Code testing method, electronic equipment, storage medium and program product

Abstract

The invention provides a code testing method, electronic equipment, a storage medium and a program product, relates to the technical field of computers, and is used for performing omission-free testing on target codes and determining untested codes according to corresponding testing results by performing static and dynamic testing on the target codes. And generating a test case for the untested target code. The method comprises the following steps: testing a target code to obtain a first test result; the first test result comprises a first code line tested by the static test and a second code line tested by the dynamic test; determining a target code line based on the first code line and the second code line; the target code line represents a complementary set of an intersection of the first code line and the second code line in the target code; constructing a first test case based on the target code line; testing the target code based on the first test case to obtain a second test result; the second test result comprises a third code line tested by the first test case.

Description

Technical Field

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

[0002] As software systems become increasingly complex, new challenges arise for the software testing industry. Traditional test case design methods struggle to cover all code logic, leading to defects and a high risk of missing code. Furthermore, the pursuit of code coverage results in numerous redundant tests, reducing the efficiency of code testing. Summary of the Invention

[0003] This application provides a code testing method, electronic device, storage medium, and program product to solve the problem that current code testing is difficult to cover all code logic and has high test redundancy.

[0004] In a first aspect, this application provides a code testing method, comprising: testing target code to obtain a first test result; the first test result includes static test results and dynamic test results, the static test result including a first line of code tested by static testing, and the dynamic test result including a second line of code tested by dynamic testing; determining a target line of code based on the first line of code and the second line of code; the target line of code representing the complement of the intersection of the first line of code and the second line of code in the target code; constructing a first test case based on the target line of code; testing the target code based on the first test case to obtain a second test result; the second test result including a third line of code tested by the first test case.

[0005] The technical solution provided in this application brings at least the following benefits: by jointly identifying the lines of code with test coverage differences through static test results and dynamic test results, it is possible to consider multiple test results, predict code that may not be tested in advance, generate new test cases based on this part of the code, and conduct targeted testing on code that may not be covered by tests, thereby improving the test coverage of code testing.

[0006] In one possible implementation, testing the target code to obtain a first test result includes: parsing the target code and generating a function call graph (FCG) and / or a data flow dependency graph (DDG) of the target code; based on the FCG and / or DDG, predicting the first line of code executed by the target code during dynamic testing; inserting tracking code into the code line of the target code; and performing dynamic testing on the target code to determine the second line of code where the tracking code runs during the dynamic testing process is located.

[0007] Based on the above implementation method, the logic of the code is identified by FCG and DDG, the potential test blind spots of the code are predicted, and the test coverage of the code is collected based on bytecode instrumentation. The dynamic and static code test coverage verification method can accurately capture test blind spots, which is beneficial for testing complex logic code.

[0008] In another possible implementation, the method further includes: determining the test coverage of the target code based on the second line of code, the third line of code, and the target code; and issuing a warning message if the test coverage is lower than a threshold. Based on the above implementation method, the test coverage of the code is monitored. If it is lower than the threshold, a prompt message is issued to remind technical personnel to intervene, so as to avoid the system performing a large number of invalid tests under low test coverage, which would waste resources and time.

[0009] In another possible implementation, test coverage includes at least one of the following: line-of-code test coverage, branch-of-code test coverage, function test coverage, loop test coverage, and path test coverage; line-of-code test coverage represents the proportion of tested lines of code in the target code to the total number of lines of code; branch-of-code test coverage represents the proportion of tested branches of code in the target code to all branches; function test coverage represents the proportion of functions called during testing to all functions in the target code; loop coverage represents the test coverage ratio for different execution scenarios of loop structures in the target code; and path coverage represents the proportion of tested paths to all paths in the target code.

[0010] Based on the above implementation method, multi-dimensional code test coverage statistics can accurately capture the code test coverage of complex logic such as function branches and exception handling paths.

[0011] In another possible implementation, the method further includes: adding the first test case to the test case library; the test case library includes multiple test cases; determining the similarity between every two test cases in the test case library based on cosine similarity; the similarity characterizes the degree of duplication of the code under test when the target code is tested using two test cases; and merging test cases with a similarity greater than a preset similarity.

[0012] Based on the above implementation method, by merging test cases with high similarity, redundant testing of the target code is reduced, thereby improving the efficiency of code testing.

[0013] In another possible implementation, the test cases in the test case library have corresponding tags; the tags represent the test type of the test case; the test type represents the type of code that the test case is used to test, and the code type includes at least one of code line, code branch, function, loop, and path; the method also includes: in response to a change in the target code, determining the code type of the changed code; based on the code type and tag of the changed code, determining a fourth test case; testing the changed code based on the fourth test case to obtain a third test result; the third test result includes the code lines that the fourth test case has tested.

[0014] Based on the above implementation method, on the one hand, it can quickly respond to code changes and automatically test the changed code; on the other hand, test cases are classified by tags, so when code changes, test cases can be quickly identified based on the changed code and the corresponding test case tags, thus improving the efficiency of code testing.

[0015] Another possible implementation method includes: visually annotating the tested lines of code in the target code based on test coverage; wherein the annotation methods for lines of code, code branches, functions, loops and paths in the target code are different.

[0016] Based on the above implementation method, by annotating the tested code, technical personnel can quickly understand which code has been tested, and different annotation methods can be used for different branches, functions and other code logic to distinguish the test coverage of code under different code logic.

[0017] In another possible implementation, the method further includes: visual annotations including color annotations, wherein the annotation colors are related to the numerical value of the test coverage.

[0018] Based on the above implementation method, using different colors to represent test coverage can also intuitively allow technical personnel to understand the current test code coverage, without having to rely on statistics to find out.

[0019] In another possible implementation, the method further includes: visually annotating a fourth line of code in the target code, excluding the first and second lines of code; the annotation method of the fourth line of code is different from the annotation method of the tested lines of code in the target code.

[0020] Based on the above implementation method, by annotating untested code in a way that is different from that of tested code, technicians can quickly identify tested and untested code, reducing the time spent by technicians analyzing test results.

[0021] In another possible implementation, the target code is composed of one or more languages, and both the first test result and the second test result are generated based on a preset language, which may be the same as or different from any of the languages ​​that constitute the target code.

[0022] Based on the above implementation method, for code composed of multiple languages, test results are generated through a common preset language, reducing the time cost for technical personnel to view the test results.

[0023] Secondly, embodiments of this application provide a code testing apparatus, comprising: The testing module is used to test the target code and obtain the first test result. The first test result includes static test results and dynamic test results. The static test result includes the first line of code that has been tested by static testing, and the dynamic test result includes the second line of code that has been tested by dynamic testing. The processing module is used to determine the target code line based on the first code line and the second code line; the target code line represents the complement of the intersection of the first code line and the second code line in the target code. The processing module is also used to build the first test case based on the target line of code; The testing module is also used to test the target code based on the first test case to obtain a second test result; the second test result includes the third line of code that has been tested by the first test case. The target code is composed of one or more languages, and both the first and second test results are generated based on a preset language, which may be the same as or different from any language that constitutes the target code.

[0024] In one possible implementation, the test module is also used to parse the target code, generate a function call graph (FCG) and / or a data flow dependency graph (DDG) of the target code; based on the FCG and / or DDG, predict the first line of code executed by the target code during dynamic testing; insert instrumentation code into the line of code of the target code; perform dynamic testing on the target code, and determine the second line of code where the instrumentation code runs during the dynamic testing process is located.

[0025] In another possible implementation, the processing module is also used to determine the test coverage of the target code based on the second line of code, the third line of code, and the target code; if the test coverage is lower than a threshold, a warning message is issued. Test coverage includes at least one of the following: line-of-speech test coverage, branch-of-speech test coverage, function test coverage, loop test coverage, and path test coverage; line-of-speech test coverage represents the proportion of tested lines of code in the target code to the total number of lines of code; branch-of-speech test coverage represents the proportion of tested branches of code in the target code to all branches; function test coverage represents the proportion of functions called during testing to all functions in the target code; loop coverage represents the test coverage ratio for different execution scenarios of loop structures in the target code; and path coverage represents the proportion of tested paths to all paths in the target code.

[0026] In another possible implementation, the processing module is also used to add the first test case to the test case library; the test case library includes multiple test cases; based on cosine similarity, the similarity between every two test cases in the test case library is determined; the similarity characterizes the degree of duplication of the code under test when the target code is tested using two test cases; and test cases with a similarity greater than a preset similarity are merged.

[0027] In another possible implementation, the test cases in the test case library have corresponding tags; the tags represent the test type of the test case; the test type represents the type of code that the test case is used to test, and the code type includes at least one of code line, code branch, function, loop, and path. The test module is also used to determine the code type of the changed code in response to changes in the target code; based on the code type and tag of the changed code, a fourth test case is determined; the changed code is tested based on the fourth test case to obtain a third test result; the third test result includes the code lines that the fourth test case has tested.

[0028] In another possible implementation, the processing module is also used to visually annotate the tested lines of code in the target code based on test coverage; where the annotation methods for lines of code, code branches, functions, loops, and paths in the target code differ. Visual annotation includes color-coding, where the annotation color is related to the numerical value of the test coverage.

[0029] In another possible implementation, the processing module is also used to visually annotate the fourth line of code in the target code, excluding the first and second lines of code; the annotation method of the fourth line of code is different from the annotation method of the tested lines of code in the target code.

[0030] Thirdly, this application provides an electronic device, including: a processor and a memory, the processor being coupled to the memory; the memory being used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the method described in the first aspect.

[0031] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0032] Fifthly, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method described in the first aspect.

[0033] The beneficial effects of the second to fifth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0034] Figure 1 A flowchart illustrating a code testing method provided in an embodiment of this application; Figure 2 A flowchart illustrating another code testing method provided in an embodiment of this application; Figure 3 A schematic diagram of a coverage detection process provided in an embodiment of this application; Figure 4 A flowchart illustrating a static / dynamic coverage analysis provided in this application embodiment; Figure 5 A flowchart illustrating a test case management process provided in this application embodiment; Figure 6 A schematic diagram of an incremental test process provided in an embodiment of this application; Figure 7 A flowchart illustrating a visual representation of an embodiment of this application; Figure 8 A schematic diagram illustrating another code testing process provided in an embodiment of this application; Figure 9 This is a schematic diagram illustrating the composition of a code detection device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] The following is a detailed description of a call detail record (CDR) data recording method provided in this application, with reference to the accompanying drawings.

[0036] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0037] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0038] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0039] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0040] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0041] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0042] As software systems become increasingly complex (e.g., distributed architecture, microservice architecture), traditional testing methods face the following challenges in the software testing industry: test cases struggle to cover all code logic, leading to a high risk of missing defects; redundant test cases increase execution costs and fail to focus on high-risk code areas; the lack of quantitative metrics to evaluate test adequacy makes it difficult to meet the needs of rapid iteration models such as agile development and DevOps; and traditional testing methods achieve an average code coverage of only 50%-60%, while defects in uncovered code can account for more than 30%.

[0043] Early code testing was mostly based on line coverage statistics, which only reflected the execution of lines of code and could not reflect deeper information such as logical branches and function calls. Later, the industry began to pay attention to test coverage in other dimensions, but the analysis of code logic is difficult to fully realize in complex systems.

[0044] To address the aforementioned issues, this application provides a code testing method. The approach involves using a combination of static and dynamic testing methods to identify potential testing blind spots and generating targeted test cases for untested code sections.

[0045] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0046] The code testing method provided in this application can be applied to electronic devices.

[0047] For example, an electronic device can be a server, such as a server cluster consisting of multiple servers, a single server, a computer, or a processor or processing chip within a server or computer. For example, an electronic device can also be a terminal, such as a mobile phone, tablet computer, wearable device, in-vehicle device, laptop computer, or ultra-mobile personal computer. Mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. It should be noted that the embodiments of this application do not limit the specific device form of the electronic equipment.

[0048] Figure 1 This is a flowchart illustrating a code testing method provided in an embodiment of this application.

[0049] like Figure 1 As shown, the code testing method provided in this application can be implemented using the aforementioned electronic device, specifically including S101~S104.

[0050] S101. Test the target code and obtain the first test result.

[0051] The first test result includes static test results and dynamic test results. The static test result includes the first line of code that has been tested by static testing, and the dynamic test result includes the second line of code that has been tested by dynamic testing.

[0052] The target code can be the code to be tested, and it can be written in one or more languages. In this embodiment, all test results generated from testing the target code are output using a unified intermediate format. For example, a program written in Java and Go can output test results in JSON format. Testing the target code includes static testing and dynamic testing.

[0053] Static testing refers to determining the syntax errors, logical vulnerabilities, and other problems in the target code by performing static analysis on the target code without actually running it. In this embodiment of the application, static testing also includes predicting the lines of code that may not be covered when testing the target code with test cases. The corresponding static test results can include the corresponding prediction results, that is, the lines of code that are run and the lines of code that are not run when testing the target code with test cases.

[0054] For example, static testing can be implemented in the following way: The target code is parsed to generate a function call graph (FCG) and / or a data dependence graph (DDG). An FCG is a directed graph used to visually represent the call and called relationships between functions in a program. It clearly presents the call path during function execution through combinations of nodes and edges. A DDG is also a directed graph used to describe the "definition, use, and transmission relationships of data" in a program, focusing on the flow and dependency logic of data between variables, statements, or functions.

[0055] Based on the FCG and / or DDG, predict the first line of code that the target code will execute during dynamic testing.

[0056] Specifically, the Function Check Group (FCG) is used to check whether the general test cases cover all function nodes in the graph. Uncovered function nodes (i.e., functions that have never been called) directly reflect gaps in function coverage. Paths in the FCG (such as A→B→C) correspond to the program's execution flow. By comparing the actual call paths of the general test cases with all possible paths in the FCG, uncovered critical paths (e.g., whether the call paths of exception handling functions have been tested) can be identified.

[0057] Furthermore, by analyzing the missing code not found by FCG, we can further analyze it through DDG. If a certain data path (such as user input → validation function → database write) exists in DDG but is not covered by test cases, it may lead to hidden data flow vulnerabilities (e.g., the processing logic after abnormal input passes through the validation function is not tested).

[0058] Dynamic testing refers to actually running the target code and observing the output results through input data to verify its functionality. In this embodiment, dynamic testing also includes testing the target code using general test cases to identify lines of code not covered by the general test cases during the testing process. Specifically, covered / uncovered lines of code during testing refer to lines of code that are executed / not executed during the testing process. The executed objects are not necessarily measured in lines of code; they can also be code branches, logical functions, functional modules, etc.

[0059] Dynamic testing can be conducted in the following ways: Insert tracking code into the code line of the target code, perform dynamic testing on the target code, and determine the second code line where the tracking code runs during the dynamic testing process.

[0060] Specifically, dynamic testing can be achieved through dynamic bytecode instrumentation. By inserting detection logic code (insertion code) into the program, when the inserted code is executed, the instrumentation code records the number of executions and the execution location to statistically analyze the test coverage of the code under test. For example, instrumentation code can be inserted at the entry point of a line of code, branch conditions, function entry / exit points, exception handling points, etc.

[0061] S102. Determine the target line of code based on the first line of code and the second line of code.

[0062] The target code line represents the complement of the intersection of the first code line and the second code line in the target code.

[0063] For example, the target code is treated as the entire set, and the complement of the intersection of the first and second lines of code within the target code is taken as the target line of code. Theoretically, the results of static and dynamic tests should match, meaning the intersection and union of the first and second lines of code should be the same. However, in actual testing, the first and second lines of code may differ. To avoid randomness, the complement of their intersection—the line of code not simultaneously covered by both—is taken as the target line of code for further targeted testing, thus preventing omissions in code testing due to randomness.

[0064] In some embodiments, in order to reduce the workload of supplementary testing, the complement of the union of the first line of code and the second line of code can be used as the target line of code, that is, the line of code covered by either dynamic testing or static testing is considered to be covered in actual testing.

[0065] In other embodiments, the complement of the intersection of the first and second code lines can be used as the target code line when the code difference covered by the first code line and the second code line is greater than a preset difference value, and the complement of the union of the two code lines can be used as the target code line when the difference is not greater than the preset difference value.

[0066] S103. Based on the target line of code, construct the first test case.

[0067] First, analyze the target code to clarify its core function and determine its input parameters (type, range, and format, etc.) and output results (expected output). Then, identify the key logical points in the target code (branch conditions, loop logic, exception handling, etc.). In some cases, boundary value testing and abnormal scenario testing should also be considered, and test cases should be constructed based on the above analysis results.

[0068] S104. Test the target code based on the first test case to obtain the second test result.

[0069] The second test result includes the third line of code that has been tested by the first test case.

[0070] Specifically, the code actually tested by the first test case is the target code line in the target code. The second test result can include the third code line covered during the testing process of the first test case, the code line not covered during the testing process of the first test case, the test coverage of the first test case, and the execution result of the target code line. When calculating the test coverage of the first test case, all code lines contained in the target code line are used as the denominator.

[0071] In some embodiments, after obtaining the second test result, the method further includes: Based on the second line of code, the third line of code, and the target code, the test coverage of the target code is determined. If the test coverage is lower than a threshold, a prompt message is issued.

[0072] The second and third lines of code are both covered lines of code obtained through dynamic testing. Combined with the target code, the test coverage of the target code is determined. Specifically, the test coverage of the target code includes at least one of the following: line test coverage, branch test coverage, function test coverage, loop test coverage, and path test coverage. In this context, line-of-code test coverage refers to the proportion of executed lines of code out of the total number of lines of code; branch-of-code test coverage refers to the proportion of executed branches out of the total number of branches; if / else, switch / case, ternary operators, etc., in a program generate branches, with each condition typically corresponding to two branches (true / false); function test coverage refers to the proportion of called functions (or methods) out of the total number of functions; loop test coverage refers to the test coverage for different loop scenarios (e.g., looping 0 times, looping once, looping multiple times, etc.); and path test coverage refers to the proportion of executed independent paths out of the total number of possible paths in the program. A "path" refers to a complete execution flow from the program's entry point to its exit point (formed by the combination of branch selections).

[0073] If the coverage of any one or more of the above tests is lower than the preset threshold (e.g., lower than 20%), a prompt message will be sent to the technical staff to request manual intervention, so as to avoid the system continuing to perform low coverage tests and wasting resources and time.

[0074] Based on the above embodiments, when testing the target code, both static test results and dynamic test results are referenced simultaneously. The two test results can be compared with each other to identify potential test blind spots, and then test cases can be generated in a targeted manner to improve the code test coverage efficiently. At the same time, it avoids the practice of using more test cases to sacrifice test efficiency in order to improve code test coverage.

[0075] In some embodiments, the test coverage obtained in the above embodiments can be visually annotated on the target code. The annotation methods differ for lines of code, code branches, functions, loops, and paths. For example, annotation methods may include using different colors, such as coloring the code font or using different colored boxes to select code. Furthermore, test coverage can also be represented by the depth or brightness of the color (adjusted by RGB values). For example, a line coverage of over 80% can be annotated in green, 50%-80% in yellow, and below 50% in red. Alternatively, a test coverage of over 80% can be represented by bright red, and below 50% by dark red.

[0076] In other embodiments, a fourth line of code in the target code, excluding the first and second lines, can be visually annotated. The annotation method for this fourth line differs from the annotation method for the tested lines of code in the target code.

[0077] For example, it can select tested code and color characters in untested code. In addition, it can generate visual charts, count branches, functions, and lines of code in the target code, and provide corresponding coverage statistics.

[0078] In some embodiments, after the tests in the above embodiments are completed, the first test case is added to the test case library; the test case library includes multiple test cases; based on cosine similarity, the similarity between every two test cases in the test case library is determined; the similarity represents the degree of duplication of the code under test when the target code is tested using two test cases; test cases with a similarity greater than a preset similarity are merged.

[0079] Specifically, the test case library includes multiple test cases, including at least the general test cases and the first test case in the above embodiments. To reduce the time wasted due to redundant testing, test cases with high test repetition are merged. For example, the similarity between any two test cases in the test case library is determined by cosine similarity. Here, similarity represents the degree of repetition between two test cases during the testing process. For example, if two test cases both test a certain piece of code, then that piece of code is tested repeatedly. When the similarity between two test cases is higher than a preset similarity (e.g., 80%), the two test cases are merged.

[0080] For example, first, it is necessary to determine the merging of test cases. If the duplicated parts are the "core process" and the differences are "minor variables" (such as different input values ​​or branch conditions), then merging is suitable. If the differences involve independent key test objectives (such as one test for normal process and one test for exception handling), even if the degree of duplication is high, merging is not recommended (the integrity of each should be preserved).

[0081] Depending on the differences, different merging methods can be adopted. For example, if there are differences in parameters, the differences in parameters of the test cases to be merged can be treated as "variables", and all possible values ​​and results can be listed during the merging process.

[0082] If there are differences between branches, such as two cases covering the same function but different branches (e.g., test case A covers if(a>0), test case B covers if(a<0)), the coverage targets of all branches must be clearly listed when merging.

[0083] By merging redundant test cases, redundant tests can be reduced, and the efficiency of code testing can be improved.

[0084] In some embodiments, test cases in the test case library have corresponding tags; the tags characterize the test type of the test case; the test type characterizes the code type that the test case is used to test, and the code type includes at least one of code line, code branch, function, loop, and path. The method further includes: in response to a change in the target code, determining the code type of the changed code; determining a fourth test case based on the code type of the changed code and the tags; testing the changed code based on the fourth test case to obtain a third test result; the third test result includes the code lines tested by the fourth test case.

[0085] The test cases in the test case library have corresponding tags. The tags identify the type of code that the test case is testing, such as testing a certain piece of code or testing a certain function.

[0086] Specifically, when the target code changes (e.g., technical personnel submit code changes), the location and type of the changed code are identified. The code type can represent the scope or function of the modified code, including at least one of the following: line of code, branch of code, function, loop, and path. For example, N lines of code were modified, code under a certain branch was modified, or a certain function was modified.

[0087] After determining the code type of the changed code, the test case library is used to filter and select a fourth test case to test the changed code. The changed code is then tested based on the fourth test case to obtain the third test result, which may include the lines of code that have been tested, the lines of code that have not been tested, and the test coverage.

[0088] By automatically responding to code changes and automatically selecting test cases for testing, it provides a better user experience for real-world development scenarios.

[0089] The code testing method of this application embodiment will be described below with reference to a specific example.

[0090] Figure 2 The flowchart of another code testing method provided in the embodiments of this application includes S201-S206.

[0091] S201. Input the code to be tested.

[0092] The code under test is equivalent to the target code in the aforementioned embodiments.

[0093] S202, Multidimensional Coverage Detection.

[0094] like Figure 3 The S202 shown includes S202a-S202c.

[0095] S202a, bytecode instrumentation / binary instrumentation.

[0096] By using dynamic bytecode instrumentation, data is collected from multiple dimensions, including line coverage, branch coverage, function coverage, loop coverage, and path coverage.

[0097] S202b, Data Standardization.

[0098] For multilingual projects, standardize coverage data across different languages ​​using a unified intermediate format (such as JSON). Employ hash algorithms (such as MD5) to identify code blocks, ensuring the accuracy of coverage merging across language modules.

[0099] S202c, Multidimensional Coverage Report.

[0100] The tested / untested code is colored to show uncovered lines of code, logical branches, functions, paths, etc.

[0101] S203, Static / Dynamic Coverage Analysis.

[0102] like Figure 4 As shown, S203 includes S203a-S203g.

[0103] S203a, Static Analysis.

[0104] Analyze the code under test to identify potentially uncalled functions, unused variables, etc.

[0105] S203b, Control Flow / Data Flow Graph Generation.

[0106] Generate a function call graph (FCG) and a data flow dependency graph (DDG) to predict possible uncovered paths (such as deeply nested conditions).

[0107] S203c, Prediction of Potentially Uncovered Areas.

[0108] Predict potentially uncovered code areas to obtain static test results.

[0109] S203d, real-time coverage acquisition.

[0110] The code under test is tested using common test cases, and test coverage data is collected.

[0111] S203e, compare with the static test results.

[0112] By collecting actual coverage data during runtime and comparing it with static test results, the set symmetric difference operation is used to locate the areas that are "statically predicted not covered or dynamically not executed". If there is a difference, proceed to S203f; if there is no difference, proceed to S203g.

[0113] S203f, Generate priority test cases.

[0114] The priority test case is equivalent to the first test case in the above embodiment, and is used to test the difference area determined in S203e.

[0115] S203g, coverage meets standards.

[0116] The current coverage meets the requirements, and no additional test cases need to be generated.

[0117] S204, Test Case Management.

[0118] Test cases are stored in a test case library and managed by tags based on the test function module, test priority, and coverage target (e.g., branch coverage ≥ 80%).

[0119] like Figure 5 S204 includes S204a-S204b.

[0120] S204a, Perform deduplication of test cases.

[0121] The cosine similarity algorithm is used to analyze the use case coverage path, merge duplicate use cases, and retain the minimum effective set.

[0122] S204b: Retain the minimum number of valid use cases.

[0123] Based on the deduplication results, retain valid test cases and update the test case library.

[0124] S205, Incremental Testing.

[0125] like Figure 6 As shown, it includes S205a-S205c.

[0126] S205a, Trigger incremental test.

[0127] In response to changes in the code under test, the latest code submission can be compared with historical code to determine whether it constitutes a code change.

[0128] S205b, Filter from the test case library.

[0129] Select test cases from the test case library to test the changed code. For details, please refer to the aforementioned embodiments.

[0130] S205c: Perform incremental testing and generate a report.

[0131] For incremental test coverage reports of newly added / modified code, only the coverage of the modified parts is displayed, and the test case tags in the test case library are updated, and invalid test cases are marked.

[0132] S206, Visualization.

[0133] like Figure 7 S206 includes S206a-S206d.

[0134] S206a, Generate a user-visual interface.

[0135] The visual interface provides a selection window, allowing users to choose the modules, branches, etc. they want to view. The real-time dashboard dynamically displays the coverage progress through the front-end interface, showing the overall coverage trend (such as row coverage increasing from 65% to 82%).

[0136] S206b, Select the target object.

[0137] The system responds to the user's selection of the target branch or module they wish to view and retrieves the coverage of that branch or module.

[0138] S206c, Generate a coverage heatmap.

[0139] Modular display coverage, for example, red indicates a low coverage module.

[0140] S206d, analysis of uncovered code.

[0141] Users can click on uncovered lines of code. In response to the user clicking on any line of code, the system will reverse trace the triggering conditions for that line of code, provide corresponding test suggestions, and redirect the user to the test case editing interface.

[0142] Figure 8 Another code testing flowchart provided for an embodiment of this application includes S801-S808.

[0143] This process can be applied to the aforementioned electronic devices, which can integrate R&D platforms and toolsets such as Jenkins and GitLab. Data can be transferred through application programming interfaces, and Docker containerization deployment is supported. Coverage testing can be performed uniformly in development (Dev), testing (QA), and pre-production (Staging) environments.

[0144] S801, Received the code under test.

[0145] Receive the code to be tested submitted by the technicians. This can be the target code in the above embodiments or the modified code.

[0146] S802, Code change detected.

[0147] It can identify whether the submitted code is new code under test or a modified version of historical code.

[0148] S803, pull code and build image.

[0149] Build a mirror image of the modified code for testing purposes.

[0150] S804, Running data collection coverage.

[0151] Test the changed code; for specific testing methods, please refer to the above embodiments.

[0152] S805, Generate test report.

[0153] A test report is generated based on the test results of S804, including coverage distribution and coverage change trends before and after the change.

[0154] S806. Is the coverage rate less than the threshold?

[0155] If the value is less than the threshold, proceed to S807; if the value is not less than the threshold, proceed to S808.

[0156] S807, Issue a notification message.

[0157] If the coverage target is not met, notify the technical staff and prevent the merging of change codes.

[0158] S808, Deployment is permitted.

[0159] If the coverage target is met, code deployment changes are permitted.

[0160] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0161] This application embodiment can divide the code testing device into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0162] In some embodiments, this application also provides a code testing apparatus. The code testing apparatus may include one or more functional modules for implementing the methods described in the above embodiments. For example, Figure 9 This is a schematic diagram illustrating the composition of a code testing device 900 provided in an embodiment of this application. Figure 9 As shown, the code testing device 900 includes: Test module 901 is used to test the target code and obtain the first test result; the first test result includes static test results and dynamic test results. The static test result includes the first line of code that has been tested by static testing, and the dynamic test result includes the second line of code that has been tested by dynamic testing. Processing module 902 is used to determine a target code line based on a first code line and a second code line; the target code line represents the complement of the intersection of the first code line and the second code line in the target code; Processing module 902 is also used to construct the first test case based on the target line of code; Test module 901 is also used to test the target code based on the first test case to obtain a second test result; the second test result includes the third line of code that has been tested by the first test case. The target code is composed of one or more languages, and both the first and second test results are generated based on a preset language, which may be the same as or different from any language that constitutes the target code.

[0163] In one possible implementation, the test module 901 is further configured to parse the target code, generate a function call graph (FCG) and / or a data flow dependency graph (DDG) of the target code; based on the FCG and / or DDG, predict the first line of code executed by the target code during dynamic testing; insert instrumentation code into the line of code of the target code; perform dynamic testing on the target code, and determine the second line of code where the instrumentation code runs during the dynamic testing process is located.

[0164] In another possible implementation, the processing module 902 is further configured to determine the test coverage of the target code based on the second line of code, the third line of code, and the target code; if the test coverage is lower than a threshold, a warning message is issued. Test coverage includes at least one of the following: line-of-code test coverage, branch-of-code test coverage, function test coverage, loop test coverage, and path test coverage; line-of-code test coverage represents the proportion of tested lines of code in the target code to the total number of lines of code; branch-of-code test coverage represents the proportion of tested branches of code in the target code to all branches; function test coverage represents the proportion of functions called during testing in the target function to all functions; loop coverage represents the test coverage ratio for different execution scenarios of loop structures in the target code; and path coverage represents the proportion of tested paths in the target code to all paths.

[0165] In another possible implementation, the processing module 902 is further used to add the first test case to the test case library; the test case library includes multiple test cases; based on cosine similarity, the similarity between every two test cases in the test case library is determined; the similarity characterizes the degree of duplication of the code under test when the target code is tested using two test cases; and test cases with a similarity greater than a preset similarity are merged.

[0166] In another possible implementation, the test cases in the test case library have corresponding tags; the tags represent the test type of the test case; the test type represents the type of code that the test case is used to test, and the code type includes at least one of code line, code branch, function, loop, and path. The test module is also used to determine the code type of the changed code in response to changes in the target code; based on the code type and tag of the changed code, a fourth test case is determined; the changed code is tested based on the fourth test case to obtain a third test result; the third test result includes the code lines that the fourth test case has tested.

[0167] In another possible implementation, processing module 902 is also used to visually annotate the tested lines of code in the target code based on test coverage; wherein the annotation methods for lines of code, code branches, functions, loops, and paths in the target code are different. The visual annotation includes color annotation, where the annotation color is related to the numerical value of the test coverage.

[0168] In another possible implementation, the processing module 902 is also used to visually annotate the fourth line of code in the target code, excluding the first and second lines of code; the annotation method of the fourth line of code is different from the annotation method of the tested lines of code in the target code.

[0169] When the methods of the above embodiments are implemented in hardware, this embodiment of the invention provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 10 As shown, the electronic device 1000 includes: a processor 1002, a communication interface 1003, and a bus 1004. Optionally, the electronic device 1000 may also include a memory 1001.

[0170] Processor 1002 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 1002 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 1002 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0171] Communication interface 1003 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0172] The memory 1001 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0173] In one possible implementation, the memory 1001 can exist independently of the processor 1002. The memory 1001 can be connected to the processor 1002 via a bus 1004 and is used to store instructions or program code. When the processor 1002 calls and executes the instructions or program code stored in the memory 1001, it can implement the method provided in the embodiments of the present invention.

[0174] In another possible implementation, the memory 1001 can also be integrated with the processor 1002.

[0175] Bus 1004 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1004 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0176] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the above device can be divided into different functional modules to complete all or part of the functions described above.

[0177] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the aforementioned computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The aforementioned computer-readable storage medium can also be an external storage device of the aforementioned device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the aforementioned device. Further, the aforementioned computer-readable storage medium can include both internal storage units of the aforementioned service call device and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the aforementioned device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0178] This application also provides a computer program product comprising a computer program that, when run on a computer, causes the computer to perform the methods provided in the above embodiments.

[0179] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A code testing method, characterized in that, The method includes: The target code is tested to obtain a first test result; the first test result includes static test results and dynamic test results, the static test result includes the first line of code that has been tested by static testing, and the dynamic test result includes the second line of code that has been tested by dynamic testing. Based on the first line of code and the second line of code, a target line of code is determined; the target line of code represents the complement of the intersection of the first line of code and the second line of code in the target code; Based on the target line of code, construct the first test case; The target code is tested based on the first test case to obtain a second test result; the second test result includes the third line of code that has been tested by the first test case.

2. The method according to claim 1, characterized in that, The test on the target code, to obtain the first test result, includes: Parse the target code to generate a function call graph (FCG) and / or a data flow dependency graph (DDG) for the target code; Based on the FCG and / or DDG, predict the first line of code that the target code will execute during dynamic testing; Insert tracking code into the code lines of the target code; The target code is dynamically tested to determine the second line of code where the embedded code is located during the dynamic test.

3. The method according to claim 1, characterized in that, The method further includes: Based on the second line of code, the third line of code, and the target code, determine the test coverage of the target code; If the test coverage is below the threshold, a prompt message will be issued.

4. The method according to claim 3, characterized in that, The test coverage includes at least one of the following: line-of-code test coverage, branch-of-code test coverage, function test coverage, loop test coverage, and path test coverage; the line-of-code test coverage represents the proportion of the number of lines of code tested in the target code to the total number of lines of code; the branch-of-code test coverage represents the proportion of the code branches tested in the target code to all code branches; the function test coverage represents the proportion of the functions called in the test to all functions in the target function; the loop coverage represents the test coverage ratio of different execution states of the loop structure in the target code; and the path coverage represents the proportion of the paths tested in the target code to all paths.

5. The method according to claim 1, characterized in that, The method further includes: Add the first test case to the test case library; the test case library includes multiple test cases. Based on cosine similarity, the similarity between any two test cases in the test case library is determined; the similarity represents the degree of duplication of the code under test when the target code is tested using two test cases. Merge test cases whose similarity is greater than a preset similarity.

6. The method according to claim 5, characterized in that, The test cases in the test case library have corresponding tags; the tags represent the test type of the test case; the test type represents the code type that the test case is used to test, and the code type includes at least one of code line, code branch, function, loop and path; The method further includes: In response to a change in the target code, determine the code type of the changed code; Based on the code type of the changed code and the tag, a fourth test case is determined; The modified code is tested based on the fourth test case to obtain a third test result; the third test result includes the lines of code tested by the fourth test case.

7. The method according to claim 4, characterized in that, The method further includes: Based on the test coverage, the tested lines of code in the target code are visually annotated; wherein, the annotation methods for lines of code, code branches, functions, loops and paths in the target code are different.

8. The method according to claim 7, characterized in that, The visualization annotations include color annotations, wherein the annotation colors are related to the numerical value of the test coverage.

9. The method according to any one of claims 7 to 8, characterized in that, The method further includes: visually annotating a fourth line of code in the target code, excluding the first and second lines of code; the annotation method of the fourth line of code is different from the annotation method of the tested lines of code in the target code.

10. The method according to claim 1, characterized in that, The target code is composed of one or more languages, and both the first test result and the second test result are generated based on a preset language, which may be the same as or different from any language that constitutes the target code.

11. An electronic device, characterized in that, It includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the code testing method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the code testing method according to any one of claims 1 to 10.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the code testing method as described in any one of claims 1 to 10.

Images