Automated anomaly testing method, device, equipment, and medium for distributed transactions

Abstract

The present application relates to an automated exception testing method, device, computer equipment and storage medium for distributed transactions. The present application can automatically initiate testing of distributed transactions. The test types include simulation methods for major exception scenarios such as rollback, idempotence, empty rollback, and anti-hanging. Rollback can be automatically triggered without manual operation, effectively improving the efficiency of testing work. The method includes: obtaining the event number of the distributed transaction; wherein the event number includes the main transaction number; obtaining the main transaction number, creating different types of transactions to be tested for the main transaction number; testing different types of transactions to be tested separately to obtain exception test results.

Description

Technical Field

[0001] The present application relates to the field of distributed computing technology, and in particular to a method, apparatus, computer equipment, storage medium, and computer program product for automated anomaly testing of distributed transactions. Background Art

[0002] Distributed transactions are transactions performed on different nodes in a distributed system. These transactions must adhere to the ACID properties. These properties are the four essential characteristics that a database management system must possess to ensure that transactions are correct and reliable when writing or updating data: atomicity (or indivisibility), consistency, isolation (also known as independence), and durability.

[0003] To ensure the aforementioned ACID properties, distributed transaction models must be tested. For distributed transactions, three typical exception tests include idempotence testing, empty rollback testing, and anti-hanging testing. For distributed transaction model testing, technical means can be used to automate test initiation and assertion verification for normal process testing. However, for exception testing, such as testing the transaction rollback process, manual rollback initiation is generally required, as the test initiator lacks visibility into the internal transaction processing mechanisms and cannot automatically trigger a rollback.

[0004] However, for manually initiated tests, due to low work efficiency and small test coverage, it is easy to cause test omissions and cannot strictly guarantee the above-mentioned ACID characteristics of the distributed transaction model. Summary of the Invention

[0005] Based on this, it is necessary to provide an automated exception testing method, device, computer equipment, and computer-readable storage medium for distributed transactions to address the above technical problems.

[0006] In a first aspect, the present application provides a method for automated anomaly testing of distributed transactions. The method comprises:

[0007] Obtaining an event ticket number for a distributed transaction, wherein the event ticket number includes a master transaction number;

[0008] Obtain the main transaction number, and create different types of transactions to be tested according to the main transaction number;

[0009] Tests are performed on the different types of transactions to be tested respectively to obtain abnormal test results.

[0010] In one embodiment, the different types of transactions to be tested include rollback transactions to be tested; and obtaining the main transaction number and creating different types of transactions to be tested based on the main transaction number include:

[0011] Obtain the main transaction number, and create the rollback transaction to be tested that is the same as the main transaction type according to the main transaction number;

[0012] When the test data is received, the transaction to be tested is executed to obtain a transaction execution result;

[0013] The abnormal test result includes a rollback test result, and the abnormal test results obtained by testing the different types of transactions to be tested separately include:

[0014] Throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation and obtain the rollback test result.

[0015] In one embodiment, after obtaining the rollback test result, the method further includes:

[0016] According to the difference between the transaction execution result and the rollback test result, a technical assertion is performed on the main transaction corresponding to the main transaction number.

[0017] In one embodiment, the rollback transaction to be tested includes a rollback transaction method to be tested and a rollback transaction service to be tested; and creating the rollback transaction to be tested having the same type as the main transaction according to the main transaction type of the main transaction number includes:

[0018] Obtain the transaction rollback method to be tested through Java mapping;

[0019] Obtain the rollback transaction service to be tested according to the environmental context information;

[0020] The rollback transaction method to be tested and the rollback transaction service to be tested are used as the rollback transaction to be tested.

[0021] In one embodiment, the different types of transactions to be tested include idempotent transactions to be tested, and obtaining the main transaction number and creating different types of transactions to be tested according to the main transaction number include:

[0022] Obtain the main transaction number, and create the idempotent transaction to be tested that has the same main transaction type as the main transaction number according to the main transaction type;

[0023] The testing of the different types of transactions to be tested is performed separately to obtain abnormal test results, including:

[0024] When the test data is received, the idempotent transaction to be tested is run to obtain an idempotent transaction running result.

[0025] In one embodiment, after executing the idempotent transaction to be tested upon receiving the test data and obtaining the idempotent transaction execution result, the method further includes:

[0026] Delete data from idempotent tables;

[0027] Update the record status of the main transaction to the rolling back state, and insert the first sub-transaction associated with the main transaction;

[0028] Trigger an empty rollback of the first subtransaction to obtain an empty rollback test result.

[0029] In one embodiment, after triggering the first subtransaction to roll back empty and obtaining an empty rollback test result, the method further includes:

[0030] Updating the record status of the main transaction to a committing state, and inserting a second subtransaction associated with the main transaction;

[0031] Trigger the second sub-transaction to enter the commit process and obtain the anti-hanging test result.

[0032] In a second aspect, the present application also provides an automated exception testing device for distributed transactions. The device comprises:

[0033] An event ticket number acquisition module, configured to acquire the event ticket number of a distributed transaction; wherein the event ticket number includes the main transaction number;

[0034] A test transaction creation module is used to obtain the main transaction number and create different types of test transactions according to the main transaction number;

[0035] The abnormality test module is used to test the different types of transactions to be tested respectively to obtain abnormality test results.

[0036] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements each step of the above-mentioned embodiment of the method for automated anomaly testing of distributed transactions when executing the computer program.

[0037] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-mentioned embodiment of the method for automated anomaly testing of distributed transactions.

[0038] The above-mentioned automated exception testing method, device, computer equipment and storage medium for distributed transactions obtain the event ticket number of the distributed transaction; wherein the event ticket number includes the main transaction number; obtain the main transaction number, create different types of test transactions for the main transaction number; test each type of test transaction separately to obtain the exception test results. This application can automatically initiate the test of distributed transactions. The test types include simulation methods for major exception scenarios such as rollback, idempotence, empty rollback, and anti-hanging. Rollback can be automatically triggered without manual operation, effectively improving the efficiency of testing work. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 1 is a flow chart of a method for automated exception testing of distributed transactions in one embodiment;

[0040] Figure 2 Schematic diagram of a flow chart of an automated anomaly testing method according to another embodiment;

[0041] Figure 3 Schematic diagram of a flow chart of an anti-hanging test method in one embodiment;

[0042] Figure 4 A structural block diagram of an automated exception testing device for distributed transactions in one embodiment;

[0043] Figure 5 is a diagram of the internal structure of a computer device in one embodiment;

[0044] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in another embodiment. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0046] The automated exception testing method for distributed transactions provided in the embodiments of the present application can be applied to a distributed cluster, which is a server cluster consisting of multiple servers. In particular, it can be applied to a two-stage TCC (Try-Confirm-Cancel) distributed service framework. In a TCC service, each preliminary operation is ultimately confirmed or canceled. Therefore, for a specific business service, the TCC transaction mechanism requires the business system to provide three stages of business logic: a preliminary Try operation, a Confirm operation, and a Cancel operation.

[0047] In one embodiment, Figure 1As shown, a method for automated exception testing of distributed transactions is provided, comprising the following steps:

[0048] Step S101: Obtain an event ticket number, wherein the event ticket number includes the main transaction number;

[0049] Distributed transactions are used to ensure data consistency across different nodes in a distributed system. In a distributed scenario, a system consists of multiple subsystems, each with an independent data source. These subsystems call each other to create more complex services. For example, an e-commerce system may consist of a shopping subsystem, an inventory subsystem, and an order subsystem. The shopping subsystem integrates the shopping service by calling the inventory and order subsystems. When a user requests the shopping subsystem to complete an order, the shopping subsystem calls the inventory subsystem to deduct the inventory quantity of the corresponding product and calls the order subsystem to insert the order record. In a distributed transaction, each entry point transaction records a unique event ID (identity document). The corresponding main transaction also has a unique main transaction ID. The main transaction may include multiple subtransactions, each with a unique subtransaction ID. For example, in an interbank transfer transaction, the channel entry point (such as mobile banking or online banking) automatically generates an event ID when initiating the transaction and then initiates the main transaction for the interbank transfer. This main transaction includes two subtransactions: debiting the customer and sending a credit message to the interbank.

[0050] Specifically, when a business process automation test case is initiated, such as an inter-bank transfer transaction, the system will obtain the event ticket number of the above business process, which includes the main transaction number.

[0051] Step S102: Obtain the main transaction number, and create different types of transactions to be tested according to the main transaction number;

[0052] Specifically, the main transaction number ID is obtained, and the type of the main transaction can be identified according to the main transaction number. Different exception tests are created according to the main transaction type. Before performing different exception tests, different types of transactions to be tested need to be created.

[0053] Step S103: testing different types of transactions to be tested respectively to obtain abnormal test results.

[0054] Specifically, for example, different types of abnormal test tasks (i.e., transactions to be tested) such as rollback test and idempotent test are created based on the main transaction of the above-mentioned inter-bank transfer, and different test data are obtained to complete one or more tests, obtain test results, and analyze the test results.

[0055] A specific implementation process for the above steps S101-S103 is as follows Figure 2 As shown, Figure 2 Shows an automated testing process, combined with Figure 2 The specific instructions are as follows:

[0056] Step S201: Start the automated exception test. This step includes starting some configuration information.

[0057] Step S202: Run an automated test case. For example, create and run an automated test case for a normal business process, such as creating and running an inter-bank transfer transaction.

[0058] Step S203: Obtain the event ticket number. Specifically, since the above business process involves collaboration between multiple subsystems or subservices, a business process often includes multiple event ticket numbers. For example, the above inter-bank transfer transaction involves deductions in one database, credits in another database, and fee calculations.

[0059] Step S204: Obtain the main transaction ID number. Specifically, obtain the main transaction ID number corresponding to this transaction based on the above event ticket number, for example, the main transaction is a deduction from one database and an entry to another database.

[0060] Step S205: Exception Condition Preparation. Exception condition preparation involves performing an exception test on the main transaction. In a normal interbank transfer, funds are debited from one database and credited to another. However, under certain abnormal conditions, such as a database failure causing the interbank transfer to fail, the system must determine whether it can recover data from the other related database based on the failed data operation in one database, thus avoiding a situation where a debit in one database fails while a credit is successfully made in another. Therefore, exception condition preparation simulates the occurrence of these failure conditions.

[0061] Step S206: Initiate an abnormal process, such as initiating a forced rollback request. For example, in the case of a database failure, a forced rollback is initiated so that the two databases involved in the transfer transaction can be rolled back to the state before the transaction failed.

[0062] Step S207, ending the case execution, that is, waiting for the above abnormal test case to finish executing.

[0063] Step S208: parsing the results returned by the abnormal test case. Specifically, the results returned by the abnormal test are analyzed, for example, analyzing whether the two databases meet expectations in the abnormal case test.

[0064] Step S209: Assertion test results are performed. This means that an assertion is performed to determine whether the exception test meets expectations. For example, if a database failure causes a transaction failure and the transfer transaction is forcibly rolled back, can the balance of the transfer-out account be restored in a timely manner? If so, it is considered to meet expectations. If not, it is considered to be unsatisfactory and requires further improvement.

[0065] Step S210: Adaptive automated exception testing. This is done by completing the adaptive automated exception testing. For transactions that fail test assertions, the machine learning platform, combined with its learning of test process data, determines that the current test failure is due to a data issue and automatically modifies the test case data. After verifying the test environment, the transaction is automatically re-initiated for re-verification to obtain a stable automated test result. Simultaneously, the test process data is fed into the machine learning platform for training. This ensures a stable automated test result, eliminating the impact of the environment and test data on the test results.

[0066] The above embodiment obtains the event ticket number of a distributed transaction, which includes the main transaction number; obtains the main transaction number, creates different types of test transactions for the main transaction number, and tests each of the different types of test transactions to obtain abnormal test results. This embodiment can automatically initiate distributed transaction testing, automatically triggering a rollback without manual operation, and effectively improving testing efficiency.

[0067] In one embodiment, the different types of transactions to be tested include rollback transactions to be tested; the step S102 includes: obtaining a main transaction number, creating a rollback transaction to be tested that is of the same type as the main transaction according to the main transaction type of the main transaction number; and executing the transaction to be tested upon receiving the test data to obtain a transaction execution result.

[0068] For distributed transactions, typical exception tests include rollback testing, idempotence testing, empty rollback testing, and anti-hang testing. A transaction is a user-defined sequence of database operations that must be performed in full or incomplete, forming an indivisible unit of work. Rollback testing involves removing updates performed by one or more partially completed transactions during exception testing. Rollbacks are required to ensure database integrity after application, database, or system errors. For example, during a user withdrawal, if the balance in the user's account decreases but the funds are not received, a transaction rollback is necessary.

[0069] Specifically, obtain the main transaction number, create a rollback transaction to be tested based on the main transaction number, and begin the rollback test. For example, a normal transaction test might throw a RuntimeException before the main transaction method is completed, causing the transaction to roll back. Before officially starting the rollback test, receive test data to complete the normal flow of the main transaction and obtain the transaction's normal execution results.

[0070] The above-mentioned abnormal test result includes a rollback test result. The above-mentioned step S103 includes: throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation, and obtaining a rollback test result.

[0071] Specifically, taking the transfer transaction test (entry point in Transfer.java) as an example, first write a Java class (TransferTest.java) based on the TestNG framework to initiate the inter-bank transfer transaction test. Define the test class TransferTest.java as a Spring Framework Bean entity. When initiating the test method of this test class, this test class assumes the role of a master transaction, initiating the tested transfer transaction. Therefore, simply throwing an exception in this test class indicates an exception in the master transaction, initiating a transaction rollback and thus rolling back the tested transfer transaction.

[0072] In the above embodiment, an automatic rollback test is triggered by throwing a JAVA exception. For example, when completing a payment, a machine malfunctions, resulting in a payment failure. In this case, a result of a failed deduction is required. The rollback test result can be quickly verified through automatic testing.

[0073] In one embodiment, after obtaining the rollback test result, the method further includes: performing a technical assertion on the main transaction corresponding to the main transaction number according to the difference between the transaction execution result and the rollback test result.

[0074] Among them, technical assertion refers to asserting that a certain actual running value is the same as expected, otherwise an exception is thrown.

[0075] Specifically, technical assertions include pre-rollback business assertions, post-rollback technical assertions, and post-rollback business assertions. They are as follows:

[0076] 1) Pre-rollback business assertion. Before a distributed transaction is rolled back, a business assertion is performed on the transaction. For example, if the transaction is a transfer of 100 yuan from card A to card B, before the transaction is rolled back, it is asserted whether the balance of card A is deducted by 100 yuan and the balance of card B is increased by 100 yuan.

[0077] 2) Post-rollback technical assertion: After a distributed transaction is rolled back, check whether the transaction log record is complete and automatically determine whether the rollback operation is successful.

[0078] 3) Post-rollback business assertion: After a distributed transaction is rolled back, a business assertion is performed on the transaction. For example, if the current transaction is a transfer of 100 yuan from card A to card B, after the transaction is rolled back, it is asserted whether the balance of card A and card B remains unchanged.

[0079] The above embodiment uses technical assertions to further accurately determine whether the business process is normal, further ensuring the ACID properties of the system. Furthermore, distributed transaction testing automatically performs assertion judgments, including both technical judgments on the transaction and business logic judgments before and after rollback, thereby fully ensuring the correctness of the program logic.

[0080] In the specific testing process, the use cases of transaction rollback are as follows:

[0081] 1). The automation case XLS must have an event number variable. You can have a column named "serialno" and fill in "#{event number}" in the cell of the corresponding case to automatically calculate the event number when the current case is running.

[0082] 2) Add a column named "Transaction Rollback" to the automation case XLS file. Enter "Transaction Rollback ({serialno})" in the cell of the corresponding case to make it clear that this case performs an active rollback operation in the distributed transaction.

[0083] 3) After the automated case completes, a post-rollback assertion is automatically generated in the result script. This requires an assertion column in the script, and it must include assertions for the host or platform table. Before the transaction is rolled back, a test assertion is performed (e.g., if a transfer transaction involves transferring 100 yuan from card A to card B, before the transaction is rolled back, an assertion is made to determine whether the balance on card A has decreased by 100 yuan and the balance on card B has increased by 100 yuan). After the transaction is rolled back, another assertion is made to determine whether the original host or platform table has been restored (e.g., if a transfer transaction involves transferring 100 yuan from card A to card B, after the transaction is rolled back, an assertion is made to determine whether the balances on card A and card B remain unchanged).

[0084] 4) For special rollback assertions, such as transaction numbers that automatically increment regardless of rollback and never roll back, add a column called "Assertion after transaction rollback 1" to the automation case to assert whether the data has been rolled back. Enter the assertion content in the corresponding case cell, such as "Host table. Query condition 1. Expected value 1" or "Platform table. Query condition 2. Expected value 1." If there are multiple assertions after transaction rollback, add multiple columns, such as "Assertion after transaction rollback 2."

[0085] Furthermore, for transactions that fail the test assertion, the machine learning platform combines its learning of the test process data and determines that the reason for the current test failure is a data problem, then automatically modifies the test case data. After checking the test environment, it automatically re-initiates the transaction for re-verification to obtain a stable automated test result. At the same time, the test process data is input into the machine learning platform for learning and training, ensuring the adaptive and automated characteristics of abnormal testing.

[0086] In one embodiment, the rollback transaction to be tested includes a rollback transaction method to be tested and a rollback transaction service to be tested. Creating a rollback transaction to be tested that is of the same type as the main transaction based on the main transaction type of the main transaction number includes: obtaining the rollback transaction method to be tested through Java mapping; obtaining the rollback transaction service to be tested based on environment context information; and using the rollback transaction method to be tested and the rollback transaction service to be tested as the rollback transaction to be tested.

[0087] The rollback transaction method to be tested and the rollback transaction service to be tested are both basic grammatical structures in Java.

[0088] Specifically,

[0089] (1) First, obtain the transaction method to be tested through JAVA mapping.

[0090] (2) Get the transaction service to be tested in conjunction with Spring's context.

[0091] (3) After filling in the input information according to the case content, call the service and method to be tested

[0092] (4) Get the return result of the service method being tested. At this time, you can test and verify the normal process of the transaction. For example, in the case of a transfer transaction, the transfer account should have been deducted.

[0093] (5) A JAVA exception is then thrown, triggering a rollback of the entire transaction. The transfer transaction is rolled back. At this point, the transaction rollback process can be tested and verified. For example, if the transfer transaction is rolled back, the balance of the transferred account should be restored.

[0094] In the above embodiment, the creation of the rollback transaction to be tested is completed by creating a test rollback transaction method and a rollback transaction service to be tested, thereby providing a data basis for subsequent testing.

[0095] In one embodiment, the different types of transactions to be tested include idempotent transactions to be tested. Step S102 includes: obtaining a main transaction number, creating a idempotent transaction to be tested that is of the same type as the main transaction according to the main transaction type of the main transaction number; and testing the different types of transactions to be tested separately to obtain abnormal test results, including: executing the idempotent transaction to be tested upon receiving test data to obtain an idempotent transaction execution result.

[0096] Idempotence testing means that the same transaction, when called multiple times, should produce the same business results as a single call. In other words, the impact of executing an operation multiple times should be the same as executing it once. For example, consider a transaction involving a payment or collection on an e-commerce website. When a customer sends a payment request to WeChat Pay, a smooth process will yield no errors. However, if a request times out after being sent, and the customer never receives a receipt confirming the success or failure of the payment, will the customer resend the payment request? This requires mechanisms to ensure idempotence. For example, use established protocols (idempotent tokens such as bill numbers) or idempotent databases.

[0097] Specifically, an idempotent transaction to be tested with the same type as the main transaction is created based on the main transaction type of the main transaction number. For example, if the main transaction type is a transaction task about purchase payment, a normal transaction is initiated and the event number of this transaction is obtained. After the main transaction method is called, the main transaction ID of this transaction is obtained from the idempotent table of the transaction based on the event number, and a transaction with the same transaction ID is re-initiated.

[0098] The above embodiment completes the automatic idempotency test by automatically initiating a transaction that is the same as the main transaction, without the need for manual initiation, thereby further improving the test efficiency.

[0099] In one embodiment, after the idempotent transaction to be tested is run upon receiving the test data and obtaining the idempotent transaction running result, the method further includes: deleting the data in the idempotent table; updating the record status of the main transaction to a rollback status, and inserting a first subtransaction associated with the main transaction; triggering an empty rollback of the first subtransaction, and obtaining an empty rollback test result.

[0100] Among them, an empty rollback means that when the reverse operation of the second-phase transaction occurs earlier than the forward operation of the first phase, the transaction should be allowed to close normally. For example, when a customer needs to remit money, he first sends a remittance request. During the period when the money reaches the target account, the customer suddenly does not want to remit the money or finds that the target account number is incorrect and needs to withdraw the remittance. At this time, the above-mentioned money has not yet entered the target account. In this case, the remittance cancellation is considered to be the reverse operation of the second-phase transaction, and this operation occurs earlier than the above-mentioned remittance action (i.e., the forward operation of the first phase). To ensure the normal operation of distributed transactions, empty rollbacks should be allowed in distributed transactions. Specifically, in the TCC (Try-Confirm-Cancel) service, if the TCC service receives a Cancel request without receiving a Try request, this scenario is called an empty rollback and needs to be tested for an empty rollback.

[0101] Specifically, the empty rollback process is as follows:

[0102] (1) Initiate a transaction, obtain the transaction event number, and complete the entire transaction process successfully.

[0103] (2) From the idempotent table of the transaction, query the transaction event number to obtain the main transaction ID of the transaction, for example, the main transaction is a payment operation.

[0104] (3) Technically clean up the business-side transaction traces generated by the transaction, that is, delete the records in the idempotent table of transaction records; and in the record library of the main transaction, change the status of the main transaction table record to "rolling back", and insert a sub-transaction task associated with this main transaction ID and with the start time of the current time, that is, the first sub-transaction mentioned above, which can be, for example, a payment revocation.

[0105] (4) At this time, the main transaction will be triggered to roll back. At this time, the business side has technically cleaned up the transaction traces in advance, so it can simulate an empty rollback on the business side.

[0106] The above embodiment simulates an empty rollback by clearing transaction traces, thereby enriching the test types.

[0107] In one embodiment, after triggering the empty rollback of the first subtransaction and obtaining the empty rollback test result, the method further includes: updating the record status of the main transaction to the committing status, and inserting the second subtransaction associated with the main transaction; triggering the second subtransaction to enter the commit process, and obtaining the anti-hanging test result.

[0108] When the transaction coordinator calls the first-phase Try operation of the TCC service, a timeout may occur due to network congestion. In this case, the transaction coordinator triggers a second-phase rollback and calls the Cancel operation of the TCC service. After this, the first-phase Try data packet stuck on the network is received by the TCC service, and the second-phase Cancel request is executed before the first-phase Try request.

[0109] When implementing TCC services, users should allow empty rollbacks, but reject the first-stage Try requests that come after the empty rollback. This requires anti-hanging.

[0110] The anti-hang test means that after an empty rollback, when the first stage forward operation is received again, it should be able to refuse to process or automatically scan and repair the state. The anti-hang test used in this embodiment is as follows Figure 3 shown.

[0111] Therefore, based on the above empty rollback test, we continue to modify the status of the main transaction table record in the main transaction record library to "Committing" and insert a subtransaction task (the second subtransaction mentioned above) associated with this main transaction ID and with the current start time. This will trigger the main transaction to enter the commit process, thereby verifying the anti-hang test of the main transaction.

[0112] The above embodiment can further ensure the reliability of distributed transactions by simulating an anti-hanging test based on an empty rollback.

[0113] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0114] Based on the same inventive concept, embodiments of the present application also provide an automated anomaly testing device for distributed transactions for implementing the aforementioned automated anomaly testing method for distributed transactions. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the embodiments of one or more automated anomaly testing devices for distributed transactions provided below can be found in the aforementioned limitations of the automated anomaly testing method for distributed transactions, and will not be further elaborated here.

[0115] In one embodiment, Figure 4 As shown, an automated exception testing device 400 for distributed transactions is provided, comprising: an event ticket number acquisition module 401, a transaction to be tested creation module 402, and an exception testing module 403, wherein:

[0116] The event ticket number acquisition module 401 is used to acquire the event ticket number of the distributed transaction; wherein the event ticket number includes the main transaction number;

[0117] A test transaction creation module 402 is configured to obtain the main transaction number and create different types of test transactions according to the main transaction number;

[0118] The abnormality testing module 403 is used to test the different types of transactions to be tested respectively to obtain abnormality test results.

[0119] In one embodiment, the different types of transactions to be tested include rollback transactions to be tested; the transaction to be tested creating module 402 is further configured to:

[0120] Obtaining the main transaction number, creating the to-be-tested rollback transaction of the same type as the main transaction according to the main transaction type of the main transaction number; executing the to-be-tested transaction upon receiving the test data, and obtaining a transaction execution result;

[0121] The abnormal test result includes a rollback test result. The abnormal test module 403 is further configured to:

[0122] Throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation and obtain the rollback test result.

[0123] In one embodiment, a test assertion unit is further included, which is configured to:

[0124] According to the difference between the transaction execution result and the rollback test result, a technical assertion is performed on the main transaction corresponding to the main transaction number.

[0125] The test assertion unit specifically includes: a pre-rollback business assertion sub-unit, a post-rollback technical assertion sub-unit and a post-rollback business assertion sub-unit.

[0126] In one embodiment, the test rollback transaction includes a test rollback transaction method and a test rollback transaction service; the test transaction creation module 402 is further configured to:

[0127] The rollback transaction method to be tested is obtained by Java mapping; the rollback transaction service to be tested is obtained according to environmental context information; and the rollback transaction method to be tested and the rollback transaction service to be tested are used as the rollback transaction to be tested.

[0128] In one embodiment, the different types of transactions to be tested include idempotent transactions to be tested, and the transaction to be tested creating module 402 is further configured to:

[0129] Obtain the main transaction number, and create the idempotent transaction to be tested that has the same main transaction type as the main transaction number according to the main transaction type;

[0130] The above-mentioned abnormal test module is further used to: run the idempotent transaction to be tested when the test data is received, and obtain the idempotent transaction running result.

[0131] In one embodiment, the anomaly testing module 403 is further configured to:

[0132] Delete the data in the idempotent table; update the record status of the main transaction to the rollback status, and insert the first sub-transaction associated with the main transaction; trigger the empty rollback of the first sub-transaction to obtain an empty rollback test result.

[0133] In one embodiment, the anomaly testing module 403 is further configured to:

[0134] The record status of the main transaction is updated to the committing status, and a second sub-transaction associated with the main transaction is inserted; the second sub-transaction is triggered to enter the commit process, and an anti-hanging test result is obtained.

[0135] Each module in the above-mentioned automated anomaly testing device for distributed transactions can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0136] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data such as distributed transactions and test results. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, an automated anomaly testing method for distributed transactions is implemented.

[0137] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown. The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, an automated anomaly testing method for distributed transactions is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the computer device housing, or an external keyboard, touchpad or mouse.

[0138] Those skilled in the art will understand that Figure 5-6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0139] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0140] Obtaining an event ticket number for a distributed transaction, wherein the event ticket number includes a master transaction number;

[0141] Obtain the main transaction number, and create different types of transactions to be tested according to the main transaction number;

[0142] Tests are performed on the different types of transactions to be tested respectively to obtain abnormal test results.

[0143] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0144] Obtain the main transaction number, and create the rollback transaction to be tested that is the same as the main transaction type according to the main transaction number;

[0145] When the test data is received, the transaction to be tested is executed to obtain a transaction execution result;

[0146] The abnormal test result includes a rollback test result, and the abnormal test results obtained by testing the different types of transactions to be tested separately include:

[0147] Throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation and obtain the rollback test result.

[0148] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0149] According to the difference between the transaction execution result and the rollback test result, a technical assertion is performed on the main transaction corresponding to the main transaction number.

[0150] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0151] Obtain the transaction rollback method to be tested through Java mapping;

[0152] Obtain the rollback transaction service to be tested according to the environmental context information;

[0153] The rollback transaction method to be tested and the rollback transaction service to be tested are used as the rollback transaction to be tested.

[0154] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0155] Obtain the main transaction number, and create the idempotent transaction to be tested that has the same main transaction type as the main transaction number according to the main transaction type;

[0156] The testing of the different types of transactions to be tested is performed separately to obtain abnormal test results, including:

[0157] When the test data is received, the idempotent transaction to be tested is run to obtain an idempotent transaction running result.

[0158] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0159] Delete data from idempotent tables;

[0160] Update the record status of the main transaction to the rolling back state, and insert the first sub-transaction associated with the main transaction;

[0161] Trigger an empty rollback of the first subtransaction to obtain an empty rollback test result.

[0162] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0163] Updating the record status of the main transaction to a committing state, and inserting a second subtransaction associated with the main transaction;

[0164] Trigger the second sub-transaction to enter the commit process and obtain the anti-hanging test result.

[0165] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0166] Obtaining an event ticket number for a distributed transaction, wherein the event ticket number includes a master transaction number;

[0167] Obtain the main transaction number, and create different types of transactions to be tested according to the main transaction number;

[0168] Tests are performed on the different types of transactions to be tested respectively to obtain abnormal test results.

[0169] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0170] Obtain the main transaction number, and create the rollback transaction to be tested that is the same as the main transaction type according to the main transaction number;

[0171] When the test data is received, the transaction to be tested is executed to obtain a transaction execution result;

[0172] The abnormal test result includes a rollback test result, and the abnormal test results obtained by testing the different types of transactions to be tested separately include:

[0173] Throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation and obtain the rollback test result.

[0174] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0175] According to the difference between the transaction execution result and the rollback test result, a technical assertion is performed on the main transaction corresponding to the main transaction number.

[0176] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0177] Obtain the transaction rollback method to be tested through Java mapping;

[0178] Obtain the rollback transaction service to be tested according to the environmental context information;

[0179] The rollback transaction method to be tested and the rollback transaction service to be tested are used as the rollback transaction to be tested.

[0180] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0181] Obtain the main transaction number, and create the idempotent transaction to be tested that has the same main transaction type as the main transaction number according to the main transaction type;

[0182] The testing of the different types of transactions to be tested is performed separately to obtain abnormal test results, including:

[0183] When the test data is received, the idempotent transaction to be tested is run to obtain an idempotent transaction running result.

[0184] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0185] Delete data from idempotent tables;

[0186] Update the record status of the main transaction to the rolling back state, and insert the first sub-transaction associated with the main transaction;

[0187] Trigger an empty rollback of the first subtransaction to obtain an empty rollback test result.

[0188] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0189] Updating the record status of the main transaction to a committing state, and inserting a second subtransaction associated with the main transaction;

[0190] Trigger the second sub-transaction to enter the commit process and obtain the anti-hanging test result.

[0191] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the computer program implements the steps in the embodiment of the above-mentioned method for automated anomaly testing of distributed transactions.

[0192] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0193] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0194] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0195] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. An automated exception testing method for distributed transactions, characterized in that: The method comprises: Obtaining the event ticket number of the distributed transaction; wherein the event ticket number includes the main transaction number; Obtain the main transaction number, and create different types of transactions to be tested according to the main transaction number; Conducting tests on the different types of abnormal scenario data to obtain abnormal test results; The different types of transactions to be tested include rollback transactions to be tested; obtaining the main transaction number and creating different types of transactions to be tested according to the main transaction number include: Obtain the main transaction number, and create the rollback transaction to be tested that is the same as the main transaction type according to the main transaction number; When the test data is received, the transaction to be tested is executed to obtain a transaction execution result; The abnormal test results include rollback test results, and the abnormal test results obtained by testing the different types of abnormal scenario data separately include: Throwing a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation and obtain the rollback test result; After obtaining the rollback test result, the method further includes: According to the difference between the transaction execution result and the rollback test result, a technical assertion is performed on the main transaction corresponding to the main transaction number.

2. The method according to claim 1, characterized in that The rollback transaction to be tested includes a rollback transaction method to be tested and a rollback transaction service to be tested; the step of creating the rollback transaction to be tested that is of the same type as the main transaction according to the main transaction type numbered by the main transaction includes: Obtain the transaction rollback method to be tested through Java mapping; Obtain the rollback transaction service to be tested according to the environmental context information; The rollback transaction method to be tested and the rollback transaction service to be tested are used as the rollback transaction to be tested.

3. The method according to claim 1, characterized in that The different types of abnormal scenario data include idempotent transactions to be tested, and obtaining the main transaction number and creating different types of transactions to be tested according to the main transaction number include: Obtain the main transaction number, and create the idempotent transaction to be tested that has the same main transaction type as the main transaction number according to the main transaction type; The abnormal scenario data of different types are tested separately to obtain abnormal test results, including: When the test data is received, the idempotent transaction to be tested is run to obtain an idempotent transaction running result.

4. The method according to claim 3, characterized in that After executing the idempotent transaction to be tested upon receiving the test data and obtaining the idempotent transaction execution result, the method further includes: Delete data from idempotent tables; Update the record status of the main transaction to the rolling back state, and insert the first sub-transaction associated with the main transaction; Trigger an empty rollback of the first subtransaction to obtain an empty rollback test result.

5. The method according to claim 4, characterized in that After triggering the first subtransaction to roll back empty and obtaining an empty rollback test result, the method further includes: Updating the record status of the main transaction to a committing state, and inserting a second subtransaction associated with the main transaction; Trigger the second sub-transaction to enter the commit process and obtain the anti-hanging test result.

6. An automated exception testing device for distributed transactions, characterized in that: The device comprises: An event ticket number acquisition module, configured to acquire the event ticket number of a distributed transaction; wherein the event ticket number includes the main transaction number; A test transaction creation module is used to obtain the main transaction number and create different types of test transactions according to the main transaction number; An abnormality testing module, used to test the different types of abnormal scenario data respectively to obtain abnormality test results; The different types of transactions to be tested include rollback transactions to be tested; the transaction creation module to be tested is further configured to obtain the main transaction number, create the rollback transaction to be tested of the same type as the main transaction according to the main transaction type of the main transaction number; and execute the transaction to be tested upon receiving the test data to obtain a transaction execution result; The exception test result includes a rollback test result, and the exception test module is further used to throw a JAVA exception to trigger the rollback transaction to be tested to start a rollback operation to obtain the rollback test result; The device further comprises: A technical assertion unit is used to make a technical assertion on the main transaction corresponding to the main transaction number according to the difference between the transaction execution result and the rollback test result.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images