Distributed transaction testing method and device, equipment and storage medium

Abstract

The invention discloses a distributed transaction testing method and device, equipment and a storage medium. The method comprises the following steps: acquiring analysis data of a distributed transaction; generating a chaos test scene corresponding to the distributed transaction based on the state machine model and the analysis data; and constructing test cases corresponding to the chaos test scene according to a preset chaos test tool, and testing each test case to obtain a test result. According to the embodiment of the invention, the chaos test scene corresponding to the distributed transaction is generated through the state machine model and the analysis data, the test cases corresponding to the chaos test scene are constructed according to the preset chaos test tool, and the test cases are tested to obtain the test result, so that the chaos test scene can be automatically generated; the problems of inaccurate generation, vulnerability and low efficiency of the chaos test scene are solved, and a more comprehensive chaos test scene is obtained, so that each test case is tested more comprehensively.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a distributed transaction testing method, device, equipment and storage medium. Background Art

[0002] The emergence of distributed systems has enabled various applications to better adapt to the needs of modern computing and data processing. However, the practice and management of distributed systems also bring some challenges, such as the urgent need to solve the testing problem of distributed transactions. For example, distributed testing scenarios are complex, fault simulation is difficult, and there is a high learning threshold. Although traditional chaos testing can simulate various unstable factors and faults encountered by the system to a certain extent, the high threshold, inconsistent standards, and long time consumption of chaos testing in distributed scenarios have not yet been solved.

[0003] In the prior art, distributed transaction test scenarios are usually generated based on formal descriptions, and then corresponding test cases are obtained for testing. Although this method overcomes the characteristic of incomplete input space division of empirical methods, the degree of automated test case generation is not high, and only the preconditions are rewritten, with a high probability of omissions, resulting in incomplete testing. Summary of the invention

[0004] In view of this, the present invention provides a distributed transaction testing method, device, equipment and storage medium, which can automatically execute the generation of chaotic test scenarios, solve the problems of inaccurate, loophole and low efficiency in the generation of chaotic test scenarios, obtain a more comprehensive chaotic test scenario, and thus test each test case more comprehensively.

[0005] According to one aspect of the present invention, an embodiment of the present invention provides a distributed transaction testing method, the method comprising: obtaining analysis data of a distributed transaction;

[0006] Generate a chaos test scenario corresponding to the distributed transaction based on the state machine model and the analysis data;

[0007] Construct test cases corresponding to the chaos test scenarios according to the preset chaos test tool, and test each of the test cases to obtain test results

[0008] According to another aspect of the present invention, an embodiment of the present invention further provides a distributed transaction testing device, the device comprising:

[0009] Data acquisition module, used to obtain analysis data of distributed transactions;

[0010] A scenario generation module, used to generate a chaos test scenario corresponding to the distributed transaction based on a state machine model and the analysis data;

[0011] The test module is used to construct test cases corresponding to the chaos test scenarios according to a preset chaos test tool, and to test each of the test cases to obtain test results.

[0012] According to another aspect of the present invention, an embodiment of the present invention further provides an electronic device, the electronic device comprising:

[0013] at least one processor; and

[0014] a memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed transaction testing method described in any embodiment of the present invention.

[0016] According to another aspect of the present invention, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed transaction testing method described in any embodiment of the present invention when executed.

[0017] According to another aspect of the present invention, an embodiment of the present invention further provides a computer program product, characterized in that the computer program product includes a computer program, and when the computer program is executed by a processor, it implements the distributed transaction testing method described in any embodiment of the present invention.

[0018] The technical effect of the present invention is that a chaos test scenario corresponding to a distributed transaction is generated through a state machine model and analysis data, a test case corresponding to the chaos test scenario is constructed according to a preset chaos test tool, and each test case is tested to obtain a test result. The generation of chaos test scenarios can be automatically executed, and the problems of inaccurate, buggy and inefficient generation of chaos test scenarios can be solved, thereby achieving the extensiveness of test cases and testing each test case more comprehensively.

[0019] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 A flow chart of a distributed transaction testing method provided by one embodiment of the present invention;

[0022] Figure 2 A flowchart of another distributed transaction testing method provided by an embodiment of the present invention;

[0023] Figure 3 A schematic diagram of an architecture for analyzing data of a distributed transaction provided by an embodiment of the present invention;

[0024] Figure 4 A schematic diagram of all possible chaos test scenarios of a distributed transaction with three branch transactions provided by an embodiment of the present invention;

[0025] Figure 5 A schematic diagram of a chaotic test scenario corresponding to an automatically generated distributed transaction with multiple branch transactions provided by an embodiment of the present invention;

[0026] Figure 6 A schematic diagram of another distributed transaction testing method provided by an embodiment of the present invention;

[0027] Figure 7 A structural block diagram of a distributed transaction testing device provided by an embodiment of the present invention;

[0028] Figure 8 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] In one embodiment, Figure 1 A flowchart of a distributed transaction testing method provided for an embodiment of the present invention. This embodiment can be applied to the generation of chaotic test scenarios and testing of distributed transactions. The method can be executed by a distributed transaction testing device. The distributed transaction testing device can be implemented in the form of hardware and / or software. The distributed transaction testing device can be configured in an electronic device.

[0032] like Figure 1 As shown, the distributed transaction testing method in this embodiment includes the following specific steps:

[0033] S110. Obtain analysis data of distributed transactions.

[0034] The analysis data includes at least: distributed transaction information and verification data information corresponding to the distributed transaction; the distributed transaction information includes at least: the number of branch transactions included in the distributed transaction; the branch transaction information corresponding to each branch transaction; the verification data information includes at least the log number and transaction date.

[0035] In this embodiment, the distributed transaction includes at least two branch transactions. Since each branch transaction may be distributed in different hosts (nodes), its records can be stored in different log databases. It can be understood that for branch transactions in the same node, the data generated by the branch transaction can be stored in the same log database. For example, log database 1 is used to store the logs corresponding to branch transactions 1 and 2, and log database 2 can store the logs corresponding to branch transactions 3, 4 and 5. Of course, in order to better extract data from each log database, the storage area of ​​the data can be divided for each log database, and the corresponding data can be stored in the specified area according to the needs for subsequent extraction.

[0036] In this embodiment, the required analysis data of distributed transactions can be extracted from the log databases of different hosts, which can include capturing the core data generated by distributed functions in multiple log databases, such as log numbers, accounting dates, etc., and extracting branch transaction information corresponding to different branch transactions; the branch transaction information may include but is not limited to branch name, running status, transaction function, compensation transaction, corresponding compensation operations of each compensation transaction, and compensation function corresponding to the compensation operation; wherein the running status includes: timeout, success, and failure.

[0037] S120. Generate a chaos test scenario corresponding to the distributed transaction based on the state machine model and analysis data.

[0038] The state machine model in this embodiment is a model used to describe the conversion relationship between the behavior and state of an object, system or program. The state machine consists of a set of states, a set of events and a set of transition rules, which are used to represent the various states that an object or system can be in and how to transition from one state to another when receiving certain events. Among them, states can include success, failure and timeout; events can include branch transactions and compensation transactions, and transition rules can include that if branch transaction n is executed successfully, branch transaction n+1 is executed; if branch transaction n fails to execute, the compensation operations of branch transactions n-1 to branch transactions 1 are executed sequentially; if branch transaction n times out, the compensation operations of branch transactions n to branch transactions 1 are executed sequentially; if compensation transaction n is executed successfully, the compensation operations of compensation transactions n-1 to compensation transactions 1 are executed sequentially.

[0039] In this embodiment, the number of branch transactions corresponding to the distributed transaction, as well as the branch name, running state, transaction function, compensation transaction, corresponding compensation operation of each compensation transaction, and compensation function corresponding to the compensation operation are determined from the scenario analysis data; one is selected from each branch transaction and each compensation transaction as the current execution operation, and it is determined whether the event corresponding to the current execution operation is a branch transaction or a transaction compensation; if the event corresponding to the current execution operation is a branch transaction, the branch transaction is used as the current branch transaction, and the running state of the current branch transaction is determined, and the first chaos test scenario is determined based on the running state; if the event corresponding to the current execution operation is transaction compensation, the transaction compensation is used as the current transaction compensation, and it is determined whether the current transaction compensation is a head compensation; if it is not a head compensation, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation, and the step of whether the current transaction compensation is a head compensation is returned to the execution until the current transaction compensation is a head compensation; if it is a head compensation, it is directly terminated; the first chaos test scenario under the event being a branch transaction and various execution situations corresponding to the event being transaction compensation are used as the chaos test scenarios corresponding to the distributed transaction.

[0040] S130: construct test cases corresponding to the chaos test scenarios according to the preset chaos test tool, and test each test case to obtain test results.

[0041] Among them, the preset chaos testing tool can be a chaosblade tool, through which test cases corresponding to chaos testing scenarios can be constructed.

[0042] In this embodiment, a chaos test tool is preset to construct a test case corresponding to a chaos test scenario. Specifically, the chaos test scenario can be converted into a text description in the form of a chaosblade statement through the chaosblade tool to reduce the repetitiveness of the test work and improve the team efficiency. The text description in the form of each chaosblade statement is used as a test case. It can be understood that after all possible chaos test scenarios are generated, chaosblade statements for different chaos test scenarios are generated. Testing each test case can be an automated execution test for executing chaosblade statements. In addition, a component for monitoring and managing the software testing process can also be set to monitor the progress of the test, collect test results, and generate a core test report.

[0043] The technical solution of the embodiment of the present invention generates a chaos test scenario corresponding to a distributed transaction through a state machine model and analysis data, constructs a test case corresponding to the chaos test scenario according to a preset chaos test tool, and tests each test case to obtain a test result. It can automatically execute the generation of chaos test scenarios, solve the problems of inaccurate, buggy and low efficiency in the generation of chaos test scenarios, thereby achieving the extensiveness of test cases and testing each test case more comprehensively.

[0044] In one embodiment, after testing each test case to obtain the test results, it also includes: performing statistical analysis on the test results to generate target test results of corresponding indicators, and generating a test result analysis report; and evaluating distributed transactions based on the test result analysis report.

[0045] In this embodiment, after obtaining the test results, the test results are statistically analyzed to generate target test results of corresponding indicators, and a test result analysis report is generated. The distributed transaction is evaluated based on the test result analysis report. In addition, the progress of the test can be monitored, the test results can be collected, and a core test report can be generated to capture exceptions when they occur and take appropriate measures to handle them, so as to ensure that the test program can run normally or provide detailed information about the exceptions, and log them for subsequent analysis, troubleshooting, monitoring and performance optimization.

[0046] In one embodiment, Figure 2A flowchart of another distributed transaction testing method provided for an embodiment of the present invention. Based on the above embodiments, this embodiment further refines the chaotic test scenarios corresponding to distributed transactions generated based on state machine models and analysis data, and the test cases corresponding to the chaotic test scenarios constructed according to preset chaos testing tools.

[0047] like Figure 2 As shown, the distributed transaction testing method in this embodiment may specifically include the following steps:

[0048] S210: extract branch transaction information, log number and accounting date corresponding to each branch transaction from a preset log database.

[0049] The preset log database is used to store log data corresponding to one or more branch transactions. There may be multiple preset log databases, one for each host, or at least two for one host, which is not limited in this embodiment.

[0050] In this embodiment, the branch transaction information, log number and accounting date corresponding to each branch transaction can be extracted from the preset log database according to the extracted keywords, the branch transaction number and other information. The method can be screening or other methods in the prior art, and this embodiment does not limit this.

[0051] For example, in order to better understand the acquisition of branch transaction information, log number and accounting date, the present embodiment takes the preset log database including log database 1 and log database 2 as an example for explanation. Figure 3 A schematic diagram of an architecture for analyzing data of a distributed transaction provided by an embodiment of the present invention is shown as follows: Figure 3 As shown in the figure, distributed transactions can be abstractly divided into three branch transactions. Since branch transactions may be distributed in different hosts (nodes), their records are stored in different log databases. Scenario analysis data and verification data mainly extract the required information from the log databases of different hosts. Specifically, verification data mainly captures the core data generated by distributed functions in multiple log databases, such as log number, accounting date, etc.; while scenario analysis data mainly extracts information from different branch transactions. For example, the form of any branch transaction can be abstracted as: TransName: "XX card transfer"; Timeout: true; function: XXX; compensate: "compensateXXX", which means that the name of the branch transaction is XX card transfer, and the branch business may time out during operation. Its corresponding transaction function is XXX, and the function corresponding to its corresponding compensation operation is compensateXXX.

[0052] S220. Determine from the scenario analysis data the number of branch transactions corresponding to the distributed transaction, as well as the branch name, running status, transaction function, compensation transaction corresponding to each branch transaction, the corresponding compensation operation corresponding to each compensation transaction, and the compensation function corresponding to the compensation operation.

[0053] In this embodiment, the number of branch transactions corresponding to the distributed transaction, as well as the branch name, running status, transaction function, compensation transaction corresponding to each branch transaction, the corresponding compensation operation corresponding to each compensation transaction, and the compensation function corresponding to the compensation operation are determined from the scenario analysis data.

[0054] S230: Select one from each branch transaction and each compensation transaction as the current execution operation, and determine whether the event corresponding to the current execution operation is a branch transaction or a transaction compensation.

[0055] In this embodiment, one of the branch transactions and the compensating transaction is selected as the current execution operation, and it is determined whether the event corresponding to the current execution operation is a branch transaction or a transaction compensation. If the current execution operation is a branch transaction, if the branch transaction succeeds, it is determined whether the current operation is the last transaction (tail transaction). If it is, it ends, otherwise, the next branch transaction is pulled; if the branch transaction fails, it is determined whether the current operation is the first transaction (head transaction). If it is, it ends, otherwise, the previous branch transaction is pulled; if the branch transaction times out, the transaction compensation of the current transaction is pulled up; if the current execution operation is transaction compensation, if the transaction compensation succeeds, it is determined whether the current operation is the first compensating transaction (head compensation). If it is, it ends, if otherwise, the previous transaction compensation is pulled, and if it fails, it ends directly.

[0056] S240: If the event corresponding to the currently executed operation is a branch transaction, the branch transaction is used as the current branch transaction, and the running state of the current branch transaction is determined, and the first chaos test scenario is determined based on the running state.

[0057] In this embodiment, if the event corresponding to the current execution operation is a branch transaction, the branch transaction is taken as the current branch transaction, and the running state of the current branch transaction is determined, and the first chaos test scenario is determined based on the running state. Specifically, the first chaos test scenario is determined based on the running state, including three cases: the first case, when the running state is execution timeout, the current branch transaction is taken as the n transaction, and the n transaction compensation operation corresponding to the n transaction is pulled up, and when the execution state of the n transaction compensation operation is successful execution, it is determined whether the n transaction compensation operation is head compensation, if not head compensation, the compensation operation of the n-1 transaction is pulled up, and when the execution state of the n-1 transaction compensation operation is successful execution, the compensation operation of the n-1 transaction is taken as the compensation operation of the n transaction, and the step of whether the compensation operation of the n transaction is head compensation is returned until the compensation operation of the n transaction is head compensation; when the execution state of the current transaction compensation is execution failure, it is directly ended; wherein, the head compensation is the compensation operation of transaction 1. The second method: when the running status is execution failure, the current branch transaction is regarded as transaction n, and it is determined whether transaction n is the head transaction. If transaction n is the head transaction, it is terminated directly; if transaction n is not the head transaction, the n-1 transaction compensation operation corresponding to transaction n-1 is started, and when the execution status of the n-1 transaction compensation operation is execution success, it is determined whether the n-1 transaction compensation operation is head compensation. If the n-1 transaction compensation operation is not head compensation, the compensation operation of transaction n-2 corresponding to the n-1 transaction compensation operation is started, and when the execution status of the n-2 transaction compensation operation is execution success, the compensation operation of transaction n-2 is used as the compensation operation of transaction n-1, and the process returns to the step of determining whether the n-1 transaction compensation operation is head compensation, until the compensation operation of transaction n-1 is head compensation. The third method: when the running status is successful execution, the current branch transaction is regarded as the n transaction, and whether the n transaction is the tail transaction is determined. If the n transaction is the tail transaction, it is terminated directly; if the n transaction is not the tail transaction, the n+1 transaction corresponding to the n transaction is pulled up, and the n+1 transaction is regarded as the n transaction, and the step of determining the running status of the current branch transaction is returned until the n transaction is the tail transaction.

[0058] In this embodiment, when the running status is execution timeout, the current transaction compensation corresponding to the current branch transaction is pulled up. When the execution status of the current transaction compensation corresponding to the current branch transaction is execution success, it is determined whether the current transaction compensation corresponding to the current branch transaction is head compensation. If not, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation. The process returns to the step of determining whether the current transaction compensation is head compensation until it is head compensation. When the execution status of the current transaction compensation corresponding to the current branch transaction is execution failure, the process ends directly.

[0059] In this embodiment, when the running status is execution failure, it is determined whether the current branch transaction is a head transaction. If it is a head transaction, it is directly terminated. If it is not a head transaction, the previous transaction compensation corresponding to the previous branch transaction of the current branch transaction is pulled up, and it is determined whether the previous transaction compensation is a head compensation. If not, the previous previous transaction compensation corresponding to the previous transaction compensation is pulled up, and the previous previous transaction compensation is used as the previous transaction compensation, and the step of determining whether the previous transaction compensation is a head compensation is returned until it is a head compensation.

[0060] In this embodiment, when the running status is successful execution, it is determined whether the current branch transaction is a tail transaction. If it is a tail transaction, it is directly terminated. If it is not a tail transaction, the next branch transaction corresponding to the current branch transaction is pulled up, and the next branch transaction is used as the current branch transaction. The process returns to the step of determining the running status of the current branch transaction until it becomes a tail transaction.

[0061] S250: If the event corresponding to the currently executed operation is transaction compensation, the transaction compensation is used as the current transaction compensation, and it is determined whether the current transaction compensation is a header compensation. If it is not a header compensation, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation. Return to the step of determining whether the current transaction compensation is a header compensation until the current transaction compensation is a header compensation. If it is a header compensation, the process ends directly.

[0062] In this embodiment, if the event corresponding to the currently executed operation is transaction compensation, the transaction compensation is used as the current transaction compensation, and it is determined whether the current transaction compensation is head compensation. If it is not head compensation, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation, and the step of determining whether the current transaction compensation is head compensation is returned until the current transaction compensation is head compensation. If it is head compensation, the process ends directly.

[0063] For example, Figure 4 A schematic diagram of all possible chaos test scenarios of a distributed transaction with three branch transactions provided by an embodiment of the present invention. The rules of the execution process of branch transactions and compensation transactions are explained by taking a distributed transaction with three branch transactions 1, 2, and 3 (branch transactions 1, 2, and 3 are executed sequentially). The execution of branch transactions can be summarized into the following three situations:

[0064] 1) If branch transaction n is executed successfully, branch transaction n+1 will be executed.

[0065] 2) If branch transaction n fails to execute, the compensation operations of branch transaction n-1 to branch transaction 1 are executed sequentially.

[0066] 3) If branch transaction n times out, the compensation operations from branch transaction n to branch transaction 1 are executed sequentially.

[0067] However, due to the complexity of the situation, specific analysis is required for specific issues.

[0068] Depend on Figure 4 It can be seen that there are so many test scenarios for a distributed transaction with three branch transactions. In order to better automate the generation of chaotic test scenarios corresponding to distributed transactions with multiple branch transactions, Figure 5 A schematic diagram of a chaotic test scenario corresponding to an automatically generated distributed transaction with multiple branch transactions provided by an embodiment of the present invention, Figure 5 The figure below is an example of automatically generating test scenarios using state machine technology. A state machine model is a model used to describe the behavior and state transition relationship of an object, system, or program. A state machine consists of a set of states, a set of events, and a set of transition rules, which are used to represent the various states that an object or system can be in and how to transition from one state to another when receiving certain events. The execution flow of this method is as follows:

[0069] 1) If the current execution operation is a branch transaction.

[0070] a) If successful, determine whether the current operation is the last transaction (tail transaction). If so, end the operation; otherwise, pull the next branch transaction.

[0071] b) If it fails, determine whether the current operation is the first transaction (head transaction). If it is, end it, otherwise pull the previous branch transaction.

[0072] c) If the timeout occurs, the current transaction is compensated.

[0073] 2) If the current execution operation is transaction compensation.

[0074] a) If successful, determine whether the current operation is the first compensating transaction (head compensation). If so, end the operation; otherwise, pull the previous transaction compensation.

[0075] b) If it fails, it ends immediately.

[0076] S260: The first chaos test scenario when the event is a branch transaction and various execution situations corresponding to the event of transaction compensation are used as chaos test scenarios corresponding to the distributed transaction.

[0077] In this embodiment, various branches under the branch transaction when the event is a branch transaction and various execution situations corresponding to the transaction compensation when the event is a branch transaction are combined to form all possible chaos test scenarios corresponding to the distributed transaction.

[0078] S270. Convert the chaos test scenario into a text description in the form of chaosblade statements according to a preset chaosblade tool, use each text description in the form of chaosblade statements as a test case, and test each test case to obtain a test result.

[0079] In this embodiment, the chaos test scenario is converted into a text description in the form of chaosblade statements according to a preset chaosblade tool, and each text description in the form of chaosblade statements is used as a test case, and each test case is tested to obtain a test result.

[0080] The technical solution of the embodiment of the present invention determines the number of branch transactions corresponding to the distributed transaction and the branch transaction information corresponding to each branch transaction from the scenario analysis data; selects one from each branch transaction and each compensation transaction as the current execution operation, and determines whether the event corresponding to the current execution operation is a branch transaction or a transaction compensation; if the event corresponding to the current execution operation is a branch transaction, the branch transaction is used as the current branch transaction, and the running state of the current branch transaction is determined, and the first chaos test scenario is determined based on the running state; if the event corresponding to the current execution operation is a transaction compensation, the transaction compensation is used as the current transaction compensation, and it is determined whether the current transaction compensation is a head compensation. If it is not a head compensation, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation. compensation, returns to the step of whether the current transaction compensation is head compensation, until the current transaction compensation is head compensation; if it is head compensation, it ends directly; the first chaos test scenario under the event is a branch transaction, and the various execution situations corresponding to the event being transaction compensation are used as chaos test scenarios corresponding to distributed transactions, and the chaos test scenarios are converted into text descriptions in the form of chaosblade statements according to the preset chaosblade tool, and the text descriptions in the form of chaosblade statements are used as test cases, and each test case is tested to obtain test results, and further, the generation of chaos test scenarios can be automatically executed, and the problems of inaccurate, loophole-containing and low-efficiency chaos test scenario generation can be solved, thereby achieving the extensiveness of test cases and testing each test case more comprehensively.

[0081] For example, to better understand the distributed transaction testing method, Figure 6A schematic diagram of another distributed transaction testing method provided for an embodiment of the present invention, a method for automatically generating distributed transaction test scenarios by inputting scenario analysis data and verification data, and a method for automatically generating distributed transaction test scenarios by inputting scenario analysis data and verification data based on state machine technology. The distributed transaction test scenario generation method based on the state machine mainly includes four modules: a data preparation module, a result generation module, a test running module, and a test analysis module. The four modules of the invention cooperate with each other to achieve the main goals of automatically generating test cases, generating Chaosblade statements, and automatically executing, reducing the learning cost of testers, improving work efficiency, and providing a safety net for testing.

[0082] like Figure 6 As shown, the specific steps are as follows:

[0083] a1. Obtain necessary data from the data warehouse, such as distributed transaction information, log number, transaction date, etc.

[0084] a2. Based on distributed transaction information, log number, transaction date and other data, all possible chaos test scenarios can be generated, and chaosblade statements for different chaos test scenarios can be generated. The multiple chaos test scenarios that have been generated can be converted into text form to reduce the duplication of testing work and improve team efficiency.

[0085] a3. Assist the normal operation of the test system, including the automated execution of chaosblade statements, the automated execution of distributed tests, monitoring the progress of tests, collecting test results, and generating core test reports, capturing these exceptions and taking appropriate measures to handle them to ensure that the test program can run normally or provide detailed information about the exceptions for subsequent analysis, troubleshooting, monitoring, and performance optimization.

[0086] a4. Analyze and evaluate the test results in a semi-automatic manner, including: converting the data generated in a3 into meaningful information to support decision making, problem diagnosis and performance analysis, and producing a result analysis report, and finally evaluating and verifying it.

[0087] In one embodiment, Figure 7 This is a structural block diagram of a distributed transaction testing device provided in one embodiment of the present invention. The device is suitable for generating chaotic test scenarios and testing conditions for distributed transactions. The device can be implemented by hardware / software. It can be configured in an electronic device to implement a distributed transaction testing method in an embodiment of the present invention.

[0088] like Figure 7As shown, the device includes: a data acquisition module 710, a scene generation module 720 and a test module 730;

[0089] The data acquisition module 710 is used to acquire the analysis data of the distributed transaction;

[0090] A scenario generation module 720, configured to generate a chaos test scenario corresponding to the distributed transaction based on a state machine model and the analysis data;

[0091] The testing module 730 is used to construct test cases corresponding to the chaos test scenarios according to a preset chaos test tool, and to test each of the test cases to obtain test results.

[0092] In an embodiment of the present invention, a scenario generation module generates a chaos test scenario corresponding to a distributed transaction through a state machine model and analysis data; a test module constructs a test case corresponding to the chaos test scenario according to a preset chaos test tool, and tests each test case to obtain a test result. The generation of chaos test scenarios can be automatically executed, and the problems of inaccurate, buggy and inefficient generation of chaos test scenarios can be solved, thereby achieving the extensiveness of test cases and testing each test case more comprehensively.

[0093] In one embodiment, the device further comprises:

[0094] An analysis module is used to, after testing each of the test cases to obtain test results, perform statistical analysis on the test results to generate target test results of corresponding indicators, and generate a test result analysis report;

[0095] An evaluation module is used to evaluate the distributed transaction according to the test result analysis report.

[0096] In one embodiment, the analysis data includes at least: distributed transaction information and verification data information corresponding to the distributed transaction;

[0097] The distributed transaction information at least includes: the number of branch transactions included in the distributed transaction; the branch transaction information corresponding to each branch transaction; and the verification data information at least includes a log number and a transaction date.

[0098] In one embodiment, the distributed transaction includes at least two branch transactions. Accordingly, the data acquisition module 710 includes:

[0099] An extraction unit, used to extract branch transaction information, log number and accounting date corresponding to each branch transaction from a preset log database;

[0100] The branch transaction information includes: branch name, running status, transaction function, compensation transaction, corresponding compensation operation of each compensation transaction and compensation function of the compensation operation; the running status includes: timeout, success and failure.

[0101] In one embodiment, the scene generation module 720 includes:

[0102] A determination unit, configured to determine, from the scenario analysis data, the number of branch transactions corresponding to the distributed transaction, as well as the branch name, running status, transaction function, compensation transaction corresponding to each of the branch transactions, the corresponding compensation operation corresponding to each of the compensation transactions, and the compensation function corresponding to the compensation operation;

[0103] A currently executed operation judging unit, configured to select one of the branch transactions and the compensation transactions as a currently executed operation, and to judge whether the event corresponding to the currently executed operation is a branch transaction or a transaction compensation;

[0104] A first chaos test scenario determination unit, configured to, if the event corresponding to the currently executed operation is a branch transaction, use the branch transaction as the current branch transaction, determine the running state of the current branch transaction, and determine the first chaos test scenario based on the running state;

[0105] The second chaos test scenario determination unit is used for, if the event corresponding to the currently executed operation is a transaction compensation, taking the transaction compensation as the current transaction compensation, and judging whether the current transaction compensation is a head compensation; if it is not a head compensation, pulling up the previous transaction compensation corresponding to the current transaction compensation, taking the previous transaction compensation as the current transaction compensation, and returning to the step of determining whether the current transaction compensation is a head compensation, until the current transaction compensation is a head compensation; if it is a head compensation, directly ending;

[0106] The target chaos test scenario determination unit is used to use the first chaos test scenario under the branch transaction as the event, and various execution situations corresponding to the transaction compensation as the chaos test scenarios corresponding to the distributed transaction.

[0107] In one embodiment, the first chaos test scenario determining unit includes:

[0108] The scenario determination subunit in the case of execution timeout is used for, when the running state is execution timeout, taking the current branch transaction as the n transaction, pulling up the n transaction compensation operation corresponding to the n transaction, and when the execution state of the n transaction compensation operation is execution success, judging whether the n transaction compensation operation is head compensation, if not head compensation, pulling up the compensation operation of the n-1 transaction, and when the execution state of the n-1 transaction compensation operation is execution success, taking the n-1 transaction compensation operation as the n transaction compensation operation, and returning to the step of determining whether the n transaction compensation operation is head compensation, until the n transaction compensation operation is head compensation; when the execution state of the current transaction compensation is execution failure, directly ending; wherein, the head compensation is the compensation operation of transaction 1;

[0109] A scenario determination subunit in the case of execution failure, used for, when the running state is execution failure, taking the current branch transaction as the n transaction, judging whether the n transaction is a head transaction, and directly terminating if the n transaction is a head transaction; if the n transaction is not a head transaction, pulling up the n-1 transaction compensation operation corresponding to the n-1 transaction, and when the execution state of the n-1 transaction compensation operation is execution success, judging whether the n-1 transaction compensation operation is head compensation, and if the n-1 transaction compensation operation is not head compensation, pulling up the compensation operation of the n-2 transaction corresponding to the n-1 transaction compensation operation, and when the execution state of the compensation operation of the n-2 transaction is execution success, taking the compensation operation of the n-2 transaction as the compensation operation of the n-1 transaction, and returning to the step of determining whether the n-1 transaction compensation operation is head compensation, until the compensation operation of the n-1 transaction is head compensation;

[0110] The scenario determination subunit in the case of successful execution is used to, when the running status is successful execution, take the current branch transaction as the n transaction, determine whether the n transaction is a tail transaction, and directly end if the n transaction is a tail transaction; if the n transaction is not a tail transaction, pull up the n+1 transaction corresponding to the n transaction, take the n+1 transaction as the n transaction, and return to the step of determining the running status of the current branch transaction until the n transaction is a tail transaction.

[0111] In one embodiment, the testing module 730 includes:

[0112] The testing unit is used to convert the chaos test scenario into a text description in the form of chaosblade statements according to a preset chaosblade tool, and use each text description in the form of chaosblade statements as a test case.

[0113] The distributed transaction testing device provided in the embodiment of the present invention can execute the distributed transaction testing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0114] In one embodiment, Figure 8 A schematic diagram of the structure of an electronic device provided for an embodiment of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0115] like Figure 8 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0116] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0117] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the distributed transaction testing method.

[0118] In some embodiments, the distributed transaction testing method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the distributed transaction testing method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to perform the distributed transaction testing method in any other appropriate manner (e.g., by means of firmware).

[0119] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0120] The computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable distributed transaction testing device, so that when the computer programs are executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer programs may be executed entirely on the machine, partially on the machine, partially on the machine as a stand-alone software package and partially on a remote machine, or entirely on a remote machine or server.

[0121] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0122] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0123] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0124] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0125] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0126] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A distributed transaction testing method, characterized in that: The method comprises: Get analytical data on distributed transactions; Generate a chaos test scenario corresponding to the distributed transaction based on the state machine model and the analysis data; A test case corresponding to the chaos test scenario is constructed according to a preset chaos test tool, and each test case is tested to obtain a test result.

2. The method according to claim 1, characterized in that: After testing each of the test cases to obtain a test result, the method further includes: Performing statistical analysis on the test results to generate target test results of corresponding indicators, and generating a test result analysis report; The distributed transaction is evaluated according to the test result analysis report.

3. The method according to claim 1, characterized in that The analysis data includes at least: distributed transaction information and verification data information corresponding to the distributed transaction; The distributed transaction information at least includes: the number of branch transactions included in the distributed transaction; the branch transaction information corresponding to each branch transaction; and the verification data information at least includes a log number and a transaction date.

4. The method according to claim 3, characterized in that The distributed transaction includes at least two branch transactions. Accordingly, obtaining analysis data of the distributed transaction includes: Extracting branch transaction information, log number and accounting date corresponding to each branch transaction from a preset log database; The branch transaction information includes: branch name, running status, transaction function, compensation transaction, corresponding compensation operation of each compensation transaction and compensation function of the compensation operation; the running status includes: timeout, success and failure.

5. The method according to claim 1, characterized in that The generating a chaos test scenario corresponding to the distributed transaction based on the state machine model and the analysis data includes: Determine from the scenario analysis data the number of branch transactions corresponding to the distributed transaction, as well as the branch name, running status, transaction function, compensation transaction corresponding to each branch transaction, the corresponding compensation operation corresponding to each compensation transaction, and the compensation function corresponding to the compensation operation; Selecting one from each of the branch transactions and each of the compensation transactions as a current execution operation, and determining whether an event corresponding to the current execution operation is a branch transaction or a transaction compensation; If the event corresponding to the currently executed operation is a branch transaction, the branch transaction is used as the current branch transaction, and the running state of the current branch transaction is determined, and the first chaos test scenario is determined based on the running state; If the event corresponding to the currently executed operation is a transaction compensation, the transaction compensation is used as the current transaction compensation, and it is determined whether the current transaction compensation is a head compensation. If it is not a head compensation, the previous transaction compensation corresponding to the current transaction compensation is pulled up, and the previous transaction compensation is used as the current transaction compensation, and the process returns to the step of determining whether the current transaction compensation is a head compensation until the current transaction compensation is a head compensation. If it is a head compensation, the process ends directly. The first chaos test scenario under the branch transaction as an event and various execution situations corresponding to the transaction compensation as an event are used as chaos test scenarios corresponding to the distributed transaction.

6. The method according to claim 5, characterized in that The determining a first chaos test scenario based on the running state includes: In the case where the running state is execution timeout, the current branch transaction is taken as the n transaction, and the n transaction compensation operation corresponding to the n transaction is pulled up. In the case where the execution state of the n transaction compensation operation is execution success, it is determined whether the n transaction compensation operation is head compensation. If it is not head compensation, the compensation operation of the n-1 transaction is pulled up, and in the case where the execution state of the n-1 transaction compensation operation is execution success, the compensation operation of the n-1 transaction is taken as the n transaction compensation operation, and the step of determining whether the n transaction compensation operation is head compensation is returned to the step of determining whether the n transaction compensation operation is head compensation, until the n transaction compensation operation is head compensation; in the case where the execution state of the current transaction compensation is execution failure, the process is terminated directly; wherein, the head compensation is the compensation operation of transaction 1; In the case where the running status is execution failure, the current branch transaction is taken as transaction n, and it is determined whether transaction n is a head transaction. If transaction n is a head transaction, it is directly terminated; if transaction n is not a head transaction, the n-1 transaction compensation operation corresponding to transaction n-1 is started, and when the execution status of the n-1 transaction compensation operation is execution success, it is determined whether the n-1 transaction compensation operation is head compensation. If the n-1 transaction compensation operation is not head compensation, the compensation operation of transaction n-2 corresponding to the n-1 transaction compensation operation is started, and when the execution status of the n-2 transaction compensation operation is execution success, the compensation operation of transaction n-2 is taken as the compensation operation of transaction n-1, and the process returns to the step of determining whether the n-1 transaction compensation operation is head compensation, until the compensation operation of transaction n-1 is head compensation; When the running status is successful execution, the current branch transaction is taken as the n transaction, and it is determined whether the n transaction is a tail transaction. If the n transaction is a tail transaction, it is directly terminated; if the n transaction is not a tail transaction, the n+1 transaction corresponding to the n transaction is pulled up, and the n+1 transaction is taken as the n transaction, and the process returns to the step of determining the running status of the current branch transaction until the n transaction is a tail transaction.

7. The method according to claim 1, characterized in that The constructing a test case corresponding to the chaos test scenario according to a preset chaos test tool includes: The chaos test scenario is converted into a text description in the form of chaosblade statements according to a preset chaosblade tool, and each text description in the form of chaosblade statements is used as a test case.

8. A distributed transaction testing device, characterized in that: The device comprises: Data acquisition module, used to obtain analysis data of distributed transactions; A scenario generation module, used to generate a chaos test scenario corresponding to the distributed transaction based on a state machine model and the analysis data; The test module is used to construct test cases corresponding to the chaos test scenarios according to a preset chaos test tool, and to test each of the test cases to obtain test results.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed transaction testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed transaction testing method according to any one of claims 1 to 7 when executed.

Images