Test case generation method and device and medium

Abstract

The invention provides a test case generation method and device and a medium, and relates to the technical field of computers. The method comprises the following steps: receiving an instruction for indicating to generate a test case, and obtaining a test role and a test task according to the instruction; querying a preset metadatabase according to the test role and the test task to obtain first test steps required by the test role to complete the test task and a dependency relationship between the first test steps; querying a preset graph database according to the metadata to generate a test case graph, nodes in the test case graph representing the first test steps, and edges representing a dependency relationship between the first test steps; and generating a test case according to the test case graph. According to the method and the device, the roles are automatically associated, the test case is generated by the visual test case graph, and the test case generation quality is improved.

Description

Technical Field

[0001] This application relates at least to the field of computer technology, and in particular to a test case generation method, apparatus and medium. Background Technology

[0002] Existing test case generation technologies mainly revolve around building static test case libraries. They rely on preset templates or manual writing of test cases, lacking technical solutions for automatic role and permission verification and visual display of test steps and their dependencies. This makes it difficult to generate accurate test cases when dealing with complex business systems. Summary of the Invention

[0003] To address the aforementioned shortcomings, this application provides a test case generation method, apparatus, and medium to solve the following technical problem: how to generate accurate test cases.

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

[0005] Receive instructions to generate test cases, and obtain test roles and test tasks according to the instructions;

[0006] Based on the test role and test task, query the preset metadata database to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps;

[0007] The first test case graph is generated by querying a preset graph database based on the metadata. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between at least some of the first test steps.

[0008] The system visualizes the first test case diagram, receives the second test case diagram modified from the first test case diagram, and generates test cases based on the second test case diagram.

[0009] Furthermore, it receives instructions to generate test cases, and obtains test roles and test tasks based on these instructions, specifically including:

[0010] Receive natural language instructions to generate test cases, and identify the test roles and first test tasks contained in the natural language instructions.

[0011] Furthermore, it receives natural language instructions to generate test cases, identifies the test roles and the first test task contained in the natural language instructions, specifically including:

[0012] The user interface layer provides a natural language command input box to the tester's terminal, and the user interface layer obtains the natural language instructions entered by the tester's terminal into the natural language command input box.

[0013] It is set up in the core engine layer of the application server to receive natural language instructions from the user interface layer, and uses its own pre-trained language model to identify the test role and the first test task contained in the natural language instructions.

[0014] Furthermore, based on the test role and test task, a pre-defined metadata database is queried to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps, specifically including:

[0015] Query the preset metadata database to obtain the second test task that has a first conditional dependency relationship with the first test task, obtain the second test step that belongs to the first test task and the second test task, filter the first test steps that meet the test permissions of the test role from the second test steps, obtain the first temporal dependency relationship and the first data dependency relationship between the first test steps, obtain the cost weight and coverage weight of the first test step to the first test task, and obtain the dependency weights of the first conditional dependency relationship, the first temporal dependency relationship and the first data dependency relationship;

[0016] The pre-defined metadata database stores test steps written by testers, test tasks to which the test steps belong, conditional dependencies between test tasks, test roles with test permissions for the test steps, temporal dependencies and data dependencies between test steps. Data dependencies include the output parameter flow relationship between test steps, the cost weight and coverage weight of test steps for different test tasks, and the dependency weights of each conditional dependency, temporal dependency and data dependency.

[0017] Furthermore, a pre-defined graph database is queried based on metadata to generate a first test case graph. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between these first test steps, specifically including:

[0018] The system queries a pre-defined graph database to obtain the pre-defined test coverage requirements and path optimization algorithms for the first test task. It generates nodes from the first test steps, and generates edges between nodes based on the first conditional dependency, the first temporal dependency, and the first data dependency. It obtains the cost weight and coverage weight of each node based on the cost weight and coverage weight of the first test steps for the first test task. It also obtains the dependency weight of each edge based on the dependency weights of the first conditional dependency, the first temporal dependency, and the first data dependency. With the goal of achieving the test coverage requirement by summing the coverage weights, reducing the sum of cost weights, and increasing the sum of dependency weights, the system uses a path optimization algorithm to obtain the first test case graph.

[0019] Furthermore, with the goals of achieving test coverage requirements by summing coverage weights, reducing cost weights by summing cost weights, and increasing dependency weights by summing dependency weights, a path optimization algorithm is used to obtain the first test case graph, specifically including:

[0020] Obtain the top N first nodes with the highest coverage weights, where the sum of the coverage weights of the top N first nodes is less than the test coverage requirement.

[0021] For each of the top N first nodes, add the node with the lowest cost weight connected to the first node and / or the node connected by the edge with the highest dependence weight. Check whether the sum of the coverage weights of the added node and the top N first nodes meets the test coverage requirement. If not, continue adding nodes. If yes, obtain the first test case graph.

[0022] Furthermore, a pre-defined graph database is queried based on metadata to generate a first test case graph. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between these first test steps. Specifically, this also includes:

[0023] If a third test case graph for a first test task or a partial subtask of a second test task is found in the preset graph database, nodes and edges are no longer generated for the partial subtasks. Instead, the nodes and edges of the remaining subtasks are directly connected using the third test case graph. The first test task includes several subtasks contained in the instruction, and the second test task includes several subtasks corresponding to different first condition dependencies.

[0024] Furthermore, the system visualizes the first test case diagram, receives a second test case diagram modified from the first, and generates test cases based on the second test case diagram, specifically including:

[0025] The system displays the first test case diagram visually to the tester's terminal, receives modifications and confirmations from the tester's terminal regarding the first test case diagram, and obtains the second test case diagram.

[0026] Test cases are generated based on the second test case diagram, and the test cases are sent to the test role terminal so that the test role can test the test cases.

[0027] Secondly, this application provides a test case generation apparatus, the apparatus comprising:

[0028] The instruction recognition unit is used to receive instructions to generate test cases and to obtain test roles and test tasks based on the instructions.

[0029] The metadata query unit, connected to the instruction identification unit, is used to query a preset metadata database based on the test role and test task to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps.

[0030] The graph generation unit is connected to the metadata query unit and is used to query a preset graph database based on the metadata to generate a first test case graph. The nodes in the first test case graph represent at least some of the first test steps, and the edges represent at least some of the first dependencies between the at least some of the first test steps.

[0031] The test case generation unit, connected to the graph generation unit, is used to visualize the first test case graph, receive the second test case graph modified from the first test case graph, and generate test cases based on the second test case graph.

[0032] Thirdly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the test case generation method described above.

[0033] This application provides a test case generation method, apparatus, and medium. By obtaining the test roles and test tasks of test case instructions, and using a preset metadata database and graph database, a test case graph including test steps and dependencies is generated. Test cases are generated based on the test case graph, thereby automatically associating roles and generating test cases with a visualized test case graph, thus improving the quality of test case generation. Attached Figure Description

[0034] Figure 1 This is a flowchart of a test case generation method according to an embodiment of this application;

[0035] Figure 2 This is a schematic diagram of the structure of a test case generation device according to an embodiment of this application;

[0036] Figure 3 This is a hierarchical architecture diagram of a test case intelligent management system according to an embodiment of this application;

[0037] Figure 4 This is a component device architecture diagram of a test case intelligent management system according to an embodiment of this application;

[0038] Figure 5 This is a flowchart of another test case generation method proposed in the embodiments of this application. Detailed Implementation

[0039] To enable those skilled in the art to better understand the technical solution of this application, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0040] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining this application and are not intended to limit this application.

[0041] It is understood that, without conflict, the various embodiments and features in the embodiments of this application can be combined with each other.

[0042] It is understood that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, while parts unrelated to this application are not shown in the drawings.

[0043] It is understood that each module or unit involved in the embodiments of this application may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple modules or units may be integrated into one entity structure.

[0044] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this application may occur in a different order than that marked in the accompanying drawings.

[0045] It is understood that the flowcharts and block diagrams of this application illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, unit, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using a hardware-based device to implement the specified function, or using a combination of hardware and computer instructions.

[0046] It is understood that the modules and units involved in the embodiments of this application can be implemented by software or by hardware. For example, the modules and units can be located in the processor.

[0047] Example 1:

[0048] like Figure 1 As shown, this application provides a test case generation method, the method comprising:

[0049] S1. Receive instructions to generate test cases, and obtain test roles and test tasks according to the instructions;

[0050] S2. Query the preset metadata database based on the test role and test task to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps;

[0051] S3. Query the preset graph database based on the metadata to generate the first test case graph. The nodes in the first test case graph represent at least some of the first test steps, and the edges represent at least some of the first dependencies between the at least some of the first test steps.

[0052] S4. Visualize the first test case diagram, receive the second test case diagram modified from the first test case diagram, and generate test cases based on the second test case diagram.

[0053] In this embodiment, the method obtains the test roles and test tasks of test case instructions, generates a test case graph including test steps and dependencies using a preset metadata database and graph database, and generates test cases based on the test case graph. This achieves automatic role association and generates test cases with a visualized test case graph, improving the quality of test case generation. Figure 1 The method shown is applied to, for example Figure 2 The apparatus shown.

[0054] Specifically, this embodiment provides a method and system for intelligent generation and dynamic management of test cases for an honor system based on Text2SQL (text to SQL language) and DAG (Directed Acyclic Graph).

[0055] The Honors System is used to manage various honor-related matters within an enterprise. It encompasses functions such as honor configuration, entry and management of individual and group honors, departmental performance evaluation information, and honor dashboard display. It sets corresponding operation permissions for different roles (such as super administrators, line administrators, and company leaders) to achieve standardized management of the entire honor lifecycle. The Honors System involves multi-role permissions, complex business logic (such as the association between honor configuration and individual / group honor entry, and deduplication verification), and its functions are frequently iterated (such as adding batch activation functionality for the "HR review" role). Existing technologies have shortcomings in dependency modeling, natural language interaction, and test case generation efficiency, making it difficult to meet system testing requirements. Therefore, dedicated test case management is needed to ensure the correctness and stability of the system's functions. Honors System test cases are used for: importing and entering honor configurations, entering and verifying individual / group honors, testing operations with different role permissions, and testing the display of honor dashboard data. The requirements for the test management system include: accurately modeling the dependencies between test steps, supporting the rapid generation and retrieval of test cases through natural language, efficiently updating test cases when system functions change, and ensuring that tests cover all critical business logic and permission scenarios.

[0056] In the field of honor system test case management, existing technologies mainly revolve around the construction of static test case libraries and basic dependency management. They typically use relational databases to store test step metadata, and test cases are written manually or using pre-set templates. Dependency types only support simple temporal relationships, lacking explicit modeling of data dependencies and conditional dependencies. For example, maintaining test steps through static tables can only record the execution order of steps and cannot dynamically resolve complex business rules such as "when a line administrator adds an honor, the line's permissions must be verified," leading to implicit dependencies and making it easy to overlook permission verification logic during test case maintenance.

[0057] In terms of natural language interaction, early Text2SQL technology focused on single-table queries or general domain semantic parsing, without optimization for testing scenarios. For example, while intelligent testing tools support natural language retrieval of test steps, they can only match simple statements such as "query steps containing 'honor configuration'", and cannot handle complex queries involving multiple dependencies, such as "find the 'add personnel honor' step executed by the line administrator after the 'configure honor' step". This makes it difficult to meet the testing needs of hierarchical permissions in the honor system (such as the differences in operation permissions between roles like super administrator and line administrator).

[0058] In test case generation and reorganization technologies, traditional methods rely on manual step assembly or generation based on fixed process templates, lacking intelligent analysis of dynamic dependencies between steps. For example, when a new "batch activation" function is added to an honor system, existing solutions require manual adjustment of the step order of related test cases. They cannot automatically identify the data dependency between "batch activation of human review roles" and "incentive status update" through algorithms, resulting in low test case generation efficiency and insufficient coverage. Furthermore, for role-permission-related test scenarios (such as leaders only being able to view all data but lacking operational permissions), existing technologies cannot automatically associate role scope with step visibility through models, requiring the repeated writing of similar test cases, leading to high maintenance costs.

[0059] In summary, existing technologies have significant shortcomings in complex business dependency modeling, natural language semantic parsing, and dynamic test case generation. They are particularly difficult to adapt to the testing requirements of multi-role permission verification and high-frequency function changes in the Honor system. There is an urgent need for an intelligent test case management solution that integrates natural language processing and graph computing technologies.

[0060] This embodiment provides a Text2SQL+DAG integrated architecture for test case management in an honor system. The core of this architecture lies in modeling the dependencies between test steps using a Directed Acyclic Graph (DAG) and combining it with natural language processing technology to achieve intelligent generation and reorganization of test cases. The system architecture is shown in Figure 3.

[0061] like Figure 3 The architecture shown is explained below:

[0062] User Interface Layer: Provides a natural language input box and a visual DAG editing tool, enabling testers to intuitively manage test step nodes and dependencies. The natural language input box allows testers to enter query commands (such as "query the test steps for adding honors to the line administrator"). After processing by the Text2SQL parser, the system displays the corresponding test steps and their dependencies in the visual DAG editing tool. Testers can intuitively view and modify the node attributes and dependencies of these test steps in the editing tool, achieving visual management and adjustment of test cases.

[0063] Core engine layer:

[0064] The Text2SQL parser uses a BERT (Bidirectional Encoder Representations from Transformers, a pre-trained language model) fine-tuned model to parse natural language queries, generating corresponding SQL (Structured Query Language) statements or DAG path queries (e.g., converting "find the steps the line administrator performs after configuring honors" into a graph database query). It generates corresponding SQL statements or DAG path queries based on natural language queries, thereby retrieving relevant execution step information from the database. This step information can be graphically displayed in visualization tools for easy understanding and use by testers.

[0065] The DAG management engine maintains a step node library (storing honor system test steps, such as "Configure Honors" and "Add Personnel Honors") and defines three types of dependencies—time-sequence, data-sequence, and condition-sequence—through a dependency manager (e.g., the "Add Personnel Honors" step depends on the output variable "Line ID" of the "Configure Honors" step). "Test steps" refer to operational steps designed to verify system functionality; they are not actual operations of adding honors to personnel. Their purpose is to test whether the system functions correctly through simulated operations. Time-sequence dependencies refer to the order in which steps are executed. For example, "Configure Honors" must be performed before "Add Personnel Honors" can be done. The DAG management engine ensures the rationality of the test process by defining this order.

[0066] Test Case Generator: Based on the DAG path planning results, it dynamically combines test steps to generate executable test cases (e.g., filtering steps by role permissions to generate test cases containing only steps operable by line administrators). Path planning is performed by the path planner in the DAG management engine. The path planner plans the optimal test step execution path from the starting point (e.g., "Login to the system") to the ending point (e.g., "Batch deletion successful") based on the test objective (e.g., verifying the function of super administrators to batch delete honors), combined with the dependencies and node weights between test steps. The test case generator then dynamically combines test steps to generate test cases based on this path.

[0067] Data storage layer: A relational database stores step metadata (such as step description and module to which it belongs), and a graph database stores the DAG structure (nodes represent test steps, and edges represent dependencies). The "to which it belongs" module here is equivalent to a test task, such as belonging to the honor configuration module, personal honor management module, collective honor management module, honor dashboard module, or permission management module. These modules correspond to different functional parts of the honor system. Step metadata is assigned to the corresponding module based on its relevant function. The natural language understanding module, based on natural language instructions such as "create test cases for line administrators to add honors," identifies test tasks containing "add honors," the role of "line administrator," and determines that this first test task contains several first sub-tasks, i.e., the multiple modules listed above.

[0068] The entire implementation process of the method in this embodiment may include the following stages:

[0069] Phase 1: Establish a basic step library and simple temporal dependencies to quickly build a basic framework for test case management and achieve preliminary structured storage of test steps.

[0070] Phase 2: Implement basic Text2SQL query functionality, supporting the retrieval of test steps and modules through natural language, and improving the convenience of test case management.

[0071] Phase 3: Introduce a complete DAG model to support data and condition dependencies and improve the ability to model complex dependencies between test steps.

[0072] Phase 4: Implement path planning and automatic test case generation to achieve the goal of intelligent test case management.

[0073] This embodiment defines initial test cases and test steps, constructs a Text2SQL+DAG fusion architecture, and leverages technologies such as natural language parsing and path planning to intelligently generate new test cases when system functions change or new testing requirements arise, improving the efficiency of test case generation and maintenance flexibility. Figure 3The test case intelligent management system shown is in a test-and-tested relationship with the honor system, used to ensure the correct operation of the honor system. Complex scenarios include: test scenarios with overlapping multi-role permissions (such as a leader viewing the honors configured by a line administrator), business process test scenarios with multiple dependencies (time sequence, data, conditions) (such as a process where a super administrator configures the line administrator's identity → the line administrator configures honors → the line administrator adds honors to members → human review), and test case update scenarios during high-frequency system iterations. These scenarios involve complex dependencies and role interactions.

[0074] In one embodiment, S1, receiving an instruction to generate test cases, and obtaining test roles and test tasks according to the instruction, specifically including:

[0075] Receive natural language instructions to generate test cases, and identify the test roles and first test tasks contained in the natural language instructions.

[0076] This embodiment addresses the following shortcomings of the prior art:

[0077] Insufficient dependency modeling capabilities: Existing honor system test case management technologies mostly use static tables or relational databases to store test steps, supporting only simple temporal dependencies and failing to effectively model complex business logic. For example, when processing line administrators adding honors, it is difficult to clearly define the data dependency between the "configure honors" and "add honors to personnel" steps, as well as the conditional dependency that "added honors must be limited to this line," resulting in test cases failing to accurately cover permission verification logic and easily missing key test points. This embodiment can achieve the following: the "configure honors" step sets the award, including key data such as award name, awarding unit, and line; when "add honors to personnel," the added honor must be an award already entered in "configure honors," and the honor added by the line administrator must be limited to this line.

[0078] Weak Natural Language Interaction Capabilities: Traditional Text2SQL technology is mainly applied to general domains or single-table queries, lacking targeted optimization for test scenarios. In the testing of the honor system, it is difficult to understand complex natural language queries involving multiple dependencies and role permissions, such as "finding the steps a leader can perform after the line administrator completes the honor configuration." Testers struggle to quickly retrieve and generate test cases that meet the requirements using natural language, resulting in low interaction efficiency. This embodiment can achieve the following: Leaders have the permission to query all honors, but it is necessary to clarify what viewing steps the leader can perform after the line administrator completes the specific operation of honor configuration. This ensures that the leader can accurately obtain relevant honor information, while verifying whether the system's control over the operation permissions of different roles in the business process is correct, ensuring the accuracy of role permission logic.

[0079] Low efficiency in test case generation and maintenance: When the functionality of the honor system changes (such as adding a "batch activation" function or adjusting role permissions), the existing solution relies on manual adjustment of the test case steps and content, and cannot automatically identify the dynamic dependencies between steps. At the same time, there is a lot of repetitive writing of test cases corresponding to different role permissions, making it difficult to reuse existing test resources, resulting in high test case maintenance costs and easy omissions, which cannot meet the testing needs of frequent system iterations.

[0080] This embodiment provides a Text2SQL+DAG integrated architecture to address the problems of inaccurate dependency modeling, insufficient natural language interaction capabilities, and low efficiency in test case generation and maintenance in existing honor system test case management. By constructing a dynamic dependency model, it achieves explicit expression of temporal, data, and conditional dependencies between test steps, ensuring that test cases fully cover complex business logic. Utilizing an enhanced Text2SQL parser, it supports domain-specific semantic understanding, achieving accurate mapping between natural language and test steps, lowering the operational threshold for testers. Combined with DAG path planning and dynamic combination strategies, it automatically generates optimal test paths and test cases, quickly identifying reusable parts when requirements change, improving test case generation efficiency and maintenance flexibility. This meets the testing requirements of the honor system for multi-role permission verification and high-frequency function iteration, improving test quality and efficiency. Specifically, after parsing, the natural language query, combined with step dependencies and role permissions in the DAG, generates complete test cases containing preconditions and main test steps, meeting the multi-role permission verification requirements of the honor system.

[0081] In one embodiment, receiving a natural language instruction to generate test cases, and identifying the test role and first test task contained in the natural language instruction, specifically includes:

[0082] The user interface layer provides a natural language command input box to the tester's terminal, and the user interface layer obtains the natural language instructions entered by the tester's terminal into the natural language command input box.

[0083] It is set up in the core engine layer of the application server to receive natural language instructions from the user interface layer, and uses its own pre-trained language model to identify the test role and the first test task contained in the natural language instructions.

[0084] In this embodiment, as Figure 4 The system diagram shown illustrates the system's deployment in the physical environment and the interactions between its components. The device is described below:

[0085] User Terminal: Testers access the system via a browser on a PC or mobile device, inputting natural language queries or performing DAG visualization operations. The user terminal communicates with the server via the HTTP protocol. Testers can retrieve test cases and test steps by inputting natural language queries in the browser; use the visual DAG editing tool to view, create, and modify test step nodes and their dependencies; view generated test cases and execute tests; and view test execution results, etc.

[0086] Load balancer: Receives all requests from user terminals and distributes them to web servers according to preset load balancing strategies (such as round-robin and least connections), ensuring the rational utilization of server resources and improving system availability and response speed.

[0087] Web server: Responsible for handling HTTP requests, parsing user input, forwarding requests to application servers via API interfaces, receiving results returned by application servers, converting them into a format suitable for display in a browser (such as HTML or JSON), and returning them to the user terminal.

[0088] Application Server: This server hosts the core engine layer's functionalities, including a Text2SQL parser, a DAG management engine, and a test case generator. It receives API calls from the web server and executes core business logic such as natural language parsing, DAG path planning, and test case generation. Based on business requirements, it requests step metadata from a relational database server and DAG structure data from a graph database server, returning the processing results to the web server. Metadata and graph structure data are different representations of the same business execution steps. Step metadata provides a detailed description of the test steps (such as step descriptions, input / output parameters, etc.) and is stored in the relational database. Graph structure data represents test steps and their dependencies in the form of nodes and edges and is stored in the graph database. When processing business logic, the application server combines both to complete functions such as test case generation and management.

[0089] A relational database server is deployed using PostgreSQL to store metadata about the steps in the Honor System test cases, such as step descriptions, modules, and input / output parameters. The application server interacts with this server via SQL statements to perform data queries, insertions, updates, and deletions. When certain test steps are obsolete, no longer applicable, or contain errors that cannot be modified, their information needs to be removed from the step metadata to ensure the accuracy and validity of the data in the database and avoid interfering with the generation of test cases.

[0090] Graph Database Server: Deploys Neo4j database to specifically store DAG structure data, including test step nodes and dependency edges between nodes; the application server interacts with this server through a graph database query language (such as Cypher) to create, traverse, and update the DAG, providing data support for path planning; initially created by the testing team based on the business logic and testing requirements of the honor system, the testing team defines the initial test step nodes, node attributes, and dependencies between steps, and records them into the graph database. Subsequently, as system functions change and testing requirements evolve, testers or the system automatically updates and maintains this data.

[0091] In one embodiment, S2, based on the test role and test task, a preset metadata database is queried to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps, specifically including:

[0092] Query the preset metadata database to obtain the second test task that has a first conditional dependency relationship with the first test task, obtain the second test step that belongs to the first test task and the second test task, filter the first test steps that meet the test permissions of the test role from the second test steps, obtain the first temporal dependency relationship and the first data dependency relationship between the first test steps, obtain the cost weight and coverage weight of the first test step to the first test task, and obtain the dependency weights of the first conditional dependency relationship, the first temporal dependency relationship and the first data dependency relationship;

[0093] The pre-defined metadata database stores test steps written by testers, test tasks to which the test steps belong, conditional dependencies between test tasks, test roles with test permissions for the test steps, temporal dependencies and data dependencies between test steps. Data dependencies include the output parameter flow relationship between test steps, the cost weight and coverage weight of test steps for different test tasks, and the dependency weights of each conditional dependency, temporal dependency and data dependency.

[0094] This embodiment provides a specific implementation example of a Text2SQL enhanced parser:

[0095] 1) Semantic parsing rule extension: To address the permission verification requirements of the honor system, new natural language mapping rules have been added:

[0096] RULES = [

[0097] {

[0098] "pattern": r"(Generate|Create).*Line Administrator.*(Add|Add).(Individual|Group)Honor.*Test Case",

[0099] SQL: """

[0100] MATCH (start:Step {desc:'Configure honors for this line'})-[r:DEPENDS_ON]->(end:Step {desc:'Add personnel honors'})

[0101] WHERE start.role_scope CONTAINS 'line_manager' ANDend.role_scope CONTAINS 'line_manager'

[0102] RETURN start, end

[0103] """

[0104] } ]

[0106] According to the above rules, the system will first parse the role information of "line administrator" in natural language, combine it with the role permission data defined in the system to identify the identity of the administrator, and then generate corresponding test cases based on the identity and query content (such as "add personal honor test case").

[0107] 2) Example of complex path query: When a user enters "Query the steps that a leader can take after the line administrator completes the honor configuration", the parser executes the following steps:

[0108] Entity extraction: Identify "Leader" (role), "Configure Honors" (preliminary step), and "View Steps" (postliminary step);

[0109] Conditional constraints: The generated graph query statement filters node roles to include "leadership" and specifies that the preceding step in the path is "configure honors". The user-input statement must contain key entity information (such as role, preceding step, and subsequent step) so that the system can accurately extract entities and apply conditional constraints. If the statement lacks necessary information, the system may not be able to generate the query results correctly, and the user may need to be prompted to provide the relevant information.

[0110] Results returned: The returned path (e.g., "Configure Honors" → "View Honor Distribution") represents the sequence of steps a leader can execute after the line administrator completes the honor configuration. These results can be used to generate corresponding test cases to verify whether the leader can correctly perform the viewing operation in this scenario, ensuring the correctness of system role permissions and business processes.

[0111] In one embodiment, S3, a preset graph database is queried based on metadata to generate a first test case graph. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between the at least some of the first test steps. Specifically, this includes:

[0112] The system queries a pre-defined graph database to obtain the pre-defined test coverage requirements and path optimization algorithms for the first test task. It generates nodes from the first test steps, and generates edges between nodes based on the first conditional dependency, the first temporal dependency, and the first data dependency. It obtains the cost weight and coverage weight of each node based on the cost weight and coverage weight of the first test steps for the first test task. It also obtains the dependency weight of each edge based on the dependency weights of the first conditional dependency, the first temporal dependency, and the first data dependency. With the goal of achieving the test coverage requirement by summing the coverage weights, reducing the sum of cost weights, and increasing the sum of dependency weights, the system uses a path optimization algorithm to obtain the first test case graph.

[0113] This embodiment provides a specific implementation example of DAG model design:

[0114] 1) Taking the scenario of "line administrators adding personal honors" in the honor system as an example, the node attributes are defined as follows:

[0115] {

[0116] "step_id": "S01-002-01",

[0117] "desc": "Configure honors for this line",

[0118] "type": "precondition",

[0119] "module": "honor_config",

[0120] "input_params": ["line_id"], / / Line ID (e.g., "Marketing Line")

[0121] "output_vars": ["valid_honor"], / / List of valid honors

[0122] "role_scope": ["line_manager"], / / Applicable role: Line manager

[0123] "dependency_type": ["data"] / / Data dependency, output for subsequent steps.

[0124] }

[0125] The above is primarily defined by the testing team based on the business rules, testing scenarios, and requirements of the honor system. The testing team is familiar with the system's functions and testing points, and can accurately set node attributes (such as step ID, description, role scope, etc.) to meet the needs of test case generation and management. A "line" refers to a business department or functional line within the enterprise with different management needs and business scopes, such as the labor union, Party affairs, Youth League, discipline inspection, human resources, marketing, and network. In the honor system, line administrators can only handle honor-related matters within their designated line.

[0126] 2) Dependency modeling defines the data dependency between the "Configure Honors" and "Add Personnel Honors" steps:

[0127] {

[0128] "source_node": "S01-002-01", / / Prerequisite step: Configure Honor

[0129] "target_node": "S01-002-02", / / Post-processing: Add personnel honors

[0130] "type": "data",

[0131] "condition": "line_id = current_line", / / Condition: Matching line ID

[0132] "weight": 1.0 / / Dependency weight (used for path planning priority)

[0133] }

[0134] Dependencies are predefined by the testing team based on business logic, clearly defining data, timing, and conditional dependencies between steps. "weight: 1.0" represents the weight of the dependency from "configure honors" to "add personnel honors." Higher-weight dependencies have higher priority in path selection, thus influencing the determination of the optimal path. For example, among multiple possible paths, the path containing a high-weight dependency may be selected first.

[0135] 3) DAG construction process:

[0136] Initialization: Load step metadata from PostgreSQL and create nodes in Neo4j (such as "Configure Honors" and "Add Personnel Honors").

[0137] Verification: Cycle detection algorithms (such as the Kahn algorithm) are used to ensure no cycles. For example, check if the "Add Personnel Honors" step has a reverse dependency on other steps. Ensuring no cycles does not mean that the "Add Personnel Honors" step cannot depend on other steps, but rather that there cannot be circular dependencies. For example, if "Add Personnel Honors" depends on "Configure Honors," and "Configure Honors" in turn depends on "Add Personnel Honors," this circular dependency will cause the test flow logic to become chaotic and unable to execute normally. Cycle detection algorithms are used to avoid such situations and ensure the rationality of dependency relationships.

[0138] Index optimization: Create composite indexes (e.g., (module, role_scope)) to accelerate retrieval steps by module and role (e.g., quickly query the executable steps for "Marketing Line" administrators). Module information comes from the functional module to which the test step belongs, and role scope information comes from the applicable roles defined in the step node. This information is set by the testing team when creating the step node. The index is manually created by technical personnel based on query requirements and system performance optimization needs. By creating a (module, role_scope) composite index, executable steps for a specific role within a specific module can be quickly located, improving retrieval efficiency.

[0139] In one implementation, with the goals of achieving test coverage requirements by summing coverage weights, reducing the sum of cost weights, and increasing the sum of dependency weights, a path optimization algorithm is used to obtain a first test case graph, specifically including:

[0140] Obtain the top N first nodes with the highest coverage weights, where the sum of the coverage weights of the top N first nodes is less than the test coverage requirement.

[0141] For each of the top N first nodes, add the node with the lowest cost weight connected to the first node and / or the node connected by the edge with the highest dependence weight. Check whether the sum of the coverage weights of the added node and the top N first nodes meets the test coverage requirement. If not, continue adding nodes. If yes, obtain the first test case graph.

[0142] This embodiment provides a specific implementation example of DAG path planning and test case generation:

[0143] 1) Taking the scenario of "super administrator batch deletion of honors" as an example, the path planning algorithm is applied as follows: Define the starting point and the ending point: the starting point is "login to system" (S00-001-01), and the ending point is "batch deletion successful" (S00-001-05); intermediate steps: verify super administrator privileges (S00-001-02) → select honors to be deleted (S00-001-03) → execute batch deletion (S00-001-04);

[0144] Other scenarios (such as line administrators adding personal honors) also require path planning, for example: super administrator logs into the system → configures a line administrator for a certain line → line administrator logs into the system → the line administrator configures the honors for this line → line administrator adds personnel honors → verify the addition result.

[0145] 2) Calculate Node Weights: Based on test coverage requirements, assign a high weight to the "Verify Deletion Permissions" step (covering super administrator permission verification). The purpose of this high weight is to prioritize this step in the test path during path planning, ensuring that critical functions (such as super administrator permission verification) are adequately tested, not to restrict user operation. The weights are calculated based on test coverage requirements, which define which functionalities and logic of the system the test cases need to cover. For example, it may require covering permission verification steps for all roles. Different nodes have different weights, reflecting their importance in the test. Test coverage requirements are an indicator of test completeness, ensuring that all functions and logic of the system are tested, such as the operational permissions of all roles and the key steps of all business processes. During path planning, the algorithm also considers various cost weights to calculate the total cost of the path.

[0146] 3) Path optimization algorithm: A* algorithm (a heuristic search algorithm used to find the optimal path from a starting point to an end point in a graph or network, widely used in path planning, game AI, etc.) Solution: Generate optimal path: Log in to the system → Verify super administrator privileges → Select honors to be deleted → Execute batch deletion → Verify deletion results. The "Verify super administrator privileges" step is filtered by the role scope attribute (role_scope: ["super_admin"]) to ensure that only super administrators can execute it.

[0147] 4) Dynamic generation of test cases: Test cases are generated based on the above path.

[0148] {

[0149] "id": "TC-20250501-001",

[0150] "name": "Super Administrator Batch Deletion of Honor Test",

[0151] "setup": [

[0152] {

[0153] "step_id": "S00-001-01",

[0154] "action": "Log in using the super administrator account",

[0155] "parameters": {"username": "super_admin", "password": "***"}

[0156] }

[0157] ],

[0158] "steps": [

[0159] {

[0160] "order": 1,

[0161] "step_id": "S00-001-02",

[0162] "action": "Verify super administrator's delete permission",

[0163] "input": {"role": "super_admin"},

[0164] "expected_output": ["delete_allowed: true"]

[0165] },

[0166] {

[0167] "order": 2,

[0168] "step_id": "S00-001-03",

[0169] "action": "Choose the honor of the marketing line",

[0170] "input": {"line_id": "marketing", "honor_ids": ["H001", "H002"]}

[0171] } ]

[0173] }

[0174] Solution Process: Taking "bulk deletion of honors by super administrators" as an example, the algorithm first determines the starting point (login system) and the ending point (successful bulk deletion). Then, it calculates the cost of each intermediate node (such as verifying permissions, selecting honors, etc.) (including the actual cost from the starting point to the node and the estimated cost to the ending point). It prioritizes nodes with lower costs to extend the path, ultimately finding the optimal path from the starting point to the ending point. This embodiment is mainly used for test case management in the honor system. The generated test cases are used to verify the correctness of the system functions. In formal use, operations are performed on actual business data, while testing is conducted in a simulated environment to avoid affecting the actual data. Test coverage metrics are standards defined by the quality assurance team to measure the completeness of tests, such as role permission test coverage, business process test coverage, etc., to ensure comprehensive testing. Automatic optimal path planning refers to selecting a series of related nodes (test steps) from the DAG graph according to the test objectives and coverage requirements, and assembling them into a path that meets the test requirements in a reasonable order. The selection of these nodes needs to consider factors such as dependencies and node weights to ensure the optimality of the path.

[0175] In one embodiment, S3, querying a preset graph database based on metadata to generate a first test case graph, wherein nodes in the first test case graph represent at least some first test steps, and edges represent at least some first dependencies between at least some of the first test steps, specifically further including:

[0176] If a third test case graph for a first test task or a partial subtask of a second test task is found in the preset graph database, nodes and edges are no longer generated for the partial subtasks. Instead, the nodes and edges of the remaining subtasks are directly connected using the third test case graph. The first test task includes several subtasks contained in the instruction, and the second test task includes several subtasks corresponding to different first condition dependencies.

[0177] In this embodiment, the Honor System test case management achieves the following objectives:

[0178] Precise dependency modeling: Explicitly express the data dependency of "Configure Honor → Add Honor" and the conditional dependency of "Super Administrator → Allow Deletion of All Data" to avoid omissions in permission verification steps; In addition to the data dependency of "Configure Honor → Add Honor" and the conditional dependency of "Super Administrator → Allow Deletion of All Data", there is also a time-series dependency, such as "Login to System" must be executed before all other operations, clearly defining the three types of dependencies: time-series, data, and condition.

[0179] Efficient Test Case Generation: For requirement changes (such as adding batch activation functionality for the "Human Resource Approval" role), the system improves efficiency by quickly identifying reusable sub-paths (e.g., "Verify Role Permissions → Batch Operations") using a Directed Acyclic Graph (DAG) to generate new test cases. When adding batch activation functionality for the "Human Resource Approval" role, the system uses a DAG subgraph matching algorithm to find common sub-paths related to "batch activation" that do not involve a specific role, such as "Verify Role Permissions → Batch Operations." This sub-path already exists in previous test cases and can be reused, significantly reducing the workload of writing test cases and thus improving efficiency. Practical experience has shown an efficiency improvement of 70%.

[0180] Natural language interaction: Supports complex queries such as "generate test cases for line administrators to modify honors in this line", reducing testers' reliance on technical documentation.

[0181] In one embodiment, S4, visually displaying the first test case diagram, receiving a second test case diagram modified from the first test case diagram, and generating test cases based on the second test case diagram, specifically including:

[0182] The system displays the first test case diagram visually to the tester's terminal, receives modifications and confirmations from the tester's terminal regarding the first test case diagram, and obtains the second test case diagram.

[0183] Test cases are generated based on the second test case diagram, and the test cases are sent to the test role terminal so that the test role can test the test cases.

[0184] In this embodiment, combined with Figure 3 and Figure 4 The test case diagram is ultimately sent to the user terminal for visual display to the testers, facilitating their modification and confirmation, in order to generate the final test cases. The final test cases can then be sent to the corresponding test roles to complete the testing.

[0185] The main steps of the method in this embodiment are as follows: Figure 5 As shown, focusing on the core issue of efficient test case generation under changing requirements, the following key technologies have been developed through technology integration and innovative design:

[0186] Dynamic Dependency Modeling Technology: A method for vectorized decomposition and recombination of test steps based on DAG, including node attribute definition rules and the construction logic of dependency edges; a dynamic dependency model construction method for multi-role permission scenarios (super administrator, line administrator, etc.) in the honor system, realizing the permission constraints and dependency expression of operation steps for different roles. A Directed Acyclic Graph (DAG) is used to vectorize the test steps of the honor system, defining a node model containing step attributes, dependency types (time sequence / data / condition), and role permission scope, as well as an edge model with weights and conditional constraints. Through this structured expression, the complex dependencies between test steps are transformed into a computable graph structure, solving the problem of implicit dependencies causing test cases to fail when requirements change.

[0187] Natural Language Intelligent Parsing and Query Technology: A natural language semantic parsing rule base for test case management, including mapping rules for test domain-specific semantics such as dependencies and role permissions; a Text2SQL-based DAG path query method to implement an algorithm for converting natural language requirements into graph database query statements; a Text2SQL enhanced parser to support test domain-specific semantic parsing, such as dependency queries and step attribute retrieval, by extending semantic understanding rules; and, combined with the DAG path query algorithm, to convert natural language requirements into complex graph database query statements, achieving automated mapping from requirement descriptions to test step paths.

[0188] Intelligent path planning and test case generation technology: Based on DAG critical path analysis and test coverage requirements, this technology utilizes graph search algorithms such as A*, combined with node weight calculation and parallel step identification strategies, to automatically plan the optimal test path. Based on the path planning results, it dynamically generates executable test cases containing preconditions, main test steps, and expected outputs, achieving automated test case generation and adaptation. Test coverage requirements are defined by the quality assurance team based on the functional requirements and business logic of the honor system. This ensures that test cases cover all key functionalities and logic, guiding test path planning. Path planning prioritizes steps that meet coverage requirements, ensuring all required coverage is included in the path. The optimal path is the one with the fewest execution steps, highest efficiency, or coverage of the most critical steps while meeting test coverage requirements. For example, in testing the deletion of honor, a path including permission verification steps is better than one without. The intelligent path planning algorithm based on DAG and test coverage includes a node weight calculation model, path search strategy and parallel step processing method; and a dynamic test case generation method, covering the conversion rules from DAG path to structured test case data (steps, parameters, expected results).

[0189] Change Impact Analysis and Test Asset Reuse Technology: A graph traversal-based change impact analysis model is established. When a test step changes, the affected test paths are automatically calculated. A DAG subgraph matching algorithm identifies reusable test sub-paths, enabling rapid trimming and reuse of test assets and reducing the cost of rebuilding test cases due to requirement changes. Test assets refer to reusable resources generated during the testing process, including test cases, test steps, test paths, and test data. These assets can be reused in subsequent tests, reducing repetitive work and lowering testing costs. The graph traversal-based test step change impact analysis method includes the calculation logic and scope definition rules for affected paths; the test case reuse and trimming method involves sub-path identification algorithms, maximum common subgraph matching strategies, and rapid test case reorganization technology. Calculation Logic: When a test step changes, a graph traversal algorithm traverses all paths in the DAG associated with that step (including paths directly and indirectly dependent on that step) to determine the scope of affected paths. Definition rules: Based on the tightness of dependencies, paths directly dependent on this step are classified as primarily affected paths, while those indirectly dependent are classified as secondarily affected paths, thus clarifying the scope of impact. Sub-path identification algorithms are used to find reusable sub-paths; the maximum common subgraph matching strategy is used to find identical substructures in different DAGs, enabling test asset reuse; and the rapid test case reorganization technique quickly generates new test cases based on the modified paths and reused sub-paths.

[0190] A multi-component collaborative system architecture: A Text2SQL+DAG fusion architecture is designed, comprising a user interface layer, a core engine layer (Text2SQL parser, DAG management engine, test case generator), and a data storage layer (relational database and graph database). These components work collaboratively to form a complete chain of "natural language query → semantic parsing → DAG path planning → test case generation," achieving full-process automation of test case management. For the Honor System's test case management, the Text2SQL+DAG fusion architecture clearly defines the functional division and interaction mechanisms of each component layer; the deployment architecture and data interaction processes of each server (Web server, application server, database server) within the system ensure efficient system operation and data consistency. Through modular design and algorithm optimization, the maintenance cost and generation efficiency of test cases meet actual engineering requirements in the Honor System's high-frequency iteration scenarios.

[0191] The specific technical details of this embodiment are partially alternative to the following:

[0192] Alternative Graph Structures: In dynamic dependency modeling, besides Directed Acyclic Graphs (DAGs), Property Graphs or Hypergraphs can be used as alternative structures. Property Graphs express complex relationships through nodes, edges, and rich attributes, and can more flexibly store information such as role permissions and execution conditions for test steps. Hypergraphs allow an edge to connect multiple nodes, making them suitable for expressing complex dependencies between multiple test steps, such as scenarios where multiple preceding steps point to a single following step. By adjusting the storage and query logic of the graph structure, structured management and dynamic path planning of test steps can also be achieved. As long as the graph structure can clearly express the test steps and their dependencies (including temporal, data, and conditional dependencies), it can serve as an alternative structure. The flexible attributes of property graphs and the ability of hypergraphs to connect multiple nodes can better meet the needs of complex dependency modeling in specific scenarios.

[0193] Natural Language Processing Alternatives:

[0194] The rule-based parsing solution does not rely on deep learning models. Instead, it builds a parsing engine based on regular expressions and grammar rules. For example, it uses tools such as ANTLR to define grammar rules specific to the testing domain, parsing natural language requirements into structured data. This solution does not require a large amount of training data, can quickly respond to semantic changes in specific domains, and is suitable for scenarios with relatively fixed testing requirements and well-defined rules.

[0195] Semantic Network Model: This model uses a semantic network to construct a mapping relationship between natural language and test steps. By defining nodes (concepts) and edges (relationships), it associates entities in natural language with test step attributes. It uses a graph traversal algorithm to realize the transformation from requirements to test paths, and can be used as an alternative implementation of the Text2SQL parser.

[0196] Alternatives to path planning algorithms:

[0197] Genetic Algorithm: By simulating the natural selection process, it performs evolutionary search on the test path, encodes the test steps as chromosomes, and gradually optimizes the test path through operations such as selection, crossover, and mutation to meet the requirements of test coverage and execution efficiency. This algorithm is suitable for large-scale test step scenarios and can find better solutions in complex solution spaces.

[0198] Simulated Annealing: Based on the principle of physical annealing, it searches for the optimal test path step by step by controlling the "temperature" parameter. During the search process, it allows for suboptimal solutions to avoid getting trapped in local optima. It is suitable for handling situations where the dependencies between test steps are complex and there are multiple local optimal paths.

[0199] Data storage alternatives:

[0200] Document-oriented databases (such as MongoDB): These replace the combination of relational databases and graph databases. They store test step metadata and dependencies, express step attributes and dependencies through nested document structures, and utilize aggregate queries to achieve functionality similar to DAG path queries, thereby reducing the complexity of data storage and management.

[0201] Time-series databases (such as InfluxDB): For the storage and analysis of historical test step execution data, time-series databases optimize data storage and query performance. Through time-series indexing, they allow for quick retrieval of test step execution records within a specific time range, aiding in test case optimization and troubleshooting. In time-series database alternatives, it's not always necessary to use both databases simultaneously. The time-series database is primarily used for storing and analyzing historical test step execution data. If this solution meets the storage requirements for step metadata and dependencies, it can be used alone; otherwise, it may need to be combined with other databases.

[0202] Hybrid architecture alternative: Adopting a rule engine + machine learning hybrid architecture, in the early stages of requirement changes, the rule engine quickly responds to clear requirement changes and generates basic test cases; as requirement change data accumulates, machine learning algorithms (such as reinforcement learning) are used to optimize and expand the rules, dynamically adjusting the test case generation strategy; this solution combines the determinism of rules with the adaptability of machine learning, and can more efficiently cope with complex and ever-changing requirement scenarios.

[0203] All the above alternatives and the solution detailed in this embodiment can achieve test scenario design for multi-role permissions (super administrator, line administrator, leader, ordinary employee, etc.) in the honor system. A graph model clearly expresses the permission constraints and dependencies of different roles' operation steps. The system can accurately model the permissions through the node's role_scope attribute and edge dependencies, meeting the needs of complex permission testing in the honor system. The technical solution covers test case management for multiple modules in the honor system, including honor dashboards, honor management (collective and individual honors), departmental assessments, honor configuration, and user management. From the test case examples, whether it's testing page display, data validation, permission control, or batch operations, this solution can achieve vectorized decomposition and dynamic combination of test steps, effectively supporting the entire process of honor system testing.

[0204] Example 2:

[0205] like Figure 2 As shown, this application provides a test case generation apparatus, the apparatus comprising:

[0206] Instruction recognition unit 1 is used to receive instructions to generate test cases and to obtain test roles and test tasks based on the instructions;

[0207] Metadata query unit 2, connected to instruction identification unit 1, is used to query a preset metadata database based on test role and test task to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps;

[0208] Graph generation unit 3 is connected to metadata query unit 2 and is used to query a preset graph database based on metadata to generate a first test case graph. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between at least some of the first test steps.

[0209] Test case generation unit 4, connected to graph generation unit 3, is used to visualize the first test case graph, receive the second test case graph modified from the first test case graph, and generate test cases based on the second test case graph.

[0210] In one embodiment, the instruction recognition unit 1 specifically includes:

[0211] The voice command recognition unit is used to receive natural language commands that instruct the generation of test cases, and to identify the test roles and the first test task contained in the natural language commands.

[0212] In one embodiment, the voice command recognition unit is specifically used for:

[0213] The user interface layer provides a natural language command input box to the tester's terminal, and the user interface layer obtains the natural language instructions entered by the tester's terminal into the natural language command input box.

[0214] It is set up in the core engine layer of the application server to receive natural language instructions from the user interface layer, and uses its own pre-trained language model to identify the test role and the first test task contained in the natural language instructions.

[0215] In one embodiment, the metadata query unit 2 is specifically used for:

[0216] Query the preset metadata database to obtain the second test task that has a first conditional dependency relationship with the first test task, obtain the second test step that belongs to the first test task and the second test task, filter the first test steps that meet the test permissions of the test role from the second test steps, obtain the first temporal dependency relationship and the first data dependency relationship between the first test steps, obtain the cost weight and coverage weight of the first test step to the first test task, and obtain the dependency weights of the first conditional dependency relationship, the first temporal dependency relationship and the first data dependency relationship;

[0217] The pre-defined metadata database stores test steps written by testers, test tasks to which the test steps belong, conditional dependencies between test tasks, test roles with test permissions for the test steps, temporal dependencies and data dependencies between test steps. Data dependencies include the output parameter flow relationship between test steps, the cost weight and coverage weight of test steps for different test tasks, and the dependency weights of each conditional dependency, temporal dependency and data dependency.

[0218] In one embodiment, the graph generation unit 3 specifically includes:

[0219] The graph element unit is used to query a preset graph database to obtain the preset test coverage requirements and path optimization algorithm for the first test task, generate the first test step as a node, and generate edges between nodes based on the first conditional dependency, the first temporal dependency, and the first data dependency.

[0220] The graph weight unit, connected to the graph element unit, is used to obtain the cost weight and coverage weight of each node based on the cost weight and coverage weight of the first test task in the first test step, and to obtain the dependency weight of each edge based on the dependency weights of the first conditional dependency, the first temporal dependency, and the first data dependency.

[0221] The path optimization unit, connected to the graph weight unit, is used to obtain the first test case graph using a path optimization algorithm, with the goals of achieving the test coverage requirement by summing the coverage weights, reducing the sum of cost weights, and increasing the sum of dependency weights.

[0222] In one embodiment, the path optimization unit is specifically used for:

[0223] Obtain the top N first nodes with the highest coverage weights, where the sum of the coverage weights of the top N first nodes is less than the test coverage requirement.

[0224] For each of the top N first nodes, add the node with the lowest cost weight connected to the first node and / or the node connected by the edge with the highest dependence weight. Check whether the sum of the coverage weights of the added node and the top N first nodes meets the test coverage requirement. If not, continue adding nodes. If yes, obtain the first test case graph.

[0225] In one embodiment, the graph generation unit 3 further includes:

[0226] The graph element simplification unit, connected to the graph element unit, is used to query a preset graph database. If a third test case graph for a portion of the subtasks of the first test task or the second test task is found in the preset graph database, nodes and edges are no longer generated for the portion of the subtasks. Instead, the nodes and edges of the remaining subtasks are directly connected using the third test case graph. The first test task includes several subtasks contained in the instruction, and the second test task includes several subtasks corresponding to different first condition dependencies.

[0227] In one embodiment, the test case generation unit 4 specifically includes:

[0228] The diagram modification unit is used to visually display the first test case diagram to the tester's terminal, receive modifications and confirmations of the first test case diagram from the tester's terminal, and obtain the second test case diagram.

[0229] The test unit, connected to the graph modification unit, is used to generate test cases based on the second test case graph and send the test cases to the test role terminal so that the test role can test the test cases.

[0230] Example 3:

[0231] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the test case generation method as described in Embodiment 1, or the test case generation apparatus as described in Embodiment 2.

[0232] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program units, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0233] Additionally, this application may provide a computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the test case generation method as described in Embodiment 1. This computer device may be the test case generation apparatus as described in Embodiment 2.

[0234] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.

[0235] Embodiments 1-3 of this application provide a test case generation method, apparatus, and medium. By acquiring the test roles and test tasks of test case instructions, and using a preset metadata database and graph database, a test case graph including test steps and dependencies is generated. Test cases are generated based on the test case graph, thereby automatically associating roles and generating test cases with a visualized test case graph, thus improving the quality of test case generation.

[0236] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.

Claims

1. A test case generation method, characterized in that, The method includes: Receive instructions to generate test cases, and obtain test roles and test tasks according to the instructions; Based on the test role and test task, query the preset metadata database to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps; The first test case graph is generated by querying a preset graph database based on the metadata. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between at least some of the first test steps. The system visualizes the first test case diagram, receives the second test case diagram modified from the first test case diagram, and generates test cases based on the second test case diagram.

2. The method according to claim 1, characterized in that, Receive instructions to generate test cases, and obtain test roles and test tasks according to the instructions, specifically including: Receive natural language instructions to generate test cases, and identify the test roles and first test tasks contained in the natural language instructions.

3. The method according to claim 2, characterized in that, Receive natural language instructions to generate test cases, identify the test roles and the first test task contained in the natural language instructions, specifically including: The user interface layer provides a natural language command input box to the tester's terminal, and the user interface layer obtains the natural language instructions entered by the tester's terminal into the natural language command input box. It is set up in the core engine layer of the application server to receive natural language instructions from the user interface layer, and uses its own pre-trained language model to identify the test role and the first test task contained in the natural language instructions.

4. The method according to any one of claims 1-3, characterized in that, Based on the test role and test task, a pre-defined metadata database is queried to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps, specifically including: Query the preset metadata database to obtain the second test task that has a first conditional dependency relationship with the first test task, obtain the second test step that belongs to the first test task and the second test task, filter the first test steps that meet the test permissions of the test role from the second test steps, obtain the first temporal dependency relationship and the first data dependency relationship between the first test steps, obtain the cost weight and coverage weight of the first test step to the first test task, and obtain the dependency weights of the first conditional dependency relationship, the first temporal dependency relationship and the first data dependency relationship; The pre-defined metadata database stores test steps written by testers, test tasks to which the test steps belong, conditional dependencies between test tasks, test roles with test permissions for the test steps, temporal dependencies and data dependencies between test steps. Data dependencies include the output parameter flow relationship between test steps, the cost weight and coverage weight of test steps for different test tasks, and the dependency weights of each conditional dependency, temporal dependency and data dependency.

5. The method according to claim 4, characterized in that, The first test case graph is generated by querying a pre-defined graph database based on metadata. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between these first test steps. Specifically, these dependencies include: The system queries a pre-defined graph database to obtain the pre-defined test coverage requirements and path optimization algorithms for the first test task. It generates nodes from the first test steps, and generates edges between nodes based on the first conditional dependency, the first temporal dependency, and the first data dependency. It obtains the cost weight and coverage weight of each node based on the cost weight and coverage weight of the first test steps for the first test task. It also obtains the dependency weight of each edge based on the dependency weights of the first conditional dependency, the first temporal dependency, and the first data dependency. With the goal of achieving the test coverage requirement by summing the coverage weights, reducing the sum of cost weights, and increasing the sum of dependency weights, the system uses a path optimization algorithm to obtain the first test case graph.

6. The method according to claim 5, characterized in that, With the goals of achieving test coverage requirements by summing coverage weights, reducing cost weights by summing cost weights, and increasing dependency weights by summing dependency weights, a path optimization algorithm is used to obtain the first test case graph, specifically including: Obtain the top N first nodes with the highest coverage weights, where the sum of the coverage weights of the top N first nodes is less than the test coverage requirement. For each of the top N first nodes, add the node with the lowest cost weight connected to the first node and / or the node connected by the edge with the highest dependence weight. Check whether the sum of the coverage weights of the added node and the top N first nodes meets the test coverage requirement. If not, continue adding nodes. If yes, obtain the first test case graph.

7. The method according to claim 5, characterized in that, The first test case graph is generated by querying a pre-defined graph database based on metadata. Nodes in the first test case graph represent at least some of the first test steps, and edges represent at least some of the first dependencies between these first test steps. Specifically, it also includes: If a third test case graph for a first test task or a partial subtask of a second test task is found in the preset graph database, nodes and edges are no longer generated for the partial subtasks. Instead, the nodes and edges of the remaining subtasks are directly connected using the third test case graph. The first test task includes several subtasks contained in the instruction, and the second test task includes several subtasks corresponding to different first condition dependencies.

8. The method according to claim 4, characterized in that, The system visualizes the first test case diagram, receives a second test case diagram modified from the first, and generates test cases based on the second test case diagram. Specifically, this includes: The system displays the first test case diagram visually to the tester's terminal, receives modifications and confirmations from the tester's terminal regarding the first test case diagram, and obtains the second test case diagram. Test cases are generated based on the second test case diagram, and the test cases are sent to the test role terminal so that the test role can test the test cases.

9. A test case generation device, characterized in that, The device includes: The instruction recognition unit is used to receive instructions to generate test cases and to obtain test roles and test tasks based on the instructions. The metadata query unit, connected to the instruction identification unit, is used to query a preset metadata database based on the test role and test task to obtain the first test step required for the test role to complete the test task and the first dependency relationship between the first test steps. The graph generation unit is connected to the metadata query unit and is used to query a preset graph database based on the metadata to generate a first test case graph. The nodes in the first test case graph represent at least some of the first test steps, and the edges represent at least some of the first dependencies between the at least some of the first test steps. The test case generation unit, connected to the graph generation unit, is used to visualize the first test case graph, receive the second test case graph modified from the first test case graph, and generate test cases based on the second test case graph.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the test case generation method as described in any one of claims 1-8.

Images