Unit test case generation method and device, electronic equipment, readable storage medium and chip

Abstract

The embodiment of the invention provides a unit test case generation method and device, electronic equipment, a readable storage medium and a chip, and the unit test case generation method comprises the steps: obtaining a structured call log in the operation process of a business application system; obtaining a source code data set of the target software and method meta-information corresponding to the source code data set; the environment parameters and the method meta-information serve as input sources and are input into the large language model; and generating a unit test case corresponding to the target software through the large language model, wherein the unit test case is used for covering at least one production environment. By means of the scheme, it is ensured that the generated unit test case covers a real service scene.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to a unit test case generation method, apparatus, electronic device, readable storage medium, and chip. Background Technology

[0002] In the field of software engineering, unit testing is a core component for ensuring code quality. However, traditional test case writing struggles to reproduce complex parameter combinations in online environments (such as abnormal boundary values ​​and special business states), leading to artificially high test pass rates and frequent online failures.

[0003] While there are test generation tools based on logs or static analysis in related technologies, they still rely on preset rules to fill in parameters, cannot understand the business semantics of the code, and cannot identify abnormal branch logic. The generated unit test cases cannot fully cover real business scenarios. Summary of the Invention

[0004] The purpose of this invention is to provide a unit test case generation method, apparatus, electronic device, readable storage medium, and chip that can solve the problem that the generated unit test cases cannot fully cover real business scenarios.

[0005] In view of this, an embodiment of the first aspect of the present invention provides a method for generating unit test cases.

[0006] A second aspect of the present invention provides a unit test case generation apparatus.

[0007] An embodiment of the third aspect of the present invention provides an electronic device.

[0008] An embodiment of the fourth aspect of the present invention provides a readable storage medium.

[0009] An embodiment of the fifth aspect of the present invention provides a chip.

[0010] To achieve the above objectives, an embodiment of the first aspect of the present invention provides a unit test case generation method, which includes: acquiring structured call logs during the operation of a business application system, wherein the structured call logs are collected in real time from the business application system using aspect-oriented programming technology, and the structured call logs include at least one environment parameter of the target software; acquiring the source code dataset of the target software and method meta-information corresponding to the source code dataset; inputting the environment parameters and method meta-information as input sources into a large language model; and generating unit test cases corresponding to the target software through the large language model, wherein the unit test cases are used to cover at least one production environment.

[0011] The unit test case generation method provided by this invention non-intrusively collects real-world call data from the production environment (i.e., environment parameters) using Aspect-Oriented Programming (AOP) technology, and extracts method metadata corresponding to the target software using static code analysis. Based on dynamic environment parameters and static method metadata, it achieves dual-source data collaborative driving, inputting both environment parameters and method metadata into a large model to generate multi-scenario unit test cases covering normal flow, boundary values, and abnormal branches.

[0012] In some technical solutions, optionally, after generating unit test cases corresponding to the target software through a large language model, the process includes: executing the unit test cases and detecting the code coverage corresponding to the unit test cases; obtaining a preset threshold for code coverage; if the code coverage is greater than or equal to the preset threshold, maintaining the business application system through the unit test cases; if the code coverage is less than the preset threshold, updating the unit test cases according to the structured call logs.

[0013] This solution progressively enhances unit test cases through code coverage feedback, automatically improving code coverage. By automating test case execution and quantifying code coverage, it objectively assesses the quality shortcomings of initially generated test cases, transforming subjective judgments of test adequacy into objective, automated decision signals based on preset thresholds, thus achieving precise incremental optimization.

[0014] In some technical solutions, optionally, after generating unit test cases corresponding to the target software through a large language model, the unit test case generation method further includes: injecting the unit test cases into the continuous delivery and / or continuous deployment pipeline for execution, so as to trigger code coverage detection when the business application system is updated.

[0015] In this solution, the generated unit test cases are injected into the Continuous Integration / Continuous Deployment (CI / CD) pipeline for execution, and code coverage is collected to automatically update the unit test cases.

[0016] In some technical solutions, optionally, unit test cases are updated based on structured call logs, including: obtaining existing code in the business application system; obtaining code coverage detection results of the existing code and identifying specific code branches or logical paths that are not covered; retrieving historical abnormal call information and / or low-frequency parameters from the structured call logs based on the specific code branches or logical paths that are not covered; and updating the unit test cases with historical abnormal call information and / or low-frequency parameters to generate targeted patch test cases.

[0017] In this solution, a static code analysis engine scans the entire source code dataset, identifying all historical code in the codebase to determine the existing code in the business application system. Static analysis tools then locate specific uncovered code branches (uncovered if-else branches in logical functions) or abnormal logic paths (such as exception class variable catch blocks and boundary value validation logic).

[0018] In some technical solutions, optionally, after generating unit test cases corresponding to the target software through a large language model, the unit test case generation method further includes: storing the unit test cases in a test asset library and establishing a monitoring association between the unit test cases and the source code of the target software; continuously monitoring whether the source code has changed; when the source code has changed, triggering the generation of updated unit test cases; obtaining the method meta-information of the changed source code and inputting the method meta-information of the changed source code and related structured call logs into the large language model to generate updated test cases synchronized with the code version.

[0019] This solution aims to address the inevitable test corruption problem in software iteration, where existing unit test cases become invalid, outdated, or uncompilable after source code modifications, thus losing their protective function. By establishing an automatic detection and update mechanism, it ensures that unit test cases are always synchronized with the code logic.

[0020] In some technical solutions, the environmental parameters may optionally include at least the input parameters, output parameters, and abnormal parameters corresponding to the business application system.

[0021] In this approach, input parameters, output parameters, and exception parameters are combined to form a complete set of environment parameters. These parameters record the actual production traffic of a call from its start (input parameters) to its normal completion (output parameters) or abnormal failure (exception parameters). This provides the large language model with all the contextual information needed to understand method behavior.

[0022] A second aspect of the present invention provides a unit test case generation device, comprising: a dynamic acquisition module for acquiring structured call logs during the operation of a business application system, wherein the structured call logs are acquired in real time from the business application system using aspect-oriented programming (AOP) technology, and the structured call logs include at least one environment parameter of the target software; a static acquisition module for acquiring the source code dataset of the target software and method metadata corresponding to the source code dataset; a data transmission module for inputting the environment parameters and method metadata as input sources into a large language model; and a test generation module for generating unit test cases corresponding to the target software through the large language model, wherein the unit test cases cover at least one production environment.

[0023] An embodiment of the third aspect of this application provides an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the unit test case generation method as described in the first aspect.

[0024] An embodiment of the fourth aspect of this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the unit test case generation method as described in the first aspect.

[0025] An embodiment of the fifth aspect of this application provides a chip including a processor and a communication interface, the communication interface and the processor being coupled together, the processor being used to run a program or instructions to implement the steps of the unit test case generation method as described in the first aspect.

[0026] Additional aspects and advantages of the technical solutions of the present invention will become apparent in the following description or may be learned by practice of the invention. Attached Figure Description

[0027] Figure 1 One of the flowcharts of the unit test case generation method according to this application is shown; Figure 2 A second flowchart illustrating the unit test case generation method according to this application is shown; Figure 3 The third flowchart illustrates the unit test case generation method according to this application; Figure 4 The fourth flowchart illustrates the unit test case generation method according to this application; Figure 5 A schematic block diagram of the unit test case generation apparatus according to this application is shown; Figure 6 A schematic block diagram of the structure of an electronic device according to this application is shown; Figure 7 The fifth flowchart illustrates the unit test case generation method according to this application; Figure 8 A schematic diagram illustrating the operational logic of the unit test case generation method according to this application is shown.

[0028] Wherein, 900: Unit test case generation device; 902: Dynamic acquisition module; 904: Static acquisition module; 906: Data transmission module; 908: Test generation module; 1000: Electronic device; 1109: Memory; 1110: Processor. Detailed Implementation

[0029] To better understand the above-described objectives, features, and advantages of the embodiments of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0030] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, embodiments of the invention may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0031] The shortcomings or deficiencies of unit testing in related technologies include: limitations of mock tools: Mock tools only solve the problem of object simulation, but test data still needs to be manually constructed and cannot obtain real parameters of the production environment; deficiencies of automated testing tools: User interface (UI) based automated testing has high maintenance costs, requiring testers to maintain it in real time according to the iteration progress, and the proportion of effective test cases generated by fuzzing is low; distortion of traditional unit test code generation tools: test case scenarios generated by traditional test case generation tools are distorted, based only on static code analysis, lacking understanding of business scenarios, and the runnable rate of generated test cases is less than 30%. Manually written test cases are often based on the understanding of developers and may not fully cover real business scenarios; high test case maintenance costs: test cases need to be updated synchronously with code changes, resulting in high manual maintenance costs; lack of test case coverage for existing code: existing code may never have had test cases written, leading to difficulties in regression testing; insufficient coverage of unit test scenarios: traditional manually written unit tests often only cover simple scenarios, and complex business scenarios (such as abnormal branches, system crashes, boundary value exceedances) are easily missed, and differences between the test environment and the production environment lead to test distortion.

[0032] By automatically collecting real request parameters from the production environment through the aspect-oriented programming system, mock data can be automatically generated without the intervention of R&D or testing personnel, reducing data construction work. Combined with the powerful context understanding and code recognition capabilities of the large-scale model, business code and corresponding real business parameters are transmitted to the large-scale model. This allows for the batch generation of unit test cases from existing code, significantly improving the efficiency of unit test case generation. Furthermore, by capturing business parameters from various scenarios (including abnormal scenarios) through real traffic, the test cases generated by the large-scale model can cover these complex situations, ensuring that the generated test cases cover real business scenarios.

[0033] The unit test case generation method, apparatus, electronic device, readable storage medium, and chip provided in this application will be described in detail below with reference to specific embodiments and application scenarios.

[0034] This embodiment provides a method for generating unit test cases, such as... Figure 1 As shown, the unit test case generation method includes: Step S100: Obtain structured call logs during the operation of the business application system. The structured call logs are collected in real time from the business application system using aspect-oriented programming technology. The structured call logs include at least one environment parameter of the target software. Step S102: Obtain the source code dataset of the target software and the corresponding method metadata; Step S104: Input the environmental parameters and method meta-information as input sources into the large language model; Step S108: Generate unit test cases corresponding to the target software using the large language model. The unit test cases are used to cover at least one production environment.

[0035] It should be noted that structured call logs are logs developed by developers during the debugging process of the code corresponding to the test functions. Developers often test as they develop, and the development work is only considered complete when the code is completed and passes the tests. Therefore, a large number of structured call logs will be generated during the operation of the business application system. Collecting the structured call logs provides reference data for the normal flow input parameters of subsequent unit tests.

[0036] As an example, when the server detects that an operation interface has been used to complete the development operation of the target software, the server obtains the structured call log corresponding to the development operation.

[0037] It is important to emphasize that the structured call log is collected in real time from the production environment of the business application system using Aspect-Oriented Programming (AOP) technology. The structured call log includes at least one environment parameter of the target software.

[0038] As an example, AOP is a programming paradigm that uses dynamic proxy technology to separate cross-cutting concerns (such as logging and transactions) from core business logic during program execution. The core concepts of AOP include aspects, join points, advice, and pointcuts. An aspect is a module that encapsulates cross-cutting logic (such as logging); a join point is a point in program execution (such as a method call); advice refers to the action of an aspect at a join point (such as before or after method execution); and a pointcut is an expression that matches a join point (such as intercepting a specific method).

[0039] By using AOP to separate business logic from system services, at least one environmental parameter of the target software can be determined.

[0040] The unit test case generation method provided by this invention non-intrusively collects real call data from the production environment (i.e., environment parameters) using AOP technology, and extracts method meta-information corresponding to the target software using static code analysis technology. Based on dynamic environment parameters and static method meta-information, it achieves dual-source data collaborative driving, inputting both environment parameters and method meta-information into a large model to generate multi-scenario unit test cases covering normal flow, boundary values, and abnormal branches.

[0041] Specifically, by employing AOP technology on business application systems running in the production environment, complete context information of method calls is collected in real time before and after the execution of the target method in a non-intrusive manner to determine at least one environmental parameter of the target software.

[0042] Once at least one environment parameter is formatted, a structured call log that can be queried and analyzed is formed.

[0043] The source code dataset of the target software is obtained from the source code repository of the business application system. The source code dataset includes multiple source codes of the target software. Static code analysis techniques are used to scan and parse the source code to extract key structured information, namely method metadata.

[0044] For example, method metadata includes method signature (method name, parameter types, return type), class-method dependencies, internal branching logic (if / else, switch, etc.), and explicitly declared exception throwing points.

[0045] The structured call logs from real-world runtime scenarios and method metadata representing the code's internal logic are combined and used as context for prompt words, which are then input into the large language model. This dual-context input approach provides the large language model with all the information necessary for high-quality test cases.

[0046] The large language model performs deep understanding and code generation based on the provided dual context.

[0047] Among them, using environmental parameters and method meta-information as input sources first requires establishing a mapping relationship between parameters and code. Prioritizing the selection of historical parameters most relevant to the current code branch logic as the main input optimizes the context construction strategy, improves the relevance of input data, and directly improves generation efficiency and quality.

[0048] For example, the large language model generates test case skeletons that conform to language specifications and framework requirements based on method meta-information; constructs legal, valid test data that covers the normal process based on parameters in the actual call logs; and intelligently infers and generates negative test cases for testing boundary conditions and abnormal scenarios by combining branches and exception throwing points in the code and exception information captured in the logs.

[0049] The final output of the large language model is a set of unit test cases that can be run directly and are designed for the target software.

[0050] Unit test cases are independent test programs that verify whether the smallest testable unit of code (such as functions, methods, and classes) works as expected.

[0051] Specifically, the meaning of a unit test case should be determined based on the actual situation. For example, in a programming language (C language), a unit refers to a function; in an object-oriented programming language (Java), a unit refers to a class; and in graphical software, it can refer to a window or a menu, etc.

[0052] In general, a unit is the smallest functional module to be tested, as defined by the developer. Unit testing is the lowest level of testing activity performed during software development; independent units of software are tested in isolation from other parts of the program.

[0053] For example, the large language model adopts a step-by-step generation strategy: first, it generates a test case framework; then, it generates specific test data based on parameters; and finally, it synthesizes complete test cases. By refining the generation process, the complexity of each generation is reduced, and the accuracy and runnability of the generation are improved.

[0054] Understandably, by collecting environmental parameters and method metadata, the system determines the actual production traffic and complete code branch logic. The large model is then guided to automatically generate test cases covering various abnormal branches and boundary conditions, transforming the time-consuming and labor-intensive manual coding work into a fully automated intelligent generation process. Once configured, the system can automatically scan the code in the business application system, collect data, call the model, and generate unit test cases, greatly liberating developer productivity, improving unit test case coverage, and thus significantly enhancing the runnability and accuracy of the generated test cases.

[0055] In some embodiments, the structured call log may optionally include thread stack information and associated database transaction number during method execution to enhance the data dimension of dynamic data and provide a basis for generating complex concurrent development scenarios and data consistency test cases.

[0056] In some embodiments, optionally, collecting real-time production environment data also includes obtaining a complete set of call chain parameters across multiple microservices through distributed tracing. This extends production environment method calls from the single method level to the business process level, supporting the generation of cross-server integration test units.

[0057] In some embodiments, optionally, code change history analysis can be used to identify frequently modified code paths and their corresponding test case change impact domains, providing more accurate code change insights for large language models and enabling more targeted unit test case optimization.

[0058] In some embodiments, optionally, such as Figure 2 As shown, after generating unit test cases corresponding to the target software using the large language model, the process includes: Step S110: Execute unit test cases and check the code coverage corresponding to the unit test cases; Step S112: Obtain the preset threshold for code coverage; Step S114: If the code coverage is greater than or equal to the preset threshold, then maintain the business application system through unit test cases; Step S116: If the code coverage is less than the preset threshold, update the unit test cases according to the structured call log.

[0059] In this embodiment, incremental enhancement of unit test cases is achieved through code coverage feedback, automatically improving the code coverage of unit test cases. By automating the execution of test cases and quantifying code coverage, the quality shortcomings of the initially generated test cases are objectively assessed. This transforms subjective judgments of test adequacy into objective, automated decision signals based on preset thresholds, enabling precise incremental optimization.

[0060] Specifically, the generated unit test cases are automatically run through the testing framework. An integrated coverage tool collects the line coverage, branch coverage, and exception path coverage of the unit test cases. Line coverage corresponds to the percentage of executed code, branch coverage to the percentage of covered logical branches, and exception path coverage to the percentage of paths where exception handling has been triggered. These three metrics constitute code coverage, and each has its own preset threshold.

[0061] For example, when the row coverage rate is greater than or equal to the preset threshold corresponding to the row coverage rate, it is used to ensure the coverage of the main logic; when the branch coverage rate is greater than or equal to the preset threshold corresponding to the branch coverage rate, it is used to verify critical condition branches; when the abnormal path coverage rate is greater than or equal to the preset threshold corresponding to the abnormal path coverage rate, it is used to provide core fault tolerance capability assurance.

[0062] When the code coverage is greater than or equal to the preset threshold, that is, when the coverage of unit test cases meets the standard, the unit test cases are allowed to enter the subsequent deployment process, and the business application system is maintained through the unit test cases.

[0063] When the code coverage is less than a preset threshold, that is, when the coverage of unit test cases is not up to standard, the self-evolution loop of unit test cases is triggered to update the unit test cases.

[0064] In some embodiments, the coverage type of code coverage may optionally include branch coverage, line coverage, and exception path coverage, and the preset threshold sets differentiated standards according to different coverage types.

[0065] In some embodiments, optionally, a preset threshold is dynamically adjusted based on the complexity of the code, with the core business code using a higher standard preset threshold.

[0066] In some embodiments, optionally, when the coverage does not meet the standard, the uncovered code branches or methods are first identified, and a mapping relationship between the uncovered code and unit test cases is established to accurately locate the missing scenarios.

[0067] In some embodiments, a maximum number of iterations may be set for updating unit test cases to avoid wasting resources due to infinite loops.

[0068] In some embodiments, optionally, after generating unit test cases corresponding to the target software through a large language model, the unit test case generation method further includes: injecting the unit test cases into the continuous delivery and / or continuous deployment pipeline to trigger code coverage detection when the business application system is updated.

[0069] In this embodiment, the generated unit test cases are injected into the continuous delivery and / or continuous deployment (CI / CD) pipeline for execution, and code coverage is collected to automatically update the unit test cases.

[0070] CI / CD is an automated pipeline in modern software engineering. Its core is to achieve code submission, automated building, automated testing, and automated deployment through an automated toolchain. Through CI / CD's configuration-as-code capability, generated unit test cases are dynamically embedded into the project's test directory. Submission management is handled by a version control system. This process is fully automated, requiring no manual intervention, and ensures that unit test cases and business code are updated synchronously.

[0071] CI / CD achieves intelligent triggering through an event listening mechanism. When developers push new code to the source code dataset or create a merge request, the system automatically starts the test pipeline. The pipeline first builds the code and then executes the injected unit test cases. The execution process adopts a distributed architecture, which divides the unit test cases into multiple execution nodes for parallel execution, greatly improving testing efficiency.

[0072] After the test is completed, CI / CD collects test coverage data and compares it with preset thresholds.

[0073] Understandably, in traditional software development, unit testing often requires developers to manually trigger execution, configure the test environment, and analyze test results, a process that typically consumes a significant portion of the development cycle. By automatically injecting unit test cases into the CI / CD pipeline, the testing process is fully automated. Code commits or merge requests trigger the test pipeline to start in real time, and the distributed cluster automatically allocates test tasks, improving the speed of software version delivery and development efficiency.

[0074] In some embodiments, optionally, an intelligent change analysis capability is added to the existing code commit triggering. When code is committed, the scope of code affected by the code change is automatically analyzed, and test cases are generated and executed only for the affected methods or related modules.

[0075] In some embodiments, optionally, such as Figure 3 As shown, the unit test cases are updated based on the structured call logs, including: Step S1160: Obtain existing code from the business application system; Step S1162: Obtain the code coverage detection results of the existing code and identify specific code branches or logical paths that are not covered; Step S1164: Based on specific code branches or logical paths that are not covered, retrieve historical abnormal call information and / or low-frequency parameters from the structured call log; Step S1166: Update the unit test cases using historical exception call information and / or low-frequency parameters to generate targeted patch test cases.

[0076] In this embodiment, a static code analysis engine scans the entire source code dataset, identifying all historical code from the codebase to determine the existing code in the business application system. Static analysis tools are then used to locate specific uncovered code branches (if-else branches not covered) or abnormal logic paths (such as catch blocks or boundary value validation logic).

[0077] Retrieve call records that triggered exceptions from structured call logs to identify historical exception call information, as well as low-frequency parameters with a probability below a set threshold but covering special scenarios.

[0078] When the coverage rate is lower than the preset threshold, the system automatically sends a scenario backtracking request to the log center. The historical abnormal call information and / or low-frequency parameters obtained through the scenario backtracking request are then input back into the large language model, which generates targeted patch test cases.

[0079] Understandably, low-frequency parameters in the production environment often correspond to boundary values ​​or extreme scenarios. By automatically identifying and utilizing these parameters to generate targeted patch test cases, we can cover edge scenarios that are difficult to construct manually and improve the coverage of unit test cases.

[0080] Specifically, a specific code branch refers to an execution path in the code divided by conditional statements, with each branch corresponding to a business scenario. Static code analysis tools map branches to nodes in the control flow graph, and uncovered branches are logical paths that have not been triggered by any test cases.

[0081] A logical path is a sequence of consecutive operations that the code may traverse during execution, including exception handling paths, loop boundary paths, and nested condition combination paths.

[0082] Historical exception call information is a record of exception calls triggered by code errors or boundary conditions in the production environment, including exception type, exception stack, and a snapshot of the parameters that triggered the exception.

[0083] In some embodiments, optionally, such as Figure 4 As shown, after generating unit test cases corresponding to the target software through the large language model, the unit test case generation method also includes: Step S118: Store unit test cases in the test asset library and establish a monitoring association between unit test cases and the source code of the target software; Step S120: Continuously monitor whether the source code has changed; Step S122: When the source code changes, trigger the generation of updated unit test cases; Step S124: Obtain the method meta-information of the modified source code, and input the modified source code's method meta-information and related structured call logs into the large language model to generate updated test cases synchronized with the code version.

[0084] This embodiment aims to address the unavoidable test corruption problem in software iteration, where existing unit test cases become invalid, outdated, or uncompilable after source code modifications, thus losing their protective function. By establishing an automatic detection and update mechanism, it ensures that unit test cases are always synchronized with the code logic.

[0085] Specifically, the unit test cases successfully generated from the large language model are saved in a structured test asset repository. Each unit test case in the test asset repository is stored as a record with rich metadata. This metadata includes, but is not limited to: the unique identifier of the unit test case, the full path of the associated source code file, the signature of the specific method being tested, the source code version number corresponding to the generation of the unit test case, the business scenario tags covered by the unit test case, and the real business parameter samples referenced when generating the unit test case.

[0086] The test case logs allow you to view the source code and methods associated with the unit test cases.

[0087] When code is committed to the repository, the system retrieves a list of files modified and their specific differences. In the development environment, it listens for file modification events in the source code directory. When a change is detected in the source code, it triggers the generation and updating of unit test cases.

[0088] Changes that require an update include: method signature changes and / or business logic changes. For example, adding, deleting, or modifying method parameters, changing the method's return type, or adding conditional branches, logical loops, or modifying existing calculation logic within the method body.

[0089] Obtain the latest version of the source code, retrieve the real call parameter records related to specific methods from historical traffic data collected from the production environment, and scan and parse the latest version of the source code using static code analysis techniques to extract key structured information, namely method meta-information.

[0090] The method meta-information and structured call logs are input into the large language model. Based on the instructions, the large language model outputs a new update test case corresponding to the latest code version. The test logic of the update test case is consistent with the source code logic of the latest version.

[0091] Furthermore, before and after storing the asset in the asset repository, the system usually automatically executes the newly generated test cases for rapid verification, ensuring that they can be compiled and run correctly, thus forming a complete closed loop from monitoring, triggering, generation to verification.

[0092] Understandably, by establishing monitoring relationships, detecting code changes, intelligently judging and driving large models to perform precise incremental updates, the real-time synchronization of test cases and source code is ultimately achieved, which greatly reduces test maintenance costs, eradicates test corruption, and provides a solid foundation for rapid and reliable software iteration.

[0093] In some embodiments, optionally, an update strategy can be intelligently selected based on the type and scale of the source code change, rather than always invoking the large model. For example, only local variable names within a method may be modified, and the variable names in unit test cases can be directly updated through automated refactoring tools to improve the update speed of unit test cases and reduce costs.

[0094] In some embodiments, optionally, when a simple null value check is added to the source code, a test branch can be automatically completed based on the template.

[0095] In some embodiments, optionally, when a significant change occurs in the detection method logic, the large language model is invoked for deep understanding and regeneration.

[0096] In some embodiments, optionally, a change preview report is generated and sent to developers or testers before automatically merging newly generated updated test cases. The report clearly shows which code changes have occurred and which parts of the test cases have been updated accordingly (e.g., which test branches have been added and which assertions have been modified). The test cases can only be merged into the asset repository after being reviewed and approved by the relevant personnel.

[0097] In some embodiments, the environmental parameters may optionally include at least the input parameters, output parameters, and exception parameters corresponding to the business application system.

[0098] In this embodiment, input parameters refer to the actual input data passed to the monitored software method in a specific business request in the production environment. Output parameters refer to the result data that the monitored method normally returns to the caller after processing the input parameters. Exception parameters refer to the complete error information when the method throws an exception during execution due to various reasons (such as business logic errors, data validation failures, system exceptions, etc.).

[0099] The input parameters, output parameters, and exception parameters combine to form a complete set of environment parameters. These parameters record the actual production traffic of a call from its start (input parameters) to its normal completion (output parameters) or abnormal failure (exception parameters). This provides the large language model with all the contextual information needed to understand method behavior.

[0100] For example, the input parameters include basic type parameters, complex object parameters, and context parameters. Basic type parameters include integers, floating-point numbers, booleans, strings, etc.; complex object parameters include custom Java objects, etc.; context parameters include implicit context information, such as the current session ID and locale, injected through the method's thread layout variables or specific annotations. The input parameters are obtained by intercepting and serializing the method before execution using AOP aspect-oriented programming techniques.

[0101] Exemplarily, the output parameters include a return value object and a return status. The return value object includes the return result of the method, and the return status reflects the status information carried by the return value itself. By verifying the output parameters, the unit test case can confirm whether the business calculation and logic processing logic of the method meet the expectations. The output parameters are obtained by intercepting and serializing the return value after the method returns normally through the AOP aspect technology.

[0102] Exemplarily, the exception parameters include the exception type, exception message, exception stack trace, and a snapshot of the input parameters when the exception occurs, etc. They are captured through the exception notification of AOP technology.

[0103] In a specific embodiment, optionally, a schematic diagram of the running logic of a unit test case generation method is as Figure 8 shown: Dual-source data collection: In the production environment, the input parameters, output parameters, and exception stack of method calls in the production environment are collected in real time through the aspects of aspect-oriented programming (AOP) to form structured call logs; in the source code repository, the source code is scanned by a code parsing engine to extract meta-information such as method signatures, dependency relationships, exception throwing points, and branch logics to form method meta-information.

[0104] Based on the large model's context understanding and code analysis capabilities, realize the two-way drive of production traffic and engineering code.

[0105] Large model collaborative generation (including the "dual-anchored context" mechanism): The source code snippet of the target method and its corresponding historical call parameters (from production logs), that is, the structured call logs and method meta-information, are jointly used as the context to input into the large language model to achieve "dual-anchored constraints". Code anchoring: The source code provides syntax structure and logical constraints to ensure the correctness of the generation logic; data anchoring: The real parameters provide a legal input range and business combination to suppress the model from "fabricating" illegal values. Adopt the "real scenario first" strategy to guide the model to generate multi-scenario test cases covering normal flow, boundary values, and exception branches, that is, generate initial test cases.

[0106] For example, "Please generate tests for the User Service.update User method, using the following real parameters: {id: 1001, name: 'Zhang San', email: 'zhangsan@company.com'}, and cover the exception branch that throws an Illegal Argument Exception when user.status == null".

[0107] During the generation process, the model needs to understand the business constraints between parameters (such as "the order amount cannot be negative") and automatically construct legal / illegal input combinations.

[0108] Closed-loop verification and feedback-driven completion: The generated test cases are injected into the Continuous Integration / Continuous Deployment (CI / CD) pipeline for execution, and code coverage (such as branch coverage and line coverage) is collected.

[0109] When the coverage rate is lower than the preset threshold (i.e., the coverage detection fails), the system automatically sends a "scenario backtracking request" to the log center to retrieve historical abnormal calls and low-frequency parameter combinations; the newly acquired parameters are then input into the large model again to generate targeted patch test cases, thereby achieving progressive enhancement of the test cases.

[0110] When the coverage rate exceeds a preset threshold (i.e., the coverage detection meets the standard), the test cases are stored in the test asset library, and it is determined whether the code of the test cases has changed. If the code of the test cases has not changed, the test cases are continuously monitored; if the code of the test cases has changed, the initial test cases are regenerated to ensure that the test cases and the code are updated in sync.

[0111] Among them, a self-evolving closed loop for unit test case generation is formed through large-scale model collaborative generation, initial test case generation, continuous integration and continuous deployment execution, coverage detection, and initiation of scenario backtracking requests.

[0112] By testing the asset library and continuously monitoring code changes to test cases, the output and feedback of the unit test case generation method are formed.

[0113] Understandably, the unit test case generation method achieves a triple drive of "production traffic + large model + feedback loop", breaking through the limitations of traditional rule engines and improving the runnability of generated test cases.

[0114] In some embodiments, optionally, such as Figure 7 As shown, the unit test case generation method includes: Step S200: Business application system runs; Step S202: The logging tool intercepts parameters; Step S204: Logs are recorded in the business log center, including request parameters, input parameters, etc. Step S206: Request the system to pull logs using parameters, and obtain the specified call logs through the interface; Step S208: Use a graphical user interface tool to scan the source code in batches and synchronously obtain the actual call parameters or scenarios; Step S210: Submit the large model to generate unit test cases / simulation data parameters and code; Step S212: Adjust and run the test cases.

[0115] Specifically, the business application system refers to the real software system that is providing services to users in the production environment. Key information about the real software system's runtime is intercepted non-intrusively through technical means (such as AOP aspects and proxies), namely, real-time collection of input parameters, output parameters, and exception stacks of method calls in the production environment. The monitored or intercepted real-time data is then formatted, transmitted, and stored in a centralized business log center, recording request parameters, input parameters, etc., forming a queryable historical record.

[0116] The parameter request system will proactively retrieve relevant call logs from the business log center on demand (e.g., based on the specified class name and method name).

[0117] The graphical user interface (GUI) tool batch scans, compiles, and parses source code, while simultaneously acquiring and synchronizing real-world call scenario data from call logs. It scans the source code using a code parsing engine and combines this data with dynamic source data.

[0118] The prepared parameters (real call data) and code (source code information) are handed over to the large model, which then generates unit test cases and / or the required simulation data based on the context information.

[0119] The generated unit test cases can be reviewed and fine-tuned by developers before being put into operation.

[0120] Understandably, by acquiring real traffic data, we can drive the generation of test cases from large models, significantly improving the coverage and realism of unit tests, while strictly controlling environment isolation and technical debt cleanup, which complies with enterprise development standards.

[0121] Furthermore, by automatically triggering historical parameter backtracking and completion generation through coverage feedback, test cases can be self-evolved, improving coverage and continuously increasing it; by capturing online abnormal calls and replaying them as test cases, the online failure rate caused by untested abnormal paths is reduced; test cases are automatically updated as business evolves, avoiding "test corruption" and reducing maintenance costs.

[0122] like Figure 5As shown in the illustration, this application embodiment also provides a unit test case generation device 900, which includes: a dynamic acquisition module 902, used to acquire structured call logs during the operation of a business application system. The structured call logs are acquired in real time from the business application system using aspect-oriented programming technology, and the structured call logs include at least one environment parameter of the target software; a static acquisition module 904, used to acquire the source code dataset of the target software and the method meta-information corresponding to the source code dataset; a data transmission module 906, used to input the environment parameters and method meta-information as input sources into a large language model; and a test generation module 908, used to generate unit test cases corresponding to the target software through the large language model, whereby the unit test cases cover at least one production environment.

[0123] The unit test case generation device 900 provided by this invention implements a unit test case generation method. Through an aspect-oriented programming (AOP) system, it automatically collects real request parameters from the production environment, automatically generating mock data without the need for R&D or testing personnel, thus reducing data construction work. Combining the powerful context understanding and code recognition capabilities of a large-scale model, business code and corresponding real business parameters are transmitted to the large-scale model. This allows for batch generation of unit test cases from existing code, significantly improving the efficiency of unit test case generation. Furthermore, by capturing business parameters from various scenarios through real traffic, the test cases generated by the large-scale model can cover these complex situations, ensuring that the generated test cases cover real business scenarios.

[0124] like Figure 6 As shown, this application embodiment also provides an electronic device 1000, including a processor 1110, a memory 1109, and a program or instructions stored in the memory 1109 and executable on the processor 1110. When the program or instructions are executed by the processor 1110, they implement the various processes of the above-described unit test case generation method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0125] Optionally, the processor 1110 is used to acquire structured call logs during the operation of the business application system. The structured call logs are collected from the business application system in real time through aspect-oriented programming technology. The structured call logs include at least one environmental parameter of the target software. Optionally, the processor 1110 is also configured to acquire the source code dataset of the target software and the method meta-information corresponding to the source code dataset; Optionally, the processor 1110 is also used to input environmental parameters and method meta-information as input sources into a large language model; Optionally, the processor 1110 is also configured to generate unit test cases corresponding to the target software using a large language model, the unit test cases being used to cover at least one production environment.

[0126] The memory 1109 can be used to store software programs and various data. The memory 1109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 1109 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 1109 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0127] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described unit test case generation method embodiments and achieve the same technical effects. To avoid repetition, these will not be described again here. Furthermore, the readable storage medium improves the data storage capacity and data processing speed of the unit test case generation method in this application.

[0128] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital universal disk (DVD), memory cards, floppy disks, encoding mechanical devices (e.g., punched cards or grooves with raised structures for recording instructions), and any suitable combination of the foregoing. The computer-readable storage medium used herein should not be construed as the transmission of signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media, or electrical signals transmitted through wires.

[0129] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0130] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described unit test case generation method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here. In addition, the chip improves the data processing speed corresponding to the unit test case generation method in this application.

[0131] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0132] In this invention, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance; the term "multiple" refers to two or more unless otherwise explicitly defined. The terms "install," "connect," "link," and "fix" should be interpreted broadly. For example, "connect" can be a fixed connection, a detachable connection, or an integral connection; "link" can be a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0133] In the description of this invention, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or unit referred to must have a specific orientation or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0134] In the description of this specification, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to specific features, structures, materials, or characteristics described in connection with an embodiment or example that are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0135] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating unit test cases, characterized in that, include: The structured call logs during the operation of the business application system are obtained. The structured call logs are collected from the business application system in real time through aspect-oriented programming technology. The structured call logs include at least one environmental parameter of the target software. Obtain the source code dataset of the target software and the method metadata corresponding to the source code dataset; The environmental parameters and the method meta-information are used as input sources and input into the large language model. Unit test cases corresponding to the target software are generated using the large language model, and the unit test cases are used to cover at least one production environment.

2. The unit test case generation method according to claim 1, characterized in that, After generating unit test cases corresponding to the target software using the large language model, the process includes: Execute the unit test cases and check the code coverage corresponding to the unit test cases; Obtain the preset threshold for the code coverage; If the code coverage is greater than or equal to the preset threshold, the business application system is maintained through the unit test cases; If the code coverage is less than the preset threshold, the unit test cases are updated according to the structured call log.

3. The unit test case generation method according to claim 2, characterized in that, After generating unit test cases corresponding to the target software using the large language model, the method further includes: The unit test cases are injected into the continuous delivery and / or continuous deployment pipeline for execution, so as to trigger the code coverage detection when the business application system is updated.

4. The unit test case generation method according to claim 2, characterized in that, The step of updating the unit test cases based on the structured call log includes: Obtain the existing code in the business application system; Obtain the code coverage detection results of the existing code and identify specific code branches or logical paths that are not covered. Based on the uncovered specific code branch or logical path, retrieve historical abnormal call information and / or low-frequency parameters from the structured call log; The unit test cases are updated using the historical abnormal call information and / or low-frequency parameters to generate targeted patch test cases.

5. The unit test case generation method according to claim 1, characterized in that, After generating unit test cases corresponding to the target software using the large language model, the process further includes: The unit test cases are stored in the test asset library, and a monitoring association is established between the unit test cases and the source code of the target software. Continuously monitor whether the source code has been changed; When the source code changes, the generation of updated unit test cases is triggered. By obtaining the method meta-information of the modified source code and inputting the modified source code method meta-information and related structured call logs into the large language model, updated test cases synchronized with the code version are generated.

6. The unit test case generation method according to any one of claims 1 to 5, characterized in that, The environmental parameters include at least the input parameters, output parameters, and abnormal parameters corresponding to the business application system.

7. A unit test case generation device, characterized in that, include: A dynamic acquisition module is used to acquire structured call logs during the operation of a business application system. The structured call logs are acquired in real time from the business application system using aspect-oriented programming technology. The structured call logs include at least one environmental parameter of the target software. A static data acquisition module is used to acquire the source code dataset of the target software and the method metadata corresponding to the source code dataset; The data transmission module is used to input the environmental parameters and the method meta-information as input sources into the large language model; A test generation module is used to generate unit test cases corresponding to the target software through the large language model, and the unit test cases are used to cover at least one production environment.

8. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the unit test case generation method as described in any one of claims 1 to 6.

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

10. A chip, characterized in that, The chip includes a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the unit test case generation method as described in any one of claims 1 to 6.

Images