Detection method and device for testing coverage rate and storage medium

Abstract

The invention discloses a detection method and device for testing the coverage rate and a storage medium, and relates to the technical field of data processing, and the method comprises the steps: carrying out the difference recognition between a current version file and a historical version file of a target project, and obtaining a difference file; inserting an interface calling code into the difference file; in the process of testing the coverage rate of the current version file, when a monitoring component monitors that an executed code exists, information of the executed code is obtained according to the interface calling code; and obtaining a coverage rate test result of the difference file according to the information of the executed code and the code information in the difference file. According to the invention, the time and resource occupation in the coverage rate test process can be reduced, and the test efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a test coverage detection method, device and storage medium. Background Art

[0002] Test coverage refers to the proportion of the internal structure or code of the software that can be touched by the execution of test cases during the software testing process. It reflects the depth and breadth of the testing activities and is an important indicator for measuring test quality and risk control.

[0003] At present, when testing coverage, all codes in different versions of files are fully tested. However, comprehensive testing involves a large number of test cases and a complex test environment, which consumes more computing resources and time. For codes that have not changed for a long time, repeated testing may not generate new value, resulting in a waste of resources.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a test coverage detection method, device and storage medium, aiming to solve the technical problem of how to perform coverage testing in a multi-language environment.

[0006] To achieve the above object, the present application proposes a method for detecting test coverage, the method comprising:

[0007] Identify differences between the current version file and the historical version file of the target project to obtain a difference file;

[0008] Inserting interface call code into the difference file;

[0009] In the process of performing coverage test on the current version file, when the monitoring component monitors the existence of the executed code, the information of the executed code is obtained according to the interface calling code;

[0010] A coverage test result of the difference file is obtained according to the information of the executed code and the code information in the difference file.

[0011] In one embodiment, the step of identifying differences between the current version and the historical version of the target project to obtain a difference file includes:

[0012] Obtain the current version file and the historical version file;

[0013] Using SVN or Git tools, identify differences between the current version file and the historical version file;

[0014] The difference file is generated according to the difference identification result.

[0015] In one embodiment, the step of inserting the interface call code into the difference file includes:

[0016] Searching for matching items in the difference file according to a preset regular expression;

[0017] When the matching item is found, the position of the matching item is determined;

[0018] Determining the insertion position of the interface calling code according to the position of the matching item;

[0019] The interface calling code is inserted into the difference file according to the insertion position.

[0020] In one embodiment, when the monitoring component monitors the existence of the executed code, the step of acquiring the information of the executed code according to the interface calling code includes:

[0021] Parsing and identifying game objects in the difference file;

[0022] Determine the file information corresponding to the game object;

[0023] When the monitoring component monitors that the game object is called for activation, determining that the game object called for activation is a target game object;

[0024] Get the file information corresponding to the target game object.

[0025] In one embodiment, when the monitoring component monitors that the game object is called for activation, before the step of determining that the game object called for activation is a target game object, the step further includes:

[0026] Adding the monitoring component to the game object;

[0027] Perform coverage test on the current version file.

[0028] In one embodiment, the step of obtaining the file information corresponding to the target game object includes:

[0029] Generate and send a monitoring message according to the monitoring component;

[0030] After receiving the monitoring message, the monitoring center obtains the file information corresponding to the target game object according to the interface calling code.

[0031] In one embodiment, the method further comprises:

[0032] Obtain a test report of the historical version file;

[0033] Obtaining a test report for the current version file according to the coverage test result of the difference file and the test report of the historical version file;

[0034] The test report is stored according to the version number of the current version file.

[0035] In one embodiment, the method further comprises:

[0036] Determine uncovered code areas according to coverage test results of the difference files;

[0037] The test cases are optimized according to the uncovered code area, and the coverage test is performed again.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a test coverage detection device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the test coverage detection method as described above.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the test coverage detection method described above are implemented.

[0040] The present application provides a method for testing coverage, which compares two versions of files to obtain a difference file, inserts interface call code into the difference file, obtains the code execution in the difference file during coverage testing, and obtains the test results of the difference file. Compared with comprehensive testing, only statistically analyzing the code execution of the difference part can reduce the scope of analysis, requiring less resources and time. As a result, test results can be obtained faster and test efficiency can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0042] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0043] Figure 1A flowchart of the first embodiment of the test coverage detection method of the present application is provided;

[0044] Figure 2 A detailed flow chart of the first embodiment of the test coverage detection method of the present application is provided;

[0045] Figure 3 A schematic diagram of a flow chart provided for the second embodiment of the method for detecting the test coverage of the present application;

[0046] Figure 4 A schematic diagram of a flow chart of a third embodiment of a method for detecting test coverage of the present application;

[0047] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the test coverage detection method in the embodiment of the present application.

[0048] Description of Figure Numbers:

[0049] 1001, processing device; 1002, read-only memory; 1003, storage device; 1004, memory; 1005, bus; 1006, I / O interface; 1007, input device; 1008, output device; 1009, communication device.

[0050] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0052] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0053] The main solution of the embodiment of the present application is: to identify the differences between the current version file and the historical version file of the target project to obtain a difference file; to insert an interface call code into the difference file; in the process of coverage testing the current version file, when the monitoring component monitors the existence of the executed code, the information of the executed code is obtained according to the interface call code; based on the information of the executed code and the code information in the difference file, the coverage test result of the difference file is obtained.

[0054] At present, when testing coverage, all codes in different versions of files are fully tested. However, comprehensive testing involves a large number of test cases and a complex test environment, which consumes more computing resources and time. For codes that have not changed for a long time, repeated testing may not generate new value, resulting in a waste of resources.

[0055] The present application provides a method for testing coverage, which compares two versions of files to obtain a difference file, inserts interface call code into the difference file, obtains the code execution in the difference file during coverage testing, and obtains the test results of the difference file. Compared with comprehensive testing, only statistically analyzing the code execution of the difference part can reduce the scope of analysis, requiring less resources and time. As a result, test results can be obtained faster and test efficiency can be improved.

[0056] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a program process abnormality monitoring device, etc. The following takes the detection device for test coverage as an example to illustrate this embodiment and the following embodiments.

[0057] Based on this, the present application embodiment provides a method for detecting test coverage, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the test coverage detection method of the present application.

[0058] In this embodiment, the test coverage detection method includes steps S10 to S40:

[0059] Step S10, identifying differences between the current version file and the historical version file of the target project to obtain a difference file;

[0060] In this embodiment, difference identification is completed by tools provided by a version control system (such as Git, SVN, etc.) or a special difference comparison tool (such as DiffMerge, WinMerge, etc.). First, determine the two versions to be compared. The current version can be the latest version in the project or the version in progress. The historical version is an old version that you want to compare with the current version. Secondly, use the version control system to obtain the current version file and the historical version file. After having two versions of the file, use a difference comparison tool to perform difference identification. The difference file obtained includes all the differences between the two versions, including specific difference parts, difference types (addition, deletion or modification) and the number of lines where the difference parts are located. By performing difference identification between the current version file and the historical version file of the target project, a detailed difference file can be obtained to display and understand the difference content between the versions.

[0061] Please refer to Figure 2 In a feasible implementation manner, step S10 may include steps S11 to S13:

[0062] Step S11, obtaining the current version file and the historical version file;

[0063] Step S12, identifying differences between the current version file and the historical version file according to the SVN or Git tool;

[0064] Step S13, generating the difference file according to the difference identification result.

[0065] Optionally, in the SVN tool, use the svn checkout command to check out the latest version from the SVN repository. If it has already been checked out, use the svn update command to ensure that the working copy is up to date. The historical version file can be any version of the file. Use svn checkout with the -r (revision) parameter to check out a specific version of the file and check the specific version out to another directory. After obtaining the two versions of the file, identify the differences and use the svn diff command to compare two directories or files (such as project-current and project-history). Use a script to traverse the directory and compare files, and generate a difference file based on the comparison results.

[0066] Optionally, use Git to identify differences. Use the git checkout command with the hash value or tag of the historical commit to check out a specific historical version and the current version. Use the git diff command to compare the differences between the two versions of the file.

[0067] Optionally, use a graphical interface difference comparison tool such as DiffMerge or WinMerge to obtain two versions of the file and identify the differences. In the DiffMerge or WinMerge application, browse and select the path of the current version file and the historical version file or directory, load the file or directory: Secondly, compare the differences between the two files, you can highlight the differences in the text; for directories, you can list all different files and subdirectories and compare them recursively.

[0068] Step S20, inserting the interface calling code into the difference file;

[0069] In this embodiment, the additional code inserted into the key positions (such as statements, branches, function entries, etc.) of the source code in the difference file is used to collect information about whether these positions are executed when the program is executed. These key positions usually represent the key paths and logical branches in the program. By recording their execution status, the coverage of the program code by the test cases can be evaluated.

[0070] Please refer to Figure 2In a feasible implementation manner, step S20 may include steps S21 to S24:

[0071] Step S21, searching for matching items in the difference file according to a preset regular expression;

[0072] Step S22, when the matching item is found, determining the position of the matching item;

[0073] Step S23, determining the insertion position of the calling code according to the position of the matching item;

[0074] Step S24: inserting the interface calling code into the difference file according to the insertion position.

[0075] In this implementation, first, a regular expression is defined. Different regular expressions are defined for different language environments. The regular expression pattern is used to describe the text pattern to be matched. Various metacharacters, ordinary characters and special structures can be used to build complex patterns. Secondly, the regular expression is used to search for matching items in the target text. Based on the matching results of the regular expression, the exact location where the code is to be inserted is determined. The code for the interface call is inserted at the determined location.

[0076] For example, if we want to Inside the tag (i.e. When inserting a piece of JavaScript code before a tag, first, to find all tags, you can use regular expressions; second, to search for text, in Python, you can use re.finditer() or re.findall() to find all matches. For each one found, insert the corresponding code before it.

[0077] Optionally, in the Lua language environment, insert code after function and before else, else if, end, return or back. If the valid code (non-comment, comment block, space, line break, etc.) of the last line of Lua is returnxxxx (class name), the code can also be inserted outside the function; if it is not return xxxx (class name) standard Lua script, it can only be inserted in the function block.

[0078] Optionally, in the C# language environment, when you need to insert after ")" + "middle space or line break" + "{" and before "else, else if, return, back, or continue}", the regular expression needs to determine whether there are other non-space, non-"(", and non-";" strings before and after keywords such as function, else, else if, end, return, back, etc., to exclude whether they are variable names rather than system keywords.

[0079] In this embodiment, when determining the insertion position, there may be a direct insertable position or there may be no direct insertable position. When there is a direct markable position, the direct insertable position usually refers to certain specific points in the code, after which the code is inserted without destroying the original logical structure and is easy to be understood by subsequent developers. For example, in Java, this can be the end of a method call, the end of a statement block, after a loop or conditional statement, etc. When there is no direct insertable position, but the line of the difference content is located in a larger code structure (such as a function body), it is necessary to search downward for other possible positions within this structure. According to the characteristics of the code structure, write or select a regular expression that can match the potential insertion point within the structure. This may be a broader regular expression used to match the end of statements, expressions, etc. within the structure. If the search reaches the end of the structure and still no suitable position is found, special processing may be required, such as recording an error, inserting code at the end of the structure (although this may not be the best practice), or giving up inserting code at this position.

[0080] In a feasible implementation, after defining the regular expression, a regular expression testing tool is used to debug and verify to ensure that the regular expression is correct. In the verification process, first, select a suitable regular expression testing tool, such as Regex101, RegExr, RegexPlanet, Rubular, Pythex, and Debuggex. When selecting a tool, ensure that the selected tool supports the regular expression engine used (such as JavaScript, Python, PCRE, etc.). After selecting a suitable tool, enter the test text in the area for entering the test text. The tool will match the test text according to the regular expression and display the matching results. The matching results are usually presented in a visual way, such as highlighting the matching items or listing all matching items. If the matching results are not as expected, the error checking and debugging functions provided by the tool can be used to find and solve the problem. These functions may include: error prompts: the tool prompts syntax errors or logical errors in the regular expression; explanations: the tool may provide detailed explanations and instructions of the regular expression to help understand the matching process; debugging mode: allows the regular expression to be executed step by step and the state changes during the matching process are observed. Finally, according to the debugging results, the regular expression is adjusted and optimized. By following the above steps, you can effectively use regular expression testing tools to debug and verify complex regular expressions, thereby improving work efficiency and accuracy.

[0081] In this implementation, in different language environments, different regular expressions are defined to insert interface call codes in the difference part to pass information about the code executed in the difference part, which can support multi-language and cross-platform coverage testing and solve the problem that a single coverage testing tool is difficult to achieve full compatibility with multiple languages ​​and multiple environments.

[0082] Step S30, in the process of performing coverage test on the current version file, when the monitoring component monitors the existence of the executed code, the information of the executed code is obtained according to the interface calling code;

[0083] In this embodiment, targeted test cases are designed according to the content of the difference file to ensure coverage of newly added or modified functional points. The test cases are run to perform coverage testing. The execution of the code in the difference file can be monitored by configuring a monitoring component. When the monitoring component monitors that the code is executed, the interface call code inserted in the difference file is called, and the file name and line number of the executed code are transmitted to the monitoring center of the server.

[0084] In this embodiment, during the coverage test, the code execution in the difference file is monitored and the executed code information is obtained. Compared with the statistics and analysis of the code execution in the current version file, the repeated statistical analysis steps are reduced and the efficiency of the coverage test is improved.

[0085] Step S40, obtaining a coverage test result of the difference file according to the information of the executed code and the code information in the difference file.

[0086] In this embodiment, the total number of lines of code in the difference file and the number of executed difference lines of code are obtained, the number of executed difference lines of code is divided by the total number of lines of code in the difference file, and the proportion of the number of covered lines of code to the total number of lines of code in the coverage test is calculated to obtain the line coverage. The proportion of executed code. If the proportion of executed code is high, it means that most of the changed code has been tested and there are fewer undiscovered errors. A low proportion may mean that there is insufficient testing, that is, some important changes have not been fully tested. Test cases can be further written or modified to improve coverage.

[0087] In a feasible implementation, the ratio of the number of covered code branches to the total number of code branches can be calculated according to the information of the executed code and the code information in the difference file during the coverage test, so as to obtain the branch coverage. The ratio of the number of covered functions or methods to the total number of functions or methods can also be calculated during the coverage test to obtain the function / method coverage. The ratio of the number of covered classes to the total number of classes can also be calculated during the coverage test to obtain the function / method coverage. The class coverage can be obtained.

[0088] The present application provides a method for testing coverage, which compares two versions of files to obtain a difference file, inserts interface call code into the difference file, obtains the code execution in the difference file during coverage testing, and obtains the test results of the difference file. Compared with comprehensive testing, only statistically analyzing the code execution of the difference part can reduce the scope of analysis, requiring less resources and time. As a result, test results can be obtained faster and test efficiency can be improved.

[0089] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 In a feasible implementation manner, step S30 may include steps S31 to S34:

[0090] Step S31, parsing and identifying the game objects in the difference file;

[0091] Step S32, determining the file information corresponding to the game object;

[0092] Step S33, when the monitoring component monitors that the game object is called for activation, determining that the game object called for activation is a target game object;

[0093] Step S34, obtaining file information corresponding to the target game object.

[0094] It should be noted that in game development, the "activated" state of a game object (such as a character, prop, UI element, etc.) may mean that it becomes visible, interactive, or starts to execute its logic. This is usually controlled by some mechanism (such as game logic, player operation, event triggering, etc.). "Being called" may mean that a method or function on the object is executed. This may be because of the needs of the game logic, or because of the player's interaction with the game object.

[0095] In the present embodiment, coverage test is performed for specific game objects in game development. First, from the difference file, newly added or modified game objects (such as roles, scene elements, etc.) are identified, and the file information corresponding to these game objects (such as file paths, versions, modification times, etc.) are collected. When the game is running, the activation event of the game object is captured in real time by the monitoring component in the plug-in. When the game object (i.e., the target game object) called for activation is determined, the file information corresponding to the game object is obtained so that coverage analysis can be performed later. By comparing the file information of the target game object (i.e., the game object actually tested) with the file information of all game objects (including unactivated), the test coverage of the target game object is evaluated.

[0096] In this embodiment, the execution of the code related to the target game object during the game running process is recorded. By analyzing the collected code execution data, the execution ratio of the target game object code is calculated. The calculated coverage rate can also be compared with a preset threshold to evaluate whether the test is sufficient.

[0097] In a feasible implementation manner, the following steps are also included before step S33:

[0098] Adding the monitoring component to the game object;

[0099] Perform coverage test on the current version file.

[0100] In this embodiment, first, a plug-in that supports the game engine (such as Unity, Unreal Engine, Cocos2d-x, etc.) is selected, and the plug-in can collect code coverage data. A plug-in is an independent code module that can be loaded into the game engine of a game or application. A plug-in can perform various tasks, such as processing network requests, providing additional game logic, integrating third-party services, etc. According to the documentation or guide of the plug-in, the assets of the plug-in (such as DLLs, SOs, script files, etc.) and necessary configuration files are added to the target project. The plug-in can be installed by copying the file to a specific folder of the project, or through the project's management tool (such as Unity's Package Manager, Unreal Engine's EpicGames Launcher). In order to automatically collect data when using the plug-in for coverage testing, the API call or specific code provided by the plug-in is inserted into the engine's script. Secondly, the rules are configured in the monitoring component of the plug-in to identify when the code in the difference file is executed through specific monitoring points, and match the file path and code line. When it is detected that the code in the difference file is executed, a corresponding monitoring message is generated and sent to the monitoring center of the server, optionally, it can be implemented by HTTP requests, WebSocket connections, message queues, etc.

[0101] In this implementation, after receiving the monitoring message, the plug-in interface made by the system for each platform is called, and the Key (relative file path name) and the number of execution lines are passed in. The relative file path corresponding to the executed code and the number of execution lines corresponding to the executed code can be obtained as: GIE.Instance:Notice(" / Client / MJHJ_UNITY / ApkFeature / Raid3 / Lry_Test / Assets / App / MJ / LuaScript / scripts / Game / MJGameBase / BaseComponent / BaseInfo / DeskBaseInfo.lua", "384").

[0102] For example, for the Unity engine, through "AssetDatabase.LoadAssetAtPath<Gam eObject> (assetPath);" interface, pass in the path of the game object to obtain game resources, and pass "asset.AddComponent <giegameobj>();" interface, add the "GI EGameObj" game object monitoring component to the game object.

[0103] In this implementation, the plug-in can be connected to the project according to the instructions to monitor the code execution of the difference part, and can work directly in the existing development or test environment without additional configuration or a specific Android environment.

[0104] In a feasible implementation manner, step S34 includes the following steps:

[0105] Generate and send a monitoring message according to the monitoring component;

[0106] After receiving the monitoring message, the monitoring center obtains the file information corresponding to the target game object according to the interface calling code.

[0107] In the present embodiment, the monitoring component defines which events need to be monitored, and these events may include the state change of the game object, the player behavior, the periodic events triggered by the system time, etc. Logic is written in the monitoring component to detect whether these events occur. When the event is detected, a monitoring message is generated. The monitoring message may include the time of occurrence, the unique identifier (such as ID or name) of the target game object, and the interface call code for obtaining the target game object file information. After the monitoring center receives the monitoring message, the monitoring message is parsed to extract the key information such as the interface call code and the identifier of the target game object. And according to the extracted interface call code, the target game object file information is obtained.

[0108] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 4 After step S40, the test coverage detection method further includes steps S50 to S70:

[0109] Step S50, obtaining a test report of the historical version file;

[0110] Step S60, obtaining a test report of the current version file according to the coverage test result of the difference file and the test report of the historical version file;

[0111] Step S70: storing the test report according to the version number of the current version file.

[0112] In this implementation, the test report of the historical version is obtained from the corresponding storage location. The storage location of the test report can be a file server, a version control system, a database, etc. For the unchanged parts of the current version file, the test results of the historical version are reused. If the result of a test case in the historical version for the unchanged part is "passed", the result of the test case in the current version can also be considered as "passed". The reused historical test results are combined with the coverage test results of the difference file to comprehensively evaluate the test status of the current version.

[0113] In this embodiment, a test report is written and generated based on previously executed test cases and collected test results. A test report typically contains the following key information: Test cases, which lists all executed test cases, including test numbers, test descriptions, expected results, etc. Test results: For each test case, record whether the actual results are consistent with the expected results. If there are differences, the inconsistencies need to be described in detail, and may include additional information such as screenshots, log files, or error codes. Defect (Bug) report: For any problems or defects found, it is necessary to record in detail information such as their description, reproduction steps, severity level, assigned developer, and repair status. Test summary: Summarize the test results, including key indicators such as test coverage, number of defects found, defect distribution, and test success rate.

[0114] In this embodiment, the test report is stored according to the version number of the current version file. After the test report is generated, in order to ensure the traceability and manageability of the test results, the test report needs to be stored according to the version number of the current version file. Optionally, a clear naming convention is formulated for the test report file, which should contain key information such as version number and date for quick identification. For example, TestReport_v1.2.3_20230401.pdf. Choose a suitable storage location to save the test report. This can be a folder in the local file system or a directory on a cloud storage service (such as Amazon S3, Google Cloud Storage, etc.). Ensure that the location is accessible to both the test team and the development team. In order to facilitate the subsequent search and use of the test report, an index or database can be created to store the metadata of the report (such as version number, date, test scope, etc.). In this way, when it is necessary to review the test results of a specific version, the corresponding report can be quickly located.

[0115] In this embodiment, to ensure that the storage location of the test report is secure to prevent unauthorized access or data leakage, appropriate access permissions and encryption measures are set according to the company's security policies and best practices. According to the responsibilities and needs of employees, it is clear who has access to the test report and set the corresponding access level to ensure that only authorized personnel can access sensitive data.

[0116] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above description, and will not be described in detail later. Figure 5 After step S50, the test coverage detection method further includes the following steps:

[0117] Determine uncovered code areas according to coverage test results of the difference files;

[0118] The test cases are optimized according to the uncovered code area, and the coverage test is performed again.

[0119] In this embodiment, the test report may include information such as the total number of lines of the tested code, the number of lines executed, the number of lines not executed, and the statement coverage (referring to the proportion of statements executed in the program during the test case execution process). The uncovered code areas can be viewed from the test report. These uncovered areas may be new and complex logic, or omissions caused by improper test case design. For the uncovered areas, the reasons why these areas are not covered are analyzed. The information on the covered code area may include: the specific number of lines of code, functions, classes or modules.

[0120] In a feasible implementation, when specifically analyzing the reasons for non-coverage, the analysis can be conducted from multiple dimensions such as test cases, the characteristics of uncovered code, and test cases. When analyzing from the perspective of test cases, check whether the test cases cover all major business scenarios and functional points, and evaluate whether the test cases contain sufficient tests for boundary conditions and abnormal situations. You can also check and analyze the execution path of the test cases to determine whether the non-coverage is caused by the failure of the execution flow of the test cases to trigger certain code paths. You can also identify possible logical jumps or omissions in the test cases, which may cause certain code areas to not be executed. When analyzing from the perspective of code characteristics, you can analyze from the perspective of code logic problems. Some code areas may not be triggered by test cases due to logical errors or vulnerabilities. By reviewing the code logic, identify and fix potential logic problems. When analyzing from the perspective of test cases, check whether there are cases where certain code paths are not covered due to insufficient or unreasonable test data.

[0121] In this embodiment, new test cases are designed and added for important areas that are not covered. Ensure that the new test cases can cover these areas and verify the relevant logic. If there are deficiencies in the existing test cases, such as incomplete coverage or unreasonable test paths, consider modifying these test cases to improve coverage. After optimizing the test cases, rerun the test and collect new coverage data. By continuously monitoring the coverage report, new problems can be discovered in a timely manner and the test cases can be further optimized.

[0122] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the detection method of the test coverage of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0123] The present application provides a test coverage detection device, the test coverage detection device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the test coverage detection method in the above-mentioned embodiment one.

[0124] Reference below Figure 5 , which shows a schematic diagram of the structure of a detection device suitable for implementing the test coverage of the embodiment of the present application. The detection device for the test coverage in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The test coverage detection device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0125] like Figure 5 As shown, the detection device for test coverage may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the detection device for test coverage are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the detection device for test coverage to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a detection device for test coverage with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0126] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0127] The test coverage detection device provided by the present application adopts the test coverage detection method in the above embodiment, which can solve the technical problem of how to perform coverage testing in a multi-language environment. Compared with the prior art, the beneficial effects of the test coverage detection device provided by the present application are the same as the beneficial effects of the test coverage detection method provided by the above embodiment, and the other technical features in the test coverage detection device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0128] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0129] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0130] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the test coverage detection method in the above-mentioned embodiment.

[0131] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0132] The computer-readable storage medium may be included in the detection device for testing coverage, or may exist independently without being assembled into the detection device for testing coverage.

[0133] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by a test coverage detection device, the test coverage detection device enables the following to: identify differences between the current version file and the historical version file of the target project to obtain a difference file; insert an interface call code into the difference file; in the process of coverage testing the current version file, when the monitoring component monitors the existence of the executed code, obtain the information of the executed code according to the interface call code; and obtain the coverage test result of the difference file according to the information of the executed code and the code information in the difference file.

[0134] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0135] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0136] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0137] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned test coverage detection method, and can solve the technical problem of how to perform coverage testing in a multi-language environment. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the test coverage detection method provided by the above-mentioned embodiment, and will not be repeated here.

[0138] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.< / giegameobj>

Claims

1. A method for detecting test coverage, characterized in that: The method includes: Identify differences between the current version file and the historical version file of the target project to obtain a difference file; Inserting interface call code into the difference file; In the process of performing coverage test on the current version file, when the monitoring component monitors the existence of the executed code, the information of the executed code is obtained according to the interface calling code; A coverage test result of the difference file is obtained according to the information of the executed code and the code information in the difference file.

2. The method according to claim 1, characterized in that The step of identifying differences between the current version and the historical version of the target project to obtain a difference file includes: Obtain the current version file and the historical version file; Using SVN or Git tools, identify differences between the current version file and the historical version file; The difference file is generated according to the result of the difference identification.

3. The method according to claim 1, characterized in that The step of inserting the interface call code into the difference file comprises: Searching for matching items in the difference file according to a preset regular expression; When the matching item is found, the position of the matching item is determined; Determining the insertion position of the interface calling code according to the position of the matching item; The interface calling code is inserted into the difference file according to the insertion position.

4. The method according to claim 1, characterized in that When the monitoring component monitors the existence of the executed code, the step of acquiring the information of the executed code according to the interface calling code includes: Parsing and identifying game objects in the difference file; Determine the file information corresponding to the game object; When the monitoring component monitors that the game object is called for activation, determining that the game object called for activation is a target game object; Get the file information corresponding to the target game object.

5. The method according to claim 4, characterized in that Before the step of determining that the game object called for activation is a target game object when the monitoring component monitors that the game object is called for activation, the step also includes: Adding the monitoring component to the game object; Perform coverage test on the current version file.

6. The method according to claim 4, characterized in that The step of obtaining the file information corresponding to the target game object includes: Generate and send a monitoring message according to the monitoring component; After receiving the monitoring message, the monitoring center obtains the file information corresponding to the target game object according to the interface calling code.

7. The method according to claim 1, characterized in that The method further comprises: Obtain a test report of the historical version file; Obtaining a test report for the current version file according to the coverage test result of the difference file and the test report of the historical version file; The test report is stored according to the version number of the current version file.

8. The method according to claim 1, characterized in that The method further comprises: Determine uncovered code areas according to coverage test results of the difference files; The test cases are optimized according to the uncovered code area, and the coverage test is performed again.

9. A test coverage detection device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the test coverage detection method according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the test coverage detection method according to any one of claims 1 to 8 are implemented.

Images