Full-link transaction automatic testing method and system

Abstract

The invention provides a full-link transaction automatic test method and system. The full-link transaction automatic test method specifically comprises the following steps: S1, acquiring test set information; s2, obtaining transaction test case information, creating a transaction test case, and storing a transaction test case execution result into the transaction test case information; s3, executing the transaction test case to form an actual result of executing the transaction test case; s4, comparing the execution result of the transaction test case with an actual result, if the execution result of the transaction test case is consistent with the actual result, passing the test and outputting the execution result table of the transaction test case, otherwise, not passing the test and outputting the execution result table of the transaction test case; s5, repeatedly executing the steps S2-S4 until all transaction test case execution result tables are output, and outputting a test set execution result table; automatic testing of the transaction full-link process is achieved, asynchronous assertion processing after interface synchronous assertion is completed, and the testing efficiency and accuracy are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and particularly to a full-link transaction automated testing method and system. Background Art

[0002] In the current field of automated testing, interface automated testing plays a crucial role. This testing process generally covers multiple core steps: First, data preprocessing is carried out, which includes parameter setting and adjustment (i.e., parameterization), normalization of data formats, necessary encryption operations, and acquisition of common parameters, etc., to ensure the accuracy and consistency of test data. Subsequently, pre-written test scripts are executed, and these scripts test the interface according to established logics and processes to verify its functions and performance.

[0003] After the test script is executed, the system performs assertion processing on the response parameters. Assertion processing is to compare and verify the actual response according to the expected results to determine whether the interface works as expected. This step is a key link to ensure the correctness of the interface. Finally, execution result reports are generated according to preset templates, and these reports display the test results in different forms for easy analysis and summary by testers.

[0004] However, for transaction testing, merely focusing on the direct execution results of the interface (i.e., synchronous responses) is not enough. Transaction testing also needs to verify multiple subsequent links, including the reception and processing of asynchronous notifications, the situation of data being written to the table in the database (i.e., storing transaction data in the database), the update of transaction status, the accuracy of settlement results, and the consistency of member accounting, etc. These links together constitute the full-link process of the transaction, and any omission in these links may lead to transaction failure or data inconsistency.

[0005] Currently, the processing of test execution results still mainly focuses on synchronously processing response messages. The core of this traditional method is that once the interface synchronously responds successfully, it is considered that the interface test passes. However, this is only a verification of the immediate return results of the interface, which we call "synchronous assertion". Synchronous assertion ensures that the interface can immediately return the expected results after receiving a request, but it does not cover all subsequent links of the transaction.

[0006] After the interface synchronously responds successfully, the transaction often involves a series of subsequent steps, such as the change of transaction status, data processing, reception and processing of asynchronous notifications, etc. The correctness of these subsequent links is crucial for the entire transaction process. However, currently, these links still need to be manually followed up and checked. This manual-dependent method is not only inefficient, consuming a large amount of labor costs, but also prone to omissions and errors when facing a large number of test orders due to limited human energy and attention.

[0007] Therefore, in order to comprehensively verify the correctness of the transaction process, it is necessary to further introduce asynchronous assertion processing on the basis of synchronous assertions. Asynchronous assertion refers to the process of continuously monitoring and verifying the subsequent links of a transaction after the synchronous response of an interface is successful. It focuses on the integrity and consistency of each link in the transaction process to ensure that the entire transaction process is executed as expected from beginning to end.

[0008] Therefore, how to implement automated testing of the entire transaction process, especially how to complement asynchronous assertion processing after synchronous assertions to achieve comprehensive monitoring and verification of the transaction process, has become an urgent problem to be solved in the current field of automated testing. Summary of the Invention

[0009] To solve the technical problems raised in the above background art, the present invention provides a method and system for automated testing of the entire transaction process, aiming to achieve automated testing of the entire transaction process and complement asynchronous assertion processing after synchronous assertions of an interface to improve testing efficiency and accuracy.

[0010] In the first aspect, the present invention provides a method for automated testing of the entire transaction process, including the following steps:

[0011] Step S1, obtaining test set information; wherein, the test set includes one or more (in this application, the "multiple" means at least two) transaction test case information;

[0012] Step S2, obtaining one piece of transaction test case information, creating a transaction test case according to the transaction test case information, and storing the execution result of the transaction test case into the transaction test case information; wherein, the execution result of the transaction test case represents the expected result formed by executing the transaction test case;

[0013] Step S3, executing the transaction test case to form the actual result of executing the transaction test case;

[0014] Step S4, comparing the execution result of the transaction test case with the actual result. If they are consistent, the test passes and the execution result table of the transaction test case is output; otherwise, the test fails and the execution result table of the transaction test case is output;

[0015] Step S5, repeatedly executing steps S2 - S4 until after all the execution result tables of the transaction test cases are output, outputting the execution result table of the test set.

[0016] Preferably, in step S2, the formation method of the transaction test case information specifically includes the following steps:

[0017] Step S201: Set an execution instruction set; wherein, the execution instruction set includes one or more execution instructions; the execution instructions include input parameter processing instructions, output parameter processing instructions, assertion processing instructions, and notification callback monitoring instructions;

[0018] Step S202: Combine one or more execution instructions to form transaction test case information.

[0019] Preferably, in step S2, the transaction test case information is saved through a persistence layer database. More preferably, the persistence layer database is MySQL.

[0020] Preferably, in step S3, one or more threads in the thread pool are used to execute the transaction test case, and the thread pool is a dynamically created thread pool or a default thread pool.

[0021] Preferably, in step S3, when executing the transaction test case to form the actual result of executing the transaction test case, the following steps are specifically included:

[0022] Step S301: Configure input parameters, output parameters, and execution parameters and select an executor according to the transaction test case; wherein, the input parameters include random parameters, encrypted parameters, and encoded parameters; the output parameters include signature verification parameters, decryption parameters, and decoding parameters; the execution parameters include the waiting time at the start of execution, the waiting time at the end of execution, the number of execution loops, and the interval between execution loops;

[0023] Step S302: Obtain an execution instruction from the execution instruction set in the transaction test case, parse the execution instruction to form a parsed execution instruction, and convert the data format or data type of the parsed execution instruction to form a data format or data type recognizable by the executor;

[0024] Step S303: According to the parsed and format-converted execution instruction, the executor performs an operation to form the execution result of the current execution instruction.

[0025] Step S304: Perform synchronous assertion processing and output parameter processing on the execution result. If the execution result is consistent with the expected result, execute step S305; otherwise, end the execution of the transaction test case; wherein, the synchronous assertion processing is used to perform assertion processing on the execution result of the execution instruction.

[0026] Step S305: After the operation of the executor is completed, parse and convert the execution result obtained through the executor to form the actual execution result of the execution instruction.

[0027] Step S306: Determine whether the execution instructions in the execution instruction set have been executed. If not, repeat Steps S302 - S305 until all the execution instructions in the execution instruction set have been executed, and form the actual result of the test case.

[0028] Preferably, in Step S302, the executor includes MySQL, HTTP, and Dubbo.

[0029] Preferably, in Step S304, while performing synchronous assertion processing and out-parameter processing, when the instruction set includes instructions that need to be executed asynchronously, perform asynchronous processing.

[0030] In this application, the instruction table is used to record in detail the information of each instruction to be executed, including various details of the execution instruction; the test case table is used to record the complete instruction information of the transaction test case, including the specific execution instruction ID corresponding to the instruction table; the test set table is used to record a test set composed of multiple transaction test cases; the instruction execution result table is used to record the execution result information of each instruction to ensure that the execution status of each instruction is queryable; the transaction test case execution result table is used to record the execution result of the transaction test case, including the execution order number of each instruction and the corresponding execution result, to track the execution status of the transaction test case; the test set execution result table is used to record the execution result of the entire test set, including the execution results of each transaction test case, the overall success rate, the total execution time, and other key information to comprehensively evaluate the execution result of the test set; the asynchronous notification callback table is used to record the information of all notification callbacks to ensure the transparency and traceability of the asynchronous notification process; the scheduled task execution table is used to record the execution information of the scheduled task to ensure the accurate execution and effective management of the scheduled task; the synchronous assertion execution result table is used to record the execution result of the synchronous assertion; the asynchronous assertion execution result table is used to record the execution result of the asynchronous assertion.

[0031] In this application, the test set includes one or more test cases; the test case includes one or more execution instructions; the execution instruction includes synchronous assertion instructions and asynchronous assertion instructions, where the number of synchronous assertion instructions is one or more, and the number of asynchronous assertion instructions is one or more.

[0032] In this application, the instruction list includes: 1) Primary key ID; 2) Step name stepName; 3) Group name groupName; 4) Environment identifier evn; 5) Executor type commandType, including HTTP, MYSQL, and DUBBO; 6) Request body information parameter reqBody, which is used when the executor type is HTTP and DUBBO, and is stored in the database as a json string. When the value of the key-value pair hits a special value starting with the apollo configuration (e.g., @), the corresponding processing tool will be found based on the field after intercepting the special character, including various random parameters (e.g., RANDOMM16 - generate 16-bit random numbers, RANDOMW20 - generate 20-bit random letters, RANDOMT13 - generate 13-bit timestamps, etc.), encryption (e.g., SM4, AES, etc.), encoding (Base64, URLEncode, HEX, etc.); 7) reqHeader, which is read when the executor type is HTTP. If it is empty, the default configuration is used. If there is a value, it is added to the HTTP request header parameters; 8) reqInfo, which is stored in the database as a json string. The fields include memberId merchant number, terminalId terminal number, and signType signature type. Through these three parameters, the corresponding key certificate can be found. When the field url is an HTTP executor, it stores the request address. When the field url is a DUBBO executor, it stores the dubbo interface registration information mapping code. When the field url is a MYSQL executor, it stores the data source mapping code. When it is an HTTP executor, the field caseType performs different types of signature verification, encryption, and decryption processing on the request message and response message; 9) assertRetry, which is stored in the database as a json string and uses the general assertion logic to repeat the execution if the assertion is successful; 10) assertSuccess, which is stored in the database as a json string and uses the general assertion logic to execute the next step if the assertion is successful and terminate if it fails; 11) Maximum number of repeated executions executeTimes. When the maximum number of executions is reached, the test result is updated as failed, with assertion information and no clear result in case of timeout; 12) Repeated execution interval time executeDelayTime; 13) Initial execution start waiting time waitingTime; 14) pullBodyGlobalParams, which is stored in the database as a json string and uses the general logic for setting parameters. It needs to obtain from the global parameters and then set them to the parameters of the request body; 15) pullHeaderGlobalParams, which is stored in the database as a json string and uses the general logic for setting parameters. It needs to obtain from the global parameters and then set them to the parameters of the request header;16) pushReqBodyToGlobalParams, which stores in the database as a JSON string and uses the general logic for setting parameters. It is the parameter that needs to be set from the request body to the global parameters; 17) pushReqHeaderToGlobalParams, which stores in the database as a JSON string and uses the general logic for setting parameters. It is the parameter that needs to be set from the request header to the global parameters; 18) pushResBodyToGlobalParams, which stores in the database as a JSON string and uses the general logic for setting parameters. It is the parameter that needs to be set from the response body to the global parameters; 19) pushResHeaderToGlobalParams, which stores in the database as a JSON string and uses the general logic for setting parameters. It is the parameter that needs to be set from the response header to the global parameters; 20) noticeListen, which stores in the database as a JSONArray. Each JSON is a notification. Each JSON field has a notifyType for the notification type and a noticeNo for the notice order number, whose value is the key value in the global parameters. (For example, if it is required to set the outTradeNo in the request body as the noticeNo, then add a key-value pair in the pushReqBodyToGlobalParams parameter, with the key value as outTradeNo and the value as outTradeNo. Then add a key-value pair to a JSON in noticeListen, with the key value noticeNo and the value outTradeNo. Then the outTradeNo in the order placement request will be assigned to noticeNo.) Each existing JSON will insert a data record into the asynchronous notification table. The fields include the batch number batchNo of the transaction test case execution, the instruction order number stepNo, the notice order number noticeNo, the notification type notifyType, the creation time createTime. After receiving the asynchronous notification, it will update the notice content noticeData, the notice status noticeStatus, the notice times noticeTime, whether the instruction execution result table noticeCommandResult has been updated, the source ip sourceIp, and the update time updataTime;21) asyncAssert stores data in the database as a jsonArray string. Each json represents an asynchronous assertion. The general assertion logic is used. In addition to the assertion fields, there are fields datasourceInfo to store data source information and sqlInfo to store sql information (for example, the where condition trade_no = @clearTradeNo and code = 302 means that if it starts with the special character @, the value is obtained from the global parameter. The example condition means obtaining the value of clearTradeNo from the global parameter as the value of trade_no =, and the code = 302 without the special character @ is not processed). The asynchronous assertion will be processed after a single step is executed successfully, inserted into the asynchronous assertion execution table, and the scheduled task will scan the table and then perform assertion processing based on the data source information, sql information, and assertion information.;

[0033] Among them, for the general assertion logic judgment, the assertion information is stored in json format, with the key being the field to be asserted and the value being the expected result. If the value is a String, it is judged whether they are equal. If the value is a List, it is judged whether it contains;

[0034] For the general logic of setting parameters, the assertion information is stored in json format, with the key being the target key value setKey to be set and the value being the key value getKey to obtain the parameter. After successfully obtaining the parameter value, the value of getKey is assigned to the value of setKey;

[0035] For the logic of obtaining key values, recursively traverse the target object;

[0036] General explanation of database fields: 0 represents unknown, 1 represents true, and 2 represents false.

[0037] In this application, the test case table includes: 1) primary key ID; 2) case name caseName; 3) group name groupName; 4) environment identifier evn; 5) specific execution steps stepIds, storing the ids in the instruction table separated by commas, such as 1, 10, 20, 2, 3, 1. When executing, it is first converted into a list, and then the instruction table is queried in sequence through the primary key ID to construct a specific executable test case. When constructing, a json format global parameter globalParams will be created as the parameter running through the entire test case.

[0038] Among them, the test cases are combined according to the execution instructions. For example, placing an order is an http instruction, querying an order is another http instruction, and querying the settlement status of an order in the database is a mysql instruction.

[0039] In this application, the test set table includes: 1) Primary key ID; 2) Test set name suitName; 3) Test set grouping suitGroup; 4) Test cases caseIds of the test set, storing the primary key IDs of the test cases separated by commas, such as 2, 3, 4, 99, 100, 110. When executing, specific test cases are queried according to the primary key ID; 5) Test set environment suitEvn; 6) Alarm address notifyUrl.

[0040] In this application, the instruction execution result table includes: 1) Primary key ID; 2) Use case execution batch number batchNo; 3) Step name setpName; 4) Step execution order number stepNo; 5) Executor type commandType, including HTTP, MYSQL, and DUBBO; 6) Execution parameter executeData, stored as a json string. For example, for http, it is the final complete request parameter; 7) Execution result parameter executeResultData, stored as a json string. For example, for msyql, it is the query result; 8) Execution times executeTime. For example, when querying an interface, it will record how many times of loop query; 9) Assertion information assertMsg, mainly recording the specific information of assertion failure; 10) Recording synchronous assertion information assertRetry; 11) Recording information of synchronous assertion assertSuccess; 12) Recording asynchronous assertion information asyncAssert; 13) Notification callback information noticeListen. When receiving a callback notification, it will be here, formed by noticeNo and notification type into a character, such as payment20200109465222511008001,sharing20200109465222611008002; 14) Recording asynchronous assertion result executeAsyncAssertRsult, default true without asynchronous assertion; 15) Recording result of synchronous execution assertion executeSyncAssertResult, default true without synchronous assertion; 16) Notification callback listening result noticeListenResult, default true without listening to notification callback; 17) Execution start time executeStartTime; 18) Execution end time executeEndTime; 19) Environment identifier evn; 20) Creation time createTime; 21) Update time updataTime; 22) Creator createBy; 23) Updater updataBy.

[0041] In this application, the test case execution result table includes: 1) Primary key ID; 2) Use case execution batch number bacthNo; 3) Use case name caseName; 4) Group name groupName; 5) Primary key ID stepResIds of the execution result table for each step of the use case, which is composed of the primary key IDs of the execution result tables for each step of the use case, such as 23, 24, 25, 26, 27; 6) Synchronous assertion result executeSyncRes ult, which is true when the synchronous results of all steps are true; 7) Asynchronous assertion result executeAsyncR esult, which is true when the asynchronous results of all steps are true; 8) Listener notification callback result listenNotic eResult, which is true when the asynchronous notification listener results of all steps are true; 9) Notification failure instructions failCommandIds, for the instructions of synchronous assertion and asynchronous assertion listener callback notifications that fail, the execution batch numbers of the instructions will be stored in the data, such as 2020000010001, 2020000010002, 2020000010003; 10) Creation time createTime; 11) Update time updataTime; 12) Creator createBy; 13) Updater updataBy.

[0042] In this application, the test set execution result table includes: 1) Primary key id; 2) Synchronous assertion result executeSyncResult, which is true when the synchronous assertion results of all test cases are true; 3) Asynchronous assertion result executeAsyncResult, which is true when the asynchronous assertion results of all test cases are true; 4) Listener notification callback result listenNoticeResult, which is true when the notification callback listener results of all test cases are true; 5) Test set group name groupName; 6) The number of test cases in the test set CasesCount; 7) The primary key IDs casesResultIds of the execution results of all test cases in the test set, such as 10000, 10001, 10006, 1009; 8) The primary key IDs failCaseSIds of the test cases with failed callback notifications. If there are test cases with failed synchronous assertion and asynchronous assertion listener callbacks, the primary key IDs of the test case execution result table will be stored in the data, separated by commas, such as 10000, 10001, 10006, 1009; 9) Total time consumption timeConsumption of the test set execution (also known as the recorded synchronous execution completion time); 10) Execution start time startTime; 11) Execution end time endTime; 12) Creation time createTime; 13) Update time updataTime; 14) Creator createBy; 15) Updater updataBy.

[0043] In this application, the asynchronous notification callback table includes: 1) Primary key ID; 2) Test case execution order number batchNo; 3) Step execution order number stepNo; 4) Notification order number noticeNo; 5) Notification type notifyType; 6) Notification content noticeData; 7) Notification status noticeStatus, whether the notification callback has been received, 0 means the notification callback has not been received, 1 means the notification callback has been received; 8) Number of notifications noticeTime; 9) Source IP sourceIp; 10) Whether the instruction execution result table has been updated for notification noticeCommandResult, 0 means no notification for update, 1 means notification for update has been made; 11) Creation time createTime; 12) Update time updataTime.

[0044] In this application, the asynchronous assertion execution result table includes: 1) primary key ID; 2) execution order number stepNo; 3) original data information datasourceInfo, and the sql query data source is switched according to this field; 4) sql information, the specific sql execution statement sqlInfo; 5) assertion information assertRetry, using the general assertion logic, continue to execute after hitting, and store it as a json string; 6) assertion information assertSuccess, using the general assertion logic, give the assertion result after hitting, and store it as a json string; 7) maximum number of queries maxQueryTimes; 8) number of retried queries retryTimes; 9) query interval time delayTime; 10) next query time nextQueryTime; 11) maximum executable time enableRetryTime; 12) assertion result assertResult, the default 0 indicates no clear result, 1 indicates assertion success, 2 indicates assertion failure, 3 indicates assertion timeout; 13) whether to notify the execution result of the update instruction noticeCommandResult, 0 indicates not notified, 1 indicates notified; 14) creation time createTime; 15) update time updataTime.

[0045] In this application, the timing task execution table includes: 1) An asynchronous assertion table scanning timing task, which scans data with a maximum executable time less than the current time and assertResult = 0 or noticeCommandResult = 0. For data with assertResult = 0, table look-up assertions are performed. For data with noticeCommandResult = 0 and assertResult!= 0, the instruction execution result table is notified for update. The scanning time range is configurable; 2) A notification callback table scanning timing task, which scans data with noticeStatus = 0 and noticeCommandResult = 0 that have received asynchronous notifications but have not updated the instruction execution result table, and performs the operation of updating the instruction execution result table. The scanning time range is configurable; 3) An asynchronous assertion scanning task for the test case execution result table, which scans data with executeAsyncAssertRsult = 0, queries the asynchronous assertion results of each instruction execution result in the test case. If all are successful, the asynchronous assertion result is updated to successful. If there are failures, the asynchronous assertion result is updated to failed, and the instruction execution order numbers of the failed ones are stored in failCommandIds; 4) A notification callback listening scanning task for the test case execution result table, which scans data with listenNoticeResult = 0, queries the notification callback listening results of each instruction execution result in the test case. If all are successful, the notification callback listening result is updated to successful. If there are failures, the notification callback listening result is updated to failed, and the instruction execution order numbers of the failed ones are stored in failCommandIds; 5) An asynchronous assertion scanning task for the test set execution result table, which scans data with executeAsyncAssertRsult = 0, queries the asynchronous assertion results of each test case result in the test case. If all are successful, the asynchronous assertion result is updated to successful. If there are failures, the asynchronous assertion result is updated to failed, and the case execution batch numbers of the failed ones are stored in failCaseSIds; 6) A notification callback listening scanning task for the test case execution result table, which scans data with listenNoticeResult = 0, queries the notification callback listening results of each test case result in the test case. If all are successful, the notification callback listening result is updated to successful. If there are failures, the notification callback listening result is updated to failed, and the case execution batch numbers of the failed ones are stored in failCaseSIds.

[0046] Preferably, the transaction test cases are processed asynchronously, including notification callback listening processing, data asynchronous assertion processing, and execution result storage processing.

[0047] Preferably, the notification callback listening processing specifically includes:

[0048] Create an asynchronous notification object and store it in the asynchronous notification table;

[0049] If after receiving the notification callback information, update the object in the asynchronous notification table according to the notification callback information.

[0050] Preferably, the data asynchronous assertion processing specifically includes:

[0051] When an asynchronous assertion is configured in the currently executing instruction, store the asynchronous assertion result of the currently executing instruction in the asynchronous assertion table.

[0052] Preferably, the execution result storage processing specifically includes:

[0053] After all the execution instructions in the execution instruction set are executed, update the transaction test case execution result table.

[0054] In a second aspect, the present invention provides a full-link transaction automated testing system, which specifically includes the following modules:

[0055] A test set information acquisition module, used to acquire test set information; wherein, the test set includes one or more transaction test case information;

[0056] A test case information acquisition module, used to acquire one transaction test case information, create a transaction test case according to the transaction test case information, and store the transaction test case execution result in the transaction test case information; wherein, the transaction test case execution result represents the expected result formed by executing the transaction test case;

[0057] A test module, which executes the transaction test case to form the actual result of executing the transaction test case;

[0058] A test case execution result processing module, which compares the transaction test case execution result with the actual result. If they are consistent, the test passes and outputs the transaction test case execution result table. Otherwise, the test fails and outputs the transaction test case execution result table;

[0059] A test set execution result processing module, used to repeatedly execute the transaction test case information acquisition module, the test module, and the test case execution result processing module until after all the transaction test case execution result tables are output, and then output the test set execution result table.

[0060] Preferably, the test case information acquisition module specifically includes the following sub-modules:

[0061] A first sub-module for acquiring test case information, used to set an execution instruction set; wherein, the execution instruction set includes one or more execution instructions; the execution instructions include input parameter processing instructions, output parameter processing instructions, assertion processing instructions, and notification callback monitoring instructions;

[0062] The second sub-module for obtaining test case information is used to combine one or more execution instructions to form transaction test case information.

[0063] Preferably, in the test case information acquisition module, the transaction test case information is saved through a persistence layer database. More preferably, the persistence layer database is MySQL.

[0064] Preferably, in the test module, one or more threads in the thread pool are used to execute the transaction test case, and the thread pool is a dynamically created thread pool or a default thread pool.

[0065] Preferably, the test module specifically includes the following sub-modules:

[0066] The first test sub-module is used to configure the input parameters, output parameters and execution parameters and select an executor according to the transaction test case; wherein, the input parameters include random parameters, encrypted parameters and encoding parameters; the output parameters include signature verification parameters, decryption parameters, decoding parameters; the execution parameters include the waiting time at the start of execution, the waiting time at the end of execution, the number of execution loops, and the interval of execution loops;

[0067] The second test sub-module is used to obtain an execution instruction from the execution instruction set in the transaction test case, parse the execution instruction to form a parsed execution instruction, and convert the data format or data type of the parsed execution instruction to form a data format or data type recognizable by the executor;

[0068] The third test sub-module is used to execute an operation according to the parsed and format-converted execution instruction by the executor to form an execution result of the current execution instruction;

[0069] The fourth test sub-module is used to perform synchronous assertion processing and output parameter processing on the execution result. If the execution result is consistent with the expected result, the fifth test sub-module is executed; otherwise, the execution of the transaction test case is ended; wherein, the synchronous assertion processing is used to perform assertion processing on the execution result of the execution instruction;

[0070] The fifth test sub-module is used to parse and convert the execution result obtained through the executor after the operation of the executor is completed to form the actual execution result of the execution instruction;

[0071] The sixth test sub-module is used to determine whether the execution instructions in the execution instruction set have been executed. If the execution has not ended, the first test sub-module, the second test sub-module, the third test sub-module, the fourth test sub-module and the fifth test sub-module are repeatedly executed until all the execution instructions in the execution instruction set are executed to form the actual result of the test case.

[0072] Preferably, in the second sub-module test, the actuators include MySQL, HTTP, and Dubbo.

[0073] Preferably, in the fourth sub-module test, while performing synchronous assertion processing and output parameter processing, when the instruction set includes instructions that need to be executed asynchronously, asynchronous processing is performed.

[0074] Preferably, the asynchronous processing of the transaction test case includes notification callback monitoring processing, data asynchronous assertion processing, and execution result storage processing.

[0075] Preferably, the notification callback monitoring processing specifically includes:

[0076] Create an asynchronous notification object and store it in the asynchronous notification table;

[0077] If notification callback information is received, update the object in the asynchronous notification table according to the notification callback information.

[0078] Preferably, the data asynchronous assertion processing specifically includes:

[0079] When asynchronous assertions are configured in the currently executing instruction, store the asynchronous assertion result of the currently executing instruction in the asynchronous assertion table.

[0080] Preferably, the execution result storage processing specifically includes:

[0081] When all the execution instructions in the execution instruction set are executed, update the transaction test case execution result table.

[0082] In a third aspect, the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements a full-link transaction automated test method according to any one of the first aspects of the present application.

[0083] In a fourth aspect, the present invention also provides an electronic device, the electronic device includes: a memory storing a computer program: a processor communicatively connected to the memory, and when the computer program is called, it executes a full-link transaction automated test method according to any one of the first aspects of the present application.

[0084] Compared with the prior art, the present invention has the following obvious outstanding substantial features and remarkable advantages:

[0085] The present invention provides a full-link transaction automated testing method and system, specifically including: Step S1, obtaining test set information; Step S2, obtaining a transaction test case information, creating a transaction test case according to the transaction test case information, and storing the execution result of the transaction test case into the transaction test case information; Step S3, executing the transaction test case to form an actual result of executing the transaction test case; Step S4, comparing the execution result of the transaction test case with the actual result. If they are consistent, the test passes and a transaction test case execution result table is output. Otherwise, the test fails and a transaction test case execution result table is output; Step S5, repeatedly executing Steps S2 - S4 until after all transaction test case execution result tables are output, outputting a test set execution result table; realizing the automated testing of the full-link process of transactions, and complementing the asynchronous assertion processing after the interface synchronization assertion, improving the testing efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0087] Figure 1 It is a flowchart of a full-link transaction automated testing method according to a preferred embodiment of the present invention.

[0088] Figure 2 It is a schematic structural diagram of a full-link transaction automated testing system according to a preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0089] In order to make the above and other features and advantages of the present invention clearer, the present invention will be further described below with reference to the drawings. It should be understood that the specific embodiments given herein are for the purpose of explaining to those skilled in the art and are merely exemplary, not restrictive.

[0090] In the description of the present invention, it should be understood that the orientation or positional relationship indicated by the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation to the present invention.

[0091] In addition, the terms "first" and "second" are only used for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise specifically and clearly defined.

[0092] Example 1:

[0093] As Figure 1 shown, a full-link transaction automation testing method described in this embodiment specifically includes the following steps:

[0094] Step S1: Obtain test set information; wherein, the test set includes one or more transaction test case information.

[0095] Step S2: Obtain one transaction test case information, create a transaction test case according to the transaction test case information, and store the execution result of the transaction test case into the transaction test case information; wherein, the execution result of the transaction test case represents the expected result formed by executing the transaction test case.

[0096] Wherein, the formation method of the transaction test case information specifically includes the following steps:

[0097] Step S201: Set an execution instruction set; wherein, the execution instruction set includes one or more execution instructions; the execution instructions include input parameter processing instructions, output parameter processing instructions, assertion processing instructions, and notification callback monitoring instructions.

[0098] Step S202: Combine one or more execution instructions to form transaction test case information.

[0099] Optionally, the transaction test case information is saved through a persistence layer database. In this embodiment, the persistence layer database is MySQL.

[0100] Step S3: Execute the transaction test case to form the actual result of executing the transaction test case.

[0101] One or more threads in the thread pool are used to execute the transaction test case, and the thread pool is a dynamically created thread pool or a default thread pool.

[0102] Optionally, in step S3, executing the transaction test case to form the actual result of executing the transaction test case specifically includes the following steps:

[0103] Step S301: Configure the input parameters, output parameters, and execution parameters according to the transaction test case and select an executor; wherein, the input parameters include random parameters, encryption parameters, and encoding parameters; the output parameters include signature verification parameters, decryption parameters, and decoding parameters; the execution parameters include the waiting time at the start of execution, the waiting time at the end of execution, the number of execution loops, and the interval between execution loops.

[0104] Step S302: Obtain an execution instruction from the execution instruction set in the transaction test case, parse the execution instruction to form a parsed execution instruction, and convert the data format or data type of the parsed execution instruction to the data format or data type recognizable by the executor; wherein, the executor includes MySQL, HTTP, and Dubbo.

[0105] Step S303: According to the parsed and format-converted execution instruction, the executor performs an operation to form the execution result of the current execution instruction.

[0106] Step S304: Perform synchronous assertion processing and output parameter processing on the execution result. If the execution result is consistent with the expected result, execute step S305; otherwise, end the execution of the transaction test case; wherein, the synchronous assertion processing is used to assert the execution result of the execution instruction.

[0107] Wherein, while performing synchronous assertion processing and output parameter processing, when the instruction set includes instructions that need to be executed asynchronously, asynchronous processing is performed.

[0108] Wherein, the asynchronous processing of the transaction test case includes notification callback listening processing, data asynchronous assertion processing, and execution result storage processing.

[0109] The notification callback listening processing includes:

[0110] Create an asynchronous notification object and store it in the asynchronous notification table;

[0111] If notification callback information is received, update the object in the asynchronous notification table according to the notification callback information.

[0112] The asynchronous assertion processing of the data includes:

[0113] When an asynchronous assertion is configured in the currently executed instruction, store the asynchronous assertion result of the currently executed instruction in the asynchronous assertion table.

[0114] The execution result storage processing includes:

[0115] After all the execution instructions in the execution instruction set are executed, update the transaction test case execution result table.

[0116] Step S305: After the operation of the executor is completed, parse and format-convert the execution result obtained by the executor to form the actual execution result of the execution instruction;

[0117] Step S306: Determine whether the execution instructions in the execution instruction set are executed. If not, repeat steps S302 - S305 until all the execution instructions in the execution instruction set are executed to form the actual result of the test case.

[0118] Step S4: Compare the transaction test case execution result with the actual result. If they are consistent, the test passes and output the transaction test case execution result table. Otherwise, the test fails and output the transaction test case execution result table;

[0119] Step S5: Repeat steps S2 - S4 until all the transaction test case execution result tables are output, and then output the test set execution result table.

[0120] Example 2:

[0121] As Figure 2 shown, a full-link transaction automation test system described in this embodiment specifically includes the following modules:

[0122] A test set information acquisition module, which is used to acquire test set information; wherein, the test set includes information of one or more transaction test cases.

[0123] A test case information acquisition module, which is used to acquire information of a transaction test case, create a transaction test case according to the transaction test case information, and store the transaction test case execution result in the transaction test case information; wherein, the transaction test case execution result represents the expected result formed by executing the transaction test case.

[0124] Among them, the test case information acquisition module specifically includes the following sub-modules:

[0125] The first sub-module for obtaining test case information is used to set an execution instruction set; wherein, the execution instruction set includes one or more execution instructions; the execution instructions include input parameter processing instructions, output parameter processing instructions, assertion processing instructions, and notification callback monitoring instructions.

[0126] The second sub-module for obtaining test case information is used to combine one or more execution instructions to form transaction test case information.

[0127] Wherein, the transaction test case information is saved through a persistence layer database, and more preferably, the persistence layer database is MySQL.

[0128] The test module executes the transaction test case to form the actual result of executing the transaction test case.

[0129] Wherein, one or more threads in the thread pool are used to execute the transaction test case, and the thread pool is a dynamically created thread pool or a default thread pool.

[0130] Wherein, the test module specifically includes the following sub-modules:

[0131] The first test sub-module is used to configure input parameters, output parameters, and execution parameters and select an executor according to the transaction test case; wherein, the input parameters include random parameters, encrypted parameters, and encoded parameters; the output parameters include signature verification parameters, decryption parameters, and decoding parameters; the execution parameters include the waiting time at the start of execution, the waiting time at the end of execution, the number of execution loops, and the interval between execution loops.

[0132] The second test sub-module is used to obtain an execution instruction from the execution instruction set in the transaction test case, parse the execution instruction to form a parsed execution instruction, and convert the data format or data type of the parsed execution instruction to form the data format or data type recognizable by the executor; wherein, the executors include MySQL, HTTP, and Dubbo.

[0133] The third test sub-module is used to perform an operation by the executor according to the parsed and format-converted execution instruction to form the execution result of the current execution instruction.

[0134] The fourth test sub-module is used to perform synchronous assertion processing and output parameter processing on the execution result. If the execution result is consistent with the expected result, the fifth test sub-module is executed; otherwise, the execution of the transaction test case is ended; wherein, the synchronous assertion processing is used to perform assertion processing on the execution result of the execution instruction.

[0135] Preferably, in the fourth sub-module of the test, while performing synchronous assertion processing and output parameter processing, when the instruction set includes instructions that need to be executed asynchronously, asynchronous processing is performed.

[0136] Preferably, the asynchronous processing of the transaction test case includes notification callback listening processing, data asynchronous assertion processing, and execution result storage processing.

[0137] Among them, the notification callback listening processing includes:

[0138] Create an asynchronous notification object and store it in the asynchronous notification table;

[0139] If notification callback information is received, update the object in the asynchronous notification table according to the notification callback information.

[0140] Among them, the data asynchronous assertion processing includes:

[0141] When the current execution instruction is configured with an asynchronous assertion, store the asynchronous assertion result of the current execution instruction in the asynchronous assertion table.

[0142] Among them, the execution result storage processing includes:

[0143] After all the execution instructions in the execution instruction set are executed, update the transaction test case execution result table.

[0144] The fifth sub-module of the test is used to parse and format-convert the execution result obtained through the executor after the operation of the executor is completed to form the actual execution result of the execution instruction.

[0145] The sixth sub-module of the test is used to determine whether the execution instructions in the execution instruction set are executed. If the execution is not completed, repeat the execution of the first sub-module of the test, the second sub-module of the test, the third sub-module of the test, the fourth sub-module of the test, and the fifth sub-module of the test until all the execution instructions in the execution instruction set are executed to form the actual result of the test case.

[0146] The test case execution result processing module compares the transaction test case execution result with the actual result. If they are consistent, the test passes and the transaction test case execution result table is output. Otherwise, the test fails and the transaction test case execution result table is output.

[0147] The test set execution result processing module is used to repeatedly execute the transaction test case information acquisition module, the test module, and the test case execution result processing module until all the transaction test case execution result tables are output, and then output the test set execution result table.

[0148] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A full-link transaction automation testing method, characterized in that: The steps include: Step S1, obtaining test set information; wherein the test set includes one or more transaction test case information; Step S2: obtaining a transaction test case information, creating a transaction test case according to the transaction test case information, and storing the transaction test case execution result in the transaction test case information; wherein the transaction test case execution result represents the expected result formed by executing the transaction test case; Step S3, executing the transaction test case to form an actual result of executing the transaction test case; Step S4: Compare the transaction test case execution result with the actual result. If they are consistent, the test passes and a transaction test case execution result table is output. Otherwise, the test fails and a transaction test case execution result table is output. Step S5: Repeat steps S2-S4 until all transaction test case execution result tables are output, and then output the test set execution result table.

2. A full-link transaction automation testing method according to claim 1, characterized in that: In step S2, the transaction test case information is formed in the following steps: Step S201, setting an execution instruction set; wherein the execution instruction set includes one or more execution instructions; the execution instructions include input parameter processing instructions, output parameter processing instructions, assertion processing instructions and notification callback listening instructions; Step S202: combine one or more execution instructions to form transaction test case information.

3. A full-link transaction automation testing method according to claim 1, characterized in that: In step S2, the transaction test case information is saved via a persistence layer database. More preferably, the persistence layer database is MySQL.

4. A full-link transaction automation testing method according to claim 1, characterized in that: In step S3, one or more threads in a thread pool are used to execute the transaction test case, and the thread pool is a dynamically created thread pool or a default thread pool.

5. A full-link transaction automation testing method according to claim 1, characterized in that: In step S3, the transaction test case is executed to form an actual result of executing the transaction test case, which specifically includes the following steps: Step S301: According to the transaction test case, configure the input parameters, output parameters and execution parameters and select the executor; wherein the input parameters include random parameters, encryption parameters and encoding parameters; the output parameters include signature verification parameters, decryption parameters and decoding parameters; the execution parameters include execution start waiting time, execution end waiting time, execution cycle number and execution cycle interval; Step S302: obtaining an execution instruction of the execution instruction set in the transaction test case, parsing the execution instruction to form a parsed execution instruction, and converting the data format or data type of the parsed execution instruction to form a data format or data type recognizable by the executor; Step S303: the executor performs an operation according to the parsed and format-converted execution instruction to form an execution result of the current execution instruction; Step S304, performing synchronous assertion processing and parameter output processing on the execution result, if the execution result is consistent with the expected result, executing step S305, otherwise, the execution of the transaction test case is terminated; wherein the synchronous assertion processing is used to perform assertion processing on the execution result of the execution instruction; Step S305: After the execution of the executor operation is completed, the execution result obtained by the executor is parsed and formatted to form the actual execution result of the execution instruction; Step S306, determine whether the execution instructions in the execution instruction set have been completed. If the execution has not been completed, repeat steps S302-S305 until all the execution instructions in the execution instruction set have been completed, thereby forming the actual result of the test case.

6. A full-link transaction automation testing method according to claim 5, characterized in that: In step S302, the executor includes MySQL, HTTP and Dubbo.

7. A full-link transaction automation testing method according to claim 5, characterized in that: In step S304, while performing synchronous assertion processing and parameter output processing, when the instruction set includes instructions that need to be executed asynchronously, asynchronous processing is performed.

8. A full-link transaction automation testing method according to claim 1, characterized in that: The transaction test case is processed asynchronously, including notification callback monitoring processing, data asynchronous assertion processing and execution result storage processing.

9. A full-link transaction automation testing method according to claim 8, characterized in that: The notification callback monitoring process specifically includes: Create an asynchronous notification object and store it in the asynchronous notification table; If notification callback information is received, the object in the asynchronous notification table is updated according to the notification callback information; The data asynchronous assertion processing specifically includes: When an asynchronous assertion is configured in the currently executed instruction, the asynchronous assertion result of the currently executed instruction is stored in the asynchronous assertion table; The execution result storage process specifically includes: When all execution instructions in the execution instruction set are executed, the transaction test case execution result table is updated.

10. A full-link transaction automation testing system, characterized in that: Includes the following modules: A test set information acquisition module, used to acquire test set information; wherein the test set includes one or more transaction test case information; A test case information acquisition module, used to acquire a transaction test case information, create a transaction test case according to the transaction test case information, and store the transaction test case execution result in the transaction test case information; wherein the transaction test case execution result represents the expected result formed by executing the transaction test case; A test module executes the transaction test case to form an actual result of executing the transaction test case; The test case execution result processing module compares the transaction test case execution result with the actual result. If they are consistent, the test passes and a transaction test case execution result table is output. Otherwise, the test fails and a transaction test case execution result table is output. The test set execution result processing module is used to repeatedly execute the transaction test case information acquisition module, the test module and the test case execution result processing module until all transaction test case execution result tables are output, and then output the test set execution result table.

Images