Software testing method, software testing system and electronic equipment

Abstract

The invention provides a software testing method, a software testing system and electronic equipment, and relates to the technical field of computers. The method comprises the following steps: acquiring an iterative defect data set of a software system, extracting multi-dimensional features from the iterative defect data set, performing clustering processing and association analysis on the multi-dimensional features, and generating a defect mode set and an association rule set, performing risk quantitative analysis on the target code module according to the defect mode set, the association rule set and code modification data of the target code module under the current iteration round to obtain a quantitative risk score, and performing priority ranking on the test cases corresponding to the target code module according to the quantitative risk score to obtain a test result; and obtaining a test strategy of the target code module under the current iteration round. According to the method, risk quantification is carried out through defect mode mining and association rules, accurate identification of a high-risk code module and optimal distribution of test resources are realized, and the test efficiency is remarkably improved while the test quality is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a software testing method, a software testing system, and an electronic device. Background Technology

[0002] In the continuous integration and delivery of software systems, rapid iteration places extremely high demands on the efficiency and accuracy of software regression testing. Current technologies primarily rely on human experience, simple statistical indicators, or pre-set static rules for software testing. For example, testers allocate test resources based on subjective judgment or rough statistics, or they use fixed rule engines for software testing.

[0003] However, existing methods generally suffer from significant drawbacks such as limited analytical dimensions and low adaptability, which leads to inefficient allocation of testing resources, easy omission of changes to high-risk code modules, and over-testing of low-risk code modules, seriously affecting the quality of software testing. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of the prior art by providing a software testing method, software testing system, and electronic device, in order to solve the problems of low efficiency in the allocation of testing resources, easy omission of changes to high-risk code modules, and over-testing of low-risk code modules, which seriously affect the quality of software testing.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a software testing method, the method comprising: Obtain the iterative defect dataset of the software system, which includes code data, defect data and test data of each code module of the software system under multiple historical iterations; Multidimensional features are extracted from the iterative defect dataset, including code features, defect features, and test features; Clustering is performed on the multidimensional features to generate a defect pattern set, and association analysis is performed on the multidimensional features to generate an association rule set. The association rule set includes multiple association rules, each of which is used to indicate the association relationship between code modification features, defect patterns, and test cases. Based on the defect pattern set, the association rule set, and the code modification data of the target code module in the current iteration round, a risk quantification analysis is performed on the target code module to obtain a quantitative risk score corresponding to the target code module. Then, the test cases corresponding to the target code module are prioritized according to the quantitative risk score to obtain the test strategy of the target code module in the current iteration round.

[0006] As one possible implementation, the clustering of the multidimensional features to generate a defect pattern set includes: Based on the multidimensional feature component defect feature matrix, the defect feature matrix includes multiple feature vectors, each feature vector representing a defect instance; Calculate the spatiotemporal similarity between any two feature vectors in the defect feature matrix, and perform density clustering on the feature vectors in the defect feature matrix based on the spatiotemporal similarity to obtain multiple defect clusters; The defect pattern set is generated based on multiple defect clusters.

[0007] As one possible implementation, calculating the spatiotemporal similarity between any two feature vectors in the defect feature matrix includes: Calculate the temporal proximity, spatial proximity, and feature similarity between any two feature vectors; The temporal proximity, spatial proximity, and feature similarity are weighted to obtain the spatiotemporal similarity.

[0008] As one possible implementation, generating the defect pattern set based on multiple defect clusters includes: For each defect cluster, time series analysis is performed on the occurrence time of each defect instance in the defect cluster to obtain the defect evolution trend. Based on the central feature vector of the defect cluster, the number of defect instances in the defect cluster, the frequency of occurrence of the defect cluster in historical iterations, and the defect evolution trend, the defect mode corresponding to the defect cluster is determined. Based on the defect patterns corresponding to each defect cluster, the defect pattern set is generated.

[0009] As one possible implementation, the step of performing association analysis on the multidimensional features to generate a set of association rules includes: Based on the aforementioned multidimensional features, a transaction set is constructed, which includes multiple transactions. Each transaction includes the modified code module, the triggered defect pattern, and the valid test cases. Calculate the support and confidence of each transaction, and generate the association rule set based on the support and confidence of each transaction.

[0010] As one possible implementation, the calculation of the support and confidence of each transaction, and the generation of the association rule set based on the support and confidence of each transaction, includes: The support level of each transaction is determined based on the occurrence time of each transaction. Transactions with a support level greater than the first preset value are selected as target transactions. Based on the modified code module corresponding to the target transaction, the triggered defect mode, and the valid test cases, multiple candidate association rules are generated, and the confidence level of each candidate association rule is calculated. The association rule set is generated by filtering candidate association rules with a confidence level greater than a second preset value from multiple candidate association rules.

[0011] As one possible implementation, the step of performing a risk quantification analysis on the target code module based on the defect pattern set, the association rule set, and the code modification data of the target code module in the current iteration round, to obtain a quantitative risk score corresponding to the target code module, includes: Based on the defect pattern set and the code modification data of the target code module in the current iteration, calculate the matching degree between the target code module and the historical defect patterns; Based on the code modification data of the target code module in the current iteration round, calculate the code modification magnitude of the target code module; Based on the set of association rules, other code modules associated with the target code module are identified, and based on the confidence level of the association rules corresponding to the target code module and the historical defect density of other code modules, the additional risk value generated by the modification of other code modules to the target code module is calculated. The matching degree, the extent of code modification, and the additional risk value are weighted and summed to obtain the quantitative risk score corresponding to the target code module.

[0012] As one possible implementation, prioritizing the test cases corresponding to the target code module based on the quantified risk score to obtain the test strategy for the target code module in the current iteration round includes: Obtain a set of test cases covering the target code module; For each test case in the test case set, the priority score of the test case is calculated based on the quantitative risk score, the number of historical defects detected for the test case, and the matching degree between the test case and the defect pattern triggered in the current iteration round. The test cases are sorted according to their priority scores to generate a test strategy for the target code module in the current iteration round. The test strategy includes the test case execution order, test scope, and test type.

[0013] Secondly, embodiments of this application provide a software testing system, the system comprising: The acquisition module is used to acquire the iterative defect dataset of the software system, which includes code data, defect data and test data of each code module of the software system in multiple historical iterations. An extraction module is used to extract multidimensional features from the iterative defect dataset, the multidimensional features including code features, defect features, and test features; The generation module is used to perform clustering processing on the multidimensional features to generate a defect pattern set, and to perform association analysis on the multidimensional features to generate an association rule set. The association rule set includes multiple association rules, each of which is used to indicate the association relationship between code modification features, defect patterns, and test cases. The risk analysis module is used to perform risk quantification analysis on the target code module based on the defect pattern set, the association rule set, and the code modification data of the target code module in the current iteration round, to obtain the quantitative risk score corresponding to the target code module, and to prioritize the test cases corresponding to the target code module based on the quantitative risk score, so as to obtain the test strategy of the target code module in the current iteration round.

[0014] As one possible implementation, the generation module is specifically used for: Based on the multidimensional feature component defect feature matrix, the defect feature matrix includes multiple feature vectors, each feature vector representing a defect instance; Calculate the spatiotemporal similarity between any two feature vectors in the defect feature matrix, and perform density clustering on the feature vectors in the defect feature matrix based on the spatiotemporal similarity to obtain multiple defect clusters; The defect pattern set is generated based on multiple defect clusters.

[0015] As one possible implementation, the generation module is specifically used for: Calculate the temporal proximity, spatial proximity, and feature similarity between any two feature vectors; The temporal proximity, spatial proximity, and feature similarity are weighted to obtain the spatiotemporal similarity.

[0016] As one possible implementation, the generation module is specifically used for: For each defect cluster, time series analysis is performed on the occurrence time of each defect instance in the defect cluster to obtain the defect evolution trend. Based on the central feature vector of the defect cluster, the number of defect instances in the defect cluster, the frequency of occurrence of the defect cluster in historical iterations, and the defect evolution trend, the defect mode corresponding to the defect cluster is determined. Based on the defect patterns corresponding to each defect cluster, the defect pattern set is generated.

[0017] As one possible implementation, the generation module is specifically used for: Based on the aforementioned multidimensional features, a transaction set is constructed, which includes multiple transactions. Each transaction includes the modified code module, the triggered defect pattern, and the valid test cases. Calculate the support and confidence of each transaction, and generate the association rule set based on the support and confidence of each transaction.

[0018] As one possible implementation, the generation module is specifically used for: The support level of each transaction is determined based on the occurrence time of each transaction. Transactions with a support level greater than the first preset value are selected as target transactions. Based on the modified code module corresponding to the target transaction, the triggered defect mode, and the valid test cases, multiple candidate association rules are generated, and the confidence level of each candidate association rule is calculated. The association rule set is generated by filtering candidate association rules with a confidence level greater than a second preset value from multiple candidate association rules.

[0019] As one possible implementation, the risk analysis module is specifically used for: Based on the defect pattern set and the code modification data of the target code module in the current iteration, calculate the matching degree between the target code module and the historical defect patterns; Based on the code modification data of the target code module in the current iteration round, calculate the code modification magnitude of the target code module; Based on the set of association rules, other code modules associated with the target code module are identified, and based on the confidence level of the association rules corresponding to the target code module and the historical defect density of other code modules, the additional risk value generated by the modification of other code modules to the target code module is calculated. The matching degree, the extent of code modification, and the additional risk value are weighted and summed to obtain the quantitative risk score corresponding to the target code module.

[0020] As one possible implementation, the risk analysis module is specifically used for: Obtain a set of test cases covering the target code module; For each test case in the test case set, the priority score of the test case is calculated based on the quantitative risk score, the number of historical defects detected for the test case, and the matching degree between the test case and the defect pattern triggered in the current iteration round. The test cases are sorted according to their priority scores to generate a test strategy for the target code module in the current iteration round. The test strategy includes the test case execution order, test scope, and test type.

[0021] Thirdly, embodiments of this application provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the software testing method as described in any of the first aspects above.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the software testing method as described in any of the first aspects above.

[0023] According to the software testing method, software testing system, and electronic device of this application, three types of multi-dimensional features—code features, defect features, and test features—are extracted from historical iteration data. An improved spatiotemporal clustering algorithm is used to identify a structured set of defect patterns. Each defect pattern in the set not only contains typical defect attributes but also integrates pattern strength, stability, and evolution trends, thereby transforming discrete defect records into structured risk information. Simultaneously, association rule mining is achieved through association analysis of the multi-dimensional features, resulting in a set of association rules. Based on this, for the target code module in the current iteration, a quantitative risk score is obtained by combining the defect pattern set and the association rule set. The priority of each test case is calculated and ranked based on the quantitative risk score, generating a test strategy focused on high-risk scenarios. In this way, test resources are no longer evenly distributed or dependent on coarse-grained rules but are precisely targeted at truly high-risk code changes. This avoids redundant coverage of stable, low-risk code modules and significantly improves the detection capability of potential defects, thereby significantly improving test efficiency while ensuring test quality. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a software testing method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating a defect pattern set generation method provided in an embodiment of this application is shown. Figure 3 A flowchart illustrating a method for determining a quantitative risk score according to an embodiment of this application is shown; Figure 4 A flowchart illustrating a test strategy determination method provided in an embodiment of this application is shown; Figure 5 This paper shows a schematic diagram of the structure of a software testing system provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0027] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0029] Figure 1 A flowchart illustrating a software testing method provided in an embodiment of this application is shown. (Refer to...) Figure 1 As shown, the method specifically includes the following steps: S101. Obtain the iterative defect dataset of the software system.

[0030] Optionally, the software system consists of multiple code modules, and users can be responsible for the operation, maintenance, and iterative updates of one or more code modules. The iterative defect dataset centrally includes code data, defect data, and test data for each code module of the software system across multiple historical iterations. Specifically, code data, such as code commit records (modified files, line counts, authors), and version control logs, can be obtained from the code repository; defect data, such as defect reports (module, type, severity, and fix), can be obtained from the defect management system; and test data, such as test cases (module, priority, execution results), historical regression test scope, and defect detection rate, can be obtained from test management tools.

[0031] Optionally, relevant data from each historical iteration of the software system throughout its lifecycle can be acquired to construct a complete iterative defect dataset. This dataset not only includes the specific code content of each code module in different historical iterations, but also related defect records and testing activity data. Together, these data provide information on how the software system evolves over time, which code modules are more prone to failure, and the effectiveness of testing strategies. Furthermore, after acquiring the iterative defect dataset, data cleaning is required to ensure data quality and consistency, such as removing duplicates and filling in missing values.

[0032] S102. Extract multidimensional features from the iterative defect dataset.

[0033] Optionally, multidimensional features include code features, defect features, and test features. Among them, code features include module modification frequency, code complexity (cyclomatic complexity), and correlation with defective modules; defect features include defect type (functionality, performance, compatibility), number of recurrences, and repair cost (repair time, code volume); and test features include test case coverage modules and the number of historically detected defects.

[0034] Optionally, in this embodiment, code data is aggregated and metrically analyzed to extract code features characterizing the activity and complexity of code modules. This includes calculating the modification frequency of each code module based on code commit records, measuring cyclomatic complexity based on code structure to assess logical complexity, and calculating the correlation between code modules and historically high-defect code modules by analyzing code dependencies. Simultaneously, defect data is statistically and categorized to extract defect features characterizing the nature of defects and their repair costs. For example, defect types are categorized and labeled according to function, performance, or compatibility; the number of recurrences under the same defect pattern is counted; and repair time and the amount of code involved are calculated based on repair records to quantify repair costs. Furthermore, test data is subjected to coverage and performance analysis to extract test features characterizing the test scope and effectiveness. For example, test cases are mapped to the software modules covered by the test, and the number of defects successfully detected by each test case is counted based on historical execution results. S103. Perform clustering on multidimensional features to generate a set of defect patterns, and perform association analysis on multidimensional features to generate a set of association rules.

[0035] Optionally, multidimensional features, including code features, defect features, and test features, are extracted from the iterative defect dataset. Attributes related to defects are selected from these multidimensional features to construct a defect feature matrix. Then, an improved spatiotemporal density clustering algorithm is used. By calculating the weighted fusion value of any two defect instances in the defect feature matrix across three dimensions—temporal proximity, spatial proximity, and feature similarity—spatiotemporal similarity is obtained. This spatiotemporal similarity is then used to replace the traditional distance metric for density clustering, thereby aggregating highly related defect instances into several defect clusters. Further, for each defect cluster, the cluster center feature vector is extracted as the core feature. Combined with the number of defects within the cluster, historical occurrence frequency, and evolutionary trends obtained from time series analysis, defect patterns are constructed, and a defect pattern set is generated.

[0036] Optionally, the association rule set includes multiple association rules, each indicating the association between code modification features, defect patterns, and test cases. It is worth noting that in this embodiment, code data, defect data, and test data serve as three types of historical information as raw inputs, recording code changes, defect occurrences, and test execution results in each iteration. This application extracts corresponding code features, defect features, and test features through structured processing and feature extraction of these three types of raw data, forming multi-dimensional features for subsequent association analysis and association rule mining. Furthermore, in the association rule mining stage, code modification features derived from code features, defect patterns generated by defect feature clustering, and test cases derived from test features and validated for effectiveness jointly establish a data-driven association relationship, thereby forming actionable knowledge of "what kind of defects specific code changes are likely to cause and which test cases should be executed first," achieving a complete mapping from raw data to intelligent test decisions.

[0037] Optionally, in this embodiment, a transaction set is constructed based on code modification records in historical iterations, defect patterns generated by clustering, and verified test cases. The support of each transaction is calculated according to the occurrence time of each transaction in the transaction set, and transactions with support higher than a first preset value are retained as target transactions. Multiple candidate association rules are generated for the target transactions, and the confidence of each candidate association rule is calculated. High-confidence association rules with confidence higher than a second preset value are selected to form a structured set of association rules.

[0038] S104. Based on the defect pattern set, association rule set, and code modification data of the target code module in the current iteration round, perform risk quantification analysis on the target code module to obtain the quantitative risk score corresponding to the target code module, and prioritize the test cases corresponding to the target code module according to the quantitative risk score to obtain the test strategy of the target code module in the current iteration round.

[0039] Optionally, based on the defect pattern set and the code modification data of the target code module in the current iteration, the matching degree between the target code module and historical defect patterns is calculated. Simultaneously, indicators such as the number of modified lines and function additions / deletions are extracted from the code modification data and weighted and normalized to obtain the code modification magnitude. Furthermore, a set of association rules is used to identify other code modules that have a dependency or causal relationship with the target code module. Combining the confidence level of the corresponding association rules with the historical defect density of other code modules, the additional risk value generated by the modifications of other code modules on the target code module is calculated. Based on this, the matching degree, code modification magnitude, and additional risk value are weighted and fused according to preset weights to generate a quantitative risk score for the target code module.

[0040] Furthermore, a set of test cases covering the module is obtained, and for each test case, a priority score is calculated based on the quantitative risk score corresponding to the target code module, the number of historical defects detected, and the degree of matching with the current high-risk defect pattern. Based on this, the test cases are sorted according to their priority scores to generate a structured test strategy that includes execution order, test scope, and test type.

[0041] Based on this, the software testing method according to the embodiments of this application extracts three types of multi-dimensional features from historical iteration data: code features, defect features, and test features. An improved spatiotemporal clustering algorithm is used to identify a structured set of defect patterns. Each defect pattern in the set not only contains typical defect attributes but also integrates pattern strength, stability, and evolution trends, thereby transforming discrete defect records into structured risk information. Simultaneously, association rule mining is achieved through association analysis of the multi-dimensional features, resulting in a set of association rules. Based on this, for the target code module in the current iteration, a quantitative risk score is obtained by combining the defect pattern set and the association rule set. The priority of each test case is calculated and ranked based on the quantitative risk score, generating a test strategy focused on high-risk scenarios. In this way, test resources are no longer evenly distributed or dependent on coarse-grained rules but are precisely targeted at truly high-risk code changes. This avoids redundant coverage of stable, low-risk code modules and significantly improves the detection capability of potential defects, thereby significantly improving test efficiency while ensuring test quality.

[0042] Figure 2 A flowchart illustrating a defect pattern set generation method provided in an embodiment of this application is shown. (Refer to...) Figure 2 As shown, the above steps perform clustering processing on multidimensional features to generate a set of defect patterns, specifically including the following steps: S201, Based on the defect feature matrix of multi-dimensional feature components.

[0043] Optionally, the defect feature matrix includes multiple feature vectors, each representing a defect instance. In this embodiment, the multidimensional features include code features, defect features, and test features. After extracting multidimensional features from the iterative defect dataset, further defect-related features can be obtained from the multidimensional features, including but not limited to: the code module to which the defect belongs, the defect type (e.g., functional error, performance bottleneck, security vulnerability), severity, introduction stage (e.g., development, testing, post-deployment), remediation plan, number of recurrences, associated code complexity changes, submitter information, etc. The obtained defect-related features are then structured to construct a defect feature matrix. , where each feature vector For a specific defect instance, each dimension represents the value of the defect on different features.

[0044] S202. Calculate the spatiotemporal similarity between any two feature vectors in the defect feature matrix, and perform density clustering on the feature vectors in the defect feature matrix based on the spatiotemporal similarity to obtain multiple defect clusters.

[0045] Optionally, embodiments of this application employ an improved spatiotemporal density clustering algorithm (DBSCAN-ST) to cluster the feature vectors in the defect feature matrix. Specifically, for any two feature vectors in the defect feature matrix, i.e., any two defect instances, the spatiotemporal similarity between the two defect instances is calculated. Then, the spatiotemporal similarity is used to replace the traditional distance metric, thereby aggregating defect instances with high spatiotemporal similarity into several defect clusters. Each defect cluster represents a set of defects that are highly correlated in the spatiotemporal context.

[0046] Optionally, the spatiotemporal similarity between any two feature vectors in the defect feature matrix is ​​calculated, including: calculating the temporal proximity, spatial proximity, and feature similarity between any two feature vectors, and weighting the temporal proximity, spatial proximity, and feature similarity to obtain the spatiotemporal similarity.

[0047] Optionally, in the embodiments of this application, temporal proximity, spatial proximity, and feature similarity are important dimensions for measuring the relationship between any two defect instances. Temporal proximity refers to assessing the correlation between two defect instances based on their occurrence time, and can specifically employ an exponential decay function. To calculate, where, Indicates the time when a defect instance occurred. Indicates the time when another instance of the defect occurred. The time decay constant represents the preset time proximity, reflecting the intuitive judgment that recently occurring defects are more relevant. Spatial proximity calculates the spatial proximity of two defect instances based on the call dependencies between the code modules associated with them. Feature similarity targets the attributes of the defects themselves, such as type, severity, and recurrence count, and can be calculated using methods such as cosine similarity or weighted Euclidean distance.

[0048] Furthermore, the spatiotemporal similarity can be obtained by weighting and fusing the three dimensions of temporal proximity, spatial proximity, and feature similarity according to a preset weight, as shown in the following expression (1): (1) in, Indicates spatiotemporal similarity, Indicates temporal proximity. Indicates spatial proximity. Indicates feature similarity. Let represent the weighting coefficients, and .

[0049] S203. Generate a set of defect patterns based on multiple defect clusters.

[0050] Optionally, in this embodiment of the application, after obtaining multiple defect clusters, each defect cluster is transformed into a structured defect pattern. For example, for each defect cluster, time-series analysis is performed on the occurrence time of each defect instance within the cluster to obtain the defect evolution trend. Based on the central feature vector of the defect cluster, the number of defect instances in the cluster, the frequency of occurrence of the cluster in historical iterations, and the defect evolution trend, the defect pattern corresponding to the cluster is determined. A defect pattern set is then generated based on the defect patterns corresponding to each defect cluster.

[0051] For example, for each defect cluster Extracting defect clusters The central feature vector, such as the mean or mode of each dimension, is used as the core feature of the defect pattern to describe the typical attributes of such defects. This is also used for statistical defect clusters. The number of defect instances contained within the pattern is used as the pattern strength of the defect pattern, reflecting the prevalence of that defect type. Defect clusters are also calculated. The frequency of occurrence in historical iterations is used as the stability of the defect pattern, measuring whether it is a persistent defect. And for defect clusters... Trend fitting analysis is performed on the occurrence time series of all defect instances, for example, by using the linear regression slope method to obtain the defect evolution trend, such as rising, stabilizing or falling.

[0052] Furthermore, the four elements mentioned above—core features, pattern strength, stability, and defect evolution trend—are combined to form a complete defect pattern, and a defect pattern set is constructed based on all the defect patterns. Among them, the defect pattern set Each defect pattern in {Core characteristics, pattern strength, stability, and defect evolution trends}.

[0053] Based on this, this application automatically mines structured defect patterns with spatiotemporal consistency and semantic interpretability from massive historical defect data, identifies which types of defects recur when and where, and further quantifies defect intensity, stability and evolution trend, thereby transforming the original defect records into reusable and predictable risk information, significantly improving the accuracy and timeliness of defect patterns.

[0054] As one possible implementation, the above steps perform association analysis on multidimensional features to generate a set of association rules, including: constructing a transaction set based on multidimensional features, calculating the support and confidence of each transaction, and generating a set of association rules based on the support and confidence of each transaction. The transaction set includes multiple transactions, and each transaction includes the modified code module, the triggered defect pattern, and valid test cases.

[0055] Optionally, in this embodiment, based on the multi-dimensional features including code features, defect features, and test features, a transaction set is constructed by obtaining corresponding code modification records, historical defect patterns, and corresponding valid test cases from the iterative defect dataset. Each transaction in this set contains three main elements: the modified code module, the triggered defect pattern, and the valid test case. In this way, each code change and its consequences are organized into a structured transaction format, facilitating subsequent data mining.

[0056] Optionally, the support and confidence of each transaction are calculated, and a set of association rules is generated based on the support and confidence of each transaction. This includes: determining the support of each transaction based on the occurrence time of each transaction; selecting transactions with a support greater than a first preset value as target transactions; generating multiple candidate association rules based on the modified code module, the triggered defect mode, and the valid test cases corresponding to the target transactions; calculating the confidence of each candidate association rule; and selecting candidate association rules with a confidence greater than a second preset value from the multiple candidate association rules to generate a set of association rules.

[0057] For example, based on the occurrence time of each transaction, the support of each transaction is determined. The support refers to the frequency of a transaction in the entire transaction set, usually expressed as a percentage or proportion. Specifically, for each transaction, its support can be defined as the number of iterations containing that transaction divided by the total number of iterations. Then, based on a pre-set first preset value, such as 0.05, transactions with a support greater than the first preset value are selected and retained as target transactions.

[0058] For example, for the filtered target transaction, multiple candidate association rules are generated. In this embodiment, the form of the association rule is, for example, "If code module M is modified and defect mode P is triggered, then test case TC will take effect." Further, for each generated candidate association rule, the confidence level of each candidate association rule is calculated, that is, the ratio of the probability that the condition part (such as module modification and defect mode) and the result part (such as test case taking effect) of the association rule occur simultaneously to the probability that the condition part occurs alone. Then, according to a pre-set second preset value, such as 0.8, candidate association rules with a confidence level higher than the second preset value are selected from all candidate association rules to form the final set of association rules.

[0059] Based on this, the embodiments of this application organize historical code modifications, defect patterns and effective test cases into structured transactions to mine highly reliable and timely association rules. Compared with traditional static or timeless association analysis methods, the embodiments of this application not only avoid low-frequency noise interference, but also ensure that the generated association rules can effectively guide risk warning and test resource focus in the current iteration, thereby improving the efficiency of regression testing and defect detection rate.

[0060] Figure 3 A flowchart illustrating a method for determining a quantitative risk score according to an embodiment of this application is shown. (Refer to...) Figure 3 As shown, the above steps, based on the defect pattern set, association rule set, and code modification data of the target code module in the current iteration round, perform risk quantification analysis on the target code module to obtain the corresponding quantitative risk score. Specifically, the steps include the following: S301. Based on the defect pattern set and the code modification data of the target code module in the current iteration, calculate the matching degree between the target code module and the historical defect patterns.

[0061] Optionally, code modification data for the target code module in the current iteration is extracted, including but not limited to: modified source files, number of lines changed, changes in cyclomatic complexity, added / deleted functions, and changes in call relationships. Then, this code modification data is compared with the core features of each defect pattern in the defect pattern set. For example, if the core features of a defect pattern are "high cyclomatic complexity, authentication module, performance type," and the current modification happens to involve the authentication module with a significant increase in cyclomatic complexity, then the target code module is determined to be a high match for this defect pattern. The matching degree can be quantified using a predefined rule engine or similarity function, ultimately outputting a matching score between 0 and 1 to reflect the likelihood that the current modification falls into a known high-risk defect pattern.

[0062] S302. Calculate the magnitude of code modification of the target code module based on the code modification data of the target code module in the current iteration round.

[0063] Optionally, multiple modification metrics are extracted from the code modification data of the target code module in the current iteration round, including: total number of lines modified, number of new functions, number of deleted interfaces, control flow complexity increment, changes in the number of dependent modules, etc. The extracted modification metrics are normalized and weighted to obtain a comprehensive code modification magnitude. The larger the value corresponding to the code modification magnitude, the greater the change in the module structure or logic, and the higher the risk of introducing new defects.

[0064] S303. Based on the set of association rules, identify other code modules associated with the target code module, and calculate the additional risk value of modifications to the target code module based on the confidence of the association rules corresponding to the target code module and the historical defect density of other code modules.

[0065] Optionally, based on the set of association rules, association rules that contain the target code module or code modules that have a strong dependency on the target code module are identified. For example, if there is an association rule "Modify the payment module to trigger defect mode P3 of the order module", then when the target code module is "order module", this association rule will be activated.

[0066] Furthermore, for each association rule, the confidence level of the association rule and other code modules associated with the target code module are obtained, and the historical defect density of other code modules in the historical iterations is queried. This historical defect density is such as the number of defects per unit line of code or the average number of defects in the last N iterations. Then, the confidence level is multiplied by the historical defect density and weighted according to the dependency strength to obtain an additional risk value. This additional risk value is used to represent the indirect impact of changes in other code modules on the target code module.

[0067] S304. The matching degree, code modification range and additional risk value are weighted and summed to obtain the quantitative risk score corresponding to the target code module.

[0068] Optionally, after obtaining the three risk components—matching degree, code modification range, and additional risk value—corresponding weight coefficients can be set for each of these three risk components. These weight coefficients can be set according to the actual situation, and the quantitative risk score corresponding to the target code module can be calculated according to the following expression (2): (2) in, This indicates a quantitative risk score. Indicates the degree of matching. Indicates the extent of code modifications. Indicates the additional risk value. Let represent the weighting coefficients, and .

[0069] Based on this, the embodiments of this application not only consider the degree of matching between the current code changes and historical defect patterns, but also integrate the inherent risks of the code's own modification range and the cross-module transmission risks revealed by association rules. Compared with the coarse-grained scoring method in the existing methods that only rely on the number of lines of code or the number of defects, this application significantly improves the accuracy of risk identification, enabling testing resources to accurately focus on truly high-risk code modules, and effectively improve the efficiency of software regression testing and defect prevention capabilities.

[0070] Figure 4 A flowchart illustrating a test strategy determination method provided in an embodiment of this application is shown. (Refer to...) Figure 4 As shown, the above steps prioritize the test cases corresponding to the target code module based on the quantitative risk score, thereby obtaining the test strategy for the target code module in the current iteration round. Specifically, the steps include the following: S401. Obtain the set of test cases that cover the target code module.

[0071] Optionally, the test case set includes multiple test cases. The test coverage of each test case can be defined by indicators such as line coverage, branch coverage, or function call coverage, without specific limitations here.

[0072] S402. For each test case in the test case set, calculate the priority score of the test case based on the quantitative risk score, the number of historical defects detected for the test case, and the matching degree between the test case and the defect pattern triggered in the current iteration round.

[0073] Optionally, for each test case in the test case set, the number of times the test case detected defects in several historical test execution rounds is queried and counted from historical test execution data. The higher this number, the more effective the test case is in practice and the higher it should be executed. Further, the matching degree between the test case and the current high-risk defect pattern is determined. Specifically, the matching degree can be calculated by comparing the test case's metadata, such as associated defect tags, test type, and verified business scenario, with the core features of the currently identified defect pattern. For example, methods such as keyword overlap, vector similarity, or predefined matching rules can be used to calculate the matching degree, resulting in a matching score between 0 and 1.

[0074] Furthermore, the quantitative risk score, the number of historical defects detected, and the defect pattern matching degree are normalized to eliminate the difference in units. Then, according to the actual situation, the weight coefficients of the quantitative risk score, the number of historical defects detected, and the defect pattern matching degree are set respectively, and the priority score of each test case is calculated by weighted linear summation.

[0075] S403. Sort the test cases according to their priority scores and generate the test strategy for the target code module in the current iteration round.

[0076] Optionally, the testing strategy includes the test case execution order, test scope, and test type. In this embodiment, after obtaining the priority scores of all test cases, the test cases are sorted from high to low scores, and a structured testing strategy is generated. This testing strategy not only includes the execution order of the test cases, but also further defines the test scope, such as executing only the first N test cases to meet time constraints, and includes the test type, such as prioritizing performance tests in high-risk areas.

[0077] Based on this, the embodiments of this application maximize defect detection efficiency with limited testing resources by deeply integrating the risk characteristics of current code changes, the historical validity of test cases and their semantic association with potential defect patterns, thereby significantly improving the accuracy, response speed and resource utilization of software regression testing.

[0078] Based on the same inventive concept, this application also provides a software testing system corresponding to the software testing method. Since the principle of the software testing system in this application is similar to that of the software testing method described above, the implementation of the software testing system can refer to the implementation of the software testing method. Repeated parts will not be described again.

[0079] Reference Figure 5 The diagram shown is a structural schematic of a software testing system provided in an embodiment of this application. The software testing system 500 includes: an acquisition module 501, an extraction module 502, a generation module 503, and a risk analysis module 504, wherein: Module 501 is used to acquire the iterative defect dataset of the software system. The iterative defect dataset includes code data, defect data and test data of each code module of the software system in multiple historical iterations. Extraction module 502 is used to extract multidimensional features from the iterative defect dataset. The multidimensional features include code features, defect features, and test features. The generation module 503 is used to perform clustering processing on multi-dimensional features to generate a set of defect patterns, and to perform correlation analysis on multi-dimensional features to generate a set of correlation rules. The set of correlation rules includes multiple correlation rules, each of which is used to indicate the correlation between code modification features, defect patterns, and test cases. The risk analysis module 504 is used to perform risk quantification analysis on the target code module based on the defect pattern set, the association rule set, and the code modification data of the target code module in the current iteration round, to obtain the quantitative risk score corresponding to the target code module, and to prioritize the test cases corresponding to the target code module based on the quantitative risk score, so as to obtain the test strategy of the target code module in the current iteration round.

[0080] Based on this, the software testing system according to the embodiments of this application extracts three types of multi-dimensional features from historical iteration data: code features, defect features, and test features. An improved spatiotemporal clustering algorithm is used to identify a structured set of defect patterns. Each defect pattern in the set not only contains typical defect attributes but also integrates pattern strength, stability, and evolution trends, thereby transforming discrete defect records into structured risk information. Simultaneously, association rule mining is achieved through association analysis of the multi-dimensional features, resulting in a set of association rules. Based on this, for the target code module in the current iteration, a quantitative risk score is obtained by combining the defect pattern set and the association rule set. The priority of each test case is calculated and ranked based on the quantitative risk score, generating a test strategy focused on high-risk scenarios. In this way, test resources are no longer evenly distributed or dependent on coarse-grained rules but are precisely targeted at truly high-risk code changes. This avoids redundant coverage of stable, low-risk code modules and significantly improves the detection capability of potential defects, thereby significantly improving test efficiency while ensuring test quality.

[0081] In one possible implementation, the generation module 503 is specifically used for: Based on the multidimensional feature component defect feature matrix, the defect feature matrix includes multiple feature vectors, and each feature vector represents a defect instance; Calculate the spatiotemporal similarity between any two feature vectors in the defect feature matrix, and perform density clustering on the feature vectors in the defect feature matrix based on the spatiotemporal similarity to obtain multiple defect clusters; A set of defect patterns is generated based on multiple defect clusters.

[0082] In one possible implementation, the generation module 503 is specifically used for: Calculate the temporal proximity, spatial proximity, and feature similarity between any two feature vectors; The temporal proximity, spatial proximity, and feature similarity are weighted to obtain the spatiotemporal similarity.

[0083] In one possible implementation, the generation module 503 is specifically used for: For each defect cluster, time series analysis is performed on the occurrence time of each defect instance in the defect cluster to obtain the defect evolution trend. Based on the central feature vector of the defect cluster, the number of defect instances in the defect cluster, the frequency of occurrence of the defect cluster in historical iterations, and the defect evolution trend, the defect mode corresponding to the defect cluster is determined. A set of defect patterns is generated based on the defect patterns corresponding to each defect cluster.

[0084] In one possible implementation, the generation module 503 is specifically used for: Based on multidimensional features, a transaction set is constructed, which includes multiple transactions. Each transaction includes the modified code module, the triggered defect pattern, and the effective test cases. Calculate the support and confidence of each transaction, and generate a set of association rules based on the support and confidence of each transaction.

[0085] In one possible implementation, the generation module 503 is specifically used for: The support level of each transaction is determined based on the occurrence time of each transaction. Transactions with a support level greater than the first preset value are selected as target transactions. Based on the modified code module corresponding to the target transaction, the triggered defect pattern, and the valid test cases, multiple candidate association rules are generated, and the confidence level of each candidate association rule is calculated. From multiple candidate association rules, select candidate association rules with a confidence level greater than a second preset value to generate an association rule set.

[0086] In one possible implementation, the risk analysis module 504 described above is specifically used for: Based on the defect pattern set and the code modification data of the target code module in the current iteration, calculate the matching degree between the target code module and the historical defect patterns; Calculate the magnitude of code modification to the target code module based on the code modification data of the target code module in the current iteration round; Based on the set of association rules, other code modules associated with the target code module are identified, and based on the confidence of the association rules corresponding to the target code module and the historical defect density of other code modules, the additional risk value generated by the modification of other code modules to the target code module is calculated. The quantitative risk score corresponding to the target code module is obtained by weighting and summing the matching degree, the extent of code modification, and the additional risk value.

[0087] In one possible implementation, the risk analysis module 504 described above is specifically used for: Obtain the set of test cases that cover the target code module; For each test case in the test case set, the priority score of the test case is calculated based on the quantitative risk score, the number of historical defects detected for the test case, and the matching degree between the test case and the defect pattern triggered in the current iteration round. The test cases are sorted according to their priority scores, and a test strategy for the target code module in the current iteration is generated. The test strategy includes the test case execution order, test scope, and test type.

[0088] The description of the processing flow of each module in the system and the interaction flow between each module can be found in the relevant descriptions in the above method embodiments, and will not be detailed here.

[0089] This application also provides an electronic device 600, such as... Figure 6 The diagram shown is a structural schematic of an electronic device 600 provided in an embodiment of this application, including: a processor 601, a memory 602, and optionally, a bus 603. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 and the memory 602 communicate via the bus 603. When the machine-readable instructions are executed by the processor 601, the steps of the software testing method described in any of the preceding claims are performed.

[0090] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the software testing method described in any of the preceding claims.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0092] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0093] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A software testing method characterized by, The method comprises the following steps: obtaining an iterative defect data set of a software system, wherein the iterative defect data set comprises code data, defect data and test data of each code module of the software system in a plurality of historical iteration rounds; extracting multi-dimensional features from the iterative defect data set, wherein the multi-dimensional features comprise code features, defect features and test features; performing clustering processing on the multi-dimensional features to generate a defect mode set, and performing association analysis on the multi-dimensional features to generate an association rule set, wherein the association rule set comprises a plurality of association rules, and each association rule indicates an association relationship between a code modification feature, a defect mode and a test case; performing risk quantification analysis on a target code module according to the defect mode set, the association rule set and code modification data of the target code module in a current iteration round, obtaining a quantification risk score corresponding to the target code module, and performing priority sorting on test cases corresponding to the target code module according to the quantification risk score, to obtain a test strategy of the target code module in the current iteration round.

2. The method of claim 1, wherein, The method of performing clustering processing on the multi-dimensional features to generate a defect mode set comprises the following steps: constructing a defect feature matrix based on the multi-dimensional features, wherein the defect feature matrix comprises a plurality of feature vectors, and each feature vector represents a defect instance; calculating a spatio-temporal similarity between any two feature vectors in the defect feature matrix, and performing density clustering on the feature vectors in the defect feature matrix based on the spatio-temporal similarity, to obtain a plurality of defect clusters; generating the defect mode set according to the plurality of defect clusters.

3. The method of claim 2, wherein, The method of calculating a spatio-temporal similarity between any two feature vectors in the defect feature matrix comprises the following steps: calculating a time proximity, a space proximity and a feature similarity between any two feature vectors; performing weighted processing on the time proximity, the space proximity and the feature similarity, to obtain the spatio-temporal similarity.

4. The method of claim 2, wherein, The method of generating the defect mode set according to the plurality of defect clusters comprises the following steps: for each defect cluster, performing time series analysis on occurrence times of defect instances in the defect cluster, to obtain a defect evolution trend, and determining a defect mode corresponding to the defect cluster based on a center feature vector of the defect cluster, a number of defect instances in the defect cluster, an occurrence frequency of the defect cluster in historical iteration rounds and the defect evolution trend; generating the defect mode set according to the defect mode corresponding to each defect cluster.

5. The method of claim 1, wherein, The method of performing association analysis on the multi-dimensional features to generate an association rule set comprises the following steps: constructing a transaction set based on the multi-dimensional features, wherein the transaction set comprises a plurality of transactions, and each transaction comprises a modified code module, a triggered defect mode and an effective test case; calculating a support degree and a confidence degree of each transaction, and generating the association rule set according to the support degree and the confidence degree of each transaction.

6. The method of claim 5, wherein, The method of calculating a support degree and a confidence degree of each transaction, and generating the association rule set according to the support degree and the confidence degree of each transaction comprises the following steps: determining the support degree of each transaction based on occurrence times corresponding to each transaction; taking a transaction with a support degree greater than a first preset value as a target transaction; According to the modified code module corresponding to the target transaction, the triggered defect mode and the effective test case, a plurality of candidate association rules are generated, and the confidence of each candidate association rule is calculated; From the plurality of candidate association rules, a candidate association rule with a confidence greater than a second preset value is screened to generate the association rule set.

7. The method of claim 1, wherein, The risk quantification analysis of the target code module according to the defect mode set, the association rule set and the code modification data of the target code module in the current iteration round is obtained. The quantitative risk score corresponding to the target code module includes: Based on the defect mode set and the code modification data of the target code module in the current iteration round, the matching degree of the target code module and the historical defect mode is calculated; Based on the code modification data of the target code module in the current iteration round, the code modification amplitude of the target code module is calculated; Based on the association rule set, other code modules associated with the target code module are identified, and based on the confidence of the association rule corresponding to the target code module and the historical defect density of the other code modules, the additional risk value of the modification of the other code modules to the target code module is calculated; The matching degree, the code modification amplitude and the additional risk value are weighted and summed to obtain the quantitative risk score corresponding to the target code module.

8. The method of claim 1, wherein, The test case corresponding to the target code module is prioritized according to the quantitative risk score to obtain the test strategy of the target code module in the current iteration round, including: Obtain a test case set covering the target code module; For each test case in the test case set, the priority score of the test case is calculated according to the quantitative risk score, the number of historical detected defects corresponding to the test case, and the matching degree of the test case and the defect mode triggered in the current iteration round; According to the priority score of each test case, each test case is sorted to generate a test strategy of the target code module in the current iteration round, and the test strategy includes test case execution order, test range and test type.

9. A software testing system, characterized by It includes: The acquisition module is used for acquiring the iteration defect data set of the software system, and the iteration defect data set includes code data, defect data and test data of each code module of the software system in a plurality of historical iteration rounds; The extraction module is used for extracting multi-dimensional features from the iteration defect data set, and the multi-dimensional features include code features, defect features and test features; The generation module is used for clustering the multi-dimensional features to generate a defect mode set, and performing association analysis on the multi-dimensional features to generate an association rule set, each association rule in the association rule set representing an association relationship between code modification features, defect modes and test cases; A risk analysis module is configured to perform risk quantification analysis on the target code module according to the defect pattern set, the association rule set, and the code modification data of the target code module in the current iteration round, to obtain a quantified risk score corresponding to the target code module, and to perform priority sorting on test cases corresponding to the target code module according to the quantified risk score, to obtain a test strategy of the target code module in the current iteration round.

10. An electronic device, comprising: Comprising: A processor and a memory, wherein the memory stores machine readable instructions executable by the processor, and when the electronic device is running, the processor executes the machine readable instructions to perform the steps of the software testing method according to any one of claims 1 to 8.

Images