Code coverage rate statistical method and device, medium and product

Abstract

The invention provides a code coverage rate statistical method and device, a medium and a product. The code coverage rate statistical method comprises the steps of obtaining a to-be-tested source code file; the source code file is a source code file after code modification; analyzing the source code file to obtain an abstract syntax tree; determining a statement node to be tested according to the modified content in the source code file; after the statement nodes in the abstract syntax tree are subjected to instrumentation, the coverage rate of the source code file is counted.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and particularly to a method, device, medium and product for code coverage statistics. Background Art

[0002] In software development work, software testing is an essential task. To meet different software testing requirements, it can be divided into black-box testing and white-box testing.

[0003] In the application of black-box testing, code coverage is one of the important indicators to measure the sufficiency and integrity of software testing work. The so-called code coverage refers to the proportion and degree of the code that has been executed during the testing process to the total amount of code to be tested. Code coverage focuses on which code has been executed and which code has not been executed. In some programming languages, the code coverage testing technology is relatively mature. However, in some programming languages (such as the Go language), there is no mature code coverage statistics scheme. Summary of the Invention

[0004] The present disclosure provides a method, device, medium and product for code coverage statistics.

[0005] According to a first aspect of the present disclosure, a method for code coverage statistics is provided. The method is applied to a server, and specifically includes: obtaining a source code file to be tested; the source code file is a source code file after code modification; parsing the source code file to obtain an abstract syntax tree; determining statement nodes to be tested according to the modified content in the source code file; after instrumenting the statement nodes in the abstract syntax tree, statistically calculating the coverage rate of the source code file.

[0006] Based on the above content, it can be known that when performing code coverage statistics, the source code file is parsed into an abstract syntax tree. Next, when performing coverage testing, the code coverage of the modified content part in the source code file can be statistically calculated. Visualization of code coverage statistics is realized. In addition, during the execution of the test task, the code can also be distinguished whether it has been executed by means of code color rendering, so that testers can intuitively see which code has been executed and which code has not been executed, effectively improving the work efficiency of testers in detecting omissions.

[0007] According to at least one embodiment of the present disclosure, the statement nodes include at least one of an expression statement, an assignment statement, and a flow control statement.

[0008] According to at least one embodiment of the present disclosure, determining statement nodes to be tested according to the modified content in the source code file includes: determining the type of execution statement included in the modified content in the source code file; determining the statement nodes according to the type of execution statement.

[0009] Determining the type of execution statements included in the modified content in the source code file according to at least one embodiment of the present disclosure includes: obtaining the difference file names between the current branch and the main branch; determining the modified content in the difference file names, and the type of execution statements modified in the modified content.

[0010] Parsing the source code file according to at least one embodiment of the present disclosure to obtain an abstract syntax tree, including: parsing the source code file using the Go language to generate an abstract syntax tree; wherein, the abstract syntax tree includes at least one of statement nodes, basic nodes, and declaration nodes.

[0011] After instrumenting the statement nodes in the abstract syntax tree according to at least one embodiment of the present disclosure, calculating the coverage rate of the source code file, including: setting a counter at the start position in the statement node; wherein, the counter includes a count field and a pos field; determining the start position and end position corresponding to the statement node; collecting the execution times of the statement node using the count field; and collecting the start position and end position of the statement node using the pos field; calculating the coverage rate of the source code file according to the data with the execution times greater than zero.

[0012] According to at least one embodiment of the present disclosure, it further includes: after completing the instrumentation task, compiling the source code file with the counter set; deploying the compiled executable program to the Pod running node; counting the execution times recorded by the counter.

[0013] After deploying the compiled executable program to the Pod running node according to at least one embodiment of the present disclosure, it further includes: rendering the first statement nodes with the execution times greater than zero in a first color; rendering the second statement nodes with the execution times equal to zero in a second color; wherein, the first color and the second color are different colors.

[0014] According to a second aspect of the present disclosure, there is provided an electronic device, including: a memory storing execution instructions; and a processor that executes the execution instructions stored in the memory, so that the processor executes the method described in the first aspect of any one of the embodiments of the present disclosure.

[0015] According to a third aspect of the present disclosure, there is provided a readable storage medium storing execution instructions, and when the execution instructions are executed by a processor, they are used to implement the method described in the first aspect of any one of the embodiments of the present disclosure.

[0016] According to a fourth aspect of the present disclosure, there is provided a computer program product including a computer program which, when executed by a processor, implements the method described in the first aspect of any one of the embodiments of the present disclosure. Description of the Drawings

[0017] The drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, are used to explain the principles of the present disclosure. The drawings are included to provide a further understanding of the present disclosure and are included in this specification and form a part of this specification.

[0018] Figure 1 It is a schematic flowchart of a method for code coverage statistics provided by the present disclosure.

[0019] Figure 2 It is a schematic flowchart of a method for implementing coverage statistics illustrated by the present disclosure.

[0020] Figure 3 It is a schematic diagram of the code coverage statistics process illustrated by the present disclosure.

[0021] Figure 4 It is a schematic block diagram of the structure of a code coverage statistics device according to an embodiment of the present disclosure.

[0022] Figure 5 It is a schematic block diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Embodiments

[0023] The present disclosure will be further described in detail below with reference to the drawings and examples. It can be understood that the specific examples described herein are only used to explain the relevant content and do not limit the present disclosure. Additionally, it should be noted that for ease of description, only parts related to the present disclosure are shown in the drawings.

[0024] It should be noted that, without conflict, the embodiments in the present disclosure and the features in the embodiments can be combined with each other. The technical solutions of the present disclosure will be described in detail below with reference to the drawings and in combination with the embodiments.

[0025] In the software development and testing scenario, the test engineer (qa) is responsible for comprehensively testing the functions after the development engineer (rd) has developed the relevant functions, and tries to ensure that there are no functional defects in the functions after they are pushed to the users. The tool proposed in this solution belongs to the tool for qa to increase efficiency and ensure quality during the testing process.

[0026] For software testing, the testing process can be divided into white-box testing and black-box testing. Black-box testing mainly focuses on the functional performance of the software without paying attention to the details of the internal implementation. In black-box testing, the tester only knows the input data and the expected output results, but does not know how the program processes the input and generates the output. On the contrary, white-box testing is carried out from an internal perspective, focusing on the code structure and logic, and requires an understanding of the internal implementation. When the tester completes both white-box and black-box testing of the function, we consider that the current test is completed. However, in the process of Go language software testing, there is no effective tool to help testers conduct black-box testing. It can only be judged whether the test is completed from whether the function has been tested, and there is no quantitative index for the degree of test completion. Therefore, a solution that can simply and efficiently implement code coverage statistics for the Go language is needed.

[0027] Term explanation.

[0028] For the convenience of description and to make the technical solutions of the specific embodiments of the present disclosure easier to understand, before describing the code coverage statistics method implemented in the specific embodiments of the present disclosure, the technical terms involved in the specific embodiments of the present disclosure are explained as follows.

[0029] Go language: Also known as Golang, it is an open-source programming language designed and developed by Google. The Go language provides strong concurrency support through goroutine and channel. Goroutine is a lightweight thread with very low creation and switching costs, enabling developers to easily write highly concurrent applications. Channel is used for communication between goroutines to ensure the security and efficiency of data transfer.

[0030] Instrumentation: Insert some code fragments such as probes at some key nodes of the source code to collect data during the code running process. Instrumentation can be performed during compilation or at runtime.

[0031] Coverage: An indicator describing the code execution situation, and common ones include incremental coverage, full coverage, branch coverage, etc.

[0032] Abstract Syntax Tree (AST): It is an intermediate representation form generated after the source code undergoes lexical analysis and syntax analysis. It represents the syntax structure of the program in the form of a tree, where each node represents a syntax element in the source code, such as expressions, statements, functions, etc. The nodes are connected through parent-child relationships and sibling relationships to form a hierarchical tree.

[0033] Figure 1 It is a flow schematic diagram of a code coverage statistics method provided by the present disclosure. As Figure 1The method shown includes steps 101 to 104. Among them, the method can be executed by an electronic device such as a server (local server or cloud server).

[0034] Specifically, Figure 1 The method shown includes: Step 101: Obtain the source code file to be tested; the source code file is a Go language source code file after code modification.

[0035] Go language source code files are the basis for building Go language applications. They contain program code to implement specific functions and organize and control the execution of the program through package declarations, import statements, type declarations, variable declarations, function definitions, and other statements and expressions.

[0036] During subsequent application processes, the code in the source code file may be modified due to certain problems (such as code bugs). To ensure that the modified code does not have logical errors resulting in unstable program operation, the source code file needs to be tested. Therefore, the source code file to be tested here is a Go language source code file with modified code in a certain project.

[0037] Step 102: Use Go language packages to parse and process the source code file to obtain an abstract syntax tree.

[0038] The Go language packages mentioned here refer to the three packages go / token, go / parser, and go / ast. When parsing the source code file, import the go / token, go / parser, and go / ast packages, as well as the fmt and os packages (for printing output and handling files).

[0039] Call the parser.ParseFile() function, passing in the file set, source file path, preprocessing options (usually nil), and parsing mode (such as parser.AllErrors to report all errors) to parse the source file and return an *ast.File node.

[0040] Check the return value of the parser.ParseFile() function. If an error occurs, print the error message and exit the program.

[0041] Use the ast.Print() function to print the default representation of the AST, or use the ast.Inspect() function to traverse the AST nodes and process specific node types as needed.

[0042] The abstract syntax tree mentioned here is obtained by parsing the source code file. In this abstract syntax tree, there are basic nodes, statement nodes, declaration nodes, and so on. In the solution of the present disclosure, statement nodes are used for code coverage statistics.

[0043] Step 103: Determine the statement nodes to be tested according to the modified content in the source code file.

[0044] In practical applications, when modifying the source code, it may be that many contents in the source code file are modified simultaneously. For example, when making a relatively large change to a certain function, it is necessary to modify assignment statements, conditional statements, loop statements, etc. Since there are many modified contents, during testing, it is necessary to perform an overall test on the source code file, which means that it is necessary to perform code coverage statistics on many statements in the source code file.

[0045] If, when modifying the source code file, only one judgment condition or parameter is modified, it may only affect one statement. For example, if only the parameter in the loop statement is modified, during testing, targeted testing can be performed on this loop statement. And when performing code coverage statistics, code coverage statistics can also be performed on the modified loop statement, or on each statement that has a call relationship with the loop statement.

[0046] Therefore, the modified content in the source code file is different, and the corresponding statement nodes to be tested are also different. When testing and calculating code coverage, an appropriate coverage statistics method can be selected according to the actual modification situation of the source code file.

[0047] Step 104: After instrumenting the statement nodes in the abstract syntax tree, calculate the coverage rate of the source code file.

[0048] After obtaining the abstract syntax tree through the method described above, the statement nodes included in this abstract syntax tree can be determined. When instrumenting, by operating on the AST, monitoring code (such as counters) can be accurately inserted at the syntax level of the source code, avoiding errors and omissions that may be caused by manual instrumentation. Parsing to obtain the abstract syntax tree (AST) and using AST instrumentation have significant advantages and necessity in code coverage testing. It can not only improve the accuracy and efficiency of testing, but also be combined with other static code analysis techniques to provide strong support for the code quality assurance system.

[0049] During the testing process, if this statement is executed, the execution count is not zero, which means that the code related to this statement is covered. On the contrary, during the testing process, if this statement is not executed, the execution count is zero, indicating that this statement and the related code are not covered.

[0050] Based on the above, it can be seen that when performing code coverage statistics, the source code file is parsed into an abstract syntax tree. Next, when performing coverage testing, code coverage statistics can be carried out for the modified content part in the source code file. Visualization of code coverage statistics is realized. In addition, during the process of executing the test task, the code can also be distinguished whether it is executed through code color rendering, so that testers can intuitively see which code is executed and which code is not executed, effectively improving the work efficiency of testers in finding and filling in the gaps.

[0051] In one or more embodiments of the present disclosure, the statement nodes include: at least one of an expression statement ExprStmt, an assignment statement AssignStmt, and a flow control statement (such as a conditional statement IfStmt, a loop statement ForStmt and RangeStmt, a Switch statement SwitchStmt, and may also be conditional judgment types: if, else, else if, switch case, loop types: for, control within the loop: break continue).

[0052] These six statement nodes are very common and important in programming. They cover operations such as basic calculations, data assignment, logical branching, loop execution, and set traversal in the program. By paying attention to these statement nodes, accurate statistics and analysis of the critical paths and logic in the program can be ensured, thereby helping to discover potential problems and improve code quality.

[0053] In addition, these statement nodes also have clear representations and easily recognizable features in the AST (abstract syntax tree), which makes it convenient to extract and process this information during the code analysis process.

[0054] In summary, paying attention to these six statement nodes, namely ExprStmt, AssignStmt, IfStmt, ForStmt, SwitchStmt, and RangeStmt, is to ensure accurate statistics and analysis of the critical paths and logic in the program, thereby improving code quality and test coverage.

[0055] In one or more embodiments of the present disclosure, determining the statement nodes to be tested according to the modified content in the source code file includes: determining the type of execution statement included in the modified content in the source code file; and determining the statement nodes according to the type of execution statement.

[0056] In practical applications, code needs to be maintained frequently. During the maintenance process, some code modifications may be made more or less. If the modified code content is not much, for example, only the parameters in a judgment condition are modified, then when performing code coverage statistics on the source code file, it may not be necessary to comprehensively count all statements and functions in the source code file. It is possible to perform code coverage statistics only on the modified content. The specific implementation method is that after the code in the source code file is modified, determine the type of execution statement where the modified code content is located (the type of execution statement refers to one or more types among expression statement type, assignment statement type, conditional statement type, loop statement type, and Switch statement type).

[0057] The statement nodes mentioned here can be all statement nodes belonging to the same type of execution statement in the abstract syntax tree. Of course, it can also be one or more modified statement nodes.

[0058] By the above method, after determining the statement nodes, the code coverage statistics range can be significantly reduced, and code coverage statistics can be performed only on the statement nodes belonging to the same type of execution statement. It is also possible to perform coverage statistics on a specific statement node. This can significantly improve the efficiency of code coverage statistics.

[0059] Of course, if there are many modifications when modifying the source code file, for example, various types of statements are modified. Then, all of the above six types of statements can be used as the statement nodes for coverage testing. In other words, perform full coverage statistics on the key statement nodes in the abstract syntax tree. By the above method, although the statistical efficiency will be reduced, it can more comprehensively count the code coverage situation during the testing process and avoid the problem of important code being omitted.

[0060] In one or more embodiments of the present disclosure, determining the type of execution statement included in the modified content in the source code file includes: using the git diff --name-only command to obtain the difference file names between the current branch and the main (master) branch; determining the modified content in the difference file names and the type of execution statement modified in the modified content.

[0061] The git diff --name-only command can be used to list the file names with differences between the current branch and the master branch. This command will ignore the details of the differences in the file content and only list the file names.

[0062] The current branch mentioned here refers to the branch that is currently being worked on, which is the branch created after code modifications. In version control software (Git), branches are used to develop different functions or fix different bugs in parallel. When cloning a Git repository or initializing a new Git repository, Git usually automatically creates a branch named master and automatically switches to this branch. After that, new branches can be created to develop new functions or fix bugs, and each branch represents an independent workflow. When switching to a certain branch to work, this branch becomes the "current branch".

[0063] The "master branch" is the default main branch name in Git. It usually represents the main development line of the project and contains the latest stable version of the project. In Git, branches are used to isolate different development work, and the master branch is regarded as the "trunk" or "main line" of the project. Developers will release new versions or fix important bugs on the master branch.

[0064] In summary, use git diff --name-only to obtain the file names that differ between the current branch and the master branch, which is used to list the file names that have differences between the branch currently being worked on and the main branch of the project. This command is very useful for developers because it can help them quickly identify which files have changed between the two branches. Furthermore, find the modified content from the files corresponding to the different file names with differences, and further determine the type of executed statements modified in the modified content.

[0065] Through the above solution, quickly lock the file names with code modifications in the source code files, and then find the corresponding files according to the file names with differences, and determine the changed code content in the files. Especially in the case of a large number of modifications, there is no need for manual search by personnel, which can significantly improve the work efficiency of finding modified content.

[0066] In one or more embodiments of the present disclosure, use Go language packages to parse and process source code files to obtain an abstract syntax tree, including: using the Go language to parse source code files to generate an abstract syntax tree; wherein, the abstract syntax tree contains at least one of statement nodes, basic nodes, and declaration nodes.

[0067] In practical applications, language packages such as go / token, go / parser, and go / ast in the Go language package can be used to parse source code files. The parsing functions of these three language packages have different focuses. Specifically as follows.

[0068] The `go / token` package is mainly used to represent the lexical units (tokens) and related position information in Go source code. Lexical units are the smallest units that are syntactically meaningful in source code, such as keywords, identifiers, operators, literals, etc. The `go / token` package defines the types of these lexical units and related constants, as well as data structures for representing the positions and kinds of lexical units.

[0069] Specifically, the functions provided by the `go / token` package include: defining a series of constants representing the types of lexical units, such as `token.IDENT` (identifier), `token.INT` (integer literal), `token.ADD` (addition operator), etc. Providing the `token.Position` struct for representing the position of a lexical unit in the source code, including file name, line number, column number, etc. Providing the `token.File` interface for representing a file containing multiple lexical units and allowing traversal of these lexical units.

[0070] The `go / parser` package is used to parse Go source code into an Abstract Syntax Tree (AST). It takes one or more `token.File` interfaces as input and then organizes these lexical units into a tree-like structure, namely the Abstract Syntax Tree AST, according to the grammar rules of the Go language. The AST is an abstract representation of the source code that retains the syntactic structure and semantic information in the source code but removes unnecessary details (such as comments, whitespace characters, etc.).

[0071] Specifically, the main functions of the `go / parser` package include: parsing Go source code files to generate the corresponding Abstract Syntax Tree AST. Providing a series of functions and interfaces for configuring the parsing process, such as specifying the parsing mode (declaration, expression, statement, etc.), handling errors, etc. Supporting parsing code from multiple files and combining them into a complete AST.

[0072] The `go / ast` package is used to represent and manipulate the Abstract Syntax Tree (AST) of the Go language. It defines a series of data structures for representing various node types in the AST, such as package declarations, import declarations, function declarations, variable declarations, expressions, statements, etc. These data structures contain key information such as node type, child nodes, position information, etc., allowing developers to traverse, modify, and analyze the AST.

[0073] Specifically, the main functions of the `go / ast` package include: providing a series of data structures for representing various node types in the AST. Providing a series of functions and interfaces for traversing, modifying, and analyzing the AST. For example, the `ast.Walk` function can be used to traverse the AST tree and perform custom operations on each node.

[0074] In summary, the three packages, go / token, go / parser, and go / ast, play a core role in the code parsing and generation process of the Go language. They work together to convert source code into an abstract syntax tree and allow developers to traverse, modify, and perform instrumentation analysis on this tree.

[0075] It should be noted that basic nodes represent expressions and types in the AST of the Go language. These nodes usually contain detailed information about the expression or type, such as operands, operators, type names, etc. Declaration nodes represent declarations in the Go language. A declaration is a statement in a program used to introduce new variables, types, functions, etc. In the AST, a declaration node contains detailed information about the declaration, such as the name, type, scope, etc. of the declaration.

[0076] In one or more embodiments of the present disclosure, a coverage statistics method is also proposed. As Figure 2 This is a schematic flowchart of the implementation method of the coverage statistics illustrated in the present disclosure. From Figure 2 it can be seen that after instrumenting the statement nodes in the abstract syntax tree, the coverage rate of the source code file is statistically calculated, which specifically includes the following steps: Step 201: Set a counter at the start position in the statement node; where the counter includes a count field and a pos field. Step 202: Determine the start position and end position corresponding to the statement node. Step 203: Use the count field to collect the execution times of the statement node, and use the pos field to collect the start position and end position of the statement node. Step 204: According to the data with the execution times greater than zero, statistically calculate the coverage rate of the source code file.

[0077] In practical applications, a counter can be inserted at the start position of the statement nodes that need to be concerned. The working principle of this counter is that as long as the code is executed during the code execution process, the execution times of the counter will increase by 1. After being executed twice, the corresponding execution times value will become 2, and if it is not executed, the execution times value will be 0.

[0078] For example, insert counter code at the start position of the statement node. During the compilation process, the compiler will scan the source code. These counter codes will be updated during the program execution, thereby recording the execution situation of the code. Finally, by reading the values of these counters, a coverage report can be generated, showing information such as which code has been executed and the number of execution times.

[0079] In the counter, there are a count field and a pos field.

[0080] For example, the implementation content of the counter is as follows: VarCover_0_303164383738303064376138=struct{ Count [3]uint32 Pos [2 * 3]uint32 }{ Pos: [2 * 3]uint32{13, 31, / / [0] 31, 33, / / [1] } } Among them, the Count field is an array of non-negative integers, and its length is equal to the number of AST (Abstract Syntax Tree) statement nodes in the source file. The main function of this field is to record the execution times of each statement node. During the automated testing process, the test framework will run the code under test and use instrumentation technology (i.e., inserting additional code at key positions in the code to collect information) to track whether each statement is executed and the number of executions. The Count field is used to store this execution times information.

[0081] Through the Count field, it is possible to intuitively understand which code paths are covered by the test and which are not, thereby evaluating the integrity and effectiveness of the test. This is crucial for discovering potential bugs, improving code quality and reliability.

[0082] The Count uint32 array, where each element in the array represents the number of times the corresponding basic block is executed. Pos represents the positions of each basic block in the source code file, in groups of three. Similar to the following output result: github.com / qiniu / goc / goc.go:21.13,23.2 1 1. The content here is obtained through counter statistics. Its basic semantics is "**file: starting line.starting column, ending line.ending column number of statements in the basic block number of times the basic block is executed**". For example, 21 here represents the starting line number of the basic block, 23 represents the ending line number, and 0x2000d is interesting. The first 16 bits represent the ending column number, and the last 16 bits represent the starting column number. A point can be uniquely determined by the row and column, and the physical range of a certain basic block in the source code file can be accurately expressed by the starting point and the ending point. Through this counter, it is very convenient to calculate whether this piece of code is executed and how many times it is executed.

[0083] However, just knowing the execution times of each statement is not enough. Sometimes it is also necessary to know the specific positions of these statements in the source code in order to accurately locate which code lines or code blocks are not covered by the test. This is where the Pos field comes into play.

[0084] The Pos field is also an array of non-negative integers, but its length is twice the number of AST statement nodes in the source file. This is because the Pos field needs to record the line numbers where each statement node starts and ends. With these two location pieces of information, we can accurately map back to the source code to find the corresponding lines or code blocks.

[0085] With the information in the Pos field, we can not only know which statements have been executed, but also know their exact locations in the source code. This is very valuable for subsequent code reviews, bug fixes, and test optimization.

[0086] In summary, the Count and Pos fields each play different roles in code coverage statistics, but they complement each other and are indispensable. The Count field provides information on the number of times a statement is executed, while the Pos field provides information on the location of the statement in the source code. Only by using these two fields together can we obtain comprehensive and accurate code coverage statistics results.

[0087] In addition, using the Count field and the Pos field simultaneously can also provide more flexibility and convenience for developers or testers. For example, developers can filter out the statements that have not been executed or have been executed fewer times based on the information in the Count field, and combine the information in the Pos field to quickly locate the positions of these statements in the source code, so as to carry out targeted test optimization or code review and other work.

[0088] The coverage mentioned here is an important indicator to measure test sufficiency. It can help developers understand how much of the code has been covered by tests, so as to evaluate the quality and effectiveness of the tests. Coverage statistics usually include multiple dimensions such as statement coverage, branch coverage, and function coverage. The calculation methods of these coverages are illustrated by examples below.

[0089] Statement coverage refers to the proportion of program statements executed during the test. The calculation method is: Formula: Statement coverage = (Number of statements executed at least once / Total number of statements to be executed) × 100%.

[0090] In addition to the above three coverage metrics, there are other metrics such as condition coverage and path coverage. Condition coverage requires that each possible value of each conditional expression be tested; path coverage requires that all possible execution paths in the program be tested. The calculation methods and application scenarios of these metrics are different, but they are all important means to measure test sufficiency.

[0091] Code coverage is one of the important metrics for measuring test sufficiency, which can help developers or testers understand how much of the code has been covered by tests. By calculating metrics such as statement coverage, branch coverage, and function coverage, the quality and effectiveness of the tests can be evaluated.

[0092] In one or more embodiments of the present disclosure, it further includes: after completing the instrumentation task, compiling the source code file with counters set; deploying the compiled runnable program to the Pod running node; and counting the number of executions recorded by the counters.

[0093] In practical applications, after inserting counters at the starting positions in the statement nodes, the source code file is compiled. Furthermore, the compiled runnable program is deployed to the Pod running node. Therefore, in practical applications, if you want to perform code coverage statistics on the Pod nodes, you can also instrument the code deployed to each Pod. Specifically, determine the deployment relationship between the source code file and the Pod node, and instrument the statement nodes in the source code file corresponding to the Pods that need to perform code coverage statistics. After compilation and deployment, count the number of executions through the instrumented counters. If the number of executions is not zero, it means the Pod is covered; if the number of executions is zero, it means the Pod is not covered.

[0094] Through the above method, not only can code coverage statistics be achieved, but also code coverage statistics on the Pod nodes can be achieved. Simple instrumentation operations can meet the code coverage statistics requirements in various scenarios.

[0095] In one or more embodiments of the present disclosure, after deploying the compiled runnable program to the Pod running node, it further includes: rendering the first statement nodes with the number of executions greater than zero in a first color; rendering the second statement nodes with the number of executions equal to zero in a second color; wherein, the first color and the second color are different colors.

[0096] In practical applications, since there is a lot of code in the source code file, although in the above embodiments, the position of the statement where the test is executed can be counted through the pos field of the counter. However, it is not obvious in the source code file and is also not obvious in the abstract syntax tree. Therefore, while counting the number of executions, targeted rendering of the statement nodes can be performed.

[0097] Specifically, during the testing process, after a statement node is executed, if the counter inserted at this statement node counts a non-zero execution count, then this first statement node can be rendered in a first color (for example, red. In actual applications, testers can choose the rendering effect and method according to their own needs). If the second statement node is not executed, that is, the execution count is zero, then the second statement node can be rendered in a second color (for example, green). It should be noted that the first color and the second color are different colors, so as to facilitate developers or testers to visually distinguish which statement nodes have been executed and which have not.

[0098] Through the above method, the test coverage situation is presented in an intuitive way, making it easier for testers to identify uncovered code areas. By quantifying the test coverage rate and providing a specific coverage percentage, it helps the team evaluate the comprehensiveness of the test. Establishing a set of standardized processes and reporting mechanisms makes the testing work more standardized. By finding the uncovered code, testers can more effectively identify potential functional defects, thereby optimizing the design of test cases and improving the overall test quality.

[0099] In order for the server to count the execution times of the counters in the Pod, an init function and an http interface for obtaining the counter values are also inserted under the main package of the source program. Among them, the init function sends a registration request to the server when the program runs. After receiving the request, the server records the ip + port of the client, which is subsequently used to call the server to count the counter values. Thus, users can intuitively understand the coverage rate statistics results through the client.

[0100] For the sake of easy understanding, the code coverage rate statistical process will be described below through specific embodiments. As Figure 3 This is a schematic diagram for illustrating the code coverage rate statistical process of the present disclosure. From Figure 3 it can be seen that First, in the root directory of the project, obtain all package information of the Go project in JSON format through "go list -json" (under the package are specific source code files). Second, obtain the names of the files that are different between the current branch and the master branch through "git diff --name-only". For incremental code coverage, only the modified and different code needs to be concerned about. After obtaining the different source code files, code instrumentation is carried out next. For.go source programs, use the official Go language packages "token" and "parser" to perform abstract syntax tree (AST) parsing on the source program. The Go language abstract syntax tree includes basic nodes, statement nodes, and declaration nodes. In the present disclosure solution, only the statement nodes need to be concerned about, including six types: ExprStmt, AssignStmt, IfStmt, ForStmt, SwitchStmt, and RangeStmt.

[0101] ExprStmt: Represents an expression statement, that is, a statement that contains only one expression.

[0102] AssignStmt: Assignment statement.

[0103] IfStmt: Conditional statement.

[0104] ForStmt: Loop statement.

[0105] SwitchStmt: switch statement.

[0106] RangeStmt: Loop statement.

[0107] The start position and end position of the statement node can be obtained from the abstract syntax tree statement node. Therefore, add a counter at the start position of these statement nodes. When the code runs to this point, the counter is incremented by one. Subsequently, by counting the value of the counter (that is, the execution count), it can be known whether the current statement node has been executed.

[0108] Each.go source program file uses a counter for code coverage statistics. The counter includes a "count" field and a "Pos" field. Among them, the "count" field is a non-negative integer array, and its length is the number of statement nodes in the abstract syntax tree (AST) corresponding to the source code file. "Pos" is also a non-negative integer data, and its length is 2 times the number of statement nodes in the source file's abstract syntax tree (AST), which is used to record the code lines at the start and end of the statement node.

[0109] In addition to instrumenting the source code, to facilitate the client to count the counter data from the server, an init function and an HTTP interface for obtaining the counter value are inserted under the main package of the source code. Among them, the init function sends a registration request to the server when the program runs. After receiving the request, the server records the client's IP + port, which is used later to call the server to count the counter value. Thus, users can intuitively understand the code coverage statistics results through the client.

[0110] The program deployment is the same as that of a general Go program, without special steps. After the program is deployed, the server will regularly obtain the counter value through the counter statistics interface instrumented in the code build and write it into the local file of the server.

[0111] Through the above embodiments, it is possible to implement targeted code coverage statistics for the Go language, thereby effectively improving the efficiency of code coverage statistics. In addition, if necessary, comprehensive code coverage statistics can also be performed on the source code files to ensure the stability and reliability of the modified source code files.

[0112] Based on any of the above embodiments, the present disclosure also provides a code coverage statistics device. Figure 4 It is a structural schematic block diagram of the code coverage statistics device according to an embodiment of the present disclosure. As Figure 4 shown, the code coverage statistics device includes: an acquisition module 41 for acquiring the source code file to be tested; the source code file is the source code file after code modification. A parsing module 42 for parsing the source code file to obtain an abstract syntax tree. A determination module 43 for determining the statement nodes to be tested according to the modified content in the source code file. A statistics module 44 for instrumenting the statement nodes in the abstract syntax tree and then counting the code coverage of the source code file.

[0113] Optionally, the statement nodes include at least one of: expression statements, assignment statements, and flow control statements.

[0114] The determination module 43 is further configured to determine the type of execution statement included in the modified content in the source code file; and determine the statement nodes according to the type of execution statement.

[0115] The determination module 43 is further configured to obtain the difference file name between the current branch and the main branch; determine the modified content in the difference file name, and the type of execution statement modified in the modified content.

[0116] The parsing module 42 is also used to parse the source code file using the Go language to generate an abstract syntax tree; wherein, the abstract syntax tree includes at least one of statement nodes, basic nodes, and declaration nodes.

[0117] The statistics module 44 is also used to set a counter at the starting position in the statement nodes; wherein, the counter includes a count field and a pos field; determine the starting position and ending position corresponding to the statement nodes; collect the execution times of the statement nodes using the count field; and, collect the starting position and ending position of the statement nodes using the pos field; and calculate the code coverage rate of the source code file according to the data with the execution times greater than zero.

[0118] The statistics module 44 is also used to, after completing the instrumentation task, compile the source code file with the counter set; deploy the compiled runnable program to the Pod running node; and count the execution times recorded by the counter.

[0119] Optionally, it further includes a rendering module 45, which is used to render the first statement nodes with execution times greater than zero into a first color; and render the second statement nodes with execution times equal to zero into a second color; wherein, the first color and the second color are different colors.

[0120] The implementation processes of the functions and roles of each module in the above device are specifically described in detail in the implementation processes of the corresponding steps in the above method, and will not be elaborated here.

[0121] The execution subject of the code coverage rate statistical method in the specific implementation manner of the present disclosure may be an electronic device such as a server (including a local server or a cloud server).

[0122] Therefore, based on any of the above embodiments, the present disclosure further provides an electronic device, which can execute the code coverage rate statistical method of any of the above embodiments described in the present disclosure.

[0123] Figure 5 It is a structural schematic block diagram of an electronic device according to an embodiment of the present disclosure.

[0124] The hardware structure of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnected buses and bridges, depending on the specific application of the hardware and the overall design constraints. The bus 1100 connects various circuits including one or more processors 1200, a memory 1300, and / or hardware modules together. The bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0125] The bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, only one connection line is used in this figure, but it does not mean that there is only one bus or one type of bus.

[0126] The present disclosure also provides a readable storage medium storing a computer program, which is used to implement the above method when executed by a processor. The "readable storage medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. More specific examples of the readable storage medium include the following: an electrical connection part (electronic device) having one or more wirings, a portable computer disk cartridge (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable read-only memory (CDROM), etc.

[0127] The present disclosure also provides a computer program product. The method of the present disclosure can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, the processes or functions of the present disclosure are executed in whole or in part.

[0128] The computer program or instructions can be stored in a readable storage medium or transmitted from one readable storage medium to another. For example, the computer program or instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired or wireless manner. The readable storage medium can be any available medium that can be accessed or a data storage device such as a server or data center integrating one or more available mediums. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it can also be an optical medium, such as a digital video disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or can include both volatile and non-volatile types of storage media.

[0129] Those skilled in the art should understand that the embodiments of the present disclosure may be provided as a method, a system, or a computer program product. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0130] The present disclosure is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to the present disclosure. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable code coverage statistical devices to produce a machine, such that the instructions executed by the processor of the computer or other programmable code coverage statistical devices produce means for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0131] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable code coverage statistical device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufactured article including instruction means that implement the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0132] These computer program instructions can also be loaded onto a computer or other programmable code coverage statistical device, such that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0133] In the description of this specification, the descriptions with reference to terms such as "one embodiment / way", "some embodiments / ways", "example", "specific example", or "some examples" etc. mean that the specific features, structures, or characteristics described in connection with the embodiment / way or example are included in at least one embodiment / way or example of the present disclosure. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment / way or example. Moreover, the specific features, structures, or characteristics described can be combined in a suitable manner in any one or more embodiments / ways or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments / ways or examples described in this specification and the features of different embodiments / ways or examples.

[0134] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0135] Those skilled in the art should understand that the above embodiments are only for clearly explaining the present disclosure and are not intended to limit the scope of the present disclosure. For those skilled in the art, other changes or modifications can be made based on the above disclosure, and these changes or modifications are still within the scope of the present disclosure.

Claims

1. A method for code coverage statistics, characterized in that, The method includes: Obtain the source code file to be tested; the source code file is the source code file after code modification; Parse the source code file to obtain an abstract syntax tree; Determine the statement nodes to be tested according to the modified content in the source code file; After instrumenting the statement nodes in the abstract syntax tree, calculate the coverage rate of the source code file.

2. The method according to claim 1, characterized in that, The statement nodes include: At least one of expression statements, assignment statements, and flow control statements.

3. The method according to claim 2, wherein The determining the statement nodes to be tested according to the modified content in the source code file includes: Determine the type of execution statement included in the modified content of the source code file; Determine the statement nodes according to the type of execution statement.

4. The method according to claim 3, wherein The determining the type of execution statement included in the modified content of the source code file includes: Obtain the difference file name between the current branch and the main branch; Determine the modified content in the difference file name and the type of execution statement modified in the modified content.

5. The method according to claim 1, wherein The parsing the source code file to obtain an abstract syntax tree includes: Parse the source code file using the Go language to generate the abstract syntax tree; wherein, the abstract syntax tree includes at least one of statement nodes, basic nodes, and declaration nodes.

6. The method according to claim 1, characterized in that, The calculating the coverage rate of the source code file after instrumenting the statement nodes in the abstract syntax tree includes: Set a counter at the start position in the statement node; wherein, the counter includes a count field and a pos field; Determine the start position and end position corresponding to the statement node; Collect the execution times of the statement node using the count field; and Collect the start position and end position of the statement node using the pos field; Calculate the coverage rate of the source code file according to the data with the execution times greater than zero.

7. The method according to claim 6, characterized in that, It further includes: After completing the instrumentation task, compile the source code file with the counter set; Deploy the compiled runnable program to the Pod running node; Calculate the execution times recorded by the counter.

8. The method according to claim 7, wherein After deploying the compiled runnable program to the Pod running node, it further includes: Render the first statement node with the execution times greater than zero in the first color; Render the second statement node with the execution times equal to zero in the second color; wherein, the first color and the second color are different colors.

9. An electronic device, characterized in that, It includes: A memory that stores execution instructions; And A processor that executes the execution instructions stored in the memory, so that the processor executes the method according to any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 8.

Images