A test method, device and system for digital currency offline transaction

Abstract

The application discloses a kind of digital currency offline transaction test method, device and system, it is related to computer technical field.The method one specific embodiment includes: determining current coin string information, test case and the target transaction result corresponding to test case, wherein, test case includes transaction data;Current coin string information is disassembled, and according to the result and transaction data of disassembling, generate new coin string information;Call the interface corresponding to the target to be tested, and send new coin string information to the target to be tested, so that the target to be tested carries out processing to new coin string information;Obtain the processing result for new coin string information, and according to processing result and target transaction result, determine the test result for the target to be tested and / or interface.By analysis of current coin string information and reorganization with test case, use the interface of reorganized new coin string information, reach test purpose.The method is high in degree of automation, and can verify background modification content in time and efficiently.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a kind of digital currency offline transaction test method, device and system. BACKGROUND

[0002] Digital Currancy (DC) is a kind of virtual currency based on node network and digital encryption algorithm, which is an electronic alternative form of currency. At present, in order to enable users to conveniently use digital currency, in many poor signal transaction scenarios such as shopping payment, subway card entry, etc., offline transaction mode can be used to complete payment. Among them, the correct management of digital currency offline transaction by each functional module such as the digital currency management system library module is the basis for realizing digital currency offline transaction. Therefore, the functional modules in the digital currency management system need to be tested to reduce the risk of digital currency offline transaction mode.

[0003] The existing offline currency test method usually needs to manually initiate end-to-end test, cannot realize automatic test process, and when the background content is modified, needs to manually deploy the modified version to re-deploy the joint debugging environment, cannot perform automatic test before the joint debugging stage, delays the intervention time of test, and thus leads to low test efficiency and high bug repair cost. SUMMARY

[0004] Therefore, the present application embodiment provides a kind of digital currency offline transaction test method, device and system, by the analysis of current coin string information and the reorganization with test case, and using the new coin string information after reorganization to call interface, to achieve test purpose. The method has high automation degree, can verify the content modified in background in time, and has high test efficiency.

[0005] To achieve the above object, according to the first aspect of the present application embodiment, a kind of digital currency offline transaction test method is provided.

[0006] The digital currency offline transaction test method of the present application embodiment includes determining current coin string information, test case and target transaction result corresponding to the test case, wherein the test case includes transaction data;

[0007] The current coin string information is disassembled, and new coin string information is generated according to the disassembled result and the transaction data;

[0008] Call the interface corresponding to the target to be tested, send the new coin string information to the target to be tested, so that the target to be tested processes the new coin string information;

[0009] obtaining a processing result corresponding to the new currency string information, and determining a test result corresponding to the target to be tested and / or the interface according to the processing result and the target transaction result.

[0010] Optionally, the determining of the current currency string information comprises: in a case where the preset digital currency wallet does not store digital currency, sending a transaction request to a server containing the target to be tested; receiving base currency string information returned by the server in response to the transaction request, and taking the base currency string information as the current currency string information.

[0011] Optionally, the determining of the current currency string information comprises: in a case where the preset digital currency wallet stores digital currency, determining a previous test corresponding to the current test; and taking new currency string information generated by the previous test as the current currency string information.

[0012] Optionally, the current currency string information and the new currency string information are in a TLV encoding format.

[0013] Optionally, the disassembling of the current currency string information and the generation of new currency string information according to the disassembled result and the transaction data comprise: parsing the current currency string information to obtain a first transaction chain; writing the transaction data into the first transaction chain to generate a second transaction chain; and recombining the first transaction chain and the second transaction chain according to a preset recombination rule to generate new currency string information.

[0014] Optionally, the method is implemented based on RobotFramework.

[0015] Optionally, the processing result corresponding to the new currency string information comprises: a return code, a return value and a data table.

[0016] The determining of the test result corresponding to the target to be tested and / or the interface comprises: obtaining the return code and the return value from a server, checking whether the return code and the return value are correct; and in a case where the return code and the return value are correct, generating a test result according to the data table and the target transaction result.

[0017] Optionally, the generation of the test result according to the data table and the target transaction result comprises: comparing data in the data table with the target transaction result, and outputting a test success test result if the comparison is consistent, or outputting a test failure test result otherwise.

[0018] Optionally, the TLV encoding format comprises: a feature code corresponding to a data transaction type, a feature code corresponding to a data length, and a feature code corresponding to a data value of digital currency.

[0019] Optionally, the method further comprises: sending the new currency string information to a to-be-tested target through another interface to test the other interface.

[0020] Optionally, the sending of the transaction request to the server comprising the to-be-tested target comprises: generating first message information comprising the transaction request; and sending the first message information to the server to enable the server to obtain the transaction request from the first message information.

[0021] Optionally, the receiving of the base currency string information returned by the server in response to the transaction request comprises: receiving second message information returned by the server in response to the transaction request and carrying the base currency string information; and parsing the base currency string information from the second message information.

[0022] To achieve the above object, according to a second aspect of an embodiment of the present application, a testing device for digital currency offline transaction is provided.

[0023] The testing device for digital currency offline transaction comprises:

[0024] A confirmation module configured to determine current currency string information, a test case, and a target transaction result corresponding to the test case, wherein the test case comprises transaction data;

[0025] An analysis and recombination module configured to disassemble the current currency string information, and generate new currency string information according to a disassembly result and the transaction data;

[0026] A transaction module configured to call an interface corresponding to a to-be-tested target, send the new currency string information to the to-be-tested target, and enable the to-be-tested target to process the new currency string information;

[0027] An inspection module configured to obtain a processing result for the new currency string information, and determine a test result for the to-be-tested target and / or the interface according to the processing result and the target transaction result.

[0028] Optionally, the confirmation module is further configured to, for a case where a preset digital currency wallet does not store digital currency, send a transaction request to a server comprising the to-be-tested target; receive base currency string information returned by the server in response to the transaction request, and take the base currency string information as the current currency string information.

[0029] Optionally, the confirmation module is further configured to, for a case where the preset digital currency wallet stores digital currency, determine a previous test corresponding to a current test; and take new currency string information generated by the previous test as the current currency string information.

[0030] Optionally, the current currency string information and the new currency string information are in a TLV encoding format.

[0031] Optionally, the parsing and recombination module is further configured to parse the current currency string information to obtain a first transaction chain, write the transaction data into the first transaction chain to generate a second transaction chain, and recombine the first transaction chain and the second transaction chain according to a preset recombination rule to generate the new currency string information.

[0032] Optionally, the parsing and recombination module comprises a RobotFramework component.

[0033] Optionally, the processing result of the new currency string information comprises a return code, a return value and a data table.

[0034] The checking module is further configured to obtain the return code and the return value from the server, check whether the return code and the return value are correct, and generate a test result according to the data table and the target transaction result when the return code and the return value are correct.

[0035] Optionally, the checking module is further configured to compare data in the data table with the target transaction result, and output a test success test result if the comparison is consistent, or output a test failure test result otherwise.

[0036] Optionally, the TLV encoding format comprises a feature code corresponding to a data transaction type, a feature code corresponding to a data length, and a feature code corresponding to a data value of a digital currency.

[0037] Optionally, the checking module is further configured to send the new currency string information to a target to be tested through another interface to test the other interface.

[0038] Optionally, the confirming module is further configured to generate first message information containing the transaction request, and send the first message information to the server, so that the server obtains the transaction request from the first message information.

[0039] Optionally, the confirming module is further configured to receive second message information carrying basic currency string information returned by the server in response to the transaction request, and parse the basic currency string information from the second message information.

[0040] To achieve the above object, according to a third aspect of an embodiment of the present application, a test system for digital currency offline transaction is provided.

[0041] The test system for digital currency offline transaction comprises the test device for digital currency offline transaction and a server containing a target to be tested.

[0042] The test device of the digital currency offline transaction sends the new coin string information to the service end containing the target to be tested; and the service end containing the target to be tested processes the new coin string information and returns the processing result to the test device of the digital currency offline transaction.

[0043] To achieve the above object, according to a fourth aspect of embodiments of the present application, an electronic device is provided.

[0044] The electronic device of embodiments of the present application comprises one or more processors; a storage system for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the test method of the digital currency offline transaction of embodiments of the present application.

[0045] To achieve the above object, according to a fifth aspect of embodiments of the present application, a computer readable medium is provided.

[0046] The computer readable medium of embodiments of the present application stores a computer program, which, when executed by a processor, implements the test method of the digital currency offline transaction of embodiments of the present application.

[0047] One embodiment of the above invention has the following advantages or beneficial effects: by analyzing the current coin string information and recombining with the test case, and using the new coin string information after recombination to call the interface, the purpose of testing the target interface to be tested can be achieved. The method has high automation degree, can verify the content modified in the background in time, and has high test efficiency.

[0048] The further effects of the above non-conventional optional mode will be described in the following combined with the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0049] The accompanying drawings serve to better understand the present application and do not constitute an improper limitation on the present application. Among them:

[0050] Figure 1 is a schematic diagram of a digital currency offline transaction system;

[0051] Figure 2 is a schematic diagram of the main process of a test method of a digital currency offline transaction of embodiments of the present application;

[0052] Figure 3 is a schematic diagram of the main process of determining the current coin string information of embodiments of the present application;

[0053] Figure 4 is a schematic diagram of another main process of determining the current coin string information of embodiments of the present application;

[0054] Figure 5 is a schematic diagram of a main process of generating new coin string information according to an embodiment of the present application;

[0055] Figure 6 is a schematic diagram of a main process of determining a test result for a target and / or interface to be tested according to an embodiment of the present application;

[0056] Figure 7 is a schematic diagram of main modules of a test device for digital currency offline transactions according to an embodiment of the present application;

[0057] Figure 8 is a test system for digital currency offline transactions according to an embodiment of the present application;

[0058] Figure 9 is a device interaction process schematic diagram of a test system for digital currency offline transactions according to an embodiment of the present application;

[0059] Figure 10 is an exemplary system architecture diagram to which embodiments of the present application can be applied;

[0060] Figure 11 is a structural schematic diagram of a computer system of a terminal device or a server suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0061] Exemplary embodiments of the present application are described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to assist in understanding, which should be considered in their context only. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Also, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0062] For digital currency offline transactions, the main process is that terminals directly transact through communication methods such as NFC and Bluetooth, and then upload the stored transaction information to the digital currency management system according to certain rules such as the terminal being in a networked state or a time period. Generally, the digital currency management system includes various functional modules, and the businesses processed by different functional modules differ. Among them, the functional module related to offline transactions is mainly the coin module. The coin module is mainly used to generate coin string information and process the coin string information to obtain a processed transaction result. In order to clearly illustrate the process of digital currency offline transactions, the following will be described with reference to the digital currency offline transaction system shown in Figure 1 as an example.

[0063] As shown in Figure 1As shown, the digital currency offline transaction system 100 includes a plurality of terminal devices 101, 102, 103 that communicate via NFC, Bluetooth, a digital currency management system 104 that communicates with the plurality of terminal devices 101, 102, 103, and a database 105 that stores data generated by the digital currency management system 104. The terminal devices 101, 102, 103, and the digital currency management system 104, and the digital currency management system 104 and the database 105 communicate via a communication link provided by a medium of the network 106. The network 106 can include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0064] For example, during the process of entering or exiting a subway station, the digital currency IC card or the mobile terminal with the digital currency wallet installed can communicate with the station POS via NFC to achieve direct deduction of the IC card or the digital currency wallet and record the transaction information. The station POS can manage the transaction information of the POS machine via the POS management server connected thereto. Then, the offline transaction information can be stored in the digital currency management system after a period of time or after the terminal device is connected to the network.

[0065] The terminal devices 101, 102, 103 can be various mobile electronic devices with a display screen and supporting web browsing, including but not limited to smartphones, tablet computers, POS machines, and other devices capable of installing a digital currency wallet, such as IC card deduction, IC card, etc.

[0066] The digital currency management system can be a server that provides various digital currency function services, such as analyzing, managing, and maintaining the digital currency transaction link of the digital currency offline transaction information and online transaction information uploaded by the terminal devices 101, 102, 103. The digital currency management system can also upload the analysis results to the database or the cloud. Subsequently, users with permission can view the digital currency flow situation via the database or the cloud.

[0067] It should be understood that Figure 1 The number of terminal devices, networks, and servers in the above description is only illustrative. According to the needs of implementation, there can be any number of terminal devices, networks, and servers.

[0068] Based on the above Figure 1The system shown can be seen that in the offline case, the existing offline scene such as mobile phone payment, subway card swiping, etc. is usually to upload the transaction data to the server after the transaction is completed, and the specific situation of the transaction is obtained by the client analysis, if an error occurs in the data uploading process or the server analysis process, it may cause the uploaded transaction data error, and further cause the transaction record error, and it may also cause the transaction data uploading failure due to the server interface problem. Therefore, the management process of the server interface and the offline system needs to be tested to accurately upload the offline data to the server, so as to facilitate the subsequent record and management work.

[0069] According to a first aspect of an embodiment of the present application, a method for testing digital currency offline transaction is provided.

[0070] Figure 2 is a schematic diagram of the main process of a method for testing digital currency offline transaction according to an embodiment of the present application. As Figure 2 shown, the method mainly includes:

[0071] Step S201: determining current coin string information, test case and target transaction result corresponding to the test case, wherein the test case includes transaction data;

[0072] Step S202: disassembling the current coin string information, and generating new coin string information according to the disassembled result and the transaction data;

[0073] Step S203: calling the interface corresponding to the target to be tested, and sending the new coin string information to the target to be tested, so that the target to be tested processes the new coin string information;

[0074] Step S204: obtaining the processing result for the new coin string information, and determining the test result for the target to be tested and / or the interface according to the processing result and the target transaction result.

[0075] Among them, the target to be tested can be a certain module in the server to be tested, or the server and / or interface to be tested. The test case is the transaction data for testing, and the type of transaction data can be the same or different; the target transaction result corresponding to the test case is the expected transaction result after the transaction data in the test case is transacted. For example, the test case is that user A has 20 yuan in the digital wallet, user B has 10 yuan in the digital wallet, and user A transfers 10 yuan to user B, then the target transaction result corresponding to the test case is that user A has 10 yuan left in the digital wallet after the transaction, and user B has 20 yuan in the digital wallet after the transaction.

[0076] For the digital currency, the coin string information contains information of all digital currencies in the digital currency wallet, such as the face value of the digital currency, the corresponding amount under each face value, and the information of the digital currency owner, etc. The storage status of all digital currencies in the current digital currency wallet can be obtained through the coin string information.

[0077] It is worth noting that the above-mentioned method for testing the offline transaction of the digital currency can be completed by a terminal device. In order to better simulate the actual transaction, a preset digital currency wallet or a simulated digital currency wallet is generally used to store the above-mentioned digital currency. At the same time, steps S203 and S204 in the present application, especially embody the testing of offline transactions. Offline transaction testing can be performed through automated test cases, and the offline transaction results are verified, and the generated new coin string information is issued to the target to be tested.

[0078] In the case that the preset digital currency wallet does not store digital currency, the digital currency needs to be stored in the digital currency wallet first before the subsequent test can be performed. In an optional embodiment, the transaction category of the transaction request can be a recharge, transfer, or other operation of transferring digital currency to the digital currency wallet. In the present application, the complete process of automated testing can be realized through RobotFramework. Among them, the process of obtaining the processing result of the target to be tested for the new coin string information, the coin string information, the transaction data, and the server message interface and the reorganization of the coin string can be realized based on RobotFramework.

[0079] In addition, the test case can also be set through the RobotFramework.

[0080] In the prior art, the coin string information of the digital currency is usually generated by the server's library currency module and third-party card plug-in, and cannot be manually generated. Among them, the third-party card can be an SDK card, and the library currency module can detect and analyze the legality of the coin string information, and then obtain transaction information such as transaction amount. Since the generation method of the coin string information can only be generated by the server, in the functional test stage, the app front end needs to initiate a transaction instruction, upload the coin string information through the plug-in, and issue the coin string information through the library currency module background to complete the test. This results in a lag in test intervention time, incomplete coverage of abnormal scenarios, and problems such as inability to perform regression testing through automated testing.

[0081] Based on the above-mentioned digital currency generation process, the digital currency for testing needs to be obtained from the server before testing. In an optional embodiment, as shown in Figure 3 , it includes:

[0082] Step S301: sending a transaction request to a server containing a target to be tested;

[0083] Step S302: receiving the base currency string information returned by the service end in response to the transaction request, and taking the base currency string information as the current currency string information.

[0084] The transaction type in the transaction request is a transaction type of depositing digital currency into a digital currency wallet, such as recharging, transferring in, etc.

[0085] In an optional embodiment, the transaction request is sent to the service end containing the target to be tested in the form of a message, specifically including: generating first message information containing the transaction request; and sending the first message information to the service end, so that the service end obtains the transaction request from the first message information.

[0086] In a further optional embodiment, the service end also returns the base currency string information in the form of a message, wherein receiving the base currency string information returned by the service end in response to the transaction request specifically includes: receiving second message information returned by the service end in response to the transaction request, the second message information carrying the base currency string information; and parsing the base currency string information from the second message information.

[0087] In the case where the preset digital currency wallet stores digital currency, in an optional embodiment, as shown in Figure 4 , it includes:

[0088] Step S401: determining the last test corresponding to the current test;

[0089] Step S402: taking the new currency string information generated by the last test as the current currency string information.

[0090] When the digital currency wallet stores digital currency, there is no need to obtain the initial currency string information through the server again, and the new currency string information generated after the last test can be directly used. This way can make the entire test process be executed in a loop, and after each test, the new currency string information generated is directly used for the next test, so that all test cases can be tested quickly, and the test efficiency is improved.

[0091] In an optional embodiment, the current currency string information and the new currency string information are in TLV encoding format. In a further optional embodiment, the TLV encoding format includes: a feature code corresponding to a data transaction type, a feature code corresponding to a data length, and a feature code corresponding to a data value of digital currency. Through the TLV encoding format, the transaction of digital currency can be well recorded, which is convenient for subsequent tracking and statistics of digital currency.

[0092] For step S202, in an optional embodiment, as shown in Figure 5 , it includes:

[0093] Step S501: parsing the current coin string information to obtain a first transaction chain;

[0094] Step S502: writing transaction data into the first transaction chain to generate a second transaction chain;

[0095] Step S503: recombining the first transaction chain and the second transaction chain according to a preset recombination rule to generate new coin string information.

[0096] In the coin string information, the transaction chain information is included, that is, the chain information of the current digital currency flow process, from which it can be obtained that the current digital currency once belonged to which owner and how it was circulated to the current owner. The first transaction chain can verify the legality of the coin string information. Compared with the first transaction chain, the second transaction chain further includes the transaction chain information of the digital currency after recombination according to the test case, that is, the owner of the new coin string. By generating the first transaction chain from the current coin string information and recombining the first transaction chain and the second transaction chain, the legality of the coin string information can be effectively verified, and the coin string of the transaction can be tracked.

[0097] The processing result of the new coin string information can include a plurality of required parameters according to human setting. In an optional embodiment, the processing result of the new coin string information includes a return code, a return value and a data table. The return code and the return value can be set according to a preset rule and then pre-stored in the client. According to the return code and the return value, it can be judged whether the to-be-tested target and / or the interface is in a healthy state. Only when the to-be-tested target and / or the interface is in a healthy state, it can be further judged whether the test transaction result is correct.

[0098] In an optional embodiment, determining the test result for the to-be-tested target and / or the interface, as shown in Figure 6 , includes:

[0099] Step S601: obtaining the return code and the return value from the server, and checking whether the return code and the return value are correct;

[0100] Step S602: in the case that the return code and the return value are correct, generating a test result according to the data table and a target transaction result.

[0101] In a further optional embodiment, the generating of the test result according to the data table and the target transaction result includes comparing the data in the data table with the target transaction result. If the comparison is consistent, a test success test result is output, otherwise a test failure test result is output.

[0102] In some practical application test processes, the amount in the digital currency wallet may not meet the amount requirement of the test case, that is, the existing amount in the digital currency wallet cannot complete the transfer of a large amount, thereby causing inconsistent test results. Therefore, when comparing test results, the test results can be classified and divided according to the transaction type, for example, the test case results of the transaction type of transfer-in are output as data table one, and the test case results of the transaction type of transfer-out are output as data table two. When the data in data table one is compared with the target transaction result and is all correct, and when the data in data table two is compared with the target transaction result and an error occurs, it is considered that the amount in the digital currency wallet does not meet the amount requirement of the test case, and it is not a problem caused by the digital currency management system. Therefore, the test result of test success is still output.

[0103] In some practical application test processes, the data in the data table may not be completely consistent with the target transaction result, or only individual data may be incorrect. This may be caused by system errors or individual errors caused by some network reasons. Therefore, a target threshold can be set for the consistency of the data. When the consistency of the data in the data table and the target transaction result reaches the target threshold, the individual data error can be ignored, and the test result of test success is output. When the consistency of the data in the data table and the target transaction result cannot reach the target threshold, it is considered that the data error is caused by the program of the management system itself, and the test result of test failure is output.

[0104] In an optional embodiment, the data table can be stored in the storage module of the target to be tested, such as a database, to facilitate subsequent export and data recording. Further, for the data table generated by each test, all data tables can be stored, or the data tables can be stored in an overwriting mode, such as cyclic overwriting or piece-by-piece overwriting. Cyclic overwriting means that the number of cyclic overwriting is set, and only the last 10 data tables of the test can be saved. When a new data table is generated, the 11th data table is deleted to ensure the persistent availability of the database storage space. Piece-by-piece overwriting means that each time a new data table is generated, the data table generated by the last test is overwritten, so that the latest data table generated by the test is always stored in the database, effectively saving the memory space in the database.

[0105] When the target to be tested has multiple interfaces that need to be tested one by one, in an optional embodiment, the method further comprises: sending the new coin string information to the target to be tested through other interfaces to test the other interfaces.

[0106] The method for testing the digital currency offline transaction of the embodiment of the application can achieve the purpose of testing each interface of the target to be tested by analyzing the current coin string information, recombining the test case, and calling the interface using the new coin string information after recombination. The method has high automation degree, can verify the content modified in the background in time, and has high testing efficiency.

[0107] According to a second aspect of the embodiment of the application, a testing device for digital currency offline transaction applied to a server is provided.

[0108] Figure 7 is a schematic diagram of main modules of the testing device 700 for digital currency offline transaction according to the second aspect of the embodiment of the application. As shown in Figure 7 , it comprises:

[0109] The confirmation module 701 is configured to determine the current coin string information, the test case, and the target transaction result corresponding to the test case, wherein the test case comprises transaction data.

[0110] The analysis and recombination module 702 is configured to disassemble the current coin string information, and generate new coin string information according to the disassembled result and the transaction data.

[0111] The transaction module 703 is configured to call the interface corresponding to the target to be tested, send the new coin string information to the target to be tested, so that the target to be tested processes the new coin string information.

[0112] The checking module 704 is configured to obtain the processing result of the new coin string information, and determine the test result of the target to be tested and / or the interface according to the processing result and the target transaction result.

[0113] In an optional embodiment, the confirmation module 701 is further configured to, in the case that the preset digital currency wallet does not store digital currency, send a transaction request to a server containing the target to be tested; receive the basic coin string information returned by the server in response to the transaction request, and take the basic coin string information as the current coin string information.

[0114] In an optional embodiment, the confirmation module 701 is further configured to, in the case that the preset digital currency wallet stores digital currency, determine the last test corresponding to the current test; take the new coin string information generated by the last test as the current coin string information.

[0115] In an optional embodiment, the current coin string information and the new coin string information are in TLV encoding format.

[0116] In an optional embodiment, the parsing and recombining module 702 is further configured to parse the current currency string information to obtain a first transaction chain; write the transaction data into the first transaction chain to generate a second transaction chain; and recombine the first transaction chain and the second transaction chain according to a preset recombination rule to generate new currency string information.

[0117] In an optional embodiment, the parsing and recombining module 702 comprises a RobotFramework component.

[0118] In an optional embodiment, the processing result for the new currency string information comprises a return code, a return value and a data table.

[0119] The checking module 704 is further configured to obtain the return code and the return value from the server, check whether the return code and the return value are correct, and generate a test result according to the data table and the target transaction result in a case where the return code and the return value are correct.

[0120] In an optional embodiment, the checking module 704 is further configured to compare data in the data table with the target transaction result, and output a test success test result if the comparison is consistent, or output a test failure test result otherwise.

[0121] In an optional embodiment, the TLV encoding format comprises a feature code corresponding to a data transaction type, a feature code corresponding to a data length and a feature code corresponding to a data value of a digital currency.

[0122] In an optional embodiment, the checking module 704 is further configured to send the new currency string information to a target to be tested through another interface to test the other interface.

[0123] In an optional embodiment, the confirming module 701 is further configured to generate first message information comprising the transaction request, and send the first message information to the server to enable the server to obtain the transaction request from the first message information.

[0124] In an optional embodiment, the confirming module 701 is further configured to receive second message information carrying basic currency string information returned by the server in response to the transaction request, and parse the basic currency string information from the second message information.

[0125] The test device for digital currency offline transactions according to the embodiment of the application can test each interface of a target to be tested by parsing current currency string information, recombining with a test case, and calling an interface using new currency string information after recombination. The device has high automation and can verify content modified in the background in time, and has high test efficiency.

[0126] The apparatus for testing the offline transaction of the digital currency can execute the method provided by the embodiments of the present application, and has the corresponding function modules and beneficial effects of the execution method. Technical details not described in detail in the embodiments can be referred to the method provided by the embodiments of the present application.

[0127] Figure 8 A system for testing the offline transaction of the digital currency is provided according to the third aspect of the embodiments of the present application, as shown in Figure 8 The system includes an apparatus for testing the offline transaction of the digital currency 801 and a service end containing a target to be tested 802, wherein the apparatus for testing the offline transaction of the digital currency 801 sends new coin string information to the service end containing the target to be tested 802; the service end containing the target to be tested 802 processes the new coin string information, and returns the processed result to the apparatus for testing the offline transaction of the digital currency.

[0128] The testing process of the offline transaction of the digital currency can be performed through the interaction between the terminal device installed with the apparatus for testing the offline transaction of the digital currency (hereinafter referred to as the testing apparatus), the service end containing the target to be tested, and the database, as shown in Figure 9 It should be noted that, in order to clearly illustrate the entire testing process, in this embodiment, the terminal device is taken as an example, which does not contain the digital currency for testing in the preset digital currency wallet, and the interface one and the interface two are tested respectively. As shown in Figure 9 The device interaction process includes the following steps:

[0129] Step S901: Pre-storing transaction data in the terminal device installed with the testing apparatus, and determining a target transaction result;

[0130] Step S902: The terminal device installed with the testing apparatus sends a transaction request to the digital currency management system;

[0131] Step S903: Receiving the basic coin string information returned by the digital currency management system in response to the transaction request;

[0132] Step S904: Taking the basic coin string information as the current coin string information, disassembling the current coin string information, and generating new coin string information according to the disassembled result and the transaction data;

[0133] Step S905: The terminal device installed with the testing apparatus calls the interface one of the digital currency management system, and sends the new coin string information to the digital currency management system;

[0134] Step S906: The digital currency management system processes the received new coin string information; and Step S907: sends the processed result to the database;

[0135] Step S908: The database stores the processed processing result.

[0136] Step S909: The terminal device with the test device obtains the processing result from the database.

[0137] Step S910: The test result for the to-be-tested interface one is determined according to the obtained processing result and the target transaction result.

[0138] At this time, the digital currency wallet has stored the digital currency after completing the test once. If the to-be-tested interface two is to be tested, step S911 can be executed: the new coin string information generated by the last test is taken as the current coin string information, the current coin string information is disassembled, and new coin string information is generated according to the disassembled result and the transaction data.

[0139] Step S912: The interface two is called, and the new coin string information is sent to the digital currency management system.

[0140] Step S913: The digital currency management system processes the received new coin string information; and step S914 is executed: the processed processing result is sent to the database.

[0141] Step S915: The database stores the processed processing result.

[0142] Step S916: The terminal device with the test device obtains the processing result from the database.

[0143] Step S917: The test result for the to-be-tested interface two is determined according to the obtained processing result and the target transaction result.

[0144] It is worth noting that the above device interaction process between the terminal device with the test device and the digital currency management system is only an example, and any interaction between the terminal device with the test device and the digital currency management platform to realize payment and collection is within the protection scope of the embodiments of the present application. The terminal device with the test device includes, but is not limited to, a laptop computer and a desktop computer, etc. Moreover, in the present application, only in the first test, that is, in the case that the digital currency wallet does not store digital currency, the basic coin string information needs to be obtained through networking, and in the subsequent test process, the process is not required, reducing the network consumption.

[0145] The test system for the digital currency offline transaction of the embodiment of the present application can complete the analysis of the coin string information of the digital currency and the reorganization with the test case in the offline case, and call the interface using the new coin string information after reorganization, so as to achieve the purpose of testing each interface of the target to be tested, and further meet the needs of efficient and automatic regression testing of the target to be tested.

[0146] Figure 10 An exemplary system architecture 1000 in which the method or test device for testing the digital currency offline transaction of the embodiment of the present application can be applied is shown.

[0147] As shown in Figure 10 The system architecture 1000 can include a terminal device 1001, a network 1002, a server containing a target to be tested 1003, and a database 1004 for storing transaction data. The network 1002 is used as a medium to provide a communication link between the terminal device 1001 and the server containing the target to be tested 1003. The network 1002 can include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0148] The user can use the terminal device 1001 to interact with the server containing the target to be tested 1003 through the network 1002 to receive or send messages, etc., and can also obtain the transaction data processed by the server containing the target to be tested 1003 from the database 1004 through the network 1002. The terminal device 1001 can be a mobile terminal, a POS machine, etc. installed with a digital wallet.

[0149] The terminal device 1001 can be various electronic devices with a display screen and supporting web browsing, including but not limited to laptop computers and desktop computers, etc.

[0150] The server containing the target to be tested 1003 can be a server providing various services, such as a background management server supporting the digital currency transaction of the user using the terminal device 1001. The background management server can analyze and process the transaction data, such as the received digital currency transaction request, the coin string information acquisition request, etc., and feed back the processing results (such as transaction data, transaction information) to the terminal device.

[0151] It should be noted that the method for testing the digital currency offline transaction provided by the first aspect of the embodiment of the present application is generally executed by the terminal device 1001, and correspondingly, the device for testing the digital currency offline transaction provided by the second aspect of the embodiment of the present application is generally arranged in the terminal device 1001.

[0152] It should be understood that Figure 10The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0153] The following is for reference. Figure 11 It shows a schematic diagram of the structure of a computer system 1100 suitable for implementing a terminal device of the present invention. Figure 11 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0154] like Figure 11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1102 or programs loaded from storage section 1108 into random access memory (RAM) 1103. The RAM 1103 also stores various programs and data required for the operation of the system 1100. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0155] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1105 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1107 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1107 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0156] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs the functions defined above in the system of this invention.

[0157] It should be noted that the computer-readable medium shown in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to, electrical connections with one or more conductive wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system or device. In the present application, the computer-readable signal medium can include a data signal carrying computer-readable program code in a baseband or as part of a carrier wave. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate or transmit programs for use by or in conjunction with an instruction execution system, system or device. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination thereof.

[0158] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, program segment or a part of code containing one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different order than that shown in the drawings. For example, two blocks that are shown in succession can actually be executed substantially in parallel, and they can also be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams or flowcharts, and the combination of blocks in the block diagrams or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0159] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. The described modules can also be arranged in a processor, for example, a processor can be described as including a sending module, an obtaining module, a determining module and a first processing module. In some cases, the names of these modules do not constitute a limitation on the modules themselves, for example, the sending module can also be described as "a module that sends an image obtaining request to a connected server".

[0160] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist independently without being assembled into the device. The computer readable medium carries one or more programs, which, when executed by the device, cause the device to include:

[0161] determining current currency string information, a test case and a target transaction result corresponding to the test case, wherein the test case includes transaction data; disassembling the current currency string information, and generating new currency string information according to the disassembled result and the transaction data; calling an interface corresponding to the target to be tested, and sending the new currency string information to the target to be tested, so that the target to be tested processes the new currency string information; obtaining a processing result for the new currency string information, and determining a test result for the target to be tested and / or the interface according to the processing result and the target transaction result.

[0162] The method and device for testing digital currency offline transactions according to the embodiments of the present application can achieve the purpose of testing the target interface to be tested by analyzing the current currency string information, recombining the test case, and calling the interface using the recombined new currency string information. The method has high automation degree, can verify the content modified in the background in time, and has high testing efficiency.

[0163] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made depending on design requirements and other factors. Any modification, equivalent replacement and improvement made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A testing method for offline digital currency transactions, characterized in that, include: Determine the current coin string information, test cases, and the target transaction results corresponding to the test cases, wherein the test cases include transaction data; The current coin string information is disassembled, and new coin string information is generated based on the disassembly results and the transaction data; The interface corresponding to the target to be tested is called to send the new coin string information to the target to be tested, so that the target to be tested can process the new coin string information; Obtain the processing result for the new coin string information, and determine the test result for the target to be tested and / or the interface based on the processing result and the target transaction result; The determination of the current coin string information specifically includes: for the case where a preset digital currency wallet stores digital currency. Determine the previous test corresponding to the current test; The new coin string information generated in the previous test is used as the current coin string information.

2. The method according to claim 1, characterized in that, The determination of the current coin string information includes: In cases where the pre-installed digital currency wallet does not store digital currency, Send a transaction request to the server containing the target to be tested; Receive the base currency string information returned by the server in response to the transaction request, and use the base currency string information as the current currency string information.

3. The method according to claim 1, characterized in that, Both the current coin string information and the new coin string information are encoded in TLV format.

4. The method according to claim 1, characterized in that, The step of disassembling the current coin string information and generating new coin string information based on the disassembly results and the transaction data includes: The first transaction chain is obtained by parsing the current coin string information; The transaction data is written into the first transaction chain to generate the second transaction chain; The first transaction chain and the second transaction chain are recombined according to a preset recombination rule to generate new coin string information.

5. The method according to claim 1, characterized in that, The method is implemented based on RobotFramework.

6. The method according to claim 1, characterized in that, The processing results for the new coin string information include: return code, return value, and data table; Determining the test results for the target under test and / or the interface includes: Obtain the return code and return value from the server, and check whether the return code and return value are correct; If the return code and the return value are correct, a test result is generated based on the data table and the target transaction result.

7. The method according to claim 6, characterized in that, Based on the data table and the target transaction results, the generation of test results includes: The data in the data table is compared with the target transaction result. If the comparison is consistent, a test result of successful test is output; otherwise, a test result of failed test is output.

8. The method according to claim 3, characterized in that, The TLV encoding format includes: feature codes corresponding to data transaction types, feature codes corresponding to data lengths, and feature codes corresponding to the data values ​​of digital currencies.

9. The method according to claim 1, characterized in that, The method further includes: The new coin string information is sent to the target to be tested through other interfaces in order to test the other interfaces.

10. The method according to claim 2, characterized in that, Sending a transaction request to the server containing the target to be tested includes: Generate a first message containing the transaction request; The first message information is sent to the server so that the server can obtain the transaction request from the first message information.

11. The method according to claim 2, characterized in that, The step of receiving the base currency string information returned by the server in response to the transaction request includes: Receive the second message information carrying the base currency string information returned by the server in response to the transaction request; The base coin string information is parsed from the second message information.

12. A testing device for offline digital currency transactions, characterized in that, include: The confirmation module is used to determine the current coin string information, test cases, and the target transaction result corresponding to the test cases, wherein the test cases include transaction data; The parsing and reorganization module is used to disassemble the current coin string information and generate new coin string information based on the disassembly results and the transaction data; The transaction module is used to call the interface corresponding to the target under test and send the new coin string information to the target under test so that the target under test can process the new coin string information. The inspection module is used to obtain the processing result for the new coin string information, and determine the test result for the target to be tested and / or the interface based on the processing result and the target transaction result; The confirmation module is further used to determine the previous test corresponding to the current test when the preset digital currency wallet stores digital currency; and to use the new coin string information generated in the previous test as the current coin string information.

13. The apparatus according to claim 12, characterized in that, The parsing and reorganization module is further configured to parse the current coin string information to obtain a first transaction chain; write the transaction data into the first transaction chain to generate a second transaction chain; and reorganize the first transaction chain and the second transaction chain according to a preset reorganization rule to generate new coin string information.

14. The apparatus according to claim 12, characterized in that, The processing results for the new coin string information include: return code, return value, and data table; The inspection module is further configured to obtain the return code and the return value from the server, and check whether the return code and the return value are correct; if the return code and the return value are correct, generate test results based on the data table and the target transaction result.

15. A testing system for offline digital currency transactions, characterized in that, The device includes a testing apparatus for offline digital currency transactions as described in any of claims 12-14, and a server containing the target to be tested, wherein... The testing device for offline digital currency transactions sends the new coin string information to the server containing the target to be tested. The server containing the target to be tested processes the new coin string information and returns the processed result to the testing device for offline digital currency transactions.

16. An electronic device, characterized in that, include: One or more processors; A storage system is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-11.

17. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-11.

Images