Unit test case generation method and device, equipment and medium

Abstract

The invention relates to the technical field of research and development management and the field of financial science and technology, and discloses a unit test case generation method, which comprises the following steps: compiling a current project to generate a class file, carrying out byte code analysis on the class file, traversing each class and method in the class file, and extracting control flow information and calling relation information. Determining circle complexity and call chain information of each method based on the extracted information, and generating path information required by the test case; simulating the execution path to generate a basic unit test case, determining an effective test case by utilizing an evaluation standard, and taking the effective test case as a template for generating a new case; and identifying the to-be-tested code of which the test case is not generated in the class file, generating a new test case by using the template, integrating the effective test case and the new test case, and generating a complete unit test case set. According to the method, by combining byte code analysis and path simulation, dependence on code context is reduced, and the effectiveness of the test case is improved through variation test and coverage rate evaluation.

Description

Technical Field

[0001] The present invention relates to the fields of research and development management technology and financial technology, and in particular to a unit test case generation method, device, equipment and storage medium. Background Art

[0002] In the field of unit testing of banking business, traditional unit testing tools usually use methods based on source code bytecode analysis to generate test cases. These tools (such as EvoSuite, TestMe, Diffblue, etc., which are widely used in the industry) mainly use the bytecode analysis tool ASM to automatically generate unit test cases. The advantage of this method is that it can accurately generate test cases that conform to the context call relationship by analyzing the code context, thereby ensuring the logical validity of the generated test code. However, traditional bytecode analysis tools have high requirements for development frameworks and code writing styles. Therefore, under some complex development frameworks or special code styles, it may be impossible to generate or incompletely generate, resulting in some errors or insufficient coverage in the generated test cases. In order to ensure the completeness and accuracy of the test, business personnel often need to manually modify and supplement test cases, which increases the workload.

[0003] In banking business scenarios, the quality and coverage of unit testing are crucial, but existing development and testing human resources are limited, and a large amount of existing code needs to be tested. The generation efficiency of traditional tools and the generation accuracy of AI tools have the following shortcomings when dealing with the testing of massive code:

[0004] Traditional tools rely on contextual analysis of bytecode and are heavily dependent on frameworks and coding styles, which can easily lead to errors or insufficient coverage in complex scenarios.

[0005] Although AI tools are fast at generating test cases, the quality of the generated test cases varies, the accuracy of package references and data filling is low, and it is difficult to batch generate and manage unit tests for the entire code.

[0006] The amount of code in banking business systems is huge and complex. The existing testing manpower is insufficient to cope with the tasks of generating and completing unit tests for massive amounts of code, making it difficult to ensure efficient test coverage. Summary of the invention

[0007] The main purpose of the present invention is to provide a unit test case generation method, device, equipment and storage medium, aiming to solve the technical problems of the prior art in which traditional bytecode analysis tools have dependence on code context and insufficient generation coverage when generating unit test cases.

[0008] To achieve the above object, the present invention provides a unit test case generation method, comprising:

[0009] Compile the current project to generate class files;

[0010] Performing bytecode analysis on the class file, traversing each class and each method in the class file, and extracting control flow information and call relationship information of each method;

[0011] Determine the cyclomatic complexity of each method based on its control flow information;

[0012] Generate path information required for the test case based on the cyclomatic complexity of each method and the call relationship information;

[0013] According to the path information, simulate the execution path and generate basic unit test cases;

[0014] Determining valid test cases among the basic unit test cases according to predetermined evaluation criteria;

[0015] Using the effective test case as a template for generating new test cases;

[0016] Identify the code to be tested for which no test case is generated in the class file, and use the template to generate a new test case for the code to be tested according to the code to be tested;

[0017] Integrate the valid test cases and the new test cases to generate a complete unit test case set.

[0018] Furthermore, to achieve the above object, the present invention provides a unit test case generation device, comprising:

[0019] Compile module, used to compile the current project to generate class files;

[0020] A bytecode analysis module is used to perform bytecode analysis on the class file, traverse each class and each method in the class file, and extract control flow information and call relationship information of each method;

[0021] A cyclomatic complexity analysis module for determining the cyclomatic complexity of each method based on the control flow information of each method;

[0022] A path information generation module, used for generating path information required for test cases based on the cyclomatic complexity of each method and the call relationship information;

[0023] A path simulation execution module is used to simulate the execution path according to the path information and generate basic unit test cases;

[0024] A test case analysis module, used to determine valid test cases in the basic unit test cases according to a predetermined evaluation standard;

[0025] A template generation module, used to use the valid test case as a template for generating a new test case;

[0026] A new test case generation module is used to identify the code to be tested for which no test case has been generated in the class file, and to generate a new test case for the code to be tested according to the code to be tested using the template;

[0027] The test case integration module is used to integrate the valid test cases and the new test cases to generate a complete unit test case set.

[0028] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a unit test case generation program stored in the memory and executable on the processor, and the unit test case generation program, when executed by the processor, implements the steps of the unit test case generation method as described above.

[0029] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a unit test case generation program is stored, and when the unit test case generation program is executed by a processor, the steps of the unit test case generation method as described above are implemented.

[0030] Beneficial effects: The present invention relates to the technical field of R&D management and the field of financial technology, and discloses a method for generating unit test cases. The method generates a class file by compiling the current project, performs bytecode analysis on the class file, traverses each class and method in the class file, extracts control flow information and call relationship information, determines the cyclomatic complexity and call chain information of each method based on the extracted information, and generates the path information required for the test case; generates basic unit test cases by simulating the execution path, determines the effective test case by using the evaluation criteria, and uses it as a template for generating new test cases; identifies the code to be tested in the class file for which no test case is generated, generates a new test case by using the template, integrates the effective test case and the new test case, and generates a complete set of unit test cases. The present invention reduces the dependence on the code context by combining bytecode analysis and path simulation, and generates the test path by cyclomatic complexity and call relationship, and improves the effectiveness of the test case by mutation testing and coverage evaluation. The efficient automatic generation and comprehensive coverage of unit test cases are achieved, and the generation quality and management efficiency of test cases are significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0032] Figure 1 A schematic diagram of an application environment of a method for generating unit test cases in an embodiment of the present invention;

[0033] Figure 2 A schematic diagram of a flow chart of an embodiment of a method for generating unit test cases of the present invention;

[0034] Figure 3 A schematic diagram of functional modules of a preferred embodiment of the unit test case generating device of the present invention;

[0035] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0036] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0037] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0038] The unit test case generation method provided by the embodiment of the present invention can be applied in the following aspects: Figure 1 In an application environment, the user end communicates with the server end through a network. The server end can compile the current project through the user end to generate a class file, perform bytecode analysis on the class file, traverse each class and method in the class file, extract control flow information and call relationship information, determine the cyclomatic complexity and call chain information of each method based on the extracted information, and generate the path information required for the test case; simulate the execution path to generate a basic unit test case, use the evaluation criteria to determine the effective test case, and use it as a template for generating a new test case; identify the code to be tested in the class file that has not generated a test case, use the template to generate a new test case, integrate the effective test case and the new test case, and generate a complete set of unit test cases. The present invention combines bytecode analysis and path simulation, and generates a test path through cyclomatic complexity and call relationship, thereby reducing the dependence on code context, and improving the effectiveness of test cases through mutation testing and coverage evaluation. The efficient automatic generation and comprehensive coverage of unit test cases are achieved, and the generation quality and management efficiency of test cases are significantly improved. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0039] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for generating unit test cases provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0040] like Figure 2 As shown, the unit test case generation method proposed in the present invention includes the following steps:

[0041] S10, compile the current project to generate class files;

[0042] In this embodiment, compiling the current project to generate a class file is the starting step of the entire method. The purpose of this step is to compile the source code files (such as .java files) in the project into bytecode files (i.e., .class files) so that subsequent bytecode analysis and test case generation have basic data input. The class file is the basic unit executed by the Java Virtual Machine (JVM), containing compiled bytecode instructions, method definitions, field descriptions, and metadata information of the class.

[0043] You can choose to use the standard JDK compiler (javac) or integrated build tools (such as Maven, Gradle) to compile in your project. When using tools such as Maven and Gradle, you can automatically manage project dependencies, compilation commands, target output paths, etc. by writing build configuration files (such as pom.xml or build.gradle).

[0044] In the command line or integrated development environment (IDE), run the compilation command, such as javac -d . / out . / src / ** / *.java, to compile all source code files into the specified output directory. Maven and Gradle automatically complete the same task through their configuration files, such as Maven using the mvn compile command.

[0045] After successful compilation, each class and method in the source code will generate a corresponding .class file, and the file path and package name will correspond. The compiler will perform syntax checking, dependency parsing, bytecode generation and other operations during this process. If there is an error (such as syntax error, type mismatch, etc.), an error message will be output.

[0046] Example: In financial applications, financial business systems usually include a large amount of Java code, which needs to be unit tested. In this scenario, by using build tools such as Maven, you can efficiently manage the compilation process of financial business codes and automatically generate class files that contain the bytecode of business logic.

[0047] By compiling and generating class files, the source code of the project can be converted into a binary file containing bytecode, which provides the basic data required for subsequent bytecode analysis. At the same time, using standard compilation tools or build tools can automatically manage the compilation process of the project, reducing the complexity and error probability of manual compilation.

[0048] S20, performing bytecode analysis on the class file, traversing each class and each method in the class file, and extracting control flow information and call relationship information of each method;

[0049] In this embodiment, the bytecode content contained in each class file is analyzed to obtain the definition of the class, the logic of the method, the control flow and the process of calling information. By analyzing the bytecode, the logical structure of each class and method and its interaction with other classes and methods can be understood without relying on the source code. Bytecode analysis usually uses a bytecode operation library, such as ASM, Javassist, BCEL, etc.

[0050] Scan and obtain all defined classes and methods contained in each class file in the project. Each class file may contain one or more inner classes and methods, so these class files need to be fully traversed.

[0051] Control flow information describes all basic blocks, loops, conditional branches, and jump logic in a method. Through control flow information, each independent path in a method and its possible execution results can be identified.

[0052] Call relationship information describes which other methods or classes a method calls when it is executed. It contains information about the method's entry, exit, and the class or method called. This information is used to determine the mutual impact between methods when generating test cases.

[0053] Use Java's class loading mechanism or bytecode analysis library (such as ASM) to read each .class file. For each class file in the project, you need to read the class definition through ClassReader. Use bytecode analysis tools (such as ASM's ClassVisitor and MethodVisitor) to traverse each class and method. This process can parse the class metadata (such as class name, modifiers, parent class, implemented interface, etc.) and method definition (such as method name, parameters, return type, etc.). Use bytecode tools to analyze the bytecode instructions of each method and build a control flow graph (CFG, ControlFlow Graph). The control flow graph consists of basic blocks and branches. Each basic block contains a set of bytecode instructions executed sequentially, and the branch represents the conditional jump or loop of the program. According to the control flow graph, independent paths, conditional judgments, and loop structures in the method can be identified.

[0054] When traversing the bytecode instructions of a method, record all INVOKE instructions (such as INVOKEVIRTUAL, INVOKESTATIC, INVOKESPECIAL, etc.) to extract the calling relationship of the method. These instructions indicate which other methods are called by the current method. The target of the call can be a method of the current class, a method of an external class, or a method of a system library. In this way, a method call graph can be constructed, where each node represents a method and the edge represents the calling relationship between methods.

[0055] Example description: In the financial field, banking business codes usually include complex transaction processing and data calculation logic. When using bytecode analysis, the control flow and call relationship of financial transaction classes and methods can be parsed, such as identifying the logical branches, data verification links, exception handling codes, etc. of each transaction. In this way, accurate unit test cases can be generated for financial transaction classes to ensure test coverage and accuracy of various transaction scenarios.

[0056] By traversing the class files with bytecode analysis tools (such as ASM), you can directly extract the control flow information and call relationship information of classes and methods without relying on source code. It can perform unified analysis under different project structures and programming styles, provide the control flow path and call relationship diagram of the method, and provide accurate data support for the subsequent generation of test cases.

[0057] S30, determining the cyclomatic complexity of each method based on the control flow information of each method;

[0058] In this embodiment, cyclomatic complexity is an important indicator for measuring code complexity, which indicates the number of independent paths in a program and is used to reflect the logical complexity of a method or function. The higher the cyclomatic complexity, the more branches and conditions there are in the code, and the more difficult it is to test the code.

[0059] Control flow information is represented by a control flow graph (CFG), which describes the execution order, conditional judgment, loop structure and jump of the method. The nodes of the control flow graph represent basic blocks, and the edges represent the execution path from one basic block to another.

[0060] According to the extracted control flow information, the cyclomatic complexity of each method is calculated by analyzing the nodes and edges of the control flow graph. The cyclomatic complexity can be calculated by the McCabe formula, that is, V(G) = E-N+2P.

[0061] Where V(G) represents cyclomatic complexity, E represents the number of edges in the control flow graph, N represents the number of nodes in the control flow graph, and P represents the number of independent connected subgraphs in the graph (usually 1). Cyclomatic complexity represents the number of independent paths in a program, which directly affects test coverage and test case design.

[0062] Using the control flow information extracted in the previous step, construct a control flow graph for each method. The control flow graph consists of nodes and edges. Nodes represent basic blocks in a method, and edges represent jump relationships from one basic block to another. Identify the basic blocks in a method based on the conditional jumps, loop structures, and exception handling instructions in the bytecode instructions. A basic block refers to a group of consecutive instructions without branches. When the program enters a basic block, all instructions are executed sequentially until the end of the basic block. Identify conditional branches through conditional jump instructions in the bytecode (such as IFNE, IFEQ, etc.); identify loop structures in methods through loop instructions; and identify exception paths through exception handling instructions.

[0063] In the control flow graph, the number of nodes (N) represents the number of basic blocks in the method, and the number of edges (E) represents the connection relationship between the basic blocks in the method. By traversing the control flow graph, the number of nodes and edges in the control flow graph can be counted. The cyclomatic complexity of each method is calculated using the formula V(G) = E-N+2, where E represents the number of edges in the control flow graph and N represents the number of nodes in the control flow graph. Since most methods are a single connected subgraph in the code, the value of P is usually 1. The cyclomatic complexity of each method is stored in the bytecode analysis results as part of the method attributes. The cyclomatic complexity result can be used as an important basis for path selection when generating test cases later.

[0064] Example: In financial applications, the transaction processing logic of banks is usually very complex, containing a large number of branches, loops, and exception handling logic. By calculating the cyclomatic complexity of each transaction processing method, the complexity and potential risk points of each method can be quantified. For example, for a transaction method that processes user loan applications, the cyclomatic complexity can identify all logical branches and exception handling paths in the method, thereby generating unit test cases covering all paths to ensure the accuracy and security of the loan application processing logic.

[0065] By analyzing the control flow information of each method and calculating the cyclomatic complexity, the complexity of each method can be accurately quantified, and the number of independent paths that need to be tested can be determined. This provides a basis for path selection for the subsequent generation of unit test cases, ensuring that the test cases cover all independent paths and improving the comprehensiveness and effectiveness of the test.

[0066] S40, generating path information required for the test case based on the cyclomatic complexity of each method and the call relationship information;

[0067] In this embodiment, cyclomatic complexity indicates the number of independent paths in a method, and the complexity of the method can be understood through cyclomatic complexity. Based on cyclomatic complexity, each independent path in the method can be identified, providing a basis for path selection for generating test cases.

[0068] The call relationship information describes which other methods a method calls during execution, as well as the dependencies between methods. This helps determine the calling order and mutual influence between different methods.

[0069] Path information refers to the independently executable logical paths in each method, including normal paths, abnormal paths, and loop paths. By combining cyclomatic complexity and call relationship information, the path information of each method can be generated to guide the generation of test cases.

[0070] Using the cyclomatic complexity (V(G)) calculated in the previous step, identify each independent path in the method. Independent paths can be identified by the edges and nodes in the control flow graph (CFG). Each independent path is a different path from the entry to the exit of the method, passing through each conditional branch or loop point. For example, in a simple if-else structure, independent paths may include a path through the if condition and a path through the else condition.

[0071] By analyzing the bytecode of the method, the call relationship of each method is extracted. The call relationship information records which other methods the current method calls during execution, as well as the target methods and classes called. The call relationship information can form a method call graph (Call Graph) to represent the dependencies and influences between methods. Call relationship information plays a key role in path generation, especially when the test case needs to be verified across multiple methods, it can determine the context environment and dependent methods that need to be tested.

[0072] Based on the independent paths calculated by cyclomatic complexity, combined with the call relationships in each path, detailed information for each path is generated. Each path information includes the following:

[0073] Path ID: A unique identifier for each path, used for reference in subsequent test cases.

[0074] Path conditions: The input conditions that trigger the path, including parameter values, status settings, etc.

[0075] Method call chain: All method call relationships involved in the current path, which clearly indicates the calling order and dependencies between methods.

[0076] Expected result: The expected output or status of the path execution, including return value, exception status, etc.

[0077] The generated path information is stored in a database or memory data structure to provide a reference for subsequent test case generation. The path information records the independent path and call chain of each method to ensure that all paths are covered when test cases are generated.

[0078] Example: In the financial field, the bank's transaction processing system contains complex fund flow and account operation logic. For the method of processing a transfer operation, each logical branch can be identified by cyclomatic complexity, such as different paths such as successful transfer, insufficient balance, and exception handling; at the same time, combined with the call relationship information, other methods called in these paths (such as updating account balances, generating transaction records, etc.) can be determined. By generating path information, accurate test cases can be generated for each transaction scenario to ensure that all paths are verified, thereby improving the stability and security of the system.

[0079] By combining the cyclomatic complexity and call relationship information of each method, the path information required for the test case is generated, which can effectively cover all possible execution paths, including normal paths, abnormal paths, and cross-method call paths. This can ensure that the test case fully covers all key logic and reduce the risk of untested code execution.

[0080] S50, simulating the execution path according to the path information to generate a basic unit test case;

[0081] In this embodiment, the path information is generated by analyzing the control flow graph and call relationship information of each method, including the independent path, call chain, input conditions and expected output of the method. The path information provides a complete execution guide for generating test cases.

[0082] Simulating the execution path means simulating the execution process of the method under the guidance of the path information. This simulation can be based on the input conditions, branch selection and method call sequence preset in the path information. The purpose of the simulation is to verify the correctness of the path and ensure that the execution results of the path under different conditions meet expectations.

[0083] Basic unit test cases are test codes generated based on path simulation execution, which are used to verify the execution results of each path. Basic unit test cases include preset input conditions, method calls, and assertion logic.

[0084] Read the previously generated path information, including the path ID, trigger conditions, call chain, and expected results of each method. This path information provides input and verification basis for simulation execution. Based on the trigger conditions in the path information, configure the corresponding input parameters for each path. The input conditions can be method parameters, class status, or global variables. Configure the expected output of each path, including the return value of the method, the modified status, and possible exceptions.

[0085] Use the path information to simulate the execution of each path one by one to verify the execution of each path. The simulation execution can simulate the triggering of all conditional branches and exception handling by calling the methods in the running path. During the execution process, the execution status of each step is recorded to capture the execution results of each path.

[0086] Based on the results of the simulation execution, basic unit test cases are generated for each path. The test cases include the following:

[0087] Input parameter settings: corresponding to the input conditions of the path.

[0088] Method calls: The methods and order in which they are called in the simulation path.

[0089] Assertion logic: Verify the result of each method call based on the expected output. Assertion logic is used to ensure that the execution result of the path meets expectations.

[0090] Verify the completeness and correctness of the generated basic unit test cases through static analysis or preliminary testing. Ensure that the test cases for each path accurately reflect the content in the path information.

[0091] Example description: In financial applications, the transaction processing logic in banking systems usually contains complex input conditions and multiple logic paths. By generating information for each transaction processing path and simulating execution based on these paths, unit test cases covering all transaction scenarios can be generated. For example, for a transfer method that processes user account balances, the fund flow path of each account can be simulated, and abnormal situations (such as insufficient balance, account freeze, etc.) can be detected, thereby generating accurate unit test cases to ensure the accuracy of transaction logic.

[0092] By simulating the execution path according to the path information and generating basic unit test cases, it can be ensured that all independent paths of each method are effectively verified. The method of simulating the execution path can verify the executable nature of the path in advance and ensure that the generated test cases have high reliability and accuracy.

[0093] S60, determining valid test cases in the basic unit test cases according to a predetermined evaluation standard;

[0094] In this embodiment, the predetermined evaluation criteria refer to a set of indicators or rules used to evaluate the effectiveness of the test case. These criteria may include coverage indicators (such as line coverage, branch coverage, exception coverage, mutation coverage, etc.) to ensure the quality and coverage of the test case.

[0095] The basic unit test case is generated based on the aforementioned path information, including the test of each method's independent path. Each test case includes input conditions, method calls, and assertion logic.

[0096] An effective test case is a test case that has been verified by the predetermined evaluation criteria and can cover the key logic and exception handling paths of the code. An effective test case should meet the coverage standard and accurately capture errors and exceptions during operation.

[0097] The predetermined evaluation criteria include indicators such as line coverage, branch coverage, exception coverage, and mutation coverage. Different standards are used to measure the coverage of different aspects of the code by the test cases. The predetermined evaluation criteria need to be set according to the requirements of the project and the complexity of the code. Use coverage analysis tools (such as JaCoCo, Cobertura, etc.) to execute each basic unit test case and collect coverage data. Coverage analysis can count the coverage of each test case on the lines, branches, and exception handling paths of the code.

[0098] Line coverage: Counts the proportion of code lines covered by each test case to the total number of lines.

[0099] Branch coverage: Counts the ratio of the number of conditional branches (such as if-else and switch-case, etc.) covered by each test case to the total number of branches.

[0100] Exception coverage: Statistics show whether each test case covers all exception handling logic, including the coverage of normal paths and exception paths.

[0101] In mutation testing, artificial mutations (such as changing conditions, deleting statements, modifying return values, etc.) are introduced to verify whether the test case can catch the introduced errors. The purpose of mutation testing is to evaluate the robustness of the test case and ensure that it can detect potential problems in the code. Mutation coverage is used to represent the ratio of the number of mutations detected by the test case to the total number of mutations. High mutation coverage means that the test case can detect most of the intentionally introduced errors.

[0102] According to the predetermined evaluation criteria, analyze the coverage data and mutation test results of each test case. Filter out the test cases that meet the coverage and mutation coverage standards and mark them as valid test cases. Valid test cases should have sufficient coverage to cover the key paths and exception handling logic in the code, and be able to capture errors introduced by code mutations.

[0103] Example: In financial applications, the unit test of the banking system needs to verify a large number of transactions and account processing logic. Through the predetermined evaluation criteria, it can be ensured that each test case covers all important transaction paths and exception handling logic. For example, for the account transfer method, coverage analysis and mutation testing can be used to ensure that the test case can cover all normal transactions, insufficient balances, account freezes and other scenarios, thereby improving the stability and security of the banking system.

[0104] By determining the effective test cases in the basic unit test cases according to the predetermined evaluation criteria, it can be ensured that each test case has sufficient coverage and can accurately detect potential problems in the code. It can improve the quality and reliability of test cases and reduce undetected logical errors and exception handling problems in the code.

[0105] S70, using the valid test case as a template for generating a new test case;

[0106] In this embodiment, valid test cases are test cases selected through predetermined evaluation criteria, which have verified their coverage of the code and can accurately detect logical errors and exception handling problems. Valid test cases include test code, input conditions, method calls, assertion logic, expected output, etc.

[0107] Use effective test cases as reference templates, and use their structure, format, and logic rules to guide the generation of new test cases. The template includes the code format, data structure, method call relationship, assertion logic, and naming rules of the test case, ensuring that the generated new test case conforms to the original test style and standards.

[0108] Extract key information from the selected valid test cases, including input conditions, method call order, assertion logic, return value or exception handling, etc. The key information will be used as the core content of the template to guide the generation of new test cases. At the same time, extract the code format and naming rules of the valid test cases, which will help ensure that the generated new test cases are consistent with the style of the existing test cases.

[0109] Based on the extracted valid test cases, define the structure of the template. The template can include the following:

[0110] Input data format: Defines the data type and default value of the input parameter.

[0111] Method calling rules: Define the order and calling relationship of method calls based on the call chain extracted from the template.

[0112] Assertion logic template: defines the format and logic of assertion statements to ensure that newly generated test cases follow consistent rules when testing results.

[0113] Exception handling template: Define the logical structure of exception handling based on the exception path in the template.

[0114] Store the defined template information in a database or file for subsequent use in generating new use cases. The stored template information should include the format of the input conditions, the rules of the call chain, and the code snippet of the assertion logic.

[0115] When a new test case needs to be generated, use the stored template as a reference to generate a new test case. The generated new test case should follow the input data format, method call sequence, and assertion logic defined in the template to ensure the consistency of the structure and logic of the new test case. The application of the template can be achieved through program automation, by writing code generation tools or using AI models to automatically generate new test cases.

[0116] By using effective test cases as templates for generating new test cases, it is possible to ensure that the generated new test cases are consistent in code style, data structure, and logical rules. This can improve the quality of newly generated test cases, reduce inconsistencies or omissions that occur during manual writing, and thus improve the completeness and maintainability of the test.

[0117] S80, identifying the code to be tested for which no test case has been generated in the class file, and generating a new test case for the code to be tested according to the code to be tested using the template;

[0118] In this embodiment, during the test process, some codes may not generate corresponding test cases due to various reasons (such as complex logic, specific conditions not met, etc.). These uncovered codes include untested logic branches, exception handling paths or codes for special boundary conditions.

[0119] The template is extracted from the valid test cases previously screened, including the structure, format, input conditions, method call order, and assertion logic of the test cases. The purpose of using the template is to ensure that the generated new test cases are consistent with the existing valid test cases in format and logic.

[0120] For the code to be tested that has not generated test cases, use templates to generate new test cases to ensure that the uncovered code is also tested. The generated new test cases should conform to the structure and logic of the code to be tested to ensure the comprehensiveness of the test.

[0121] Use code coverage analysis tools (such as JaCoCo) to perform coverage analysis on all existing basic unit test cases and generate a code coverage report. The report contains the coverage of each class, method, and line of code. By analyzing the coverage report, identify those codes that are not covered in the existing test cases. These uncovered code parts may include unexecuted logic branches, exception handling logic, or boundary condition code. Extract the control flow information and calling relationship of the code to be tested: Further analyze the uncovered code to be tested to extract the control flow information of the code and the calling relationship of the method. This information helps to understand the execution path and dependencies of the code to be tested. According to the logic of the code to be tested, determine the possible input conditions and expected outputs. For example, for a conditional branch, you can determine the possible output results under different inputs.

[0122] According to the structure and characteristics of the code to be tested, select a suitable template to match. The template should be similar in structure to the code to be tested and be able to guide the generation of new test cases. According to the input rules in the template and the requirements of the code to be tested, set appropriate input parameters. According to the calling sequence of the template, build the call chain of the code to be tested to ensure that the test case can cover all method calls of the code to be tested. Based on the assertion rules in the template, add verification logic to the newly generated test case to ensure that the result of each method call can be correctly verified.

[0123] Perform static inspection or preliminary execution on the newly generated test cases to verify whether their format and logic meet the requirements. Ensure that the newly generated test cases can correctly cover the code to be tested. Store the newly generated test cases in the test case library so that they can be integrated and managed with the existing test cases.

[0124] By identifying the code to be tested in the class file that has not generated test cases, and using templates to generate new test cases, you can ensure that all uncovered code is effectively tested. Using templates can improve the consistency and generation efficiency of test cases, reduce omissions and logical inconsistencies during manual writing, and thus comprehensively improve code coverage and test quality.

[0125] S90, integrating the valid test cases and the new test cases to generate a complete unit test case set.

[0126] In this embodiment, the effective test cases are the test cases that meet the requirements after being screened out by evaluation criteria (such as coverage, branch coverage, etc.) The effective test cases can cover the main logic paths of the code and verify the correctness of the code.

[0127] New test cases are generated based on templates or identified uncovered code. These new test cases fill in the gaps in coverage of existing test cases, ensuring that all logic paths and exception handling are covered.

[0128] The unit test case set is a combination of all test cases, including valid test cases and newly generated test cases. This case set can be used as a complete test tool to verify the functional and logical correctness of the code. A complete unit test case set should be able to cover the code path of the project to the greatest extent possible.

[0129] Collect all valid test cases verified by the evaluation criteria from the test library. Valid test cases usually cover most common logic paths, basic functions, and known boundary conditions. Check these test cases to ensure that their logic and coverage are complete and compliant.

[0130] Integrate the new test cases generated based on uncovered code with the existing valid test cases. The new test cases should make up for the deficiencies in the valid test cases and cover the code logic, boundary conditions or abnormal paths that were not tested before. The newly generated test cases should be statically checked to ensure that the format, calling sequence and assertion logic meet the requirements of the template.

[0131] During the integration process, check whether there are duplicate test cases to avoid the same logical path being tested multiple times, which can improve the efficiency of test execution. Confirm the uniqueness and coverage of test cases through path analysis or coverage comparison. Optimize the execution order of test cases to ensure that the dependencies in the test case set are clear and avoid mutual interference between test cases.

[0132] Integrate the valid test cases and the newly generated test cases into a complete unit test case set. This test case set should be able to cover all key logic paths, conditional branches, and exception handling situations in the project. The complete unit test case set can be used as the final test resource to ensure that the project code can be fully verified every time it is changed or deployed.

[0133] The generated complete test case set is stored in the project's version control system. The test case set can be version controlled through version management tools (such as Git) to ensure that the test cases can be updated and maintained in a timely manner when the code is updated.

[0134] Generate a coverage report for the integrated test case set to ensure that the integrated test case set covers the code logic to the maximum extent. The report should include indicators such as coverage, branch coverage, and line coverage as a basis for evaluating the integration effect.

[0135] By integrating valid test cases and newly generated test cases to generate a complete set of unit test cases, all logical paths and exception handling situations of the project can be covered to the maximum extent, ensuring the robustness and security of the code. At the same time, through deduplication and optimization, the execution efficiency of the test can be improved and unnecessary repeated tests can be reduced. In addition, the complete test case set can also serve as a key component in the project's continuous integration (CI) and automated deployment, ensuring that each code change can be verified in a timely manner.

[0136] The present invention relates to the technical field of research and development management and the field of financial technology, and discloses a method for generating unit test cases, which generates a class file by compiling the current project, performs bytecode analysis on the class file, traverses each class and method in the class file, extracts control flow information and call relationship information, determines the cyclomatic complexity and call chain information of each method based on the extracted information, and generates the path information required for the test case; simulates the execution path to generate a basic unit test case, uses the evaluation criteria to determine the effective test case, and uses it as a template for generating a new test case; identifies the code to be tested in the class file that does not generate a test case, uses the template to generate a new test case, integrates the effective test case and the new test case, and generates a complete set of unit test cases. The present invention combines bytecode analysis and path simulation, and generates a test path through cyclomatic complexity and call relationship, reduces the dependence on code context, and improves the effectiveness of the test case through mutation testing and coverage evaluation. The efficient automatic generation and comprehensive coverage of unit test cases are achieved, and the generation quality and management efficiency of test cases are significantly improved.

[0137] In one embodiment, the above S40 includes:

[0138] S401, identifying independent control flow paths in each method based on the cyclomatic complexity of each method;

[0139] S402, extracting path information for generating test cases from the call relationship information and independent control flow paths of each method.

[0140] In this embodiment, cyclomatic complexity is an indicator to measure the complexity of a method, which indicates the number of independent paths in a program. Based on the analysis of cyclomatic complexity, independent paths in a method can be identified, such as basic conditional judgment, loop, exception handling, etc.

[0141] Call relationship information refers to the information about other methods or classes called by a method during execution. Call relationship helps determine the execution order of each method and the impact on each other.

[0142] Independent control flow paths refer to all independent execution paths within a method, usually represented by a control flow graph (CFG). Each path represents the execution flow of a method under different input conditions and states.

[0143] During the bytecode analysis, a control flow graph is constructed for each method. The control flow graph consists of nodes and edges. Nodes represent basic blocks in the method, and edges represent jumps in program execution. The cyclomatic complexity of each method is calculated using the control flow graph. The formula for calculating cyclomatic complexity is: V(G) = E-N+2P.

[0144] Where E is the number of edges in the graph, N is the number of nodes, and P is the number of connected subgraphs (usually 1).

[0145] According to the structure of the control flow graph, all possible independent paths in each method are identified. An independent path is a complete execution path from the entry to the exit of a method, which may go through logic such as conditional judgment, loop or exception handling. Call relationship information records other methods or classes called by each method during execution. By analyzing the call instructions in the bytecode, a method call graph can be constructed to represent the call relationship between methods. Combining independent paths with call relationship information can generate more comprehensive path information. Path information includes path ID, path conditions (such as input conditions, status), method call chain, etc.

[0146] The generated path information is stored in a database or memory data structure for use when generating test cases. The path information provides the basic data for test case generation and ensures that the test cases cover all possible execution paths.

[0147] This embodiment can generate comprehensive path information by combining the cyclomatic complexity and call relationship information of each method. This path information can effectively cover all independent execution paths and method calls, ensuring that the generated test cases cover all key logics and reduce the risk of untested paths.

[0148] In one embodiment, the above S50 includes:

[0149] S501, configuring corresponding input conditions and expected outputs for each path based on the path information;

[0150] S502, simulating the execution of each path to verify the execution status of each path;

[0151] S503, during the simulation execution process of each path, recording the execution status of each execution step;

[0152] S504, based on the result of the path simulation execution, generate a basic unit test case corresponding to each path.

[0153] In this embodiment, the path information is generated by analyzing the control flow graph and call relationship of the method, including the input conditions, call chain, trigger conditions and expected output of each independent path, etc. These path information provide the basic basis for generating test cases.

[0154] Simulating the execution path is to simulate the execution process of the path one by one according to the path information to verify the execution of the path. The goal of simulation execution is to simulate the actual execution of the path according to the input conditions, call sequence and expected output in the path information, and verify whether the path is executed as expected.

[0155] Basic unit test cases are test codes generated based on the results of simulated execution paths. Each test case contains input conditions, method calls, and assertion logic to verify the execution results of the path.

[0156] According to the input conditions in each path information, set the input data of each path. The input conditions can be method parameters, object properties, global status, etc. According to the logic of the path, set the expected execution result. The expected output can include return value, state change or exception throwing, etc.

[0157] Execute each method in the path in sequence according to the calling order in the path information. When simulating execution, you need to strictly follow the call chain and trigger conditions in the path information to simulate the execution of each method. After each method call, verify whether the execution result of the current method is consistent with the expectation. Verification includes checking the return value, state change, and exception throwing.

[0158] During the simulation execution, the execution status of each step in each path is recorded. The execution status can include the parameters of the method call, the return value, the call chain information, etc. These records can be used for subsequent debugging and analysis. For paths involving multiple method calls, the start and end time, input parameters and return value of each method call are recorded.

[0159] Generate the code of the basic unit test case based on the results of the path simulation execution. The test code should include the configuration of input parameters, method calls, and assertion logic. In the test code, define the assertion logic to verify the execution results of each path. The assertion logic can include the verification of return values, state changes, and exceptions.

[0160] Perform preliminary verification on the generated test cases to ensure that the format and logic of the test code meet the requirements. After verification, store the test cases in the test case library for further use and integration.

[0161] This embodiment can ensure independent verification of each path by simulating the execution path according to the path information and generating basic unit test cases. The simulated execution path can verify the executable and correctness of the path in advance, ensuring that the generated test cases can accurately reflect the actual logical path and method call.

[0162] In one embodiment, the above S60 includes:

[0163] S601, performing mutation testing on the original code under test tested by the basic unit test case to generate a mutated version of the code under test;

[0164] S602, using the basic unit test case, respectively executing the mutated version of the tested code and the unmutated original tested code;

[0165] S603, comparing the execution results of the variant version of the tested code with the original tested code;

[0166] S604, when the execution results are different, using corresponding test data and assertions to verify whether the basic unit test case can capture the error introduced by the mutation, so as to confirm whether the basic unit test case is a valid test case.

[0167] In this embodiment, the predetermined evaluation criteria refer to the criteria for evaluating the effectiveness of the basic unit test cases, including evaluation methods such as mutation testing and coverage. The main purpose of mutation testing is to verify whether the test cases can detect these changes by introducing artificial code changes.

[0168] Mutation testing is a software testing technique that introduces intentional errors (called mutations) into the original code to verify whether existing test cases can detect these errors. Mutations can include changing conditional statements, deleting statements, modifying return values, etc.

[0169] Mutated versions of the code under test are generated by introducing code mutations, with the aim of simulating potential errors in the code to verify the robustness of the test cases.

[0170] The original code under test refers to the code version without introducing mutations. It is the benchmark version used for comparison and verification by basic unit test cases.

[0171] By using mutation testing tools (such as Pitest), mutations are introduced into the original code under test. Mutations can include modifying conditional judgments, deleting certain code blocks, changing return values, etc. The purpose is to simulate potential errors in the code by introducing these mutations. After the mutations are introduced, one or more mutated versions of the code under test are generated. These mutated versions are used to verify the robustness of the test cases. Using basic unit test cases, run the mutated version and the original version without mutation respectively. By comparing the execution results of the two, the detection capability of the test case can be verified. After the test execution is completed, compare the execution results of the mutated version and the original version. The comparison of execution results includes the return value of the method, state changes, exceptions thrown, etc. When the execution results are different, verify whether the basic unit test case can capture the errors introduced by the mutation:

[0172] If the execution result of the variant version is different from the original version, it means that the introduced mutation has an impact on the behavior of the code.

[0173] Use the corresponding test data and assertions to verify whether the basic unit test cases can detect these differences. The assertions can include checking return values, state variables, exception information, etc.

[0174] If the base unit test case is able to detect the bug introduced by the mutation, it is marked as a valid test case. A valid test case means that it is robust enough to catch potential bugs in the code.

[0175] This embodiment can verify the robustness of the basic unit test cases by introducing mutation testing and comparing execution results. Mutation testing can help detect potential errors that may not be discovered in conventional testing, thereby improving the coverage and effectiveness of test cases.

[0176] In one embodiment, the above S60 includes:

[0177] S605, analyzing the line coverage of each basic unit test case;

[0178] S606, analyzing the branch coverage of each basic unit test case;

[0179] S607, analyzing the coverage of each basic unit test case on the exception handling logic;

[0180] S608, determining valid test cases in the basic unit test cases based on the line coverage, branch coverage and coverage of exception handling logic of the basic unit test cases.

[0181] In this embodiment, line coverage refers to how many lines of the tested code are covered during the execution of the test case. A high line coverage means that the test case can trigger and verify more lines of code, thereby improving the comprehensiveness of the test.

[0182] Branch coverage measures whether the test cases cover all conditional branches in the code, such as if-else structures, switch-case statements, etc. By analyzing branch coverage, you can determine whether the test cases verify all possible logic paths.

[0183] Exception handling logic includes exceptions and error handling paths that may be thrown by the program under certain conditions. Analyzing the coverage of exception handling logic by test cases can ensure that the test cases verify all potential exceptions and error paths.

[0184] Use coverage analysis tools (such as JaCoCo, Cobertura, etc.) to collect line coverage data for each test case when executing basic unit test cases. Coverage data includes the number of lines of code covered when each test case is executed. Based on the collected coverage data, calculate the line coverage of each test case. The calculation formula for line coverage is: Line coverage = number of lines of code covered / total number of lines of code × 100.

[0185] Store the line coverage data of each test case in the test report for subsequent analysis.

[0186] Through the coverage tool, count the number of conditional branches covered by each test case, including if-else branches, loop branches, and switch-case branches. Based on the coverage data, calculate the branch coverage of each test case. The calculation formula for branch coverage is: branch coverage = number of covered branches / total number of branches in the code × 100%.

[0187] Store branch coverage data for each test case in the test report.

[0188] In the code, identify all possible exception handling paths and error handling code blocks (such as try-catch blocks, throw statements, etc.). Use bytecode analysis tools or manual review to confirm the exception handling paths that need to be tested. Execute each basic unit test case to check whether all exception handling paths are triggered and covered. Record the exception handling paths that are covered and the paths that are not covered.

[0189] Comprehensively analyze the data of line coverage, branch coverage, and exception handling coverage to evaluate the coverage and effectiveness of each test case. According to the predetermined coverage standards (such as line coverage and branch coverage reaching more than 90%, exception handling coverage meeting 100%, etc.), filter out valid test cases that meet the standards and mark them as valid.

[0190] This embodiment can ensure that the test cases can cover all key code paths and error handling logic by comprehensively analyzing the line coverage, branch coverage and exception handling logic, which can improve the comprehensiveness and effectiveness of the test cases and reduce potential problems in the code.

[0191] In one embodiment, the above S80 includes:

[0192] S801, analyzing the code coverage of each class and each method in the class file, and identifying the code to be tested that is not covered by the valid test case;

[0193] S802, determining a test scenario based on the structure and functional characteristics of the code to be tested, and generating a new test case using the template.

[0194] In this embodiment, the code to be tested refers to those code parts that are outside the coverage of existing test cases. These codes may not be covered due to high logic complexity, special input conditions or lack of corresponding test scenarios. The template is extracted from the effective test case in the previous stage, which contains the format of the test case, the definition of input conditions, the calling sequence and the assertion logic. The template can be used to guide the generation of new test cases that conform to the style of existing test cases.

[0195] Code coverage refers to the coverage data of each class and method collected by coverage analysis tools such as JaCoCo. The coverage data includes information such as line coverage and branch coverage for each method, which is used to identify uncovered code sections.

[0196] Use coverage analysis tools (such as JaCoCo, Cobertura) to collect code coverage when existing test cases are executed. Generate a coverage report that includes line coverage, branch coverage, and other data for each class and each method. Identify code that is not covered by existing test cases by analyzing the coverage report. Uncovered code sections may include untriggered conditional judgments, unhandled exception paths, or special input boundary conditions. For uncovered code sections, analyze their code structure, including the method's logical flow, call chain, data flow, etc. Determine the basic logical structure and key dependencies of the code to be tested. Understand the functions of the code to be tested and determine possible input conditions and triggering scenarios. Functional features include the expected behavior of the code, processing conditions, and exception handling logic.

[0197] From the stored templates, select the template that best matches the structure and functional characteristics of the code to be tested. The template should be able to provide a test case structure with similar logic. Use the selected template to generate a new test case. The generation process includes:

[0198] Configure input conditions: Configure appropriate input parameters and conditions based on the functional characteristics of the code to be tested.

[0199] Build a method call chain: Build a call chain for the code to be tested based on the method call rules in the template.

[0200] Define assertion logic: In the newly generated test case, define the assertion logic related to the code under test to ensure that the output results of the code under test are verified during execution.

[0201] Perform static inspection and preliminary execution on the newly generated test cases to verify whether their format and logic meet the requirements. Store the new test cases in the test case library for subsequent integration and management.

[0202] This embodiment analyzes code coverage and identifies the code to be tested that is not covered by existing test cases, thereby ensuring that all important logic paths, exception handling paths, and special conditions can be effectively tested. Using templates to generate new test cases can improve generation efficiency and ensure that the new test cases are consistent with existing test cases in format and logic.

[0203] In one embodiment, after the above S90, the method further includes:

[0204] S1001, uploading the unit test case set to the unit test code repository of the current project;

[0205] S1002, retrieving unit test cases from the unit test code repository to execute tests;

[0206] S1003, analyzing the execution path, branch conditions, and exception handling logic of the code based on the test results, and determining whether the unit test case can cover each critical path of the code;

[0207] S1004, if the unit test case cannot cover every critical path of the code, then mark the unit test case as unqualified;

[0208] S1005: If the unit test case can cover each critical path of the code, the unit test case is marked as qualified and a test report is generated.

[0209] In this embodiment, a complete test set is formed by integrating valid test cases and newly generated test cases. This set is intended to fully cover all logic paths, branch conditions and exception handling scenarios of the code.

[0210] The unit test code repository is a place where all test cases are centrally managed and stored, usually in a code version control system (such as Git). The purpose of uploading is to facilitate version control and share test cases so that they can be used uniformly throughout the project. Test cases are loaded from the unit test code repository and executed through a unit testing framework (such as JUnit, TestNG). The purpose of executing the test is to verify the behavior of the code under various input conditions. Based on the test execution results, analyze the coverage of each test case on the code to determine whether the test case can fully cover all critical paths, conditional branches, and exception handling logic.

[0211] Upload the integrated unit test case set to the project's code repository. The uploaded test case set can be managed and tracked through version control tools (such as Git). The version control system ensures that all developers and testers can access and use the latest test case set. Test cases can be shared within the team to ensure consistency.

[0212] Load all test cases in the code repository through an automated testing framework (such as JUnit, TestNG). The automated testing framework can select and execute test cases based on configuration files or predefined execution plans. Execute all unit test cases one by one according to the loaded test case set. The test framework will generate a test execution report to record the execution results of each test case.

[0213] Analyze the execution results of each test case according to the report generated by the test framework. This includes a detailed check of the test case execution path, covered branch conditions, and triggered exception handling logic. Check whether the test case covers each critical path in the code. The critical path includes the main logical branches, special input condition paths, and all exception handling logic.

[0214] If a test case fails to cover every critical path, it is marked as failed. You can mark the failed test cases in the report and record the reasons and the paths that are not covered. If the test case covers all critical paths, it is marked as qualified and a complete test report is generated. The report should contain information such as the coverage, execution status, and verification results of each test case.

[0215] This embodiment can achieve centralized management, version control and sharing of test cases by uploading the integrated test case set to the unit test code repository of the project and automatically executing the test. Coverage analysis based on the test results can ensure that each critical path is fully verified, thereby improving the stability and reliability of the project code.

[0216] In one embodiment, a unit test case generation device is provided, and the unit test case generation device corresponds one-to-one to the unit test case generation method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the unit test case generation device of the present invention. Compilation module 10, bytecode analysis module 20, cyclomatic complexity analysis module 30, path information generation module 40, path simulation execution module 50, test case analysis module 60, template generation module 70, new test case generation module 80 and test case integration module 90. The functional modules are described in detail as follows:

[0217] Compilation module 10, used to compile the current project to generate class files;

[0218] The bytecode analysis module 20 is used to perform bytecode analysis on the class file, traverse each class and each method in the class file, and extract control flow information and call relationship information of each method;

[0219] A cyclomatic complexity analysis module 30 for determining the cyclomatic complexity of each method based on the control flow information of each method;

[0220] A path information generating module 40, used for generating path information required for a test case based on the cyclomatic complexity of each method and the call relationship information;

[0221] A path simulation execution module 50 is used to simulate the execution path according to the path information and generate basic unit test cases;

[0222] A test case analysis module 60, for determining valid test cases in the basic unit test cases according to a predetermined evaluation standard;

[0223] A template generation module 70, used to use the valid test case as a template for generating a new test case;

[0224] A new test case generation module 80 is used to identify the code to be tested for which no test case has been generated in the class file, and to generate a new test case for the code to be tested according to the code to be tested using the template;

[0225] The test case integration module 90 is used to integrate the valid test cases and the new test cases to generate a complete unit test case set.

[0226] In one embodiment, the path information generating module 40 is specifically used to:

[0227] Identify the independent control flow paths within each method based on the cyclomatic complexity of each method;

[0228] From the calling relationship information and independent control flow paths of each method, path information for generating test cases is extracted.

[0229] In one embodiment, the path simulation execution module 50 is specifically configured to:

[0230] Based on the path information, configure corresponding input conditions and expected outputs for each path;

[0231] Simulate the execution of each path and verify the execution of each path;

[0232] During the simulation execution of each path, the execution status of each execution step is recorded;

[0233] Based on the results of the path simulation execution, a basic unit test case corresponding to each path is generated.

[0234] In one embodiment, the test case analysis module 60 is specifically used to:

[0235] Performing mutation testing on the original code under test tested by the basic unit test case to generate a mutated version of the code under test;

[0236] Using the basic unit test case, respectively executing the mutated version of the tested code and the unmutated original tested code;

[0237] Compare the execution results of the variant version of the tested code with the original tested code;

[0238] When the execution results are different, corresponding test data and assertions are used to verify whether the basic unit test case can capture the errors introduced by the mutation, so as to confirm whether the basic unit test case is a valid test case.

[0239] In one embodiment, the test case analysis module 60 is specifically used to:

[0240] Analyze the line coverage of each basic unit test case;

[0241] Analyze the branch coverage of each basic unit test case;

[0242] Analyze the coverage of exception handling logic by each basic unit test case;

[0243] Based on the line coverage, branch coverage and coverage of exception handling logic of the basic unit test cases, valid test cases in the basic unit test cases are determined.

[0244] In one embodiment, the new test case generation module 80 is specifically used to:

[0245] Analyze the code coverage of each class and each method in the class file to identify the code to be tested that is not covered by the effective test cases;

[0246] The test scenario is determined based on the structure and functional characteristics of the code to be tested, and a new test case is generated using the template.

[0247] In one embodiment, the test case integration module 90 is specifically used to:

[0248] Upload the unit test case set to the unit test code repository of the current project;

[0249] Retrieving unit test cases from the unit test code repository to execute tests;

[0250] Analyze the execution path, branch conditions, and exception handling logic of the code based on the test results to determine whether the unit test cases can cover each critical path of the code;

[0251] If a unit test case cannot cover every critical path of the code, the unit test case is marked as unqualified;

[0252] If the unit test case can cover each critical path of the code, the unit test case is marked as qualified and a test report is generated.

[0253] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database 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 and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of a unit test case generation method server side.

[0254] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. 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 network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the user side of a unit test case generation method

[0255] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the following steps are implemented:

[0256] Compile the current project to generate class files;

[0257] Performing bytecode analysis on the class file, traversing each class and each method in the class file, and extracting control flow information and call relationship information of each method;

[0258] Determine the cyclomatic complexity of each method based on its control flow information;

[0259] Generate path information required for the test case based on the cyclomatic complexity of each method and the call relationship information;

[0260] According to the path information, simulate the execution path and generate basic unit test cases;

[0261] Determining valid test cases among the basic unit test cases according to predetermined evaluation criteria;

[0262] Using the effective test case as a template for generating new test cases;

[0263] Identify the code to be tested for which no test case is generated in the class file, and use the template to generate a new test case for the code to be tested according to the code to be tested;

[0264] Integrate the valid test cases and the new test cases to generate a complete unit test case set.

[0265] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0266] Compile the current project to generate class files;

[0267] Performing bytecode analysis on the class file, traversing each class and each method in the class file, and extracting control flow information and call relationship information of each method;

[0268] Determine the cyclomatic complexity of each method based on its control flow information;

[0269] Generate path information required for the test case based on the cyclomatic complexity of each method and the call relationship information;

[0270] According to the path information, simulate the execution path and generate basic unit test cases;

[0271] Determining valid test cases among the basic unit test cases according to predetermined evaluation criteria;

[0272] Using the effective test case as a template for generating new test cases;

[0273] Identify the code to be tested for which no test case is generated in the class file, and use the template to generate a new test case for the code to be tested according to the code to be tested;

[0274] Integrate the valid test cases and the new test cases to generate a complete unit test case set.

[0275] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0276] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and 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 embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0277] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0278] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for generating unit test cases, characterized in that: The following steps are involved: Compile the current project to generate class files; Performing bytecode analysis on the class file, traversing each class and each method in the class file, and extracting control flow information and call relationship information of each method; Determine the cyclomatic complexity of each method based on its control flow information; Generate path information required for the test case based on the cyclomatic complexity of each method and the call relationship information; According to the path information, simulate the execution path and generate basic unit test cases; Determining valid test cases among the basic unit test cases according to predetermined evaluation criteria; Using the effective test case as a template for generating new test cases; Identify the code to be tested for which no test case is generated in the class file, and use the template to generate a new test case for the code to be tested according to the code to be tested; Integrate the valid test cases and the new test cases to generate a complete unit test case set.

2. The unit test case generation method according to claim 1, characterized in that: Generate path information required for test cases based on the cyclomatic complexity of each method and the call relationship information, including: Identify the independent control flow paths within each method based on the cyclomatic complexity of each method; From the calling relationship information and independent control flow paths of each method, path information for generating test cases is extracted.

3. The unit test case generation method according to claim 1, characterized in that: According to the path information, the execution path is simulated to generate basic unit test cases, including: Based on the path information, configure corresponding input conditions and expected outputs for each path; Simulate the execution of each path and verify the execution of each path; During the simulation execution of each path, the execution status of each execution step is recorded; Based on the results of the path simulation execution, a basic unit test case corresponding to each path is generated.

4. The unit test case generation method as claimed in claim 1, characterized in that: Determining valid test cases in the basic unit test cases according to predetermined evaluation criteria includes: Performing mutation testing on the original code under test tested by the basic unit test case to generate a mutated version of the code under test; Using the basic unit test case, respectively executing the mutated version of the tested code and the unmutated original tested code; Compare the execution results of the variant version of the tested code with the original tested code; When the execution results are different, corresponding test data and assertions are used to verify whether the basic unit test case can capture the errors introduced by the mutation, so as to confirm whether the basic unit test case is a valid test case.

5. The unit test case generation method according to claim 1, characterized in that: Determining valid test cases in the basic unit test cases according to predetermined evaluation criteria includes: Analyze the line coverage of each basic unit test case; Analyze the branch coverage of each basic unit test case; Analyze the coverage of exception handling logic by each basic unit test case; Based on the line coverage, branch coverage and coverage of exception handling logic of the basic unit test cases, valid test cases in the basic unit test cases are determined.

6. The unit test case generation method according to claim 1, characterized in that: Identifying the code to be tested for which no test case is generated in the class file, and using the template to generate a new test case for the code to be tested according to the code to be tested, comprising: Analyze the code coverage of each class and each method in the class file to identify the code to be tested that is not covered by the effective test cases; The test scenario is determined based on the structure and functional characteristics of the code to be tested, and a new test case is generated using the template.

7. The unit test case generation method according to claim 1, characterized in that: After integrating the effective test cases and the new test cases to generate a complete unit test case set, the following is also included: Upload the unit test case set to the unit test code repository of the current project; Retrieving unit test cases from the unit test code repository to execute tests; Analyze the execution path, branch conditions, and exception handling logic of the code based on the test results to determine whether the unit test cases can cover each critical path of the code; If a unit test case cannot cover every critical path of the code, the unit test case is marked as unqualified; If the unit test case can cover each critical path of the code, the unit test case is marked as qualified and a test report is generated.

8. A unit test case generating device, characterized in that: The unit test case generating device comprises: Compile module, used to compile the current project to generate class files; A bytecode analysis module is used to perform bytecode analysis on the class file, traverse each class and each method in the class file, and extract control flow information and call relationship information of each method; A cyclomatic complexity analysis module for determining the cyclomatic complexity of each method based on the control flow information of each method; A path information generation module, used for generating path information required for test cases based on the cyclomatic complexity of each method and the call relationship information; A path simulation execution module is used to simulate the execution path according to the path information and generate basic unit test cases; A test case analysis module, used to determine valid test cases in the basic unit test cases according to a predetermined evaluation standard; A template generation module, used to use the valid test case as a template for generating a new test case; A new test case generation module is used to identify the code to be tested for which no test case has been generated in the class file, and to generate a new test case for the code to be tested according to the code to be tested using the template; The test case integration module is used to integrate the valid test cases and the new test cases to generate a complete unit test case set.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a unit test case generation program stored in the memory and executable on the processor. When the unit test case generation program is executed by the processor, the steps of the unit test case generation method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a unit test case generation program, which, when executed by a processor, implements the steps of the unit test case generation method according to any one of claims 1 to 7.

Images