A test case batch generation and iterative self-repairing method based on large model agent
By using a large-scale intelligent model to clean and standardize requirement documents, test cases are generated and optimized. This solves the problems of difficulty in global understanding and insufficient test case generation caused by fragmented requirements, and achieves efficient test case generation and defect management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FAZHENG INTELLIGENT TECH CO LTD
- Filing Date
- 2026-05-13
- Publication Date
- 2026-06-12
AI Technical Summary
In requirements management and testing engineering, existing technologies suffer from problems such as fragmented requirements leading to difficulties in global understanding, insufficient test case generation, and inefficient defect tracing. In particular, it is difficult to generate comprehensive and traceable test scenarios in large-scale, highly complex functional scenarios.
A large model intelligent agent is used to summarize and clean up requirement documents of multiple formats and versions, generate standardized product documents, and generate standardized test points based on various test case design methods. After executing the test cases, the requirement description is optimized through error inference algorithm to achieve iterative self-repair.
It enables a global understanding of requirements and batch generation of test cases, improves test scenario coverage and the ability to accurately trace defects, and supports continuous optimization and closed-loop feedback.
Smart Images
Figure CN122195860A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a method for batch generation and iterative self-repair of test cases based on large model intelligent agents. Background Technology
[0002] In the current era where the "intelligent agent" era has fully permeated the enterprise digital ecosystem, the evolution of artificial intelligence has entered a new stage driven by large-scale models. However, facing increasingly complex product systems and a rapidly iterating market pace, enterprises still face three key challenges in requirements management and test engineering practices: First, fragmented storage of requirements leads to difficulties in global understanding. Currently, product requirements are often maintained by multiple product managers in separate modules. During version iterations, there is a lack of a unified, structured expression mechanism. Original materials are scattered across meeting minutes, instant messages, prototype annotations, emails, or miscellaneous documents, resulting in inconsistent formats and fragmented semantics. Traditional methods relying on manual organization or static archiving cannot automatically extract and align business intents from different sources, making it difficult to build a coherent and traceable global semantic view of requirements. This leads to biases and even blind spots in the understanding of product logic by developers and testers.
[0003] Secondly, the generation of test cases in a single instance is limited by the quantity and insufficient context coverage. Existing rule-based or template-based test case generation methods, when faced with large-scale and highly complex functions, often produce only limited and superficial test scenarios due to limitations in the length of the input context or a lack of deep semantic reasoning capabilities. This makes it difficult to cover boundary conditions, abnormal paths, and multi-module interaction logic, resulting in insufficient test sufficiency and potential quality issues.
[0004] Third, there is a lack of effective tracing mechanisms for defects after test execution. When defects are discovered during test case execution, due to the lack of fine-grained semantic mapping between the original requirements and the test cases, defects are often difficult to trace back to specific business rules or user story levels, and it is even more difficult to automatically associate them with relevant requirement change history and context. This results in inefficient root cause analysis of defects, hindering closed-loop feedback and continuous optimization.
[0005] Therefore, under these conditions, how to provide a method for batch generation and iterative self-repair of test cases based on large model intelligent agents is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0006] In view of this, the present invention provides a method for batch generation and iterative self-repair of test cases based on large model intelligent agents, which solves the problems existing in the background technology.
[0007] To achieve the above objectives, the present invention provides the following technical solution: A method for batch generation and iterative self-repair of test cases based on large model intelligent agents includes the following steps: S1. Collect and upload multi-format, multi-version requirement documents of the same product to the large model agent, and input new requirements of existing products using a requirement matrix in a preset format. S2. The large model intelligent agent summarizes and cleans the business logic of the requirement document based on the prompt word engineering, divides the requirement document into multiple functional blocks according to the preset standard structure, and improves the content of each group. S3. Match the functional blocks with the product knowledge base, add new requirements that do not exist, and repeatedly identify and iteratively update existing requirements. S4. Based on the requirements and structural format, output standardized product documents; S5. Based on multiple test case design methods, standardized test points are generated for each functional block using prompt word engineering. S6. Generate functional test cases containing complete test parameters based on standardized test points and corresponding functional blocks; S7. Execute functional test cases and input the discovered defects into the large model agent in the specified format; S8. Combining error inference algorithms and prompt word engineering, defects are transformed into optimized requirement descriptions and updated to the product knowledge base to enable iterative generation of subsequent test cases.
[0008] Optionally, in S1, multi-format requirement documents include Word, Excel, TXT text, and clipboard text; for product iteration requirements, the product name, requirement description, and requirement change points are entered in a specified format to complete the requirement input.
[0009] Optionally, S2 specifically involves: using prompt word engineering to enable the large model agent to perform semantic understanding of the original requirement text, sorting out, cleaning and integrating scattered information, repetitive expressions and missing context content to form a complete product functional requirement description; and using prompt word engineering to break down the complete product functional requirement description into multiple independent functional blocks with sequential order and upstream and downstream influence nodes.
[0010] Optionally, S3 specifically involves: the large model agent parsing the demand matrix corresponding to new product or iterative demand, comparing it with the product knowledge base, and then performing demand addition or iterative update operations.
[0011] Optionally, in S4, standardized product documents include a product requirements specification, a product requirements specification, and a product operation manual. The product requirements specification records the product background and objectives, user profiles and scenarios, function list and priorities, business processes, acceptance criteria, and non-functional requirements. The product requirements specification records the interface prototype and interaction details, data model and field definitions, API interface specifications, state processes, error handling logic, technical constraints, and dependencies.
[0012] Optionally, in S5, test case design methods include scenario-based testing, equivalence class partitioning, boundary value analysis, cause-effect graphing, and state transition methods. Based on each method, test point descriptions in clear and logically rigorous single-sentence form are generated.
[0013] Optionally, S6 specifically involves: inputting standardized test points as user prompts and corresponding functional block descriptions as system prompts into the large model agent to generate complete functional test cases containing preconditions, operation steps, and expected results.
[0014] Optionally, S7 specifically involves: after executing the functional test cases, archiving the functional defects found during testing, and transmitting them to the large model agent in a specified format.
[0015] Optionally, S8 specifically involves: combining error inference algorithms as system prompts and archived functional defects as user prompts into the large model agent to optimize and reflect on the completeness and accuracy of the requirements, forming new requirement points and using them for subsequent test case iteration generation.
[0016] As can be seen from the above technical solutions, compared with the prior art, the present invention discloses a method for batch generation and iterative self-repair of test cases based on large model intelligent agents, which can effectively solve the problems of difficulty in global understanding caused by fragmented storage of requirements, insufficient test scenarios due to the one-time generation of test cases, and layered management of defects that occur after test case execution. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating the method for batch generation and iterative self-repair of test cases based on large model intelligent agents provided by the present invention. Detailed Implementation
[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0020] Example 1
[0021] This invention discloses a method for batch generation and iterative self-repair of test cases based on large model intelligent agents, such as... Figure 1 As shown, it includes the following steps: S1. Collect and upload multi-format, multi-version requirement documents of the same product to the large model agent, and input new requirements of existing products using a requirement matrix in a preset format. S2. The large model intelligent agent summarizes and cleans the business logic of the requirement document based on the prompt word engineering, divides the requirement document into multiple functional blocks according to the preset standard structure, and improves the content of each group. S3. Match the functional blocks with the product knowledge base, add new requirements that do not exist, and repeatedly identify and iteratively update existing requirements. S4. Based on the requirements and structural format, output standardized product documents; S5. Based on multiple test case design methods, standardized test points are generated for each functional block using prompt word engineering. S6. Generate functional test cases containing complete test parameters based on standardized test points and corresponding functional blocks; S7. Execute functional test cases and input the discovered defects into the large model agent in the specified format; S8. Combining error inference algorithms and prompt word engineering, defects are transformed into optimized requirement descriptions and updated to the product knowledge base to enable iterative generation of subsequent test cases.
[0022] For the same product, one or more product managers may be responsible for compiling requirements, resulting in various forms of requirement documents. Specifically, in S1 of this embodiment, multi-format requirement documents include Word, Excel, TXT text, clipboard text, screenshots, chat logs, etc. Users can upload files of all formats for the same product to the large model agent. For product iteration requirements, the requirement is input by specifying the product name, requirement description, and requirement change points in a specified format to complete the requirement input.
[0023] Different carrier formats require different description methods or formats, for example: The Word document describes it as follows: The login page of the "Project Management" product has two functions: one is to log in with an account, and the other is to log in with a password. Successful login will prompt "System login successful", and failed login will prompt "Account or password incorrect".
[0024] The table document describes the following columns: "Project Name", "Primary Function", "Secondary Function", "Business Logic", and "Exceptions". The first row of data in the table is "Project Management", "Login", "Account", "Enter account, check if it is correct and exists in the database, if the match is successful, log in to the system normally", "Account does not exist, prompt account or password is incorrect, system action: prohibit login to the system". The second row of data in the table is "Project Management", "Login", and "Password", "1. Enter password, check if it is correct and exists in the database, if the match is successful, log in to the system normally; 2. Password must be encrypted", "Password does not exist, prompt account or password is incorrect, system action: prohibit login to the system".
[0025] The TXT document describes it as follows: Accounts and passwords must be subject to mandatory verification. For example, the account and password cannot exceed 10 characters, the password must contain both uppercase and lowercase letters and numbers, and if the same account and password are entered incorrectly more than 5 times, login will be prohibited for 10 minutes. The requirements for account and password are the same in the personal registration and password modification functions.
[0026] Therefore, S2 in this embodiment specifically involves: using prompt word engineering to enable the large model agent to perform semantic understanding of the original requirement text, sorting, cleaning (including deduplication, merging, sorting, classification and grouping, etc.) and integrating scattered information, repetitive expressions and missing context content to form a complete product functional requirement description; using prompt word engineering, the complete product functional requirement description is split into multiple independent functional blocks with sequential order and upstream and downstream influence nodes.
[0027] In this process, the user uses prompt words with a specified structure as the role of an agent. The agent then rearranges and combines the input product requirement description, for example, given the format [Product Name][Primary Function][Secondary Function][Function Scope][Impact Scenarios][User Permissions]. The large model then fills in the specific content according to the new format. Product Name: Project Management - Primary Function: Login Page - Secondary functions: Username, Password - Functional scope: 1. Only when the username and password match exactly will you be allowed to enter the system. If either verification fails, you will not be able to log in and will be prompted with the message: "Incorrect username or password"; 2. The username and password must be at most 10 characters long. The password must be encrypted and must contain both uppercase and lowercase letters and numbers; 3. If the username or password is entered incorrectly more than 5 times, the same account will be prohibited from logging in for 10 minutes.
[0028] -Affected scenarios: Personal registration, password modification
[0029] -User permissions: All users
[0030] There are various methods for finding paths that affect the scene, but they all involve the following combinations: Current function 1 → Impact → Function 2, Function 1 → Impact → Function 1; Current function 1 → impact → function 2 and function 3, function 2 or function 3 → impact → function 1; Current Function 1 → Impact → Function 4, Function 4 → Impact → Function 5, Function 5 → Impact → Function 1.
[0031] The set of data generated in the above format is a functional block. The large model agent will continue to generate all functional blocks of this structure under the requirements understood in step 2.
[0032] Furthermore, in this embodiment, S3 specifically involves: the large model agent parsing the demand matrix corresponding to new product demand or iterative demand, comparing it with the product knowledge base, and then performing demand addition or iterative update operations.
[0033] Furthermore, in this embodiment, the S4 operation of structurally outputting standard documents is a branch of S3. After confirming that the document content is correct based on the standard requirement description stored in the product knowledge base, the user can export it according to the Product Requirements Document (PRD), Product Requirements Specification (SRS), or Product Operation Manual.
[0034] The standardized product documents include the Product Requirements Document (PRD), the Product Requirements Specification (SRS), and the Product Operation Manual. The PRD records the product background and objectives, user profiles and scenarios, function list and priorities, business processes, acceptance criteria, and non-functional requirements in plain text. The SRS records the interface prototype and interaction details, data models and field definitions, API interface specifications, state processes, error handling logic, technical constraints, and dependencies in a way that integrates programming language and business requirements.
[0035] Furthermore, in S5 of this embodiment, the test case design methods include scenario method, equivalence class partitioning method, boundary value analysis method, cause-effect graphing method, and state transition method. Based on each writing method, a clear and logically rigorous single-sentence test point description is generated. Each method uses prompt word engineering to strictly constrain the generation range and boundaries.
[0036] Specifically, each test case design method serves as the system prompt for the large model agent, and the functional block produced in step S2 serves as the user prompt for the large model agent. The combination of these two methods invokes the large model agent. Each standard method only contains the requirements analysis method and does not have the ability to directly generate relatively complete test cases that include preconditions, operational steps, and expected results. Therefore, it produces a one-sentence test point description that is fully understandable, has a clear subject, and a rigorous purpose. A more specific example is as follows: System prompt words [ #Role You are a test engineer proficient in {methods} #Target Business requirement extraction target #Scenario Analysis Capability Analyze the specific steps #Description Writing Guidelines A one-sentence writing guideline #limit Rules prohibiting crossing boundaries ] User prompt words [ {Step S2: Generate Function Block Description} ] Using the five independent methods described above, around one hundred test point descriptions can be generated for the same functional block requirement description. Finally, the test point outputs generated by each method are merged into one group for easy input in the next step.
[0037] Furthermore, in this embodiment, S6 specifically involves: inputting standardized test points as user prompts and corresponding functional block descriptions as system prompts into the large model agent to generate complete functional test cases containing preconditions, operation steps, and expected results.
[0038] Specifically, a complete set of test point descriptions generated in step S5 is extracted. Using prompt word engineering, each test point description is combined again with the functional blocks generated in step S2, and then fed into the large model agent to generate relatively complete test cases for each test point. A more specific example is as follows: System prompt words [ #Role You are a professional test engineer #Target Business requirement extraction target #Ability to write test cases - Read the user-provided requirement description - Read the user-provided test point description -Specify the writing conditions and content #Description Writing Guidelines Specifications for writing test cases #limit Rules prohibiting crossing boundaries ] User prompt words [ The requirement is described as follows: {Step S2 generates a function block description} The test point description is as follows: {Step S5 generates all test point descriptions} ]
[0039] Example 2
[0040] Based on Example 1, there exists such as Figure 1 The branching process shown includes the following steps when a new requirement is passed in: Specifying new requirements for products from the same source: When facing iterative requirements for the same product, users directly organize the product name, requirement description, and requirement change points into independent data using a specified format and input it into the large model agent for processing. This update will be executed as a historical project. If the product specified by this function block already exists in the product knowledge base, the description of the corresponding function block under that product will be updated directly. Since the updated content will inevitably have an affected node order, the original description will be directly overwritten, without needing to consider its specific differences from the original function block.
[0041] The subsequent process will follow the processing method after step S2 in Example 1.
[0042] Example 3
[0043] Based on Embodiment 1, the following is provided: Figure 1 The branching process shown is used to handle defects discovered after executing test cases, and includes the following steps: Step S7: After executing the functional test cases, archive the functional defects found during testing and input them into the large model agent in the specified format. In practice, this step is not limited by format requirements; any format of document can be stored as input, either ordered or unordered, and then input into the large model agent.
[0044] Step S8: Input the error inference algorithm as system prompt words and archived functional defects as user prompt words into the large model agent. Optimize and reflect on the completeness and accuracy of the requirements, forming new requirement points for subsequent test case iteration generation. This step focuses on prompt word engineering, applying the standardized test case writing method of the error inference algorithm to requirement optimization iteration. Specifically, it allows the large model to accurately identify missing, inaccurate, or insufficiently analyzed aspects of the requirements by analyzing the original requirements and current defects, and transforms these into supplementary or alternative updates to the product knowledge base.
[0045] The subsequent process will follow the processing method after step S3 in Example 1.
[0046] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0047] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for batch generation and iterative self-repair of test cases based on large-model intelligent agents, characterized in that, Includes the following steps: S1. Collect and upload multi-format, multi-version requirement documents of the same product to the large model agent, and input new requirements of existing products using a requirement matrix in a preset format. S2. The large model intelligent agent summarizes and cleans the business logic of the requirement document based on the prompt word engineering, divides the requirement document into multiple functional blocks according to the preset standard structure, and improves the content of each group. S3. Match the functional blocks with the product knowledge base, add new requirements that do not exist, and repeatedly identify and iteratively update existing requirements. S4. Based on the requirements and structural format, output standardized product documents; S5. Based on multiple test case design methods, standardized test points are generated for each functional block using prompt word engineering. S6. Generate functional test cases containing complete test parameters based on standardized test points and corresponding functional blocks; S7. Execute functional test cases and input the discovered defects into the large model agent in the specified format; S8. Combining error inference algorithms and prompt word engineering, defects are transformed into optimized requirement descriptions and updated to the product knowledge base to enable iterative generation of subsequent test cases.
2. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, In S1, multi-format requirement documents include Word, Excel, TXT text, and clipboard text; for product iteration requirements, the product name, requirement description, and requirement change points are entered in a specified format to complete the requirement input.
3. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, S2 specifically involves: using prompt word engineering to enable the large model agent to semantically understand the original requirement text, sorting out, cleaning and integrating scattered information, repetitive expressions and missing context to form a complete product functional requirement description; and using prompt word engineering to break down the complete product functional requirement description into multiple independent functional blocks with sequential order and upstream and downstream influence nodes.
4. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, S3 specifically involves: The large model agent parses the demand matrix corresponding to new product requirements or iterative requirements, compares it with the product knowledge base, and then performs the operation of adding or iteratively updating requirements.
5. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, In S4, standardized product documents include the Product Requirements Specification, the Product Requirements Specification, and the Product Operation Manual. The Product Requirements Specification records the product background and objectives, user profiles and scenarios, function list and priorities, business processes, acceptance criteria, and non-functional requirements. The Product Requirements Specification records the interface prototype and interaction details, data model and field definitions, API interface specifications, state processes, error handling logic, technical constraints, and dependencies.
6. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, In S5, test case design methods include scenario-based testing, equivalence class partitioning, boundary value analysis, cause-effect graphing, and state transition methods. Based on each method, test point descriptions are generated in clear and logically rigorous single-sentence form.
7. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, S6 specifically involves inputting standardized test points as user prompts and corresponding functional block descriptions as system prompts into a large model agent to generate complete functional test cases that include preconditions, operation steps, and expected results.
8. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, S7 specifically involves: after executing the functional test cases, archiving the functional defects found during testing, and transmitting them to the large model agent in a specified format.
9. The method for batch generation and iterative self-repair of test cases based on a large model intelligent agent according to claim 1, characterized in that, S8 specifically involves inputting a combination of error inference algorithms as system prompts and archived functional defects as user prompts into a large model agent. This process optimizes and reflects on the completeness and accuracy of the requirements, generating new requirement points for subsequent test case iterations.