Software system risk checking method, device and system based on fault simulation

Abstract

The invention discloses a software system risk troubleshooting method, device and equipment based on fault simulation and a storage medium, and relates to the field of software testing, and the method comprises the following steps: obtaining a service link topological graph of a software system to be troubleshot; analyzing data of each node in the service link topological graph; generating a chaos test task of each node according to each node data in the service link topological graph; and executing a chaos test task of each node, and determining whether each node is a high-risk node according to a chaos test result. The scheme provided by the invention provides an automatic risk checking scheme for the software system.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a software system risk troubleshooting method, device, equipment and storage medium based on fault simulation. Background Art

[0002] With the continuous evolution of distributed systems, a large number of core applications have migrated from traditional mainframes to distributed platform architectures. Compared with large mainframes, distributed architectures are more complex and challenging. Massive nodes, heterogeneous machines, unreliable networks, and widespread node failures have brought about uncertainty, placing higher demands on the reliability of systems and applications.

[0003] In the actual business production and operation process, there will be a variety of production problems caused by failures in the underlying infrastructure, such as disk failures, switch failures, etc. Traditional testing has limited capabilities and means in this regard and cannot provide good protection. At this time, a new technical capability is needed to inject different types of failures into the nodes in the distributed system to simulate the failure scenarios in production, discover and fix potential reliability problems, and improve the high availability of the system. For this reason, chaos engineering came into being. Chaos engineering aims to randomly inject various types of failures into the target system, observe the performance of the system under failures, and then trace back the system problems through the performance to help verify the defects related to the high availability of the system.

[0004] However, judging from the industry's usage, chaos engineering still has the pain point of being more dependent on the experience of testers. In the process of version iteration, core business systems often encounter problems such as inaccurate registration of service interface call relationships and inability to clearly evaluate upstream and downstream dependencies. This makes it difficult for testers to keep chaos cases complete and intact, and also makes it difficult to continuously protect system risks. Summary of the invention

[0005] The present invention provides a software system risk troubleshooting method, device, equipment and storage medium based on fault simulation, and provides an automatic risk troubleshooting solution for the software system.

[0006] According to one aspect of the present invention, a software system risk troubleshooting method based on fault simulation is provided, comprising:

[0007] Obtain the business link topology diagram of the software system to be checked;

[0008] Analyze the data of each node in the business link topology diagram;

[0009] Generate chaos test tasks for each node based on the data of each node in the business link topology diagram;

[0010] Execute chaos test tasks for each node and determine whether each node is a high-risk node based on the chaos test results.

[0011] In one embodiment, after obtaining the service link topology diagram of the software system to be checked, the method further includes:

[0012] If the current business of the software system to be checked has no business link topology diagram, the risk troubleshooting process ends.

[0013] In one embodiment, parsing each node data in the service link topology diagram includes:

[0014] Analyze the service link topology diagram and obtain each node in the service link topology diagram and service-related parameters of each node.

[0015] In one embodiment, generating a chaos test task for each node according to the data of each node in the service topology diagram includes:

[0016] Generate chaos test tasks for each node according to the business-related parameters of each node in the business link topology diagram;

[0017] Add matching chaos test cases to the chaos test tasks of each node.

[0018] In one embodiment, the chaos test cases are multiple test cases based on different types of fault simulations of chaos test tasks.

[0019] In one embodiment, executing a chaos test task of each node and determining whether each node is a high-risk node according to the chaos test result includes:

[0020] Execute chaos testing tasks on each node to determine changes in key business-related indicators;

[0021] If the change range of key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a high-risk node.

[0022] In one embodiment, after executing the chaos test task of each node and determining the change of key indicators related to the business, the following is further included:

[0023] If the change range of key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a low-risk node.

[0024] According to another aspect of the present invention, a software system risk troubleshooting device based on fault simulation is provided, comprising:

[0025] An acquisition module is used to obtain a business link topology diagram of the software system to be checked;

[0026] The parsing module is used to parse the data of each node in the service link topology diagram;

[0027] A generation module is used to generate a chaos test task for each node according to the data of each node in the service link topology diagram;

[0028] The execution module is used to execute the chaos test task of each node and determine whether each node is a high-risk node according to the chaos test result.

[0029] According to another aspect of the present invention, there is provided an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0030] Memory stores computer-executable instructions;

[0031] The processor executes the computer execution instructions stored in the memory to implement the above-mentioned software system risk troubleshooting method based on fault simulation.

[0032] According to another aspect of the present invention, a computer program product is provided, including a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and at least one processor implements the above-mentioned software system risk troubleshooting method based on fault simulation when executing the computer program.

[0033] The technical solution of the embodiment of the present invention first obtains the business link topology map of the software system to be checked, then parses the data of each node in the business link topology map, generates the chaos test task of each node according to the data of each node in the business link topology map, and finally executes the chaos test task of each node, and determines whether each node is a high-risk node according to the chaos test result. Since the business link topology map based on the software system reflects the relevant conditions of each node related to the business, the high-risk nodes in the software system can be accurately checked by testing the software system according to the chaos test tasks of each node generated by the business link topology map, which provides an automatic risk checking solution for the software system and solves the problem that the tester cannot accurately locate the module with high risk of the system version during the version iteration process. .

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

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

[0036] Figure 1 A schematic diagram of a flow chart of a software system risk troubleshooting method based on fault simulation provided by an embodiment of the present invention;

[0037] Figure 2 A schematic diagram of a business link topology diagram of a transaction business;

[0038] Figure 3 A flowchart of another software system risk troubleshooting method based on fault simulation provided by an embodiment of the present invention;

[0039] Figure 4 A schematic diagram of the structure of a software system risk troubleshooting device based on fault simulation provided by an embodiment of the present invention;

[0040] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiment of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiment of the present invention. Obviously, the described embodiment is only an embodiment of a part of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work should fall within the scope of protection of the present invention. The acquisition, storage, use, and processing of data in the technical scheme of this application comply with the relevant provisions of national laws and regulations.

[0042] Figure 1 A flowchart of a software system risk troubleshooting method based on fault simulation is provided in an embodiment of the present invention, such as Figure 1 As shown, the software system risk troubleshooting method based on fault simulation provided in this embodiment includes:

[0043] Step S110, obtaining a service link topology diagram of the software system to be checked.

[0044] The software system risk troubleshooting method based on fault simulation provided in the embodiment of the present application is applied to any computer or server with processing capability, the computer or server is used to test the software system to be troubleshooted, the computer or server is a computer or server that deploys the software system, or is a computer or server dedicated to testing the software system. The computer or server can be deployed locally or in the cloud.

[0045] The current computer system architecture has widely used distributed systems. When a software system running on a distributed system executes business processing, different physical nodes may execute the corresponding processing. Therefore, different physical nodes may execute the business. At the software level, a software system may be composed of different software modules, and multiple different software modules may be involved in the execution of business processing. Since a variety of different hardware nodes or software modules are involved, higher requirements are placed on the reliability of the software system. Traditional testing methods are difficult to deal with software systems with many nodes, so chaos testing methods are introduced. However, for chaos testing methods, traditional testing methods rely on the experience of testers. Testers need to design chaos testing tasks and construct chaos testing cases. It is difficult to accurately reflect the complete process of the software system when executing business, so the test cannot fully test the software system.

[0046] In the embodiment of the present application, it is proposed to test the software system based on the business link topology of the software system. First, the business link topology of the software system to be checked is obtained. The business link topology is a plurality of software or hardware nodes that the software system to be checked passes when executing the business. Different businesses of the software system may correspond to different business link topology.

[0047] Figure 2 A schematic diagram of a business link topology diagram of a transaction business, such as Figure 2 As shown, for the transfer service business, two types of risk control services are involved, as well as remittance services, settlement services, public settlement services and databases. Figure 2 Each node involved in the service link topology diagram shown is a software module node.

[0048] For some non-business logic software systems, it may be impossible to obtain the business link topology diagram of the software system to be checked, so the software system risk troubleshooting method based on fault simulation provided in this embodiment cannot automatically troubleshoot the risk, and the risk troubleshooting process ends. Testers can use traditional testing methods to perform risk troubleshooting.

[0049] Step S120, parsing the data of each node in the service link topology diagram.

[0050] After determining the business link topology map corresponding to the business, parse the business link topology map to obtain the data of each node in the business link topology map. Each node data includes the relevant data of each node, such as node name, node type, etc. Each node data also includes various technical parameters such as the service type of the node. The data of each node is used to clarify each node on the one hand, and to generate the chaos test tasks corresponding to each node according to the data on the other hand. Specifically, the business link topology map can be parsed to obtain each node in the business link topology map and the business-related parameters of each node.

[0051] For example, after having a business link topology diagram, we can deeply study each node in the business link topology diagram, and by parsing the multi-way tree, clarify the application name, cluster name, service name, service type, etc. of each link, and then generate a chaos test task.

[0052] Step S130, generating a chaos test task for each node according to the data of each node in the service link topology diagram.

[0053] After parsing the business link topology diagram to obtain the data of each node, the chaos test task of each node can be generated based on the data of each node. The chaos test task of each node is to randomly inject various faults into each node, and determine the performance of each node under various faults based on the test results of each node, so as to determine whether there is a problem in the design of the software system. The chaos test task of each node needs to be generated based on the relevant data of each node that has been parsed to match the situation of each node. For example, the service provided by node A is of http type. By associating the cases that the http type should have, the chaos test tasks related to node A are automatically filled.

[0054] The process of generating chaos test tasks for each node includes: firstly, generating chaos test tasks for each node according to the business-related parameters of each node in the business link topology diagram; then adding matching chaos test cases for the chaos test tasks of each node. In the chaos test tasks of each node, the added chaos test cases are different types of chaos test cases corresponding to the simulation of different faults, that is, different types of chaos test cases are generated for various faults related to the node, so as to perform sufficient chaos tests on each node.

[0055] Step S140, executing the chaos test task of each node, and determining whether each node is a high-risk node according to the chaos test result.

[0056] After generating the chaos test task of each node, the chaos test task of each node can be executed to obtain the chaos test result. The chaos test task of each node can be executed sequentially or in parallel. According to the chaos test result of each node, it can be determined whether each node is a high-risk node. It can be determined whether each node is a high-risk node based on the relevant data of the chaos test result of each node. For example, it can be determined whether the node is a high-risk node based on the change trend of key indicators.

[0057] For software systems, there are often version updates. After the version update, in order to ensure the stability of the software system, the updated version needs to be fully tested and risk checked. After adopting the software system risk troubleshooting method based on fault simulation provided in this embodiment, the business link topology map is obtained based on the software business link, and then a chaos test is performed on each node in the business link topology map using a method based on fault simulation, thereby forming an automatic high-risk troubleshooting capability for the system based on fault simulation, which solves the problem that testers are often unable to clearly locate the modules with high risks in the current version of the system during version iteration.

[0058] For each node in the business link topology diagram, after executing the chaos test task of each node, determine the changes in the key indicators related to the business in the chaos test task results. If the change range of the key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a high-risk node; if the change range of the key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a low-risk node. For example, for Figure 2 For the transfer service shown in , the key indicator is the transfer success rate. Then, whether the node is a high-risk node can be judged based on whether the transfer success rate changes significantly. If the transfer success rate changes significantly, it means that the current fault injection node is a high-risk node.

[0059] Furthermore, after high-risk nodes are determined according to the software system risk screening method based on fault simulation provided in this embodiment, more rigorous risk screening can be arranged later.

[0060] The software system risk investigation method based on fault simulation provided in this embodiment first obtains the business link topology map of the software system to be investigated, then parses the data of each node in the business link topology map, generates a chaos test task for each node according to the data of each node in the business link topology map, and finally executes the chaos test task for each node, and determines whether each node is a high-risk node according to the chaos test result. Since the business link topology map based on the software system reflects the relevant conditions of each node related to the business, testing the software system according to the chaos test tasks of each node generated by the business link topology map can accurately investigate the high-risk nodes in the software system, thereby providing an automatic risk investigation solution for the software system, which solves the problem that testers cannot accurately locate the modules with high risks in the system version during version iteration.

[0061] Figure 3 A flowchart of another software system risk troubleshooting method based on fault simulation provided by an embodiment of the present invention is shown in FIG. Figure 3 As shown, the software system risk troubleshooting method based on fault simulation provided in this embodiment is a specific example.

[0062] First, determine whether the software system to be checked has a business link topology map. If so, obtain the business link topology map, otherwise end this troubleshooting process. In step 1, obtain the business link topology map of the specified transaction according to the situation of the software system under test. In step 2, parse the data of each node in the business link topology map in turn. The business link topology map generally contains information about the services of each node involved in the current transaction, such as the transfer business involving service A of application A and service B of application B, and includes a variety of technical parameters such as the node where service A is located and the type of service A (http or rpc). In step 3, generate chaos test tasks and fill in chaos test cases based on the types and parameters of each node in the business link topology map. In step 4, automatically add the chaos test cases that the current node should have to the generated chaos test tasks. For example, if the service provided by node A is of http type, the chaos test tasks related to node A are automatically filled in by associating the cases that should have http type. Step 5: Execute the generated chaos test task and determine whether the business key indicators are affected. If the key indicators change significantly, the current node is judged to be a high-risk node. If the key indicators do not change significantly, the current node is judged to be a low-risk node.

[0063] Figure 4 A schematic diagram of the structure of a software system risk troubleshooting device based on fault simulation provided by an embodiment of the present invention, such as Figure 4 As shown, the software system risk troubleshooting device based on fault simulation provided in this embodiment includes:

[0064] The acquisition module 41 is used to obtain the business link topology diagram of the software system to be checked; the parsing module 42 is used to parse the data of each node in the business link topology diagram; the generation module 43 is used to generate the chaos test task of each node according to the data of each node in the business link topology diagram; the execution module 44 is used to execute the chaos test task of each node and determine whether each node is a high-risk node according to the chaos test result.

[0065] The software system risk troubleshooting device based on fault simulation provided in this embodiment is used to implement Figure 1 The software system risk troubleshooting method based on fault simulation provided in the illustrated embodiment has similar implementation principles and technical effects, which will not be described in detail here.

[0066] In one embodiment, the analysis module 42 is further configured to terminate the risk investigation process if there is no business link topology diagram for the current business of the software system to be investigated.

[0067] In one embodiment, the parsing module 42 is specifically used to parse the service link topology map, and obtain each node in the service link topology map and service-related parameters of each node.

[0068] In one embodiment, the generating module 43 is specifically used to generate a chaos test task for each node according to the service-related parameters of each node in the service link topology diagram; and add a matching chaos test case to the chaos test task for each node.

[0069] In one embodiment, the chaos test cases are multiple test cases based on different types of fault simulations of chaos test tasks.

[0070] In one embodiment, the execution module 44 is specifically used to execute the chaos test task of each node and determine the change of key indicators related to the business; if the change range of the key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a high-risk node.

[0071] In one embodiment, the execution module 44 is further configured to determine that the corresponding node is a low-risk node if the change range of the key indicator related to the business exceeds a preset threshold.

[0072] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 5 As shown, the electronic device may include: a transceiver 51 , a processor 52 , and a memory 53 .

[0073] The processor 52 executes the computer execution instructions stored in the memory, so that the processor 52 executes the scheme in the above embodiment. The processor 52 can be a general-purpose processor, including a central processing unit CPU, a network processor (NP), etc.; it can also be a digital signal processor DSP, an application-specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

[0074] The memory 53 is connected to the processor 52 via a system bus and completes communication between them. The memory 53 is used to store computer program instructions.

[0075] The transceiver 51 may be used to obtain tasks to be executed and configuration information of the tasks to be executed.

[0076] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The transceiver is used to realize the communication between the database access device and other computers (such as clients, read-write libraries, and read-only libraries). The memory may include random access memory (RAM) and may also include non-volatile memory.

[0077] The electronic device provided in the embodiment of the present application may be a computer or server deployed by the software system risk troubleshooting device based on fault simulation in the above-mentioned embodiment.

[0078] An embodiment of the present application also provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on a computer, the computer executes the technical solution of the software system risk troubleshooting method based on fault simulation in the above embodiment.

[0079] An embodiment of the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When at least one processor executes the computer program, it can implement the technical solution of the software system risk investigation method based on fault simulation in the above embodiment.

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

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

Claims

1. A software system risk investigation method based on fault simulation, characterized in that: include: Obtain the business link topology diagram of the software system to be checked; Parsing the data of each node in the service link topology diagram; Generate a chaos test task for each node according to the data of each node in the service link topology diagram; Execute the chaos test task of each node, and determine whether each node is a high-risk node according to the chaos test result.

2. The method according to claim 1, characterized in that: The parsing of each node data in the service link topology diagram includes: The service link topology diagram is parsed to obtain each node in the service link topology diagram and service-related parameters of each node.

3. The method according to claim 1, characterized in that The generating of the chaos test task of each node according to the data of each node in the business topology diagram includes: Generate a chaos test task for each node according to the service-related parameters of each node in the service link topology diagram; Add matching chaos test cases to the chaos test tasks of each node.

4. The method according to claim 3, characterized in that The chaos test cases are multiple test cases based on the simulation of different types of failures in chaos test tasks.

5. The method according to any one of claims 1 to 4, characterized in that: The performing of the chaos test task of each node and determining whether each node is a high-risk node according to the chaos test result includes: Execute chaos testing tasks on each node to determine changes in key business-related indicators; If the change range of key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a high-risk node.

6. The method according to any one of claims 1 to 4, characterized in that: After executing the chaos test task of each node and judging the change of key indicators related to the business, the method further includes: If the change range of key indicators related to the business exceeds the preset threshold, the corresponding node is determined to be a low-risk node.

7. The method according to any one of claims 1 to 4, characterized in that: After obtaining the service link topology diagram of the software system to be checked, the method further includes: If the current business of the software system to be checked has no business link topology diagram, the risk checking process is terminated.

8. A software system risk troubleshooting device based on fault simulation, characterized in that: include: An acquisition module is used to obtain a business link topology diagram of the software system to be checked; A parsing module, used to parse the data of each node in the service link topology diagram; A generation module, used to generate a chaos test task for each node according to the data of each node in the service link topology diagram; The execution module is used to execute the chaos test task of each node and determine whether each node is a high-risk node according to the chaos test result.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the software system risk troubleshooting method based on fault simulation as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the software system risk troubleshooting method based on fault simulation as described in any one of claims 1 to 7.

11. A computer program product, characterized in that It includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When at least one processor executes the computer program, it can implement the software system risk investigation method based on fault simulation as described in any one of claims 1 to 7.

Images