Testing Method, Device, Computer Equipment and Storage Medium

Abstract

The present application relates to a testing method, apparatus, computer device, and storage medium. The method includes: obtaining a node path graph constructed according to a state machine diagram; the node path graph includes normal service state nodes, abnormal service state nodes, and edge attributes between the nodes; the edge attributes include normal service flow operations and abnormal operation components; obtaining call path information between state nodes according to the edge attributes between the state nodes in the node path graph; generating automated test cases according to the call path information and executing the automated test cases. Since the node path graph includes normal service process operations and abnormal operation components, the automated test cases can cover both business scenario testing and abnormal scenario testing, making the testing more comprehensive.

Description

Technical Field

[0001] This application relates to the technical field of software testing, and particularly to a testing method, apparatus, computer device, and storage medium. Background Art

[0002] Testing is an important part of software development. With the rapid increase in the number and complexity of application software, to improve testing efficiency, automated testing has been widely applied.

[0003] Automated testing refers to a process of converting test behaviors driven by humans into machine execution. Test cases are usually used in the process of automated testing. Therefore, the automated generation of test cases has become increasingly important. In related technologies, for front-end services, a directed graph is used to establish a test model by representing expected states with vertices and actions to achieve expected states with edges, so as to generate test cases.

[0004] However, traditional test cases usually only cover business scenarios at present, and the test content is relatively single, which leads to incomplete testing. Summary of the Invention

[0005] Based on this, it is necessary to provide a testing method, apparatus, computer device, and storage medium that can enrich test content and improve the comprehensiveness of testing for the above technical problems.

[0006] A testing method, the method includes:

[0007] Obtain a node path graph constructed according to a state machine graph; the node path graph includes normal business state nodes, abnormal business state nodes, and edge attributes between nodes; the edge attributes include normal business flow operations and abnormal operation components;

[0008] Obtain call path information between state nodes according to the edge attributes between state nodes in the node path graph;

[0009] Generate automated test cases according to the call path information and execute the automated test cases.

[0010] A testing apparatus, the apparatus includes:

[0011] A node path graph acquisition module, configured to obtain a node path graph constructed according to a state machine graph; the node path graph includes normal business state nodes, abnormal business state nodes, and edge attributes between nodes; the edge attributes include normal business flow operations and abnormal operation components;

[0012] A call path acquisition module, configured to obtain call path information between state nodes according to the edge attributes between state nodes in the node path graph;

[0013] A test module for generating automated test cases according to the call path information and executing the automated test cases.

[0014] A computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, the following steps are implemented:

[0015] Obtain a node path graph constructed according to a state machine diagram; the node path graph includes normal business state nodes, abnormal business state nodes, and edge attributes between nodes; the edge attributes include normal business flow operations and abnormal operation components;

[0016] Obtain call path information between state nodes according to the edge attributes between state nodes in the node path graph;

[0017] Generate automated test cases according to the call path information and execute the automated test cases.

[0018] A computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the following steps are implemented:

[0019] Obtain a node path graph constructed according to a state machine diagram; the node path graph includes normal business state nodes, abnormal business state nodes, and edge attributes between nodes; the edge attributes include normal business flow operations and abnormal operation components;

[0020] Obtain call path information between state nodes according to the edge attributes between state nodes in the node path graph;

[0021] Generate automated test cases according to the call path information and execute the automated test cases.

[0022] In the above test method, device, computer device, and storage medium, a node path graph constructed according to a state machine diagram is obtained, call path information between state nodes is obtained according to the edge attributes between state nodes in the node path graph. The node path graph includes normal business state nodes, abnormal state business nodes, and edge attributes including normal business flow operations and abnormal operation components. According to the call path information, automated test cases are generated and executed. Since the node path graph includes normal business process operations and abnormal operation components, the automated test cases can cover business scenario testing and abnormal scenario testing, making the testing more comprehensive. Description of the Drawings

[0023] Figure 1 It is an application environment diagram of the test method in an embodiment;

[0024] Figure 2Schematic diagram of the test method in an embodiment;

[0025] Figure 3 System architecture diagram of the test method in an embodiment;

[0026] Figure 4 Node path diagram in an embodiment;

[0027] Figure 5 Schematic diagram of splitting test cases according to edge attributes in an embodiment;

[0028] Figure 6 Schematic diagram of the steps of generating and executing automated test cases based on the call path information between nodes in the normal business state and the call path information corresponding to the abnormal operation components in an embodiment;

[0029] Figure 7 Schematic diagram of the process of generating the first automated test case for status verification in an embodiment;

[0030] Figure 8 Schematic diagram of traversing normal state nodes in an embodiment;

[0031] Figure 9 Schematic diagram of the process of abnormal verification in an embodiment;

[0032] Figure 10 Schematic diagram of the process of interface re - entry verification in an embodiment;

[0033] Figure 11 Structural block diagram of the test device in an embodiment;

[0034] Figure 12 Internal structure diagram of a computer device in an embodiment. Detailed implementation manners

[0035] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0036] Artificial Intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to obtain the best results. In other words, artificial intelligence is a comprehensive technology in computer science that attempts to understand the essence of intelligence and produce a new intelligent machine that can react in a way similar to human intelligence. Artificial intelligence also studies the design principles and implementation methods of various intelligent machines to enable machines to have the functions of perception, reasoning, and decision-making.

[0037] Artificial intelligence technology is an interdisciplinary subject that involves a wide range of fields, including both hardware-level and software-level technologies. The basic technologies of artificial intelligence generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, and mechatronics. This application relates to the application of artificial intelligence in the testing field, specifically to the executable scripts for tests automatically generated based on MBT modeling.

[0038] The testing method provided in this application can be applied to an application environment such as Figure 1 shown. Among them, the terminal 102 communicates with the server 104. The terminal runs a test application, and the server 104 is the server of the application to be tested. The test application on the terminal 102 runs the testing method, generates automated test cases, and realizes the testing of the application to be tested by calling the server 104. Specifically, the testing method includes: obtaining a node path graph constructed according to a state machine diagram; the node path graph includes normal business state nodes, abnormal business state nodes, and the edge attributes between the nodes; the edge attributes include normal business flow operations and abnormal operation components; obtaining the call path information between state nodes according to the edge attributes between each state node in the node path graph; generating automated test cases according to the call path information and executing the automated test cases.

[0039] Among them, the terminal 102 can be, but is not limited to, various personal computers, laptop computers, smartphones, tablet computers, and portable wearable devices, and the server 104 can be implemented by an independent server or a server cluster composed of multiple servers.

[0040] In one embodiment, as Figure 2 shown, a testing method is provided. Taking the terminal in Figure 1 as an example for illustration, it includes the following steps:

[0041] Step 202, obtaining a node path graph constructed according to a state machine diagram; the node path graph includes normal business state nodes, abnormal business state nodes, and the edge attributes between the nodes; the edge attributes include normal business flow operations and abnormal operation components.

[0042] Specifically, the system architecture of the test method is as follows. Figure 3 As shown in the figure, download the flowchart tool YED, parse the system source code of the application under test, identify the code logic, and generate a state machine diagram through YED. The state machine diagram records the transition relationships between states.

[0043] Construct a node path diagram based on the state machine diagram. The node path diagram serves as the modeling diagram for model-based testing. The Chinese name of MBT is model-based testing, and model-based testing belongs to a testing method in the field of software testing. The steps of MBT are as follows: First, construct a model of the system under test (SUT) based on some (usually functional) aspects of the system under test. Then, generate test cases according to the model or a part of the model. Furthermore, conduct software testing.

[0044] Specifically, convert the state machine diagram into a directed graph to obtain the node path diagram. Among them, the node path diagram of one embodiment is as follows. Figure 4 As shown in the figure, it includes state nodes. A vertex is called a state node, usually represented as a box indicating the expected state we want to check. In any implementation code / test, the result can be modified through assertions or data verification.

[0045] Edges, that is, the arrows connecting two states, represent the methods from one state node to another state node. This is any action required to reach the next state. It can select some menu options, click buttons, etc. as test actions. Among them, the method from one state node to another state node is that an edge can have multiple edge attributes, that is, there can be multiple methods from one state node to another state node, such as normal business process operations.

[0046] To achieve the comprehensiveness of testing, manual operations can be performed on the node path diagram. Some of the state nodes are set as abnormal business state nodes, and some edge attributes are added with common abnormal components as abnormal operation components.

[0047] Among them, the normal business process operation is the normal business processing flow, such as a purchase payment process. The abnormal operation component is the type of executing abnormal test cases. To achieve fault tolerance, the common checkpoints for abnormal testing can be encapsulated into a common component, that is, the abnormal operation component.

[0048] Such as Figure 4 As shown in the figure, "v_" identifies the normal business state node; "vE_" identifies the abnormal business state node; for edges with multiple edge attributes, the "&" symbol is used to identify the edge attributes of the table. For example, the edge attribute "e_exception" is a common abnormal component.

[0049] Step 204: Obtain the call path information between state nodes based on the edge attributes between state nodes in the node path diagram.

[0050] Specifically, use the path generation algorithm to generate test paths to each state node according to the node path diagram. Each edge attribute represents a method from one state node to another state node. One edge attribute corresponds to one test path, that is, from one state node, call a method to another state node. According to the edge attributes, use cases for business scenario coverage, general system exception use cases, business exception use cases, and main process use cases can be obtained. Among them, the use cases for business scenario coverage correspond to the edge attributes of normal business process operations, and the general system exception use cases and business exception use cases correspond to the edge attributes of exception operation components.

[0051] Specifically, for the node path diagram, for two nodes with multiple edge attributes, according to the edge attributes, divide the paths between the state nodes corresponding to the edge attributes to obtain the call path information corresponding to each edge attribute; for two nodes with a single edge attribute, according to the edge attribute, obtain the path between the state nodes to obtain the call path information.

[0052] For the edge attributes of each state node in the node path diagram, if an edge has multiple edge attributes, it indicates that multiple methods can be called from the previous state node, and the next state result can be obtained. Among them, the edge attributes are identified by the symbol "&". For two nodes with multiple edge attributes, divide the paths between the state nodes corresponding to the edge attributes according to the "&" identifier to obtain the call path information corresponding to each edge attribute. As Figure 5 shown, state A and state B call four methods, and the "&" symbol is used between each method. By according to the "&" symbol, the path from state A to state A is divided into four call paths, and each call path calls different methods to implement.

[0053] For two nodes with a single edge attribute, it is relatively simple. According to the edge attribute, obtain the path between the state nodes to obtain the call path information.

[0054] Step 206: Generate automated test cases based on the call path information and execute the automated test cases.

[0055] Specifically, the call path information includes the path information for performing normal business state transitions between state nodes and the exception operation components between state nodes. Therefore, the automated test cases generated according to the call path information cover both business scenarios and exception scenarios, that is, the test content not only covers business scenarios but also includes exception scenarios.

[0056] The above test method obtains a node path graph constructed according to a state machine diagram, and obtains call path information between state nodes based on the edge attributes between state nodes in the node path graph. The node path graph includes normal business state nodes and abnormal state business nodes, and the edge attributes include normal business flow operations and abnormal operation components. According to the call path information, automated test cases are generated and the automated test cases are executed. Since the node path graph includes normal business process operations and abnormal operation components, the automated test cases can cover business scenario testing and abnormal scenario testing, making the test more comprehensive.

[0057] Specifically, as Figure 6 shown, according to the call path information between normal business state nodes and the call path information corresponding to abnormal operation components, automated test cases are generated and the automated test cases are executed, including:

[0058] S602, according to the call path information, obtain the input parameter data and expected values of the full-scenario use case.

[0059] Specifically, according to the call path information with the edge attribute being a normal business flow operation, obtain the input parameter data and expected values of the full-scenario use case. The input parameter data can, on the one hand, be used as the source of input parameter data for automated testing. The expected value is the expected execution result of the automated use case, and the test result of the application program can be obtained based on the actual execution result.

[0060] S604, according to the edge attributes in the link of normal business state nodes in the node path graph, construct whether to call the operation method corresponding to the edge attribute to obtain a single pair of node cross-state link graphs, and generate the first automated test case for state verification based on the single pair of node cross-state link graphs.

[0061] The node path graph includes state nodes and edges connecting two state nodes. An edge, that is, an arrow connecting two states, can have multiple edge attributes, and each edge attribute represents a method from one state node to another state node, that is, each edge attribute corresponds to an operation method. For example, a method for business flow, a method for abnormal use cases, etc.

[0062] Specifically, for any two business state nodes in the node path graph, multiple links can be obtained according to the path direction of the node link graph. As Figure 4For the V state node 2 to the V state node 3, it may include three links. The first link is: V state node 2 -> VE state node 8 -> VE state node 9 -> VE state node 10 -> V state node 3. The second link is: V state node 2 -> VE state node 11 -> VE state node 12 -> VE state node 13 -> VE state node 14 -> V state node 3. The third link is V state node 2 -> V state node 3. Among them, the state processes of the two state nodes execute the operation methods corresponding to the edge attributes.

[0063] For each link of the normal business state nodes, by constructing whether to call the operation method corresponding to the edge attribute, it is possible to simulate the invocation of one or more of them, and not to call the business scenarios corresponding to one or more of the methods of the edge attributes. It can facilitate cross-state transition testing with multiple levels, making the testing more sufficient. Among them, the construction method is enumeration, that is, for each link, there are N operation methods, and the cases of enumerating the invocation of N - 1 operation methods (not invoking one operation method), the cases of enumerating the invocation of N - 2 operation methods (not invoking two operation methods),..., the cases of enumerating not invoking N - 1 operation methods (invoking one operation method) are enumerated to obtain the cross-state link graph of a single pair of nodes corresponding to each enumeration case.

[0064] Specifically, as Figure 7 shown, it includes the following steps:

[0065] The first step is to obtain the normal business state nodes according to the node path graph.

[0066] Specifically, all the normal business state nodes are extracted from the node path graph, that is, Figure Four the state nodes marked as V in

[0067] The second step is to sort the normal business state nodes to obtain the sorted normal business state nodes.

[0068] Sort the normal business state nodes according to the node name so that the generated nodes have sequentiality for subsequent generation of the ending nodes for cross-state verification. For example, the normal business state nodes in the node path graph include (node two, node seven, node eight, node one), and they are sorted in the order of the node name as (node one, node two, node seven, node eight)

[0069] The third step is to traverse the sorted normal business state nodes, take any normal business state node as the starting node, and take the normal business state nodes sorted after the starting node as the ending nodes. According to the node path graph, query the path from the starting node to the ending node to obtain the node link graph.

[0070] The order of traversal is the sorting of the nodes in normal business status. A normal business status node is taken as the starting node in order, and the normal business status node sorted after it is taken as the ending node. Then, the node path graph is returned to query the graph path from the starting node to the ending node to obtain multiple node link graphs.

[0071] Assume that nodes A, B, and C are all in normal business state, and the sorted order is A, B, and C. Figure 8 As shown, first take A as the starting node, B and C can be used as the ending nodes respectively, and obtain two node link graphs A->B and A->C. Then take B as the starting node and C as the ending node to obtain the ending link graph of B->C. Finally, we get three node link graphs A->B, A->C, and B->C.

[0072] The fourth step is to construct multiple paths between single pairs of nodes across the state link graph based on the existence of edges in the node-link graph.

[0073] Among them, according to the node link diagram, from the start node to the end node, multiple other nodes may be passed in the middle. Through the edge attributes of each node, that is, the method of executing the call in sequence, the state jump from the start end to the end node is realized.

[0074] Edge existence, that is, whether the method corresponding to the edge is called. The number of edges in a node-link graph corresponds to the number of links to be tested. By simulating the existence of all edges in a node-link graph, it is possible to simulate whether a single pair of nodes across state link graphs are called for corresponding methods.

[0075] Specifically, the total number of links to be tested, N, is first obtained, and combinations of 1 0 and N-1 1s, 2 0s and N-2 1s, ..., i 0s and Ni 1s, ..., N-1 0s and 1 1 are generated in sequence. For example, the four methods included in a link are method 1, method 2, method 3, and method 4. The number of edges between two nodes is digitally modeled, that is, the edges are abstracted into independent objects. If the edge is not called, it is represented by 0, and if the edge is called, it is represented by 1. The generated single-node cross-state link graph can be:

[0076] The corresponding situations of calling three methods among four methods: [(1,0,1,1),(1,1,0,1),(0,1,1,1),(1,1,1,0)];

[0077] The corresponding cases of calling two methods among four methods: [(1,1,0,0),(0,1,0,1),(1,0,0,1),(0,1,1,0)] and [(1,0,1,0),(0,0,1,1)];

[0078] The situation of calling one method among four methods: [(0,0,0,1),(1,0,0,0),(0,1,0,0),(0,0,1,0)].

[0079] That is to say, by constructing the operation methods corresponding to whether to call the edge attributes, 14 business scenarios can be constructed, which can facilitate cross-state transition testing with multiple levels and make the testing more sufficient.

[0080] Step 606, execute the first automated test case according to the input parameter data to obtain the first execution result.

[0081] Specifically, for each path of the single-pair node cross-state link diagram, substitute the specific meaning of the edge to restore and generate a business call relationship link, and then generate the corresponding automated test cases for cross-state link testing.

[0082] S606, execute the first automated test case according to the input parameter data respectively to obtain the first execution result.

[0083] Specifically, substitute the corresponding input parameter data and execute the first automated test case to obtain the first execution result of the cross-state link test.

[0084] S608, obtain the first test result according to the first execution result and the expected value.

[0085] Specifically, the input parameter data obtained by calling the path information can be used as the source of the input parameter data for the automated test cases of cross-state verification, and the expected value can be used as the standard value for comparing the expected values of the execution results of the automated test cases of cross-state verification. Comparing the two can obtain the first test result of the cross-state link test. For example, if the two are the same, it indicates that the test passes.

[0086] In this embodiment, by constructing the operation methods corresponding to whether to call the edge attributes, multiple business scenarios can be constructed, which can facilitate cross-state transition testing with multiple levels and make the testing more sufficient.

[0087] In another embodiment, generating automated test cases according to the call path information and executing the automated test cases further includes: obtaining the expected value of exception verification according to the call path information, generating the second automated test case; constructing an abnormal environment and executing the second automated test case in the constructed abnormal environment to obtain the second execution result; obtaining the second test result according to the second execution result and the expected value of the exception verification.

[0088] Specifically, system exceptions are verified. For system exceptions, an environment exception construction tool, such as Pumba, is used to construct environment exceptions and run scenario test cases. The types of environment exceptions include: 1) network latency 2) network packet loss 3) restricted network latency transmission speed 4) network packet duplication 5) network packet corruption.

[0089] The specific exception verification process is as Figure 9 shown.

[0090] First, the expected value of the exception verification result is obtained according to the first part of the link data.

[0091] Secondly, an environment exception construction tool, such as Pumba, is used to construct environment exceptions, and scenario test cases are executed in the abnormal system. Specifically, the environment exception tool is called to build an abnormal environment to obtain an abnormal system, and the second automated test case is executed in the abnormal system to obtain a second execution result.

[0092] Finally, the verification unit obtains the execution result from the system under test and compares it with the expected value. If they are consistent, it is determined that the scenario test case is not affected by the set environment exception. That is, the second execution result and the expected value are compared. If they are consistent, it is determined that the scenario test case is not affected by the set environment exception.

[0093] In another embodiment, the edge attribute further includes an entry function; according to the call path information, generating and executing the automated test case further includes: generating a third automated test case according to the entry function; executing the third automated test case on another server with a similar environment to obtain a third execution result; executing the third automated test case on the original server to obtain a fourth execution result; if the third execution result and the fourth execution result satisfy interface idempotency, it is determined that the interface supports reentry.

[0094] Interface idempotency means that the result of a single request or multiple requests initiated by the user for the same operation is the same, and there will be no side effects due to multiple clicks. For places in the business that need to consider idempotency, they are generally repeated requests of the interface. A repeated request refers to the same request being submitted multiple times for some reason. In response to this situation, as Figure 10 shown, interface reentry ensures interface idempotency. The implementation mainly involves the following steps:

[0095] 1) Pull the main code, obtain the position in the source code according to the name of the interface function to be interrupted, and use a runtime debugging tool, such as gdb, to set a breakpoint at that position. Specifically, determine the position of the code in the source code according to the entry function under test; call the debugging tool to set a breakpoint at that position to obtain a third automated test case.

[0096] 2) Replay the request with the request parameters on another server in a similar environment. After success, continue to execute the original server statements, observe and verify the results. If the interface idempotency is satisfied, it indicates that the interface supports re - entry. That is to say, execute the third automated test case on another server in a similar environment and execute the third automated test case on the original server. If the execution results of the two satisfy the interface idempotency, that is, the second request will not duplicate the result of the first request, it is determined that the interface supports re - entry.

[0097] In this embodiment, the test of whether the interface is re - entrant is also carried out to improve the comprehensiveness of the test.

[0098] Such as Figure 3 As shown, for the node path diagram obtained by MBT modeling, through the execution of link verification, status verification and exception verification on the system under test, according to the actual verification results and expected values, the test results can be obtained. Summarize the test results and send them to the relevant project personnel. The test covers link verification, status verification and exception verification. The method of this application can be applied to any state - machine - flowing product for exception testing. Ensure the test completeness, so that the full - link automated test cases can be correctly executed when the expected values exist. Expose the performance of the business system in common network problem situations in advance and release the unknown risks in the later stage. Compared with the existing exploratory testing method, it can detect the test in combination with the expected results.

[0099] It should be understood that although the steps in the above flowcharts are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the above can include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same moment, but can be executed at different moments. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0100] In one embodiment, as Figure 11 shown, a test device is provided. This device can be a software module, a hardware module, or a combination of both to become a part of a computer device. Specifically, the device includes: a node path diagram acquisition module 1102, a call path acquisition module 1104, and a test module 1106, where:

[0101] The node path graph acquisition module 1102 is used to acquire a node path graph constructed according to a state machine graph; the node path graph includes normal service state nodes, abnormal service state nodes, and edge attributes between the nodes; the edge attributes include normal service transfer operations and abnormal operation components.

[0102] The call path acquisition module 1104 is used to obtain call path information between state nodes according to the edge attributes between the state nodes in the node path graph.

[0103] The test module 1106 is used to generate automated test cases according to the call path information and execute the automated test cases.

[0104] The above test device acquires a node path graph constructed according to a state machine graph, obtains call path information between state nodes according to the edge attributes between the state nodes in the node path graph. The node path graph includes normal service state nodes, abnormal service state nodes, and the edge attributes include normal service transfer operations and abnormal operation components. According to the call path information, automated test cases are generated and the automated test cases are executed. Since the node path graph includes normal service process operations and abnormal operation components, the automated test cases can cover business scenario tests and abnormal scenario tests, making the test more comprehensive.

[0105] In another embodiment, the test module includes:

[0106] The parameter acquisition module is used to acquire input parameter data and expected values of full-scenario use cases according to the call path information;

[0107] The use case generation module is used to construct a single-pair node cross-state link graph by determining whether to call the operation method corresponding to the edge attribute according to the edge attributes in the link of the normal service state nodes in the node path graph, and generate the first automated test case for state verification according to the single-pair node cross-state link graph;

[0108] The execution module is used to execute the first automated test case respectively according to the input parameter data to obtain a first execution result;

[0109] The test result acquisition module is used to obtain a first test result according to the first execution result and the expected value.

[0110] In another embodiment, the use case generation module includes:

[0111] The extraction module is used to acquire normal service state nodes according to the node path graph;

[0112] The sorting module is used to sort the normal service state nodes to obtain the sorted normal service state nodes;

[0113] A traversal module for traversing the sorted normal business state nodes, taking any normal business state node as the starting node, taking the normal business state nodes sorted after the starting node as the ending nodes, and querying the path from the starting node to the ending node according to the node path diagram to obtain a node link diagram;

[0114] A construction module for constructing multiple paths of a single pair of node cross-state link diagrams according to the edge existence in the node link diagram;

[0115] A first test case generation module for generating a first automated test case according to the operation methods of the edges in each path of the single pair of node cross-state link diagrams.

[0116] In another embodiment, the test module further includes:

[0117] A second test case generation module for obtaining the expected value of exception verification according to the call path information and generating a second automated test case;

[0118] An environment construction module for constructing an abnormal environment, executing the second automated test case in the constructed abnormal environment to obtain a second execution result;

[0119] A test result acquisition module for obtaining a second test result according to the second execution result and the expected value of the exception verification.

[0120] Among them, the environment construction module is used to call an environment exception tool to build an abnormal environment to obtain an abnormal system; execute the second automated test case in the abnormal system to obtain a second execution result.

[0121] In another embodiment, the edge attribute further includes an entry function, and the test module further includes:

[0122] A third test case generation module for generating a third automated test case according to the entry function;

[0123] A re-entry test module for executing the third automated test case on another server with a similar environment to obtain a third execution result; executing the third automated test case on the original server to obtain a fourth execution result; if the third execution result and the fourth execution result satisfy interface idempotency, it is determined that the interface supports re-entry. Among them, the third test case generation module is used to determine the location of the code in the source code according to the entry function to be tested; call a debugging tool to set breakpoints at the location to obtain a third automated test case.

[0124] For the specific limitations of the test device, reference may be made to the limitations on the test method in the foregoing text, which will not be elaborated here. Each module in the above test device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory of the computer device in the form of software, so as to facilitate the processor to call and execute the operations corresponding to each of the above modules.

[0125] In one embodiment, a computer device is provided. The computer device can be a terminal, and its internal structure diagram can be as Figure 12 shown. The computer device includes a processor, a memory, a communication interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner. The wireless manner can be implemented through WIFI, a carrier network, NFC (Near Field Communication), or other technologies. The computer program, when executed by the processor, implements a test method. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covering the display screen, or a button, a trackball, or a touchpad provided on the housing of the computer device, or an external keyboard, touchpad, or mouse, etc.

[0126] Those skilled in the art can understand that Figure 12 the structure shown in

[0127] is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have a different component layout.

[0128] In one embodiment, a computer-readable storage medium is provided, storing a computer program, which, when executed by a processor, implements the steps in the foregoing method embodiments.

[0129] In one embodiment, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions that are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in the foregoing method embodiments.

[0130] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the foregoing method embodiments. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided in this application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0131] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0132] The above-described embodiments merely represent several implementation manners of this application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several modifications and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of the patent of this application should be subject to the appended claims.

Claims

1. A testing method, characterized in that, including obtaining a node path graph constructed according to a state machine diagram; the node path graph includes normal service state nodes, abnormal service state nodes, and edge attributes between nodes; the edge attributes include normal service transfer operations and abnormal operation components; obtaining call path information between state nodes according to the edge attributes between state nodes in the node path graph; obtaining input parameter data and expected values of full-scenario use cases according to the call path information; constructing a single-pair node cross-state link graph by determining whether to call the operation method corresponding to the edge attribute according to the edge attributes in the link of normal service state nodes in the node path graph, and generating a first automated test case for state verification according to the single-pair node cross-state link graph; executing the first automated test case respectively according to the input parameter data to obtain a first execution result; obtaining a first test result according to the first execution result and the expected value; 2. The method according to claim 1, wherein The step of constructing a single-pair node cross-state link graph by determining whether to call the operation method corresponding to the edge attribute according to the edge attributes in the link of normal service state nodes in the node path graph, and generating a first automated test case for state verification according to the single-pair node cross-state link graph includes: obtaining normal service state nodes according to the node path graph; sorting the normal service state nodes to obtain sorted normal service state nodes; traversing the sorted normal service state nodes, taking any normal service state node as a start node, taking the normal service state node sorted after the start node as an end node, and querying the path from the start node to the end node according to the node path graph to obtain a node link graph; constructing multiple paths of a single-pair node cross-state link graph according to the existence of edges in the node link graph; generating a first automated test case according to the operation methods of each edge in each path of the single-pair node cross-state link graph.

3. The method according to claim 1, wherein The step of generating an automated test case according to the call path information and executing the automated test case further includes: obtaining an expected value for exception verification according to the call path information and generating a second automated test case; constructing an abnormal environment and executing the second automated test case in the constructed abnormal environment to obtain a second execution result; obtaining a second test result according to the second execution result and the expected value for exception verification; 4. The method according to claim 3, characterized in that, The step of constructing an abnormal environment and executing the second automated test case in the constructed abnormal environment to obtain a second execution result includes: calling an environment exception tool to construct an abnormal environment to obtain an abnormal system; executing the second automated test case in the abnormal system to obtain a second execution result.

5. The method according to claim 1, characterized in that, The edge attribute further includes an entry function; the step of generating an automated test case according to the call path information and executing the automated test case further includes: generating a third automated test case according to the entry function; executing the third automated test case on another server with a similar environment to obtain a third execution result; executing the third automated test case on the original server to obtain a fourth execution result; If the third execution result and the fourth execution result satisfy the interface idempotency, it is determined that the interface supports reentry.

6. The method according to claim 5, characterized in that, The generating of the third automated test case according to the entry function includes: Determining the location of the code in the source code according to the entry function to be tested; Invoking a debugging tool to set breakpoints at the location to obtain the third automated test case.

7. A test device, characterized in that, The apparatus includes: A node path graph acquisition module, configured to acquire a node path graph constructed according to a state machine graph; the node path graph includes normal service state nodes, abnormal service state nodes, and edge attributes between the nodes; the edge attributes include normal service flow operations and abnormal operation components; A call path acquisition module, configured to obtain call path information between state nodes according to the edge attributes between the state nodes in the node path graph; A test module, configured to: obtain input parameter data and expected values of full-scenario test cases according to the call path information; construct a single pair of node cross-state link graphs by determining whether to call the operation method corresponding to the edge attribute according to the edge attributes in the link of the normal service state nodes in the node path graph, and generate a first automated test case for state verification according to the single pair of node cross-state link graphs; execute the first automated test case according to the input parameter data respectively to obtain a first execution result; and obtain a first test result according to the first execution result and the expected value.

8. The device according to claim 7, characterized in that The test module includes: An extraction module, configured to obtain normal service state nodes according to the node path graph; A sorting module, configured to sort the normal service state nodes to obtain sorted normal service state nodes; A traversal module, configured to traverse the sorted normal service state nodes, use any one of the normal service state nodes as a start node, use the normal service state nodes sorted after the start node as end nodes, and query the path from the start node to the end node according to the node path graph to obtain a node link graph; A construction module, configured to construct multiple paths of a single pair of node cross-state link graphs according to the existence of edges in the node link graph; A first test case generation module, configured to generate a first automated test case according to the operation methods of the edges in each path of the single pair of node cross-state link graphs.

9. The device according to claim 7, characterized in that, The test module further includes: A second test case generation module, configured to obtain expected values for exception verification according to the call path information and generate a second automated test case; An environment construction module, configured to construct an abnormal environment, execute the second automated test case in the constructed abnormal environment to obtain a second execution result; A test result acquisition module, configured to obtain a second test result according to the second execution result and the expected value for exception verification.

10. The device according to claim 9, characterized in that, The environment construction module is specifically configured to: Invoke an environment exception tool to construct an abnormal environment to obtain an abnormal system; Execute the second automated test case in the abnormal system to obtain a second execution result.

11. The device according to claim 7, characterized in that, The edge attributes further include an entry function; the test module further includes: A third test case generation module, configured to generate a third automated test case according to the entry function; The re - entry test module is used to: execute the third automated test case on a server in another similar environment to obtain a third execution result; execute the third automated test case on the original server to obtain a fourth execution result; if the third execution result and the fourth execution result meet the interface idempotency, determine that the interface supports re - entry.

12. The device according to claim 11, characterized in that, The third test case generation module is specifically used to: Determine the position of the code in the source code according to the entry function to be tested; Call the debugging tool to set breakpoints at the position to obtain the third automated test case.

13. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 6.

14. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method described in any one of claims 1 to 6.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method described in any one of claims 1 to 6.

Images