Code testing method, code testing device, and computer storage medium

Abstract

The application provides a code testing method, a code testing device and a computer storage medium. The code testing method comprises the following steps: performing code mutation testing on a to-be-tested code to generate a target test case; mapping an initial compilation command maintained by a target test framework based on a compiler command mapping rule to obtain a target compilation instruction; calling a corresponding compiler based on the target compilation instruction to compile the to-be-tested code and the target test case to obtain a target execution file; and executing the target execution file in a virtual hardware model integrated in the target test framework and generating a test report corresponding to the to-be-tested code based on an execution result. The code testing efficiency is improved by the code testing method.

Description

Technical Field

[0001] This application relates to the field of intelligent robots, and in particular to a code testing method, a code testing device, and a computer storage medium. Background Technology

[0002] In the field of embedded software development, embedded software code testing is a core component for ensuring software quality. Its efficiency and effectiveness directly determine the time-to-market and market competitiveness of embedded products. Among related technologies, mainstream frameworks in embedded software testing, in order to lower the barrier to entry, pre-set a set of editing commands. Therefore, these frameworks are only suitable for testing software code developed in specific environments. However, embedded development scenarios involve various heterogeneous compilers with significant differences in their underlying characteristics. Switching compilers completely erases existing compilation configurations, requiring developers to manually reconfigure all compilation options, macro definitions, and header file paths. This makes it difficult to reuse the testing framework across different scenarios, reducing code testing efficiency.

[0003] Furthermore, the generation and maintenance of test cases for embedded software currently rely primarily on manual processes, resulting in inefficiency, incomplete coverage, and a high risk of errors. During the test case generation phase, testers must manually analyze software requirements documents and source code to design test cases that fit the testing scenarios. This process is time-consuming and labor-intensive, failing to keep pace with the rapid iterative development of embedded software and further reducing code testing efficiency.

[0004] In conclusion, the related technologies suffer from low code testing efficiency. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a code testing method, a code testing apparatus, and a computer storage medium.

[0006] To address the aforementioned technical problems, this application provides a code testing method, comprising: performing code mutation testing on the code to be tested to generate target test cases; mapping the initial compilation commands maintained by the target testing framework based on compiler command mapping rules to obtain target compilation instructions; calling the corresponding compiler based on the target compilation instructions to compile the code to be tested and the target test cases to obtain a target executable file; executing the target executable file in a virtual hardware model integrated in the target testing framework, and generating a test report corresponding to the code to be tested based on the execution results.

[0007] The process of performing code mutation testing on the code to be tested and generating target test cases includes: identifying function input boundaries in the code to be tested; generating multiple initial test cases based on the function input boundaries; modifying the code to be tested according to preset mutation rules to generate multiple mutants; running the initial test cases for each mutant to obtain running results, wherein the running results include the survival status of each mutant; and determining the target test cases based on the running results.

[0008] The step of determining the target test case based on the running results includes: identifying surviving mutants among the multiple mutants based on the running results, wherein the surviving mutants pass all tests corresponding to the initial test cases; generating new test cases by analyzing the surviving mutants; and determining the new test cases and all the initial test cases as the target test cases.

[0009] The process of identifying function input boundaries in the code under test includes: extracting the parameter types corresponding to the input parameters in the code under test and the range descriptions in the comments of the code under test; determining the function input boundaries based on the parameter types and the range descriptions; and / or, describing the conditional statements in the code under test and determining the function input boundaries based on the numerical constants in the conditional statements.

[0010] The method further includes: performing anomaly prediction on the code to be tested using dynamic symbols to obtain anomaly prediction results; and determining the target test cases based on the anomaly prediction results.

[0011] Specifically, mapping the initial compilation commands maintained by the target testing framework based on compiler command mapping rules to obtain target compilation instructions includes: obtaining the attribute information of the target compiler from the configuration file corresponding to the code to be tested; activating the compiler command mapping rules in the abstraction layer of the target testing framework based on the attribute information; mapping the initial compilation commands to the target compilation instructions based on the compiler command mapping rules, and issuing the target compilation instructions to the target compiler.

[0012] The process of calling the corresponding compiler based on the target compilation instructions to compile the code to be tested and the target test cases to obtain the target executable file includes: traversing the code to be tested and identifying the target instrumentation points in the code to be tested; inserting marker code at the target instrumentation points to obtain the target test code; and compiling the target test code and the target test cases to obtain the target executable file.

[0013] The process of identifying the target instrumentation point in the code to be tested includes: identifying function definition statements and conditional jump statements in the code to be tested; determining multiple initial instrumentation points based on the function definition statements and the conditional jump statements; and removing the initial instrumentation points whose corresponding code paths are preset paths to obtain the target instrumentation point.

[0014] To address the aforementioned technical problems, this application also provides a code testing apparatus, which includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the code testing method described above.

[0015] To address the aforementioned technical problems, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the steps in the code testing method described above.

[0016] Compared with existing technologies, the beneficial effects of this application are as follows: By performing code mutation testing on the code to be tested and generating target test cases, the efficiency of code testing is improved by automatically generating target test cases instead of manually generating test cases. In addition, by mapping the initial compilation commands maintained by the target testing framework based on compiler command mapping rules to obtain target compilation instructions, the adaptation to different compilers is achieved. It is only necessary to map the initial compilation commands maintained by the target testing framework and call the corresponding compiler based on the target compilation instructions to compile the code to be tested and the target test cases to complete the subsequent code testing work, which further improves the efficiency of code testing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart illustrating an embodiment of the code testing method provided in this application; Figure 2 This is an example of the code to be tested provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the code testing device provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation

[0018] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It is to be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, it should be noted that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, not all structures. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] The terms “first,” “second,” etc. (if applicable) in this application are used to distinguish different objects, not to describe a particular order. Furthermore, the terms “comprising” and “featured,” and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] The code testing method of this application is applied to a code testing device, which can be a server, a terminal device, or a system in which the server and the terminal device cooperate with each other. Accordingly, the various parts of the code testing device, such as each unit, subunit, module, and submodule, can all be set in the server, all in the terminal device, or separately in the server and the terminal device.

[0022] Furthermore, the aforementioned server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules, such as software or software modules used to provide distributed server functionality, or as a single software program or software module; no specific limitations are made here.

[0023] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the code testing method provided in this application.

[0024] Specifically, such as Figure 1 As shown, the specific steps are as follows: Step S11: Perform code mutation testing on the code to be tested to generate target test cases.

[0025] In this embodiment of the application, a general testing framework, namely the target testing framework, is built on the ceedling testing framework. The ceedling testing framework is based on Ruby (a programming language) and integrates Unity (which provides rich assertion macros for verifying whether the behavior of the code is as expected) and CMock (a tool for automatically generating mock objects for isolating the code to be tested from external dependencies).

[0026] The target testing framework integrates an additional code testing command on top of the ceedling testing framework. The code testing command is used to perform code mutation testing on the code to be tested and automatically generates target test cases, eliminating the need for manual test case generation and improving code testing efficiency.

[0027] In an optional embodiment, code mutation testing is performed on the code to be tested to generate target test cases, including: identifying function input boundaries in the code to be tested; generating multiple initial test cases based on the function input boundaries; modifying the code to be tested according to preset mutation rules to generate multiple mutants; running the initial test cases for each mutant to obtain running results, wherein the running results include the survival status of each mutant; and determining the target test cases based on the running results.

[0028] In this embodiment of the application, when performing code mutation testing, the function input boundary is first identified. The function input boundary function is the limit value of the range or condition of the input parameter allowed by the function in the code under test when it is defined, as well as the point adjacent to these limit values.

[0029] Function input boundaries are an important basis for test cases. By testing function input boundaries, common programming errors in the code under test can be efficiently discovered.

[0030] Based on the function input boundaries, list multiple boundary values ​​corresponding to each input parameter, determine multiple input combinations, determine the expected output for each input combination, and generate multiple initial test cases based on the multiple input combinations and the corresponding expected outputs.

[0031] The process of identifying function input boundaries in the code under test includes: extracting the parameter types corresponding to the input parameters in the code under test and the range descriptions in the comments of the code under test; determining the function input boundaries based on the parameter types and the range descriptions; and / or, scanning the conditional statements in the code under test and determining the function input boundaries based on the numerical constants in the conditional statements.

[0032] In this embodiment, the function input boundaries in the code under test are identified using the following methods: Method 1: By analyzing the parameter types of the input parameters and the range described in the comments written by the developer, the function input boundaries can be directly obtained. The parameter types of the input parameters are such as int, float, uint8_t, etc. Some parameter types implicitly include the basic range. For example, uint8_t implicitly exposes the corresponding input range as 0~255. When writing the code to be tested, the developer will add comments (function descriptions) to define the range of input values ​​in the comments.

[0033] Method 2: Static scan the conditional statements in the function and extract the constant values ​​in the comparison expressions related to the input parameters. These constant values ​​are often also boundary conditions. For example, if a conditional statement in the function is "if(x<0||x>100)", the constant values ​​in the comparison expression are 0 and 100. 1 and 100 can be used as the function input boundaries.

[0034] In practical applications, one of the above methods can be used to identify the function input boundary, or two of the above methods can be used simultaneously to identify the function input boundary.

[0035] Alternatively, symbolic execution tools (such as KLEE) can be used to represent input parameters as symbolic variables, simulate the function paths of the program executing the code under test, collect the conditions that trigger different branches, and thus derive boundary values. Symbolic execution tools explore all possible execution paths, record the constraints of each path, solve the constraints to obtain the input values ​​that can trigger each path, and directly generate a set of initial test cases that can cover all paths.

[0036] After generating multiple initial test cases, code mutation testing is used to determine whether the multiple initial test cases are reliable and sufficient.

[0037] The code to be tested is modified according to a preset mutation rule. Minor, syntactically correct changes are made to the code to be tested to simulate common programming errors and generate multiple mutants. Modifications to the code to be tested include changing operators, modifying constants, and deleting statements.

[0038] Please see Figure 2 , Figure 2 This is an example of the test code provided in this application, such as... Figure 2 As shown, the following mutants were obtained by making different modifications to the code to be tested: Mutant 1: change a<1 to a<0; Mutant 2: change the return value -1 to 0; Mutant 3: delete the range judgment condition of b.

[0039] For each mutant, after compiling the initial test cases and the mutant, the test is executed to determine the survival status of each mutant, i.e. the running result. Based on the running result, the target test cases are determined.

[0040] The survival state is divided into the killed state and the live state. The mutant in the killed state refers to the failure of at least one initial test case, that is, the code under test has been changed. The mutant in the live state refers to the success of all initial test cases, that is, no change has been detected in the code under test.

[0041] Determining the target test case based on the running results includes: identifying surviving mutants among the multiple mutants based on the running results, wherein the surviving mutants pass all tests corresponding to the initial test cases; generating new test cases by analyzing the surviving mutants; and determining the new test cases and all the initial test cases as the target test cases.

[0042] In this embodiment, surviving mutants are analyzed to determine the initial test cases. New test cases are then added to ensure the modified test cases can detect the mutation. The addition of new test cases and the original initial test cases determine the target test cases that can kill all mutants.

[0043] Alternatively, iterative updates can be performed by repeatedly modifying test cases, running mutants and test cases, until a target test case set capable of killing all mutants is generated.

[0044] In an optional embodiment, the method further includes: performing anomaly prediction on the code to be tested using dynamic symbols to obtain anomaly prediction results; and determining the target test cases based on the anomaly prediction results.

[0045] By using dynamic symbols, such as symbolic execution tools, the possible types of exceptions in the code can be identified, i.e., the exception detection results. Specifically, in ceedling, CMock automatically generates stub functions of dependent modules and injects exception detection logic.

[0046] The anomaly detection includes types such as null pointer exceptions, length boundary exceptions, numerical range exceptions, and return value exceptions. It identifies potential risks in the code under test, such as the possibility of inputting a null pointer or input length exceeding the limit, input exceeding the data range, and return value exceptions. The detected anomaly conditions are transformed into specific test inputs, and test cases are automatically generated.

[0047] When a null pointer exception is detected, test cases containing a null pointer input parameter are automatically generated to verify the function's fault tolerance capability for null pointers. When a length boundary exception is detected, test cases are generated based on the detected boundary value, such as test cases for data lengths of 7 (normal), 8 (boundary), and 9 (out of bounds), covering different length scenarios. The exception detection results are used as assertion conditions for the test cases and written into the parameterized test template to ensure that the test cases can verify the function's exception handling logic.

[0048] Step S12: Map the initial compilation commands maintained by the target test framework based on the compiler command mapping rules to obtain the target compilation instructions.

[0049] In this embodiment of the application, compiler command mapping rules are written through Ruby templates in the abstraction layer of the ceedling framework to achieve standardized conversion of compilation commands.

[0050] The ceedling framework's default compilation commands are only for a single compiler and cannot be adapted to different compilers across toolchains.

[0051] When a compilation command is triggered, the initial compilation command maintained by the target testing framework is mapped based on the compiler command mapping rules, and mapped to the compilation instructions corresponding to the target compiler specified by the code to be tested.

[0052] In an optional embodiment, the initial compilation commands maintained by the target testing framework are mapped based on compiler command mapping rules to obtain target compilation instructions, including: obtaining attribute information of the target compiler from the configuration file corresponding to the code to be tested; activating the compiler command mapping rules in the abstraction layer of the target testing framework based on the attribute information; mapping the initial compilation commands to the target compilation instructions based on the compiler command mapping rules, and issuing the target compilation instructions to the target compiler.

[0053] In this embodiment of the application, when the test compilation instruction is triggered, the toolchain configuration in the configuration file (project.yml) is read first, that is, the attribute information of the target compiler corresponding to the code to be tested.

[0054] When the target compiler's attribute information is detected (when the target compiler is Keil / IAR), the mapping rules are automatically activated, the input compilation instructions are parsed, the corresponding mapping relationship in the compiler command mapping rules is matched, the compilation instructions are converted into target compilation instructions corresponding to the target compiler, and the target compilation instructions are sent to the target compiler to call the target compiler for compilation.

[0055] In an optional embodiment, multiple debugger control protocols (such as J-Link's RTT protocol and ST-Link's SWD protocol) are also integrated into the configuration file through a plug-in mechanism, standardizing the debugging interface and eliminating the need to rely on specific burning tools to adapt to multiple debuggers.

[0056] Step S13: Based on the target compilation instructions, call the corresponding compiler to compile the code to be tested and the target test cases to obtain the target executable file.

[0057] In this embodiment of the application, after the target compiler completes the compilation, it outputs a target executable file in a uniform format for use in subsequent testing processes.

[0058] Step S14: Execute the target executable file in the virtual hardware model integrated in the target testing framework, and generate a test report corresponding to the code to be tested based on the execution result.

[0059] In this embodiment, a QEMU emulator is integrated into the ceedling testing framework to form a target testing framework. The target testing framework is an open-source, general-purpose emulator capable of simulating a complete computer system, including hardware components such as CPU and memory. Within the target testing framework, QEMU provides one or more virtual hardware environments, i.e., virtual hardware models, allowing test code to run without relying on real chips.

[0060] Configure one or more virtual hardware environments in the configuration file, which means configuring various parameters of the real chip, such as CPU architecture, peripheral interfaces, memory distribution and other parameters.

[0061] Pure software testing can be achieved by using a virtual hardware model to create a virtual runtime environment, saving hardware resources, adapting to different hardware platforms, and improving code testing efficiency.

[0062] Optionally, peripheral behavior can also be simulated through CMock in the ceedling test framework. The peripheral status (such as GPIO level, UART data transmission and reception, and CAN message) can be recorded in real time through virtual registers in CMock, supporting real-time debugging signal tracing.

[0063] After executing the target executable file, a corresponding test report is generated based on the execution results.

[0064] In this embodiment of the application, an automatic defect tracking interface is integrated into the target testing framework. When a test case fails, the failure details (such as the name of the failed test case, error information, and code location) are automatically extracted, a defect ticket is created in the test report, and related code submission records are associated, thereby realizing a closed loop of testing and defect management.

[0065] The automated processes of Continuous Integration and Continuous Delivery / Deployment are deeply integrated into the target testing framework, thereby achieving full-process automation of code submission, automated build, automated testing, and automated deployment / defect tracking.

[0066] Dynamic coverage is an important metric in test reports. Dynamic coverage measures which parts of the code under test were actually executed during the test case's execution, such as which functions were called, which branches were traversed, and which statements were executed. If the coverage is low, it means that a large part of the code has never been tested, and potential defects may be hidden in it. Therefore, dynamic coverage is used to verify the test integrity of the code under test.

[0067] The compiler is invoked based on the target compilation instructions to compile the code to be tested and the target test cases to obtain the target executable file. This includes: traversing the code to be tested and identifying the target instrumentation points in the code to be tested; inserting marker code at the target instrumentation points to obtain the target test code; and compiling the target test code and the target test cases to obtain the target executable file.

[0068] In the embodiments of this application, instrumentation during the compilation process is the basis for dynamic coverage statistics. Instrumentation refers to inserting lightweight marker code into the code to be tested to obtain target test code. The target test code is then combined with target test cases to obtain the target executable file.

[0069] When the test file with inserted marker code is run, the counter updates its count value when the marker code is reached, and the dynamic coverage is finally generated based on the counter's count value.

[0070] The process of identifying the target instrumentation point in the code to be tested includes: identifying function definition statements and conditional jump statements in the code to be tested; determining multiple initial instrumentation points based on the function definition statements and the conditional jump statements; and removing the initial instrumentation points whose corresponding code paths are preset paths to obtain the target instrumentation point.

[0071] In this embodiment, the initial instrumentation point is first identified. The identification logic for the initial instrumentation point includes: identifying function entry points and branch jump points; identifying function definition statements, such as `int add (int a, int b)`, by parsing the abstract syntax tree of the code; inserting marker code at the position of the definition statement, such as the first line of the function; scanning conditional jump statements in the code to be tested, including if / else, switch / case, for / while, etc., and inserting marker code at the entry point of each branch corresponding to the conditional jump statement.

[0072] Simultaneously, non-target code is excluded. For example, some code paths do not need or cannot be instrumented. When the target test framework is initialized, the configuration file is parsed and an exclusion list is established. The code paths recorded in the exclusion list are preset paths. The initial instrumentation points in the preset paths are removed, and the remaining initial instrumentation points are the target instrumentation points. Instrumentation is performed at the positions of the target instrumentation points before the actual coding.

[0073] The relevant counting uses full instrumentation, inserting a mark for each line of code. However, the embodiment of this application only generates marks for function entry points and branch jump points, greatly reducing the number of instrumentation points. Furthermore, the marked code only contains simple counting variables and has no complex coverage data structure, thus reducing the memory usage of a single mark.

[0074] In another alternative embodiment, address mapping is used instead of raw data storage. The memory address of the instrumentation point is used as the key, and the coverage count is used as the value, stored in a memory-mapped table. This eliminates the need to store redundant information such as the line number and function name of the instrumentation point. Coverage data is updated in real-time during testing. After the test, only non-zero count data is written to the storage medium; zero-count data is not stored. Differential encoding compression is used on the data in the memory-mapped table to further reduce storage footprint; for example, for consecutive address counts, only the first address and the difference are stored.

[0075] Through the above embodiments, code mutation testing is performed on the code to be tested, and target test cases are generated. By automatically generating target test cases instead of manually generating test cases, the efficiency of code testing is improved. In addition, based on the compiler command mapping rules, the initial compilation commands maintained by the target testing framework are mapped to obtain target compilation instructions, which realizes the adaptation of different compilers. It is only necessary to map the initial compilation commands maintained by the target testing framework, and then call the corresponding compiler based on the target compilation instructions to compile the code to be tested and the target test cases to complete the subsequent code testing work, which further improves the efficiency of code testing.

[0076] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0077] To implement the above code testing method, this application also proposes a code testing device, for details please refer to [link / reference needed]. Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the code testing device provided in this application.

[0078] The code testing device 400 of this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.

[0079] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the code testing method described in the above embodiment.

[0080] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.

[0081] This application also provides a computer storage medium; please refer to the following: Figure 4 , Figure 4 This is a schematic diagram of a computer storage medium according to an embodiment of the present application. The computer storage medium 600 stores a computer program 61, which, when executed by a processor, is used to implement the code testing method of the above embodiment.

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

[0083] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A code testing method, characterized in that, The code testing methods include: Perform code mutation testing on the code to be tested and generate target test cases; Based on the compiler command mapping rules, the initial compilation commands maintained by the target testing framework are mapped to obtain the target compilation instructions; Based on the target compilation instructions, the corresponding compiler is invoked to compile the code to be tested and the target test cases to obtain the target executable file; The target executable file is executed in the virtual hardware model integrated in the target testing framework, and a test report corresponding to the code to be tested is generated based on the execution results.

2. The code testing method according to claim 1, characterized in that, Perform code mutation testing on the code to be tested, and generate target test cases, including: Identify the function input boundaries in the code to be tested; Multiple initial test cases are generated based on the function input boundaries; The code to be tested is modified according to a preset mutation rule to generate multiple mutants; For each mutant, the initial test case is run to obtain the running results, wherein the running results include the survival status of each mutant; The target test cases are determined based on the results of the test.

3. The code testing method according to claim 2, characterized in that, The target test cases are determined based on the execution results, including: Based on the running results, surviving mutants are determined from among the multiple mutants, wherein the surviving mutants pass all tests for the initial test cases; New test cases are generated by analyzing the surviving mutants; The new test case and all the initial test cases are identified as the target test case.

4. The code testing method according to claim 2, characterized in that, Identifying function input boundaries in the code under test includes: Extract the parameter types corresponding to the input parameters in the code under test and the range descriptions in the comments of the code under test; determine the function input boundaries based on the parameter types and the range descriptions; and / or, Scan the conditional statements in the code to be tested, and determine the function input boundaries based on the numerical constants in the conditional statements.

5. The code testing method according to claim 3, characterized in that, The method further includes: Anomaly prediction is performed on the code under test using dynamic symbols to obtain anomaly prediction results; The target test cases are determined based on the anomaly prediction results.

6. The code testing method according to claim 1, characterized in that, Based on the compiler command mapping rules, the initial compilation commands maintained by the target testing framework are mapped to obtain the target compilation instructions, including: Obtain the target compiler's attribute information from the configuration file corresponding to the code to be tested; Based on the attribute information, the compiler command mapping rule is activated in the abstraction layer of the target testing framework; Based on the compiler command mapping rules, the initial compilation command is mapped to the target compilation instruction, and the target compilation instruction is sent to the target compiler.

7. The code testing method according to claim 1, characterized in that, Based on the target compilation instructions, the corresponding compiler is invoked to compile the code to be tested and the target test cases, resulting in a target executable file, including: Traverse the code to be tested and identify the target instrumentation points in the code to be tested; Insert marker code at the target insertion point to obtain the target test code; The target test code and the target test cases are compiled to obtain the target executable file.

8. The code testing method according to claim 7, characterized in that, Identify the target instrumentation points in the code to be tested, including: Identify function definition statements and conditional jump statements in the code to be tested; Multiple initial instrumentation points are determined based on the function definition statement and the conditional jump statement; The initial instrumentation points with corresponding code paths of the preset paths are removed to obtain the target instrumentation points.

9. A code testing device, characterized in that, The code testing device includes a memory and a processor, wherein the memory is coupled to the processor; The memory is used to store program data, and the processor is used to execute the program data to implement the code testing method according to any one of claims 1 to 8.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the steps of the code testing method as described in any one of claims 1 to 8.

Images