Test case generation method and related device

Abstract

A test case generation method. The method comprises: acquiring an object under test, said object being software under test or a code snippet within said software; performing software analysis on said object to obtain engineering dependency information and context of said object, the context comprising at least one of a file-level context or a project-level context; then generating a test header of a test case of said object on the basis of the engineering dependency information and the context, the test header being an initial part of the test case, and the initial part comprising information other than a test method; next, performing continuation writing on the test header of the test case by means of a language model to obtain the test case; and presenting the test case to a user. In the method, by combining software analysis and prompt engineering, a test header is provided for a language model to generate a test case, and continuation writing is performed on the test header by means of the language model instead of generating a test case by the language model from scratch, thereby improving the quality and effectiveness of test cases generated by the language model.

Description

A test case generation method and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202411509005.7, filed with the State Intellectual Property Office of China on October 25, 2024, entitled "A Test Case Generation Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of software testing technology, and in particular to a test case generation method, a test platform, a computing device cluster, a computer-readable storage medium, and a computer program product. Background Technology

[0003] To ensure the correctness of a software system (or software program), test cases are typically used to test it. For example, during software system development, developers can use unit test (UT) test cases while writing code to perform unit tests, ensuring the effectiveness of the software system. Since manually writing test cases requires significant effort and expert knowledge, automated test case generation technology has become a key research area in recent years.

[0004] In recent years, with the continuous development of deep learning (DL), more and more research has begun to focus on using pre-trained large language models (LLMs) for test case generation tasks. For example, some intelligent programming tools utilize the superior coding capabilities of generative pre-trained transform models (GPTs) to drive the generation of test cases through design prompts. Test cases generated based on LLMs have high readability and maintainability, are relatively close to test cases written by developers, and also possess a certain degree of effectiveness.

[0005] However, test cases generated based on LLM cannot guarantee correctness, which greatly affects the quality of test cases. Summary of the Invention

[0006] This application provides a test case generation method. This method generates test case headers using software analysis, and then continues writing the test headers using a language model. This solves the problem of generating incorrect test headers during the language model's test case generation process, improving the quality and effectiveness of the test cases generated by the language model. This application also provides a corresponding test platform, computing device cluster, computer-readable storage medium, and computer program product.

[0007] Firstly, this application provides a test case generation method. This method can be executed by a testing platform. The testing platform, also known as a testing system, can be used to generate test cases. In some examples, the testing platform can be a software system used to generate test cases to test the software under test. This software system can be a standalone software system, such as a standalone software testing tool or suite. The standalone software system can include a general-purpose software system for different users, or a customized software system provided for specific user needs. Alternatively, the software system can be integrated into other software as a functional module, plugin, extension, component, or applet. For example, the software system can be integrated into an Integrated Development Environment (IDE) as a plugin, allowing developers to directly use the plugin's functionality within the IDE. In other examples, the testing platform can also be a hardware system. The hardware system can be a cluster of computing devices with test case generation capabilities; when the computing device cluster runs, it executes the test case generation method of this application.

[0008] Specifically, the testing platform acquires the object under test, which is the software under test or a code snippet within it. It then performs software analysis on the object under test to obtain its project dependency information and context. The context includes at least one of file-level or project-level contexts. Based on the project dependency information and context, the testing platform generates test headers for test cases of the object under test. These test cases are used to test the object under test, and the test headers are the initial part of the test cases, including information other than the test methods. The testing platform then uses a language model to further refine the test headers, obtaining the test cases themselves, and presents these test cases to the user.

[0009] This method combines software analysis (e.g., static analysis) and hint engineering to provide test headers for generating test cases from the language model. Instead of the language model generating test cases from scratch, it continues writing the test headers through the language model. This allows the software analysis results to intervene in the decoding process of test case generation from the language model, providing constraints on the generated results and resolving the problem of generating incorrect test headers, thus improving the quality and effectiveness of the generated test cases. Furthermore, this method eliminates the need for iterative test case repair, improving the efficiency of test case generation.

[0010] In some possible implementations, the testing platform can query a template library for test header templates that match the project dependency information, populate the context into the test header templates, and obtain the test headers for the test cases of the object under test. This method, by querying test header templates that match the project dependency information and then populating them with the context obtained from software analysis, can fully leverage the high accuracy and coverage of software analysis, improving the accuracy and effectiveness of test headers, and consequently improving the accuracy and effectiveness of test cases written based on these test headers. Furthermore, this method eliminates the need for language model inference to generate test headers, reducing the number of tokens that the language model needs to infer, improving the efficiency of test case generation, and enhancing overall performance.

[0011] In some possible implementations, the testing platform can determine the project dependency information of the object under test (AUT) from the AUT's project build files through project structure analysis. Project dependency information includes at least one of a test framework or a simulation framework. The testing platform can also obtain at least one of the file-level context or project-level context of the AUT through static analysis. The file-level context includes at least one of dependency import information, variable information, function information, and class constructors; the project-level context includes function call information. Specifically, dependency import information can include dependency import statements of the class containing the AUT; variable information can include variable information of the class containing the AUT (also called the class under test); variable information includes at least one of variable name, variable type, scope, or initial value; function information includes function information of functions in the class containing the AUT, such as function information of other functions in the class besides the function under test; function information can include at least one of function name, parameter information (e.g., a parameter list of input parameters), return value (e.g., return value name, return value type), or scope. Function call information can be function information of external functions called by the AUT.

[0012] This method obtains the test framework and simulation framework of the object under test through engineering structure analysis. Based on the test framework and simulation framework, a test header template corresponding to the task can be matched. Furthermore, dependency import information, variable information, function information, class constructor or function call information are obtained through static analysis. Filling the test header template with the above information can produce a test header with a high accuracy rate, solving the problem of incorrect test headers caused by model "illusion".

[0013] In some possible implementations, function call information includes function information of external functions called by the object under test, and variable information includes variable information of member variables of the class containing the object under test. Accordingly, the testing platform can analyze the external functions based on their function information to obtain the class signature of the declaration class of the external functions called by the object under test. This class signature is then filled into the test class annotation template in the test header template that matches the project dependency information to obtain the test class signature. The testing platform fills the variable information of the member variables of the class containing the object under test into the public variable template in the test header template to obtain the definition of the public variables. Finally, it fills the function information and / or class constructor from the file-level context into the public method template to obtain the definition of the public methods.

[0014] This method constructs test class signatures, public variables, and public methods based on the context obtained from software analysis, which can generate test headers with high accuracy, laying the foundation for improving the quality and effectiveness of test cases.

[0015] In some possible implementations, the testing platform can also extract the identifier of the index class from the populated template, where the index class is the declared class in the populated template. Then, based on the index class identifier, the testing platform looks up the classpath of the index class, and subsequently constructs the dependency import statement based on the classpath of the index class.

[0016] This method improves the completeness of the test header by extracting the identifier of the index class from the populated template, finding the classpath, and constructing dependency import statements based on the classpath. This avoids compilation or execution failures due to missing dependency import statements.

[0017] In some possible implementations, the testing platform can construct question prompts based on the context, construct answer prompts based on the test header, pre-fill the question prompts using a language model, and decode the answer prompts using a language model to continue writing test cases from the test header.

[0018] The compilation issues of test cases are usually concentrated in the test class initialization process. This application expands the scope of the prompts to the response part of the language model, introducing the concept of response prompts to intervene in the decoding process of the language model. This allows the language model to continue writing based on the correct test headers provided to the language model until the entire test class is completed, instead of the language model directly generating a complete test class itself. Here, the test class is the class containing the test cases, and a test class can include one or more test cases.

[0019] In some possible implementations, the object under test is either the function under test or the class under test. The class under test may include one or more functions, and the implementation methods for generating test cases for the class under test can refer to those for generating test cases for the function under test.

[0020] This method can generate highly accurate test cases for the function or class under test, ensuring high availability. Furthermore, it addresses the uncertainty of "execution-feedback" test case repair schemes, generating highly accurate test cases without repeated iterations, thus improving performance. In addition, by generating highly accurate test cases, this method can improve test coverage.

[0021] Secondly, this application provides a testing platform. The testing platform includes:

[0022] The software analysis module is used to acquire the object under test, which is the software under test or a code segment in the software under test; to perform software analysis on the object under test to obtain the project dependency information and context of the object under test, wherein the context includes at least one of file-level context or project-level context;

[0023] The test header generation module is used to generate test headers for test cases of the object under test based on the project dependency information and the context. The test header is the initial part of the test case, and the initial part includes information other than the test method.

[0024] The test case generation module is used to continue writing the test header of the test case through a language model to obtain the test case, which is used to test the object under test.

[0025] The interaction module is used to present the test cases to the user.

[0026] In some possible implementations, the test header generation module is specifically used for:

[0027] Based on the project dependency information, query the template library for a test header template that matches the project dependency information;

[0028] The context is populated into the test header template to obtain the test header of the test cases for the object under test.

[0029] In some possible implementations, the software analysis module is specifically used for:

[0030] Through engineering structure analysis, the engineering dependency information of the tested object is determined from the engineering construction file of the software under test. The engineering dependency information includes at least one of a test framework or a simulation framework.

[0031] Through static analysis, at least one of the file-level context or the project-level context of the object under test is obtained. The file-level context includes at least one of dependency import information, variable information, function information, and class constructor. The project-level context includes function call information.

[0032] In some possible implementations, the function call information includes function information of external functions called by the object under test, the variable information includes variable information of member variables of the class containing the object under test, and the test header generation module is specifically used for:

[0033] Analyze the external function called by the object under test based on the function information of the external function, obtain the class signature of the declaration class of the external function called by the object under test, and fill the class signature of the declaration class into the test class annotation template in the test header template that matches the project dependency information to obtain the test class signature.

[0034] The variable information of the member variables of the class to which the object under test belongs is filled into the public variable template in the test header template to obtain the definition of the public variable;

[0035] The function information and / or class constructor from the file-level context are populated into the public method template to obtain the definition of the public method.

[0036] In some possible implementations, the test header generation module is also used for:

[0037] Extract the identifier of the index class from the populated template, where the index class is the declaration class in the populated template;

[0038] Based on the identifier of the index class, find the class path of the index class;

[0039] Construct a dependency import statement based on the classpath of the index class.

[0040] In some possible implementations, the test case generation module is specifically used for:

[0041] Construct question prompts based on the context, and construct answer prompts based on the test header;

[0042] Based on the problem prompts, pre-filling is performed using a language model;

[0043] Based on the answer prompts, the language model is used for decoding to continue writing the test header and obtain the test cases.

[0044] In some possible implementations, the object under test is the function under test or the class under test.

[0045] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, which includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory to cause the computing device or the computing device cluster to perform the test case generation method as described in the first aspect or any implementation thereof.

[0046] Fourthly, this application provides a computer-readable storage medium storing instructions that instruct a computing device or a cluster of computing devices to execute the test case generation method described in the first aspect or any implementation thereof.

[0047] Fifthly, this application provides a computer program product containing instructions that, when run on a computing device or a cluster of computing devices, causes the computing device or cluster of computing devices to execute the test case generation method described in the first aspect or any implementation thereof.

[0048] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0049] To more clearly illustrate the technical methods of this application, the accompanying drawings used will be briefly described below.

[0050] Figure 1 is a flowchart illustrating a test case repair scheme based on "execution-feedback" provided in this application;

[0051] Figure 2 is a schematic diagram of the architecture of a test platform provided in this application;

[0052] Figure 3 is a schematic diagram of an interface for generating test cases for the function under test provided in this application;

[0053] Figure 4 is a flowchart of a test case generation method provided in this application;

[0054] Figure 5 is a schematic diagram of a test class signature construction process provided in this application;

[0055] Figure 6 is a flowchart illustrating the construction of a public variable and a public method provided in this application;

[0056] Figure 7 is a flowchart illustrating a method for constructing a dependency import statement according to this application;

[0057] Figure 8 is a schematic diagram of a writing continuation method based on question prompts and answer prompts provided in this application;

[0058] Figure 9 is a schematic diagram of the structure of a computing device provided in this application;

[0059] Figure 10 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0060] Figure 11 is a schematic diagram of another computing device cluster provided in this application;

[0061] Figure 12 is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0062] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0063] First, some technical terms involved in the embodiments of this application will be introduced.

[0064] Software testing is the process of operating software programs under specified conditions to discover errors, measure software quality, and evaluate whether the software meets design requirements. Software testing can be categorized by granularity into unit testing, integration testing, and system testing. Unit testing tests software components (or simply units) to verify their correctness. The test object is the smallest unit of software design, such as a function. Integration testing, also known as synthesis testing, assembly testing, or joint testing, involves assembling program modules using appropriate integration strategies and testing the correctness of the system's interfaces and integrated functionality. The main purpose of integration testing is to check the correctness of the interfaces between software units. The test object can be a module or unit that has already undergone unit testing.

[0065] A test case (TC) is a set of test inputs, execution conditions, and expected results designed for a specific objective, used to verify whether the software under test meets a specific software requirement. The code for a test case, also called test case code, can be written according to the testing requirements of the software under test. The following example illustrates testing an addition function: `def test_addition(): assert addition(2, 3) == 5; assert addition(-1, 1) == 0; assert addition(0, 0) == 0; assert addition(99999, 1) == 100000;`

[0066] In the example above, multiple test cases are encapsulated into a test function named `test_addition()`. Each test case calls the function `addition()` and uses the `assert` statement to verify that the function's return value equals the expected value. If a test case fails, the `assert` statement can throw an `AssertionError` exception.

[0067] Since manually writing test cases requires significant effort and expert knowledge, automated test case generation technology has become a key research focus in recent years. With the continuous development of deep learning, more and more research is focusing on using pre-trained large language models (LLMs) for test case generation. LLMs, often simply referred to as large models, are typically based on transformer structures. A transformer is a deep learning model that employs an attention mechanism, assigning different weights based on the importance of different parts of the input data. Typical examples of LLMs include Generative Pre-trained Transformer (GPT) models or Bidirectional and Auto-Regressive Transformers (BART) models. Some intelligent programming tools use BART models to translate the "function under test" into unit test cases, while others leverage GPT's powerful coding capabilities by designing prompts (or hints / words) to drive GPT in generating test cases. Test cases generated based on LLM have high readability and maintainability, are similar to test cases written by developers, and have a certain degree of effectiveness.

[0068] However, LLM is trained on large amounts of data. It learns statistical patterns or regularities from the data to generate output. When LLM encounters new input, it may generate content related to the input but not entirely based on it, often referred to as "illusions," based on the learned patterns or regularities. In test case generation scenarios, LLM might generate non-existent function or class names. A class is a cohesive package composed of specific metadata; a class definition can include a class declaration and a class body. The class body can include member variable declarations, constructor declarations, member method declarations, and initialization blocks. Member methods can also be called member functions. This compromises the accuracy of the generated test cases, significantly impacting their quality.

[0069] To address this, the industry has proposed a test case repair scheme based on "execution-feedback". Due to the widespread illusion problem in large models, the generated test cases may fail to compile or execute. However, during the compilation or execution process, when errors occur, error information or error reports can be output, such as outputting the call stack or exception message. Based on this, the code capabilities of large models can be used to automatically repair errors in test cases in combination with error information to improve the quality of generated test cases. As shown in Figure 1, the test case repair scheme based on "execution-feedback" includes the following key steps: (1) calling a large model (such as LLM) to generate test cases; (2) executing the test cases and collecting the execution results; (3) feeding the error report back to the large model, using the large model to repair the problems in the test cases, and repeating step (2) until the correct test cases are obtained.

[0070] While "execution-feedback"-based test case repair solutions have made some progress in improving the correctness of test cases, they cannot guarantee that the iterative process will produce the expected results. For example, when calling a large model to repair errors in a test case, there is no guarantee that the large model's repair of the test case will be accurate this time. This can lead to a large number of iterations, or even multiple iterations without meeting the requirements. This poses a significant challenge to the time efficiency of generating test cases from large models, and introduces considerable uncertainty. How to efficiently generate correct test cases has become a key focus in the industry.

[0071] In view of this, this application provides a test case generation method. This method can be applied to a testing platform. The testing platform is used to generate test cases. The testing platform can be a software system used to generate test cases to test the software under test. This software system can be an independent software system, such as an independent software testing tool or suite. The independent software system can include a software system general to different users, or a customized software system provided for specific user needs. Alternatively, the software system can be integrated into other software as functional modules, plugins, extensions, components, or applets. For example, the software system can be integrated into an Integrated Development Environment (IDE) as a plugin, allowing developers to directly use the plugin's functionality within the IDE.

[0072] It should be noted that the software system can be an application or a command-line tool, which users can install and use locally. Applications or command-line tools can be provided with perpetual licenses or periodic subscriptions. In some examples, the software system can also be provided to users in the form of cloud services or application programming interface (API) services. Specifically, the cloud platform can provide online cloud services where users can upload code or provide code repository addresses, and the cloud service automatically analyzes and generates test cases. Cloud services can be charged on a usage-based or subscription basis. API services can be RESTful APIs, which follow the Representational State Transfer (REST) ​​style, allowing other development tools or Continuous Integration / Continuous Deployment (CI / CD) systems to integrate the functionality of this application. API services can be charged per API call. In some examples, the testing platform can also be a hardware system. The hardware system can be a cluster of computing devices with test case generation capabilities; when the computing device cluster runs, it executes the test case generation method of this application.

[0073] Specifically, the testing platform can obtain the object under test, which is the software under test or a code snippet within it, such as a function or class under test. The testing platform can then perform software analysis on the object under test to obtain its project dependency information and context. This context includes at least one of file-level or project-level contexts. Based on the project dependency information and context, the testing platform can generate test headers for the test cases of the object under test. The test header is the initial part of the test case, including information other than the test methods. For example, the test header can be a Test Class Initialization Header, which can be the portion of a test class in an object-oriented programming (OOP) language or a language containing OOP elements, excluding dependency imports (or dependency import information), annotations (if any), test class declarations, public methods, and public variables. The test class can be the class containing the test cases. The testing platform can continue writing the test headers of the test cases using a language model to obtain the test cases, which are used to test the object under test and then presented to the user.

[0074] This method combines software analysis (e.g., static analysis) and hint engineering to provide test headers for generating test cases from the language model. Instead of the language model generating test cases from scratch, it uses the results of software analysis to intervene in the decoding process of test case generation, providing constraints on the generated results. This addresses the problem of generating incorrect test headers during the language model's test case generation process, improving the quality and effectiveness of the generated test cases. Furthermore, this method eliminates the need for iterative test case repair, thus increasing the efficiency of test case generation.

[0075] To make the technical solution of this application clearer and easier to understand, the system architecture of the test platform of this application will be described below with reference to the accompanying drawings.

[0076] Referring to Figure 2, which shows a schematic diagram of the architecture of a testing platform, the testing platform 20 includes a software analysis module 202, a test header generation module 204, a test case generation module 206, and an interaction module 208. The test header generation module 204 can also be called the initialization code generation module, and the test case generation module 206 can be a model integration module used to interface with the API of language models such as LLM to generate test cases for continuation writing mode. The functions of each module are described in detail below.

[0077] The software analysis module 202 is used to acquire the object under test, which is the software under test or code fragments within the software under test. Then, software analysis is performed on the object under test to obtain its project dependency information and context. This software analysis can include static analysis or dynamic analysis; for ease of description, this application uses static analysis as an example. Static analysis, also known as static program analysis or static code analysis, refers to a method of program analysis performed without running the program.

[0078] Project dependency information may include information about the frameworks that the software project depends on. This framework information may include the framework name, and further, the framework version number. The framework may include at least one of a testing framework or a mocking framework. Taking Java as an example, the testing framework may include, but is not limited to, JUnit4 / JUnit5, and the mocking framework may include, but is not limited to, PowerMock and Mockito.

[0079] The context includes at least one of file-level or project-level contexts. In some possible implementations, a file-level context includes at least one of dependency import information, variable information, function information, and class constructors. Dependency import information can be dependency import statements in the class containing the object under test (in some cases, simply referred to as the class under test). Variable information includes member variables of the class containing the object under test. Function information includes function information of functions in the class containing the object under test. Class constructors include class constructors in the class containing the object under test. A project-level context includes function call information. Function call information can include function information of external functions (or simply called functions) called by the object under test. This function information can include at least one of the following: function name, parameter information, return value, or scope.

[0080] The test header generation module 204 generates test headers for test cases of the object under test based on project dependency information and context. The test header is the initial part of the test case, including information other than the test methods. For example, the test header can be an initialization header for the test class, including the parts of the test class in OOP language or a language containing OOP elements, excluding dependency imports, annotations, test class declarations, public methods, and public variables of the test methods. It should be noted that test cases may also exclude annotations; correspondingly, the test header can include the parts of the test class in OOP language or a language containing OOP elements, excluding dependency imports, test class declarations, public methods, and public variables of the test methods.

[0081] The test case generation module 206 is used to continue writing the test header of the test cases using the language model to obtain the test cases. The test cases are used to test the object under test. The language model can be a large language model such as GPT. In specific implementation, the test case generation module 206 can assemble the test header into the prompt, interfering with the decoding process of the language model in generating test cases, so that the language model no longer generates test cases from scratch, but instead generates test cases based on the test header.

[0082] The interaction module 208 is used to present test cases to the user. Specifically, the interaction module 208 can present test cases to the user through a user interface (UI). The user interface can include, but is not limited to, a graphical user interface (GUI) or a command user interface (CUI). Figure 3 illustrates the generation of test cases using an IDE plugin and the presentation of test cases to the user through a GUI. In this example, the object under test is the function under test, and the test platform 20 generates unit test test cases for the function under test. As shown in Figure 3, the test platform 20 displays the user-selected function under test 302 on the interaction interface 300. In this example, the function name of function under test 302 is addToList. The user can trigger the task of generating unit test test cases. The test platform 20 can obtain function under test 302, perform software analysis on function under test 302, generate test case headers based on the project dependency information and context of the object under test obtained from the software analysis, and then call LLM to continue writing the test headers, thereby generating test case 304.

[0083] In some possible implementations, the interaction module 208 also supports user-configured parameters or editing of test cases generated by the language model. The user-configured parameters may include, but are not limited to, software analysis algorithms and the target coverage of the test cases. The target coverage can be the desired coverage level.

[0084] Based on the test platform 20 shown in Figure 2, this application also provides a test case generation method. The test case generation method of this application will be described in detail below with reference to the accompanying drawings.

[0085] Referring to Figure 4, a flowchart of a test case generation method is shown. This method can be applied to test platform 20 and includes the following steps:

[0086] S402, Test platform 20 obtains the object under test.

[0087] The object under test is the software under test or a code segment within the software under test. When the test task type is system testing, the object under test can be the software under test; when the test task type is unit testing or integration testing, the object under test can be the function under test or the class under test of the software under test.

[0088] Specifically, the testing platform 20 can obtain the object under test in response to a user-triggered test case generation operation. For example, the testing platform 20 can capture the position of the input cursor when the user triggers the test case generation operation, and obtain the object under test based on the position of the input cursor. The object under test can be a function or class preceding the position of the input cursor. As another example, when the user writes annotations in the code interface, the testing platform 20 can obtain the user-written annotations when the user triggers the test case generation operation, and obtain the object under test based on the user's annotations.

[0089] S404 and Test Platform 20 perform software analysis on the object under test to obtain the engineering dependency information and context of the object under test.

[0090] The project dependency information includes at least one of a testing framework or a mocking framework. A framework is a reusable design, represented as a set of abstract components and methods for interaction between component instances. Specifically, a testing framework can be a collection of tools for multiple automated testing basic modules, automated testing management modules, and automated testing statistics modules. A mocking framework is used to create mock objects and define their behavior to assist testing. For example, a mocking framework can simulate function calls within the tested method during unit testing, and can simulate the behavior of a function without executing the function call. Testing frameworks and mocking frameworks can differ for different languages. In some examples, for Java, testing frameworks may include, but are not limited to, JUnit4 / JUnit5, and mocking frameworks may include, but are not limited to, PowerMock and Mockito.

[0091] The context includes at least one of a file-level context or a project-level context. File-level context and project-level context represent contexts of different granularities. In some possible implementations, a file-level context includes at least one of dependency import information, variable information, function information, and class constructors, while a project-level context includes function call information.

[0092] Software analysis can include source code analysis, binary program analysis, and software repository mining. Source code analysis typically employs static analysis methods, while binary program analysis can use dynamic methods. For example, a test platform 20 can execute binary programs and perform analysis based on the execution results. A typical implementation of static analysis is Abstract Syntax Tree (AST) analysis. An AST, also simply called a syntax tree, is an abstract representation of the syntactic structure of source code. The syntax tree represents the syntactic structure of a programming language in a tree-like form. Each node in the syntax tree represents a syntactic structure of the source code. Syntax verification is performed based on these syntactic structures, thus achieving syntax tree analysis.

[0093] In this application, the testing platform 20 can obtain the mock frameworks (PowerMock / Mockito for Java) and testing frameworks (JUnit4 / 5 for Java) that the unit tests depend on through project-level engineering dependency analysis. Specifically, the testing platform 20 determines the engineering dependency information of the object under test from the project build file of the software under test through engineering structure analysis. This engineering dependency information includes at least one of the testing frameworks or mocking frameworks.

[0094] The testing platform 20 can obtain at least one of the file-level context or project-level context of the object under test through static analysis. The file-level context includes at least one of dependency import information, variable information, function information, and class constructors; the project-level context includes function call information. Static analysis can be used for both file-level and project-level context analysis. The testing platform 20 can obtain the context within the file containing the object under test through static file-level context analysis, thus obtaining the file-level context. The file containing the object under test can be the file of the class containing the object under test, such as the file of the class containing the function under test, or the file of the class under test. Similarly, the testing platform 20 can obtain the project-level context of the object under test through static project-level context analysis. This project-level context includes function call information. The function call information can include the function information of external functions (also called outgoing functions) called by the object under test. Cross-file analysis based on the function information of outgoing functions can obtain the class signature of the class declaring the outgoing functions.

[0095] S406, Test platform 20 generates test headers for test cases of the object under test based on project dependency information and context.

[0096] The test header is the initial part of a test case, containing information other than the test methods. In some examples, the test header can be a test class initialization header, which can be the part of the test class in a language or a language containing OOP components, excluding dependency imports of test methods, annotations (if any), test class declarations, public methods, and public variables. The test class can be the class containing the test cases, and a test class can encapsulate one or more test cases. Public methods can be methods shared by all members of the test class; similarly, public variables can be variables shared by all members of the test class.

[0097] In practice, the test platform 20 can query a test header template that matches the project dependency information from the template library. Then, the test platform 20 can populate the context into the test header template to obtain the test headers for the test cases of the object under test.

[0098] The test header template can include at least one of the following: a test class annotation template, a public variable template, or a public method template. Function call information includes function information of external functions called by the object under test, which can include at least one of the following: function name, parameter information, return value, and scope. Variable information includes member variables of the class containing the object under test, which can include at least one of the following: variable name, variable type, scope, or initial value. Scope is used to limit the code range in which variables are available; the scope can be private, public, or protected.

[0099] Accordingly, the test platform 20 can analyze the external functions called by the object under test based on the function information of the external functions, and obtain the class signature of the declaration class of the external functions called by the object under test. The test platform 20 can then fill the class signature of the declaration class of the external functions called by the object under test into the test class annotation template in the test header template that matches the project dependency information, thereby obtaining the test class signature. The test class signature can be obtained by filling the test class annotation template with the class signature of the declaration class and the class declaration of the test class. For example, it can be obtained by signing the test class annotation template with the class signature of the declaration class and the class declaration of the test class. The test platform 20 fills the variable information of the member variables of the object under test into the public variable template in the test header template, thereby obtaining the definition of the public variables, and fills the function information and / or class constructor in the file-level context into the public method template, thereby obtaining the definition of the public methods.

[0100] In some possible implementations, the file-level context includes dependency import information, which includes dependency import statements for the class containing the object under test. The test platform 20 can place these dependency import statements at the beginning of the test header template to obtain a complete test header. Furthermore, the test platform 20 can extract the identifier (ID) of the index class from the populated template, where the index class is the declared class in the populated template. The test platform 20 can extract the IDs of all used declared classes from the populated template. Based on the identifier of the index class, the test platform 20 can find the classpath of the index class and then construct dependency import statements based on the classpath of the index class. For ease of distinction, the dependency import statement for the class containing the object under test can be called the first import statement, and the dependency import statement constructed based on the classpath of the index class can be called the second import statement.

[0101] S408 and Test Platform 20 use language models to continue writing the test headers of test cases to obtain test cases.

[0102] Test cases are used to test the object under test. Specifically, the test platform 20 can construct a question prompt based on the context and an answer prompt based on the test header. Then, the test platform 20 can prefill the question prompt using a language model and decode the answer prompt using a language model to continue writing the test header and obtain the test cases.

[0103] When language models such as LLM employ transformer networks, they exhibit the following significant characteristics: each inference round generates only one token as output. This token is then combined with all previously generated tokens to form the input sequence for the next round of inference. Here, the token represents the smallest unit of meaning that the language model can understand and generate, serving as its fundamental unit. Depending on the tokenization scheme used, a token can represent a word, a portion of a word, or even just a character. Tokens are assigned numerical values ​​or identifiers, arranged as sequences or vectors, and input into or output from the language model, forming its linguistic components. This generation process is repeated until a complete output sequence is generated. Because each round's input sequence only adds one token to the previous round's, it leads to significant redundant computation. Therefore, the industry has introduced key-value caches (KV caches) to reduce redundant computation.

[0104] The introduction of KV Cache divides the inference process into two phases: prefill and decode. The prefill phase generates the first output token. During prefill, the system precisely computes the key and value vectors for each transformer layer and caches them, forming a key cache and a value cache. The decode phase generates the second output token until all tokens are generated; that is, it generates every token except for the prefill phase. During the decode phase, since the KV Cache (such as the key cache and value cache) already stores the key and value vectors from previous rounds, each round of inference in this phase can read data from the KV Cache and add the newly computed key and value vectors to the corresponding caches.

[0105] Compilation issues with test cases typically arise during test class initialization. Therefore, this embodiment expands the scope of the Prompt to the Answer section of the language model, introducing the concept of Answer Prompt to intervene in the language model's decoding process. This ensures that the language model continues writing based on the correct test headers provided to it until the entire test class is completed, rather than the language model directly generating a complete test class. It should be noted that the test class is the class containing the test cases, and a test class can include one or more test cases.

[0106] S410 and Test Platform 20 present test cases to users.

[0107] Specifically, the testing platform 20 can present test cases to users through an interactive interface, allowing users to view the test cases. For example, the testing platform 20 can present test cases to users through a GUI. Furthermore, the testing platform 20 can also support users editing test cases generated by the language model. For example, the interactive interface may include editing controls, allowing users to edit test cases.

[0108] Based on the above description, this application provides a test case generation method. This method introduces software analysis into test case generation based on language models. It generates test case headers through software analysis and combines software analysis with hint engineering to constrain the language model's decoding and test case generation process. This ensures that the language model continues writing the test headers to generate test cases, rather than generating test cases from scratch. This solves the problem of generating incorrect test headers during the language model's test case generation process, improving the quality and effectiveness of the generated test cases. Furthermore, this method eliminates the need for repeated iterative test case repair, thus improving the efficiency of test case generation.

[0109] Next, we will introduce the test case generation method of this application in the context of a specific application scenario. This scenario uses the object under test as an example of the function under test.

[0110] The test case generation method of this application can be divided into the following stages: Stage 1, generating test headers through software analysis; Stage 2, continuing the test headers through language models to generate test cases. Each stage is described in detail below.

[0111] In Phase 1, the test platform 20 can typically perform test class signature construction, public variable construction, public method construction, and dependency import statement construction based on the results of software analysis of the function under test, such as the context and project dependency information of the function under test, thereby obtaining a complete test header, that is, obtaining the completed test case initialization generation content.

[0112] First, referring to Figure 5, which illustrates a flowchart of test class signature construction, the test platform 20 can perform engineering structure analysis on the function under test to obtain engineering dependency information. This engineering dependency information includes information about the frameworks the software's project depends on. These frameworks can include one or more of the test frameworks or simulation frameworks that the project depends on. The information about the frameworks the software's project depends on can include the framework name, and further, the framework version number. The test platform 20 can then match the engineering dependency information with templates in the test class annotation template library, and extract the test class annotation templates corresponding to the test frameworks and simulation frameworks from the library based on the matching results.

[0113] The test platform 20 also performs AST analysis on the function under test to obtain the method-level context of the function under test. The method-level context includes the signature of the method under test, the method return type, and function call information. The method under test is the method of the function under test, and the function call information belongs to the project-level context. Furthermore, the test platform 20 can perform cross-file analysis based on the function call information to obtain a cross-file context. The cross-file context includes the class signature of the declaration class of the calling function. As illustrated in Figure 5, the cross-file context can include the class signatures of the declaration classes of calling function A, B, and C. These declaration classes can be used as class variables of the test class. Based on this, the test platform 20 can use the cross-file context as annotation parameters to populate the test class annotation templates corresponding to the test framework and simulation framework, obtaining a test class annotation template with completed parameter population. The test platform 20 can also obtain the class declaration of the test class and the test class annotation template with completed parameter population, generating a test class signature. The class declaration of the test class can include the class name and scope.

[0114] Then, referring to the flowchart of the construction of public variables and public methods shown in Figure 6, the test platform 20 can perform engineering structure analysis on the function under test to obtain engineering dependency information. It should be noted that the engineering dependency information in Figure 6 can reuse the engineering dependency information obtained from the engineering structure analysis when constructing the test class signature. For example, during the construction of the test class signature, the test platform 20 can store the engineering dependency information obtained from the engineering structure analysis of the function under test. Thus, when constructing public variables and public methods, the test platform 20 can read the engineering dependency information without repeatedly performing the engineering structure analysis. The test platform 20 can match the engineering dependency information, such as the test framework and simulation framework that the project depends on, with the public variable and public method template library, and extract the public variable templates and public method templates corresponding to the test framework and simulation framework based on the matching results.

[0115] Test platform 20 performs AST analysis on the function under test to obtain the file-level context. The file-level context can be a class-level context, which can be the context of the class containing the function under test. This includes the member variables of the class under test, function information of other functions within the class, and the class constructor. Function information can include at least one of the following: function parameters, return value, and scope. Test platform 20 can analyze whether the class under test has a non-default constructor. If so, it populates the public method template with the analyzed class constructor. Additionally, test platform 20 can populate the public variable template with the member variables of the class under test. Once populated, test platform 20 obtains the definitions of public variables and public methods. It should be noted that when constructing the definition of public methods, function information of other functions can also be populated.

[0116] For ease of understanding, this example uses the Juni5 testing framework and Mockito as the mocking framework. Test platform 20 analyzes whether the class under test has a non-default constructor. If so, it explicitly calls the constructor of the class under test in the `@BeforeAll` method. Test platform 20 also injects the analyzed member variables of the class under test into the public variable template in the `@BeforeAll` method using reflection. Here, `@BeforeAll` is an annotation in Juni5 used to indicate that the annotated method should be executed before all tests in the current test class.

[0117] Next, the test platform 20 can construct dependency import statements, also known as import statements, corresponding to all identifiers used in the already populated template. Referring to Figure 7, which illustrates a flowchart of constructing dependency import statements, the test platform 20 can extract identifiers, for example, from the populated template, and use project-level analysis techniques to find the corresponding declaration class, also known as the index class. The test platform 20 can then find the classpath of the index class based on its identifier and construct the dependency import statements accordingly. These dependency import statements can be `import` commands, which can be placed at the beginning of the test header to obtain a complete test header.

[0118] This application uses software analysis algorithms to identify the context and engineering dependency information of the function under test, and generates the correct test head based on the context and engineering dependency information. It does not require training a language model to generate test heads with a large amount of specific corpora of different frameworks and versions, and it will not cause the generated test head to be incorrect due to AI "illusion".

[0119] Figures 5 to 7 provide a detailed explanation of how test headers are generated through software analysis. The following section, in conjunction with the accompanying figures, provides a detailed explanation of how to continue writing test headers using language models to generate test cases.

[0120] Referring to Figure 8, which illustrates a test case generation process, Figure 8 demonstrates the generation of test cases for unit testing of the function under test. In this example, the test platform 20 assembles the project dependency information and context of the function under test obtained from software analysis into the prompts of the unit test (UT) task. The project dependency information includes the test framework and simulation framework that the project depends on. The context of the function under test includes project-level context and file-level context. The project-level context includes function call information, and the file-level context includes at least one of dependency import information, variable information, function information, or class constructor. Dependency import information can be dependency import statements defined in the class containing the function under test. Variable information can include variable information of the class containing the function under test, such as the variable information of member variables of the class under test. Variable information can include at least one of variable name, variable type, scope, or initial value. Function information includes function information in the class definition of the class containing the function under test. Function information can include at least one of function name, parameter information, return value, or scope. The above-mentioned project dependency information and context are the necessary and sufficient information for implementing a UT class (the test class containing the test cases of the unit test).

[0121] Due to the limitations of language models, even with sufficient information provided, the UT classes generated by the language model may still fail to compile in practical applications. These compilation failures are concentrated during test class initialization. Therefore, this embodiment expands the scope of the prompt to include the answer section, introducing an answer prompt. As shown in Figure 8, the test platform 20 constructs a question prompt 802 based on the context and an answer prompt 804 based on the test header. The answer prompt 804 includes the test header, followed by the answer start section. This guides the language model to continue writing the test header obtained from software analysis until the entire test class is completed (before the answer end), instead of the language model directly generating a complete test class from scratch.

[0122] Language model-based test case generation often involves providing the test case context in the prompt section, prompting the language model to generate the corresponding test class in the Answer section. However, language models tend to generate numerous errors in the test case headers. This application uses the test case headers generated by software analysis algorithms as the starting point of the Answer section, inputting them into the language model. This allows the language model to continue writing test cases or test classes based on the test headers provided by software analysis, addressing the issues of missing correct dependencies, generating incorrect dependencies, and generating incorrect initialization content when language models generate test cases. This reduces the total number of tokens generated by the model and improves the correctness and generation speed of the generated content.

[0123] Based on the aforementioned test case generation method, this application also provides a test platform 20. The test platform of this application will be described below from the perspective of functional modularity.

[0124] Referring to Figure 2, which shows a schematic diagram of the structure of a test platform 20, the test platform 20 includes:

[0125] The software analysis module 202 is used to acquire the object under test, which is the software under test or a code segment in the software under test; to perform software analysis on the object under test to obtain the project dependency information and context of the object under test, wherein the context includes at least one of file-level context or project-level context;

[0126] The test header generation module 204 is used to generate a test header for the test cases of the object under test based on the project dependency information and the context. The test header is the initial part of the test cases, and the initial part includes information other than the test methods.

[0127] The test case generation module 206 is used to continue writing the test header of the test case through a language model to obtain the test case, which is used to test the object under test.

[0128] Interaction module 208 is used to present the test cases to the user.

[0129] For example, the software analysis module 202, test header generation module 204, test case generation module 206, and interaction module 208 described above can be implemented in hardware or in software.

[0130] When implemented in software, the software analysis module 202, test header generation module 204, test case generation module 206, and interaction module 208 can be applications running on computing devices, such as computing engines. These applications can also be virtualized and provided to users as virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, or container services. VM services can be services that use virtualization technology to create virtual machine (VM) resource pools on multiple physical hosts to provide VMs for users to use on demand. BMS services are services that use virtualization technology to create BMS resource pools on multiple physical hosts to provide BMS for users to use on demand. Container services are services that use virtualization technology to create container resource pools on multiple physical hosts to provide containers for users to use on demand. A VM is a simulated virtual computer, that is, a logical computer. A BMS is a scalable, high-performance computing service with computing performance indistinguishable from traditional physical machines and features secure physical isolation. Containers are a kernel virtualization technology that provides lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In practical applications, virtualization services can also include other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0131] When implemented in hardware, the software analysis module 202, test header generation module 204, test case generation module 206, and interaction module 208 may include at least one computing device, such as a server. Alternatively, the software analysis module 202, test header generation module 204, test case generation module 206, and interaction module 208 may also be devices implemented using application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). The aforementioned PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0132] In some possible implementations, the test header generation module 204 is specifically used for:

[0133] Based on the project dependency information, query the template library for a test header template that matches the project dependency information;

[0134] The context is populated into the test header template to obtain the test header of the test cases for the object under test.

[0135] In some possible implementations, the software analysis module 202 is specifically used for:

[0136] Through engineering structure analysis, the engineering dependency information of the tested object is determined from the engineering construction file of the software under test. The engineering dependency information includes at least one of a test framework or a simulation framework.

[0137] Through static analysis, at least one of the file-level context or the project-level context of the object under test is obtained. The file-level context includes at least one of dependency import information, variable information, function information, and class constructor. The project-level context includes function call information.

[0138] In some possible implementations, the function call information includes function information of external functions called by the object under test, and the variable information includes variable information of member variables of the class to which the object under test belongs. The test header generation module 204 is specifically used for:

[0139] Analyze the external function called by the object under test based on the function information of the external function, obtain the class signature of the declaration class of the external function called by the object under test, and fill the class signature of the declaration class into the test class annotation template in the test header template that matches the project dependency information to obtain the test class signature.

[0140] The variable information of the member variables of the class to which the object under test belongs is filled into the public variable template in the test header template to obtain the definition of the public variable;

[0141] The function information and / or class constructors in the file level are populated into the public method template to obtain the definition of the public method.

[0142] In some possible implementations, the test header generation module 204 is further configured to:

[0143] Extract the identifier of the index class from the populated template, where the index class is the declaration class in the populated template;

[0144] Based on the identifier of the index class, find the class path of the index class;

[0145] Construct a dependency import statement based on the classpath of the index class.

[0146] In some possible implementations, the test case generation module 206 is specifically used for:

[0147] Construct question prompts based on the context, and construct answer prompts based on the test header;

[0148] Based on the problem prompts, pre-filling is performed using a language model;

[0149] Based on the answer prompts, the language model is used for decoding to continue writing the test header and obtain the test cases.

[0150] In some possible implementations, the object under test is the function under test or the class under test.

[0151] This application also provides a computing device 900. As shown in FIG9, the computing device 900 includes: a bus 902, a processor 904, a memory 906, and a communication interface 908. The processor 904, the memory 906, and the communication interface 908 communicate with each other via the bus 902. The computing device 900 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 900.

[0152] Bus 902 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 9, but this does not imply that there is only one bus or one type of bus. Bus 902 can include pathways for transmitting information between various components of computing device 900 (e.g., memory 906, processor 904, communication interface 908).

[0153] Processor 904 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0154] Memory 906 may include volatile memory, such as random access memory (RAM). Memory 906 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 906 stores executable program code, which processor 904 executes to implement the aforementioned test case generation method. Specifically, memory 906 stores instructions for test platform 20 to execute the test case generation method. For example, memory 906 stores instructions for implementing the functions of software analysis module 202, test header generation module 204, test case generation module 206, and interaction module 208.

[0155] The communication interface 908 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 900 and other devices or communication networks.

[0156] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0157] As shown in Figure 10, the computing device cluster includes at least one computing device 900. The memory 906 of one or more computing devices 900 in the computing device cluster may store instructions from the same test platform 20 for executing test case generation methods.

[0158] In some possible implementations, one or more computing devices 900 in the computing device cluster can also be used to execute some of the instructions used by the test platform 20 to execute the test case generation method. In other words, a combination of one or more computing devices 900 can jointly execute the instructions used by the test platform 20 to execute the test case generation method.

[0159] It should be noted that the memory 906 in different computing devices 900 in the computing device cluster can store different instructions for executing some functions of the test platform 20.

[0160] Figure 11 illustrates one possible implementation. As shown in Figure 11, two computing devices 900A and 900B are connected via a communication interface 908. The memory in computing device 900A stores instructions for executing the functions of the software analysis module 202 and the test head generation module 204. The memory in computing device 900B stores instructions for executing the functions of the test case generation module 206 and the interaction module 208. In other words, the memory 906 of computing devices 900A and 900B jointly stores the instructions used by the test platform 20 to execute the test case generation method.

[0161] The connection method between the computing device clusters shown in Figure 11 can be considered because the test case generation method provided in this application requires a lot of resources to run the language model and rewrite the test header to generate test cases. Therefore, it is considered that the functions implemented by the test case generation module 206 can be executed by an independent computing device. Considering the transmission overhead between the test case generation module 206 and the interaction module 208, the functions implemented by the interaction module 208 can also be implemented by the computing device where the test case generation module 206 is located. Based on this, the functions implemented by the software analysis module 202 and the test header generation module 204 can be executed by computing device 900A, and the functions implemented by the test case generation module 206 and the interaction module 208 can be executed by computing device 900B.

[0162] It should be understood that the functions of computing device 900A shown in Figure 11 can also be performed by multiple computing devices 900. Similarly, the functions of computing device 900B can also be performed by multiple computing devices 900.

[0163] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 12 illustrates one possible implementation. As shown in Figure 12, two computing devices 900C and 900D are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 906 in computing device 900C stores instructions for executing the functions of the software analysis module 202 and the test header generation module 204. Simultaneously, the memory 906 in computing device 900D stores instructions for executing the functions of the test case generation module 206 and the interaction module 208.

[0164] The connection method between the computing device clusters shown in Figure 12 can be considered as follows: considering that the test case generation method provided in this application requires a lot of resources to continue writing the test header to generate test cases, it is considered that the functions implemented by the test case generation module 206 and the interaction module 208 are executed by an independent computing device, such as computing device 900D.

[0165] It should be understood that the functions of computing device 900C shown in Figure 12 can also be performed by multiple computing devices 900. Similarly, the functions of computing device 900D can also be performed by multiple computing devices 900.

[0166] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the test case generation method described above, applied to the test platform 20.

[0167] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the above-described test case generation method.

[0168] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A test case generation method, characterized in that, The method includes: Obtain the object under test, which is the software under test or a code segment in the software under test; The test object is subjected to software analysis to obtain the test object's engineering dependency information and context, the context including at least one of file-level context or project-level context; Based on the project dependency information and the context, a test header for the test cases of the object under test is generated. The test header is the initial part of the test cases, and the initial part includes information other than the test methods. The test cases are obtained by continuing the test header of the test cases through the language model, and the test cases are used to test the object under test. Present the test cases to the user.

2. The method according to claim 1, characterized in that, The step of generating the test header for the test cases of the object under test based on the project dependency information and the context includes: Based on the project dependency information, query the template library for a test header template that matches the project dependency information; The context is populated into the test header template to obtain the test header of the test cases for the object under test.

3. The method according to claim 1 or 2, characterized in that, The step of performing software analysis on the object under test to obtain the engineering dependency information and context of the object under test includes: Through engineering structure analysis, the engineering dependency information of the tested object is determined from the engineering construction file of the software under test. The engineering dependency information includes at least one of a test framework or a simulation framework. Through static analysis, at least one of the file-level context or project-level context of the object under test is obtained. The file-level context includes at least one of dependency import information, variable information, function information, and class constructor. The project-level context includes function call information.

4. The method according to claim 3, characterized in that, The function call information includes function information of external functions called by the object under test, and the variable information includes variable information of member variables of the class in which the object under test resides. Generating the test header for the test cases of the object under test based on the project dependency information and the context includes: Analyze the external function called by the object under test based on the function information of the external function, obtain the class signature of the declaration class of the external function called by the object under test, and fill the class signature of the declaration class into the test class annotation template in the test header template that matches the project dependency information to obtain the test class signature. The variable information of the member variables of the class to which the object under test belongs is filled into the public variable template in the test header template to obtain the definition of the public variable; The function information and / or class constructor from the file-level context are populated into the public method template to obtain the definition of the public method.

5. The method according to claim 4, characterized in that, The method further includes: Extract the identifier of the index class from the populated template, where the index class is the declaration class in the populated template; Based on the identifier of the index class, find the class path of the index class; Construct a dependency import statement based on the classpath of the index class.

6. The method according to any one of claims 1 to 5, characterized in that, The step of continuing to write the test header of the test case using a language model to obtain the test case includes: Construct question prompts based on the context, and construct answer prompts based on the test header; Based on the problem prompts, pre-filling is performed using a language model; Based on the answer prompts, the language model is used for decoding to continue writing the test header and obtain the test cases.

7. The method according to any one of claims 1 to 6, characterized in that, The object under test is either the function under test or the class under test.

8. A testing platform, characterized in that, The testing platform includes: The software analysis module is used to acquire the object under test, which is the software under test or a code segment in the software under test; to perform software analysis on the object under test to obtain the project dependency information and context of the object under test, wherein the context includes at least one of file-level context or project-level context; The test header generation module is used to generate test headers for test cases of the object under test based on the project dependency information and the context. The test header is the initial part of the test case, and the initial part includes information other than the test method. The test case generation module is used to continue writing the test header of the test case through a language model to obtain the test case, which is used to test the object under test. The interaction module is used to present the test cases to the user.

9. The testing platform according to claim 8, characterized in that, The test header generation module is specifically used for: Based on the project dependency information, query the template library for a test header template that matches the project dependency information; The context is populated into the test header template to obtain the test header of the test cases for the object under test.

10. The testing platform according to claim 8 or 9, characterized in that, The software analysis module is specifically used for: Through engineering structure analysis, the engineering dependency information of the tested object is determined from the engineering construction file of the software under test. The engineering dependency information includes at least one of a test framework or a simulation framework. Through static analysis, at least one of the file-level context or project-level context of the object under test is obtained. The file-level context includes at least one of dependency import information, variable information, function information, and class constructor. The project-level context includes function call information.

11. The testing platform according to claim 10, characterized in that, The function call information includes function information of external functions called by the object under test, and the variable information includes variable information of member variables of the class in which the object under test resides. The test header generation module is specifically used for: Analyze the external function called by the object under test based on the function information of the external function, obtain the class signature of the declaration class of the external function called by the object under test, and fill the class signature of the declaration class into the test class annotation template in the test header template that matches the project dependency information to obtain the test class signature. The variable information of the member variables of the class to which the object under test belongs is filled into the public variable template in the test header template to obtain the definition of the public variable; The function information and / or class constructor from the file-level context are populated into the public method template to obtain the definition of the public method.

12. The testing platform according to claim 11, characterized in that, The test head generation module is also used for: Extract the identifier of the index class from the populated template, where the index class is the declaration class in the populated template; Based on the identifier of the index class, find the class path of the index class; Construct a dependency import statement based on the classpath of the index class.

13. The test platform according to any one of claims 8 to 12, characterized in that, The test case generation module is specifically used for: Construct question prompts based on the context, and construct answer prompts based on the test header; Based on the problem prompts, pre-filling is performed using a language model; Based on the answer prompts, the language model is used for decoding to continue writing the test header and obtain the test cases.

14. The test platform according to any one of claims 8 to 13, characterized in that, The object under test is either the function under test or the class under test.

15. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, the at least one computing device including at least one processor and at least one memory, the at least one memory storing computer-readable instructions; the at least one processor executes the computer-readable instructions to cause the computing device cluster to perform the test case generation method as described in any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that, Includes computer-readable instructions; the computer-readable instructions are used to implement the test case generation method according to any one of claims 1 to 7.

17. A computer program product, characterized in that, Includes computer-readable instructions; the computer-readable instructions are used to implement the test case generation method according to any one of claims 1 to 7.

Images