A test case reuse automation management method, system, device and medium

Abstract

The application discloses a test case reuse automation management method, system, device and medium, relates to the field of system testing, and comprises the following steps: obtaining a requirement text submitted by a tester; sequentially performing keyword matching and semantic matching on the requirement text and test cases in a test case library, sorting the matched test cases according to reuse priorities, and generating a semantic matching case set; performing rule verification on the requirement text and the test cases in the semantic matching case set, and displaying a reuse scheme to guide the tester to reuse the corresponding test cases; after the reused test cases are checked for duplication, the test cases are stored in the test case library; and test cases with a reuse rate lower than a set threshold in the test case library are deleted at a set time interval. The application can efficiently reuse test cases, significantly reduces the time for manually writing test cases, ensures that the reused test cases meet current testing requirements, and thus improves the efficiency and quality of testing.

Description

Technical Field

[0001] This application relates to the field of system testing, and in particular to an automated management method, system, device, and medium for test case reuse. Background Technology

[0002] Current mainstream test case management solutions (such as TestRail, JiraTestManagement, etc.) have many shortcomings in practical applications and are unable to effectively solve the core pain points of test case reuse and automated management.

[0003] Regarding reuse mechanisms, the relevant technologies are based on simple keyword searches, manual labeling, and lack intelligent recommendations, resulting in insufficient keyword matching accuracy and easy omission of implicit requirements. For example, the "user login" scenario cannot be associated with the "verification code invalidation" reverse use case, and reuse relies on manual experience, which is inefficient.

[0004] In terms of classification and judgment, the relevant technologies rely on manual classification, lack real-time validity verification, and do not support proportional verification, which leads to type confusion and execution failure. For example, interface test cases are misused for functional testing, outdated test cases cannot be detected, resulting in low credibility of test results, as well as problems such as high missing rate and insufficient coverage of reverse test cases.

[0005] In terms of dynamic maintenance, the relevant technologies use a static use case library, which requires manual cleaning periodically. There is no algorithm self-optimization mechanism, which leads to redundant expansion of the use case library, reduced retrieval speed, inability of the matching algorithm to adapt to new scenarios, and a year-on-year decrease in accuracy. When requirements change, use cases need to be rebuilt, resulting in high maintenance costs.

[0006] In terms of technical architecture, the relevant technologies use a single database for storage, lack distributed retrieval capabilities, and have closed rule configurations, resulting in a retrieval time of over 10 seconds for millions of test cases. It cannot support complex rules (such as cross-project ratio verification), and non-technical personnel cannot customize rules.

[0007] In summary, the core problems that existing technologies cannot solve include: (1) Lack of semantic understanding and implicit requirement matching: Traditional keyword matching cannot handle the ambiguity of natural language, resulting in a reuse scenario coverage rate of less than 30%. (2) Lack of a continuous optimization mechanism for test case quality: Traditional solutions rely on manual periodic cleaning of the test case library, which is time-consuming, labor-intensive, and prone to subjective judgment errors. The average retention time of outdated test cases is as long as 18 months. (3) Lack of industry standard compliance management: Existing tools do not support industry-specific rules such as positive / reverse test case ratio verification, which requires the testing team to manually compile statistics. The compliance check accounts for 10% of the time. Summary of the Invention

[0008] The purpose of this application is to provide a method, system, device, and medium for automated management of test case reuse, which can efficiently reuse test cases and improve the efficiency and quality of testing.

[0009] To achieve the above objectives, this application provides the following solution:

[0010] Firstly, this application provides an automated management method for test case reuse, including:

[0011] Obtain the requirement text submitted by the testers;

[0012] The requirement text is matched with the test cases in the test case library by keywords and semantics in turn. The matched test cases are sorted according to the reuse priority to generate a semantic matching test case set.

[0013] The requirement text is matched with the test cases in the semantic matching test case set. Rule verification is performed, and a reuse plan is generated and displayed to guide testers to reuse the corresponding test cases. The rule verification includes test case type consistency verification, environment adaptability verification, and positive and negative test case ratio verification.

[0014] After deduplication verification, the reused test cases are stored in the test case library.

[0015] Test cases with a reuse rate lower than a set threshold are deleted from the test case library at set time intervals.

[0016] Secondly, this application provides an automated management system for test case reuse, comprising:

[0017] A test case library for storing test cases using a hybrid storage architecture;

[0018] The user interface is used to obtain the requirement text submitted by the testers and display the generated reuse plan to guide the testers to reuse the corresponding test cases;

[0019] The intelligent matching module is used to perform keyword matching and semantic matching on the requirement text and the test cases in the test case library in sequence, and sort the matched test cases according to the reuse priority to generate a semantic matching test case set;

[0020] The rule engine module is used to perform rule verification on the requirement text and the test cases in the semantic matching test case set, and generate a reuse scheme; the rule verification includes test case type consistency verification, environment adaptability verification, and positive and negative test case ratio verification.

[0021] The test case library management module is used to perform deduplication verification on reused test cases, store them in the test case library, and delete test cases in the test case library with a reuse rate lower than a set threshold at set time intervals.

[0022] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described automated management method for test case reuse.

[0023] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described automated management method for test case reuse.

[0024] According to the specific embodiments provided in this application, this application has the following technical effects:

[0025] This application provides a method, system, device, and medium for automated management of test case reuse. Testers can efficiently reuse test cases, significantly reducing the time spent manually writing them. Simultaneously, rule validation automatically determines the type and validity of test cases, ensuring that reused test cases meet current testing requirements, thereby improving testing efficiency and quality. Furthermore, as test cases are continuously accumulated and optimized, the test case matching and rule judgment capabilities will also continuously improve, providing more comprehensive and accurate support for software testing. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is an application environment diagram of an automated management method for test case reuse in one embodiment of this application.

[0028] Figure 2 This is a flowchart illustrating an automated management method for test case reuse, provided as an embodiment of this application.

[0029] Figure 3 This is a diagram illustrating the rules for determining the function / interface / security test type in one embodiment of this application.

[0030] Figure 4 This is a schematic diagram illustrating the process of use case execution monitoring in one embodiment of this application.

[0031] Figure 5This is a schematic diagram of the functional modules of a test case reuse automated management system provided in one embodiment of this application.

[0032] Figure 6 This is a schematic diagram of a test case library in one embodiment of this application. Detailed Implementation

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

[0034] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0035] The automated management method for test case reuse provided in this application can be applied to, for example... Figure 1 In the application environment shown, terminal 101 communicates with server 102 via a network. A data storage system can store the data that server 102 needs to process. The data storage system can be set up independently, integrated into server 102, or placed in the cloud or on other servers. Terminal 101 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Server 102 can be implemented using a standalone server, a server cluster consisting of multiple servers, or a cloud server.

[0036] In one exemplary embodiment, such as Figure 2 As shown, an automated management method for test case reuse is provided. This method is executed by a computer device, specifically a terminal or server, or both. In this embodiment, the method is applied to... Figure 1 Taking server 102 as an example, the explanation includes the following steps 201 to 205.

[0037] Step 201: Obtain the requirement text submitted by the testers. Specifically, the testers fill out a requirement form containing basic information, scenario description, and special requirements through the user interface, which serves as the requirement text.

[0038] Step 202: Perform keyword matching and semantic matching on the requirement text and the test cases in the test case library in sequence, and sort the matched test cases according to the reuse priority to generate a semantic matching test case set.

[0039] In a specific application example, step 202 includes steps 21 to 23.

[0040] Step 21: Perform keyword matching between the requirement text and the test cases in the test case library to obtain a preliminary candidate test case set.

[0041] Specifically, step 21 includes the following steps (1) to (5).

[0042] (1) The required text is subjected to regularization and word segmentation (e.g., Jieba word segmentation) in sequence, and high-frequency keywords are extracted using the Term Frequency-Inverse Document Frequency (TF-IDF) algorithm. The high-frequency keywords are words in the required text whose word frequency is greater than a set proportion (e.g., 5%), that is, the proportion of the number of times the word appears in the document to the total number of times exceeds 5%.

[0043] Further calculate the TF-IDF weights for each word: ;in, For vocabulary In the document TF-IDF weights in For vocabulary In the document Word frequency, i.e., vocabulary In the document The number of times it appears in the document divided by the number of times it appears in the document Total number of words in For vocabulary The frequency of reverse files, , Total number of documents For words containing The number of documents.

[0044] TF-IDF weights are used to quantify the importance of each keyword in a test case, facilitating subsequent test case retrieval, classification, and similarity matching, thereby enabling more efficient test case reuse. For example, when a user searches for test cases for a specific function, test cases with high matching scores can be quickly filtered based on the TF-IDF weights of keywords, and relevant content with high matching scores can be displayed first.

[0045] (2) Match the high-frequency keywords with the feature word library of each pre-established test scenario to determine the test scenario of the requirement text.

[0046] The test scenarios include functional testing (such as user operation flow, business logic implementation, etc.), interface testing (such as application programming interface calls, data interaction, etc.), and security testing (such as access control, data encryption, etc.). By matching the extracted high-frequency keywords with the feature word library of each test scenario, if the matching degree exceeds 60%, the requirement text is determined to belong to that test scenario.

[0047] like Figure 3 As shown, firstly, the use case descriptions for each test scenario are extracted, thus obtaining the feature word library. Then, the feature word library for the interface test scenario is matched with the high-frequency keywords using regular expressions. If a matching feature word exists, the requirement text is marked as an interface test; otherwise, the feature word library for the security test scenario is matched with the high-frequency keywords using regular expressions. If a matching feature word exists, the requirement text is marked as a security test; otherwise, the requirement text is marked as a functional test.

[0048] Each test scenario's feature word library stores frequently occurring keywords that characterize the core attributes of a specific test scenario, extracted from multiple sources such as historical test case libraries, business requirement documents, and user feedback records. For example, in e-commerce system testing, words such as "order placement," "inventory deduction," and "payment success" frequently appear in order process-related test cases, and these words can be selected as feature words for that scenario.

[0049] Specifically, the feature word library for each test scenario includes business keywords related to the test scenario (such as "order" and "payment" in e-commerce scenarios), technical keywords (such as "application programming interface" and "database query"), operation keywords (such as "add", "delete", and "modify"), status keywords (such as "success", "failure", and "exception"), and data type keywords (such as "string", "number", and "date"). These feature word libraries are summarized based on the actual needs of different business or technical scenarios and are used to accurately describe and identify various elements and behaviors in that scenario.

[0050] The feature word library provides a basis for classification and retrieval of test cases. By using feature words, relevant test cases can be quickly located, improving the reuse efficiency of test cases. The test case library is the practical source of the feature word library. After new test cases are executed, if new scenario features or keywords are found, they can be fed back to the feature word library for updating and improvement, continuously optimizing the feature word library to make it more in line with actual test scenarios.

[0051] (3) Based on the test scenario of the requirement text, irrelevant words in the high-frequency keywords are filtered using a predefined tag library to obtain the requirement keywords. The predefined tag library includes multiple feature words and category tags for each feature word. The category tags represent different test scenarios.

[0052] Specifically, the high-frequency keywords in the requirement text are compared with the feature words in the predefined tag library, and the similarity is calculated. When the similarity between the high-frequency keywords and the feature words of a certain type of tag is less than 30%, they are judged as irrelevant words and filtered out.

[0053] The predefined tag library is obtained by collecting a large number of historical test cases, manually labeling them with type tags (functional, interface, security), and then extracting the corresponding feature words for each type of tag. The predefined tag library is the product of abstracting, integrating, and standardizing the feature word library. It extracts common category tags, such as "functional", "performance", and "security" tags.

[0054] The feature vocabulary library provides specific vocabulary materials and scenario basis for the predefined tag library, while the predefined tag library provides a unified classification framework and management standard for the feature vocabulary library.

[0055] This application further constructs a data closed loop through a machine learning model to achieve continuous optimization of the predefined tag library. Specifically, it uses the tag annotation data of historical test cases, execution results, and related requirement text features as model inputs, extracts semantic features using natural language processing techniques, and combines test execution feedback to form a training dataset. The model output includes three parts: 1) Tag confidence score: evaluating the matching accuracy between existing tags and test cases; 2) Similar tag clustering results: identifying tags with similar semantics but different expressions, and assisting in merging redundant tags; 3) Recommended new tags: predicting potential tag classifications based on domain knowledge graphs and industry trends.

[0056] (4) Extract the test case description text of each test case from the test case library.

[0057] (5) Calculate the similarity between the required keywords and the test case description text of each test case, and determine the preliminary candidate test case set based on the similarity.

[0058] Specifically, the BM25 (Best Matching 25) algorithm is used to calculate the similarity between requirement keywords and use case description text.

[0059] Step 22: Convert the requirement text and the test cases in the preliminary candidate test case set into semantic vectors to obtain requirement semantic vectors and multiple test case semantic vectors.

[0060] Specifically, a pre-trained model based on Transformer Bidirectional Encoder Representations from Transformers (BERT) is used to convert the requirement text and the test cases in the preliminary candidate use case set into semantic vectors to capture the implicit relationships between words.

[0061] Step 23: Calculate the similarity between the requirement semantic vector and the semantic vector of each use case. Based on the similarity, filter out semantically matching test cases and sort them according to reuse priority to obtain a semantically matching test case set. Specifically, after sorting by reuse priority, filter the environment adaptation tags and return the top 20 test cases as the semantically matching test case set.

[0062] Specifically, the cosine similarity between the requirement semantic vector and the use case semantic vector is calculated: ,in, The cosine similarity between the requirement semantic vector and the use case semantic vector. For demand semantic vectors, This is the semantic vector for the test cases. Matching test cases are filtered based on a similarity threshold (e.g., exceeding 50%).

[0063] Reuse Priority = Similarity Score × 0.6 + Historical Success Rate × 0.3 + Usage Frequency × 0.1; where, the similarity score is the weighted average of BM25 and cosine similarity (each accounting for 50%); the historical success rate is the number of successful executions of the test case in the past 12 months / the total number of executions (e.g., a success rate of 90% corresponds to 0.9 points); the usage frequency is the standardized value of the number of reuses in the past 6 months (e.g., 10 reuses correspond to 0.8 points).

[0064] As an optional implementation, based on the environmental requirements in the requirement text (such as "compatible with Chrome 115"), records containing the target version in the "Supported Browser Versions" tag are filtered for test cases. This application adds a separate runtime environment filter to the environment adaptation filter, including browser version, operating system version, device type, and Application Programming Interface (API) version. The matching filtering method involves exact or fuzzy matching between the environmental requirements in the requirement text and the supported environment information in the test case tags. Exact matching requires complete consistency, while fuzzy matching allows for version range matching (e.g., if the requirement is Chrome 115, and the test case supports Chrome 110-116, then the match is successful). The top 20 test cases are then returned in descending order of priority. Each test case includes basic information (number, title, type, similarity score) and quality metrics (historical success rate, most recent execution time, and environment compatibility).

[0065] Step 203: Perform rule verification on the requirement text and the test cases in the semantic matching test case set, and generate a reuse scheme for display to guide testers to reuse the corresponding test cases.

[0066] The rule verification includes use case type consistency verification, environment compatibility verification, and positive / negative use case ratio verification. Specifically, use case type consistency verification checks the consistency between the use case type and the requirement; if they are inconsistent, it is marked as "requires manual confirmation." Environment compatibility verification compares the "supported browser version" in the use case record with "Chrome 115" in the requirement text; if they do not match, it prompts "parameters need to be modified." Positive / negative use case ratio verification sets the ratio of positive to negative use cases to 1:2; if the ratio of positive to negative use cases in the current project does not meet 1:2, a warning "insufficient negative use cases, 2 more need to be added" is automatically triggered, and a compliance report is generated.

[0067] The reuse scheme includes the ID of each test case in the semantic matching test case set, its similarity to the requirement text, quality indicators, and reuse suggestions. The reuse suggestions include direct reuse, parameterized modification, or scenario combination. This application supports batch generation of reuse scheme documents.

[0068] After generating a reusable test case, testers can modify the test case parameters. Once the parameters are modified, the test case enters a "pending execution" state and is automatically associated with the corresponding test plan. The test plan includes information such as execution time, personnel involved, and expected results. After entering the "pending execution" state, the test case will be displayed in the execution list of the test plan. Testers can view and execute the test case and record the execution results for subsequent effectiveness evaluation.

[0069] Step 204: After deduplication verification of the reused test cases, store them in the test case library.

[0070] Specifically, after the test cases are executed, the key information of the new test cases is automatically extracted, the rule engine is called to generate category labels, and duplicate verification is performed with the existing test cases (if the similarity is >80%, a message is prompted that "duplicate test cases exist"), stored in MySQL and the Elasticsearch index is updated.

[0071] Step 205: Delete test cases in the test case library whose reuse rate is lower than a set threshold according to the set time interval.

[0072] In a specific application example, the reuse rate of test cases is calculated weekly. Test cases with a reuse rate of less than 5% and that have not been executed in the last 12 months are automatically marked as "to be eliminated". The matching model (including BERT and BM25) is retrained every quarter based on a new test case library.

[0073] like Figure 4 As shown, the execution process of the reuse scheme is as follows: the test cases in the reuse scheme are associated with the test plan and executed through a multi-threaded execution engine. At the same time, the execution status is monitored, the execution information is recorded and stored in the MySQL database, and the execution status is displayed in real time. If the test case is executed successfully, the execution result is synchronized to the test case library and the historical success rate of the test case is updated. If the test case fails to execute, an alarm is triggered and an anomaly analysis report is generated and pushed to the user interface.

[0074] This application also provides an example of an automated management method for application test case reuse.

[0075] ① Submit test requirements. Testers fill out a requirement form through the user interface, which includes basic information, scenario description, and special requirements. For example, the project name is "E-commerce Platform V2.0", the version number is "2.0.1", the test type is "functional test", the scenario description is "user password change function, which requires verification of weak password hints", and the special requirement is "must include 2 reverse test cases".

[0076] ② Intelligent matching of use cases.

[0077] Requirement text preprocessing: Process the phrase "Users need to verify weak password hints for password modification function" by removing punctuation and segmenting it into "user", "password modification", "function", "needs", "verification", "weak password", and "hint".

[0078] Keyword extraction and semantic vector generation: Based on the TF-IDF algorithm, the weights of each word are calculated to select high-frequency keywords such as "change password," "weak password," and "verify." Combined with a predefined tag library, the functional testing scenario is determined. The keywords are then input into the BERT model to generate the requirement semantic vector.

[0079] Multi-dimensional matching strategy: The BM25 algorithm is used to calculate the similarity with the use case description text to obtain a preliminary set of candidate use cases; cosine similarity calculation is used to supplement the matching of implicit requirements, such as use cases related to "password strength verification".

[0080] Reuse priority ranking: Calculate the priority of each use case according to the reuse priority formula. For example, if a use case has a similarity score of 0.8, a historical success rate of 0.9, and a usage frequency of 0.7, then the reuse priority = 0.8 × 0.6 + 0.9 × 0.3 + 0.7 × 0.1 = 0.48 + 0.27 + 0.07 = 0.82.

[0081] Results filtering and return: Based on the "functional test" type and no special environmental requirements, return the top 20 test cases sorted by priority.

[0082] ③ Rule engine verification.

[0083] Type Validation: Check if the returned test case label is "Functional Test". If it does not match, mark it as "Requires Manual Confirmation".

[0084] Validation: Check whether the test cases have been executed in the past 12 months, whether the execution success rate is ≥70%, and whether the ratio of positive to negative test cases meets the 1:2 standard. If the standards are not met, relevant information will be displayed.

[0085] ④ Display a list of use cases and reuse suggestions. For example, if a use case has a similarity of 90% and a historical success rate of 100%, it is recommended to "reuse directly"; if a use case has a similarity of 85% and some parameters need to be adjusted, it is recommended to "modify by parameters".

[0086] ⑤ Test Case Adjustment and Execution. Testers adjust the parameters of test cases that are suggested for "parameterization modification." If the expected result is modified, the adjusted test case enters the "pending execution" state and is associated with the "E-commerce Platform V2.0 Password Function Test Plan." After executing the test case, the executor records the execution result.

[0087] ⑥ New test cases are stored in the database. After execution, the key information of the new test cases is extracted, category tags are generated, and after deduplication verification, they are stored in the database.

[0088] ⑦ Dynamic optimization. Check the reuse rate of test cases weekly, and mark test cases with a reuse rate of <5% as "to be eliminated"; retrain the model and optimize the matching algorithm every quarter.

[0089] In this application, testers can efficiently reuse historical test cases, significantly reducing the time spent manually writing test cases. Simultaneously, it can automatically determine the type and validity of test cases, ensuring that reused test cases meet current testing requirements, thereby improving testing efficiency and quality. Furthermore, as test cases are continuously accumulated and optimized, the intelligent matching and rule-based judgment capabilities will also continuously improve, providing more comprehensive and accurate support for software testing.

[0090] Based on the same inventive concept, this application also provides a test case reuse automated management system for implementing the test case reuse automated management method described above. The solution provided by this system is similar to the implementation scheme described in the above method; therefore, the specific limitations of one or more test case reuse automated management system embodiments provided below can be found in the limitations of the test case reuse automated management method described above, and will not be repeated here.

[0091] In one exemplary embodiment, such as Figure 5 and Figure 6As shown, an automated management system for test case reuse is provided, including: a test case library, a user interface, an intelligent matching module, a rule engine module, and a test case library management module (not shown in the figure).

[0092] The test case library is used to store test cases using a hybrid storage architecture.

[0093] In a specific application example, the test case library is a MySQL database with partitioned tables (partitioned by project / year), and the full-text index uses Elasticsearch, which supports millions of test cases and second-level cross-dimensional retrieval. The storage is managed by project, functional module, test type, and version number tags.

[0094] The user interface is used to obtain the requirement text submitted by the testers and display the generated reuse plan to guide the testers in reusing the corresponding test cases.

[0095] In a specific application example, the user interface is based on the Vue.js framework, providing drag-and-drop test case reuse and visual rule configuration capabilities. It includes a test case management workbench, reuse report generation, and rule debugging tools. The user interface has a user-written interface and can display test case details.

[0096] The intelligent matching module is used to perform keyword matching and semantic matching on the requirement text and the test cases in the test case library in sequence, and sort the matched test cases according to the reuse priority to generate a semantic matching test case set.

[0097] In a specific application example, the intelligent matching module is based on the Scikit-learn + TensorFlow algorithm framework and Redis caching mechanism to realize multi-condition combination search and real-time similar test case recommendation. It calculates text similarity through the BM25 algorithm, extracts semantic features by combining the BERT pre-trained model, and sorts test cases using a reuse priority formula.

[0098] Specifically, the Scikit-learn + TensorFlow algorithm framework is used to analyze historical test data and discover reusable test case patterns. At the same time, the Redis caching mechanism can store analysis results and commonly used test case data, improve data reading efficiency, and help to quickly filter and optimize test cases.

[0099] The rule engine module is used to perform rule verification on the requirement text and the test cases in the semantic matching test case set, and generate a reuse plan. The rule verification includes test case type consistency verification, environment adaptability verification, and positive and negative test case ratio verification.

[0100] The rules engine module has an input interface and a query interface. The input interface provides access to the reuse scheme, MySQL database, and main use case information. The query interface provides access to the MySQL database and Elasticsearch indexes for full-text and vector indexing.

[0101] In a specific application example, the rule engine module is based on the Decision Model and Notation (DMN) decision table and natural language rules, and uses the Drools execution engine to achieve automatic type labeling, validity scoring (1-10 points), and ratio verification and warning, including functional / interface / security test type judgment rules, timeliness / historical performance / ratio verification rules.

[0102] The type judgment rules in the rules engine module include: functional testing, interface testing, and security testing. Functional testing includes, but is not limited to, keywords such as "interface interaction" and "business process," and requires no more than 5 input / output parameters. Interface testing includes, but is not limited to, keywords such as "API," "HTTP / HTTPS," and "response code," and requires specifying the request method (GET / POST, etc.). Security testing includes, but is not limited to, keywords such as "authorization verification," "data encryption," and "vulnerability scanning."

[0103] The validity assessment rules in the rules engine module include: timeliness, historical performance, and proportional verification. Timeliness is defined as use cases that have not been executed in the past 12 months being marked as "to be verified." Historical performance is defined as use cases with an execution success rate of less than 70% being marked as "to be optimized." Proportional verification is a mandatory check of the ratio of positive to negative use cases; if the ratio is not met, a compliance defect report is generated.

[0104] The test case library management module is used to perform deduplication verification on reused test cases, store them in the test case library, and delete test cases in the test case library with a reuse rate lower than a set threshold at set time intervals.

[0105] Furthermore, the test case reuse automated management system also includes a test case execution monitoring module. This module monitors the execution status of test cases in real time, records execution time, execution results, and error information, and triggers alarms when execution fails.

[0106] In a specific application example, the test case execution monitoring module uses Java multithreading and the Spring Boot framework to monitor the execution status of test cases in real time, triggering alarms and generating reports when execution fails.

[0107] Furthermore, the test case reuse automation management system also includes a permission management module. Based on the Shiro framework and a MySQL database, the permission management module sets differentiated operation permissions for administrators, testers, and developers to ensure data security. Specifically, administrators can manage all test cases and rules, testers can only operate on test cases within their assigned projects, and developers can only view the execution results of test cases.

[0108] In summary, the architecture of the test case reuse automated management system provided in this application is shown in Table 1.

[0109] Table 1 System Architecture

[0110]

[0111] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0112] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0113] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0114] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0115] In this application, all actions to acquire signals, information, or data are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with the authorization granted by the owner of the relevant device.

[0116] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0117] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0119] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An automated management method for test case reuse, characterized in that, The method includes: Obtain the requirement text submitted by the testers; the requirement text includes basic information, scenario description, and special requirements. The requirement text and test cases in the test case library are sequentially matched using keywords and semantics. The matched test cases are then sorted according to reuse priority to generate a semantically matched test case set. Specifically, this includes: performing keyword matching on the requirement text and test cases in the test case library to obtain a preliminary candidate test case set; converting the requirement text and the test cases in the preliminary candidate test case set into semantic vectors to obtain requirement semantic vectors and multiple test case semantic vectors; calculating the similarity between the requirement semantic vector and each test case semantic vector; filtering semantically matched test cases based on similarity; and sorting them according to reuse priority to obtain a semantically matched test case set. A BERT pre-trained model is used to convert the requirement text and the test cases in the preliminary candidate test case set into semantic vectors. Reuse priority = similarity score × 0.6 + historical success rate × 0.3 + usage frequency × 0.1; where the similarity score is the weighted average of BM25 and cosine similarity; the historical success rate is the number of successful executions of the test case in the past 12 months / the total number of executions; and the usage frequency is the standardized value of the reuse count in the past 6 months. The system performs rule verification on the test cases in the semantic matching test case set for the requirement text, and generates a reuse plan for display to guide testers in reusing the corresponding test cases. The rule verification includes test case type consistency verification, environment adaptability verification, and positive and negative test case ratio verification. Test case type consistency verification checks the consistency between the test case type and the requirement; if they are inconsistent, it is marked as "requires manual confirmation". Environment adaptability verification compares the "supported browser version" in the test case record with "Chrome115" in the requirement text; if they do not match, it prompts "parameters need to be modified". Positive and negative test case ratio verification sets the ratio of positive test cases to negative test cases to 1:

2. If the ratio of positive test cases to negative test cases in the current project does not meet 1:2, a warning "insufficient negative test cases, 2 more need to be added" is automatically triggered, and a compliance report is generated. After deduplication verification, the reused test cases are stored in the test case library. According to the set time interval, test cases with a reuse rate lower than the set threshold in the test case library are deleted; specifically, the reuse rate of test cases is calculated weekly, and test cases with a reuse rate of <5% and not executed in the last 12 months are automatically marked as "to be eliminated". The matching model is retrained every quarter based on the new test case library; the matching model includes BERT and BM25.

2. The automated management method for test case reuse according to claim 1, characterized in that, The requirement text is matched with test cases in the test case library using keywords to obtain a preliminary candidate test case set, which specifically includes: The requirement text is processed by regularization and word segmentation in sequence, and high-frequency keywords are extracted using the term frequency-inverse document frequency algorithm; the high-frequency keywords are words in the requirement text whose word frequency is greater than a set proportion. The high-frequency keywords are matched with a pre-established feature word library for each test scenario to determine the test scenario for the requirement text; Based on the test scenario of the requirement text, irrelevant words in the high-frequency keywords are filtered using a predefined tag library to obtain the requirement keywords; the predefined tag library includes multiple feature words and category tags for each feature word; the category tags represent different test scenarios; Extract the test case description text for each test case from the test case library; Calculate the similarity between the required keywords and the test case description text of each test case, and determine the preliminary candidate test case set based on the similarity.

3. The automated management method for test case reuse according to claim 1, characterized in that, The reuse scheme includes the number of each test case in the semantic matching test case set, its similarity to the requirement text, quality indicators, and reuse suggestions; the reuse suggestions are direct reuse, parameterized modification, or scenario combination.

4. An automated management system for test case reuse, characterized in that, The system is applied to the automated management method for test case reuse according to any one of claims 1-3, and the system comprises: A test case library for storing test cases using a hybrid storage architecture; The user interface is used to obtain the requirement text submitted by the testers and display the generated reuse plan to guide the testers to reuse the corresponding test cases; The intelligent matching module is used to perform keyword matching and semantic matching on the requirement text and the test cases in the test case library in sequence, and sort the matched test cases according to the reuse priority to generate a semantic matching test case set; The rule engine module is used to perform rule verification on the requirement text and the test cases in the semantic matching test case set, and generate a reuse scheme; the rule verification includes test case type consistency verification, environment adaptability verification, and positive and negative test case ratio verification. The test case library management module is used to perform deduplication verification on reused test cases, store them in the test case library, and delete test cases in the test case library with a reuse rate lower than a set threshold at set time intervals.

5. The automated management system for test case reuse according to claim 4, characterized in that, The system also includes: The test case execution monitoring module is used to monitor the execution status of test cases in real time, record the execution time, execution results and error information, and trigger alarms when execution fails.

6. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the test case reuse automated management method according to any one of claims 1-3.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the test case reuse automated management method as described in any one of claims 1-3.

Images