Code testing method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application relate to the technical field of software testing, and disclose a code testing method and device, electronic equipment and a storage medium. The code testing method comprises the following steps: when a function replacement instruction of test code is read, a preset function replacement interface is called according to the function replacement instruction, the function replacement interface is used to replace a first part of binary code of a to-be-tested function after compilation with long call binary instructions of a replacement function; binary code of the to-be-tested function after replacement is executed to obtain an execution result of the replacement function; and the execution result of the replacement function is returned to the to-be-tested function. Thus, the related calling function can be dynamically replaced, the test logic that cannot be covered originally can be virtually generated, and the code coverage is improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of software testing technology, and in particular to a code testing method, apparatus, electronic device and storage medium. Background Technology

[0002] Software testing, as a crucial part of the software development process, can be categorized by scope, such as unit testing and functional testing. To improve code coverage, many high-level programming languages ​​have proposed testing frameworks based on mock techniques. These frameworks use reflection or polymorphism to simulate function inputs and outputs. However, low-level programming languages, lacking support for reflection and polymorphism, typically achieve this by replacing the relevant input / output functions of the function under test during the code compilation preprocessing stage.

[0003] However, even after replacing the code compilation preprocessing stage, the code coverage of complex functions is still relatively low during software testing. Summary of the Invention

[0004] The purpose of this invention is to provide a code testing method, apparatus, electronic device, and storage medium that enables dynamic replacement of relevant calling functions, virtualizes test logic that was previously not covered, and improves code coverage.

[0005] To achieve the above objectives, embodiments of the present invention provide a code testing method, comprising: upon reading a function replacement instruction of test code, calling a preset function replacement interface according to the function replacement instruction, wherein the function replacement interface is used to replace the first part of the compiled binary code of the function under test with a long call binary instruction of the replacement function; executing the replaced binary code of the function under test to obtain the execution result of the replacement function; and returning the execution result of the replacement function to the function under test.

[0006] To achieve the above objectives, embodiments of the present invention also provide a code testing device, comprising: a replacement module, configured to, upon reading a function replacement instruction of test code, call a preset function replacement interface according to the function replacement instruction, wherein the function replacement interface is configured to replace the first part of the compiled binary code of the function under test with a long call binary instruction of the replacement function; an execution module, configured to read and execute the replaced binary code of the function under test to obtain the execution result of the replacement function; and a result return module, configured to return the execution result of the replacement function to the function under test.

[0007] To achieve the above objectives, embodiments of the present invention also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the code testing method as described above.

[0008] To achieve the above objectives, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the code testing method described above.

[0009] The code testing method provided in this invention, during the execution of test code, if a function substitution instruction is read in the test code, a preset function substitution interface is called according to the function substitution instruction. This causes the first part of the compiled binary code of the function under test to be replaced with the long call binary instruction of the substitution function. Thus, when the compiled binary code of the function under test is read and executed, the call to the substitution function is dynamically redirected, and the execution result of the substitution function is obtained. Then, by returning the execution result of the substitution function to the function under test, the execution result is presented externally as the execution result of the function under test, making the test result unaware of the substitution. Furthermore, the setting of the substitution function is not limited by the compilation process of the low-level language, allowing for flexible and dynamic setting of the substitution function to simulate corresponding test scenarios, especially the abnormal scenarios targeted by the function under test. This ensures that all logic of the function under test can be executed, improving code coverage. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1 This is a flowchart of a code testing method provided in one embodiment of the present invention;

[0012] Figure 2 This is a flowchart of a code testing method including the step of determining an address based on a function substitution instruction, provided in another embodiment of the present invention;

[0013] Figure 3 This is a flowchart of a step code testing method including pre-stored information in storage space, provided in another embodiment of the present invention;

[0014] Figure 4This is a flowchart of a code testing method that includes updating the latest identifier to a global variable, provided in another embodiment of the present invention;

[0015] Figure 5 This is a flowchart of a code test method including the step of reading the stack register provided in another embodiment of the present invention;

[0016] Figure 6 This is a flowchart of a code testing method provided in another embodiment of the present invention, which includes the step of writing the address of the next instruction into the storage space and binding it with an identifier;

[0017] Figure 7 This is a schematic diagram of the structure of the code testing equipment provided in another embodiment of the present invention;

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device provided in another embodiment of the present invention. Detailed Implementation

[0019] As can be seen from the background technology, low-level programming languages, such as C, have very limited effect on improving the code coverage of complex functions by replacing the function under test during the code compilation preprocessing stage.

[0020] Analysis revealed that one of the reasons for the above problem is that replacing the function under test during the code compilation preprocessing stage will cause all places in the compiled binary file that need to execute the function under test to be uniformly replaced. Although it is possible to cover some previously uncovered scenarios by replacing the function, the calls to the replaced function in other scenarios will also be affected, thus affecting code coverage. This effect is particularly obvious in complex functions.

[0021] To address the aforementioned problems, this invention provides a code testing method, comprising: upon reading a function replacement instruction of test code, invoking a preset function replacement interface according to the function replacement instruction, wherein the function replacement interface is used to replace the first part of the compiled binary code of the function under test with a long call binary instruction of the replacement function; executing the replaced binary code of the function under test to obtain the execution result of the replacement function; and returning the execution result of the replacement function to the function under test.

[0022] The code testing method provided in this invention, during the execution of test code, if a function substitution instruction is read in the test code, a preset function substitution interface is called according to the function substitution instruction. This causes the first part of the compiled binary code of the function under test to be replaced with the long call binary instruction of the substitution function. Thus, when the compiled binary code of the function under test is read and executed, the call to the substitution function is dynamically redirected, and the execution result of the substitution function is obtained. Then, by returning the execution result of the substitution function to the function under test, the execution result is presented externally as the execution result of the function under test, making the test result unaware of the substitution. Furthermore, the setting of the substitution function is not limited by the compilation process of the low-level language, allowing for flexible and dynamic setting of the substitution function to simulate corresponding test scenarios, especially the abnormal scenarios targeted by the function under test. This ensures that all logic of the function under test can be executed, improving code coverage.

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of the present invention to enable the reader to better understand the present invention. However, the technical solutions claimed in the present invention can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0024] The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined with and referenced by each other without contradiction.

[0025] One embodiment of the present invention provides a code testing method applicable to electronic devices such as computers and servers. The process is as follows: Figure 1 As shown.

[0026] Step 101: When the function replacement instruction of the test code is read, the preset function replacement interface is called according to the function replacement instruction. The function replacement interface is used to replace the first part of the binary code of the function under test after compilation with the long call binary instruction of the replacement function.

[0027] In this embodiment, the function replacement interface is a pre-generated function. When the function replacement interface is called, the pre-generated function will be executed, that is, the first part of the compiled binary code of the function under test will be replaced with the long call binary instruction of the replacement function. In other words, the execution jumps to the replacement function instead of the binary code of the function under test. The binary code file of the function under test is obtained by preprocessing the function under test. The replacement function is a function constructed for scenarios that cannot be covered by simple code testing of the function under test. For example, if the statement of the function under test involves memory allocation failure, simple code testing is unlikely to encounter memory allocation failure, making it difficult to run the memory allocation failure handling logic in the function under test. The replacement function can be designed for this scenario, that is, artificially constructing a function that will return failure, so that the failure result is used as the result of memory allocation, triggering the execution of the memory allocation failure handling logic.

[0028] It should be noted that the function substitution instructions in the test code are part of the test code written to test special scenarios that cannot be covered currently, and are implemented by developers according to the actual situation; the first part refers to a character segment of a certain length starting from one character, the length of which is related to the operating system type and hardware type of the electronic device executing the code testing method provided in this invention, such as a central processing unit (CPU) configured with a Windows or Linux operating system and using an x64 architecture. When performing code testing on an electronic device (CPU), the long call instruction consists of 12 bytes (0x48, 0xb8, 8-byte target address, 0xff, 0xd0), comprising two CPU instructions, corresponding to the assembly code mov$fun,%rax;call*%rax. Since x64 requires a 16-byte stack alignment, the length of the header is set to 16 bytes. The 4 bytes not occupied by the long call instruction can be filled with preset content. Specifically, a flag can be bound to the long call to distinguish different function replacements during the test. This flag is filled into the 4 bytes not occupied by the long call instruction, resulting in a flag length of 4 bytes, which can be used for a maximum of 2... 32 The function replacement process is marked.

[0029] In some embodiments, a pre-packaged function replacement function is provided. Testing specific scenarios only requires inputting the addresses of the function to be tested and the replacement function, thereby reducing the amount of code developers need to write during the testing process. For example, Figure 2 As shown, step 101 can be achieved through the following steps:

[0030] Step 1011: Based on the function substitution instructions, determine the address of the binary code of the function under test after compilation and the address of the binary code of the function to be substituted after compilation.

[0031] In some cases, the function substitution instruction carries the address of the compiled binary code of the function under test and the address of the compiled binary code of the substitution function. Therefore, by parsing the function substitution instruction, the addresses of the compiled binary code of the function under test and the substitution function can be determined.

[0032] In other examples, the function substitution instruction carries an address or information indicating that address, which points to a memory space storing the addresses of the compiled binary code of the function under test and the compiled binary code of the substitution function. Therefore, by reading the information at that address, the addresses of the compiled binary code of the function under test and the compiled binary code of the substitution function can be determined.

[0033] Step 1012: Take the address of the binary code of the function under test and the address of the binary code of the replacement function as input to the function replacement interface, call the function replacement interface to add write permission to the address of the binary code of the function under test, and replace the first part of the binary code at the address of the binary code of the function under test with a long call binary instruction containing the address of the binary code of the replacement function.

[0034] It's important to note that the compiled binary code of the function under test is typically located in the code segment of memory, which is not writable by default. Therefore, to perform header replacement on the compiled binary code, it's necessary to modify its address permissions, adding write permissions so that long-call binary instructions can be written into the header of the compiled binary code. Taking Linux as an example, the `mprotect` function can be used to modify the address protection attributes of the compiled binary code, thus adding write permissions.

[0035] For complex functions, they may be designed to handle various abnormal situations, such as insufficient memory or disk space, software or hardware malfunctions, and interface errors. Based on the encapsulated interface functions provided in this embodiment, dynamic replacement of related functions can be achieved through simple address input, simulating various abnormal scenarios. This is more concise and easier to implement, ensuring that all logic of the function under test can be executed, greatly improving the code coverage of the function under test, and thus significantly improving the quality of software delivery.

[0036] Furthermore, in other embodiments, other functionalities can be extended to the function replacement interface. For example, the caller of the function replacement interface can customize the timing of using the function under test and the replacement function, such as replacing the first n calls to the function under test with long calls to the replacement function, and not replacing the (n+1)th to (n+m)th calls; or, the caller of the function replacement interface can customize the timing of stopping the replacement, such as automatically resuming the replacement after a test case is executed to avoid affecting other test cases.

[0037] Step 102: Execute the binary code of the replaced function to be tested to obtain the execution result of the replaced function.

[0038] In this embodiment, the binary code of the replaced function to be tested will first read the long call instruction in the beginning part, and then jump to execute the replacement function to obtain the execution result of the replacement function.

[0039] Step 103: Return the execution result of the replacement function to the function under test.

[0040] In this embodiment, the execution result of the replacement function is returned to the function under test, so that the next instruction can be executed based on the result.

[0041] Compared to simulating the actual runtime environment of the code, such as when the function under test needs to retrieve data from a network interface (where the interface is a function called internally by the function under test), testing this method might require writing test code to build a server for the network interface and realistically simulating the scenario where the function under test returns preset data when calling the network interface. By replacing the network interface function with a local function when the function under test runs, and directly returning the preset data to the function under test, no extra work is needed. This method can still simulate the possible execution logic, greatly simplifying the test code, reducing the workload of writing test code, and thus reducing software development costs.

[0042] Considering that the function under test may contain multiple scenarios that cannot be directly covered, requiring multiple function replacements, an identifier is added to the replacement process to better distinguish between different function replacements. This allows for simplification of restoring the compiled binary code of the function under test through the identifier. Based on this, in some embodiments, the function replacement interface is also used to bind an identifier to the beginning of the compiled binary code of the function under test, such as... Figure 3 As shown, the code testing methods also include:

[0043] Step 104: Record the address of the binary code of the function to be tested after compilation, the address of the binary code of the replacement function after compilation, the header and the identifier in the preset storage space.

[0044] In this embodiment, the preset storage space can be the specific memory storage space of the electronic device, or it can be a data table created in an external database, etc.

[0045] It should be noted that, Figure 3 Taking step 104 as an example, which is executed after step 101 and before step 102, in other examples, step 104 can also be implemented simultaneously with step 102, which will not be elaborated here.

[0046] Accordingly, step 101 includes: calling the function replacement interface according to the function replacement instruction, assigning an identifier to the function under test, and modifying a portion of the binary code of the function under test after compilation to the identifier.

[0047] It should also be noted that the bytes modified to identify the identifier in the compiled binary code of the function under test can be bytes in the header or bytes after the header. In particular, the long call instruction and the identifier can jointly form the header, and the length of the header meets the stack alignment requirements of different hardware architectures. For example, in the x64 architecture that requires 16-byte alignment, after deducting the 4 bytes occupied by the long call instruction and the 4 bytes occupied by the identifier, the header length is 16 bytes. Of course, in other architectures or in other cases, the header length can also be the number of aligned bytes * k, where k is a positive integer. The bytes in the header other than the 12 bytes occupied by the long call instruction can be occupied by the identifier, etc.

[0048] In particular, in some embodiments, for the convenience of managing the identifiers, such as Figure 4 As shown, the code testing methods also include:

[0049] Step 105: Update the latest identifier to the global variable.

[0050] In this embodiment, the storage space also includes global variables for recording the current identifier. These global variables are stored in the aforementioned preset storage space, along with information related to the function under test, the replacement function, etc. The data in the preset storage space is stored using a hash table or an array.

[0051] In this way, by using global variables to represent the current replacement, and by simply modifying the value of the global variables, different forms of replacement can be extended. For example, after replacing the beginning of the function under test, the beginning of the replacement function can be replaced with the address of another replacement function, or the beginning of the function under test can be replaced with the addresses of two different replacement functions at different times.

[0052] For relatively complex functions, the testing process may involve calls from other functions. Therefore, in addition to testing specific scenarios, it is also necessary to ensure the integrity of the original code of the function under test. Based on this, in some embodiments, such as... Figure 5As shown, step 102 can be achieved through the following steps:

[0053] Step 1021: Read the address of the compiled binary code of the function under test recorded in the stack register.

[0054] Step 1022: Based on the address of the binary code of the function under test after compilation, read the identifier carried in the binary code of the replaced function under test after compilation.

[0055] Step 1023: Query the storage space according to the identifier, determine the first part, and write the first part back to the compiled binary code of the function under test.

[0056] Step 1024: Based on the address of the binary code compiled by the function under test, read the address of the binary code compiled by the replacement function and perform a long jump to execute the binary code compiled by the replacement function to obtain the execution result of the replacement function.

[0057] In order to ensure that after a long call jumps to execute the replacement function, it can quickly jump to the next instruction of the function under test, in some embodiments, such as Figure 6 As shown, after reading the address of the compiled binary code of the function under test recorded in the stack register during step 102, the following steps are also included:

[0058] Step 1025: Determine the address of the next instruction of the function under test based on the address of the binary code of the function under test after compilation.

[0059] Step 1026: Write the address of the next instruction into the storage space and bind it to the identifier.

[0060] After obtaining the execution result of the replacement function during step 102, the following steps are also included:

[0061] Step 1027: Write the execution result of the replacement function into the storage space.

[0062] Accordingly, step 103 can be achieved through the following steps:

[0063] Step 1031: Based on the identifier, retrieve the address of the next instruction and the execution result of the replacement function from the storage space.

[0064] Step 1032: Return the execution result of the replacement function to the function under test.

[0065] Step 1033: Jump to the address of the next instruction and execute it.

[0066] To help those skilled in the art better understand the above method embodiments, the following description uses an assembly-based implementation on X64 architecture hardware as an example.

[0067] Write 0x48, 0xb8, 8 bytes to the address where the binary code of the function under test is stored, 0xff, 0xd0, and 4 bytes to the first 16 bytes of the binary code of the function under test.

[0068] After the beginning of the function under test is replaced, the long call instruction and the return of the execution result are implemented in the following way:

[0069] Execution of long call instructions:

[0070] (1) Read the address D1 of the stack register and the address D2 of the stack register plus 8. The value of D1 is the identifier, and the value of D2 is the address of the next instruction after the function to be tested is called in the current function call stack.

[0071] (2) Read the 4-byte value on D1, which is the identifier for function substitution.

[0072] (3) By querying the data table used to store replacement-related information in the preset storage space by the identifier, the storage address and header of the binary code of the function under test after compilation are obtained, the header is written back to the binary code of the function under test after compilation, and the original function of the function under test is restored, so as to ensure that the function under test will not be replaced in a loop when it is called again during the replacement process.

[0073] (4) Read the value of 8 bytes at address D2, mark it as D3, and store D3 in the record of the data table. D3 is the position to continue execution after calling the function under test.

[0074] (5) Request a global variable global_replace_ID in advance to record the current identifier. First, store the old identifier value in the record of the data table and mark it as D4. Then update the value of global_replace_ID to the identifier.

[0075] (6) By setting the stack register to 16, D1 and D2 are popped from the stack.

[0076] (7) Push the address of the function where the execution result is returned onto the stack.

[0077] (8) Jump to the location of the replacement function and execute the replacement function.

[0078] Based on the characteristics of assembly encoding: when using a register, the old value of the register needs to be saved to the stack first, and restored after use. The registers used in steps (1)-(5) need to be pushed onto the stack for protection before use. At this time, the registers are popped off the stack in sequence to restore them, so that the registers remain consistent with those before the function under test is called.

[0079] In step (7) above, the execution result return function is added to the top of the heap through the stack push operation. Therefore, after the replacement function is completed, the execution will continue to the result return function, that is, the result of the replacement function is returned to the function under test and then the next instruction of the function under test is executed.

[0080] The implementation of the function that returns the execution result is as follows:

[0081] (1) Query the data table through global_replace_ID to obtain the relevant data stored in the data table, including the identifier, temporary data D3, D4, etc.

[0082] (2) Update global_replace_ID to D4, which restores the old value of global_replace_ID.

[0083] (3) At this point, the process of calling the function under test has been completed. The call to the function under test is switched to the execution of the replacement function through the constant call instruction. In fact, the function under test is not executed, but the replacement function is executed.

[0084] It is understandable that the beginning of the binary output of the replacement function has been restored during the aforementioned long call implementation, thus restoring the initial functionality of the function under test. If subsequent calls to the function under test require further replacement with the replacement function, the beginning of the function under test will be replaced again; this will not be elaborated upon here.

[0085] (4) Jump to D3 to continue execution, where D3 is the end point of the call to the function under test.

[0086] Based on the characteristics of assembly encoding: when using a register, the old value of the register needs to be saved to the stack first, and then restored after use. In steps (1)-(3), the registers used need to be pushed onto the stack in advance for temporary storage. Now, the registers are popped off the stack to restore them, so that each register remains consistent with the state after the replacement function is called.

[0087] To help those skilled in the art better understand the rollover coverage statistics process in code testing methods, the following will also provide an example of testing the memory allocation failure handling logic.

[0088] The pseudocode for the function A to be tested is as follows:

[0089]

[0090] At this point, the exception handling logic for memory allocation failure is tested using the following replacement function B:

[0091]

[0092] Running the above test function will inevitably trigger the exception handling for memory allocation failure.

[0093] Assuming that all memory allocations exceeding 1GB fail, the usage of malloc can be monitored using the following code:

[0094]

[0095] At this point, the function under test A can be called while the replacement function B is being executed. Therefore, the usage of the function under test can still be monitored through the code coverage statistics interface, thereby achieving normal code coverage statistics for the function under test A.

[0096] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0097] Another aspect of the present invention provides a code testing device, such as... Figure 7 As shown, it includes:

[0098] The replacement module 701 is used to call a preset function replacement interface when the function replacement instruction of the test code is read. The function replacement interface is used to replace the first part of the binary code of the function under test after compilation with the long call binary instruction of the replacement function.

[0099] The execution module 702 is used to read and execute the binary code of the replaced function to obtain the execution result of the replaced function.

[0100] The result return module 703 is used to return the execution result of the replacement function to the function under test.

[0101] It is not difficult to see that this embodiment is a device embodiment corresponding to the method embodiment, and this embodiment can be implemented in conjunction with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

[0102] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by this invention; however, this does not mean that other units are absent from this embodiment.

[0103] Another aspect of the present invention provides an electronic device, such as... Figure 8 As shown, it includes: at least one processor 801; and a memory 802 communicatively connected to at least one processor 801; wherein the memory 802 stores instructions executable by at least one processor 801, the instructions being executed by at least one processor 801 to enable at least one processor 801 to execute the code testing method described in any of the above method embodiments.

[0104] The memory 802 and processor 801 are connected via a bus, which can include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 801 and memory 802 together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 801 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 801.

[0105] The processor 801 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 802 can be used to store data used by the processor 801 during operation.

[0106] Another aspect of this invention provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the code testing method described in any of the above method embodiments.

[0107] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0108] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing the present invention, and in practical applications, various changes in form and detail may be made without departing from the spirit and scope of the present invention.

Claims

1. A code testing method, characterized in that, include: When the function replacement instruction of the test code is read, a preset function replacement interface is called according to the function replacement instruction. The function replacement interface is used to replace the first part of the binary code of the function under test after compilation with the long call binary instruction of the replacement function. Execute the binary code of the replaced function to obtain the execution result of the replaced function; The execution result of the replacement function is returned to the function under test; wherein, the step of calling a preset function replacement interface according to the function replacement instruction includes: Based on the function replacement instruction, determine the address of the binary code of the function under test after compilation and the address of the binary code of the replacement function after compilation; The address of the binary code of the function under test and the address of the binary code of the replacement function are used as inputs to the function replacement interface. The function replacement interface is called to add write permission to the address of the binary code of the function under test and replace the first part of the binary code at the address of the binary code of the function under test with a long call binary instruction containing the address of the binary code of the replacement function.

2. The code testing method according to claim 1, characterized in that, The function replacement interface is also used to bind an identifier to the beginning part of the compiled binary code of the function under test. After calling the preset function replacement interface according to the function replacement instruction, the method further includes: The address of the binary code of the function under test, the address of the binary code of the replacement function, the header and the identifier are recorded in a preset storage space.

3. The code testing method according to claim 2, characterized in that, The step of calling a preset function replacement interface according to the function replacement instruction includes: According to the function replacement instruction, the function replacement interface is called to assign the identifier to the function under test and modify a portion of the binary code of the function under test after compilation to the identifier.

4. The code testing method according to claim 2, characterized in that, The execution result of the replaced function is obtained by executing the binary code of the function under test, including: Read the address of the compiled binary code of the function under test, which is recorded in the stack register; Based on the address of the binary code compiled by the function under test, read the identifier carried in the binary code compiled by the replaced function under test; The memory space is queried according to the identifier to determine the first part and the first part is written back to the binary code of the function under test after compilation. Based on the address of the binary code compiled by the function under test, the address of the binary code compiled by the replacement function is read and a long jump is performed to execute the binary code compiled by the replacement function, thereby obtaining the execution result of the replacement function.

5. The code testing method according to claim 4, characterized in that, The storage space also includes a global variable for recording the current identifier, and the method further includes: Update the latest identifier to the global variable.

6. The code testing method according to claim 4, characterized in that, After reading the address of the compiled binary code of the function under test recorded in the stack register, the method further includes: The address of the next instruction of the function under test is determined based on the address of the binary code of the function under test after compilation. Write the address of the next instruction into the storage space and bind it to the identifier; After the long jump to execute the compiled binary code of the replacement function and obtain the execution result of the replacement function, the method further includes: Write the execution result of the replacement function into the storage space; Returning the execution result of the replacement function to the function under test includes: Based on the identifier, the address of the next instruction and the execution result of the replacement function are obtained from the storage space; The execution result of the replacement function is returned to the function under test; Jump to the address of the next instruction and execute it.

7. A code testing device, characterized in that, include: The replacement module is used to call a preset function replacement interface according to the function replacement instruction when the function replacement instruction of the test code is read. The function replacement interface is used to replace the first part of the binary code of the function under test after compilation with the long call binary instruction of the replacement function. An execution module is used to read and execute the replaced binary code of the function under test to obtain the execution result of the replaced function; The result return module is used to return the execution result of the replacement function to the function under test; The replacement module is further configured to determine the address of the compiled binary code of the function under test and the address of the compiled binary code of the replacement function according to the function replacement instruction; use the address of the compiled binary code of the function under test and the address of the compiled binary code of the replacement function as input to the function replacement interface; call the function replacement interface to add write permission to the address of the compiled binary code of the function under test; and replace the first part of the binary code at the address of the compiled binary code of the function under test with a long call binary instruction containing the address of the compiled binary code of the replacement function.

8. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the code testing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the code testing method as described in any one of claims 1 to 6.

Images