Test case generation method and device based on business scene and related equipment

Abstract

The embodiment of the invention discloses a test case generation method and device based on a service scene and related equipment. The method comprises the following steps: acquiring historical test data, and identifying and extracting entities and corresponding entity relationships in the historical test data through a pre-trained identification model; according to the entities and the corresponding entity relationships, storage is carried out in a triple form, and a test knowledge graph is constructed; analyzing based on the test document of the current test item, and determining the test requirement and the test item of the test document; based on the test requirements and the test items, matching corresponding standard triads and reference test cases from the knowledge graph and a preset test case library to obtain a target triad set and a target reference case; and generating a target cue word based on the test requirement, the test item, the target triple set and the target reference case, and generating a target test case through a pre-trained large language model. According to the method, the scene coverage of the test case is higher, and the logic continuity of the test case is improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of software testing technology, and in particular to a method, apparatus and related equipment for generating test cases based on business scenarios. Background Technology

[0002] Existing test case generation methods based on large models primarily involve acquiring test documents (including software requirements documents and software design documents), identifying test items, matching reference test cases, and then inputting this information into a prompt word template to generate test cases from the large model. This method has significant technical drawbacks: the test documents and reference test cases exist in linear text format, making it difficult to intuitively express the relationships between business scenarios. This limits the large model's understanding of complex business logic and easily leads to the generation of logically incoherent test cases. Furthermore, for edge business scenarios (such as cross-module interaction scenarios triggered by extreme conditions), simply matching test points with reference test cases is insufficient to achieve comprehensive coverage, resulting in test vulnerabilities.

[0003] For example, in testing the transfer function of financial software, existing methods may only generate test cases covering the main scenario of "normal transfer," while missing peripheral scenarios such as "transfer amount exceeding the limit triggering a limit prompt" and "bank interface call failure triggering a retry mechanism." These peripheral scenarios involve cross-module interactions between the account module, interface module, and notification module. Linear text cannot allow the primary model to accurately capture the related logic, resulting in incomplete test case coverage and potential risks.

[0004] Therefore, how to integrate business scenario information through structured means to assist large models in generating test cases with scenario coverage and logical accuracy has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] This invention provides a method, apparatus, and related equipment for generating test cases based on business scenarios, aiming to solve the technical problem that test cases generated from large models in traditional technologies are difficult to meet testing requirements.

[0006] In a first aspect, embodiments of the present invention provide a test case generation method based on a business scenario, comprising:

[0007] Historical test data is acquired, and entities and corresponding entity relationships in the historical test data are identified and extracted through a pre-trained recognition model. The historical test data includes at least historical test cases, test documents, and user behavior logs. The entities include business scenarios, business rules, user behaviors, system modules, and edge scenario triggering conditions. The entity relationships include at least inclusion, triggering, and derivation.

[0008] Based on the entities and their corresponding entity relationships, the data is stored in the form of triples to obtain multiple standard triples. A test knowledge graph is then constructed based on the standard triples. Each triple includes two entities and their corresponding entity relationships.

[0009] Receive the test document for the current test project, parse the test document, and determine the test requirements and test items in the test document;

[0010] Based on the test requirements and test items, the corresponding standard triples and reference test cases are matched from the knowledge graph and the pre-set test case library to obtain the target triple set and target reference test cases.

[0011] The test requirements, test items, target triplet set, and target reference test cases are filled into the preset prompt word template to obtain the target prompt words;

[0012] The target prompt words are input into a pre-trained large language model to generate test cases, thus obtaining the target test cases.

[0013] Secondly, embodiments of the present invention provide a test case generation device based on a business scenario, comprising:

[0014] An extraction module is used to acquire historical test data and identify and extract entities and corresponding entity relationships in the historical test data through a pre-trained recognition model. The historical test data includes at least historical test cases, test documents, and user behavior logs. The entities include business scenarios, business rules, user behaviors, system modules, and edge scenario triggering conditions. The entity relationships include at least inclusion, triggering, and derivation.

[0015] The knowledge graph construction module is used to store the entities and their corresponding entity relationships in the form of triples to obtain multiple standard triples, and to construct a test knowledge graph based on the standard triples. Each triple includes two entities and their corresponding entity relationships.

[0016] The parsing module is used to receive the test document of the current test project, parse the test document, and determine the test requirements and test items of the test document;

[0017] The matching module is used to match the corresponding standard triples and reference test cases from the knowledge graph and the pre-set test case library based on the test requirements and test items, respectively, to obtain the target triple set and the target reference test cases;

[0018] The fill module is used to fill the test requirements, test items, target triplet set and target reference test cases into the preset prompt word template to obtain the target prompt words;

[0019] The generation module is used to input the target prompt words into a pre-trained large language model to generate test cases and obtain target test cases.

[0020] Thirdly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test case generation method based on business scenarios described in the first aspect.

[0021] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to execute the business scenario-based test case generation method described in the first aspect.

[0022] This invention provides a method, apparatus, and related equipment for generating test cases based on business scenarios. The method acquires historical test data and identifies and extracts entities and corresponding entity relationships from the historical test data using a pre-trained recognition model. Based on the entities and their corresponding entity relationships, the data is stored in the form of triples to obtain multiple standard triples, and a test knowledge graph is constructed based on these standard triples. The method receives the test document of the current test project and parses it to determine the test requirements and test items. Based on the test requirements and test items, corresponding standard triples and reference test cases are matched from the knowledge graph and a pre-set test case library to obtain a target triple set and target reference test cases. The test requirements, test items, target triple set, and target reference test cases are filled into a pre-set prompt word template to obtain target prompt words. The target prompt words are input into a pre-trained large language model for test case generation to obtain target test cases. This method determines the set of triples related to the current test project through the association reasoning of the constructed test knowledge graph. It then integrates test requirements, test items, target triple sets, and target reference test cases to fill the pre-set prompt word template to generate target prompt words. Based on the target prompt words, the method generates target test cases through a large language model, which makes the scenario coverage of the test cases output by the large language model higher. In addition, the supplementary constraints based on the target triple set can also improve the logical coherence of the test cases. Attached Figure Description

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

[0024] Figure 1A flowchart illustrating an embodiment of the test case generation method based on business scenarios provided by this invention;

[0025] Figure 2 A flowchart illustrating another embodiment of the test case generation method based on business scenarios provided in this invention;

[0026] Figure 3 This is a schematic block diagram of a test case generation device based on a business scenario provided in an embodiment of the present invention. Detailed Implementation

[0027] 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, not all, of the embodiments of the present invention. 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.

[0028] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0029] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0030] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] Please see Figure 1 This is a flowchart illustrating a business scenario-based test case generation method provided in an embodiment of the present invention. The method includes steps S110 to S160.

[0032] Step S110: Obtain historical test data, and identify and extract entities and corresponding entity relationships in the historical test data through a pre-trained recognition model;

[0033] In this embodiment, historical test data includes historical test cases, test documents, and user behavior logs. Test-related data such as test requirements and business rules (e.g., "daily transfer limit of 100,000 yuan" and "refund time limit of 24 hours") recorded in the test documents, scenario descriptions in historical test cases (e.g., "user initiates transfer → system verifies balance → executes transfer"), and operation sequences (e.g., "enter amount → click confirm → receive receipt") in the user behavior logs are identified. Entities such as business scenarios, business rules, user behaviors, system modules, and edge scenario triggering conditions are extracted from the test-related data using a large language model, and the entity relationships between these entities are identified based on semantics.

[0034] In one embodiment, the entity relationship between business scenarios and business rules is as follows: The core constraint of the transfer scenario is "controlling the risk of daily transfers," and the "daily limit of 500,000 yuan" is a business rule that this scenario must comply with. If this rule is missing, the transfer scenario may have the risk of over-transfer. Therefore, the "transfer scenario" as a whole must include the "daily limit rule." The "refund scenario" includes the rule "refunds arrive within 24 hours." Logical explanation: The refund scenario needs to protect the user's financial rights. "Refunds arrive within 24 hours" is the core expectation of users to accept the refund service and is a necessary rule for the refund scenario. Therefore, the "refund scenario" includes this time limit rule.

[0035] Furthermore, business scenarios include user behaviors. For example, the "transfer scenario" includes the user behavior sequence logic of "enter receiving account → verify account validity → enter transfer amount → confirm transfer". Explanation: The complete process of the transfer scenario depends on the user's continuous operation. The above behaviors are necessary steps to complete the transfer. The absence of any step (such as failure to verify account validity) will cause the scenario to be interrupted. Therefore, the "transfer scenario" includes this user behavior sequence.

[0036] Furthermore, business scenarios involve system modules. For example, the "transfer scenario" involves the "account module, payment interface module, log module, and notification module." Logical explanation: The operation of the transfer scenario requires the collaboration of multiple modules—the account module is responsible for verifying the balance and account validity, the payment interface module is responsible for connecting with the bank to complete the fund transfer, the log module is responsible for recording the transfer operation (such as user ID, amount, and time), and the notification module is responsible for pushing the transfer receipt to the user. Without any of these modules, the transfer scenario cannot be fully executed. Therefore, the "transfer scenario" involves the above modules.

[0037] Furthermore, edge scenario triggering conditions, such as "third-party payment interface response timeout > 3s" triggering "interface timeout retry scenario", are explained as follows: "interface timeout > 3s" is a preset edge scenario triggering condition. When this condition occurs in a transfer scenario, the system is directly triggered to enter the "interface timeout retry scenario" and execute the process of "automatically retrying the interface call 3 times → if the retry fails, log it and notify the user".

[0038] Furthermore, defining entity relationships must include at least "inclusion," "triggering," and "deriving." For example, an "inclusion" relationship might be: "Order payment scenario" includes "order inventory must be verified before payment." The rule logic explains that the payment scenario must avoid "ordering beyond inventory limits," and "inventory verification" is a necessary step before payment, belonging to the core rules of the order payment scenario; therefore, the "order payment scenario" includes this verification rule. Similarly, a "triggering" relationship might be: "User inputting an amount exceeding the limit (e.g., 600,000 yuan)" triggers an "amount exceeding the limit scenario." The logic explains that when a user inputs an amount exceeding the "daily limit of 500,000 yuan" (business rule) in a transfer scenario, this operation directly breaks the normal transfer logic, causing the system to enter the "amount exceeding the limit scenario" (edge ​​scenario), triggering subsequent actions such as displaying an over-limit warning and intercepting the transfer request. For example, a "derivative" relationship can be derived from a "transfer scenario" (the main business scenario) which includes "excess amount edge scenario" and "insufficient balance edge scenario". The logic is as follows: the normal operation of the "transfer scenario" depends on the premises of "amount compliance" and "sufficient balance". When these premises are not met (such as exceeding the amount limit or insufficient balance), the main scenario cannot be executed normally, thus giving rise to edge scenarios. The "excess amount edge scenario" is used to handle the excess problem, and the "insufficient balance edge scenario" is used to prompt the user to recharge. Both are extensions of the main scenario under abnormal conditions, and therefore belong to the "derivative" relationship.

[0039] Step S120: Store the entities and their corresponding entity relationships in the form of triples to obtain multiple standard triples, and construct a test knowledge graph based on the standard triples;

[0040] In this embodiment, the Neo4j tool is used to store entities and their corresponding entity relationships in the form of triples (such as (transfer scenario, including, limit rule), (amount exceeding limit, derived, transfer scenario)) to construct a test knowledge graph, forming a visualized test knowledge network that intuitively presents the hierarchical relationships between entities (such as the hierarchical relationship between the main business scenario and the edge scenario, and the interaction logic between system modules).

[0041] Step S130: Receive the test document of the current test project, parse the test document, and determine the test requirements and test items of the test document;

[0042] In this embodiment, the received test documents include, but are not limited to: 1. Core requirement documents: Software Requirements Documents (SRS) and Software Design Documents (SDD). These documents clearly define business functions, rules, and module interaction logic, and are the main source of test requirements (e.g., the "Transfer Business Requirements Document" for the "Commercial Bank Transfer Function" in the document); 2. Test planning documents: Test plans and test schemes. These documents clearly define the test scope and test focus, and can help select core test items (e.g., the test scope definition for "Full-Scenario Testing of Transfer Function" in the document); 3. Historical reference documents: List of historical test cases and summaries of user behavior logs. These documents can supplement requirements for edge scenarios (e.g., the requirement for the "Interface Timeout Retry" scenario in the document can be extracted from historical logs). The received unstructured test documents are processed through "keyword positioning, structured information extraction, and format standardization". Keyword localization involves establishing a keyword library based on the core elements of the business scenarios in the solution (business rules, user behavior, system modules, and edge scenarios) to quickly locate paragraphs in the document containing requirement information. Examples include: business rule keywords such as "rule," "quota," "time limit," "constraint," "must," and "should"; function keywords such as "support," "implement," "provide," and "must complete"; exception scenario keywords such as "exception," "error," "timeout," "insufficient," and "failure"; and system module keywords such as "module," "interface," "dependency," and "call." Structured information extraction involves extracting information from the located core paragraphs according to four dimensions: "information type," "description content," "constraints," and "related modules," forming a structured data table. In one embodiment, taking the "Transfer Function Description" paragraph in the "Transfer Business Requirements Document" as an example: The original paragraph reads, "This system supports intra-bank and inter-bank transfers for individual users. Intra-bank transfers must be real-time, and inter-bank transfers must be T+1. The cumulative daily transfer amount for individual users must not exceed 500,000 yuan. If it exceeds this limit, the system must intercept the transfer request and display an over-limit prompt. When a user's account balance is insufficient, a pop-up window must display the message 'Insufficient balance, please recharge.' If the bank interface call times out (exceeds 3 seconds) during the transfer process, the system must automatically retry 3 times. If the retry fails, the log will be recorded and the user will be notified." The structured extraction result is as follows:

[0043] |Information Type|Description Content|Constraints|Related Modules|

[0044] |----|----|----|----|

[0045] |Functional Requirements|Same-bank Transfer|Real-time Transfer|Account Module, Payment Module, Notification Module|

[0046] |Functional Requirements|Interbank Transfer|T+1 Arrival|Account Module, Payment Module, Bank Interface Module|

[0047] |Rules Required|Daily Cumulative Transfer Amount|≤500,000 RMB, exceeding the limit will result in blocking|Account Module, Payment Module|

[0048] |Abnormal Requirement|Insufficient Account Balance|Pop-up message "Insufficient balance, please recharge"|Account Module, Front-end Interaction Module|

[0049] |Exceptional Requirements|Bank Interface Timeout|Timeout > 3 seconds, automatically retry 3 times, log and notify on failure|Payment Module, Log Module, Notification Module|

[0050] Standardize the format of the extracted structured information: unify the format of the extracted information to ensure consistency in subsequent requirement classification and test item breakdown.

[0051] Constraint format: Use "numerical value + unit + logical relationship" (e.g., "≤500,000 yuan" ">3 seconds").

[0052] Related modules format: sorted by "core modules → auxiliary modules" (e.g., "account module → payment module → log module").

[0053] Prompt text format: Retain the content within the original quotation marks (e.g., "Insufficient balance, please recharge") to avoid semantic discrepancies.

[0054] Based on the structured parsing results, test requirements are extracted and categorized into three main categories: "functional requirements," "rule requirements," and "abnormal requirements." Classification criteria are set according to business scenarios, business rules, and edge cases.

[0055] Functional requirements: The core functions corresponding to the "business scenarios" in the knowledge graph are the basic capabilities that the software needs to achieve to function properly (such as "real-time arrival of intra-bank transfers" and "T+1 arrival of inter-bank transfers").

[0056] Rule requirements: Corresponding to the "Business Rules" entity in the knowledge graph, these are the conditions that constrain the operation of the function (such as "Daily transfer limit of 500,000 yuan" and "Over-limit interception").

[0057] Abnormal requirements: These correspond to the "edge scenario triggering conditions" entity in the knowledge graph and are requirements for handling abnormal situations (such as "insufficient balance prompt" or "interface timeout retry").

[0058] For each extracted test requirement, test items are broken down according to the principle of "executable and verifiable", and a relationship of "test requirement - test item - verification point" is established to ensure that the test items can fully cover the requirements.

[0059] Step S140: Based on the test requirements and test items, match the corresponding standard triple set and reference test cases from the knowledge graph and the pre-set test case library respectively to obtain the target triple set and target reference test cases;

[0060] In this embodiment, the target triple set is structured data (entity 1, relation, entity 2) in the knowledge graph directly related to the test requirements and test items. It needs to be matched through three steps: "entity mapping – relation filtering – set verification," focusing on the "test item verification point," to ensure coverage of the business rules, module interactions, and scenario-related logic required for the test. Step 1: Establish the mapping relationship between test items and entities in the knowledge graph. Using the "verification point" of the test item as the core, extract keywords and locate the corresponding entities in the core entity library of the knowledge graph (business scenarios, business rules, system modules, edge scenario triggering conditions), forming a "test item – core entity" mapping table. For example, the core entity mapping table for the transfer function test is as follows:

[0061]

[0062]

[0063] Step 2: Filter candidate triples based on entity relationships. According to the three predefined core relationships (containment, triggering, and derivation) in the knowledge graph, filter candidate triples containing "matched core entities" to ensure coverage of the rule constraints, module interactions, and scenario-derived logic required for the test item. Step 3: Verify the suitability of candidate triples and determine the target triple set. From three dimensions—"rule consistency," "scenario relevance," and "module completeness"—remove candidate triples irrelevant to the test requirements, ultimately forming the target triple set. This ensures that each triple can support the verification logic of the test item.

[0064] Furthermore, the target reference test cases are selected from the pre-built test case library, which are consistent with the test item scenario and have complete steps. They undergo a three-step selection process: "keyword retrieval – relevance assessment – ​​priority ranking," providing reference templates that conform to business logic for generating test cases for the large language model. Specifically, firstly, each test case in the pre-built test case library contains metadata such as "test case name, test scenario, test steps, expected results, and related requirements" (mentioned in the documentation). Candidate test cases containing corresponding information in the metadata are retrieved using the keyword combination of "test scenario + verification point" for the test item. For example, taking the test item "verify real-time arrival of peer-to-peer transfers" as an example: the keyword combination is "peer-to-peer transfer + real-time arrival";

[0065] Search results (candidate use cases):

[0066] Candidate use case 1: TC-TR-001 Real-time transfer test of RMB 10,000 between the same party;

[0067] Candidate use case 2: TC-TR-005 Successful interbank transfer of 30,000 yuan (example use case in step 2 of the document);

[0068] Candidate use case 3: TC-TR-012 Interbank transfer of 50,000 yuan with T+1 arrival test (containing the keyword "transfer", but the scenario does not match, so it was initially screened out).

[0069] Next, candidate use cases are evaluated from three core dimensions: "scenario consistency", "step completeness", and "result matching degree" (the implicit logic in the document, based on the requirement that use case generation must "conform to the business process") to ensure that the selected use cases can be directly used as reference templates. Finally, the optimal use case is selected as the target reference use case by prioritizing "typicality > timeliness > coverage".

[0070] In addition, the target triple set and target reference test cases can be integrated according to the "test requirements - test items" dimension to form a "one-to-one" mapping relationship. The "completeness, consistency and validity" verification is used to ensure that there are no omissions or deviations, providing accurate input for the subsequent generation of target prompt words.

[0071] Step S150: Fill the test requirements, test items, target triplet set and target reference test cases into the preset prompt word template to obtain the target prompt words;

[0072] Step S160: Input the target prompt word into the pre-trained large language model to generate test cases and obtain target test cases.

[0073] In this embodiment, the pre-set prompt template must include four modules: "Instruction Header, Core Information Area, Constraint Rules Area, and Output Format Area," ensuring no information is omitted, constraints are clear, and output is standardized. The "Instruction Header" clarifies the core task of the large model (generating test cases); the "Core Information Area" integrates test requirements, test items, target triplet sets, and target reference test cases, providing all supporting data for generating test cases; the "Constraint Rules Area" limits the business logic constraints (based on target triplets) and scenario coverage requirements that test cases must meet; and the "Output Format Area" clarifies the specific format of the test cases (ensuring automated subsequent verification).

[0074] Taking the preset prompt template corresponding to "transfer function test" in the document as an example, the complete template framework is as follows:

[0075] [Instruction Header] Based on the following test resources, generate test cases that cover the entire scenario of the specified test item, ensuring logical coherence and compliance with business rules.

[0076] [Core Information Area]

[0077] 1. Testing Requirements: {Description of testing requirements, including functional / rule / exception requirements}

[0078] 2. Test Items and Verification Points: {Test Item Name, Corresponding Verification Point (e.g., "Verify Single Transaction Exceedance Interception: Input > 500,000 RMB, Verify Interception + Prompt")}

[0079] 3. Target triple set: {(Entity 1, Relation, Entity 2) Format list, annotating the core functions}

[0080] 4. Target Reference Use Case Summary: {Reference Use Case Number + Core Scenario + Key Steps (e.g., “TC-TR-005: Intra-bank transfer of 30,000 yuan, steps include account module verification → payment module execution”)}

[0081] [Constraint Rules Area]

[0082] 1. Scene Coverage: The test items must cover both the main scene and the peripheral scenes associated with them (based on the "derived" and "triggered" relationships in the triples).

[0083] 2. Logical constraints: The operation steps must conform to the relationship defined by the triple (e.g., "steps involving module dependencies must be executed in the order of dependencies, and rule-type triples must be reflected in the expected results").

[0084] 3. Business compliance: Must comply with the core rules in the testing requirements (such as "daily transfer limit of 500,000 yuan" and "interface timeout retry 3 times").

[0085] Output Format Area

[0086] Each test case should be output in the following structure:

[0087] 1. Test case number: TC-[Test item abbreviation]-00X (e.g., TC-TR-LIMIT-001);

[0088] 2. Scene type: Main scene / Edge scene;

[0089] 3. Test objective: To clarify the verification requirements and the basis for the triplet;

[0090] 4. Operation steps: Write them in the format of "step number + operation description + involved modules" (e.g., "1. User logs in to the commercial bank APP (account module)");

[0091] 5. Expected results: Describe in points, and associate with the corresponding triple rules (e.g., "System pop-up prompts 'Daily limit of 500,000 yuan', which meets the triple (transfer scenario, includes, daily limit of 500,000 yuan rule)").

[0092] The generation of target prompts should follow the logic of "template module → resource matching → precise filling," mapping test requirements, test items, target triplet sets, and target reference test cases one by one to the corresponding positions in the template. This ensures that the information in each module is complete, unambiguous, and consistent with the business logic of the test document. The following uses the test item "Commercial Bank Transfer Function - Verification of Single Transfer Exceedance Interception" as an example to break down the filling process in detail:

[0093] Testing requirements:

[0094] 1. Rule Requirements: Daily cumulative transfers by individual users must be ≤500,000 RMB; exceeding this limit will result in blocking.

[0095] 2. Business Objectives: To control financial risks and comply with regulatory requirements.

[0096] Test items and verification points:

[0097] 1. Test item: Verify the blocking of single-transfer exceeding limits;

[0098] 2. Verification point: Enter an amount greater than 500,000 yuan (e.g., 600,000 yuan) to verify whether the system blocks the transfer request + a pop-up window will display the message "Daily limit 500,000 yuan".

[0099] The target set of triples:

[0100] 1. (Transfer scenario, including the daily limit of 500,000 yuan) — Core function: to clarify the business rules for blocking exceeding the limit;

[0101] 2. (Amount > 500,000 RMB, triggered, exceeding the limit scenario) — Core function: Associates abnormal input with edge scenarios;

[0102] 3. (For scenarios involving excessive amounts, involving the account module) – Core function: Clearly define the system module responsible for verification;

[0103] 4. (Transfer scenario, derivative, amount exceeding limit scenario) – Core function: Confirm the hierarchical relationship of scenarios. Target reference use case:

[0104] Number: TC-TR-021; Core Scenario: Interception of a single transfer exceeding the limit of 600,000 yuan; Key Steps: 1. User login (account module) → 2. Enter the receiving account (account module) → 3. Enter the amount of 600,000 yuan (account module) → 4. Click "Next"; Expected Result: The system intercepts the transfer and displays a pop-up message indicating that the limit has been exceeded.

[0105] The above resources are accurately mapped to the corresponding modules of the pre-set templates. During the population process, attention should be paid to "the core role of triplet annotations," "extracting key information from reference use cases," and "associating constraint rules with specific resources" to ensure that the large language model can accurately capture the core logic. The final target prompt words generated are as follows:

[0106] [Instruction Header] Based on the following test resources, generate test cases covering the entire scenario of the "Verify Single Transfer Exceedance Interception" test item, ensuring logical coherence and compliance with business rules.

[0107] [Core Information Area]

[0108] 1. Testing Requirements: Rule Requirements: The cumulative daily transfer amount for individual users must be ≤ 500,000 yuan. If this limit is exceeded, the system must intercept the transfer request and display an over-limit warning. Business Objective: Control financial risks and comply with financial regulatory requirements.

[0109] 2. Test Items and Verification Points: The test item is "Verify the interception of single transfer exceeding the limit"; the verification point is "When a user enters a single transfer amount of 600,000 yuan (>500,000 yuan limit), verify whether the system triggers the interception mechanism and displays the message 'Daily transfer limit is 500,000 yuan, please adjust the amount' in a pop-up window."

[0110] 3. Target triple set:

[0111] (Transfer scenario, including the daily limit of 500,000 yuan rule) - Core function: Define the core business rules for over-limit interception, and serve as the rule basis for verification points;

[0112] (Amount > 500,000 yuan, triggered, amount exceeds limit scenario) - Core function: Clarify the conditions for triggering edge scenarios, corresponding to the "input 600,000 yuan" operation in the verification point;

[0113] (For scenarios involving exceeding the limit, the account module is involved) — Core function: to specify the system module that performs the amount verification, and the operation steps must reflect the participation of the account module;

[0114] (Transfer scenario, derivative, amount exceeding limit scenario) - Core function: to confirm that this scenario is an edge scenario of the main transfer scenario, and a separate use case needs to be generated to cover it.

[0115] 4. Target Reference Use Case Summary: Reference use case TC-TR-021, the core scenario is "interception of single transfer exceeding the limit of 600,000 yuan", the key steps include "login to account module → input of payment information in account module → input of amount in account module → triggering interception", the expected result is "the system intercepts and pops up a message indicating that the limit has been exceeded".

[0116] [Constraint Rules Area]

[0117] 1. Scenario Coverage: It is necessary to cover "scenarios on the edge of exceeding the amount limit" (based on the triple (transfer scenario, derivative, scenario of exceeding the amount limit)) to ensure that no scenario is missed;

[0118] 2. Logical constraints: The operation steps must first execute the account module operation (such as login, input amount, verification), and then determine whether to trigger the interception (which conforms to the module association relationship of the triple (exceeding the amount limit scenario, involving the account module));

[0119] 3. Business Compliance: The expected result must include a "daily limit of 500,000 yuan" message and strictly comply with the business rules of the three-element system (transfer scenario, including the daily limit of 500,000 yuan).

[0120] Output Format Area

[0121] Each test case should be output in the following structure:

[0122] 1. Use case number: TC-TR-LIMIT-001 (TR = transfer, LIMIT = limit);

[0123] 2. Scene type: Edge scene;

[0124] 3. Test objective: To verify the over-limit blocking function when a single transfer amount is greater than 500,000 yuan, based on the triple (transfer scenario, including the daily limit of 500,000 yuan rule) and (amount > 500,000 yuan, triggered, over-limit scenario);

[0125] 4. Operation steps: Write them in the format of "step number + operation description + involved modules", and indicate the system module corresponding to each step;

[0126] 5. Expected Results: Describe in bullet points. Each result should be associated with the corresponding target triple and explain the business rules it complies with.

[0127] Furthermore, a pre-built large language model parses the target prompt words, identifying four key pieces of information: "core task (generating over-limit interception test cases)," "supporting resources (triplets, reference test cases)," "constraint rules (module order, scenario type)," and "output format (test case structure)," forming a "task list" for internal reasoning. For example, for the aforementioned over-limit interception prompt words, the model will extract the core instructions: "It is necessary to generate edge scenario test cases, the steps must include the account module, and the expected result must be associated with the limit triplet." Based on the "inclusion," "trigger," and "derive" relationships in the target triplet, the large language model infers the scope of scenarios that the test item must cover, ensuring no omissions. For example, the reasoning logic: starting from the trigger condition "amount > 500,000 yuan" (triplet 2), it associates "amount over-limit scenario" (edge ​​scenario), and then confirms the scenario level through "transfer scenario derives amount over-limit scenario" (triplet 4), ultimately determining that the test case must cover the edge scenario of "single amount over-limit," without needing to expand other scenarios (such as multiple cumulative over-limits, since the test item is clearly "single"). Using the "key steps" of the target reference test case as a template, and combining the entity relationships in the triples, generate logical operation steps; finally, according to the requirements of the "output format area" in the prompt, supplement the test case number, scenario type, test purpose, format the steps and expected results, and generate the final target test case.

[0128] like Figure 2 As shown, in one embodiment, after step S160, the following steps are included:

[0129] Step S210: Verify the target test cases across multiple test dimensions;

[0130] Step S221: If all test dimensions pass, the verification is successful;

[0131] Step S222: If any one of the test dimensions fails, the verification fails, and the reason for the failure is marked.

[0132] In this embodiment, based on a knowledge graph, the target test cases are validated across multiple testing dimensions to check whether they cover all inferred scenarios (test scenario coverage) and whether the operation steps conform to the relationships between entities (triple relationships).

[0133] For test scenario coverage: Target test cases are labeled with scenarios to determine the target business scenarios they cover. Target test scenarios include main business scenarios and peripheral scenarios. Based on the test item, all relevant test scenarios are queried in the test knowledge graph to obtain a standard test scenario list. The target test scenarios and the complete test scenario list are validated to determine if the target business scenario fully covers all test scenarios in the standard test scenario list. If yes, the validation passes; otherwise, it fails, and the reason for failure is marked as missing scenario coverage. For example, in the "transfer scenario," starting from the "transfer function test" test point, the list of scenarios to be covered is inferred through relationships such as "transfer scenario leading to excessive amount scenario" and "inputting excessive amount triggering excessive limit scenario," including main scenarios (normal transfer: normal transfer within the same bank, normal transfer across banks) and peripheral scenarios (excessive amount, insufficient balance, interface timeout retries, holiday arrival delays). If the test case set does not contain any scenario in the "inferred scenario list" (e.g., the "holiday arrival delay" scenario is missing), it is determined as "missing scenario coverage," and the validation fails.

[0134] For triple relationships: Parse the target test case to identify the triples within it, obtaining the set of validation triples contained in the target test case. For each triple in the validation triple set, query the test knowledge graph to determine if each triple conforms to the corresponding entity relationship. If yes, the validation passes; otherwise, it fails, and the reason for failure is marked as a relationship violation. For example, taking a money transfer scenario, the set of triple relationships to be extracted is as follows:

[0135] |Rule inclusion relationship| (Transfer scenario, includes daily limit of 500,000 yuan), (Transfer scenario, includes rule of 3 retries for interface timeout)|Whether the validation test case follows the business rules (e.g., whether to block if the amount exceeds the limit, whether to retries if the interface times out)|

[0136] |Module Triggering Relationship| (Account Module, Trigger, Payment Module), (Payment Module, Dependency, Log Module) |Module call order for verification operation steps (e.g., whether the account module verification is executed first, and then the payment module is called)|

[0137] |Module Derivation Relationship| (Transfer scenario, derived from, notification module), (API timeout scenario, derived from, logging module) | Does the verification scenario include interactions with related modules (e.g., whether the notification module is called to push a receipt after a successful transfer, whether the logging module is called to record API timeout)?|

[0138] If any use case step violates the triple relationship (such as "the payment module operation did not execute the account module verification first" or "the log module was not called in the interface timeout scenario"), it is judged as "relationship violation" and marked as verification failure; only when all steps meet the triple relationship and no scenario is omitted, it is judged as verification success.

[0139] This method acquires historical test data and uses a pre-trained recognition model to identify and extract entities and their corresponding entity relationships from the historical test data. Based on the entities and their corresponding entity relationships, the data is stored in the form of triples to obtain multiple standard triples, and a test knowledge graph is constructed based on these standard triples. The method receives the test document for the current test project, parses the test document, and determines the test requirements and test items. Based on the test requirements and test items, the corresponding standard triples and reference test cases are matched from the knowledge graph and a pre-set test case library to obtain a target triple set and target reference test cases. The test requirements, test items, target triple set, and target reference test cases are filled into a pre-set prompt word template to obtain target prompt words. The target prompt words are input into a pre-trained large language model to generate test cases, resulting in target test cases. This method determines the set of triples related to the current test project through the association reasoning of the constructed test knowledge graph. It then integrates test requirements, test items, target triple sets, and target reference test cases to fill the pre-set prompt word template to generate target prompt words. Based on the target prompt words, the method generates target test cases through a large language model, which makes the scenario coverage of the test cases output by the large language model higher. In addition, the supplementary constraints based on the target triple set can also improve the logical coherence of the test cases.

[0140] This invention also provides a test case generation apparatus based on business scenarios, which is used to execute any embodiment of the aforementioned test case generation method based on business scenarios. Specifically, please refer to... Figure 3 , Figure 3 This is a schematic block diagram of a test case generation device based on a business scenario provided in an embodiment of the present invention. The test case generation device 100 based on the business scenario can be configured in a server.

[0141] like Figure 3 As shown, the test case generation device 100 based on business scenarios includes an extraction module 110, a graph construction module 120, a parsing module 130, a matching module 140, a filling module 150, and a generation module 160.

[0142] Extraction module 110 is used to acquire historical test data and identify and extract each entity and its corresponding entity relationship in the historical test data through a pre-trained recognition model. The historical test data includes at least historical test cases, test documents and user behavior logs. The entities include business scenarios, business rules, user behaviors, system modules and edge scenario triggering conditions. The entity relationships include at least inclusion, triggering and derivation.

[0143] The graph construction module 120 is used to store the entities and their corresponding entity relationships in the form of triples to obtain multiple standard triples, and to construct a test knowledge graph based on the standard triples. Each triple includes two entities and their corresponding entity relationships.

[0144] The parsing module 130 is used to receive the test document of the current test project, parse the test document, and determine the test requirements and test items of the test document;

[0145] The matching module 140 is used to match the corresponding standard triples and reference test cases from the knowledge graph and the preset test case library based on the test requirements and test items, respectively, to obtain the target triple set and the target reference test cases;

[0146] The filling module 150 is used to fill the test requirements, test items, target triplet set and target reference test cases into a preset prompt word template to obtain target prompt words;

[0147] The generation module 160 is used to input the target prompt word into a pre-trained large language model to generate test cases and obtain target test cases.

[0148] In one embodiment, the test case generation device 100 based on business scenarios further includes:

[0149] The verification module is used to verify the target test case in multiple test dimensions, including test scenario coverage and triplet relationships. If all test dimensions pass, the verification is successful; if any test dimension fails, the verification fails and the reason for failure is marked.

[0150] In one embodiment, the verification module includes:

[0151] The scene annotation unit is used to annotate the target test cases and determine the target business scenarios covered by the target test cases. The target test scenarios include main business scenarios and edge scenarios.

[0152] The query unit is used to query all related test scenarios in the test knowledge graph based on the test item to obtain a list of standard test scenarios.

[0153] The scenario verification unit is used to verify the target test scenario and the complete test scenario list, and to determine whether the target business scenario completely covers all test scenarios in the standard test scenario list; if yes, the verification passes; if no, the verification fails, and the failure reason is marked as scenario coverage missing.

[0154] In one embodiment, the verification module further includes:

[0155] The triplet parsing unit is used to parse the target test case, determine the triples in the target test case, and obtain the set of verification triples contained in the target test case.

[0156] The triplet query unit is used to query the test knowledge graph for each triple in the verification triplet set to determine whether each triple in the verification triplet set conforms to the corresponding entity relation; if yes, the verification passes; if no, the verification fails and the reason for failure is marked as relation violation.

[0157] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the business scenario-based test case generation method described above.

[0158] In another embodiment of the invention, a computer-readable storage medium is provided. This computer-readable storage medium may be a non-volatile computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the business scenario-based test case generation method as described above.

[0159] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0160] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0161] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0162] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0163] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.

[0164] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A test case generation method based on business scenarios, characterized in that, include: Historical test data is acquired, and entities and corresponding entity relationships in the historical test data are identified and extracted through a pre-trained recognition model. The historical test data includes at least historical test cases, test documents, and user behavior logs. The entities include business scenarios, business rules, user behaviors, system modules, and edge scenario triggering conditions. The entity relationships include at least inclusion, triggering, and derivation. Based on the entities and their corresponding entity relationships, the data is stored in the form of triples to obtain multiple standard triples. A test knowledge graph is then constructed based on the standard triples. Each triple includes two entities and their corresponding entity relationships. Receive the test document for the current test project, parse the test document, and determine the test requirements and test items in the test document; Based on the test requirements and test items, the corresponding standard triple set and reference test cases are matched from the knowledge graph and the pre-set test case library to obtain the target triple set and target reference test cases. The test requirements, test items, target triplet set, and target reference test cases are filled into the preset prompt word template to obtain the target prompt words; The target prompt words are input into a pre-trained large language model to generate test cases, thus obtaining the target test cases.

2. The test case generation method based on business scenarios as described in claim 1, characterized in that, The step of inputting the target prompt word into a pre-trained large language model to generate test cases, and obtaining the target test cases, includes: The target test cases are validated across multiple test dimensions, including test scenario coverage and triplet relationships. If all test dimensions pass, the verification is successful; If any one of the test dimensions fails, the validation fails, and the reason for the failure is marked.

3. The test case generation method based on business scenarios as described in claim 2, characterized in that, The verification of the target test cases across multiple test dimensions includes: The target test cases are labeled with scenarios to determine the target business scenarios covered by the target test cases. The target test scenarios include main business scenarios and edge scenarios. Based on the test item, query all related test scenarios in the test knowledge graph to obtain a list of standard test scenarios; Verify the target test scenario and the complete test scenario list to determine whether the target business scenario completely covers all test scenarios in the standard test scenario list; If so, the verification passes; If not, the verification fails, and the reason for failure is marked as missing scene coverage.

4. The test case generation method based on business scenarios as described in claim 2, characterized in that, The verification of the target test cases across multiple test dimensions also includes: The target test case is parsed to determine the triples in the target test case, thus obtaining the set of validation triples contained in the target test case; For each triple in the set of verification triples, query the test knowledge graph to determine whether each triple in the set of verification triples conforms to the corresponding entity relationship. If so, the verification passes; If not, the validation fails, and the failure is marked as a relationship violation.

5. A test case generation device based on business scenarios, characterized in that, include: An extraction module is used to acquire historical test data and identify and extract entities and corresponding entity relationships in the historical test data through a pre-trained recognition model. The historical test data includes at least historical test cases, test documents, and user behavior logs. The entities include business scenarios, business rules, user behaviors, system modules, and edge scenario triggering conditions. The entity relationships include at least inclusion, triggering, and derivation. The knowledge graph construction module is used to store the entities and their corresponding entity relationships in the form of triples to obtain multiple standard triples, and to construct a test knowledge graph based on the standard triples. Each triple includes two entities and their corresponding entity relationships. The parsing module is used to receive the test document of the current test project, parse the test document, and determine the test requirements and test items of the test document; The matching module is used to match the corresponding standard triples and reference test cases from the knowledge graph and the pre-set test case library based on the test requirements and test items, respectively, to obtain the target triple set and the target reference test cases; The fill module is used to fill the test requirements, test items, target triplet set and target reference test cases into the preset prompt word template to obtain the target prompt words; The generation module is used to input the target prompt words into a pre-trained large language model to generate test cases and obtain target test cases.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test case generation method based on any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the test case generation method based on any one of claims 1 to 4.

Images