Unit test method, apparatus and electronic device

Abstract

The application discloses a unit test method, device and electronic equipment. The method comprises the following steps: generating test case code of a to-be-tested code by a large language model according to a test case framework; obtaining at least one target function identifier of a to-be-generated stub function according to the test case code and the to-be-tested code; generating a stub function corresponding to each target function identifier by the large language model according to a stub function framework; and running the test case code, the to-be-tested code and the stub function to obtain a unit test result of the to-be-tested code. The application can improve test efficiency and reduce labor cost.

Description

Technical Field

[0001] This application belongs to the field of software testing technology, specifically relating to a unit testing method, apparatus, and electronic device. Background Technology

[0002] In embedded system programming, the limited number of target boards (hardware environments) prevents them from being used extensively for running unit tests. To address this, a Linux-based computer is typically used as the unit testing environment, or a Windows or macOS system running a compatible compilation environment is used. However, when performing unit tests on Linux, Windows, or macOS computers, cross-compilation issues make it difficult to obtain third-party software packages for the test platform (such as x86 systems), leading to compilation and execution failures. To solve this problem, stub functions are typically introduced to replace third-party software packages.

[0003] In existing technologies, it is generally necessary to manually identify which third-party software requires stub functions, and then manually write the stub functions, or use an AI-enabled editor such as VSCode to implement them one by one using an LLM (Large Language Model). This process is very tedious, error-prone, and requires a lot of manpower, resulting in low testing efficiency and high costs. Summary of the Invention

[0004] The purpose of this application is to provide a unit testing method, apparatus, and electronic device that can solve the problems of low testing efficiency and high cost caused by cumbersome stub function generation.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, this application provides a unit testing method, which includes: Based on the test case framework, test case code is generated for the code under test using a large language model; Based on the test case code and the code under test, obtain at least one target function identifier for the stub function to be generated; Based on the stub function framework, stub functions corresponding to the target function identifiers are generated through the large language model; Run the test case code, the code under test, and the stub function to obtain the unit test results of the code under test.

[0006] Secondly, this application provides a unit testing apparatus, comprising: The test case generation module is used to generate test case code for the code under test based on the test case framework and a large language model. The function identifier acquisition module is used to acquire at least one target function identifier of the stub function to be generated based on the test case code and the code under test; The stub function generation module is used to generate stub functions corresponding to each of the target function identifiers based on the stub function framework and the large language model. The execution module is used to run the test case code, the code under test, and the stub function to obtain the unit test results of the code under test.

[0007] Thirdly, 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 method described in the first aspect.

[0008] Fourthly, 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 method described in the first aspect.

[0009] Fifthly, this application provides a chip including 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 method as described in the first aspect.

[0010] In this application, based on the test case framework, test case code for the code under test is generated through a large language model. Based on the test case code and the code under test, at least one target function identifier for the stub functions to be generated is obtained. Based on the stub function framework, the stub functions corresponding to each target function identifier are generated through the large language model. The test case code, the code under test, and the stub functions are run to obtain the unit test results of the code under test. Since at least one target function identifier for the stub functions to be generated can be obtained from the test case code and the code under test, and all stub functions are uniformly generated through the large language model, it is not necessary to manually determine the required stub functions and hand them over to the large language model for implementation one by one. This can improve the efficiency of stub function generation, thereby improving testing efficiency and reducing labor costs. Attached Figure Description

[0011] Figure 1 This is a flowchart of a unit testing method provided in an embodiment of this application; Figure 2 This is a flowchart of a unit testing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a unit testing device provided in an embodiment of this application; Figure 4 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0014] In related technologies, when writing stub functions using LLM, operations are typically performed on a function-by-function basis. For example, if 10 functions need stub functions, the LLM needs to be manually instructed on how to generate the stub function for the first function; then the LLM is manually instructed to start processing the second function, and so on. This process is extremely cumbersome, cannot be separated from manual intervention, and results in low efficiency and high labor costs.

[0015] The unit testing method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0016] Figure 1 This is a flowchart illustrating a unit testing method provided in an embodiment of this application. This unit testing method can be applied to electronic devices such as computers, and is suitable for C language unit testing scenarios for embedded systems, such as... Figure 1 As shown, the method may include steps 110 to 140.

[0017] Step 110: Based on the test case framework, generate test case code for the code under test using the large language model.

[0018] Among them, the test case framework is a pre-set architecture for test cases, which can guide the large language model to fill in the test code related to the code under test in the corresponding position within the test case framework to obtain the test case code.

[0019] The test case framework may include: registering appropriate lambda function bodies to the stub function dataset according to the test requirements within the test case function; running the function under test within the test case function; and checking the running status and results of the lambda function within the test case function to confirm whether the corresponding test objective has been achieved.

[0020] Here is an example of a test case framework: Suppose there exists the following function to be tested: extern void do_something(); / / Third-party function extern bool is_enabled(); / / Third-party function void foo() { / / The function being tested if (is_enabled()) { do_something(); } } The following unit test function can be designed: TEST(FooTest, doSomething) { bool called = false; bool enable = false; stub_map["is_enabled"]["FooTest.doSomething"] = std::function<int(void)> ([]() { return enable; / / Key point }); stub_map["do_something"]["FooTest.doSomething"] = std::function<void(void)> ([&]() { called = true; / / Auxiliary point }); enable = false; / / Key point foo(); / / Run the function under test EXPECT_FALSE(called); / / Key point: proves that `do_something()` is not called when enable is False. called = false; enable = true; / / Key point foo(); / / Run the function under test EXPECT_TRUE(called); / / Key point: proves that `do_something()` is called when enable is True. } Within the aforementioned test case framework, when generating test case code using the large language model, it is possible to...<int(void)> Enter the test code related to the code being tested in the specified location.

[0021] The test case framework, the code under test, and prompts for generating test case code can be input into a large language model. Guided by these prompts, the large language model analyzes the code under test and fills in the relevant test code within the test case framework, resulting in compileable (cc) test case code. This test case code can include different types of test case code, such as randomized tests, boundary value tests, branch tests, and other conventional unit test cases.

[0022] In some embodiments of this application, generating test case code for the code under test using a large language model based on a test case framework includes: generating a test case design document for the code under test using a large language model based on the test case framework; and generating test case code for the code under test using a large language model based on the test case design document.

[0023] The test case design document provides the design ideas for test cases in text form.

[0024] The test case framework and the code under test can be input into a large language model. The large language model analyzes the code under test and generates a test case design document for the code under test. The test case design document and the code under test can be input into the large language model and analyzed by the large language model to generate compilable test case code for the code under test.

[0025] First, a test case design document is generated using a large language model. Then, based on the test case design document, the large language model is called again to generate test case code. This avoids the error problems that are easy to occur when directly generating test case code and improves the accuracy of the generated test case code.

[0026] In some embodiments of this application, generating a test case design document for the code under test using a large language model based on a test case framework includes: inputting the test case framework, the code under test, and a first prompt word into the large language model; and generating a test case design document for the code under test based on the test case framework using the large language model guided by the first prompt word. The first prompt word is a prompt word used to guide the large language model in generating the test case design document.

[0027] The test case framework, the code under test, and the first prompt are input into the large language model. Guided by the first prompt, the large language model analyzes the code under test and generates test case design documents for the code under test, such as design documents for common unit test cases like random tests, boundary value tests, and branch tests, based on the test case framework.

[0028] Using the first prompt word can effectively guide the large language model to generate test case design documents that meet the requirements, thereby improving the accuracy of the generated test case design documents.

[0029] In some embodiments of this application, generating test case code for the code under test using a large language model based on a test case design document includes: inputting the test case design document, the code under test, and a second prompt word into the large language model; and generating test case code for the code under test based on the test case design document using the large language model guided by the second prompt word. The second prompt word is a prompt word used to guide the large language model in generating test case code.

[0030] The test case design document, the code under test, and the second prompt word are input into the large language model. Guided by the second prompt word, the large language model analyzes the test case design document and the code under test, and generates compilable test case code for the code under test, such as generating code for conventional unit test cases such as random tests, boundary value tests, and branch tests.

[0031] Using a second prompt word can effectively guide the large language model to generate test case code that meets the requirements, thereby improving the accuracy of test case code generation.

[0032] Step 120: Based on the test case code and the code under test, obtain at least one target function identifier for the stub function to be generated.

[0033] The test case code and the code under test can be edited and linked to obtain at least one function identifier that failed to link. From these failed function identifiers, at least one function identifier in the code under test that failed to link can be determined. Based on this, at least one object function identifier for the stub function to be generated can be determined. Compilation converts the source code (.c file) into object files (.o or .obj file). Linking merges multiple object files and library files to generate the final executable file (such as a .exe or .out file). Function identifiers are used to distinguish different functions; for example, they can be function names.

[0034] For example, determining at least one target function identifier of the stub function to be generated based on at least one function identifier of the tested code that failed to link can include: using at least one function identifier of the tested code that failed to link as at least one target function identifier of the stub function to be generated; or, determining at least one target function identifier of the stub function to be generated from at least one function identifier of the tested code that failed to link.

[0035] In some embodiments of this application, obtaining at least one target function identifier of the stub function to be generated based on the test case code and the code under test includes: compiling and linking the test case code and the code under test to obtain at least one function identifier that failed to link; and determining at least one target function identifier of the stub function to be generated from the function identifiers that failed to link, based on the function declaration list of the stub function to be generated corresponding to the code under test.

[0036] The function declaration list is a list of declarations of other functions (such as third-party functions) that the code under test depends on, obtained through prior analysis of the code under test. These other functions serve as stub functions to be generated. Each function declaration in the function declaration list can include a function identifier (such as function name), return type, and parameter types.

[0037] The test case code and the code under test are compiled and linked (ld / link) to obtain the identifiers (e.g., function names) of all failed linking functions, resulting in at least one failed linking function identifier. This identifier is then compared to a pre-obtained list of function declarations for stub functions. Function identifiers included in the function declaration list from the list of failed linking function identifiers are selected as at least one target function identifier for the stub functions. Generally, at least one failed linking function identifier will appear in the function declaration list. However, if the list includes function identifiers not included in the function declaration list, these can be manually detected or addressed using other tools to identify and fix the corresponding functions.

[0038] By combining the function declaration list of the stub functions to be generated, at least one target function identifier of the stub functions to be generated can be determined from at least one function identifier of the test case code and the code under test that failed to link. This can accurately obtain the stub functions required in the code under test, improve the accuracy of the target function identifier determination, and reduce labor costs by eliminating the need for manual determination.

[0039] In some embodiments of this application, before determining at least one target function identifier of the stub function to be generated from the function identifiers of the failed linking functions based on the function declaration list of the stub function to be generated corresponding to the code under test, the method further includes: obtaining a list of software packages that the code under test depends on; extracting the header files of each software package in the software package list; parsing the header files of each software package to obtain the function declaration list of the stub function to be generated.

[0040] The list of software packages that the code under test depends on can be a list of third-party software packages that the code under test depends on. These third-party software packages are software packages developed by software providers other than the provider of the code under test.

[0041] The script can analyze the project of the code under test to obtain a list of third-party software packages that the code under test depends on, thus obtaining a list of software packages that the code under test depends on; extract the header files of each software package in the list of all dependent software packages of the code under test from the compilation environment (such as a cross-compilation environment); use an AST (Abstract Syntax Tree) tool (a general-purpose tool specifically used for parsing code) to parse the header files of each software package to obtain a list of declarations of third-party interface functions, which will be used as a list of function declarations to be generated as stub functions.

[0042] By analyzing the code under test and obtaining the list of software packages, and then extracting the header files of each software package and parsing the header files, the function declaration list of the stub functions to be generated can be accurately obtained, thus improving the accuracy of obtaining the function declaration list of the stub functions to be generated.

[0043] Step 130: Based on the stub function framework, generate the stub functions corresponding to each objective function identifier through the large language model.

[0044] The stub function framework is a pre-defined architecture for stub functions that guides the large language model to fill in the corresponding stub function code at the appropriate position within the framework, thus obtaining the stub function.

[0045] Below is an example of a stub function framework: Type * Stub function name(const char * value) { const char* name = get_case_name(); / / Get the name of the currently running unit test if (stub_map["stub function name"].count(name)) { / / Check if the lambda function body of the stub function corresponding to the test case has been registered. auto f = std::any_cast <std::function<Type *(const char *)> >(stub_map["stub function name"][name]); / / Get the stub function pointer of the lambda return f(value); / / Run the lambda stub function } return (Type *)0; } The stub function framework and the identifiers of each objective function can be input into a large language model. The large language model analyzes the identifiers and the stub function framework to generate stub functions corresponding to each objective function identifier. For example, for the above stub function framework example, when generating stub functions through the large language model, the objective function identifier (objective function name) can be filled in the "stub function name" position, and the corresponding stub function's functionality can be filled in the "function" position to obtain the generated stub functions.

[0046] In some embodiments of this application, based on the stub function framework, generating stub functions corresponding to each of the target function identifiers through a large language model includes: inputting the stub function framework, each target function identifier, and a third prompt word into the large language model, and generating stub functions corresponding to each target function identifier through the large language model. The third prompt word is a prompt word used to guide the large language model to generate stub functions.

[0047] The third prompt word is a pre-designed prompt word that can guide the large language model to generate stub functions.

[0048] The stub function framework, the identifiers of each objective function, and the third prompt word can be input into the large language model. Guided by the third prompt word, the large language model analyzes the stub function framework and the identifiers of each objective function, and generates the stub function corresponding to each objective function identifier.

[0049] By using the stub function framework, the identifiers of each objective function, and the third prompt word, the large language model can be easily and quickly guided to generate stub functions corresponding to each objective function identifier. This eliminates the need to call the large language model separately for each stub function to be generated, thus improving the efficiency of stub function generation.

[0050] Step 140: Run the test case code, the code under test, and the stub functions to obtain the unit test results of the code under test.

[0051] The test case code, the code under test, and stub functions are compiled and linked to generate an executable file. Running the generated executable file yields the unit test results for the code under test. If compilation fails, steps 130 and 140 can be re-executed to regenerate the stub functions using the large language model, and the process can be repeated until compilation and execution succeed to obtain the unit test results.

[0052] In some embodiments of this application, running the test case code, the code under test, and the stub function to obtain the unit test result of the code under test includes: running the test case code and registering the stub function body of the stub function in the stub function dataset; running the code under test and running the stub function, obtaining the stub function pointer corresponding to the stub function identifier and test case name from the stub function dataset based on the stub function identifier and test case name, and running the stub function body based on the stub function pointer; and determining the unit test result of the code under test based on the running status and running result of the stub function body.

[0053] The stub function pointer is used to locate the stub function body in memory. The stub function dataset is pre-designed based on C++'s MAP, providing the mapping relationship between stub function identifiers, test case names, and stub function pointers. For example, the stub function dataset can take the following form: std::map <std::string, std::map<std::string, std::any> >stub_map; The first string is the name of the target stub function, the second string is the name of the test case, and any is a lambda function pointer (stub function pointer).

[0054] The test case code is executed. Within the test case function, appropriate stub function bodies (lambda function bodies) are registered with the stub function dataset according to the test requirements. The code under test is then run within the test case function. When the code under test calls a stub function, the stub function is executed. Inside the stub function, based on the identifier (i.e., its own function name) of the currently running stub function and the name of the currently running test case, the stub function dataset is queried to obtain the stub function pointer (lambda function pointer) corresponding to that identifier and test case name. The stub function body (lambda stub function) is then executed based on this pointer. After the code under test and the stub function have finished running, the execution status and results of the stub function bodies are checked within the test case function to determine whether the corresponding test objective has been achieved, thus obtaining the unit test results for the code under test.

[0055] By running test case code and registering stub function bodies with the stub function dataset, the code under test and the stub functions can be executed sequentially according to the execution order of the test case code, thereby obtaining the unit test results of the code under test. Test results can be obtained without manual intervention, which can reduce labor costs.

[0056] The unit testing method provided in this application generates test case code for the code under test using a large language model based on a test case framework. Based on the test case code and the code under test, it obtains at least one target function identifier for the stub functions to be generated. Then, based on the stub function framework, it generates the stub functions corresponding to each target function identifier using the large language model. Finally, it runs the test case code, the code under test, and the stub functions to obtain the unit test results for the code under test. Since at least one target function identifier for the stub functions to be generated can be obtained from the test case code and the code under test, and all stub functions are generated uniformly using the large language model, it eliminates the need for manual determination of the required stub functions and their individual implementation by the large language model. This improves the efficiency of stub function generation, thereby increasing testing efficiency and reducing labor costs.

[0057] Based on the above technical solution, after running the test case code, the code under test, and the stub function to obtain the unit test results of the code under test, the method further includes: if the unit test results indicate that the test failed or the coverage is less than the coverage threshold, then the steps of generating test case code and running test case code, the code under test, and the stub function are re-executed until the test is successful and the coverage is greater than or equal to the coverage threshold.

[0058] If the unit test results indicate test failure or coverage is less than the coverage threshold, steps 110 and 140 are re-executed to request the large language model to generate test case code again. Different warning words are selected based on whether the test failed or coverage was insufficient to guide the large language model in optimizing the test cases, until all test cases are successfully tested and coverage is greater than or equal to the coverage threshold. If the test results determine that the stub function is problematic, the step of generating the stub function can also be re-executed. Coverage can be the proportion of executed statements in the tested code out of all executed statements. The coverage threshold is a pre-set threshold based on test requirements, such as 75%, 90%, etc.

[0059] By re-executing the steps of generating test case code, running test case code, code under test, and stub functions when a test fails or the coverage is less than the coverage threshold, until the test succeeds and the coverage is greater than or equal to the coverage threshold, the required test results can be obtained.

[0060] Figure 2 This is a flowchart of a unit testing method provided in an embodiment of this application, such as... Figure 2 As shown, the method may include steps 210 to 280.

[0061] Step 210: Input the test case framework, the code under test, and the first prompt word into the large language model. Guided by the first prompt word, the large language model generates a test case design document for the code under test based on the test case framework.

[0062] Step 220: Input the test case design document, the code under test, and the second prompt word into the large language model. Guided by the second prompt word, the large language model generates test case code for the code under test based on the test case design document.

[0063] Step 230: Compile and link the test case code and the code under test to obtain the identifier of at least one function that failed to link.

[0064] Step 240: Based on the function declaration list of the stub functions to be generated corresponding to the code under test, determine at least one target function identifier of the stub function to be generated from the function identifiers of the failed linking.

[0065] Step 250: Manually or using tools, check the remaining functions in the function identifiers of the failed links, identify the problem and fix it, then proceed to step 230.

[0066] Step 260: Input the stub function framework, the identifiers of each objective function, and the third prompt word into the large language model, and generate the stub functions corresponding to each objective function identifier through the large language model.

[0067] Step 270: Run the test case code, the code under test, and the stub functions to obtain the unit test results of the code under test.

[0068] Step 280: Determine whether the test was successful and whether the coverage is greater than or equal to the coverage threshold. If yes, the process ends; otherwise, return to step 210.

[0069] This application's embodiments determine which third-party software packages' function interfaces need stub functions by generating test case code and compiling and linking it, thus reducing manual costs. By using well-designed prompts combined with a stub function framework to guide the LLM in generating stub functions, and by using well-designed prompts combined with a test case framework to guide the LLM in generating unit test functions that use stub functions, code quality can be improved. Furthermore, the generation of stub functions does not require manual intervention, saving labor costs and increasing testing efficiency.

[0070] It should be noted that the unit testing method provided in this application embodiment can be executed by a unit testing device, or a control module within that unit testing device for executing the loading unit test method. This application embodiment uses the execution of the loading unit test method by a unit testing device as an example to illustrate the unit testing method provided in this application embodiment.

[0071] Figure 3 This is a schematic diagram of the structure of a unit testing device provided in an embodiment of this application, as shown below. Figure 3 As shown, the unit test apparatus may include: The test case generation module 310 is used to generate test case code for the code under test based on the test case framework and a large language model. The function identifier acquisition module 320 is used to acquire at least one target function identifier of the stub function to be generated based on the test case code and the code under test; The stub function generation module 330 is used to generate stub functions corresponding to each of the target function identifiers based on the stub function framework and the large language model. The execution module 340 is used to run the test case code, the code under test, and the stub function to obtain the unit test results of the code under test.

[0072] Optionally, the test case generation module includes: The test case design document generation unit is used to generate a test case design document for the code under test based on the test case framework and the large language model. The test case generation unit is used to generate test case code for the code under test based on the test case design document and the large language model.

[0073] Optionally, the use case design document generation unit is specifically used for: The test case framework, the code under test, and the first prompt word are input into the large language model. Based on the guidance of the first prompt word, the large language model generates a test case design document for the code under test according to the test case framework. The first prompt word is a prompt word used to guide the large language model to generate the test case design document. And / or, the test case generation unit is specifically used for: The test case design document, the code under test, and the second prompt word are input into the large language model. Based on the guidance of the second prompt word, the large language model generates test case code for the code under test according to the test case design document. The second prompt word is a prompt word used to guide the large language model to generate test case code.

[0074] Optionally, the function identifier acquisition module is specifically used for: Compile and link the test case code and the code under test to obtain at least one function identifier that failed to link. Based on the function declaration list of the stub function to be generated corresponding to the code under test, at least one target function identifier of the stub function to be generated is determined from the function identifiers of the failed linking.

[0075] Optionally, the apparatus further includes a function declaration list acquisition module, which is used to: Obtain the list of software packages that the code under test depends on; Extract the header files of each software package in the software package list; The header files of each software package are parsed to obtain a list of function declarations for which stub functions are to be generated.

[0076] Optionally, the stub function generation module is specifically used for: The stub function framework, each of the target function identifiers, and the third prompt word are input into the large language model. The large language model generates stub functions corresponding to each of the target function identifiers. The third prompt word is a prompt word used to guide the large language model to generate stub functions.

[0077] Optionally, the device further includes: The re-execution module is used to re-execute the steps of generating test case code, running test case code, code under test, and stub functions if the unit test result indicates that the test failed or the coverage is less than the coverage threshold, until the test is successful and the coverage is greater than or equal to the coverage threshold.

[0078] Optionally, the running module is specifically used for: Run the test case code to register the stub function body of the stub function with the stub function dataset; Run the code under test and run the stub function. Based on the identifier of the stub function and the test case name, obtain the stub function pointer corresponding to the identifier of the stub function and the test case name from the stub function dataset, and run the stub function body based on the stub function pointer. Based on the running status and results of the stub function body, the unit test results of the code under test are determined.

[0079] The unit testing device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0080] The unit testing device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0081] The unit testing apparatus provided in this application embodiment can achieve… Figures 1 to 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0082] The unit testing apparatus provided in this application generates test case code for the code under test using a large language model based on a test case framework. Based on the test case code and the code under test, it obtains at least one target function identifier for the stub functions to be generated. Based on the stub function framework, it generates the stub functions corresponding to each target function identifier using the large language model. Running the test case code, the code under test, and the stub functions yields the unit test results for the code under test. Since at least one target function identifier for the stub functions to be generated can be obtained from the test case code and the code under test, and all stub functions are generated uniformly using the large language model, it eliminates the need for manual determination of the required stub functions and their individual implementation by the large language model. This improves the efficiency of stub function generation, thereby increasing testing efficiency and reducing labor costs.

[0083] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described unit testing method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0084] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0085] Figure 4 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application. The electronic device 400 includes, but is not limited to, components such as: a radio frequency unit 401, a network module 402, an audio output unit 403, an input unit 404, a sensor 405, a display unit 406, a user input unit 407, an interface unit 408, a memory 409, and a processor 410. The input unit 404 may include an image processor 4041 and a microphone 4042; the display unit 406 may include a display panel 4061; and the user input unit 407 may include a touch panel 4071 and other input devices (such as a keyboard) 4072.

[0086] Those skilled in the art will understand that the electronic device 400 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 410 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here. The memory 409 stores a program or instruction that can run on the processor. When the program or instruction is executed by the processor 410, it implements the various processes of the above-described unit test method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0087] 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 method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

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

[0089] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described unit testing method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

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

[0091] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0092] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0093] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A unit testing method, characterized in that, include: Based on the test case framework, test case code is generated for the code under test using a large language model; Based on the test case code and the code under test, obtain at least one target function identifier for the stub function to be generated; Based on the stub function framework, stub functions corresponding to the target function identifiers are generated through the large language model; Run the test case code, the code under test, and the stub function to obtain the unit test results of the code under test.

2. The method according to claim 1, characterized in that, The step of obtaining at least one target function identifier for the stub function to be generated based on the test case code and the code under test includes: Compile and link the test case code and the code under test to obtain at least one function identifier that failed to link. Based on the function declaration list of the stub function to be generated corresponding to the code under test, at least one target function identifier of the stub function to be generated is determined from the function identifiers of the failed linking.

3. The method according to claim 2, characterized in that, Before determining at least one target function identifier of the stub function to be generated from the function declaration list of the stub function corresponding to the tested code, the method further includes: Obtain the list of software packages that the code under test depends on; Extract the header files of each software package in the software package list; The header files of each software package are parsed to obtain a list of function declarations for which stub functions are to be generated.

4. The method according to any one of claims 1-3, characterized in that, The step of generating stub functions corresponding to each of the target function identifiers through the large language model based on the stub function framework includes: The stub function framework, each of the target function identifiers, and the third prompt word are input into the large language model. The large language model generates stub functions corresponding to each of the target function identifiers. The third prompt word is a prompt word used to guide the large language model to generate stub functions.

5. The method according to any one of claims 1-3, characterized in that, After running the test case code, the code under test, and the stub function to obtain the unit test results of the code under test, the method further includes: If the unit test result indicates that the test failed or the coverage is less than the coverage threshold, then the steps of generating test case code, running test case code, code under test, and stub functions are re-executed until the test is successful and the coverage is greater than or equal to the coverage threshold.

6. The method according to any one of claims 1-3, characterized in that, The process of running the test case code, the code under test, and the stub function to obtain the unit test results of the code under test includes: Run the test case code to register the stub function body of the stub function with the stub function dataset; Run the code under test and run the stub function. Based on the identifier of the stub function and the test case name, obtain the stub function pointer corresponding to the identifier of the stub function and the test case name from the stub function dataset, and run the stub function body based on the stub function pointer. Based on the running status and results of the stub function body, the unit test results of the code under test are determined.

7. The method according to any one of claims 1-3, characterized in that, The step of generating test case code for the code under test based on the test case framework and through a large language model includes: Based on the test case framework, a test case design document for the code under test is generated using the large language model; Based on the test case design document, test case code is generated for the code under test using the large language model.

8. The method according to claim 7, characterized in that, The step of generating a test case design document for the code under test based on the test case framework and the large language model includes: The test case framework, the code under test, and the first prompt word are input into the large language model. Based on the guidance of the first prompt word, the large language model generates a test case design document for the code under test according to the test case framework. The first prompt word is a prompt word used to guide the large language model to generate the test case design document. And / or, the step of generating test case code for the code under test based on the test case design document and the large language model includes: The test case design document, the code under test, and the second prompt word are input into the large language model. Based on the guidance of the second prompt word, the large language model generates test case code for the code under test according to the test case design document. The second prompt word is a prompt word used to guide the large language model to generate test case code.

9. A unit testing device, characterized in that, include: The test case generation module is used to generate test case code for the code under test based on the test case framework and a large language model. The function identifier acquisition module is used to acquire at least one target function identifier of the stub function to be generated based on the test case code and the code under test; The stub function generation module is used to generate stub functions corresponding to each of the target function identifiers based on the stub function framework and the large language model. The execution module is used to run the test case code, the code under test, and the stub function to obtain the unit test results of the code under test.

10. 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 testing method as described in any one of claims 1-8.

Images