Software test recommendation method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a software test recommendation method and device, equipment and a storage medium. The method comprises the following steps: performing feature extraction on a technical document of to-be-tested software to obtain test features of the to-be-tested software; according to a similarity score between the test feature and a historical test feature corresponding to a historical test demand, screening out a target historical test demand meeting a condition from the historical test demand; performing feature screening on the test features corresponding to the target historical test requirements based on an association rule analysis algorithm to obtain target test features; performing clustering processing on the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension; and recommending the software test suggestion information to a user. According to the embodiment of the invention, quality fluctuation caused by experience and ability level differences of testers can be avoided, the systematicness and consistency of test suggestions are improved, and the coverage of the test suggestions is improved.

Description

Technical Field

[0001] The present application relates to the technical field of software testing, and in particular to a recommended method, device, equipment and storage medium for software testing. Background Art

[0002] In the software development process, testing is an important part of ensuring software quality and stability. However, as the complexity and scale of software systems continue to increase, traditional testing methods face problems such as low efficiency, insufficient coverage, and waste of resources. In order to meet these challenges, a test suggestion recommendation system based on recommendation algorithms has emerged, aiming to improve test efficiency and coverage through intelligent means.

[0003] Existing test suggestion recommendation systems mainly rely on manual summarization and experience accumulation. Testers usually need to manually analyze requirement documents, development documents, and release orders to summarize test focus and strategies. This method is not only time-consuming and labor-intensive, but also easily affected by human factors, resulting in insufficient accuracy and coverage of test suggestions. Specifically, the existing technical solutions have the following main disadvantages:

[0004] 1. Strong manual dependence: The generation of test suggestions mainly relies on the experience and subjective judgment of testers, and lacks systematic and automated support.

[0005] 2. Inefficiency: Manual analysis and summarization of test suggestions require a lot of time and effort, and it is difficult to quickly respond to frequent changes in requirements and code modifications.

[0006] 3. Insufficient coverage: Due to the limitations of manual analysis, test recommendations may not fully cover all potential test scenarios and risk points.

[0007] 4. Poor consistency: Different testers have different levels of experience and ability, which makes it difficult to ensure the quality and consistency of test recommendations. Summary of the invention

[0008] The technical problem to be solved by the embodiments of the present application is to provide a recommended method, device, equipment and storage medium for software testing to avoid quality fluctuations caused by differences in testers' experience and ability levels, improve the systematicness and consistency of test suggestions, and improve the coverage of test suggestions.

[0009] In a first aspect, an embodiment of the present application provides a software testing recommendation method, the method comprising:

[0010] Extracting features from the technical documents of the software to be tested to obtain test features of the software to be tested;

[0011] Filtering out qualified target historical test requirements from the historical test requirements according to the similarity scores between the test characteristics and the historical test characteristics corresponding to the historical test requirements;

[0012] Based on the association rule analysis algorithm, feature screening is performed on the test features corresponding to the target historical test requirements to obtain target test features;

[0013] Clustering the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension;

[0014] The software testing suggestion information is recommended to the user.

[0015] In a second aspect, an embodiment of the present application provides a software testing recommendation device, the device comprising:

[0016] A test feature acquisition module is used to extract features from the technical documents of the software to be tested to obtain the test features of the software to be tested;

[0017] A target test requirement acquisition module, configured to filter out target historical test requirements that meet the conditions from the historical test requirements according to a similarity score between the test feature and the historical test feature corresponding to the historical test requirement;

[0018] A target test feature acquisition module is used to perform feature screening on the test features corresponding to the target historical test requirements based on an association rule analysis algorithm to obtain target test features;

[0019] A software test suggestion acquisition module, used to cluster the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension;

[0020] The software testing suggestion recommendation module is used to recommend the software testing suggestion information to the user.

[0021] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0022] A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, any one of the above-mentioned recommended methods for software testing is implemented.

[0023] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform any of the recommended methods for software testing described above.

[0024] Compared with the prior art, the embodiments of the present application have the following advantages:

[0025] In the embodiment of the present application, the test features of the software to be tested are obtained by extracting features from the technical documents of the software to be tested. According to the similarity score between the test features and the historical test features corresponding to the historical test requirements, the target historical test requirements that meet the conditions are screened from the historical test requirements. The test features corresponding to the target historical test requirements are screened based on the association rule analysis algorithm to obtain the target test features. The target test features are clustered based on the preset clustering dimensions to obtain the software test suggestion information under the preset clustering dimensions. The software test suggestion information is recommended to the user. The embodiment of the present application automatically analyzes the technical documents of the software to be tested and generates test suggestions in combination with historical test features, which can avoid quality fluctuations caused by differences in tester experience and ability levels, reduce dependence on tester experience and subjective judgment, improve the systematicness and consistency of test suggestions, and at the same time, improve software testing efficiency. At the same time, by comprehensively analyzing the technical documents of the software to be tested and performing cluster analysis in combination with the preset clustering dimensions, the coverage of software test scenarios and risk points can be improved, and changes in requirements and codes can be quickly responded to, providing real-time test suggestions and optimization suggestions, and adapting to the rapid iteration development environment.

[0026] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 A flowchart of the steps of a recommended method for software testing provided in an embodiment of the present application;

[0028] Figure 2 A flowchart of a test feature acquisition method provided in an embodiment of the present application;

[0029] Figure 3 A flowchart of a method for obtaining target historical test requirements provided in an embodiment of the present application;

[0030] Figure 4 A flowchart of a method for screening target test characteristics provided in an embodiment of the present application;

[0031] Figure 5 A flowchart of a method for determining software test suggestion information provided by an embodiment of the present application;

[0032] Figure 6 A flowchart of a method for obtaining software test suggestion information provided by an embodiment of the present application;

[0033] Figure 7 A schematic diagram of the structure of a recommended device for software testing provided in an embodiment of the present application;

[0034] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0036] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0037] Reference Figure 1 , shows a flowchart of the steps of a recommended method for software testing provided by an embodiment of the present application, such as Figure 1 As shown, the recommended method for software testing may include: step 101, step 102, step 103, step 104 and step 105.

[0038] Step 101: extracting features from the technical documents of the software to be tested to obtain test features of the software to be tested.

[0039] In this embodiment, the software under test (SUT) refers to a software system or application that needs to be tested during the software development or maintenance process to verify whether its quality, function, performance, security, usability, etc. meet expectations. Testing is a key link in the software development cycle, which helps the development team discover and fix defects in the software and ensure that the software can run correctly according to the requirements specification.

[0040] Technical documents may include: product documentation, development documents, release notes and other documents of the software to be tested.

[0041] Among them, product documents may include: requirement specifications (detailed description of the functions, performance, user interface and other requirements of the software), user manuals (operation guides for end users, describing how to install, configure and use the software), product white papers (outlining the key features, advantages and market positioning of the product, and providing product background information for testers) and other information.

[0042] Development documents may include: design documents (including architecture design documents, detailed design documents, etc., which describe the overall structure of the software, module division, interface definition, etc.), development plans (detailed description of the software development schedule, milestones, resource allocation, etc.), code bases and version control records (provides a history of software changes to help testers identify environmental or functional changes that may affect testing) and other information.

[0043] The release sheet may include: test plan (developed by the test team, detailing the scope, methods, resources, schedule, etc. of the test), test cases (detailed test steps and expected results based on the requirements specification and design documents), and other information.

[0044] When generating test suggestions for the software to be tested, the technical documents of the software to be tested can be obtained, and feature extraction can be performed on the technical documents of the software to be tested to obtain test features of the software to be tested. Figure 2 This is described in detail as follows.

[0045] Reference Figure 2 , shows a flow chart of the steps of a test feature acquisition method provided by an embodiment of the present application. Figure 2 As shown, the test feature acquisition method may include: step 201, step 202 and step 203.

[0046] Step 201: Obtain product documents, development documents and release notes of the software to be tested.

[0047] In this embodiment, when generating the test suggestion of the software to be tested, the product document, development document and release sheet of the software to be tested can be obtained, and the product document, development document and release sheet can be used as the technical document of the software to be tested. The product document, development document and release sheet can be as described above, and this embodiment will not be repeated here.

[0048] Step 202: Process the product document, the development document and the release form based on natural language processing technology to obtain keyword features, service features and features of the module to which the modified code belongs.

[0049] Natural Language Processing (NLP) technology refers to allowing computers to accept user input in the form of natural language, and perform a series of operations such as processing and calculation internally through algorithms defined by humans to simulate human understanding of natural language and return the results expected by users.

[0050] After obtaining the product documents, development documents and release sheets of the software to be tested, they can be processed based on natural language processing technology to obtain keyword features, service features and features of the module to which the modified code belongs.

[0051] Among them, keyword features can be used to describe the core concepts and functions of the current requirements to be tested.

[0052] Service characteristics can be used to indicate the microservices or modules involved in the software to be tested.

[0053] The module feature to which the modified code belongs can be used to indicate the specific modules and files of the code changes of the software to be tested.

[0054] Step 203: preprocess the keyword features, the service features and the features of the module to which the modified code belongs to obtain preprocessed keyword features, service features and features of the module to which the modified code belongs, and use the preprocessed keyword features, service features and features of the module to which the modified code belongs as the test features.

[0055] After obtaining the keyword features, service features, and features of the module to which the modified code belongs, the keyword features, service features, and features of the module to which the modified code belongs may be preprocessed to obtain preprocessed keyword features, service features, and features of the module to which the modified code belongs, and the preprocessed keyword features, service features, and features of the module to which the modified code belongs are used as test features of the software to be tested. Specifically, the preprocessing method may include at least one of the following:

[0056] 1. Text cleaning: remove noise data, such as stop words, punctuation marks, etc.

[0057] 2. Word vectorization: Use word embedding technology (such as Word2Vec, GloVe (Global Vectors for Word Representation) or BERT (Bidirectional Encoder Representations from Transformers) to convert keywords into vector representations.

[0058] 3. Feature standardization: Standardize the numerical features so that they can be compared on the same scale.

[0059] The embodiment of the present application uses natural language processing (NLP) technology to quickly analyze requirement documents, development documents, and release orders to generate test suggestions, which can significantly reduce the time and effort of manual analysis and induction and improve the efficiency of generating test suggestions.

[0060] After extracting features from the technical documents of the software to be tested to obtain the test features of the software to be tested, step 102 is executed.

[0061] Step 102: Filter out target historical test requirements that meet the conditions from the historical test requirements according to the similarity scores between the test features and the historical test features corresponding to the historical test requirements.

[0062] Software testing requirements are the core part of the software testing process. Testing requirements define the requirements for testing objectives, scope, functionality, performance, security, etc. Testing requirements are designed to help the testing team understand how to plan and execute testing activities to verify whether the system or software meets specific requirements and quality standards.

[0063] In this example, the historical test requirements are the test requirements of different test items in the past software testing process.

[0064] The similarity score can be used to indicate the score of the similarity between the test feature and the historical test feature. In this example, the higher the similarity score, the more similar the test feature is to the historical test feature.

[0065] After extracting features from the technical documents of the software to be tested to obtain the test features of the software to be tested, the similarity score between the test features and the historical test features corresponding to the historical test requirements can be obtained, and the target historical test requirements that meet the conditions can be screened out from the historical test requirements according to the similarity score. Among them, the target historical test requirements that meet the conditions are the test requirements that have a high similarity with the current test requirements of the software to be tested.

[0066] The screening process for target historical testing requirements can be combined with Figure 3 This is described in detail as follows.

[0067] Reference Figure 3 , shows a flowchart of the steps of a method for obtaining target historical test requirements provided by an embodiment of the present application. Figure 3 As shown, the target historical test requirement acquisition method may include: step 301, step 302 and step 303.

[0068] Step 301: Calculate the text similarity, service similarity and module similarity between the requirements to be tested corresponding to the software to be tested and the historical test requirements based on the test features and the historical test features.

[0069] In this embodiment, after obtaining the test features of the software to be tested, the text similarity, service similarity and module similarity between the test requirements of the software to be tested (i.e., the test requirements of the software to be tested) and the historical test requirements can be calculated based on the test features and the historical test features of the historical test requirements.

[0070] In the specific implementation, an intelligent recommendation algorithm can be used to match the preprocessed features, that is, to match the keyword features, service features, and module features of the modified code corresponding to the requirements to be tested and the historical test requirements of the software to be tested. Then, text similarity, service similarity, and module similarity are performed based on the matched features.

[0071] Among them, text similarity can use cosine similarity, Jaccard similarity or TF-IDF (Term Frequency-Inverse Document Frequency) and other methods to calculate the similarity between keywords.

[0072] Service similarity can be calculated based on the calling relationship and dependency relationship between microservices to calculate the similarity between services.

[0073] Module similarity can be calculated based on the module information of code changes. The similarity between modules can be calculated using information such as module call relationship graph or historical change frequency.

[0074] After obtaining the text similarity, service similarity and module similarity, step 302 is executed.

[0075] Step 302: weighting the text similarity, the service similarity and the module similarity to obtain a similarity score of the historical test requirements.

[0076] After obtaining the text similarity, service similarity and module similarity, the text similarity, service similarity and module similarity may be weighted to obtain a similarity score of the historical test requirements.

[0077] In a specific implementation, different weights can be assigned to the three features according to their importance (i.e., keyword features, service features, and features of the module to which the modified code belongs). After obtaining the text similarity, service similarity, and module similarity, they can be weighted and summed according to the pre-assigned weights to obtain a similarity score.

[0078] After weighted processing is performed on the text similarity, service similarity, and module similarity to obtain the similarity score of the historical test requirements, step 303 is executed.

[0079] Step 303: Filter out the historical test requirements whose similarity scores are ranked in the top N from the historical test requirements to serve as the target historical test requirements.

[0080] After weighting the text similarity, service similarity and module similarity to obtain the similarity scores of the historical test requirements, the historical test requirements ranked in the top N similarity scores can be screened out from the historical test requirements as target historical test requirements, where N is a positive integer.

[0081] The embodiment of the present application can improve the accuracy of test suggestions and thus improve the quality and effect of the test by screening historical test requirements with high similarity to the current test in a feature matching manner for subsequent test suggestion analysis.

[0082] After selecting target historical test requirements that meet the conditions from the historical test requirements based on the similarity scores between the test features and the historical test features corresponding to the historical test requirements, step 103 is performed.

[0083] Step 103: Screen the test features corresponding to the target historical test requirements based on an association rule analysis algorithm to obtain target test features.

[0084] In this example, the association rule analysis algorithm may be, but is not limited to, an Apriori algorithm, which is an algorithm for iterative search based on the properties of frequent item sets.

[0085] In practical applications, the association rule analysis algorithm may also be the FP-Growth algorithm, which optimizes the learning process of association rules by constructing a special data structure—FP tree (Frequent Pattern tree).

[0086] After screening out the target historical test requirements that meet the conditions, the test features corresponding to the target historical test requirements can be screened based on the association rule analysis algorithm to obtain the target test features. Figure 4 This is described in detail as follows.

[0087] Reference Figure 4 , shows a flow chart of the steps of a target test feature screening method provided by an embodiment of the present application. Figure 4 As shown, the target test feature screening method may include: step 401, step 402 and step 403.

[0088] Step 401: Format conversion is performed on the test features corresponding to the target historical test requirements to generate a transaction data set, wherein each transaction in the transaction data set corresponds to one of the target historical test requirements, and each transaction includes a number of test items.

[0089] In this embodiment, after obtaining the target historical test requirements, the test features corresponding to the target historical test requirements may be format converted to generate a transaction data set, that is, the test features corresponding to the target historical test requirements are converted into a format suitable for association rule mining.

[0090] Each transaction in the transaction data set corresponds to a target historical test requirement, and each transaction can contain several test items. In the specific implementation, each transaction can be a list, tuple, or data structure, which contains all the test items under the test requirement. Each test item can be the name and value of a test feature, or an object containing more detailed information.

[0091] After format conversion is performed on the test features corresponding to the target historical test requirements to generate a transaction data set, step 402 is executed.

[0092] Step 402: using an association rule mining algorithm to process each test item in the transaction data set to generate a target frequent item set, each of which contains multiple test items of a target historical test requirement.

[0093] After converting the format of the test features corresponding to the target historical test requirements to generate a transaction data set, an association rule mining algorithm can be used to process each test item in the transaction data set to generate a target frequent item set, where each target frequent item set contains multiple test items of a target historical test requirement. The association rule mining algorithm is the Apriori algorithm, and the generation process of the target frequent item set can be described in detail in combination with the following specific implementation method.

[0094] In a specific implementation of the present application, the above step 402 may include:

[0095] Sub-step S1: Combine the frequent item sets generated in the previous round to generate a new candidate item set, which initially contains only a single test item.

[0096] In this embodiment, when the Apriori algorithm is used for processing, the frequent item sets generated in the previous round can be combined to generate a new candidate item set, and the candidate item set only contains a single test item at the beginning. That is, starting from a single item, a larger candidate item set is gradually generated. A larger candidate item set is gradually generated by combining existing frequent item sets. For example, if {A}, {B} is a frequent item set, {A, B} is generated as a new candidate item set, etc.

[0097] After combining the frequent item sets generated in the previous round to generate new candidate item sets, sub-step S2 is executed.

[0098] Sub-step S2: Calculate the first support corresponding to each candidate item set, where the first support is used to indicate the frequency of occurrence of the candidate item set in the transaction data set.

[0099] After combining the frequent itemsets generated in the previous round to generate new candidate itemsets, the first support corresponding to each candidate itemset can be calculated, and the first support can be used to indicate the frequency of the candidate itemset in the transaction data set. Specifically, the transaction data set can be traversed to calculate the number of times each candidate itemset appears in the data set (i.e., the support).

[0100] After calculating the first support corresponding to each candidate item set, sub-step S3 is executed.

[0101] Sub-step S3: Eliminate the candidate item sets whose first support is less than the first support threshold in the candidate item sets.

[0102] The first support threshold refers to a preset support threshold for screening candidate item sets. The specific value of the first support threshold can be determined according to business requirements, and this embodiment does not impose any limitation on this.

[0103] After calculating the first support corresponding to each candidate item set, the candidate item sets whose first support is less than the first support threshold can be eliminated, that is, the candidate item sets whose support is lower than the preset minimum support threshold are removed.

[0104] Sub-step S4: iteratively executing the step of combining the frequent item sets generated in the previous round to generate new candidate item sets, to the step of eliminating the candidate item sets whose first support is less than the first support threshold, until the iteration condition is met, and the target frequent item set is obtained.

[0105] Furthermore, sub-steps S1 to S3 may be iteratively executed until an iteration condition is satisfied (ie, until no new frequent itemsets can be generated), thereby obtaining a target frequent itemset.

[0106] By applying the Apriori algorithm, the embodiments of the present application can discover potential associations between test features, thereby better understanding the relationship between test requirements, optimizing the test process, and possibly discovering some previously unnoticed test blind spots.

[0107] After the association rule mining algorithm is used to process each test item in the transaction data set to generate a target frequent item set, step 403 is executed.

[0108] Step 403: Evaluate the target frequent item set based on a preset evaluation index, and filter out the target test feature from the target frequent item set according to the evaluation result.

[0109] After the association rule mining algorithm is used to process each test item in the transaction data set to generate a target frequent item set, the target frequent item set can be evaluated based on a preset evaluation index, and the target test feature can be screened out from the target frequent item set according to the evaluation result. In this example, the preset evaluation index can include: at least one of support, confidence, and lift. The implementation process of evaluating and screening the target test feature according to the preset evaluation index can be described in detail in combination with the following specific implementation method.

[0110] In a specific implementation of the present application, the above step 403 may include:

[0111] Sub-step M1: Obtain the second support, confidence and lift corresponding to the target frequent item set, wherein the second support is used to indicate the frequency of occurrence of the target frequent item set in the transaction data set, the confidence is used to indicate the probability that a transaction included in one target frequent item set is also included in another target frequent item set, and the lift is used to indicate the strength of association between the two target frequent item sets.

[0112] In this embodiment, after obtaining the target frequent itemset, the second support, confidence and lift corresponding to the target frequent itemset may be obtained.

[0113] Among them, the second support can be used to indicate the frequency of the target frequent itemset in the transaction data set, that is, the proportion of transactions containing a specific itemset in the data set. For example, for itemsets X and Y, the support is the proportion of transactions containing both X and Y to the total number of transactions. Support is a direct indicator to measure the frequency of occurrence of itemsets.

[0114] Confidence can be used to indicate the probability that a transaction included in one target frequent itemset is also included in another target frequent itemset. For example, for itemsets X and Y, confidence measures the conditional probability that a transaction containing itemset X also contains itemset Y. It indicates the probability that Y also occurs under the condition that X occurs.

[0115] Lift can be used to indicate the strength of association between two target frequent itemsets. For example, for item sets X and Y, lift can be used as an indicator to evaluate the independence or correlation between item sets X and Y.

[0116] After obtaining the second support, confidence and lift corresponding to the target frequent itemset, sub-step M2 is executed.

[0117] Sub-step M2: Filter out from the target frequent item set a frequent item set whose second support is greater than a second support threshold, and / or whose confidence is greater than a confidence threshold, and / or whose lift is greater than a lift threshold, and use the test feature in the frequent item set as the target test feature.

[0118] After obtaining the second support, confidence and lift corresponding to the target frequent itemset, the frequent itemsets whose second support is greater than the second support threshold, and / or whose confidence is greater than the confidence threshold, and / or whose lift is greater than the lift threshold can be screened out from the target frequent itemset, and the test features in the frequent itemset are used as the target test features. For example, the target frequent itemset needs to meet the following conditions before it can be recommended:

[0119] 1. The second support is higher than a certain threshold (such as 0.1). For example, if the BUG type is a technical design type defect with the highest frequency, its support is relatively the highest. When recommending, priority should be given to testing and focusing on defects that may exist in this type.

[0120] 2. The confidence level is higher than a certain threshold (such as 0.7). For example, in requirements AB, defects occur in the same code module or bug type during the development process. When recommending, it is recommended that the test focus on this code module or bug type.

[0121] 3. The lift is higher than 1 (indicating a positive correlation). For example, if the test finds a bug in requirement A through test case 1, and then finds a similar bug in requirement B through test case 1, it means that test case 1 has a strong correlation with this type of bug. Lift>1: There is a positive correlation between item set A and item set B, that is, the appearance of A increases the probability of B appearing. Lift = 1: There is no association between item set A and item set B, that is, the appearance of A has no effect on the appearance of B. Lift <1: There is a negative correlation between item set A and item set B, that is, the appearance of A reduces the probability of B appearing.

[0122] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0123] The embodiment of the present application can mine historical test features that are highly similar to the current test and easy to mine for test suggestions by using the Apriori algorithm, thereby improving the accuracy of the generated test suggestions. At the same time, the Apriori algorithm is highly interpretable and applicable to large-scale data sets.

[0124] After the test features corresponding to the target historical test requirements are screened based on the association rule analysis algorithm to obtain the target test features, step 104 is executed.

[0125] Step 104: clustering the target test features based on preset clustering dimensions to obtain software test suggestion information under the preset clustering dimensions.

[0126] The preset clustering dimension refers to a dimension preset for clustering target test features. In this example, the preset clustering dimension may include at least one of a developer clustering dimension, a test case clustering dimension, and a bug clustering dimension.

[0127] After obtaining the target test features by screening the test features corresponding to the target historical test requirements based on the association rule analysis algorithm, the target test features can be clustered based on the preset clustering dimension to obtain software test recommendation information under the preset clustering dimension. Specifically, the test features matching the preset clustering dimension can be obtained from the target test features, and then clustering can be performed using the K-means clustering algorithm to obtain the clustering results under the preset clustering dimension, and the software test recommendation information can be determined based on the clustering results. Figure 5 This is described in detail as follows.

[0128] Reference Figure 5 , shows a flowchart of the steps of a method for determining software test suggestion information provided by an embodiment of the present application. Figure 5 As shown, the method for determining software test suggestion information may include: step 501, step 502, step 503 and step 504.

[0129] Step 501: Obtain a specified test feature in the target test feature that matches the preset clustering dimension.

[0130] After obtaining the target test features, clustering processing can be performed. Specifically, according to the preset clustering dimensions, the specified test features matching the preset clustering dimensions can be obtained from the target test features. The specified test features can reflect the key behavior patterns in the development and testing process, for example:

[0131] Number and frequency of developer commits: The number and frequency of code commits by developers within a certain period of time.

[0132] Test case coverage: the number of code lines or functional modules covered by each test case.

[0133] Number of bugs: The number of bugs associated with each developer or test case.

[0134] Production issues: The number and types of bugs that each tester or developer missed to production.

[0135] Production rollbacks: The number and type of rollbacks for each test or developer release.

[0136] Specifying test characteristics can help identify which developers or test cases behave similarly, allowing for effective grouping.

[0137] It can be understood that the specified test features listed above are merely examples for better understanding the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0138] After obtaining the designated test features in the target test features that match the preset clustering dimensions, step 502 is performed.

[0139] Step 502: Standardize the specified test features to obtain standardized test features of the preset clustering dimensions.

[0140] After obtaining the specified test features in the target test features that match the preset clustering dimensions, the specified test features can be standardized to obtain standardized test features of the preset clustering dimensions. In the specific implementation, since the quantities of different features may be different (for example, the number of submissions may be dozens to hundreds, while the number of bugs may be in the single digit), the data needs to be standardized so that different features have the same scale.

[0141] In this example, the standardization method may be: a Z-score standardization method, a Min-Max standardization method, or the like.

[0142] After the designated test feature is standardized to obtain the standardized test feature of the preset clustering dimension, step 503 is executed.

[0143] Step 503: clustering the standard test features based on the K-means clustering algorithm to obtain clustering results of the preset clustering dimensions.

[0144] K-means clustering algorithm is a widely used clustering algorithm for dividing data points into K clusters, where the center of each cluster is represented by the mean of all the points in the cluster. When processing standard test features, the K-means algorithm can be applied to discover the potential structure or pattern in the data and classify similar feature points into the same cluster.

[0145] After the specified test features are standardized to obtain the standardized test features of the preset clustering dimension, the K-means clustering algorithm can be used to cluster the standard test features to obtain the clustering results of the preset clustering dimension. The specific clustering process can be:

[0146] 1. Select the clustering dimension K. In the specific implementation, you can use methods such as the Elbow Method or Silhouette Score to determine the optimal number of clusters K, such as plotting the SSE corresponding to different numbers of clusters (SSE is the sum of the squares of the distances from each data point to the centroid of the cluster to which it belongs), select the "inflection point where SSE drops significantly" as the optimal number of clusters, and then perform clustering.

[0147] 2. Initialization: Randomly select K points as the initial cluster centers.

[0148] 3. Assign clusters: Assign each data point to the cluster to which the nearest centroid belongs.

[0149] 4. Update the centroid: Repeatedly calculate the centroid of each cluster, which is the average value of all data points in the cluster.

[0150] 5. Iterate the above steps 3 and 4 until the centroid no longer changes significantly or the maximum number of iterations is reached, thereby obtaining the clustering result under the preset clustering dimension.

[0151] After obtaining the preliminary clustering results, you can also use PCA (Principal Component Analysis) to reduce the data dimension to 2D and draw the clustering results. You can divide the data into different clusters, each cluster representing developers, test cases or bugs with similar behavior patterns, to obtain the final clustering results.

[0152] After the clustering results under the preset clustering dimensions are obtained, step 504 is executed.

[0153] Step 504: Determine software test suggestion information under the preset clustering dimension according to the clustering result.

[0154] After the clustering results under the preset clustering dimensions are obtained, software test suggestion information under the preset clustering dimensions may be determined according to the clustering results.

[0155] Specifically, the software testing suggestions under the developer clustering dimension, the test case clustering dimension, and the bug clustering dimension can be described in detail in combination with the following examples.

[0156] 1. Developer clustering:

[0157] Through cluster analysis, developers with similar commit counts and frequencies can be identified. Based on these clustering results, the following testing recommendations can be recommended:

[0158] 1) Developers who frequently submit code: For developers who frequently submit code, it is recommended to increase the coverage of automated tests to quickly detect potential problems introduced by code changes.

[0159] 2) Developers with low frequency of submission: For developers with low submission frequency, more detailed code review and manual testing are recommended to ensure the quality of each submission.

[0160] 3) Developers with medium-frequency submissions: For developers with moderate submission frequency, it is recommended to balance automated testing and manual testing to ensure effective use of testing resources.

[0161] 2. Test case clustering:

[0162] Through cluster analysis, we can identify test cases with similar coverage and number of bugs. Based on these clustering results, we can recommend the following test suggestions:

[0163] 1) Test cases with high coverage and a large number of bugs: These test cases may cover key functional modules. It is recommended to execute these test cases first and increase the frequency of regression testing.

[0164] 2) Test cases with low coverage and a small number of bugs: These test cases may cover non-critical functional modules. It is recommended to optimize the design of these test cases to improve their coverage.

[0165] 3) Test cases with medium coverage and number of bugs: It is recommended to regularly evaluate the effectiveness of these test cases to ensure that they can continue to discover potential problems.

[0166] 3. BUG clustering:

[0167] Cluster analysis can be used to identify bugs of similar types and numbers. Based on these clustering results, the following testing suggestions can be recommended:

[0168] 1) High-frequency BUG clusters: For frequently occurring BUG types, it is recommended to add targeted testing, especially automated regression testing, to quickly discover and fix such problems.

[0169] 2) Low-frequency BUG clusters: For the types of BUGs that occur occasionally, it is recommended to conduct in-depth analysis to find out the root cause and increase the corresponding coverage in the test cases.

[0170] 3) Medium-frequency bug clusters: For bug types that occur with medium frequency, it is recommended to review and update test cases regularly to ensure that they can effectively capture such problems.

[0171] The embodiment of the present application further optimizes the recommendation results by deeply analyzing user behavior data, mining the user's testing habits and preferences. User behavior analysis includes association analysis and cluster analysis, which can identify developers, test cases and bugs with similar behavior patterns, thereby providing more personalized and accurate test suggestions.

[0172] In this embodiment, initial test suggestions under preset clustering dimensions can be obtained through clustering, and then the initial test suggestions can be processed according to the preset sorting rules and diversity suggestion screening rules to generate final software test suggestions. Figure 6 This is described in detail as follows.

[0173] Reference Figure 6 , shows a flowchart of the steps of a method for obtaining software test suggestion information provided by an embodiment of the present application. Figure 6 As shown, the method for obtaining software test suggestion information may include: step 601, step 602 and step 603.

[0174] Step 601: clustering the target test features based on preset clustering dimensions to obtain initial test suggestion information under the preset clustering dimensions.

[0175] In this embodiment, after obtaining the target test features, the target test features can be clustered based on the preset clustering dimensions to obtain initial test suggestion information under the preset clustering dimensions. The implementation process can refer to the description of steps 501 to 504 above, and this embodiment will not be repeated here.

[0176] After clustering the target test features based on the preset clustering dimensions to obtain initial test suggestion information under the preset clustering dimensions, step 602 is executed.

[0177] Step 602: sort the initial test suggestion information under the preset clustering dimension according to a preset sorting rule to obtain the test suggestion sorting information under the preset clustering dimension under different sorting rules.

[0178] After clustering the target test features based on the preset clustering dimensions to obtain the initial test suggestion information under the preset clustering dimensions, the initial test suggestion information under the preset clustering dimensions can be sorted according to the preset sorting rules to obtain the test suggestion sorting information under the preset clustering dimensions under different sorting rules.

[0179] In this example, the preset sorting rule may be at least one of a priority sorting rule, an influence sorting rule, and a historical data sorting rule.

[0180] The priority sorting rule refers to sorting the test suggestions according to their urgency and importance. For example, test suggestions for high-frequency bugs should be prioritized over test suggestions for low-frequency bugs.

[0181] The influence ranking rule refers to ranking the test suggestions based on their impact on system stability and quality. For example, test suggestions covering key functional modules should take precedence over test suggestions covering non-key functional modules, and problems that occur in production should be given special attention.

[0182] The historical data sorting rule refers to sorting the test suggestions in the historical data according to their effectiveness. For example, test suggestions that found a large number of bugs in the past should be given priority over test suggestions that found fewer bugs, etc.

[0183] The implementation process of sorting the initial test suggestion information according to the preset sorting rule may include at least one of the following:

[0184] 1. When the sorting rule is a priority sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the urgency and importance index of the test suggestion to obtain the test suggestion sorting information under the priority sorting rule of the preset clustering dimension.

[0185] 2. When the sorting rule is an influence sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the influence coefficient of the test suggestion on system stability and quality to obtain the test suggestion sorting information under the influence sorting rule of the preset clustering dimension.

[0186] 3. When the sorting rule is a historical data sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the effectiveness of the test suggestions in the historical data to obtain the test suggestion sorting information of the preset clustering dimension under the historical data sorting rule.

[0187] The embodiment of the present application can sort the test suggestions according to a preset sorting rule, so that the most important and relevant test suggestions can be placed at the front, thereby improving the accuracy of the test suggestion recommendation.

[0188] After sorting, the sorted test suggestions can also be filtered to remove irrelevant or low-value test suggestions to ensure that the recommended test suggestions are of high quality. In the specific implementation, filtering can be performed according to the following criteria:

[0189] 1. Relevance: Filter out test suggestions that are not relevant to the current test goal. For example, if the current test goal is performance testing, filter out suggestions related to functional testing.

[0190] 2. Repeatability: Filter out duplicate test suggestions to avoid wasting test resources.

[0191] After the initial test suggestion information under the preset clustering dimension is sorted according to the preset sorting rule to obtain the test suggestion sorting information under the preset clustering dimension under different sorting rules, step 603 is performed.

[0192] Step 603: Filter the test suggestion sorting information according to the diversity suggestion filtering rule to obtain the software test suggestion information.

[0193] Diversity suggestion screening rules refer to pre-set rules for screening test suggestions to ensure that the recommended test suggestions cover different test dimensions and scenarios.

[0194] After the initial test suggestion information under the preset clustering dimension is sorted according to the preset sorting rule to obtain the test suggestion sorting information under the preset clustering dimension under different sorting rules, the test suggestion sorting information can be filtered according to the diversity suggestion filtering rule to obtain the software test suggestion information.

[0195] In this example, the diversity suggestion screening rule may be at least one of the following rules: covering different functional modules, including different test types, etc. The implementation process of the test suggestion screening may include the following steps:

[0196] 1. Filtering out test suggestion information covering different functional modules from the test suggestion sorting information to obtain first test suggestion information; and / or

[0197] 2. Filter out test suggestion information containing different test types from the test suggestion sorting information to obtain second test suggestion information;

[0198] 3. Determine software test suggestion information based on the first test suggestion information and / or the second test suggestion information.

[0199] In this example, the filter rules covering different functional modules can ensure that the recommended test suggestions cover different functional modules of the system to comprehensively test all parts of the system. The filter rules covering different test types can ensure that the recommended test suggestions include different types of tests, such as functional testing, performance testing, security testing, etc.

[0200] After the test suggestions are filtered according to the above filtering rules, different categories of resources such as test cases, test scripts, test data, etc. can be included in the recommendation list at the same time.

[0201] The embodiment of the present application can ensure that the recommended test suggestions cover different test dimensions and scenarios by pre-setting the diversity suggestion screening rules, so as to improve the comprehensiveness and effectiveness of the test.

[0202] After clustering the target test features based on the preset clustering dimensions to obtain software test suggestion information under the preset clustering dimensions, step 105 is executed.

[0203] Step 105: Recommend the software testing suggestion information to the user.

[0204] After obtaining the software test suggestion information, the software test suggestion information can be recommended to the user. Specifically, the test suggestion recommendation can be made in a visual display manner, such as using a chart, a list, etc. to intuitively display the recommendation results.

[0205] In this embodiment, an interactive function may also be provided to allow users to rate, comment on and provide feedback on the recommendation results, so as to further optimize the recommendation algorithm and thus improve the accuracy of subsequent test suggestion recommendations.

[0206] The software testing recommendation method provided in the embodiment of the present application obtains the test features of the software to be tested by extracting features from the technical documents of the software to be tested. According to the similarity score between the test features and the historical test features corresponding to the historical test requirements, the target historical test requirements that meet the conditions are screened from the historical test requirements. The test features corresponding to the target historical test requirements are screened based on the association rule analysis algorithm to obtain the target test features. The target test features are clustered based on the preset clustering dimensions to obtain the software test recommendation information under the preset clustering dimensions. The software test recommendation information is recommended to the user. The embodiment of the present application automatically analyzes the technical documents of the software to be tested and generates test recommendations in combination with historical test features, which can avoid quality fluctuations caused by differences in tester experience and ability levels, reduce dependence on tester experience and subjective judgment, improve the systematicness and consistency of test recommendations, and at the same time, improve software testing efficiency. At the same time, by comprehensively analyzing the technical documents of the software to be tested and performing cluster analysis in combination with the preset clustering dimensions, the coverage of software testing scenarios and risk points can be improved, and changes in requirements and codes can be quickly responded to, providing real-time test recommendations and optimization recommendations to adapt to the rapid iteration development environment.

[0207] Reference Figure 7 , which shows a schematic diagram of the structure of a recommended device for software testing provided by an embodiment of the present application, such as Figure 7 As shown, the software testing recommendation device 700 may include the following modules:

[0208] A test feature acquisition module 710 is used to extract features from the technical documents of the software to be tested to obtain the test features of the software to be tested;

[0209] A target test requirement acquisition module 720 is used to filter out target historical test requirements that meet the conditions from the historical test requirements according to the similarity scores between the test characteristics and the historical test characteristics corresponding to the historical test requirements;

[0210] A target test feature acquisition module 730 is used to perform feature screening on the test features corresponding to the target historical test requirements based on an association rule analysis algorithm to obtain target test features;

[0211] A software test suggestion acquisition module 740 is used to cluster the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension;

[0212] The software testing suggestion recommendation module 750 is used to recommend the software testing suggestion information to the user.

[0213] Optionally, the test feature acquisition module includes:

[0214] A test document acquisition unit, used to acquire product documents, development documents and release sheets of the software to be tested;

[0215] A feature extraction unit, configured to process the product document, the development document and the release form based on natural language processing technology to obtain keyword features, service features and features of the module to which the modified code belongs;

[0216] The test feature acquisition unit is used to preprocess the keyword features, the service features and the features of the module to which the modified code belongs, obtain the preprocessed keyword features, service features and the features of the module to which the modified code belongs, and use the preprocessed keyword features, service features and the features of the module to which the modified code belongs as the test features.

[0217] Optionally, the target test requirement acquisition module includes:

[0218] A similarity calculation unit, used to calculate the text similarity, service similarity and module similarity between the requirements to be tested corresponding to the software to be tested and the historical test requirements according to the test characteristics and the historical test characteristics;

[0219] A similarity score acquisition unit, used for performing weighted processing on the text similarity, the service similarity and the module similarity to obtain a similarity score of the historical test requirement;

[0220] The target test requirement acquisition unit is used to filter out the historical test requirements with similarity scores ranked in the top N from the historical test requirements to serve as the target historical test requirements.

[0221] Optionally, the target test feature acquisition module includes:

[0222] A transaction data set generating unit, configured to convert the format of the test features corresponding to the target historical test requirements to generate a transaction data set, wherein each transaction in the transaction data set corresponds to one of the target historical test requirements, and each transaction includes a plurality of test items;

[0223] A target frequent item set generating unit, used for processing each test item in the transaction data set by using an association rule mining algorithm to generate a target frequent item set, each of which contains a plurality of test items of a target historical test requirement;

[0224] The target test feature screening unit is used to evaluate the target frequent item set based on a preset evaluation index, and screen out the target test feature from the target frequent item set according to the evaluation result.

[0225] Optionally, the target frequent item set generating unit includes:

[0226] The candidate item set generation subunit is used to combine the frequent item sets generated in the previous round to generate a new candidate item set. The candidate item set contains only a single test item at the beginning.

[0227] A first support calculation subunit, used to calculate a first support corresponding to each of the candidate item sets, where the first support is used to indicate the frequency of occurrence of the candidate item set in the transaction data set;

[0228] A candidate item set elimination subunit, used to eliminate the candidate item set whose first support is less than a first support threshold in the candidate item set;

[0229] The target frequent item set acquisition subunit is used to iteratively execute the candidate item set generation subunit, the first support calculation subunit and the candidate item set elimination subunit until an iteration condition is met to obtain the target frequent item set.

[0230] Optionally, the target test feature screening unit includes:

[0231] An evaluation index acquisition subunit is used to acquire a second support, confidence and lift corresponding to the target frequent itemset, wherein the second support is used to indicate the frequency of occurrence of the target frequent itemset in the transaction data set, the confidence is used to indicate the probability that a transaction included in one target frequent itemset is also included in another target frequent itemset, and the lift is used to indicate the strength of association between the two target frequent itemsets;

[0232] The target test feature acquisition subunit is used to filter out the frequent item sets whose second support is greater than the second support threshold, and / or the confidence is greater than the confidence threshold, and / or the lift is greater than the lift threshold from the target frequent item set, and use the test features in the frequent item sets as the target test features.

[0233] Optionally, the software testing suggestion acquisition module includes:

[0234] A designated test feature acquisition unit, used to acquire a designated test feature in the target test feature that matches the preset clustering dimension;

[0235] A standardized feature acquisition unit, used for performing a standardized process on the specified test feature to obtain a standardized test feature of the preset clustering dimension;

[0236] A clustering result acquisition unit, used for performing clustering processing on the standard test features based on a K-means clustering algorithm to obtain a clustering result of the preset clustering dimension;

[0237] A software test suggestion determination unit, configured to determine software test suggestion information under the preset clustering dimension according to the clustering result;

[0238] The preset clustering dimensions include: developer clustering dimension, test case clustering dimension and bug clustering dimension.

[0239] Optionally, the software testing suggestion acquisition module includes:

[0240] An initial test suggestion acquisition unit, configured to perform clustering processing on the target test features based on a preset clustering dimension to obtain initial test suggestion information under the preset clustering dimension;

[0241] A test suggestion sorting unit, used to sort the initial test suggestion information under the preset clustering dimension according to a preset sorting rule, to obtain the test suggestion sorting information under different sorting rules of the preset clustering dimension;

[0242] The software test suggestion information acquisition unit is used to filter the test suggestion sorting information according to the diversity suggestion filtering rule to obtain the software test suggestion information.

[0243] Optionally, the test suggestion sorting unit includes:

[0244] A first sorting information acquisition subunit is used to sort the initial test suggestion information under the preset clustering dimension according to the urgency and importance index of the test suggestion when the sorting rule is a priority sorting rule, so as to obtain the test suggestion sorting information of the preset clustering dimension under the priority sorting rule;

[0245] A second sorting information acquisition subunit is used to sort the initial test suggestion information under the preset clustering dimension according to the influence coefficient of the test suggestion on system stability and quality when the sorting rule is an influence sorting rule, so as to obtain the test suggestion sorting information of the preset clustering dimension under the influence sorting rule;

[0246] The third sorting information acquisition subunit is used to sort the initial test suggestion information under the preset clustering dimension according to the effectiveness of the test suggestions in the historical data when the sorting rule is a historical data sorting rule, so as to obtain the test suggestion sorting information of the preset clustering dimension under the historical data sorting rule.

[0247] Optionally, the software testing suggestion information acquisition unit includes:

[0248] A first test suggestion acquisition subunit is used to filter out test suggestion information covering different functional modules from the test suggestion sorting information to obtain first test suggestion information;

[0249] A second test suggestion acquisition subunit is used to filter out test suggestion information containing different test types from the test suggestion sorting information to obtain second test suggestion information;

[0250] The software test suggestion determining subunit is used to determine the software test suggestion information according to the first test suggestion information and / or the second test suggestion information.

[0251] The software test recommendation device provided in the embodiment of the present application obtains the test features of the software to be tested by extracting features from the technical documents of the software to be tested. According to the similarity score between the test features and the historical test features corresponding to the historical test requirements, the target historical test requirements that meet the conditions are screened from the historical test requirements. The test features corresponding to the target historical test requirements are screened based on the association rule analysis algorithm to obtain the target test features. The target test features are clustered based on the preset clustering dimensions to obtain the software test recommendation information under the preset clustering dimensions. The software test recommendation information is recommended to the user. The embodiment of the present application automatically analyzes the technical documents of the software to be tested and generates test recommendations in combination with historical test features, which can avoid quality fluctuations caused by differences in tester experience and ability levels, reduce dependence on tester experience and subjective judgment, improve the systematicness and consistency of test recommendations, and at the same time, improve software testing efficiency. At the same time, by comprehensively analyzing the technical documents of the software to be tested and performing cluster analysis in combination with the preset clustering dimensions, the coverage of software test scenarios and risk points can be improved, and changes in requirements and codes can be quickly responded to, providing real-time test recommendations and optimization recommendations to adapt to the rapid iteration development environment.

[0252] An embodiment of the present application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the above-mentioned recommended method for software testing when executed by the processor.

[0253] Figure 8 FIG. 8 is a schematic diagram showing the structure of an electronic device 800 according to an embodiment of the present invention. Figure 8 As shown, the electronic device 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 802 or computer program instructions loaded from a storage unit 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 can also be stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0254] Multiple components in the electronic device 800 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, a mouse, a microphone, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0255] The various processes and processing described above may be performed by the processing unit 801. For example, the method of any of the above embodiments may be implemented as a computer software program, which is tangibly contained in a computer-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the CPU 801, one or more actions in the method described above may be performed.

[0256] In addition, an embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned recommended method for software testing when executed by a processor.

[0257] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0258] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0259] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminals (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0260] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0261] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal so that a series of operating steps are executed on the computer or other programmable terminal to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0262] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0263] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or terminal including the elements.

[0264] The above is a detailed introduction to a recommended method for software testing, a recommended device for software testing, an electronic device and a computer-readable storage medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for a person skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A recommended method for software testing, characterized in that: The method comprises: Extracting features from the technical documents of the software to be tested to obtain test features of the software to be tested; Filtering out qualified target historical test requirements from the historical test requirements according to the similarity scores between the test characteristics and the historical test characteristics corresponding to the historical test requirements; Based on the association rule analysis algorithm, feature screening is performed on the test features corresponding to the target historical test requirements to obtain target test features; Clustering the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension; The software testing suggestion information is recommended to the user.

2. The method according to claim 1, characterized in that: The extracting features of the technical documents of the software to be tested to obtain the test features of the software to be tested includes: Obtain product documentation, development documentation and release notes for the software to be tested; Processing the product document, the development document and the release form based on natural language processing technology to obtain keyword features, service features and features of the module to which the modified code belongs; The keyword features, the service features and the features of the module to which the modified code belongs are preprocessed to obtain preprocessed keyword features, service features and features of the module to which the modified code belongs, and the preprocessed keyword features, service features and features of the module to which the modified code belongs are used as the test features.

3. The method according to claim 2, characterized in that The step of screening out target historical test requirements that meet the conditions from the historical test requirements according to the similarity scores between the test features and the historical test features corresponding to the historical test requirements includes: According to the test features and the historical test features, calculating the text similarity, service similarity and module similarity between the requirements to be tested corresponding to the software to be tested and the historical test requirements; Performing weighted processing on the text similarity, the service similarity and the module similarity to obtain a similarity score of the historical test requirements; The historical test requirements ranked in the top N in terms of similarity scores are selected from the historical test requirements to serve as the target historical test requirements.

4. The method according to claim 1, characterized in that: The feature screening of the test features corresponding to the target historical test requirements based on the association rule analysis algorithm to obtain the target test features includes: Performing format conversion on the test features corresponding to the target historical test requirements to generate a transaction data set, wherein each transaction in the transaction data set corresponds to one of the target historical test requirements, and each transaction includes a number of test items; Using an association rule mining algorithm to process each test item in the transaction data set to generate a target frequent item set, each of the target frequent item sets containing multiple test items of a target historical test requirement; The target frequent item set is evaluated based on a preset evaluation index, and the target test feature is screened out from the target frequent item set according to the evaluation result.

5. The method according to claim 4, characterized in that The method of using an association rule mining algorithm to process each test item in the transaction data set to generate a target frequent item set includes: Combine the frequent item sets generated in the previous round to generate a new candidate item set, which initially contains only a single test item; Calculating a first support corresponding to each of the candidate item sets, where the first support is used to indicate the frequency of occurrence of the candidate item set in the transaction data set; Eliminate the candidate item set whose first support is less than the first support threshold in the candidate item set; Iteratively execute the step of combining the frequent item sets generated in the previous round to generate a new candidate item set, until the step of eliminating the candidate item sets whose first support is less than the first support threshold in the candidate item sets, until the iteration condition is met, and the target frequent item set is obtained.

6. The method according to claim 4, characterized in that The step of evaluating the target frequent item set based on a preset evaluation index, and selecting the target test feature from the target frequent item set according to the evaluation result, includes: Obtaining a second support, confidence, and lift corresponding to the target frequent itemset, wherein the second support is used to indicate the frequency of occurrence of the target frequent itemset in the transaction data set, the confidence is used to indicate the probability that a transaction included in one target frequent itemset is also included in another target frequent itemset, and the lift is used to indicate the strength of association between the two target frequent itemsets; A frequent item set whose second support is greater than a second support threshold, and / or whose confidence is greater than a confidence threshold, and / or whose lift is greater than a lift threshold is screened out from the target frequent item set, and a test feature in the frequent item set is used as the target test feature.

7. The method according to claim 1, characterized in that The clustering process of the target test features based on the preset clustering dimension to obtain software test suggestion information under the preset clustering dimension includes: Acquire a specified test feature in the target test feature that matches the preset clustering dimension; Performing standardization processing on the specified test features to obtain standardized test features of the preset clustering dimensions; Clustering the standard test features based on the K-means clustering algorithm to obtain a clustering result of the preset clustering dimension; Determining software test suggestion information under the preset clustering dimension according to the clustering result; The preset clustering dimensions include: developer clustering dimension, test case clustering dimension and bug clustering dimension.

8. The method according to claim 1, characterized in that The clustering process of the target test features based on the preset clustering dimension to obtain software test suggestion information under the preset clustering dimension includes: Clustering the target test features based on a preset clustering dimension to obtain initial test suggestion information under the preset clustering dimension; Sorting the initial test suggestion information under the preset clustering dimension according to a preset sorting rule to obtain the test suggestion sorting information under different sorting rules of the preset clustering dimension; The test suggestion sorting information is screened according to the diversity suggestion screening rule to obtain the software test suggestion information.

9. The method according to claim 8, characterized in that The step of sorting the initial test suggestion information under the preset clustering dimension according to the preset sorting rule to obtain the test suggestion sorting information under different sorting rules of the preset clustering dimension includes: In the case where the sorting rule is a priority sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the urgency and importance index of the test suggestion to obtain the test suggestion sorting information of the preset clustering dimension under the priority sorting rule; and / or In the case where the sorting rule is an influence sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the influence coefficient of the test suggestion on system stability and quality to obtain the test suggestion sorting information of the preset clustering dimension under the influence sorting rule; and / or In the case where the sorting rule is a historical data sorting rule, the initial test suggestion information under the preset clustering dimension is sorted according to the validity of the test suggestions in the historical data to obtain the test suggestion sorting information of the preset clustering dimension under the historical data sorting rule.

10. The method according to claim 8, characterized in that The step of screening the test suggestion sorting information according to the diversity suggestion screening rule to obtain the software test suggestion information includes: Filtering out test suggestion information covering different functional modules from the test suggestion sorting information to obtain first test suggestion information; and / or Filtering out test suggestion information containing different test types from the test suggestion sorting information to obtain second test suggestion information; The software test suggestion information is determined according to the first test suggestion information and / or the second test suggestion information.

11. A recommended device for software testing, characterized in that: The device comprises: A test feature acquisition module is used to extract features from the technical documents of the software to be tested to obtain the test features of the software to be tested; A target test requirement acquisition module, configured to filter out target historical test requirements that meet the conditions from the historical test requirements according to a similarity score between the test feature and the historical test feature corresponding to the historical test requirement; A target test feature acquisition module is used to perform feature screening on the test features corresponding to the target historical test requirements based on an association rule analysis algorithm to obtain target test features; A software test suggestion acquisition module, used to cluster the target test features based on a preset clustering dimension to obtain software test suggestion information under the preset clustering dimension; The software testing suggestion recommendation module is used to recommend the software testing suggestion information to the user.

12. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the recommended method for software testing according to any one of claims 1 to 10 when executing the program.

13. A computer-readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the recommended method for software testing according to any one of claims 1 to 10.

Images