Test case generation method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a test case generation method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring a control flow diagram of a source program to be tested, wherein the control flow diagram represents a control flow relationship among program statements in the source program to be tested; determining a coverage condition of a data stream based on the control stream diagram, wherein the coverage condition of the data stream comprises all data stream paths covering the source program to be tested; and generating a target test case, wherein the target test case is used for testing all data flow paths of the source program to be tested. According to the method, the focusing definition-use pair is analyzed through the data flow, only the paths related to the actual dependence of the variables are covered, the problem of exponential growth of the state space caused by traversing all the control flow paths in a traditional method can be solved, the test cost and the test complexity are reduced, and the test precision is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method, device, computer equipment and storage medium for generating test cases. Background Art

[0002] In the field of industrial control, PLC (Programmable Logic Controller) is widely used in multiple application scenarios such as electric power, water conservancy, chemical industry, aerospace, etc. Since the PLC software directly controls the core equipment in the safety system, if there are vulnerabilities, it may cause significant losses to human lives and property. As the main programming language for PLC software products, the IEC 61131-3 standard ST language, improving the testing level of ST language programs has become one of the important means to ensure the quality of PLC software products.

[0003] In the related art, generally, automated test cases are used to test the automation level of language programs. However, the commonly used automated test case generation methods generally have the following problems: every time a branch point is encountered during the execution process, two execution paths may be generated. As the program scale increases, the number of paths may increase exponentially, which is called path explosion. Due to the sharp expansion of the state space caused by path explosion, the test case generation process will become very time-consuming and resource-intensive, thus increasing the cost and complexity of testing. Summary of the Invention

[0004] To solve the technical problems of high testing cost and high testing complexity, this application provides a method, device, computer equipment and storage medium for generating test cases, which reduces the testing cost and testing complexity and improves the testing accuracy.

[0005] The first aspect of this application provides a method for generating test cases, the method includes:

[0006] Obtain the control flow graph of the source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested;

[0007] Based on the control flow graph, determine the coverage conditions of the data flow, where the coverage conditions of the data flow include covering all data flow paths of the source program to be tested;

[0008] Generate target test cases, where the target test cases are used to test all data flow paths of the source program to be tested.

[0009] In some embodiments of this application, the determining the coverage conditions of the data flow based on the control flow graph includes:

[0010] Perform data flow analysis according to the control flow graph to identify the definition points and usage points of all variables in the source program to be tested, where the definition point is the statement node where the variable is assigned a value, and the usage point is the statement node where the variable is referenced;

[0011] Construct a data flow coverage model based on the definition points and usage points of all variables in the source program to be tested, and determine the coverage conditions of the data flow through the data flow coverage model.

[0012] In some embodiments of the present application, the constructing a data flow coverage model based on the definition points and usage points of all variables in the source program to be tested includes:

[0013] Based on path reachability analysis, generate all reachable usage points within the scope of each definition point to form a first definition-use pair set;

[0014] Perform semantic validity checking on the initial definition-use pair set to obtain a second definition-use pair set;

[0015] Use dynamic symbolic execution technology to generate coverage paths and extract constraints for each definition-use pair in the second definition-use pair set, retain the feasible definition-use pairs with solutions, and use the feasible definition-use pairs as a third definition-use pair set;

[0016] Construct a data flow coverage model according to the third definition-use pair set, and the data flow coverage model stores the coverage paths and path constraints of each feasible definition-use pair.

[0017] In some embodiments of the present application, the generating target test cases includes:

[0018] Extract the path constraints of the coverage paths of each feasible definition-use pair;

[0019] Call an SMT solver to solve the path constraints. If there is a solution, generate a test input that covers the definition-use pair;

[0020] Combine all the generated test inputs into a target test case.

[0021] In some embodiments of the present application, the calling an SMT solver to solve the path constraints includes:

[0022] Set a maximum expansion times limit for nested loop structures to generate loop path variants with a finite depth;

[0023] Independently extract constraints for each sub-path in the branch path to ensure that all data flow paths under branch conditions are covered;

[0024] For each of the path variants and each sub-path, use a candidate path filter to select uncovered candidate paths according to the depth-first search strategy.

[0025] In some embodiments of the present application, the semantic validity check of the initial set of definition-use pairs to obtain a second set of definition-use pairs includes at least one of the following:

[0026] For each definition-use pair in the initial set of definition-use pairs, check whether the data type of the variable at the use point is consistent with that at the definition point;

[0027] For each definition-use pair in the initial set of definition-use pairs, verify whether the scope of the variable at the use point is legal;

[0028] Exclude invalid definition-use pairs caused by unreachable control flow or context conflicts.

[0029] In some embodiments of the present application, the obtaining of the control flow graph of the source program to be tested includes:

[0030] Identify a plurality of syntax units from the character sequence of the source program to be tested;

[0031] Construct a syntax parse tree according to the plurality of syntax units;

[0032] Filter the valid program content in the syntax parse tree to obtain an abstract syntax tree;

[0033] Construct the control flow graph of the source program to be tested based on the key statements in the abstract syntax tree, where the key statements refer to the statements that represent the control flow execution nodes in the source program to be tested.

[0034] The second aspect of the present application provides a test case generation device, which includes:

[0035] An acquisition module for acquiring the control flow graph of the source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested;

[0036] A determination module for determining the coverage condition of the data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested;

[0037] A generation module for generating a target test case, where the target test case is used to test all data flow paths of the source program to be tested.

[0038] A third aspect of the present application provides a computer device, including a memory and a processor. A computer-readable instruction is stored in the memory. When the computer-readable instruction is executed by the processor, the processor executes the method for generating test cases described in the embodiments of the present application.

[0039] A fourth aspect of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for generating test cases described in the embodiments of the present application is implemented.

[0040] The technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0041] In the method for generating test cases described in the embodiments of the present application, a control flow graph of a source program to be tested is obtained, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested; based on the control flow graph, a coverage condition of data flow is determined, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested; a target test case is generated, where the target test case is used to test all data flow paths of the source program to be tested; thus, the present application focuses on definition-use pairs through data flow analysis, only covers the paths related to the actual dependencies of variables, overcomes the problem of exponential growth of the state space caused by traversing all control flow paths in the prior art, reduces the cost and complexity of program testing, and improves the accuracy of testing.

[0042] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. Description of the Drawings

[0043] By reading the detailed description of the preferred embodiments below, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present application. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0044] Figure 1 is a schematic diagram of the steps of a method for generating test cases in an exemplary embodiment of the present application;

[0045] Figure 2 is a schematic diagram of the steps of obtaining a control flow graph of a source program to be tested in an exemplary embodiment of the present application;

[0046] Figure 3 is a schematic diagram of lexical analysis, syntax analysis, and semantic analysis provided in an exemplary embodiment of the present application;

[0047] Figure 4It is a schematic diagram of the syntax parsing tree listener access mechanism provided by an exemplary embodiment of the present application;

[0048] Figure 5 It is a schematic diagram of the steps for determining the coverage condition of data flow based on a control flow graph provided by an exemplary embodiment of the present application;

[0049] Figure 6 It is a schematic diagram of the first code snippet provided by an exemplary embodiment of the present application;

[0050] Figure 7 It is a schematic diagram of the second code snippet provided by an exemplary embodiment of the present application;

[0051] Figure 8 It is a schematic diagram of the structure of a test case generation device provided by an exemplary embodiment of the present application;

[0052] Figure 9 It is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application.

[0053] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. Detailed implementation manners

[0054] The following further describes the present application in detail with reference to the drawings and embodiments. It can be understood that the embodiments described herein are only used to explain the related invention, rather than limiting the invention. Additionally, it should be noted that for the sake of convenience of description, only parts related to the relevant invention are shown in the drawings.

[0055] In the field of industrial control, PLC (Programmable Logic Controller) is widely used in many key fields such as power, water conservancy, chemical industry, and aerospace. Since PLC software directly controls the core equipment in the safety system, once a vulnerability occurs, it may lead to serious casualties and property losses. Therefore, it is crucial to improve the test quality of PLC software. And the ST language (Structured Text) in the IEC 61131-3 standard, as one of the main languages for PLC programming, the test level of its programs becomes a key link to ensure product reliability.

[0056] In existing test technologies, automated test cases are usually used to evaluate the test coverage of a program. However, common automated test case generation methods face some challenges: Whenever the program encounters a branch point, two possible execution paths will be generated. As the program scale increases, the number of these paths may grow exponentially, resulting in the so-called "path explosion" problem. The rapid expansion of the state space caused by path explosion makes the process of generating effective test cases extremely time-consuming and resource-intensive, thereby increasing the cost and complexity of testing.

[0057] To this end, the present application provides a method for generating test cases, as Figure 1 shown, the method includes S1 - S3.

[0058] S1. Obtain the control flow graph of the source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested.

[0059] In a possible implementation manner, as Figure 2 shown, the obtaining of the control flow graph of the source program to be tested includes S11 - S14.

[0060] Before step S11, obtain the syntax definition of the ST language from the IEC 61131 - 3 standard, write a syntax specification file for parsing the ST source code according to this syntax definition, and implement lexical analysis, syntax analysis, and semantic analysis of the source code based on this syntax specification. Figure 3 shows a flow schematic diagram of lexical analysis, syntax analysis, and semantic analysis of a section of ST source code. As Figure 3 shown, the lexical analysis, syntax analysis, and semantic analysis of the source code correspond to a lexical analyzer, a syntax analyzer, and a semantic analyzer.

[0061] S11. Identify multiple syntax units from the character sequence of the source program to be tested.

[0062] In this step, first, through the lexical analyzer of the ST language syntax definition in the IEC 61131 - 3 standard, read the character sequence of the source program to be tested; then, according to the syntax specification, ignore meaningless factors (such as whitespace characters and comments), divide the character sequence into multiple meaningful lexical units (tokens), and output a token list containing multiple meaningful lexical units.

[0063] S12. Construct a syntax parse tree according to the multiple syntax units.

[0064] In this step, based on the syntax analyzer, combine the sorting order of each lexical unit according to the syntax rules, so as to construct a syntax parse tree.

[0065] S13. Filter the valid program content in the syntax parse tree to obtain an abstract syntax tree.

[0066] In this step, first, traverse the syntax parse tree according to the semantic analyzer, perform semantic error - related checks on the source code, such as: type checking, variable scope and lifecycle checking, context - related meaning checking of the syntax structure, confirm whether there are problems in the code logic, and obtain a syntax parse tree without semantic errors; after obtaining a syntax parse tree without semantic errors, as Figure 4As shown: Based on the listener mechanism, traverse the syntax parse tree without semantic errors, separate and remove invalid program content, and construct an abstract syntax tree. Among them, the listener mechanism accesses the syntax parse tree nodes layer by layer, provides the enter() method when entering each node, and provides the exit() method when leaving the node.

[0067] S14. Construct a control flow graph of the source program to be tested based on the key statements in the abstract syntax tree, where the key statements refer to the statements that represent the control flow execution nodes in the source program to be tested.

[0068] Specifically, the constructed abstract syntax tree includes some key nodes, such as input variable declaration nodes, conditional branch nodes, assignment statement nodes, and so on. Then, based on the key statements in the abstract syntax tree, such as jump statements and branch entry / exit, divide basic blocks and connect them.

[0069] S2. Determine the coverage conditions of the data flow based on the control flow graph, where the coverage conditions of the data flow include covering all data flow paths of the source program to be tested.

[0070] In a possible implementation, as Figure 5 shown, determining the coverage conditions of the data flow based on the control flow graph includes steps S21 - S22.

[0071] S21. Perform data flow analysis based on the control flow graph to identify the definition points and usage points of all variables in the source program to be tested, where the definition point is the statement node where the variable is assigned a value, and the usage point is the statement node where the variable is referenced.

[0072] Figure 6 Show the first code snippet, as Figure 6 shown, traverse the control flow graph to identify the definition points (Def) and usage points (Use), that is, mark the operations of variables value and sensor. For example, value is a definition point, value * 2 and value := 0 are usage points.

[0073] S22. Construct a data flow coverage model based on the definition points and usage points of all variables in the source program to be tested, and determine the coverage conditions of the data flow through the data flow coverage model.

[0074] Furthermore, when constructing the data flow coverage model based on the definition points and usage points of all variables in the source program to be tested, first, based on path reachability analysis, generate all reachable usage points within the scope for each definition point to form a set of the first definition - usage pairs (DU pairs), that is, generate DU pairs through path reachability analysis and construct an initial set of DU pairs. For example, the first pair of DU pairs is that the value after assignment is used in the expression, and the second pair of DU pairs is that the assignment in the ELSE branch may be used by subsequent code.

[0075] It should be noted that when performing path reachability analysis, depth-first search or breadth-first search can be performed based on the control flow graph to determine the reachable paths from each variable definition point to its potential use points. Starting from the definition point and tracing backward along the control flow path to mark all nodes that may use the variable (such as the expression value*2) is forward reachability analysis. Conversely, starting from the use point and tracing forward along the control flow path to find all possible definition points (such as the initial assignment of value) is backward reachability analysis.

[0076] When generating DU pairs, if the definition point and the use point are in the same basic block and there is no intermediate redefinition, then directly generate DU pairs; if the definition point is in basic block A, the use point is in basic block B, and there is a path from A to B, then generate cross-block DU pairs; for variables within a loop, by expanding the loop such as setting the maximum expansion times, generate iterative-dependent DU pairs.

[0077] Figure 7 Show the second code snippet, such as Figure 7 As shown, the initial DU pair set, i.e., the first DU pair set, is "Def(BB2: y := x + 1) → Use(BB4: y * 2)" and "Def(BB3: y := 0) → Use(BB4: y * 2)".

[0078] Next, perform semantic validity checks on the initial DU pair set, i.e., the first definition-use pair set, to obtain the second DU pair set. The specific checks include at least one of the following: For each DU pair in the initial DU pair set, check whether the data type of the variable at the use point is consistent with that at the definition point. For example, check the type matching of value in the assignment (INT) and use (arithmetic operation); for another example, verify whether the data types of the variable at the definition point and the use point match. For example, if the definition point assigns x := 10 (INT type), and the use point expression is x := x + "text" (string concatenation), then mark this DU pair as invalid. For each DU pair in the initial DU pair set, verify whether the scope of the variable at the use point is legal. For example, in "IF condition THEN VAR_TEMP temp: INT := 5; / / Temporary variable, scope limited to the THEN branch", the scope of "temp" is limited to the THEN branch, and if it is used outside the branch, it is marked as illegal. Exclude invalid DU pairs caused by control flow unreachability or context conflicts. For example, for global variables or cross-module variables, check whether their visibility rules allow use at the target location. After filtering, if the types of Def(BB3) and Use(BB4) do not match, then only retain Def(BB2) → Use(BB4) as the second DU pair set.

[0079] Use dynamic symbolic execution technology to generate coverage paths and extract constraints for each DU pair in the second set of DU pairs, retain the feasible DU pairs with solutions, and use the feasible DU pairs as the third set of DU pairs; construct a data flow coverage model according to the third set of DU pairs, and the data flow coverage model stores the coverage paths and their path constraints of each feasible DU pair. It can be understood that through the progressive screening of the three-level DU pair sets, only the feasible paths are retained, avoiding the generation of invalid test cases.

[0080] In one embodiment, when performing dynamic symbolic execution and path constraint extraction, first convert the ST code into a symbolic expression in SMT-LIB format. Then extract the logical constraints for the coverage path of each DU pair. For example, referring to Figure 7 again, the path constraint for covering Def(BB2)→Use(BB4) is "x>0". Further, call the SMT solver to verify the satisfiability of the path constraint. If there is a solution, retain the DU pair and record the test input corresponding to the solution (such as `x = 5`); if there is no solution, mark the DU pair as infeasible. For example, the path constraint "x>0 AND x<0" has no solution.

[0081] It can be understood that the data flow coverage model gradually constructs a complete data dependency graph through the progressive screening of the three-level DU pair sets. The initial set, that is, the first set of DU pairs, is used as the original input, the second set of DU pairs is generated through semantic checks, and then the third set of DU pairs is generated through dynamic symbolic execution verification. The model finally stores all feasible DU pairs, coverage paths, and constraint conditions, forming the direct basis for test case generation.

[0082] S3. Generate target test cases, where the target test cases are used to test all data flow paths of the source program to be tested.

[0083] Preferably, before generating the target test cases, the data flow coverage model extracts the constraints of all feasible paths (such as x>0) from the third set of DU pairs and passes these constraints to the SMT solver. The test inputs (such as x = 5) returned by the solver are directly bound to the DU pairs in the model to ensure that each test case clearly corresponds to a specific data dependency path. In addition, the model uses a coverage rate statistics module to monitor the test progress in real time and drive the dynamic symbolic execution engine to supplement test cases for uncovered paths.

[0084] In a specific implementation manner, the step of generating the target test cases includes: extracting the path constraints of the coverage paths of each feasible definition-use pair; calling the SMT solver to solve the path constraints, and if there is a solution, generating a test input that covers the definition-use pair; combining all the generated test inputs into the target test cases.

[0085] When calling the SMT solver to solve the path constraints, first, a maximum expansion times limit is set for the nested loop structure to generate loop path variants with a finite depth. For example, in "WHILE i<3 DO i:=i+1; END_WHILE", the maximum expansion times for the loop structure is set to 3 times. Second, constraints are independently extracted for each sub-path in the branch path to ensure that all data flow paths under branch conditions are covered. For example, for a composite condition like "IF A OR B", the composite condition can be split into independent sub-paths to generate independent constraints respectively. Finally, for the path variants and each sub-path, a candidate path filter is used to select uncovered candidate paths according to the depth-first search strategy. For example, untested DU pairs are preferentially covered, the path generation order is dynamically adjusted, and DU pairs associated with dominant nodes are preferentially covered to improve the critical path coverage rate.

[0086] Further optionally, test case verification and coverage feedback are also performed. First, tests are executed and coverage information is collected. Second, feedback and iterative optimization are carried out. For example, the test input is loaded into the PLC simulation environment, the program under test is executed, and the actual covered paths are recorded. The actual covered paths are compared with the expected paths in the data flow coverage model, and the coverage rate index is calculated. If there are uncovered DU pairs, the dynamic symbolic execution engine is called again to generate supplementary test cases. For contradictory constraints (such as infeasible paths caused by hardware dependencies), the data flow coverage model is updated. In other words, according to the path constraints in the data flow coverage model, the SMT solver is called to generate inputs, and the coverage status is dynamically updated by comparing the expected paths and the actual paths in the data flow coverage model.

[0087] It should be noted that the loop expansion and branch splitting strategies can ensure full coverage of nested structures and composite conditions. Moreover, the generated test cases can be directly mapped to the PLC single-cycle execution logic, supporting hardware-in-the-loop (HIL) testing. And through path merging and minimum test set generation, the number of test cases can be reduced by more than 40%. It can be understood that the present application focuses on definition-use pairs through data flow analysis, only covering paths related to the actual dependencies of variables, overcoming the problem of exponential growth of the state space caused by traversing all control flow paths in the prior art, reducing the cost and complexity of program testing, and improving the accuracy of testing.

[0088] In some other embodiments of the present application, a test case generation device is also provided, as Figure 8 shown. The device includes:

[0089] An acquisition module 801, configured to acquire a control flow graph of a source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested;

[0090] A determination module 802, configured to determine a coverage condition of a data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested;

[0091] A generation module 803, configured to generate target test cases, where the target test cases are used to test all data flow paths of the source program to be tested.

[0092] The device also overcomes the problem in the prior art that the state space grows exponentially due to traversing all control flow paths, reduces the cost of program testing and the complexity of testing, and improves the accuracy of testing.

[0093] Please refer to the following Figure 9 , which shows a schematic diagram of an electronic device provided by some embodiments of the present application. As Figure 9 shown, the electronic device 2 includes: a processor 200, a memory 201, a bus 202, and a communication interface 203. The processor 200, the communication interface 203, and the memory 201 are connected through the bus 202; a computer program that can run on the processor 200 is stored in the memory 201. When the processor 200 runs the computer program, it executes the test case generation method provided by any one of the foregoing embodiments of the present application. The method includes: obtaining a control flow graph of the source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested; determining a coverage condition of a data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested; generating target test cases, where the target test cases are used to test all data flow paths of the source program to be tested.

[0094] Among them, the memory 201 may include a high-speed random access memory (RAM: Random Access Memory), and may also include a non-volatile memory, such as at least one disk memory. Through at least one communication interface 203 (which may be wired or wireless), a communication connection is established between the system network element and at least one other network element, and the Internet, a wide area network, a local area network, a metropolitan area network, etc. can be used.

[0095] The bus 202 may be an ISA bus, a PCI bus, an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. Among them, the memory 201 is used to store a program. After receiving an execution instruction, the processor 200 executes the program. The control method disclosed in any one of the foregoing embodiments of the present application may be applied to the processor 200 or implemented by the processor 200.

[0096] The processor 200 may be an integrated circuit chip with the ability to process signals. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 200 or the instructions in the form of software. The above-mentioned processor 200 may be a general-purpose processor, including a central processing unit (CPU for short), a network processor (NP for short), etc.; it may 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 gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware decoding processor, or executed and completed by the combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory 201, and the processor 200 reads the information in the memory 201 and combines its hardware to complete the steps of the method for generating the test case.

[0097] The embodiment of the present application also provides a computer-readable storage medium corresponding to the method for generating a test case provided in the foregoing embodiment. A computer program is stored thereon, and when the computer program is run by a processor, it will execute the method for generating a test case provided in any of the foregoing embodiments.

[0098] In addition, examples of the computer-readable storage medium may also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other optical and magnetic storage media, which will not be elaborated herein one by one.

[0099] In addition, an embodiment of the present application also provides a computer program product, including a computer program, which when executed by a processor implements the method for generating test cases provided in any of the foregoing embodiments. The method includes: obtaining a control flow graph of a source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested; determining a coverage condition of a data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested; generating a target test case, where the target test case is used to test all data flow paths of the source program to be tested.

[0100] Those skilled in the art can understand that each component embodiment of the present application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components in the virtual machine creation device according to the embodiments of the present application.

[0101] As described above, only the preferred specific embodiments of the present application are provided, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for generating test cases, characterized in that, The method includes: Obtaining a control flow graph of the source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested; Determining the coverage condition of the data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested; Generating target test cases, where the target test cases are used to test all data flow paths of the source program to be tested.

2. The method for generating a test case according to claim 1, wherein The determining the coverage condition of the data flow based on the control flow graph includes: Performing data flow analysis according to the control flow graph to identify the definition points and usage points of all variables in the source program to be tested, where the definition point is the statement node where the variable is assigned a value, and the usage point is the statement node where the variable is referenced; Constructing a data flow coverage model based on the definition points and usage points of all variables in the source program to be tested, and determining the coverage condition of the data flow through the data flow coverage model.

3. The method for generating a test case according to claim 2, wherein The constructing a data flow coverage model based on the definition points and usage points of all variables in the source program to be tested includes: Based on path reachability analysis, generating all reachable usage points within the scope for each definition point to form a first set of definition-use pairs; Performing semantic validity check on the initial set of definition-use pairs to obtain a second set of definition-use pairs; Using dynamic symbolic execution technology to generate coverage paths and extract constraints for each definition-use pair in the second set of definition-use pairs, retaining the feasible definition-use pairs with solutions, and using the feasible definition-use pairs as a third set of definition-use pairs; Constructing a data flow coverage model according to the third set of definition-use pairs, where the data flow coverage model stores the coverage paths and path constraints of each feasible definition-use pair.

4. The method for generating a test case according to claim 3, wherein The generating target test cases includes: Extracting the path constraints of the coverage paths of each feasible definition-use pair; Invoking an SMT solver to solve the path constraints, and if there is a solution, generating a test input that covers the definition-use pair; Combining all the generated test inputs into target test cases.

5. The method for generating a test case according to claim 4, wherein, The invoking an SMT solver to solve the path constraints includes: Setting a maximum expansion times limit for nested loop structures to generate loop path variants with a finite depth; Independently extracting constraints for each sub-path in the branch path to ensure that all data flow paths under branch conditions are covered; For the path variants and each sub-path, using a candidate path filter to select uncovered candidate paths according to the depth-first search strategy.

6. The method for generating a test case according to claim 3, wherein The performing semantic validity check on the initial set of definition-use pairs to obtain a second set of definition-use pairs includes at least one of the following: For each definition-use pair in the initial set of definition-use pairs, checking whether the data type of the variable at the usage point is the same as that at the definition point; For each definition-use pair in the initial set of definition-use pairs, verifying whether the scope of the variable at the usage point is legal; Excluding invalid definition-use pairs caused by unreachable control flow or context conflicts.

7. The method for generating a test case according to claim 1, wherein The obtaining a control flow graph of the source program to be tested includes: Identify a plurality of syntax units from the character sequence of the source program to be tested; Construct a syntax parsing tree based on the plurality of syntax units; Filter the valid program content in the syntax parsing tree to obtain an abstract syntax tree; Construct a control flow graph of the source program to be tested based on the key statements in the abstract syntax tree, where the key statements refer to the statements that represent the control flow execution nodes in the source program to be tested.

8. A test case generation device, characterized in that, The apparatus includes: An acquisition module, configured to acquire a control flow graph of a source program to be tested, where the control flow graph represents the control flow relationship between each program statement in the source program to be tested; A determination module, configured to determine a coverage condition of a data flow based on the control flow graph, where the coverage condition of the data flow includes covering all data flow paths of the source program to be tested; A generation module, configured to generate a target test case, where the target test case is used to test all data flow paths of the source program to be tested.

9. A computer device, comprising a memory and a processor, characterized in that, Computer-readable instructions are stored in a memory. When the computer-readable instructions are executed by a processor, the processor executes the test case generation method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the test case generation method according to any one of claims 1-7.

Images