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

Abstract

The invention provides a test case generation method and device, electronic equipment and a readable storage medium, code change is extracted based on Git change perception, and code change information of a to-be-tested program of a target version is obtained; screening out a first test case based on the code change information and a trained test case screening model; generating a second test case based on the code change information and a trained test case generation model; extracting dependency information of each external dependency associated with the code change, and matching a Mock object and a Mock rule for the external dependencies in the first test case and the second test case; and determining the matched first test case and second test case as a target test case of the to-be-tested program of the target version. Thus, through the trained test case screening model and test case generation model, the test case matched with the code change of the to-be-tested program can be generated, and the accuracy of test case generation in automatic testing is improved.

Description

Technical Field

[0001] The present application relates to the field of automated testing technology, and in particular to a method, device, electronic device, and readable storage medium for generating test cases. Background Art

[0002] With the shortening of software development cycles and the increasing 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 to test cases. Manually updating test cases and mock objects creates a huge maintenance burden.

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

[0004] In view of this, the embodiments of the present application at least provide a test case generation method, device, electronic device and readable storage medium. Through the trained test case screening model and test case generation model, test cases that match the code changes of the program to be tested can be generated, thereby improving the accuracy of test case generation in automated testing.

[0005] This application mainly includes the following aspects: In a first aspect, an embodiment of the present application provides a method for generating a test case, the method comprising: Extract code changes of the target version of the program to be tested based on Git change awareness, and obtain code change information of the target version of the program to be tested; Based on the code change information and the trained test case screening model, screening at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested; 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 change of the program to be tested and is not included in the historical test cases of the program to be tested; Extracting dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and matching corresponding mock objects and mock rules for the external dependencies in the first test case and the second test case based on the dependency information; The matched first test case and the matched second test case are determined as target test cases of the target version of the program to be tested.

[0006] In a second aspect, an embodiment of the present application further provides a test case generation device, the test case generation device comprising: A change extraction module is used to extract code changes of the target version of the program to be tested based on Git change perception, and obtain code change information of the target version of the program to be tested; a first determining module, configured to screen out at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested based on the code change information and a trained test case screening model; A second determination module is configured to generate, based on the code change information and the trained test case generation model, at least one second test case that is related to the code change of the program to be tested and is not included in the historical test cases of the program to be tested; A 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 to be tested, and based on the dependency information, match 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 configured to determine the matched first test case and the matched second test case as target test cases of the target version of the program to be tested.

[0007] In a third aspect, an embodiment of the present application further provides an electronic device comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate through the bus, and the machine-readable instructions are executed by the processor to execute the steps of the test case generation method as described above.

[0008] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, the steps of the test case generation method as described above are executed.

[0009] The test case generation method, device, electronic device and readable storage medium provided by the embodiment of the present application extract the code changes of the target version of the program to be tested based on Git change perception to obtain the code change information of the target version of the program to be tested; 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 to be tested is screened from the historical test cases of the program to be tested; based on the code change information and the trained test case generation model, at least one second test case related to the code change of the program to be tested and not in the historical test cases of the program to be tested is generated; the dependency information of each external dependency associated with the code change of the program to be tested in the target version is extracted, and based on the dependency information, the corresponding Mock objects and Mock rules are matched 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 of the target version of the program to be tested. In this way, through the trained test case screening model and the test case generation model, test cases that match the code changes of the program to be tested can be generated, thereby improving the accuracy of test case generation in automated testing.

[0010] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 A flow chart showing a method for generating a test case provided in an embodiment of the present application is shown; Figure 2 One of the functional module diagrams of a test case generation device provided in an embodiment of the present application is shown; Figure 3 A second functional module diagram of a test case generation device provided in an embodiment of the present application is shown; Figure 4 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0013] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0014] To facilitate understanding of the present application, the technical solutions provided in the present application are described in detail below in conjunction with specific embodiments.

[0015] See also Figure 1 , Figure 1 This is a flow chart of a method for generating a test case provided in an embodiment of the present application. Figure 1 As shown, the test case generation method provided in the embodiment of the present application includes the following steps: S101, extracting code changes of a target version of a program to be tested based on Git change awareness, and obtaining code change information of the target version of the program to be tested.

[0016] Here, Git Change Perception (Git Change Perception) monitors code commits for the target version of the program under test, analyzes code changes using the Git diff tool, and generates code change information for the target version of the program under test. Git Change Perception is a technology used to monitor and analyze code changes in the Git version control system in real time. Code change information includes information such as changed files, methods, classes, and modified line numbers. This information provides basic data support for subsequent test case screening and generation.

[0017] In the embodiment of the present application, by configuring Git Hook (such as post-commit), it is ensured that the change detection module is automatically triggered after each code submission, and test optimization and dependency identification are performed, thereby synchronously updating the test environment. Specifically, in the ".git / hooks" directory of the Git repository, configure the post-commit hook. Edit the post-commit file and 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 Run the following command: `python3 detect_changes.py changed_files.txt`. Integrate this script 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 testing and optimization. For example, after committing code, the post-commit hook is triggered, generating "changed_files.txt" and passing it to Jenkins, which then performs automated testing and optimization.

[0018] Next, use the git diff tool to analyze each submitted code change, extract the changed files and modified lines, and generate a detailed change report to represent the code change information, providing data support for dependency identification. Specifically, use the git diff command to compare the current submission with the previous version and obtain the changed files and line numbers: "git diff --name-only HEAD~1 HEAD | grep ".java" git diff HEAD~1 HEAD -- .java>diff_report.txt".

[0019] Parse "diff_report.txt", extract the changed files and modified line numbers, and generate a structured change area report (such as JSON or XML format). For example, code change information can be expressed in the following change area report format: "{ "file": "OrderService.java", "changed_lines": [20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32,33, 34, 35], "change_type": "modified" }".

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

[0021] Furthermore, static analysis is used to identify the dependencies of the changed areas, providing support for subsequent incremental test case generation and mock object generation. Specifically, static analysis tools (such as Eclipse JDT or Spoon) are used to parse the changed files and generate an abstract syntax tree (AST) to capture the dependencies between the codes. Dependency nodes such as method calls and variable references in the code are identified. For example, it is identified 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.).

[0022] Based on static analysis, we further identify and analyze the relationship between the changed code and external dependencies (such as databases, APIs, message queues, etc.). Based on the static analysis results, we generate a dependency report to ensure the accuracy of mock object generation and test cases.

[0023] S102 : Based on the code change information and the trained test case screening model, screen out at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested.

[0024] Here, we leverage a trained test case screening model to filter out test cases related to code changes from historical test cases. By analyzing code change information and the characteristics of historical test cases, the model identifies potentially affected test cases, thereby avoiding unnecessary full regression testing and improving testing efficiency.

[0025] In an embodiment of the present application, a trained test case screening model is used to analyze the change area report generated in S101 to identify classes, methods, and modules related to the change, with a focus on their inputs, outputs, and dependencies. Relevant test cases are automatically found based on the change content, and redundant test cases that are not related to the change are excluded. 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 to be tested is screened from the historical test cases of the program to be tested as the first test case. The change area report records the specific information of the code change, including the changed code lines, 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 the change content: the specific modified code area (such as class, method, functional module); the scope of impact: the modules, classes, and methods affected by the change, as well as their external dependencies (such as databases, external services, etc.); the change type: method addition, logic modification, code deletion, etc.

[0026] Specifically, the test case screening model filters out test cases related to the changed area from historical test cases. For example, when modifying the order validation logic of the "OrderService.processOrder" method, the test case screening model will identify test cases related to this method, such as "OrderServiceTest.testProcessOrderValidId", and mark them as test cases related to the change. The test case screening model automatically excludes test cases that are not related to the change by analyzing the characteristics of the changed area, avoiding waste of resources. The test case screening model can also automatically identify and exclude irrelevant test cases based on historical test coverage and dependencies between modules. Finally, a streamlined test case list is generated, including only test cases related to the change.

[0027] For example, suppose the order ID validation logic of the "OrderService.processOrder" method has changed. After analysis, the test case screening model identifies the following test cases related to the change: Changed code: The order ID validation logic of the "OrderService.processOrder" method has been modified.

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

[0029] Exclude irrelevant test cases, such as the test of the "PaymentService" module.

[0030] Finally, the filtered test cases are obtained: "OrderServiceTest.testProcessOrderValidId"; "OrderServiceTest.testProcessOrderInvalidId".

[0031] Screening results: These test cases will be executed, and other irrelevant test cases will be excluded to avoid redundant execution and thus improve test efficiency.

[0032] 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 change of the program to be tested and is not in the historical test cases of the program to be tested.

[0033] Here, the 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 areas and generate incremental test cases that cover the changed areas, further improving test coverage. By filtering out redundant test cases, it ensures both efficiency and quality.

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

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

[0036] Here, in order to ensure that the generated test cases can fully cover the code changes and effectively verify their correctness, the second test cases generated in the present invention are incremental test cases, which include the following key components: Test case input data: the input parameters or data sets inferred by the test case generation model; Expected output of the test case: the correct output or exception handling result derived from the change; Test case verification method: used to verify whether the test results meet the expected automated verification logic; Test case execution order: Optimize the execution order of test cases based on historical data, the impact of the change, and risk assessment, giving priority to high-risk test cases.

[0037] For example, assuming that the order ID verification logic of the "OrderService.processOrder" method has changed, the test case generation model will generate the following incremental test cases: Test Case 1: When the order ID is negative, throw "OrderNotFoundException"; Input: "Order ID = -1"; Expected output: Throws "OrderNotFoundException".

[0038] Test case 2: When the order ID is 0, throw "InvalidOrderIdException"; Input: "Order ID = 0"; Expected Output: Throws "InvalidOrderIdException".

[0039] Test case 3: When the order ID is a valid number, the processing is successful and the order information is returned; Input: "Order ID = 123"; Expected output: Order object with return status "Success".

[0040] Furthermore, the test case generation model not only focuses on the number of generated test cases, but also optimizes the quality of test cases through the following means: Reduce redundant test cases: By analyzing the impact of the change and historical test execution data, the test case generation model identifies redundant test cases and excludes them from the generation list. For logic that has already been tested or unaffected code paths, the test case generation model automatically identifies and avoids duplication of tests.

[0041] Covering Potentially Risky Paths: The test case generation model analyzes historical errors and testing blind spots, automatically generating potentially undetected error paths to further improve test coverage. Using historical failure data, the test case generation model identifies undertested boundary conditions and exception handling paths, supplementing these test cases to ensure comprehensive coverage of all possible code paths.

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

[0043] Here, we extract external dependency information associated with code changes in the target version of the program under test and match corresponding mock objects and mock rules to the external dependencies in the filtered and generated test cases. By dynamically generating and optimizing mock objects, we ensure that test cases can run in an isolated environment, reducing dependence on external systems and improving test stability and efficiency.

[0044] Specifically, it automatically monitors changes in the Git code base, extracts change information (change area report), and identifies external dependencies related to code changes (such as databases, APIs, message queues, etc.). Configure the post-commit hook to trigger change analysis when the code is submitted. Use the git diff command to extract the changed files and lines, generate a change area report, and indicate the affected modules and dependencies. Analyze the change area report and automatically identify external dependencies that need to generate Mock objects. For example, if the "processOrder" method in the "OrderService" class modifies the call to "orderRepository.findById(orderId)", it is identified that the database query dependency needs to generate a Mock object for processing.

[0045] Then, based on the dependency analysis results, Mock objects are automatically generated to replace actual external services, ensuring that the test is independent of external systems. Specifically, for database dependencies, simulate database calls and return preset data. For HTTPAPI dependencies, simulate HTTP response data and return simulated JSON responses. For message queue dependencies, simulate message responses and return simulated messages. To ensure that Mock objects are automatically injected into unit tests, use the dependency injection mechanism in conjunction with test frameworks (such as JUnit, Mockito, Spring Test, etc.). Specifically, Mock objects are automatically created and injected into test cases through Dependency Injection (DI). Use the "@Mock" annotation or other automated configuration tools to ensure that Mock objects are correctly injected during test execution.

[0046] Next, configure appropriate return values ​​for the mock objects based on the call behavior of each external dependency. Use a mocking 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 change areas, select which mock objects require specific return values.

[0047] Next, ensure that mock objects are automatically created and destroyed during 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 clear them after the test execution to ensure the independence of each test case.

[0048] Furthermore, if the business logic changes, the system automatically updates the behavior of the mock object to ensure consistency with the actual code logic. Specifically, the system monitors business logic changes and automatically updates the return value or behavior of the mock object based on the changes. Using AI models or a rules engine, the mock object is ensured to adapt to changes in business logic.

[0049] In the embodiment of the present application, the Mock rules are automatically optimized through the AI ​​model so that the behavior of the Mock object can dynamically adapt to changes in code and business logic, ensuring a high degree of consistency with the actual external service, thereby improving test accuracy and efficiency.

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

[0051] 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 issues are covered.

[0052] When the system's business logic changes, the AI ​​model automatically generates new mock rules and replaces the old ones, ensuring that 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 an "OrderNotFoundException" exception.

[0053] Furthermore, through external configuration files, testers can dynamically modify the behavior and test strategies of Mock objects in real time to ensure that the test can adapt to changes in code and business logic, thereby ensuring efficient test execution and accurate test results. Specifically, the Mock object and Mock rules are first automatically generated according to the code dependency information of the target version by an automatic generation module driven by the dependency analysis results; then, the Mock configuration is read from the external configuration file, and the automatically generated rules are merged or overwritten. Among them: if the configuration file does not define a rule for a certain dependency, the automatically generated rule is retained; if the configuration file provides a detailed definition for a certain dependency, the configuration file rules are used to replace or supplement the automatically generated content to dynamically adjust the behavior and test strategy of the Mock object in real time.

[0054] Specifically, the configuration file format in the embodiment of the present application supports multiple formats (such as JSON, YAML) so that testers can choose the appropriate format according to their needs. 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 in the configuration file in real time. Once the file is modified, the system will automatically capture 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. At the same time, only the changed part is updated to avoid repeated loading of the unchanged configuration, thereby improving system performance.

[0055] Furthermore, the configuration management system records the history of every configuration file change and generates a unique version number. Testers can view version changes and trace changes. Configuration version management is implemented using 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.

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

[0057] Furthermore, the configuration management system supports priority management. When multiple rules conflict, the system loads configurations in order of priority, ensuring that the highest-priority rules take effect. Specifically, each configuration can specify a "priority" field, and the system will prioritize loading the highest-priority configuration.

[0058] Furthermore, after a configuration file is modified, if certain fields or rules contain errors (such as missing required fields or invalid values), the configuration management system will trigger an alarm and promptly notify relevant personnel. The alarm can be sent via email, SMS, or push notification.

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

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

[0061] Furthermore, the test case screening model is trained according to the following steps: Step a1: Obtain historical code change information of the program to be tested and historical test cases of the program to be tested.

[0062] Here, we obtain historical code change information and test cases for the program under test. This historical code change information includes the content of each code commit, such as the changed files, methods, classes, and modified line numbers. The historical test cases record the test cases associated with each code change, including test case descriptions, input parameters, expected outputs, and actual execution results. This historical data provides rich learning material for model training.

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

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

[0065] Step a3: training the test case screening model based on the first input feature to obtain a trained test case screening model.

[0066] Here, a test case screening model is trained based on the first input features to obtain a trained test case screening model. Specifically, through machine learning algorithms such as deep learning, decision trees, or random forests, the extracted first input features are trained to enable the model to accurately determine whether a change affects a specific test case, as well as the dependencies between them, and accurately filter out relevant test cases based on the code change information. The trained model will be used in the subsequent test case screening process to improve the accuracy and efficiency of test case screening.

[0067] Furthermore, the test case generation model is trained according to the following steps: Step b1, obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases.

[0068] Here, we obtain historical code change information for the program under test, historical test cases for the program under test, and historical test results for these test cases. This historical code change information includes the changes made to each code commit, such as the changed files, methods, classes, and modified line numbers. Historical test cases record the test cases associated with each code change, including test case descriptions, input parameters, and expected outputs. Historical test results record execution records, 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 / failure, execution time, coverage, etc.). This historical data provides rich learning material for model training.

[0069] 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 code lines covered by the test case, the input parameter type of the test case, the expected output of the test case and the execution path when the test case is executed.

[0070] Here, the second input features of the program to be tested are determined based on historical code change information, historical test cases, and historical test results. The second input features include: Code lines covered by test cases: Identify which code lines have been executed during the execution of the test case. Input parameter type of the test case: Identify the input data type of the test case, such as integer, string, object, etc., and the input numerical range of the test case. Expected output of the test case: Identify the expected result of the test case, such as normal return value, exception information, etc. Execution path during test case execution: Identify the execution path of the test case in the code, including method call chain and control flow path. By analyzing historical data, features related to code changes and test cases are extracted to provide key information for model training.

[0071] Step b3: training the test case generation model based on the second input feature to obtain a trained test case generation model.

[0072] Here, the test case generation model is trained based on the second input features to produce a trained test case generation model. The extracted second input features are trained using machine learning algorithms, such as deep learning, decision trees, or random forests. Through the training process, the model learns how to infer which test cases need to be executed based on the changed areas. This training process leverages historical data to build a model that identifies the correlation between different types of changes (such as function modifications, parameter changes, and conditional modifications) 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, thereby improving incremental test coverage and reducing irrelevant test cases.

[0073] Furthermore, the method further comprises: Step c1: determining the test priority of each target test case based on the target test case of the target version of the program to be tested and the trained test priority prediction model.

[0074] Here, the test priority of each target test case is determined based on the target test cases in the target version of the program under test and a trained test priority prediction model. Specifically, the test priority prediction model analyzes the characteristics of the target test cases (such as the impact of code changes, historical test case execution results, and test case coverage) to predict the importance and risk level of each test case. High-priority test cases are generally considered more critical and should be executed first. This ensures that test cases with the highest potential for discovering defects are executed first within limited testing resources.

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

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

[0077] Here, the test order of each target test case is determined based on the test priority of each target test case. The determination of the test order generally follows the following principles: High priority first: high-priority test cases are executed first to ensure that key functions and high-risk changes are verified first. Dependencies: Consider the dependencies between test cases to ensure that dependent test cases are executed before dependent test cases. Resource optimization: According to the availability of test resources, the execution order of test cases is reasonably arranged to avoid resource bottlenecks. Through a reasonable test sequence, test resources can be used more efficiently, potential problems can be discovered more quickly, and test efficiency and quality can be improved. For example, the "OrderService.processOrder" method modifies the order ID verification logic. The test priority prediction model evaluates that the "testProcessOrderInvalidId" use case is high risk and has a higher priority, so it is executed first.

[0078] Furthermore, the test priority prediction model is trained according to the following steps: Step d1, obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases.

[0079] Here, the historical code change information of the program to be tested, the historical test cases of the program to be tested, and the historical test results of the historical test cases are obtained. These data include: Historical code change information: records the changes of each code submission, including the changed files, methods, classes, and modified line numbers. Historical test cases: records the historical test cases related to each code change, including the description of the test case, input parameters, expected output, etc. Historical test results: records execution records, change data, code paths and other information. These data include past test case execution status, code areas covered by the test, and test results (whether it passed, execution time, coverage, etc.). These historical data provide rich learning materials for model training, helping the model learn the relationship between code changes and test case priorities.

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

[0081] Here, the third input feature of the program to be tested is determined based on historical code change information, historical test cases, and historical test results. The third input feature includes: Test case execution results: Identify the results of the test case in historical execution, such as pass, fail, exception, etc. Test case failure frequency: Count the frequency of failure of each test case in historical execution, reflecting the stability and importance of the test case. Code change complexity: Evaluate the complexity of code changes, such as the number of lines of code involved in the change, the number of modules affected, etc., to reflect the scope of the impact of the change on the system. These features can help the model more accurately evaluate the priority of each test case.

[0082] Step d3: training the test priority prediction model based on the third input feature to obtain a trained test priority prediction model.

[0083] Here, a test priority prediction model is trained based on the third input feature to obtain a trained test priority prediction model. Using a machine learning algorithm, such as deep learning, decision trees, or random forests, the extracted third input feature is trained to enable the model to predict the priority of a test case based on its characteristics. The trained model is then used in the subsequent test priority prediction process to improve the accuracy and efficiency of test case priority assessment.

[0084] Furthermore, the method further comprises: Step e1 : testing the target version of the program to be tested based on the target test case of the target version of the program to be tested, and obtaining a target test result of the target version of the program to be tested.

[0085] Here, the target version of the program under test is tested based on the target test cases of the target version of the program under test, resulting in the target test results for the target version of the program under test. This process includes: Test execution: Running the target test cases on the target version of the program under test, recording the execution results of each test case, including pass, fail, and exception. Result collection: Collecting detailed information during the test execution process, such as the test case execution path, covered code lines, input parameters, and output results. This step verifies the validity of the target test cases and the functional correctness of the target version of the program under test.

[0086] Specifically, after each test is executed, the system automatically collects the following information: Test case execution status (pass / fail); Code coverage (line coverage, branch coverage, condition coverage, etc.); Error messages and exception reports.

[0087] It is also integrated with CI / CD tools (such as Jenkins and GitLab CI) to automatically generate reports through test coverage tools (such as JaCoCo) and upload them to the feedback system for analysis.

[0088] For example, after the test case "processOrder_WithValidOrderId" is executed, the system generates the following report: “Test Execution Report: Test Case: processOrder_WithValidOrderId Status: Passed Line Coverage: 85% Branch Coverage: 75% Failed Test Cases: 2 (OrderNotFoundException handling missed) Exception: OrderNotFoundException (missed coverage)".

[0089] Step e2: Generate target optimization suggestions for the target test case based on the target test result and the trained test result optimization model; the target optimization suggestions include test scenarios not covered by the target test case, boundary conditions missing from the target test case, and exception handling paths for the target test case.

[0090] Here, based on the target test results and the trained test result optimization model, the model analyzes multiple dimensions, including historical data, execution results, and code changes, to automatically optimize test data generation strategies and mock rules. This ensures that the generated test cases are accurate and efficient, while also dynamically adapting to evolving business logic, external dependencies, and test requirements. Targeted optimization recommendations are then generated for the target test cases. These recommendations include: Uncovered 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 identifies scenarios or paths not yet covered by the test cases. Missing boundary conditions: Identifying boundary conditions not covered by the target test cases. For example, determining whether input parameter boundary values ​​(such as maximum, minimum, and null values) are fully tested. Exception handling paths: Identifying exception handling paths not covered by the target test cases. For example, determining whether certain exception conditions are covered by the test cases and whether the exception handling logic is correct. These optimization recommendations help testers further refine their test cases, improving test coverage and quality.

[0091] In the embodiment of the present application, the test result optimization model analyzes the test results in real time to identify uncovered business scenarios or test blind spots. At the same time, it marks uncovered logical branches, exception handling paths, etc. as improvement points. For example, if the "OrderService.processOrder" method's processing path for a negative "orderId" value is not fully tested, the system will automatically generate optimization suggestions: Feedback: Coverage missed for negative orderId scenario (OrderNotFoundExceptionnot tested). Suggested Action: Add a test case where orderId = -1, expectedexception: OrderNotFoundException.".

[0092] 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.

[0093] For example, if the OrderService.processOrder method frequently throws an OrderNotFoundException when the orderId is a negative number, the test result optimization model will generate the following test case: “testCase: name: processOrder_WithNegativeOrderId input: orderId: -1 expectedOutput: exception: OrderNotFoundException".

[0094] 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 a negative number.

[0095] Furthermore, the training data for the test result optimization model includes historical test case execution results, code coverage, failure information, code change records, and business logic changes. This data helps the test result optimization model identify potential testing blind spots, missing coverage paths, and inadequately tested exception 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 tailored to specific business logic. Deep learning, reinforcement learning, and other technologies are used to train the test result optimization model and optimize test data generation and mock rules. For example, suppose the "OrderService.processOrder" method throws an "OrderNotFoundException" when processing a negative "orderId." If the 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 the associated mock objects and mock rules.

[0096] The embodiment of the present application provides a method for generating a test case, comprising: extracting code changes of a target version of a program to be tested based on Git change perception to obtain code change information of the target version of the program to be tested; based on the code change information and a trained test case screening model, screening at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested; based on the code change information and a trained test case generation model, generating at least one second test case related to the code change of the program to be tested and not in the historical test cases of the program to be tested; extracting dependency information of each external dependency associated with the code change of the program to be tested in the target version, and matching corresponding mock objects and mock rules for the external dependencies in the first test case and the second test case based on the dependency information; determining the matched first test case and the matched second test case as the target test case of the target version of the program to be tested. In this way, through the trained test case screening model and the test case generation model, test cases that match the code change of the program to be tested can be generated, thereby improving the accuracy of test case generation in automated testing.

[0097] Based on the same application concept, the embodiments of the present application also provide a test case generation device corresponding to the test case generation method provided in the above embodiments. Since the principle of solving the problem by the device in the embodiments of the present application is similar to the test case generation method in the above embodiments of the present application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0098] See also Figure 2 , Figure 2 This is one of the functional module diagrams of a test case generation device provided in an embodiment of the present application. Figure 2 As shown, the test case generation device 200 includes: The change extraction module 210 is used to extract code changes of the target version of the program to be tested based on Git change awareness, and obtain code change information of the target version of the program to be tested.

[0099] The first determining module 220 is configured to screen out at least one first test case related to the code change of the program to be tested from the historical test cases of the program to be tested based on the code change information and the trained test case screening model.

[0100] The second determination module 230 is configured to generate at least one second test case related to the code change of the program to be tested and not included in the historical test cases of the program to be tested based on the code change information and the trained test case generation model.

[0101] The dependency matching module 240 is used to 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 corresponding Mock objects and Mock rules for the external dependencies in the first test case and the second test case.

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

[0103] Furthermore, the first determining module 220 is further configured to train the test case screening model according to the following steps: Obtaining historical code change information of the program to be tested and historical test cases of the program to be tested; Determining first input features of the program to be tested based on the historical code change information and the historical test cases; the first input features include coverage of the changed methods, classes, modules, and test cases, and input data types; The test case screening model is trained based on the first input feature to obtain a trained test case screening model.

[0104] Furthermore, the second determining module 230 is further configured to train the test case generation model according to the following steps: Obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases; Determining a second input feature of the program to be tested based on the historical code change information, the historical test cases, and the historical test results; the second input feature includes code lines covered by the test case, input parameter types of the test case, expected output of the test case, and execution path when the test case is executed; The test case generation model is trained based on the second input feature to obtain a trained test case generation model.

[0105] Further, see Figure 3 , Figure 3 This is the second functional module diagram of a test case generation device provided in an embodiment of the present application. Figure 3 As shown, the test case generation device 200 also includes: The fourth determining module 260 is configured to determine the test priority of each target test case based on the target test case of the target version of the program to be tested and the trained test priority prediction model.

[0106] The fifth determining module 270 is configured to determine a test order for each of the target test cases based on the test priority of each of the target test cases.

[0107] Furthermore, the fourth determining module 260 is further configured to train the test priority prediction model according to the following steps: Obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases; Determining a third input feature of the program to be tested based on the historical code change information, the historical test cases, and the historical test results; the third input feature includes the execution result of the test case, the failure frequency of the test case, and the complexity of the code change; The test priority prediction model is trained based on the third input feature to obtain a trained test priority prediction model.

[0108] Further, if Figure 3 As shown, the test case generation device 200 also includes: A sixth determining module 280 is configured to test the target version of the program to be tested based on the target test case of the target version of the program to be tested, and obtain a target test result of the target version of the program to be tested; The seventh determination module 290 is used to generate target optimization suggestions for the target test case 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 case, boundary conditions missing from the target test case, and exception handling paths for the target test case.

[0109] The present invention provides a test case generation device, comprising a change extraction module for extracting code changes of a target version of a program to be tested based on Git change perception to obtain code change information of the target version of the program to be tested; a first determination module for filtering out at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested based on the code change information and a trained test case screening model; a second determination module for generating at least one second test case related to the code change of the program to be tested and not in the historical test cases of the program to be tested 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 change of the program to be tested in the target version, and matching corresponding mock objects and mock rules for the external dependencies in the first test case and the second test case based on the dependency information; and a third determination module for determining the matched first test case and the matched second test case as target test cases of the target version of the program to be tested. In this way, through the trained test case screening model and the test case generation model, test cases that match the code change of the program to be tested can be generated, thereby improving the accuracy of test case generation in automated testing.

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

[0111] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 through the bus 430. The machine-readable instructions are executed by the processor 410 when running to execute the steps of the test case generation method provided in the above embodiment. The specific implementation method can be found in the method embodiment and will not be repeated here.

[0112] Based on the same application concept, an embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, the steps of the test case generation method provided in the above embodiment are executed. The specific implementation method can be found in the method embodiment and will not be repeated here.

[0113] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0114] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0115] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

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

[0117] If the functions are implemented in the form of 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 the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0118] It should be noted that similar numbers and letters represent similar items in the following figures. 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 only used to distinguish the description and are not to be understood as indicating or implying relative importance.

[0119] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The scope of protection of the present application is not limited thereto. Although the present application has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed in the present application, or make equivalent replacements for some of the technical features thereof. However, these modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application. They should all be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A method for generating a test case, characterized in that: The method comprises: Extract code changes of the target version of the program to be tested based on Git change awareness, and obtain code change information of the target version of the program to be tested; Based on the code change information and the trained test case screening model, screening at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested; 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 change of the program to be tested and is not included in the historical test cases of the program to be tested; Extracting dependency information of each external dependency associated with the code changes of the target version of the program to be tested, and matching corresponding mock objects and mock rules for the external dependencies in the first test case and the second test case based on the dependency information; The matched first test case and the matched second test case are determined as target test cases of the target version of the program to be tested.

2. The test case generation method according to claim 1, characterized in that: Train the test case screening model according to the following steps: Obtaining historical code change information of the program to be tested and historical test cases of the program to be tested; Determining a first input feature of the program to be tested based on the historical code change information and the historical test cases; The first input features include the coverage of the changed methods, classes, modules, and test cases and the input data types; The test case screening model is trained based on the first input feature to obtain a trained test case screening model.

3. The test case generation method according to claim 1, characterized in that: Train the test case generation model according to the following steps: Obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases; Determining a second input feature of the program to be tested based on the historical code change information, the historical test cases, and the historical test results; the second input feature includes code lines covered by the test case, input parameter types of the test case, expected output of the test case, and execution path when the test case is executed; The test case generation model is trained based on the second input feature to obtain a trained test case generation model.

4. The test case generation method according to claim 1, wherein: 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 case.

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

6. The test case generation method according to claim 5, characterized in that: The test priority prediction model is trained according to the following steps: Obtaining historical code change information of the program to be tested, historical test cases of the program to be tested, and historical test results of the historical test cases; Determining a third input feature of the program to be tested based on the historical code change information, the historical test cases, and the historical test results; The third input features include the execution results of the test cases, the failure frequency of the test cases, and the complexity of the code changes; The test priority prediction model is trained based on the third input feature to obtain a trained test priority prediction model.

7. The test case generation method according to claim 1, characterized in that: The method further comprises: Testing the target version of the program to be tested based on the target test case of the target version of the program to be tested, and obtaining a target test result of the target version of the program to be tested; Based on the target test results and the trained test result optimization model, a target optimization suggestion for the target test case is generated; the target optimization suggestion includes the test scenarios not covered by the target test case, the boundary conditions missing from the target test case, and the exception handling path of the target test case.

8. A test case generation device, characterized in that: The test case generating device includes: A change extraction module is used to extract code changes of the target version of the program to be tested based on Git change perception, and obtain code change information of the target version of the program to be tested; a first determining module, configured to screen out at least one first test case related to the code change of the program to be tested from historical test cases of the program to be tested based on the code change information and a trained test case screening model; A second determination module is configured to generate, based on the code change information and the trained test case generation model, at least one second test case that is related to the code change of the program to be tested and is not included in the historical test cases of the program to be tested; A 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 to be tested, and based on the dependency information, match 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 configured to determine the matched first test case and the matched second test case as target test cases of the target version of the program to be tested.

9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate through the bus. When the processor is running, the machine-readable instructions execute the steps of the test case generation method as described in any one of claims 1 to 7.

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

Images