Test method, device and equipment, readable storage medium and program product

Abstract

The embodiment of the invention provides a test method and device, equipment, a readable storage medium and a program product, and the method comprises the steps: determining test scene information which is used for indicating a first service update state and a second service update state; simulating and calling the first service equipment to execute the target main transaction according to the main transaction processing logic corresponding to the first service updating state to obtain a simulation execution result of the target main transaction; simulating and calling the second service equipment to execute the target slave transaction according to the simulation execution result of the target master transaction and the slave transaction processing logic corresponding to the second service updating state to obtain the simulation execution result of the target slave transaction; and determining a test result according to the simulation execution result of the target slave transaction. According to the method provided by the embodiment of the invention, the test can be performed according to the test scene information to obtain the test result for the transaction processing logic, which is beneficial to troubleshooting possible abnormities in the gray release process in advance and effectively improves the stability of a service system.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a testing method, a testing device, a computer device, a computer-readable storage medium, and a computer program product. Background Art

[0002] Gray release is a release method that enables smooth transition. For example, in a service system including multiple service devices, when multiple service devices implement the same transaction, the gray release method can be used to gradually update the transaction processing logic in each service device, thereby improving the user experience. Transactions include main transactions and sub-transactions. Generally, after the main transaction is executed, the sub-transaction can be executed to ensure data consistency.

[0003] However, when using the gray release method to update the transaction processing logic of multiple service devices, the pre-update transaction processing logic and the post-update transaction processing logic may coexist in the service system, and there may be compatibility issues, timing issues, etc. between the pre-update transaction processing logic and the post-update transaction processing logic, which may cause abnormalities during the gray release process and reduce the system stability. Summary of the Invention

[0004] Embodiments of this application provide a testing method, device, equipment, readable storage medium, and program product, which can perform tests according to test scenario information to obtain test results for transaction processing logic, helping to detect potential abnormalities in the gray release process in advance and effectively improving the stability of the service system.

[0005] On the one hand, embodiments of this application provide a testing method, and the method includes:

[0006] Determine test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the pre-update transaction processing logic, and the service device in the service updated status is used to implement the target transaction according to the post-update transaction processing logic, and the transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic;

[0007] According to the test scenario information, simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction;

[0008] Simulate calling the second service device to execute the target sub-transaction according to the simulation execution result of the target main transaction, and execute the target sub-transaction according to the transaction processing logic corresponding to the state updated by the second service, so as to obtain the simulation execution result of the target sub-transaction;

[0009] Determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target sub-transaction, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0010] On the one hand, an embodiment of the present application provides a test device, and the device includes:

[0011] A determination unit, configured to determine test scenario information, where the test scenario information is used to indicate: the first service update state of the service device for executing the target main transaction, and the second service update state of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update state and the second service update state are respectively the service not updated state or the service updated state; the service device in the service not updated state is used to implement the target transaction according to the transaction processing logic before the update, and the service device in the service updated state is used to implement the target transaction according to the transaction processing logic after the update, and the transaction processing logic includes a main transaction processing logic and a sub-transaction processing logic;

[0012] A simulation unit, configured to simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update state according to the test scenario information, so as to obtain the simulation execution result of the target main transaction;

[0013] The simulation unit is further configured to simulate calling the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update state according to the simulation execution result of the target main transaction, so as to obtain the simulation execution result of the target sub-transaction;

[0014] A test unit, configured to determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target sub-transaction, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0015] On the one hand, an embodiment of the present application provides a computer device, including: a processor, a communication interface, and a memory, which are interconnected. Wherein, the memory stores executable program code, and the processor is configured to call the executable program code to implement the test method provided by the embodiment of the present application.

[0016] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored. When the instructions are run on a computer, the computer is enabled to implement the test method provided by the embodiment of the present application.

[0017] Correspondingly, an embodiment of the present application further provides a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device implements the test method provided by the embodiment of the present application.

[0018] Through the test method provided by the embodiments of the present application, it is possible to determine the test scenario information indicating the update status of the first service and the update status of the second service, which is beneficial to subsequent targeted testing based on the test scenario information and determining whether there are problems between the main transaction processing logic and the sub-transaction processing logic in the scenario corresponding to the test scenario information; it is possible to simulate calling the service device to execute the target main transaction according to the main transaction processing logic corresponding to the update status of the first service, and obtain the simulated execution result of the target main transaction. Since the update status of the first service can be the service not updated status or the service updated status, the main transaction processing logic corresponding to the update status of the first service can be the main transaction processing logic before the update or the main transaction processing logic after the update, so that it is possible to determine whether there are problems with the main transaction processing logic before or after the update based on the simulated execution result of the target main transaction; it is possible to simulate calling the service device to execute the target sub-transaction according to the simulated execution result of the target main transaction and the sub-transaction processing logic corresponding to the update status of the second service, and obtain the simulated execution result of the target sub-transaction. Since the update status of the second service can be the service not updated status or the service updated status, the sub-transaction processing logic corresponding to the update status of the second service can be the sub-transaction processing logic before the update or the sub-transaction processing logic after the update, so that it is possible to determine whether there are problems with the sub-transaction processing logic before or after the update based on the simulated execution result of the target sub-transaction; it is possible to determine the test result of the transaction processing logic for the target transaction based on the simulated execution result of the target sub-transaction. The test result can include one or more of a timing test result, a compatibility test result, and a coding test result, and can indicate whether there are abnormalities between the main transaction processing logic in different update states (i.e., before or after the update) and the sub-transaction processing logic in different update states; through the method provided by the present application, it is possible to test the transaction processing logic before the gray release, so that it is possible to detect in advance the abnormalities that may occur during the gray release, which is beneficial to resolving the detected abnormalities in advance, thereby effectively improving the stability of the service system. Description of the Drawings

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

[0020] Figure 1 Shows the execution process of a transaction;

[0021] Figure 2 Is a schematic diagram of the execution situation of a transaction provided by an embodiment of the present application;

[0022] Figure 3 It is a schematic diagram of the system architecture of a test system provided by an embodiment of the present application;

[0023] Figure 4 It is a schematic flowchart of a test method provided by an embodiment of the present application;

[0024] Figure 5 It is a schematic diagram of a service device call scenario provided by an embodiment of the present application;

[0025] Figure 6a It is a schematic diagram of the test scenario corresponding to the first test scenario information provided by an embodiment of the present application;

[0026] Figure 6b It is a schematic diagram of the test scenario corresponding to the second test scenario information provided by an embodiment of the present application;

[0027] Figure 6c It is a schematic diagram of the test scenario corresponding to the third test scenario information provided by an embodiment of the present application;

[0028] Figure 6d It is a schematic diagram of the test scenario corresponding to the fourth test scenario information provided by an embodiment of the present application;

[0029] Figure 7 It is a schematic flowchart of another test method provided by an embodiment of the present application;

[0030] Figure 8 It is a schematic diagram of a method for determining a target time provided by an embodiment of the present application;

[0031] Figure 9 It is a block diagram of the structure of a test device provided by an embodiment of the present application;

[0032] Figure 10 It is a block diagram of the structure of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0033] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0034] It should be noted that the descriptions such as "first" and "second" involved in the embodiments of the present application are only for descriptive purposes, and cannot be understood as indicating or implying their relative importance or implicitly specifying the quantity of the indicated technical features. Therefore, the technical features defined with "first" and "second" may explicitly or implicitly include at least one such feature.

[0035] A service system may include multiple different services. A service can be implemented by one or more service devices. For example, the login service can be implemented by one service device, and the query service can be jointly implemented by three service devices. A service may include transactions, and transactions are an effective means to ensure the consistency of background data. Transactions usually include main transactions and sub-transactions. The main transaction usually implements the main process to ensure the normal operation of the entire link process, while the sub-transaction is usually used to implement operations such as data verification. Please refer to Figure 1 , which shows the execution process of a transaction. Figure 1 In, the service device can determine the sub-transaction information before executing the main transaction, store the sub-transaction information in a transfer information packet (transfer_info), and send the transfer information packet to the calling device. The calling device can return a first reception confirmation message to the service device. The service device executes the main transaction according to the main transaction processing logic in this device. After the main transaction is completed, the service device submits a sub-transaction request to the calling device, and the calling device can return a second reception confirmation message to the service device. After receiving the sub-transaction request, the calling device sends a callback request containing the transfer information packet to the service device. The service device can process the callback request using a specific unified gateway interface and execute the sub-transaction according to the sub-transaction processing logic in this device according to the sub-transaction information in the transfer information packet.

[0036] When the main transaction and the sub-transaction in a transaction are completed by the same service device, Figure 1 the execution process shown can be normally realized. However, the main transaction and the sub-transaction in a transaction can be executed by the same service device or by multiple service devices, and there may be various different situations during the gray release process. Please refer to Figure 2 , which is a schematic diagram of a transaction execution situation provided by the embodiments of the present application. Figure 2There are a calling device, a service device A, and a service device B. These two service devices are used to implement the same service, that is, all three service devices can implement the main transaction and the subordinate transaction included in the service. During the gray release process, a possible device update situation is as follows: Service device A is a grayed device (that is, the transaction processing logic in service device A is the updated transaction processing logic (the transaction processing logic includes the main transaction processing logic and the subordinate transaction processing logic)), and service device B is a non-grayed device (that is, the transaction processing logic in service device B is the transaction processing logic before the update); when executing the main transaction and the subordinate transaction, the calling device can call service device A to execute the main transaction and call service device B to execute the subordinate transaction. Then, service device A will execute the main transaction according to the updated main transaction processing logic, and service device B will execute the subordinate transaction according to the pre-updated subordinate transaction processing logic. From the above Figure 1 It can be seen that there is a direct association between the main transaction and the subordinate transaction of the same transaction. If there is a timing problem between the updated main transaction processing logic and the pre-updated subordinate transaction processing logic, it will cause the transaction to not be executed normally, thereby resulting in service anomalies, reduced system stability, and seriously affecting the usage experience of the service.

[0037] Based on this, the embodiment of the present application provides a testing method that can determine test scenario information. The test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target subordinate transaction; the target main transaction and the target subordinate transaction are respectively the main transaction and the subordinate transaction of the target transaction; the first service update status and the second service update status are respectively the service non-update status or the service updated status; the service device in the service non-update status is used to implement the target transaction according to the pre-updated transaction processing logic, and the service device in the service updated status is used to implement the target transaction according to the updated transaction processing logic. The transaction processing logic includes the main transaction processing logic and the subordinate transaction processing logic; according to the test scenario information, simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction; simulate calling the second service device to execute the target subordinate transaction according to the simulated execution result of the target main transaction and the subordinate transaction processing logic corresponding to the second service update status, and obtain the simulated execution result of the target subordinate transaction; according to the simulated execution result of the target subordinate transaction, determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information. The test result includes one or more of a timing test result, a compatibility test result, and a coding test result. Through the method provided by the embodiment of the present application, testing can be performed according to the test scenario information to obtain the test result of the transaction processing logic, which is beneficial to early detection of possible anomalies during the gray release process, effectively improving the stability of the service system and enhancing the usage experience of the service.

[0038] The testing method provided by the embodiments of the present application can be applied to the field of artificial intelligence. Artificial Intelligence (AI) uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, and is a theory, method, technology, and application system that can perceive the environment, acquire knowledge, and use knowledge to obtain the best results. An artificial intelligence service can be implemented by multiple service devices. When updating the artificial intelligence service, the method of gray release can be used to improve the usage experience. Before performing gray release for the artificial intelligence service, the testing method provided by the embodiments of the present application can be used for testing processing to obtain a test result, which can indicate whether there is an abnormality in the transaction processing logic of the transaction in the artificial intelligence service under the test scenario corresponding to the test scenario information; if so, further adjustment can be made to ensure that no abnormality occurs during actual release, thereby ensuring the stability of the system and improving the usage experience.

[0039] The testing method provided by the embodiments of the present application can also be applied to the field of cloud computing. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computing devices, enabling various application systems to obtain computing power, storage space, and information services as needed. The cloud computing resource pool mainly includes: computing devices (virtualized machines, including operating systems), storage devices, and network devices. The testing method provided by the embodiments of the present application can be implemented based on cloud computing technology: before performing gray release, cloud computing technology can be used to determine test scenario information, and according to the test scenario information, simulate and call service devices to execute the target main transaction according to the main transaction processing logic corresponding to the first service update state to obtain the simulated execution result of the target main transaction, and simulate and call the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update state based on the simulated execution result of the target main transaction to obtain the simulated execution result of the target sub-transaction; the test result of the transaction processing logic for the target transaction under the test scenario indicated by the test scenario information can be determined according to the simulated execution result of the target sub-transaction, which is beneficial to detecting possible abnormalities in the gray release process in advance and effectively improving the stability of the service system.

[0040] Next, the architecture of the testing system provided by the embodiments of the present application will be introduced with reference to the accompanying drawings.

[0041] Please refer to Figure 3 , which is a schematic diagram of the system architecture of a testing system provided by the embodiments of the present application. The testing system includes a reporting device 301, a testing device 302, and a service device 303 ( Figure 3The middle service device 303 includes service device 1, service device 2, service device 3, …, service device N (N is an integer greater than 3). The test device 302 can perform data interaction with the reporting device 301 and the service device 303. Among them:

[0042] The reporting device 301 can generate update information and report the update information to the test device 302. The update information can be update information for a certain service. The reporting device 301 can be a handheld device with communication functions (such as a smart phone, a tablet computer), a computing device (such as a personal computer (Personal Computer, PC)), a vehicle-mounted terminal, an intelligent voice interaction device, a wearable device or other intelligent devices, etc., but is not limited thereto.

[0043] The test device 302 can receive the update information sent by the reporting device 301 and perform update processing on the corresponding service device according to the update information. For example: the update information is update information for the first service, and service device 1 and service device 2 in the service device 303 are used to implement the first service. Then the test device 302 can use the update information to perform update processing on service device 1 and service device 2, so that service device 1 and service device 2 use the updated processing logic to implement the first service. The test device 302 can also be used to call the service device to implement the main transaction and the sub-transaction in the same transaction. For example: service device 1 and service device 2 in the service device 303 are used to implement the first service, and the first service includes the first transaction. The test device 302 can call service device 1 to implement the main transaction in the first transaction and call service device 2 to implement the sub-transaction in the first transaction. When there is update information and the service targeted by the update information is implemented by multiple service devices, the test device 302 can also perform test processing to obtain a test result. The test device 302 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and big data and artificial intelligence platforms.

[0044] The service device 303 may include multiple service devices, which are used to respond to service requests from terminal devices and provide different services to terminal devices. The service devices in the service device 303 may provide different services or the same service. For example, in the service device 303, service device 1, service device 2, and service device 3 may provide the same service (assumed to be the first service), while service device N may provide a service different from that of service device 1. A service includes transactions, and the service device includes transaction processing logic corresponding to the transactions. The service device may execute corresponding transactions according to the transaction processing logic in this device. The transaction processing logic in the service device may be updated, and the service device may execute transactions according to the updated transaction processing logic. The service device 303 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms.

[0045] The working principle of the test system shown below will be elaborated in detail: Figure 3 as follows:

[0046] The reporting device 301 may send update information for the target transaction in the first service to the test device 302. Service device 1, service device 2, and service device 3 in the service device 303 can all provide the first service; before the gray release, the test device 302 can perform test processing: the test device 302 can determine test scenario information, which can be used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the transaction processing logic before the update, and the service device in the service updated status is used to implement the target transaction according to the transaction processing logic after the update. The transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic.

[0047] The test device 302 may, according to the test scenario information, simulate and invoke the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the update of the first service, and obtain the simulated execution result of the target main transaction; the test device 302 may also simulate and invoke the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the update of the second service based on the simulated execution result of the target main transaction, and obtain the simulated execution result of the target sub-transaction. The test device 302 may determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target sub-transaction. If the test result indicates no abnormality, the test device 302 may perform gray release on the service device 1, the service device 2, and the service device 3 according to the update information, so that the service device 1, the service device 2, and the service device 3 can provide the updated first service. If the test result indicates an abnormality, the test device 302 may generate an adjustment prompt message according to the test result and send the adjustment prompt message to the reporting device 301, so that the reporting device 301 may appropriately adjust the update information. Through the test method provided in the embodiments of the present application, testing may be performed according to the test scenario information to obtain the test result of the transaction processing logic, which is beneficial to early detection of possible abnormalities in the gray release process, effectively improves the stability of the service system, and is also beneficial to improving the user experience.

[0048] It can be understood that the schematic diagram of the architecture of the test system described in the embodiments of the present application is for more clearly explaining the test method in the embodiments of the present application, and does not constitute a limitation on the test method provided in the embodiments of the present application. For example, the test method provided in the embodiments of the present application may be executed not only by the test device 302, but also by other devices different from the test device 302 and capable of communicating with the reporting device 301 and the service device 303. As is known to those of ordinary skill in the art, Figure 3 the numbers of the reporting device 301, the test device 302, and the service device 303 in [[ ]] are merely illustrative. According to the needs of business implementation, devices with any number may be configured. And, with the evolution of the system architecture and the emergence of new business scenarios, the test method provided in the embodiments of the present application is equally applicable to similar technical problems.

[0049] It should be noted that the collection and processing of relevant data (such as: transaction processing logic, simulated execution results, etc.) in the present application should strictly comply with the requirements of relevant laws and regulations during actual application, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing behaviors within the scope of authorization of laws and regulations and the personal information subject.

[0050] Please refer to Figure 4 , Figure 4A flowchart showing the process of a testing method provided by an embodiment of the present application. The testing method can be implemented by the above-mentioned testing device 302 or other devices. The process of the testing method provided by the embodiment of the present application includes but is not limited to:

[0051] S401. Determine test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the transaction processing logic before the update, and the service device in the service updated status is used to implement the target transaction according to the transaction processing logic after the update, and the transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic.

[0052] In an embodiment of the present application, a service can be provided by multiple service devices. When the service needs to be updated, usually the processing logic in the service device is updated accordingly. To ensure the stability and user experience of the system, the method of gray release can be used to gradually update the processing logic in multiple service devices. For example, if three service devices provide the same service, the method of gray release can be used to first update the processing logic in one of the service devices, while the other two service devices maintain the original processing logic. After running for a period of time, if no abnormal situation occurs, the processing logic in the remaining two service devices can be continued to be updated. The service includes transactions, and the transactions include main transactions and sub-transactions. When multiple service devices provide the same service, the service device for executing the main transaction and the device for executing the sub-transaction can be different, as shown above Figure 2 shown.

[0053] During the gray release process, the service update status of different service devices may be different. Therefore, there may be a situation where the service update status of the service device for executing the main transaction is different from the service update status of the service device for executing the sub-transaction; at this time, if there is an abnormality between the transaction execution logics before and after the update, it will cause the service device to be unable to provide services normally, thereby affecting the stability of the system. The testing method provided by the embodiment of the present application can be used to perform test processing on possible situations before actual gray release to obtain test results, so as to determine whether there is an abnormality between the transaction execution logics before and after the update, and problems can be detected in advance, thereby reducing resource losses and improving system stability.

[0054] After determining the update information for a target transaction (the target transaction includes a target main transaction and a target sub - transaction), the test device may first determine test scenario information. This test scenario information can be used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub - transaction. For example, the test scenario information can be the service not - updated status, the service updated status, that is, the service update status of the service device for executing the target main transaction is the service not - updated status, and the service update status of the service device for executing the target sub - transaction is the service updated status. The service device in the service not - updated status can implement the target transaction according to the pre - update transaction processing logic, while the service device in the service updated status can implement the target transaction according to the post - update transaction processing logic. This transaction processing logic can include the main transaction processing logic and the sub - transaction processing logic. The post - update transaction processing logic can be obtained by adjusting the pre - update transaction processing logic according to the update information for the target transaction. Through the method provided by the embodiments of the present application, the test scenario information can be determined, which is beneficial to subsequent targeted test processing based on the test scenario information to obtain accurate test results.

[0055] It should be noted that the update information for the target transaction may include the update content and update strategy of the transaction processing logic. The update content can be used to indicate the specific update data for the transaction processing logic. For example: the update data of the main transaction processing logic, the update data of the sub - transaction processing logic, etc.; the update strategy can be used to indicate the update strategy for the transaction processing logic. For example: the main transaction processing logic and the sub - transaction processing logic are updated simultaneously, or for another example: first update the main transaction processing logic, wait for a period of time, and then update the sub - transaction processing logic. In the method provided by the embodiments of the present application, the test device can simulate the update of the corresponding transaction processing logic according to the update information and conduct targeted tests for the possible scenarios after the update to obtain test results, thereby effectively ensuring the correctness and effectiveness of the update information, avoiding anomalies during the actual update process and causing losses, and also effectively ensuring the stability of the system.

[0056] S402. According to the test scenario information, simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction.

[0057] In the embodiments of the present application, after determining the test scenario information, the test device may, according to the test scenario information, simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction. The simulated execution result of the target main transaction may include the data required to implement the target sub-transaction. For example, if the target main transaction is to obtain the input login information and the sub-transaction is to store the login information in the login information database, then the simulated execution result of the target main transaction may include the obtained login information at this time. The first service update status may be the service updated status or the service not updated status. When the first service update status is the service updated status, the test device may simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the service updated status, that is, simulate and call the first service device to execute the target main transaction according to the updated main transaction processing logic, and obtain the simulated execution result of the target main transaction. When the first service update status is the service not updated status, the test device may simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the service not updated status, that is, simulate and call the first service device to execute the target main transaction according to the main transaction processing logic before the update, and obtain the simulated execution result of the target main transaction. Through the method provided by the embodiments of the present application, it is possible to simulate the execution of the target main transaction and obtain the simulated execution result of the target main transaction, which is beneficial to subsequently executing the sub-transaction according to the simulated execution result of the target main transaction and obtaining an accurate test result.

[0058] In one embodiment, the simulated execution result of the target main transaction may also indicate whether the target main transaction is executed normally: If the first service update status is the service updated status, the test device may simulate and call the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the service updated status (i.e., the updated main transaction processing logic), and obtain the simulated execution result of the target main transaction. Assuming that there is an abnormality in the updated main transaction processing logic (for example: processing logic error, coding problem, etc.), there may also be an abnormality in the simulated execution result of the target main transaction. It is possible to determine whether there is an abnormality in the updated main transaction processing logic according to the simulated execution result of the target main transaction. Through the method provided by the embodiments of the present application, it is possible to perform abnormality determination through the simulated execution result of the target main transaction, realize the abnormality detection of the main transaction processing logic, thereby avoiding losses caused by system abnormalities after actual update, effectively ensuring the stability of the system, and reducing resource losses.

[0059] S403. Simulate and call the second service device to execute the target sub-transaction according to the simulated execution result of the target main transaction and according to the sub-transaction processing logic corresponding to the second service update status, and obtain the simulated execution result of the target sub-transaction.

[0060] In the embodiments of the present application, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the updated state of the second service based on the simulated execution result of the target main transaction, and obtain the simulated execution result of the target sub-transaction. The simulated execution result of the target sub-transaction may be used to indicate whether there is an abnormality in the execution of the sub-transaction. The second service device may be the same device as the first service device or a different device from the first service device.

[0061] The updated state of the second service may be the service updated state or the service not updated state. When the updated state of the second service is the service updated state, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the service updated state, that is, simulate and call the second service device to execute the target sub-transaction according to the updated transaction processing logic, and obtain the simulated execution result of the target sub-transaction. When the updated state of the second service is the service not updated state, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the service not updated state, that is, simulate and call the second service device to execute the target sub-transaction according to the pre-updated transaction processing logic, and obtain the simulated execution result of the target sub-transaction. Through the method provided in the embodiments of the present application, it is possible to simulate the execution of the target sub-transaction and obtain the simulated execution result of the target sub-transaction, which is beneficial to determining an accurate test result based on the simulated execution result of the target sub-transaction subsequently, thereby realizing anomaly detection and further improving the stability of the system.

[0062] It should be noted that the simulated execution result of the target sub-transaction may be used to indicate whether there is an abnormality in the execution of the target sub-transaction, or may include the execution result data of the target sub-transaction. When the simulated execution result of the target sub-transaction includes the execution result data of the target sub-transaction, the simulated execution result of the target sub-transaction may be evaluated, and whether there is an abnormality in the execution of the target sub-transaction may be determined according to the evaluation result.

[0063] In one embodiment, the updated main transaction processing logic is used to indicate the generation of new vector data and add the new vector data to the execution result of the main transaction. The updated subordinate transaction processing logic is used to indicate processing using the new vector data. The implementation manner of simulating a call to the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status to obtain the simulated execution result of the target main transaction may be as follows: If the first service update status is the service not updated status, then simulate a call to the first service device to execute the target main transaction according to the pre-update main transaction processing logic corresponding to the service not updated status, and obtain the simulated execution result of the target main transaction that does not include the new vector data. The implementation manner of simulating a call to the second service device to execute the target subordinate transaction according to the simulated execution result of the target main transaction according to the subordinate transaction processing logic corresponding to the second service update status to obtain the simulated execution result of the target subordinate transaction may be as follows: If the second service update status is the service updated status, then simulate a call to the second service device to execute the target subordinate transaction according to the post-update subordinate transaction processing logic corresponding to the service updated status based on the simulated execution result that does not include the new vector data, and obtain the simulated execution result indicating that the execution of the target subordinate transaction is abnormal.

[0064] Suppose in a possible situation, the updated main transaction processing logic is used to indicate the generation of new vector data and add the new vector data to the execution result of the main transaction, while the pre-update main transaction processing logic does not indicate the completion of this operation. The updated subordinate transaction processing logic is used to indicate processing using the new vector data, while the pre-update subordinate transaction processing logic does not indicate the completion of this operation. At this time, if the first service update status is the service not updated status, the test device can simulate a call to the first service device to execute the target main transaction according to the pre-update main transaction processing logic, and obtain the simulated execution result of the target main transaction that does not include the newly implemented data. If the second service update status is the service updated status, the test device can simulate a call to the second service device to execute the target subordinate transaction according to the simulated execution result that does not include the new vector data according to the post-update subordinate transaction execution logic. At this time, since the post-update subordinate transaction execution logic indicates processing using the new vector data, and the simulated execution result of the main transaction does not include the new vector data, a data acquisition exception will occur, which will further cause the failure of the subordinate transaction execution, that is, obtain the simulated execution result indicating that the execution of the target subordinate transaction is abnormal, and this simulated execution result can indicate a timing problem. Through the method provided by the embodiments of the present application, the main transaction processing logic and the subordinate transaction processing logic before and after the update can be tested, which is convenient for obtaining accurate test results subsequently, and thus is beneficial to avoiding abnormalities during the gray release process and improving the stability of the system.

[0065] Please refer to Figure 5 , which is a schematic diagram of a service device call scenario provided by the embodiments of the present application.Figure 5 A test scenario simulated by a test device, which includes two service devices (i.e., Figure 5 service device 1 and service device 2 in the figure), and these two service devices are used to provide the same service. The service update status of service device 1 is the service not updated status, and the service update status of service device 2 is the service updated status. The service provided by these two service devices includes a target transaction, and the target transaction includes a target main transaction and a target sub-transaction. The updated main transaction processing logic is used to indicate generating new vector data (denoted as update_vector) and adding the new vector data to the execution result of the main transaction (denoted as transfer_info); the updated sub-transaction processing logic is used to indicate processing using the new vector data.

[0066] Assume that the first service update status indicated by the test scenario information is the service not updated status, the second service update status is the service updated status, the first service device is service device 1, and the second service device is service device 2. It is possible to simulate calling service device 1 to execute the target main transaction according to the main transaction processing logic before the update, and obtain the simulated execution result of the target main transaction without the new vector data (denoted as transfer_info), that is, transfer_info does not include the new vector data (i.e., update_vector); it is possible to simulate calling service device 2 to execute the target sub-transaction according to the updated sub-transaction processing logic. However, since transfer_info does not include update_vector, an exception will occur in the execution of the target sub-transaction, that is, the simulated execution result of the target sub-transaction indicating an execution exception is obtained. This exception is caused by the timing relationship between the transaction processing logics before and after the update, rather than a problem with the transaction processing logic itself. If such problems occur during the gray release process, it will lead to difficulties in exception troubleshooting and the inability to achieve gray release normally. Through the method provided by the embodiments of the present application, it is possible to test the transaction processing logics before and after the update before the gray release, thereby effectively avoiding exceptions during the actual gray release, effectively improving the efficiency of the gray release, and reducing the resource losses caused by the exceptions.

[0067] S404. Determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target sub-transaction. The test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0068] In the embodiments of the present application, the test device may determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target subordinate transaction. For example, if the test scenario information indicates that the update status of the first service is the service updated status and the update status of the second service is the service not updated status, the corresponding test scenario may be determined according to the test scenario information, that is, the target main transaction is executed according to the updated main transaction processing logic, and the target subordinate transaction is executed according to the pre-updated subordinate transaction processing logic to obtain the simulation execution result of the target subordinate transaction. The test result may be determined according to the simulation execution result of the target subordinate transaction. The test result may indicate whether there is an abnormality in the transaction processing logic of the target transaction in the test scenario indicated by the test scenario information. The test result may include one or more of a timing test result, a compatibility test result, and a coding test result. If there is a mismatch between the pre-updated main transaction processing logic and the post-updated subordinate transaction processing logic, the test result may include a timing test result, and the timing test result indicates that the test fails; if there is a mismatch between the post-updated main transaction processing logic and the pre-updated subordinate transaction processing logic, the test result may include a compatibility test result, and the compatibility test result indicates that the test fails; if there is a coding error in the post-updated main transaction processing logic or the post-updated subordinate transaction processing logic itself, the test result may include a coding test result, and the coding test result indicates that the test fails. Through the method provided by the embodiments of the present application, it is possible to determine whether there is an abnormality in the transaction processing logic in the test scenario corresponding to the test scenario information, implement the test between the main transaction processing logic and the subordinate transaction processing logic, effectively avoid problems during actual gray release, effectively ensure the stability of the system, and reduce the resource loss that may be caused by problems.

[0069] In one embodiment, the implementation manner of determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target subordinate transaction may be: determining a reference test result indicating that the test fails according to the simulation execution result indicating that the target subordinate transaction execution is abnormal; determining the reference test result as the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information. If the simulation execution result of the target subordinate transaction is a simulation execution result indicating that the target subordinate transaction execution is abnormal, a reference test result indicating that the test fails may be determined; the reference test result may be determined as the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information. Through the method provided by the embodiments of the present application, the test result for the transaction processing logic can be accurately determined, which is beneficial to accurately identifying potential problems and improving the stability of the system.

[0070] In one embodiment, the updated main transaction processing logic is determined according to the main transaction update information, and the updated sub-transaction processing logic is determined according to the sub-transaction update information. The test method provided by this application may further: according to the test results, use the main transaction update information to update the main transaction processing logic of multiple service devices, so that the multiple service devices all execute the target main transaction according to the updated main transaction processing logic; after the main transaction processing logic of each service device among the multiple service devices is updated, use the sub-transaction update information to update the sub-transaction processing logic of the multiple service devices, so that the multiple service devices all execute the target sub-transaction according to the updated sub-transaction processing logic. The main transaction update information includes the update content of the main transaction processing logic, and the sub-transaction update information includes the update content of the sub-transaction processing logic. If the test results include timing test results, and the timing test results indicate that the test fails in the test scenario corresponding to the test scenario information, and the test scenario information indicates that the first service update status is the service not updated status and the second service update status is the service updated status, it means that there is a timing problem between the pre-update main transaction processing logic corresponding to the service not updated status and the post-update main transaction processing logic corresponding to the service updated status. Then, the method provided by the embodiments of this application can be used to update the main transaction processing logic of multiple service devices by using the main transaction update information, so that the multiple service devices all execute the target main transaction according to the updated main transaction processing logic. These multiple service devices are all used to execute the target transaction.

[0071] After the main transaction processing logic of each service device among the multiple service devices is updated, the sub-transaction update information can be used to update the sub-transaction processing logic of the multiple service devices, so that the multiple service devices all execute the target sub-transaction according to the updated sub-transaction processing logic. Since there is a timing problem between the pre-update main transaction processing logic and the post-update sub-transaction processing logic, the method provided by the embodiments of this application can be used to update all the main transaction processing logics of the multiple service devices and then update the sub-transaction processing logics of the multiple service devices, so that during the actual transaction execution process, the situation of using the pre-update main transaction processing logic to execute the target main transaction and using the post-update sub-transaction processing logic to execute the target sub-transaction will not occur, and thus anomalies can be avoided. Through the method provided by the embodiments of this application, anomalies during the gray release process can be effectively avoided, the stability of the system is ensured, the user experience is improved, and resource consumption is also reduced.

[0072] It should be noted that the method described in the above embodiments is only a feasible implementation manner, and this method mainly targets the situation where the test scenario information indicates that the update status of the first service is the service not updated status, the update status of the second service is the service updated status, and the test result includes the timing test result indicating that the test fails. For this situation, the main transaction update information and the sub-transaction update information can be adjusted to avoid the mismatch between the main transaction processing logic before the update and the sub-transaction processing logic after the update. For this situation, the update information related to the exception in the sub-transaction update information can also be "commented" so that the update information related to the exception cannot indicate the corresponding operation. The transaction processing logic of multiple service devices is updated using the main transaction update information and the "commented" sub-transaction update information; when the transaction processing logic of multiple service devices is updated and there is no exception, the update information related to the exception in the sub-transaction update information is "uncommented" so that the update information related to the exception can indicate the corresponding operation again, and the transaction processing logic of multiple service devices is updated using the "uncommented" sub-transaction update information, thereby avoiding exceptions. In the actual application process, different methods can be determined according to different application scenarios and test scenario information. The method provided in the embodiments of this application can determine the test results corresponding to different test scenario information, which is beneficial to achieving comprehensive testing, avoiding various possible problems, improving the stability of the system, and reducing the resource consumption caused by exception handling during the actual release process.

[0073] In one embodiment, the test scenario information includes the first test scenario information, the second test scenario information, the third test scenario information, and the fourth test scenario information. The update status of the first service and the update status of the second service indicated by the first test scenario information are both the service updated status; the update status of the first service and the update status of the second service indicated by the second test scenario information are both the service not updated status; the update status of the first service and the update status of the second service indicated by the third test scenario information are respectively the service updated status and the service not updated status; the update status of the first service and the update status of the second service indicated by the fourth test scenario information are respectively the service not updated status and the service updated status. Then, according to the simulated execution result of the target sub-transaction, the implementation manner of determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information can be: according to the simulated execution results of the target sub-transaction corresponding to the first test scenario information, the second test scenario information, the third test scenario information, and the fourth test scenario information respectively, determine the first test result, the second test result, the third test result, and the fourth test result of the transaction processing logic for the target transaction in the test scenario indicated by the corresponding test scenario information.

[0074] The test scenario information may include first test scenario information, second test scenario information, third test scenario information, and fourth test scenario information. These four types of test scenario information may correspond to four scenarios that may occur during the gray release process: the first test scenario information corresponds to the first test scenario (the scenario of the updated main transaction processing logic and the updated subordinate transaction processing logic), the second test scenario information corresponds to the second test scenario (the scenario of the unupdated main transaction processing logic and the unupdated subordinate transaction processing logic), the third test scenario information corresponds to the third test scenario (the scenario of the updated main transaction processing logic and the unupdated subordinate transaction processing logic), and the fourth test scenario information corresponds to the fourth test scenario (the scenario of the unupdated main transaction processing logic and the updated subordinate transaction processing logic). For these four different types of test scenario information, the test device may perform test processing respectively to obtain the first test result, second test result, third test result, and fourth test result of the transaction processing logic for the target transaction under the test scenario indicated by the corresponding test scenario information. Through the method provided by the embodiments of the present application, the test results under various possible test scenarios can be determined, so as to achieve comprehensive testing, effectively ensuring the stability and correctness of the gray release process.

[0075] In one embodiment, the test method provided by the present application may further: determine the scenario test result of the transaction processing logic for the target transaction according to the first test result, second test result, third test result, and fourth test result. The scenario test result is used to indicate whether there is an abnormality in the transaction processing logic for the target transaction under each test scenario. After determining the test results corresponding to the four possible test scenarios, the scenario test result of the transaction processing logic for the target transaction can be determined according to these four test results. The scenario test result can be used to indicate whether there is an abnormality in the transaction processing logic for the target transaction under each test scenario. Through the method provided by the embodiments of the present application, comprehensive testing of the transaction processing logic for the target transaction can be achieved, and the scenario test result can be obtained, which is beneficial to comprehensively avoiding problems that may occur during the gray release process, improving the efficiency of the gray release, and reducing resource consumption.

[0076] A service device with a service update status of service updated status can be called a grayed device, and a service device with a service update status of service unupdated status can be called a non-grayed device. A transaction includes a main transaction and a subordinate transaction. The main transaction and the subordinate transaction can be used for the same service device to execute, or can be executed by different service devices respectively. Please refer to Figure 6a, this figure is a schematic diagram of the test scenario corresponding to the first test scenario information provided by the embodiments of the present application. This test scenario includes 5 service devices (service devices 1 - 5 respectively), among which, service device 1 and service device 2 are devices with gray scale enabled, and service devices 3 - 5 are devices without gray scale enabled. Both the first service update status and the second service update status indicated by the first test scenario information are service updated statuses, that is Figure 6a in the test device, from the devices that can execute the main transaction (service devices 1 - 5 can all execute), it simulates calling service device 1 to execute the main transaction according to the updated main transaction processing logic, and obtains the simulated execution result of the main transaction; from the devices that can execute the sub - transaction (service devices 1 - 5 can all execute), it simulates calling service device 2 to execute the sub - transaction according to the updated sub - transaction processing logic, and obtains the simulated execution result of the sub - transaction, and determines the first test result based on the simulated execution result of the sub - transaction.

[0077] Please refer to Figure 6b , this figure is a schematic diagram of the test scenario corresponding to the second test scenario information provided by the embodiments of the present application. This test scenario includes 5 service devices (service devices 1 - 5 respectively), among which, service device 1 and service device 2 are devices with gray scale enabled, and service devices 3 - 5 are devices without gray scale enabled. Both the first service update status and the second service update status indicated by the first test scenario information are service non - updated statuses, that is Figure 6b in the test device, from the devices that can execute the main transaction (service devices 1 - 5 can all execute), it simulates calling service device 4 to execute the main transaction according to the pre - updated main transaction processing logic, and obtains the simulated execution result of the main transaction; from the devices that can execute the sub - transaction (service devices 1 - 5 can all execute), it simulates calling service device 3 to execute the sub - transaction according to the pre - updated sub - transaction processing logic, and obtains the simulated execution result of the sub - transaction, and determines the second test result based on the simulated execution result of the sub - transaction.

[0078] Please refer to Figure 6c , this figure is a schematic diagram of the test scenario corresponding to the third test scenario information provided by the embodiments of the present application. This test scenario includes 5 service devices (service devices 1 - 5 respectively), among which, service device 1 and service device 2 are devices with gray scale enabled, and service devices 3 - 5 are devices without gray scale enabled. The first service update status and the second service update status indicated by the first test scenario information are service updated status and service non - updated status respectively, that is Figure 6cThe test device simulates calling Service Device 1 from the devices that can execute the main transaction (Service Devices 1-5 can all execute) to execute the main transaction according to the updated main transaction processing logic, and obtains the simulated execution result of the main transaction; the test device simulates calling Service Device 3 from the devices that can execute the sub-transaction (Service Devices 1-5 can all execute) to execute the sub-transaction according to the pre-updated sub-transaction processing logic, obtains the simulated execution result of the sub-transaction, and determines the third test result based on the simulated execution result of the sub-transaction.

[0079] Please refer to Figure 6d , which is a schematic diagram of the test scenario corresponding to the fourth test scenario information provided in the embodiment of the present application. This test scenario includes 5 service devices (Service Devices 1-5 respectively), among which, Service Device 1 and Service Device 2 are devices that have been in gray scale, and Service Devices 3-Service Device 5 are devices that have not been in gray scale. The first service update status and the second service update status indicated by the first test scenario information are the service not updated status and the service updated status respectively, that is Figure 6d The test device simulates calling Service Device 4 from the devices that can execute the main transaction (Service Devices 1-5 can all execute) to execute the main transaction according to the pre-updated main transaction processing logic, and obtains the simulated execution result of the main transaction; the test device simulates calling Service Device 1 from the devices that can execute the sub-transaction (Service Devices 1-5 can all execute) to execute the sub-transaction according to the updated sub-transaction processing logic, obtains the simulated execution result of the sub-transaction, and determines the fourth test result based on the simulated execution result of the sub-transaction.

[0080] The test device can perform the above Figure 6a , Figure 6b , Figure 6c and Figure 6d shown test processes respectively according to the first test scenario information, the second test scenario information, the third test scenario information and the fourth test scenario information, and obtains the simulated execution results of the sub-transaction corresponding to these four test scenario information respectively; and can determine the first test result, the second test result, the third test result and the fourth test result of the sub-transaction processing logic for the sub-transaction under the test scenario indicated by the corresponding test scenario information according to the simulated execution results of the sub-transaction corresponding to the four test scenario information respectively. The test device can determine the scenario test result of the sub-transaction processing logic for the sub-transaction according to the first test result, the second test result, the third test result and the fourth test result, and the scenario test result is used to indicate whether there is an abnormality in the sub-transaction processing logic for the sub-transaction under each test scenario. For example: Suppose Figure 6a , Figure 6b , Figure 6c respectively corresponding first test result, second test result and third test result all indicate that the transaction is executed normally, while Figure 6dThe corresponding fourth test result includes a timing test result. If the timing test result indicates that the test fails, the scenario test result indicating abnormal transaction execution can be determined, and the scenario test result indicates that there is an abnormality. Through the method provided in the embodiments of the present application, the test results of the transaction processing logic in each test scenario can be determined, realizing comprehensive testing of the transaction processing logic, facilitating comprehensive investigation of potential problems, effectively avoiding abnormalities during the actual gray release process, improving the gray release efficiency, and reducing resource losses caused by abnormalities.

[0081] In one embodiment, the method provided in the embodiments of the present application can further: generate an adjustment prompt message according to the test result and send the adjustment prompt message to the management object. The adjustment prompt message is used to instruct the management object to adjust the transaction processing logic of the target transaction. If the test result indicates that the test fails, the test device can generate an adjustment prompt message according to the test result and send the adjustment prompt message to the management object, so that the management object adjusts the transaction processing logic of the target transaction. Through the method provided in the embodiments of the present application, rapid processing of abnormalities can be achieved, which is beneficial to improving the processing efficiency.

[0082] Through the test method provided in the embodiments of the present application, multiple different test scenario information can be determined, which is beneficial to using the test scenario information for test processing and comprehensively investigating potential problems; before the gray release, the test device can be simulated and called according to the test scenario information for targeted testing to obtain accurate test results, so that possible abnormalities can be determined, which is beneficial to improving the efficiency and accuracy of the gray release, avoiding abnormalities and resource losses during the gray release process, and effectively ensuring the stability of the system at the same time; corresponding adjustments can be made to the update process of the transaction processing logic according to the test results, so as to ensure the normal execution of the gray release process subsequently, and thus effectively improve the user experience during the gray release process.

[0083] Please refer to Figure 7 , Figure 7 which is a schematic flowchart of another test method provided in the embodiments of the present application. This test method can be implemented by the above test device 302 or by other devices. The process of the test method provided in the embodiments of the present application includes but is not limited to:

[0084] S701. Determine the test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the transaction processing logic before the update, and the service device in the service updated status is used to implement the target transaction according to the transaction processing logic after the update, and the transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic.

[0085] In the embodiments of the present application, a service can be provided by multiple service devices. When the service needs to be updated, usually the processing logic in the service device is updated accordingly. To ensure the stability of the system and the user experience, the method of gray release can be adopted to gradually update the processing logic in multiple service devices. The service includes transactions, and the transactions include main transactions and sub-transactions. When multiple service devices provide the same service, the service devices for executing the main transaction and the service devices for executing the sub-transaction can be different, as shown above Figure 2 shown. During the gray release process, the service update statuses of different service devices may be different. Therefore, there may be a situation where the service update status of the service device for executing the main transaction is different from the service update status of the service device for executing the sub-transaction. At this time, if there is an abnormality between the transaction execution logics before and after the update, it will cause the service device to be unable to provide services normally, thereby affecting the stability of the system. The test method provided in the embodiments of the present application can be used to perform test processing on possible situations before the actual gray release, obtain the test results, so as to determine whether there is an abnormality between the transaction execution logics before and after the update, and can detect problems in advance, thereby reducing resource losses and improving system stability.

[0086] After determining the update information for a target transaction (the target transaction includes a target main transaction and a target sub - transaction), the test device may first determine test scenario information, which can be used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub - transaction. A service device in the service not - updated state may implement the target transaction according to the pre - update transaction processing logic, while a service device in the service updated state may implement the target transaction according to the post - update transaction processing logic, and the transaction processing logic may include a main transaction processing logic and a sub - transaction processing logic. The post - update transaction processing logic may be obtained by adjusting the pre - update transaction processing logic according to the update information for the target transaction. Through the method provided by the embodiments of the present application, test scenario information can be determined, which is beneficial to subsequent targeted test processing according to the test scenario information to obtain accurate test results.

[0087] S702. According to the test scenario information, simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction.

[0088] In the embodiments of the present application, after determining the test scenario information, the test device may, according to the test scenario information, simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction. The simulated execution result of the target main transaction may include the data required to implement the target sub - transaction. The first service update status may be the service updated state or the service not - updated state. When the first service update status is the service updated state, the test device may simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the service updated state, that is, simulate calling the first service device to execute the target main transaction according to the post - update main transaction processing logic, and obtain the simulated execution result of the target main transaction. When the first service update status is the service not - updated state, the test device may simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the service not - updated state, that is, simulate calling the first service device to execute the target main transaction according to the pre - update main transaction processing logic, and obtain the simulated execution result of the target main transaction. Through the method provided by the embodiments of the present application, the simulation execution of the target main transaction can be realized, and the simulated execution result of the target main transaction can be obtained, which is beneficial to subsequent execution of the sub - transaction according to the simulated execution result of the target main transaction to obtain accurate test results.

[0089] S703. Simulate calling the second service device to execute the target sub - transaction according to the simulated execution result of the target main transaction and according to the sub - transaction processing logic corresponding to the second service update status, and obtain the simulated execution result of the target sub - transaction.

[0090] In the embodiments of the present application, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the updated state of the second service based on the simulated execution result of the target main transaction, and obtain the simulated execution result of the target sub-transaction. The simulated execution result of the target sub-transaction may be used to indicate whether there is an abnormality in the execution of the sub-transaction. The second service device may be the same device as the first service device or a different device from the first service device.

[0091] The updated state of the second service may be the service updated state or the service not updated state. When the updated state of the second service is the service updated state, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the service updated state, that is, simulate and call the second service device to execute the target sub-transaction according to the updated transaction processing logic, and obtain the simulated execution result of the target sub-transaction. When the updated state of the second service is the service not updated state, the test device may simulate and call the second service device to execute the target sub-transaction according to the transaction processing logic corresponding to the service not updated state, that is, simulate and call the second service device to execute the target sub-transaction according to the pre-updated transaction processing logic, and obtain the simulated execution result of the target sub-transaction. Through the method provided by the embodiments of the present application, it is possible to simulate the execution of the target sub-transaction and obtain the simulated execution result of the target sub-transaction, which is beneficial to determining an accurate test result based on the simulated execution result of the target sub-transaction in the subsequent process, thereby realizing abnormality troubleshooting and further improving the stability of the system.

[0092] S704. Determine a test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target sub-transaction, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0093] In the embodiments of the present application, the test device may determine, according to the simulation execution result of the target subordinate transaction, the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information. For example, if the test scenario information indicates that the update status of the first service is the service updated status and the update status of the second service is the service not updated status, the corresponding test scenario may be determined according to the test scenario information, that is, the target main transaction is executed according to the updated main transaction processing logic, and the target subordinate transaction is executed according to the pre-updated subordinate transaction processing logic to obtain the simulation execution result of the target subordinate transaction. The test result may be determined according to the simulation execution result of the target subordinate transaction. The test result may indicate whether there is an abnormality in the transaction processing logic of the target transaction in the test scenario indicated by the test scenario information. The test result may include one or more of a timing test result, a compatibility test result, and a coding test result. Through the method provided by the embodiments of the present application, it is possible to determine whether there is an abnormality in the transaction processing logic in the test scenario corresponding to the test scenario information, realizing the abnormality detection between the main transaction processing logic and the subordinate transaction processing logic, effectively avoiding problems during actual gray release, effectively ensuring the stability of the system, and reducing the resource loss that may be caused by abnormalities.

[0094] S705. Generate test result prompt information according to the test result, and send the test result prompt information to the management object.

[0095] In the embodiments of the present application, the test device may generate test result prompt information according to the test result. The test result prompt information may include the test scenario information and the test result corresponding to the test scenario information. When the test result indicates that the test fails, the test result prompt information may further include modification prompt information, which is used to instruct the management object to modify the transaction processing logic of the target transaction or modify the update information of the target transaction. The test device may send the test result prompt information to the management object so that the management object can perform corresponding operations. Through the method provided by the embodiments of the present application, the functions of abnormal testing and information prompting can be realized, effectively avoiding abnormalities during the actual gray release process, improving the efficiency of gray release, and effectively saving resources.

[0096] In one embodiment, there are multiple services, each service provided by one or more service devices. During the gray release process, the process of updating a service is called an update task. When there are multiple services to be updated, there are multiple update tasks to be executed. For example, there are three services, namely the first service, the second service, and the third service. Among them, the first service is provided by service device 1, the second service is provided by service device 2, and the third service is provided by service device 3 and service device 4. Now, it is necessary to update these three services (updating a service means updating the transaction processing logic in the corresponding service device). Then, there are three update tasks. The first update task instructs to update the transaction processing logic in service device 1 according to the first service update information; the second update task instructs to update the transaction processing logic in service device 2 according to the second service update information; the third update task instructs to update the transaction processing logic in service device 3 and service device 4 respectively according to the third service update information.

[0097] When there are multiple update tasks to be executed, it is necessary to predict the release completion time of these multiple update tasks to be executed. Then, the method provided in the embodiments of the present application can be adopted: determine the first release time, determine the minimum task executable time from the update task mapping table. The update task mapping table includes multiple update task identifiers and the associated information of each update task identifier. The associated information includes the task execution quantity, the task executable time, and the remaining task quantity. Among the multiple update task identifiers, there is an identifier of the update task for the service corresponding to the target transaction; if the minimum task executable time is greater than the first release time, then update the first release time according to the minimum task executable time to obtain the second release time; perform a query process on the update task mapping table based on the second release time to obtain the target index information, and update the task executable time and the remaining task quantity corresponding to the target update task identifier. The target update task identifier is the update task identifier corresponding to the target index information in the update task mapping table; if the remaining task quantities included in the update task mapping table are all less than or equal to the quantity threshold, then determine the target time according to the second release time. The target time is used to indicate the time required for the release completion of the update tasks corresponding to all the update task identifiers in the update task mapping table.

[0098] The update task mapping table is constructed according to the relevant information of the update tasks to be executed. The relevant information of the update tasks can include the update task identifier (denoted as taskid), the device information (denoted as machine_info), the change code (denoted as code), and the consumption time (denoted as cost_time). The update task mapping table constructed according to the relevant information of a type of update task can be as shown in Table 1 below.

[0099] Table 1:

[0100] id freq nextValid rest A 6 1 6 B 1 1 1 C 1 1 1 D 1 1 1 E 1 1 1 F 1 1 1 G 1 1 1

[0101] As shown in Table 1, the update task mapping table may include multiple update task identifiers (i.e., the ids in the table) and the associated information of each update task identifier. The associated information includes the task execution quantity (i.e., freq in the table, used to indicate how many service devices the update task needs to be published on in total), the task executable time (i.e., nextValid in the table, used to indicate the time for the next execution of the update task), and the remaining task quantity (i.e., rest in the table, used to indicate how many service devices the update task still needs to be published on). Among the multiple update task identifiers, there may be an identifier of the update task for the service corresponding to the target transaction. The update task mapping table shown in Table 1 includes 7 update tasks (the ids are A - G respectively). Among them, for update task A, the task execution quantity is 6, the task executable time is 1, and the remaining task quantity is 6, which means that the update task A needs to be published on 6 service devices in total (i.e., the transaction processing logic of 6 service devices needs to be updated). Executing update task A once is equivalent to publishing on one service device; the next time update task A can be executed is 1, and the update task A still needs to be published on 6 service devices.

[0102] The first release time can be determined. The initial value of the first release time can be 0. During the algorithm implementation process, the first release time can be equal to the first release time + 1. The minimum task executable time can be determined from the updated task mapping table. Taking Table 1 above as an example, the minimum task executable time can be determined to be 1. If the minimum task executable time is greater than the first release time, the first release time can be updated according to the minimum task executable time to obtain the second release time. If the minimum task executable time is less than or equal to the first release time, the second release time can be determined according to the first release time, that is, the value of the second release time (Time2) is equal to the maximum value of the first release time (Time1) and the minimum task executable time (minNextValid), which can be expressed as Time2 = max(Time1, minNextValid). For example: if the first release time is 1 and the minimum task executable time is 1, the second release time can be determined to be 1. If the first release time is 2 and the minimum task executable time is 2, the second release time can be determined to be 2. After determining the second release time, the updated task mapping table can be queried based on the second release time to obtain the target index information. The target update task identifier is the update task identifier corresponding to the target index information in the updated task mapping table. The task executable time and the remaining number of tasks corresponding to the target update task identifier can be updated; that is, after determining the second release time, the update task that can be released currently (the update task corresponding to the target update task identifier) can be determined from the updated task mapping table. After simulating the release of this update task, the data in the updated task mapping table can be modified accordingly.

[0103] For example: Now it is determined that the second release time is 1. For the updated task mapping table shown in Table 1 above, the updated task mapping table is queried based on the second release time to obtain the target index information. The target index information is 0. The target update task identifier corresponding to the target index information in the updated task mapping table is A. Then the task executable time and the remaining number of tasks corresponding to the target update task identifier can be updated to obtain the updated task mapping table shown in Table 2.

[0104] Table 2:

[0105] id freq nextValid rest A 6 4 5 B 1 1 1 C 1 1 1 D 1 1 1 E 1 1 1 F 1 1 1 G 1 1 1

[0106] In Table 2 above, the nextValid corresponding to the update task identifier A becomes 4, indicating that the update task corresponding to the update task identifier A can be executed again when the second release time is 4; the rest corresponding to the update task identifier A becomes 5, indicating that the update task corresponding to the update task identifier A still needs to be released on 5 service devices.

[0107] After adjusting the data in the update task mapping table, if the remaining number of tasks included in the update task mapping table is less than or equal to the quantity threshold (the quantity threshold can be 0), it indicates that the update tasks corresponding to each update task identifier have been released. The target time can be determined according to the second release time, and this target time is used to indicate the time required for the completion of the release of the update tasks corresponding to all update task identifiers in the update task mapping table. To a certain extent, the target time can represent the waiting time before the completion of the release of the update tasks. Work can be reasonably arranged according to this waiting time, which improves the utilization rate of time resources. At the same time, the release completion time of each update task can be determined according to the target time, so that after the release of the update tasks, the released update tasks can be monitored in a timely manner to ensure the stability of the system. Through the method provided in the embodiments of this application, the release time required for multiple update tasks can be determined, which is beneficial to optimizing the time allocation and is also beneficial to monitoring relevant situations after the completion of the release of the update tasks to ensure the stability of the system.

[0108] In one embodiment, after completing the adjustment of the data in the updated task mapping table, the method provided by the embodiments of the present application may further: if there is a remaining task quantity greater than the quantity threshold in the updated task mapping table, determine a new first release time according to the second release time; execute the steps of determining the minimum task executable time from the updated task mapping table and subsequent steps according to the new first release time. After completing the adjustment of the data in the updated task mapping table, if there is a remaining task quantity greater than the quantity threshold (the quantity threshold may be 0) in the updated task mapping table, a new first release time may be determined according to the second release time, and the steps of determining the minimum task executable time from the updated task mapping table and its subsequent steps may be executed according to the new first release time. For example: the updated task mapping table is as shown in Table 1 above. By using the method provided by the present application, the second release time can be determined to be 1, and the target index information can be determined according to the second release time. The updated task identifier corresponding to the target index information is A; the task executable time and the remaining task quantity corresponding to the updated task identifier A are updated. The adjusted updated task mapping table is as shown in Table 2 above. At this time, there is a remaining task quantity greater than 0 in the adjusted updated task mapping table, so a new first release time can be determined according to the second release time. The new first release time (Time1) may be the second release time (Time2) + 1 (i.e., Time1 = Time2 + 1). After determining the new first release time, the steps of determining the minimum task executable time from the adjusted updated task mapping table and subsequent steps may be executed according to the method provided in the above embodiment. Such cyclic processing is performed until the remaining task quantities included in the updated task mapping table are all less than or equal to the quantity threshold. Through the method provided by the embodiments of the present application, the time calculation of multiple update tasks can be realized, which is beneficial to the reasonable allocation of time and the improvement of resource utilization efficiency.

[0109] Please refer to Figure 8, This figure is a schematic diagram of a method for determining a target time provided by an embodiment of the present application. When there are multiple update tasks to be released, the task information of each update task can be obtained first, and an update task mapping table can be constructed according to the task information of each update task. The update task mapping table can include multiple update task identifiers and the associated information of each update task identifier. The associated information includes the number of task executions, the task executable time, and the remaining number of tasks. The update task identifier corresponds to the update task one by one. The update task mapping table can be traversed to determine whether the remaining number of tasks included in the update task mapping table is less than or equal to the quantity threshold. If so, it means that all update tasks have been released, and the target time is determined, and the process ends; if not, the first release time is determined, and the minimum task executable time is determined from the update task mapping table; it is judged whether the first release time is less than or equal to the minimum task executable time. If so, the second release time is determined according to the minimum task executable time. If not, the second release time is determined according to the first release time; query processing is performed on the update task mapping table based on the determined second release time to determine the target index information, and the task executable time and the remaining number of tasks corresponding to the target index information in the update task mapping table are updated; then, the remaining number of tasks included in the update task mapping table is judged. Through the method provided by the embodiment of the present application, the target time can be accurately determined, which is beneficial to the rational utilization of the target time and improves the resource utilization rate.

[0110] In one embodiment, the implementation manner of querying and processing the updated task mapping table based on the second release time to obtain the target index information may be: query and process the remaining task quantity corresponding to each updated task identifier according to the quantity threshold to obtain multiple candidate updated task identifiers, and the remaining task quantity corresponding to the candidate updated task identifiers is greater than the quantity threshold; if the executable time of the task corresponding to the candidate updated task identifier is less than or equal to the second release time, then determine the candidate updated task identifier as the to-be-determined updated task identifier; determine the index information corresponding to the to-be-determined updated task identifier with the largest remaining task quantity as the target index information. Taking the updated task mapping table shown in Table 1 as an example for illustration, after determining the second release time (assuming the second release time is 1), the remaining task quantity corresponding to each updated task identifier can be queried and processed according to the quantity threshold (assuming the quantity threshold is 0) to obtain multiple candidate updated task identifiers, and the remaining task quantity corresponding to the candidate updated task identifiers is greater than the quantity threshold. For the updated task mapping table shown in Table 1, it can be determined that the updated task identifiers A - G are candidate updated task identifiers; if the executable time of the task corresponding to the candidate updated task identifier is less than or equal to the second release time, then determine the candidate updated task identifier as the to-be-determined updated task identifier. For the determined candidate updated task identifiers A - G, the executable time of the tasks corresponding to the updated task identifiers A - G is less than or equal to the second release time (at this time, the second release time is 1), so the updated task identifiers A - G can all be determined as the to-be-determined updated task identifiers; the index information corresponding to the to-be-determined updated task identifier with the largest remaining task quantity can be determined as the target index information. For the determined to-be-determined updated task identifiers A - G, the remaining task quantity corresponding to the updated task identifier A is the largest, so the index information corresponding to the updated task identifier A can be determined as the target index information. It should be noted that when there are multiple to-be-determined updated task identifiers with the largest remaining task quantity, the target index information can be determined according to the arrangement order of the multiple to-be-determined updated task identifiers in the updated task mapping table. For example: when there are multiple to-be-determined updated task identifiers with the largest remaining task quantity, the index information of the to-be-determined updated task identifier with the earliest arrangement order in the updated task mapping table can be determined as the target index information. Through the method provided by the embodiments of the present application, the target index information can be accurately determined, which is beneficial to accurately determining the target time, and further improving the utilization rate of resources.

[0111] In one embodiment, the implementation method for updating the task executable time and the remaining number of tasks corresponding to the target update task identifier may be as follows: updating the task executable time corresponding to the target update task identifier according to the second release time, the task execution duration, and the cooling time; updating the remaining number of tasks corresponding to the target update task identifier. Updating the task executable time and the remaining number of tasks corresponding to the target update task identifier is to make the relevant data in the update task mapping table conform to the current situation. When the target update task identifier is determined, it indicates that the update task corresponding to the target update task identifier will be executed. Therefore, both the remaining number of tasks and the task executable time of this update task will change.

[0112] Specifically, the task executable time (nextValid) corresponding to the target update task identifier can be determined according to the second release time (Time2), the task execution duration, and the cooling time (interval). The task execution duration is used to indicate the time spent on executing a task, and the cooling time is used to indicate the cooling time of this type of update task. For example: if the second release time is 1, the task execution duration is 1, and the cooling time is 2, then the task executable time nextValid corresponding to the target update task identifier can be determined as nextValid = Time2 + 1 + interval = 4. After determining to execute the update task corresponding to the target update task identifier, the remaining number of tasks (rest) corresponding to the target update task identifier will be updated. For example: the remaining number of tasks (rest) corresponding to the target update task identifier can be equal to the original remaining number of tasks (rest) corresponding to the target update task identifier minus 1; according to the method provided in the embodiments of the present application, updating the data in the update task mapping table shown in Table 1 above can obtain the update task mapping table shown in Table 2 above. Through the method provided in the embodiments of the present application, the data in the update task mapping table can be updated, which ensures the normal execution of the algorithm and is also beneficial to determining the accurate target time.

[0113] For example: the implementation process of determining the target time according to the update task mapping table shown in Table 1 may be as follows: performing statistical processing on the number of tasks executed corresponding to each update task identifier in the update task mapping table shown in Table 1 to obtain an execution task mapping table, and this execution task mapping table may be as shown in Table 3.

[0114] Table 3:

[0115] subscript 0 1 2 3 4 5 6 7 8 9 10 11 tasks A A A A A A B C D E F G

[0116] Table 3 includes subscripts and update task identifiers (denoted as tasks), where the subscripts range from 0 to 11, a total of 12, which are the sum of the task execution quantities corresponding to each update task identifier in the update task mapping table shown in Table 1. Among them, the update task identifiers corresponding to subscripts 0 - 5 are A, indicating that the update task corresponding to the update task identifier A needs to be implemented on 6 service devices; subscripts 6 - 11 correspond to update task identifiers B - G respectively. The cooling time (interval) can be specified as 2, the task execution duration as 1, and the initial first release time Time1 as 0; when determining the target time, first check whether the subscripts in Table 3 have been traversed completely (that is, whether the remaining quantities of all tasks included in the update task mapping table are less than or equal to the quantity threshold (the quantity threshold is 0)). If it is determined that Table 3 has not been traversed completely, then traverse to subscript 0, as shown in Table 4 below.

[0117] Table 4:

[0118]

[0119] The first release time Time1 = Time1 + 1 = 1; from the update task mapping table shown in Table 1, determine that the minimum task executable time is 1, that is, minNextValid = 1; according to the first release time and the minimum task executable time (the specific calculation method can be Time2 = max(Time1, minNextValid)), determine that the second release time Time2 is 1.

[0120] After determining the second release time, query the update task mapping table shown in Table 1 to determine the target index information. Specifically, the target index information can be determined according to the three conditions of rest[j] > 0, nextValid[j] <= Time2, and rest[j] being the largest, where j represents the index information corresponding to each update task identifier in the update task mapping table, the index information corresponding to A is 0, the index information corresponding to G is 6, rest[0] represents the remaining quantity of the task corresponding to the update task identifier A, the value of rest[0] is 6, rest[1] represents the remaining quantity of the task corresponding to the update task identifier B, the value of rest[1] is 1; nextValid[0] represents the executable time of the task corresponding to the update task identifier A, the value of nextValid[0] is 1; according to the above three conditions, the target index information can be determined as best = 0.

[0121] After determining the target index information, the update task mapping table can be updated. Specifically, the update method can be nextValid[best]=Time2+interval+1, rest[best]=rest[best]-1; where nextValid[best] represents the executable time of the task corresponding to the update task identifier of the target index information, interval represents the cooling time, and the value is 2, and 1 represents the task execution duration. Now, if best=0 is determined, then nextValid[0]=1+2+1=4 and rest[0]=6-1=5 can be determined. The update task mapping table can be updated according to the determined data to obtain the update task mapping table shown in Table 5.

[0122] Table 5:

[0123] id nextValid rest A 4 5 B 1 1 C 1 1 D 1 1 E 1 1 F 1 1 G 1 1

[0124] After the update is completed, if there are tasks with a remaining quantity greater than the quantity threshold in the update task mapping table, a loop needs to be performed again. Then, traverse the task mapping table to subscript 1, as shown in Table 6.

[0125] Table 6:

[0126]

[0127] The first release time Time1=Time1+1=2 (it can also be Time1=Time2+1); from the update task mapping table shown in Table 5, the minimum task executable time is determined to be 1, that is, minNextValid=1; according to the first release time and the minimum task executable time (the specific calculation method can be Time2=max(Time1, minNextValid)), the second release time Time2 is determined to be 2.

[0128] After determining the second release time, the update task mapping table shown in Table 5 can be queried according to the three conditions of rest[j]>0, nextValid[j]< =Time2, and rest[j] being the largest (when there are multiple rest[j] that are the largest, best can be determined according to the smallest j) to determine the target index information, and the target index information can be determined to be best=1.

[0129] After determining the target index information, the update task mapping table can be updated. The update method can be nextValid[best]=Time2+interval+1, rest[best]=rest[best]-1. Now, if best = 1 is determined, then nextValid[1]=2+2+1 = 5 and rest[1]=1-1 = 0 can be determined. Based on the determined data, the update task mapping table is updated to obtain the update task mapping table as shown in Table VII.

[0130] Table VII:

[0131] id nextValid rest A 4 5 B 5 0 C 1 1 D 1 1 E 1 1 F 1 1 G 1 1

[0132] After the update is completed, if there is a task remaining quantity greater than the quantity threshold in the update task mapping table, a loop is still required. Then, the task mapping table is traversed until the subscript is 2, as shown in Table VIII.

[0133] Table VIII:

[0134]

[0135] The first release time Time1 = Time1+1 = 3; from the update task mapping table shown in Table VII, the minimum task executable time is determined to be 1, that is, minNextValid = 1; according to the first release time and the minimum task executable time (the specific calculation method can be Time2 = max(Time1, minNextValid)), the second release time Time2 is determined to be 3.

[0136] After determining the second release time, the update task mapping table shown in Table VII can be queried according to the three conditions of rest[j]>0, nextValid[j]< = Time2, and rest[j] being the largest (when there are multiple rest[j] that are the largest, best can be determined according to the smallest j), and the target index information can be determined. It can be determined that the target index information is best = 2.

[0137] After determining the target index information, the update task mapping table can be updated. The update method can be nextValid[best]=Time2+interval+1, rest[best]=rest[best]-1; according to the steps described above, if best = 2 is determined, then nextValid[2]=3+2+1 = 6 and rest[2]=1-1 = 0 can be determined. Based on the determined data, the update task mapping table is updated to obtain the update task mapping table as shown in Table IX.

[0138] Table IX:

[0139] id nextValid rest A 4 5 B 5 0 C 6 0 D 1 1 E 1 1 F 1 1 G 1 1

[0140] After the update is completed, if there are remaining tasks in the update task mapping table whose quantities are greater than the quantity threshold and another loop is required, then traverse the task mapping table up to index 3, as shown in Table X.

[0141] Table X:

[0142]

[0143] The first release time Time1 = Time1 + 1 = 4; from the update task mapping table shown in Table IX, the minimum task executable time is determined to be 1, that is, minNextValid = 1; according to the first release time and the minimum task executable time (the specific calculation method can be Time2 = max(Time1, minNextValid)), the second release time Time2 is determined to be 4.

[0144] After determining the second release time, the update task mapping table shown in Table IX can be queried according to the three conditions of rest[j] > 0, nextValid[j] <= Time2, and rest[j] being the largest (when there are multiple rest[j] that are the largest, best can be determined according to the smallest j), and the target index information can be determined. It can be determined that the target index information is best = 0.

[0145] After determining the target index information, the update task mapping table can be updated. The update method can be nextValid[best] = Time2 + interval + 1, rest[best] = rest[best] - 1; according to the steps described above, it can be determined that best = 0, then it can be determined that nextValid[0] = 4 + 2 + 1 = 7, rest[0] = 5 - 1 = 4; updating the update task mapping table according to the determined data, the update task mapping table shown in Table XI can be obtained.

[0146] Table XI:

[0147] id nextValid rest A 7 4 B 5 0 C 6 0 D 1 1 E 1 1 F 1 1 G 1 1

[0148] After the update is completed, if there are still remaining tasks in the update task mapping table whose quantities are greater than the quantity threshold and another loop is required, then traverse the task mapping table up to index 4, as shown in Table XII.

[0149] Table XII:

[0150]

[0151] The first release time Time1 = Time1 + 1 = 5; From the update task mapping table shown in Table XI, the minimum task executable time is determined to be 1, i.e., minNextValid = 1; According to the first release time and the minimum task executable time (the specific calculation method can be Time2 = max(Time1, minNextValid)), the second release time Time2 is determined to be 5.

[0152] After determining the second release time, the update task mapping table shown in Table XI can be queried according to the three conditions of rest[j] > 0, nextValid[j] <= Time2, and rest[j] being the largest (when there are multiple largest rest[j], best can be determined according to the smallest j) to determine the target index information, and it can be determined that the target index information is best = 3.

[0153] After determining the target index information, the update task mapping table can be updated. The update method can be nextValid[best] = Time2 + interval + 1, rest[best] = rest[best] - 1; According to the steps described above, it can be determined that best = 3, then it can be determined that nextValid[0] = 5 + 2 + 1 = 8, rest[0] = 1 - 1 = 0; The update task mapping table can be updated according to the determined data to obtain the update task mapping table shown in Table XIII.

[0154] Table XIII:

[0155] id nextValid rest A 7 4 B 5 0 C 6 0 D 8 0 E 1 1 F 1 1 G 1 1

[0156] After the update is completed, there are still task remaining quantities greater than the quantity threshold in the update task mapping table, and the loop needs to be performed again. Then, the task mapping table is traversed to the subscript 5, as shown in Table XIV.

[0157] Table XIV:

[0158]

[0159] The first release time Time1 = Time1 + 1 = 6; From the update task mapping table shown in Table XIII, the minimum task executable time is determined to be 1, i.e., minNextValid = 1; According to the first release time and the minimum task executable time (the specific calculation method can be Time2 = max(Time1, minNextValid)), the second release time Time2 is determined to be 6.

[0160] After determining the second release time, the updated task mapping table shown in Table XIII can be queried according to the three conditions: rest[j]>0, nextValid[j]<=Time2, and rest[j] being the largest (when there are multiple largest rest[j], best can be determined according to the smallest j), and the target index information can be determined. It can be determined that the target index information is best = 4.

[0161] After determining the target index information, the updated task mapping table can be updated. The update method can be nextValid[best] = Time2 + interval + 1, rest[best] = rest[best] - 1; according to the steps described above, it can be determined that best = 4, then it can be determined that nextValid[0] = 6 + 2 + 1 = 9, rest[0] = 1 - 1 = 0; updating the updated task mapping table according to the determined data, the updated task mapping table shown in Table XV can be obtained.

[0162] Table XV:

[0163] id nextValid rest A 7 4 B 5 0 C 6 0 D 8 0 E 9 0 F 1 1 G 1 1

[0164] After the update is completed, there are still task remaining quantities greater than the quantity threshold in the updated task mapping table, and the loop needs to be performed again, repeating the above steps until all subscripts in the execution task mapping table are traversed. Finally, the updated task mapping table shown in Table XVI can be obtained.

[0165] Table XVI:

[0166] id nextValid rest A 19 0 B 5 0 C 6 0 D 8 0 E 9 0 F 11 0 G 12 0

[0167] At the same time, it can be determined that the target time is 16, and the possible task release order is "A - B - C - A - D - E - A - F - G - A - standby - standby - A - standby - standby - A", where "standby" indicates that no task release operation is performed during this time period. Through the method provided by the embodiments of the present application, the target time can be accurately determined, which is beneficial to the reasonable planning of time allocation.

[0168] In one embodiment, after determining the target time, the method provided by this application may further: publish the update tasks corresponding to each update task identifier in the update task mapping table, where the publication time of the update task is the third publication time; determine the publication completion time according to the third publication time and the target time, and match the publication completion time with the current time to obtain a matching result; if the matching result indicates that the publication completion time matches the current time, generate a publication completion prompt message, which is used to prompt that the update task has been published. After determining the target time, the test device can publish the update tasks corresponding to each update task identifier in the update task mapping table. The publication time of the update task can be the third time. The publication completion time can be determined according to the third publication time and the target time. For example, if the third publication time is 10:00 and the target time is 2 hours, the publication completion time can be determined to be 12:00. That is, at 12:00, the update tasks corresponding to each update task identifier in the update task mapping table have all been published. The publication completion time can be matched with the current time to obtain a matching result. If the matching result indicates that the publication completion time matches the current time, a publication completion prompt message can be generated. This publication completion prompt message is used to prompt that the update task has been published. For example, if the publication completion time is 12:00 and the current time is 11:30, the matching result indicates that the publication completion time does not match the current time, and no operation is performed. If the publication completion time is 12:00 and the current time is 12:00, the matching result indicates that the publication completion time matches the current time, and a publication completion prompt message can be generated. The publication completion prompt message can be sent to the management object, so that the management object can monitor the publication situation after the update task is published and handle abnormal situations in a timely manner. Through the method provided by the embodiments of this application, timely prompt of publication completion can be achieved, ensuring that the situation after publication can be monitored and abnormal situations can be handled in a timely manner, ensuring the stability of the system and facilitating the reduction of resource losses caused by abnormalities.

[0169] Through the test method provided by the embodiments of the present application, multiple different test scenario information can be determined, which is beneficial to using the test scenario information for test processing and comprehensively checking potential problems; before gray release, the test scenario information can be used to simulate and call devices for targeted testing to obtain accurate test results, so as to determine whether there are abnormalities, which is beneficial to improving the efficiency and accuracy of gray release, avoiding abnormalities and resource losses during gray release, and effectively ensuring the stability of the system at the same time; corresponding adjustments can be made to the update process of the transaction processing logic according to the test results, so as to ensure the normal execution of the gray release process subsequently; the completion times of multiple update tasks can be obtained, which is convenient for reasonable time arrangement and beneficial to making full use of resources; timely prompts for the completion of update task releases can be realized, ensuring that the situation after the release can be monitored and abnormal situations can be handled in a timely manner, ensuring the stability of the system.

[0170] Please refer to Figure 9 , Figure 9 which is a structural block diagram of a test device provided by the embodiments of the present application. The device includes:

[0171] A determination unit 901, configured to determine test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service non-updated status or the service updated status; the service device in the service non-updated status is used to implement the target transaction according to the pre-update transaction processing logic, and the service device in the service updated status is used to implement the target transaction according to the post-update transaction processing logic, and the transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic;

[0172] A simulation unit 902, configured to simulate and call a first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status based on the test scenario information, and obtain a simulated execution result of the target main transaction;

[0173] The simulation unit 902 is further configured to simulate and call a second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update status based on the simulated execution result of the target main transaction, and obtain a simulated execution result of the target sub-transaction;

[0174] A test unit 903 is configured to determine, according to the simulation execution result of the target transaction, a test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0175] In one embodiment, the updated main transaction processing logic is used to indicate generating new vector data and adding the new vector data to the execution result of the main transaction, and the updated sub-transaction processing logic is used to indicate processing by using the new vector data; when the simulation unit 902 simulates calling a first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status and obtains the simulation execution result of the target main transaction, it is specifically configured to: if the first service update status is a service not updated status, simulate calling the first service device to execute the target main transaction according to the pre-update main transaction processing logic corresponding to the service not updated status, and obtain the simulation execution result of the target main transaction that does not include the new vector data; when the simulation unit 902 simulates calling a second service device to execute the target sub-transaction according to the simulation execution result of the target main transaction and according to the sub-transaction processing logic corresponding to the second service update status and obtains the simulation execution result of the target sub-transaction, it is specifically configured to: if the second service update status is a service updated status, simulate calling the second service device to execute the target sub-transaction according to the simulation execution result that does not include the new vector data and according to the updated sub-transaction processing logic corresponding to the service updated status, and obtain the simulation execution result indicating that the execution of the target sub-transaction is abnormal.

[0176] In one embodiment, when the test unit 903 determines the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target sub-transaction, it is specifically configured to: determine a reference test result indicating that the test fails according to the simulation execution result indicating that the execution of the target sub-transaction is abnormal; and determine the reference test result as the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information.

[0177] In one embodiment, the updated main transaction processing logic is determined according to the main transaction update information, and the updated subordinate transaction processing logic is determined according to the subordinate transaction update information. The test unit 903 is further configured to: according to the test result, use the main transaction update information to update the main transaction processing logic of multiple service devices, so that the multiple service devices all execute the target main transaction according to the updated main transaction processing logic; after the main transaction processing logic of each service device in the multiple service devices is updated, use the subordinate transaction update information to update the subordinate transaction processing logic of the multiple service devices, so that the multiple service devices all execute the target subordinate transaction according to the updated subordinate transaction processing logic.

[0178] In one embodiment, the test scenario information includes first test scenario information, second test scenario information, third test scenario information, and fourth test scenario information. The first service update status and the second service update status indicated by the first test scenario information are both service updated statuses; the first service update status and the second service update status indicated by the second test scenario information are both service non-updated statuses; the first service update status and the second service update status indicated by the third test scenario information are respectively a service updated status and a service non-updated status; the first service update status and the second service update status indicated by the fourth test scenario information are respectively a service non-updated status and a service updated status. When determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target subordinate transaction, the test unit 903 is specifically configured to: determine the first test result, the second test result, the third test result, and the fourth test result of the transaction processing logic for the target transaction in the test scenario indicated by the corresponding test scenario information according to the simulated execution results of the target subordinate transaction corresponding to the first test scenario information, the second test scenario information, the third test scenario information, and the fourth test scenario information.

[0179] In one embodiment, the test unit 903 is further configured to: determine a scenario test result of the transaction processing logic for the target transaction according to the first test result, the second test result, the third test result, and the fourth test result, where the scenario test result is used to indicate whether there is an abnormality in the transaction processing logic for the target transaction in each test scenario.

[0180] In one embodiment, the test unit 903 is further configured to: determine a first release time, and determine the minimum task executable time from the update task mapping table, where the update task mapping table includes multiple update task identifiers and the associated information of each update task identifier, the associated information includes the task execution quantity, the task executable time, and the remaining task quantity, and the multiple update task identifiers include the identifier of the update task for the service corresponding to the target transaction; if the minimum task executable time is greater than the first release time, update the first release time according to the minimum task executable time to obtain a second release time; perform a query process on the update task mapping table based on the second release time to obtain target index information, and update the task executable time and the remaining task quantity corresponding to the target update task identifier, where the target update task identifier is the update task identifier corresponding to the target index information in the update task mapping table; if the remaining task quantities included in the update task mapping table are all less than or equal to the quantity threshold, determine a target time according to the second release time, where the target time is used to indicate the time required for the completion of the release of the update tasks corresponding to all the update task identifiers in the update task mapping table.

[0181] In one embodiment, the test unit 903 is further configured to: if there is a remaining task quantity greater than the quantity threshold in the update task mapping table, determine a new first release time according to the second release time; perform the step of determining the minimum task executable time from the update task mapping table and subsequent steps according to the new first release time.

[0182] In one embodiment, when the test unit 903 performs a query process on the update task mapping table based on the second release time to obtain target index information, it is specifically configured to: perform a query process on the remaining task quantities corresponding to each update task identifier according to the quantity threshold to obtain multiple candidate update task identifiers, where the remaining task quantities corresponding to the candidate update task identifiers are greater than the quantity threshold; if the task executable time corresponding to the candidate update task identifier is less than or equal to the second release time, determine the candidate update task identifier as a pending update task identifier; determine the index information corresponding to the pending update task identifier with the largest remaining task quantity as the target index information.

[0183] In one embodiment, the test unit 903 is further configured to: publish the update tasks corresponding to the respective update task identifiers in the update task mapping table, where the release time of the update tasks is the third release time; determine the release completion time according to the third release time and the target time, and perform matching processing on the release completion time and the current time to obtain a matching result; if the matching result indicates that the release completion time matches the current time, generate a release completion prompt message, where the release completion prompt message is used to prompt that the update task has been released.

[0184] It can be understood that the functions of the functional units of the test device according to the embodiments of the present application can be specifically implemented according to the test methods in the above method embodiments, and the specific implementation process can refer to the relevant descriptions in the above test method embodiments, which will not be elaborated here. In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other relevant parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of the overall module or unit that includes the function of the module or unit.

[0185] Through the test device provided by the embodiments of the present application, multiple different test scenario information can be determined, which is beneficial to using the test scenario information for test processing and comprehensively checking potential problems; before gray release, the device can be simulated and called according to the test scenario information for targeted testing to obtain accurate test results, so as to determine whether there is an abnormality, which is beneficial to improving the efficiency and accuracy of gray release, avoiding abnormalities and resource losses during gray release, and effectively ensuring the stability of the system at the same time; the update process of the transaction processing logic can be adjusted correspondingly according to the test results, so as to ensure the normal execution of the gray release process subsequently; the release completion times of multiple update tasks can be obtained, which is convenient for reasonable time arrangement and beneficial to making full use of resources; the timely prompt for the completion of the update task release can be realized, ensuring that the situation after the release is completed can be monitored and abnormal situations can be processed in a timely manner, ensuring the stability of the system.

[0186] Please refer to Figure 10 , Figure 10 which is a structural block diagram of a computer device provided by the embodiments of the present application. The computer device described in the embodiments of the present application includes: a processor 1001, a communication interface 1002, and a memory 1003. Among them, the processor 1001, the communication interface 1002, and the memory 1003 can be connected through a bus or other means. In the embodiments of the present application, the connection through a bus is taken as an example.

[0187] Among them, the processor 1001 (or CPU (Central Processing Unit)) is the computing core and control core of the computer device. It can parse various instructions in the computer device and process various data of the computer device. For example, the CPU can be used to parse the power-on and power-off instructions sent by the user to the computer device and control the computer device to perform power-on and power-off operations. Another example is that the CPU can transmit various interaction data between the internal structures of the computer device, and so on. The communication interface 1002 may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and is controlled by the processor 1001 to send and receive data. The memory 1003 (Memory) is the memory device in the computer device and is used to store programs and data. It can be understood that the memory 1003 here can include both the built-in memory of the computer device and, of course, the extended memory supported by the computer device. The memory 1003 provides a storage space, and this storage space stores the operating system of the computer device, which may include but is not limited to: Android system, iOS system, Windows Phone system, etc. The present application does not make any limitations in this regard.

[0188] In the embodiment of the present application, the processor 1001 executes the following operations by running the executable program code in the memory 1003:

[0189] Determine the test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the transaction processing logic before the update, and the service device in the service updated status is used to implement the target transaction according to the transaction processing logic after the update. The transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic;

[0190] According to the test scenario information, simulate calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtain the simulated execution result of the target main transaction;

[0191] Simulate calling the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update status based on the simulated execution result of the target main transaction, and obtain the simulated execution result of the target sub-transaction;

[0192] Determine the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target transaction, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

[0193] In one embodiment, the updated main transaction processing logic is used to indicate generating new vector data and adding the new vector data to the execution result of the main transaction, and the updated subordinate transaction processing logic is used to indicate processing using the new vector data; when the processor 1001 simulates calling the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status and obtains the simulation execution result of the target main transaction, it is specifically used for: if the first service update status is the service not updated status, then simulate calling the first service device to execute the target main transaction according to the main transaction processing logic before the update corresponding to the service not updated status, and obtain the simulation execution result of the target main transaction that does not include the new vector data; when the processor 1001 simulates calling the second service device to execute the target subordinate transaction according to the simulation execution result of the target main transaction and according to the subordinate transaction processing logic corresponding to the second service update status and obtains the simulation execution result of the target subordinate transaction, it is specifically used for: if the second service update status is the service updated status, then simulate calling the second service device to execute the target subordinate transaction according to the simulation execution result that does not include the new vector data and according to the updated subordinate transaction processing logic corresponding to the service updated status, and obtain the simulation execution result indicating that the execution of the target subordinate transaction is abnormal.

[0194] In one embodiment, when the processor 1001 determines the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target subordinate transaction, it is specifically used for: determining a reference test result indicating that the test fails according to the simulation execution result indicating that the execution of the target subordinate transaction is abnormal; determining the reference test result as the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information.

[0195] In one embodiment, the updated main transaction processing logic is determined according to the main transaction update information, and the updated subordinate transaction processing logic is determined according to the subordinate transaction update information. The processor 1001 is further configured to: according to the test result, use the main transaction update information to update the main transaction processing logic of multiple service devices, so that the multiple service devices all execute the target main transaction according to the updated main transaction processing logic; after the main transaction processing logic of each service device among the multiple service devices is updated, use the subordinate transaction update information to update the subordinate transaction processing logic of the multiple service devices, so that the multiple service devices all execute the target subordinate transaction according to the updated subordinate transaction processing logic.

[0196] In one embodiment, the test scenario information includes first test scenario information, second test scenario information, third test scenario information, and fourth test scenario information. The first service update status and the second service update status indicated by the first test scenario information are both service updated statuses; the first service update status and the second service update status indicated by the second test scenario information are both service non-updated statuses; the first service update status and the second service update status indicated by the third test scenario information are respectively a service updated status and a service non-updated status; the first service update status and the second service update status indicated by the fourth test scenario information are respectively a service non-updated status and a service updated status. When determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target subordinate transaction, the processor 1001 is specifically configured to: determine the first test result, the second test result, the third test result, and the fourth test result of the transaction processing logic for the target transaction in the test scenario indicated by the corresponding test scenario information according to the simulated execution results of the target subordinate transaction corresponding to the first test scenario information, the second test scenario information, the third test scenario information, and the fourth test scenario information.

[0197] In one embodiment, the processor 1001 is further configured to: determine a scenario test result of the transaction processing logic for the target transaction according to the first test result, the second test result, the third test result, and the fourth test result, where the scenario test result is used to indicate whether there is an abnormality in the transaction processing logic for the target transaction in each test scenario.

[0198] In one embodiment, the processor 1001 is further configured to: determine a first release time, and determine the minimum task executable time from an updated task mapping table, where the updated task mapping table includes multiple updated task identifiers and associated information of each updated task identifier, and the associated information includes the number of task executions, the task executable time, and the remaining number of tasks, and the multiple updated task identifiers include the identifier of the updated task for the service corresponding to the target transaction; if the minimum task executable time is greater than the first release time, perform an update process on the first release time according to the minimum task executable time to obtain a second release time; perform a query process on the updated task mapping table based on the second release time to obtain target index information, and perform an update process on the task executable time and the remaining number of tasks corresponding to the target updated task identifier, where the target updated task identifier is the updated task identifier corresponding to the target index information in the updated task mapping table; if the remaining number of tasks included in the updated task mapping table is less than or equal to a quantity threshold, determine a target time according to the second release time, where the target time is used to indicate the time required for the completion of the release of the updated tasks corresponding to all the updated task identifiers in the updated task mapping table.

[0199] In one embodiment, the processor 1001 is further configured to: if there is a remaining number of tasks greater than the quantity threshold in the updated task mapping table, determine a new first release time according to the second release time; perform the step of determining the minimum task executable time from the updated task mapping table and subsequent steps according to the new first release time.

[0200] In one embodiment, when the processor 1001 performs a query process on the updated task mapping table based on the second release time to obtain target index information, the processor 1001 is specifically configured to: perform a query process on the remaining number of tasks corresponding to each updated task identifier according to the quantity threshold to obtain multiple candidate updated task identifiers, where the remaining number of tasks corresponding to the candidate updated task identifiers is greater than the quantity threshold; if the task executable time corresponding to the candidate updated task identifier is less than or equal to the second release time, determine the candidate updated task identifier as a pending updated task identifier; determine the index information corresponding to the pending updated task identifier with the largest remaining number of tasks as the target index information.

[0201] In one embodiment, the processor 1001 is further configured to: publish the update tasks corresponding to the respective update task identifiers in the update task mapping table, where the release time of the update tasks is the third release time; determine a release completion time according to the third release time and the target time, and perform a matching process on the release completion time and the current time to obtain a matching result; if the matching result indicates that the release completion time matches the current time, generate a release completion prompt message, where the release completion prompt message is used to prompt that the update task has been released.

[0202] In a specific implementation, the processor 1001, communication interface 1002, and memory 1003 described in the embodiments of the present application may execute the implementation manners of the test device described in a test method provided by the embodiments of the present application, or may execute the implementation manners described in a test device provided by the embodiments of the present application, which will not be elaborated here.

[0203] Through the computer device provided by the embodiments of the present application, multiple different test scenario information can be determined, which is beneficial to performing test processing using the test scenario information to comprehensively detect potential problems; before gray release, the device can be simulated and called for targeted testing according to the test scenario information to obtain accurate test results, so as to determine whether there is an abnormality, which is beneficial to improving the efficiency and accuracy of gray release, avoiding abnormalities and resource losses during gray release, and effectively ensuring the stability of the system at the same time; the update process of the transaction processing logic can be adjusted correspondingly according to the test results, so as to ensure the normal execution of the gray release process subsequently; the release completion times of multiple update tasks can be obtained, which is convenient for reasonable time arrangement and is beneficial to making full use of resources; timely prompts for the completion of the release of update tasks can be realized, ensuring that the situation after the release is monitored and abnormal situations can be processed in a timely manner, ensuring the stability of the system.

[0204] The embodiments of the present application further provide a computer-readable storage medium, in which a computer program is stored. When it runs on a computer, it causes the computer to execute the test method as described in the embodiments of the present application. Its specific implementation manner may refer to the previous description and will not be elaborated here.

[0205] The embodiments of the present application further provide a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, causing the computer device to execute the test method as described in the embodiments of the present application. Its specific implementation manner may refer to the previous description and will not be elaborated here.

[0206] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0207] In the above embodiments, the descriptions of each embodiment have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments. The technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a computer, a server, or a network device, etc., specifically, the processor in the computer device) to execute all or part of the steps of the foregoing methods in each embodiment of this application. Among them, the foregoing storage medium may include: USB flash drives, mobile hard disks, magnetic disks, optical discs, read-only memories (English: Read-Only Memory, abbreviation: ROM), or random access memories (English: Random Access Memory, abbreviation: RAM), and other various media that can store program codes.

[0208] As described above, the above embodiments are only used to illustrate the technical solutions of this application, rather than to limit it; although this application has been described in detail with reference to the foregoing embodiments, it should be understood that: the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of this application.

Claims

1. A testing method, characterized in that, The method includes: Determining test scenario information, where the test scenario information is used to indicate: the first service update status of the service device for executing the target main transaction, and the second service update status of the service device for executing the target sub-transaction; the target main transaction and the target sub-transaction are respectively the main transaction and the sub-transaction of the target transaction; the first service update status and the second service update status are respectively the service not updated status or the service updated status; the service device in the service not updated status is used to implement the target transaction according to the pre-update transaction processing logic, and the service device in the service updated status is used to implement the target transaction according to the post-update transaction processing logic, and the transaction processing logic includes the main transaction processing logic and the sub-transaction processing logic; According to the test scenario information, simulating a call to the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtaining the simulated execution result of the target main transaction; Simulating a call to the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update status based on the simulated execution result of the target main transaction, and obtaining the simulated execution result of the target sub-transaction; According to the simulated execution result of the target sub-transaction, determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

2. The method according to claim 1, wherein The post-update main transaction processing logic is used to indicate generating new vector data and adding the new vector data to the execution result of the main transaction, and the post-update sub-transaction processing logic is used to indicate processing using the new vector data; The simulating a call to the first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, and obtaining the simulated execution result of the target main transaction, includes: If the first service update status is the service not updated status, then simulating a call to the first service device to execute the target main transaction according to the pre-update main transaction processing logic corresponding to the service not updated status, and obtaining the simulated execution result of the target main transaction that does not include the new vector data; The simulating a call to the second service device to execute the target sub-transaction according to the sub-transaction processing logic corresponding to the second service update status based on the simulated execution result of the target main transaction, and obtaining the simulated execution result of the target sub-transaction, includes: If the second service update status is the service updated status, then simulating a call to the second service device to execute the target sub-transaction according to the post-update sub-transaction processing logic corresponding to the service updated status based on the simulated execution result that does not include the new vector data, and obtaining the simulated execution result indicating that the target sub-transaction execution is abnormal.

3. The method according to claim 2, characterized in that The determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulated execution result of the target sub-transaction, includes: Determine a reference test result indicating a failed test based on the simulation execution result of the transaction execution exception for the indicated target; Determine the reference test result as the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information.

4. The method according to claim 3, wherein The updated main transaction processing logic is determined based on the main transaction update information, and the updated subordinate transaction processing logic is determined based on the subordinate transaction update information. The method further includes: According to the test result, use the main transaction update information to update the main transaction processing logics of multiple service devices, so that the multiple service devices all execute the target main transaction according to the updated main transaction processing logic; After the main transaction processing logics of each service device among the multiple service devices are updated, use the subordinate transaction update information to update the subordinate transaction processing logics of the multiple service devices, so that the multiple service devices all execute the target subordinate transaction according to the updated subordinate transaction processing logic.

5. The method according to claim 1, wherein The test scenario information includes first test scenario information, second test scenario information, third test scenario information, and fourth test scenario information. The first service update status and the second service update status indicated by the first test scenario information are both service updated statuses; the first service update status and the second service update status indicated by the second test scenario information are both service non-updated statuses; the first service update status and the second service update status indicated by the third test scenario information are respectively service updated status and service non-updated status; the first service update status and the second service update status indicated by the fourth test scenario information are respectively service non-updated status and service updated status; The determining the test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target subordinate transaction includes: According to the simulation execution results of the target subordinate transaction corresponding to the first test scenario information, second test scenario information, third test scenario information, and fourth test scenario information respectively, determine the first test result, second test result, third test result, and fourth test result of the transaction processing logic for the target transaction in the test scenario indicated by the corresponding test scenario information.

6. The method according to claim 5, wherein The method further includes: According to the first test result, second test result, third test result, and fourth test result, determine a scenario test result of the transaction processing logic for the target transaction, where the scenario test result is used to indicate whether there is an exception in the transaction processing logic for the target transaction in each test scenario.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Determine a first release time, and determine the minimum task executable time from an update task mapping table, where the update task mapping table includes multiple update task identifiers and the associated information of each update task identifier, the associated information includes the task execution quantity, task executable time, and task remaining quantity, and the multiple update task identifiers include the identifier of the update task for the service corresponding to the target transaction; If the minimum task execution time is greater than the first release time, update the first release time according to the minimum task execution time to obtain a second release time; Query the updated task mapping table based on the second release time to obtain target index information, and update the task execution time and the remaining number of tasks corresponding to the target updated task identifier. The target updated task identifier is the updated task identifier corresponding to the target index information in the updated task mapping table; If the remaining number of tasks included in the updated task mapping table is less than or equal to the quantity threshold, determine a target time according to the second release time. The target time is used to indicate the time required for the release of all updated tasks corresponding to the updated task identifiers in the updated task mapping table to be completed.

8. The method according to claim 7, wherein The method further includes: If there is a remaining number of tasks greater than the quantity threshold in the updated task mapping table, determine a new first release time according to the second release time; Execute the step of determining the minimum task execution time from the updated task mapping table and subsequent steps according to the new first release time.

9. The method according to claim 7, wherein The querying the updated task mapping table based on the second release time to obtain target index information includes: Query the remaining number of tasks corresponding to each updated task identifier according to the quantity threshold to obtain a plurality of candidate updated task identifiers, and the remaining number of tasks corresponding to the candidate updated task identifiers is greater than the quantity threshold; If the task execution time corresponding to the candidate updated task identifier is less than or equal to the second release time, determine the candidate updated task identifier as a to-be-determined updated task identifier; Determine the index information corresponding to the to-be-determined updated task identifier with the largest remaining number of tasks as the target index information.

10. The method according to claim 7, characterized in that The method further includes: Release the updated tasks corresponding to each updated task identifier in the updated task mapping table, and the release time of the updated tasks is the third release time; Determine the release completion time according to the third release time and the target time, and perform a matching process between the release completion time and the current time to obtain a matching result; If the matching result indicates that the release completion time matches the current time, generate a release completion prompt message, and the release completion prompt message is used to prompt that the updated task has been released.

11. A testing device, characterized in that, The device includes: A determining unit, configured to determine test scenario information, where the test scenario information is used to indicate: a first service update status of a service device for executing a target main transaction and a second service update status of a service device for executing a target subordinate transaction; the target main transaction and the target subordinate transaction are respectively the main transaction and the subordinate transaction of a target transaction; the first service update status and the second service update status are respectively a service not updated status or a service updated status; a service device in the service not updated status is used to implement the target transaction according to the transaction processing logic before the update, and a service device in the service updated status is used to implement the target transaction according to the transaction processing logic after the update, and the transaction processing logic includes a main transaction processing logic and a subordinate transaction processing logic; A simulation unit, configured to, according to the test scenario information, simulate and call a first service device to execute the target main transaction according to the main transaction processing logic corresponding to the first service update status, so as to obtain a simulation execution result of the target main transaction; The simulation unit is further configured to simulate and call a second service device to execute the target subordinate transaction according to the subordinate transaction processing logic corresponding to the second service update status according to the simulation execution result of the target main transaction, so as to obtain a simulation execution result of the target subordinate transaction; A testing unit, configured to determine a test result of the transaction processing logic for the target transaction in the test scenario indicated by the test scenario information according to the simulation execution result of the target subordinate transaction, where the test result includes one or more of a timing test result, a compatibility test result, and a coding test result.

12. A computer device, characterized in that, Comprising: A processor, a communication interface, and a memory, where the processor, the communication interface, and the memory are connected to each other. Among them, the memory stores executable program code, and the processor is configured to call the executable program code to implement the test method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, Computer instructions are stored in the computer-readable storage medium, and when the computer instructions run on the computer, the computer is caused to implement the test method according to any one of claims 1-10.

14. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, the test method according to any one of claims 1-10 is implemented.

Images