Code change testing method and device, storage medium and computer equipment

Abstract

According to the code change testing method and device, the storage medium and the computer equipment, a change code is obtained, and code modification points of the change code and branch paths corresponding to the code modification points are recognized; inserting a corresponding burying point code into each branch path, and generating a burying point data table according to each burying point code; executing a test operation on the change code of the buried point, and marking the tested buried point code in the buried point data table; when it is determined that each burying point code is tested according to the burying point data table, a test report of the changed codes is generated. Thus, it can be ensured that each code change is fully verified, the situations of omission and insufficient verification are avoided, and therefore the coverage degree and accuracy of self-testing can be effectively improved under the situation that the codes are modified.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a code change testing method, device, storage medium and computer equipment. Background Art

[0002] In the development of large-scale software projects, there are usually dozens or even hundreds of developers involved, and a large amount of code is submitted every day during the development process. If any code submission is not fully self-tested and verified, it may introduce new problems, leading to functional regression, anomalies, or even system-level failures, thus affecting the progress of the entire project. In serious cases, it may cause project delays.

[0003] At present, the quality assurance of software code after submission mainly depends on the following links: self-testing by R&D personnel, code review, and continuous integration and compilation into the repository. Although these links can effectively reduce problematic code, it is found in project practice that most problematic code is caused by insufficient self-testing. However, there is currently no objective measurement indicator for the adequacy of self-testing by R&D personnel. It relies on the ability and consciousness of developers, and there is a risk of insufficient self-testing coverage. This may cause some scenarios to be missed, and potential problems in the modified code cannot be identified in time, thus affecting software quality and development progress. Summary of the invention

[0004] The purpose of this application is to solve at least one of the above-mentioned technical defects, especially the technical defect of insufficient self-test coverage in the prior art.

[0005] In a first aspect, the present application provides a code change testing method, the method comprising:

[0006] Obtain the changed code, and identify the code modification points of the changed code and the branch paths corresponding to each code modification point;

[0007] Insert the corresponding embedding code into each branch path, and generate an embedding data table according to each embedding code;

[0008] Perform test operations on the changed code that has been tracked, and mark the tested tracking code in the tracking data table;

[0009] When it is determined that each tracking code has been tested according to the tracking data table, a test report for the changed code is generated.

[0010] In one embodiment, the step of identifying the code modification points of the changed code and the branch paths corresponding to each code modification point includes:

[0011] Scan the changed code to determine the code modification points of the changed code;

[0012] Perform control flow analysis on each code modification point to determine the branch path corresponding to each code point.

[0013] In one embodiment, the step of inserting the corresponding embedding code in each branch path includes:

[0014] Determine the key code segments in each branch path and add corresponding tracking code to each key code segment.

[0015] In one embodiment, the step of generating a burying point data table according to each burying point code includes:

[0016] Obtain the tracking information of each tracking code, and use the tracking information to generate a tracking data table.

[0017] In one embodiment, the step of performing a test operation on the changed code with embedded points includes:

[0018] Compile the changed code with embedded points to generate the corresponding build version and then perform testing operations.

[0019] In one embodiment, the process of determining whether each tracking code has been tested according to the tracking data table includes:

[0020] After each test operation is completed, the code coverage of the embedded point is determined according to the tested embedded point code in the embedded point data table. If the code coverage of the embedded point does not reach the preset threshold, the test operation is continued. If the code coverage of the embedded point reaches the preset threshold, it is determined that each embedded point code has been tested.

[0021] In one embodiment, the step of generating a test report of the changed code includes:

[0022] Obtain the test passing timestamp of each embedded code, and generate a test report of the changed code using an encryption algorithm based on each embedded code and its test passing timestamp.

[0023] In a second aspect, the present application provides a code change testing device, the device comprising:

[0024] A change code acquisition module is used to acquire the change code and identify the code modification points of the change code and the branch path corresponding to each code modification point;

[0025] A point-of-entry data table generation module is used to insert a corresponding point-of-entry code into each branch path and generate a point-of-entry data table according to each point-of-entry code;

[0026] The change code test module is used to perform test operations on the change code that has been tracked and mark the tested tracked code in the tracked data table;

[0027] The test report generation module is used to generate a test report for the changed code when it is determined according to the tracking data table that each tracking code has been tested.

[0028] In a third aspect, the present application provides a storage medium: the storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of any code change testing method in the above embodiments.

[0029] In a fourth aspect, the present application provides a computer device, comprising: one or more processors, and a memory;

[0030] The memory stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the steps of the code change testing method in any one of the above embodiments are performed.

[0031] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0032] In the code change testing method, device, storage medium and computer equipment provided in the present application, by inserting the embedded code in the change code and testing each modification point of the code according to the embedded data table, the coverage and accuracy of the self-test can be effectively improved. First, by identifying the modification points of the change code and inserting the embedded code for the branch path corresponding to each modification point, it can be ensured that each code change is fully verified; then, through the test operation and the management of the embedded data table, it can be clearly marked which embedded codes have been tested to avoid omissions and inadequate verification; when all embedded codes are tested and confirmed to be correct, a test report is generated to provide an objective self-test adequacy indicator. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] 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, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0034] Figure 1 A flowchart of a code change testing method provided in an embodiment of the present application;

[0035] Figure 2 An example diagram of a code change testing method provided in an embodiment of the present application;

[0036] Figure 3 A schematic diagram of the structure of a code change test device provided in an embodiment of the present application;

[0037] Figure 4 A schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0039] The present application provides a code change test method. The following embodiments are described by taking the method applied to a computer device as an example. It can be understood that the computer device can be any device with data processing functions, including but not limited to a single server, a server cluster, a personal laptop, a desktop computer, etc. Figure 1 As shown, the method may include the following steps:

[0040] S101: Acquire the changed code, and identify the code modification points of the changed code and the branch paths corresponding to each code modification point.

[0041] Among them, the changed code refers to the part of the existing code that is modified, added or deleted during the software development process. The code modification point refers to the specific place in the changed code where the modification occurs, which may be the modification of variables, adjustment of functions, change of logic, etc. Branch paths refer to the different execution paths that the program may take during the code execution process due to the existence of control structures such as conditional judgments or loops.

[0042] In this step, you can pull the latest submission from the version control system. For example, you can do this through an API call or command line operation, which will download the latest changed code from the code repository to the local computer. After that, you can identify the code modification points of the changed code by comparing the difference between the current code and the previous version. For example, you can use a difference comparison tool to automatically mark where changes have occurred by calculating the difference between the codes. Next, you can analyze the conditional statements and loop statements in the code to infer the execution paths that each modification point will affect. For example, this can be done through a static code analysis tool or a dynamic execution tracking tool. The tool will analyze the control flow graph and identify possible branch paths of the program.

[0043] It can be understood that, first of all, by obtaining the changed code, it is ensured that the latest code version is being operated. Next, by identifying the code modification points, the change position of each code submission can be accurately located, avoiding blind testing or missing key modified parts. Identifying the branch path corresponding to each modification point can ensure that the different execution paths of the changed code are fully tested, especially for complex conditions and loop statements, to avoid missing potential problems. In general, this process can significantly improve the coverage of self-testing by refining the tracking and testing of code changes.

[0044] S102: inserting a corresponding embedding code into each branch path, and generating a embedding data table according to each embedding code.

[0045] Among them, the tracking code refers to the code snippet inserted in the code for collecting data or recording information. The tracking data table is a table that stores data related to the tracking code, usually containing the execution information of each tracking record, such as timestamp, execution status, call stack, input and output data, etc.

[0046] In this step, in the computer device, inserting the buried code usually adds additional statements or function calls at specific locations in the source code, which can be used to record the status or events of the program when it is running. Specifically, the corresponding buried code is automatically inserted at the key position of each branch path. For example, logging or performance monitoring code is inserted under each branch of the `if` statement. The buried code can be generated by a code editor, IDE plug-in or automation tool. Generating a buried data table usually refers to creating a table in a database or log system to store all data related to the buried code.

[0047] It can be understood that, first of all, by inserting the tracking code in each branch path, it can ensure that sufficient execution data can be collected on all possible paths of code execution, which helps to find potential performance bottlenecks or logical errors, especially in complex conditional judgments or multiple loops. By inserting different tracking codes on the branch path, the test of each condition can be refined to ensure that each branch is fully verified. At the same time, generating a tracking data table can centrally store the tracking data for subsequent analysis and monitoring. As a carrier for data aggregation, the tracking data table can locate and troubleshoot potential defects or anomalies.

[0048] S103: Perform a test operation on the changed code that has been embedded, and mark the tested embedded code in the embedded data table.

[0049] The test operation refers to testing the code that has been embedded to verify the function, performance and correctness of the code. The test operation ensures that the program is executed as expected and can detect potential problems in a timely manner by executing the code and monitoring the embedded data during its operation.

[0050] In this step, for the test operation, an automated test framework can be run to simulate user behavior or test scenarios and trigger the tracking points in the change code. Among them, the test framework can be a unit test framework or an integrated test framework. The framework will execute predetermined test cases for the change code and execute each path of the code by calling relevant methods, inputting data, triggering conditions, etc. At the same time, by monitoring the triggering of each tracking code during the execution process, the corresponding test data is recorded. Marking the tested tracking code can be achieved by adding a flag to the corresponding record in the tracking data table. Whenever the test operation is completed, find the corresponding tracking record in the data table and modify the status field of the record, for example, change the "untested" mark to "tested". This marking operation can be implemented through the update statement of the database, such as the `UPDATE` statement in SQL, or recorded through the logging system of the test framework.

[0051] It can be understood that, first of all, by executing the test operation, it is ensured that each tracking point of the changed code is triggered and the actual execution data is obtained, thereby verifying the behavior and status of the code under different conditions. The test operation verifies each modification path of the changed code to ensure that all code modifications are fully covered and potential errors or performance issues can be captured.

[0052] Marking the tested tracking code provides a clear basis for subsequent test management and result analysis. By recording which tracking points have been tested in the tracking data table, it can ensure that each tracking code has been verified, avoiding repeated tests or missed tests. This marking operation helps improve the efficiency and accuracy of the test and ensures that each change is fully verified.

[0053] S104: When it is determined according to the tracking data table that each tracking code has been tested, a test report of the changed code is generated.

[0054] Among them, the test report is a summary document of the test process and test results, usually including information such as test coverage, test pass rate, defects or anomalies found, etc.

[0055] In this step, you may need to traverse the tracking data table and check the test status field of each tracking code, such as "tested" or "untested". For example, you can complete this check by querying the database, such as using SQL query statements to determine whether all tracking codes have been marked as "tested". If the status fields of all tracking points are displayed as "tested", it means that the test has covered all changed codes. Then, summarize the test results and form a report based on the information in the tracking data table. For example, you can generate a report by writing a script or using an automated tool. Specifically, you can extract necessary data from the tracking data table, such as test status, execution time, error information, etc., and format it into a readable report.

[0056] It can be understood that first, checking whether each tracking code has been tested avoids missing test links and ensures that all modifications are fully covered. Generating a test report further summarizes the test results, making it easier to understand which parts of the code have passed the test and which parts have problems, so as to locate and fix defects in a timely manner. By automatically generating reports, manual intervention is reduced, work efficiency is improved, and the consistency and accuracy of the reports are ensured.

[0057] In the above embodiment, by inserting the embedded point code into the change code and testing each modification point of the code according to the embedded point data table, the coverage and accuracy of the self-test can be effectively improved. First, by identifying the modification points of the change code and inserting the embedded point code for the branch path corresponding to each modification point, it can be ensured that each code change is fully verified; then, through the test operation and the management of the embedded point data table, it can be clearly marked which embedded point codes have been tested to avoid omissions and insufficient verification; when all embedded point codes are tested and confirmed to be correct, a test report is generated to provide an objective self-test adequacy indicator.

[0058] In one embodiment, the step of identifying the code modification points of the changed code and the branch paths corresponding to each code modification point includes:

[0059] Scan the changed code to determine the code modification points of the changed code;

[0060] Perform control flow analysis on each code modification point to determine the branch path corresponding to each code point.

[0061] Control flow analysis refers to the analysis of the execution order of the code in the program, especially the analysis of control structures such as conditional statements and loop statements. Through control flow analysis, different execution paths or branches can be identified.

[0062] Specifically, you can use code comparison tools to compare the original code with the changed code to find the modified or newly added parts of the code. The scanning process can be automated, using scripts to traverse the code base, identify the changed lines and mark them. You can also use static or dynamic analysis tools to analyze the modification points of the code to determine the location and type of the changes. Next, you can use static analysis tools or compilers to perform symbolic execution to analyze the different execution paths of the program. The tool will build a control flow graph of the program based on the branch statements in the code and identify the different branch paths that may be triggered by each code modification point.

[0063] In this embodiment, first, by scanning the changed code, the specific location of the change in the program can be accurately located. Next, through control flow analysis, the branch path corresponding to each code modification point can be identified to ensure that the program is fully tested on all possible execution paths.

[0064] In one embodiment, the step of inserting the corresponding embedding code into each branch path includes:

[0065] Determine the key code segments in each branch path and add corresponding tracking code to each key code segment.

[0066] Among them, the critical code segment is the part of code in a branch path of the program that has a significant impact on the program behavior.

[0067] In this step, you first need to analyze the control flow graph of the program. You can identify the execution logic of each branch path and determine which parts of the code are critical, such as code segments involving state modifications, external interface calls, or complex calculations, by performing static analysis on the conditional statements and loop statements in the program. Code comments, function dependency analysis, and program documentation can also be used to assist. Once the critical code segments are identified, the next step is to insert the tracking code. The tracking code can be a simple log statement, or it can be automatically inserted using a dedicated tracking framework to ensure that it is not missed.

[0068] In this embodiment, firstly, by determining the key code segments, we can focus on those parts that may affect the normal behavior or core functions of the program, rather than inserting tracking points throughout the entire program, thereby improving the efficiency of testing and debugging and ensuring that the most critical parts of the program are fully monitored and verified. Secondly, the insertion of tracking code can help capture key information during program execution.

[0069] In one embodiment, the step of generating a burying point data table according to each burying point code includes:

[0070] Obtain the tracking information of each tracking code, and use the tracking information to generate a tracking data table.

[0071] Specifically, after the embedding code is inserted, the source code of the changed code can be scanned to identify the insertion position of the embedding code. Static analysis technology can be used to identify key positions in the code, such as function calls, conditional judgment statements, etc., and record relevant information. Code comments or predefined tags can also be used to accurately determine the function and trigger condition of each embedding code. For example, in the source code, the "embedding" keyword is marked at each key position or a specific comment is used. After that, these tags are found through regular expressions or abstract syntax tree analysis to obtain the location of the embedding code and its functional role. Then, the embedding information is saved in a data table in a structured manner to generate a embedding data table. Each embedding information corresponds to a row in the table, and the columns of the table may include the insertion position, embedding type, function description, trigger condition, etc. For example, a data management tool is used to store this information, and the information of each embedding point can be inserted into a predefined data table through scripts or database operations.

[0072] In this embodiment, by obtaining the embedding information of each embedding code and generating a embedding data table, the accuracy and efficiency of embedding code insertion can be ensured. Obtaining embedding information helps to accurately locate the location and function of each embedding point and reduce the risk of omission or error; and generating a embedding data table can systematically store this information for subsequent tracking and management.

[0073] In one embodiment, the step of performing a test operation on the changed code with embedded points includes:

[0074] Compile the changed code with embedded points to generate the corresponding build version and then perform testing operations.

[0075] Specifically, the build tool is first called to compile the changed source code. The build tool compiles the source code into target files, and then packages the target files into a build version, which usually has a specific version number to distinguish different code states. For example, the build tool performs code compilation according to the instructions in the configuration file, and the compiled code will be packaged into an installation package or executable file. The compilation process can be triggered by the command line, IDE integrated tools, or automated CI / CD tools to finally generate a build version.

[0076] After the build is generated, a series of tests are performed on the build. The test tool can be used to execute the pre-written test cases to verify whether the functions of the compiled code meet expectations. The test results will generate a report. For example, the test tool will load the compiled build and execute different levels of tests including unit testing and integration testing. The test cases will check various aspects of the code, such as input and output, performance, exception handling, etc. The test tool simulates actual usage scenarios to ensure that the code changes will not destroy the original functions and that the new functions run as expected.

[0077] In this embodiment, first, the compilation process converts the source code into an executable file to ensure that all changes are correctly integrated and avoid missing or wrong code fragments from being executed. The generated build version can be reused in different environments to ensure the consistency of the test environment and the production environment and reduce problems caused by environmental differences. Secondly, the test operation verifies the functionality, performance, and stability of the changed code through automated execution, and can promptly discover potential errors or defects.

[0078] In one embodiment, the process of determining whether each tracking code has been tested according to the tracking data table includes:

[0079] After each test operation is completed, the code coverage of the embedded point is determined according to the tested embedded point code in the embedded point data table. If the code coverage of the embedded point does not reach the preset threshold, the test operation is continued. If the code coverage of the embedded point reaches the preset threshold, it is determined that each embedded point code has been tested.

[0080] Among them, the tracking code coverage refers to the ratio of the tracking code actually tested during the test process to all the tracking codes, reflecting the test coverage of the tracking part in the changed code.

[0081] Specifically, you can scan the tracking data table to confirm which tracking codes have been executed and marked as "tested", and calculate the ratio of the number of tested tracking codes to the total number of tracking codes to obtain coverage. At the same time, when performing multiple rounds of testing, the tracking data table is updated in real time, and the coverage is recalculated after each round of testing to ensure full verification of the tracking code. According to the coverage results, if the preset threshold is not reached, additional test operations are triggered until the coverage meets the requirements. The continued execution of test operations can be achieved through incremental testing, adjusting test cases, or re-running uncovered parts. Test operations can be performed by automated testing tools, and the automation framework will check which tracking points are not triggered during each run and focus on these parts in the next round of testing.

[0082] When it is detected that the coverage has reached or exceeded the preset threshold, the status of each tracking code is marked as "tested" according to the tracking data table, and a final test report is generated, recording all the tracking codes that have been successfully covered.

[0083] In this embodiment, by determining the coverage of each embedded code and adjusting the test operation according to a preset threshold, it is possible to ensure that each key part of the changed code is fully verified, effectively reducing the risk of missing tests and improving the comprehensiveness and accuracy of the tests.

[0084] In one embodiment, the step of generating a test report of the changed code includes:

[0085] Obtain the test passing timestamp of each embedded code, and generate a test report of the changed code using an encryption algorithm based on each embedded code and its test passing timestamp.

[0086] Specifically, by scanning the tracking data table or monitoring test framework, the passing time of each tracking code is automatically extracted from the test record. It can be understood that during the test, when a tracking code successfully passes, the current system time will be recorded and associated with the tracking code. After that, the test status of all tracking codes and their timestamps are used as input, and encryption algorithms such as SHA-256 or AES are used to encrypt and generate a protective test report. This report can ensure the security and integrity of the report content and prevent data from being tampered with during transmission or storage.

[0087] In this embodiment, obtaining the test passing timestamp of each buried point code can ensure that after each test operation, the status of the buried point code and the specific time of passing are accurately recorded. Based on each buried point code and its test passing timestamp, an encryption algorithm is used to generate a test report of the changed code, which can ensure the immutability and security of the report content and prevent the data from being illegally modified during transmission or storage.

[0088] To facilitate understanding of the solution of the present application, specific examples are provided below for illustration.

[0089] like Figure 2 As shown, first, when receiving the code modification submission, the modified code is preprocessed before compilation. First, all code modification points and the code running branch paths involved in the modification content are identified through scanning technology; then, pile-insertion is performed on each branch path, that is, monitoring code is inserted in the key code segment; then, a static point-insertion data table is automatically generated to record the location and related information of all pile-insertion points. After that, the patchbuild version is compiled and generated for test verification. The test methods include manual testing, monkey, unit testing, etc. Whenever a pile-insertion path is executed, the corresponding test point-insertion is found in the global point-insertion data table and marked as passed. All pile-insertion points must be covered to be considered as fully self-tested modification points. After the test is completed, an encrypted point-insertion test pass report is output, which contains the points-insertion of the test path and the timestamp of the test passing.

[0090] The following is a description of the code change test device provided in the embodiment of the present application. The code change test device described below and the code change test method described above can be referred to in correspondence with each other. Figure 3 As shown, the present application provides a code change test device, the device comprising:

[0091] The change code acquisition module 201 is used to acquire the change code and identify the code modification points of the change code and the branch paths corresponding to each code modification point;

[0092] The embedding point data table generating module 202 is used to insert the corresponding embedding point code into each branch path and generate the embedding point data table according to each embedding point code;

[0093] The change code testing module 203 is used to perform a test operation on the change code that has been embedded, and mark the tested embedded code in the embedded data table;

[0094] The test report generation module 204 is used to generate a test report for the changed code when it is determined according to the tracking data table that each tracking code has been tested.

[0095] In one embodiment, the change code acquisition module 201 includes:

[0096] A code modification point determination unit, used for scanning the changed code and determining the code modification point of the changed code;

[0097] The branch path determination unit is used to perform control flow analysis on each code modification point and determine the branch path corresponding to each code point.

[0098] In one embodiment, the embedding data table generation module 202 includes:

[0099] The embedding code insertion unit is used to determine the key code segment in each branch path and add the corresponding embedding code in each key code segment.

[0100] In one embodiment, the embedding data table generation module 202 includes:

[0101] The point-of-entry data table production unit is used to obtain the point-of-entry information of each point-of-entry code and generate a point-of-entry data table using the point-of-entry information.

[0102] In one embodiment, the code change testing module 203 includes:

[0103] The change code test unit is used to compile the embedded change code to generate the corresponding build version and then perform testing operations.

[0104] In one embodiment, the test report generation module 204 includes:

[0105] The code testing unit is changed to determine the coverage of the tracking code after each test operation is completed based on the tested tracking code in the tracking data table. If the tracking code coverage does not reach the preset threshold, the test operation will continue. If the tracking code coverage reaches the preset threshold, it is determined that each tracking code has been tested.

[0106] In one embodiment, the test report generation module 204 includes:

[0107] The test report generation unit is used to obtain the test passing timestamp of each embedded code, and generate a test report of the changed code using an encryption algorithm based on each embedded code and its test passing timestamp.

[0108] In one embodiment, the present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the code change testing method described in any one of the above embodiments.

[0109] In one embodiment, the present application also provides a computer device having computer-readable instructions stored therein. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the code change testing method as described in any one of the above embodiments.

[0110] Indicatively, Figure 4 As shown, Figure 4 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. The computer device 300 may be provided as a server. Figure 4 The computer device 300 includes a processing component 302, which further includes one or more processors, and a memory resource represented by a memory 301 for storing instructions executable by the processing component 302, such as an application. The application stored in the memory 301 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 302 is configured to execute instructions to perform the code change testing method of any of the above embodiments.

[0111] The computer device 300 may further include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate based on an operating system stored in the memory 301, such as Windows Server TM, Mac OS X TM, Unix TM, Linux TM, Free BSD TM, or the like.

[0112] Those skilled in the art will understand that Figure 4The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0113] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only includes those elements, but also includes other elements not clearly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. Herein, "one", "one", "said", "the" and "it" may also include plural forms, unless the context clearly indicates another way. A plurality refers to at least two cases, such as 2, 3, 5 or 8, etc. "And / or" includes any and all combinations of the relevant listed items.

[0114] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0115] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A code change testing method, characterized in that: The method comprises: Acquire the change code, and identify the code modification points of the change code and the branch paths corresponding to each of the code modification points; Inserting a corresponding embedding code into each of the branch paths, and generating an embedding data table according to each of the embedding codes; Performing a test operation on the changed code that has been embedded, and marking the tested embedded code in the embedded data table; When it is determined according to the embedding data table that each embedding code has been tested, a test report of the changed code is generated.

2. The code change testing method according to claim 1, characterized in that: The step of identifying the code modification points of the changed code and the branch paths corresponding to each of the code modification points comprises: Scanning the change code to determine a code modification point of the change code; Control flow analysis is performed on each of the code modification points to determine a branch path corresponding to each of the code points.

3. The code change testing method according to claim 1, characterized in that: The step of inserting the corresponding embedding code into each branch path includes: Determine the key code segment in each of the branch paths, and add corresponding embedding code in each of the key code segments.

4. The code change testing method according to claim 1, characterized in that: The step of generating a buried point data table according to each buried point code comprises: The embedding point information of each embedding point code is obtained, and the embedding point data table is generated using the embedding point information.

5. The code change testing method according to claim 1, characterized in that: The step of performing a test operation on the changed code with embedded points includes: Compile the changed code with embedded points to generate the corresponding build version and then perform testing operations.

6. The code change testing method according to claim 1, characterized in that: The process of determining that each of the burying point codes has been tested according to the burying point data table includes: After each test operation is completed, the buried point code coverage is determined according to the tested buried point code in the buried point data table. If the buried point code coverage does not reach the preset threshold, the test operation is continued. If the buried point code coverage reaches the preset threshold, it is determined that each of the buried point codes has been tested.

7. The code change testing method according to claim 1, characterized in that: The step of generating a test report of the changed code comprises: The test passing timestamp of each of the embedded code is obtained, and based on each of the embedded code and its test passing timestamp, an encryption algorithm is used to generate a test report of the changed code.

8. A code change testing device, characterized in that: The device comprises: A change code acquisition module, used to acquire the change code and identify the code modification points of the change code and the branch paths corresponding to each of the code modification points; A buried point data table generating module, used for inserting a corresponding buried point code into each of the branch paths, and generating a buried point data table according to each of the buried point codes; A change code test module is used to perform a test operation on the change code that has been embedded, and mark the tested embedded code in the embedded data table; A test report generation module is used to generate a test report for the changed code when it is determined according to the burying point data table that each of the burying point codes has been tested.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the code change testing method as described in any one of claims 1 to 7.

10. A computer device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the code change testing method according to any one of claims 1 to 7 are performed.

Images