Test case generation methods, devices, equipment, and storage media

Abstract

This application relates to a test case generation method, apparatus, device, and storage medium. The method includes: obtaining a structured requirements document; retrieving reference test cases from a historical test case library based on the structured requirements document; inputting the structured requirements document and reference test cases into a generation model to generate test cases; verifying the test cases and obtaining quality feedback information; if the quality feedback information does not meet preset quality conditions, dynamically adjusting the generation parameters based on the quality feedback information, and regenerating the test cases using the adjusted generation parameters; the generation parameters include retrieval conditions and / or model-side parameters. This application achieves continuous optimization of test case quality, controllable convergence, and improved automated generation efficiency by constructing a closed-loop mechanism, combining knowledge guidance from reference test cases with dynamic parameter adjustment, and balancing quality and resource consumption under the constraint of an upper limit on the number of iterations.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to a test case generation method, apparatus, device, and storage medium. Background Technology

[0002] In the software development lifecycle, the design and writing of test cases are crucial steps in ensuring software quality. With the increasing complexity of modern software system architectures and the accelerating pace of requirement iterations under agile development models, the traditional method of relying on manual test case writing is no longer sufficient to meet the requirements of efficient and high-quality delivery.

[0003] To improve test case generation efficiency, the industry has proposed various automated test case generation solutions. For example, using large language models to parse requirements documents and generate test cases has achieved some breakthroughs in efficiency improvement and process automation. However, existing solutions still have significant shortcomings in areas such as domain adaptability, complex document processing, resource consumption, dynamic response, and quality assurance. Summary of the Invention

[0004] One objective of this application is to provide a test case generation method to address the comprehensive deficiencies of existing automated test case generation schemes in terms of domain adaptability, complex document processing, resource consumption, dynamic response, and quality assurance; another objective is to provide a test case generation device; a third objective is to provide an electronic device; and a fourth objective is to provide a computer-readable storage medium.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0006] Firstly, this application provides a test case generation method, the method comprising:

[0007] Obtain a structured requirements document; wherein the structured requirements document includes at least one requirement unit to be used to generate test cases;

[0008] Based on the structured requirements document, retrieve reference test cases from the historical test case library;

[0009] Input the structured requirements document and the reference use cases into the generation model to generate test cases;

[0010] The test cases are verified to obtain quality feedback information;

[0011] If the quality feedback information does not meet the preset quality conditions, the generation parameters are dynamically adjusted based on the quality feedback information, and the test cases are regenerated using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

[0012] In one possible implementation, verifying the test cases and obtaining quality feedback information includes:

[0013] The automated verification module performs syntax consistency checks, logic conflict detection, and requirement traceability coverage analysis on the test cases to generate quality scores.

[0014] The test cases are validated through manual review, the quality scores are corrected, and problem information is marked.

[0015] The revised quality score and the problem information are used as the quality feedback information.

[0016] In one possible implementation, dynamically adjusting the retrieval conditions includes one or more of the following: modifying the weight or similarity threshold of the query vector, switching the index type or retrieval field, or encoding the feedback information from the previous round of verification into additional query constraints.

[0017] Dynamically adjusting the model-side parameters includes one or more of the following: updating the prompt word template, introducing negative examples and correction instructions, adjusting the model parameters of the generated model, and switching the generated model.

[0018] In one possible implementation, retrieving reference test cases from the historical test case library based on the structured requirements document includes:

[0019] Using the requirement units in the structured requirement document as query conditions, similarity matching and filtering are performed through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library; wherein, the multi-level index includes semantic vector index, tag inverted index and module classification index; the reference test cases carry boundary condition handling methods and / or abnormal path design logic.

[0020] In one possible implementation, the step of using requirement units in the structured requirement document as query conditions and performing similarity matching and filtering through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library includes:

[0021] The requirement units in the structured requirement document are encoded into query vectors; wherein, the requirement unit includes at least a functional module identifier, an operation step description, and an expected result;

[0022] Using the module classification index, the retrieval range corresponding to the functional module identifier is determined from the historical test case library;

[0023] Based on the query vector, the semantic vector index is used to search within the retrieval range to determine a set of candidate use cases;

[0024] The candidate use case set is filtered and reordered using the inverted index of the tags to obtain the reference use case.

[0025] In one possible implementation, the method further includes:

[0026] When the number of test cases in the historical test case library for the business domain to which the structured requirement document belongs is lower than a preset threshold, the associated business domains corresponding to the business domain to which the structured requirement document belongs are retrieved from the preset domain knowledge graph based on the semantic similarity between business domains; wherein, the preset domain knowledge graph is used to store the semantic association relationships between functional modules of different business domains, and the semantic association relationships include semantic similarity;

[0027] The test cases corresponding to the associated business domains are used as migration test cases, and terminology mapping and structure alignment are performed on the migration test cases to generate candidate test cases that are adapted to the business domain to which the structured requirements document belongs.

[0028] In one possible implementation, obtaining the structured requirements document includes:

[0029] Obtain the initial requirements document;

[0030] The initial requirements document is subjected to multimodal content parsing to obtain the parsed content; wherein, the multimodal content parsing includes at least one of the following: layout analysis and hierarchical structure recognition for text content, optical character recognition and image segmentation for image content, and structure recognition for table content;

[0031] The parsed content is semantically segmented and cleaned to generate the structured requirements document.

[0032] In one possible implementation, the method further includes:

[0033] The system receives revisions from reviewers to the structured requirements document and uses the revised document as the final structured requirements document. The revisions include at least one of error correction, content addition, and redundancy removal.

[0034] In one possible implementation, the method further includes:

[0035] Control the test cases to execute in an automated execution environment; if execution fails, obtain the execution log and failure information.

[0036] The test cases, execution logs, and failure information are input into the generation model. Errors are located and fixed by combining historical successful test case templates, and the fixed test cases are generated. The verification and iterative optimization steps are then re-executed.

[0037] Secondly, embodiments of this application provide a test case generation apparatus, the apparatus comprising:

[0038] The first processing unit is used to obtain a structured requirements document; wherein the structured requirements document includes at least one requirement unit to generate test cases;

[0039] The second processing unit is used to retrieve reference test cases from the historical test case library based on the structured requirements document;

[0040] The third processing unit is used to input the structured requirements document and the reference use cases into the generation model to generate test cases;

[0041] The fourth processing unit is used to verify the test cases and obtain quality feedback information.

[0042] The fifth processing unit is used to dynamically adjust the generation parameters according to the quality feedback information if the quality feedback information does not meet the preset quality conditions, and to regenerate test cases using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

[0043] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0044] The memory stores computer-executed instructions;

[0045] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0046] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0047] The beneficial effects of this application are:

[0048] The test case generation method, apparatus, device, and storage medium provided in this application embodiment achieve continuous optimization and controllable convergence of test case quality by constructing a closed-loop mechanism of "generation-verification-feedback-iteration," significantly improving the completeness, accuracy, and engineering usability of the generated results. At the same time, the knowledge guidance of historical reference test cases reduces the risk of model illusion, the dynamic adjustment of generation parameters enhances the system's adaptability, and the setting of the upper limit of the number of iterations effectively balances quality improvement and resource consumption, thereby improving the efficiency of automated generation while ensuring high-quality output of test cases. Attached Figure Description

[0049] Figure 1 A flowchart illustrating a test case generation method provided in an embodiment of this application;

[0050] Figure 2 A flowchart illustrating the process of generating test cases is provided in an embodiment of this application.

[0051] Figure 3 A schematic diagram of the architecture of a test case generation system based on a large model provided in an embodiment of this application;

[0052] Figure 4 A flowchart illustrating another test case generation method provided in this application embodiment;

[0053] Figure 5 A flowchart illustrating a multi-level indexing mechanism is provided for embodiments of this application.

[0054] Figure 6 This application provides a flowchart of a closed-loop iterative optimization process in a test case generation method.

[0055] Figure 7 This is a schematic diagram of the structure of a test case generation device provided in an embodiment of this application;

[0056] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0058] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0059] As modern software system architectures become increasingly complex, traditional test case writing paradigms are facing unprecedented challenges. This predicament is particularly pronounced when dealing with multi-dimensional requirement documents and scenarios involving frequent requirement changes. Traditional test case design relies heavily on manual operations, requiring test engineers to deeply analyze requirement documents, accurately grasp functional characteristics, and construct test plans. However, this process has several limitations: manual analysis is susceptible to cognitive differences, potentially leading to omissions of key test scenarios or misjudgments of ambiguous requirements; test case updates triggered by requirement changes often consume significant manpower and are prone to version synchronization discrepancies. When system functionality grows exponentially, traditional methods struggle to maintain the completeness and accuracy of test coverage, especially regarding insufficient coverage of boundary condition verification and complex interaction scenarios.

[0060] Against this backdrop, the timeliness requirements of the agile development model for testing processes have further exacerbated the contradiction. The continuous compression of development cycles and the rigid constraints of testing resources create a sharp conflict, making traditional manual test design methods unable to meet the dynamic quality assurance needs of modern software engineering. This efficiency bottleneck not only slows down testing progress but may also allow potential defects to escape due to testing blind spots, ultimately affecting the product's market competitiveness.

[0061] To address these challenges, the industry has proposed various automated test case generation solutions, achieving some breakthroughs in efficiency improvement and process automation. However, existing solutions still have significant shortcomings in areas such as domain adaptability, complex document processing, resource consumption, dynamic response, and quality assurance. The main reasons for this are: insufficient deep semantic understanding of unstructured, multimodal requirements by the models; a lack of dynamic optimization mechanisms for the test lifecycle within the automation framework; and insufficient knowledge reuse, failing to effectively utilize high-quality test case assets accumulated by the enterprise, leading to reinventing the wheel and a lack of consistency and reusability in the generated results.

[0062] To address the aforementioned issues, this application provides a test case generation method. This method obtains a structured requirements document and retrieves historical reference test cases from a historical test case library, providing high-quality input and knowledge guidance for the generated model. After initial test case generation, an automated verification process is introduced to obtain quality feedback. When the generated results do not meet preset quality conditions, the generation parameters (including retrieval conditions and model-side parameters) are dynamically adjusted and the test cases are regenerated. Through a closed-loop mechanism of "generation-verification-feedback-iteration," the quality of the test cases gradually converges to meet engineering standards until the preset quality conditions or the upper limit of the number of iterations are reached. This transforms test case generation from a one-time output into a quality-controllable iterative evolution process, effectively solving problems such as unstable test case generation quality, lack of dynamic optimization, and insufficient knowledge reuse in existing technologies.

[0063] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0064] It should be noted that the execution subject of the test case generation method provided in this application embodiment can be a test case generation device, which can be deployed on mobile phones, computers, servers or other electronic devices. This application embodiment does not impose any restrictions.

[0065] Figure 1 This is a flowchart illustrating a test case generation method provided in an embodiment of this application. Figure 1 As shown, the test case generation method provided in this application embodiment may include:

[0066] S101. Obtain the structured requirements document; wherein the structured requirements document includes at least one requirement unit to be used to generate test cases.

[0067] For example, a structured requirements document refers to a requirements description document organized according to a pre-defined format specification or data model. Compared with traditional natural language requirements documents, structured requirements documents have clear semantic unit divisions, facilitating subsequent retrieval and generation processing. This document can be stored in formats such as JSON (JavaScript Object Notation) and XML (Extensible Markup Language). Each requirement item must contain at least the following fields: functional module identifier, preconditions, operation steps, and expected results. A requirement unit refers to the smallest testable functional point extracted from the structured requirements document; each requirement unit corresponds to an independent test scenario. For example, the "user login" function can be broken down into multiple requirement units such as "normal login," "incorrect password login," and "account locked login."

[0068] In one specific embodiment of this application, when the user-provided requirement document is an unstructured requirement document, obtaining a structured requirement document can be achieved through the following methods: First, the user-uploaded original requirement document (such as PDF, Word, scanned copies, or other non-standardized formats) is received; then, multimodal content parsing technology is used to extract text, images, tables, and other information from the document; finally, a large language model fine-tuned in the requirements engineering domain is used to reorganize the parsed content into a structured requirement document in a unified format. By converting the non-standardized original requirement document into a structured standard document, not only can format noise and ambiguity be eliminated, but a high-quality semantic input foundation is also provided for subsequent retrieval and generation steps, significantly improving the accuracy and consistency of test case generation.

[0069] S102. Based on the structured requirements document, retrieve reference test cases from the historical test case library.

[0070] For example, a historical test case library refers to a collection of high-quality test cases accumulated over time within an enterprise or domain. Each test case includes at least metadata information such as test case name, preconditions, test steps, expected results, module to which it belongs, and test type. Reference test cases refer to standard test cases retrieved from the historical test case library that are semantically similar to the current requirement unit. They serve as generation templates, providing prior knowledge and a basis for generating the model.

[0071] When retrieving reference test cases, matching searches can be performed in the historical test case library based on features such as keywords, functional tags, and semantic similarity of the requirement unit to obtain historical test cases that are highly relevant to the current requirement as reference test cases.

[0072] S103. Input the structured requirements document and reference use cases into the generation model to generate test cases.

[0073] For example, the generative model of this application is a large language model fine-tuned from test case corpora. This model learns the mapping relationship from natural language requirements to structured test cases through a supervised fine-tuning (SFT) strategy. For example, the generative model can be a sequence-to-sequence model based on the Transformer architecture, a pre-trained language model, or other structured generative networks. This application embodiment does not impose any limitations. It can automatically generate test cases that conform to the specified format based on the input requirement description and reference test cases.

[0074] In one specific embodiment of this application, when generating test cases, the requirement units in the structured requirement document can be concatenated with the retrieved reference test cases to form prompt words containing requirement descriptions and example templates; then, the concatenated prompt words are input into the generation model; the generation model uses an attention mechanism to identify functional module boundaries, operation sequences and constraints in the requirement units, as well as structural paradigms and design logic in the reference test cases, and then outputs structured test cases.

[0075] By using reference use cases as contextual examples to guide the generation process, the output use cases are kept consistent with historical high-quality use cases in terms of format standardization, language style, and engineering applicability. This solves problems such as format confusion, logical omissions, and inconsistent terminology that may occur in the open generation process of large models.

[0076] S104. Verify the test cases and obtain quality feedback information.

[0077] For example, verification refers to the process of evaluating the quality of generated test cases, which typically includes one or more of the following: syntax verification, field integrity verification, logical consistency verification, and matching degree verification with the requirements document. This can include automated verification, manual review, and other methods. Quality feedback information refers to the information obtained during the verification process used to evaluate the quality of test cases, and can include quality scores, issue annotation information, etc.

[0078] Optionally, in one possible embodiment, verifying the test cases and obtaining quality feedback information may include:

[0079] S1. The automated verification module performs syntax consistency checks, logic conflict detection, and requirement traceability coverage analysis on test cases to generate quality scores.

[0080] S2. Verify the validity of test cases through manual review, revise the quality score, and mark the problem information;

[0081] S3. Use the revised quality score and problem information as quality feedback information.

[0082] For example, test cases can be subjected to multi-dimensional quality checks through an automated verification module. Syntax consistency checks verify the completeness and format compliance of test case fields, such as checking whether necessary fields like test case name, preconditions, test steps, and expected results are included. Logical conflict detection identifies contradictory test cases based on rule engines or knowledge graphs, such as multiple mutually exclusive outputs for the same input. Requirement traceability coverage analysis evaluates the coverage of test cases to the functional points of requirement units using a requirement traceability matrix, identifying uncovered test scenarios. In one specific implementation, structural integrity scores, semantic consistency scores, and requirement coverage scores can be obtained separately as quality scores; alternatively, reasonable weights can be pre-assigned to each dimension, scores can be given for each dimension during evaluation, and finally, a weighted summation is performed to calculate the total score as the comprehensive quality score; this application embodiment does not impose limitations.

[0083] Furthermore, the evaluation process and results of the automated verification module can be displayed to auditors for validity verification. For example, auditors can: confirm the accuracy of the automated scoring, choose to accept or reject the automated evaluation results, and correct unreasonable scores; they can also mark the types of problems existing in each test case, such as logical errors, incomplete coverage, missing steps, etc. Finally, the corrected quality scores and problem type information are used as quality feedback information for parameter adjustments in subsequent steps.

[0084] By combining automated verification with manual review, both verification efficiency and the accuracy and relevance of feedback were ensured. The revised quality scores and issue annotations also provided precise optimization directions for subsequent parameter adjustments.

[0085] S105. If the quality feedback information does not meet the preset quality conditions, the generation parameters are dynamically adjusted according to the quality feedback information, and the test cases are regenerated using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

[0086] For example, preset quality conditions are evaluation criteria pre-set for quality feedback information. These may include pre-set quality thresholds for each score, as well as other quality requirements. For instance, preset quality conditions may include: a quality score of 80 or higher, and no serious logical errors. Generation parameters refer to configurable parameters that affect the test case generation process, including search criteria and model-side parameters. Search criteria are parameters that affect the reference test case retrieval process, such as query vector weights, similarity thresholds, index types, and the number of reference test cases. Model-side parameters are parameters that affect the output of the generated model, such as prompt word templates, negative examples, correction instructions, and model parameters.

[0087] When the generated test cases are validated and the obtained quality feedback information meets the preset quality conditions (e.g., quality score ≥ 80 points), the iteration terminates and the current test case is output; or, when the number of iterations reaches the preset upper limit (e.g., 5 times), the iteration terminates and the current best test case is output. When the quality feedback information does not meet the preset quality conditions and the number of iterations has not reached the upper limit, the search conditions and / or model-side parameters can be dynamically adjusted based on the quality feedback information. For example, when the quality feedback information indicates that the test case has a low degree of matching with the requirements, the similarity threshold in the search conditions can be adjusted to expand or narrow the search scope and obtain more relevant or more diverse reference test cases; when the quality feedback information indicates that the test case is semantically ambiguous or logically inconsistent, the decoding strategy in the generation-side parameters can be adjusted to reduce the randomness of generation and enhance the determinism of the generated content; and so on. Then, the retrieval step S102 is re-executed using the adjusted retrieval conditions to obtain the updated reference test cases; using the adjusted model-side parameters, the structured requirements document and the updated reference test cases are input into the generation model, and the generation step S103 is re-executed to obtain new test cases; subsequently, the verification step S104 is re-executed to obtain new quality feedback information, and the above iterative process is repeated until the termination condition is met.

[0088] Through a closed-loop iterative mechanism of "generation-verification-feedback-adjustment-regeneration," continuous evolution of test case quality is achieved. Compared with existing technologies that "generate once" or "only adjust prompts," this application incorporates both search conditions and model-side parameters into a dynamic adjustment range, enabling the system to adaptively optimize search and generation strategies based on verification feedback. In particular, the "feedback-driven re-search" mechanism creates deep synergy between retrieval and generation, significantly improving the completeness, accuracy, and executability of the final output test cases and effectively suppressing the "illusion" problem. Through the closed-loop generation and optimization of test cases, the generation strategy can be adaptively adjusted based on quality assessment results during the generation process, significantly improving the quality of the final test cases.

[0089] The test case generation method provided in this application, by constructing a closed-loop mechanism of "generation-verification-feedback-iteration", achieves continuous optimization and controllable convergence of test case quality, significantly improving the completeness, accuracy and engineering usability of the generated results. At the same time, it reduces the risk of model illusion by using knowledge guidance from historical reference test cases, enhances the system's adaptability by dynamically adjusting the generation parameters, and effectively balances quality improvement and resource consumption by setting an upper limit on the number of iterations, thereby improving the efficiency of automated generation while ensuring high-quality output of test cases.

[0090] For example, Figure 2 This is a flowchart illustrating a process for generating test cases, provided as an embodiment of this application. Figure 2As shown, the complete processing flow from non-standard requirements documents to high-quality test cases includes: First, through the document preprocessing and standardization module, non-standard documents such as PDF and Word are parsed, optical character recognition (OCR) is performed, and tables are extracted. Semantic cleaning and segmentation are also performed to transform the original documents into well-structured standard requirements documents. Then, the test case generation and optimization module is entered. Retrieval-Augmented Generation (RAG) technology is used to retrieve standard test cases from the historical test case library as templates. Combined with a fine-tuned Large Language Model (LLM), preliminary test cases are generated. Then, through the Generate-Feedback-Optimize-Verify (GFOV) closed-loop iterative mechanism, the test cases are continuously optimized, and finally, a high-quality test case set that can be directly used in engineering practice is output.

[0091] Figure 3 This is a schematic diagram of the architecture of a test case generation system based on a large model, provided as an embodiment of this application. For example... Figure 3 As shown, this large-scale model-based test case generation system comprises an access layer, a functional module layer, and a service layer. The access layer provides visual interfaces for managing original requirement documents, standard requirement documents, excellent test case libraries, and test cases, supporting interaction between testers and the system. The functional module layer handles core business logic, including standardizing original requirements to generate standard requirements, maintaining an excellent test case library categorized by business, and annotating the validity and results of test cases generated by the AI ​​model. It also integrates AI model prompt word management and data statistics management modules to ensure real-time data synchronization across all stages. The service layer provides unified basic services such as login authentication, permission authentication, and data authentication, ensuring system security and data isolation. The overall architecture reflects a collaborative design philosophy between humans and AI models. Testers can review and correct key points such as standard requirement generation and test case validity annotation, thereby driving the large-scale model to continuously optimize generation quality through a feedback mechanism.

[0092] Combination Figure 2 and Figure 3 This application also provides another method for generating test cases. For example, Figure 4This is a flowchart illustrating another test case generation method provided in this application embodiment. Based on the aforementioned embodiments, this embodiment further addresses the problem that unstructured or semi-structured requirement documents (such as product requirement documents, user feedback screenshots, and mixed-format requirement specifications) are difficult for the test case generation model to understand directly, and improves the recall accuracy and efficiency of reference test cases through an optimized multi-level retrieval mechanism. Figure 4 As shown, the test case generation method provided in this application embodiment may include:

[0093] S401. Obtain the initial requirements document.

[0094] For example, an initial requirements document refers to the original requirements description file uploaded by the user. It is usually in an unstructured or semi-structured form, and the format may include PDF, Word, plain text, scanned image, Excel with tables, etc. Its content organization does not conform to the preset fixed data model or format specifications. For example, the initial requirements document includes, but is not limited to, at least one of the following forms of content: text (such as natural language paragraphs, lists, etc.), images (such as interface prototype diagrams, flowcharts, hand-drawn sketches, etc.), and tables (such as data dictionaries, business rule matrices, etc.).

[0095] The test case generation device can receive one or more initial requirement documents uploaded by users through a front-end interface or Application Programming Interface (API). It can also record metadata such as the document's source information (e.g., business team, project name), business category (e.g., financial transactions, user management, report statistics), and access permissions for subsequent data management and analysis. By supporting direct upload of documents in multiple formats, it lowers the barrier to entry for users, eliminating the need for manual pre-conversion of requirement documents to specific formats, thus adapting to the diverse document formats prevalent in enterprise operations.

[0096] S402. Perform multimodal content parsing on the initial requirements document to obtain the parsed content; wherein, multimodal content parsing includes at least one of the following: layout analysis and hierarchical structure recognition for text content, optical character recognition and image segmentation for image content, and structure recognition for table content.

[0097] For example, multimodal content parsing refers to the technology of comprehensively parsing documents containing multiple modalities of information such as text, images, and tables. This step aims to convert messy unstructured input into a machine-understandable structured intermediate representation. In the embodiments of this application, different processing strategies are adopted for different types of content to convert heterogeneous information in the original document into unified text or structured data that can be recognized by subsequent semantic processing modules. For example, layout analysis and hierarchical structure recognition of text content can be performed by: using the text position information after optical character recognition, or directly analyzing the paragraph attributes of rich text documents (such as PDF and Word), identifying blocks such as titles, body text, lists, and annotations, and restoring the hierarchical structure of the document through indentation, font size, numbering patterns, etc., to provide boundary basis for subsequent semantic segmentation. Optical character recognition and image segmentation of image content can be performed by: using OCR technology to recognize the text regions in the image as editable text; and combining image segmentation algorithms to separate the text regions in the image from non-text regions such as charts and illustrations to avoid noise interference. Structure recognition of table content can be achieved by detecting features such as row and column lines and cell merging relationships, converting the table content into structured data (such as JSON or CSV format), and preserving the correspondence between table headers and cells. The result of the above parsing process is collectively referred to as the parsed content. It retains the core semantics of the original document, eliminates formatting noise, and is presented in a uniform, location-labeled text or structured data format.

[0098] This application utilizes multimodal content parsing to accurately extract semantic information from non-standardized documents such as scanned documents, Word documents with images, and complex tables, eliminating the impact of format noise on subsequent processing. Compared to existing technologies that only support plain text input, this method significantly enhances its adaptability to the diversity of documents in real-world business scenarios.

[0099] S403. Perform semantic segmentation and cleaning on the parsed content to generate a structured requirements document.

[0100] For example, semantic segmentation refers to dividing continuous parsed content into independent and complete requirement units based on natural language understanding technology. Segmentation criteria may include: semantic integrity (e.g., a complete functional description), document hierarchy markers (e.g., content under a third-level heading), or preset granularity requirements (e.g., each business rule is a separate segment). Cleaning refers to removing redundant information (e.g., repeated explanatory text), irrelevant noise (e.g., headers, footers, annotations), and formatting tags from the segmented content, and standardizing terminology (e.g., replacing synonyms with standard terms). In one specific embodiment of this application, after semantic segmentation and cleaning of the parsed content, the resulting semantic fragments can be input into a large language model fine-tuned by the requirements engineering domain, where the model performs structured reorganization according to preset field templates. For example, the model transforms the natural language description "After the user clicks the login button and enters the correct username and password, they should be successfully redirected to the homepage" into structured entries containing "Functional Module: User Login", "Preconditions: User has registered", "Operation Steps: 1. Enter username; 2. Enter password; 3. Click login", and "Expected Result: Redirect to homepage". All the reorganized entries are compiled into a structured requirements document.

[0101] By employing semantic segmentation and structured reorganization, this application transforms unstructured raw requirements into a standard format that can be efficiently processed by computers, eliminating ambiguity and format noise, and providing high-quality input for subsequent retrieval and generation steps. Simultaneously, the unified structured fields enable independent retrieval and generation of requirement units, improving the system's flexibility and maintainability.

[0102] Optionally, in one possible embodiment, after generating the structured requirements document, the method of this application embodiment may further include: receiving a reviewer's correction operation on the structured requirements document, and using the corrected structured requirements document as the final structured requirements document; wherein the correction operation includes at least one of error correction, content supplementation, and redundancy deletion.

[0103] For example, in practical applications, although structured requirement documents can be automatically generated through multimodal content parsing and semantic reorganization, the automatically generated structured documents may still contain a few errors or omissions because the original requirement documents may contain highly ambiguous, unclear, or unconventional expressions. Therefore, this application also provides an optional manual review and correction mechanism to ensure the quality of input entering the subsequent retrieval and generation stages.

[0104] Specifically, the test case generation device can present automatically generated structured requirements documents to reviewers through a visual interface (such as a web form, JSON editor, or preview). Each requirement unit and its fields (functional module, preconditions, operation steps, expected results, and constraints) in the document can be edited individually. Reviewers can inspect the structured requirements document using the visual interface and perform corrections using the system's editing tools. For example, if a functional module is incorrectly categorized, the module name can be directly modified or a new business category can be selected; if the precondition description is inaccurate, the text content can be edited; if operation steps are missing, new steps can be inserted; if the expected result does not match the requirements, the expected result can be corrected; if redundant or duplicate content is found, the corresponding entries can be deleted; if the scoring is unreasonable, the score can be modified; and so on. The system records detailed logs of each correction operation in real time, including the operator, operation time, and a comparison of the content before and after the modification. After completing the correction, the reviewer clicks the "Confirm" or "Submit" button, making the corrected document the final structured requirements document, replacing the original automatically generated version, and passing it to the subsequent retrieval and generation model. If the reviewer deems the document requires no modifications, they can directly approve it.

[0105] This optional embodiment, by introducing a manual review and correction mechanism, can capture semantic ambiguities or logical errors that are difficult to eliminate during the automatic generation process, ensuring that the structured requirements documents entering subsequent stages are accurate, complete, and free of redundancy, thereby fundamentally improving the accuracy of test case generation. For extremely complex non-standardized documents, automatic processing may fail, and manual review also provides an effective fallback solution, ensuring the applicability of the method in various real-world scenarios.

[0106] S404. Using the requirement units in the structured requirement document as the query, perform similarity matching and filtering through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library; wherein, the multi-level index includes semantic vector index, tag inverted index and module classification index; the reference test cases carry boundary condition handling methods and / or abnormal path design logic.

[0107] For example, using semantic vector indexing requires pre-converting each test case and its associated requirements in the historical test case library into a high-dimensional semantic vector using a semantic encoding model, and then building a vector database. During retrieval, the current requirement unit is also converted into a vector, and the top-K test cases that are semantically closest to the current requirement are recalled by calculating cosine similarity or inner product. This index excels at capturing implicit semantic relevance, such as the similarity between "login" and "authentication".

[0108] A tag-based inverted index refers to a historical test case library where each test case is pre-labeled with a business tag (such as "payment," "security," or "performance"), a test type tag (such as "functional test" or "boundary test"), or a priority tag. The system builds an inverted list from tags to test case IDs. During retrieval, explicit or implicit tags are extracted from the current requirement unit (e.g., through rule matching or classification models), and the inverted index is used to quickly locate all test cases with the same tag. This index ensures that the type of retrieved results matches expectations, such as mandating reference to "security" test cases.

[0109] Module classification indexes categorize historical use cases according to the module tree of the software system. During retrieval, the functional module to which the current requirement unit belongs is first identified (this can be inferred from chapter paths or classification models in the requirements document), and then a limited search is performed within the same module, its parent modules, and its child modules. This index leverages the stability of architectural knowledge to avoid introducing irrelevant use cases across modules.

[0110] For example, Figure 5 This is a flowchart illustrating a multi-level indexing mechanism provided in an embodiment of this application. Figure 5 As shown, the standard test case recall mechanism based on Retrieval Enhanced Generation (RAG) in this application may include: using requirement units in a structured requirement document as query input, encoding them into query vectors through a text embedding model, performing similarity matching in a vector database using semantic vector indexes, and combining test cases and their function slice information stored in a relational database, using a multi-level indexing mechanism (including tag inverted index and module classification index) to achieve fine-grained retrieval, and after similarity matching and re-ranking, finally recalling multiple standard test cases with the most similar semantics as generation templates, providing structural paradigms and contextual semantic guidance for large models, thereby improving the standardization and reusability of generated test cases.

[0111] Combination Figure 5 As shown, in one embodiment of this application, the semantic vector index is deployed in a vector database to store vectorized representations of historical test cases and their associated requirement units. It can also store function slice vectors to support code-level semantic retrieval. The tag inverted index and module classification index are deployed in a relational database to store structured metadata of test cases (such as test type, priority, business category, functional module path, etc.). During retrieval, the business scope is first limited by the module classification index in the relational database, then the semantic vector index in the vector database is used for approximate nearest neighbor search, and finally the tag inverted index in the relational database is used to filter and reorder the retrieved results, achieving collaborative work between heterogeneous databases.

[0112] The retrieval process employs a multi-level indexing mechanism (semantic vector index + module classification index + tag inverted index), ensuring both accurate semantic matching and rapid localization and precise filtering. The retrieved reference use cases not only provide structural paradigms but also carry deeper semantic information such as boundary condition handling methods and abnormal path design logic, providing high-quality template guidance for subsequent generation steps and effectively suppressing the "illusion" phenomenon of large models. Compared to single-vector retrieval, this mechanism can more effectively handle technical terms, synonyms, and cross-module reuse scenarios in requirements.

[0113] Optionally, in one possible embodiment, using requirement units in the structured requirement document as the query, and performing similarity matching and filtering through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library, may include:

[0114] S10. Encode the requirement units in the structured requirement document into query vectors; wherein, the requirement unit shall at least include a functional module identifier, an operation step description, and an expected result;

[0115] S20. Based on the functional module identifier, determine the retrieval scope in the historical test case library through the module classification index;

[0116] S30. Based on the query vector, search within the retrieval range using the semantic vector index to determine the candidate use case set;

[0117] S40. Filter and reorder the candidate use case set using the label inverted index to obtain reference use cases.

[0118] For example, the test case generation device first extracts the current requirement unit to be processed from the structured requirement document. Each requirement unit contains at least three key fields: functional module identifier (e.g., "user login"), operation step description (e.g., "enter username and password and click login"), and expected result (e.g., "redirect to homepage"). These fields are then concatenated into a short text and mapped to a high-dimensional semantic vector, called a query vector, using a pre-trained text embedding model. This vector captures the semantic meaning of the requirement unit, providing a numerical basis for subsequent similarity calculations.

[0119] Furthermore, the test case generation device extracts the functional module identifier (e.g., "login authentication") from the requirement unit based on the pre-established module classification index of the historical test case library. Using this index, it quickly locates the set of use cases related to that module in the library, narrowing the search scope from the entire library to a specific business domain. For example, it only searches for use cases under the "login authentication" module, ignoring other modules such as "report export" and "permission management," thus significantly reducing the size of the candidate set for subsequent calculations. Within the search scope determined in step S20, a pre-built semantic vector index (e.g., an approximate nearest neighbor index based on a preset Inverted File Index (IVF) algorithm) is used to perform a similarity search. Using the query vector generated in step S10 as input, the index quickly returns the Top-K use cases (K can be 10 or 20, etc.) that are semantically most similar to the vector. These use cases are called the candidate use case set to ensure that the recalled use cases are highly semantically relevant to the current requirement. Finally, based on the characteristics of the current requirement unit (e.g., the need for boundary testing scenarios) or feedback from the previous round of verification, an inverted index is used to quickly filter out test cases in the candidate test case set that do not meet the label conditions. The remaining test cases are then reordered: test cases with higher label matching and better fit for the current requirements are ranked first. Ultimately, the Top-M (M is usually 3 or 5, etc.) are selected as the reference test cases generated this time.

[0120] This optional embodiment first limits the retrieval scope to relevant business domains through a module classification index, avoiding global searches and significantly reducing computational overhead. Then, a semantic vector index ensures that the recalled test cases and requirements are highly similar in content meaning, rather than just keyword matching. Finally, a tag-based inverted index further filters and reorders based on metadata, ensuring that the test type, priority, and other attributes of the final reference test cases meet the requirements of the current scenario. The three-level indexes are independent of each other and their weights can be added, deleted, or adjusted according to the actual application scenario, providing good configurability.

[0121] Optionally, in one possible embodiment, the method provided in this application may further include:

[0122] S50. When the number of test cases in the historical test case library for the business domain to which the structured requirements document belongs is lower than a preset threshold, based on the semantic similarity between business domains, the associated business domains corresponding to the business domain to which the structured requirements document belongs are retrieved from the preset domain knowledge graph; wherein, the preset domain knowledge graph is used to store the semantic association relationships between functional modules of different business domains; the semantic association relationships include semantic similarity;

[0123] S60. Use the test cases corresponding to the related business domain as migration test cases, and perform term mapping and structure alignment on the migration test cases to generate candidate test cases that adapt to the business domain to which the structured requirements document belongs.

[0124] For example, in practical applications, newly launched projects or business areas may lack sufficient historical test case accumulation (e.g., entirely new product lines or niche businesses). In this case, directly using the main process retrieval of this application may fail to retrieve high-quality reference templates due to the insufficient number of relevant test cases in the historical test case library. To solve this "cold start" problem, this application provides an optional cross-domain knowledge transfer mechanism.

[0125] Specifically, the process first determines whether the number of test cases in the historical test case library for the business domain to which the current structured requirements document belongs is below a preset threshold (e.g., 50). If it is below the threshold, the migration process is triggered: using the business domain as the query, a pre-built domain knowledge graph is retrieved. This graph pre-stores the semantic relationships between functional modules in different business domains (e.g., "financial transfer" and "e-commerce payment" have high similarity). The test case generation device can find one or more related business domains whose semantic similarity to the current domain meets preset conditions (e.g., the highest). Then, the corresponding test cases in the related business domains can be used as migration test cases, and terminology mapping and structural alignment are performed on them, and the test case field format is unified to the standard structure of the target business domain. The aligned test cases can then be used as candidate test cases to participate in subsequent reference template retrieval or directly as generation examples.

[0126] This optional embodiment effectively solves the cold start problem by introducing cross-domain knowledge transfer based on a domain knowledge graph. It allows new business domains to quickly start test case generation by leveraging historical assets from similar domains, eliminating the need to accumulate test cases from scratch and significantly shortening the preparation cycle. Furthermore, even when test cases are sparse in the target domain, the migrated test cases still provide a standardized structure and design logic, avoiding the "illusion" or format chaos caused by a lack of templates, thus significantly improving generation quality. Simultaneously, the system automatically completes domain adaptation, eliminating the need for manual writing of numerous example test cases for the new domain, significantly reducing labor costs. Moreover, the knowledge graph and mapping rules can be continuously enriched as business develops, forming an enterprise-level test knowledge asset library, enabling continuous knowledge accumulation and reuse across projects and domains. This mechanism effectively utilizes the enterprise's cross-domain test knowledge assets, ensuring the guiding quality of test case generation even when historical test cases are sparse.

[0127] S405. Input the structured requirements document and reference use cases into the generated model to generate test cases.

[0128] It should be noted that the specific implementation of step S405 is similar to that of step S103, and will not be elaborated here. In short, the current requirement unit in the structured requirement document is concatenated with the reference use case retrieved in S404 to form a prompt word containing requirement description and example template. This prompt word is then input into a domain-adapted generative model (such as a large language model based on Transformer), and the model can output structured test cases.

[0129] S406. Verify the test cases and obtain quality feedback information.

[0130] It should be noted that the specific implementation of step S406 is similar to that of step S104, and will not be repeated here. Understandably, verification may include automated verification (syntax checking, logical conflict detection, coverage analysis) and / or manual review (correcting scores, annotating issues), ultimately obtaining quality feedback information.

[0131] S407. Determine whether the quality feedback information meets the preset quality conditions and whether the number of iterations has reached the upper limit.

[0132] If yes, proceed to step S408; otherwise, proceed to step S409.

[0133] For example, based on the aforementioned quality feedback information, it is determined whether the preset quality conditions are met. If met, the process jumps to S408 to output the current test case; if not, it further determines whether the current iteration count has reached the preset upper limit. If the upper limit has been reached, even if the quality is substandard, the process jumps to S408 to output the current best test case (with a quality warning if necessary); if the upper limit has not been reached, the process jumps to S409 to adjust the parameters. By setting a quality threshold and an iteration upper limit, this application ensures both output quality and algorithm convergence and response time, avoiding system resource exhaustion due to repeated iterations.

[0134] S408, Output test cases.

[0135] For example, when the termination conditions are met (quality meets the target or the maximum number of iterations is reached), the final generated test cases are output in a user-specified format (such as Excel, JSON, XML, or directly displayed on the web interface). Furthermore, the generation process, iteration history, and quality score of the test case can be recorded for subsequent analysis and auditing.

[0136] Optionally, when the output test cases meet the preset quality conditions, the test cases and their corresponding structured requirements documents can be stored in the historical test case library for subsequent retrieval and generation, so as to achieve knowledge reuse.

[0137] S409. Dynamically adjust the generated parameters based on quality feedback information; wherein, the generated parameters include search conditions and / or model-side parameters.

[0138] For example, the retrieval conditions in this step refer to the retrieval parameters used by the multi-level indexing mechanism in step S404, such as: semantic similarity threshold, weight coefficient of each index, recall number (Top-K value), search depth of module index (whether to search sub-modules), etc. Model-side parameters refer to parameters that affect the output results of the generated model, such as prompt word templates, negative examples, correction instructions, model parameters, etc.

[0139] Optionally, dynamically adjusting search criteria includes one or more of the following: modifying the weight or similarity threshold of the query vector, switching the index type or search field, and encoding the feedback information from the previous round of validation into additional query constraints. Dynamically adjusting model-side parameters includes one or more of the following: updating the prompt word template, introducing negative examples and correction instructions, adjusting the model parameters of the generative model, and switching the generative model.

[0140] For example, regarding search criteria, if the quality feedback indicates "insufficient coverage" (i.e., certain functionalities are not covered), the similarity threshold can be lowered to expand the recall scope, while increasing the weight of the "operation step description" field in the query vector to make the search focus more on operational details. If the quality feedback indicates "logical conflict" (such as incorrect order of generated use case steps), the "logical conflict type" can be encoded as an additional query constraint, such as adding the keyword "correct order" for filtering. When the quality feedback indicates "missing boundary value test," query constraints such as "boundary value," "critical value," and "equivalence class" can be automatically generated and added to the query vector or used as a tag filtering condition, so that the next round of retrieval can recall reference use cases containing boundary value design. If the quality feedback indicates "terminology inconsistency," the index type can be switched, such as prioritizing the use of tag inverted indexes to match standard terms.

[0141] Regarding model-side parameters, if the quality feedback indicates "missing steps" or "incorrect format," the prompt word template can be updated to add mandatory instructions, such as "ensure that the test steps include at least 3 steps" or "the expected result field must be included." If the quality feedback indicates "boundary conditions not considered," negative examples (such as "do not ignore null inputs") and correction instructions (such as "please add boundary value test scenarios") can be introduced into the prompt words. If the score in the quality feedback is low and there is no significant improvement after multiple iterations, the model parameters of the generative model can be adjusted to make the output more deterministic and conservative; or another generative model that has been fine-tuned with different corpora can be switched to.

[0142] After adjustment, the process returns to step S404 (or S405, depending on whether a re-retrieval is required), regenerates test cases using the new generation parameters, and executes the verification steps again, forming a closed loop. Unlike existing technologies that only adjust prompts or model parameters, this application also includes search conditions in the dynamic adjustment scope, realizing a "feedback-driven re-retrieval" mechanism. When the quality of generated test cases is insufficient, the retrieval strategy can be proactively corrected, recalling more suitable reference templates, thereby fundamentally improving the generation effect.

[0143] The test case generation method provided in this application introduces multimodal content parsing and semantic segmentation, enabling it to directly process non-standardized original requirement documents. Simultaneously, it leverages a multi-level indexing mechanism to achieve accurate and efficient reference test case retrieval, and combines a closed-loop iterative mechanism to dynamically adjust retrieval conditions and model-side parameters, continuously optimizing test case quality. Compared to existing technologies, this method achieves end-to-end automation from requirement documents of any format to high-quality test cases, eliminating the need for manual preprocessing or template writing, thus significantly improving efficiency. By retrieving the enterprise's historical test case library and fine-tuning the domain model, the generated test cases possess strong domain adaptability, conforming to the terminology and testing logic of specific business domains. The collaborative feedback between automated verification and manual review, along with multiple rounds of iterative optimization, ensures the completeness, accuracy, and executability of the output test cases, keeping quality under control. The dynamic re-retrieval mechanism continuously corrects the generation direction, effectively suppressing the illusion of generating invalid test cases from large models. Furthermore, this method fully utilizes the enterprise's accumulated testing assets, achieving knowledge reuse, avoiding reinventing the wheel, and significantly improving the consistency and maintainability of test cases.

[0144] For example, Figure 6 This is a flowchart illustrating the closed-loop iterative optimization process in a test case generation method provided in an embodiment of this application. Figure 6 As shown, the GFOV (Generate-Feedback-Optimize-Verify) closed-loop iterative optimization process can include: after inputting structured standard documents, obtaining reference test case templates by retrieving historical test cases through RAG, and combining them with updated prompt word templates, negative examples, and correction instructions to drive the large model to generate test cases; subsequently, LLM scores the generated test cases in multiple dimensions (such as syntax, logic, coverage, etc.), and uses the scores as feedback information; it is determined whether the condition of "score exceeding a preset threshold and iteration steps not reaching the upper limit" is met. If it is met, the final test cases are output through the verification stage; if not, the generation strategy is dynamically adjusted (such as updating prompt word templates, supplementing negative examples and correction instructions, etc.), and the RAG retrieval and generation process is retried to form a closed-loop iteration until the test case quality meets the standard or the maximum number of iterations is reached. This mechanism ensures the continuous optimization and quality convergence of test cases.

[0145] Furthermore, based on any of the above embodiments, the method provided in this application may further include:

[0146] S100: Control the execution of test cases in the automated execution environment. If the execution fails, obtain the execution log and failure information.

[0147] S200: Input test cases, execution logs, and failure information into the generation model, combine them with historical successful test case templates to locate and fix errors, generate fixed test cases, and re-execute the verification and iterative optimization steps.

[0148] For example, the method provided in this application may also include a self-repairing step for test cases. This step can be located outside the closed-loop iterative optimization process or work in conjunction with the main process. Specifically, after generating test cases through the aforementioned steps, the test cases can be controlled to actually run in an automated execution environment (such as a unit testing framework, interface testing platform, or UI automation tool). If the test case fails to execute (e.g., execution fails, script errors, or timeouts), execution logs and failure information can be automatically captured, including the failure location, error type, stack trace, and the difference between the actual output and the expected result. Subsequently, the original test cases, execution logs, and failure information are input into the generation model, while simultaneously retrieving historical successful test case templates (e.g., successful test cases that have passed testing under the same functional module) from the historical test case library that are similar to the current failure scenario. The generation model can use this information as context to analyze the reasons for failure (e.g., missing steps, incorrect data dependencies, inaccurate expected results), and then generate repaired test cases by referring to the structure and logic of the successful test case templates. The repaired test cases can re-enter the verification and iterative optimization steps in the main process of this application (e.g., ... Figure 4 (S406 to S409 in the original text) undergo automated verification and manual review again to ensure the quality of the repair.

[0149] The self-repair mechanism in this optional embodiment connects the generation and execution of test cases, forming a complete closed loop of "generation, execution, failure capture, error location, automatic repair, and re-verification," which greatly reduces the workload of manually locating and repairing test cases; it also improves the repair accuracy by utilizing historical successful experience; and as execution and repair data accumulate, the error prediction capability of the generation model will continue to improve, thereby continuously reducing the failure rate of subsequent generated test cases.

[0150] Figure 7 This is a schematic diagram of a test case generation device provided in an embodiment of this application. Figure 7 As shown, the test case generation device 70 provided in this application embodiment includes: a first processing unit 701, a second processing unit 702, a third processing unit 703, a fourth processing unit 704, and a fifth processing unit 705.

[0151] The first processing unit 701 is used to obtain a structured requirements document; wherein the structured requirements document includes at least one requirement unit to generate test cases;

[0152] The second processing unit 702 is used to retrieve reference test cases from the historical test case library based on the structured requirements document;

[0153] The third processing unit 703 is used to input the structured requirements document and reference use cases into the generation model to generate test cases;

[0154] The fourth processing unit 704 is used to verify test cases and obtain quality feedback information;

[0155] The fifth processing unit 705 is used to dynamically adjust the generation parameters according to the quality feedback information if the quality feedback information does not meet the preset quality conditions, and to regenerate test cases using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

[0156] In one possible embodiment, the fourth processing unit 704 is specifically used for:

[0157] The automated verification module performs syntax consistency checks, logic conflict detection, and requirement traceability coverage analysis on test cases to generate quality scores.

[0158] The validity of test cases is verified through manual review, the quality score is adjusted, and problem information is marked.

[0159] The revised quality score and issue information will be used as quality feedback information.

[0160] In one possible embodiment, dynamically adjusting the search conditions includes one or more of the following: modifying the weight or similarity threshold of the query vector, switching the index type or search field, and encoding the feedback information from the previous round of verification into additional query constraints.

[0161] Dynamically adjusting model-side parameters includes one or more of the following: updating prompt word templates, introducing negative examples and correction instructions, adjusting model parameters of the generated model, and switching the generated model.

[0162] In one possible embodiment, the second processing unit 702 is specifically used for:

[0163] Using the requirement units in the structured requirement document as query conditions, similarity matching and filtering are performed through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library. The multi-level index includes semantic vector index, tag inverted index, and module classification index. The reference test cases carry boundary condition handling methods and / or abnormal path design logic.

[0164] In one possible embodiment, the second processing unit 702 is specifically used for:

[0165] Encode the requirement units in the structured requirement document into query vectors; wherein, the requirement unit shall at least include a functional module identifier, an operation step description, and an expected result;

[0166] Using the module classification index, determine the retrieval scope corresponding to the functional module identifier from the historical test case library;

[0167] Based on the query vector, a set of candidate use cases is determined by searching within the retrieval scope using semantic vector indexing.

[0168] The candidate test case set is filtered and reordered using a tag-based inverted index to obtain reference test cases.

[0169] In one possible embodiment, the second processing unit 702 is further configured to:

[0170] When the number of test cases in the historical test case library for the business domain to which the structured requirements document belongs is lower than a preset threshold, the associated business domains corresponding to the business domain to which the structured requirements document belongs are retrieved from the preset domain knowledge graph based on the semantic similarity between business domains. The preset domain knowledge graph is used to store the semantic relationships between functional modules in different business domains, and the semantic relationships include semantic similarity.

[0171] Test cases corresponding to the relevant business domains are used as migration test cases. The migration test cases are then mapped in terms and aligned in structure to generate candidate test cases that fit the business domain to which the structured requirements document belongs.

[0172] In one possible embodiment, the first processing unit 701 is specifically used for:

[0173] Obtain the initial requirements document;

[0174] The initial requirements document is subjected to multimodal content parsing to obtain the parsed content; the multimodal content parsing includes at least one of the following: layout analysis and hierarchical structure recognition of text content, optical character recognition and image segmentation of image content, and structure recognition of table content.

[0175] The parsed content is semantically segmented and cleaned to generate a structured requirements document.

[0176] In one possible embodiment, the first processing unit 701 is further specifically used for:

[0177] The system receives revisions from reviewers to the structured requirements document and uses the revised document as the final structured requirements document. The revisions include at least one of error correction, content addition, and redundancy removal.

[0178] In one possible embodiment, the fifth processing unit 705 is specifically used for:

[0179] Control the execution of test cases in an automated execution environment; if execution fails, obtain the execution log and failure information.

[0180] The test cases, execution logs, and failure information are input into the generation model. Combined with historical successful test case templates, errors are located and fixed, and the fixed test cases are generated. The verification and iterative optimization steps are then re-executed.

[0181] The test case generation device provided in this embodiment is used to execute the technical solutions in any of the aforementioned method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0182] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the device 80 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0183] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0184] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0185] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0186] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0187] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0188] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0189] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0190] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0191] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0192] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0194] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0195] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a 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 a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0196] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0197] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A test case generation method, characterized in that, The method includes: Obtain a structured requirements document; wherein the structured requirements document includes at least one requirement unit to be used to generate test cases; Based on the structured requirements document, retrieve reference test cases from the historical test case library; Input the structured requirements document and the reference use cases into the generation model to generate test cases; The test cases are verified to obtain quality feedback information; If the quality feedback information does not meet the preset quality conditions, the generation parameters are dynamically adjusted based on the quality feedback information, and the test cases are regenerated using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

2. The method according to claim 1, characterized in that, The process of verifying the test cases and obtaining quality feedback information includes: The automated verification module performs syntax consistency checks, logic conflict detection, and requirement traceability coverage analysis on the test cases to generate quality scores. The test cases are validated through manual review, the quality scores are corrected, and problem information is marked. The revised quality score and the problem information are used as the quality feedback information.

3. The method according to claim 1, characterized in that, Dynamically adjusting the search conditions includes one or more of the following: modifying the weight or similarity threshold of the query vector, switching the index type or search field, and encoding the feedback information from the previous round of verification into additional query constraints; Dynamically adjusting the model-side parameters includes one or more of the following: updating the prompt word template, introducing negative examples and correction instructions, adjusting the model parameters of the generated model, and switching the generated model.

4. The method according to claim 1, characterized in that, The step of retrieving reference test cases from the historical test case library based on the structured requirements document includes: Using the requirement units in the structured requirement document as query conditions, similarity matching and filtering are performed through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library; wherein, the multi-level index includes semantic vector index, tag inverted index and module classification index; the reference test cases carry boundary condition handling methods and / or abnormal path design logic.

5. The method according to claim 4, characterized in that, The step of using requirement units in the structured requirement document as query conditions and performing similarity matching and filtering through a multi-level indexing mechanism to retrieve reference test cases from the historical test case library includes: The requirement units in the structured requirement document are encoded into query vectors; wherein, the requirement unit includes at least a functional module identifier, an operation step description, and an expected result; Using the module classification index, the retrieval range corresponding to the functional module identifier is determined from the historical test case library; Based on the query vector, the semantic vector index is used to search within the retrieval range to determine a set of candidate use cases; The candidate use case set is filtered and reordered using the inverted index of the tags to obtain the reference use case.

6. The method according to claim 5, characterized in that, The method further includes: When the number of test cases in the historical test case library for the business domain to which the structured requirement document belongs is lower than a preset threshold, the associated business domains corresponding to the business domain to which the structured requirement document belongs are retrieved from the preset domain knowledge graph based on the semantic similarity between business domains; wherein, the preset domain knowledge graph is used to store the semantic association relationships between functional modules of different business domains, and the semantic association relationships include semantic similarity; The test cases corresponding to the associated business domains are used as migration test cases, and terminology mapping and structure alignment are performed on the migration test cases to generate candidate test cases that are adapted to the business domain to which the structured requirements document belongs.

7. The method according to claim 1, characterized in that, The process of obtaining structured requirements documents includes: Obtain the initial requirements document; The initial requirements document is subjected to multimodal content parsing to obtain the parsed content; wherein, the multimodal content parsing includes at least one of the following: layout analysis and hierarchical structure recognition for text content, optical character recognition and image segmentation for image content, and structure recognition for table content; The parsed content is semantically segmented and cleaned to generate the structured requirements document.

8. The method according to claim 7, characterized in that, The method further includes: The system receives revisions from reviewers to the structured requirements document and uses the revised document as the final structured requirements document. The revisions include at least one of error correction, content addition, and redundancy removal.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Control the test cases to execute in an automated execution environment; if execution fails, obtain the execution log and failure information. The test cases, execution logs, and failure information are input into the generation model. Errors are located and fixed by combining historical successful test case templates, and the fixed test cases are generated. The verification and iterative optimization steps are then re-executed.

10. A test case generation device, characterized in that, The device includes: The first processing unit is used to obtain a structured requirements document; wherein the structured requirements document includes at least one requirement unit to generate test cases; The second processing unit is used to retrieve reference test cases from the historical test case library based on the structured requirements document; The third processing unit is used to input the structured requirements document and the reference use cases into the generation model to generate test cases; The fourth processing unit is used to verify the test cases and obtain quality feedback information. The fifth processing unit is used to dynamically adjust the generation parameters according to the quality feedback information if the quality feedback information does not meet the preset quality conditions, and to regenerate test cases using the adjusted generation parameters; wherein, the generation parameters include retrieval conditions and / or model-side parameters.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

Images