Test method and device of distributed service, electronic equipment and storage medium

Abstract

The application discloses a distributed service testing method and device, electronic equipment and a storage medium. The method comprises the following steps: obtaining abnormal scene set of a distributed service from abnormal scene information of a service node of the distributed service, wherein the abnormal scene information represents an abnormal scene injected into the corresponding service node; obtaining combined abnormal scene information by combining a plurality of target abnormal scene information in the abnormal scene set; triggering the target service node corresponding to each target abnormal scene information to activate the target abnormal scene corresponding to the corresponding target abnormal scene information based on the combined abnormal scene information, so as to activate the corresponding combined abnormal scene; and executing a service test case of the distributed service under the combined abnormal scene to obtain a service test result corresponding to the combined abnormal scene. The application improves the fault test efficiency of different abnormal scenes of the distributed service, greatly improves the test flexibility, shortens the time consumption of the test, and reduces the cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for testing distributed services. Background Technology

[0002] Currently, testing for distributed services, in addition to basic interface function testing, also requires simulating various abnormal scenarios to conduct fault testing on distributed services.

[0003] In related technologies, fault testing efficiency for different abnormal scenarios in distributed services is low, and the testing flexibility is poor and the time consumption is long. Summary of the Invention

[0004] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, electronic device, and storage medium for testing distributed services. The technical solution is as follows:

[0005] On the one hand, a testing method for distributed services is provided, which includes:

[0006] Abnormal scenario information is obtained from the business nodes of the distributed business to obtain the abnormal scenario set corresponding to the distributed business; the abnormal scenario information represents the abnormal scenario injected into the corresponding business node; the abnormal scenario is implemented based on the abnormal logic code used to simulate the abnormal scenario.

[0007] Based on the abnormal scene information from the set of abnormal scenes, the scene is combined to obtain combined abnormal scene information; the combined abnormal scene information includes the multiple target abnormal scene information.

[0008] Based on the combined abnormal scenario information, the target business node corresponding to each of the target abnormal scenario information is triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information, so as to activate the corresponding combined abnormal scenario.

[0009] The business test cases of the distributed service are executed under the combined abnormal scenario to obtain the business test results corresponding to the combined abnormal scenario.

[0010] On the other hand, a testing device for distributed services is provided, the device comprising:

[0011] An abnormal scenario information acquisition module is used to acquire abnormal scenario information from the business nodes of the distributed business to obtain a set of abnormal scenarios corresponding to the distributed business; the abnormal scenario information represents the abnormal scenarios injected into the corresponding business nodes; the abnormal scenarios are implemented based on abnormal logic code used to simulate abnormal scenarios;

[0012] The scene combination module is used to combine multiple target abnormal scene information from the abnormal scene set to obtain combined abnormal scene information; the combined abnormal scene information includes the multiple target abnormal scene information.

[0013] The combined scenario activation module is used to trigger the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information based on the combined abnormal scenario information, so as to activate the corresponding combined abnormal scenario.

[0014] The testing module is used to execute business test cases of the distributed service under the combined abnormal scenarios and obtain business test results corresponding to the combined abnormal scenarios.

[0015] In one exemplary implementation, the combined scene activation module includes:

[0016] The task type determination module is used to determine the task type corresponding to the combined abnormal scenario information; the task type includes timed task type and non-timed task type.

[0017] The scheduled task generation module is used to generate a target scheduled task based on the combined abnormal scenario information and the target timing information when the task type is a scheduled task type; the target scheduled task indicates that the target business node corresponding to each of the target abnormal scenario information will be triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information at a target time; the target time is the time indicated by the target timing information.

[0018] The scheduled task execution module is used to execute the target scheduled task when the target time is reached.

[0019] In one exemplary embodiment, the scheduled task generation module includes:

[0020] The execution order determination module is used to determine the execution order of multiple target abnormal scenario information in the combined abnormal scenario information;

[0021] The scheduled task generation submodule is used to generate a target scheduled task based on the multiple target abnormal scenario information, the execution order of the multiple target abnormal scenario information, and the target timing information.

[0022] The target timed task instruction triggers the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information in accordance with the execution order at the target time.

[0023] In one exemplary embodiment, the combined scene activation module further includes:

[0024] The task generation module is used to generate a target task based on the combined abnormal scenario information when the task type is a non-timed task type; the target task indicates that the target business node corresponding to each of the target abnormal scenario information should be activated to activate the target abnormal scenario corresponding to the target abnormal scenario information.

[0025] The task execution module is used to execute the target task.

[0026] In one exemplary embodiment, the abnormal scene information acquisition module includes:

[0027] The query module is used to send abnormal scenario query requests to the business nodes of the distributed service at preset time intervals;

[0028] The query result receiving module is used to receive the query results returned by the business nodes of the distributed service in response to the query request in the abnormal scenario;

[0029] The storage module is used to store the abnormal scenario information in the query result into a designated storage space when the query result indicates the existence of a newly injected abnormal scenario, so as to obtain the abnormal scenario set corresponding to the distributed service; wherein, the newly injected abnormal scenario refers to the abnormal scenario injected within the preset time interval.

[0030] In one exemplary embodiment, the abnormal scene information acquisition module further includes:

[0031] The update module is used to update the set of abnormal scenarios corresponding to the distributed service based on the information of the deleted abnormal scenarios when the query result indicates that the abnormal scenarios should be deleted.

[0032] In one exemplary embodiment, the apparatus further includes:

[0033] An atomic acquisition module is used to acquire the exception logic code to be injected from the exception logic code set; different exception logic codes in the exception logic code set are used to simulate different exception scenarios.

[0034] The code injection module is used to inject the exception logic code to be injected into the business code package corresponding to the distributed business.

[0035] The compilation module is used to compile the injected business code package to obtain the target executable file;

[0036] An abnormal scenario injection module is used to send the target executable file to the business node of the distributed service, so as to inject the abnormal scenario simulated by the abnormal logic code to be injected into the business node.

[0037] On the other hand, an electronic device is provided, including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement distributed services in any of the above aspects, and a test method is provided.

[0038] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement a test method for distributed services as described above.

[0039] On the other hand, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, executes the computer instructions, and causes the electronic device to perform a test method for distributed services according to any of the above aspects.

[0040] This application embodiment obtains an abnormal scenario set corresponding to a distributed service by acquiring abnormal scenario information from the service nodes of the distributed service, and combines multiple target abnormal scenario information in the abnormal scenario set to obtain combined abnormal scenario information. Based on the combined abnormal scenario information, the target service nodes corresponding to each target abnormal scenario information are triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information to activate the corresponding combined abnormal scenario. Then, the business test cases of the distributed service are executed under the combined abnormal scenario to obtain the business test results corresponding to the combined abnormal scenario. Thus, the distributed service can be automatically tested under the combined abnormal scenario based on the required combined abnormal scenario, which improves the fault testing efficiency for different abnormal scenarios of the distributed service, greatly improves the testing flexibility, and has a short testing time and low cost. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0043] Figure 2 This is a schematic diagram of the blockchain system provided in the embodiments of this application;

[0044] Figure 3 This is an optional schematic diagram of the block structure provided in an embodiment of this application;

[0045] Figure 4 This is a flowchart illustrating a testing method for distributed services provided in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the process for injecting abnormal scenarios into the business nodes of a distributed service, provided in an embodiment of this application.

[0047] Figure 6 This is a flowchart illustrating another method for testing distributed services provided in an embodiment of this application;

[0048] Figure 7 This is a flowchart illustrating another method for testing distributed services provided in an embodiment of this application;

[0049] Figure 8 This is a schematic diagram of the scheduling execution provided in the embodiments of this application;

[0050] Figure 9(a) is a schematic diagram of the state transition of the target task corresponding to the non-timed task type provided in the embodiments of this application;

[0051] Figure 9(b) is a schematic diagram of the state transition of the target timed task corresponding to the timed task type provided in the embodiments of this application;

[0052] Figure 10 This is a schematic diagram of an automation framework used to implement embodiments of this application;

[0053] Figure 11 This is a flowchart illustrating another method for testing distributed services provided in an embodiment of this application;

[0054] Figure 12 This is a flowchart illustrating another method for testing distributed services provided in an embodiment of this application;

[0055] Figure 13 This is a structural block diagram of a distributed service testing device provided in an embodiment of this application;

[0056] Figure 14 This is a hardware structure block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0058] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0059] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0060] For distributed services, it is necessary to simulate various abnormal scenarios to conduct fault testing. Fault testing in related technologies uses various commands to simulate resource anomalies, such as high CPU (Central Processing Unit) usage, high memory usage, network disconnection, and out-of-order delivery. On the other hand, it uses code injection technology to simulate abnormal behavior of each node. However, both of these methods are one-time, meaning that injecting an abnormal scenario into a node can only perform one test. This results in low efficiency, poor flexibility, and high time cost for fault testing of different abnormal scenarios.

[0061] In view of this, this application provides a testing method for distributed services. This method obtains an abnormal scenario set corresponding to the distributed service by acquiring abnormal scenario information from the business nodes of the distributed service, and combines multiple target abnormal scenario information in the abnormal scenario set to obtain combined abnormal scenario information. Based on the combined abnormal scenario information, the target business nodes corresponding to each target abnormal scenario information are triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information to realize the activation of the combined abnormal scenario. Then, the business test cases of the distributed service are executed under the combined abnormal scenario to obtain the business test results corresponding to the combined abnormal scenario. Thus, the distributed service can be automatically tested under the combined abnormal scenario based on the required combined abnormal scenario, realizing one injection and multiple implementations, improving the fault testing efficiency for different abnormal scenarios of distributed services, greatly improving testing flexibility, and reducing testing time and cost.

[0062] It should be noted that the distributed services in this application can be a distributed system formed by connecting clients and multiple nodes (any form of computing device in the network, such as servers and user terminals) through network communication, such as a distributed system based on event-driven architecture (EDA).

[0063] Please see Figure 1 The diagram shown is an implementation environment provided in the embodiment of this application. The implementation environment may include a test server 110 and a distributed system 120. The test server 110 and the distributed system 120 can communicate through a network, which can be a wired network or a wireless network.

[0064] Specifically, the distributed system 120 provides distributed services, and the test server 110 can perform fault testing on the distributed services. The fault testing mainly tests the stability of the distributed services by simulating various abnormal scenarios, thereby detecting whether there are any abnormalities in the distributed services.

[0065] Taking a distributed system as an example, see blockchain system. Figure 2 , Figure 2This is an optional structural diagram of a distributed system applied to a blockchain system, as provided in this application embodiment. It consists of multiple nodes (any form of computing device connected to the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0066] See Figure 2 The functions of each node in the blockchain system shown include:

[0067] 1) Routing: A basic function of nodes used to support communication between nodes.

[0068] In addition to routing capabilities, nodes can also have the following functions:

[0069] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0070] For example, the business logic implemented by the application includes:

[0071] 2.1) A wallet is used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0072] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0073] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0074] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0075] See Figure 3 , Figure 3 This is an optional schematic diagram of the block structure provided in this application embodiment. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0076] It should be noted that the terminals in this application embodiment include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0077] Please see Figure 4 The diagram shown is a flowchart illustrating a testing method for distributed services provided in an embodiment of this application. This method can be applied to... Figure 1The test server in the document. It should be noted that this specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many, and does not represent the only execution order. In actual system or product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 4 As shown, the method may include:

[0078] S401: Obtain abnormal scenario information from the business nodes of the distributed business to obtain the set of abnormal scenarios corresponding to the distributed business.

[0079] The abnormal scenario information represents the abnormal scenarios injected into the corresponding business nodes. These abnormal scenarios are implemented based on abnormal logic code used to simulate abnormal scenarios. Taking distributed business as a blockchain business as an example, abnormal scenarios can include block anomalies, transaction anomalies, network packet tampering, network latency, panic anomalies, etc.

[0080] The abnormal scenario information can include the node identifier of the business node and the abnormal scenario identifier. The node identifier uniquely identifies a specific business node, and the abnormal scenario identifier uniquely identifies the abnormal scenario simulated by a specific abnormal logic code. For example, the abnormal scenario information can be represented as {Node ID, Abnormal Scenario ID}.

[0081] Among them, the abnormal scenario set corresponding to the distributed business is used to store the abnormal scenario information obtained from each business node of the distributed business. Each abnormal scenario information represents an abnormal scenario injected into the corresponding business node.

[0082] The abnormal scenario injected into the business node can be stored in the business node as a binary target executable file. The target executable file is obtained by compiling a business code package that has been injected with the abnormal logic code. This business code package is used to implement the distributed business. To facilitate subsequent business nodes in quickly finding the abnormal scenario that needs to be activated, the abnormal scenario information can, for example, also include the executable file identifier of the target executable file. That is, the abnormal scenario information can be represented as {node ID, executable file ID, abnormal scenario ID}.

[0083] Based on this, in an exemplary embodiment, the method may further include steps related to injecting abnormal scenarios into the business nodes of the distributed service; that is, the method may further include... Figure 5 The following steps are included:

[0084] S501: Obtain the exception logic code to be injected from the exception logic code set.

[0085] The different exception logic codes in the exception logic code set are used to simulate different exception scenarios. In specific implementation, the different exception scenarios can be determined based on the actual distributed business. Taking blockchain business as an example, the exception logic code set may include exception logic code 1 for simulating panic exception, exception logic code 2 for simulating network latency, exception logic code 3 for simulating network packet tampering, exception logic code 4 for simulating block exception, and exception logic code 5 for simulating transaction exception, etc.

[0086] The exception logic code to be injected can be selected from the exception logic code set based on actual needs.

[0087] S503 injects the exception logic code to be injected into the business code package corresponding to the distributed business.

[0088] Among them, the business code package is used to implement distributed business; for example, the business code package can be a code package used to implement blockchain business.

[0089] In practical applications, you can first determine the instrumentation point in the business code package based on the abnormal scenario corresponding to the abnormal logic code to be injected, and then inject the abnormal logic code to be injected at that instrumentation point.

[0090] For example, exception logic code can be injected at instrumentation points based on the fault simulation tool FailPoint. FailPoint is a Golang implementation of FreeBSD failpoints, which can inject errors or exception behaviors into the code to simulate error handling in various complex systems to improve the fault tolerance, correctness and stability of the system. Specifically, failpoint.Inject can be used to inject a failpoint (a code snippet simulating an exception) at the call site.

[0091] S505 compiles the injected business code package to obtain the target executable file.

[0092] The target executable file is a binary file.

[0093] In practice, when compiling the injected business code package, the code file containing the injected exception logic code can be compiled first to obtain an intermediate file. Then, the intermediate file and the remaining code files in the business code package can be compiled to obtain the target executable file.

[0094] S507, the aforementioned target executable file is sent to the business nodes of the distributed business to inject the abnormal scenario simulated by the abnormal logic code to be injected into the corresponding business nodes.

[0095] In practice, the business nodes in the distributed service that are used to receive the target executable file can be identified first, and then the target executable file can be sent to these business nodes.

[0096] Understandably, the selection of the business node to receive the target executable file can be determined based on the actual distributed business scenario. Taking the distributed business scenario of BFT (Byzantine Fault Tolerance) consensus as an example, assuming that the blockchain business includes n business nodes, when the BFT consensus scenario has more than 2n / 3 Byzantine nodes, more than 2n / 3 business nodes can be selected from the n business nodes as the business nodes to receive the target executable file; when the BFT consensus scenario has fewer than 2n / 3 Byzantine nodes, fewer than 2n / 3 business nodes can be selected from the n business nodes as the business nodes to receive the target executable file.

[0097] In practical applications, relevant parameters for the delivery of the target executable file can be obtained, such as the type and number of business nodes. Based on these parameters, the business nodes that receive the target executable file can be determined, and then the target executable file can be delivered to these business nodes. This allows the abnormal scenarios corresponding to the target executable file (i.e., the abnormal scenarios simulated by the abnormal logic code injected into the target executable file) to be injected into these business nodes.

[0098] Understandably, a single business node can inject multiple executable files corresponding to different exception scenarios as needed, thus allowing different exception scenarios to be injected into the same business node. For example, business node A can inject transaction exception scenarios, block exception scenarios, etc.

[0099] It should be noted that, based on the above steps S501 to S507, the corresponding abnormal scenarios can be injected into the corresponding business nodes of the distributed business. However, these abnormal scenarios are still in a closed or inactive state and will not cause the distributed business to enter the corresponding abnormal scenarios.

[0100] In one exemplary implementation, the test server may obtain abnormal scenario information from the service nodes of the distributed service, including, for example: Figure 6 The following steps are shown:

[0101] S601 sends anomaly scenario query requests to the business nodes of the distributed business at preset time intervals.

[0102] The abnormal scenario query request is used to request information about abnormal scenarios. The preset time interval can be set according to actual needs; for example, an abnormal scenario query request can be sent to each business node of the distributed business every 1 minute or 3 minutes.

[0103] S603 receives the query results returned by the business node of the distributed service in response to the above-mentioned abnormal scenario query request.

[0104] S605, when the query result indicates the existence of a new injection exception scenario, store the exception scenario information in the query result into the specified storage space to obtain the exception scenario set corresponding to the distributed service.

[0105] Among them, newly injected abnormal scenarios refer to abnormal scenarios injected within the aforementioned preset time interval.

[0106] Specifically, the test server can send abnormal scenario information query requests to each business node of the distributed service at preset time intervals. After receiving the abnormal scenario information query request, each business node obtains the current abnormal scenario identifier (e.g., failpointname) based on the target executable file stored locally, and generates query results based on the current abnormal scenario identifier.

[0107] When generating query results, each business node can determine whether the current abnormal scenario identifier is an identifier of an abnormal scenario newly injected into the business node within a preset time interval. If so, it can generate abnormal scenario information based on the current abnormal scenario identifier and the node identifier, and generate query results indicating the existence of a newly injected abnormal scenario based on the abnormal scenario information. It can be understood that the abnormal scenario information in the query results indicates an abnormal scenario newly injected into the business node. Conversely, if the current abnormal scenario identifier is not an identifier of an abnormal scenario newly injected into the business node within a preset time interval, it can generate query results indicating that no new abnormal scenario has been injected.

[0108] In the above implementation, the test server sends abnormal scenario query requests to the business nodes of the distributed service at preset time intervals, and receives the query results returned by the business nodes of the distributed service in response to the abnormal scenario query requests. Then, when the query results indicate that a new injected abnormal scenario exists, the abnormal scenario information in the query results is stored in a designated storage to obtain the abnormal scenario set corresponding to the distributed service. This enables dynamic detection of abnormal scenarios in each business node, ensuring that the abnormal scenario set corresponding to the distributed service can cover the abnormal scenarios injected on each business node, which is beneficial to improving the comprehensiveness of subsequent fault testing based on the abnormal scenario set.

[0109] In one exemplary implementation, to ensure the accuracy of subsequent fault testing based on this set of abnormal scenarios, please refer to [link to relevant documentation]. Figure 6 The method may also include:

[0110] S607: When the query result indicates that an abnormal scenario should be deleted, the set of abnormal scenarios corresponding to the distributed service should be updated based on the information of the deleted abnormal scenario.

[0111] Specifically, when generating query results at preset time intervals, if each business node detects that one or more target executable files have been deleted, it can obtain the abnormal scenario identifier corresponding to the abnormal logic code in these deleted target executable files. Based on the abnormal scenario identifier and the node identifier, it generates query results indicating the deletion of abnormal scenarios. After receiving the query results indicating the deletion of abnormal scenarios, the test server parses the query results to obtain the deleted abnormal scenario information, and then deletes the deleted abnormal scenario information from the abnormal scenario set corresponding to the distributed business. This achieves timely updates to the abnormal scenario set and ensures the success rate of subsequent fault tests based on the abnormal scenario set.

[0112] S403, combine multiple target abnormal scene information from the abnormal scene set to obtain combined abnormal scene information.

[0113] The aforementioned combined abnormal scenario information includes multiple target abnormal scenario information, which can be determined based on actual fault testing needs.

[0114] In one implementation, the test server can respond to a combined abnormal scenario configuration command by displaying abnormal scenario information from a set of abnormal scenarios through an associated display device, and respond to a selection command to determine multiple target abnormal scenario information to be selected. Then, it can combine these multiple target abnormal scenario information to obtain combined abnormal scenario information. For example, combined abnormal scenario information can be represented as {(node ​​ID1, executable file ID1, abnormal scenario ID1), (node ​​ID2, executable file ID2, abnormal scenario ID2)}. It is understood that based on the abnormal scenario set and actual fault testing requirements, multiple combined abnormal scenario information indicating different combined abnormal scenarios can be obtained, resulting in a set of combined abnormal scenario information.

[0115] In another implementation, the test server can automatically combine the abnormal scene information in the abnormal scene set based on preset combination rules, thereby automatically combining multiple combined abnormal scene information indicating different combined abnormal scenes, and obtaining a combined abnormal scene information set.

[0116] For example, for each combined abnormal scene information in the combined abnormal scene information set, a corresponding combined abnormal scene identifier can be configured to uniquely identify a combined abnormal scene, such as {scene-1, scene-2, ...}, where scene-1 indicates combined abnormal scene 1, scene-2 ​​indicates combined abnormal scene 2, and so on.

[0117] S405, based on the above combined abnormal scenario information, trigger the target business node corresponding to each target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information, so as to activate the corresponding combined abnormal scenario.

[0118] Specifically, the test server can send an exception scenario activation command to the target service node corresponding to each target exception scenario information based on the combined exception scenario information. This allows the target service node to activate the exception scenario indicated by the exception scenario identifier in the corresponding target exception scenario information in response to the exception scenario activation command. When all target exception scenarios corresponding to each target service node are activated, the combined exception scenario is activated.

[0119] Understandably, the abnormal scenario activation instruction can carry the corresponding executable file identifier and abnormal scenario identifier. The corresponding target business node finds the target executable file based on the executable file identifier, and then activates the abnormal logic code in the target executable file based on the abnormal scenario identifier. Once the abnormal logic code is activated, it can be executed when the target executable file is executed, thereby causing the corresponding target business node to enter the abnormal scenario simulated by the abnormal logic code. When all target business nodes enter the corresponding abnormal scenario, the distributed business enters the corresponding combined abnormal scenario.

[0120] For example, suppose the combined abnormal scenario information is {(node ​​ID1, executable file ID1, abnormal scenario ID1), (node ​​ID2, executable file ID2, abnormal scenario ID2)}. Then the test server will trigger business node 1 to activate the abnormal logic code 1 in executable file 1 (i.e., the abnormal logic code indicated by abnormal scenario ID1), causing business node 1 to enter abnormal scenario 1. It will also trigger business node 2 to activate the abnormal logic code 2 in executable file 2 (i.e., the abnormal logic code indicated by abnormal scenario ID2), causing business node 2 to enter abnormal scenario 2. Thus, the combined abnormal scenarios activated are: business node 1 - abnormal scenario 1 & business node 2 - abnormal scenario 2.

[0121] Understandably, the combined anomaly scenario information in this step indicates the combined anomaly scenarios that need to be tested for faults. When there are multiple combined anomaly scenario information indicating different combined anomaly scenarios in the test server, the target combined anomaly scenario information can be determined in response to the selection instruction of the combined anomaly scenario. Then, in this step, the target business node corresponding to each target anomaly scenario information in the target combined anomaly scenario information is activated to enable the distributed business to enter the corresponding target combined anomaly scenario.

[0122] As an example, the test server can generate a one-to-one distributed transaction based on multiple target abnormal scenario information in the combined abnormal scenario information. Each distributed transaction is used to instruct the corresponding target business node to activate the corresponding target abnormal scenario, and then send each distributed transaction to the corresponding target business node.

[0123] S407, Execute the business test cases for distributed services under the above combined abnormal scenarios, and obtain the business test results corresponding to the combined abnormal scenarios.

[0124] Among them, the business test cases for distributed services refer to normal automated test cases. Taking distributed services as blockchain services as an example, the business test cases can include transaction data recording, block generation, block uploading, etc.

[0125] The business test results may include abnormal operation logs generated at each target business node. In practical applications, the business test results can be presented in the form of test reports to facilitate testers in locating specific problems.

[0126] In one exemplary implementation, after obtaining the business test results corresponding to the combined abnormal scenario, the test server can also send an instruction to each target business node to close the corresponding target abnormal scenario, so that each target business node responds to the relevant instruction to close the corresponding target abnormal scenario, thereby closing the current combined abnormal scenario.

[0127] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application automatically discover injected abnormal scenarios, store injected abnormal scenarios, and combine scenarios based on stored abnormal scenario information, and automatically test distributed services under combined abnormal scenarios, which improves the fault testing efficiency for different abnormal scenarios of distributed services. Moreover, one abnormal scenario injection can be implemented multiple times, greatly improving testing flexibility and significantly reducing testing time and testing costs.

[0128] In one exemplary implementation, to further improve the accuracy and automation of fault testing, such as Figure 7 As shown, step S405 above may include the following steps when implemented:

[0129] S701, determine the task type corresponding to the above combined abnormal scenario information.

[0130] The task type can include scheduled task type and non-scheduled task type.

[0131] In one implementation, the test server can search for target timing information corresponding to the combined abnormal scenario information. If found, the task type corresponding to the combined abnormal scenario information is a scheduled task type; otherwise, if not found, the task type corresponding to the combined abnormal scenario information is a non-scheduled task type. The target timing information can be time information obtained by the test server in response to the timing configuration for the combined abnormal scenario information, and this time information can be set according to the actual fault testing needs.

[0132] In another implementation, the test server can obtain the abnormal scenario identifiers in the combined abnormal scenario information, and determine the task type of the combined abnormal scenario information based on the abnormal scenario identifiers and the timed scenario configuration information. The timed scenario configuration information represents the abnormal scenario that needs to be executed at a time. For example, it may include multiple preset abnormal scenario identifiers, each of which indicates the abnormal scenario that needs to be executed at a time. If all the abnormal scenario identifiers in the combined abnormal scenario information match the timed scenario configuration information, it indicates that the combined abnormal scenario information is a timed task type. Conversely, if not all the abnormal scenario identifiers in the combined abnormal scenario information match the timed scenario configuration information, it indicates that the combined abnormal scenario information is a non-timed task type.

[0133] Specifically, if the task type corresponding to the combined abnormal scenario information is a scheduled task type, then the following steps S703 to S705 can be executed; if the task type corresponding to the combined abnormal scenario information is a non-scheduled task type, then the following steps S707 to S709 can be executed.

[0134] S703, if the task type corresponding to the combined abnormal scenario information is a timed task type, then generate a target timed task based on the combined abnormal scenario information and the target timed information.

[0135] The target timed task indicates that the target business node corresponding to each target abnormal scenario information in the combined abnormal scenario information will be activated at the target time, and the target time is the time indicated by the target timed information.

[0136] S705, when the target time is reached, execute the target timed task.

[0137] Specifically, if the combined abnormal scenario information is a scheduled task type, after generating the corresponding target scheduled task, it is necessary to wait until the system time reaches the above-mentioned target time before the test server executes the target scheduled task, thereby triggering each target business node to activate the corresponding target abnormal scenario, and thus causing the distributed business to enter the combined abnormal scenario.

[0138] S707, if the task type corresponding to the above combined abnormal scenario information is a non-timed task type, then generate a target task based on the combined abnormal scenario information.

[0139] Among them, the target task instruction triggers the target business node corresponding to each target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information.

[0140] S709, execute the aforementioned target task.

[0141] Specifically, if the combined anomaly scenario information is a non-scheduled task type, the target task can be executed directly after the corresponding target task is generated, thereby triggering each target business node to activate the corresponding target anomaly scenario, and thus causing the distributed business to enter the combined anomaly scenario.

[0142] In one exemplary embodiment, step S703 may include the following when implemented:

[0143] Determine the execution order of multiple target abnormal scenario information in the combined abnormal scenario information;

[0144] Based on the above-mentioned multiple target abnormal scenario information, the execution order corresponding to the multiple target abnormal scenario information, and the target timing information, a target timing task is generated.

[0145] Among them, the target timed task indicator triggers the target business node corresponding to each target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information in the target time indicated by the target timed information according to the execution order corresponding to multiple target abnormal scenario information.

[0146] The execution order of multiple target abnormal scenario information can be set based on the actual fault test needs, or it can be obtained by the test server arranging multiple target abnormal scenario information based on preset orchestration rules. The preset encoding rules indicate the order in which multiple target abnormal scenarios are activated, and the multiple target abnormal scenarios are the abnormal scenarios indicated by multiple target abnormal scenario information.

[0147] In specific implementation, the target scheduled task can include multiple target subtasks that correspond one-to-one with multiple target abnormal scenario information, and these multiple target subtasks have the execution order described above. Each target subtask instructs the target business node corresponding to the target abnormal scenario information to activate the target abnormal scenario corresponding to that target abnormal scenario information. When the test server executes the above target scheduled task, it executes each target subtask sequentially based on the execution order of the multiple target subtasks.

[0148] In the above implementation, by determining the execution order and then generating the target timed task based on successful execution, precise control of combined abnormal scenarios can be achieved, thereby improving the accuracy of fault testing for distributed services.

[0149] In a specific implementation scenario, the test server can be configured with an injection scheduler and an injection executor, such as... Figure 8 The diagram illustrates the scheduling and execution of the Inject-Scheduler and Inject-Executor. When the test server determines that the task type corresponding to the combined exception scenario information is a scheduled task, it can send the combined exception scenario information and the corresponding target timing information to the Inject-Scheduler. The Inject-Scheduler then generates a target scheduled task based on the combined exception scenario information and the target timing information and places the target scheduled task in the scheduling queue to wait for execution. When the target time arrives, the Inject-Scheduler sends the target scheduled task to the Inject-Executor to invoke the Inject-Executor to execute the target scheduled task. Conversely, when the test server determines that the task type corresponding to the combined exception scenario information is not a scheduled task, it can directly send the combined exception scenario information to the Inject-Executor, which then generates a target task based on the combined exception scenario information and executes it.

[0150] The injection executor, when executing a task, can do so based on the consistency principle of distributed transactions, thereby triggering each target business node (such as N1, N2, N3, N4, etc.) to activate the corresponding target abnormal scenario. Specifically, the injection executor can send corresponding abnormal scenario activation instructions to each target business node. Each target business node responds to the corresponding abnormal scenario activation instructions, activates the corresponding target abnormal scenario, and can feed back the activation result to the injection executor. This activation result indicates whether the corresponding target abnormal scenario was successfully activated. Thus, the injection executor can determine whether the combined abnormal scenario was successfully activated based on the activation results of each target business node. Specifically, if the activation results of each target business node indicate successful activation, then the combined abnormal scenario was successfully activated; conversely, if the activation result of any target business node indicates failure, then the combined abnormal scenario was not activated.

[0151] In practical applications, the test server can also record the status information of tasks corresponding to combined anomaly scenarios, allowing testers to promptly understand the activation status of combined anomaly scenarios in distributed business processes. For example... Figure 8 As shown, the test server can record task status information through MySQL.

[0152] Specifically, as shown in Figure 9(a), the state transition diagram of the target task corresponding to the non-timed task type is as follows: when the target task is successfully created, the target task is recorded as "initialized" state; when the injected executor starts executing the target task, the target task is recorded as "running" state; when it is determined that the target abnormal scenarios corresponding to each target business node are activated, the target task is recorded as "successful" state; conversely, when it is determined that the target abnormal scenario corresponding to any target business node fails to activate, the target task is recorded as "failed" state.

[0153] Figure 9(b) illustrates the state transition of a target scheduled task corresponding to a scheduled task type. When a target scheduled task is successfully created, it is recorded as "initialized". When the injection scheduler places the successfully created target scheduled task into the scheduling queue, it is recorded as "waiting". When the injection scheduler successfully calls the injection executor to start executing the target scheduled task, it is recorded as "running". When it is determined that all target abnormal scenarios corresponding to each target business node are activated, the target scheduled task is recorded as "successful". Conversely, when it is determined that the activation of any target abnormal scenario corresponding to any target business node fails, the target scheduled task is recorded as "failed". Additionally, when the injection scheduler's call to the injection executor fails, the target scheduled task is recorded as "failed".

[0154] In a specific application scenario, the technical solution of this application embodiment can be implemented as follows: Figure 10 The automated framework shown is used to perform fault testing on the consensus mechanism of blockchain projects.

[0155] like Figure 10As shown, the exception injection library of the automation framework stores multiple exception logic codes simulating different exception scenarios. These scenarios can include panic, network latency, network packet tampering, block anomalies, transaction anomalies, and so on. The injection module of the automation framework can inject these exception scenarios into the consensus nodes of the blockchain. The injection discovery module (Inject-Ping) of the automation framework can detect the injection of exception scenarios into consensus nodes and store the detected exception scenario information in the database of the storage layer. The injection scenario management module (Inject-Scene) of the automation framework can query the static exception scenario information in the database and assemble the queried exception scenario information into combined exception scenario use cases (such as scene-1, scene-2, etc.). The injection scheduler (Inject-Scheduler) of the automation framework provides scheduling and orchestration services for combined exception scenario use cases of scheduled task types; see the aforementioned section for details. Figure 8 The corresponding description is provided, and the injection executor is invoked to perform exception execution when the scheduled time arrives. The injection executor of the automation framework is used to trigger the failure point of the consensus node corresponding to the task to start or stop abnormally. Figure 10 In this context, the SPV domain refers to at least one node responsible for payment verification, and the consensus domain refers to at least one node responsible for reaching a consensus mechanism.

[0156] To facilitate a better understanding of the technical solutions of the embodiments of this application, the following examples illustrate some specific steps and implementation methods involved in the actual testing process.

[0157] Within the iteration cycle of the product under test corresponding to the distributed business, R&D engineers submit the developed distributed business project to the REQ platform (i.e., the software development and testing process management platform), triggering test execution. After completing basic functional testing, testers can begin fault testing. Fault testing primarily simulates various abnormal scenarios to test the stability of the distributed business project, thereby detecting whether any anomalies exist. For fault testing of distributed businesses, the following methods can be used: Figure 11 or Figure 12 The automated testing process shown includes, Figure 12 It also shows some other steps related to the testing process.

[0158] like Figure 11 or Figure 12 As shown, the testing process for the distributed business project under test by the test server is as follows:

[0159] 1) Pull the project under test (i.e. the source code corresponding to the distributed business project under test) from the distributed version control system Git, query the failpoint fault name (i.e. the abnormal logic code to be injected, which can be logic code written based on historical abnormal scenarios) from the specified abnormal logic code set, inject the FailPoint-inject instrumentation point, inject the abnormal logic code to be injected into the instrumentation point, enable it, and generate intermediate files.

[0160] 2) Automatically compile the injected project file to generate an executable file;

[0161] 3) Submit the relevant parameters for the executable file distribution, select to deploy it to multiple business nodes, and deploy automatically.

[0162] 4) The automated framework performs injection discovery, remotely confirms various fault points (i.e., abnormal scenario information) under the distributed business nodes, and stores them in the database;

[0163] 5) Combine the statically injected fault points in the database to obtain combined scenario use cases;

[0164] 6) The injection scheduler selects the appropriate scenario use case and starts the injection executor to start or shut down the fault points of the distributed business nodes;

[0165] 7) At the same time, the automated test cases (i.e. business test cases) of the project under test are also being executed. Under the triggering of various abnormal scenarios, the functional test cases are run in batches to generate corresponding test reports, which makes it easier for testers to locate problems.

[0166] The above testing method is equivalent to layering the entire test execution process into an atomic layer (i.e., the exception injection library layer), a storage layer, a discovery layer, a composite scenario layer, a scheduling layer, and an execution layer. In the testing phase, the atomic layer queries for the faults to be injected and injects them into the source code of the project under test. Then, the discovery layer dynamically queries the fault information under the distributed nodes and assembles them into composite scenario test cases as needed. Finally, the scheduler and executor implement the faults in the distributed transactions, thus forming a fully automated process for precise exception injection testing. This allows for one-time injection and multiple implementations, reducing costs and improving efficiency, while also enhancing the precise control of fault testing.

[0167] Corresponding to the distributed service testing methods provided in the above embodiments, this application also provides a distributed service testing apparatus. Since the distributed service testing apparatus provided in this application corresponds to the distributed service testing methods provided in the above embodiments, the implementation methods of the aforementioned distributed service testing methods are also applicable to the distributed service testing apparatus provided in this embodiment, and will not be described in detail in this embodiment.

[0168] Please see Figure 13 The diagram shows a schematic representation of a distributed service testing device provided in an embodiment of this application. This device has the function of implementing the distributed service testing method described in the above method embodiments. This function can be implemented in hardware or by hardware executing corresponding software. Figure 13 As shown, the testing device 1300 for this distributed service may include:

[0169] The abnormal scenario information acquisition module 1310 is used to acquire abnormal scenario information from the business nodes of the distributed business to obtain the abnormal scenario set corresponding to the distributed business; the abnormal scenario information represents the abnormal scenario injected into the corresponding business node; the abnormal scenario is implemented based on the abnormal logic code used to simulate the abnormal scenario.

[0170] The scene combination module 1320 is used to combine multiple target abnormal scene information in the abnormal scene set to obtain combined abnormal scene information; the combined abnormal scene information includes the multiple target abnormal scene information.

[0171] The combined scenario activation module 1330 is used to trigger the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information based on the combined abnormal scenario information, so as to activate the corresponding combined abnormal scenario.

[0172] The test module 1340 is used to execute business test cases of the distributed service under the combined abnormal scenario and obtain the business test results corresponding to the combined abnormal scenario.

[0173] In one exemplary implementation, the combined scene activation module includes:

[0174] The task type determination module is used to determine the task type corresponding to the combined abnormal scenario information; the task type includes timed task type and non-timed task type.

[0175] A scheduled task generation module is used to generate a target scheduled task based on the combined abnormal scenario information and the target timing information when the task type is a scheduled task type; the target scheduled task indicates that the target business node corresponding to each of the target abnormal scenario information will be triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information at a target time; the target time is the time indicated by the target timing information;

[0176] The scheduled task execution module is used to execute the target scheduled task when the target time is reached.

[0177] In one exemplary embodiment, the scheduled task generation module includes:

[0178] The execution order determination module is used to determine the execution order of multiple target abnormal scenario information in the combined abnormal scenario information;

[0179] The scheduled task generation submodule is used to generate a target scheduled task based on the multiple target abnormal scenario information, the execution order of the multiple target abnormal scenario information, and the target timing information.

[0180] The target timed task instruction triggers the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information in accordance with the execution order at the target time.

[0181] In one exemplary embodiment, the combined scene activation module further includes:

[0182] The task generation module is used to generate a target task based on the combined abnormal scenario information when the task type is a non-timed task type; the target task indicates that the target business node corresponding to each of the target abnormal scenario information should be activated to activate the target abnormal scenario corresponding to the target abnormal scenario information.

[0183] The task execution module is used to execute the target task.

[0184] In one exemplary embodiment, the abnormal scene information acquisition module includes:

[0185] The query module is used to send abnormal scenario query requests to the business nodes of the distributed service at preset time intervals;

[0186] The query result receiving module is used to receive the query results returned by the business nodes of the distributed service in response to the query request in the abnormal scenario;

[0187] The storage module is used to store the abnormal scenario information in the query result into a designated storage space when the query result indicates the existence of a newly injected abnormal scenario, so as to obtain the abnormal scenario set corresponding to the distributed service; wherein, the newly injected abnormal scenario refers to the abnormal scenario injected within the preset time interval.

[0188] In one exemplary embodiment, the abnormal scene information acquisition module further includes:

[0189] The update module is used to update the set of abnormal scenarios corresponding to the distributed service based on the information of the deleted abnormal scenarios when the query result indicates that the abnormal scenarios should be deleted.

[0190] In one exemplary embodiment, the apparatus further includes:

[0191] An atomic acquisition module is used to acquire the exception logic code to be injected from the exception logic code set; different exception logic codes in the exception logic code set are used to simulate different exception scenarios.

[0192] The code injection module is used to inject the exception logic code to be injected into the business code package corresponding to the distributed business.

[0193] The compilation module is used to compile the injected business code package to obtain the target executable file;

[0194] An abnormal scenario injection module is used to send the target executable file to the business node of the distributed service, so as to inject the abnormal scenario simulated by the abnormal logic code to be injected into the business node.

[0195] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0196] This application provides an electronic device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement any of the distributed service testing methods provided in the above method embodiments.

[0197] Memory can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. Memory can primarily include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for the functions, etc.; the data storage area can store data created based on the use of the device, etc. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory can also include a memory controller to provide the processor with access to the memory.

[0198] The methods and embodiments provided in this application can be executed in a computer terminal, server, or similar computing device; that is, the aforementioned electronic device may include a computer terminal, server, or similar computing device. Taking running on a server as an example... Figure 14This is a hardware structure block diagram of an electronic device that runs a test method for a distributed service, as provided in an embodiment of this application. Figure 14 As shown, the server 1400 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1410 (CPUs 1410 may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 1430 for storing data, and one or more storage media 1420 (e.g., one or more mass storage devices) for storing application programs 1423 or data 1422. The memory 1430 and storage media 1420 may be temporary or persistent storage. The program stored in the storage media 1420 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 1410 may be configured to communicate with the storage media 1420 and execute the series of instruction operations stored in the storage media 1420 on the server 1400. Server 1400 may also include one or more power supplies 1460, one or more wired or wireless network interfaces 1450, one or more input / output interfaces 1440, and / or one or more operating systems 1421, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0199] The input / output interface 1440 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 1400. In one example, the input / output interface 1440 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one example, the input / output interface 1440 can be a radio frequency (RF) module for wireless communication with the Internet.

[0200] Those skilled in the art will understand that Figure 14 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 1400 may also include... Figure 14 The more or fewer components shown, or having the same Figure 14 The different configurations shown.

[0201] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to a test method for implementing a distributed service. The at least one instruction or the at least one program is loaded and executed by the processor to implement any of the distributed service test methods provided in the above-described method embodiments.

[0202] Embodiments of this application also provide a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform a testing method for distributed services according to any of the above aspects.

[0203] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0204] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0205] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0206] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0207] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A testing method for distributed services, characterized in that, The method includes: Based on the dynamic detection of abnormal scenarios in each business node of the distributed business, abnormal scenario information is obtained from the business nodes of the distributed business to obtain the abnormal scenario set corresponding to the distributed business; the abnormal scenario information represents the abnormal scenarios injected into the corresponding business nodes; the abnormal scenarios are implemented based on abnormal logic code used to simulate abnormal scenarios. Based on the abnormal scene information from multiple target abnormal scene information in the abnormal scene set, scene combination is performed to obtain combined abnormal scene information; the combined abnormal scene information includes the multiple target abnormal scene information. Based on the combined abnormal scenario information, the target business node corresponding to each of the target abnormal scenario information is triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information, so as to activate the corresponding combined abnormal scenario. The business test cases of the distributed service are executed under the combined abnormal scenario to obtain the business test results corresponding to the combined abnormal scenario.

2. The method according to claim 1, characterized in that, The step of triggering the target business node corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information based on the combined abnormal scenario information includes: Determine the task type corresponding to the combined abnormal scenario information; the task type includes scheduled task type and non-scheduled task type. If the task type is a scheduled task type, then a target scheduled task is generated based on the combined abnormal scenario information and the target scheduled information; the target scheduled task indicates that the target business node corresponding to each of the target abnormal scenario information will be triggered to activate the target abnormal scenario corresponding to the target abnormal scenario information at a target time; the target time is the time indicated by the target scheduled information. When the target time is reached, the target timed task is executed.

3. The method according to claim 2, characterized in that, The step of generating a target timed task based on the combined abnormal scenario information and target timing information includes: Determine the execution order of multiple target abnormal scenario information in the combined abnormal scenario information; A target timed task is generated based on the multiple target abnormal scenario information, the execution order of the multiple target abnormal scenario information, and the target timing information. The target timed task instruction triggers the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information in accordance with the execution order at the target time.

4. The method according to claim 2, characterized in that, The method further includes: If the task type is a non-scheduled task type, then a target task is generated based on the combined abnormal scenario information; the target task indicates that the target business node corresponding to each of the target abnormal scenario information is triggered to activate the target abnormal scenario corresponding to the corresponding target abnormal scenario information. Perform the target task.

5. The method according to any one of claims 1 to 4, characterized in that, The method involves dynamically detecting abnormal scenarios in each service node of a distributed service, obtaining abnormal scenario information from the service nodes of the distributed service, and obtaining a set of abnormal scenarios corresponding to the distributed service, including: An abnormal scenario query request is sent to the business node of the distributed service at a preset time interval; Receive the query results returned by the business node of the distributed service in response to the query request for the abnormal scenario; When the query result indicates the existence of a newly injected abnormal scenario, the abnormal scenario information in the query result is stored in a designated storage space to obtain the abnormal scenario set corresponding to the distributed service; wherein, the newly injected abnormal scenario refers to the abnormal scenario injected within the preset time interval.

6. The method according to claim 5, characterized in that, The method further includes: When the query result indicates that an abnormal scenario should be deleted, the set of abnormal scenarios corresponding to the distributed service is updated based on the information of the deleted abnormal scenario.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the exception logic code to be injected from the exception logic code set; different exception logic codes in the exception logic code set are used to simulate different exception scenarios; Inject the exception logic code to be injected into the business code package corresponding to the distributed business; The injected business code package is compiled to obtain the target executable file; The target executable file is sent to the business node of the distributed service to inject the abnormal scenario simulated by the abnormal logic code to be injected into the business node.

8. A testing device for distributed services, characterized in that, The device includes: An abnormal scenario information acquisition module is used to acquire abnormal scenario information from the business nodes of the distributed business based on the dynamic detection of abnormal scenarios in each business node of the distributed business, and obtain an abnormal scenario set corresponding to the distributed business; the abnormal scenario information represents the abnormal scenarios injected into the corresponding business nodes; the abnormal scenarios are implemented based on abnormal logic code used to simulate abnormal scenarios. The scene combination module is used to combine multiple target abnormal scene information from the abnormal scene set to obtain combined abnormal scene information; the combined abnormal scene information includes the multiple target abnormal scene information. The combined scenario activation module is used to trigger the target business nodes corresponding to each of the target abnormal scenario information to activate the target abnormal scenario corresponding to the target abnormal scenario information based on the combined abnormal scenario information, so as to activate the corresponding combined abnormal scenario. The testing module is used to execute business test cases of the distributed service under the combined abnormal scenarios and obtain business test results corresponding to the combined abnormal scenarios.

9. An electronic device, characterized in that, The method includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the test method for distributed services as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the test method for distributed services as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, The system includes a computer program that, when executed by a processor, implements the testing method for the distributed services described in any one of claims 1 to 7.

Images