Method, apparatus, device, and storage medium for testing code

Abstract

The present application discloses a method, apparatus, device, and storage medium for testing code, relating to the field of code testing. The specific implementation solution is as follows: obtain target code, where the target code includes at least one method function; run the target code; obtain the input parameters and return values generated by at least one method function during the running process; obtain the target test case corresponding to the target code; determine the test result of the target code according to each input parameter, each return value, and the target test case. This implementation manner can implement the testing of code during the running process, so that it is not necessary for technicians to write complex test cases, improving the testing efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the field of code testing, and particularly to methods, devices, equipment, and storage media for testing code. Background Art

[0002] In order to control the quality of software code and better avoid the occurrence of program errors, generally, corresponding unit test cases need to be written for the updated code before or after updating the software function code. After each code update, the unit test cases are executed to verify whether the software runs correctly, thereby avoiding the occurrence of program errors.

[0003] The existing approach usually monitors the code update, manually searches for the corresponding unit test cases, and manually starts to execute the unit test; after the unit test ends, manually analyzes whether all the test structures pass. Summary of the Invention

[0004] There is provided a method, device, equipment, and storage medium for testing code.

[0005] According to a first aspect, there is provided a method for testing code, including: obtaining target code, where the target code includes at least one method function; running the target code; obtaining input parameters and return values generated by at least one method function during the running process; obtaining a target test case corresponding to the target code; and determining a test result of the target code according to each input parameter, each return value, and the target test case.

[0006] According to a second aspect, there is provided a device for testing code, including: a target code obtaining unit configured to obtain target code, where the target code includes at least one method function; a target code running unit configured to run the target code; a parameter obtaining unit configured to obtain input parameters and return values generated by at least one method function during the running process; a test case obtaining unit configured to obtain a target test case corresponding to the target code; and a test result determining unit configured to determine a test result of the target code according to each input parameter, each return value, and the target test case.

[0007] According to a third aspect, there is provided an electronic device for executing the method for testing code, 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described in the first aspect.

[0008] According to a fourth aspect, a non-transitory computer-readable storage medium storing computer instructions is provided, and the computer instructions are used to cause a computer to execute the method described in the first aspect.

[0009] According to a fifth aspect, a computer program product includes a computer program, and when the computer program is executed by a processor, the method described in the first aspect is implemented.

[0010] According to the technology of the present application, a code testing method is provided, which can implement code testing during operation, so that technicians do not need to write complex test cases, improving the testing efficiency.

[0011] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. Description of the Drawings

[0012] The drawings are used to better understand the solution and do not constitute a limitation to the present application. Among them:

[0013] Figure 1 is an exemplary system architecture diagram to which an embodiment of the present application can be applied;

[0014] Figure 2 is a flowchart of an embodiment of the method for testing code according to the present application;

[0015] Figure 3 is a schematic diagram of an application scenario of the method for testing code according to the present application;

[0016] Figure 4 is a flowchart of another embodiment of the method for testing code according to the present application;

[0017] Figure 5 is a schematic structural diagram of an embodiment of the apparatus for testing code according to the present application;

[0018] Figure 6 is a block diagram of an electronic device for implementing the method for testing code in the embodiments of the present application. Detailed Embodiments

[0019] The following describes exemplary embodiments of the present application with reference to the drawings. Various details of the embodiments of the present application are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described here without departing from the scope and spirit of the present application. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted below.

[0020] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The following will describe this application in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0021] Figure 1 An exemplary system architecture 100 is shown, which can apply the embodiments of the method or device for testing code in this application.

[0022] As Figure 1 shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0023] Users can use the terminal devices 101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications, such as code integration applications, etc., can be installed on the terminal devices 101, 102, 103. Users can use the code integration applications installed on the terminal devices 101, 102, 103 to write code and send the code to the server 105.

[0024] The terminal devices 101, 102, 103 can be hardware or software. When the terminal devices 101, 102, 103 are hardware, they can be various electronic devices, including but not limited to laptop computers and desktop computers, etc. When the terminal devices 101, 102, 103 are software, they can be installed in the above-listed electronic devices. It can be implemented as multiple software or software modules (for example, used to provide distributed services), or it can be implemented as a single software or software module. No specific limitation is made here.

[0025] The server 105 can be a server that provides various services, such as a background server for testing the code submitted on the terminal devices 101, 102, 103. The background server can use test cases to test the code and feedback the test results to the terminal devices 101, 102, 103.

[0026] It should be noted that the server 105 can be hardware or software. When the server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or it can be implemented as a single server. When the server 105 is software, it can be implemented as multiple software or software modules (for example, used to provide distributed services), or it can be implemented as a single software or software module. No specific limitation is made here.

[0027] It should be noted that the method for testing code provided by the embodiments of the present application is generally executed by the server 105. Correspondingly, the device for testing code is generally set in the server 105.

[0028] It should be understood that Figure 1 the numbers of the terminal devices, networks, and servers in

[0029] Continuing to refer to Figure 2 , a flowchart 200 of an embodiment of the method for testing code according to the present application is shown. The method for testing code in this embodiment includes the following steps:

[0030] Step 201, obtain the target code.

[0031] In this embodiment, the execution subject of the method for testing code (such as Figure 1 the server 105 shown) can obtain the target code in various ways. Here, the target code can be the code edited by the developer through a code integration application, which may include at least one method function. Each method function can also be embodied in the form of an interface.

[0032] Step 202, run the target code.

[0033] After obtaining the target code, the execution subject can run the target code in various ways. For example, the execution subject can trigger the running of the target code by receiving the operation of the user. Such running can be online running or offline running. Online running can be understood as processing the user's request or providing online services, etc. Offline running can be running using a code integration application before the software goes online.

[0034] Step 203, obtain the input parameters and return values generated by at least one method function during the running process.

[0035] The execution subject can obtain the input parameters and return values generated by each method function in the target code during the running process in various ways. Specifically, the execution subject can obtain the generated input parameters and return values by inserting pre-functions and / or post-functions into the target code in advance. Or, the execution subject can intercept the input parameters and return values generated by each method function through other executable files during the running process of the target code.

[0036] Step 204, obtain the target test case corresponding to the target code.

[0037] In this embodiment, the execution entity may also obtain target test cases corresponding to the target code. These test cases may be pre-written by the user according to the target code, or may be test cases used by other codes including various method functions. Alternatively, the execution entity may also obtain these test cases from a preset test case library. Each test case in the test case library may have a corresponding relationship with at least one method function, and the execution entity may use the test cases corresponding to the various method functions in the target code as the target test cases.

[0038] Step 205: Determine the test result of the target code according to each input parameter, each return value, and the target test case.

[0039] In this embodiment, the execution entity may determine the test result of the target code according to each input parameter, each return value, and the target test case. Specifically, for a single method function, the execution entity may input the input parameter of the method function into the test case corresponding to the method function, compare the result obtained from the test case with each return value, and use the comparison result as the test result. Alternatively, the execution entity may substitute each input parameter and each return value into the target test case together to obtain the analysis result of the target test case for each input parameter and each return value, and use the analysis result as the test result.

[0040] In existing white-box testing, in order to call the code to be tested, code testers need to construct input parameters and return values corresponding to the various method functions in the code to be tested. For some method functions with simple parameters, code testers can easily handle them. However, for input parameters or return values of some complex data types, the construction of parameters is particularly cumbersome. For example, if a parameter is a complex object and there are many nested objects inside this object, then the complex system of this object needs to be completely constructed before the corresponding test case can be called.

[0041] In addition, the interfaces, method functions, parameters, etc. in the code to be tested may not be independent and may depend on other information, such as caches, online services, etc. If you want to construct the execution of such test cases, then many additional encapsulations are required. For example, for a cache, common data information, the interface needs to obtain some data from the cache. Then, when constructing the test case for this interface, an offline cache must be created and the corresponding data must be supplemented in it before a call to the interface to be tested can be initiated, and this process is particularly cumbersome. When the interface depends on some remote interfaces, it is similar. The call logic of the remote interface must be handled well before the code to be tested can be executed. When the interface depends on the query logic of some databases, then the query logic of the database must be implemented during the unit test process, and there must be an accessible database locally and corresponding data exists.

[0042] In this embodiment, by obtaining the input parameters and return values of each method function in the target code, it is not necessary for code testers to manually construct the above parameters, which reduces the work complexity of code testers and also avoids test errors caused by human errors, improving the accuracy of code testing.

[0043] Continue to refer to Figure 3 , which shows a schematic diagram of an application scenario of the method for testing code according to the present application. In Figure 3 the application scenario, the developer edits a certain code through the terminal 301 and sends the target code to the server 302. After receiving the target code, the server 302 runs the target code and obtains the input parameters and return values generated by each method function during the running process of the target code. It also obtains the target test case corresponding to the target code from the database 303. Combining the obtained input parameters and return values with the target test case, the test result is obtained. And the test result is returned to the terminal 301.

[0044] The method for testing code provided in the above embodiment of the present application can implement code testing during the running process, so that it is not necessary for technicians to write complex test cases offline, improving the test efficiency.

[0045] Continue to refer to Figure 4 , which shows the process 400 of another embodiment of the method for testing code according to the present application. As Figure 4 shown, the method of this embodiment may include the following steps:

[0046] Step 401, obtain the target code.

[0047] Step 402, in response to determining that the target code meets the preset conditions, obtain the upstream code that calls the target code; run the upstream code.

[0048] In this embodiment, the execution entity may further determine whether the target code meets a preset condition. The preset condition here may be various conditions set according to the actual application scenario. For example, it may include that the number of method functions in the target code is greater than a preset value, the total amount of input parameters is greater than a preset value, the number of nested levels is greater than a preset value, and so on. If the target code meets the preset condition, it indicates that the target code is relatively complex. Since the input parameters of the target code are required to trigger when running the target code. In the case where the target code is relatively complex, the input parameters of the target code are also relatively complex and it is difficult to trigger. Then at this time, the upstream code that calls the target code can be obtained. Here, there is a call relationship between the codes. The code that calls the target code can be called the upstream code of the target code. The code called by the target code can be called the downstream code of the target code. When determining the upstream code, the codes that do not meet the preset condition can be obtained, that is, the codes with fewer input parameters and are easy to trigger and run. Since the upstream code will definitely call the target code during the running process, the running of the target code can be achieved by running the target code.

[0049] Alternatively, the above preset condition further includes receiving a user instruction. If the execution entity receives a user instruction, it can be determined that the complexity of the above target code is relatively high. If no user instruction is received, it can be determined that the complexity of the above target code is not high.

[0050] Step 403, determine the dynamic bytecodes generated by each method function during the running process; weave a pre-function and a post-function into the dynamic bytecodes, and obtain the input parameters and return values of each method function.

[0051] Generally, code cannot be inserted randomly during the running process. Generally, before running, code can be inserted into the target code. During the running process, the inserted code can be run by running the above target code to obtain the input parameters and return values.

[0052] In this embodiment, if the target code is Java code, it will generate dynamic bytecodes during the running process. When the dynamic bytecodes are loaded into the Java Virtual Machine (JVM), they can be interpreted and executed. In this embodiment, by modifying the dynamic bytecodes, it is possible to weave a pre-function and a post-function into the target code during the running process. Here, the pre-function (before) can intercept the input parameters of each method function in the target code, and the post-function (after) can intercept the return values of each method function in the target code. It can be understood that the pre-function and the post-function need to be written by technical personnel according to the actual application situation.

[0053] In some specific practices, the ASM framework can be used to modify the dynamic bytecode files (class files) generated during the running of the target code. ASM is a Java bytecode manipulation framework. It can be used to dynamically generate classes or enhance the functions of existing classes. ASM can directly generate binary class files or dynamically change class behavior before the class is loaded into the Java virtual machine. Class files are stored in class files with a strictly defined format. These class files have enough metadata to parse all elements in the class: class name, methods, attributes, and Java bytecode (instructions). After reading the information from the class file, ASM can change class behavior, analyze class information, and even generate new classes according to user requirements.

[0054] In some specific applications, checkpoints can be used to represent each method function in the target code or an interface in the target code. When using the ASM framework to modify the dynamic bytecode, the following steps can be used to achieve it:

[0055] 1. Create a Java agent program and load the test metadata.

[0056] Here, the Java agent program needs to contain a premain method. This premain method is a proxy method agreed upon by the Java virtual machine. This method will be executed before the system's main method, so that some processing can be done before the main method is executed. The implementation of the premain method is to first load all the test metadata. The test metadata here can include the information of checkpoints and the information of entry points. The information of checkpoints mainly describes the data information related to detection, such as which implementation class is used to detect which interface, etc. The information of entry points can be understood as the positions of checkpoints where the code to be inserted is located.

[0057] 2. Use ASM to dynamically weave in the call to the total control module according to the test metadata.

[0058] Since the test metadata includes the information of checkpoints and the information of entry points. Each entry point describes the position information to be woven in, that is, which class's which method, etc. These classes and methods are the objects we need to modify, that is, certain processing logic needs to be woven in at these positions.

[0059] Since the weaving process using ASM mainly adopts the disassembly operation of dynamic bytecode and the logic is very complex, so here we do not weave in the specific entry points, but weave in a total control module, and then the total control module calls each entry point to complete the specific logic. In this way, only how to weave in the total control module to the target position needs to be considered. This can ensure that the logic woven in for different entry points is the same.

[0060] The total control module mainly includes a pre-function and a post-function. The pre-function is mainly used to cut into the entry point of the method function, that is, the first line of the method function. The post-function is mainly woven into the line before the method function returns. The pre-function mainly passes in the identifier of the cut-in point, the description information of the method function, the reference of the interface object, and the execution parameters of the method function, etc. The post-function accesses the return value of the method function before the method function executes and returns.

[0061] 3. Configure the total control module into the system where the target code is located.

[0062] The code of the total control module can be packaged and the target code can be run using the parameters of the virtual machine, so that the Java agent program can be added to the running target code to achieve dynamic modification of the target code.

[0063] Step 404, obtain general test cases and special test cases corresponding to at least one method function from a preset test case library.

[0064] In this embodiment, a test case library can be preset, and the test case library can include general test cases and special test cases. General test cases can be test cases that have nothing to do with the business logic of the target code, such as testing performance, the number of interface calls, etc. For these tests, they only need to be written once. Special test cases are test cases related to the business logic of the target code. They have a corresponding relationship with the method function.

[0065] In some specific applications, the test cases in the above test case library can be common with Junit test cases to achieve seamless compatibility with Junit. JUnit is a unit test framework for the Java language.

[0066] The execution entity can obtain general test cases and special test cases corresponding to at least one method function from the above test case library.

[0067] Step 405, execute the target test case according to each input parameter and each return value, and determine the test result of the target code according to the execution result of the target test case.

[0068] After obtaining the target test case, the execution entity can execute the target test case according to each input parameter and each return value, and determine the test result of the target code according to the execution result of the target test case. When executing the test case, the input parameters of the method function can be used as the input to run the target test case to obtain the execution result. The execution entity can use the execution result as the test result of the target code, or compare the execution result with the return value of the method function and use the difference between the two as the test result.

[0069] In some alternative implementation manners of this embodiment, if the target code includes an interface and the target code is an update of the interface, the execution entity may implement the test of the updated interface through the following steps: substitute each input parameter into the target test case to determine the output result of the target test case; compare the output result with each return value to determine the test result of the target code.

[0070] In this implementation manner, the execution entity may substitute each input parameter of the interface into the target test case to obtain the output result of the target test case. Then, by comparing the output result with each return value, the test result of the target code can be obtained.

[0071] It can be understood that in this case, the target test case may be the test case used by the interface before the update or the updated test case. If the previously used test case is used, the reuse of the test case can be realized, improving the test efficiency.

[0072] Step 406, in response to determining that the preset test completion condition is satisfied, stop executing the target test case.

[0073] In this embodiment, the execution entity may determine whether the preset test completion condition is satisfied. If it is satisfied, it means that the target code does not need to be tested anymore, and thus the execution of the target test case can be stopped. It can be understood that if the target test case includes multiple test cases, the above preset test completion condition may include multiple sub-conditions that match the above multiple test cases. The execution entity may respectively determine whether each sub-condition is satisfied. If a certain sub-condition is satisfied, stop executing the test case corresponding to the sub-condition. The above test completion condition may include that the test has been carried out for a preset duration, etc.

[0074] In some specific applications, the execution entity may set a flag bit for the test case to indicate whether a certain test case has been executed. For example, when the flag bit is true, it means that the test case should be executed. When the flag bit is false, it means that the test case is not to be executed.

[0075] Furthermore, if it is determined that the target code no longer needs to be tested, the test of the target code may be stopped by disconnecting the Java agent program. In this way, the pre-function and post-function will not be woven into the running process of the target code either. It is equivalent to deleting the pre-function and post-function from the target code. The method of this embodiment can control the target test case by setting the flag bit of the test case, realizing the personalized test of the target code. Through the setting of the Java agent program, the "start and stop at any time" of the test can be realized, that is, the test can be started and stopped at any time.

[0076] Step 407: Save the input parameters and return values of each method function; generate test cases for each method function according to the saved input parameters and return values.

[0077] In this embodiment, the execution entity can also implement the "recording" function. That is, save the input parameters and return values of each obtained method function. Generate test cases for each method function according to these saved data. Specifically, for a certain method function, the execution entity can obtain the test cases of method functions similar to this method function. Replace the input parameters and return values therein to generate test cases for this method function. Alternatively, the execution entity can output the saved input parameters and return values to the user. In this way, it is convenient for the user to manually construct input parameters and return values when writing test cases.

[0078] In some optional implementation manners of this embodiment, when generating test cases, the execution entity can first determine the coverage of the method function, that is, perform coverage testing on the method function. If the coverage meets the preset coverage condition, test cases can be generated. Here, the preset coverage condition can correspond to different levels of coverage testing. Coverage testing can include multiple levels such as function coverage, statement coverage, decision coverage, and condition coverage. Each level has different requirements for the execution granularity. For example, function coverage requires executing every statement in the code, and decision coverage requires executing each branch of the decision. If the coverage meets the requirements corresponding to different levels, corresponding test cases are generated.

[0079] In some optional implementation manners of this embodiment, if the coverage is less than the preset threshold, it means that some branches in the method function are not covered by the test cases. Then, the saved input parameters and return values can be output to the user, and the user can write test code for the uncovered branches to generate test cases with a larger coverage.

[0080] Step 408: Add the generated test cases to the test case library.

[0081] The execution entity can also add the generated test cases to the test case library. In this way, the test case library can be enriched, enabling the "recorded" test cases to be used again, that is, "replaying" the test cases. And since the test cases are seamlessly integrated with Junit test cases, the Junit test case library can also be enriched.

[0082] The method for testing code provided by the above embodiment of this application can dynamically weave pre - functions and post - functions during the code running process to achieve dynamic testing.

[0083] Further reference Figure 5, as an implementation of the methods shown in the above figures, the present application provides an embodiment of a device for testing code. This device embodiment corresponds to Figure 2 the method embodiment shown, and this device can be specifically applied to various electronic devices.

[0084] As shown in Figure 5 , the device 500 for testing code in this embodiment includes: a target code acquisition unit 501, a target code running unit 502, a parameter acquisition unit 503, a test case acquisition unit 504, and a test result determination unit 505.

[0085] The target code acquisition unit 501 is configured to acquire target code. The target code includes at least one method function.

[0086] The target code running unit 502 is configured to run the target code.

[0087] The parameter acquisition unit 503 is configured to acquire input parameters and return values generated by at least one method function during the running process.

[0088] The test case acquisition unit 504 is configured to acquire target test cases corresponding to the target code.

[0089] The test result determination unit 505 is configured to determine the test result of the target code according to each input parameter, each return value, and the target test case.

[0090] In some alternative implementation manners of this embodiment, the target code running unit 502 can be further configured to: in response to determining that the target code meets a preset condition, acquire upstream code that calls the target code; run the upstream code.

[0091] In some alternative implementation manners of this embodiment, the parameter acquisition unit 503 can be further configured to: determine dynamic bytecodes generated by each method function during the running process; weave pre-functions and post-functions into the dynamic bytecodes to acquire input parameters and return values of each method function.

[0092] In some alternative implementation manners of this embodiment, the test case acquisition unit 504 can be further configured to: acquire general test cases and dedicated test cases corresponding to at least one method function from a preset test case library.

[0093] In some alternative implementation manners of this embodiment, the test result determination unit 505 can be further configured to: execute the target test case according to each input parameter and each return value, and determine the test result of the target code according to the execution result of the target test case.

[0094] In some alternative implementation manners of this embodiment, the test result determination unit 505 may be further configured to: substitute each input parameter into the target test case to determine the output result of the target test case; compare the output result with each return value to determine the test result of the target code.

[0095] In some alternative implementation manners of this embodiment, the apparatus 500 may further include Figure 5 a test stop unit not shown in the figure, configured to: stop executing the target test case in response to determining that a preset test completion condition is satisfied.

[0096] In some alternative implementation manners of this embodiment, the apparatus 500 may further include Figure 5 a test case generation unit not shown in the figure, configured to: save the input parameters and return values of each method function; generate test cases for each method function according to the saved input parameters and return values.

[0097] In some alternative implementation manners of this embodiment, the apparatus 500 may further include Figure 5 a test case storage unit not shown in the figure, configured to: add the generated test cases to a test case library.

[0098] In some alternative implementation manners of this embodiment, the test case generation unit is further configured to: determine the coverage of the method function; in response to determining that the coverage is greater than or equal to a preset threshold, generate test cases for each method function according to the saved input parameters and return values.

[0099] In some alternative implementation manners of this embodiment, the apparatus 500 may further include Figure 5 a parameter output unit not shown in the figure, configured to: output the saved input parameters and return values in response to determining that the coverage is less than the preset threshold.

[0100] It should be understood that the units 501 to 505 described in the apparatus 500 for testing code respectively correspond to the respective steps in the method described with reference to Figure 2 above. Therefore, the operations and features described above for the method for testing code also apply to the apparatus 500 and the units included therein, and will not be elaborated herein.

[0101] According to the embodiments of the present application, the present application also provides an electronic device, a readable storage medium, and a computer program product.

[0102] Figure 6FIG. 0 is a block diagram of an electronic device 600 that executes a method for testing code according to an embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as, for example, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as, for example, personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0103] As Figure 6 shown, the device 600 includes a processor 601 that can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a memory 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 can also be stored. The processor 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An I / O interface (input / output interface) 605 is also connected to the bus 604.

[0104] A plurality of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, a mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a memory 608, such as a magnetic disk, an optical disk, etc.; and a communication unit 609, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0105] The processor 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 601 executes the various methods and processes described above, such as the method for testing code. For example, in some embodiments, the method for testing code can be implemented as a computer software program that is tangibly contained in a machine-readable storage medium, such as the memory 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the processor 601, one or more steps of the method for testing code described above can be executed. Alternatively, in other embodiments, the processor 601 can be configured to execute the method for testing code in any other suitable manner (e.g., by means of firmware).

[0106] Various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuitry, integrated circuit systems, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), application-specific standard products (ASSP), systems-on-a-chip (SOC), complex programmable logic devices (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor, and can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0107] The program code for implementing the methods of this application can be written in any combination of one or more programming languages. The above program code can be encapsulated into a computer program product. These program codes or computer program products can be provided to the processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing devices, such that when the program code is executed by the processor 601, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0108] In the context of this application, a machine-readable storage medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable storage medium can be a machine-readable signal storage medium or a machine-readable storage medium. The machine-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0109] To provide for interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0110] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local area network (LAN), wide area network (WAN), and the Internet.

[0111] A computer system may include a client and a server. The client and the server are generally far from each other and usually interact through a communication network. The relationship between the client and the server is generated by computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system, and solves the defects of difficult management and weak business scalability existing in traditional physical hosts and VPS services ("Virtual Private Server", or simply "VPS"). The server may also be a server of a distributed system or a server combined with a blockchain.

[0112] It should be understood that various forms of processes shown above can be used, and steps can be reordered, added, or deleted. For example, the steps described in this application can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of this application can be achieved, and no limitation is imposed herein.

[0113] The above specific embodiments do not constitute a limitation on the protection scope of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims

1. A method for testing code, comprising: Obtaining target code, where the target code includes at least one method function; Running the target code; Determining the dynamic bytecode generated by each method function during the running process; Weaving a total control module into the dynamic bytecode, weaving the pre-function and post-function included in the total control module into the cut-in position called by the total control module, and intercepting the input parameters and return values of each method function; Obtaining a target test case corresponding to the target code; Determining the test result of the target code according to each input parameter, each return value, and the target test case.

2. The method according to claim 1, wherein, The running the target code includes: In response to determining that the target code meets a preset condition, obtaining the upstream code that calls the target code; Running the upstream code.

3. The method according to claim 1, wherein, The obtaining a target test case corresponding to the target code includes: Obtaining a general test case and a dedicated test case corresponding to the at least one method function from a preset test case library.

4. The method according to claim 1, wherein, The determining the test result of the target code according to each input parameter, each return value, and the target test case includes: Executing the target test case according to each input parameter and each return value, and determining the test result of the target code according to the execution result of the target test case.

5. The method according to claim 4, wherein The executing the target test case according to each input parameter and each return value, and determining the test result of the target code according to the execution result of the target test case includes: Substituting each input parameter into the target test case to determine the output result of the target test case; Comparing the output result with each return value to determine the test result of the target code.

6. The method according to claim 1, wherein, The method further includes: In response to determining that a preset test completion condition is met, stopping the execution of the target test case.

7. The method according to claim 3, wherein The method further includes: Saving the input parameters and return values of each method function; Generating test cases for each method function according to the saved input parameters and return values.

8. The method according to claim 7, wherein The method further includes: Adding the generated test cases to the test case library.

9. The method according to claim 7, wherein The generating test cases for each method function according to the saved input parameters and return values includes: Determining the coverage of the method function; In response to determining that the coverage meets a preset coverage condition, generating test cases for each method function according to the saved input parameters and return values.

10. The method according to claim 9, wherein, The method further includes: In response to determining that the coverage is less than a preset threshold, outputting the saved input parameters and return values.

11. A device for testing code, comprising: A target code obtaining unit configured to obtain target code, where the target code includes at least one method function; A target code running unit configured to run the target code; A parameter obtaining unit configured to determine the dynamic bytecode generated by each method function during the running process; Weaving a total control module into the dynamic bytecode, weaving the pre-function and post-function included in the total control module into the cut-in position called by the total control module, and intercepting the input parameters and return values of each method function; A test case acquisition unit, configured to acquire a target test case corresponding to the target code; A test result determination unit, configured to determine a test result of the target code according to each input parameter, each return value, and the target test case.

12. An electronic device for executing a method for testing code, comprising: 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method according to any one of claims 1-10.

13. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method according to any one of claims 1-10.

14. A computer program product, comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-10.

Images