Incremental code testing method and device, electronic equipment, storage medium and program product
By integrating a software development and operations toolset pipeline with a code parsing platform, test cases for incremental code are automatically generated and executed, solving the problems of inaccurate test scope and low efficiency in existing technologies, and achieving efficient incremental code testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PEOPLE'S INSURANCE COMPANY OF CHINA
- Filing Date
- 2025-12-23
- Publication Date
- 2026-04-28
AI Technical Summary
In existing technologies, incremental code testing relies on manual selection of test cases, and static analysis tools have difficulty identifying changes in code coverage, resulting in inaccurate test scope and low efficiency.
By integrating software development and operations toolset pipelines with code parsing platforms, software version release parameters are automatically transmitted, differential analysis is performed, test cases are generated using semantic analysis models, and test cases are automatically executed to achieve incremental code testing.
It improves the accuracy and efficiency of the testing scope, ensuring the accuracy of code coverage and the closed-loop nature of test management.
Smart Images
Figure CN121935145A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and in particular to a method, apparatus, electronic device, storage medium, and program product for testing incremental code. Background Technology
[0002] In the field of software development, the code of large systems is frequently updated, and the system version iteration speed is accelerating. The testing team needs to verify the stability of the new version code within a limited time.
[0003] In existing technologies, testing incremental code mainly relies on testers using static analysis tools to identify incremental code regions, manually selecting test cases, and executing tests.
[0004] However, existing testing methods rely on manual selection of test cases, and static analysis tools have difficulty identifying changes in code coverage during the incremental identification process, resulting in inaccurate test scope and reduced test efficiency. Summary of the Invention
[0005] This application provides a method, apparatus, electronic device, storage medium, and program product for testing incremental code, in order to solve the problems of inaccurate testing scope and reduced testing efficiency in the prior art.
[0006] In a first aspect, embodiments of this application provide a method for testing incremental code, including:
[0007] In response to configuration modification operations in the software development and operations toolset pipeline, obtain software version release parameters;
[0008] Call the code parsing platform interface to transmit the software version release parameters to the code parsing platform and generate version data;
[0009] The incremental code is obtained by performing a differential analysis between the version data and historical version data;
[0010] The incremental code is parsed according to a preset semantic analysis model, and test cases for the incremental code are generated.
[0011] Execute the test cases for the incremental code to test the incremental code.
[0012] In one possible implementation, the step of parsing the incremental code according to a preset semantic analysis model and generating test cases for the incremental code includes: obtaining code fragments in the incremental code; performing semantic parsing on the code fragments according to the semantic analysis model to generate code semantic features; filtering test cases in a knowledge base according to the code semantic features to obtain a set of test cases; and determining test cases for the incremental code according to the set of test cases.
[0013] In one possible implementation, before obtaining the code snippets in the incremental code, the process includes: obtaining the function call relationships in the incremental code; creating a code module dependency graph based on the function call relationships; and determining the scope of the incremental code based on the code module dependency graph.
[0014] In one possible implementation, the step of filtering test cases in the knowledge base based on the code semantic features to obtain a test case set includes: matching the code semantic features with the tags and execution history of the test cases to generate a matching result; and prioritizing multiple test cases in the matching result to obtain a test case set.
[0015] In one possible implementation, the step of performing differential analysis on the version data and historical version data to obtain incremental code includes: comparing the version data and historical version data by version number to generate a comparison result; if the version data and historical version data belong to the same version number in the comparison result, then merging the code coverage of the version data and the code coverage of the historical version data to generate a target code coverage; and determining the incremental code based on the target code coverage.
[0016] In one possible implementation, after executing the test cases of the incremental code to test the incremental code, the method further includes: collecting the test results of the test cases executed within a preset test cycle; obtaining the code coverage corresponding to the test results; and generating a test report based on the code coverage and the test results.
[0017] Secondly, embodiments of this application provide a testing apparatus for incremental code, comprising:
[0018] The first acquisition module is used to acquire software version release parameters in response to configuration modification operations in the software development and maintenance toolset pipeline.
[0019] The first generation module is used to call the code parsing platform interface, transmit the software version release parameters to the code parsing platform, and generate version data.
[0020] The differential analysis module is used to perform differential analysis between the version data and historical version data to obtain incremental code;
[0021] The parsing module is used to parse the incremental code according to a preset semantic analysis model and generate test cases for the incremental code.
[0022] The execution module is used to execute the test cases of the incremental code to implement the testing of the incremental code.
[0023] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;
[0024] The memory stores computer-executed instructions;
[0025] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.
[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.
[0027] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0028] The incremental code testing method, apparatus, electronic device, storage medium, and program product provided in this application integrate the interface of the software development and maintenance toolset pipeline with the code parsing platform to automate the transmission of software version release parameters. When the pipeline configuration is modified, the software version release parameters are obtained, the code parsing platform interface is called, the software version release parameters are transmitted to the platform, version data is generated, and differential analysis is performed on the version data and historical version data to obtain incremental code, which improves the accuracy of the code testing scope. The semantic analysis model is called to automatically parse the incremental code to match test cases, and the test cases are automatically executed to test the incremental code, thereby improving testing efficiency. Attached Figure Description
[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0030] Figure 1 This is a schematic diagram of the system structure of a computer device provided in an embodiment of this application;
[0031] Figure 2 A flowchart illustrating the testing method for the incremental code provided in this application. Figure 1 ;
[0032] Figure 3 A flowchart illustrating the testing method for the incremental code provided in this application. Figure 2 ;
[0033] Figure 4 A schematic diagram of the test apparatus for the incremental code provided in this application;
[0034] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.
[0035] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0037] First, let me explain the terms used in this application:
[0038] Software development and operations toolset pipeline: refers to a collection of automated steps that connect the entire process of code from version control repository to final deployment to production environment, enabling fast, reliable and frequent software delivery. It is equivalent to a software "assembly pipeline". The input is code changes submitted by developers, and after a series of automated processes (such as building, testing, deployment, etc.), the output is a new version of software that is usable and running in the production environment.
[0039] In the field of software development, large systems experience frequent code updates and rapid version iterations, requiring testing teams to verify the stability of new code versions within a limited timeframe. Current technologies primarily rely on testers using static analysis tools to identify incremental code regions, manually selecting test cases, and executing them. However, existing testing methods depend on manual test case selection, and static analysis tools struggle to identify changes in code coverage during the incremental identification process, leading to inaccurate test scope and reduced testing efficiency.
[0040] To address the aforementioned technical problems, this application proposes the following technical concept: The inventors considered integrating the interface of the software development and maintenance toolset pipeline with the code parsing platform to automate the transmission of software version release parameters. When the pipeline configuration is modified, the software version release parameters are obtained and transmitted to the code parsing platform to generate version data. Differential analysis is performed on historical version data and version data to obtain incremental code. Considering the use of a semantic analysis model to parse the incremental code and generate test cases, the accuracy of the test scope is improved.
[0041] Figure 1 This is a schematic diagram of the system architecture of a computer device provided in an embodiment of this application. Figure 1 As shown, the computer device includes: a receiving device 101, a processing device 102, and a display device 103.
[0042] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the testing method for incremental code. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.
[0043] In the specific implementation process, the receiving device 101 can be an input / output interface or a communication interface, which can obtain software version release parameters.
[0044] The processing unit 102 can generate test cases for incremental code.
[0045] The display device 103 can be used to display test cases, etc., of the aforementioned incremental code.
[0046] The display device can also be a touch screen, used to receive user commands while displaying the above content, so as to realize the operation interaction with the user.
[0047] It should be understood that the above-mentioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.
[0048] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0049] Figure 2 A flowchart illustrating the testing method for the incremental code provided in this application. Figure 1 ,like Figure 2 As shown, the method includes:
[0050] S201: In response to configuration modification operations in the software development and operations toolset pipeline, obtain software version release parameters.
[0051] In this embodiment, the software development and operations toolset pipeline is a DevOps pipeline.
[0052] In this embodiment, the software version release parameters include, but are not limited to, the code repository address, the code pull flag, and the deployment number.
[0053] Specifically, when a developer modifies the configuration of the version build phase in the DevOps pipeline task on the graphical interface, the modification will trigger a configuration update event. The pipeline engine's configuration monitor captures the event and executes the associated script to obtain the software version release parameters.
[0054] S202: Call the code parsing platform interface to transmit the software version release parameters to the code parsing platform and generate version data.
[0055] Specifically, a call request is generated and transmitted to the code parsing platform via the code parsing platform interface. The code parsing platform pulls the source code from the version control repository, performs code analysis, packages the source code, analysis results, and version parameters into a structured data package, and generates the corresponding data ID.
[0056] S203: Perform differential analysis between version data and historical version data to obtain incremental code.
[0057] Specifically, the version data is compared with the historical version data by version number. If they belong to the same version number, the code coverage is merged to generate the target code coverage. The incremental code is then determined based on the generated target code coverage.
[0058] S204: Parse the incremental code according to the preset semantic analysis model and generate test cases for the incremental code.
[0059] Specifically, code snippets are obtained from the incremental code, a semantic analysis model is called to perform semantic parsing on the code snippets, test cases are selected based on the semantic features of the code, and test cases for the incremental code are determined.
[0060] S205: Execute test cases for incremental code to perform incremental code testing.
[0061] Specifically, the test execution phase of the pipeline takes over the work. The test executor obtains the generated test case list from the semantic analysis service, converts it into a script that the test framework can recognize, and executes it in parallel in an isolated environment.
[0062] As can be seen from the above embodiments, by integrating the software development and maintenance toolset pipeline with the code parsing platform interface, the automated transmission of software version release parameters is achieved. When the pipeline configuration is modified, the software version release parameters are obtained, the code parsing platform interface is called, the software version release parameters are transmitted to the platform, version data is generated, and differential analysis is performed on the version data and historical version data to obtain incremental code, which improves the accuracy of the code testing scope. The semantic analysis model is called to automatically parse the incremental code and match test cases, and the test cases are automatically executed to test the incremental code, thereby improving testing efficiency.
[0063] In one embodiment of this application, step S204 includes:
[0064] S2041: Retrieve code snippets from incremental code.
[0065] Specifically, the code snippet extractor processes the received incremental code change set, cutting each changed method body and its immediate context into independent code snippets.
[0066] In this embodiment, the content recorded in the code snippet includes, but is not limited to, file path, method signature, and change type.
[0067] S2042: Perform semantic parsing on code fragments based on the semantic analysis model to generate code semantic features.
[0068] Specifically, the inference API interface of the semantic analysis model is called. The model receives a code snippet as input, which is processed by the encoder and attention mechanism to output a high-level semantic understanding of the snippet.
[0069] S2043: Filter test cases from the knowledge base based on code semantic features to obtain a test case collection.
[0070] Specifically, the test case tags and execution history are matched based on the semantic features of the code to generate matching results. Multiple test cases in the matching results are prioritized to obtain a set of test cases.
[0071] S2044: Determine the test cases for the incremental code based on the test case collection.
[0072] Specifically, the test case optimizer optimizes the initial set of test cases, eliminates redundant or overly broad test cases based on the scope of the change, and performs parameterized adaptation on some common test cases to determine the test cases for the incremental code.
[0073] As can be seen from the above embodiments, through semantic parsing and knowledge base matching mechanisms, the business intent of incremental code is directly associated with the logic of test cases through semantic parsing, avoiding matching deviations caused by missing code comments or ambiguous terms.
[0074] Figure 3 A flowchart illustrating the testing method for the incremental code provided in this application. Figure 2 ,like Figure 3 As shown, the procedure before step S2041 also includes:
[0075] S301: Obtain the function call relationships in the incremental code.
[0076] Specifically, code analysis tools are invoked to analyze the entire project codebase, construct the project's global abstract syntax tree and control flow diagram, and extract the call and called relationships between functions.
[0077] S302: Create a code module dependency graph based on function call relationships.
[0078] Specifically, the graph construction module constructs a code module dependency graph based on function call relationships, using code modules or key classes as nodes and dependencies between modules or classes as edges. The code module dependency graph visualizes other code areas that changes may involve through interface calls, inheritance, or composition.
[0079] S303: Determine the scope of incremental code based on the code module dependency graph.
[0080] Specifically, the analyzer uses the initial module that underwent the change as the root node and traverses the graph to a finite depth, marking all modules visited during the traversal as potentially affected areas. The entire source code contained in the marked modules collectively constitutes the expanded incremental code scope.
[0081] As can be seen from the above embodiments, by obtaining the function call relationships in the incremental code, a code module dependency graph is created based on the call relationships. The scope of the incremental code is expanded through the module dependency graph, avoiding test omissions caused by the complexity of the call relationships between modules.
[0082] In one embodiment of this application, step S2043 includes:
[0083] S431: Match the code semantic features with the test case tags and execution history to generate matching results.
[0084] Specifically, the intelligent search engine executes a multi-dimensional matching algorithm to calculate the similarity between the code's semantic feature vector and the tag vector of each test case. Simultaneously, the algorithm incorporates execution history as a tuning factor; for example, test cases that have recently failed frequently, or those that have historically effectively captured similar code defects, are given higher weight. After comprehensive calculation, a matching result entry containing a matching score and a recommendation reason is generated for each candidate test case.
[0085] S432: Prioritize multiple test cases in the matching results to obtain a set of test cases.
[0086] Specifically, the priority scheduler processes the matching result list, sorting it in descending order according to the overall matching score. For test cases with similar scores, a secondary sorting rule is applied: prioritizing test cases with shorter execution times to improve feedback speed; and prioritizing test cases that have not been executed recently to ensure the freshness of test coverage. After multi-level sorting, the final ordered list is the set of test cases optimized according to test value and execution efficiency.
[0087] As can be seen from the above embodiments, by using a multi-dimensional matching mechanism, test cases are matched based on semantic features, and the matched test cases are sorted from high to low priority to obtain a set of test cases, thus avoiding omission of test points.
[0088] In one embodiment of this application, step S203 includes:
[0089] S2031: Compare the version data with historical version data by version number and generate comparison results.
[0090] Specifically, the version comparator reads the semantic version number defined in the current version data packet and the version number of the specified baseline historical version data. The comparator parses the major version number, minor version number, and revision number, and generates a structured comparison result.
[0091] S2032: If the version data and historical version data belong to the same version number in the comparison results, then the code coverage of the version data and the code coverage of the historical version data are merged to generate the target code coverage.
[0092] Specifically, when the comparison results determine that two versions belong to the same major version number, the coverage merging logic is triggered. This logic extracts the line coverage or branch coverage dataset from the test history reports associated with the two versions. The merger performs a logical "union" operation on these two datasets to obtain a merged coverage set, i.e., the target code coverage. This set represents all lines of code that have been covered by tests up to the current version.
[0093] S2033: Determine incremental code based on target code coverage.
[0094] Specifically, the set of original code change lines obtained from code difference analysis is compared with the target code coverage set to identify code lines that have been changed but are not within the target code coverage. These code lines are defined as incremental code that requires the highest priority testing.
[0095] As can be seen from the above embodiments, by continuously collecting and merging version numbers, dynamic monitoring of coverage data is achieved, and the code coverage of the same version is automatically classified to ensure the accuracy of coverage data.
[0096] In one embodiment of this application, after step S205, the method further includes:
[0097] S206: Collect the test results of the test cases executed within the preset test cycle.
[0098] Specifically, the pipeline's test result aggregator automatically collects detailed test results of all executed test cases within a preset test cycle from the log storage of the distributed test executor.
[0099] In this embodiment, the test results include, but are not limited to, test case ID, status, duration, error information, and associated test environment information.
[0100] S207: Obtain the code coverage corresponding to the test results.
[0101] Specifically, while the test is being executed, a code coverage collection agent runs in the test environment. This agent uses bytecode instrumentation or runtime monitoring technology to record in real time which lines of source code and branches are executed by the test.
[0102] Specifically, after the test is completed, the agent uploads the raw coverage data to the coverage analysis service. The coverage analysis service processes the data and binds it to the pipeline run ID to generate a visual code coverage report.
[0103] S208: Generate a test report based on code coverage and test results.
[0104] Specifically, the report generation service is triggered to integrate test result summary data and code coverage report, and automatically generate a structured comprehensive test report based on a configurable template.
[0105] In this embodiment, the test report records, but is not limited to, a test execution summary, root cause analysis of failed test cases, code coverage of this build, trend comparison with historical data, and suggested follow-up action strategies.
[0106] As can be seen from the above embodiments, by automatically collecting test results within the test cycle and generating test coverage reports based on code coverage and test results, closed-loop management of the test process is achieved, thereby improving test management efficiency.
[0107] Figure 4 A schematic diagram of the test apparatus for the incremental code provided in this application is shown below. Figure 4As shown, the incremental code testing device 40 provided in this embodiment includes: a first acquisition module 401, a first generation module 402, a differential analysis module 403, a parsing module 404, and an execution module 405.
[0108] The first acquisition module 401 is used to acquire software version release parameters in response to configuration modification operations in the software development and maintenance toolset pipeline.
[0109] The first generation module 402 is used to call the code parsing platform interface, transmit the software version release parameters to the code parsing platform, and generate version data.
[0110] The differential analysis module 403 is used to perform differential analysis between version data and historical version data to obtain incremental code.
[0111] The parsing module 404 is used to parse the incremental code according to the preset semantic analysis model and generate test cases for the incremental code.
[0112] Execution module 405 is used to execute test cases for incremental code in order to test the incremental code.
[0113] In one possible implementation, the parsing module 404 includes:
[0114] The first acquisition unit is used to acquire code snippets from the incremental code.
[0115] The parsing unit is used to perform semantic parsing on code fragments based on the semantic analysis model and generate code semantic features.
[0116] The filtering unit is used to filter test cases in the knowledge base based on the semantic features of the code, so as to obtain a set of test cases.
[0117] The first determining unit is used to determine the test cases for the incremental code based on the test case set.
[0118] In one possible implementation, the parsing module 404 further includes:
[0119] The second acquisition unit is used to acquire the function call relationships in the incremental code.
[0120] Create a unit to generate a code module dependency graph based on function call relationships.
[0121] The second determining unit is used to determine the incremental code range based on the code module dependency graph.
[0122] In one possible implementation, the screening unit includes:
[0123] The matching subunit is used to match code semantic features with test case tags and execution history to generate matching results.
[0124] The sorting subunit is used to prioritize multiple test cases in the matching results to obtain a set of test cases.
[0125] In one possible implementation, the differentiation analysis module 403 includes:
[0126] The comparison unit is used to compare the version data with historical version data by version number and generate comparison results.
[0127] The merging unit is used to merge the code coverage of the version data and the code coverage of the historical version data if the version data and the historical version data belong to the same version number in the comparison results, and generate the target code coverage.
[0128] The third determining unit is used to determine incremental code based on the target code coverage.
[0129] In one embodiment of this application, the incremental code testing device 40 further includes:
[0130] The data acquisition module is used to collect the test results of test cases executed within a preset test cycle.
[0131] The second acquisition module is used to obtain the code coverage corresponding to the test results.
[0132] The second generation module is used to generate test reports based on code coverage and test results.
[0133] The incremental code testing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0134] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.
[0135] In the specific implementation process, at least one processor 501 executes the computer execution instructions stored in memory 502, causing at least one processor 501 to execute the above-mentioned incremental code test method.
[0136] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0137] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0138] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0139] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0140] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the test method for the incremental code described above.
[0141] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described incremental code testing method.
[0142] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0143] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0144] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.
[0146] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0147] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0148] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0149] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A method for testing incremental code, characterized in that, include: In response to configuration modification operations in the software development and operations toolset pipeline, obtain software version release parameters; Call the code parsing platform interface to transmit the software version release parameters to the code parsing platform and generate version data; The incremental code is obtained by performing a differential analysis between the version data and historical version data; The incremental code is parsed according to a preset semantic analysis model, and test cases for the incremental code are generated. Execute the test cases for the incremental code to test the incremental code.
2. The method according to claim 1, characterized in that, The step of parsing the incremental code according to a preset semantic analysis model and generating test cases for the incremental code includes: Retrieve code snippets from incremental code; The code fragment is semantically parsed based on the semantic analysis model to generate semantic features of the code. Test cases are filtered from the knowledge base based on the semantic features of the code to obtain a set of test cases; The test cases for the incremental code are determined based on the aforementioned set of test cases.
3. The method according to claim 2, characterized in that, Before obtaining the code snippet from the incremental code, the following steps are included: Obtain the function call relationships in the incremental code; Create a code module dependency graph based on the function call relationships; The incremental code range is determined based on the code module dependency graph.
4. The method according to claim 2, characterized in that, The step of filtering test cases from the knowledge base based on the semantic features of the code to obtain a set of test cases includes: The matching results are generated by matching the semantic features of the code with the tags and execution history of the test cases; The test cases in the matching results are sorted by priority to obtain a set of test cases.
5. The method according to claim 1, characterized in that, The step of performing differential analysis between the version data and historical version data to obtain incremental code includes: The version data is compared with historical version data by version number to generate a comparison result; If the version data and the historical version data belong to the same version number in the comparison results, then the code coverage of the version data and the code coverage of the historical version data are merged to generate the target code coverage. Incremental code is determined based on target code coverage.
6. The method according to claims 1 to 5, characterized in that, After executing the test cases for the incremental code to test the incremental code, the method further includes: The test results of the test cases executed within the preset test cycle are collected. Obtain the code coverage corresponding to the test results; A test report is generated based on the code coverage and the test results.
7. A testing device for incremental code, characterized in that, include: The first acquisition module is used to acquire software version release parameters in response to configuration modification operations in the software development and maintenance toolset pipeline. The first generation module is used to call the code parsing platform interface, transmit the software version release parameters to the code parsing platform, and generate version data. The differential analysis module is used to perform differential analysis between the version data and historical version data to obtain incremental code; The parsing module is used to parse the incremental code according to a preset semantic analysis model and generate test cases for the incremental code. The execution module is used to execute the test cases of the incremental code to implement the testing of the incremental code.
8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the test method for incremental code as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the test method for incremental code as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the test method of the incremental code as described in any one of claims 1 to 6.