Test case determination method and device, computer readable storage medium and processor

Abstract

The invention discloses a test case determination method and device, a computer readable storage medium and a processor. The method comprises the following steps: identifying a source code of software by utilizing a pre-trained large model to obtain a plurality of functional modules in the software and a dependency relationship among the plurality of functional modules; in response to updating of the source code of the software, determining a code updating part in the source code; determining a test case matched with the code updating part from a test case library of the software based on the code updating part and a dependency relationship among the plurality of functional modules, the test case being used for testing the code updating part; based on a test result of the test case, adjusting a selection strategy of the test case; and re-determining the test case for testing the code updating part based on the adjusted selection strategy of the test case. The technical problem that a traditional regression test strategy is low in test efficiency is solved.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and in particular to a method, device, computer-readable storage medium and processor for determining a test case. Background Art

[0002] In the field of software engineering, regression testing is a crucial quality assurance practice, especially in the environment of continuous integration and iterative development of software. Regression testing aims to verify whether the existing functions are still correct after the software is modified or updated. Traditional regression testing methods often rely on completely repeating all test cases, which is inefficient and resource-intensive when the software is large in scale and has many functional modules. With the increase in the complexity and iteration speed of software projects. Traditional regression testing strategies have the technical problem of low testing efficiency.

[0003] With respect to the technical problem that the traditional regression testing strategy has low testing efficiency, no effective solution has been proposed so far. Summary of the invention

[0004] The embodiments of the present invention provide a method, device, computer-readable storage medium and processor for determining a test case, so as to at least solve the technical problem of low test efficiency of a traditional regression test strategy.

[0005] According to one aspect of an embodiment of the present invention, a method for determining a test case is provided. The method may include: using a pre-trained large model to identify the source code of the software, and obtaining multiple functional modules in the software and the dependencies between the multiple functional modules; in response to the source code of the software being updated, determining the code update part in the source code; based on the code update part and the dependencies between the multiple functional modules, determining a test case matching the code update part from a test case library of the software, wherein the test case is used to test the code update part; based on the test results of the test case, adjusting the selection strategy of the test case; based on the adjusted test case selection strategy, re-determining the test case for testing the code update part.

[0006] Optionally, a pre-trained large model is used to identify the source code of the software to obtain multiple functional modules in the software and the dependencies between the multiple functional modules, including: using the large model to perform deep semantic analysis on the source code of the software to obtain analysis results; based on the analysis results, dividing the source code into multiple functional modules; based on the analysis results, determining the dependencies between the multiple functional modules.

[0007] Optionally, the method further comprises: generating a module dependency graph based on dependency relationships among the plurality of functional modules, wherein the module dependency graph is used to at least represent the calling relationships among the plurality of functional modules.

[0008] Optionally, based on the code update part and the dependency relationship between multiple functional modules, a test case matching the code update part is determined from a test case library of the software, including: determining the degree of influence of the code change part on the multiple functional modules based on a module dependency graph and a call chain between multiple functional modules; based on the degree of influence of the code change part on the multiple functional modules and the dependency relationship between the multiple functional modules, determining at least one test case matching the code change part from the test case library of the software.

[0009] Optionally, the method also includes: performing a risk assessment on the code change part to obtain a risk assessment result; determining the priority of at least one test case based on the risk assessment result and the coverage of at least one test case; and executing at least one test case based on the priority to test the code update part.

[0010] Optionally, based on the test results of the test cases, a test case selection strategy is adjusted, including: comparing the test results with expected results to obtain a comparison result, wherein the comparison result is used to indicate the pass status of the test case execution, defect location information and test coverage, and the effectiveness of the test case for code change detection; based on the pass status of the test case execution, defect location information and test coverage in the comparison result, and the effectiveness of the test case for code change detection, the test case selection strategy is adjusted; the method also includes: based on the adjusted selection strategy, redetermining the test cases that match the code update part in the test case library of the software.

[0011] According to another aspect of an embodiment of the present invention, a device for determining a test case is also provided. The device may include: an identification unit, which is used to identify the source code of the software using a pre-trained large model to obtain multiple functional modules in the software and the dependencies between the multiple functional modules; a first determination unit, which is used to determine the code update part in the source code in response to the source code of the software being updated; a second determination unit, which is used to determine the test case matching the code update part from the test case library of the software based on the code update part and the dependencies between the multiple functional modules, wherein the test case is used to test the code update part; an adjustment unit, which is used to adjust the selection strategy of the test case based on the test result of the test case; and a third determination unit, which is used to re-determine the test case for testing the code update part based on the adjusted test case selection strategy.

[0012] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein when the program is executed by a processor, the device where the storage medium is located is controlled to execute the method for determining the test case in the embodiment of the present invention.

[0013] According to another aspect of an embodiment of the present invention, a processor is further provided, wherein the processor is used to run a program, wherein the method for determining a test case in an embodiment of the present invention is executed when the program is run.

[0014] According to another aspect of the embodiment of the present invention, a computer program product is provided, which includes computer instructions, and when the computer instructions are executed by a processor, the method for determining a test case in the embodiment of the present invention is implemented.

[0015] In an embodiment of the present invention, by performing deep semantic analysis on the source code through a pre-trained large model, each functional module in the software and the complex dependencies between these modules can be accurately identified and extracted. When the software source code is updated, the system can quickly detect the code change part, and based on the understanding ability of the large model, intelligently evaluate the impact of the change, so as to quickly filter out the most relevant test cases from the test case library. Based on the test results of the test case, the system can dynamically adjust the selection strategy of the test case, continuously learn and optimize, and ensure that the test strategy always maintains high efficiency and accuracy during the iteration process of the software. This continuous learning mechanism helps to improve the intelligent matching ability of the large model, making the selection of test cases more accurate and covering more comprehensive. By determining the test case through deep semantic analysis, intelligent matching and dynamic learning mechanism, the determined test case can be matched with the code change part, thereby improving the efficiency and accuracy of software regression testing, which plays an important role in accelerating the software development process, controlling testing costs, and improving software quality, especially when dealing with large and complex software projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0017] Figure 1 is a flow chart of a method for determining a test case according to an embodiment of the present invention;

[0018] Figure 2 is a schematic diagram of a large model module division according to an embodiment of the present invention;

[0019] Figure 3 is a schematic diagram of a code change analysis according to an embodiment of the present invention;

[0020] Figure 4 is a schematic diagram of intelligent test case matching according to an embodiment of the present invention;

[0021] Figure 5is a schematic diagram of a device for determining a test case according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, functional component or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, functional components or devices.

[0024] According to an embodiment of the present invention, an embodiment of a method for determining a test case is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0025] Figure 1 is a flow chart of a method for determining a test case according to an embodiment of the present invention. The method can be used in a regression test process of software during software development, such as Figure 1 As shown, the method may include the following steps:

[0026] Step S101, using a pre-trained large model to identify the source code of the software, and obtain multiple functional modules in the software and the dependencies between the multiple functional modules.

[0027] In the technical solution provided in the above step S101 of the present invention, the pre-trained large model can be a Transformer architecture, and the large model has been pre-trained on large-scale code and text data and has the ability to understand code structure, logic and semantics.

[0028] In this embodiment, a pre-trained large model is used to perform in-depth semantic analysis on the source code of the software, extract basic code elements such as functions, classes, and methods, and construct a structured representation of the code, such as an Abstract Syntax Tree (AST).

[0029] Optionally, after determining the structured representation of the source code, the large model can identify and divide multiple logical functional modules in the software according to the structured representation of the source code.

[0030] Optionally, the large model further analyzes the dependencies between these identified functional modules, wherein the dependencies between the functional modules include but are not limited to: call relationships, data flow dependencies, interface and interface dependencies, control flow dependencies, etc., which are not specifically limited here.

[0031] Optionally, for call relationships, you can identify which modules directly call functions or methods in other modules to form a call chain. For data flow dependencies, you can track the transfer path of data or variables between modules, including input and output parameters, and data interaction between the module and the outside; for interface and interface dependencies, you can analyze the dependencies between modules that communicate through defined interfaces, including application programming interface (API) calls, message passing, etc.; for control flow dependencies, you can determine how control logic is propagated between modules, such as conditional judgment, loop control, etc.

[0032] In this step, by identifying multiple functional modules in the software and the dependencies between multiple functional modules, the large model can generate a detailed module dependency graph, clearly showing the relationships and dependencies between different functional modules, and providing basic data for subsequent code change analysis and test case matching. Among them, the module dependency graph not only captures direct call relationships, but more importantly, it can reflect indirect, cross-module functional dependencies, thereby providing a comprehensive and accurate perspective for intelligent test case screening.

[0033] Step S102: in response to the source code of the software being updated, determining a code update portion in the source code.

[0034] In the technical solution provided in the above step S102 of the present invention, when the software development team modifies, adds or deletes the source code (ie, updates the source code), the system automatically triggers the code update detection mechanism.

[0035] In this embodiment, for the code of the newly added functional module, newly introduced code segments can be detected, which may contain new functional implementations, algorithm designs or external interface calls. For the modified existing code, by comparing the code version differences, it is determined which existing code lines are modified, and these modifications may involve functional logic adjustments, error corrections or performance optimizations; for the deleted code, by identifying and recording the deleted code segments, it may be because of the abandonment of functions, the cleaning of code redundancy or the enhancement of security.

[0036] Optionally, after determining the updated code parts, this information is passed to the big model in the subsequent steps for detailed analysis, including understanding the semantics of the change (i.e., functional impact), analyzing dependencies between modules, and evaluating the potential risks of the change. This information is the basis for intelligent test case screening and prioritization, ensuring that the test process can focus resources on testing the parts most affected by the change, thereby improving the efficiency and accuracy of regression testing.

[0037] Step S103: Based on the code update part and the dependency relationship between the multiple functional modules, determine the test case matching the code update part from the test case library of the software.

[0038] In the technical solution provided by the above step S103 of the present invention, after the code update part is determined by step S102, the test case matching the code update part can be determined from the test case library of the software according to the dependency relationship between the code update part and multiple functional modules.

[0039] In this embodiment, based on the obtained results of source code module division and code change analysis, a group of test cases most relevant to the code update part is intelligently screened out from the test case library of the software.

[0040] For example, we first need to identify the updated code, that is, the newly added, deleted, or modified code segments. Then, we use the code change analysis capabilities of the large model to evaluate the impact of these change points on each functional module in the software, including the impact of the direct call chain and the impact of indirect dependencies. After that, we build an impact matrix to represent the impact of the code update on each functional module. This impact matrix is ​​based on the module dependency graph, calculates the direct and indirect impact weights between the change points and the modules, and clearly shows which modules need to be retested.

[0041] Optionally, based on the impact matrix, the test cases most relevant to the code update are intelligently matched. The intelligent matching algorithm used here not only considers the functional coverage of the test cases, but also combines the dependencies between modules to give priority to those test cases that can cover the impact scope of the change.

[0042] Optionally, prioritize the matched test cases, and generate an optimized test case execution plan based on the change risk assessment results, test case coverage, and previous test case execution history to ensure adequate testing of high-risk areas. After that, output a set of test cases that match the updated code, as well as a detailed test case execution plan, including information such as the test case ID, functional description, execution order, and expected results.

[0043] In this step, after the software is updated, the set of test cases that need to be executed can be quickly and intelligently screened, which significantly improves the efficiency and pertinence of regression testing. The intelligent matching of test cases not only considers the direct impact of code changes, but also integrates the complex dependencies between modules, ensuring the comprehensiveness of test coverage and the stability of software quality.

[0044] Step S104: adjusting the test case selection strategy based on the test result of the test case.

[0045] In the technical solution provided in the above step S104 of the present invention, after executing a specific test case, the actual test result can be compared with the expected result to analyze the effectiveness and coverage of the test result, and then the test case selection strategy can be adjusted according to the test result.

[0046] In this embodiment, it is determined whether the test case can accurately detect new defects introduced after the software change or the functional problems affected. If the test case fails to find any defects, but the changed part does introduce problems, this indicates that the test case may need more comprehensive coverage or more accurate matching.

[0047] Optionally, evaluate the coverage of test cases for software functional modules and code change points to ensure that the changed parts are fully tested. If it is found that some functional modules or change points are not covered, the system will consider adding tests covering these areas in future test case selection.

[0048] Optionally, the execution time and required resources of the test cases are analyzed to evaluate their cost-benefit ratio. For test cases with high execution cost but limited coverage, the system may consider optimizing its execution strategy or finding alternative cases.

[0049] Optionally, the frequency and severity of defects detected by test cases after software changes are statistically analyzed to provide a basis for risk assessment for subsequent test case selection. Based on the analysis of the above test results, the test case selection strategy is adjusted.

[0050] Optionally, based on the performance of the test cases, their selection algorithm will be optimized, such as increasing the priority of test cases that detect defects, reducing the frequency of test cases that fail to find any problems, or introducing new test cases to fill in coverage blind spots.

[0051] Optionally, using test result feedback, continuously learn and adjust the parameters of the large model so that it can more accurately predict the impact of code changes on software functions, thereby improving the accuracy of test case screening. Based on the test results, update the test case library, delete or modify inefficient test cases, and add new test cases to enhance the testing capabilities of specific functional modules. The system may need to expand or refine its test case coverage to ensure that all key functional modules and change points can be fully tested.

[0052] In this step, continuous optimization of intelligent test case screening can be achieved to ensure that during the software life cycle, the testing process can adapt to the needs of rapid iteration and functional changes, and continuously improve the efficiency of regression testing and the accuracy of software quality control.

[0053] Step S105 , based on the adjusted test case selection strategy, re-determine the test case for testing the code update part.

[0054] In the technical solution provided in the above step S105 of the present invention, based on the analysis feedback of the test case execution results in the above steps, the test case selection strategy is dynamically adjusted, and then the adjusted test cases are used to re-determine the set of cases for testing the updated part of the software code from the test case library.

[0055] In this embodiment, according to the adjusted strategy, a set of test cases that is most relevant and effective and covers the change point and its surrounding functional modules is re-determined in the test case library of the software. This set will be used for the next round of regression testing to ensure the continuity and effectiveness of software quality control, while reducing unnecessary test case execution to improve the economy and time efficiency of the testing process. Through continuous test feedback and strategy optimization, this solution can adapt to the continuous iteration and functional evolution of the software and maintain high coverage and high efficiency of regression testing.

[0056] In the above steps S101 to S105, the source code is subjected to deep semantic analysis by the pre-trained large model, which can accurately identify and extract the various functional modules in the software and the complex dependencies between these modules. When the software source code is updated, the system can quickly detect the code changes, and based on the understanding ability of the large model, intelligently evaluate the impact of the changes, so as to quickly filter out the most relevant test cases from the test case library. Based on the test results of the test case, the system can dynamically adjust the selection strategy of the test case, continuously learn and optimize, and ensure that the test strategy always maintains high efficiency and accuracy during the iteration process of the software. This continuous learning mechanism helps to improve the intelligent matching ability of the large model, making the selection of test cases more accurate and covering more comprehensive. By determining the test case through deep semantic analysis, intelligent matching and dynamic learning mechanism, the determined test case can be matched with the code change part, thereby improving the efficiency and accuracy of software regression testing, which plays an important role in accelerating the software development process, controlling the testing cost and improving the software quality, especially when dealing with large and complex software projects.

[0057] The above method of this embodiment is further introduced below.

[0058] As an optional implementation method, step S101 uses a pre-trained large model to identify the source code of the software to obtain multiple functional modules in the software and the dependencies between the multiple functional modules, including: using the large model to perform deep semantic analysis on the source code of the software to obtain the analysis results; based on the analysis results, dividing the source code into multiple functional modules; based on the analysis results, determining the dependencies between the multiple functional modules.

[0059] In this embodiment, a large model is used to perform deep semantic analysis on the source code of the software, and the source code is converted into an abstract syntax tree (AST), which helps to understand the basic structure and grammatical elements of the code.

[0060] Optionally, the big model uses deep learning technology to perform semantic understanding of the code, which includes identifying the definition and call of functions, classes, and interfaces, understanding the purpose and function of code segments, and identifying data flow and control flow. The big model can consider the code context, including non-code elements such as comments, document strings, variable names, etc., to more fully understand the intent and logic of the code.

[0061] Optionally, after performing deep semantic analysis on the source code and obtaining the analysis results, relatively independent functional modules in the source code can be identified based on the analysis results, which may correspond to specific business logic, function implementation or data processing flow.

[0062] For example, the large model can be used to determine the boundaries of modules, including code elements such as files, functions, and classes, as well as the calling relationships between them, to ensure the logical integrity of each module. Based on the identified modules and their boundaries, modular grouping is performed to build a module hierarchy, which helps with subsequent change impact analysis and test case screening.

[0063] Optionally, the dependencies between multiple functional modules are determined based on the parsing results. For example, by analyzing direct calls in the code, the large model can determine which modules have direct dependencies, such as function calls, class inheritance, or interface implementations. Using structured analysis and data flow tracking of the code, the system can identify indirect dependencies between modules, including data transfer or control flow propagation through intermediate modules. After determining the dependencies between multiple functional modules, the large model and system algorithms work together to construct a detailed module dependency graph that clearly depicts the dependencies between all functional modules, including direct and indirect dependencies.

[0064] In this step, the large model can not only accurately understand the syntax and semantics of the source code, but also automatically complete the software module division, while accurately analyzing and determining the dependencies between modules, providing a solid foundation for subsequent code change analysis and intelligent test case matching.

[0065] As an optional implementation manner, the method further includes: generating a module dependency graph based on the dependency relationship between the multiple functional modules, wherein the module dependency graph is used to at least represent the calling relationship between the multiple functional modules.

[0066] In this embodiment, the pre-trained large model performs deep semantic analysis on the software source code, identifies each independent or relatively independent functional module, and constructs dependency data between modules. Based on this dependency data, a module dependency graph can be further generated.

[0067] Optionally, the system can identify direct calling relationships between modules in the code, including function calls, class instantiations, method calls, etc. These calling relationships are connected by arrows in the module dependency graph, clearly showing the calling relationships between modules and the transfer of data flow or control flow that may be brought about by such calls.

[0068] Optionally, in addition to direct calls, the large model also analyzes the flow of data between modules, including the transfer of variables, data structures, configuration parameters, etc. These data dependencies are also represented in the dependency graph, which helps to identify which modules are closely connected in function and may affect each other.

[0069] Optionally, the system identifies control logic such as branch structures and loop structures in the code, and how they affect the execution order and conditional dependencies between modules. This analysis helps understand the interaction of modules under different execution paths and the indirect impact that change points may bring.

[0070] Optionally, the module dependency graph also includes interface calls between the software and external components (such as databases, network services, hardware devices), as well as dependencies with other software modules, to ensure comprehensive coverage of the software's external interaction environment.

[0071] Optionally, the system integrates the above information into a visual chart or structured data, namely, a module dependency graph. In the dependency graph, each module is represented as a node, and the lines between the nodes represent the call, data flow or control flow dependency between them.

[0072] Optionally, the module dependency graph not only helps with intelligent test case matching, but also provides a clear view of the software architecture for the software development and maintenance team, making it easier to understand the interactions between modules and the change propagation path. In a continuous integration environment with frequent software updates, the dependency graph can quickly locate which modules may be affected by the changes, provide direction for the test team, reduce unnecessary test case execution, and improve test efficiency and resource utilization.

[0073] Optionally, the module dependency graph can also facilitate the optimization of test case selection strategies. By identifying high-risk module dependency chains, the system can prioritize test cases that cover critical paths to ensure functional stability and performance after software changes. Under the mechanism of continuous learning and dynamic adjustment, the dependency graph, as the basis for system analysis and decision-making, can be continuously updated with software iterations to maintain its accuracy and timeliness.

[0074] As an optional implementation, step S102, in response to an update of the source code of the software, determines the updated portion of the code in the source code, including: in response to an update of the source code of the software, detecting the changed position of the update in the source code; based on the changed position, determining the changed portion of the code in the source code.

[0075] In this embodiment, when the source code of the software is updated, the system is integrated into the version control system (such as Git, SVN, etc.) to immediately trigger the change detection mechanism. The system can automatically identify and mark the newly added, modified or deleted code segments in the code base.

[0076] Optionally, the system uses the change comparison function provided by the version control tool to determine the specific files and lines of code that have been changed in the code base. This detection is usually based on the difference (i.e., diff) between the code versions before and after the change, which can be accurate to the code line level to ensure accurate identification of the change location.

[0077] Optionally, after determining the location of the change, the nature of the code change can be further analyzed and understood, including the type of change (such as the addition of functions, modification of logic, adjustment of configuration, etc.) and the scale of the change (such as the number of lines of code involved). The system may also use a pre-trained large model to analyze the semantics of the changed code and determine the extent of its impact on the software function, thereby determining the code changes that require regression testing.

[0078] Optionally, after determining the code changes, the impact of these changes on the overall functionality of the software can be further analyzed.

[0079] In this step, emphasis is placed on precise detection and location of code changes, as well as in-depth understanding of the changed parts, which provides accurate data preparation for subsequent intelligent test case matching and ensures the pertinence and efficiency of regression testing.

[0080] As an optional implementation method, step S103, based on the code update part and the dependency relationship between multiple functional modules, determines the test case that matches the code update part from the test case library of the software, including: based on the module dependency graph and the call chain between multiple functional modules, determining the impact of the code change part on the multiple functional modules; based on the impact of the code change part on the multiple functional modules and the dependency relationship between the multiple functional modules, determining at least one test case that matches the code change part from the test case library of the software.

[0081] In this embodiment, the module dependency graph is used to deeply analyze the direct and indirect calling relationships between the code change part and other functional modules in the software. By identifying the calling path, the system can evaluate how the change affects other modules through the calling chain.

[0082] Optionally, for each functional module, the system calculates the impact of the change on the module based on the depth and breadth of the call chain and the strength of the dependencies between modules. A higher impact weight means that the module is directly affected by the change and needs more detailed testing. In addition to directly called modules, modules that are indirectly dependent through data flow and control flow are also considered, which may be potentially affected by the change even if they are physically far away from the change point.

[0083] Optionally, when selecting test cases based on the impact of the change and module dependencies, you can intelligently match the test cases most relevant to the code changes based on the impact of the change point and the dependencies between modules. Include test cases that cover the changed code, the affected modules, and the data flow or control flow interactions with these modules; ensure that the selected test cases can fully cover the scope of the change impact, including directly and indirectly affected functional modules. The system may need to select multiple test case combinations to ensure coverage without omissions.

[0084] Optionally, the system prioritizes the matched test cases based on the complexity of the code changes, the degree of dependency between modules, and the importance of the modules. Test cases related to modules with high risk or high dependency will be executed first.

[0085] Optionally, the system dynamically adjusts the test strategy based on the specific circumstances of the change point, such as adding test cases for specific scenarios, or reducing the amount of testing in low-risk areas, to optimize the allocation of test resources.

[0086] In this step, by deeply analyzing the impact of code changes on software functional modules and combining module dependencies, we can achieve intelligent screening and optimization of test cases, ensuring the pertinence and efficiency of regression testing. This process not only considers the direct impact of code changes, but also evaluates the scope of indirect impact that changes may have through inter-module dependencies, thereby improving the comprehensiveness of test coverage and is an important part of ensuring software quality control.

[0087] As an optional implementation, the method also includes: performing a risk assessment on the code change part to obtain a risk assessment result; determining the priority of at least one test case based on the risk assessment result and the coverage of at least one test case; and executing at least one test case based on the priority to test the code update part.

[0088] In this embodiment, risk assessment is a process of quantitatively evaluating the risks that may be brought about by the code update part based on factors such as the complexity of the code change, the location of the change point in the software architecture, the type of errors that may be introduced by the change, and historical test data.

[0089] Optionally, the scale (such as the number of modified lines of code), type (such as new features, logic modifications, code refactoring) and number of modules involved in the code change can be preliminarily calculated as a preliminary basis for risk assessment. Using module dependency graphs and large model analysis, determine the functional modules associated with the change point and their importance and impact in the entire software architecture. Changes to core functional modules or modules with high dependency usually have higher risk assessment scores.

[0090] Optionally, the risk assessment results can be adjusted by referring to the execution results and defect records of historical test cases, especially the historical defect rate of modules related to the change. The risk assessment score of modules with frequent defects in history will also increase accordingly when changes occur.

[0091] Optionally, test case priorities are determined based on risk assessment results and test case coverage. For example, the coverage of each test case in the test case library is analyzed, including the functional modules, code paths, and specific software states that it can detect. The test case coverage is compared with the risk assessment results, and test cases that cover high-risk areas are prioritized to ensure that the highest-risk parts of the software are tested first with limited testing resources. Based on the matching results, a priority value is assigned to each test case, which reflects the execution order and importance of the test case in the current regression test round. Test cases in high-risk areas are usually given the highest priority.

[0092] Optionally, after determining the priorities of each test case, a test execution plan is automatically generated based on the test case priorities, which includes the execution order of the test cases, expected results, and configuration of the execution environment. Test cases are automatically executed in order of priority, with priority given to modules and functions with high risk assessment scores, ensuring that regression testing can quickly identify and locate potential problems.

[0093] Optionally, during the test execution process, test results are continuously collected, including the execution status of each use case, detected defect information, and test coverage, etc., for subsequent test case selection strategy optimization and risk assessment model training.

[0094] In this step, the regression testing process can be intelligently optimized to ensure that after the software is updated, the riskiest parts of the software can be tested first in the shortest time and with the least resource consumption, effectively improving testing efficiency and the accuracy of software quality control.

[0095] As an optional implementation, step S105, based on the test results of the test cases, adjusts the test case selection strategy, including: comparing the test results with the expected results to obtain a comparison result, wherein the comparison result is used to indicate the pass status of the test case execution, defect location information and test coverage, and the effectiveness of the test case for code change detection; based on the pass status of the test case execution in the comparison result, defect location information and test coverage, and the effectiveness of the test case for code change detection, adjust the test case selection strategy; the method also includes: based on the adjusted selection strategy, redetermining the test cases that match the code update part in the test case library of the software.

[0096] In this embodiment, the actual execution result of the test case is compared with the expected result to generate a comparison result, which includes identifying whether the test case passes (no defects), identifying defects or exceptions, and the software functional modules and code ranges covered by the test case.

[0097] Optionally, for test cases that fail, the system records detailed defect information, including defect type, location (specific line number or function in the source code), and possible triggering conditions, which helps the development team quickly locate the problem. The system analyzes the coverage of software functions by test cases, identifies which modules, code paths, or change points are covered by tests, and which areas still have coverage blind spots. This includes coverage statistics for each functional module, as well as targeted test coverage assessments for code change points. Based on the test results, the system evaluates the effectiveness of test cases for code change detection, determines which test cases can effectively identify potential problems after changes, and which test cases have a low correlation between coverage and change points.

[0098] Optionally, based on the comparison results, adjust the test case selection strategy and optimize the test case set. This may include deleting or downgrading test cases that contribute less to defect detection, while adding or upgrading test cases that can more effectively cover change points.

[0099] Optionally, for each test execution, the system may adjust the priority weights of the big model for different test cases based on the defect detection rate, test coverage, and test case execution efficiency to ensure that high-risk areas are tested first.

[0100] Optionally, the system uses test result feedback to continuously optimize the parameters of the large model, enabling it to more accurately predict the scope of impact of code changes, thereby improving the intelligence and accuracy of test case selection.

[0101] Optionally, based on the optimized strategy, re-match the test cases in the test case library of the software. This process may involve re-ordering, screening and combining the test cases to ensure that the test cases most relevant to the updated code are executed first.

[0102] Optionally, review and adjust the test case collection to ensure that all key modules and functional points affected by the change are adequately covered while avoiding over-testing of low-risk areas.

[0103] Optionally, when redefining the test cases, the system may also consider factors such as the execution time and resource consumption of the test cases to balance the test efficiency and the test quality.

[0104] In this step, the test case selection strategy is dynamically adjusted through test result feedback to ensure that regression testing can accurately and efficiently cover the key areas after the software update, while reducing unnecessary test execution. This is an important part of achieving automated and intelligent test case screening and optimization. This mechanism can significantly improve the efficiency of software development and testing, reduce labor costs, and improve software quality.

[0105] The technical solution of the embodiment of the present invention is illustrated below in conjunction with preferred implementation modes.

[0106] At present, regression testing is a key link in ensuring software quality during software development. However, traditional regression testing methods have problems of low testing efficiency and high resource consumption when facing large-scale software updates. Especially when the software is large in scale and has many functional modules, how to efficiently determine which test cases need to be re-executed becomes a challenge.

[0107] However, an embodiment of the present invention proposes an intelligent test case screening method based on a big model, the core of which is to use big model technology to automatically analyze the structure of the software, divide it into multiple functional modules, and intelligently match relevant test cases according to code changes, thereby significantly improving the efficiency and accuracy of regression testing.

[0108] Next, the intelligent test case screening method based on a large model provided in an embodiment of the present invention is introduced.

[0109] In this embodiment, the intelligent test case screening method based on the big model mainly includes: big model module division, code change analysis, intelligent test case matching and dynamic learning mechanism.

[0110] Large model module division: Use a pre-trained large model (for example, a model with a Transformer architecture) to perform deep semantic analysis on the software source code to identify and extract various functional modules.

[0111] Code change analysis: When the software is updated, the system automatically detects the code changes and uses the big model to understand the impact of the changes.

[0112] Intelligent test case matching: Based on the code changes and the functional modules they affect, the system intelligently selects the most relevant test case sets, reducing unnecessary test execution and improving test targeting.

[0113] Dynamic learning mechanism: The system continuously learns and optimizes the test case selection strategy, and continuously adjusts and improves the performance of large models through feedback mechanisms to adapt to the iterative development of the software.

[0114] Figure 2 is a schematic diagram of a large model module division according to an embodiment of the present invention, such as Figure 2As shown in the figure, it describes how to use a pre-trained large model (such as a Transformer architecture model) to perform deep semantic analysis on the source code of the software to automatically divide the functional modules of the software and understand the logic and dependencies between these modules. Source code input: the starting point of the entire method; large model semantic analysis: the large model performs deep semantic analysis on the input source code to understand the structure and function of the code; functional module extraction: after the large model is parsed, it can identify and extract multiple functional modules in the software, providing a basis for subsequent change analysis and test case matching.

[0115] Optionally, Figure 2 The dependencies between modules are also reflected in the module diagram, which helps to evaluate the impact of the change. The resulting module block diagram clearly shows the module division and dependencies of the software, which facilitates the subsequent intelligent test case screening.

[0116] Optionally, a pre-trained big model is used to perform deep semantic analysis of the software source code, thereby realizing the modular division process of the software. The big model is used to perform deep semantic analysis of the software source code, analyze the functional structure, logical flow and dependencies of the code, and identify and extract each functional module. The big model not only analyzes the surface syntax, but also understands the semantics and purpose of the code. When understanding the semantics of the code, the big model has the following key capabilities: code structure analysis, function call relationship analysis, interface definition and interaction logic, module collaboration logic, modular grouping, fine-tuning and adaptation of the big model, deep semantic analysis of the code, semantic understanding, pattern recognition, etc.

[0117] Among them, code structure analysis includes analyzing the hierarchical structure of the code (such as functions, classes, modules); understanding the relationship between the code, such as call chains, inheritance structures, etc. Function call relationship analysis includes the model building a complete call graph (Call Graph) based on the definition and call location of the function in the code. Parse the input and output parameters of the function and its relationship with other modules. Interface definition and interaction logic include identifying interfaces in the code (such as APIs or public methods) and understanding their parameters, return values, and expected functions. Analyze the logic of interaction between modules through interfaces and identify cross-module dependencies. Module collaboration logic includes analyzing the paths of collaboration between modules, such as data flow, event triggering, and dependencies; generate module interaction diagrams based on dependencies for further division and optimization.

[0118] Optionally, modular grouping includes dividing the code into logical functional modules based on the analysis results of the large model, identifying critical paths and functional blocks, and generating detailed module dependency graphs to facilitate subsequent change analysis.

[0119] Optionally, a modular structure can be obtained through fine-tuning and adaptation of large models, deep semantic analysis of codes, and module division and grouping.

[0120] Optionally, fine-tuning and adaptation of the large model include training model selection and model fine-tuning. Pre-trained model selection uses a large model that has been trained with massive code and natural language text. Model fine-tuning uses the target project's code base and its related documents (such as test cases, module descriptions) to fine-tune the model to enhance its adaptability to specific projects. Deep semantic analysis of code includes syntax parsing, semantic understanding, and pattern recognition, among which syntax parsing generates an abstract syntax tree (AST) of the code through a parser; analyzes the boundaries of code blocks (such as function definitions, class definitions). Semantic understanding uses a large model combined with contextual information to understand the function and purpose of code snippets; analyzes the logical relationships and call dependencies of code across modules. Pattern recognition, through learning from historical code and module design, the large model can identify similar functional modules; automatically cluster code snippets to summarize logically consistent functional units.

[0121] Optionally, module division and grouping includes dependency analysis and module merging and optimization. Dependency analysis refers to using call graphs and dependency graphs to identify coupled modules in the code; dividing independent functional modules to reduce the complexity of coupling. Module merging and optimization refers to merging modules with similar functions; optimizing module division based on usage frequency or complexity to generate the final modular structure.

[0122] Figure 3 is a schematic diagram of a code change analysis according to an embodiment of the present invention, such as Figure 3 As shown, it includes: version control system. The source code of software updates is managed through the version control system, which provides a data source for detecting code changes. Big model impact analysis: When the code changes, the big model will analyze the change points and their potential impact on the software functional modules, and generate an impact matrix or report. Risk assessment: Combined with the complexity, impact scope and historical records of code changes, the system automatically conducts risk assessment to provide a basis for the selection of test cases. Deployment diagram: Figure 3 The deployment diagram based on change risk assessment is also shown, which helps the development team understand which modules need to be tested and focused on.

[0123] Optionally, code change analysis includes: change detection, impact analysis, and change risk assessment. Among them, for change detection, when the software version is updated, the system automatically detects the change location of the source code through the version control system, including the newly added, deleted, and modified code parts; for impact analysis, the large model combines the code dependencies to evaluate the possible impact of these changes. The system not only pays attention to the module where the changed code is located, but also analyzes its potential impact on related modules, generates an impact matrix, and evaluates the functional scope that the change may affect; for high-risk change assessment, based on the change scale, change location, and the complexity of related functions, the system automatically conducts risk assessment on the change, and provides a priority reference for test case selection.

[0124] Figure 4 is a schematic diagram of intelligent test case matching according to an embodiment of the present invention, such as Figure 4 As shown in the figure, it describes how to filter out the most relevant test cases from the test case database based on code changes and module dependencies, including: Test case database: The system maintains a database containing a large number of test cases, and each test case has detailed metadata information. Change and test case association: When the code changes, the system will intelligently match the relevant test cases according to the change points and module dependencies. Optimization algorithm automatic screening: Through the optimization algorithm, the system automatically filters out the basic test case set to reduce unnecessary test execution. Big model-test case matching: Using the big model's understanding of the change points, further optimize the matching of test cases to ensure coverage of key areas. Risk assessment: Combined with the risk of code changes, the system prioritizes test cases and gives priority to executing test cases in high-risk areas. Recommended test cases: Finally, the system outputs a list of filtered and sorted test cases for testing the quality of the software after the update.

[0125] Optionally, test case database construction: the system maintains a large database of historical test cases, storing the execution history, functional coverage and related module information of each test case. The metadata of the test case should include information such as function labels, dependent modules, and coverage scenarios. Change association with test cases: the system automatically filters out a basic set of test cases through optimization algorithms, reduces unnecessary regression testing, and improves testing efficiency. At the same time, the system uses a large model to analyze the impact of code changes on each functional module, and automatically matches test cases related to the changes. Consider the complexity of code changes and the dependencies between modules to ensure that key test scenarios are not missed. Test case prioritization: based on the change risk assessment results and the coverage of the test cases, the system assigns a priority to each test case, and gives priority to test cases in high-risk areas.

[0126] Optionally, the dynamic learning mechanism includes establishing a feedback mechanism, optimizing adaptive strategies, and continuously updating models.

[0127] Optionally, for feedback mechanism establishment: After each test execution, the system compares the test results with the expected results and analyzes the effectiveness of test case matching. By recording the success rate of test execution, test coverage, and the impact of code changes on test results, the system continuously accumulates data. For adaptive strategy optimization: Based on the collected feedback data, the system dynamically adjusts the test case selection and matching strategy. By continuously updating the parameters and training data of the large model, the performance of the model is optimized, and the accuracy and efficiency of future test case matching are improved.

[0128] For continuous model updates: The training data of large models should be continuously expanded as the software is updated, incorporating the latest code changes and corresponding test case information to improve the model's adaptability to future changes. The system regularly retrains or fine-tunes the model to ensure that it maintains a high level of generalization ability.

[0129] Optionally, the training data of the large model should contain a large amount of software code and corresponding test case information to ensure the generalization ability of the model and the accuracy of test case matching. Training data preparation: The training data of the large model should contain a large amount of diverse actual software code and its corresponding test cases, covering different languages, frameworks and application scenarios to ensure that the large model has good generalization ability. The data set should include the code version before and after the change, the test case set actually executed after each change and its results, the dependencies between modules, the function call path, etc. Help the model understand the relationship between code changes and functional impacts. Intelligent matching algorithm improvement: For code change analysis, the intelligent matching algorithm should comprehensively consider the complexity of code changes, dependencies between modules, call paths and functional coverage to ensure that key functions can be properly tested after each change. The model reduces unnecessary test execution through continuous optimization while ensuring comprehensive test coverage.

[0130] According to an embodiment of the present invention, a device for determining a test case is also provided. It should be noted that the device for determining a test case can be used to execute the method for determining a test case in the embodiment.

[0131] Figure 5 is a schematic diagram of a device for determining a test case according to an embodiment of the present invention. Figure 5 As shown, the test case determination device 500 may include: an identification unit 501 , a first determination unit 502 , a second determination unit 503 , an adjustment unit 504 and a third determination unit 505 .

[0132] The identification unit 501 is used to identify the source code of the software using the pre-trained large model to obtain multiple functional modules in the software and the dependency relationship between the multiple functional modules;

[0133] A first determining unit 502, configured to determine a code update portion in the source code in response to an update of the source code of the software;

[0134] A second determining unit 503 is used to determine a test case matching the code update part from a test case library of the software based on the code update part and the dependency relationship between the multiple functional modules, wherein the test case is used to test the code update part;

[0135] An adjusting unit 504, configured to adjust a test case selection strategy based on a test result of the test case;

[0136] The third determining unit 505 is used to re-determine the test case for testing the code update part based on the adjusted test case selection strategy.

[0137] Optionally, the identification unit 501 is also used to: use the large model to perform deep semantic analysis on the source code of the software to obtain a analysis result; based on the analysis result, divide the source code into multiple functional modules; based on the analysis result, determine the dependency relationship between the multiple functional modules.

[0138] Optionally, the apparatus 500 is further configured to: generate a module dependency graph based on dependency relationships between multiple functional modules, wherein the module dependency graph is configured to at least represent a calling relationship between multiple functional modules.

[0139] Optionally, the first determining unit 501 is further configured to: in response to the source code of the software being updated, detect a changed position in the source code where the update occurs; and determine a code changed portion in the source code where the update occurs based on the changed position.

[0140] Optionally, the second determination unit 503 is also used to: determine the degree of impact of the code change part on multiple functional modules based on the module dependency graph and the call chain between multiple functional modules; based on the degree of impact of the code change part on multiple functional modules and the dependency relationship between multiple functional modules, determine at least one test case matching the code change part from the test case library of the software.

[0141] Optionally, the device 500 is also used to: perform risk assessment on the code change part to obtain a risk assessment result; determine the priority of at least one test case based on the risk assessment result and the coverage of at least one test case; execute at least one test case based on the priority to test the code update part.

[0142] Optionally, the adjustment unit 504 is also used to: compare the test results with the expected results to obtain a comparison result, wherein the comparison result is used to indicate the pass status of the test case execution, defect location information and test coverage, and the effectiveness of the test case for code change detection; based on the pass status of the test case execution, defect location information and test coverage in the comparison result, and the effectiveness of the test case for code change detection, adjust the test case selection strategy; the device is also used to: based on the adjusted selection strategy, redetermine the test case that matches the code update part in the test case library of the software.

[0143] In this embodiment, the source code is deeply semantically analyzed by pre-training the large model, and each functional module in the software and the complex dependencies between these modules can be accurately identified and extracted. When the software source code is updated, the system can quickly detect the code changes, and based on the understanding ability of the large model, intelligently evaluate the impact of the changes, so as to quickly filter out the most relevant test cases from the test case library. Based on the test results of the test case, the system can dynamically adjust the selection strategy of the test case, continuously learn and optimize, and ensure that the test strategy always maintains high efficiency and accuracy during the iteration process of the software. This continuous learning mechanism helps to improve the intelligent matching ability of the large model, making the selection of test cases more accurate and covering more comprehensive. By determining the test case through deep semantic analysis, intelligent matching and dynamic learning mechanism, the determined test case can be matched with the code change part, thereby improving the efficiency and accuracy of software regression testing, which plays an important role in accelerating the software development process, controlling testing costs, and improving software quality, especially when dealing with large and complex software projects.

[0144] According to an embodiment of the present invention, a computer-readable storage medium is further provided. The storage medium includes a stored program, wherein the program executes the method for determining the test case in Embodiment 1.

[0145] According to an embodiment of the present invention, a processor is further provided, the processor being used to run a program, wherein the method for determining the test case in Embodiment 1 is executed when the program is running.

[0146] According to another aspect of the present invention, a computer program product is provided, which includes computer instructions, and when the computer instructions are executed by a processor, the method for determining the test case in the first embodiment is implemented.

[0147] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0148] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0149] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0150] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0151] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0152] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent functional component, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software functional component, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, Read-Only Memory (ROM), Random Access Memory (RAM), mobile hard disk, magnetic disk or optical disk, etc., various media that can store program codes.

[0153] The above are only preferred embodiments of the present invention. It should be pointed out that, for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for determining a test case, characterized in that: include: Using a pre-trained large model to identify the source code of the software, multiple functional modules in the software and the dependency relationships between the multiple functional modules are obtained; In response to an update of the source code of the software, determining a code update portion in the source code; Based on the dependency relationship between the code update part and the multiple functional modules, determine a test case matching the code update part from a test case library of the software, wherein the test case is used to test the code update part; Based on the test results of the test cases, adjusting the selection strategy of the test cases; Based on the adjusted test case selection strategy, the test cases for testing the code update part are re-determined.

2. The method according to claim 1, characterized in that The source code of the software is identified by using a pre-trained large model to obtain multiple functional modules in the software and the dependencies of the multiple functional modules, including: Using the large model to perform deep semantic analysis on the source code of the software to obtain the analysis result; Based on the parsing result, dividing the source code into a plurality of functional modules; Determine the dependency relationship between the multiple functional modules based on the parsing result.

3. The method according to claim 2, characterized in that The method further comprises: Based on the dependency relationships among the multiple functional modules, a module dependency graph is generated, wherein the module dependency graph is used to at least represent the calling relationships among the multiple functional modules.

4. The method according to claim 3, characterized in that In response to the source code of the software being updated, determining a code update portion in the source code includes: In response to an update of the source code of the software, detecting a changed position where the update occurs in the source code; Based on the change position, a code change portion in the source code that is updated is determined.

5. The method according to claim 4, characterized in that Based on the dependency relationship between the code update part and the plurality of functional modules, determining a test case matching the code update part from a test case library of the software comprises: Determining the impact of the code change portion on the multiple functional modules based on the module dependency graph and the call chains between the multiple functional modules; Based on the degree of influence of the code change portion on the multiple functional modules and the dependency relationships between the multiple functional modules, at least one test case matching the code change portion is determined from the test case library of the software.

6. The method according to claim 5, characterized in that: The method further comprises: Performing risk assessment on the code change part to obtain a risk assessment result; Determining a priority of the at least one test case based on the risk assessment result and the coverage of the at least one test case; The at least one test case is executed based on the priority to test the code update portion.

7. The method according to claim 1, characterized in that Adjusting the selection strategy of the test case based on the test result of the test case includes: Comparing the test result with the expected result to obtain a comparison result, wherein the comparison result is used to indicate the pass status of the test case execution, defect location information and test coverage, and the effectiveness of the test case for code change detection; Adjusting the test case selection strategy based on the pass status of the test case execution in the comparison result, the defect location information and the test coverage, and the effectiveness of the test case for code change detection; The method further comprises: Based on the adjusted selection strategy, test cases matching the code update portion are re-determined in the test case library of the software.

8. A device for determining a test case, characterized in that: include: An identification unit, used to identify the source code of the software using a pre-trained large model, and obtain multiple functional modules in the software and the dependency relationships between the multiple functional modules; A first determining unit, configured to determine a code update portion in the source code in response to an update of the source code of the software; a second determining unit, configured to determine, based on the dependency relationship between the code update part and the plurality of functional modules, a test case matching the code update part from a test case library of the software, wherein the test case is used to test the code update part; An adjusting unit, configured to adjust a selection strategy of the test case based on a test result of the test case; The third determining unit is used to re-determine the test case for testing the code update part based on the adjusted test case selection strategy.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed by a processor, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 7.

10. A processor, characterized in that: The processor is used to run a program, wherein the program executes the method according to any one of claims 1 to 7 when running.

Images