Business test case automatic generation method based on knowledge enhancement large model

Abstract

The invention belongs to the field of intelligent testing of intelligent software engineering, and particularly relates to a business test case automatic generation method based on a knowledge enhancement large model, which comprises the following steps: S1, business knowledge system construction: document analysis and graph construction; s2, design document reconstruction: flow analysis and logic reconstruction are carried out; s3, knowledge enhancement large model training: incremental pre-training and instruction fine tuning; and step S4: test case generation and automatic inspection: test case generation, test case formatting and output, test case automatic inspection and deep business understanding: by constructing a knowledge enhancement large model, the large model can deeply understand the business background, the test case which is highly customized and closely fits the business logic is generated, and the business understanding efficiency is improved. And challenges of changeable business rules and special and precise domain knowledge can be effectively handled.

Description

A method for automatically generating business test cases based on a knowledge-enhanced large model Technical Field

[0001] This invention belongs to the field of intelligent testing in intelligent software engineering, and in particular relates to a method for automatically generating business test cases based on a knowledge-enhanced large model. Background Technology

[0002] As software systems become increasingly complex and large-scale, traditional test case generation methods face numerous challenges, such as insufficient test coverage, high test case maintenance costs, and strong design subjectivity. Detailed design documents for large-scale software systems are typically divided into multiple independent sections, including functional design, interface design, process design, and database design. Furthermore, key information such as business rule symbols, processing functions, and domain-specific terminology is often not explicitly explained in the specific design documents but is recorded in other specific documents or materials. This multi-source, heterogeneous document structure makes knowledge integration particularly difficult.

[0003] In the traditional test case generation process, the manual writing of test cases has revealed many drawbacks. Testers need to spend a lot of time and energy reviewing multiple design documents, and for less experienced testers, further research is often required to understand the business requirements. However, even so, manually written test cases still have many problems, such as strong subjectivity in test case design, difficulty in comprehensively covering all business scenarios and functionalities, resulting in insufficient test coverage; inconsistent quality of test cases, which may miss key test steps or expected results, affecting the effectiveness of the tests; and high maintenance costs due to frequent software system iterations.

[0004] While there are mature applications of generating test cases based on large language models in various industries, these cases are often limited to general scenarios and struggle to deeply adapt to the complex needs of specific businesses. Simply passing this information to the large model through simple context concatenation can easily lead to the loss of key information or semantic misunderstandings due to the model's inherent limitations in handling long contexts and establishing cross-document relationships. This makes it difficult to generate test cases that fit specific business logic, ultimately affecting the accuracy and completeness of the generated test cases. Currently, there is an urgent need for a method that can deeply integrate business knowledge, automatically combine multiple source documents, and generate high-quality test cases to address the challenges of changing business rules, specialized domain knowledge, and cross-document relationships. Summary of the Invention

[0005] This invention aims to solve the following technical problems:

[0006] (1) How to enable large models to deeply understand the business background and generate highly customized test cases that fit the business logic;

[0007] (2) How to effectively integrate scattered design documents and business tacit knowledge to ensure the accuracy and completeness of test cases.

[0008] This invention achieves intelligent generation and quality assurance of test cases by constructing a business knowledge graph, refactoring design documents into business logic pseudocode, training a knowledge-enhanced large-scale model, and introducing an automated verification mechanism. This method significantly improves test coverage and reduces human error and maintenance costs.

[0009] For scattered design documents and business tacit knowledge, they are categorized into common and non-common categories based on business experience. Common documents are parsed and transformed using parsing and conversion tools to extract effective data from common business assets, convert them into a unified code table format, and store them in a knowledge graph as common knowledge. Non-common documents are reconstructed into pseudocode based on specific document association logic, defined as business logic pseudocode, and presented in a structured and standardized manner, including conditional statements, loops, and function calls, thereby effectively integrating hidden knowledge and explicit rules.

[0010] For general-purpose large models that lack understanding of business operations, domain-specific business knowledge is incorporated through incremental pre-training and fine-tuning, enabling them to possess a deep understanding of vertical domain business logic. Fine-tuning data includes business education materials and common business design materials to ensure the model can capture subtle differences in business scenarios. Then, project test cases and corresponding business logic pseudocode are annotated, and fine-tuning is performed based on the annotated QA pairs and corresponding instructions. The resulting large model is defined as a knowledge-enhanced large model.

[0011] By refactoring the design documents to obtain pseudocode of business logic, which is then used as context input to a knowledge-enhanced model, and combined with corresponding prompt templates, the model is required to generate test cases. The model dynamically retrieves relevant business knowledge from the knowledge graph as supplementary explanations to generate test cases. After generation, the test cases are automatically validated using a rule engine and coverage analysis tools to ensure they comply with business rules and cover critical paths. Compared to directly inputting all design document content into the large model, this invention significantly reduces the complexity of the model processing extremely long contexts, enhances the correlation between cross-document information, and reduces comprehension biases.

[0012] A business knowledge base is built by combining a code table of business-specific terms, enabling the model to dynamically retrieve and reference key business terms, rules, and constraints. Simultaneously, through carefully designed prompt word templates and writing format rules, the large model is guided to generate structured and complete test cases based on refactored pseudocode and retrieved knowledge. The prompt word templates explicitly specify the elements of the test cases, such as test steps, expected results, and business rule verification points, ensuring that the output is highly consistent with the business context.

[0013] By integrating multi-dimensional knowledge, qualified test cases that meet business requirements can be generated efficiently, significantly improving the intelligence and practicality of software testing.

[0014] The technical solution of this invention:

[0015] A method for automatically generating business test cases based on a knowledge-enhanced large model, the specific steps of which are as follows:

[0016] Step S1: Building a Business Knowledge System: Common business documents (such as function descriptions and processing instructions) are parsed or manually annotated, converted to JSON format, and valid data is extracted to generate a code table. The code table includes fields for type, source, key, number of parameters, and value. Based on a preset graph pattern, the code table data is stored in a knowledge graph. Graph nodes include code table, key, and value; relationships include "contains" and "maps," where the "maps" relationship attribute includes the number of parameters.

[0017] Step S2: Design Document Reconstruction: On a project-by-project basis, analyze the program flow design document to obtain a list of triggering events, the main processing function of each event, and the list of functions it contains; then, on an event-by-event basis, traverse the function list of its main processing function, and replace each function and its parameters with the corresponding business description by querying the knowledge graph to form business logic pseudocode.

[0018] Step S3: Training the Knowledge-Enhanced Large Model: Using the business knowledge graph data constructed in Step S1 and various business education materials, a domain corpus is built. The general large language model (such as Qwen3-32B) is incrementally pre-trained to obtain a business knowledge-enhanced base model with deep business understanding capabilities. Then, on a project-by-project basis, a dataset is constructed consisting of business logic pseudocode (input), generation instructions (such as "write test cases based on the current logic pseudocode"), and corresponding test cases (output). The base model is fine-tuned with instructions to obtain a knowledge-enhanced large model that can generate test cases based on business logic.

[0019] Step S4: Test Case Generation and Automated Verification: Based on the knowledge-enhanced model obtained through two-stage fine-tuning in Step S3, input the business logic pseudocode and prompt word template into the knowledge-enhanced model to generate test case text. Use a format converter to fill the test cases into a project template (e.g., Excel), resulting in a final test case document that conforms to project specifications and can be directly used for test execution. An automated verification mechanism is introduced: a rule engine is used to verify the logical correctness of the test cases; coverage analysis tools are used to identify and highlight blind spots with insufficient coverage, guiding the supplementation and optimization of test cases.

[0020] Furthermore, step S1 specifically includes the following steps:

[0021] Document Parsing: Common business documentation is parsed into JSON format using a parsing tool. Different parsing tools are used for different document formats / styles. A conversion tool then transforms the valid data from the parsed / annotated JSON files into a code table and stores it in the knowledge graph. The code table columns include: Type (common), Source (filename of the knowledge source), Key (function name / parameter name), Number of Parameters (0 / 1 / 2 / …), Value (business description / explanation), and Parameter (index of the parameter to be called further).

[0022] The documentation for common business functions includes function documentation, processing documentation, and screen documentation.

[0023] The function documentation (which typically includes the function, parameters, and corresponding logical descriptions) requires special handling. The format and content of the function documentation are shown below.

[0024]

[0025] Taking the Func_TRN function as an example, the table information is manually converted into a logical description: "When parameter 1 is 0, migrate to parameter 2; otherwise, do nothing." To facilitate dynamic rendering of the business logic, this logic needs to be converted into a Jinja2 template format. The conversion result is as follows:

[0026] {% if param[0] == 0 %} Migrate to screen ID: {{}}{% endif %};

[0027] The information after conversion to the code table is shown below.

[0028]

[0029] The processing instruction document and screen description document need to be parsed and then converted. The format and content of the processing instruction document are shown below.

[0030]

[0031] The following JSON information was obtained using the parsing tool:

[0032] [{'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TAM', 'function_name': 'Taxpayer Management', 'Remarks': 'View and edit taxpayer information', 'processes_difference': {0: 'View', 1: 'Edit'}, {'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TIM', 'function_name': 'Tax Information Management', 'Remarks': 'View and update tax information', 'processes_difference': {0: 'View', 2: 'Update'}}

[0033] The valid information is converted into a code table using a conversion tool, as shown below.

[0034]

[0035] Knowledge graph construction: The schema of the knowledge graph is: Node [Code Table] -> Relationship (Contains) -> Node [KEY] -> Relationship (mapping) -> Node [VALUE]. The attributes of the Node [Code Table] include type (common) and source (the filename of the knowledge source); the attributes of the Node [KEY] include type (common), source (the filename of the knowledge source), and key / KEY (function name / parameter name); the attributes of the relationship (mapping) include the number of parameters (0 / 1 / 2 / …); the attributes of the Node [VALUE] include type (common), source (the filename of the knowledge source), value / VALUE (business description / explanation), and parameter (the index of the parameter to be called further). Both key / KEY and value / VALUE are name attributes in the graph, and KEY and VALUE are the node's label.

[0036] Based on the code table information obtained in step S1:

[0037]

[0038] Store the data in the knowledge graph according to the knowledge graph schema. Taking the first two rows of data as an example...

[0039] Node A [KEY]:

[0040] Name: "Func_TRN"

[0041] Type: "common"

[0042] Source: "Function Documentation"

[0043] Relationship [mapping]:

[0044] Param_num:2

[0045] Node B [VALUE]:

[0046] Name:” {% if param[0] == 0 %} Migrate to screen ID: {{}}{% endif %}”

[0047] Type: "common"

[0048] Source: "Function Documentation"

[0049] Furthermore, step S2 specifically includes the following steps:

[0050] Process analysis: On a project-by-project basis, analyze the program flow design document to obtain the list of triggering events, the main processing function of each event and the list of its contained functions;

[0051] The format and content of the program flow design document are shown below.

[0052]

[0053] Parsing the document yielded the following information:

[0054] List of events triggered by each process ([Event1, Event2, Event3, Event4], where each event corresponds to a "triggering action" + "interface element", for example, Event1 corresponds to "clicking the confirm button", Event2 represents "clicking the cancel button", and so on).

[0055] 1. Entry points for the main processing functions of each event (Event1 corresponds to the main processing function FuncMain_Confirm, Event2 corresponds to the main processing function FuncMain_Cancel, Event3 corresponds to the main processing function FuncMain_Delete, and Event4 corresponds to the main processing function FuncMain_Update).

[0056] 2. List of functions included in each processing function (FuncMain_Confirm: [validateUserInput(a,b), saveToDatabase(c), updateUI_Success()]; FuncMain_Cancel: [clearFormData(), navigateBack()]; FuncMain_Delete: [fetchTargetRecord(x), confirmDeletion(y), deleteFromDatabase(z), updateUI_Refresh()]; FuncMain_Update: [validateUserInput(a, b), fetchTargetRecord(x), updateDatabase(x, c), updateUI_Success()]).

[0057] Logical restructuring: Taking events as units, traverse the function list of their main processing functions, and replace each function and its parameters with the corresponding business description by querying the knowledge graph, forming business logic pseudocode.

[0058] Taking Event1 as an example. After locating its main processing function FuncMain_Confirm, iterate through all functions contained in FuncMain_Confirm [validateUserInput(a, b), saveToDatabase(c), updateUI_Success()] and begin refactoring: By retrieving the meaning / explanation of relevant functions / parameters in the knowledge graph, refactor all functions / parameters of symbol, letter, and number combinations into business descriptions; refactor all jump, call, judgment logic, and sequential execution business logic into pseudocode format. For example, retrieve the parameter explanation corresponding to the node named validateUserInput with 2 parameters in the knowledge graph, and retrieve the statement through the knowledge graph cypher:

[0059] ```cypher

[0060] MATCH (a {name: 'validateUserInput'})-[r]->(b)

[0061] WHERE r.parameter_num = 2

[0062] RETURN b.text

[0063] ```;

[0064] The following results were retrieved:

[0065] "Validate the validity of {parameter1} and {parameter2}. If the validation fails: proceed to the error handling process; otherwise: continue execution."

[0066] Next, the system sequentially retrieves the corresponding business meanings of parameters a and b in the knowledge graph, obtaining "username" and "password" respectively. Through string formatting operations, the placeholders {parameter1} and {parameter2} in the template are replaced with the specific meanings mentioned above, ultimately generating a precise business description: "Verify the validity of the username and password. If verification fails: proceed to the error handling process; otherwise: continue execution."

[0067] For the other functions within the main event handler, the above retrieval and reconstruction operations are repeated until all elements are converted into business descriptions. Ultimately, Event1 is reconstructed into the following business logic pseudocode:

[0068] # Event: Clicking the Confirm button (Event1)

[0069] # Main processing function: FuncMain_Confirm

[0070] start:

[0071] Step 1: Verify the validity of the username and password.

[0072] If verification fails:

[0073] Jump to error handling process

[0074] otherwise:

[0075] Continue with step 2

[0076] Step 2: Save the user-submitted form data to the database.

[0077] Step 3: Update the interface to display a successful operation status message.

[0078] Finish;

[0079] Furthermore, step S3 specifically includes the following steps:

[0080] Incremental pre-training: The JSON file obtained through parsing / annotation in step S1 is used as part of the incremental pre-training data. In addition, unstructured valuable business assets such as business education materials (e.g., product manuals, business training PPTs), videos (e.g., system operation tutorials), and audio (e.g., transcripts of business requirement review meetings) are converted into the following text description format using parsing tools (e.g., OCR, ASR speech recognition) combined with manual annotation and proofreading:

[0081] [

[0082] {"text": "document"},

[0083] {"text": "document"}

[0084] ];

[0085] The JSON data from all the aforementioned sources were mixed, cleaned, and deduplicated to construct a high-quality domain knowledge corpus. Using the content of this corpus (i.e., documents), the general-purpose model Qwen3-32B was incrementally pre-trained. At this stage, the training objective was to model standard language models, aiming to deeply integrate vertical domain business terminology, conceptual relationships, and business rule knowledge into the model's parameters, evolving the model from a "general-purpose model" into a "business-aware" business knowledge-enhanced foundation model.

[0086] Command fine-tuning: A command fine-tuning dataset is built on a project-by-project basis. The dataset construction process is as follows:

[0087] Input: Retrieves the pseudocode of the business logic obtained after the project's refactoring in step S2. For example, for the event "Click the Confirm button", the input is the refactored pseudocode of the business logic:

[0088] # Event: Clicking the Confirm button (Event1)

[0089] # Main processing function: FuncMain_Confirm

[0090] start:

[0091] Step 1: Verify the validity of the username and password entered by the user.

[0092] If verification fails:

[0093] Jump to error handling process

[0094] otherwise:

[0095] Continue with step 2

[0096] Step 2: Save the user-submitted form data to the database.

[0097] Step 3: Update the interface to display a successful operation status message.

[0098] Finish;

[0099] Instructions: Use a fixed prompt template, such as "Write test cases based on the current business logic pseudocode".

[0100] Output: Extract the test case content corresponding to the business logic from the project's historical test case design documents, including structured fields such as "Test Item / Content," "Test Method," and "Confirmation Method." For example, for the pseudocode above, the expected output is:

[0101] Test item: User login function - success process;

[0102] Test steps:

[0103] 1. Enter a valid username "testUser" in the username input box.

[0104] 2. Enter the valid password "password123" in the password input box.

[0105] 3. Click the "Confirm" button.

[0106] Expected results:

[0107] 1. The system successfully verified the username and password.

[0108] 2. User information is saved to the database.

[0109] 3. The interface redirects to a success page and displays a "Operation successful" message.

[0110] Confirmation methods: Check database records and check the content displayed on the interface;

[0111] Based on the constructed (instruction, input, output) dataset, the business knowledge enhancement foundation model obtained in step (3-1) undergoes instruction fine-tuning. The training objective at this stage is to enable the model to learn to follow the instruction of "generating test cases based on business logic pseudocode" and output test case text that conforms to project specifications and business requirements. Through this stage, the model further evolves from "understanding the business" to a knowledge-enhanced large-scale model that "can write test cases".

[0112] Furthermore, step S4 specifically includes the following steps:

[0113] Test case generation:

[0114] Based on the knowledge-enhanced large model obtained through two-stage fine-tuning in step S3, test cases are generated. The specific process is as follows:

[0115] Combine the pseudo-code of the business logic that needs to generate test cases (from step S2) with the optimized prompt template (e.g., "You are a senior test engineer. Please generate detailed test cases based on the following business logic, covering normal scenarios, abnormal scenarios, and boundary scenarios.") as input to the large model.

[0116] After receiving input, the model uses its inherent business knowledge and instruction-following capabilities to automatically generate structured test case text. The generated content typically includes the test objective, preconditions, test steps, expected results, and key elements of the test data.

[0117] Test case formatting and output:

[0118] A format converter automatically fills the text-based test cases generated from the large model into the corresponding fields (such as "Test Case Number", "Test Item", "Operation Steps", and "Expected Result" columns) in the test case design document template (such as an Excel spreadsheet) specified by the project, generating a final test case document that can be directly used for test execution and conforms to the project specifications.

[0119] Automatic test case verification:

[0120] To ensure the quality of generated test cases, an automated verification mechanism is introduced:

[0121] Rule engine verification: A business rule base is established, which defines core rules extracted from the business knowledge system (such as "passwords must contain numbers and letters" and "transaction amounts cannot be negative"). The rule engine scans the generated test cases one by one to verify whether their "expected results" and "test data" conflict with the constraints in the business rule base, thereby ensuring the logical correctness of the test cases.

[0122] Coverage Analysis: Using coverage analysis tools, the generated test cases are mapped back to the business logic pseudocode (considered as business scenario paths) refactored in step S2 or the actual code paths. Through analysis, the degree of coverage of test cases for key business scenarios, code branches (such as if-else statements), and function calls is calculated. This analysis is used to identify and highlight blind spots with insufficient coverage, guiding the supplementation and optimization of test cases.

[0123] Compared with the prior art, the present invention has the following advantages and effects:

[0124] 1. Deep Business Understanding: By constructing a knowledge-enhanced large model, this invention enables the large model to deeply understand the business context, generate highly customized test cases that closely fit the business logic, and effectively address the challenges of changing business rules and specialized domain knowledge.

[0125] 2. Document integration capability: The invention's design document reconstruction method can reconstruct scattered multi-source design documents into pseudocode, effectively integrating explicit rules and hidden knowledge, solving the problems of document dispersion and heterogeneity, reducing the complexity of model processing long contexts, enhancing the correlation of cross-document information, and reducing comprehension bias.

[0126] 3. Intelligent generation: Combined with customized prompt word templates, this invention can guide large models to generate test cases with standardized structure and complete content, significantly improving the intelligence level and practicality of software testing.

[0127] 4. Adaptability and scalability: The method of this invention has good adaptability and scalability, and can be customized according to the characteristics of different business fields. It can be widely used in multiple industries such as finance, healthcare, and communications, promoting the development and application of software testing technology.

[0128] 5. Efficiency and Reliability: Through a closed loop of three sub-steps—generation, formatting, and verification—the final output is a quality-verified test case document that can be directly used, significantly improving the efficiency and reliability of the testing phase. Attached Figure Description

[0129] Figure 1 shows the overall process of the automatic generation method for business test cases based on the knowledge-enhanced large model of the present invention.

[0130] Figure 2 is a flowchart of the business knowledge system construction stage in the business test case automatic generation method based on the knowledge-enhanced big model of the present invention.

[0131] Figure 3 is a flowchart of the design document reconstruction stage in the automatic generation method of business test cases based on the knowledge-enhanced big model of the present invention.

[0132] Figure 4 is a flowchart of the knowledge-enhanced large model training phase in the automatic generation method of business test cases based on the knowledge-enhanced large model of the present invention. Detailed Implementation

[0133] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. These embodiments are implemented based on the technical solution of the present invention, providing detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0134] As shown in Figure 1, the overall process of the method of this invention includes four major stages: knowledge system construction, design document reconstruction, model training, and test case generation and verification. The following uses the "Click Confirm Button" event (Event1) of the "User Login" function in "Project A" as an example to illustrate each step in detail with reference to the accompanying drawings.

[0135] Example: Test case generation based on project A:

[0136] As shown in Figure 2, the documentation for common business categories is parsed and annotated into JSON format using a parsing tool / manual annotation (manual annotation is required for extremely complex / highly specific formats, and no additional parsing tool is developed). The valid data in the JSON file is then converted into a code table and stored in the knowledge graph using a conversion tool.

[0137] The specific steps are as follows:

[0138] Document Parsing: Common business documentation is parsed into JSON format using parsing tools / manual annotation. Different parsing tools are used for different document formats / styles. A conversion tool then transforms the valid data from the parsed / annotated JSON files into a code table and stores it in the knowledge graph. The code table columns include: Type (common), Source (filename of the knowledge source), Key (function name / parameter name), Number of Parameters (0 / 1 / 2 / …), Value (business description / explanation), and Parameter (index of the parameter to be called).

[0139] The documentation for common business functions includes function documentation, processing documentation, and screen documentation.

[0140] The function documentation (which typically includes the function, parameters, and corresponding logical descriptions) requires special handling. The format and content of the function documentation are shown below.

[0141]

[0142] Taking the Func_TRN function as an example, the table information is manually converted into a logical description: "When parameter 1 is 0, migrate to parameter 2; otherwise, do nothing." To facilitate dynamic rendering of the business logic, this logic needs to be converted into a Jinja2 template format. The conversion result is as follows:

[0143] {% if param[0] == 0 %} Migrate to screen ID: {{}}{% endif %};

[0144] The information after conversion to the code table is shown below.

[0145]

[0146] The processing instruction document and screen description document need to be parsed and then converted. The format and content of the processing instruction document are shown below.

[0147]

[0148] The following JSON information was obtained using the parsing tool:

[0149] [{'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TAM', 'function_name': 'Taxpayer Management', 'Remarks': 'View and edit taxpayer information', 'processes_difference': {0: 'View', 1: 'Edit'}, {'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TIM', 'function_name': 'Tax Information Management', 'Remarks': 'View and update tax information', 'processes_difference': {0: 'View', 2: 'Update'}};

[0150] The valid information is converted into a code table using a conversion tool, as shown below.

[0151]

[0152] Knowledge graph construction: The schema of the knowledge graph is: Node [Code Table] -> Relationship (Contains) -> Node [KEY] -> Relationship (mapping) -> Node [VALUE]. The attributes of the Node [Code Table] include type (common) and source (the filename of the knowledge source); the attributes of the Node [KEY] include type (common), source (the filename of the knowledge source), and key / KEY (function name / parameter name); the attributes of the relationship (mapping) include the number of parameters (0 / 1 / 2 / …); the attributes of the Node [VALUE] include type (common), source (the filename of the knowledge source), value / VALUE (business description / explanation), and parameter (the index of the parameter to be called further). Both key / KEY and value / VALUE are name attributes in the graph, and KEY and VALUE are the node's label.

[0153] Based on the code table information obtained in step S1

[0154]

[0155] Store the data in the knowledge graph according to the knowledge graph schema. Taking the first two rows of data as an example...

[0156] Node A [KEY]:

[0157] Name: "Func_TRN"

[0158] Type: "common"

[0159] Source: "Function Documentation"

[0160] Relationship [mapping]:

[0161] Param_num:2

[0162] Node B [VALUE]:

[0163] Name:” {% if param[0] == 0 %} Migrate to screen ID: {{}}{% endif %}”

[0164] Type: "common"

[0165] Source: "Function Documentation"

[0166] (1) Construct the design documents of non-business common classes outside the program flow design documents into the knowledge graph in the same way as in step (1). On a project-by-project basis, parse the program flow design documents of each project to obtain the following information: ① list of trigger events for each process; ② main processing function entry for each event; ③ list of functions contained in each processing function.

[0167] The format and content of the program flow design document are shown below.

[0168]

[0169] Parsing the document yielded the following information:

[0170] ① List of events triggered by each process ([Event1, Event2, Event3, Event4], where each event corresponds to a "triggering action" + "interface element", for example, Event1 corresponds to "clicking the confirm button", Event2 represents "clicking the cancel button", and so on);

[0171] ②The main processing function entry points for each event (Event1 corresponds to the main processing function FuncMain_Confirm, Event2 corresponds to the main processing function FuncMain_Cancel, Event3 corresponds to the main processing function FuncMain_Delete, and Event4 corresponds to the main processing function FuncMain_Update).

[0172] ③ List of functions included in each processing function (FuncMain_Confirm: [validateUserInput(a,b), saveToDatabase(c), updateUI_Success()]; FuncMain_Cancel: [clearFormData(), navigateBack()]; FuncMain_Delete: [fetchTargetRecord(x), confirmDeletion(y), deleteFromDatabase(z), updateUI_Refresh()]; FuncMain_Update: [validateUserInput(a, b), fetchTargetRecord(x), updateDatabase(x, c), updateUI_Success()]).

[0173] Using the program flow design document as the primary refactoring object, as shown in Figure 3, the refactoring is performed on a per-flow trigger event basis. After locating the main processing function FuncMain_Confirm for the current event Event1 (clicking the confirmation button), the refactoring process begins by traversing all functions contained in FuncMain_Confirm [validateUserInput(a, b), saveToDatabase(c), updateUI_Success()]. The refactoring process for the function validateUserInput(a, b) is as follows: The refactoring process for the function validateUserInput(a, b) is as follows: (The refactoring process is described in the knowledge graph, where relevant functions validateUserInput, saveToDatabase, and updateUI_Success are retrieved.)

[0174] Retrieve the parameter explanation for the node named validateUserInput with 2 parameters in the knowledge graph using the Cypher search query:

[0175] ```cypher

[0176] MATCH (a {name: 'validateUserInput'})-[r]->(b)

[0177] WHERE r.parameter_num = 2

[0178] RETURN b.text

[0179] ```;

[0180] The following results were retrieved:

[0181] "Validate the validity of {parameter1} and {parameter2}. If the validation fails: proceed to the error handling process; otherwise: continue execution."

[0182] Next, the system sequentially retrieves the corresponding business meanings of parameters a and b in the knowledge graph, obtaining "username" and "password" respectively. Through string formatting operations, the placeholders {parameter1} and {parameter2} in the template are replaced with the specific meanings mentioned above, ultimately generating a precise business description: "Verify the validity of the username and password. If verification fails: proceed to the error handling process; otherwise: continue execution."

[0183] For the other functions within the main event handler, the above retrieval and reconstruction operations are repeated until all elements are converted into business descriptions. Ultimately, Event1 is reconstructed into the following business logic pseudocode:

[0184] # Event: Clicking the Confirm button (Event1);

[0185] # Main processing function: FuncMain_Confirm;

[0186] start:

[0187] Step 1: Verify the validity of the username and password.

[0188] If verification fails:

[0189] Jump to error handling process

[0190] otherwise:

[0191] Continue with step 2

[0192] Step 2: Save the user-submitted form data to the database.

[0193] Step 3: Update the interface to display a successful operation status message.

[0194] Finish;

[0195] (2) As shown in Figure 4, the JSON file obtained through parsing / annotation in step (1) is used as part of the incremental pre-training data. After processing, the following is obtained:

[0196] [

[0197] {"text": "{'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TAM', 'function_name':'Taxpayer Management', 'Remarks': 'View and edit taxpayer information', 'processes_difference':{0:'View', 1:'Edit'}"},

[0198] {"text": "{'process_code': 'TA001', 'process_name': 'Tax Management', 'function_code': 'TIM', 'function_name':'Tax Information Management', 'Remarks': 'View and Update Tax Information', 'processes_difference':{0:'View', 2:'Update'}"}

[0199] ];

[0200] In addition, valuable business assets such as business education materials, videos, and audio recordings are processed using parsing tools or manual annotation to obtain corresponding JSON format files.

[0201] For example, business training materials are generally in PPT format. To help newcomers in the project team understand business-related knowledge more intuitively, PPTs usually don't use long paragraphs of text, but rather images, legends, and diagrams to aid understanding. OCR technology can be used to assist in annotation, but the accuracy is not high. Considering that the amount of this type of data is relatively small and not frequently updated, manual annotation is used directly. For example, in the introduction to the tax system, PPTs usually use tree diagrams, which need to be converted into text descriptions and recorded in JSON format. After processing, we get: [{"text": "The tax system is a management system established by the state to realize the tax function. The system consists of the tax bureau, the Ministry of Finance, and the customs agency, and is responsible for the implementation of tax policies, collection supervision, and service optimization, etc."},{"text": "The main types of taxes include income tax, property tax, resource tax, behavior tax, and turnover tax."}]. All the above JSON files are used as fine-tuning data for incremental pre-training of the general large model Qwen3-32B.

[0207] For each project, the test items / contents, test methods, and confirmation methods in the test case design document are obtained as outputs. The business logic pseudocode obtained after the project is reconstructed in step (2) is obtained as input. The prompt "Write test cases based on the current logic pseudocode" is used as an instruction. An instruction fine-tuning dataset is constructed, and the large model after the first stage of fine-tuning is fine-tuned by instructions.

[0208] Input: Obtain the pseudocode of the business logic obtained after the project is refactored in step (2). For example, for the event "Click the Confirm Button", the input is the refactored pseudocode of the business logic:

[0209] # Event: Clicking the Confirm button (Event1)

[0210] # Main processing function: FuncMain_Confirm

[0211] start:

[0212] Step 1: Verify the validity of the username and password entered by the user.

[0213] If verification fails:

[0214] Jump to error handling process

[0215] otherwise:

[0216] Continue with step 2

[0217] Step 2: Save the user-submitted form data to the database.

[0218] Step 3: Update the interface to display a successful operation status message.

[0219] Finish;

[0220] Instructions: Use a fixed prompt template, such as "Write test cases based on the current business logic pseudocode".

[0221] Output: Extract the test case content corresponding to the business logic from the project's historical test case design documents, including structured fields such as "Test Item / Content," "Test Method," and "Confirmation Method." For example, for the pseudocode above, the expected output is:

[0222] Test Item: User Login Function - Success Process

[0223] Test steps:

[0224] 1. Enter a valid username "testUser" in the username input box.

[0225] 2. Enter the valid password "password123" in the password input box.

[0226] 3. Click the "Confirm" button.

[0227] Expected results:

[0228] 1. The system successfully verified the username and password.

[0229] 2. User information is saved to the database.

[0230] 3. The interface redirects to a success page and displays a "Operation successful" message.

[0231] Confirmation methods: Check database records and check the content displayed on the interface.

[0232] Based on the constructed (instruction, input, output) dataset, the business knowledge enhancement foundation model obtained in step (3-1) undergoes instruction fine-tuning. The training objective at this stage is to enable the model to learn to follow the instruction of "generating test cases based on business logic pseudocode" and output test case text that conforms to project specifications and business requirements. Through this stage, the model further evolves from "understanding the business" to a knowledge-enhanced large-scale model that "can write test cases".

[0233] (3) Based on the knowledge-enhanced large model obtained through two-stage fine-tuning in step (3), test cases are generated. The specific process is as follows:

[0234] Input Construction: The pseudocode of the business logic obtained in step (2) for a specific event (e.g., Event1: “Click the Confirm button”) is combined with a carefully optimized prompt word template to form the complete input of the large model. This prompt word template has been trained in the instruction fine-tuning stage, and the model is familiar with its instructions. An example of an optimized template is as follows:

[0235] "You are a senior test engineer. Please generate detailed functional test cases based on the following 'business logic pseudocode'."

[0236] The requirements are as follows:

[0237] Coverage of multiple scenarios: It must cover normal scenarios, abnormal scenarios (such as invalid input, operation failure) and boundary scenarios (such as input limit values).

[0238] Complete structure: Each test case must include: test purpose, preconditions, test steps, test data, and expected results.

[0239] Business alignment: The expected results must strictly correspond to the business logic in the pseudocode and reference key business rules.

[0240] Pseudocode of the business logic to be analyzed:

[0241] {}”

[0242] The formatting tool system automatically fills in the pseudocode generated in step (2), for example, the pseudocode for Event1:

[0243] # Event: Clicking the Confirm button (Event1)

[0244] # Main processing function: FuncMain_Confirm

[0245] start:

[0246] Step 1: Verify the validity of the username and password.

[0247] If verification fails:

[0248] Jump to error handling process

[0249] otherwise:

[0250] Continue with step 2

[0251] Step 2: Save the user-submitted form data to the database.

[0252] Step 3: Update the interface to display a successful operation status message.

[0253] Finish;

[0254] Model Reasoning and Generation: After receiving input, the knowledge-enhanced large model utilizes the domain business knowledge learned during the incremental pre-training phase and the test case writing capabilities acquired during the instruction fine-tuning phase to perform automated reasoning. It can understand conditional statements in pseudocode (such as "if verification fails") and automatically derive test cases for both normal and abnormal flows accordingly. The model's output is structured natural language text, covering all elements required by the aforementioned prompts. The generated results are as follows:

[0255] TC001: Normal Procedure - Valid Username and Password

[0256] Test objective: To verify that the entire process can be completed normally when a valid username and password are entered.

[0257] Prerequisites:

[0258] The system is on the login page.

[0259] Database connection is normal

[0260] The form data has been filled in completely.

[0261] Test steps:

[0262] Enter a valid username (that meets the format requirements).

[0263] Enter a valid password (that meets the format requirements).

[0264] Click the OK button

[0265] Observe the system response

[0266] Test data:

[0267] Username: "testuser123"

[0268] Password: "Password123"

[0269] Form data: Complete required fields

[0270] Expected results:

[0271] Username and password verification successful (referencing rule: Step 1 verification successful)

[0272] The form data was successfully saved to the database (reference rule: step 2 executed successfully).

[0273] The interface displays a success status message (reference rule: Step 3 was executed successfully).

[0274] TC002: Abnormal Scenario - Username is empty

[0275] Test objective: To verify error handling when the username is empty.

[0276] Prerequisite: The system is on the login page.

[0277] Test steps:

[0278] Leave the username field blank.

[0279] Enter a valid password.

[0280] Click the OK button

[0281] Observe the error message

[0282] Test data:

[0283] username: ""

[0284] Password: "ValidPass123"

[0285] Expected results:

[0286] Username and password verification failed (referencing rule: Step 1 verification failed).

[0287] Jump to the error handling process and display the corresponding error message.

[0288] Steps 2 and 3 are not executed.

[0289] TC003: Abnormal Scenario - Password is empty

[0290] Test objective: To verify error handling when the password is empty.

[0291] Prerequisite: The system is on the login page.

[0292] Test steps:

[0293] Enter a valid username

[0294] Leave the password field blank.

[0295] Click the OK button

[0296] Observe the error message

[0297] Test data:

[0298] Username: "testuser"

[0299] password: ""

[0300] Expected results:

[0301] Username and password verification failed (referencing rule: Step 1 verification failed).

[0302] Jump to the error handling process and display the corresponding error message.

[0303] Steps 2 and 3 are not executed.

[0304] TC004: Boundary Scenario - Minimum Username Length

[0305] Test objective: To verify the handling of usernames that meet the minimum length requirement.

[0306] Prerequisite: The system is on the login page.

[0307] Test steps:

[0308] Enter the minimum length of a valid username.

[0309] Enter a valid password.

[0310] Click the OK button

[0311] Test data:

[0312] Username: "ab" (assuming minimum length is 2)

[0313] Password: "ValidPass123"

[0314] Expected results:

[0315] Username and password verification successful (referencing rule: Step 1 verification successful)

[0316] The form data was successfully saved to the database.

[0317] The interface displays a success status message.

[0318] TC005: Boundary Scenario - Maximum Username Length

[0319] Test objective: To verify the handling of usernames reaching the maximum length.

[0320] Prerequisite: The system is on the login page.

[0321] Test steps:

[0322] Enter the maximum length of a valid username.

[0323] Enter a valid password.

[0324] Click the OK button

[0325] Test data:

[0326] Username: "a" × 50 (assuming a maximum length of 50)

[0327] Password: "ValidPass123"

[0328] Expected results:

[0329] Username and password verification successful (referencing rule: Step 1 verification successful)

[0330] The form data was successfully saved to the database.

[0331] The interface displays a success status message.

[0332] TC006: Boundary Scenario - Minimum Password Length

[0333] Test objective: To verify the handling of passwords that meet the minimum length requirement.

[0334] Prerequisite: The system is on the login page.

[0335] Test steps:

[0336] Enter a valid username

[0337] Enter the minimum valid password.

[0338] Click the OK button

[0339] Test data:

[0340] Username: "testuser"

[0341] Password: "pwd8" (assuming minimum length is 4)

[0342] Expected results:

[0343] Username and password verification successful (referencing rule: Step 1 verification successful)

[0344] The form data was successfully saved to the database.

[0345] The interface displays a success status message.

[0346] ···(omitted);

[0347] To enable test cases to be used immediately, this invention introduces a format converter.

[0348] Template mapping: This converter has built-in test case design document templates (such as Excel format) that are specified by the project. The templates predefine fields such as "Test Case Number", "Test Item", "Operation Steps", "Expected Results" and "Test Data".

[0349] Automated Filling: The format converter uses natural language processing technology (such as keyword matching and rule parsing) to automatically identify and extract different parts of the text-based test cases generated by the large model, and then accurately fills them into the corresponding fields of the template document.

[0350] Final output: The final output is a standardized test case document (such as a filled Excel file) that fully conforms to project specifications and can be directly delivered to the testing team for execution, eliminating the need for manual copying, pasting, and formatting adjustments. The document format and content are shown below.

[0351]

[0352] To ensure the quality of generated test cases, this invention introduces an automated verification closed loop that includes the following two dimensions:

[0353] A. Rule engine verification:

[0354] Rule base construction: Based on the business knowledge system constructed in step (1), extract core business rules (such as "username cannot be empty" and "password length must be greater than 6 characters") to form a computable business rule base.

[0355] Logical correctness verification: The rule engine scans the "test data" and "expected results" of each generated test case. For example, for a test case, if its test data is username="", password="123", while the expected result includes "login successful", the rule engine will immediately identify the logical contradiction of the test case based on the rule "username cannot be empty" and mark it as "verification failed", prompting the designer to review it. This effectively prevents the generation of invalid test cases that violate basic business rules.

[0356] Rule base construction example:

[0357] Based on the business knowledge system, the following core business rules are extracted, formalized, and stored in the rule base:

[0358] RULE_001: Username cannot be empty (username != null && username != "")

[0359] RULE_002: Password length must be greater than 6 characters (password.length >= 6)

[0360] Example of logical correctness verification:

[0361] Scenario: Testing the "user login" function.

[0362] A generated test case (before formatting) looks like this:

[0363] Test Case Name: Test Login Behavior When Entering a Short Password

[0364] Test steps:

[0365] Enter "test_user" in the username input box.

[0366] Enter "123" in the password input box.

[0367] Click the "Login" button

[0368] Expected results:

[0369] The system popped up a prompt box that said "Login successful".

[0370] The interface redirects to the user's homepage.

[0371] Rule engine verification process and output:

[0372] The rules engine scans the test case and extracts key data: username="test_user", password="123", and expected result="Login successful".

[0373] The engine matches the data against the rule base. Rule RULE_002 (password length must be greater than 6 characters) is triggered.

[0374] The engine performs logical reasoning: the password length in the test data is 3, which violates RULE_002. Therefore, the correct result of the business logic should be "login failed" with an error message. However, the expected result of the test case is "login successful".

[0375] The rules engine outputs an inspection report:

[0376] ```text

[0377] [Rule Engine Verification Report]

[0378] - Inspection time: 2024-05-20 10:00:00

[0379] - Test case: Test login behavior when entering a short password

[0380] - Test results: fail

[0381] - Rule violation: RULE_002 (Password length must be greater than 6 characters)

[0382] - Conflict details: The test data (password="123") violates the business rules, but the expected result contradicts it (expected to be "Login successful").

[0383] - Recommendation: Please review this test case. The expected result should be adjusted to display an error message indicating insufficient password length.

[0384] ```;

[0385] This example clearly demonstrates how a rules engine can automatically capture potential logical errors in test cases, preventing test cases that violate basic business rules from being misused.

[0386] B. Coverage Analysis:

[0387] Path mapping: Using coverage analysis tools, the pseudocode of the business logic refactored in step S2 is regarded as a set of business scenario paths to be covered. For example, "If verification fails: jump to the error handling process" and "Otherwise: continue to execute step S2" in the pseudocode constitute two independent logical paths.

[0388] Coverage assessment: This tool treats all generated test cases as a whole and analyzes their correspondence with these business logic paths. Through calculation, it can generate a coverage report that clearly indicates which business paths (especially exception and boundary paths) have not yet been covered by any test cases.

[0389] Optimization Guidance: This system not only enables "post-event" evaluation but also "pre-event" guidance. Testers can use the "blind spot" prompts provided in the coverage report to specifically adjust the prompts for the large model (e.g., explicitly requesting "please add test cases when the username is empty"), or directly perform a small number of supplementary designs, thereby systematically improving the completeness of the test case set.

[0390] Path mapping example:

[0391] Taking the pseudocode of the business logic for the "Click Confirm Button" event refactored in step S2 as an example, it is parsed into a set of overridable paths:

[0392] Path P1 (Normal Flow): [Step 1: Verification Successful] -> [Step S2: Save Data] -> [Step S3: Interface Update Successful];

[0393] Path P2 (Abnormal Flow - Validation Failure): [Step 1: Validation Failure] -> [Jump to Error Handling Flow]

[0394] Path P3 (Boundary Flow - Password Length = 6): [Step 1: Verification Passed (Password Length = 6)] -> [Step 2] -> [Step 3] (This path may be the same as P1 at the code level, but is independent in the test data design)

[0395] Coverage assessment and report output examples:

[0396] Suppose the system generates the following two test cases in response to this event:

[0397] TC001: Enter the correct username and long password. Login successful as expected. (Overwrite P1)

[0398] TC002: Entering a blank username will result in login failure and a message. (Override P2)

[0399] After running the coverage analysis tool, the following report is generated:

[0400] ```text;`

[0401] [Business Logic Path Coverage Analysis Report]

[0402] Analysis object: Event "Clicking the Confirm Button" (Event1);

[0403] Total number of covered paths: 2 / 3 (coverage rate 66.7%);

[0404] Details of uncovered paths:

[0405] Path P3: [Step 1: Verification successful (password length = 6)] -> [Step S2] -> [Step S3];

[0406] Path description: This path is used to verify boundary cases where the password length is exactly the minimum requirement (6 bits).

[0407] Missing scenario: Currently, all test cases have password lengths greater than 6 characters, and there is a lack of boundary tests with a length of 6 characters.

[0408] Optimization suggestion: It is recommended to add a test case with a password length of 6 characters in the test data.

[0409] Optimization guidance example:

[0410] Upon receiving the above report, the testers can take two actions:

[0411] "Pre-test" guidance (iterative generation): The conclusions of the coverage report are used as new requirements, feeding back to the prompt word template and triggering a new round of test case generation. For example, the system can automatically construct the following prompt words for the large model:

[0412] "You are a senior test engineer. Please generate new test cases based on existing test cases and the following supplementary requirements:"

[0413] Additional requirement: The existing test cases do not adequately cover the boundary scenario where the password length is exactly 6 characters. Please generate a test case specifically for this boundary condition.

[0414] The large model will then generate test cases that cover path P3.

[0415] Direct supplement: Based on the report, the tester manually and quickly designs a test case to cover path P3.

Claims

1. A method for automatically generating business test cases based on a knowledge-enhanced large model, characterized in that, Includes the following steps: Step S1: Building a Business Knowledge System: Document Parsing and Knowledge Graph Construction; Step S2: Design document restructuring: process analysis and logic restructuring; Step S3: Knowledge-enhanced large model training: incremental pre-training and instruction fine-tuning; Step S4: Test Case Generation and Automatic Verification: Test case generation, test case formatting and output, and automatic test case verification.

2. The method for automatically generating business test cases based on a knowledge-enhanced large model according to claim 1, characterized in that, In step S1: the documentation for common business categories is parsed into JSON format using a parsing tool, with different parsing tools corresponding to different document formats / styles; the valid data in the parsed / annotated JSON file is converted into a code table and stored in the knowledge graph using a conversion tool.

3. The method for automatically generating business test cases based on a knowledge-enhanced large model according to claim 1, characterized in that, In step S2: the program flow design document is parsed on a project-by-project basis to obtain a list of triggering events, the main processing function of each event and its contained function list; the function list of the main processing function is traversed on an event-by-event basis, and each function and its parameters are replaced with the corresponding business description by querying the knowledge graph to form business logic pseudocode.

4. The method for automatically generating business test cases based on a knowledge-enhanced large model according to claim 1, characterized in that, In step S3: the JSON file obtained by parsing / annotating in step S1 is used as part of the incremental pre-training data. In addition, business education materials, videos, audio, and unstructured valuable business assets are parsed using a combination of parsing tools and manual annotation and proofreading.

5. The method for automatically generating business test cases based on a knowledge-enhanced large model according to claim 1, characterized in that, In step S3: a fine-tuning instruction dataset is constructed on a project-by-project basis; the construction process of the dataset is as follows: Input: obtain the pseudo-code of the business logic obtained after the reconstruction of the project in step S2; Instruction: use a fixed prompt word template; Output: Extract the test case content corresponding to the business logic from the historical test case design documents of the project, including the structured fields of "Test Project / Content", "Test Method" and "Confirmation Method"; Based on the constructed (instruction, input, output) dataset, fine-tune the business knowledge enhancement base model obtained in step S3.

6. The method for automatically generating business test cases based on a knowledge-enhanced large model according to claim 1, characterized in that, In step S4: Test cases are generated based on the knowledge-enhanced large model obtained through two-stage fine-tuning in step S3; The pseudocode step S2 of the business logic that needs to generate test cases is paired with the optimized prompt word template; After receiving input, the model uses its inherent business knowledge and instruction-following ability to automatically generate structured test case text. Test case formatting and output: Through a format converter, the text-based test cases generated from the large model are automatically filled into the corresponding fields in the test case design document template specified by the project, generating a final test case document that can be directly used for test execution and conforms to the project specifications; Automated test case verification: To ensure the quality of generated test cases, an automated verification mechanism is introduced; a business rule base is established, which defines the core rules extracted from the business knowledge system; the rule engine will scan the "test data" and "expected results" of the generated test cases one by one.

Images