Software code coverage rate testing method and terminal

Abstract

The invention discloses a software code coverage rate testing method and a terminal, and the method comprises the steps: obtaining and recording the real-time execution information of a script code of target software in a running state during testing, and obtaining an actual execution path according to the real-time execution information; performing static analysis on the source code of the script code, and obtaining all possible paths according to a static analysis result; and calculating the coverage rate of the script code of the target software in combination with the actual execution path and all possible paths. According to the method, the execution condition of the script code of the target software is analyzed from two levels of a running stage and a static state, and then the coverage rate of the script code of the target software is calculated by combining an actual execution path and all possible paths, so that the conditions of new and old codes can be more comprehensively considered, the script code coverage rate is quickly analyzed, and the efficiency is improved. Therefore, whether potential problems exist or not is analyzed, and the quality and reliability of codes are ensured.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a software code coverage testing method and terminal. Background Technology

[0002] In today's software development field, especially in game development, code quality and thorough testing are paramount. As the game industry continues to evolve, server-side complexity is increasing, making the need for efficient code testing tools ever more urgent.

[0003] Lightweight scripting languages, such as Lua, are widely used in game server development. Furthermore, to meet version update requirements, the software needs to periodically add or modify script code. After an update, the script code coverage needs to be tested to determine if the old and new content function correctly and whether any potential vulnerabilities or errors have gone undetected.

[0004] However, traditional testing methods often struggle to fully cover all code paths, especially when testing code changes, making it difficult to quickly determine which parts of the code need to be retested. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a software code coverage testing method and terminal that can quickly and comprehensively analyze script code coverage, ensuring the quality and reliability of the code.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A software code coverage testing method includes the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A software code coverage testing terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

[0008] The beneficial effects of this invention are as follows: It provides a software code coverage testing method and terminal, which combines runtime information acquisition and static analysis technology to analyze the execution of the target software's script code from both runtime and static perspectives. Furthermore, by combining the actual execution path and all possible paths, it calculates the script code coverage of the target software. This method can more comprehensively consider the situation of new and old code, quickly analyze the script code coverage, and facilitate the analysis of potential problems, thereby ensuring the quality and reliability of the code. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating the steps of a software code coverage testing method according to the present invention; Figure 2 This is a system block diagram of a software code coverage testing terminal according to the present invention.

[0010] Label Explanation: 1. A software code coverage testing terminal; 2. Memory; 3. Processor. Detailed Implementation

[0011] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0012] Please refer to Figure 1 A software code coverage testing method includes the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

[0013] As can be seen from the above description, the beneficial effects of the present invention are as follows: by combining runtime information acquisition and static analysis technology, the execution of the target software's script code is analyzed from both the runtime and static levels. Furthermore, by combining the actual execution path and all possible paths, the script code coverage of the target software is calculated. This allows for a more comprehensive consideration of the situation of both new and old code, and rapid analysis of script code coverage, in order to analyze whether there are potential problems and ensure the quality and reliability of the code.

[0014] Furthermore, the script code includes at least two key code blocks, each of which corresponds one-to-one with a function of the target software; Step S3 further includes: Obtain a first actual path corresponding to one of the key code blocks from the actual execution path, and obtain a first possible path of the key code block corresponding to the first actual path from all possible paths; Based on the first actual path and the first possible path, calculate the coverage of the corresponding key code block.

[0015] As described above, when analyzing the coverage of script code, the multiple key code blocks it contains can be calculated and analyzed one by one, which helps testers quickly understand which areas of the code are not fully covered, making it easier to compare different parts of the code and making the analysis process more detailed.

[0016] Furthermore, it also includes: S4. Calculate and set the corresponding display method for the code of each key code block according to the coverage of each key code block. The key code blocks with different coverage will have different display methods.

[0017] As can be seen from the above description, in order to facilitate testers to view the execution status of each part of the code, different display methods are set for each key code block according to different coverage rates.

[0018] Furthermore, it also includes: S5. Monitor whether the script code of the target software has changed. If so, re-execute steps S1 to S3 for the target software to generate a coverage change report for the target software.

[0019] As described above, by setting up a monitoring function, when the target software's script code changes, a coverage test is immediately performed on the target software again, and a coverage change report is generated so that the development team can understand the changes in code quality in a timely manner.

[0020] Furthermore, step S3 also includes: The actual execution path is compared with all possible paths. Based on the comparison results, the code that was not executed is determined, and the display mode of the code that was not executed is set to the preset display mode.

[0021] As described above, the actual execution path and all possible paths are not only used to calculate coverage, but also to identify which paths were not executed by comparison. This allows developers to conduct further testing and optimization on these unexecuted paths, ensuring the quality and reliability of the code.

[0022] Please refer to Figure 2 A software code coverage testing terminal 1 includes a memory 2, a processor 3, and a computer program stored in the memory 2 and executable on the processor 3. When the processor 3 executes the computer program, it performs the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

[0023] As can be seen from the above description, the beneficial effects of the present invention are as follows: by combining runtime information acquisition and static analysis technology, the execution of the target software's script code is analyzed from both the runtime and static levels. Furthermore, by combining the actual execution path and all possible paths, the script code coverage of the target software is calculated. This allows for a more comprehensive consideration of the situation of both new and old code, and rapid analysis of script code coverage, in order to analyze whether there are potential problems and ensure the quality and reliability of the code.

[0024] Furthermore, the script code includes at least two key code blocks, each of which corresponds one-to-one with a function of the target software; Step S3 further includes: Obtain a first actual path corresponding to one of the key code blocks from the actual execution path, and obtain a first possible path of the key code block corresponding to the first actual path from all possible paths; Based on the first actual path and the first possible path, calculate the coverage of the corresponding key code block.

[0025] As described above, when analyzing the coverage of script code, the multiple key code blocks it contains can be calculated and analyzed one by one, which helps testers quickly understand which areas of the code are not fully covered, making it easier to compare different parts of the code and making the analysis process more detailed.

[0026] Furthermore, it also includes: S4. Calculate and set the corresponding display method for the code of each key code block according to the coverage of each key code block. The key code blocks with different coverage will have different display methods.

[0027] As can be seen from the above description, in order to facilitate testers to view the execution status of each part of the code, different display methods are set for each key code block according to different coverage rates.

[0028] Furthermore, it also includes: S5. Monitor whether the script code of the target software has changed. If so, re-execute steps S1 to S3 for the target software to generate a coverage change report for the target software.

[0029] As described above, by setting up a monitoring function, when the target software's script code changes, a coverage test is immediately performed on the target software again, and a coverage change report is generated so that the development team can understand the changes in code quality in a timely manner.

[0030] Furthermore, step S3 also includes: The actual execution path is compared with all possible paths. Based on the comparison results, the code that was not executed is determined, and the display mode of the code that was not executed is set to the preset display mode.

[0031] As described above, the actual execution path and all possible paths are not only used to calculate coverage, but also to identify which paths were not executed by comparison. This allows developers to conduct further testing and optimization on these unexecuted paths, ensuring the quality and reliability of the code.

[0032] Please refer to Figure 1 Embodiment 1 of the present invention is as follows: A software code coverage testing method, taking Lua script code as an example, includes the following steps: S0. Introduce the libraries and tools required for the target code of the test software, including the Lua runtime environment, libraries for the Hook mechanism, and static analysis tools such as `luac`. Specifically, LuaJIT can be introduced as the Lua runtime environment, and LuaRocks can be used to manage the required libraries. For the Hook mechanism, specific Lua libraries such as debug.sethook can be used.

[0033] S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; In this embodiment, the LuaHook mechanism is used to set up hook functions during the execution of the server-side Lua code to capture real-time execution information, including function calls and variable assignments. For example, in a game server, when a player performs a specific action, a series of Lua functions are called to handle it. The hook mechanism captures these function calls and the assignment of related variables. Then, the captured information is summarized in real time, recording key data such as the execution path and timestamps.

[0034] For example, record the timestamps of player actions, as well as the order and parameter values ​​of function calls. Continuously write this information to a log file to create a detailed runtime log. The generated log file can be used for subsequent analysis and troubleshooting. For instance, if game lag occurs, you can check the log file to determine which Lua functions are taking too long to execute.

[0035] S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; In this embodiment, the script code includes at least two key code blocks, each corresponding one-to-one with a function of the target software. Static analysis of the server-side Lua source code is performed using tools such as `luac`. Taking a large-scale multiplayer online game as an example, the game's server may contain numerous Lua scripts for handling player interactions, game logic, etc. `luac` can be used to perform static analysis on these scripts. The source code is traversed to extract information from key code blocks such as functions and configurations, including function names, parameters, and line numbers. For example, functions handling player combat logic in the game can be extracted, including function parameters such as player attack power and defense power, as well as the line number of the function.

[0036] Examples of all possible paths are illustrated below: Let's take a simple game login function as an example. During the static analysis phase, the Lua code related to the login function may reveal several different execution scenarios. For instance, one path is when the user enters the correct username and password; another is when the user enters an incorrect username and password but performs a password recovery operation; and yet another is when the user enters an incorrect username and password and their account is locked after multiple attempts. These different scenarios constitute all the possible paths obtained from the static analysis. However, during actual runtime, such as in a test, only some paths may be executed. For example, the path where the user successfully logs in with the correct username and password, and the path where the user enters an incorrect username and password but exits without performing a password recovery operation, are the actual code execution paths.

[0037] S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

[0038] In this embodiment, assuming that static analysis shows 100 possible code paths, and 80 paths are actually executed during a game, the code coverage rate is calculated to be 80% by statistically analyzing the proportion of executed lines of code to the total number of lines of code. It should be noted that the calculation method is not limited to the aforementioned method of calculating the execution percentage.

[0039] Furthermore, the above calculations are performed on different game code segments corresponding to different key code blocks. Specifically, the first actual path corresponding to a key code block is obtained from the actual execution path, and the first possible path of the key code block corresponding to the first actual path is obtained from all possible paths. Based on the first actual path and the first possible path, the coverage of the corresponding key code block is calculated.

[0040] In addition, by comparing the actual execution path with all possible paths, the code that was not executed is identified based on the comparison results, and its display mode is set to the default display mode. If a function is not executed during testing, its code area will be highlighted in red, allowing developers to quickly locate the function for further testing and optimization.

[0041] S4. Calculate and set the corresponding display method for the code of each critical code block based on the coverage rate. The display method differs for critical code blocks with different coverage rates. For example, the display method uses color. The visualization of the test results includes: In the editor, based on the calculated code coverage results, different colors are assigned to key code blocks with different coverage levels: Firstly, fully covered code areas are highlighted in bright green, indicating that this code has been thoroughly executed in tests and is stable and reliable. When developers see large green areas, they can intuitively understand which parts of the code have undergone rigorous testing and can be used with confidence. For example, in the core combat logic of a game, if the code coverage is high and displayed in green, it means that this part of the functionality performs well in various test scenarios.

[0042] Secondly, partially covered code is highlighted in a striking yellow, alerting developers that while these areas have some test coverage, there are still instances where code hasn't been executed. This yellow warning prompts developers to pay closer attention to these sections and conduct more in-depth testing. For example, in new game feature modules, code in certain scenarios might not be fully covered; the yellow highlighting allows developers to quickly locate these potential risk areas.

[0043] Third, uncovered code is highlighted in bright red, a strong visual signal indicating that this code was not executed during testing and poses a significant risk. Red areas are a key focus for developers, who need to design new test cases to cover this code as quickly as possible to ensure the game's stability and reliability. For example, if the code for a peripheral function of the game is displayed in red, developers need to take immediate action to prevent problems from occurring in actual operation.

[0044] S5. Monitor whether the script code of the target software has changed. If so, re-execute steps S1 to S3 for the target software to generate a coverage change report for the corresponding target software.

[0045] In this embodiment, the execution of server-side Lua code and test implementation is continuously monitored. When new test cases are executed or code changes occur, the above process is repeated. For example, during the continuous development of a game, as new features are added and code is modified, the coverage changes of the Lua code are continuously monitored. For instance, when the development team adds a new gameplay element, the new Lua code needs to be tested. At this time, the tool will automatically detect the code change and re-perform coverage analysis.

[0046] Simultaneously, a feedback mechanism is provided, such as generating reports or displaying coverage change trends on the interface, to help the development team understand changes in code quality in a timely manner; generating detailed coverage change reports, including specific code coverage values, uncovered code areas, and other information. Additionally, coverage change trend graphs are displayed on the development tool interface, allowing the development team to intuitively understand the improvement or decline in code quality. For example, the development team can use reports and trend graphs to understand that in the most recent test, code coverage increased by 5%, or that the code coverage of a certain module decreased, requiring focused testing and optimization.

[0047] Please refer to Figure 2 Embodiment two of the present invention is as follows: A software code coverage testing terminal 1 includes a memory 2, a processor 3, and a computer program stored in the memory 2 and executable on the processor 3. When the processor 3 executes the computer program, it implements a software code coverage testing method according to Embodiment 1.

[0048] In summary, the software code coverage testing method and terminal provided by this invention combines runtime information acquisition and static analysis techniques to analyze the execution of the target software's script code from both runtime and static perspectives. Furthermore, by combining the actual execution path and all possible paths, the coverage of the target software's script code is calculated. This approach comprehensively considers both new and old code, and enables coverage analysis of key code blocks within the script code. It quickly parses the script code coverage to facilitate the analysis of potential problems and ensure code quality and reliability.

[0049] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A software code coverage testing method, characterized in that, Includes the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

2. The software code coverage testing method according to claim 1, characterized in that, The script code includes at least two key code blocks, and each key code block corresponds one-to-one with the function of the target software. Step S3 further includes: Obtain a first actual path corresponding to one of the key code blocks from the actual execution path, and obtain a first possible path of the key code block corresponding to the first actual path from all possible paths; Based on the first actual path and the first possible path, calculate the coverage of the corresponding key code block.

3. The software code coverage testing method according to claim 2, characterized in that, Also includes: S4. Calculate and set the corresponding display method for the code of each key code block according to the coverage of each key code block. The key code blocks with different coverage will have different display methods.

4. The software code coverage testing method according to claim 1, characterized in that, Also includes: S5. Monitor whether the script code of the target software has changed. If so, re-execute steps S1 to S3 for the target software to generate a coverage change report for the target software.

5. The software code coverage testing method according to claim 1, characterized in that, Step S3 further includes: The actual execution path is compared with all possible paths. Based on the comparison results, the code that was not executed is determined, and the display mode of the code that was not executed is set to the preset display mode.

6. A software code coverage testing terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: S1. During testing, acquire and record the real-time execution information of the target software's script code in a running state, and obtain the actual execution path based on the real-time execution information; S2. Perform static analysis on the source code of the script and obtain all possible paths based on the results of the static analysis; S3. Calculate the script code coverage of the target software by combining the actual execution path and all possible paths.

7. A software code coverage testing terminal according to claim 6, characterized in that, The script code includes at least two key code blocks, and each key code block corresponds one-to-one with the function of the target software. Step S3 further includes: Obtain a first actual path corresponding to one of the key code blocks from the actual execution path, and obtain a first possible path of the key code block corresponding to the first actual path from all possible paths; Based on the first actual path and the first possible path, calculate the coverage of the corresponding key code block.

8. A software code coverage testing terminal according to claim 7, characterized in that, Also includes: S4. Calculate and set the corresponding display method for the code of each key code block according to the coverage of each key code block. The key code blocks with different coverage will have different display methods.

9. A software code coverage testing terminal according to claim 6, characterized in that, Also includes: S5. Monitor whether the script code of the target software has changed. If so, re-execute steps S1 to S3 for the target software to generate a coverage change report for the target software.

10. A software code coverage testing terminal according to claim 6, characterized in that, Step S3 further includes: The actual execution path is compared with all possible paths. Based on the comparison results, the code that was not executed is determined, and the display mode of the code that was not executed is set to the preset display mode.

Images