Test method and device based on code change, equipment and medium

Abstract

The invention discloses a code change-based test method and device, equipment and a medium, and the method comprises the steps: obtaining a to-be-tested code, carrying out the inter-version differentiation analysis of the to-be-tested code, and recognizing a changed target code block in the to-be-tested code; performing test target identification on the target code block, and generating a corresponding unit test case according to an identification result; in response to the increment test instruction, a preset increment execution switch is turned on, and independent execution of the unit test case is controlled through the increment execution switch; and according to an independent execution result of the unit test case, performing statistics according to a preset dimension to obtain a test coverage rate of the target code block. According to the method, the changed part in the code is accurately identified by carrying out differentiation analysis on the code, the corresponding unit test case is generated based on the changed code, and the related case is independently executed, so that automatic unit test is carried out only for the changed code block, the unit test efficiency during code change is improved, and the test efficiency is improved. And the test time and resources are effectively saved.

Description

Technical Field

[0001] The present invention relates to the field of testing technology, and is applied to unit testing scenarios of incremental code of banking systems, and in particular to a testing method, device, equipment and medium based on code changes. Background Art

[0002] As unit testing in the industry has gradually gained attention, in-bank unit testing has experienced explosive growth. However, due to the large number of existing systems and complex business code logic, in the process of promoting the implementation of unit testing, it is necessary to give priority to the coverage of unit tests for incremental code, and then gradually complete the unit test cases for existing code after the incremental coverage is stable.

[0003] However, the unit test coverage of incremental code relies on developers to sort out the scenario logic by themselves and manually write unit test cases for new scenarios, which is cumbersome and inefficient. It consumes a lot of manpower, and the test scope cannot be evaluated. Test omissions may also occur, resulting in incomplete coverage of incremental code. At the same time, for projects that already have a large number of unit test cases, the number of existing unit test cases is large, and the full execution efficiency is low and the time is long, which reduces the efficiency of continuous integration and continuous testing of the project and is not conducive to rapid iteration of the project. Summary of the invention

[0004] In view of the above-mentioned deficiencies in the prior art, the object of the present invention is to provide a code change-based testing method, device, equipment and medium that can be applied to financial technology or other related fields. Its main purpose is to realize the automatic generation and execution of incremental code unit test cases and improve the unit testing efficiency during code changes.

[0005] The technical solution of the present invention is as follows:

[0006] A first aspect of the present invention provides a testing method based on code changes, comprising:

[0007] Obtaining the code to be tested, performing inter-version difference analysis on the code to be tested, and identifying target code blocks with changes in the code to be tested;

[0008] Performing test target identification on the target code block, and generating corresponding unit test cases according to the identification result;

[0009] In response to the incremental test instruction, a preset incremental execution switch is turned on, and the independent execution of the unit test case is controlled by the incremental execution switch;

[0010] The test coverage of the target code block is obtained according to the independent execution results of the unit test cases according to preset dimensions.

[0011] In one embodiment, the step of obtaining the code to be tested, performing version difference analysis on the code to be tested, and identifying a target code block with a change in the code to be tested includes:

[0012] Receive test requirement information, and determine the code range that needs to be tested according to the test requirement information;

[0013] Accessing a code base through a version control system, and pulling corresponding to-be-tested code from the code base according to the code range to be tested;

[0014] Acquire a benchmark code corresponding to the code to be tested according to a preset difference comparison strategy, and perform a difference comparison between the code to be tested and the benchmark code;

[0015] The target code block in which the change exists in the code to be tested is located and obtained according to the difference comparison result.

[0016] In one embodiment, the obtaining of a benchmark code corresponding to the code to be tested according to a preset difference comparison strategy, and performing a difference comparison between the code to be tested and the benchmark code, includes:

[0017] Determine the difference comparison dimension according to the preset difference comparison strategy, where the difference comparison dimension includes commit type and branch version;

[0018] Acquire, in the code base, a code of a specified commit type or a specified branch version according to the difference comparison dimension as a benchmark code corresponding to the code to be tested;

[0019] The code to be tested is compared with the benchmark code in terms of commit ID or branch version.

[0020] In one embodiment, locating and acquiring the target code block having changes in the code to be tested according to the difference comparison result includes:

[0021] Positioning and parsing the difference comparison results to obtain the changed code lines in the code to be tested;

[0022] Performing an invalid change query on the changed code line to confirm whether the changed code line contains invalid changes of a specified type, where the invalid changes of the specified type include spaces, line breaks, and comments;

[0023] The changed code lines are filtered according to the invalid changes found to obtain the target code block.

[0024] In one embodiment, the step of performing test target identification on the target code block and generating corresponding unit test cases according to the identification result includes:

[0025] Compile and package the target code block, and scan the compiled and packaged bytecode to identify the classes and methods that need to be tested in the target code block;

[0026] Generate corresponding unit test cases and test data according to the classes and methods that need to be tested, and automatically mock upstream and downstream data through random seeds.

[0027] In one embodiment, the step of obtaining the test coverage of the target code block according to the independent execution results of the unit test cases according to preset dimensions includes:

[0028] Collect coverage data and generate a coverage report based on the independent execution results of the unit test cases using a preset coverage tool;

[0029] Coloring the coverage report according to the target code block to highlight the coverage data of the target code block;

[0030] Coverage statistics are performed on the coverage data of the target code block according to a preset dimension to obtain the test coverage of the target code block.

[0031] In one embodiment, after obtaining the test coverage of the target code block according to the independent execution results of the unit test cases according to the preset dimensions, the method further includes:

[0032] Comparing the test coverage of the target code block with a preset coverage in the continuous integration pipeline to confirm whether the test coverage of the target code block is greater than or equal to the preset coverage;

[0033] When the test coverage of the target code block is greater than or equal to the preset coverage, the subsequent nodes of the continuous integration pipeline continue to be executed; otherwise, the current test node is interrupted and an interrupt prompt is output.

[0034] A second aspect of the present invention provides a test device based on code change, comprising:

[0035] A difference analysis module is used to obtain the code to be tested, perform difference analysis between versions of the code to be tested, and identify target code blocks with changes in the code to be tested;

[0036] A test case generation module is used to identify the test target of the target code block and generate corresponding unit test cases according to the identification results;

[0037] A case execution module, configured to, in response to an incremental test instruction, turn on a preset incremental execution switch, and control the independent execution of the unit test case through the incremental execution switch;

[0038] The statistical module is used to obtain the test coverage of the target code block according to the independent execution results of the unit test cases according to preset dimensions.

[0039] A third aspect of the present invention provides a computer device, comprising at least one processor; and

[0040] a memory communicatively connected to the at least one processor; wherein,

[0041] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned test method based on code change.

[0042] A fourth aspect of the present invention provides a non-volatile computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by one or more processors, the one or more processors can execute the above-mentioned code change-based testing method.

[0043] Beneficial effects: The present invention discloses a test method, device, equipment and medium based on code changes. Compared with the prior art, the embodiments of the present invention obtain the code to be tested, perform differential analysis between versions on the code to be tested, identify the target code block with changes in the code to be tested; perform test target identification on the target code block, and generate corresponding unit test cases according to the identification results; in response to the incremental test instruction, turn on the preset incremental execution switch, and control the independent execution of the unit test case through the incremental execution switch; and obtain the test coverage of the target code block according to the statistics of the independent execution results of the unit test case according to the preset dimensions. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the places where defects are most likely to be introduced, and generate corresponding unit test cases based on the changed code and execute related cases separately, so as to realize automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the scheme in the present invention, a brief introduction is given below to the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0045] Figure 1A flow chart of a code change-based testing method provided by an embodiment of the present invention;

[0046] Figure 2 A flow chart of step S101 in the code change-based testing method provided in an embodiment of the present invention;

[0047] Figure 3 A flow chart of step S102 in the code change-based testing method provided in an embodiment of the present invention;

[0048] Figure 4 A flow chart of step S104 in the code change-based testing method provided in an embodiment of the present invention;

[0049] Figure 5 A schematic diagram of functional modules of a code change-based testing device provided in an embodiment of the present invention;

[0050] Figure 6 A schematic diagram of the hardware structure of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solution and effect of the present invention clearer and more specific, the present invention is further described in detail below. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. The embodiments of the present invention are described below in conjunction with the accompanying drawings.

[0052] As unit testing in the industry has gradually gained attention, in-bank unit testing has experienced explosive growth. However, due to the large number of existing systems and complex business code logic, in the process of promoting the implementation of unit testing, it is necessary to give priority to the coverage of unit tests for incremental code, and then gradually complete the unit test cases for existing code after the incremental coverage is stable.

[0053] However, the unit test coverage of incremental code relies on developers to sort out the scenario logic by themselves and manually write unit test cases for new scenarios, which is cumbersome and inefficient. It consumes a lot of manpower, and the test scope cannot be evaluated. Test omissions may also occur, resulting in incomplete coverage of incremental code. At the same time, for projects that already have a large number of unit test cases, the number of existing unit test cases is large, and the full execution efficiency is low and the time is long, which reduces the efficiency of continuous integration and continuous testing of the project and is not conducive to rapid iteration of the project.

[0054] In order to solve the above problems, the present invention proposes a testing method based on code changes, please refer to Figure 1 , Figure 1A flowchart of an embodiment of a test method based on code changes provided by the present invention. The system architecture of the test method based on code changes provided in this embodiment may include a first terminal device, a second terminal device, a third terminal device, a network and a server. The network is used to provide a medium for a communication link between the first terminal device, the second terminal device, the third terminal device and the server. The network may include various connection types, such as wired or wireless communication links, etc.

[0055] The user may use the first terminal device, the second terminal device, and the third terminal device to interact with the server through the network to receive or send messages, etc. Various communication client applications may be installed on the first terminal device, the second terminal device, and the third terminal device, such as knowledge reading applications, web browser applications, search applications, instant messaging tools, email clients, or social platform software, etc. (only as examples).

[0056] The first terminal device, the second terminal device, and the third terminal device may be various electronic devices having display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0057] The server may be a server that provides various services, such as a background management server that provides support for the content browsed by the user using the first terminal device, the second terminal device, and the third terminal device (for example only). The background management server may analyze and process the received data such as the user request, and feed back the processing results (such as web pages, information, or data obtained or generated according to the user request) to the terminal device. The server may be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services ("Virtual Private Server", or "VPS" for short). The server may also be a server for a distributed system, or a server combined with a blockchain.

[0058] It should be noted that the code change-based test method provided in the embodiment of the present invention can generally be executed by the first terminal device, the second terminal device or the third terminal device. Correspondingly, the code change-based test device provided in the embodiment of the present invention can also be set in the first terminal device, the second terminal device or the third terminal device.

[0059] Alternatively, the test method based on code changes provided in the embodiment of the present invention may also be generally executed by a server. Accordingly, the test device based on code changes provided in the embodiment of the present invention may generally be arranged in a server. The test method based on code changes provided in the embodiment of the present invention may also be executed by a server or server cluster that is different from the server and can communicate with the first terminal device, the second terminal device, the third terminal device or the server. Accordingly, the test device based on code changes provided in the embodiment of the present invention may also be arranged in a server or server cluster that is different from the server and can communicate with the first terminal device, the second terminal device, the third terminal device or the server.

[0060] It should be understood that the numbers of the above terminal devices, networks and servers are only illustrative. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0061] like Figure 1 As shown, the code change-based testing method provided in this embodiment specifically includes the following steps:

[0062] S101 , obtaining a code to be tested, performing a difference analysis between versions of the code to be tested, and identifying a target code block with a change in the code to be tested.

[0063] In this embodiment, the code to be tested refers to the code that has been developed but has not been verified by the system test. These codes may include newly developed modules, updates or modifications of existing modules, and codes after fixing defects, etc. In the application scenario of the banking system, the code to be tested can be, for example, a new online loan application function has been added to the banking system. This part of the newly written code needs to be tested to ensure that it works as expected; or if the transfer function of the banking system has been optimized, such as increasing the transfer limit or increasing the transfer speed, the modified code also needs to be tested to verify whether the change is correctly implemented; or a bug is found in the account management module of the banking system, such as the account balance is not updated in time. After the developer fixes this problem, the fixed code needs to be tested to ensure that the bug is fixed correctly and no new problems are introduced, etc.

[0064] After code development or modification is completed, the code to be tested is obtained through a version control system (such as Git) for version difference analysis, comparing the differences between the old and new versions of the code, and identifying the target code blocks that have changed in the code to be tested, especially those involving business logic, data access or core algorithms that need to be tested. In this way, when the code changes, the code area that needs to be tested can be quickly located, thereby improving the targetedness of unit testing.

[0065] In one specific implementation, in a banking system scenario, developers have enhanced the functionality of a deposit module of the banking system and submitted code changes. The changed code is obtained through a version control tool as the code to be tested, and a version difference analysis is performed on the code to be tested. For example, a stable baseline version is selected as the starting point for comparison, which can usually be the last released or last tested version. The differences between the baseline version and the code to be tested are compared, and the target code blocks that have been modified, added or deleted in the deposit module are identified. This ensures a thorough and targeted analysis of the changes in the deposit module of the banking system, helps to promptly discover and fix potential problems, and ensures that the changes do not affect the stability and security of the system.

[0066] S102: Perform test target identification on the target code block, and generate corresponding unit test cases according to the identification result.

[0067] In this embodiment, the corresponding unit test cases are automatically generated based on the identified target code block through pre-set intelligent unit test tools, such as Junit, Mockito, EvoSuite or other machine learning-based test case generation tools, etc. Specifically, the business logic and functional requirements of the changed target code block are first analyzed, and then the test target is identified, that is, the test targets in the target code block are determined, such as input verification, boundary conditions, exception handling, etc., and the corresponding unit test cases are automatically generated based on the identified test targets to ensure that each functional point in the changed target code block can be tested and verified, so as to achieve the comprehensiveness of the unit test after the code is modified, achieve the effect of accurate unit testing, and reduce the risk of defects.

[0068] In one specific implementation, in a banking system scenario, developers have enhanced the functionality of a deposit module of the banking system and submitted code changes. Based on the business logic and requirements of the deposit module, including calculation of deposit amounts, updating of account balances, generation of transaction records, etc., test target identification is performed on the target code blocks that have changed, that is, based on business requirements and change points, test targets that need to be verified are determined, such as input verification, boundary conditions, exception handling, performance requirements, etc.; detailed unit test cases are generated and designed based on the test objectives, and each unit test case should include the test purpose: clarifying the functional points to be verified by the test case; input data: defining the input conditions of the test case, including normal and abnormal situations; expected results: clarifying the results that should be achieved after the test case is executed; execution steps: describing how to execute the test case, thereby ensuring that changes to the deposit module of the banking system are fully tested and verified, reducing the risk of introducing defects, and improving code quality and system stability.

[0069] S103 . In response to the incremental test instruction, a preset incremental execution switch is turned on, and the independent execution of the unit test case is controlled by the incremental execution switch.

[0070] In this embodiment, an incremental execution switch is set in a continuous integration (CI) system, such as Jenkins or Travis CI. When it is necessary to execute unit test cases for a target code block, the tester can input an incremental test instruction. After receiving the incremental test instruction, the system responds and turns on a preset incremental execution switch. The switch is used to control the independent execution of unit test cases. That is, when the incremental execution switch is turned on, unit test cases for the changed code are executed separately, so that the relevant test cases are executed separately only when a code change is detected and the incremental test instruction is triggered. The relevant test cases can be executed separately for the changed code without the need for full execution each time, thereby improving the efficiency of continuous integration.

[0071] In one specific implementation, in a banking system scenario, developers have enhanced the functionality of the deposit module of the banking system and submitted code changes. After the target code block of the change has been identified and the corresponding unit test cases have been generated, it is ensured that there is a continuous integration (CI) system (such as Jenkins, CircleCI, GitLab CI, etc.) configured and connected to the version control system. In the configuration file of the CI system, the instructions or conditions for triggering incremental testing are defined, such as a specific commit message, branch name, or a specific pattern of code changes, and an incremental execution switch is set in the CI script to control whether to perform incremental testing. This switch can be turned on or off according to the type or scope of the code change. When the incremental execution switch is turned on when the incremental test instruction is triggered, the CI system will automatically execute the unit test cases related to the changed code block, and only perform unit tests on the changed part of the deposit module, greatly reducing the test execution time, thereby ensuring that the deposit module changes of the banking system receive fast and accurate test feedback, and timely discover and fix problems, thereby maintaining the stability and reliability of the system.

[0072] S104. Obtain the test coverage of the target code block according to the independent execution results of the unit test cases according to preset dimensions.

[0073] In this embodiment, after the unit test case is independently executed, the execution of the test case is monitored by a code coverage tool (such as JaCoCo, Cobertura), and the test coverage of the target code block is obtained according to the preset dimension statistics, including line coverage, branch coverage, etc. For the statistical test coverage, the uncovered code area in the target code block can be further analyzed to supplement the corresponding test case. Through quantified test coverage data, it helps to understand the comprehensiveness of the test, and is conducive to discovering potential test blind spots, further optimizing test cases, and realizing the automatic implementation of the full process of accurate unit testing based on code changes.

[0074] In one specific implementation, in a banking system scenario, when a deposit module of a banking system is changed, the target code block that has been changed has been identified and a unit test case has been generated. After the individual execution is completed, the coverage data of the unit test case execution is automatically collected through the coverage tool pre-integrated in the continuous integration process, such as JaCoCo (Java), Cobertura (multiple languages), Istanbul (JavaScript), etc. The coverage tool can also be used to generate a report to visually display the test coverage. Based on the coverage results, the code areas that may be at risk are determined, which may require more test cases or code refactoring, so as to continuously optimize the test cases and code, and improve the code quality and test reliability.

[0075] In the above embodiment, the present invention discloses a test method based on code changes, which obtains the code to be tested, performs differential analysis between versions on the code to be tested, identifies the target code block with changes in the code to be tested; identifies the test target of the target code block, and generates corresponding unit test cases according to the identification results; in response to the incremental test instruction, turns on the preset incremental execution switch, and controls the independent execution of the unit test case through the incremental execution switch; and obtains the test coverage of the target code block according to the preset dimension statistics based on the independent execution results of the unit test case. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the most likely places to introduce defects, generates corresponding unit test cases based on the changed code, and executes related cases separately, thereby realizing automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources.

[0076] In one embodiment, Figure 2 As shown, step S101 includes:

[0077] S201, receiving test requirement information, and determining a code range to be tested according to the test requirement information;

[0078] S202, accessing a code library through a version control system, and pulling corresponding to-be-tested code from the code library according to the code range to be tested;

[0079] S203, obtaining a reference code corresponding to the code to be tested according to a preset difference comparison strategy, and performing a difference comparison between the code to be tested and the reference code;

[0080] S204: Locate and obtain a target code block having a change in the code to be tested according to the difference comparison result.

[0081] In this embodiment, the tester clarifies the test requirements based on the communication with the developer, including new functions, change points or defects to be repaired, etc., receives the test requirement information input by the tester and analyzes it, determines the code range to be tested, such as the entire project, a specific module or a specific file, etc., for example, it can be a specific functional code module such as deposit, withdrawal, transfer, etc. in the bank system, so as to design the test plan and test cases in a targeted manner. Use a version control system (such as Git) to access the code library of the bank system, and according to the determined test requirements, check out or pull the corresponding branch or submission from the code library to obtain the code to be tested, so as to quickly obtain the code version to be tested, and lay the foundation for subsequent difference comparison and test execution. When performing differential analysis between versions, a baseline code version is determined according to a preset difference comparison strategy, such as the last stable version or the last tested version, etc., and the difference between the code to be tested and the baseline code is obtained through a difference comparison tool (such as git diff), and the specific location of the code change is clearly identified, which provides a basis for determining the test target and designing the test case. By analyzing the difference comparison results, the target code blocks with addition, modification or deletion in the code to be tested are identified, so as to accurately locate the code areas that need to be tested, and improve the pertinence and coverage of the test. This makes the unit testing work more systematic and automated when the code is changed, and at the same time improves the quality and efficiency of the test.

[0082] In one embodiment, step S203 includes:

[0083] Determine the difference comparison dimension according to the preset difference comparison strategy, where the difference comparison dimension includes commit type and branch version;

[0084] Acquire, in the code base, a code of a specified commit type or a specified branch version according to the difference comparison dimension as a benchmark code corresponding to the code to be tested;

[0085] The code to be tested is compared with the benchmark code in terms of commit ID or branch version.

[0086] In this embodiment, the predefined difference comparison strategy determines the dimensions that need to be compared, and the difference comparison dimensions include commit type and branch version, wherein the difference comparison dimension of commit type is used to distinguish between functional submissions, repair submissions or other types of submissions, and the difference comparison dimension of branch version is used to determine whether it is a main branch, a development branch or a specific functional branch, thereby clarifying the difference dimensions that need to be focused on. According to the determined difference comparison dimension, the corresponding benchmark code is queried and obtained in the code library. If the difference comparison is performed by commit type, the latest submission of a specific type can be found through commit ID. If the difference comparison is performed by branch version, a snapshot of the current or specific version of the specified branch can be obtained as the benchmark code corresponding to the code to be tested. Code difference comparison is performed according to commit ID or branch version. If Commit ID difference comparison is performed, the difference between the code to be tested and the code of a specific commit ID is compared. If branch version difference comparison is performed, the difference between the code to be tested and the code of a specific branch version is compared. Through different difference comparison requirements, the target code blocks that need to be changed under the corresponding dimensions need to be accurately identified, which provides a basis for the subsequent test case design and execution, reduces unnecessary test coverage, and allows test resources to be concentrated on where they really need to be tested.

[0087] In one embodiment, step S204 includes:

[0088] Position and analyze the difference comparison results to obtain the changed code lines in the code to be tested;

[0089] Performing an invalid change query on the changed code line to confirm whether the changed code line contains invalid changes of a specified type, where the invalid changes of the specified type include spaces, line breaks, and comments;

[0090] The changed code lines are filtered according to the invalid changes found to obtain the target code block.

[0091] In this embodiment, the difference comparison results are located and analyzed to locate the changed code lines, including newly added, modified or deleted lines, etc. The accuracy of the location analysis can identify the changed code lines and accurately identify which parts of the code have changed, providing specific information for further analysis and testing. At the same time, in order to further improve the efficiency of unit testing, the types of invalid changes are pre-defined, such as changes in spaces, line breaks and comments, which usually do not affect the logic and function of the code. Invalid change queries are performed on the identified changed code lines to confirm whether the changed code lines contain invalid changes of these specified types, avoid including invalid changes in the test scope, reduce unnecessary testing work, and improve the pertinence of the test. Based on the identified invalid changes, these invalid changes are filtered out from the changed code lines, and the changes that actually affect the logic and function of the code are retained, thereby obtaining the final target code block, ensuring that the test cases only target the code changes that actually affect the business logic, reduce the testing of invalid changes, and improve the effectiveness and efficiency of the test.

[0092] In one embodiment, Figure 3 As shown, step S102 includes:

[0093] S301, compile and package the target code block, and scan the compiled and packaged bytecode to identify the class and method that need to be tested in the target code block;

[0094] S302: Generate corresponding unit test cases and test data according to the classes and methods to be tested, and automatically mock upstream and downstream data through random seeds.

[0095] In the present embodiment, the target code block is compiled using a construction tool (such as Maven, Gradle, etc.) to generate an executable bytecode, and the compiled bytecode and all dependencies are packaged into a deployable format, such as a JAR or WAR file. Afterwards, the packaged bytecode is scanned by a static code analysis tool (such as SonarQube, FindBugs, etc.) to identify the classes and methods that need to be tested, including public interfaces, core logic, etc., to ensure that all key classes and methods are identified, and to provide a basis for writing unit test cases. According to the identified classes and methods, a template for a test case is generated using a unit test framework (such as JUnit, TestNG, etc.) or a test case generation tool based on machine learning, and a test data set is defined according to the input parameters and expected behavior of the method, including normal conditions and boundary conditions, and the test cases and test data generated automatically improve the efficiency and coverage of the test. At the same time, automatic mock processing is performed for external dependencies. Mock tools (such as Mockito, EasyMock, etc.) are used to simulate upstream and downstream services and dependencies. Random seeds are used to automatically mock upstream and downstream data, thereby simulating the behavior of external dependencies or upstream and downstream services. In order to test the target code block in an isolated environment, the independence and controllability of the test are ensured.

[0096] In one embodiment, Figure 4 As shown, step S104 includes:

[0097] S401, collecting coverage data and generating a coverage report according to the independent execution results of the unit test cases through a preset coverage tool;

[0098] S402, coloring the coverage report according to the target code block to highlight the coverage data of the target code block;

[0099] S403: Perform coverage statistics on the coverage data of the target code block according to a preset dimension to obtain the test coverage of the target code block.

[0100] In this embodiment, the preset coverage tool can be JaCoCo, Cobertura, etc., which is integrated into the build and test process, and the unit test cases are run. The code execution data in the independent execution process of the unit test cases is automatically collected through the coverage tool, and a detailed coverage report is generated, including line coverage, branch coverage, etc. Since the coverage data collected by the preset coverage tool is the full code coverage, which is not conducive to the coverage statistics of the incremental part, after executing the incremental case, the coverage report is also dyed according to the target code block, and the coverage data of the target code block is highlighted. For example, the dyeing rules are set in the coverage report, such as the uncovered code lines are displayed in red, the partially covered code lines are displayed in yellow, and the fully covered code lines are displayed in green. According to the location of the target code block, the coverage data of these areas are highlighted in the report, and the coverage data of the target code block is quickly identified in a visual way. The coverage data is counted according to preset dimensions (such as packages, classes, methods, lines, etc.), the coverage data of the target code block is summarized, the overall test coverage is calculated, the precise test coverage of the target code block is obtained, and quantitative indicators are provided for test quality and code quality.

[0101] In one embodiment, after step S104, the method further includes:

[0102] Comparing the test coverage of the target code block with a preset coverage in the continuous integration pipeline to confirm whether the test coverage of the target code block is greater than or equal to the preset coverage;

[0103] When the test coverage of the target code block is greater than or equal to the preset coverage, the subsequent nodes of the continuous integration pipeline continue to be executed; otherwise, the current test node is interrupted and an interrupt prompt is output.

[0104] In this embodiment, the test coverage of the target code block is compared with the preset coverage in the continuous integration pipeline, that is, a reasonable minimum coverage threshold is set as the quality red line according to project requirements. The standard is met only when the test coverage is greater than or equal to the minimum coverage threshold. During continuous integration, the coverage result of the target code block is compared with the quality red line to determine whether the coverage meets the standard to determine the direction of the continuous integration pipeline. If the test coverage is greater than or equal to the preset coverage, the continuous integration pipeline will continue to execute subsequent build, test, deployment and other nodes. If the test coverage is lower than the preset coverage, the continuous integration pipeline will be interrupted at the current test node and a clear prompt message will be output to notify relevant personnel, explaining the reason for the interruption and the measures to be taken. Through coverage checking, it is ensured that only code that meets the quality standards can enter the subsequent process, which not only improves the efficiency of continuous integration, but also improves the stability and reliability of the code, and reduces the risk of defects flowing into the production environment.

[0105] It should be noted that there is not necessarily a certain order between the above-mentioned steps. A person skilled in the art can understand, based on the description of the embodiments of the present invention, that in different embodiments, the above-mentioned steps may have different execution orders, that is, they may be executed in parallel, may be executed interchangeably, and so on.

[0106] Further references Figure 5 , as a response to the above Figure 1 The present invention provides an embodiment of a test device based on code change, and the device embodiment is similar to Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0107] like Figure 5 As shown, the code change-based testing device 50 described in this embodiment includes:

[0108] The difference analysis module 501 is used to obtain the code to be tested, perform difference analysis between versions of the code to be tested, and identify the target code blocks with changes in the code to be tested;

[0109] A test case generation module 502 is used to identify the test target of the target code block and generate corresponding unit test cases according to the identification result;

[0110] A case execution module 503, configured to turn on a preset incremental execution switch in response to an incremental test instruction, and control the independent execution of the unit test case through the incremental execution switch;

[0111] The statistical module 504 is used to obtain the test coverage of the target code block according to the independent execution results of the unit test cases according to preset dimensions.

[0112] The module referred to in the present invention refers to a series of computer program instruction segments that can perform specific functions, which is more suitable for describing the test execution process based on code changes than a program. For the specific implementation of each module, please refer to the corresponding method embodiment above, which will not be repeated here.

[0113] In one embodiment, the difference analysis module 501 includes:

[0114] A range confirmation unit, configured to receive test requirement information and determine a code range to be tested according to the test requirement information;

[0115] A code acquisition unit, used to access a code library through a version control system, and pull corresponding to-be-tested code from the code library according to the code range to be tested;

[0116] A difference comparison unit, used for obtaining a reference code corresponding to the code to be tested according to a preset difference comparison strategy, and performing a difference comparison between the code to be tested and the reference code;

[0117] The change locating unit is used to locate and obtain the target code block with changes in the code to be tested according to the difference comparison result.

[0118] In one embodiment, the difference comparison unit includes:

[0119] A dimension determination unit, used to determine a difference comparison dimension according to a preset difference comparison strategy, wherein the difference comparison dimension includes a commit type and a branch version;

[0120] A benchmark code acquisition unit, configured to acquire, in the code base according to the difference comparison dimension, code of a specified commit type or a specified branch version as a benchmark code corresponding to the code to be tested;

[0121] The comparison unit is used to compare the commit ID difference or branch version difference between the code to be tested and the benchmark code.

[0122] In one embodiment, the positioning change unit includes:

[0123] A positioning and analysis unit, used to perform positioning and analysis on the difference comparison result, and obtain the changed code lines in the code to be tested;

[0124] An invalid query unit, used to perform invalid change query on the changed code line to confirm whether the changed code line contains invalid changes of a specified type, where the invalid changes of the specified type include spaces, line breaks and comments;

[0125] The invalid filtering unit is used to filter the changed code lines according to the invalid changes found to obtain the target code block.

[0126] In one embodiment, the use case generation module 502 includes:

[0127] A compiling and scanning unit, used to compile and package the target code block, and scan the compiled and packaged bytecode to identify the classes and methods that need to be tested in the target code block;

[0128] The use case generation unit is used to generate corresponding unit test cases and test data according to the classes and methods that need to be tested, and automatically mock upstream and downstream data through random seeds.

[0129] In one embodiment, the statistics module 504 includes:

[0130] A report generating unit, used for collecting coverage data and generating a coverage report according to the independent execution results of the unit test cases through a preset coverage tool;

[0131] A dyeing unit, used for dyeing the coverage report according to the target code block to highlight the coverage data of the target code block;

[0132] The statistical unit is used to perform coverage statistics on the coverage data of the target code block according to a preset dimension to obtain the test coverage of the target code block.

[0133] In one embodiment, the device 50 further includes:

[0134] A coverage comparison module is used to compare the test coverage of the target code block with a preset coverage in the continuous integration pipeline to confirm whether the test coverage of the target code block is greater than or equal to the preset coverage;

[0135] The node control module is used to continue executing the subsequent nodes of the continuous integration pipeline when the test coverage of the target code block is greater than or equal to the preset coverage; otherwise, the current test node is interrupted and an interrupt prompt is output.

[0136] In the above embodiment, the present invention discloses a test device based on code changes, which obtains the code to be tested, performs differential analysis between versions on the code to be tested, identifies the target code block with changes in the code to be tested; performs test target identification on the target code block, and generates corresponding unit test cases according to the identification results; in response to the incremental test instruction, turns on the preset incremental execution switch, and controls the independent execution of the unit test case through the incremental execution switch; and obtains the test coverage of the target code block according to the preset dimension statistics based on the independent execution results of the unit test case. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the most likely places to introduce defects, generates corresponding unit test cases based on the changed code and executes the related cases separately, thereby realizing automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources.

[0137] Another embodiment of the present invention provides a computer device, such as Figure 6 As shown, the computer device 60 includes:

[0138] One or more processors 601 and memory 602, Figure 6 A processor 601 is used as an example for description. The processor 601 and the memory 602 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0139] Processor 601 is used to complete various control logics of computer device 60, and it can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a single-chip microcomputer, an ARM (Acorn RISC Machine) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component or any combination of these components. In addition, processor 601 can also be any traditional processor, microprocessor or state machine. Processor 601 can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP and / or any other such configuration.

[0140] The memory 602 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions corresponding to the code change-based test method in the embodiment of the present invention. The processor 601 executes various functional applications and data processing of the computer device 60 by running the non-volatile software programs, instructions and units stored in the memory 602, that is, implementing the code change-based test method in the above method embodiment.

[0141] The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device 60, etc. In addition, the memory 602 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 602 may optionally include a memory remotely arranged relative to the processor 601, and these remote memories may be connected to the computer device 60 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. One or more units are stored in the memory 602, and when executed by one or more processors 601, the steps of the test method based on code changes in any of the above-mentioned method embodiments are executed.

[0142] In the above embodiment, the present invention discloses a computer device, which obtains the code to be tested, performs differential analysis between versions on the code to be tested, identifies the target code block with changes in the code to be tested; performs test target identification on the target code block, and generates corresponding unit test cases according to the identification results; in response to the incremental test instruction, turns on the preset incremental execution switch, and controls the independent execution of the unit test case through the incremental execution switch; and obtains the test coverage of the target code block according to the preset dimension statistics based on the independent execution results of the unit test case. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the most likely places to introduce defects, generates corresponding unit test cases based on the changed code and executes related cases separately, thereby realizing automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources.

[0143] An embodiment of the present invention provides a non-volatile computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by one or more processors, the steps of the test method based on code changes in any of the above method embodiments are executed.

[0144] In the above embodiment, the present invention discloses a non-volatile computer-readable storage medium, which obtains the code to be tested, performs differential analysis between versions on the code to be tested, identifies the target code block with changes in the code to be tested; performs test target identification on the target code block, and generates corresponding unit test cases according to the identification results; in response to the incremental test instruction, turns on the preset incremental execution switch, and controls the independent execution of the unit test case through the incremental execution switch; and obtains the test coverage of the target code block according to the preset dimension statistics based on the independent execution results of the unit test case. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the most likely places to introduce defects, generates corresponding unit test cases based on the changed code, and executes related cases separately, thereby realizing automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources.

[0145] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0146] The present invention can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present invention can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present invention can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0147] In summary, the present invention discloses a test method, device, equipment and medium based on code changes, the method includes: obtaining the code to be tested, performing differential analysis between versions on the code to be tested, identifying the target code block with changes in the code to be tested; performing test target identification on the target code block, and generating corresponding unit test cases according to the identification results; in response to the incremental test instruction, turning on the preset incremental execution switch, and controlling the independent execution of the unit test case through the incremental execution switch; and obtaining the test coverage of the target code block according to the preset dimension statistics based on the independent execution results of the unit test case. Through differential analysis between versions, the changed parts of the code can be accurately identified, which helps to concentrate test resources and attention on the most likely places to introduce defects, generate corresponding unit test cases based on the changed code and execute related cases separately, so as to realize automated unit testing only for the changed code blocks, without the need for full execution each time, reducing repeated testing of unchanged code, improving continuous integration efficiency, and improving unit testing efficiency when the code is changed, effectively saving testing time and resources.

[0148] Of course, those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware (such as a processor, a controller, etc.) through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium, and the computer program can include the processes of the above-mentioned method embodiments when executed. The storage medium can be a memory, a disk, a floppy disk, a flash memory, an optical storage device, etc.

[0149] It should be understood that the application of the present invention is not limited to the above examples. For ordinary technicians in this field, improvements or changes can be made based on the above description. All these improvements and changes should fall within the scope of protection of the claims attached to the present invention.

Claims

1. A testing method based on code changes, characterized in that: include: Obtaining the code to be tested, performing inter-version difference analysis on the code to be tested, and identifying target code blocks with changes in the code to be tested; Performing test target identification on the target code block, and generating corresponding unit test cases according to the identification result; In response to the incremental test instruction, a preset incremental execution switch is turned on, and the independent execution of the unit test case is controlled by the incremental execution switch; The test coverage of the target code block is obtained according to the independent execution results of the unit test cases according to preset dimensions.

2. The code change-based testing method according to claim 1, characterized in that: The step of obtaining the code to be tested, performing version difference analysis on the code to be tested, and identifying a target code block with a change in the code to be tested includes: Receive test requirement information, and determine the code range that needs to be tested according to the test requirement information; Accessing a code base through a version control system, and pulling corresponding to-be-tested code from the code base according to the code range to be tested; Acquire a benchmark code corresponding to the code to be tested according to a preset difference comparison strategy, and perform a difference comparison between the code to be tested and the benchmark code; The target code block in which the change exists in the code to be tested is located and obtained according to the difference comparison result.

3. The code change-based testing method according to claim 2, characterized in that: The step of obtaining a reference code corresponding to the code to be tested according to a preset difference comparison strategy, and performing a difference comparison between the code to be tested and the reference code, includes: Determine the difference comparison dimension according to the preset difference comparison strategy, where the difference comparison dimension includes commit type and branch version; Acquire, in the code base, a code of a specified commit type or a specified branch version according to the difference comparison dimension as a benchmark code corresponding to the code to be tested; The code to be tested is compared with the benchmark code in terms of commit ID or branch version.

4. The code change-based testing method according to claim 2, characterized in that: The step of locating and acquiring a target code block having a change in the code to be tested according to the difference comparison result includes: Positioning and parsing the difference comparison results to obtain the changed code lines in the code to be tested; Performing an invalid change query on the changed code line to confirm whether the changed code line contains invalid changes of a specified type, where the invalid changes of the specified type include spaces, line breaks, and comments; The changed code lines are filtered according to the invalid changes found to obtain the target code block.

5. The code change-based testing method according to claim 1, characterized in that: The step of performing test target identification on the target code block and generating corresponding unit test cases according to the identification result includes: Compile and package the target code block, and scan the compiled and packaged bytecode to identify the classes and methods that need to be tested in the target code block; Generate corresponding unit test cases and test data according to the classes and methods that need to be tested, and automatically mock upstream and downstream data through random seeds.

6. The code change-based testing method according to claim 1, characterized in that: The step of obtaining the test coverage of the target code block by statistics according to the independent execution results of the unit test cases according to preset dimensions includes: Collect coverage data and generate a coverage report based on the independent execution results of the unit test cases using a preset coverage tool; Coloring the coverage report according to the target code block to highlight the coverage data of the target code block; Coverage statistics are performed on the coverage data of the target code block according to a preset dimension to obtain the test coverage of the target code block.

7. The code change-based testing method according to claim 1, characterized in that: After obtaining the test coverage of the target code block by statistics according to the independent execution results of the unit test cases according to the preset dimensions, the method further includes: Comparing the test coverage of the target code block with a preset coverage in the continuous integration pipeline to confirm whether the test coverage of the target code block is greater than or equal to the preset coverage; When the test coverage of the target code block is greater than or equal to the preset coverage, the subsequent nodes of the continuous integration pipeline continue to be executed; otherwise, the current test node is interrupted and an interrupt prompt is output.

8. A test device based on code changes, characterized in that: include: A difference analysis module is used to obtain the code to be tested, perform difference analysis between versions of the code to be tested, and identify target code blocks with changes in the code to be tested; A test case generation module is used to identify the test target of the target code block and generate corresponding unit test cases according to the identification results; A case execution module, configured to, in response to an incremental test instruction, turn on a preset incremental execution switch, and control the independent execution of the unit test case through the incremental execution switch; The statistical module is used to obtain the test coverage of the target code block according to the independent execution results of the unit test cases according to preset dimensions.

9. A computer device, characterized in that: comprising 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 code change-based testing method according to any one of claims 1 to 7.

10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by one or more processors, enable the one or more processors to execute the code change-based testing method described in any one of claims 1-7.

Images