Code test method and apparatus

Abstract

The present application relates to the field of computers. Provided are a code test method and apparatus, which are used for providing code coverage data in an interface dimension, thereby quickly locating a person in charge of a test, and supplementing a test case. The method comprises: performing instrumentation on at least one class comprised in source codes, so as to record code coverage data regarding calling the class from a target interface among at least one interface, wherein the code coverage data is used for indicating an execution situation of the class; when a test of the source codes is completed by using a test case, acquiring the code coverage data of when the at least one class in the codes is called from the target interface; and displaying a code coverage result of the source codes on the basis of the code coverage data, wherein the code coverage result of the source codes comprises code coverage data regarding calling the source codes by means of the target interface.

Description

Code testing method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on July 24, 2023, with application number 202310911645.X and invention name “A code testing method, device and system”, and the Chinese patent application filed with the State Intellectual Property Office on November 29, 2023, with application number 202311633126.8 and invention name “A code testing method”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present invention relates to the field of computers, and in particular to a code testing method and device. Background Art

[0003] With the rapid development of computer technology, code testing has played a significant role in improving the quality of software code. Code testing is to test the program using test cases under specified conditions to find errors or defects in the program.

[0004] Code coverage data is a metric used to assess test quality during code testing. It refers to the proportion and extent of source code tested during testing. The fundamental purpose of collecting code coverage data is to identify potential missed test cases and supplement them accordingly.

[0005] Currently, code coverage data is collected at the service level. In some scenarios, when testers are supplementing test cases, they assign responsibilities based on the application program interface (API). This makes it difficult to identify the responsible individuals when supplementing test cases based on uncovered data. Therefore, there is an urgent need for code coverage data from the API perspective to quickly identify the responsible individuals for supplementing test cases.

[0006] Summary of the Invention

[0007] The code testing method and device provided in this application provide code coverage data in the interface dimension, so as to quickly locate the test responsible person to supplement the test cases.

[0008] To achieve the above objectives, the present invention adopts the following technical solutions:

[0009] In a first aspect, a code testing method is provided for testing source code using a test case, the source code including at least one class, the test case being used to test the source code by calling at least one interface of the source code. The method specifically comprises: instrumenting at least one class included in the source code to record code coverage data for calls to the class from a target interface in the at least one interface, the code coverage data indicating the execution status of the class; after testing the source code using the test case, obtaining code coverage data for calls to the at least one class included in the source code from the target interface; and displaying code coverage results for the source code based on the code coverage data, the code coverage results for the source code including the code coverage percentage of calls to the source code via the target interface.

[0010] Through the solution provided in this application, the classes included in the source code are instrumented according to the interface dimension, and the code coverage data of the test case on the class can be obtained when the function in the class is called from the target interface (the interface of the test case calling the source code). Then, the code coverage results of the source code including the code coverage of calling the source code through the target interface are displayed to provide the code coverage results of the interface dimension, and quickly locate the person responsible for testing the interface to supplement the test cases.

[0011] In one possible implementation, the code coverage data for calling a source code from a target interface with one less class included in the source code is the raw code coverage data for the source code obtained by the instrumentation when calling the class from the target interface. This raw data indicates the code coverage rate. The code coverage rate for calling the source code from the target interface is the code coverage ratio expressed in graphical or numerical form. The code coverage rate for calling the source code from the target interface can be converted from the code coverage data for calling a source code from the target interface with one less class included in the source code.

[0012] In another possible implementation, at least one class included in the source code includes an entry class. Instrumenting the at least one class in the source code includes performing bytecode enhancement on the entry class of the source code to record the interface of the source code invoked by the test case as the target interface. Because the entry class is the first code executed during a call, performing bytecode enhancement on the entry class accurately records the target interface.

[0013] In another possible implementation, instrumenting at least one class included in the source code includes adding a variable to the at least one class included in the source code. The variable is used to record code coverage data for test cases calling the class through a target interface, with the key of the variable's data structure being the interface identifier. Instrumenting with variables allows for more efficient code instrumentation and minimizes the impact of instrumentation on the source code.

[0014] In another possible implementation, the data structure of the above variables is HashMap<String,Boolean[]> Since the HashMap data structure has a faster access speed, the timeliness and speed of obtaining the interface dimension code coverage data of this application are improved.

[0015] In another possible implementation, the source code includes multiple functions. The method may further include: obtaining a function call relationship in the source code, where the function call relationship represents the order in which the multiple functions are called when the test case calls the target interface to test the source code; and displaying the function call relationship in the source code. Because the function call relationship reflects the order in which the functions are called when the test case tests the source code, the automatically obtained function call relationship can be used to easily drill down and drill up when supplementing the test case to analyze a specific function, reducing the difficulty of supplementing the test case and further improving the efficiency and quality of test quality assessment.

[0016] In another possible implementation, the function call relationships in the source code include static call relationships, and obtaining the function call relationships in the source code includes: performing static analysis on the source code to obtain the static call relationships. Through static analysis, the static call relationships can be obtained before the source code is executed, thereby preventing the function call relationships from affecting the source code.

[0017] In another possible implementation, the function call relationships in the source code include dynamic call relationships. Obtaining the function call relationships in the source code includes dynamically analyzing the source code during testing of the source code using test cases to obtain the dynamic call relationships in the source code. Obtaining the dynamic call relationships through dynamic analysis improves the accuracy of the function call relationships and can better assist in supplementing test cases.

[0018] In another possible implementation, the method may further include: performing bytecode enhancement at the entry points and exit points of multiple functions included in the source code to record dynamic call relationships during source code execution. The function entry point is where the function begins execution, and the function exit point is where the function ends execution. Because the function entry point reflects the relationship with the previous function, and the function exit reflects the relationship with the next function, performing bytecode enhancement at the function entry and exit points can accurately record function call relationships.

[0019] In a second aspect, a code testing device is provided for testing source code using a test case, wherein the source code includes at least one class, and the test case is used to test the source code by calling at least one interface of the source code. The device includes: an instrumentation unit, an acquisition unit, and a display unit.

[0020] The instrumentation unit is used to instrument at least one class included in the source code to record code coverage data of calling the class from a target interface in at least one interface, where the code coverage data is used to indicate the execution status of the class.

[0021] The acquisition unit is used to obtain code coverage data when at least one class in the source code is called from the target interface after the source code is tested using the test case.

[0022] The display unit is used to display the code coverage result of the source code based on the code coverage data, where the code coverage result of the source code includes the code coverage rate of calling the source code through the target interface.

[0023] It should be noted that the code testing device provided in the second aspect is used to implement the code testing method provided in the above-mentioned first aspect or any possible implementation method. Its specific implementation can refer to the first aspect or any possible implementation method of the first aspect, and will not be repeated here.

[0024] In a third aspect, a computing device cluster is provided, comprising at least one computing device, each computing device comprising a processor and a memory, the processor of the at least one computing device being configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the operations of the method described in the first aspect or any possible implementation method.

[0025] In a fourth aspect, a computer program product comprising instructions, when the instructions are executed by a computing device cluster, causes the computing device cluster to perform the operations of the method described in the first aspect or any possible implementation manner.

[0026] In a fifth aspect, a computer-readable storage medium includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the operations of the method described in the first aspect or any possible implementation manner.

[0027] It should be noted that various possible implementations of any of the above aspects can be combined under the premise that the solutions are not contradictory. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a schematic diagram of a service-level code coverage data display page based on native Jacoco;

[0029] FIG2 is a schematic diagram of the structure of a computer system provided in an embodiment of the present application;

[0030] FIG3 is a flow chart of a method for obtaining code coverage data provided in an embodiment of the present application;

[0031] FIG4 is a schematic diagram of performing bytecode enhancement on an API entry class of a JAVA program according to an embodiment of the present application;

[0032] FIG5 is a schematic diagram of a display page for code coverage data of source code in an interface dimension provided by an embodiment of the present application;

[0033] FIG6 is a flow chart of another method for obtaining code coverage data provided in an embodiment of the present application;

[0034] FIG7 is a schematic diagram of the implementation process of the solution provided in an embodiment of the present application;

[0035] FIG8 is a schematic structural diagram of a code testing device provided in an embodiment of the present application;

[0036] FIG9 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0037] FIG10 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0038] FIG11 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] In the embodiments of the present application, in order to clearly describe the technical solutions of the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity or execution order, and words such as "first" and "second" do not necessarily mean different. There is no order of precedence or priority between the technical features described by "first" and "second".

[0040] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0041] In the embodiments of the present application, at least one can also be described as one or more, and multiple can be two, three, four or more, which is not limited in this application.

[0042] In addition, the network architecture and scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0043] To facilitate understanding, the terms involved in the embodiments of this application are first explained.

[0044] Software testing is the process of executing a program (software product, or functional unit in a software product (which can be called a service)) in order to find errors.

[0045] Source code refers to the object tested in software testing, that is, the executed program.

[0046] A test case is a description of the testing task for a specific software product, embodying the test plan, methods, techniques, and strategies. It includes the test objectives, test environment, input data, test steps, expected results, test scripts, and other details, ultimately documented. A test case is a set of test inputs, execution conditions, and expected results compiled for a specific purpose, used to verify whether a specific software requirement is met.

[0047] Code coverage is a metric in software testing that describes the proportion and extent to which source code in a program is tested. The resulting proportion is called code coverage.

[0048] Instrumentation refers to inserting probes into the program while ensuring the logical integrity of the original program. The probes collect information in the code (the method itself, method parameter values, return values, etc.) and insert code segments at specific locations to collect dynamic context information when the program is running.

[0049] When testing programs written in JAVA, Jacoco is commonly used to collect code coverage for services and evaluate the test quality of the services being tested. Jacoco is an open source Java agent (tool) project that can collect, calculate, and display service-level code coverage data. Testers can evaluate service quality and supplement test cases by analyzing the overall code coverage of the service. Figure 1 illustrates the service-level code coverage data display page based on native Jacoco. As shown in Figure 1, the display page includes statistical data on code coverage (line coverage, branch coverage, and method coverage) for different dimensions of each service during the test process, and displays them in graphical form.

[0050] Service-level code coverage data only has one copy of the coverage data for the class in the source code, making it impossible to confirm which scenario (test case) triggered the test coverage in the class. In actual JAVA programs, a single function often involves calls to multiple API interfaces. In this case, based on the coverage data, it is impossible to confirm which API interface actually tested a specific line in the function, or which APIs have not tested this function. Therefore, in service-level code coverage data collection solutions, it is difficult to determine which uncovered branches belong to a specific tester, making it difficult to locate the tester so that they can supplement the test cases based on the code coverage data.

[0051] In addition, in cloud scenarios, the services provided by the source code being tested are increasing, and the number of testers required for source code testing will continue to grow. The efficiency of locating test responsibilities will also greatly affect the efficiency of test quality assessment.

[0052] Based on this, the present application provides a code testing method for using test cases to test source code including at least one class, the test case is used to test the source code by calling at least one interface of the source code, and by instrumenting the classes in the source code, the instrumentation of a class is used to obtain the code coverage data when the class is called through different interfaces during the test process, thereby achieving the statistical code coverage data of the interface dimension, so that in the scenario where testers are divided into responsibilities according to interfaces, the testers can be quickly located according to the code coverage rate, so that the testers can supplement the test cases according to the code coverage data.

[0053] The solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0054] The solution provided in this application can be applied to the computer system shown in Figure 2. As shown in Figure 2, the computer system includes a test platform 201, a statistics platform 202, and a presentation platform 203. The computer system is deployed in a computing device 20, which can be one or more data centers, servers, virtual machines, or containers, although this application does not limit this.

[0055] The test platform 201 is used to test source code, and the statistical platform 202 is used to collect statistics of code coverage data during the test process of the test platform 201, convert it into code coverage, and transmit the code coverage to the display platform 203.

[0056] Finally, the display platform 203 displays the code coverage in the interface. Alternatively, the display platform 203 sends the code coverage to the terminal 30, which establishes a communication connection 40 with the computer system, and the terminal 30 displays the code coverage.

[0057] For example, the test platform 201, the statistics platform 202, and the display platform 203 included in the computer system shown in FIG2 may be deployed separately or integrated, and this embodiment of the present application does not specifically limit this.

[0058] For example, the statistics platform 202 is integrated into the test platform 201, and the presentation platform 203 is deployed independently.

[0059] Of course, FIG2 is only an example description of a computer system applying the solution of the present application by way of example, and does not constitute a specific limitation on the application scenario of the solution provided by the present application.

[0060] On the one hand, an embodiment of the present application provides a code testing method, which is applied to the statistical platform 202 in the computer system shown in Figure 2. The method can be executed by a computing device. The method is used to test source code using test cases. The source code includes at least one class, and the test case is used to test the source code by calling at least one interface of the source code.

[0061] As shown in FIG3 , the code testing method provided in the embodiment of the present application may include:

[0062] S301: A computing device instruments at least one class included in a source code to record code coverage data of calling the at least one class from a target interface in at least one interface included in the source code.

[0063] The code coverage data of a class included in the source code called from the target interface is used to indicate the execution status of the class. The execution status of a class is used to indicate the coverage ratio of the class when the class is called from the target interface.

[0064] Specifically, in S301, each class in at least one class included in the source code is instrumented. Instrumenting a class is used to record code coverage data of the class when a test case calls the class from a target interface.

[0065] The target interface is the interface of the calling class in the source code, including the interface. There can be one or more target interfaces.

[0066] In a possible implementation, when there are multiple target interfaces, calling the code coverage data of a class from the target interface includes calling the code coverage data of the class from each target interface respectively.

[0067] Exemplarily, the process of S301 may be executed when the service of the source code is started.

[0068] Exemplarily, the code coverage data may include one or more of the following data: branch coverage data, line coverage data, etc. The embodiment of the present application does not limit the specific type of code coverage data, and it can be configured according to actual needs.

[0069] Specifically, in S301 , the computing device may first obtain class data (class data) of the source code, and perform instrumentation on each class in the source code according to the class indicated by the class data.

[0070] For example, in order to evaluate the test quality of the interface dimension, it is necessary to instrument the class in the source code according to the interface dimension to obtain multiple coverage data of a certain class, each coverage data representing the coverage of the class by a target interface test.

[0071] Specifically, it should be understood that the instrumentation of a class described in S301 can be used to obtain code coverage data of the source code for each target interface when a test case calls this class from different target interfaces.

[0072] For example, assuming that class A in the source code, API interface B and API interface C will call functions in class A, API interface B and API interface C are both the above-mentioned target interfaces, and the above-mentioned instrumentation is performed on class A. The instrumentation can obtain the code coverage data of the source code when the test case calls class A through API interface B, and can also obtain the code coverage data of the source code when the test case calls class A through API interface C.

[0073] Furthermore, since the above-mentioned instrumentation is used to record the coverage data of the interface dimension, when the instrumentation is actually performed, it is also necessary to identify the processing interface of the current thread.

[0074] Exemplarily, the at least one class included in the source code may include an entry class. Instrumenting the at least one class included in the source code in S301 includes: performing bytecode enhancement on the entry class of the source code to record the interface of the source code invoked by the test case as the target interface. In other words, performing bytecode enhancement on the interface entry class of the source code to record the processing interface of the current thread, thereby enabling identification of the processing interface of the current thread.

[0075] As shown in Figure 4, the bytecode of the Java program's API entry class is enhanced to obtain the currently processed API and record it in the thread-shared TransmittableThreadLocal structure. This structure then records the current interface information and completes the downward transmission of the interface information. The method for obtaining the instrumentation data set in each class is modified to:

[0076] public static boolean[]$jacocoTraceInit(){

[0077] / / Get the $jacocoData map of the current class

[0078] / / Get the currently executed interface information

[0079] / / Return the boolean array of the interface information

[0080] }

[0081] Exemplarily, in S301, at least one class included in the source code is instrumented, which can be specifically implemented as follows: adding a variable to at least one class included in the source code, where the variable is used to record the code coverage data of the test case calling the class through the target interface, and the key of the variable's data structure is the interface identifier.

[0082] For example, the data structure of the variable can be HashMap<String,Boolean[]> .

[0083] Taking Jacoco as an example, the native Jacoco tool (Agent) only records one copy of coverage data for each class when instrumenting code coverage, and automatically generates a $jacocoData array for each class to save the code coverage status of the class.

[0084] For example, the native Jacoco Agent's instrumentation ideas are as follows:

[0085] In S301, the native Jacoco tool (Agent) can be improved to improve the code coverage instrumentation, record the code coverage data according to the interface dimension, and save multiple coverage data for each class according to the interface dimension. For example, using HashMap<String,Boolean[]> A data structure that records the instrumentation data of a class. When the key value of the data structure is an interface identifier, in this application, the instrumentation idea of ​​the class can be as follows:

[0086] Comparing the above two plug-in ideas, we can see that in the plug-in idea of ​​this application, the plug-in storage medium of each class is replaced with HashMap<String,Boolean[]> , you can get the code coverage data at the interface level. Use HashMap<String,Boolean[]> Structure, record class instrumentation data, HashMap<String,Boolean[]> The key value of the structure is the interface identifier. Bytecode enhancement is performed on the API entry class to retrieve the currently processed API and record it in the thread-shared TransmittableThreadLocal structure. During actual Class program execution, the current API is retrieved in the $jacocoTraceInit function, and the coverage array of the corresponding processed API for that class is returned. Subsequent instrumentation probes can record the coverage identifier in the coverage array of the specified API during execution.

[0087] Of course, in actual applications, the ideas, data structures, and specific codes of the instrumentation can be configured according to actual needs, and the above examples do not constitute a specific limitation.

[0088] S302: After the source code is tested using the test case, the computing device obtains code coverage data when at least one class in the source code is called from the target interface.

[0089] Specifically, by inserting each class in the source code in S301, when the source code is tested using the test case, the inserting probe will record the relevant coverage data into the corresponding array as the code coverage data when each class in the source code is called from the target interface.

[0090] S303: The computing device displays a code coverage result of the source code based on the code coverage data. The code coverage result of the source code includes a code coverage rate of calling the source code through the target interface.

[0091] Specifically, after the source code test is completed, S303 may be executed according to the data recorded in S302.

[0092] The code coverage data is the original data obtained in S302 , and the computing device converts the code coverage data into the code coverage rate of calling the source code through the target interface based on the code coverage data.

[0093] For example, the code coverage data for calling a class from a target interface can be the number of lines of code executed in the class when calling the class from the target interface. Dividing the number of executed lines of code by the total number of lines of code in the class gives the code coverage for calling the class from the target interface. The code coverage for calling the source code from the target interface can be calculated by summing the code coverage of each class in the source code.

[0094] Specifically, S303 may be executed by the computing device or by another platform connected to the computing device. The computing device sends the code coverage of the source code in the interface dimension to the platform, and the platform executes S303 to display the code coverage result of the source code.

[0095] Exemplarily, FIG5 illustrates a display page of code coverage of source code in the interface dimension. In the display page, one row is the code coverage of the source code called from a target interface by a test case.

[0096] Through the solution provided in this application, classes in the source code are instrumented according to the interface dimension, and the code coverage data of the test cases for the class can be obtained when functions in a class are called from different interfaces. This can provide code coverage data in the interface dimension, and quickly locate the test person in charge to supplement the test cases.

[0097] Furthermore, in cloud scenarios, quickly locating the person responsible for testing can effectively ensure the efficiency of test quality assessment.

[0098] Furthermore, the source code includes multiple functions, and the code coverage data displayed by Jacoco is flat. When supplementing test cases to analyze a specific function, it is necessary to manually identify the function call chain, making it difficult to drill down and drill up. This also makes it difficult to supplement test cases, further reducing the efficiency and quality of test quality assessment. Based on this, as shown in Figure 6, the code testing method provided in the embodiment of the present application can also include S304 and S305.

[0099] S304: Obtain function call relationships of the source code.

[0100] The function call relationship is the calling sequence between multiple functions included in the source code during the process of the test case testing the source code by calling the target interface.

[0101] In one possible implementation, the function call relationship of the source code includes a static call relationship, and in S304, the source code can be statically analyzed to obtain the static call relationship of the source code. The embodiment of the present application does not limit the specific scheme of static analysis, for example, static analysis can include static scanning or other methods.

[0102] In one possible implementation, most function call relationships can be obtained through static analysis of the source code. However, in some scenarios, function call relationships are determined or created at runtime and cannot be obtained through static analysis. These scenarios include but are not limited to: reflection calls, dynamic proxies, native method calls, dynamic class loading, and multithreading. Among them:

[0103] Reflection call: The reflection mechanism in Java can dynamically obtain class information and call methods at runtime. Because reflection calls are determined at runtime, these call relationships cannot be obtained during static scanning.

[0104] Dynamic proxy: The dynamic proxy mechanism in Java allows the creation of a proxy class that implements a set of interfaces at runtime. The proxy class can intercept method calls and perform specific processing. Because dynamic proxies are created at runtime, the actual call relationship between the proxied object and the proxy object cannot be obtained during static scanning.

[0105] Native method calls: Native methods in Java call native C / C++ methods through the Java Native Interface (JNI). Because JNI calls are made at runtime and may involve the operation of other system resources, static scanning cannot capture the calling relationship between native and Java methods.

[0106] Dynamically loaded classes: Java classes can be dynamically loaded at runtime using methods such as Class.forName(). Since static scanning cannot obtain information about dynamically loaded classes, it is also impossible to accurately obtain the call relationships between methods in dynamically loaded classes.

[0107] Multithreading: Multithreaded programs in Java can be subject to uncertainty during runtime, potentially leading to changes in function call relationships. Therefore, static analysis of multithreaded programs may not accurately capture the function call relationships.

[0108] Furthermore, the function call relationship of the source code includes static call relationship and dynamic call relationship. Therefore, based on the static analysis, the source code can also be dynamically analyzed in the process of testing the source code using test cases to obtain the dynamic call relationship of the source code.

[0109] Among them, the dynamic analysis method can refer to the call chain technology, and perform bytecode enhancement on the entry and exit of multiple functions included in the source code to record the dynamic call relationship when the source code is executed. The entry is the location where the function starts to execute, and the exit is the location where the function ends to execute.

[0110] S305: Display the function call relationship of the source code.

[0111] Specifically, in S305, the function call relationship of one or more interfaces (first interface) in the source code can be displayed. The function call relationship of an interface can be the execution order of the functions in the source code when the source code is called from the interface as the input interface.

[0112] In a possible implementation, the first interface may be an interface selected by a user, or the first interface may be all interfaces included in the source code.

[0113] For example, the user can click to select one or more interfaces in the code coverage display page of the source code in the interface dimension, and the user-selected interfaces are used as function call relationships of the input interfaces and displayed in the display interface.

[0114] For example, the user can click to select one or more interfaces on the code coverage display page of the source code in the interface dimension, and the user-selected interfaces are used as function call relationships of the input interfaces and displayed in a pop-up display box.

[0115] The method of displaying the function call relationship in S305 can be configured according to actual needs, and the embodiment of the present application is not limited to this.

[0116] For example, the implementation process of the solution provided in the embodiment of the present application may be shown in FIG7 , which may specifically include the following three stages:

[0117] Phase 1. Test environment initialization phase:

[0118] When the test service is first started, the coverage data tool analyzes the source code to collect class data from the Java source code program and instrument each class in the source code stored in the data storage system. The coverage data tool then notifies the call relationship service to calculate the static call relationship of the function and begin recording the dynamic call relationship. The call relationship service then stores the static call relationship of the function in the database.

[0119] Phase 2. Test execution phase:

[0120] During the concurrent execution phase of the test, the execution and scheduling system distributes test cases. Different executors (executor A, executor B, and executor C in the figure) execute the test cases they receive and test the source code. The coverage data tool obtains API dimension coverage data for each class through the insertion of probes and continuously reports it to the data storage system.

[0121] Phase 3. End of testing:

[0122] After the test is complete, the test execution machine scheduling system notifies the coverage data calculation service to calculate the interface-level source code coverage data. The coverage data calculation service retrieves the coverage data recorded during the test from the data storage system, calculates the interface-level source code coverage, and displays the results to the code coverage analysis service (which can be a platform).

[0123] The above mainly introduces the solution provided by the embodiment of the present invention from the perspective of the working principle of the computing device. It can be understood that in order to realize the above functions, the computing device, etc. includes hardware structures and / or software modules corresponding to the execution of each function. It should be easy for those skilled in the art to realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0124] In the embodiments of the present invention, functional modules can be divided into functional modules in computing devices according to the above-described method examples. For example, functional modules can be divided according to respective functions, or two or more functions can be integrated into a single processing module. The above-mentioned integrated modules can be implemented in the form of hardware or software functional modules. It should be noted that the module division in the embodiments of the present invention is illustrative and is merely a logical functional division. In actual implementation, other division methods may be used.

[0125] The present application also provides a code testing device 80, as shown in FIG8, the code testing device 80 may include: an inserting unit 801, an acquiring unit 802 and a display unit 803.

[0126] The instrumentation unit 801 is configured to instrument at least one class included in the source code to record code coverage data of calling the class from a target interface in at least one interface, where the code coverage data is used to indicate execution status of the class.

[0127] The acquisition unit 802 is configured to acquire code coverage data when at least one class in the source code is called from a target interface after the source code is tested using the test case.

[0128] The display unit 803 is configured to display a code coverage result of the source code based on the code coverage data. The code coverage result of the source code includes a code coverage rate of calling the source code through the target interface.

[0129] The instrumentation unit 801, acquisition unit 802, and display unit 803 can all be implemented in software or hardware. For example, the implementation of the instrumentation unit 801 will be described below using the instrumentation unit 801 as an example. Similarly, the implementation of the acquisition unit 802 and display unit 803 can refer to the implementation of the instrumentation unit 801.

[0130] As an example of a software functional unit, the plug-in unit 801 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, module A may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0131] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0132] As an example of a hardware functional unit, module A may include at least one computing device, such as a server. Alternatively, the plug-in unit 801 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0133] The multiple computing devices included in the instrumentation unit 801 can be distributed in the same region or in different regions. The multiple computing devices included in the instrumentation unit 801 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the instrumentation unit 801 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0134] It should be noted that in other embodiments, the instrumentation unit 801 is used to execute process S301 in Figure 3 or Figure 6; the acquisition unit 802 is used to execute process S302 in Figure 3 or Figure 6; and the display unit 803 is used to execute process S303 in Figure 3 or Figure 6. The steps that the instrumentation unit 801, acquisition unit 802, and display unit 803 are responsible for implementing can be specified as needed. The full functionality of the code testing device 80 is achieved by having the instrumentation unit 801, acquisition unit 802, and display unit 803 respectively implement different steps in the code testing method provided in Figure 3 or Figure 6.

[0135] The embodiment of the present application provides a schematic diagram of the structure of a computing device 900. Exemplarily, the computing device 900 can implement the functions of the statistics platform 202 shown in FIG2 .

[0136] As shown in Figure 9, computing device 900 may include a bus 902, a processor 904, a memory 906, and a communication interface 908. Processor 904, memory 906, and communication interface 908 communicate with each other via bus 902. Computing device 900 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 900.

[0137] Bus 902 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG9 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 902 may include a path for transmitting information between various components of computing device 900 (e.g., memory 906, processor 904, and communication interface 908).

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

[0139] The memory 906 may include volatile memory, such as random access memory (RAM). The processor 904 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0140] The communication interface 908 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 900 and other devices or a communication network.

[0141] On the other hand, the memory 906 in the computing device 900 shown in FIG. 9 provided by this application stores executable program code, and the processor 904 executes the executable program code to respectively implement the functions of the aforementioned instrumentation unit 801, acquisition unit 802, and display unit 803, thereby implementing the code testing method illustrated in FIG. 3 or FIG. 6 . In other words, the memory 906 stores instructions for executing the code testing method illustrated in FIG. 3 or FIG. 6 .

[0142] In another aspect, an embodiment of the present application further provides a computing device cluster as shown in FIG10 . The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0143] As shown in Figure 10, the computing device cluster includes at least one computing device 900. The memory 906 in one or more computing devices 900 in the computing device cluster may store the same instructions for executing the code testing method illustrated in Figure 3 or Figure 6.

[0144] In some possible implementations, the memory 906 of one or more computing devices 900 in the computing device cluster may also store partial instructions for executing the code testing method illustrated in FIG3 or FIG6 . In other words, the combination of one or more computing devices 900 can jointly execute instructions for executing the code testing method illustrated in FIG3 or FIG6 .

[0145] It should be noted that the memories 906 in different computing devices 900 in the computing device cluster may store different instructions, each for executing part of the functions of the code testing apparatus 80. In other words, the instructions stored in the memories 906 in different computing devices 900 may implement the functions of one or more modules in the instrumentation unit 801, the acquisition unit 802, and the display unit 803.

[0146] In some possible implementations, one or more computing devices 900 in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG11 shows a possible implementation. As shown in FIG11 , two computing devices 900A and 900B are connected via a network. Specifically, the connection to the network is made via a communication interface in each computing device. In this type of possible implementation, the memory 906 in the computing device 900A stores instructions for executing the functions of the plug-in unit 801. At the same time, the memory 906 in the computing device 900B stores instructions for executing the functions of the acquisition unit 802 and the display unit 803.

[0147] The connection method between the computing device clusters shown in Figure 11 can be considered to be that the code testing method provided in this application requires a large amount of data storage, so it is considered to hand over the functions implemented by the acquisition unit 802 and the display unit 803 to the computing device 900B for execution.

[0148] It should be understood that the functionality of the computing device 900A shown in FIG11 may also be implemented by multiple computing devices 900. Similarly, the functionality of the computing device 900B may also be implemented by multiple computing devices 900.

[0149] In another aspect, embodiments of the present application further provide a computer program product comprising instructions. The computer program product may be software or a program product comprising instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the code testing method illustrated in FIG. 3 or FIG. 6 .

[0150] On the other hand, an embodiment of the present application further provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the code testing method illustrated in Figure 3 or Figure 6 above, or instruct the computing device to execute the code testing method illustrated in Figure 3 or Figure 6 above.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A code testing method, characterized in that: The method is used to test source code using a test case, wherein the source code includes at least one class, and the test case is used to test the source code by calling at least one interface of the source code, and the method includes: Instrumenting at least one of the classes included in the source code to record code coverage data of calling the class from a target interface in the at least one interface, wherein the code coverage data is used to indicate an execution status of the class; When the source code is tested using the test case, code coverage data when at least one of the classes in the source code is called from the target interface is obtained; Based on the code coverage data, a code coverage result of the source code is displayed, where the code coverage result of the source code includes a code coverage rate of calling the source code through the target interface.

2. The method according to claim 1, characterized in that The at least one class included in the source code includes an entry class, and the inserting of the at least one class included in the source code includes: The entry class of the source code is bytecode enhanced to record that the test case calls the interface of the source code as the target interface.

3. The method according to claim 1 or 2, characterized in that: The instrumenting at least one of the classes included in the source code comprises: A variable is added to the at least one class included in the source code, the variable is used to record the code coverage data of the test case calling the class through the target interface, and the key of the data structure of the variable is the interface identifier.

4. The method according to claim 3, characterized in that The data structure of the variable is HashMap<String,Boolean[]> .

5. The method according to any one of claims 1 to 4, characterized in that: The source code includes a plurality of functions, and the method further includes: Acquire a function calling relationship of the source code, where the function calling relationship is a calling sequence between the multiple functions in a process in which the test case tests the source code by calling the target interface; The function calling relationship of the source code is displayed.

6. The method according to claim 5, characterized in that The function calling relationship of the source code includes a static calling relationship, and obtaining the function calling relationship of the source code includes: Perform static analysis on the source code to obtain a static calling relationship of the source code.

7. The method according to claim 5 or 6, characterized in that: The function calling relationship of the source code includes a dynamic calling relationship, and obtaining the function calling relationship of the source code includes: In the process of testing the source code by using the test case, the source code is dynamically analyzed to obtain the dynamic calling relationship of the source code.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: Bytecode enhancement is performed at the entrances and exits of the multiple functions to record the dynamic calling relationship when the source code is executed, the entrance is the location where the function starts to execute, and the exit is the location where the function ends to execute.

9. A code testing device, characterized in that: The apparatus is used to test source code using a test case, wherein the source code includes at least one class, and the test case is used to test the source code by calling at least one interface of the source code, and the apparatus includes: an instrumentation unit, configured to instrument at least one of the classes included in the source code to record code coverage data of calling the class from a target interface in the at least one interface, wherein the code coverage data is used to indicate an execution status of the class; an acquisition unit, configured to acquire code coverage data when at least one of the classes in the source code is called from the target interface after the source code is tested using the test case; A display unit is used to display a code coverage result of the source code based on the code coverage data, where the code coverage result of the source code includes a code coverage rate of calling the source code through the target interface.

10. The device according to claim 9, characterized in that The at least one class included in the source code includes an entry class, and the instrumentation unit is specifically used for: The entry class of the source code is bytecode enhanced to record that the test case calls the interface of the source code as the target interface.

11. The device according to claim 9 or 10, characterized in that The plugging unit is specifically used for: A variable is added to the at least one class included in the source code, the variable is used to record the code coverage data of the test case calling the class through the target interface, and the key of the data structure of the variable is the interface identifier.

12. The device according to claim 11, characterized in that The data structure of the variable is HashMap<String,Boolean[]> .

13. The device according to any one of claims 9 to 12, characterized in that: The source code includes a plurality of functions, and the device further includes: A calling relationship acquisition unit, used for acquiring the function calling relationship of the source code, which is the calling sequence between the multiple functions in the process of the test case calling the target interface to test the source code; A display unit is used to display the function calling relationship of the source code.

14. The device according to claim 13, characterized in that The function calling relationship of the source code includes a static calling relationship, and the calling relationship obtaining unit is specifically used for: Perform static analysis on the source code to obtain a static calling relationship of the source code.

15. The device according to claim 13 or 14, characterized in that The function calling relationship of the source code includes a dynamic calling relationship, and the calling relationship obtaining unit is specifically used for: In the process of testing the source code by using the test case, the source code is dynamically analyzed to obtain the dynamic calling relationship in the source code.

16. The device according to any one of claims 9 to 15, characterized in that: The device also includes: The processing unit is used to perform bytecode enhancement at the entry and exit of the multiple functions to record the dynamic calling relationship when the source code is executed, the entry is the position where the function starts to execute, and the exit is the position where the function ends to execute.

17. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 8.

18. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 8.

19. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.

Images