Code testing method and device

Abstract

The invention provides a code testing method and device, relates to the field of computers, and aims to provide code coverage data of an interface dimension and quickly position a test responsible person to supplement a test case. The method comprises the steps that instrumentation is conducted on at least one class included in a source code so as to record code coverage data of the class called from a target interface in at least one interface, and the code coverage data is used for indicating the execution condition of the class; when the source code is tested by using the test case, obtaining code coverage data when at least one class in the code is called from the target interface; and based on the code coverage data, displaying a code coverage result of the source code, the code coverage result of the source code including calling the code coverage data of the source code through the target interface.

Description

[0001] This application claims the priority of 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”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application 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 an indicator for evaluating the quality of code testing. Code coverage data refers to the proportion and degree of source code being tested during testing. The fundamental purpose of statistical code coverage data is to find potential missing test cases and supplement them in a targeted manner.

[0005] Currently, relevant code coverage data is counted at the service granularity. In some scenarios, when testers supplement test cases, they divide the responsible persons according to the application program interface (API). When supplementing test cases based on uncovered data, it is difficult to determine the responsible persons. Therefore, there is an urgent need for code coverage data from the API interface perspective to quickly locate the responsible persons for supplementing test cases. Summary of the invention

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

[0007] In order to achieve the above purpose, the embodiment of the present application adopts the following technical solution:

[0008] In a first aspect, a code testing method is provided, which is used to test source code using a test case, 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 method specifically includes: inserting at least one class included in the source code to record code coverage data of calling the class from a target interface in the at least one interface, the code coverage data is used to indicate the execution status of the class; after the source code is tested using the test case, the code coverage data of calling at least one class included in the source code from the target interface is obtained; based on the code coverage data, the code coverage result of the source code is displayed, and the code coverage result of the source code includes the code coverage rate of calling the source code through the target interface.

[0009] Through the solution provided in the present 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, so as 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.

[0010] In a possible implementation, the code coverage data when one less class is included in the source code called from the target interface is the code coverage raw data of the source code when the class is called from the target interface obtained by the instrumentation, and the raw data indicates the code coverage rate. The code coverage rate of the source code called through the target interface is the code coverage ratio expressed in the form of a graph or a numerical value. The code coverage rate of the source code called through the target interface can be converted from the code coverage data when one less class is included in the source code called from the target interface.

[0011] In another possible implementation, at least one class included in the source code includes an entry class, and the above-mentioned instrumentation of at least one class included in the source code includes: performing bytecode enhancement on the entry class of the source code to record the interface of the test case calling the source code as the target interface. Since the entry class is the first code executed when calling, performing bytecode enhancement on the entry class can accurately record the target interface.

[0012] In another possible implementation, inserting a stub into at least one class included in the source code includes: adding a variable to at least one class included in the source code, the variable being used to record code coverage data of a test case calling a class through a target interface, wherein a key of a data structure of the variable is an interface identifier. Inserting a stub by means of a variable can achieve more efficient code insertion and minimize the impact of the insertion on the source code.

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

[0014] In another possible implementation, the source code includes multiple functions, and the method may also include: obtaining a function call relationship of the source code, the function call relationship being the calling order between the multiple functions in the process of the test case testing the source code by calling the target interface; and displaying the function call relationship of the source code. Since the function call relationship reflects the calling order of the functions in the process of the test case testing the source code, when supplementing the test case to analyze a certain function, it is easy to drill down and explore up by using the automatically obtained function call relationship, reducing the difficulty of supplementing the test case, and further improving the efficiency and quality of the test quality assessment.

[0015] In another possible implementation, the function call relationship of the source code includes a static call relationship, and obtaining the function call relationship of the source code includes: performing static analysis on the source code to obtain the static call relationship of the source code. Through static analysis, the static call relationship can be obtained before the source code is executed, avoiding the influence of obtaining the function call relationship on the source code.

[0016] In another possible implementation, the function call relationship of the source code includes a dynamic call relationship, and obtaining the function call relationship of the source code includes: in the process of testing the source code using the test case, dynamically analyzing the source code to obtain the dynamic call relationship of the source code. Obtaining the dynamic call relationship by dynamic analysis improves the accuracy of the function call relationship and can better help supplement the test case.

[0017] In another possible implementation, the method may further include: performing bytecode enhancement at 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 of the function is the location where the function starts to execute, and the exit of the function is the location where the function ends to execute. Since the entry of the function reflects the association with the previous function, and the exit of the function reflects the association with the next function, therefore, performing bytecode enhancement at the entry and exit of the function can accurately record the function call relationship.

[0018] In a second aspect, a code testing device 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 device includes: an insert unit, an acquisition unit, and a display unit.

[0019] in:

[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, wherein the code coverage data is used to indicate the execution status of the class.

[0021] The acquisition unit is used to acquire 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, and 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 used 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 method.

[0027] It should be noted that various possible implementation methods 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 This is a schematic diagram of a service-level code coverage data display page based on native Jacoco;

[0029] Figure 2 A schematic diagram of the structure of a computer system provided in an embodiment of the present application;

[0030] Figure 3 A flowchart of a method for obtaining code coverage data provided in an embodiment of the present application;

[0031] Figure 4 A schematic diagram of performing bytecode enhancement on an API entry class of a JAVA program provided in an embodiment of the present application;

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

[0033] Figure 6 A flowchart of another method for obtaining code coverage data provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of the implementation process of the solution provided in the embodiment of the present application;

[0035] Figure 8 A schematic diagram of the structure of a code testing device provided in an embodiment of the present application;

[0036] Fig. 9 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0037] Fig.10 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0038] Fig.11 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 identical functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different. There is no order of precedence or size between the technical features described by the "first" and "second".

[0040] In the embodiments of the present 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 the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy 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 the present 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. A person of ordinary skill in the art can appreciate that with the evolution of the 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 the present 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 a test task for a specific software product, reflecting the test plan, method, technology and strategy. Its content includes test objectives, test environment, input data, test steps, expected results, test scripts, etc., and finally forms a document. It can be understood that a test case is a set of test inputs, execution conditions and expected results compiled for a special goal, which is used to verify whether a specific software requirement is met.

[0047] Code coverage is a metric in software testing that describes the proportion and degree of source code tested in a program. 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] In the testing of programs written in JAVA language, Jacoco is commonly used to collect code coverage of the business and evaluate the test quality of the tested service. 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 This shows the service-level code coverage data display page based on native Jacoco. Figure 1 As shown, the display page includes statistical data on code coverage (line coverage, branch coverage, method coverage) of different dimensions for each service during the test process, and displays them in the form of graphics.

[0050] The service-level code coverage data only has one copy of the coverage data for the class in the source code, and it is impossible to confirm which scenario (test case) triggered the test coverage in the class. In actual JAVA programs, a function often involves calls to multiple API interfaces. At this time, based on the coverage data, it is impossible to confirm which API interface actually tested the specified line in the function, and which APIs have not tested this function. Therefore, in the service-level code coverage data collection solution, it is difficult to determine which uncovered branches belong to a certain tester, and it is not easy to locate the tester so that the tester 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 being 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 code coverage data of the statistical interface dimension, so that in the scenario of testers whose responsibilities are divided 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 solution provided by the embodiments of the present application is described in detail below in conjunction with the accompanying drawings.

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

[0055] The test platform 201 is used to test the source code, and the statistical platform 202 is used to count the code coverage data during the test of the test platform 201 and 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, Figure 2 The test platform 201, the statistical platform 202 and the display platform 203 included in the illustrated computer system may be deployed separately or integrated, and the embodiments of the present application do 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] certainly, Figure 2 The example description of the computer system applying the solution of the present application is only 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, the present invention provides a method for testing a code. Figure 2 In the statistical platform 202 in the illustrated computer system, the method can be executed by a computing device. The method is used to test source code using a test case. The source code includes at least one class. The test case is used to test the source code by calling at least one interface of the source code.

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

[0062] S301: A computing device performs instrumentation on 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. The target interface can be one or more.

[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 stubs 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 stub for a class described in S301 can be used to obtain code coverage data of the source code for each target interface when the test case calls the 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, at least one class included in the source code may include an entry class, and the at least one class included in the source code is plugged in S301, including: performing bytecode enhancement on the entry class of the source code to record the interface of the test case calling the source code as the target interface. That is, performing bytecode enhancement on the interface entry class of the source code to record the processing interface of the current thread to identify the processing interface of the current thread.

[0075] like Figure 4 As shown, 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, which records the current interface information and completes the downward transmission of the interface information. The method for obtaining the instrumentation data group of 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: adding a variable in 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.

[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) inserts code coverage, records only one set of coverage data for each class, and automatically generates a $jacocoData array for each class to save the code coverage of the class.

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

[0085]

[0086] In S301, the native Jacoco tool (Agent) can be improved to improve the code coverage plug-in, record the code coverage data according to the interface dimension, and save multiple coverage data according to the interface dimension for each class coverage.<String,Boolean[]> Data structure, recording the instrumentation data of the class. When the key value of the data structure is the interface identifier, in this application, the instrumentation idea of ​​the class can be as follows:

[0087]

[0088] By comparing the above two plug-in ideas, it can be seen 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 obtain the currently processed API and record it in the thread-shared TransmittableThreadLocal structure. When the actual Class program is executed, the current API is obtained in the $jacocoTraceInit function, and the coverage array of the corresponding processing API of the class is returned. Subsequent stub probes can record the coverage identifier to the coverage array of the specified API during the execution process.

[0089] Of course, in actual applications, the idea, data structure and specific code of the plug-in can be configured according to actual needs, and the above examples do not constitute specific limitations.

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

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

[0092] 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 a target interface.

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

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

[0095] For example, the code coverage data for calling a class from a target interface can be the number of lines of code in the class that are executed when the class is called from the target interface. Then, the code coverage rate of calling the class from the target interface can be obtained by dividing the number of lines of code executed by the total number of lines of code in the class. The sum of the code coverage rates of each class in the source code called from a target interface can be used as the code coverage rate of calling the source code from the target interface.

[0096] Specifically, S303 may be executed by the computing device or by another platform to which the computing device is connected. 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.

[0097] For example, Figure 5 A display page of code coverage of source code in interface dimension is illustrated. In the display page, a row in the display page is the code coverage of source code called from a target interface by a test case.

[0098] 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 the code coverage data in the interface dimension and quickly locate the person responsible for testing to supplement the test cases.

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

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

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

[0102] The function calling 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.

[0103] In a 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.

[0104] In a possible implementation, most function call relationships can be obtained by static analysis of the source code. However, in some scenarios, the 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 call, dynamic proxy, native method call, dynamic class loading, multithreading, etc.; among them:

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

[0106] 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. Since the dynamic proxy is created at runtime, the actual calling relationship between the proxied object and the proxy object cannot be obtained during static scanning.

[0107] Native method call: Native methods in Java call native C / C++ methods through Java native interface (Java native interface, JNI). Since JNI calls are performed at runtime and may involve the operation of other system resources, the calling relationship between Native methods and Java methods cannot be obtained during static scanning.

[0108] Dynamically loaded classes: Classes in Java can be dynamically loaded at runtime through methods such as Class.forName(). Since it is impossible to obtain information about dynamically loaded classes during static scanning, it is also impossible to accurately obtain the calling relationship between methods in dynamically loaded classes.

[0109] Multithreading: Multithreaded programs in Java will have uncertainty during runtime, which may cause changes in function call relationships. Therefore, when performing static analysis on multithreaded programs, it may not be possible to obtain the function call relationships completely and accurately.

[0110] Furthermore, the function calling relationship of the source code includes a static calling relationship and a dynamic calling 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 calling relationship of the source code.

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

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

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

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

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

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

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

[0118] For example, the implementation process of the solution provided in the embodiment of the present application can be as follows: Figure 7 As shown, it can specifically include the following three stages:

[0119] Phase 1. Test environment initialization phase:

[0120] When the test service is just started, the coverage data tool collects the class data of the JAVA source code program by analyzing the source code, and inserts each class in the source code stored in the data storage system. Then, the call relationship service is notified to calculate the static call relationship of the function and start recording the dynamic call relationship. The call relationship service will then store the static call relationship of the function in the database.

[0121] Phase 2. Test execution phase:

[0122] 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 the API dimension coverage data of each class through the insertion probe and continuously reports it to the data storage system.

[0123] Phase 3. End of testing:

[0124] After the test is completed, the test execution machine scheduling system notifies the coverage data calculation service to calculate the coverage data of the source code in the interface dimension. The coverage data calculation service obtains the coverage data recorded during the test from the data storage system, calculates the coverage of the source code in the interface dimension, and displays the results to the code coverage analysis service (which can be a platform).

[0125] 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 is understandable 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 easily appreciated by those skilled in the art 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 exceed the scope of the present invention.

[0126] The embodiment of the present invention can divide the functional modules of the computing device according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0127] The present application also provides a code testing device 80, such as Figure 8 As shown, the code testing device 80 may include: an inserting unit 801, an acquiring unit 802 and a display unit 803. Among them:

[0128] The instrumentation unit 801 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.

[0129] The acquisition unit 802 is used to acquire 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.

[0130] The display unit 803 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.

[0131] Among them, the plugging unit 801, the acquisition unit 802 and the display unit 803 can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the plugging unit 801 is introduced below by taking the plugging unit 801 as an example. Similarly, the implementation of the acquisition unit 802 and the display unit 803 can refer to the implementation of the plugging unit 801.

[0132] As an example of a software functional unit, the plug-in unit 801 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned 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 a data center or multiple data centers with similar geographical locations. Among them, usually a region may include multiple AZs.

[0133] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0134] As an example of a hardware functional unit, module A may include at least one computing device, such as a server, etc. Alternatively, the plug-in unit 801 may also be a device 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.

[0135] The multiple computing devices included in the plug-in unit 801 can be distributed in the same region or in different regions. The multiple computing devices included in the plug-in unit 801 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the plug-in 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.

[0136] It should be noted that, in other embodiments, the plugging unit 801 is used to execute Figure 3 or Figure 6 Process S301 in; the acquisition unit 802 is used to execute Figure 3 or Figure 6 Process S302 in the display unit 803 is used to execute Figure 3 or Figure 6 The steps implemented by the plugging unit 801, the acquisition unit 802 and the display unit 803 can be specified as needed, and the plugging unit 801, the acquisition unit 802 and the display unit 803 can be implemented respectively. Figure 3 or Figure 6 The different steps in the provided code testing method are used to implement the full functions of the code testing device 80 .

[0137] The present application embodiment provides a schematic diagram of the structure of a computing device 900. For example, the computing device 900 can implement Figure 2 The functions of the statistics platform 202 are shown in FIG.

[0138] like Fig. 9 As shown, the computing device 900 may include a bus 902, a processor 904, a memory 906, and a communication interface 908. The processor 904, the memory 906, and the communication interface 908 communicate with each other through the bus 902. The computing device 900 may be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 900.

[0139] The bus 902 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9The bus 902 may include a path for transmitting information between various components of the computing device 900 (eg, the memory 906, the processor 904, and the communication interface 908).

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

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

[0142] 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 communication networks.

[0143] On the other hand, the present application provides Fig. 9 The memory 906 in the computing device 900 shown in the figure stores executable program codes, and the processor 904 executes the executable program codes to respectively implement the functions of the aforementioned plugging unit 801, the acquisition unit 802, and the display unit 803, thereby implementing the aforementioned Figure 3 or Figure 6 The code testing method is shown in FIG. 1 . That is, the memory 906 stores the code for executing the above Figure 3 or Figure 6 Illustrated code test method instructions.

[0144] On the other hand, the present application embodiment also provides a Fig.10 The computing device cluster shown. 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, a laptop, or a smart phone.

[0145] like Fig.10 As shown, 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 Figure 3 or Figure 6 Illustrated code test method instructions.

[0146] In some possible implementations, the memory 906 of one or more computing devices 900 in the computing device cluster may also store the memory 906 for executing the above Figure 3 or Figure 6 In other words, the combination of one or more computing devices 900 can jointly execute the above-mentioned Figure 3 or Figure 6 Illustrated code test method instructions.

[0147] It should be noted that the memory 906 in different computing devices 900 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the code testing device 80. That is, the instructions stored in the memory 906 in different computing devices 900 can implement the functions of one or more modules in the plugging unit 801, the acquisition unit 802 and the display unit 803.

[0148] In some possible implementations, one or more computing devices 900 in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.11 A possible implementation is shown. Fig.11 As shown, two computing devices 900A and 900B are connected via a network. Specifically, the network is connected 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 plugging 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.

[0149] Fig.11 The connection method between the computing device clusters shown may be based on the consideration that the code testing method provided in the present application requires a large amount of data storage, and therefore the functions implemented by the acquisition unit 802 and the display unit 803 are considered to be executed by the computing device 900B.

[0150] It should be understood that Fig.11 The functions of the computing device 900A shown in FIG. 9A may also be completed by multiple computing devices 900. Similarly, the functions of the computing device 900B may also be completed by multiple computing devices 900.

[0151] In another aspect, the present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above Figure 3 or Figure 6 Illustrative code testing method.

[0152] On the other hand, the embodiments of the present application also provide 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 that contains 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 hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above Figure 3 or Figure 6 Schematic code testing method, or instruct the computing device to execute the above Figure 3 or Figure 6 Illustrative code testing method.

[0153] 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 cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the 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: Performing stubbing on 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; After 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