Test case generation method and system

Abstract

The invention relates to a test case generation method and system, and the method comprises the steps: carrying out the change weighting of all change line numbers, change timestamps, change depths and change operators, which are extracted from a Git change record of a current version, through employing a time exponential decay model; meanwhile, a penalty factor of author diversity entropy generated by a change operator is introduced in the weight change process to obtain row-level change popularity, and a code calling graph, a code inheritance graph and a data dependency graph are extracted from a complete code library of the current version through a static analysis tool to construct a code heterogeneous graph; the method comprises the following steps: establishing a large language model, introducing line-level change popularity and carrying out weight aggregation to generate an influence map, extracting and executing a hotspot method from the influence map to generate a to-be-covered path, and inputting the to-be-covered path into the large language model to output a recall test case and a newly-added test case. Therefore, the method not only has the capability of generating the new test case, but also ensures the recall rate and the accuracy of the test case.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for generating test cases. Background Technology

[0002] In a rapidly iterating software development model, frequent code changes are the norm, posing a significant challenge to testing. Existing technologies primarily employ three methods to address this, but all have significant limitations: (a) Experience-driven approach: Test engineers manually select regression test cases based on code diffs, requirements documents, and historical defect experience. This method is highly dependent on personal experience and is prone to overtesting or undertesting. (ii) Static Difference Comparison: This method recommends existing test cases by comparing the syntax differences between two versions, at the file or function level. However, it only stays at the surface level of "file → function", resulting in low recall and high false positive rate of test cases. (iii) Simple utilization of version metadata: Using Git differences to trigger test case recommendations or generation. Although this method introduces the version control system's metadata, it can only reuse historical test cases and lacks the ability to generate new test cases for added or modified logic. Summary of the Invention

[0003] The technical problem to be solved by this invention is: This invention provides a method and system for generating test cases, which does not rely on human experience, has the ability to generate new test cases, and at the same time ensures the recall and accuracy of test cases.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a method for generating test cases, comprising: Collect the Git change history of the current version, extract all change line numbers, change timestamps, change depths and change operators of the Git change history, and use the time exponential decay model to change and weight all change line numbers, change timestamps and change depths. At the same time, during the change and weighting process, a penalty factor of author diversity entropy generated by the change operator is introduced to obtain the line-level change popularity. Obtain the complete codebase of the current version, and extract the code call graph, code inheritance graph, and data dependency graph from the complete codebase using static analysis tools to construct a code heterogeneity graph. Introduce the row-level change heat into the code heterogeneity graph and perform weight aggregation to generate an impact graph. The influence map is used to extract and execute a hotspot method to generate a set of paths to be covered. The set of paths to be covered is then input into a large language model to output recall test cases and new test cases.

[0005] The beneficial effects of this invention are as follows: it directly extracts multi-dimensional change features such as all changed line numbers, change timestamps, change depths, and change operators from Git change records, and uses a time-exponential decay model for change weighting. This ensures that the obtained row-level change heat is based on more comprehensive change features, achieving accurate and granular change assessment. This breaks through the limitations of traditional change assessment that relies solely on single surface differences. Furthermore, the time-exponential decay model effectively avoids distortion in the calculated row-level change heat. In addition, the introduction of a penalty factor based on author diversity entropy generated by the change operator during the change weighting process effectively avoids false row-level change heat caused by modifications by a single change operator, further improving the authenticity and accuracy of the obtained row-level change heat. Compared to building relationships solely based on Git change records, constructing a heterogeneous code graph using code call graphs, code inheritance graphs, and data dependency graphs obtained from the complete codebase can fully cover implicit relationships between codes, ensuring the completeness of the impact graph. This, in turn, guarantees the recall and accuracy of test cases. Furthermore, the set of paths to be covered is generated based on hot methods, ensuring that the output recall test cases and new test cases focus on high-frequency paths to be covered, avoiding resource waste caused by full coverage. It also has the ability to generate new test cases.

[0006] Optionally, the time-exponential decay model is used to weight all changed line numbers, changed timestamps, and changed depths. Simultaneously, a penalty factor based on the author diversity entropy generated by the change operator is introduced during the weighting process to obtain the line-level change heat, which includes: The change depth is calculated by obtaining the number of newly added characters, the number of deleted characters, and the maximum value of the AST node changes from the Git change records. All changed line numbers, changed timestamps, and changed depths are input into a time-weighted index formula for weighting. Simultaneously, a penalty factor based on the author diversity entropy generated by the change operator is introduced during the weighting process. The line-level change popularity is then calculated using a line-level popularity formula, which is: ; in, This indicates the weighting of a single change in a Git change record r. Indicates the line number to be changed. Depth of change Indicates the line number to be changed. Change timestamp, This represents the current time, and T represents the decay half-life. Indicates the current attenuation coefficient; The formula for row-level heat is: ; in, Indicates the number of lines changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. This indicates the weighting of a single change in a Git change record. Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates that it has been modified. gather.

[0007] As described above, change depth is calculated based on the number of new characters, the number of deleted characters, and the maximum change in AST nodes in the Git change log. Compared to the traditional method of only counting the increase or decrease of characters, it can more accurately reflect the intensity of changes at the code logic level, avoid the problem of underestimating small character changes but logical refactoring or overestimating large character redundant modifications, and improve the accuracy of the obtained line-level change heat.

[0008] Optionally, the simultaneous introduction of the penalty factor of author diversity entropy generated by the change operator during the weighting process includes: Calculate the percentage of changes submitted by each change operator in the Git change log, input this percentage into the author entropy formula, and obtain the corresponding author diversity entropy for the change operator. The author entropy formula is: ; in, Indicates a change of operator The entropy of author diversity Indicates a change of operator relative path, This represents the set of authors for the Git change record 'r'. Indicates a change of operator The percentage of changes; The author diversity entropy of each change operator is input into the penalty formula for calculation, resulting in the corresponding penalty factor for author diversity entropy. The penalty formula is as follows: ; in, Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates a change of operator The entropy of author diversity This represents the set of authors for the Git change record r.

[0009] As described above, when the proportion of changes made by a single change operator is high, the corresponding author diversity entropy is low. After transformation by the penalty formula, a larger penalty factor will be obtained, thereby reducing the row-level change heat and avoiding high-frequency, high-volume modifications by a single change operator, which could lead to false row-level change heat and further ensure the authenticity of the obtained row-level change heat.

[0010] Optionally, the step of extracting code call graphs, code inheritance graphs, and data dependency graphs from the complete codebase using static analysis tools to construct a code heterogeneity graph, and then introducing the line-level change heat into the code heterogeneity graph and performing weight aggregation to generate an influence graph includes: Static analysis tools are used to extract code call graphs, code inheritance graphs, and data dependency graphs from the complete codebase to construct a code heterogeneity graph containing multi-granularity entities, including lines of code, methods, classes, and packages; Calculate the number of times all classes and all methods are referenced in the code heterogeneity graph to generate the corresponding class static coupling degree and method static coupling degree. At the same time, collect the class production call frequency and the method production call frequency of all classes and all methods through the production environment call chain to generate the corresponding class runtime heat and method runtime heat. The line-level change heat is introduced into the code heterogeneity graph. Combined with the class static coupling degree, the method static coupling degree, the class runtime heat and the method runtime heat, weights are aggregated according to the hierarchical relationship of code line, method, class and package. The weights are propagated across entities through the lightweight GraphSAGE network to output the graph node weights with each granular entity as the node, so as to generate the influence graph.

[0011] As described above, the generated code heterogeneity graph is a multi-granularity entity heterogeneity graph containing lines of code, methods, classes, and packages. It breaks through the limitations of traditional single shallow granular analysis, achieving full-level coverage from the bottom line of code to the top package. At the same time, it introduces class static coupling, method static coupling, class runtime heat, and method runtime heat, forming a multi-dimensional system from static to dynamic to intensity with line-level change heat. Weights are aggregated according to the hierarchical relationship of lines of code, methods, classes, and packages, avoiding the disconnect between weight calculation and code structure. At the same time, weight propagation across entities is carried out through a lightweight GraphSAGE network, which can correct the possible weight deviation of a single entity and ensure the accuracy of weight propagation. This makes the final influence graph generated based on the weights of the graph nodes with each granularity entity as a node both fit the code hierarchy logic and take into account the correlation influence between entities.

[0012] Optionally, the step of extracting and executing a hotspot method from the influence map to generate the set of paths to be covered includes: Obtain the graph node weight of each node in the influence graph, and sort all nodes in descending order according to the graph node weight to obtain the node sequence after descending order. The methods corresponding to the top N nodes in the descending sorted node sequence are taken as hot methods, and the hot methods are executed to generate the current path conditions. Obtain the new path condition from the change statement corresponding to each change line number, and perform a feasibility judgment on each new path condition and the current path condition. If the current path condition and the new path condition cannot exist at the same time, then the new path condition is taken as the path to be covered. or If there is no historical test case in the historical test case library that contains both the new path condition and the current path condition, then the new path condition will be the path to be covered. All paths that need to be covered are summarized to generate a set of paths that need to be covered.

[0013] As described above, nodes are sorted in descending order based on their weights in the influence graph. The top N nodes are used as the hotspot method, avoiding the subjectivity and bias of manual judgment regarding hotspots. Only new path conditions that cannot coexist with the current path conditions and new path conditions not covered by historical test cases are considered as paths to be covered. This eliminates redundant paths from repeated testing and avoids path omissions, ensuring the completeness and accuracy of the generated set of paths to be covered.

[0014] Optionally, inputting the set of paths to be covered into a large language model to output recall test cases and new test cases includes: The set of paths to be covered is matched with a pre-built triplet mapping table to obtain the function IDs to be covered. The triplet mapping table is (class, method, function ID). Calculate the cosine similarity between the function description text corresponding to the function ID to be covered and the historical test cases in the historical test case library, and output the historical test cases whose cosine similarity exceeds the first similarity threshold as recall test cases; The function description text corresponding to the function ID to be covered is combined with the set of paths to be covered and the change code corresponding to the set of paths to be covered to construct a structured prompt template, so that the large language model can generate and output new test cases based on the structured prompt template.

[0015] As described above, matching the set of paths to be covered with a pre-built triplet mapping table realizes the transformation from path to function, avoiding the recall and addition of test cases remaining only at the code level, solving the pain point of disconnect between technology and business, and only using historical test cases with a cosine similarity exceeding the first similarity threshold as recall test cases output, reducing the redundant cost of manual screening, and improving the matching efficiency and accuracy of recall test cases. By combining the function description text corresponding to the function ID to be covered with the set of paths to be covered and the corresponding changed code to construct a structured prompt template, a full set of information is provided to the large language model, enabling it to generate new test cases, and ensuring that the generated new test cases can both meet the path coverage requirements and match the code change logic.

[0016] Optionally, outputting historical test cases with cosine similarity exceeding a first similarity threshold as recall test cases includes: Historical test cases whose cosine similarity exceeds the first similarity threshold are used as candidate recall test cases; Count the number of business keywords in the function IDs that need to be covered, input the number and the row-level change popularity into the first formula to calculate the business priority. The first formula is: ; ; in, Indicates business priority. This indicates the runtime popularity of the classes in the path set that need to be covered. This indicates the runtime popularity of the methods in the set of paths that need to be covered. As the first weight, This indicates the file-level change popularity of the Git change record 'r' generated based on the row-level change popularity. Indicates the second weight. Indicate quantity, Indicates the third weight. Indicates the number of lines changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. Indicates the line number to be changed. The number of syntax nodes; Calculate the defect density of candidate recall test cases, and input the defect density, the business priority, and the cosine similarity into a second formula to obtain the final similarity. The second formula is: ; in, Indicates business priority. Indicates defect density, Represents cosine similarity. This indicates the weights of the graph nodes in the path set that need to be covered; The final recall test case is selected from the candidate recall test cases and the one with the highest similarity is output as the final recall test case.

[0017] As described above, candidate recall test cases are first screened using cosine similarity to eliminate low-relevance (i.e., low-similarity) test cases, thus reducing computational costs. Then, the final recall test cases are locked using the final similarity score. This avoids the tedious manual screening of candidate recall test cases. Furthermore, when calculating the final similarity score, the defect density of candidate recall test cases, the weight of graph nodes in the required path set, and business priority are introduced to improve the accuracy of the calculated final similarity score. The business priority is calculated using class runtime popularity, method runtime popularity, file-level change popularity, and the number of business keywords, quantifying business priority from multiple dimensions to ensure that recall test cases with high business priority are screened first, thereby guaranteeing the accuracy of the output final recall test cases.

[0018] Optionally, inputting the set of paths to be covered into a large language model to output recall test cases and new test cases includes: Calculate the AST structure fingerprint and sentence embedding vector for each recall test case and each new test case, and fuse the AST structure fingerprint and the corresponding sentence embedding vector to generate a composite fingerprint for each recall test case and a composite fingerprint for each new test case. Calculate the first similarity of the composite fingerprint among all recalled test cases, calculate the second similarity of the composite fingerprint among all new test cases, and calculate the third similarity of the composite fingerprint between each recalled test case and each new test case. Based on the first similarity, the second similarity, and the third similarity, all recall test cases and all new test cases are deduplicated to obtain deduplicated recall test cases and deduplicated new test cases.

[0019] As described above, the composite fingerprint generated by the AST structure fingerprint and sentence embedding vector is used to deduplicatize recall test cases and new test cases, breaking through the limitations of single-dimensional deduplication and achieving accurate deduplication in both structural and semantic dimensions. Furthermore, the similarity calculation for the entire scenario ensures thorough deduplication, reduces the scale of recall test cases and new test cases, and improves subsequent execution efficiency.

[0020] Optionally, it also includes: The execution priorities of the recalled test cases and the newly added test cases are calculated using a third formula, and the test plan is arranged according to the execution priorities. The third formula is: ; in, Indicates execution priority. Indicates business priority. This represents the graph node weight of node j corresponding to the recalled / added test cases in the influence graph. This indicates the code complexity of recalling / adding test cases. This represents the recall defect density of recall test cases / the new defect density of new test cases; The XGBoost regression model is used as the input vector to predict the test man-hours and test resources of the test plan, using the feature vector composed of the number of IDs of all function IDs involved in the test plan, the row-level change heat, the number of recalled test cases and the recalled defect density, the number of new test cases and the new defect density. The corresponding prediction results are obtained. At the same time, the defect risks of the test plan are quantified by Monte Carlo simulation to generate a risk heat map.

[0021] As described above, by integrating business priority, code complexity, recalled defect density, new defect density, and graph node weights into the third formula to calculate execution priority, it ensures that high-risk, high-value, and highly relevant test cases are executed first. It can also predict test hours and test resources for test plans orchestrated according to execution priority, which is forward-looking and facilitates subsequent refined planning of test plans. At the same time, it can quantify the defect risks in the test plan and achieve proactive prevention and control of defect risks.

[0022] In a second aspect, the present invention provides a test case generation system, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test case generation method described in the first aspect.

[0023] The technical effects of the test case generation system provided in the second aspect are the same as those of the test case generation method provided in the first aspect. Attached Figure Description

[0024] Figure 1 This is a flowchart of a test case generation method provided in this embodiment; Figure 2 This is a schematic diagram of the overall process of a test case generation method provided in this embodiment; Figure 3This is a schematic diagram of the structure of a test case generation system provided in this embodiment.

[0025] [Explanation of Labels in the Attached Image] 1. A test case generation system; 2. Processor; 3. Memory. Detailed Implementation

[0026] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0027] Example 1 Please refer to Figures 1 to 2 This invention provides a method for achieving zero-intrusion dynamic data desensitization, comprising the following steps: S1. Collect the Git change records of the current version, extract all change line numbers, change timestamps, change depths and change operators of the Git change records, and use the time exponential decay model to change and weight all change line numbers, change timestamps and change depths. At the same time, in the process of changing and weighting, a penalty factor of author diversity entropy generated by the change operator is introduced to obtain the line-level change heat. In this embodiment, as Figure 2 As shown, the Git change history of the current version is collected, and all change line numbers, change timestamps, change depths, and change operators of the Git change history are extracted, i.e., multi-dimensional change features. A penalty factor of author diversity entropy is generated based on the change operator. A time exponential decay model is used to weight all change line numbers, change timestamps, and change depths. At the same time, the penalty factor of author diversity entropy is introduced in the process of weighting to obtain the line-level change popularity.

[0028] At this point, the time-exponential decay model described in step S1 is used to weight all changed line numbers, changed timestamps, and changed depths. Simultaneously, a penalty factor based on the author diversity entropy generated by the change operator is introduced during the weighting process to obtain the line-level change heat, including: S11. Obtain the number of newly added characters, the number of deleted characters, and the maximum value of the AST node change from the Git change record to calculate the change depth; S12. Input all changed line numbers, changed timestamps, and changed depths into a time-weighted index formula for weighting. Simultaneously, during the weighting process, a penalty factor based on the author diversity entropy generated by the change operator is introduced. The line-level change popularity is then calculated using a line-level popularity formula. The time-weighted index formula is as follows: ; in, This indicates the weighting of a single change in a Git change record r. Indicates the line number to be changed. Depth of change Indicates the line number to be changed. Change timestamp, This represents the current time, and T represents the decay half-life. Indicates the current attenuation coefficient; The formula for row-level heat is: ; in, Indicates the number of lines changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. This indicates the weighting of a single change in a Git change record. Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates that it has been modified. gather.

[0029] At this point, step S12, which involves simultaneously introducing the penalty factor of author diversity entropy generated by the change operator during the weighting process, includes: S121. Calculate the percentage of changes submitted by each change operator in the Git change log, input the percentage of changes into the author entropy formula, and calculate the corresponding author diversity entropy for the change operator. The author entropy formula is: ; in, Indicates a change of operator The entropy of author diversity Indicates a change of operator relative path, This represents the set of authors for the Git change record 'r'. Indicates a change of operator The percentage of changes; S122. Input the author diversity entropy of each change operator into the penalty formula for calculation to obtain the corresponding penalty factor for author diversity entropy. The penalty formula is as follows: ; in, Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates a change of operator The entropy of author diversity This represents the set of authors for the Git change record r.

[0030] In this embodiment, as Figure 2 As shown, the maximum values ​​of the number of newly added characters, the number of deleted characters, and the change amount of AST nodes are obtained from the Git change log. The change depth is calculated based on these values. All changed line numbers, change timestamps, and change depths are input into a time-weighted formula for weighting. The percentage of changes committed by each change operator in the Git change log is calculated. This percentage is then input into the author entropy formula to obtain the corresponding author diversity entropy for the change operator. The change percentage ∈ [0,1], and the author diversity entropy ∈ [0,1]. The author diversity entropy of each change operator is input into the penalty formula for calculation, resulting in a penalty factor for the corresponding author diversity entropy. The penalty factor takes values ​​∈ [0,1]. During the change weighting process, the penalty factor of the author diversity entropy generated by the change operator is introduced. Row-level change heat is calculated using the row-level heat formula. According to the author entropy formula and the penalty formula, if a change operator has a high change rate, their corresponding author diversity entropy will decrease. After transformation by the penalty formula, a larger penalty factor is obtained. According to the row-level heat formula, when the penalty factor is larger, the corresponding row-level change heat is lower. The change weighting values ​​are ∈ [0,1].

[0031] In this embodiment, the time-exponential decay model adopts a self-evolutionary approach. Closed-loop feedback mechanism Online self-evolution is achieved through a delayed label and AUC feedback loop, specifically as follows: 1. Constructing Delayed Labels: After each CI regression, the actual execution result of that regression is used as the sample label y to form ( y The triplet; 2. Calculate the smoothed AUC index: using As the predicted score, y is used as the true label to calculate the ROC-AUC, PR-AUC, or F1 index, which is used as the current AUC index. The AUC index is calculated using the sliding window exponential average to obtain the smoothed AUC index. The smoothed AUC index = 0.7 × current AUC index + 0.3 × previous AUC index. 3. Update the current decay coefficient: Using the first-order SGD algorithm, the gradient direction is approximated by finite difference, and the following update formula is applied. The update is performed using the following formula: ; ; in, This represents the current decay coefficient at the (k+1)th iteration. This represents the current decay coefficient at the k-th iteration. Indicates the learning rate. This represents the smoothed AUC index for the k-th iteration. This represents the smoothed AUC index for the (k-1)th iteration. This represents the current attenuation coefficient at the (k-1)th iteration; in, =0.01, the hard boundary of λ is [1×10 -3 [1×10], with an initial value of 0.05.

[0032] Furthermore, if the update directions are inconsistent for three consecutive times during the update process of λ, then λ will be frozen and an alarm will be triggered. 4. Snapshots and Rollbacks: After each update to λ, the current decay coefficient, smoothed AUC metric, and weighted image CID are written to the Git note to enable version tracking.

[0033] S2. Obtain the complete codebase of the current version, and extract the code call graph, code inheritance graph and data dependency graph from the complete codebase using static analysis tools to construct a code heterogeneity graph. Introduce the row-level change heat into the code heterogeneity graph and perform weight aggregation to generate an impact graph. At this point, step S2, which involves extracting code call graphs, code inheritance graphs, and data dependency graphs from the complete codebase using static analysis tools to construct a code heterogeneity graph, and then introducing the line-level change heat into the code heterogeneity graph and performing weight aggregation to generate an influence graph, includes: S21. Extract code call graph, code inheritance graph and data dependency graph from the complete code library using static analysis tools to construct a code heterogeneous graph containing multi-granularity entities, wherein the multi-granularity entities include lines of code, methods, classes and packages; S22. Calculate the number of times all classes and all methods are referenced in the code heterogeneity graph, generate the corresponding class static coupling degree and method static coupling degree, and collect the class production call frequency and method production call frequency of all classes and all methods through the production environment call chain to generate the corresponding class runtime heat and method runtime heat. S23. Introduce the line-level change heat into the code heterogeneity graph, combine the class static coupling degree, the method static coupling degree, the class runtime heat and the method runtime heat, perform weight aggregation according to the hierarchical relationship of code line, method, class and package, and perform cross-entity weight propagation through the lightweight GraphSAGE network to output the graph node weights with each granular entity as the node, so as to generate the influence graph.

[0034] In this embodiment, as Figure 2 As shown, the complete codebase of the current version is obtained. Static analysis tools are used to extract code call graphs, inheritance graphs, and data dependency graphs from the complete codebase to construct a code heterogeneity graph containing lines of code, methods, classes, and packages. The number of references for all classes and methods in the code heterogeneity graph is calculated to generate corresponding class static coupling and method static coupling. Simultaneously, the production call frequency of all classes and the production call frequency of all methods are collected through the production environment call chain to generate corresponding class runtime heat and method runtime heat. Line-level change heat is introduced into the code heterogeneity graph. Combined with class static coupling, method static coupling, class runtime heat, and method runtime heat, weights are aggregated according to the hierarchical relationship of lines of code, methods, classes, and packages. A lightweight GraphSAGE network is used for cross-entity weight propagation, outputting the graph node weights with each granularity entity as a node to generate an influence graph. The graph node weights can be expressed as: ; in, This represents the graph node weight of node j. Indicates the number of lines changed. The popularity of row-level changes Indicates the runtime popularity of the class. Indicates the runtime popularity of the method. Indicates the static coupling degree of a class. Represents the static coupling degree of the method. Indicates row-level weight. Indicates the class's runtime weight. Indicates the weight of the method execution. Indicates class coupling weights. Representation method coupling weights; Furthermore, the lightweight GraphSAGE network is a GraphSAGE network with a Weight-Mirror Layer inserted into the first layer of the GraphSAGE network. When performing weight propagation across entities, it writes a weight snapshot to IPFS and obtains the CID to write to a Git note during forward computation to achieve version tracking.

[0035] S3. Extract and execute the hotspot method from the influence map to generate a set of paths to be covered, and input the set of paths to be covered into the large language model to output recall test cases and new test cases.

[0036] At this point, step S3, which involves extracting and executing a hotspot method from the influence map to generate the set of paths to be covered, includes: S31. Obtain the graph node weight of each node in the influence graph, and sort all nodes in descending order according to the graph node weight to obtain the node sequence after descending order. S32. The methods corresponding to the top N nodes in the descending sorted node sequence are taken as hotspot methods, and the hotspot methods are executed to generate the current path conditions. S33. Obtain new path conditions from the change statement corresponding to each change line number, and make a feasibility judgment on each new path condition and the current path condition. If the current path condition and the new path condition cannot exist at the same time, then the new path condition is taken as the path to be covered. or S34. If there is no historical test case in the historical test case library that simultaneously contains the new path condition and the current path condition, then the new path condition shall be taken as the path to be covered. S35. Summarize all paths that need to be covered to generate a set of paths that need to be covered.

[0037] In this embodiment, as Figure 2As shown, nodes in the influence graph are obtained and sorted in descending order according to their node weights, resulting in a descending-sorted node sequence. The methods corresponding to the top N nodes in this sequence are designated as hotspot methods, where N is set to 5, but can be adjusted based on actual needs. The hotspot methods are executed to generate current path conditions. New path conditions are retrieved from the change statements corresponding to each change line number. A feasibility check is performed between the new and current path conditions. If the new and current path conditions cannot coexist, a new test case for the new path condition must be generated to cover the new branch; therefore, the new path condition is designated as the path to be covered. Alternatively, if no historical test case exists in the historical test case library that simultaneously contains both the new and current path conditions, then the new path condition is designated as the path to be covered. All paths to be covered are aggregated to generate a set of paths to be covered. This implements the binding of line-level changes in Git change records with execution paths.

[0038] At this point, step S3, which involves inputting the set of paths to be covered into a large language model to output recall test cases and new test cases, includes: S36. Match the set of paths to be covered with a pre-built triplet mapping table to obtain the function ID to be covered. The triplet mapping table is (class, method, function ID). S37. Calculate the cosine similarity between the function description text corresponding to the function ID to be covered and the historical test cases in the historical test case library, and output the historical test cases whose cosine similarity exceeds the first similarity threshold as recall test cases. In this embodiment, as Figure 2 As shown, the set of paths to be covered is matched with a pre-built triplet mapping table, which is (class, method, function ID), to obtain the function IDs to be covered. That is, the mapping from the paths to be covered to the function IDs to be covered is implemented. The cosine similarity between the function description text corresponding to the function ID to be covered and the historical test cases in the historical test case library is calculated. Historical test cases with a cosine similarity exceeding a first similarity threshold are output as recall test cases, where the first similarity threshold is 90%.

[0039] At this point, step S37, which involves outputting historical test cases whose cosine similarity exceeds the first similarity threshold, as recall test cases, includes: S371. Historical test cases whose cosine similarity exceeds the first similarity threshold are used as candidate recall test cases. S372. Count the number of business keywords in the function IDs that need to be covered, and input the number and the row-level change heat into the first formula to calculate the business priority. The first formula is: ; ; in, Indicates business priority. This indicates the runtime popularity of the classes in the path set that need to be covered. This indicates the runtime popularity of the methods in the set of paths that need to be covered. As the first weight, This indicates the file-level change popularity of the Git change record 'r' generated based on the row-level change popularity. Indicates the second weight. Indicate quantity, Indicates the third weight. Indicates the number of lines changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. Indicates the line number to be changed. The number of syntax nodes; S373. Calculate the defect density of the candidate recall test cases, and input the defect density, the business priority, and the cosine similarity into the second formula for calculation to obtain the final similarity. The second formula is: ; in, Indicates business priority. Indicates defect density, Represents cosine similarity. This indicates the weights of the graph nodes in the path set that need to be covered; S374. Select the recall test case with the highest final similarity from the candidate recall test cases as the final recall test case output.

[0040] In this embodiment, the recall test cases obtained in step S37 will be further screened in a finer granular manner. First, the recall test cases obtained in step S37 are used as candidate recall test cases. The number of business keywords in the function ID that needs to be covered is counted. The business keywords are pre-defined, such as login, payment, authentication, order, etc. The number and line-level change heat are input into the first formula for calculation to obtain the business priority. At the same time, the defect density of the candidate recall test cases is calculated, where the defect density refers to the ratio of the number of defects to the number of lines of code. The defect density, business priority and cosine similarity are input into the second formula for calculation to obtain the final similarity. The recall test case with the highest final similarity is selected from the candidate recall test cases as the final recall test case output.

[0041] S38. Combine the function description text corresponding to the function ID to be covered with the path set to be covered and the change code corresponding to the path set to be covered to construct a structured prompt template, so that the large language model can generate and output new test cases according to the structured prompt template.

[0042] In this embodiment, as Figure 2 As shown, the function description text corresponding to the function ID to be covered is combined with the set of paths to be covered and the change code corresponding to the set of paths to be covered to construct a structured prompt template. The structured prompt template includes the executor role definition, the preconditions, the core event flow, the steps and the expected output results, so that the large language model can generate new test cases that meet the set of paths to be covered based on the structured prompt template and output the new test cases.

[0043] In this embodiment, the output recall test cases and new test cases will be deduplicated. The specific deduplication steps are as follows: Calculate the AST structure fingerprint and sentence embedding vector for each recall test case and each new test case, and fuse the AST structure fingerprint and the corresponding sentence embedding vector to generate a composite fingerprint for each recall test case and a composite fingerprint for each new test case. Calculate the first similarity of the composite fingerprint among all recalled test cases, calculate the second similarity of the composite fingerprint among all new test cases, and calculate the third similarity of the composite fingerprint between each recalled test case and each new test case. Based on the first similarity, the second similarity, and the third similarity, all recall test cases and all new test cases are deduplicated to obtain deduplicated recall test cases and deduplicated new test cases.

[0044] In this embodiment, to streamline the size of the final output recall and new test cases, a dual-dimensional fingerprint of structure and semantics is used. Specifically, a composite fingerprint obtained by fusing and encoding the AST structure fingerprint and sentence embedding vector is used to deduplicate all test cases. That is, not only are the composite fingerprints between recall test cases compared to calculate the first similarity, but the composite fingerprints between new test cases are also compared to calculate the second similarity. Furthermore, the composite fingerprints of each recall test case and each new test case are compared to calculate the third similarity. Based on the first, second, and third similarities, all recall test cases and all new test cases are deduplicated. Recall test cases and new test cases with similarity exceeding the similarity threshold are deduplicated to obtain deduplicated recall test cases and deduplicated new test cases.

[0045] In this embodiment, the output recall test cases and new test cases will undergo subsequent test plan orchestration and test prediction. The specific steps are as follows: The execution priorities of the recalled test cases and the newly added test cases are calculated using a third formula, and the test plan is arranged according to the execution priorities. The third formula is: ; in, Indicates execution priority. Indicates business priority. This represents the graph node weight of node j corresponding to the recalled / added test cases in the influence graph. This indicates the code complexity of recalling / adding test cases. This represents the recall defect density of recall test cases / the new defect density of new test cases; The XGBoost regression model is used as the input vector to predict the test man-hours and test resources of the test plan, using the feature vector composed of the number of IDs of all function IDs involved in the test plan, the row-level change heat, the number of recalled test cases and the recalled defect density, the number of new test cases and the new defect density. The corresponding prediction results are obtained. At the same time, the defect risks of the test plan are quantified by Monte Carlo simulation to generate a risk heat map.

[0046] In this embodiment, the execution priority of recalled test cases and new test cases is calculated using a third formula, and the recalled and new test cases are arranged according to the execution priority to obtain the test plan. An XGBoost regression model is used as the input vector, consisting of the number of IDs of all function IDs involved in the test plan, row-level change popularity, the number of recalled test cases and the recalled defect density, and the number of new test cases and the new defect density, to predict the test man-hours and test resources of the test plan, obtaining the corresponding prediction results. The XGBoost regression model is built and trained offline using historical data and will be updated according to a preset period. The prediction results are expressed as follows: ; in, Indicates the prediction result. This represents the total number of CART regression trees. Indicates the first The tree weights of each CART regression tree. Indicates the first CART regression tree, Let b represent the input vector and b represent the bias term; Simultaneously, Monte Carlo simulation is used to quantify the defect risks of the test plan. When quantifying the defect risks of the test plan, Monte Carlo constructs a priori probability of single-function point defects based on the graph node weights of the nodes corresponding to recalled and newly added test cases in the influence graph. ; Where pdefect(j) represents the prior probability of a single-function point defect constructed based on the graph node weights of node j. This represents the Sigmoid function. This represents the graph node weight of node j corresponding to the recalled / added test cases in the influence graph. The sum of the new defect density and the recalled defect density is represented by , and cyclomatici represents the cyclomatic complexity generated based on the AST structure of the new and recalled test cases in the test plan. Represents the first regression coefficient. This represents the second regression coefficient. This represents the third regression coefficient; M sets of simulation results were generated using Monte Carlo sampling: ; in, This represents the simulation results of M groups, where pdefect(j) represents the prior probability of a single-function point defect constructed based on the graph node weights of node j. Indicates the number of rows changed. This represents the total number of changed rows. This indicates Bernoulli's experiment. This indicates the row number of the function point with row number i that has been changed. Indicates business priority; Calculate risk indicators based on the simulation results of Group M: ; in, Indicates defect risk / risk indicator. This represents the simulation results of group M. This represents the mean of the M simulation results. This represents the sample standard deviation of the simulation results for the M groups.

[0047] Risk indicators are mapped to pixel-level risk heatmaps according to function points and risk levels, and high-risk areas are highlighted.

[0048] Example 2 Please refer to Figure 3The present invention provides a test case generation system 1, including a memory 3, a processor 2, and a computer program stored in the memory 3 and executable on the processor 2. When the processor 2 executes the computer program, it implements the steps in Embodiment 1.

[0049] Since the systems / devices described in the above embodiments of the present invention are systems / devices used to implement the methods of the above embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the systems / devices based on the methods described in the above embodiments of the present invention, and therefore will not be repeated here. All systems / devices used in the methods of the above embodiments of the present invention fall within the scope of protection of the present invention.

[0050] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0051] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0052] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In claims that enumerate several means, several of these means may be embodied by the same hardware. The use of the terms first, second, third, etc., is merely for convenience of expression and does not indicate any order. These terms can be understood as part of the component names.

[0053] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0054] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0055] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A method for generating test cases, characterized in that, include: Collect the Git change history of the current version, extract all change line numbers, change timestamps, change depths and change operators of the Git change history, and use the time exponential decay model to change and weight all change line numbers, change timestamps and change depths. At the same time, during the change and weighting process, a penalty factor of author diversity entropy generated by the change operator is introduced to obtain the line-level change popularity. Obtain the complete codebase of the current version, and extract the code call graph, code inheritance graph, and data dependency graph from the complete codebase using static analysis tools to construct a code heterogeneity graph. Introduce the row-level change heat into the code heterogeneity graph and perform weight aggregation to generate an impact graph. The influence map is used to extract and execute a hotspot method to generate a set of paths to be covered. The set of paths to be covered is then input into a large language model to output recall test cases and new test cases.

2. The method for generating test cases as described in claim 1, characterized in that, The time-exponential decay model is used to weight all changed line numbers, changed timestamps, and changed depths. Simultaneously, a penalty factor based on the author diversity entropy generated by the change operator is introduced during the weighting process to obtain the line-level change heat, including: The change depth is calculated by obtaining the number of newly added characters, the number of deleted characters, and the maximum value of the AST node changes from the Git change records. All changed line numbers, changed timestamps, and changed depths are input into a time-weighted index formula for weighting. Simultaneously, a penalty factor based on the author diversity entropy generated by the change operator is introduced during the weighting process. The line-level change popularity is then calculated using a line-level popularity formula, which is: ； in, This indicates the weighting of a single change in a Git change record r. Indicates the line number to be changed. Depth of change Indicates the line number to be changed. Change timestamp, This represents the current time, and T represents the decay half-life. Indicates the current attenuation coefficient; The formula for row-level heat is: ； in, Indicates the line number to be changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. This indicates the weighting of a single change in a Git change record. Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates that it has been modified. gather.

3. The method for generating test cases as described in claim 2, characterized in that, The simultaneous introduction of the penalty factor of author diversity entropy generated by the change operator during the weighting process includes: Calculate the percentage of changes submitted by each change operator in the Git change log, input this percentage into the author entropy formula, and obtain the corresponding author diversity entropy for the change operator. The author entropy formula is: ； in, Indicates a change of operator The entropy of author diversity Indicates a change of operator relative path, This represents the set of authors for the Git change record 'r'. Indicates a change of operator The percentage of changes; The author diversity entropy of each change operator is input into the penalty formula for calculation, resulting in the corresponding penalty factor for author diversity entropy. The penalty formula is as follows: ； in, Indicates a change of operator The penalty factor for the generated author diversity entropy, Indicates a change of operator The entropy of author diversity This represents the set of authors for the Git change record r.

4. The method for generating test cases as described in claim 1, characterized in that, The process of extracting code call graphs, code inheritance graphs, and data dependency graphs from the complete codebase using static analysis tools to construct a code heterogeneity graph, and then introducing the line-level change heat into the code heterogeneity graph and performing weight aggregation to generate an influence graph includes: Static analysis tools are used to extract code call graphs, code inheritance graphs, and data dependency graphs from the complete codebase to construct a code heterogeneity graph containing multi-granularity entities, including lines of code, methods, classes, and packages; Calculate the number of times all classes and all methods are referenced in the code heterogeneity graph to generate the corresponding class static coupling degree and method static coupling degree. At the same time, collect the class production call frequency and the method production call frequency of all classes and all methods through the production environment call chain to generate the corresponding class runtime heat and method runtime heat. The line-level change heat is introduced into the code heterogeneity graph. Combined with the class static coupling degree, the method static coupling degree, the class runtime heat and the method runtime heat, weights are aggregated according to the hierarchical relationship of code line, method, class and package. The weights are propagated across entities through the lightweight GraphSAGE network to output the graph node weights with each granular entity as the node, so as to generate the influence graph.

5. The method for generating test cases as described in claim 1, characterized in that, The step of extracting and executing a hotspot method from the influence map to generate the set of paths to be covered includes: Obtain the graph node weight of each node in the influence graph, and sort all nodes in descending order according to the graph node weight to obtain the node sequence after descending order. The methods corresponding to the top N nodes in the descending sorted node sequence are taken as hot methods, and the hot methods are executed to generate the current path conditions. Obtain the new path condition from the change statement corresponding to each change line number, and perform a feasibility judgment on each new path condition and the current path condition. If the current path condition and the new path condition cannot exist at the same time, then the new path condition is taken as the path to be covered. or If there is no historical test case in the historical test case library that contains both the new path condition and the current path condition, then the new path condition will be the path to be covered. All paths that need to be covered are summarized to generate a set of paths that need to be covered.

6. The method for generating test cases as described in claim 1, characterized in that, The step of inputting the set of paths to be covered into a large language model to output recall test cases and new test cases includes: The set of paths to be covered is matched with a pre-built triplet mapping table to obtain the function IDs to be covered. The triplet mapping table is (class, method, function ID). Calculate the cosine similarity between the function description text corresponding to the function ID to be covered and the historical test cases in the historical test case library, and output the historical test cases whose cosine similarity exceeds the first similarity threshold as recall test cases; The function description text corresponding to the function ID to be covered is combined with the set of paths to be covered and the change code corresponding to the set of paths to be covered to construct a structured prompt template, so that the large language model can generate and output new test cases based on the structured prompt template.

7. The method for generating test cases as described in claim 6, characterized in that, The step of outputting historical test cases whose cosine similarity exceeds the first similarity threshold as recall test cases includes: Historical test cases whose cosine similarity exceeds the first similarity threshold are used as candidate recall test cases; Count the number of business keywords in the function IDs that need to be covered, input the number and the row-level change popularity into the first formula to calculate the business priority. The first formula is: ； ； in, Indicates business priority. This indicates the runtime popularity of the classes in the path set that need to be covered. This indicates the runtime popularity of the methods in the set of paths that need to be covered. As the first weight, This indicates the file-level change popularity of the Git change record 'r' generated based on the row-level change popularity. Indicates the second weight. Indicate quantity, Indicates the third weight. Indicates the number of lines changed. The popularity of row-level changes Indicates a relative path. Indicates a change in line number. Indicates the line number to be changed. The number of syntax nodes; Calculate the defect density of candidate recall test cases, and input the defect density, the business priority, and the cosine similarity into a second formula to obtain the final similarity. The second formula is: ； in, Indicates business priority. Indicates defect density, Represents cosine similarity. This indicates the weights of the graph nodes in the path set that need to be covered; The final recall test case is selected from the candidate recall test cases and the one with the highest similarity is output as the final recall test case.

8. The method for generating test cases as described in claim 1, characterized in that, The step of inputting the set of paths to be covered into a large language model to output recall test cases and new test cases includes: Calculate the AST structure fingerprint and sentence embedding vector for each recall test case and each new test case, and fuse the AST structure fingerprint and the corresponding sentence embedding vector to generate a composite fingerprint for each recall test case and a composite fingerprint for each new test case. Calculate the first similarity of the composite fingerprint among all recalled test cases, calculate the second similarity of the composite fingerprint among all new test cases, and calculate the third similarity of the composite fingerprint between each recalled test case and each new test case. Based on the first similarity, the second similarity, and the third similarity, all recall test cases and all new test cases are deduplicated to obtain deduplicated recall test cases and deduplicated new test cases.

9. The method for generating test cases as described in claim 1, characterized in that, Also includes: The execution priorities of the recalled test cases and the newly added test cases are calculated using a third formula, and the test plan is arranged according to the execution priorities. The third formula is: ； in, Indicates execution priority. Indicates business priority. This represents the graph node weight of node j corresponding to the recalled / added test cases in the influence graph. This indicates the code complexity of recalling / adding test cases. This represents the recall defect density of recall test cases / the new defect density of new test cases; The XGBoost regression model is used as the input vector to predict the test man-hours and test resources of the test plan, using the feature vector composed of the number of IDs of all function IDs involved in the test plan, the row-level change heat, the number of recalled test cases and the recalled defect density, the number of new test cases and the new defect density. The corresponding prediction results are obtained. At the same time, the defect risks of the test plan are quantified by Monte Carlo simulation to generate a risk heat map.

10. A test case generation system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

Images