Method and apparatus for generating test cases based on natural language processing

Abstract

The application provides a test case generation method and device based on natural language processing, which comprises: preprocessing input data and generating a structured requirement table; matching a rule base to determine compliance requirements; selecting the most similar test template through a semantic similarity algorithm; dynamically filling parameters to generate test cases and supplement complete content; outputting structured test cases and marking risk levels. The risk level is determined by a weighted fusion algorithm that comprehensively evaluates dimensions such as semantic similarity, risk matching degree, compliance matching degree, and template usage frequency. For high-risk test cases, the application also extends the test path by creating and associating action test nodes. The application realizes automatic generation of test cases through natural language processing technology, significantly improves the efficiency and accuracy of natural language processing, reduces the cost of manual testing, enhances the test coverage and complex scenario adaptability through multi-dimensional risk assessment and path expansion mechanism, and ensures that the test cases meet the requirements of regulatory standards.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and specifically to a method, apparatus, and storage medium for generating test cases based on natural language processing. Background Technology

[0002] In the field of software testing, test case writing is a crucial step in ensuring system quality and verifying functional implementation. Traditional test case generation primarily relies on testers manually writing test cases based on requirements documents. This is not only time-consuming and labor-intensive but also prone to problems such as incomplete test coverage and inconsistent test case quality due to misunderstandings or lack of experience. As software systems become increasingly complex, the demands for testing efficiency and accuracy also rise, making traditional manual methods insufficient for meeting the needs of rapid iteration and high-quality delivery.

[0003] In recent years, the industry has begun to explore methods for automatically generating test cases based on natural language processing (NLP) technology. Some research has attempted to generate test cases by identifying keywords or sentence structures in requirement texts, extracting test scenarios, and matching them with predefined templates, which has improved the automation level of test case writing to some extent. However, these methods generally suffer from limited semantic understanding capabilities, low template matching accuracy, and a lack of risk assessment mechanisms, resulting in poor applicability of the generated test cases and difficulty in dealing with complex and ever-changing business scenarios and the testing requirements of high-risk functional modules.

[0004] Existing methods for prioritizing test cases typically rely on manual judgment, lacking quantitative criteria and hindering the rational allocation of test resources and the timely discovery of critical issues. Furthermore, in terms of test path construction, most solutions only support static template filling, lacking dynamic expansion capabilities and making it difficult to achieve automated test path expansion based on high-risk test cases.

[0005] Therefore, there is an urgent need for a test case generation method that can deeply integrate natural language processing, rule reasoning, and intelligent evaluation mechanisms to solve the problems of low intelligence, unstable generation quality, weak risk identification ability, insufficient compliance guarantee, and limited test path construction ability in the current technology, thereby comprehensively improving the efficiency, accuracy, and practicality of test case generation. Summary of the Invention

[0006] This invention protects a method for generating test cases based on natural language processing, comprising the following steps: preprocessing input data to extract key entity information and generate a structured requirement table; matching the requirement information in the structured requirement table with a predefined rule base to determine compliance requirements; matching the requirement information with test patterns in a test template library using a semantic similarity algorithm, and selecting the most similar test template; extracting parameters from the requirement information and dynamically filling them into the selected test template to generate test cases; combining predefined test steps and expected results to complete the test case content; outputting the generated test cases in a structured format and marking the risk level and compliance requirements of the test cases.

[0007] Furthermore, the generated test cases are output in a structured format, and their risk levels are marked. This includes: comprehensively scoring multiple risk assessment dimensions using a weighted fusion algorithm. These dimensions include: semantic similarity matching score, used to measure the semantic matching degree between the requirement information and the test template; risk matching degree, used to match the risk level of the requirement with the historical applicable risk level of the test template; compliance matching degree, used to determine whether the test template covers the regulatory standards involved in the requirement; and template usage frequency, used to adjust template priority based on the frequency of template calls based on historical usage data. Based on the scores of multiple risk assessment dimensions, a weighted calculation is performed according to preset weight coefficients α, β, γ, and δ, and the comprehensive risk score is obtained using the following formula: Score = α × SemanticSimilarity + β × RiskMatch + γ × ComplianceMatch + δ × TemplateFrequency; where α is the semantic similarity weight, β is the risk matching weight, γ is the compliance matching weight, and δ is the template usage frequency weight. Based on the matching range between the comprehensive risk score and a threshold, the risk level of the test cases is determined and marked.

[0008] Furthermore, when the risk level is high, the method also includes: dividing multiple test scenarios based on business requirements, creating action test nodes for each test scenario; finding the corresponding action test nodes based on the requirement information corresponding to the test cases with high risk levels; determining at least one action test node associated with the found action test node within a preset range; creating and expanding test paths based on the found action test nodes, and creating and expanding test paths based on the associated action test nodes.

[0009] Furthermore, the creation and expansion of test paths based on the found action test nodes, and the creation and expansion of test paths based on associated action test nodes, include: creating a test path centered on the found action test node, and expanding the path based on the created test path; and creating a test path centered on the found action test node and / or associated action test nodes, and expanding the test path based on the created test path.

[0010] Furthermore, test cases are generated based on the created test paths; or a structured requirements table is generated based on the created test paths.

[0011] Furthermore, the created test paths are mixed, and test paths that can cover multiple test scenarios are generated through a preset model. The number of test paths generated is set as a model parameter condition, which satisfies the condition of having the minimum number.

[0012] Furthermore, the input data is preprocessed to extract key entity information and generate a structured requirement table, including: loading a pre-trained language model using natural language processing tools; converting the input data into document objects and identifying and extracting key entity information from the documents using the language model; and constructing a structured requirement table based on the extracted key entity information. The requirement information in the structured requirement table includes requirement ID, action, condition, expected result, and risk level.

[0013] Furthermore, a semantic similarity algorithm is used to match requirements with test patterns in the test template library, selecting the most similar test template. This includes: converting the requirement text into a vector representation; using a pre-trained language model to extract the semantic features of the requirement text and converting it into a fixed-dimensional vector representation; vectorizing each test template in the test template library; using a pre-trained language model to generate a vector representation for each test template in the test template library; calculating the semantic similarity between the requirement vector and each test template vector; and selecting the test template with the highest semantic similarity as the matching result based on the calculation results.

[0014] Furthermore, after calculating the semantic similarity between the requirement vector and each test template vector, the process also includes: dynamically replacing placeholders in the selected test templates based on the values ​​and conditions extracted from the requirements; generating test cases based on the placeholders; checking whether there are any unreplaced placeholders in the test cases; loading a predefined set of test steps; combining the test steps with the generated test cases; and supplementing the corresponding expected results.

[0015] Furthermore, it also includes: performing compliance verification on requirements through a rules engine; wherein, the rules engine checks whether the requirements contain specific conditions or actions according to predefined rules, and triggers exception handling if the rules are not met; and analyzes the content of the requirements through intelligent algorithms, and automatically adds risk tags to the requirements when it detects that the requirements involve high-risk content or data integrity-related fields.

[0016] This invention protects a test case generation device based on natural language processing, comprising: a preprocessing module for preprocessing input data, extracting key entity information, and generating a structured requirement table; a rule matching module for matching the requirement information in the structured requirement table with a predefined rule library to determine compliance requirements; a template matching module for matching the requirement information with test patterns in a test template library using a semantic similarity algorithm, and selecting the most similar test template; a test case generation module for extracting parameters from the requirement information and dynamically filling them into the selected test template to generate preliminary test cases, and supplementing the complete test case content by combining predefined test steps and expected results; and an output module for outputting the generated test cases in a structured format, marking risk levels and compliance requirements.

[0017] This invention protects a test case generation method based on natural language processing (NLP). It utilizes NLP technology to structure the input requirement text and combines it with a rule base and test template library to automate test case generation, significantly improving the efficiency and accuracy of test case generation, reducing the workload and error rate of manual test case writing, and ensuring that generated test cases meet relevant regulatory standards through a compliance matching mechanism, thereby improving the standardization and traceability of the testing process. Furthermore, this method introduces a multi-dimensional risk assessment model, comprehensively considering indicators such as semantic similarity, risk matching, compliance matching, and template usage frequency. A weighted fusion algorithm is used to calculate the risk level of test cases, improving the applicability and priority judgment ability of test cases in different application scenarios, helping testers quickly identify high-risk test items and focus on verification. Moreover, in cases of high risk, the method constructs action test nodes and their relationships to dynamically create and expand test paths, enhancing test coverage and adaptability to complex scenarios, effectively addressing the testing challenges brought by high-risk requirements. Furthermore, this method employs a pre-trained language model to vectorize the requirement text and test templates, and achieves accurate matching through semantic similarity calculation. This improves the intelligence level and matching accuracy of test template selection, thereby ensuring the quality and applicability of generated test cases. Finally, after test template matching, the method also supports dynamically replacing placeholders in the template based on requirement parameters, and combines predefined test steps with expected results to complete the complete construction of test cases, further enhancing the automation and practicality of test case generation. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the test case generation method based on natural language processing according to an embodiment of this application.

[0020] Figure 2 This is a schematic diagram illustrating the process of constructing a structured requirements table according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram illustrating the process of selecting the most similar test template in an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the framework of a test case generation device based on natural language processing according to an embodiment of this application;

[0023] Figure 5 This is a schematic diagram of a test case generation device based on natural language processing, as described in an embodiment of this application. Detailed Implementation

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

[0025] Research has revealed that in the field of software testing, traditional test case generation methods primarily rely on manual parsing of Requirements Documents (URS / FS) and manual design of test scenarios and procedures. However, this method is inefficient and prone to incomplete test coverage due to human error, especially when dealing with high-risk functions, potentially overlooking critical requirements. Even though some existing technologies attempt to generate test cases automatically, they typically rely on simple keyword matching or fixed template filling, failing to effectively parse the semantic information in complex requirements documents or incorporate risk assessment and labeling based on compliance requirements. Furthermore, these methods lack systematic supplementation of test procedures and expected results, resulting in insufficiently complete test cases that fail to meet the stringent requirements of high-risk industries (such as pharmaceuticals and finance).

[0026] Based on this, please refer to Figure 1 This application provides a method for generating test cases based on natural language processing, including the following steps:

[0027] The input data is preprocessed to extract key entity information and generate a structured requirements table;

[0028] Based on the requirement information in the structured requirement table, a predefined rule base is matched to determine compliance requirements;

[0029] The requirement information is matched with the test patterns in the test template library using a semantic similarity algorithm, and the most similar test template is selected.

[0030] Parameters are extracted from the requirement information and dynamically populated into the selected test template to generate test cases;

[0031] Complete the test case content by combining the predefined test steps and expected results;

[0032] The generated test cases are output in a structured format, and the risk level and compliance requirements of the test cases are marked.

[0033] This application provides a test case generation method based on natural language processing, which significantly improves the automation level of test case generation and reduces manual intervention. By preprocessing input data and extracting key entity information, a structured requirement table is generated, ensuring the comprehensiveness and accuracy of requirement analysis. A semantic similarity algorithm is used to match requirement information with a test template library, selecting the most similar test template, avoiding the limitations of traditional keyword matching methods and improving the intelligence level of matching. Simultaneously, by combining a predefined rule base and test steps, the test case content is supplemented and completed, and risk levels and compliance requirements are marked. The generated test cases are not only comprehensive but also meet the strict compliance requirements of high-risk industries, thereby reducing potential risks during the testing process and improving software quality assurance capabilities.

[0034] Please see Figure 1 In step S101, the input data is preprocessed to extract key entity information and generate a structured requirement table. Specifically, this step aims to parse the input data using natural language processing technology, extract key information, and transform it into a structured form for subsequent processing, thereby converting unstructured requirement text into a structured requirement table.

[0035] To achieve the above functions, refer to Figure 2As shown, in step S1011, a pre-trained language model is loaded using a natural language processing tool. For example, mature NLP tools such as spaCy or NLTK can be selected, and a suitable pre-trained language model (such as en_core_web_lg) can be loaded. By loading these models, basic support can be provided for subsequent entity recognition and semantic analysis.

[0036] Next, in step S1012, the input data is converted into a document object, and key entity information in the document is identified and extracted using the language model. Converting input data (such as a requirement description) into a document object can be achieved in the spaCy tool by calling the nlp() function. Then, the language model loaded in step S1011 is used to identify and extract key entity information from the document. Taking “URS-3.2: System shall lock account after 3 failed loginattempts.” as an example, the input data is first converted into a document object, and then the loaded language model is used to extract key entity information, such as “3” being identified as CARDINAL type and “login attempts” being identified as NOUN type. This key entity information constitutes the core elements of the requirement.

[0037] Finally, in step S1013, a structured requirement table is constructed based on the extracted key entity information. This structured requirement table includes, but is not limited to, fields such as requirement ID, action, condition, expected result, and risk level, which constitute the requirement information. For example, for the above example, the following structured requirement table can be generated: Requirement ID is URS-3.2, action is "Lock Account", condition is "3 failed login attempts", expected result is "Account Lock + Audit Log", and risk level is "High". In this way, unstructured input data can be transformed into a clear and easily processed structured form, laying the foundation for the generation of subsequent test cases.

[0038] In summary, step S101, through preprocessing the input data and combining natural language processing technology with the construction of a structured requirement table, achieves the transformation from raw requirements to standardized data. This process not only improves the efficiency of data processing but also provides a reliable input basis for subsequent steps.

[0039] In step S102, based on the requirement information in the structured requirement table, a predefined rule base is matched to determine compliance requirements. This process aims to ensure that the generated test cases comply with relevant regulations and standards through rule base matching and verification.

[0040] In this step, the rule engine performs compliance verification on the requirement information in the structured requirement table output in step S101. Specifically, the rule engine loads a predefined rule base, which is usually stored in JSON or other structured formats and contains various compliance requirements and corresponding check conditions. For example, for the requirement of "locking an account", the rule base may contain the following: `{"rule_id":"SEC-001","action":"account_lock","requirements": ["audit_log","timestamp","user_identity"],"compliance":"21 CFR Part 11 §11.300"}`. In the rule base, "rule_id":"SEC-001" is the rule number; "action":"account_lock" indicates the action is "lock account"; "requirements": ["audit_log","timestamp","user_identity"] specifies the conditions to be met, including audit logs, timestamps, and user identity information; "compliance":"21 CFR Part 11 §11.300" specifies the applicable regulatory standards. The rule engine will verify this requirement information one by one based on these rules.

[0041] Furthermore, the rules engine checks whether the requirements contain specific conditions or actions based on predefined rules. If the rules are not met, exception handling is triggered. For example, if requirement A does not include the requirement for audit log recording, the rules engine will throw an exception message, such as `ValidationException("Missing audit log verification")`. This mechanism can effectively avoid risks caused by omitting key compliance requirements.

[0042] Furthermore, before matching structured requirements with the rule base through the rule engine, intelligent algorithms analyze the content of the requirements. When a requirement is detected to involve high-risk content or data integrity-related fields, a risk marker is automatically added to the requirement. For example, if a requirement contains "audit trail" or is marked as "high-risk," the system will automatically add a "Data Integrity" tag to the requirement and set its priority to P1. This intelligent processing method not only improves the efficiency of compliance verification but also enhances the ability to identify potential risks.

[0043] In summary, step S102, by matching the requirement information in the structured requirement table with the predefined rule base, combined with the verification of the rule engine and the analysis of intelligent algorithms, comprehensively determines the compliance requirements. This process not only ensures the accuracy of test case generation but also provides a solid foundation for subsequent risk management and compliance assurance.

[0044] In step S103, the requirement information is matched with test patterns in the test template library using a semantic similarity algorithm, and the most similar test template is selected. This process aims to utilize natural language processing technology to compare the requirement information with the patterns in the test template library, thereby providing a suitable template basis for the subsequent generation of test cases. Specifically, in this step, the requirement information and each test pattern in the test template library are first converted into vector representations. For example, a pre-trained language model (such as BERT) can be used to encode the text, generating corresponding word vectors or sentence vectors. Then, the degree of matching is evaluated by calculating the semantic similarity between the requirement information and each test pattern. Commonly used similarity calculation methods include cosine similarity and Euclidean distance.

[0045] This involves vectorizing the requirement information and test patterns, and then selecting the test template from the test template library that is semantically most similar to the requirement information. For example, suppose the requirement information is "lock account after 3 failed loginattempts", and the test template library contains the following two patterns: "auth_failure: Verify system locksaccount after [n] failed attempts" and "password_policy: Verify passwordcomplexity enforcement". By calculating the semantic similarity between the requirement information and these two patterns, "auth_failure" will ultimately be selected as the most similar test template.

[0046] In summary, step S103 uses a semantic similarity algorithm to match requirement information with test patterns in the test template library and selects the most similar test template. This process not only improves the automation of test case generation but also ensures that the generated test cases accurately reflect the core content of the requirements.

[0047] In step S104, parameters are extracted from the requirement information and dynamically populated into the selected test template to generate test cases. This step combines the specific parameters in the requirement information with the selected test template to generate preliminary test cases that meet the requirements. Specifically, in this step, key parameters are first extracted from the requirement information. These parameters typically include numerical values, conditions, or other specific information. For example, in the requirement "lock account after 3 failed login attempts", the parameter "3" can be extracted as the numerical value of the number of failed login attempts. These parameters can be accurately identified and extracted from the requirement text using natural language processing techniques or regular expression matching. Next, the extracted parameters are dynamically populated into the selected test template. For example, suppose the selected test template is "Verify system locks account after [n] failed attempts", where "[n]" is a placeholder used to receive the parameters extracted from the requirement information. By replacing the placeholder "[n]" with the parameter "3", the following preliminary test case can be generated: "Verify system locks account after 3 failed attempts". Furthermore, to ensure that the generated initial test cases fully reflect the core content of the requirements, the template after parameter filling will be further verified to ensure that it conforms to the expected logic. For example, it will check for issues such as unreplaced placeholders or syntax errors, thereby ensuring that the generated test cases have basic usability.

[0048] In summary, step S104 generates test cases by extracting parameters from the requirement information and dynamically filling them into the selected test template. This process not only improves the flexibility and accuracy of test case generation but also provides fundamental support for subsequent test case refinement.

[0049] In step S105, the test case content is completed by combining predefined test steps and expected results. This step combines the initially generated test cases with predefined standard test steps and expected results to form complete and executable test cases. Specifically, in this step, a set of predefined test steps needs to be loaded first. These test steps are based on industry standards or internal enterprise specifications and cover detailed guidance from test environment preparation to specific operations. For example, for testing the login function, the predefined test steps may include: "1. Navigate to the login page", "2. Enter a valid username and an incorrect password", "3. Repeat the incorrect password twice (a total of three failures)", and "4. Attempt to log in using the correct credentials". Next, the above test steps are combined with the initially generated test cases, and the corresponding expected results are added. The expected results are used to clarify the behavior that the system should exhibit after each test step is completed. For example, for step "3. Repeat the incorrect password twice (a total of three failures)", the expected result could be "The system displays the 'Account locked' message and records relevant audit logs".

[0050] In this way, the system ensures that test cases not only include operational guidelines but also clearly define verification standards. Furthermore, to improve the completeness and readability of test cases, the system further optimizes the content format, ensuring that each part is logically clear and interconnected. For example, test steps are arranged by number, and each step is provided with a detailed description and corresponding expected results, so that testers can accurately understand and execute the test tasks.

[0051] In summary, step S105, by combining predefined test steps and expected results, supplements and improves the content of the initial test cases. This process not only enhances the quality of the test cases but also provides a comprehensive and reliable basis for subsequent test execution.

[0052] In step S106, the generated test cases are output in a structured format, and the risk level and compliance requirements are determined and marked. This step, through structured output and marking mechanisms, ensures that the generated test cases are not only readable and executable, but also meet the needs of risk management and regulatory compliance.

[0053] To achieve the above functionality, the generated structured test cases are output to the manual review interface within the test management tool. Specifically, the test cases are exported in a standardized format (such as JSON, XML, or tables) and integrated into commonly used test management tools (such as JIRA, TestRail, etc.). For example, the following is an example of JSON format output:

[0054] {

[0055] "test_id":"TC-LOGIN-03",

[0056] "title":"Verify account locks after 3 failed loginattempts",

[0057] "steps": [

[0058] 1. Navigate to login page

[0059] "2. Enter valid username and wrong password",

[0060] "3. Repeat step 2 two more times (total 3 failures)",

[0061] "4. Attempt login with correct credentials"],

[0062] "expected": [

[0063] "Account locked with message'Account locked for 30 minutes'",

[0064] "Audit log contains timestamp, user ID, and event type'ACCOUNT_LOCK'"],

[0065] "compliance": ["21 CFR Part 11 §11.300","EUAnnex 11 §9"],

[0066] "risk":"high",

[0067] "automation": true}

[0068] During the manual review process, intelligent tools assist in the review of test cases. After the structured test case output in step S106 is completed, the auxiliary review system further determines whether the currently generated test cases are marked as "high" risk level. If there are test cases with a high risk level, an enhanced test path generation mechanism is triggered, providing risk and boundary testing suggestions and compliance warnings to improve the test coverage depth and logical integrity of high-risk functional points.

[0069] After test cases are generated, the system collects evaluation data in four dimensions in parallel:

[0070] Semantic Similarity Matching: The BERT model is used to calculate the semantic embedding vectors of the requirement text and the test template, and a scaled value of 0-1 is output using the cosine similarity algorithm. For example, the similarity score between the requirement "user login failure lockout" and the template "account security exception handling" is 0.87.

[0071] Risk Match: Matches based on the template's historical risk database: 0.9 points are assigned when the demand risk level is exactly the same as the template's historical level, 0.5 points are assigned when they differ by one level (e.g., high vs. medium), and 0.1 points are assigned when they are completely mismatched.

[0072] Compliance Match: Calculates the overlap between the relevant regulatory clauses of the requirement and the clauses covered by the template. For example, if the requirement involves 5 regulations and the template covers 4 of them, the score is 0.8.

[0073] Template usage frequency: Based on historical call logs, the number of times the template is used is normalized to a value between 0 and 1 (current usage count / historical highest usage count).

[0074] After determining the data for each dimension, the weighting coefficients for each dimension are determined. These weighting coefficients can be pre-configured, determined based on a large model, or calculated based on expert scores. This embodiment uses the example of configuring and determining the coefficients to illustrate the specific calculation process and method.

[0075] Before the system runs, the weight coefficients are determined through the front-end configuration interface. For example, the weight coefficients are configured as α=0.4, β=0.3, γ=0.2, δ=0.1, where α is the semantic similarity weight, β is the risk matching weight, γ is the compliance matching weight, and δ is the template usage frequency weight.

[0076] Perform weighted calculations according to the formula:

[0077] Score=α×SemanticSimilarity+β×RiskMatch+γ×ComplianceMatch+δ×TemplateFrequency;

[0078] For example, the data determined by semantic similarity matching, risk matching, compliance matching, and template frequency are 0.87, 0.9, 0.8, and 0.6, respectively, with a final calculation result of 0.838.

[0079] The system predetermines built-in threshold ranges for different risks. Here are some example data ranges: Score ≥ 0.8: High risk (red label, triggers mandatory boundary test extension); 0.8 > Score ≥ 0.4: Medium risk (yellow label, performs basic boundary check); Score < 0.4: Low risk (green label, only verifies normal flow). The previous example, with a score of 0.838, is marked as high risk. After determining the risk level, structured output data is generated, and the risk labels are written into the structured test cases.

[0080] json

[0081] {

[0082] "test_id":"TC-AUTH-07",

[0083] "risk":"medium",

[0084] "risk_detail": { / / Retain the original dimension scores

[0085] SemanticSimilarity: 0.87,

[0086] "risk_match": 0.9,

[0087] "compliance_match": 0.8,

[0088] "template_freq": 0.6

[0089] }

[0090] }

[0091] The risk level is automatically synchronized to tools such as TestRail / JIRA via REST API, and the risk level is mapped to the priority field (e.g., High→P0).

[0092] The system can analyze the steps in test cases, identify potentially missing boundary conditions, and propose improvement suggestions. For example, if a login failure locks an account, the AI ​​might suggest adding verification conditions for when the account is not locked on the second failure, thus enhancing test coverage. Furthermore, the AI ​​will check whether the test cases cover all relevant regulatory requirements. If any omissions are found (such as the lack of mention of electronic signature verification), the system will generate a compliance warning.

[0093] The boundary testing suggestions include actions to add additional verification conditions for specific test steps, and the compliance warnings highlight regulatory requirements not covered in the test cases. For example, for the above example, the AI ​​might generate the following suggestions and warnings:

[0094] Boundary testing suggestion: [AI suggestion] Add boundary test: Verify that the account is not locked after the second failure and further verification is required;

[0095] Compliance Warning: [Compliance Warning] The expected outcome does not mention electronic signature verification (refer to 21 CFR Part 11 §11.200).

[0096] These prompts are integrated into the manual review interface for testers to refer to and decide whether to adopt. In this way, AI-assisted review not only improves the quality of test cases but also reduces the risk of omitting key test conditions or regulatory requirements.

[0097] In summary, step S106, by outputting the generated test cases in a structured format and combining them with risk level and compliance requirement tags, achieves comprehensive management and optimization of the test cases. Simultaneously, the AI-assisted review function further enhances the completeness and reliability of the test cases, providing a solid guarantee for subsequent test execution.

[0098] In step S106 above, it has been described in detail how to output the generated test cases in a structured format and mark the risk level and compliance requirements.

[0099] However, when the risk level is high, the method also includes a series of enhanced processing steps to further improve test coverage and quality, specifically addressing high-risk requirements. The implementation of these steps will be described in detail below.

[0100] First, based on business requirements, divide the test into multiple scenarios and create action test nodes for each scenario. For example, the requirements can be divided into login, query, payment, and download scenarios. Create corresponding test nodes for each scenario; for the login scenario, there can be a login node. This rough division improves efficiency and reduces the amount of operation.

[0101] Action test nodes are used to describe specific test operations and their expected results. For example, assuming the requirement is "locking an account," test scenarios can be divided based on different numbers of failed login attempts (e.g., 1, 2, and 3) and whether a locking mechanism is triggered, and corresponding action test nodes can be created for each scenario. The following is an example code snippet:

[0102] test_scenarios = {

[0103] "scenario_1":"Verify system behavior after 1 failed login attempt",

[0104] "scenario_2":"Verify system behavior after 2 failed login attempts",

[0105] "scenario_3":"Verify account lock after 3 failed loginattempts"

[0106] }

[0107] action_nodes = {}

[0108] for scenario_id, scenario_description in test_scenarios.items():

[0109] action_nodes[scenario_id] = f"ActionNode for {scenario_description}"

[0110] In the code above, the `test_scenarios` dictionary defines multiple test scenarios, while the `action_nodes` dictionary stores the action test nodes associated with each test scenario.

[0111] Next, the system locates the corresponding action test nodes based on the requirement information of the test cases with high risk levels. For example, if the aforementioned generated test cases involve a high-risk scenario of "lockdown after multiple failures," the system will automatically match action test nodes associated with that scenario, such as the "login" node.

[0112] Subsequently, based on the found action test nodes, at least one associated action test node within a preset range is determined. This process expands the coverage of the test path by analyzing the logical relationships between action test nodes. For example, if the found action test node is a "login" node, its associated nodes could be nodes such as query, payment, and download. The preset range can be customized, such as a range of three actions.

[0113] Finally, test paths are created and expanded based on the found action test nodes, as well as based on associated action test nodes. Specifically, the system dynamically generates or adjusts test paths based on the found action test nodes and their associated nodes. For example, for the "login" node, the system might generate the following test path: Enter username -> Enter incorrect password (three times) -> Verify account lockout status -> Record audit log -> Send notification email. This dynamic path generation mechanism not only improves the flexibility of testing but also ensures the integrity of testing in high-risk scenarios. Furthermore, it eliminates the need to determine all test paths and the test paths corresponding to all scenarios, reducing computational load and improving efficiency, making it simpler and more efficient, and avoiding unnecessary complexity.

[0114] Furthermore, the path can be expanded and adjusted using a neural network model (already trained with expanded test paths). For the login node, it can be expanded to: enter username -> enter incorrect password (2 or 4 times) -> verify account lock status. It can also be expanded to: enter username -> enter incorrect password (2 times) -> enter correct password -> verify account lock status, etc. This process aims to ensure that high-risk requirements are fully covered by refining the test path, and to lay the foundation for subsequent testing.

[0115] For the "login" node, the system may further link it to other related nodes, such as query, payment, and download nodes. A corresponding test path will be constructed, such as: enter username -> enter username -> enter incorrect password (2 or 4 times) -> verify account lock status -> verify payment status -> send notification email, etc.

[0116] Furthermore, by refining test scenarios, it's possible to ensure that high-risk requirements are fully covered. For example, the requirement to "lock the account after a failed login" can be divided into several test scenarios: normal login, locking after multiple failures, and unlocking the account. For each test scenario, create corresponding action test nodes, such as "enter username," "enter incorrect password," and "verify account status." Alternatively, for login requirements, scenarios can be refined to include login input, login failure, locking after multiple failures, and successful login.

[0117] For the "Enter wrong password three times" node in the scenario where the account is locked after multiple failures, the system may further link to other related nodes, such as "Record audit log" and "Send notification email". The system can then generate the following test path: Enter username -> Enter wrong password (three times) -> Verify account lock status -> Record audit log -> Send notification email. Further details will not be elaborated here.

[0118] In summary, when the risk level is high, a series of steps, including dividing test scenarios, creating action test nodes, finding related nodes, and dynamically generating test paths, achieve in-depth coverage and refined testing of high-risk requirements. This enhanced processing, together with the structured output and tagging mechanism in step S106, constitutes a complete test case generation method based on natural language processing, thereby effectively improving testing efficiency and quality.

[0119] Furthermore, an optimized implementation can also mix the created test paths and generate test paths that can cover multiple test scenarios through a preset model, and set the number of generated test paths as a model parameter condition, which satisfies the condition of a minimum number.

[0120] First, existing test paths are combined. These test paths are generated by creating test paths centered on the found action test nodes and expanding upon them, as well as by creating test paths centered on the found action test nodes and / or associated action test nodes and expanding upon them. By combining and expanding these paths, new test paths can be generated that cover more test scenarios. For example, the "user login" path can be combined with the "user upload file" path to generate a new path that includes "user logs in and uploads a file".

[0121] The new test paths described above are input into a pre-trained neural network model. During training, the model acquires sample data—a mixture of test paths—and selects the n highest-scoring results from multiple outputs. When selecting paths, the goal is to minimize the number of generated paths while still covering multiple test scenarios. This can be achieved by setting the model's parameters, for example, by using an optimization algorithm to select the optimal path combination.

[0122] like Figure 3 As shown, step S103 uses a semantic similarity algorithm to match the requirement information with the test patterns in the test template library, and selects the most similar test pattern. This step further includes several steps.

[0123] In step S1031, the requirement text is converted into a vector representation. Specifically, to achieve semantic understanding and matching of the requirement text, it is first necessary to vectorize it. During this process, a pre-trained language model (such as spaCy, NLTK, or a Transformer-based model) can be used to extract the semantic features of the requirement text and convert them into a fixed-dimensional vector representation. For example, by loading the pre-trained model en_core_web_lg, its built-in word vector functionality can be used to process the requirement text. The following is an example code snippet:

[0124] import spacy

[0125] nlp = spacy.load("en_core_web_lg")

[0126] doc = nlp("URS-3.2: System shall lock account after 3 failed login attempts.")

[0127] req_vector = doc.vector # Get the vector representation of the requested text

[0128] In the code above, `doc.vector` returns the average vector representation of the entire document, which captures the main semantic information of the request text. In this way, the request text is successfully converted into vector form, providing a foundation for subsequent semantic similarity calculations. This step helps reduce noise interference, thereby improving the quality of the final matching results.

[0129] In step S1032, each test template in the test template library is vectorized. Based on the vectorization method of the requirement text in step S1031, a pre-trained language model can also be used to generate vector representations for each test template in the test template library. Specifically, the test template library typically contains multiple predefined test templates, each describing a specific test scenario or pattern. To achieve semantic matching with the requirement text, these test templates need to be converted into vector form one by one. The following is an example code snippet:

[0130] templates = {

[0131] "auth_failure":"Verify system locks account after [n]failed attempts",

[0132] "password_policy":"Verify password complexityenforcement"

[0133] }template_vectors = {}

[0134] for template_id, template_text in templates.items():

[0135] template_doc = nlp(template_text)

[0136] template_vectors[template_id] = template_doc.vector

[0137] In the code above, the `templates` dictionary stores all templates in the test template library, where the key is the template ID and the value is the corresponding template text. By traversing this dictionary, each template text can be processed by calling the same language model (such as `en_core_web_lg`), and converted into a vector representation, which is finally stored in the `template_vectors` dictionary.

[0138] It is important to note that the vectorization process of the test templates should be consistent with that of the requirement text to ensure the comparability of semantic similarity calculations between the two. Furthermore, if the test template library is large, batch processing or optimization of the vectorization method can be considered to improve efficiency. Through this step, each template in the test template library is successfully converted into vector form, providing the necessary data support for subsequent semantic similarity calculations.

[0139] In step S1033, the semantic similarity between the demand vector and each test template vector is calculated. Based on the demand vector and test template vector generated in steps S1031 and S1032 respectively, a suitable semantic similarity algorithm can be used to quantify the degree of matching between them. Specifically, commonly used semantic similarity algorithms include cosine similarity and Euclidean distance. Among them, cosine similarity is widely used in natural language processing tasks due to its good adaptability to text data. The following is an example code snippet:

[0140] from sklearn.metrics.pairwise import cosine_similarity

[0141] req_vector = req_vector.reshape(1, -1) # Adjust the shape to fit the cosine_similarity function

[0142] similarity_scores = {}

[0143] for template_id, template_vector in template_vectors.items():

[0144] template_vector = template_vector.reshape(1, -1)

[0145] similarity = cosine_similarity(req_vector, template_vector)[0][0]

[0146] similarity_scores[template_id] = similarity

[0147] In the code above, the `cosine_similarity` function calculates the cosine similarity between the demand vector and each test template vector. By iterating through all test template vectors in the `template_vectors` dictionary, the similarity score between the demand vector and each test template vector is obtained and stored in the `similarity_scores` dictionary. It's important to note that to ensure the accuracy of the calculation results, the dimensions of the demand vector and the test template vectors must be consistent. Furthermore, if the test template library is large, the similarity calculation process can be optimized, for example, by using matrix operations or a distributed computing framework to improve efficiency. This step successfully quantifies the semantic similarity between the demand vector and each test template vector, providing a basis for subsequently selecting the most similar test template.

[0148] In step S1034, the test template with the highest semantic similarity is selected as the matching result based on the calculation results. Based on the semantic similarity scores between the requirement vector and each test template vector calculated in step S1033, the test template that best meets the requirements can be further filtered. Specifically, by traversing the `similarity_scores` dictionary generated in step S1033, the test template ID with the highest similarity score is found, and its corresponding test template is used as the final matching result. The following is an example code snippet:

[0149] best_match_id = max(similarity_scores, key=similarity_scores.get)

[0150] best_match_template = templates[best_match_id]

[0151] In the code above, the `max` function, combined with the `similarity_scores.get` method, is used to find the key (i.e., the test template ID) with the highest similarity score from the dictionary, and then extract the corresponding test template text from the original `templates` dictionary using this ID. It's important to note that if multiple test templates have the same highest similarity score, one template can be selected based on actual needs, or other rules (such as template priority) can be introduced for further filtering. Furthermore, to improve the reliability of the matching results, a similarity threshold can be set; a match is considered successful only when the highest similarity score exceeds this threshold, otherwise no match is returned. Through this step, the test template with the highest semantic similarity is successfully selected from the test template library as the matching result for the requirement, thus achieving an effective association between the requirement and the test template, providing a foundation for subsequent test case generation.

[0152] Please see Figure 4 , Figure 4 This is a schematic diagram of a test case generation device based on natural language processing, provided as an embodiment of this application. Figure 4 As shown, the generation device 300 includes: a preprocessing module 310 for preprocessing input data, extracting key entity information, and generating a structured requirement table; a rule matching module 320 for matching the requirement information in the structured requirement table with a predefined rule library to determine compliance requirements; a template matching module 330 for matching the requirement information with test patterns in a test template library using a semantic similarity algorithm, and selecting the most similar test template; a test case generation module 340 for extracting parameters from the requirement information and dynamically filling them into the selected test template to generate preliminary test cases, and supplementing the complete test case content by combining predefined test steps and expected results; and an output module 350 for outputting the generated test cases in a structured format, marking the risk level and compliance requirements.

[0153] Furthermore, when the risk level is high, the generation device 300 also includes a scenario segmentation module, which is used to: divide multiple test scenarios based on business requirements, and create action test nodes for each test scenario; find the corresponding action test nodes according to the requirement information corresponding to the test cases with high risk levels; determine at least one action test node associated with the found action test node within a preset range; create and expand test paths according to the found action test nodes, and create and expand test paths according to the associated action test nodes.

[0154] Furthermore, when the scene segmentation module is used to create and expand test paths based on the found action test nodes, and to create and expand test paths based on the associated action test nodes, the scene segmentation module is used to: create a test path centered on the found action test node, and expand the path based on the created test path; and create a test path centered on the found action test node and / or the associated action test node, and expand the test path based on the created test path.

[0155] Furthermore, the generation device 300 also includes a path generation module, which is used to generate test cases based on the created test paths; or to generate a structured requirement table based on the created test paths.

[0156] Furthermore, the generation device 300 also includes a path mixing module, which is used to: mix the created test paths, generate test paths that can cover multiple test scenarios through a preset model, and set the number of generated test paths as a model parameter condition, which satisfies the minimum number.

[0157] Furthermore, when the preprocessing module 310 preprocesses the input data, extracts key entity information, and generates a structured requirement table, the preprocessing module 310 is used to: load a pre-trained language model using a natural language processing tool; convert the input data into document objects, and identify and extract key entity information from the documents using the language model; and construct a structured requirement table based on the extracted key entity information, wherein the requirement information in the structured requirement table includes requirement ID, action, condition, expected result, and risk level.

[0158] Furthermore, when the template matching module 330 is used to match the requirements with the test patterns in the test template library using a semantic similarity algorithm and select the most similar test template, the template matching module 630 is used to: convert the requirement text into a vector representation; perform vectorization processing on each test template in the test template library; calculate the semantic similarity between the requirement vector and each test template vector; and select the test template with the highest semantic similarity as the matching result based on the calculation result.

[0159] Furthermore, when the template matching module 330 is used to calculate the semantic similarity between the demand vector and each test template vector, the template matching module 330 is used to: calculate the similarity value between the demand vector and each test template vector using a cosine similarity algorithm; and use the calculated similarity value as a quantitative indicator of semantic similarity.

[0160] Furthermore, when the template matching module 330 is used to calculate the similarity value between the demand vector and each test template vector using the cosine similarity algorithm, the template matching module 330 is used to: input the demand vector and each test template vector into the cosine similarity algorithm for calculation; and normalize the dimensions of the demand vector and the test template vector during the calculation process.

[0161] Furthermore, when the test case generation module 340 extracts parameters from the requirements and dynamically fills them into the selected test template to generate preliminary test cases, and supplements the complete test case content by combining predefined test steps and expected results, the test case generation module 340 is also used to: dynamically replace placeholders in the selected test template according to the values ​​and conditions extracted from the requirements; and supplement the test steps and expected results of the complete test cases based on predefined standard operating procedures.

[0162] Furthermore, the generation device 300 also includes a compliance verification module, which is used to: perform compliance verification on the requirements through a rule engine; wherein, the rule engine checks whether the requirements contain specific conditions or actions according to predefined rules, and triggers exception handling if the rules are not met; at the same time, it analyzes the content of the requirements through intelligent algorithms, and automatically adds risk markers to the requirements when it detects that the requirements involve high-risk content or data integrity-related fields.

[0163] Furthermore, the generation device 300 also includes an auxiliary review module, which is used to: output the generated structured test cases to the manual review interface in the test management tool; perform auxiliary review of the test cases through intelligent tools, and provide boundary test suggestions and compliance warnings; wherein, the boundary test suggestions include operations to add additional verification conditions for specific test steps, and the compliance warnings indicate regulatory requirements not covered in the test cases.

[0164] The requirement parsing and test case generation device based on natural language processing provided in this application preprocesses the input data to extract key entity information and generate a structured requirement table. Based on the requirement information in the structured requirement table, it matches the data with a predefined rule base to determine compliance requirements. A semantic similarity algorithm matches the requirement information with test patterns in a test template library, selecting the most similar test template. Parameters are extracted from the requirement information and dynamically populated into the selected test template to generate preliminary test cases. The test cases are then completed by combining predefined test steps and expected results. Finally, the generated test cases are output in a structured format, labeled with risk levels and compliance requirements. This allows for automated test case generation, improving testing efficiency and reducing labor costs.

[0165] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430. The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 and the memory 420 communicate via the bus 430. When the machine-readable instructions are executed by the processor 410, the steps of the test case generation method based on natural language processing as described in the above method embodiment can be performed. For specific implementation details, please refer to the method embodiment, which will not be repeated here.

[0166] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it can execute the steps of the test case generation method based on natural language processing as described in the above method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

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

[0168] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. If the function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage media include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media that can store program code.

[0169] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating test cases based on natural language processing, characterized in that, Includes the following steps: The input data is preprocessed to extract key entity information and generate a structured requirements table; Load a pre-trained language model using a natural language processing tool; transform the input data into document objects, and identify and extract key entity information from the documents using the language model; construct a structured requirement table based on the extracted key entity information, wherein the requirement information in the structured requirement table includes requirement ID, action, condition, expected result, and risk level; Based on the requirement information in the structured requirement table, a predefined rule base is matched to determine compliance requirements; The requirement information is matched with the test patterns in the test template library using a semantic similarity algorithm, and the most similar test template is selected. Parameters are extracted from the requirement information and dynamically populated into the selected test template to generate test cases; Complete the test case content by combining the predefined test steps and expected results; The generated test cases are output in a structured format, and the risk level and compliance requirements of the test cases are marked. The risk level of the test cases is comprehensively scored by a weighted fusion algorithm based on multiple risk assessment dimensions, including: semantic similarity matching degree, which measures the degree of semantic matching between the requirement information and the test template; risk matching degree, which matches the risk level of the requirement with the historical applicable risk level of the test template; compliance matching degree, which determines whether the test template covers the laws and standards involved in the requirement; and template usage frequency, which is used to count the frequency of template calls based on historical usage data. The scores are calculated by weighting the values ​​according to preset weighting coefficients α, β, γ, and δ, and the overall score is obtained using the following formula: Score=α×SemanticSimilarity+β× RiskMatch+ γ ×ComplianceMatch+δ×TemplateFrequency; Where α is the semantic similarity weight, β is the risk matching weight, γ is the compliance matching weight, and δ is the template usage frequency weight; Based on the matching interval between the comprehensive score and the threshold, the risk level of the test case is determined and marked; when the risk level is high, the test coverage and quality are improved. When the risk level is high, the method further includes: Based on business needs, multiple test scenarios were divided, and action test nodes were created for each test scenario. Find the corresponding action test node based on the requirement information corresponding to the test cases with high risk levels; Based on the found action test nodes, determine at least one action test node associated with it within the preset range; The test path is created and expanded based on the found action test nodes, and the test path is also created and expanded based on the associated action test nodes. The process involves creating and expanding test paths based on the identified action test nodes, as well as creating and expanding test paths based on associated action test nodes, including: Create a test path centered on the found action test node, and expand the test path based on the created test path. Also create a test path centered on the found action test node and / or the associated action test node, and expand the test path based on the created test path.

2. The test case generation method based on natural language processing according to claim 1, characterized in that, Test cases can be generated based on the created test path; or a structured requirements table can be generated based on the created test path.

3. The test case generation method based on natural language processing according to claim 1, characterized in that, The created test paths are mixed, and test paths that can cover multiple test scenarios are generated through a preset model. The number of test paths generated is set as a model parameter condition, which satisfies the minimum number.

4. The test case generation method based on natural language processing according to claim 1, characterized in that, The step of matching requirements with test patterns in the test template library using a semantic similarity algorithm and selecting the most similar test template includes: The requirement text is converted into a vector representation. A pre-trained language model is used to extract the semantic features of the requirement text and convert it into a fixed-dimensional vector representation. Each test template in the test template library is vectorized, and a pre-trained language model is used to generate a vector representation for each test template in the test template library. Calculate the semantic similarity between the requirement vector and each test template vector; The test template with the highest semantic similarity is selected as the matching result based on the calculation results.

5. The test case generation method based on natural language processing according to claim 1, characterized in that, After calculating the semantic similarity between the demand vector and each test template vector, the following steps are also included: Dynamically replace placeholders in the selected test template based on the values ​​and conditions extracted from the requirements, generate test cases based on the placeholders, and check whether there are any placeholders in the test cases that have not been replaced. Load a predefined set of test steps, combine the test steps with the generated test cases, and supplement the corresponding expected results.

6. The test case generation method based on natural language processing according to claim 1, characterized in that, Also includes: The requirements are validated for compliance using a rules engine; The rule engine checks whether the requirements contain conditions or actions according to predefined rules. If the rules are not met, exception handling is triggered. By analyzing the content of the requirements through intelligent algorithms, when a requirement is detected to involve high-risk content or fields related to data integrity, a risk marker is automatically added to the requirement.

7. A test case generation device based on natural language processing, characterized in that, include: The preprocessing module is used to preprocess the input data, extract key entity information and generate a structured requirement table; load a pre-trained language model using a natural language processing tool; convert the input data into document objects and identify and extract key entity information from the documents through the language model; construct a structured requirement table based on the extracted key entity information, wherein the requirement information in the structured requirement table includes requirement ID, action, condition, expected result and risk level; The rule matching module is used to match the requirement information in the structured requirement table with a predefined rule base to determine compliance requirements; The template matching module is used to match requirement information with test patterns in the test template library using a semantic similarity algorithm, and select the most similar test template. The test case generation module is used to extract parameters from the requirements information and dynamically populate them into the selected test template to generate preliminary test cases. It also supplements the complete test case content by combining predefined test steps and expected results. The output module outputs the generated test cases in a structured format, marking risk levels and compliance requirements. The risk level of the test cases is comprehensively scored based on multiple risk assessment dimensions using a weighted fusion algorithm. These multiple risk assessment dimensions include: semantic similarity matching degree, used to measure the degree of semantic matching between the requirement information and the test template; risk matching degree, used to match the risk level of the requirement with the historical applicable risk level of the test template; compliance matching degree, used to determine whether the test template covers the regulations and standards involved in the requirement; and template usage frequency, used to statistically analyze the frequency of template calls based on historical usage data. The scores are calculated by weighting the values ​​according to preset weighting coefficients α, β, γ, and δ, and the overall score is obtained using the following formula: Score=α×SemanticSimilarity+β× RiskMatch+ γ ×ComplianceMatch+δ×TemplateFrequency; Where α is the semantic similarity weight, β is the risk matching weight, γ is the compliance matching weight, and δ is the template usage frequency weight; Based on the matching interval between the comprehensive score and the threshold, the risk level of the test case is determined and marked; when the risk level is high, the test coverage and quality are improved. When the risk level is high, the generating device further includes: Based on business needs, multiple test scenarios were divided, and action test nodes were created for each test scenario. Find the corresponding action test node based on the requirement information corresponding to the test cases with high risk levels; Based on the found action test nodes, determine at least one action test node associated with it within the preset range; The test path is created and expanded based on the found action test nodes, and the test path is also created and expanded based on the associated action test nodes. The process involves creating and expanding test paths based on the identified action test nodes, as well as creating and expanding test paths based on associated action test nodes, including: Create a test path centered on the found action test node, and expand the test path based on the created test path. Also create a test path centered on the found action test node and / or the associated action test node, and expand the test path based on the created test path.

Images