A function test case closed loop generation method based on structured requirement review

Abstract

The application discloses a kind of function test case closed loop generation method and system based on structured demand review, the method includes: the demand data is parsed into traceable data block, and is organized into demand module and cross-module demand;The demand module and cross-module demand are reviewed and optimized, and supplementary generation field is generated;Enter closed loop generation link, execute test planning for current demand module or cross-module demand, generate candidate case, and independently review candidate case via review role, rewrite problem case, supplement generation for missing coverage item, until meeting stop condition;Finally output the candidate case set after deduplication, and establish the traceable relationship with demand source.This application introduces structured demand review and closed loop generation mechanism, effectively improves the generation quality of function test case and demand coverage, solves the problems that test case is generated by relying on manual, quality is unstable, lacks closed loop control in prior art.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method for generating closed-loop functional test cases based on structured requirements review. Background Technology

[0002] In software testing, functional test cases are typically written manually by testers based on requirements specifications, product prototypes, business process diagrams, page screenshots, interface specifications, acceptance criteria, historical defects, and business rules. Testers need to first understand the requirements, then break down functional modules, identify test points, design forward flows, exception flows, boundary conditions, permission scenarios, state transitions, and cross-module business processes, and finally convert them into functional test cases that conform to the test management platform's specifications. However, this existing manual writing method suffers from problems such as low efficiency, reliance on personal experience, unstable coverage, and high maintenance costs.

[0003] With the development of large language model technology, existing technologies have emerged that utilize large language models to assist in generating functional test cases. This approach typically inputs the requirement text or a simply organized set of requirements into the model, which then outputs test cases all at once. For requirements with relatively simple content and a clear structure, this method can improve test case writing efficiency to some extent. However, in real-world software testing scenarios, where requirement documents are complex, business modules are interconnected, and test coverage requirements are high, relying solely on the one-time generation method still has the following drawbacks and limitations: 1. Insufficient analysis of requirements data, resulting in missing basis for generation. In actual projects, requirements data often include non-text information such as tables, flowcharts, and page screenshots. Existing technologies usually focus on extracting and understanding the main text, lacking unified processing of table boundaries, image semantics, title paths, original text positions, and source relationships. This can lead to some test basis being missed before generation.

[0004] 2. The requirements themselves may have problems such as missing preconditions or incomplete descriptions of business rules. Existing technologies still directly generate test cases when the requirements are incomplete or untestable, which can easily lead to problems such as steps that cannot be executed, expected results that cannot be verified, test scenarios that deviate from the requirements, or business rules that are automatically filled in by the model.

[0005] 3. Existing technologies typically require large models to generate several test cases based on the requirements, without first identifying test points, coverage targets, and priority order around specific requirement modules. This may result in insufficient coverage of key test points for complex modules and the generation of a large number of repetitive or low-value test cases for simple modules.

[0006] 4. Existing technologies typically output results directly after generating test cases, lacking mechanisms for independent review of candidate test cases, problem identification, rewriting and correction, missing coverage supplementation, and stopping judgment. This may lead to low-quality test cases easily entering the final result, requiring extensive manual screening and modification by testers.

[0007] 5. Existing technologies typically generate test cases based on only a single requirement or a single module, which may overlook cross-module test scenarios such as data transfer between modules, state transitions, multi-role collaboration, notification triggering, and abnormal interruptions.

[0008] 6. Existing technologies often generate only text collections, lacking stable source traceability and database constraints, which makes it difficult to analyze the impact of subsequent requirement changes, review use cases, locate defects, and perform regression maintenance.

[0009] It is evident that the core deficiency of existing technologies lies in their failure to establish a complete functional test case generation process. This process begins with the structured analysis and review of requirements data, centered on module-level planning, generation, review, rework, and supplementation, and supports standardized data entry and traceability management. Therefore, there is an urgent need to design a method and system that can first improve the quality of requirements input, then implement closed-loop control over the test case generation process, and ultimately create traceable test cases. Summary of the Invention

[0010] To address the shortcomings of the prior art, this invention provides a method and system for closed-loop generation of functional test cases based on structured requirements review. The core idea is to first convert unstructured requirements data into testable requirements structures and conduct quality reviews, then generate candidate test cases under the drive of test planning in the closed-loop generation stage, and finally store them in the system database after quality closure through the candidate pool.

[0011] The specific technical solution is as follows: A method for generating closed-loop functional test cases based on structured requirements review includes the following steps: Step 1: Receive the user-uploaded requirement data RD, parse the requirement data RD to obtain several traceable data blocks RB; organize the traceable data blocks RB into one or more requirement modules RM based on the user-specified title level as the main segmentation criterion, generate a module summary MS for each requirement module RM, and identify cross-module requirements XF based on the module summary MS. Step 2: Perform quality review on the required module RM and cross-module required XF, identify issues affecting the quality of test case generation, generate correction suggestions, obtain user confirmation of the correction suggestions, and write the confirmed correction content into the supplementary generation fields of the corresponding required module RM and cross-module required XF to obtain the reviewed and optimized required module RM and cross-module required XF. Step 3: Using the reviewed and optimized requirement module RM and cross-module requirement XF as input, execute the closed-loop generation process, including: for the current requirement module RM or cross-module requirement XF, calling the planning role to generate a test design plan; according to the test design plan, calling the generation role to generate one or more candidate functional test cases and storing them in the candidate pool; calling the review role to review the candidate test cases in the candidate pool and outputting a list of approved candidates, a list of problematic candidates, and a list of missing coverage; for the candidate test cases in the problematic candidate list, calling the generation role to rewrite them; for the test points in the missing coverage list, calling the generation role to supplement them; the rewritten or supplemented candidate test cases re-enter the candidate pool for review until the preset stopping conditions are met. Step 4: Convert the candidate test cases that have passed the review in Step 3 into formal test cases and write them into the test case library. At the same time, establish a structured traceability relationship between the formal test cases and the requirement information RD, requirement module RM, data block RB, and test points.

[0012] Furthermore, step 1 also includes an image semantic enhancement step: for images in the requirement data RD, the original image file is located according to the image placeholder, and the image and context are input into a large language model that supports multimodal capabilities, based on the title path of the image and the preceding and following text context, to identify the business information contained in the image, and the identification result is written into the enhanced text field of the corresponding image data block RB.

[0013] Further, in step 1, a module summary MS is generated for each requirement module RM, and cross-module requirement XF is identified based on the module summary MS. Specifically, this includes: inputting each requirement module RM into the large language model in sequence to generate a lightweight structured module summary MS corresponding to the requirement module RM; summarizing all module summary MSs, calling the large language model to identify cross-module business processes composed of two or more requirement module RMs, and outputting a list of cross-module requirement XFs.

[0014] Furthermore, in step 2, the quality review of the requirement module RM includes: taking a single requirement module RM as the review object, reading the data block RB, image semantic enhancement text, table text and source citation associated with the requirement module RM, combining them into a module review context according to the document order, and then inputting the module review context and preset review prompt words into the large language model. The large language model evaluates whether the requirement module RM has any problems affecting the quality of test cases from the perspective of test case generation.

[0015] Furthermore, a quality review is performed on the cross-module requirement XF, including: taking a single cross-module requirement XF as the review object, reading the corresponding requirement module RM, module summary MS, and data block RB according to the associated module list of the single cross-module requirement XF, combining them into a cross-module review context, and then inputting the cross-module review context and preset cross-module review prompts into a large language model, which evaluates whether the cross-module requirement XF has the conditions to generate end-to-end test cases.

[0016] Furthermore, the planning, generation, and review roles in step 3 are undertaken by different large language models, or by the same large language model under different system prompts, task contexts, and output constraints; wherein, the planning role is used to identify the test points that the current module should cover and give a priority coverage order; the generation role is used to generate or revise candidate test cases; and the review role is used to review the quality, coverage, and duplication of candidate test cases.

[0017] Furthermore, the stopping conditions in step 3 include the following conditions being met: the reviewer determines that the key test points of the current module have been sufficiently covered; no new effective coverage is generated in a continuous round of supplementary generation; the current module reaches the preset maximum closed-loop round.

[0018] Furthermore, step 3 also includes: after the closed-loop generation of the current requirement module RM and the cross-module requirement XF, performing semantic deduplication again on the candidate use cases that have passed the review, in order to eliminate duplicate or nearly duplicate use cases between use cases within the module and cross-module process use cases, and between different modules in this process.

[0019] Furthermore, in step 4, the established structured traceability relationship specifically involves associating the formal use case ID with the corresponding requirement document ID, requirement module RM identifier, cross-module requirement XF identifier, data block RB identifier, function point or test point identifier, title path, page number or original text position, image identifier or table identifier, and generation batch identifier.

[0020] Accordingly, the present invention also provides a functional test case closed-loop generation system based on structured requirements review, used to execute the various steps in the above method, including: The requirement data parsing and module segmentation module is used to parse the requirement data RD into traceable data blocks RB, then organize the traceable data blocks RB into one or more requirement modules RM, generate a module summary MS for each requirement module RM, and identify cross-module requirements XF based on the module summary MS. The Requirements Module and Cross-Module Requirements Review and Optimization Module are used to conduct quality reviews of the Requirements Module (RM) and Cross-Module Requirements (XF), and to supplement and revise the Requirements Module (RM) and Cross-Module Requirements (XF) based on the quality review results. The test case generation module is used to execute the closed-loop test case generation process, taking the reviewed and optimized requirement module RM and cross-module requirement XF as input. The test case standardization and traceability management module is used to convert the finally passed candidate test cases into formal test cases and establish a structured traceability relationship between formal test cases and requirement documents, requirement modules (RM), data blocks (RB), function points, or test points.

[0021] Compared with the prior art, the beneficial technical effects of the present invention are as follows: This invention parses the main text, titles, tables, images, and process information in the requirements documents and forms data blocks with source citations. This allows the subsequent generation process to utilize information such as text descriptions, table rules, image semantics, and original text locations simultaneously. Compared to existing technologies that generate test cases based solely on the main text, this invention reduces omissions in testing criteria such as field rules, process nodes, page operations, and state changes, thereby improving the completeness of requirements document utilization.

[0022] Before generating test cases, this invention conducts a quality review of the requirement modules and cross-module requirements to identify issues related to preconditions, business rules, role permissions, state changes, abnormal branches, and acceptance criteria. User-confirmed supplementary content is used as the basis for subsequent generation. This approach reduces invalid or unexecutable test cases and the problem of models automatically completing business rules due to incomplete or unverifiable requirement descriptions, thus improving the testability of requirements before generation.

[0023] This invention does not generate test cases all at once. Instead, it first plans the test scenarios for the required modules, determining test points, coverage objectives, and priorities, and then generates candidate test cases according to the plan. Through a module-level planning mechanism, the generation process is transformed from free generation to controlled generation around the test objectives. In complex module scenarios, this reduces the omission of key test points, and in simple module scenarios, it reduces the generation of low-value repetitive test cases, thereby improving the controllability of module-level test coverage.

[0024] This invention reviews the generated candidate use cases and distinguishes between approved use cases, problematic use cases, and missing coverage items based on the review results. Problematic use cases are rewritten and corrected; missing coverage items are supplemented and generated; and use cases that still fail to meet quality requirements are discarded or recorded. Through a closed-loop mechanism of planning, generation, review, rework, supplementation, and further review, the proportion of problematic use cases—those with unexecutable steps, unverifiable expectations, or content deviating from the requirements—that enter the final result can be reduced, thus improving the quality closed-loop capability of generated use cases.

[0025] This invention identifies cross-module requirements based on the requirements module processing and performs test planning and candidate test case generation for cross-module processes. This allows for supplementary coverage beyond functional test cases within a module, including end-to-end main processes, cross-module data transfer, state transitions, multi-role collaboration, notification triggering, and exception interruptions. This reduces omissions in cross-module main processes when generating test cases only for a single module, thus improving the coverage of cross-module business processes.

[0026] This invention manages the status of candidate test cases during the generation process through a candidate pool and performs deduplication at the module and task levels. Invalid test cases are handled by rewriting and replacement, while missing coverage is handled by adding and supplementing, preventing multiple versions before and after rework from simultaneously entering the final result. This mechanism reduces duplicate or nearly duplicate test cases, lowering the subsequent manual cleanup and merging costs for testers.

[0027] This invention establishes a traceability relationship between test cases and the sources of requirement documents, requirement modules, data blocks, test points, images, or tables upon formal inclusion in the database. This enables testers to quickly identify the source and scope of impact of test cases during test case reviews, requirement changes, defect localization, and regression maintenance. Compared to existing technologies that only output text test cases, the test cases generated by this invention are easier to maintain and reuse over the long term, improving the efficiency of test case traceability and maintenance. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart of the closed-loop generation method for functional test cases according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the system structure in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the process of parsing requirements data and dividing modules in an embodiment of the present invention. Figure 4 This is a flowchart illustrating the test case generation process for the module-level planning-generation-review closed loop in this embodiment of the invention. Figure 5 This is a flowchart illustrating the structured output protocol and fault-tolerant parsing and recovery process in an embodiment of the present invention. Figure 6 This is a state transition diagram of the candidate pool use cases in an embodiment of the present invention; Figure 7 This is a traceability diagram of some functional test cases in an embodiment of the present invention. Detailed Implementation

[0030] 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.

[0031] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] refer to Figure 1-2 This invention provides a method for generating closed-loop functional test cases based on structured requirements review, comprising the following steps: Step 1: As Figure 3 As shown, the system performs requirement data parsing and module segmentation as follows: The system receives the requirement data RD uploaded by the user, which is used to define the scope of data for this requirement parsing, review, and use case generation. The system then parses the requirement data RD and splits it into traceable data blocks RB according to the order of title, paragraph, table boundaries, image placeholders, and document. The system uses the title level specified by the user as the main segmentation criterion and organizes the traceable data blocks RB into one or more requirement modules RM. After the user confirms the requirement module RM, the system generates a module summary MS and identifies cross-module requirements XF based on the module summary MS. Finally, the system outputs the requirement module RM, module summary MS, cross-module requirements XF, and the source mapping relationship of requirement data RD → data block RB → requirement module RM → module summary MS / cross-module requirements XF.

[0033] Among them, RD (Requirement Documents) refers to a single requirement document or requirement document containing images uploaded by the user.

[0034] The traceable data block RB represents the smallest traceable content unit obtained by splitting the requirement data RD according to the order of title, paragraph, table boundary, image placeholder and document.

[0035] The requirement module RM represents a business function module formed by organizing one or more data blocks RB according to the user-specified header hierarchy.

[0036] The module summary (MS) represents a lightweight structured summary generated by the system based on the user-confirmed requirement module (RM).

[0037] Cross-module requirement (XF) refers to an end-to-end business process, cross-module state transition, or cross-module exception branch composed of two or more requirement modules (RM).

[0038] The SourceMap represents the relationships between Requirement Data (RD), Data Block (RB), Requirement Module (RM), Module Summary (MS), and Cross-Module Requirement (XF).

[0039] The specific steps are as follows: 1.1: Register Requirement Documents (RD): The system receives a single requirement document (RD) uploaded by the user and records the Project Id, Requirement Document Id, Document Name (RDName), Document Version (RDVersion), Document Type (RDType), and Original File Path, providing a unified document index for subsequent parsing, module segmentation, requirement review, and use case tracing.

[0040] 1.2: Parsing Requirement Documents (RD): The system reads the requirement documents (RD) and selects a corresponding parsing strategy based on one or more of the following: file extension, file header characteristics, MIME type, and content structure characteristics. For Word documents, the system extracts headings, paragraphs, tables, and image references in the original document order, converts heading styles to Markdown headings, and converts tables to Markdown table text. When an image is detected, a docimg: / / img_NNN placeholder is inserted at the corresponding position in the body text, and the image number, image order, image type, file size, and image storage address are recorded. For PDF documents, the system extracts text page by page and retains page number information. For Markdown and plain text documents, the system retains the original heading, paragraph, list, and numbering structure. For older versions of Word documents, the system employs a multi-level degradation strategy, including format conversion, Office interface, command-line parsing, and plain text parsing, prioritizing the preservation of heading and body text structures. When parsing fails or structural information is missing, the system lowers the parsing confidence level and prompts for manual review, thereby improving the parsing success rate and usability of different document formats.

[0041] 1.3: Generating Traceable Data Blocks (RBs): The system takes the requirement document RD parsed in step 1.2 as input and generates one or more traceable data blocks (RBs) from the requirement document RD based on the title, paragraphs, table boundaries, image placeholders, and document order. Each data block RB contains the following attributes: data block ID, requirement document identifier RDId, document type, title path, original content, enhanced text, sequence number, source citation, and resolution confidence. The source citation includes document version, chapter title, paragraph number, page number, table number, and image number; the original content stores text, table text, or image placeholders directly parsed from the requirement document RD; and the enhanced text stores the results of subsequent image semantic recognition. Through this process, a single requirement document RD is converted into multiple data blocks (RBs) with source citations. The data block RB serves as the smallest unit for subsequent module segmentation, module summary generation, cross-module requirement identification, and use case tracing.

[0042] 1.4: Image Semantic Enhancement: The system locates the original image file based on image placeholders and, combined with the image's title path and surrounding text context, inputs the image and its context into a large language model that supports multimodal capabilities. The model then identifies the business information contained within the image, including but not limited to process relationships, page elements, field information, button operations, state changes, role relationships, rule descriptions, and exception prompts. The system writes the recognition results into the enhanced text field of the corresponding image data block (RB). When the model does not support multimodal capabilities, the system retains the original image reference and marks the image data block (RB) as requiring manual confirmation. This mechanism overcomes the problem that pure text parsing cannot obtain image-related requirement information.

[0043] 1.5: Organizing Requirement Modules (RMs) by Title Level: The system uses the user-specified title level as the primary segmentation strategy. It iterates through all data blocks (RBs) processed in steps 1.3 and 1.4, and based on the title path, title level, and document order of each RB, groups one or more RBs located within the same title boundary into a single requirement module (RM). Each requirement module (RM) includes a module ID, module name, module content, a list of associated data blocks, title context, module order, and module confidence. The module content is formed by combining the original content and enhanced text of its associated data blocks (RBs) in document order. The list of associated data blocks records all RB identifiers contained in this requirement module (RM). The system retains all parent titles of the current module as module context, aligning module boundaries with business function boundaries. When the number of headings in the required document is zero, or the ratio of the number of headings to the number of paragraphs in the document is lower than a preset threshold, the system determines that the required document lacks a usable heading structure, automatically downgrades it to temporary segmentation by paragraph, number, or character length, and marks this type of segmentation result as low confidence for subsequent manual confirmation and adjustment.

[0044] 1.6: Manual Confirmation and Adjustment of Requirement Modules (RM): The system displays the segmentation results of the requirement modules (RM) to the user for confirmation and adjustment. Users can perform actions such as merging modules, splitting modules, renaming modules, moving data blocks, deleting modules, and creating new modules. After each adjustment, the system re-maintains the mapping relationship between the requirement modules (RM) and data blocks (RB). The confirmed requirement modules (RM) serve as the basic input for subsequent requirement reviews, module summary generation, and use case generation.

[0045] 1.7: Generating Module Summary MS and Identifying Cross-Module Requirement XFs: Addressing the challenge of identifying cross-module business processes solely based on title boundaries, after the user confirms the Requirement Module RM, the system sequentially inputs the module name, module content, associated data block RB, associated image semantics, table text, title context, and source citations of each Requirement Module RM into the large language model to generate a lightweight structured module summary MS corresponding to that Requirement Module RM. The module summary MS includes the module ID, module name, summary text, key processes, state changes, source citations, and summary confidence. The summary text summarizes the module's business meaning, key processes describe the main action chains within the module, state changes record state transitions that may affect cross-module flows, and source citations preserve the basis for the summary. The system simultaneously saves the mapping relationship between the MS and RM when saving the module summary MS. Subsequently, the system aggregates all module summary MSs and calls the large language model to identify cross-module business processes composed of two or more Requirement Module RMs, outputting a list of cross-module requirement XFs. Each cross-module requirement (XF) includes a cross-module requirement ID, process name, list of associated modules, process steps, triggering conditions, termination conditions, exception branches, source citations, and identification confidence level. The system configures structured output protocols for the generation of both the module summary (MS) and the cross-module requirement (XF), requiring the large language model to output results according to a preset field model. After receiving the model output, the system parses and validates the fields according to the structured protocol. When the output contains Markdown wrapping, JSON syntax errors, missing fields, or type mismatches, the system sequentially performs format cleaning, JSON repair, field completion validation, and guided retries with error reasons. If a valid structured result cannot be obtained after multiple processing steps, the failure reason is recorded and manual review is prompted.

[0046] Step 2: The system performs a quality review of the required modules (RM) and cross-module requirements (XF), identifies issues affecting the quality of test case generation, and generates correction suggestions. When a user adopts or edits and then adopts a correction suggestion, the system writes the confirmed content into the supplementary generation fields of the corresponding RM or XF, without modifying the original requirement data (RD) and data block (RB). This step ultimately results in the reviewed and optimized RM and XF, which serve as input for subsequent test point planning and functional test case generation.

[0047] The supplementary generated fields are structured fields appended to the requirement module RM or cross-module requirement XF, used to record review revisions confirmed by the user. These fields are independent of the original requirement data RD and data block RB, and are used as input along with the original content in subsequent test planning and test case generation phases.

[0048] The review results are the structured output of the system after reviewing a single RM or XF, including the review object identifier, risk level, problem list, and correction suggestion list. The risk level is divided into three levels: high, medium, and low. Each problem in the problem list includes the problem type, problem description, problem location, and impact description. Each suggestion in the correction suggestion list includes the suggestion content, the corresponding problem identifier, and the basis for the suggestion.

[0049] The specific steps are as follows: 2.1: Requirement Module Quality Review: The system uses a single requirement module (RM) as the review object, reads the associated data blocks (RBs), image semantic enhancement text, table text, and source citations, and combines them into a module review context in document order. The system inputs the module review context and preset review prompts into the large language model, requiring the model to evaluate whether the RM has issues affecting test case quality from the perspective of test case generation. The review prompts include review dimensions such as function point descriptions, business rules, state changes, abnormal branches, role permissions, and acceptance criteria, used to guide the model to identify problems from the perspective of test executability and verifiability. The large language model outputs the review results according to the structured review output protocol. The review results include the review object identifier, risk level, problem list, and correction suggestion list; the risk level is divided into three levels: high, medium, and low. High risk indicates the existence of problems that make test cases unexecutable or unverifiable; medium risk indicates problems that affect test case quality but can be corrected by supplementing information; low risk indicates problems that are not clearly described but do not affect test case generation. The system performs the same structured parsing and fault-tolerant processing on the review model output as in step 1.7.

[0050] 2.2 Cross-Module Requirement Quality Review: The system uses a single cross-module requirement (XF) as the review object. Based on the list of associated modules for that XF, it reads the corresponding requirement module's RM, module summary (MS), and necessary data block (RB) content, combining them into a cross-module review context. The system inputs the cross-module review context and preset cross-module review prompts into the large language model, requiring the model to evaluate whether the XF meets the conditions for generating end-to-end test cases. The cross-module review prompts include review dimensions such as process start and end points, cross-module action connections, state transitions, shared data, role collaboration, and abnormal branches. The large language model outputs the review results according to the structured review output protocol, with the review result format the same as in step 2.1. Issues addressed in the review include unclear process start or end points, missing cross-module action connections, missing intermediate states in state transitions, inconsistent shared data definitions, lack of permission descriptions for role collaboration, and undefined handling methods for abnormal branches. The system performs the same structured parsing and fault-tolerant processing on the review model output as in step 1.7.

[0051] 2.3: Review Result Summary and Risk Ranking: After completing the review of all RM modules and XF cross-module requirements, the system summarizes all review results and generates review summary information. The review summary information includes the risk level, number of issues, main issue types, and number of corrective suggestions for each RM and XF. The system sorts the reviewed objects according to their risk level from high to low, prioritizing the display of high-risk objects, enabling testers to quickly locate the most critical requirement defects.

[0052] 2.4: User Confirmation and Adoption of Correction Suggestions: The system displays the review results of each RM and XF to the user, sorted by risk. Each review result includes a risk level, a list of issues, and a list of correction suggestions. Users can choose to ignore, adopt, or edit and then adopt each correction suggestion. For suggestions chosen to be ignored, the system records the reason for the ignore but does not modify the content of the corresponding RM or XF. For suggestions chosen to be adopted, the system directly writes the correction suggestion into the supplementary generation field of the corresponding RM or XF. For suggestions chosen to be edited and then adopted, the system writes the user-edited correction content into the supplementary generation field of the corresponding RM or XF.

[0053] 2.5: Supplementary Content Writing and Cascading Updates: When supplementary generated fields of the Resource Provider (RM) or Module Summary (XF) are updated, the system performs a cascading update operation. If the update involves critical processes or status changes of the RM, the system regenerates the corresponding fields in the RM's Module Summary (MS) and checks whether the change affects identified cross-module requirements (XFs). If it does, the system synchronously updates the process steps, triggering conditions, or abnormal branches of the relevant XFs. If the update involves XF process steps or cross-module action connections, the system synchronously checks and updates the supplementary generated fields related to the XF in the associated module's RM. Cascading updates only modify the supplementary generated fields and the Module Summary (MS), and do not modify the original requirement data (RD) and data block (RB).

[0054] 2.6: Post-Review Requirement Status Confirmation: After the user completes all confirmations and cascading updates, the system marks the review status of each RM and XF as reviewed, and records the review time, the number of adopted correction suggestions, and the number of ignored suggestions. The reviewed and optimized RMs and XFs serve as input for subsequent test point planning and functional test case generation.

[0055] Step 3: Test case generation based on module-level planning-generation-review closed loop (closed-loop generation stage): such as Figure 4 As shown, taking the requirement module RM (after review and optimization in step 2) and cross-module requirement XF (after user confirmation) as input, the test planning, candidate test case generation, candidate test case review, problem test case rewriting, missing coverage supplementation, deduplication, and output are completed module by module. The candidate pool is only used to manage the status of candidate test cases in this generation task to prevent the model generation results from entering the formal test case library directly without review.

[0056] The core process is as follows: 3.1: Task Initialization and Collaboration Role Configuration: The system reads the user-confirmed Requirement Module (RM) and cross-module Requirements (XF), establishes a queue of modules to be generated according to the document order of the RM or the user confirmation order, and initializes a candidate pool for the current RM. The candidate pool manages the generation process status of candidate test cases for the current module. The candidate status of test cases includes: generated (generated and awaiting review), needs_rework (requires rewriting), discarded (discarded), and approved (approved and ready for subsequent stages). The system initializes the generation rounds, the number of rewritten test cases, and the module completion marker for the current RM. Simultaneously, the system configures planning, generation, and review roles in this stage. These roles can be undertaken by different large language models, or by the same large language model under different system prompts, task contexts, and output constraints. The planning role identifies the test points or test intentions that the current module should cover; the generation role generates or modifies candidate test cases; and the review role reviews the quality, coverage, and duplication of candidate test cases.

[0057] 3.2: Current Module Test Planning: The system calls the planning role to read the module content, associated data blocks (RBs), module summary (MS), supplementary generated fields, and necessary project knowledge base information of the current Resource Manager (RM), and outputs the test design plan for the current RM. The project knowledge base stores the business rules, test specifications, and typical test experiences of the current project, and is continuously maintained by testers during the project. Each entry in the knowledge base includes an entry identifier, business object name, associated keywords, entry content, and update time. The system retrieves relevant entries from the project knowledge base based on the module name, keywords, business object, or process name of the current RM or XF. The retrieved knowledge base information is only used as an auxiliary reference for business rules, test specifications, or historical experience, and does not replace the RM or XF as the primary basis for generation. The knowledge base information is obtained by the system from the project knowledge base based on the module name, keywords, business object, or process name of the RM or XF, and is only used as an auxiliary reference for business rules, test specifications, or historical experience, and does not replace the RM or XF as the primary basis for generation.

[0058] The planning role proactively identifies test points or test intentions to be covered based on the RM content and provides a priority coverage order. The system provides test design check dimensions such as main process, field constraints, business rules, permissions, state changes, abnormal paths, data display and query in the prompts to remind the planning role to avoid missing typical test perspectives, but does not require each RM to mechanically generate all types of test points. The test design plan output by the planning role should conform to the system's preset structured field model and should at least include test points or test intentions, coverage objectives, priority order, and generation prompts. The system only proceeds to the candidate test case generation step after the plan result is successfully parsed and passes field validation.

[0059] 3.3: Candidate Test Case Generation and Pooling: The system call generation role generates candidate functional test cases based on the current RM's test design plan. The generated candidate test cases must undergo structured formatting and fault-tolerant parsing before being written into the candidate pool. (Refer to...) Figure 5 Each candidate test case must include at least a test case title, test case type, importance level, preconditions, test steps, expected results, belonging module, corresponding test point or test intent, and candidate status. The test case type can include functional, performance, compatibility, security, and other test types, and the importance level can correspond to P0, P1, P2, P3, etc. Candidate test cases are associated with their corresponding Resource Managers (RMs), test points, or test intents for subsequent review, rewriting, deduplication, and traceability.

[0060] 3.4: Candidate Test Case Review and One-Time Feedback: The system calls the review role to independently review candidate test cases in the current module's candidate pool. In a single review result, it simultaneously outputs a list of approved candidates, a list of problematic candidates, a list of missing coverage items, and a judgment on whether the current module is complete, processed using a structured format and fault-tolerant parsing. Review criteria include: whether the candidate test cases cover the planned test points or test intentions; whether the steps are executable; whether the expected results are verifiable; whether the content deviates from RM or XF; whether there are any baseless assumptions; whether the test case type and importance are reasonable; and whether any key processes, abnormal paths, or cross-module main processes are omitted. The candidate pool status is only used for internal circulation within the generation process and is not equivalent to the review status in the official test case library of the test management platform.

[0061] 3.5: Test Case Rewriting and Missing Field Coverage: Rewritten and supplemented test cases still need to undergo the same structured parsing and field validation mechanism. Results with parsing failures or incomplete fields should not be directly entered into the candidate pool. (See reference...) Figure 6 .

[0062] For candidate test cases that fail the review, the system passes the original candidate test case, the reason for the review failure, the corresponding Resource Manager (RM), and the corresponding test point or test intent to the generation role. The generation role then regenerates the revised candidate test case. The revised candidate test case re-enters the review process, and the original candidate test case is not included in the database. If the same candidate test case fails to pass the review after multiple rewrites, the system marks it as discarded and records the reason in the generation task report.

[0063] For missing coverage items pointed out by the review role, the system does not forcibly modify existing test cases. Instead, it treats the missing test points or test intentions as supplementary generation tasks, requiring the generation role to add candidate test cases. In this way, the system handles the two types of problems, "existing test case quality is unacceptable" and "insufficient test coverage," separately, avoiding the duplication of candidate test cases during rework.

[0064] 3.6: Current Module Termination Judgment: The system determines whether the current Resource Management (RM) generation should end based on feedback from the review role and the closed-loop execution status. The current module's closed loop ends when any of the following conditions are met: The review role determines that the key test points or test intents of the current module have been sufficiently covered; a consecutive round of supplementary generation has not produced any new effective coverage; the current module has reached its maximum closed-loop round. For gaps that are still not covered and cannot be effectively generated further, the system records them in the generation task report as a reference for subsequent manual supplementation of requirements or manual design of test cases, but they are not written into the test case library as formal test cases.

[0065] 3.7: Deduplication of Candidate Test Cases in the Current Module: After the current RM loop is completed, the system performs semantic deduplication on the candidate test cases in the approved state in the candidate pool of the current module. Deduplication only processes the candidate test cases generated by the current module in this generation task and does not compare them with the platform's existing test case library. The system inputs the candidate test case set of the current module into the review role, who judges whether there is duplication or near duplication among the candidate test cases from the aspects of business objectives, test scenarios, operation steps, and expected results. For candidate test cases that differ only in wording but have the same verification objectives and test processes, the review role outputs suggestions for retention, merging, or deletion. Based on this, the system marks duplicate or low-value candidates as discarded and only retains valid candidates to continue to the subsequent process.

[0066] 3.8: Cross-module requirement XF closed-loop generation: After all RM processing is completed, the system uses cross-module requirement XF as input to execute the same test planning, candidate test case generation, candidate test case review, problem test case rewriting, missing coverage supplementation, stop judgment and deduplication process. The XF closed loop focuses on covering end-to-end main process, cross-module data transfer, state transition, multi-role collaboration, notification triggering and exception interruption scenarios.

[0067] 3.9: Task-level Deduplication and Output: After all RM and XF loops are completed, the system performs task-level semantic deduplication on all approved candidates in this generated task. This is to eliminate possible duplication or near-duplication between test cases within a module and cross-module process test cases, as well as between different modules in this process. Finally, only the set of candidate test cases in the approved state is output for the standardization and traceability step 4 to write into the test management system.

[0068] Step 4: Standardized Test Case Storage and Traceability Management: Receive the approved candidate test case set output from Step 3, convert it into system-manageable formal test cases, and establish traceability relationships between formal test cases and requirement documents, requirement modules (RM), data blocks (RB), functional points, or test points. The core process is as follows: 4.1: Establishing a mapping relationship between candidate test cases and test modules: The system groups the set of candidate test cases in the approved state according to their respective requirement modules (RM) or cross-module requirements (XF). Users select a corresponding test module for each group. When the system imports the test cases, it saves all candidate test cases under that group to the user-selected test module. This test module is only used for categorization display on the test management page and does not represent the source of the requirement; the actual source of the test cases is still recorded by the traceability relationship. Based on the mapping relationship confirmed by the user, the system writes the corresponding candidate test cases to different test modules. For test case groups without test module mapping, the system directly imports them into the default module of the project.

[0069] 4.2: Writing Formal Test Cases: Based on the test modules confirmed by the user, the system writes candidate test cases into the system. During writing, the system saves the test case title, preconditions, importance level, test case type, test steps, and expected results according to the test case data format. The test steps are written in the order of the steps in the candidate test cases, and each step includes at least a step number, step description, and expected result. The internal status of the candidate pool is not reflected in the platform's review status; formal test cases added to the database are uniformly placed into a pending review status.

[0070] 4.3: Establishing Traceability Relationships: The system establishes a structured traceability relationship for each formal use case, associating the formal use case ID with the corresponding requirement document ID, requirement module (RM) identifier, cross-module requirement (XF) identifier, data block (RB) identifier, function point or test point identifier, title path, page number or original text location, image identifier or table identifier, and generation batch identifier. When the system displays a formal use case, it simultaneously displays the requirement module, function point, and test point from which the use case originated; when a user clicks on the traceability information, the system can jump to or locate the corresponding requirement document, requirement module, or original text fragment.

[0071] 4.4: Transactional Data Ingestion and Result Feedback: The system writes formal test case data in batches according to the module mapping relationships confirmed by the user, and writes the test case master record, test step record, and traceability relationship record within the same ingestion transaction. If the current batch write fails, the batch is rolled back to avoid situations where the test case master record exists but the steps or traceability relationships are missing. After the ingestion is completed, the system outputs the ingestion results, including the number of successful ingestions, the number of failed ingestions, the reason for the failure, the corresponding requirement module or cross-module requirement, the target test module, and the generated batch information.

[0072] In one specific embodiment, the user uploads a "Requirement Specification for Employee Overtime Application Approval" as requirement document RD001. This requirement document includes instructions for filling out the overtime application page, a field rule table, an approval flowchart, screenshots of the applicant's page, screenshots of the approver's processing page, and acceptance criteria. The field rule table records fields such as overtime date, start time, end time, reason for overtime, and attachments; the approval flowchart records nodes such as application creation, submission, approval approval, approval rejection, and notification to the applicant.

[0073] After receiving the requirement document RD001, the system parses its title, body text, tables, and images to generate multiple traceable data blocks RB. For example, RB001 corresponds to the overtime application function overview, RB002 to the field rule table, RB003 to the approval flowchart image, RB004 to the screenshot of the approver's processing page, and RB005 to the acceptance criteria. For RB003 and RB004, the system combines the chapter in which the image is located and the surrounding text to call a large model with multimodal capabilities for image semantic recognition, extracting information such as process nodes, page buttons, status changes, and role operations, and writes the recognition results into the enhanced text field of the corresponding data block.

[0074] The system then segments the data blocks (RBs) into modules according to the user-specified header hierarchy, forming requirement modules (RMs). For example, RM01 is for overtime application creation, RM02 for overtime application submission, RM03 for approver processing, and RM04 for application record query. The system generates a module summary (MS) for each requirement module and identifies cross-module requirements (XF01) based on the module summary, representing the "end-to-end process of overtime applications from creation, submission, approval processing to notification and query." The system also maintains the source mapping relationships between RD001, each data block (RB), each requirement module (RM), and the cross-module requirement (XF01).

[0075] During the requirements review phase, the system invokes the large model to conduct quality reviews of the requirements module RM and cross-module requirements XF. Taking RM01 "Overtime Application Creation" as an example, the system identifies that the field rule table only states "overtime duration needs to be verified," but does not specify the minimum duration or the verification method for the time range. Taking XF01 as an example, the system identifies a "rejection" node in the approval flowchart, but the acceptance criteria do not specify the application status after rejection or whether the applicant can resubmit. Based on this, the system generates correction suggestions, such as "overtime duration must not be less than 0.5 hours," "start time must not be later than end time," and "after approval rejection, the status is 'rejected,' and the applicant can modify and resubmit." After the user confirms the adoption, the system writes the above content into the supplementary generated fields of the corresponding RM or XF, without modifying the original requirements data RD001.

[0076] After completing the requirements review, the system sequentially selects a requirement module (RM) or a cross-module requirement (XF) as the current generation object and executes a module-level planning-generation-review closed loop. In this closed loop, the system configures planning, generation, and review roles; the planning role is used to generate test plans, the generation role is used to generate or rewrite candidate test cases, and the review role is used to review the quality, coverage, and duplication of candidate test cases.

[0077] When RM01 "Overtime Application Creation" is the current generation object, the planning role reads the content of RM01, the associated data block RB002, the image semantic enhancement text, supplementary generation fields, and necessary knowledge base information to generate a test plan. The test plan, having passed structured validation, is then input into the next generation stage. This test plan includes test points, coverage objectives, and priority order. The coverage objective describes the business results or risk scope that needs to be verified for that test point, and the priority order indicates the order of processing during generation. For example, the coverage objective for test point TP001 "Start Time Later Than End Time" is to verify whether the system blocks illegal time ranges and provides a clear prompt; its priority order can be set to P1. The coverage objective for "Attachment Format Not Supported" is to verify whether the system blocks unauthorized attachment formats and keeps the application unsaved; its priority order can be set to P2.

[0078] The system generates candidate functional test cases based on the test plan of RM01, and writes the candidate test cases that pass the structured validation into the candidate pool corresponding to RM01. For example, for the test point "start time is later than end time", the system generates a candidate test case whose steps are to fill in the overtime date, set the start time to be later than the end time, and click save; the expected result is that the system will prevent saving and prompt an error in the time range. The candidate test case is also associated with the RM01 and RB002 field rule tables and the corresponding test point.

[0079] Subsequently, the system invokes the review role to review the candidate test cases in the RM01 candidate pool. If the review finds that the expected result of a test case is only written as "error message", and the specific verification result cannot be determined, the candidate test case is marked as needs_rework, and the failure reason is passed to the generation role. The generation role then rewrites the test case accordingly, correcting the expected result to "page prompts 'start time cannot be later than end time', application record is not saved". If the review finds that the "attachment format not supported" coverage item is missing, the system adds a supplementary generation task to generate the corresponding candidate test case. The rewritten and supplementary generated test cases re-enter the candidate pool for review.

[0080] When all high-priority test points in the RM01 test plan are covered by approved candidate test cases, and the review role no longer outputs any missing coverage items, the system determines that the current module coverage is sufficient. If gaps still exist but the maximum closed-loop cycle has been reached, or continuous supplementary generation has not produced effective new coverage, the system also ends the current module closure and records the remaining gaps in the generation task report. After the RM01 closure ends, the system immediately performs module-level deduplication on the approved candidate test cases in the module's candidate pool; for test cases with essentially the same verification objectives, operation steps, and expected results, the one with more complete coverage and clearer description is retained, and the remaining candidates are marked as discarded.

[0081] For the cross-module requirement XF01, the system also executes the planning, generation, review, rewriting, supplementation, and deduplication process. The cross-module test points generated by the system include: the applicant creating and submitting an overtime application, the approver approving it, the applicant receiving a notification, and the application record status changing to "approved"; as well as scenarios where the applicant modifies and resubmits after approval rejection. If the review role finds that the end-to-end process lacks a branch for resubmission after rejection, the system will use that branch as a missing coverage item to supplement and generate cross-module candidate test cases.

[0082] After all requirement modules (RM) and cross-module requirement (XF) loops are closed, the system performs task-level deduplication on all approved candidate test cases in this task. This eliminates potential duplication or near-duplication between different modules, and between test cases within a module and cross-module test cases. After deduplication, the system outputs the final set of candidate test cases that can be added to the database for this task.

[0083] During the standardization and database entry phase, users map RM01-related candidate test cases to the "Overtime Application" test module and XF01-related candidate test cases to the "Overtime Approval Process" test module. The system writes approved candidate test cases into the formal test case library, saving the test case title, preconditions, test steps, expected results, importance level, and test case type, and sets the formal test case status to pending review.

[0084] Simultaneously, the system establishes source traceability relationships for formal use cases. For example, the formal use case TC001 "Verification of overtime application start time being later than end time" is associated with requirement data RD001, requirement module RM01, data block RB002, test point TP001 "Time range verification", and generation batch BATCH001; the cross-module formal use case TC020 "Modify and resubmit overtime application after rejection" is associated with requirement data RD001, cross-module requirement XF01, RM01, RM02, and RM03 participating in the cross-module process, approval flowchart data block RB003, acceptance standard data block RB005, test point TP020 "Modify and resubmit after rejection", and generation batch BATCH001. For details on use cases and traceability relationships, see [link to relevant documentation]. Figure 7 As shown, testers can quickly locate the source and scope of impact of test cases based on this traceability relationship during subsequent reviews, requirement changes, or defect localization.

[0085] Through the above embodiments, the present invention can convert requirement data containing text, tables and images into reviewable requirement modules and cross-module requirements in real business requirement scenarios. Through large model planning roles, generation roles and review roles, a closed loop of planning, generation, review, rewriting, supplementation and deduplication is executed with a single RM or XF as the object, and finally form functional test cases that can be stored, audited and traced.

[0086] In another embodiment, a functional test case closed-loop generation system based on structured requirements review is also provided, for performing the steps in the above method, including: The requirement data parsing and module segmentation module is used to parse the requirement data RD into traceable data blocks RB, then organize the traceable data blocks RB into one or more requirement modules RM, generate a module summary MS for each requirement module RM, and identify cross-module requirements XF based on the module summary MS. The Requirements Module and Cross-Module Requirements Review and Optimization Module are used to conduct quality reviews of the Requirements Module (RM) and Cross-Module Requirements (XF), and to supplement and revise the Requirements Module (RM) and Cross-Module Requirements (XF) based on the quality review results. The test case generation module is used to execute the closed-loop test case generation process, taking the reviewed and optimized requirement module RM and cross-module requirement XF as input. The test case standardization and traceability management module is used to convert the finally passed candidate test cases into formal test cases and establish a structured traceability relationship between formal test cases and requirement documents, requirement modules (RM), data blocks (RB), function points, or test points.

[0087] Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. Furthermore, those skilled in the art will recognize that, based on the ideas of this invention, 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 invention.

Claims

1. A method for generating closed-loop functional test cases based on structured requirements review, characterized in that, Includes the following steps: Step 1: Receive the user-uploaded requirement data RD, parse the requirement data RD to obtain several traceable data blocks RB; organize the traceable data blocks RB into one or more requirement modules RM based on the user-specified title level as the main segmentation criterion, generate a module summary MS for each requirement module RM, and identify cross-module requirements XF based on the module summary MS. Step 2: Perform quality review on the required module RM and cross-module required XF, identify issues affecting the quality of test case generation, generate correction suggestions, obtain user confirmation of the correction suggestions, and write the confirmed correction content into the supplementary generation fields of the corresponding required module RM and cross-module required XF to obtain the reviewed and optimized required module RM and cross-module required XF. Step 3: Using the reviewed and optimized requirement module RM and cross-module requirement XF as input, execute the closed-loop generation process, including: for the current requirement module RM or cross-module requirement XF, calling the planning role to generate a test design plan; according to the test design plan, calling the generation role to generate one or more candidate functional test cases and storing them in the candidate pool; calling the review role to review the candidate test cases in the candidate pool and outputting a list of approved candidates, a list of problematic candidates, and a list of missing coverage; for the candidate test cases in the problematic candidate list, calling the generation role to rewrite them; for the test points in the missing coverage list, calling the generation role to supplement them; the rewritten or supplemented candidate test cases re-enter the candidate pool for review until the preset stopping conditions are met. Step 4: Convert the candidate test cases that have passed the review in Step 3 into formal test cases and write them into the test case library. At the same time, establish a structured traceability relationship between the formal test cases and the requirement information RD, requirement module RM, data block RB, and test points.

2. The functional test case closed-loop generation method according to claim 1, characterized in that, Step 1 also includes an image semantic enhancement step: For images in the requirement data RD, the original image file is located according to the image placeholder, and the image and context are input into a large language model that supports multimodal capabilities, based on the title path of the image and the preceding and following text context, to identify the business information contained in the image, and the identification result is written into the enhanced text field of the corresponding image data block RB.

3. The functional test case closed-loop generation method according to claim 2, characterized in that, In step 1, a module summary MS is generated for each requirement module RM, and cross-module requirement XF is identified based on the module summary MS. Specifically, this includes: inputting each requirement module RM into the large language model in sequence to generate a lightweight structured module summary MS corresponding to the requirement module RM; summarizing all module summary MSs, calling the large language model to identify cross-module business processes composed of two or more requirement module RMs, and outputting a list of cross-module requirement XFs.

4. The functional test case closed-loop generation method according to claim 1, characterized in that, In step 2, the quality review of the requirement module RM includes: taking a single requirement module RM as the review object, reading the data block RB, image semantic enhancement text, table text and source citation associated with the requirement module RM, combining them into a module review context according to the document order, and then inputting the module review context and preset review prompt words into the large language model. The large language model evaluates whether the requirement module RM has any problems affecting the quality of test cases from the perspective of test case generation.

5. The functional test case closed-loop generation method according to claim 4, characterized in that, The quality review of the cross-module requirement XF includes: taking a single cross-module requirement XF as the review object, reading the corresponding requirement module RM, module summary MS and data block RB according to the associated module list of the single cross-module requirement XF, combining them into a cross-module review context, and then inputting the cross-module review context and preset cross-module review prompts into a large language model. The large language model evaluates whether the cross-module requirement XF has the conditions to generate end-to-end test cases.

6. The method for generating closed-loop functional test cases according to claim 1, characterized in that, The planning, generation, and review roles in step 3 are undertaken by different large language models, or by the same large language model under different system prompts, task contexts, and output constraints. The planning role is used to identify the test points that the current module should cover and give a priority order for coverage. The generation role is used to generate or modify candidate test cases. The review role is used to review the quality, coverage, and duplication of candidate test cases.

7. The functional test case closed-loop generation method according to claim 6, characterized in that, The stopping condition in step 3 includes the following condition being met: the reviewer determines that the key test points of the current module have been sufficiently covered; One round of supplementary generation failed to produce any new effective coverage; the current module has reached the preset maximum closed-loop cycle.

8. The functional test case closed-loop generation method according to claim 6, characterized in that, Step 3 further includes: after the closed-loop generation of the current requirement module RM and the cross-module requirement XF, performing semantic deduplication again on the candidate use cases that have passed the review, in order to eliminate duplicate or nearly duplicate use cases between use cases within the module and cross-module process use cases, and between different modules in this process.

9. The method for generating closed-loop functional test cases according to claim 1, characterized in that, In step 4, the structured traceability relationship is established by associating the formal use case ID with the corresponding requirement document ID, requirement module RM identifier, cross-module requirement XF identifier, data block RB identifier, function point or test point identifier, title path, page number or original text position, image identifier or table identifier, and generation batch identifier.

10. A functional test case closed-loop generation system based on structured requirements review, used to execute the functional test case closed-loop generation method as described in any one of claims 1-9, characterized in that, include: The requirement data parsing and module segmentation module is used to parse the requirement data RD into traceable data blocks RB, then organize the traceable data blocks RB into one or more requirement modules RM, generate a module summary MS for each requirement module RM, and identify cross-module requirements XF based on the module summary MS. The Requirements Module and Cross-Module Requirements Review and Optimization Module are used to conduct quality reviews of the Requirements Module (RM) and Cross-Module Requirements (XF), and to supplement and revise the Requirements Module (RM) and Cross-Module Requirements (XF) based on the quality review results. The test case generation module is used to execute the closed-loop test case generation process, taking the reviewed and optimized requirement module RM and cross-module requirement XF as input. The test case standardization and traceability management module is used to convert the finally passed candidate test cases into formal test cases and establish a structured traceability relationship between formal test cases and requirement documents, requirement modules (RM), data blocks (RB), function points, or test points.

Images