Test suite generation method and device, electronic equipment and storage medium

Abstract

The invention discloses a test suite generation method and device, electronic equipment and a storage medium, belongs to the technical field of software engineering, and is used for solving the problem that a test suite generated by a related test suite generation technology is poor in quality. The method comprises the steps of obtaining a plurality of test cases, and performing feature extraction on the test cases to obtain input features, execution features and coverage features of the test cases; the coverage feature is determined based on code coverage information of the test case and function demand coverage information; constructing a feature vector of the test case based on the input feature, the execution feature and the coverage feature; based on the feature vectors of the test cases, grouping the test cases through an improved clustering algorithm to obtain a plurality of test case sets; and for each test case set, based on the feature vector, performing redundant test case identification to obtain an identification result, and based on the identification result and the test case set, generating a test suite.

Description

Technical Field

[0001] This application belongs to the field of software engineering technology, and specifically relates to a test suite generation method, apparatus, electronic device and storage medium. Background Technology

[0002] Related test suite generation technologies streamline traditional test suites based on code coverage and test execution results.

[0003] However, using test execution results as the basis for similarity judgment ignores the differentiated value of failed test cases; the redundancy judgment of temporarily passing test cases fails, as these test cases may pass intermittently in multiple executions, and decisions based on a single result are prone to accidental deletion. Furthermore, related test suite generation technologies ignore the temporal characteristics and state evolution of test cases. For example, process testing from policy contract to policy maintenance to claims and simple policy contract testing may cover the same code modules, but the related test suite generation technologies cannot identify the progressive relationship of their business processes, easily leading to accidental deletion.

[0004] In other words, the relevant test suite generation technology suffers from poor quality in the generated test suites. Summary of the Invention

[0005] This application provides a test kit generation method, apparatus, electronic device, and storage medium, which can solve the problem of poor quality of the generated test kits in related test kit generation technologies.

[0006] In a first aspect, embodiments of this application provide a test suite generation method, the method comprising: acquiring multiple test cases, and extracting features from the test cases to obtain input features, execution features, and coverage features of the test cases; the coverage features are determined based on code coverage information and functional requirement coverage information of the test cases; constructing feature vectors of the test cases based on the input features, the execution features, and the coverage features; grouping the test cases into multiple test case sets using an improved clustering algorithm based on the feature vectors of the test cases; for each test case set, identifying redundant test cases based on the feature vectors to obtain identification results, and generating a test suite based on the identification results and the test case sets.

[0007] Secondly, embodiments of this application provide a test suite generation apparatus, the apparatus comprising: an acquisition module, configured to acquire multiple test cases and extract features from the test cases to obtain input features, execution features, and coverage features of the test cases; the coverage features are determined based on code coverage information and functional requirement coverage information of the test cases; a construction module, configured to construct the feature vector of the test cases based on the input features, the execution features, and the coverage features; a grouping module, configured to group the test cases based on the feature vector of the test cases using an improved clustering algorithm to obtain multiple test case sets; and a generation module, configured to identify redundant test cases for each test case set based on the feature vector, obtain an identification result, and generate a test suite based on the identification result and the test case set.

[0008] Thirdly, embodiments of this application provide an electronic device comprising: a processor; and a memory arranged to store computer-executable instructions configured to be executed by the processor, the executable instructions including instructions for performing the test suite generation method as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a storage medium for storing computer-executable instructions that cause a computer to perform the test suite generation method as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the test suite generation method as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the test suite generation method as described in the first aspect.

[0012] In this embodiment, multiple test cases are acquired, and feature extraction is performed on the test cases to obtain input features, execution features, and coverage features. The coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. Based on the input features, execution features, and coverage features, the feature vector of the test cases is constructed. Based on the feature vector of the test cases, the test cases are grouped using an improved clustering algorithm to obtain multiple test case sets. For each test case set, redundant test cases are identified based on the feature vector to obtain identification results. Based on the identification results and the test case sets, a test suite is generated. Compared with related test suite generation technologies that simplify traditional test suites based on code coverage and test execution results, this application extracts feature vectors for constructing test cases using multi-dimensional features (i.e., input features, execution features, and coverage features) and uses an improved clustering algorithm to group the test cases, resulting in a more accurate set of test cases. Based on this, redundant test cases are identified based on the feature vectors to obtain accurate identification results. This allows for maintaining test coverage and fault detection capabilities while reducing the size of the test suite, generating a high-quality test suite. The problem of poor quality in the generated test suites has been addressed by the relevant test suite generation technology. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a test kit generation method provided in an embodiment of this application; Figure 2 A comparative chart showing the impact of abnormal test cases on clustering quality when using different clustering algorithms, provided as an embodiment of this application; Figure 3 A flowchart illustrating another test kit generation method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a test kit generation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0016] The test kit generation method, apparatus, electronic device, and storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0017] Figure 1 This illustration shows a test suite generation method provided by an embodiment of the present invention. The method can be executed by an electronic device, which may include a server and / or a terminal device, wherein the terminal device may be, for example, an in-vehicle terminal or a mobile phone terminal. In other words, the method can be executed by software or hardware installed on the electronic device, and the method includes the following steps: S102: Obtain multiple test cases and extract features from the test cases to obtain the input features, execution features, and coverage features of the test cases.

[0018] Among them, the coverage features are determined based on the code coverage information of test cases and the functional requirement coverage information.

[0019] In practical applications, input features of test cases can be extracted by analyzing their input parameters, boundary conditions, and input domain. Specifically, hash encoding can be used to convert string-type parameters in test cases into numerical features, achieving feature quantification. For numerical parameters in test cases, boundary value analysis, value range partitioning, and normalization can be used to obtain normalized numerical features, ensuring the comparability of parameters with different dimensions. For Boolean and enumerated parameters in test cases, one-hot encoding is used to preserve parameter type information. Furthermore, the documentation and comments of test cases can be analyzed to extract keywords related to the test intent and construct a test intent vector. Thus, based on one or more of the test intent vector, numerical features, normalized numerical features, and one-hot encoding, the input features of the test case are formed.

[0020] Instrumentation techniques can be used to record the function call sequence, execution path, exception handling path, and state transitions during test case execution, thereby extracting the execution characteristics of the test cases. Specifically, the function call sequence can be encoded using an N-gram model to convert it into function call sequence features, capturing the sequential relationships and contextual dependencies of function calls. For the execution path, branch coverage analysis is performed to obtain execution path features. For the exception handling path, exception types and handling methods are extracted to construct exception handling features, reflecting the test case's ability to verify exceptions. By analyzing the system state changes during test case execution, the trajectory of key state variables is recorded, forming a state transition feature vector. Thus, based on one or more of the function call sequence features, execution path features, exception handling features, and state transition feature vectors of the test case, the execution characteristics of the test case are constructed, providing dynamic behavioral features for subsequent clustering analysis. For example, the execution characteristics of the test case are constructed based on the function call sequence features, execution path features, exception handling features, and state transition feature vectors of the test case, along with their corresponding weight factors of 0.35, 0.25, 0.20, and 0.20, respectively.

[0021] Coverage features are determined based on two dimensions: code coverage information and functional requirement coverage information for test cases. In practical applications, lightweight instrumentation tools can be used to collect code coverage and functional requirement coverage information, thus minimizing the impact on test execution performance and allowing application to large-scale test suites. Specifically, both code coverage and functional requirement coverage information for test cases can include the coverage information of code elements by the test cases, such as statements and methods. For functional requirement coverage information, a requirement coverage matrix can be constructed to represent it. By constructing the requirement coverage matrix, a mapping relationship between test cases and requirement items is established, thereby reflecting the verification status of test cases for functional and non-functional requirements. That is, the functional requirement coverage information of test cases can also include coverage information for each functional and non-functional requirement.

[0022] Coverage features can be specifically represented using binary vectors. For example, a coverage feature could be:

[0023] in, Represents test cases Coverage features, This represents the coverage information for the j-th code element, where 1 indicates coverage and 0 indicates no coverage, and n is the total number of code elements.

[0024] Furthermore, there are no specific limitations on the acquisition of test cases; for example, the aforementioned test cases can be obtained from the test suite to be streamlined.

[0025] S104: Construct feature vectors for test cases based on input features, execution features, and coverage features.

[0026] Specifically, the input features, execution features, and coverage features can first be standardized to obtain standardized input features, standardized execution features, and standardized coverage features, thus eliminating the influence of dimensions and making the features comparable. Then, based on the standardized input features, standardized execution features, standardized coverage features, and corresponding preset first weights, second weights, and third weights, the feature vector of the test case can be generated. Of course, the feature vector of the test case can also be generated directly based on the input features, execution features, coverage features, and corresponding preset first weights, second weights, and third weights.

[0027] The first, second, and third weights can be adjusted according to different testing scenarios. Principal component analysis can be used to generate feature vectors for test cases, thereby reducing feature dimensionality, preserving key feature information, and reducing computational complexity. The resulting feature vectors comprehensively reflect the input, execution, and coverage features of the test cases, providing high-quality data representation for subsequent grouping.

[0028] For example, the feature vector of the test case can be generated based on the input features, execution features, and coverage features, as well as the corresponding preset first weight, second weight, and third weight, as shown in the following formula (1): (1) in, Represents test cases eigenvectors, , as well as , representing the input feature vector, the executed feature, and the covered feature, respectively. , as well as The weights are the first weight, the second weight, and the third weight, respectively, satisfying... .

[0029] S106: Based on the feature vectors of test cases, the test cases are grouped using an improved clustering algorithm to obtain multiple test case sets.

[0030] Improved clustering algorithms include one or more improvements such as optimizing the selection of initial centroids, adaptively adjusting the number of clusters, and introducing outlier handling mechanisms. Specifically, the clustering algorithm can be the K-means clustering algorithm.

[0031] S108: For each set of test cases, redundant test cases are identified based on feature vectors to obtain the identification results, and a test suite is generated based on the identification results and the set of test cases.

[0032] Specifically, for each test case set, based on the code coverage and functional requirement coverage information of the test cases in the cluster set, a representative test case can be determined. The representative test case is the test case with the highest coverage score in that cluster set, determined based on the code coverage and functional requirement coverage information. The test case with the highest coverage score is, for example, the test case with the highest product or weighted average of code coverage rate and functional requirement coverage rate in the cluster set, determined based on code coverage and functional requirement coverage information. The similarity between the feature vectors of the remaining test cases and the feature vector of the representative test case is determined, as is the overlap between the coverage features of the remaining test cases and the coverage features of the representative test case. The remaining test cases are those other than the representative test case in the test case set. Based on the similarity and overlap between the remaining test cases and the representative test case, the redundancy between the remaining test cases and the representative test case is determined. Based on the redundancy and a preset redundancy threshold, an identification result characterizing whether a test case is redundant is determined, and a test suite is generated based on the identification result and the test case set. Specifically, the similarity between the feature vectors of the remaining test cases and the feature vectors of the test case representative is determined, and the overlap between the coverage features of the remaining test cases and the coverage features of the test case representative is determined; and, based on the similarity and overlap between the remaining test cases and the test case representative, the redundancy between the remaining test cases and the test case representative is determined, as detailed in steps C3 to C4 below.

[0033] The test suite generation method provided in this invention obtains multiple test cases and extracts features from them to obtain input features, execution features, and coverage features. Coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. Based on the input features, execution features, and coverage features, feature vectors for the test cases are constructed. Based on the feature vectors, an improved clustering algorithm is used to group the test cases, resulting in multiple test case sets. For each test case set, redundant test cases are identified based on the feature vectors, yielding identification results. Based on the identification results and the test case sets, a test suite is generated. Compared to related test suite generation technologies that simplify traditional test suites based on code coverage and test execution results, this application extracts feature vectors for constructing test cases using multi-dimensional features (i.e., input features, execution features, and coverage features) and uses an improved clustering algorithm to group the test cases, resulting in a more accurate set of test cases. Furthermore, based on the feature vectors, redundant test cases are identified, yielding accurate identification results. This allows for maintaining test coverage and fault detection capabilities while reducing the size of the test suite, generating a high-quality test suite. The problem of poor quality in the generated test suites has been addressed by the relevant test suite generation technology.

[0034] In one implementation, based on the feature vectors of the test cases, an improved clustering algorithm is used to group the test cases to obtain multiple test case sets (i.e., S106), and the following steps A1 to A2 can be executed: Step A1: Determine multiple initial center points from the feature vectors of multiple test cases.

[0035] Optionally, multiple initial center points can be determined from the feature vectors of multiple test cases through the following steps A1.1 to A1.3; alternatively, multiple feature vectors can be randomly determined from the feature vectors of multiple test cases as initial center points.

[0036] Step A2: Repeat steps A2.1 to A2.4 until the evaluation metrics of the clusters meet the preset conditions. Based on the test cases corresponding to the first number of clusters, determine multiple test case sets: Step A2.1: Determine the number of the first clusters, and based on the number of the first clusters and the initial centroids, iteratively generate clusters using a preset clustering algorithm.

[0037] Specifically, the initial centroids for the first number of clusters are determined from the initial centroids and used as cluster centroids. Then, based on the cluster centroids, clustering is performed using a preset clustering algorithm to iteratively generate clusters.

[0038] During the loop execution, when step A2.1 is executed for the first time, the silhouette coefficient method and interval statistics can be used to estimate the number of the first cluster.

[0039] Step A2.2: Determine the evaluation metrics for the clusters.

[0040] The evaluation metrics include intra-cluster dispersion, inter-cluster distance, and / or the Davies-Bouldin index. The Davies-Bouldin index is the ratio of intra-cluster dispersion to inter-cluster distance. Intra-cluster dispersion is the average distance from a point within a cluster to the cluster center. Inter-cluster distance is the minimum distance between cluster centers.

[0041] Step A2.3: Determine whether the evaluation index of the cluster meets the preset conditions.

[0042] If the evaluation metrics of a cluster meet the preset conditions, then multiple test case sets are determined based on the test cases corresponding to the first number of clusters. Specifically, the first number of clusters can be used as the first number of test case sets.

[0043] Step A2.4: If the evaluation index of the cluster does not meet the preset conditions, then determine the number of the second cluster based on the evaluation index, and use the number of the second cluster as the number of the first cluster.

[0044] The preset conditions correspond to the evaluation metrics. Evaluation metrics include the intra-cluster dispersion, inter-cluster distance, and / or the Davies-Bouldin index. The preset conditions may include one or more of the following: the intra-cluster dispersion is lower than a preset intra-cluster dispersion threshold; the inter-cluster distance is greater than a preset inter-cluster distance threshold; and the Davies-Bouldin index is less than or equal to a preset index value. For example, if the evaluation metric includes intra-cluster dispersion, the preset conditions may include the intra-cluster dispersion being lower than a preset intra-cluster dispersion threshold. If the evaluation metric includes inter-cluster distance and the Davies-Bouldin index, the preset conditions may include the inter-cluster distance being greater than a preset inter-cluster distance threshold and the Davies-Bouldin index being less than or equal to a preset index value. There are various combinations of evaluation metrics, and corresponding preset conditions exist in various ways, which will not be elaborated here.

[0045] For example, if the intra-cluster dispersion of a cluster is higher than a preset intra-cluster dispersion threshold, the current number of the first cluster is increased to obtain the number of the second cluster; if the inter-cluster distance of a cluster is lower than a preset inter-cluster distance threshold, the current number of the first cluster is decreased to obtain the number of the second cluster.

[0046] In this embodiment, an improved clustering algorithm is designed. By adaptively adjusting the number of clusters, the optimal number of clusters (i.e., the first number of clusters) can be dynamically determined according to the actual distribution characteristics of the test cases, thereby improving the accuracy and interpretability of the clustering results.

[0047] In one implementation, determining multiple initial center points (i.e., step A1) from the feature vectors of multiple test cases can be achieved by executing steps A1.1 to A1.3 as follows: Step A1.1: Calculate the local density of the feature vector for each test case, and determine the potential centroids by sorting the feature vectors based on the local density and the preset number of potential centroids.

[0048] Specifically, based on the local density of the feature vectors, the feature vectors are sorted to obtain multiple sorted feature vectors. Then, a preset number of feature vectors are selected from the beginning of the sorted feature vectors and used as potential center points.

[0049] The local density of the feature vector can be calculated using the following formula (2): (2) in, Let exp(x) be the local density of the i-th eigenvector, and let exp(x) represent the natural exponential function, which is an exponential function with the real number e as the base. and Let them be any two eigenvectors; This is the preset bandwidth parameter.

[0050] Step A1.2: For each potential center point, calculate the first distance between the potential center point and the target potential center point, and determine multiple candidate center points among the potential center points based on the first distance and local density.

[0051] Among them, the target potential center point is the potential center point with a local density greater than that of the potential center point and the closest potential center point.

[0052] Specifically, multiple candidate center points are determined from the potential center points using a first distance, local density, and a preset selection threshold. A candidate center point is a potential center point whose product of the first distance and local density is greater than or equal to the preset selection threshold.

[0053] At this point, multiple candidate center points can be directly used as multiple initial center points. In addition, a center point conflict detection mechanism is designed to ensure the minimum distance between initial center points and prevent the selection of points that are too close. That is, step A1.3 can also be performed to prevent the determined initial center points from having too high similarity, which would affect the quality of the clustering results.

[0054] Step A1.3: Determine the second distance between candidate center points, and determine multiple initial center points among the candidate center points based on the second distance and a preset first distance threshold.

[0055] Specifically, candidate center points whose second distance is greater than a preset first distance threshold are used as initial center points.

[0056] In this embodiment, an improved clustering algorithm is designed to optimize the selection of initial centroids, thereby improving the quality of the generated test case set.

[0057] In one implementation, before determining multiple initial centroids in the feature vectors of multiple test cases (i.e., step A1), step B1 can also be performed as follows: Step B1: Based on the feature vector, detect multiple corresponding test cases to obtain abnormal test cases.

[0058] Specifically, the Local Outlier Factor (LOF) algorithm can be used to detect multiple test cases and obtain abnormal test cases.

[0059] After calculating the first distance between the potential center point and the target potential center point (i.e., step A1.2), step B2 can also be performed as follows: Step B2: Calculate the third distance between the feature vector of the abnormal test case and the target potential center point, and determine the boundary test cases based on the third distance and the preset second distance threshold.

[0060] Specifically, abnormal test cases where the third distance is greater than or equal to the preset second distance threshold are designated as boundary test cases. By first identifying abnormal test cases and then determining boundary test cases from among them, the identified boundary test cases are more accurate. Therefore, boundary test cases are categorized separately to prevent them from interfering with normal clustering.

[0061] Based on the test cases corresponding to the first number of clusters, multiple test case sets are determined (i.e., step A2), which can be executed as follows: steps B3 to B4: Step B3: Based on the test cases corresponding to the clusters, determine the initial test case set of the first cluster number, and based on the feature vectors, determine the membership degree of the boundary test cases to the initial test case set.

[0062] Specifically, fuzzy clustering can be used to calculate the membership degree of boundary test cases to each initial test case set.

[0063] Step B4: Based on the preset membership threshold and membership, determine the number of test cases for the third cluster.

[0064] Specifically, if the membership degree of a boundary test case to any initial test case set is greater than or equal to a preset membership degree threshold, then according to the maximum membership degree principle, the boundary test case is assigned to each initial test case set based on its membership degree, generating a test case set. The number of the third cluster is the current number of the first cluster. If the membership degree of a boundary test case to any initial test case set is less than the preset membership degree threshold, then that boundary test case can be treated as a separate test case set. Therefore, the number of the third cluster can be determined based on the current number of the first cluster and the boundary test cases with membership degrees less than the preset membership degree threshold.

[0065] For example, taking the K-means clustering algorithm as an example, this embodiment compares the impact of the improved K-means algorithm and the standard K-means algorithm in related technologies on clustering quality as the proportion of outliers (abnormal test cases) gradually increases. Figure 2 As shown.

[0066] In this embodiment, an improved clustering algorithm is designed and an outlier handling mechanism is introduced to improve the stability and accuracy of the algorithm.

[0067] In one implementation, before identifying redundant test cases based on feature vectors for each set of test cases and obtaining the identification result (i.e., S108), the following step C1 can also be performed: Step C1: Based on the code coverage information and functional requirement coverage information of test cases in multiple test case sets, determine the initial test suite, and determine the cluster set according to the initial test suite and test case set.

[0068] Based on the code coverage and functional requirement coverage information of test cases in multiple test case sets, an initial test suite is determined, as detailed in step c1 below. According to the correspondence between the test cases in the initial test suite and the test cases in the multiple test case sets, the test cases in the initial test suite are grouped to generate cluster sets.

[0069] Accordingly, for each set of test cases, redundant test cases are identified based on feature vectors to obtain identification results. Based on the identification results and the set of test cases (i.e., S108), the following steps C2 to C5 can be executed: Step C2: For each cluster set, based on the code coverage information and functional requirement coverage information of the test cases in the cluster set, determine the representative of the test cases in the cluster set.

[0070] The test case in this cluster represents the test case with the highest coverage score. The coverage score is determined based on code coverage information and functional requirement coverage information. The test case with the highest coverage score is, for example, the test case with the highest product or weighted average of code coverage rate and functional requirement coverage rate in the cluster determined based on code coverage information and functional requirement coverage information.

[0071] Step C3: Determine the similarity between the feature vectors of the remaining test cases and the feature vectors represented by the test cases, and determine the overlap between the coverage features of the remaining test cases and the coverage features represented by the test cases.

[0072] The remaining test cases are those in the cluster set other than the test case representative.

[0073] Specifically, the similarity between the feature vectors of the remaining test cases and the feature vectors represented by the test cases can be determined using Euclidean distance or cosine similarity. The overlap between the coverage features of the remaining test cases and the coverage features represented by the test cases can be determined by calculating the ratio of the intersection to the union of their coverage features using the Jaccard coefficient.

[0074] Step C4: Determine the redundancy between the remaining test cases and the test case representative based on similarity and overlap.

[0075] For example, redundancy can be determined based on the similarity and overlap between the feature vectors of the remaining test cases and the feature vectors represented by the test cases, using the following formula (3): R(ti,tj)=ω1 S(V(ti),V(tj))+ω2 J(C(ti),C(tj))(3) Where R(ti,tj) represents the redundancy between test case representative ti and the remaining test cases tj; S(V(ti),V(tj)) represents the similarity between the feature vectors of the remaining test cases and the feature vectors of the test case representative; J(C(ti),C(tj)) represents the overlap between the coverage features of the remaining test cases and the coverage features of the test case representative; ω1 and ω2 are the preset fourth and fifth weights, respectively, satisfying ω1+ω2=1.

[0076] Step C5: Based on redundancy and a preset redundancy threshold, determine the identification result that characterizes whether the test cases are redundant, and generate a test suite based on the identification result and the cluster set.

[0077] Specifically, if the redundancy is greater than a preset redundancy threshold, the remaining test cases are determined to be redundant. If the redundancy is less than or equal to the preset redundancy threshold, the remaining test cases are determined not to be redundant.

[0078] In practical applications, redundancy markers for test cases can be determined based on their coverage characteristics and the identification results indicating whether test cases are redundant. Redundancy markers include non-redundant test case markers, necessary redundant test case markers, and redundant test case markers. Test suites are generated based on the redundancy markers and cluster sets of test cases. Specifically, if a test case is redundant, but its coverage characteristics determine that it has a unique coverage path or covers key functional requirements within the cluster set, then the redundancy marker for that test case is determined to be a necessary redundant test case marker.

[0079] In this embodiment, by designing a redundancy metric based on similarity and overlap, the redundancy relationship between test cases is quantified into comparable values, thereby accurately simplifying the test suite.

[0080] In one implementation, based on the code coverage information and functional requirement coverage information of test cases in multiple test case sets, an initial test suite is determined (i.e., step C1), which can be performed as follows: Step c1: Based on the code coverage information and functional requirement coverage information of test cases in multiple test case sets, as well as the preset coverage matrix, the test cases with the largest coverage gain are iteratively selected through an improved greedy algorithm until the target code elements in the coverage matrix are covered, or the coverage rate of the coverage matrix reaches the preset coverage rate threshold, to obtain the initial test suite.

[0081] Among them, code coverage information and functional requirement coverage information include coverage information of code elements; coverage gain is the ratio of the coverage increment of code elements between two test cases in the test case set to the execution cost information corresponding to the coverage increment.

[0082] The matrix to be covered consists of multiple code elements. The target code element is the code element in the matrix to be covered that is designated as needing to be covered.

[0083] The coverage increment is the incremental increase in code element coverage between two test cases. For example, if test case A covers 17 code elements and test case B covers 15 code elements, then the 2 additional code elements covered by test case A compared to test case B constitute the coverage increment. The execution cost information corresponding to the coverage increment includes, for example, the number of code lines corresponding to those 2 code elements.

[0084] In this embodiment, the improved greedy algorithm iteratively selects the test cases with the greatest coverage gain, simplifies the test cases, and can significantly reduce the size of the test suite while ensuring the effectiveness of the test. This generates a simplified initial test suite and reduces the test execution cost, thereby reducing the number of test cases to be checked for redundancy.

[0085] In one implementation, a test suite (i.e., S108) is generated based on the identification results and the test case set, and the following steps D1 to D2 can be executed: Step D1: Based on the coverage characteristics of the test cases and the identification results of whether the test cases are redundant, determine the redundancy markers of the test cases.

[0086] Redundancy markers include non-redundant test case markers, necessary redundant test case markers, and redundant test case markers.

[0087] If a test case is redundant, but its coverage characteristics determine that it has a unique coverage path or covers key functional requirements in the cluster set, then the redundancy mark of the test case is determined as a necessary redundant test case mark.

[0088] Step D2: Generate a test suite based on the redundancy markers and test case set of the test cases.

[0089] Specifically, a test suite can be generated based on test cases that are redundantly marked as non-redundant test cases and those marked as necessary redundant test cases in the test case set. Furthermore, multiple target test cases that are redundantly marked as necessary redundant test cases and whose functional requirement coverage information similarity is greater than a preset threshold can be merged to generate a new test case. A test suite can then be generated based on this new test case, the redundant test cases marked as necessary redundant test cases (excluding the target test case), and the test cases marked as non-redundant test cases, thereby reducing the size of the test suite while maintaining functional coverage.

[0090] Considering that the quality of the test suite may decrease after simplification, a simplification quality assurance mechanism was designed to ensure that the quality of the test suite does not decrease significantly after simplification. This mechanism involves conducting multi-dimensional quality assessments of the test suite and using incremental simplification strategies and rollback mechanisms to ensure the effectiveness of the simplified test suite.

[0091] Specifically, during the execution of steps C5, C1, and S108, there are test cases to be removed during the generation of test suites or initial test suites. These test cases are decomposed into multiple batches of test cases. For each batch of test cases removed, a quality assessment index is determined for the test suites or initial test suites formed from the test cases outside the removed batches. If the quality assessment index is greater than or equal to a preset index threshold, the next batch of test cases is removed. If the quality assessment index is lower than the preset index threshold, the test cases to be retained in the next batch are determined based on the quality assessment index and the test cases in the next batch, and the test cases in the next batch are removed except for those to be retained. If the quality assessment index is lower than the rollback trigger threshold, the test cases to be rolled back are determined based on the quality assessment index and the test cases in the removed batch, wherein the rollback trigger threshold is lower than the preset index threshold. Afterward, a test suite or initial test suite is formed based on the test cases to be rolled back and the test cases outside the removed batches. The quality assessment metrics include at least the code coverage, functional requirement coverage, fault detection capability, and anomaly detection capability of the test suite or initial test suite. For example, the corresponding preset metric thresholds can be 0.95, 0.98, 0.9, and 0.93, respectively, and the rollback trigger thresholds can be 0.9, 0.95, 0.85, and 0.88, respectively. It should be noted that the above examples are for ease of understanding only and do not impose specific limitations on the preset metric thresholds and rollback trigger thresholds.

[0092] Of course, the test suite can also be scored for quality. If the quality score of the test suite is lower than the preset quality score, the test suite is regenerated. For example, the quality score of the test suite can be calculated using the following formula (4): (4) in, This indicates the quality score of the test suite; and These represent the coverage of the test suite and the overall coverage of the test cases in S102, respectively. , These represent the fault detection capability of the test suite and the overall fault detection capability of the test cases in S102, respectively. , These represent the size information of the test cases in the test suite and the size information of the test cases in S102, respectively; α, β and γ are the preset sixth weight, seventh weight and eighth weight, respectively.

[0093] Figure 3 This is a flowchart illustrating another test suite generation method provided in an embodiment of this application. Figure 3 As shown, the method includes: Step 302: Obtain multiple test cases and extract features from the test cases to obtain the input features, execution features, and coverage features of the test cases.

[0094] Among them, the coverage features are determined based on the code coverage information of test cases and the functional requirement coverage information.

[0095] Step 304: Construct feature vectors for test cases based on input features, execution features, and coverage features.

[0096] Step 306: Calculate the local density of the feature vector for each test case, and determine the potential center points by sorting the feature vectors based on the local density and the preset number of potential center points.

[0097] Step 308: For each potential center point, calculate the first distance between the potential center point and the target potential center point, and determine multiple candidate center points among the potential center points based on the first distance and local density; wherein, the target potential center point is the potential center point with a local density greater than that of the potential center point and the closest distance to the potential center point.

[0098] Step 310: Determine the second distance between candidate center points, and determine multiple initial center points among the candidate center points based on the second distance and a preset first distance threshold.

[0099] Repeat steps 312 to 318 until the evaluation metrics of the clusters meet the preset conditions. Based on the test cases corresponding to the first number of clusters, determine multiple test case sets: Step 312: Determine the number of the first clusters, and based on the number of the first clusters and the initial centroids, iteratively generate clusters using a preset clustering algorithm; Step 314: Determine the evaluation metrics for the clusters.

[0100] The evaluation metrics include intra-cluster dispersion, inter-cluster distance, and / or the Davies-Bouldin index.

[0101] Step 316: Determine whether the evaluation index of the cluster meets the preset conditions.

[0102] Step 318: If the evaluation index of the cluster does not meet the preset conditions, then determine the number of the second cluster based on the evaluation index, and use the number of the second cluster as the number of the first cluster.

[0103] Step 320: For each set of test cases, redundant test cases are identified based on feature vectors to obtain the identification results, and a test suite is generated based on the identification results and the set of test cases.

[0104] The specific processes of steps 302 to 320 above have been described in detail in the above embodiments, and will not be repeated here.

[0105] In this embodiment, multiple test cases are acquired, and feature extraction is performed on them to obtain input features, execution features, and coverage features. Coverage features are determined based on code coverage information and functional requirement coverage information of the test cases. Feature vectors for the test cases are constructed based on these features. Based on these feature vectors, an improved clustering algorithm is used to group the test cases, resulting in multiple test case sets. For each test case set, redundant test cases are identified based on the feature vectors, yielding identification results. A test suite is then generated based on these identification results and the test case sets. Compared to related test suite generation technologies that simplify traditional test suites based on code coverage and test execution results, this application extracts feature vectors for constructing test cases using multi-dimensional features (i.e., input features, execution features, and coverage features) and uses an improved clustering algorithm to group the test cases, resulting in a more accurate set of test cases. Furthermore, redundant test cases are identified based on these feature vectors, yielding accurate identification results. This allows for maintaining test coverage and fault detection capabilities while reducing the size of the test suite, generating a high-quality test suite. This solves the problem of poor quality test suites generated by related test suite generation technologies.

[0106] Based on the same technical concept, and corresponding to the test kit generation method provided in the above embodiments, this invention also provides a test kit generation apparatus. Figure 4 This is a schematic diagram of a test kit generation apparatus according to an embodiment of the present invention, which is used to perform... Figures 1 to 3 The described test suite generation method, such as Figure 4 As shown, the test suite generation device includes: an acquisition module 410, a construction module 420, a grouping module 430, and a generation module 440.

[0107] The acquisition module 410 is used to acquire multiple test cases and extract features from the test cases to obtain the input features, execution features, and coverage features of the test cases; the coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. Module 420 is used to construct feature vectors for test cases based on input features, execution features, and coverage features; Grouping module 430 is used to group test cases based on the feature vectors of test cases using an improved clustering algorithm to obtain multiple test case sets; The generation module 440 is used to identify redundant test cases for each test case set based on feature vectors, obtain the identification results, and generate a test suite based on the identification results and the test case set.

[0108] In one implementation, the grouping module 430 includes: The first determining unit is used to determine multiple initial center points in the feature vectors of multiple test cases; The second determining unit is used to repeatedly execute the following steps until the evaluation index of the clusters meets the preset conditions, and to determine multiple test case sets based on the test cases corresponding to the first number of clusters: Determine the number of the first clusters, and based on the number of the first clusters and the initial centroids, iteratively generate clusters using a preset clustering algorithm; Determine the evaluation metrics for the clusters; among which, the evaluation metrics include intra-cluster dispersion, inter-cluster distance, and / or, Davies-Bouldin index. Determine whether the evaluation indicators of the clusters meet the preset conditions; If the evaluation index of a cluster does not meet the preset conditions, then the number of the second cluster is determined according to the evaluation index, and the number of the second cluster is used as the number of the first cluster.

[0109] In one implementation, the first determining unit is specifically used for: Calculate the local density of the feature vector for each test case, and determine the potential centroids by sorting the feature vectors based on the local density and the preset number of potential centroids. For each potential center point, calculate the first distance between the potential center point and the target potential center point, and determine multiple candidate center points among the potential center points based on the first distance and local density; wherein, the target potential center point is the potential center point with a local density greater than that of the potential center point and the closest distance to the potential center point. Determine the second distance between candidate center points, and based on the second distance and a preset first distance threshold, determine multiple initial center points among the candidate center points.

[0110] In one implementation, the test suite generation apparatus further includes an anomaly detection module. The anomaly detection module is used for: Based on feature vectors, multiple corresponding test cases are detected to obtain abnormal test cases; Calculate the third distance between the feature vector of the abnormal test case and the target potential center point, and determine the boundary test cases based on the third distance and the preset second distance threshold; The second determining unit is specifically used for: Based on the test cases corresponding to the clusters, determine the number of initial test case sets for the first cluster, and determine the membership degree of the boundary test cases to the initial test case sets based on the feature vectors; Based on the preset membership threshold and membership degree, the number of test cases for the third cluster is determined.

[0111] In one implementation, the test suite generation apparatus further includes an initial suite generation module. The initial suite generation module is used for: Based on the code coverage information and functional requirement coverage information of test cases in multiple test case sets, an initial test suite is determined, and based on the initial test suite and test case sets, a cluster set is determined; Module 440 is generated, specifically for: For each cluster set, based on the code coverage information and functional requirement coverage information of the test cases in the cluster set, the representative test cases in the cluster set are determined; Determine the similarity between the feature vectors of the remaining test cases and the feature vectors of the test case representative, and determine the overlap between the coverage features of the remaining test cases and the coverage features of the test case representative; wherein, the remaining test cases are the test cases in the cluster set other than the test case representative. Based on similarity and overlap, determine the redundancy between the remaining test cases and the test case representative; Based on redundancy and a preset redundancy threshold, the identification results that characterize whether test cases are redundant are determined, and a test suite is generated based on the identification results and cluster sets.

[0112] In one implementation, the aforementioned initial kit generation module is specifically used for: Based on the code coverage information and functional requirement coverage information of test cases in multiple test case sets, as well as the preset coverage matrix, the test cases with the largest coverage gain are iteratively selected through an improved greedy algorithm until the target code elements in the coverage matrix are covered, or the coverage rate of the coverage matrix reaches the preset coverage rate threshold, thus obtaining the initial test suite.

[0113] Among them, code coverage information and functional requirement coverage information include coverage information of code elements; coverage gain is the ratio of the coverage increment of code elements between two test cases in the test case set to the execution cost information corresponding to the coverage increment.

[0114] In one implementation, the generation module 440 is specifically used for: Based on the coverage characteristics of the test cases and the identification results of whether the test cases are redundant, the redundancy markers of the test cases are determined; the redundancy markers include non-redundant test case markers, necessary redundant test case markers, and redundant test case markers. A test suite is generated based on the redundancy markers of test cases and the set of test cases.

[0115] In this embodiment, multiple test cases are acquired, and feature extraction is performed on them to obtain input features, execution features, and coverage features. Coverage features are determined based on code coverage information and functional requirement coverage information of the test cases. Feature vectors for the test cases are constructed based on these features. Based on these feature vectors, an improved clustering algorithm is used to group the test cases, resulting in multiple test case sets. For each test case set, redundant test cases are identified based on the feature vectors, yielding identification results. A test suite is then generated based on these identification results and the test case sets. Compared to related test suite generation technologies that simplify traditional test suites based on code coverage and test execution results, this application extracts feature vectors for constructing test cases using multi-dimensional features (i.e., input features, execution features, and coverage features) and uses an improved clustering algorithm to group the test cases, resulting in a more accurate set of test cases. Furthermore, redundant test cases are identified based on these feature vectors, yielding accurate identification results. This allows for maintaining test coverage and fault detection capabilities while reducing the size of the test suite, generating a high-quality test suite. This solves the problem of poor quality test suites generated by related test suite generation technologies.

[0116] Those skilled in the art will understand that the above-described test kit generation apparatus can be used to implement the test kit generation method described above, and the detailed description therein should be similar to the method description above. To avoid repetition, it will not be repeated here.

[0117] Based on the same technical concept, embodiments of this application also provide an electronic device for executing the above-described test kit generation method. Figure 5 This is a schematic diagram of the structure of an electronic device to implement various embodiments of this application. The electronic device can vary significantly due to differences in configuration or performance, and may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540. The processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can call a computer program stored in the memory 530 and executable on the processor 510 to perform the following steps: Multiple test cases are obtained, and feature extraction is performed on the test cases to obtain the input features, execution features, and coverage features of the test cases; the coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. Based on input features, execution features, and coverage features, construct feature vectors for test cases; Based on the feature vectors of test cases, an improved clustering algorithm is used to group test cases into multiple test case sets. For each set of test cases, redundant test cases are identified based on feature vectors to obtain identification results. Based on the identification results and the set of test cases, a test suite is generated.

[0118] In this embodiment, multiple test cases are acquired, and feature extraction is performed on them to obtain input features, execution features, and coverage features. Coverage features are determined based on code coverage information and functional requirement coverage information of the test cases. Feature vectors for the test cases are constructed based on these features. Based on these feature vectors, an improved clustering algorithm is used to group the test cases, resulting in multiple test case sets. For each test case set, redundant test cases are identified based on the feature vectors, yielding identification results. A test suite is then generated based on these identification results and the test case sets. Compared to related test suite generation technologies that simplify traditional test suites based on code coverage and test execution results, this application extracts feature vectors for constructing test cases using multi-dimensional features (i.e., input features, execution features, and coverage features) and uses an improved clustering algorithm to group the test cases, resulting in a more accurate set of test cases. Furthermore, redundant test cases are identified based on these feature vectors, yielding accurate identification results. This allows for maintaining test coverage and fault detection capabilities while reducing the size of the test suite, generating a high-quality test suite. This solves the problem of poor quality test suites generated by related test suite generation technologies.

[0119] The specific execution steps can be found in the various steps of the above test suite generation method embodiment, and can achieve the same technical effect. To avoid repetition, they will not be repeated here.

[0120] It should be noted that the electronic devices in the embodiments of this application include: servers, terminals, or other devices besides terminals.

[0121] The above electronic device structure does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or arrange them differently. For example, an input unit may include a Graphics Processing Unit (GPU) and a microphone, and a display unit may use a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar display panels. User input units include at least one of a touch panel and other input devices. A touch panel is also called a touchscreen. Other input devices may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be elaborated further here.

[0122] Memory can be used to store software programs and various data. Memory can primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area can store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, memory can include volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0123] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly handles operations related to the operating system, user interface, and applications, while the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor.

[0124] This application also provides a storage medium storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they implement the various processes of the above-described test suite generation method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0125] The processor is the processor in the electronic device described in the above embodiments. The storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0126] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described test kit generation method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0127] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0128] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the various processes of the above-described test suite generation method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0129] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include multitasking and parallel processing according to the functions involved, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0131] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for generating a test suite, characterized in that, The method includes: Multiple test cases are obtained, and feature extraction is performed on the test cases to obtain the input features, execution features, and coverage features of the test cases; the coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. Based on the input features, the execution features, and the coverage features, the feature vector of the test case is constructed; Based on the feature vectors of the test cases, the test cases are grouped using an improved clustering algorithm to obtain multiple test case sets. For each set of test cases, redundant test cases are identified based on the feature vector to obtain the identification result, and a test suite is generated based on the identification result and the set of test cases.

2. The method according to claim 1, characterized in that, Based on the feature vectors of the test cases, an improved clustering algorithm is used to group the test cases, resulting in multiple test case sets, including: Multiple initial centroids are determined from the feature vectors of multiple test cases, and the following steps are executed iteratively until the evaluation index of the clusters meets preset conditions. Based on the test cases corresponding to the first number of clusters, multiple sets of test cases are determined: The number of the first clusters is determined, and based on the number of the first clusters and the initial centroids, the clusters are iteratively generated using a preset clustering algorithm; Determine the evaluation metrics for the clusters; wherein the evaluation metrics include intra-cluster dispersion, inter-cluster distance, and / or, Davies-Bouldin index. Determine whether the evaluation index of the cluster meets the preset conditions; If the evaluation index of the cluster does not meet the preset condition, then the second cluster number is determined according to the evaluation index, and the second cluster number is used as the first cluster number.

3. The method according to claim 2, characterized in that, Determining multiple initial center points from the feature vectors of the multiple test cases includes: Calculate the local density of the feature vector for each test case, and determine the potential center points by sorting the feature vectors based on the local density and a preset number of potential center points; For each potential center point, a first distance between the potential center point and the target potential center point is calculated, and multiple candidate center points are determined among the potential center points based on the first distance and the local density; wherein, the target potential center point is the potential center point whose local density is greater than that of the potential center point and whose distance to the potential center point is the closest. A second distance is determined between the candidate center points, and based on the second distance and a preset first distance threshold, a plurality of initial center points are determined among the candidate center points.

4. The method according to claim 3, characterized in that, Before determining multiple initial center points in the feature vectors of the multiple test cases, the method further includes: Based on the feature vector, multiple corresponding test cases are detected to obtain abnormal test cases; After calculating the first distance between the potential center point and the target potential center point, the method further includes: Calculate the third distance between the feature vector of the abnormal test case and the target potential center point, and determine the boundary test cases based on the third distance and a preset second distance threshold; The determination of multiple test case sets based on the test cases corresponding to the first number of clusters includes: Based on the test cases corresponding to the clusters, determine the number of initial test case sets for the first cluster, and based on the feature vectors, determine the membership degree of the boundary test cases to the initial test case sets; Based on the preset membership threshold and the membership degree, the number of test cases in the third cluster is determined.

5. The method according to claim 1, characterized in that, Before identifying redundant test cases based on the feature vector for each set of test cases and obtaining the identification result, the method further includes: Based on the code coverage information and functional requirement coverage information of the test cases in the multiple test case sets, an initial test suite is determined, and a cluster set is determined according to the initial test suite and the test case sets; For each set of test cases, redundant test cases are identified based on the feature vector to obtain an identification result. Based on the identification result and the set of test cases, the following steps are taken: For each cluster set, based on the code coverage information and functional requirement coverage information of the test cases in the cluster set, a representative test case in the cluster set is determined; Determine the similarity between the feature vector of the remaining test cases and the feature vector represented by the test cases, and determine the overlap between the coverage features of the remaining test cases and the coverage features represented by the test cases; wherein, the remaining test cases are the test cases in the cluster set other than those represented by the test cases. Based on the similarity and the overlap, the redundancy between the remaining test cases and the test case representative is determined; Based on the redundancy and the preset redundancy threshold, an identification result characterizing whether the test case is redundant is determined, and based on the identification result and the cluster set, the test suite is generated.

6. The method according to claim 5, characterized in that, The determination of the initial test suite based on the code coverage information and functional requirement coverage information of the test cases in multiple test case sets includes: Based on the code coverage information and functional requirement coverage information of the test cases in multiple test case sets, and a preset coverage matrix, an improved greedy algorithm iteratively selects the test case with the largest coverage gain until the target code element in the coverage matrix is ​​covered, or the coverage rate of the coverage matrix reaches a preset coverage threshold, thus obtaining the initial test suite; wherein, the code coverage information and the functional requirement coverage information include code element coverage information; the coverage gain is the ratio of the coverage increment of the code element between two test cases in the test case set to the execution cost information corresponding to the coverage increment.

7. The method according to claim 1, characterized in that, The step of generating a test suite based on the identification results and the test case set includes: Based on the coverage characteristics of the test cases and the identification results indicating whether the test cases are redundant, the redundancy markers of the test cases are determined; the redundancy markers include non-redundant test case markers, necessary redundant test case markers, and redundant test case markers. The test suite is generated based on the redundancy markers of the test cases and the set of test cases.

8. A test kit generation apparatus, characterized in that, The device includes: The acquisition module is used to acquire multiple test cases and extract features from the test cases to obtain the input features, execution features, and coverage features of the test cases; the coverage features are determined based on the code coverage information and functional requirement coverage information of the test cases. A construction module is used to construct the feature vector of the test case based on the input features, the execution features, and the coverage features; The grouping module is used to group the test cases based on their feature vectors using an improved clustering algorithm, thereby obtaining multiple test case sets. The generation module is used to identify redundant test cases for each set of test cases based on the feature vector, obtain the identification result, and generate a test suite based on the identification result and the set of test cases.

9. An electronic device, characterized in that, include: processor; as well as A memory configured to store computer-executable instructions configured to be executed by the processor, the executable instructions including instructions for performing the test suite generation method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium is used to store computer-executable instructions that cause a computer to perform the test suite generation method as described in any one of claims 1-7.

Images