Test case generation method and device and electronic equipment

Abstract

The invention relates to the technical field of data processing, in particular to a test case generation method and device and electronic equipment.The method comprises the steps that semantic analysis is conducted on test demand data of a to-be-tested service, and multiple demand elements are extracted; constructing a business logic diagram of the to-be-tested business based on each demand element; according to the business logic diagram and a predefined test dimension set, performing test key point analysis on the plurality of demand elements, and generating a test key point map including a plurality of test dimensions; aiming at each test key point under each test dimension, respectively executing the following steps: determining a target demand element corresponding to the test key point from each demand element; based on the target demand element, calling a test scheme generation strategy corresponding to the test dimension, and constructing a test scheme of the test key points; generating a test case of the test key points based on the test scheme of the test key points; and aggregating the test cases of the test key points, and generating a test case set corresponding to the to-be-tested service. And the generation efficiency and the coverage rate of the test case are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method, apparatus, and electronic device for generating test cases. Background Technology

[0002] With the rapid growth in the scale of software systems, the software development process typically requires customized test cases based on user requirements documents to comprehensively verify the software's various functionalities, business rules, and non-functional requirements. Therefore, the rapid, accurate, and high-coverage generation of test cases has become a crucial step in ensuring software product quality and improving development efficiency.

[0003] In related technologies, test case generation mainly relies on testers manually reading, analyzing, and understanding requirements documents, extracting key test points based on their personal experience, and then writing specific test cases accordingly. This approach is inefficient, especially in rapid iteration models such as agile development or continuous delivery, where frequent changes and massive requirements make manual design difficult to meet the demands of rapid test asset delivery. Furthermore, the quality of test results is highly dependent on individual professional skills and subjective judgment. Different personnel may have differing understandings of the same requirement, leading to incomplete extraction of key test points, omission of boundary conditions, and insufficient coverage of abnormal paths. This results in low test case coverage, poor consistency, and difficulty in guaranteeing effectiveness.

[0004] Therefore, in related technologies, the methods for generating test cases suffer from low generation efficiency and low coverage. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for generating test cases, which improves the generation efficiency and coverage of test case generation methods.

[0006] Firstly, this application provides a method for generating test cases, the method comprising:

[0007] Semantic parsing is performed on the test requirement data of the business under test to extract multiple requirement elements;

[0008] Based on each requirement element, a business logic diagram of the business to be tested is constructed; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the analysis of the requirement elements.

[0009] Based on the business logic diagram and the predefined set of test dimensions, test point analysis is performed on the multiple requirement elements to generate a test point map containing multiple test dimensions.

[0010] For each test point under each test dimension in the test point map, perform the following operations: determine the target requirement element corresponding to the test point from the requirement elements; based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point; and generate test cases for the test point based on the test plan for the test point.

[0011] Aggregate the test cases for each test point to generate a test case set corresponding to the service to be tested.

[0012] In some embodiments, the requirement elements include function points and business rules;

[0013] The process of constructing the business logic diagram of the service to be tested based on various requirement elements includes:

[0014] Analyze the functional points and business rules, and construct business nodes based on the analysis results;

[0015] Natural language processing technology is used to identify the conditional statements in the business rules, and the logical flow and dependency relationships between the business nodes are determined based on the conditional statements.

[0016] Based on the logical flow and dependency relationships, each business node is connected to generate the business logic graph.

[0017] In some embodiments, the step of performing test point analysis on the multiple requirement elements based on the business logic diagram and a predefined set of test dimensions, and generating a test point map containing multiple test dimensions, includes:

[0018] Based on the service type of the service to be tested, multiple test dimensions are determined from a predefined set of test dimensions;

[0019] For each testing dimension, the following steps are performed: Based on the business logic diagram and the multiple requirement elements, at least one parent node to be tested under the dimension is determined, wherein the parent node represents the target test object under the dimension; for each parent node, the requirement elements associated with the parent node are decomposed to determine at least one child node, wherein the child node represents the target test sub-object of the corresponding parent node; each child node is used as a new parent node, and the requirement element decomposition steps are repeated until a preset node termination condition is met; at least one test point is generated based on the requirement elements associated with at least one target child node that meets the preset node termination condition.

[0020] Based on all test dimensions, the relationships between nodes at each level corresponding to each test dimension, and each test point, construct the test point map.

[0021] In some embodiments, the test dimension includes a functional dimension, and the test plan generation strategy corresponding to the functional dimension includes graph traversal algorithm, equivalence class partitioning method and boundary value analysis method;

[0022] The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes:

[0023] Using the graph traversal algorithm, at least one business flow path associated with the test point is located in the business logic graph;

[0024] The equivalence class partitioning method and the boundary value analysis method are used to generate test input data for the test points.

[0025] Based on the business flow path and the test input data, a test plan for the test points is generated.

[0026] In some embodiments, the test dimension further includes a performance dimension, and the test plan generation strategy corresponding to the performance dimension includes a stepped stress load method;

[0027] The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes:

[0028] Extract at least one performance indicator from the target requirement elements corresponding to the test points;

[0029] Based on the stepped pressure load method, load patterns and performance thresholds are generated for the at least one performance index;

[0030] Based on the load pattern and performance threshold, a test plan for the test points is generated.

[0031] In some embodiments, the testing dimension further includes a compatibility dimension, and the test plan generation strategy corresponding to the compatibility dimension includes orthogonal experimental design.

[0032] The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes:

[0033] Extract at least one environmental constraint from the target requirement elements corresponding to the test points;

[0034] Using the environmental constraints as input, the orthogonal experimental method is applied to generate a test plan for the test points.

[0035] In some embodiments, the testing dimension further includes a security dimension, and the test plan generation strategy corresponding to the security dimension includes a penetration testing path generation method based on a threat modeling knowledge base;

[0036] The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes:

[0037] Based on the threat modeling knowledge base, analyze the security risk points corresponding to the test points;

[0038] Using the penetration test path generation method, at least one penetration test path and verification steps for the security risk point are generated;

[0039] Based on the penetration testing path and verification steps for each security risk point, a test plan for the aforementioned test points is generated.

[0040] In some embodiments, generating test cases for the test points based on the test plan includes:

[0041] Based on a predefined test case template, create a data structure for the test case to be generated. The data structure includes the test case identifier, the function it belongs to, the test intent, the preconditions, the operation steps, the expected result, and some or all of the fields in the test data.

[0042] According to the predefined field mapping rules, the information contained in the test plan of the test points is filled into the corresponding fields of the data structure;

[0043] Based on the populated data structure, test cases for the aforementioned test points are generated.

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

[0045] The extraction module is used to perform semantic parsing on the test requirement data of the business under test and extract multiple requirement elements;

[0046] The construction module is used to construct the business logic diagram of the business to be tested based on each requirement element; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the analysis of the requirement elements;

[0047] The analysis module is used to perform test point analysis on the multiple requirement elements based on the business logic diagram and the predefined test dimension set, and generate a test point map containing multiple test dimensions.

[0048] The generation module is used to perform the following operations for each test point under each test dimension in the test point map: determine the target requirement element corresponding to the test point from the requirement elements; based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point; and generate test cases for the test point based on the test plan for the test point.

[0049] The aggregation module is used to aggregate test cases for each test point and generate a test case set corresponding to the service under test.

[0050] Thirdly, this application provides an electronic device, comprising: at least one processor, and a memory communicatively connected to said at least one processor, wherein:

[0051] The memory stores a computer program that can be executed by at least one processor, which enables the at least one processor to perform the method for generating the test cases described above.

[0052] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the above-described method for generating test cases.

[0053] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to execute the above-described method for generating test cases.

[0054] In this embodiment, semantic parsing is performed on the test requirement data of the business under test to extract multiple requirement elements; based on each requirement element, a business logic diagram of the business under test is constructed; according to the business logic diagram and a predefined set of test dimensions, test point analysis is performed on the multiple requirement elements to generate a test point map containing multiple test dimensions; for each test point under each test dimension in the test point map, the following operations are performed: determining the target requirement element corresponding to the test point from each requirement element; based on the target requirement element, calling the test plan generation strategy corresponding to the test dimension to construct a test plan for the test point; based on the test plan for the test point, generating test cases for the test point; aggregating the test cases of each test point to generate a test case set corresponding to the business under test. In this way, by first performing semantic parsing on the requirement document to automatically extract multiple requirement elements, the time cost of manual intervention is reduced. Then, business logic diagrams are automatically generated based on these requirements, further improving processing speed. At the same time, multi-dimensional test point analysis and the application of various test strategies ensure that test cases can cover a wide range of test scenarios, improving overall test coverage. Standardized process design and algorithm-driven test plan generation mechanism avoid omissions or errors caused by differences in individual understanding, thus improving the overall quality of test cases.

[0055] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0056] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0057] Figure 1 A schematic diagram illustrating an application scenario of a test case generation method provided in this application embodiment;

[0058] Figure 2 A flowchart illustrating a method for generating test cases provided in an embodiment of this application;

[0059] Figure 3 A business logic diagram of a service under test provided in an embodiment of this application;

[0060] Figure 4 A schematic diagram of test points provided in an embodiment of this application;

[0061] Figure 5A schematic diagram of the structure of a test case generation device provided in an embodiment of this application;

[0062] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for implementing a test case generation method, provided in an embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0064] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0065] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0066] The acquisition, transmission, storage, and use of data in this application all comply with the requirements of relevant national laws and regulations.

[0067] SeeFigure 1 , Figure 1 This is a schematic diagram of an application scenario for a test case generation method provided in an embodiment of this application. The application scenario includes a terminal device 110 and a server 120.

[0068] In this embodiment, the terminal device 110 includes, but is not limited to, electronic devices with data processing and network communication capabilities such as smartphones, tablets, laptops, and desktop computers. The terminal device can install or access a client related to test case generation. This client can be an independent application (such as dedicated testing tool software), a web application, a mini-program, or a web interface accessed through a browser. The server 120 is a backend server corresponding to the aforementioned client, used to execute core processing logic such as test requirement parsing, business logic modeling, test point analysis, and test case generation. The server 120 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This application does not specifically limit its scope in this regard.

[0069] It should be noted that the test case generation method in each embodiment of this application can be executed by an electronic device, which can be a terminal device 110 or a server 120. That is, the method can be run entirely on the local terminal device, or it can be completed entirely on the server side, or it can be implemented in a hybrid mode of "terminal uploads requirements - server generates test cases - terminal displays results".

[0070] In one alternative implementation, the terminal device 110 and the server 120 can communicate via a communication network.

[0071] In one alternative implementation, the communication network is a wired network or a wireless network.

[0072] It should be noted that, Figure 1 The examples shown are merely illustrative. In actual deployments, the number, type, and topology of terminal devices and servers can be flexibly adjusted according to project scale and performance requirements. This application does not impose any restrictions on this.

[0073] Furthermore, the embodiments of this application can be applied to various software development and quality assurance scenarios, including not only traditional industry software such as financial credit systems (e.g., bank online loan processes), e-commerce platforms, government service platforms, medical information systems, and IoT device management platforms, but also microservice architecture systems and automated testing in continuous integration / continuous delivery pipelines.

[0074] See Figure 2 , Figure 2 A flowchart of a test case generation method provided in this application embodiment, the method including the following steps.

[0075] In step 201, semantic parsing is performed on the test requirement data of the service to be tested to extract multiple requirement elements.

[0076] In practice, the business to be tested refers to one or more business function modules or end-to-end business processes in the software system that need to be verified. For example, in a bank's online lending system, the business to be tested could be the "user loan application process," which covers the entire process from the user submitting the application to the system disbursing the loan; in an e-commerce platform, the business to be tested could be the "order placement and payment process," "product search and filtering," "order status change notification," etc.; in a medical information system, the business to be tested could be "patient appointment registration," "electronic medical record retrieval," etc.

[0077] Test requirement data refers to the original input information describing the business functions, rules, constraints, and non-functional requirements to be tested. It usually comes from requirements specifications, user stories, product prototypes, interface documents, or business process diagrams. This test requirement data can be structured (such as JSON, YAML), semi-structured (such as Word documents with headings, Confluence pages), or unstructured text (such as requirement paragraphs described in pure natural language).

[0078] Requirements elements are key semantic units automatically identified and structured from test requirement data using Natural Language Processing (NLP) technology. They are used to represent the core test objects of the business under test. Specifically, they can include functional points (such as "submit loan application", "perform risk control review", "send SMS verification code"), business rules (such as "reject application if credit score < 600", "reject users in high-risk areas"), constraints (such as "loan amount ≥ 100 yuan", "only 11-digit mobile phone numbers are supported"), exception handling processes (such as "retry 3 times when network timeout", "prompt re-enter when ID number format is incorrect"), and non-functional requirements (such as "support 1000 concurrent users", "password must be transmitted in encrypted form"), etc.

[0079] For example, the system receives test requirement data uploaded by users (such as a Word document containing the statement "Applications with a credit score below 600 should be rejected"). First, a Bidirectional Long Short-Term Memory with Conditional Random Field (Bi-LSTM-CRF) model based on an attention mechanism performs deep semantic parsing on the document to identify functional entities and business rules. This model dynamically focuses on key semantic segments in the text through an attention mechanism, combining contextual information to accurately identify and extract functional entities (such as "submit a loan application" and "perform risk control review") and business rules (such as "if the credit score is below 600, the application should be rejected").

[0080] In step 202, a business logic diagram of the business to be tested is constructed based on each requirement element; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the requirement element analysis.

[0081] In practice, when constructing the business logic diagram of the business to be tested, firstly, the functional points and business rules can be analyzed, and business nodes can be constructed based on the analysis results; then, natural language processing technology is used to identify the conditional statements in the business rules, and the logical flow and dependency relationship between business nodes is determined based on the conditional statements; finally, the business nodes are connected based on the logical flow and dependency relationship to generate the business logic diagram.

[0082] First, the requirements elements include functional points and business rules. When constructing the business logic diagram of the business to be tested, functional points and business rules can be analyzed. Functional points refer to the functions or services that the business to be tested needs to implement, such as user registration, identity verification, and risk control review. These functional points will serve as the main business nodes in the business logic diagram, representing key processing steps in the process. Business rules refer to the conditional logic that controls the direction of the business process, used to define the flow conditions between functional points, such as "if the credit score is below 600, the risk control review will not pass" or "a loan application is only allowed after the user completes real-name authentication." These business rules will be parsed into logical branch conditions to determine the connection relationship and execution path between business nodes. Although business rules themselves may not directly become business nodes, they are crucial for determining which functions should be abstracted into independent business nodes. By analyzing business rules, functional points that need to be processed separately can be identified more accurately, complex logic can be decomposed into multiple small, manageable business nodes, and the interaction methods between these nodes can be clarified. After analysis, business nodes are constructed.

[0083] Secondly, after constructing the business nodes, natural language processing technology is used to identify conditional statements in the business rules. Based on the identified conditional statements, the system can determine the logical flow and dependencies between each business node. Logical flow refers to how the system moves from one node to another under specific conditions. For example, "If credit score < 600, then reject the application" indicates the flow condition from the "risk control review" node to the "reject review" node. Dependencies refer to whether there are preconditions or postconditions between different nodes. For example, "Only after the user completes real-name authentication is a loan application allowed" indicates that the "real-name authentication" node is a precondition for the "loan application" node.

[0084] Finally, based on the determined logical flow and dependencies, the system connects each business node with directed edges to form a complete business logic graph. Each business node in the business logic graph represents a specific business activity or state, and each directed edge indicates the direction of data flow or control flow and may be labeled with corresponding conditional statements.

[0085] Taking the bank's online lending process as an example, see [link / reference]. Figure 3 , Figure 3 This application provides a business logic diagram for a business under test. The diagram, presented as a directed graph, illustrates the entire process from user application submission to final loan disbursement or rejection, covering multiple stages including front-end interaction, channel access, core transactions, risk control, and data management. Key elements include business nodes (loan application interface, channel system, business system, core system, risk control system, database, account and fund checks, risk assessment, basic verification, etc.), all derived from functional points in the requirement elements. The diagram also includes logical branches and conditional statements (redirecting to return verification results upon verification failure, executing rules if risk assessment passes, otherwise rejecting the application, and disbursing the loan upon successful verification). These branch conditions originate from business rules in the requirement elements, such as "reject if identity information is inconsistent" and "loan disbursement is only allowed after risk control is passed."

[0086] Figure 3The execution logic of the business logic diagram is as follows: Users fill in information and submit their applications on the loan application interface of the front-end application layer (such as an app or mini-program). The application request is first received by the channel system in the channel access layer and initially encapsulated and routed. The channel system forwards the application data to the business system in the business processing layer, which then leads the subsequent processing flow. The business system first performs basic verification on the application data, including: whether the ID card format is valid, whether the mobile phone number is valid, whether it is on a blacklist, and whether there are duplicate applications. If the verification fails, an error result is returned directly, and the business system forwards the error result to the channel system to notify the user, terminating the process. If the verification passes, the process proceeds to the next step. After the basic verification passes, the business system sends the user data to the risk control system in the risk control decision layer to initiate a risk assessment. The risk control system, based on user credit scores, behavioral data, device fingerprints, etc., calls the rule engine to execute policy judgments. If the rule engine returns "approval rejected," the rejection result is directly returned to the business system, which then returns to the channel system to notify the user that the application has been rejected, ending the process. If the rule engine returns "approval passed," the approval result is directly returned to the business system, and the subsequent process continues. Assuming risk control is successful, the business system sends a formal loan disbursement request to the core system of the core transaction layer. Upon receiving the request, the core system performs account checks, such as verifying the user's account status (not frozen, not cancelled), eligibility for lending, and adequacy of credit limit. If the check fails, a failure result is returned to the business system, and the process terminates. If the check passes, the actual loan disbursement is executed. After disbursement, the core system synchronizes the successful disbursement result to the data and status management layer, updating user status and available credit information and writing it to the database. The business system returns the final "Loan Disbursement Successful" result to the channel system. The channel system notifies the user via app push notifications, SMS, etc.: "Your loan has been successfully disbursed."

[0087] In step 203, based on the business logic diagram and the predefined set of test dimensions, test point analysis is performed on multiple requirement elements to generate a test point map containing multiple test dimensions.

[0088] In practice, firstly, multiple test dimensions can be determined from a predefined set of test dimensions based on the business type of the business to be tested.

[0089] In practice, based on the business type of the business to be tested (such as credit approval, e-commerce order placement, etc.), multiple test dimensions related to that business type can be selected from a predefined set of test dimensions. These test dimensions can include functional dimensions, performance dimensions, compatibility dimensions, and security dimensions. For example, the dimensions for a "credit application" business might include functionality, performance, and security; while the dimensions for a "cross-platform app login" business might include functionality and compatibility dimensions.

[0090] Then, for each test dimension, at least one test point is generated through the following three steps:

[0091] Step 1: Based on the business logic diagram and multiple requirement elements, determine at least one parent node to be tested in this dimension, where the parent node represents the target test object in this dimension.

[0092] For example, in terms of functionality, the parent node can be a functional business node such as "risk control review", "user management" or "transaction process"; in terms of performance, the parent node can be a performance business node such as "load testing" or "stress testing"; and in terms of security, the parent node can be a security business node such as "data security" or "business security".

[0093] Step 2: For each parent node, decompose the requirement elements associated with the parent node to determine at least one child node, where the child node represents the target test sub-object of the corresponding parent node.

[0094] For each parent node, its associated requirement elements (such as functionalities, business rules, and constraints) are further semantically decomposed to determine at least one child node. For example, the parent node "User Management" can be decomposed into child nodes such as "Registration Function" and "Face Recognition"; the parent node "Data Security" can be decomposed into child nodes such as "Sensitive Information Encryption", "Data Transmission Security", and "Anti-Injection Attack Prevention".

[0095] Step 3: Treat each child node as a new parent node and repeat the requirement element decomposition steps until the preset node termination condition is met; generate at least one test point based on the requirement elements associated with at least one target child node that meets the preset node termination condition.

[0096] In practice, each child node is treated as a new parent node, and the above-mentioned steps for decomposing the requirements are repeated to form a multi-level tree structure until the preset node termination condition is met. The preset node termination condition may include, but is not limited to:

[0097] The node can no longer be semantically decomposed;

[0098] Reach the preset maximum decomposition level (e.g., three-level nodes);

[0099] Each node corresponds to a test scenario that can be independently verified.

[0100] Once the termination condition is met, at least one specific test point is generated based on the requirement elements associated with the termination node (i.e., the target child node). For example, for the target child node "registration function", test points can be generated as follows: "verify the correctness of the mobile phone number format, verify the validity of the ID card number rules, and verify the complexity of the username and password".

[0101] Finally, based on all test dimensions, the relationships between nodes at each level corresponding to each test dimension, and each test point, a test point mind map is constructed.

[0102] In practice, all test dimensions, the parent-child and sibling relationships between first-level / second-level / ... / terminal-level nodes under each dimension, and the final generated test points are integrated to construct a structured test point mind map.

[0103] In practice, the testing dimensions can also include the abnormal scenario dimension, see [link / reference]. Figure 4 , Figure 4 This application provides a test point mind map diagram, using a "peer-to-peer lending system" as an example. It includes four test dimensions: functionality, performance, abnormal scenarios, and security. Each dimension has multiple levels of sub-nodes, forming a tree structure. Taking the functionality dimension as an example, the parent nodes are "User Management," "Transaction Process," "Fee Rate and Interest Calculation Rules," and "Core Risk Control Rules." For "User Management," the target sub-nodes are "Registration Function" and "Facial Recognition." For "Transaction Process," the sub-nodes are "Amount and Term Rules." The target sub-nodes for "Amount and Term Rules" are "Loan Amount Upper and Lower Limits," "Term Range Validity," and "Daily Application Limit," and so on. At least one specific test point can be marked on the target sub-nodes, such as "Verifying ID Number Format" or "Simulating High Concurrency Requests." The test point mind map also supports interactive buttons such as "Intelligent Modification" and "Online Editing," allowing testers to dynamically adjust the test plan according to project progress, further improving the coverage and accuracy of the test.

[0104] This application's embodiments, by constructing a test point mind map, not only help the team clearly understand the key points to focus on in each test dimension, but also demonstrate in a hierarchical manner how to progressively refine from high-level requirements to specific test cases. This structured representation method greatly improves the efficiency and quality of test design, while making the testing process more transparent and easier to trace.

[0105] In step 204, for each test point under each test dimension in the test point map, the following operations are performed: determine the target requirement element corresponding to the test point from each requirement element; based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point; based on the test plan for the test point, generate test cases for the test point.

[0106] In practical implementation, when the testing dimension includes a functional dimension, the test plan generation strategy corresponding to the functional dimension can include graph traversal algorithms, equivalence class partitioning, and boundary value analysis. Graph traversal algorithms refer to automatically identifying at least one complete business flow path related to the current test point based on the business logic graph, using methods such as depth-first search or breadth-first search. This path includes all business nodes and their conditional branches traversed from the starting node to the ending node. Equivalence class partitioning involves dividing the test input data into several equivalence classes, where any input in each equivalence class should produce the same result in program behavior. Selecting a representative value from each equivalence class for testing covers all cases in that class, thereby reducing redundant test cases. Boundary value analysis involves designing test data for the boundary conditions of the input or output (such as minimum, maximum, just exceeding / below the boundary value).

[0107] Therefore, when constructing a test plan for a test point based on the target requirement elements and the test plan generation strategy, the graph traversal algorithm can be used first to locate at least one business flow path associated with the test point in the business logic graph; then, equivalence class partitioning and boundary value analysis can be used to generate test input data for the test point; finally, the test plan for the test point can be generated based on the business flow path and the test input data.

[0108] For example: if the test requirement is "verify the upper and lower limits of the loan amount", then the system will iterate through... Figure 3 The main path from "user submits application" to "basic verification" to "risk control system" to "core system loan disbursement check" is analyzed, with particular attention paid to the "amount and term rules" node and its conditional branches. Then, based on the target requirement elements (such as the business rule "loan amount range is 1000-50000 yuan"), the following methods are used: Equivalence class partitioning: The amount is divided into three equivalence classes: Valid class: 1000 ≤ amount ≤ 50000; Invalid class 1: amount < 1000; Invalid class 2: amount > 50000. Boundary value analysis: Boundary values ​​are selected: 999, 1000, 1001, 49999, 50000, 50001. Finally, the above business flow path is combined with the test input data to form a structured test plan, namely, test preconditions (such as user login, completed real-name authentication); execution path (along...). Figure 3(Specified process); Input data (e.g., loan amount = 999); Expected result (the system prompts "the loan amount must not be less than 1000 yuan" and refuses to submit).

[0109] In practice, when the testing dimension also includes a performance dimension, the test plan generation strategy corresponding to the performance dimension can include the stepped load test method. The stepped load test method is a performance testing method that gradually applies system load. By gradually increasing the number of concurrent users or request frequency at a preset step size (such as 100 users / second), the system response indicators (such as response time, throughput, and error rate) are observed at each load level for a period of time, thereby identifying the system performance inflection point, stability threshold, and crash threshold.

[0110] Therefore, when constructing a test plan for test points based on target requirement elements and calling the test plan generation strategy, at least one performance indicator can be extracted from the target requirement elements corresponding to the test points. Then, based on the stepped load method, a load mode and performance threshold are generated for at least one performance indicator. Finally, a test plan for the test points is generated based on the load mode and performance threshold.

[0111] For example, the test objective is "verifying the stability of the loan application submission interface under high concurrency." The target requirement for this test objective is the business rule "the system must support 500 concurrent users submitting applications simultaneously, and 95% of request response times must be ≤1.5 seconds." At least one explicit performance metric is extracted: "Concurrency = 500, response time P95 ≤ 1.5 seconds." Then, a tiered load balancing method is used to design the load pattern: Phase 1: 100 concurrent users, lasting 2 minutes; Phase 2: 200 concurrent users, lasting 2 minutes; ... Phase 5: 500 concurrent users, lasting 5 minutes. Simultaneously, performance thresholds are set: P95 response time ≤ 1.5s, error rate < 0.1%. Finally, the above load patterns and performance thresholds are integrated into a structured performance testing plan, generating the following test plan: Through an automated performance testing platform, a tiered concurrent user load is simulated (gradually increasing from 100 to 500, with the number of concurrent users increasing by 100 in each stage, and each stage lasting 2 minutes). The core business interface for processing loan application requests is monitored, and its 95th percentile response time and request error rate are collected. If the preset performance threshold is met in three consecutive tests under a concurrent load of 500, the test is considered to have passed.

[0112] In practice, when the testing dimension also includes a compatibility dimension, the test plan generation strategy corresponding to the compatibility dimension can include orthogonal experimental design. Orthogonal experimental design refers to a mathematical method for designing multi-factor, multi-level combination test cases based on orthogonal arrays. This method achieves efficient and balanced coverage of complex compatibility scenarios by selecting representative factor level combinations, thus avoiding the waste of resources caused by exhaustive testing.

[0113] Therefore, when constructing test plans for test points based on target requirement elements and invoking test plan generation strategies, at least one environmental constraint can first be extracted from the target requirement elements corresponding to the test points. Then, using the environmental constraint as input, orthogonal experimental design is applied to generate test plans for the test points. These environmental constraints typically include operating system type and version, browser type and version, device model or screen resolution, and some or all of the network environment constraints.

[0114] For example, the test objective is to "verify the display and interaction compatibility of the loan application page on mainstream mobile terminals," and the target requirement element is a non-functional requirement: "The system must support devices with operating systems A14 and above, and B10 and above, and be compatible with mainstream browsers." The environmental constraints are extracted as follows:

[0115] Operating systems: Operating system A15, Operating system A16, Operating system B12;

[0116] Browsers: Browser 1, Browser 2, Browser 3;

[0117] Screen resolutions: 375×812, 412×915, 390×844;

[0118] The orthogonal experimental design is as follows: L9(3 4 An orthogonal array was used to generate 9 typical test combinations:

[0119] Combination 1: (Operating System A15, Browser 1, 375×812);

[0120] Combination 2: (Operating System A15, Browser 2, 412×915);

[0121] Combination 3: (Operating System A16, Browser 3, 390×844)... (9 groups in total). Therefore, the generated test plan is as follows: Under the 9 terminal environment combinations generated by the orthogonal experimental method, execute the entire loan application process to verify the integrity of page rendering, button click response, and whether the form submission function is normal; if there are no compatibility defects in all combinations, the test point is deemed to have passed.

[0122] In practice, when the testing dimension also includes a security dimension, the test plan generation strategy corresponding to the security dimension can include a penetration testing path generation method based on a threat modeling knowledge base. The penetration testing path generation method based on a threat modeling knowledge base refers to a method that combines a pre-built security threat knowledge base with the business context to be tested to automatically identify potential security risk points and derive executable attack simulation paths and verification steps accordingly.

[0123] Therefore, when constructing test plans for key test points based on target requirements and utilizing test plan generation strategies, the first step is to analyze the security risks corresponding to the test points using a threat modeling knowledge base. Then, a penetration testing path generation method is applied to generate at least one penetration testing path and verification steps for each security risk point. Finally, based on the penetration testing paths and verification steps for each security risk point, a test plan for the key test points is generated. These security risks include, for example, authentication bypass, unencrypted transmission of sensitive data, and injection attacks caused by unvalidated input.

[0124] For example, the test objective is "verify that the loan amount submitted by the user cannot be tampered with by the front end." The target requirement is the business rule that "the loan amount must be dynamically verified by the server based on the credit limit, and the client is prohibited from directly inputting a valid amount." Based on the threat modeling knowledge base, the identified security risk is business logic bypass. The penetration test path is generated as follows: Attack path: The user normally enters the loan page, and the front end displays the available loan amount as 20,000 yuan; the target proxy tool intercepts the submission request; the "20,000" in the request body is modified to "100,000"; the modified request is replayed to the server. The verification steps are: check whether the system rejects the request and returns an error message (such as "the application amount exceeds the available credit limit"), check whether the database has not generated a corresponding loan record, and check whether the risk control system records this abnormal parameter submission behavior. Therefore, the test plan is: simulate an attacker tampering with the loan amount parameter to verify whether the server independently verifies the legality of the amount. If the system still rejects the transaction after the parameter is maliciously modified, there is no financial loss, and the security event is recorded, then the test objective is considered passed.

[0125] In practice, after generating the test plan for each test point, a data structure for the test cases to be generated can be created based on a predefined test case template. This data structure can include the test case identifier, the function it belongs to, the test intent, the preconditions, the operation steps, the expected results, and some or all of the fields in the test data. Then, according to the predefined field mapping rules, the information contained in the test plan for each test point is filled into the corresponding fields of the data structure. Finally, based on the filled data structure, the test cases for each test point are generated.

[0126] The test case identifier is a unique number that identifies the test case; the function to which the test case belongs is the business function module to which it belongs (such as "user registration" or "loan application"); the test intent is to explain the core requirement or risk point that this test case aims to verify; the preconditions are the states that the system should meet before executing this test case (such as "user has been real-name authenticated" or "account is not frozen"); the operation steps are to describe the specific actions to be performed in sequence; the expected result is the behavior or state that should be returned under correct implementation; and the test data is the set of input parameters used to drive the test.

[0127] Subsequently, according to predefined field mapping rules, the key information extracted from the test plan is automatically populated into the corresponding fields of the aforementioned data structure. These field mapping rules can be pre-configured in the system rule engine, such as mapping "business flow path" in the test plan to operation steps, mapping "performance threshold" or "validation rule" to expected results, and combining test point names with dimension information to generate test intent and associated functions. In specific implementations, the data structure can also include case status (untested, tested), test case nature (positive example, negative example), test plan generation strategy, etc., which are not limited in this application.

[0128] For example, the test point is: "Verify that the loan amount is not less than 1,000 yuan"; the test plan is as follows: business path: user submits application, system verifies the amount is ≥1,000 yuan, test input: amount = 999; expected behavior: refuse to submit, prompt "the loan amount is not less than 1,000 yuan"; prerequisite: the user has completed real-name authentication.

[0129] Assuming the test case data structure includes test case identifier, associated function, test intent, preconditions, operation steps, expected results, and test data fields, then after filling the corresponding fields of the data structure with the information contained in the test plan for the test points according to predefined field mapping rules, the resulting test cases are shown in Table 1.

[0130] Table 1

[0131]

[0132] In some embodiments, after test cases are generated, they can be updated when changes in test requirement data are detected.

[0133] In practice, test cases can be associated and mapped with the requirement elements in the test requirement data;

[0134] When changes to test requirement data are detected, the changed content is identified using a text similarity algorithm, and the associated test cases are automatically updated. Updates include adding rules, deleting rules, and modifying parameters.

[0135] For example, consider the addition of a new rule: Suppose the original requirement v1.0: "Applications with a credit score below 600 should be rejected." Test case 001 is generated: verifying rejection when the credit score is 550. New requirement v2.0: adds "Users from 'high-risk areas' should be rejected regardless of their credit score." The process of automatically updating the associated test cases is as follows: Test case 001 remains unchanged because it still needs to verify the rule "rejecting applications with a credit score below 600," and a new test case is generated: Test Case ID: 003, Test Intent: Verify that user applications from "high-risk areas" are correctly rejected by the risk control system. Steps: 1. Submit a loan application, setting the user's location to "high-risk area." 2. Execute the risk control review process. Expected Result: The risk control review result is "rejected," and the reason is recorded as "location is a high-risk area."

[0136] In practice, an online editing interface can be provided to users to manually modify each generated test case, such as supporting the addition and deletion of fields, adjustment of steps, and recording of modification records.

[0137] In some embodiments, after generating test cases, the accuracy of the test cases can be evaluated. For example, the data structure may contain multiple fields (test case identifier, function, test intent, preconditions, operation steps, expected results, test data), and corresponding weights are set for each field (e.g., expected result weight = 0.4, operation step weight = 0.3, test data weight = 0.2, test intent weight = 0.1). Then, the generated values ​​corresponding to the fields are compared with reference values ​​(such as expert-written golden test cases, historical high pass rate test cases, or explicit descriptions in the requirement specifications) using similarity calculations (e.g., cosine similarity). The similarity calculation results of each field are weighted and summed with their corresponding weights to obtain the accuracy evaluation value of the test case. Furthermore, the arithmetic mean of the accuracy evaluation values ​​of all test cases under the business to be tested is taken as the overall accuracy evaluation value of the business.

[0138] In this way, the evaluation value can be used as a feedback signal to fine-tune the test case generation model.

[0139] In some embodiments, the percentage of test cases adopted during actual execution can also be statistically analyzed. Assuming the system generates a total of 100 test cases, of which 10 are marked as invalid, and 72 are adopted during actual execution, the adoption rate is: In this way, the adoption rate directly reflects whether the test cases are executable, valuable, and trustworthy. A high adoption rate indicates that the generated logic fits the real test scenario, while a low adoption rate suggests that the strategy needs to be adjusted. When the adoption rate is consistently higher than the threshold (e.g., ≥75%), test engineers are more willing to rely on automated generation of results to reduce the burden of manual coding.

[0140] In some embodiments, to comprehensively reflect the quality level and coverage of the test design, the system can integrate a multi-dimensional data analysis engine to automatically aggregate, analyze, and visualize data throughout the testing process, generating a structured comprehensive quality assessment report.

[0141] For example, by designing a data aggregation layer, the system collects and integrates heterogeneous data from multiple sources to build an evaluation foundation. This heterogeneous data includes requirements element analysis results, test case metadata, and accuracy assessment results. Through a visualization layer, based on the aggregated data, the system uses multi-chart linkage technology to dynamically generate interactive visualizations. Examples include pie charts showing the proportion of requirements for each testing dimension (functionality, performance, compatibility, security); bar charts showing the number of test cases by high / medium / low priority to verify whether the testing strategy focuses on the core path; line charts showing changes in requirements coverage, code coverage, or scenario coverage; and heatmaps using modules or business domains, with color depth representing quality health to quickly locate risk areas. Through an intelligent analysis layer, the system automatically performs deep diagnostics based on preset accuracy and adoption rate thresholds. For example, if the average accuracy assessment value of a business module is <0.75, it is marked as "weak semantic understanding"; if the adoption rate is <70%, it prompts "Insufficient usability of generated test cases; optimization of test data construction logic is recommended." The above analysis results are packaged into a standardized comprehensive quality assessment report by designing a report output layer. It supports export in multiple formats such as PDF and Excel. Each report is automatically associated with the corresponding requirement version, test case set version and generation timestamp to ensure the auditability of the report.

[0142] In step 205, test cases for each test point are aggregated to generate a test case set corresponding to the service to be tested.

[0143] In this embodiment, firstly, semantic parsing of the requirements document automatically extracts multiple requirement elements, reducing the time cost of manual intervention. Then, based on these requirement elements, a business logic diagram is automatically generated, further improving processing speed. Simultaneously, multi-dimensional test point analysis and the application of various test strategies ensure that test cases cover a wide range of test scenarios, improving overall test coverage. Standardized process design and algorithm-driven test plan generation mechanisms avoid omissions or errors caused by differences in individual understanding, thus improving the overall quality of test cases.

[0144] Based on the same inventive concept, embodiments of this application provide a test case generation apparatus, please refer to... Figure 5 The device includes:

[0145] Extraction module 501 is used to perform semantic parsing on the test requirement data of the business under test and extract multiple requirement elements;

[0146] The construction module 502 is used to construct a business logic diagram of the business to be tested based on each requirement element; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the analysis of the requirement elements;

[0147] Analysis module 503 is used to perform test point analysis on the multiple requirement elements based on the business logic diagram and the predefined test dimension set, and generate a test point map containing multiple test dimensions.

[0148] The generation module 504 is used to perform the following operations for each test point under each test dimension in the test point map: determine the target requirement element corresponding to the test point from the requirement elements; based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point; and generate test cases for the test point based on the test plan for the test point.

[0149] The aggregation module 505 is used to aggregate test cases for each test point and generate a test case set corresponding to the service under test.

[0150] In some embodiments, the requirement elements include function points and business rules;

[0151] The construction module 502 is specifically used for:

[0152] Analyze the functional points and business rules, and construct business nodes based on the analysis results;

[0153] Natural language processing technology is used to identify the conditional statements in the business rules, and the logical flow and dependency relationships between the business nodes are determined based on the conditional statements.

[0154] Based on the logical flow and dependency relationships, each business node is connected to generate the business logic graph.

[0155] In some embodiments, the analysis module 503 is specifically used for:

[0156] Based on the service type of the service to be tested, multiple test dimensions are determined from a predefined set of test dimensions;

[0157] For each testing dimension, the following steps are performed: Based on the business logic diagram and the multiple requirement elements, at least one parent node to be tested under the dimension is determined, wherein the parent node represents the target test object under the dimension; for each parent node, the requirement elements associated with the parent node are decomposed to determine at least one child node, wherein the child node represents the target test sub-object of the corresponding parent node; each child node is used as a new parent node, and the requirement element decomposition steps are repeated until a preset node termination condition is met; at least one test point is generated based on the requirement elements associated with at least one target child node that meets the preset node termination condition.

[0158] Based on all test dimensions, the relationships between nodes at each level corresponding to each test dimension, and each test point, construct the test point map.

[0159] In some embodiments, the test dimension includes a functional dimension, and the test plan generation strategy corresponding to the functional dimension includes graph traversal algorithm, equivalence class partitioning method and boundary value analysis method;

[0160] The generation module 504 is specifically used for:

[0161] Using the graph traversal algorithm, at least one business flow path associated with the test point is located in the business logic graph;

[0162] The equivalence class partitioning method and the boundary value analysis method are used to generate test input data for the test points.

[0163] Based on the business flow path and the test input data, a test plan for the test points is generated.

[0164] In some embodiments, the test dimension further includes a performance dimension, and the test plan generation strategy corresponding to the performance dimension includes a stepped stress load method;

[0165] The generation module 504 is specifically used for:

[0166] Extract at least one performance indicator from the target requirement elements corresponding to the test points;

[0167] Based on the stepped pressure load method, load patterns and performance thresholds are generated for the at least one performance index;

[0168] Based on the load pattern and performance threshold, a test plan for the test points is generated.

[0169] In some embodiments, the testing dimension further includes a compatibility dimension, and the test plan generation strategy corresponding to the compatibility dimension includes orthogonal experimental design.

[0170] The generation module 504 is specifically used for:

[0171] Extract at least one environmental constraint from the target requirement elements corresponding to the test points;

[0172] Using the environmental constraints as input, the orthogonal experimental method is applied to generate a test plan for the test points.

[0173] In some embodiments, the testing dimension further includes a security dimension, and the test plan generation strategy corresponding to the security dimension includes a penetration testing path generation method based on a threat modeling knowledge base;

[0174] The generation module 504 is specifically used for:

[0175] Based on the threat modeling knowledge base, analyze the security risk points corresponding to the test points;

[0176] Using the penetration test path generation method, at least one penetration test path and verification steps for the security risk point are generated;

[0177] Based on the penetration testing path and verification steps for each security risk point, a test plan for the aforementioned test points is generated.

[0178] In some embodiments, the generation module 504 is specifically used for:

[0179] Based on a predefined test case template, create a data structure for the test case to be generated. The data structure includes the test case identifier, the function it belongs to, the test intent, the preconditions, the operation steps, the expected result, and some or all of the fields in the test data.

[0180] According to the predefined field mapping rules, the information contained in the test plan of the test points is filled into the corresponding fields of the data structure;

[0181] Based on the populated data structure, test cases for the aforementioned test points are generated.

[0182] Based on the same inventive concept, embodiments of this application provide an electronic device that can realize the function of the test case generation device discussed above. Please refer to... Figure 6 The device includes a memory 601, one or more processors 602, and a bus 603.

[0183] The memory 601 is used to store computer programs executed by the processor 601. The memory 601 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0184] Memory 601 may be volatile memory, such as random-access memory (RAM); memory 601 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 601 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 601 may be a combination of the above-described memories.

[0185] Processor 602 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 602 is used to implement the test case generation method in the above embodiments when calling the computer program stored in memory 602.

[0186] This application embodiment does not limit the specific connection medium between the memory 601 and the processor 602 described above. This application embodiment... Figure 6 The memory 601 and the processor 602 are connected via a bus 603, and the bus 603 is in Figure 6 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 603 bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0187] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when run on a computer, causes the computer to execute any of the test case generation methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the test case generation method, the implementation of the above-described computer-readable storage medium can refer to the implementation of the test case generation method; repeated details will not be elaborated further.

[0188] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the test case generation methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the test case generation method, the implementation of the above computer program product can refer to the implementation of the test case generation method, and the repeated parts will not be described again.

[0189] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0190] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0191] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0192] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0193] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for generating test cases, characterized in that, include: Semantic parsing is performed on the test requirement data of the business under test to extract multiple requirement elements; Based on each requirement element, a business logic diagram of the business to be tested is constructed; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the analysis of the requirement elements. Based on the business logic diagram and the predefined set of test dimensions, test point analysis is performed on the multiple requirement elements to generate a test point map containing multiple test dimensions. For each test point under each test dimension in the test point map, perform the following operations: determine the target requirement element corresponding to the test point from the requirement elements; based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point; Based on the test plan for the aforementioned test points, generate test cases for the aforementioned test points; Aggregate the test cases for each test point to generate a test case set corresponding to the service to be tested.

2. The method as described in claim 1, characterized in that, The required elements include functional points and business rules; The process of constructing the business logic diagram of the service to be tested based on various requirement elements includes: Analyze the functional points and business rules, and construct business nodes based on the analysis results; Natural language processing technology is used to identify the conditional statements in the business rules, and the logical flow and dependency relationships between the business nodes are determined based on the conditional statements. Based on the logical flow and dependency relationships, each business node is connected to generate the business logic graph.

3. The method as described in claim 1, characterized in that, The step involves analyzing the test points of the multiple requirement elements based on the business logic diagram and a predefined set of test dimensions, generating a test point map containing multiple test dimensions, including: Based on the service type of the service to be tested, multiple test dimensions are determined from a predefined set of test dimensions; For each testing dimension, the following steps are performed: Based on the business logic diagram and the multiple requirement elements, at least one parent node to be tested under the dimension is determined, wherein the parent node represents the target test object under the dimension; for each parent node, the requirement elements associated with the parent node are decomposed to determine at least one child node, wherein the child node represents the target test sub-object of the corresponding parent node; each child node is used as a new parent node, and the requirement element decomposition steps are repeated until a preset node termination condition is met; at least one test point is generated based on the requirement elements associated with at least one target child node that meets the preset node termination condition. Based on all test dimensions, the relationships between nodes at each level corresponding to each test dimension, and each test point, construct the test point map.

4. The method as described in claim 1, characterized in that, The testing dimensions include functional dimensions, and the test plan generation strategies corresponding to the functional dimensions include graph traversal algorithms, equivalence class partitioning, and boundary value analysis. The step of constructing a test plan for the test points based on the target requirement elements and invoking the test case generation strategy includes: Using the graph traversal algorithm, at least one business flow path associated with the test point is located in the business logic graph; The equivalence class partitioning method and the boundary value analysis method are used to generate test input data for the test points. Based on the business flow path and the test input data, a test plan for the test points is generated.

5. The method as described in claim 4, characterized in that, The testing dimension also includes a performance dimension, and the test plan generation strategy corresponding to the performance dimension includes the stepped stress load method. The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes: Extract at least one performance indicator from the target requirement elements corresponding to the test points; Based on the stepped pressure load method, load patterns and performance thresholds are generated for the at least one performance index; Based on the load pattern and performance threshold, a test plan for the test points is generated.

6. The method as described in claim 5, characterized in that, The testing dimension also includes a compatibility dimension, and the test plan generation strategy corresponding to the compatibility dimension includes the orthogonal experimental method. The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes: Extract at least one environmental constraint from the target requirement elements corresponding to the test points; Using the environmental constraints as input, the orthogonal experimental method is applied to generate a test plan for the test points.

7. The method as described in claim 6, characterized in that, The testing dimension also includes a security dimension, and the test plan generation strategy corresponding to the security dimension includes a penetration testing path generation method based on a threat modeling knowledge base; The step of constructing a test plan for the test points based on the target requirement elements and invoking the test plan generation strategy includes: Based on the threat modeling knowledge base, analyze the security risk points corresponding to the test points; Using the penetration test path generation method, at least one penetration test path and verification steps for the security risk point are generated; Based on the penetration testing path and verification steps for each security risk point, a test plan for the aforementioned test points is generated.

8. The method according to any one of claims 1 to 7, characterized in that, The step of generating test cases for the test points based on the test plan includes: Based on a predefined test case template, create a data structure for the test case to be generated. The data structure includes the test case identifier, the function it belongs to, the test intent, the preconditions, the operation steps, the expected result, and some or all of the fields in the test data. According to the predefined field mapping rules, the information contained in the test plan of the test points is filled into the corresponding fields of the data structure; Based on the populated data structure, test cases for the aforementioned test points are generated.

9. A test case generation device, characterized in that, include: The extraction module is used to perform semantic parsing on the test requirement data of the business under test and extract multiple requirement elements; The construction module is used to construct the business logic diagram of the business to be tested based on each requirement element; the business logic diagram represents the execution flow and logical branches of each business node obtained based on the analysis of the requirement elements; The analysis module is used to perform test point analysis on the multiple requirement elements based on the business logic diagram and the predefined test dimension set, and generate a test point map containing multiple test dimensions. The generation module is used to perform the following operations for each test point under each test dimension in the test point map: determine the target requirement element corresponding to the test point from the requirement elements; and, based on the target requirement element, call the test plan generation strategy corresponding to the test dimension to construct the test plan for the test point. Based on the test plan for the aforementioned test points, generate test cases for the aforementioned test points; The aggregation module is used to aggregate test cases for each test point and generate a test case set corresponding to the service under test.

10. An electronic device, characterized in that, include: At least one processor, and a memory communicatively connected to said at least one processor, wherein: The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-8.

Images