Test case generation method and device, electronic equipment and readable storage medium

Abstract

The application provides a test case generation method and device, electronic equipment and a readable storage medium. Code changes are extracted based on Git change perception to obtain code change information of a target version of a program to be tested. First test cases are screened based on the code change information and a trained test case screening model. Second test cases are generated based on the code change information and a trained test case generation model. Dependency information of each external dependency associated with the code changes is extracted, and Mock objects and Mock rules are matched for the external dependencies in the first test cases and the second test cases. The matched first test cases and the second test cases are determined as target test cases of the target version of the program to be tested. In this way, the trained test case screening model and the test case generation model can generate test cases matched with code changes of the program to be tested, thereby improving the accuracy of test case generation in automated testing.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to methods, apparatus, electronic devices and readable storage media for generating test cases. Background Technology

[0002] With the shortening of software development cycles and the increase in complexity, automated testing has become an indispensable part of the software development process. In a continuous integration (CI) environment, frequent code changes lead to frequent updates of test cases, and manually updating test cases and mock objects brings a huge maintenance burden.

[0003] Traditional test case generation methods are usually based on full regression testing, which means re-executing all test cases after each code change. This not only consumes a lot of computing resources and time, but may also lead to incomplete test coverage or redundant tests, resulting in low accuracy of test case generation. Summary of the Invention

[0004] In view of this, embodiments of this application at least provide a method, apparatus, electronic device, and readable storage medium for generating test cases. By using a trained test case filtering model and a test case generation model, test cases that match the code changes of the program under test can be generated, thereby improving the accuracy of test case generation in automated testing.

[0005] This application mainly includes the following aspects:

[0006] In a first aspect, embodiments of this application provide a method for generating test cases, the method comprising:

[0007] Based on Git change awareness, the code changes of the target version of the test program are extracted to obtain the code change information of the target version of the test program.

[0008] Based on the code change information and the trained test case screening model, at least one first test case related to the code changes of the program under test is selected from the historical test cases of the program under test.

[0009] Based on the code change information and the trained test case generation model, at least one second test case is generated that is related to the code changes of the program under test and is not in the historical test cases of the program under test.

[0010] Extract dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and based on the dependency information, match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case;

[0011] The matched first test case and the matched second test case are determined as the target test cases for the target version of the program to be tested.

[0012] Secondly, embodiments of this application also provide a test case generation apparatus, the test case generation apparatus comprising:

[0013] The change extraction module is used to extract code changes of the target version of the test program based on Git change awareness, and obtain the code change information of the target version of the test program.

[0014] The first determining module is used to select at least one first test case related to the code changes of the program under test from the historical test cases of the program under test based on the code change information and the trained test case filtering model.

[0015] The second determining module is used to generate at least one second test case that is related to the code changes of the program under test and is not in the historical test cases of the program under test, based on the code change information and the trained test case generation model.

[0016] The dependency matching module is used to extract dependency information of each external dependency associated with the code changes of the target version of the program under test, and based on the dependency information, to match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case.

[0017] The third determining module is used to determine the matched first test case and the matched second test case as the target test cases of the target version of the program to be tested.

[0018] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory through the bus, and the machine-readable instructions are executed by the processor to perform the steps of the test case generation method as described above.

[0019] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the test case generation method described above.

[0020] The test case generation method, apparatus, electronic device, and readable storage medium provided in this application extract code changes of the target version of the program under test based on Git change awareness, obtaining code change information of the target version of the program under test; based on the code change information and a trained test case filtering model, at least one first test case related to the code changes of the program under test is selected from the historical test cases of the program under test; based on the code change information and a trained test case generation model, at least one second test case related to the code changes of the program under test, but not in the historical test cases of the program under test, is generated; dependency information of each external dependency associated with the code changes of the target version of the program under test is extracted, and based on the dependency information, corresponding Mock objects and Mock rules are matched for the external dependencies in the first and second test cases; the matched first and second test cases are determined as the target test cases of the target version of the program under test. In this way, by using the trained test case filtering model and test case generation model, test cases matching the code changes of the program under test can be generated, improving the accuracy of test case generation in automated testing.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a test case generation method provided in an embodiment of this application is shown;

[0024] Figure 2 This illustration shows one of the functional block diagrams of a test case generation device provided in an embodiment of this application;

[0025] Figure 3 This illustration shows a second functional block diagram of a test case generation device provided in an embodiment of this application;

[0026] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.

[0029] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for generating test cases provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method for generating test cases includes the following steps:

[0030] S101, Based on Git change awareness, extract the code changes of the target version of the program under test to obtain the code change information of the target version of the program under test.

[0031] Here, Git Change Perception is used to monitor code commits of the target version of the program under test. The `git diff` tool is then used to analyze code changes and generate code change information for the target version of the program under test. Git Change Perception is a technique used to monitor and analyze code changes in the Git version control system in real time. The code change information includes information such as the changed files, methods, classes, and modified line numbers. This information provides the basic data support for subsequent test case selection and generation.

[0032] In this embodiment, a Git Hook (e.g., post-commit) is configured to ensure that the change detection module is automatically triggered after each code commit, performing test optimization and dependency identification, thereby synchronously updating the test environment. Specifically, a post-commit hook is configured in the ".git / hooks" directory of the Git repository. The post-commit file is edited to write a script to automatically detect changes and generate a change report. For example: "git diff --name-only HEAD~1 HEAD | grep ".java">changed_files.txt

[0033] The script `python3 detect_changes.py changed_files.txt` integrates with a Continuous Integration / Continuous Delivery (CI / CD) system (such as Jenkins) to ensure that changed files are automatically passed to the CI / CD system, triggering subsequent automated test optimizations. For example, after code is committed, the post-commit hook is triggered, generating `"changed_files.txt"`, which is then passed to Jenkins, where it performs automated test optimizations.

[0034] Next, the `git diff` tool is used to analyze the code changes in each commit, extracting the changed files and lines, and generating a detailed change report to represent the code change information, providing data support for dependency identification. Specifically, the `git diff` command is used to compare the differences between the current commit and the previous version, obtaining the changed files and line numbers:

[0035] "git diff --name-only HEAD~1 HEAD | grep ".java"

[0036] git diff HEAD~1 HEAD -- .java>diff_report.txt".

[0037] Parse "diff_report.txt" to extract the changed files and line numbers, and generate a structured change area report (such as JSON or XML format). For example, code change information can be represented as a change area report in the following format:

[0038] {

[0039] "file": "OrderService.java",

[0040] "changed_lines": [20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32,33, 34, 35],

[0041] "change_type": "modified"

[0042] }".

[0043] Output the changed region report to "changed_files.txt" and "diff_report.txt" for subsequent dependency identification.

[0044] Furthermore, static analysis identifies dependencies in changed regions, supporting the generation of subsequent incremental test cases and mock objects. Specifically, static analysis tools (such as Eclipse JDT or Spoon) are used to parse the change files and generate an Abstract Syntax Tree (AST) to capture dependencies between code segments. This identifies dependency nodes such as method calls and variable references. For example, it identifies that the "OrderService.processOrder" method calls "orderRepository.findById". A structured dependency report is output, including modules, methods, and dependency types (such as databases, APIs, etc.).

[0045] Building upon static analysis, the relationships between modified code and external dependencies (such as databases, APIs, message queues, etc.) are further identified and analyzed. Based on the static analysis results, a dependency report is generated to ensure the accuracy of mock object generation and test cases.

[0046] S102, based on the code change information and the trained test case screening model, at least one first test case related to the code change of the program under test is selected from the historical test cases of the program under test.

[0047] Here, a trained test case filtering model is used to filter out test cases related to code changes from historical test cases. This model identifies potentially affected test cases by analyzing code change information and the characteristics of historical test cases, thereby avoiding unnecessary full regression testing and improving testing efficiency.

[0048] In this embodiment, a trained test case screening model is used to analyze the change area report generated in S101, identifying classes, methods, and modules related to the change, with a focus on their inputs, outputs, and dependencies. Relevant test cases are automatically searched based on the change content, eliminating redundant test cases unrelated to the change. The impact of the change on external dependencies is analyzed to further confirm which test cases are indirectly affected by the change. Finally, at least one test case related to the code changes of the program under test is selected from the historical test cases of the program under test as the first test case. The change area report records specific information about the code changes, including the changed lines of code, modules, classes, methods, etc., as well as other modules and dependencies that may be affected by the change. Specifically, the content of the change area report may include: change content: the specific modified code area (e.g., class, method, functional module); scope of impact: the modules, classes, and methods affected by the change, and their external dependencies (e.g., database, external services); change type: method addition, logic modification, code deletion, etc.

[0049] Specifically, the test case filtering model selects test cases relevant to the changed area from historical test cases. For example, when modifying the order verification logic of the "OrderService.processOrder" method, the test case filtering model will identify test cases related to this method, such as "OrderServiceTest.testProcessOrderValidId," and mark them as change-related test cases. By analyzing the characteristics of the changed area, the test case filtering model automatically excludes test cases unrelated to the change, avoiding resource waste. The test case filtering model can also automatically identify and exclude irrelevant test cases based on historical test coverage and dependencies between modules. Finally, a concise test case list is generated, including only test cases relevant to the change.

[0050] For example, suppose the order ID verification logic in the "OrderService.processOrder" method has changed. After analysis by the test case filtering model, the following test cases related to the change were identified:

[0051] Code change: The "OrderService.processOrder" method has modified the order ID verification logic.

[0052] Identify the relevant test cases: "OrderServiceTest.testProcessOrderValidId" and "OrderServiceTest.testProcessOrderInvalidId".

[0053] Exclude irrelevant test cases, such as tests for the "PaymentService" module.

[0054] The final filtered test cases are as follows:

[0055] "OrderServiceTest.testProcessOrderValidId";

[0056] "OrderServiceTest.testProcessOrderInvalidId".

[0057] Filtering results: These test cases will be executed, while other irrelevant test cases will be excluded to avoid redundant execution and thus improve testing efficiency.

[0058] S103, based on the code change information and the trained test case generation model, generate at least one second test case that is related to the code changes of the program under test and is not in the historical test cases of the program under test.

[0059] Here, a trained test case generation model is used to generate incremental test cases related to code changes that are not yet present in historical test cases. This model can infer potential test paths and boundary conditions based on the changed area, generating incremental test cases that cover the changed area, further improving test coverage. By filtering out redundant test cases, it ensures both testing efficiency and quality.

[0060] Specifically, based on code changes, the test case generation model analyzes the type of change and its potential impact on code paths, inferring relevant input data. This process considers not only the changed lines of code but also the affected classes, methods, and external dependencies (such as databases and APIs). By analyzing historical test case failure data and change types, the test case generation model generates input data covering potential risks and boundary conditions. For example, if a function's boundary conditions were not adequately covered in past tests, the model will recommend new input data to cover these unrevealed boundaries. For instance, if a function handles a large range of parameters, the model will automatically infer the parameter's boundary values ​​(such as maximum, minimum, negative, or zero) and generate corresponding test input data. The model can also automatically deduce the expected output for each input based on code changes. This includes not only normal return values ​​but also expected outputs for exceptional cases. The model generates a set of possible outputs (e.g., error codes or messages for exception handling paths) to ensure all changed paths are adequately tested. For example, when the order ID is negative, the system should throw an "OrderNotFoundException" exception. The test case generation model will deduce this type of exception as the expected output and generate test cases to verify that the exception is thrown correctly.

[0061] Furthermore, any of the second test cases includes the input data of the test case, the expected output of the test case, the verification method of the test case, and the execution order of the test cases.

[0062] Here, to ensure that the generated test cases can fully cover code changes and effectively verify their correctness, the second test case generated in this invention is an incremental test case, which includes the following key components:

[0063] Input data for test cases: Input parameters or datasets that the test case generation model infers;

[0064] Expected output of test cases: Correct output or exception handling results derived from the changes;

[0065] Test case verification methods: Automated verification logic used to verify whether the test results meet expectations;

[0066] Test case execution order: Optimize the execution order of test cases based on historical data, the scope of impact of changes, and risk assessment, prioritizing the execution of high-risk test cases.

[0067] For example, suppose the order ID verification logic in the "OrderService.processOrder" method changes, the test case generation model will generate the following incremental test cases:

[0068] Test case 1: Throw an "OrderNotFoundException" when the order ID is negative;

[0069] Enter: "Order ID = -1";

[0070] Expected output: Throws "OrderNotFoundException".

[0071] Test case 2: When the order ID is 0, throw "InvalidOrderIdException";

[0072] Enter: "Order ID = 0";

[0073] Expected output: Throws "InvalidOrderIdException".

[0074] Test Case 3: When the order ID is a valid number, the process is successful and the order information is returned;

[0075] Enter: "Order ID = 123";

[0076] Expected output: Order object, with a return status of "success".

[0077] Furthermore, the test case generation model not only focuses on the quantity of test cases generated, but also optimizes the quality of test cases in the following ways:

[0078] Reduce redundant test cases: By analyzing the impact of changes to affected areas and historical test execution data, the test case generation model can identify redundant test cases and exclude them from the generation list. For logic that has already passed testing or unaffected code paths, the test case generation model automatically identifies and avoids duplicate testing.

[0079] Covering Potential Risk Paths: The test case generation model analyzes historical errors and test blind spots, automatically generating potentially undetected error paths to further improve test coverage. Through historical failure data, the test case generation model can identify which boundary conditions and exception handling paths have not been adequately tested, thereby supplementing these test cases and ensuring comprehensive coverage of all possible code paths.

[0080] S104, extract the dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and based on the dependency information, match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case.

[0081] Here, external dependency information associated with code changes in the target version of the program under test is extracted, and corresponding Mock objects and Mock rules are matched for the external dependencies in the selected and generated test cases. By dynamically generating and optimizing Mock objects, it is ensured that test cases can run in an independent environment, reducing dependence on external systems and improving the stability and efficiency of testing.

[0082] Specifically, it automatically monitors changes to the Git repository, extracts change information (change area reports), and identifies external dependencies related to code changes (such as databases, APIs, message queues, etc.). It configures post-commit hooks to trigger change analysis when code is committed. The `git diff` command is used to extract changed files and lines, generating change area reports that indicate affected modules and dependencies. The change area reports are analyzed to automatically identify external dependencies that require the generation of mock objects. For example, if the `processOrder` method in the `OrderService` class modifies the call to `orderRepository.findById(orderId)`, it identifies that this database query dependency requires the generation of a mock object for processing.

[0083] Next, based on the dependency analysis results, mock objects are automatically generated to replace the actual external services, ensuring that the tests are independent of the external system. Specifically, for database dependencies, database calls are simulated, returning preset data. For HTTP API dependencies, HTTP response data is simulated, and a mock JSON response is returned. For message queue dependencies, message responses are simulated, and mock messages are returned. To ensure automatic injection of mock objects in unit tests, dependency injection mechanisms are used in conjunction with testing frameworks (such as JUnit, Mockito, Spring Test, etc.). Specifically, mock objects are automatically created and injected into test cases via dependency injection (DI), using the "@Mock" annotation or other automated configuration tools to ensure that mock objects are correctly injected during test execution.

[0084] Next, configure appropriate return values ​​for the mock objects based on the call details of each external dependency. Use a mock framework (such as Mockito) to define the behavior of the mock objects. For example, "orderRepository.findById(orderId)" returns a mock Order object. Based on the analysis of the changed regions, select which mock objects require special return values.

[0085] Next, ensure that mock objects are automatically created and destroyed throughout the test lifecycle to avoid resource leaks and inconsistent states. Specifically, use the test framework's lifecycle management (such as JUnit's "@Before" and "@After" annotations) to manage the creation and destruction of mock objects. Create mock objects before each test method and clean them up after test execution to ensure the independence of each test case.

[0086] Furthermore, if business logic changes, the system automatically updates the behavior of the mock objects to ensure consistency with the actual code logic. Specifically, the system monitors changes in business logic and automatically updates the return values ​​or behaviors of the mock objects accordingly. AI models or rule engines are used to ensure that the mock objects can adapt to changes in business logic.

[0087] In this embodiment, the AI ​​model automatically optimizes the Mock rules, enabling the behavior of the Mock object to dynamically adapt to changes in code and business logic, ensuring a high degree of consistency with actual external services, thereby improving testing accuracy and efficiency.

[0088] Specifically, the system collects historical test data, analyzes test case execution results, coverage, failure information, etc., identifies common anomalies and change patterns, and dynamically adjusts the behavior of mock objects. The AI ​​model automatically adjusts the return value and behavior of mock objects based on changes in external dependencies. For example, if the response format of the API interface changes, the AI ​​model will automatically update the response structure of the mock object to ensure consistency with the new interface.

[0089] The AI ​​model dynamically adjusts the behavior of mock objects by monitoring changes in code and business logic in real time. Specifically, it detects changes in code and business logic in real time and automatically updates the return value of mock objects or simulates exceptions. The AI ​​model learns different exception scenarios and automatically simulates exceptions to ensure that all potential problems are covered.

[0090] When the system's business logic changes, the AI ​​model automatically generates new mock rules to replace the old ones, ensuring that the mock objects always reflect the latest business requirements. For example, when "OrderService.processOrder" adds an order ID range check, the AI ​​model generates a new mock rule to simulate the "OrderNotFoundException" exception.

[0091] Furthermore, through external configuration files, testers can dynamically modify the behavior and testing strategies of mock objects in real time, ensuring that tests can adapt to changes in code and business logic, thereby guaranteeing efficient test execution and accurate test results. Specifically, mock objects and mock rules are first automatically generated by an auto-generation module driven by dependency analysis results, based on the code dependency information of the target version; subsequently, the mock configuration is read from the external configuration file, and the automatically generated rules are merged or overridden. Specifically: if no rule is defined for a dependency in the configuration file, the automatically generated rule is retained; if the configuration file provides a fine-grained definition for a dependency, the automatically generated content is replaced or supplemented with the configuration file rules to dynamically adjust the behavior and testing strategies of mock objects in real time.

[0092] Specifically, the configuration file format in this embodiment supports multiple formats (such as JSON and YAML) to allow testers to choose the appropriate format as needed. The configuration file structure is concise, easy to maintain, and can accommodate a large amount of Mock configuration content. The configuration management system uses a file monitoring mechanism (such as Java's WatchService API) to monitor changes to the configuration file in real time. Once a file is modified, the system automatically detects the change. After detecting a change in the configuration file, the system automatically loads the new configuration and updates the behavior of the Mock object. Simultaneously, only the changed parts are updated, avoiding the repeated loading of unchanged configurations and improving system performance.

[0093] Furthermore, the configuration management system supports recording the history of every configuration file change, generating a unique version number. Testers can view version changes and trace the changes. Configuration version management is implemented through Git or other version control tools, ensuring that every change is traceable. After a configuration change, if a test fails or does not meet expectations, testers can choose to roll back to the previous configuration version.

[0094] Furthermore, the configuration management system supports configuring different Mock rules for different environments (such as development, testing, and production) to adapt to different testing needs. The system loads the corresponding configuration based on the current operating environment.

[0095] Furthermore, the configuration management system supports priority management. When multiple rules conflict, the system loads configurations according to their priority order, ensuring that higher-priority rules take effect. Specifically, each configuration can specify a "priority" field, and the system will load higher-priority configurations first.

[0096] Furthermore, if errors occur in certain fields or rules after the configuration file is modified (such as missing necessary fields or invalid values), the configuration management system will trigger an alarm to promptly notify relevant personnel. Alarms can be sent via email, SMS, or push notifications.

[0097] S105, the matched first test case and the matched second test case are determined as the target test cases of the target version of the program to be tested.

[0098] Here, the first and second test cases, which match the mock objects, are identified as the target test cases for the target version of the program under test. These target test cases will be used for actual test execution to ensure that the system behavior after code changes meets expectations.

[0099] Further, the test case selection model is trained according to the following steps:

[0100] Step a1: Obtain historical code change information and historical test cases of the program under test.

[0101] Here, we obtain historical code change information and historical test cases for the program under test. Historical code change information includes the changes made in each code commit, such as changed files, methods, classes, and line numbers. Historical test cases record the test cases associated with each code change, including the test case description, input parameters, expected output, and actual execution result. This historical data provides rich learning material for model training.

[0102] Step a2: Based on the historical code change information and the historical test cases, determine the first input feature of the program to be tested; the first input feature includes the changed methods, classes, modules, as well as the coverage of the test cases and the input data type.

[0103] Here, based on historical code change information and the historical test cases, the first input features of the program to be tested are determined. The first input features include the methods, classes, and modules that have changed, as well as the coverage and data type of the test cases. By analyzing historical data, features related to code changes and test cases are extracted, providing crucial information for model training.

[0104] Step a3: Train the test case selection model based on the first input features to obtain the trained test case selection model.

[0105] Here, a test case selection model is trained based on the first input features, resulting in a trained test case selection model. Specifically, machine learning algorithms, such as deep learning, decision trees, or random forests, are used to train the extracted first input features, enabling the model to accurately determine whether a change will affect a particular test case, as well as the dependencies between them, and to accurately select relevant test cases based on code change information. The trained model will be used in subsequent test case selection processes to improve the accuracy and efficiency of test case selection.

[0106] Further, the test case generation model is trained according to the following steps:

[0107] Step b1: Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases.

[0108] This section retrieves historical code change information, historical test cases, and historical test results for the program under test. Historical code change information includes the changes made in each code commit, such as changed files, methods, classes, and line numbers. Historical test cases record the test cases related to each code change, including test case descriptions, input parameters, and expected outputs. Historical test results record execution logs, change data, code paths, and other information. This data includes the execution status of past test cases, the code areas covered by the tests, and the test results (pass / fail, execution time, coverage, etc.). This historical data provides rich learning material for model training.

[0109] Step b2: Based on the historical code change information, the historical test cases, and the historical test results, determine the second input features of the program to be tested; the second input features include the lines of code covered by the test cases, the types of input parameters for the test cases, the expected output of the test cases, and the execution path when the test cases are executed.

[0110] Here, based on historical code change information, historical test cases, and historical test results, the second input features of the program to be tested are determined. These second input features include: Lines of code covered by the test cases: identifying which lines of code were executed during the test case execution process; Input parameter types of the test cases: identifying the data type of the input test cases, such as integers, strings, objects, etc., and the range of input values; Expected output of the test cases: identifying the expected results of the test cases, such as normal return values, exception information, etc.; Execution path during test case execution: identifying the execution path of the test cases in the code, including the method call chain and control flow path. By analyzing historical data, features related to code changes and test cases are extracted, providing key information for model training.

[0111] Step b3: Train the test case generation model based on the second input features to obtain the trained test case generation model.

[0112] Here, a test case generation model is trained based on the second input feature, resulting in a well-trained model. Machine learning algorithms, such as deep learning, decision trees, or random forests, are used to train the extracted second input feature, enabling the model to learn how to infer which test cases need to be executed based on the changed regions. This training process utilizes historical data to build the model and identify the correlation between different types of changes (such as function modifications, parameter changes, condition modifications, etc.) and test cases. After training, the test case generation model can automatically identify incremental test cases that may need to be executed based on current code changes, improving incremental test coverage and reducing irrelevant test cases.

[0113] Furthermore, the method also includes:

[0114] Step c1: Based on the target test cases of the target version of the program to be tested and the trained test priority prediction model, determine the test priority of each target test case.

[0115] Here, based on the target test cases of the target version of the program under test and the trained test priority prediction model, the test priority of each target test case is determined. Specifically, the test priority prediction model predicts the importance and risk level of each test case by analyzing its characteristics (such as the impact of code changes, historical execution results of test cases, and test case coverage). High-priority test cases are generally considered more critical and need to be executed first. In this way, it is ensured that, with limited testing resources, test cases most likely to find defects are executed first.

[0116] Specifically, the test priority prediction model assesses the risk of test cases based on data such as the execution results, failure frequency, and code change complexity of historical test cases, assigns a risk score to each test case, and evaluates the test priority of test cases based on factors such as change complexity and failure rate.

[0117] Step c2: Determine the test order of each target test case based on the test priority of each target test case.

[0118] Here, the test order of each target test case is determined based on its test priority. The determination of the test order typically follows these principles: High priority: Execute high-priority test cases first to ensure that critical functions and high-risk changes are verified first. Dependencies: Consider the dependencies between test cases to ensure that dependent test cases are executed before the test cases they depend on. Resource optimization: Arrange the execution order of test cases reasonably based on the availability of test resources to avoid resource bottlenecks. A reasonable test order can utilize test resources more efficiently, discover potential problems faster, and thus improve test efficiency and quality. For example, the "OrderService.processOrder" method modifies the order ID verification logic. The test priority prediction model assesses the "testProcessOrderInvalidId" test case as high-risk and has a higher priority, so it is executed first.

[0119] Further, the test priority prediction model is trained according to the following steps:

[0120] Step d1: Obtain the historical code change information of the program under test, the historical test cases of the program under test, and the historical test results of the historical test cases.

[0121] This section retrieves historical code change information, historical test cases, and historical test results for the program under test. This data includes: Historical code change information: records the changes made in each code commit, including changed files, methods, classes, and line numbers. Historical test cases: records historical test cases related to each code change, including test case descriptions, input parameters, and expected outputs. Historical test results: records execution logs, change data, code paths, and other information. This data includes past test case execution status, code areas covered by the tests, and test results (pass / fail, execution time, coverage, etc.). This historical data provides rich learning material for model training, helping the model learn the relationship between code changes and test case priorities.

[0122] Step d2: Based on the historical code change information, the historical test cases, and the historical test results, determine the third input feature of the program to be tested; the third input feature includes the execution result of the test cases, the failure frequency of the test cases, and the complexity of code changes.

[0123] Here, based on historical code change information, historical test cases, and historical test results, the third input feature of the program to be tested is determined. This third input feature includes: Test case execution results: identifying the outcome of test cases in historical execution, such as pass, fail, or exception. Test case failure frequency: statistically analyzing the frequency of failure for each test case in historical execution, reflecting the stability and importance of the test cases. Code change complexity: assessing the complexity of code changes, such as the number of lines of code involved and the number of modules affected, reflecting the scope of the change's impact on the system. These features help the model more accurately evaluate the priority of each test case.

[0124] Step d3: Train the test priority prediction model based on the third input feature to obtain the trained test priority prediction model.

[0125] Here, a test priority prediction model is trained based on the third input feature, resulting in a well-trained model. Machine learning algorithms, such as deep learning, decision trees, or random forests, are used to train the extracted third input feature, enabling the model to predict the priority of test cases based on their characteristics. The trained model will then be used in subsequent test priority prediction processes, improving the accuracy and efficiency of test case priority evaluation.

[0126] Furthermore, the method also includes:

[0127] Step e1: Test the target version of the program under test based on the target test cases of the target version of the program under test, and obtain the target test results of the target version of the program under test.

[0128] Here, based on the target test cases of the target version of the program under test, the target version of the program under test is tested to obtain the target test results. This process includes: Test execution: Running the target test cases on the target version of the program under test and recording the execution result of each test case, including pass, failure, exception, etc. Result collection: Collecting detailed information during the test execution process, such as the execution path of the test cases, the lines of code covered, input parameters, output results, etc. Through this step, the validity of the target test cases and the functional correctness of the target version of the program under test can be verified.

[0129] Specifically, after each test is executed, the system automatically collects the following information:

[0130] Test case execution status (pass / fail);

[0131] Code coverage (line coverage, branch coverage, condition coverage, etc.);

[0132] Error messages and exception reports.

[0133] It integrates with CI / CD tools (such as Jenkins and GitLab CI) and automatically generates reports through test coverage tools (such as JaCoCo), which are then uploaded to the feedback system for analysis.

[0134] For example, after the test case "processOrder_WithValidOrderId" is executed, the system generates the following report:

[0135] Test Execution Report:

[0136] Test Case: processOrder_WithValidOrderId

[0137] Status: Passed

[0138] Line Coverage: 85%

[0139] Branch Coverage: 75%

[0140] Failed Test Cases: 2 (OrderNotFoundException handling missed)

[0141] Exception: OrderNotFoundException (missed coverage)".

[0142] Step e2: Based on the target test results and the trained test result optimization model, generate target optimization suggestions for the target test cases; the target optimization suggestions include test scenarios not covered by the target test cases, boundary conditions missing by the target test cases, and exception handling paths for the target test cases.

[0143] Here, based on the target test results and the trained test result optimization model, it analyzes multi-dimensional information such as historical data, execution results, and code changes to automatically optimize the test data generation strategy and mock rules. This ensures that the generated test cases are accurate, efficient, and dynamically adaptable to constantly changing business logic, external dependencies, and test requirements, generating target optimization suggestions for the target test cases. These suggestions include: Covered Test Scenarios: Identifying business scenarios or functional paths not covered by the target test cases. By analyzing the target test results and code change information, the model can indicate which scenarios or paths have not yet been covered by the test cases. Missing Boundary Conditions: Identifying boundary conditions not covered by the target test cases. For example, whether the boundary values ​​of input parameters (such as maximum, minimum, and null values) have been adequately tested. Exception Handling Paths: Identifying exception handling paths not covered by the target test cases. For example, whether certain exceptions are covered by the test cases, and whether the exception handling logic is correct. These optimization suggestions help testers further improve test cases, increasing test coverage and test quality.

[0144] In this embodiment, the test result optimization model analyzes test results in real time to identify uncovered business scenarios or test blind spots. Simultaneously, it marks uncovered logical branches, exception handling paths, etc., as areas for improvement. For example, if the processing path for negative values ​​"orderId" in the "OrderService.processOrder" method is not sufficiently tested, the system will automatically generate optimization suggestions:

[0145] Feedback:

[0146] Coverage missed for negative orderId scenario (OrderNotFoundExceptionnot tested).

[0147] Suggested Action: Add a test case where orderId = -1, expectedexception: OrderNotFoundException.".

[0148] Furthermore, the test result optimization model optimizes the test strategy based on historical test data (including failure information, coverage, etc.) to ensure that the test covers all critical paths.

[0149] For example, if the "orderId" in the "OrderService.processOrder" method is negative, and "OrderNotFoundException" is frequently thrown, the test result optimization model will generate the following test cases:

[0150] "testCase:

[0151] name: processOrder_WithNegativeOrderId

[0152] input:

[0153] orderId: -1

[0154] expectedOutput:

[0155] exception: OrderNotFoundException".

[0156] At the same time, the test result optimization model will adjust the Mock rules of the corresponding Mock object to ensure that "OrderNotFoundException" is returned when "orderId" is negative.

[0157] Furthermore, the training data for the test result optimization model includes the execution results of historical test cases, code coverage, failure information, code change records, and business logic changes. This data helps the test result optimization model identify potential test blind spots, missing coverage paths, and insufficiently tested abnormal scenarios. Specifically, historical test data is cleaned, preprocessed, and standardized to remove noise, and feature engineering is performed to ensure efficient training of the test result optimization model. Features are extracted from failure cases to help the test result optimization model generate test data features for specific business logic. Deep learning, reinforcement learning, and other techniques are used to train the test result optimization model, optimizing test data generation and mock rules. For example, suppose the "OrderService.processOrder" method throws an "OrderNotFoundException" when handling the negative number "orderId". If historical data does not cover this scenario, the test result optimization model will automatically identify the missing data and generate a test case for "orderId = -1" along with related mock objects and mock rules.

[0158] This application provides a test case generation method, comprising: extracting code changes of a target version of the program under test based on Git change awareness to obtain code change information of the target version of the program under test; based on the code change information and a trained test case filtering model, selecting at least one first test case related to the code changes of the program under test from the historical test cases of the program under test; generating at least one second test case related to the code changes of the program under test and not present in the historical test cases of the program under test based on the code change information and a trained test case generation model; extracting dependency information of each external dependency associated with the code changes of the target version of the program under test, and matching corresponding Mock objects and Mock rules for the external dependencies in the first and second test cases based on the dependency information; and determining the matched first and second test cases as the target test cases for the target version of the program under test. In this way, by using a trained test case filtering model and a test case generation model, test cases matching the code changes of the program under test can be generated, improving the accuracy of test case generation in automated testing.

[0159] Based on the same application concept, this application also provides a test case generation device corresponding to the test case generation method provided in the above embodiments. Since the principle of the device in this application to solve the problem is similar to the test case generation method in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0160] Please see Figure 2 , Figure 2 This is one of the functional block diagrams of a test case generation device provided in an embodiment of this application. For example... Figure 2 As shown, the test case generation device 200 includes:

[0161] The change extraction module 210 is used to extract code changes of the target version of the test program based on Git change awareness, and obtain the code change information of the target version of the test program.

[0162] The first determining module 220 is used to select at least one first test case related to the code changes of the program under test from the historical test cases of the program under test based on the code change information and the trained test case filtering model.

[0163] The second determining module 230 is used to generate at least one second test case that is related to the code changes of the program under test and is not in the historical test cases of the program under test, based on the code change information and the trained test case generation model.

[0164] The dependency matching module 240 is used to extract the dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and based on the dependency information, match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case.

[0165] The third determining module 250 is used to determine the matched first test case and the matched second test case as the target test cases of the target version of the program to be tested.

[0166] Furthermore, the first determining module 220 is also used to train the test case screening model according to the following steps:

[0167] Obtain historical code change information and historical test cases of the program under test;

[0168] Based on the historical code change information and the historical test cases, the first input feature of the program to be tested is determined; the first input feature includes the changed methods, classes, modules, as well as the coverage of the test cases and the data type of the input.

[0169] The test case selection model is trained based on the first input feature to obtain the trained test case selection model.

[0170] Furthermore, the second determining module 230 is also used to train the test case generation model according to the following steps:

[0171] Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases;

[0172] Based on the historical code change information, the historical test cases, and the historical test results, a second input feature of the program to be tested is determined; the second input feature includes the lines of code covered by the test cases, the types of input parameters for the test cases, the expected output of the test cases, and the execution path when the test cases are executed.

[0173] The test case generation model is trained based on the second input feature to obtain the trained test case generation model.

[0174] Further, please refer to Figure 3 , Figure 3 This is a second functional block diagram of a test case generation device provided in an embodiment of this application. (See diagram below.) Figure 3 As shown, the test case generation device 200 also includes:

[0175] The fourth determining module 260 is used to determine the test priority of each target test case based on the target test cases of the target version of the program to be tested and the trained test priority prediction model.

[0176] The fifth determining module 270 is used to determine the test order of each target test case based on the test priority of each target test case.

[0177] Furthermore, the fourth determining module 260 is also used to train the test priority prediction model according to the following steps:

[0178] Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases;

[0179] Based on the historical code change information, the historical test cases, and the historical test results, a third input feature of the program to be tested is determined; the third input feature includes the execution result of the test cases, the failure frequency of the test cases, and the complexity of code changes;

[0180] The test priority prediction model is trained based on the third input feature to obtain the trained test priority prediction model.

[0181] Furthermore, such as Figure 3 As shown, the test case generation device 200 also includes:

[0182] The sixth determining module 280 is used to test the target version of the program under test based on the target test cases of the target version of the program under test, and obtain the target test results of the target version of the program under test;

[0183] The seventh determining module 290 is used to generate target optimization suggestions for the target test cases based on the target test results and the trained test result optimization model; the target optimization suggestions include test scenarios not covered by the target test cases, boundary conditions missing by the target test cases, and exception handling paths for the target test cases.

[0184] This application provides a test case generation apparatus, comprising: a change extraction module for extracting code changes of a target version of a program under test based on Git change awareness, thereby obtaining code change information of the target version of the program under test; a first determination module for selecting at least one first test case related to the code changes of the program under test from its historical test cases based on the code change information and a trained test case filtering model; a second determination module for generating at least one second test case related to the code changes of the program under test, but not present in the program under test's historical test cases, based on the code change information and a trained test case generation model; a dependency matching module for extracting dependency information of each external dependency associated with the code changes of the target version of the program under test, and matching corresponding Mock objects and Mock rules for the external dependencies in the first and second test cases based on the dependency information; and a third determination module for determining the matched first and second test cases as target test cases for the target version of the program under test. Thus, by using the trained test case filtering and generation models, test cases matching the code changes of the program under test can be generated, improving the accuracy of test case generation in automated testing.

[0185] Based on the same application concept, please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0186] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 and the memory 420 communicate through the bus 430. When the machine-readable instructions are executed by the processor 410, the steps of the test case generation method provided in the above embodiment are executed. For specific implementation, please refer to the method embodiment, which will not be repeated here.

[0187] Based on the same concept, this application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it executes the steps of the test case generation method provided in the above embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0188] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0189] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0190] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0192] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0193] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0194] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for generating test cases, characterized in that, The method includes: Based on Git change awareness, the code changes of the target version of the test program are extracted to obtain the code change information of the target version of the test program. Based on the code change information and the trained test case screening model, at least one first test case related to the code changes of the program under test is selected from the historical test cases of the program under test. Based on the code change information and the trained test case generation model, at least one second test case is generated that is related to the code changes of the program under test and is not in the historical test cases of the program under test; the second test case is an incremental test case, including the input data of the test case, the expected output of the test case, the verification method of the test case, and the execution order of the test cases; Extract dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and based on the dependency information, match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case; The matched first test case and the matched second test case are determined as the target test cases for the target version of the program to be tested; The test case generation model is trained according to the following steps: Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases; Based on the historical code change information, the historical test cases, and the historical test results, a second input feature of the program to be tested is determined; the second input feature includes the lines of code covered by the test cases, the types of input parameters for the test cases, the expected output of the test cases, and the execution path when the test cases are executed. The test case generation model is trained based on the second input feature to obtain the trained test case generation model.

2. The test case generation method according to claim 1, characterized in that, Train the test case selection model according to the following steps: Obtain historical code change information and historical test cases of the program under test; Based on the historical code change information and the historical test cases, the first input feature of the program to be tested is determined; The first input features include the method, class, module that has changed, the coverage of the test cases, and the data type of the input; The test case selection model is trained based on the first input feature to obtain the trained test case selection model.

3. The test case generation method according to claim 1, characterized in that, Each of the second test cases includes the input data of the test case, the expected output of the test case, the verification method of the test case, and the execution order of the test cases.

4. The test case generation method according to claim 1, characterized in that, The method further includes: Based on the target test cases of the target version of the program to be tested and the trained test priority prediction model, the test priority of each target test case is determined; The test order of each target test case is determined based on the test priority of each target test case.

5. The test case generation method according to claim 4, characterized in that, Train the test priority prediction model according to the following steps: Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases; Based on the historical code change information, the historical test cases, and the historical test results, the third input feature of the program to be tested is determined; The third input feature includes the execution result of the test case, the failure frequency of the test case, and the complexity of code changes; The test priority prediction model is trained based on the third input feature to obtain the trained test priority prediction model.

6. The test case generation method according to claim 1, characterized in that, The method further includes: Test the target version of the program under test based on the target test cases, and obtain the target test results of the target version of the program under test. Based on the target test results and the trained test result optimization model, target optimization suggestions are generated for the target test cases; the target optimization suggestions include test scenarios not covered by the target test cases, boundary conditions missing by the target test cases, and exception handling paths for the target test cases.

7. A test case generation device, characterized in that, The test case generation device includes: The change extraction module is used to extract code changes of the target version of the test program based on Git change awareness, and obtain the code change information of the target version of the test program. The first determining module is used to select at least one first test case related to the code changes of the program under test from the historical test cases of the program under test based on the code change information and the trained test case filtering model. The second determining module is used to generate at least one second test case that is related to the code changes of the program under test and is not in the historical test cases of the program under test, based on the code change information and the trained test case generation model; the second test case is an incremental test case, including the input data of the test case, the expected output of the test case, the verification method of the test case, and the execution order of the test case; The dependency matching module is used to extract the dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and based on the dependency information, match the corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case. The third determining module is used to determine the matched first test case and the matched second test case as the target test cases of the target version of the program to be tested; The second determining module is further configured to train the test case generation model according to the following steps: Obtain historical code change information of the program under test, historical test cases of the program under test, and historical test results of the historical test cases; Based on the historical code change information, the historical test cases, and the historical test results, a second input feature of the program to be tested is determined; the second input feature includes the lines of code covered by the test cases, the types of input parameters for the test cases, the expected output of the test cases, and the execution path when the test cases are executed. The test case generation model is trained based on the second input feature to obtain the trained test case generation model.

8. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the test case generation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the test case generation method as described in any one of claims 1 to 6.

Images