Test case generation method and device, equipment and storage medium

Abstract

The application relates to the technical field of interface testing, and discloses a test case generation method, device and equipment and a storage medium, which comprises the following steps: obtaining a natural language test requirement input by a user; performing intention recognition on the natural language test requirement input by the user to obtain a task type corresponding to the test intention of the user; performing reasoning on the natural language test requirement according to the task type to determine test configuration information; and generating an automatic test case based on the test configuration information. The user only needs to describe the test intention in a natural language, and the manual serial configuration can be converted into end-to-end automatic generation, without the need to master any special configuration syntax or script language, so that a complete automatic test case can be generated by one key, the learning cost tends to be zero, and the development threshold and time consumption of the test case are significantly reduced.

Description

Technical Field

[0001] This application relates to the field of interface testing technology, and in particular to a test case generation method, apparatus, device and storage medium. Background Technology

[0002] Currently, the generation of automated test cases mainly relies on manual configuration. Users need to build test processes by dragging and dropping nodes on a low-code platform, which involves multiple independent steps such as test data preparation, interface matching, and verification logic configuration. Each step requires user participation in the configuration, which is not only inefficient but also prone to errors. Summary of the Invention

[0003] The main purpose of this application is to provide a test case generation method, apparatus, device and storage medium, which aims to solve the technical problems of low efficiency and easy error caused by the current reliance on manual configuration of automated test cases.

[0004] To achieve the above objectives, this application proposes a test case generation method, which includes: Natural language testing requirements for obtaining user input; The user's input of natural language testing requirements is subjected to intent recognition to obtain the task type corresponding to the user's testing intent; Based on the task type, the natural language testing requirements are inferred to determine the test configuration information, which includes target data, target interface, and target verification logic. Automated test cases are generated based on the test configuration information.

[0005] Optionally, the step of reasoning about the natural language testing requirements based on the task type to determine the test configuration information includes: Based on the task type, perform static reasoning on the natural language testing requirements to determine the target data and target interface; Dynamic reasoning is performed based on the task type, the target data, and the target interface to determine the target verification logic.

[0006] Optionally, the step of performing static reasoning on the natural language testing requirements based on the task type to determine the target data includes: Obtain the data acquisition rules for the task type; When the data acquisition rule is of the first type, the natural language testing requirements are parsed to generate a data expression, and the data expression is used as the target data. When the data acquisition rule is of the second type, target data corresponding to the natural language testing requirements is acquired according to the preset rule corresponding to the second type.

[0007] Optionally, parsing the natural language testing requirements and generating data expressions includes: When the natural language testing requirements meet the preset format requirements, a data expression is generated according to the preset matching rules; When the natural language testing requirements do not meet the preset format requirements, the natural language testing requirements are parsed based on the first model to obtain the parsing results; If the first model is successfully parsed, the parsing result is mapped to a preset data processing function to generate a data expression; If the first model fails to parse, the second model is used to reason about the natural language testing requirements and generate a data expression.

[0008] Optionally, the step of performing static reasoning on the natural language testing requirements based on the task type to determine the target interface includes: Determine the target vector of the natural language testing requirements, and obtain the candidate interfaces corresponding to the target vector from the interface vector database; Obtain the interface metadata information of the candidate interfaces; The interface metadata information and the context information of the current test case are input into the agent so that the agent can determine the target interface from the candidate interfaces.

[0009] Optionally, the step of dynamically reasoning based on the task type, the target data, and the target interface to determine the target verification logic includes: Based on the task type, determine the verification object and corresponding expected value of the natural language testing requirement; Determine the verification baseline value based on the expected value, the target data, and the response message of the target interface; Target verification logic is generated based on the verification object and the verification benchmark value.

[0010] Optionally, the step of performing intent recognition on the natural language testing request input by the user to obtain the task type corresponding to the user's testing intent includes: Input the natural language testing requirements into the prompt word template and obtain the data extraction results; The task type for the natural language testing requirement is determined based on the data extraction results. The task type includes data preparation tasks, transaction sending tasks, and result verification tasks.

[0011] Furthermore, to achieve the above objectives, this application also proposes a test case generation apparatus, which includes: The acquisition module is used to acquire the user's input of natural language testing requirements; The recognition module is used to identify the intent of the natural language test request input by the user and obtain the task type corresponding to the user's test intent; The reasoning module is used to reason about the natural language testing requirements based on the task type and determine the test configuration information, which includes target data, target interface and target verification logic. The generation module is used to generate automated test cases based on the test configuration information.

[0012] In addition, to achieve the above objectives, this application also proposes a test case generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the test case generation method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the test case generation method described above.

[0014] This application obtains user-inputted natural language test requirements and performs intent recognition to determine the task type. Based on the task type, it then infers and determines the test configuration information, including target data, target interfaces, and target validation logic. Finally, it automatically generates complete automated test cases. Users only need to describe their test intent in natural language to transform manual, sequential configuration into end-to-end automated generation. No specialized configuration syntax or scripting language is required; users can generate complete automated test cases with a single click, reducing the learning curve to near zero and significantly lowering the development threshold and time required for test cases. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the test case generation method of this application; Figure 2 This is a diagram illustrating the overall design architecture of the test case generation method for this application. Figure 3This is a flowchart illustrating the reasoning process for this application case; Figure 4 This is a flowchart illustrating the second embodiment of the test case generation method of this application; Figure 5 A simplified flowchart illustrating a test case generation method; Figure 6 This is a schematic diagram of the module structure of the test case generation device in an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the test case generation method in this application embodiment.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions. The following description uses a test case generation system as an example to illustrate this embodiment and the subsequent embodiments.

[0022] Based on this, embodiments of this application provide a test case generation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the test case generation method of this application.

[0023] In this embodiment, the test case generation method includes: Step S10: Obtain the natural language testing requirements input by the user.

[0024] It should be noted that natural language testing requirements are the testing intentions described by users in natural language, and they include at least one of the following: test data information, interface call information, and expected result verification information. Input methods for natural language testing requirements include, but are not limited to, text input, voice input, or selection from preset templates. Users do not need to master any specialized configuration syntax or scripting languages.

[0025] Optionally, users can input the natural language testing requirements at each node of the model graph through a prompt word plugin. The prompt word plugin has built-in automated prompt word templates and supports intelligent completion of similar prompts.

[0026] Specifically, as an optional implementation, the user inputs natural language text into the graphical interface provided by the automated testing platform, such as "Test login interface, username is a randomly generated mobile phone number, expected login success and return of token". After receiving the natural language text, the client or server uses it as the natural language test requirement.

[0027] Understandably, when a user inputs the natural language testing requirements through the front-end page, the client obtains the input and sends it to the server for further processing; when the user inputs the requirements through the command line or API interface, the server directly receives the natural language testing requirements.

[0028] Step S20: Perform intent recognition on the natural language test request input by the user to obtain the task type corresponding to the user's test intent.

[0029] It should be noted that intent recognition refers to semantic understanding and classification of the natural language testing requests input by the user to determine the type of target task the user expects to perform. The task type characterizes the functional category to which the user's testing intent belongs, and includes at least one of data preparation tasks, transaction sending tasks, and result verification tasks. Specifically, a data preparation task indicates the need to prepare test data, a transaction sending task indicates calling the target interface to send a transaction, and a result verification task indicates verifying the transaction execution result.

[0030] Optionally, the natural language testing requirement can be categorized into any one or more of the three task types mentioned above. For example, if a user describes both data preparation and transaction sending requirements in a natural language testing requirement, the intent recognition result can simultaneously include both data preparation and transaction sending task types.

[0031] It is understandable that if the natural language testing requirements only contain partial types of test information, such as the user only inputting a description of the requirements related to data preparation but not a description related to transaction sending or result verification, then the intent recognition result will only contain one task type: data preparation. In this case, the target interface and target verification logic in the test configuration information can be determined according to the default rules or not configured for the time being, and will be supplemented in subsequent nodes.

[0032] In the specific implementation process, a built-in automated prompt word template can be used to support intelligent completion of similar prompts. The prompt word template is used to extract structured information from user input, efficiently and accurately extracting key test data, interface call information, and expected result verification information from unstructured natural language, providing clear and accurate task classification guidance for subsequent reasoning. At this point, step S20 may include: Input the natural language testing requirements into the prompt word template and obtain the data extraction results; The task type for the natural language testing requirement is determined based on the data extraction results. The task type includes data preparation tasks, transaction sending tasks, and result verification tasks.

[0033] It should be noted that the prompt word template is a pre-configured, standardized prompt template used to guide the large language model in producing structured output. It defines the information fields to be extracted from the natural language text and their output format. The data extraction result is structured information extracted from natural language testing requirements.

[0034] Specifically, as an optional implementation, the natural language testing requirements are input into a preset prompt word template. The prompt word template includes field extraction instructions, which instruct the large language model to extract specified field information from the input text and output the data extraction results in a preset format. The data extraction results include test data information, interface call information, and expected result verification information.

[0035] After obtaining the data extraction results, the task type corresponding to the natural language testing requirement is determined based on whether each field in the data extraction results contains valid extracted content. For example, if the test data information field in the data extraction results contains valid content, the natural language testing requirement is determined to include a data preparation task; if the interface call information field contains valid content, the natural language testing requirement is determined to include a transaction sending task; and if the expected result verification information field contains valid content, the natural language testing requirement is determined to include a result verification task.

[0036] Step S30: Based on the task type, reason about the natural language testing requirements to determine the test configuration information, which includes target data, target interface, and target verification logic.

[0037] It should be noted that, based on the task type, the natural language testing requirements can be semantically parsed, information mapped, and decision generated to transform the test requirements described in natural language into structured configuration information that can be executed by the automated testing framework.

[0038] Test configuration information is a set of core elements required to generate automated test cases, including target data, target interfaces, and target verification logic. Target data refers to the input data required to execute test cases, including but not limited to general generated data (such as random IDs, date data in specific time formats, etc.), data retrieved from the product database or data pool, data generated by user-defined scripts, and data obtained through external data generation interfaces. Target interfaces refer to the target application interface to be tested, including registered interfaces and custom component interfaces. Target verification logic is used to verify whether the test execution results meet expectations, including message expected value verification logic and database expected value verification logic.

[0039] Step S40: Generate automated test cases based on the test configuration information.

[0040] It should be noted that generating automated test cases can involve assembling the test configuration information according to a preset case structure, replacing parameters, and chaining actions to form a complete test case that can be recognized and executed by the automated testing framework. The automated test case includes an executable program or executable configuration script containing at least one of the following actions: data preparation, transaction sending, and result verification. This executable program or script can be loaded and executed on the automated testing platform. The preset case structure can also be a data structure defined by the automated testing platform to describe the test process, containing multiple sequentially arranged nodes. Each node corresponds to different functional types such as data preparation, transaction sending, and result verification, and the nodes are connected through data flow and control flow.

[0041] It is understood that by filling the target data, target interface, and target verification logic from the test configuration information into the corresponding types of nodes and establishing data transfer relationships between the nodes, a complete executable test case can be output. Optionally, the preset case structure is a model graph structure, which contains multiple nodes and connections between nodes. Each node corresponds to a test action, and the connections represent the execution order and data flow between test actions.

[0042] Specifically, as an optional implementation, generating automated test cases may include associating the target data, the target interface, and the target verification logic according to a preset case structure; passing the target data to the target interface and configuring the target verification logic according to the process context; and performing parameter replacement and action chaining on the associated preset case structure to generate the automated test cases.

[0043] The step of associating the target data, the target interface, and the target verification logic according to a preset case structure can be as follows: creating a first node corresponding to the data preparation action and filling the output field of the first node with the target data; creating a second node corresponding to the transaction sending action and filling the interface field of the second node with the target interface; creating a third node corresponding to the result verification action and filling the verification rule field of the third node with the target verification logic; and connecting the first node, the second node, and the third node sequentially according to the execution order.

[0044] The step of passing the target data to the target interface according to the process context may include determining the mapping relationship between the output fields of the first node and the input fields of the second node; and, according to the mapping relationship, using the target data obtained after executing the data expression in the first node as the input parameter of the target interface in the second node. For example, if the target data generated in the data preparation node is a mobile phone number, then the mobile phone number is passed to the "mobile phone number" input parameter field of the transfer interface in the transaction sending node.

[0045] Configuring the target verification logic can include binding the target verification logic to the output result of the second node, so that after the automated test case completes the transaction sending action, it automatically calls the target verification logic to verify the execution result of the transaction sending action. For example, for the response message of the transfer interface, the verification logic can be configured to verify that the transaction status field in the response message is "successful" and the account balance field has increased by the corresponding amount.

[0046] The parameter replacement and action chaining of the associated preset case structure can involve identifying variable placeholders in the preset case structure, replacing each variable placeholder with the corresponding actual value or expression in the test configuration information, and chaining the execution actions of each associated node into a complete execution flow according to the node connection order to generate the automated test case. The variable placeholders are markers used to identify positions to be filled in the preset case structure, including but not limited to data placeholders, interface placeholders, and validation logic placeholders. For example, if the preset case structure is "Prepare data variables, call interface name, validate expected result", the corresponding variable placeholders are data, interface name, and expected result, respectively. The target data "random mobile phone number", the target interface "transfer interface", and the target validation logic "transfer successful and account balance increased by the corresponding amount" are replaced with the placeholders, and then chained together to generate a complete automated test case.

[0047] In another optional implementation, generating automated test cases may further include: inputting the target data, the target interface, and the target verification logic into the master agent; the master agent autonomously decides the execution order and parameter passing method of each node based on the context information of the current model graph, and calls the corresponding action executors to complete the configuration and concatenation of each node, thereby generating the automated test cases. Here, the master agent is an autonomous decision-making intelligent agent built based on a large language model, capable of reasoning and making decisions based on the input test configuration information and context information, and coordinating various components to complete the assembly of test cases.

[0048] Optionally, before associating the target data, the target interface, and the target verification logic according to a preset case structure, the method further includes: obtaining a model graph template selected by the user, wherein the model graph template is a pre-configured model graph framework containing a fixed node structure and connection relationships between nodes; and determining, based on the task type, target nodes matching the task type and target connection relationships between each target node from the model graph template, as the preset case structure. For example, when the task type includes a data preparation task, a transaction sending task, and a result verification task, a model graph template containing data preparation nodes, transaction sending nodes, and result verification nodes connected in sequence is selected as the preset case structure; when the task type only includes a data preparation task, a model graph template containing only data preparation nodes is selected as the preset case structure.

[0049] Optionally, after generating the automated test cases, the method further includes: storing the automated test cases in a case management platform and assigning corresponding test case identifiers to the automated test cases, so that users can view, edit, execute and manage the automated test cases through the test case identifiers.

[0050] It is understandable that when any item in the target data, target interface, or target verification logic in the test configuration information is null, the corresponding type of node can be skipped or set as a null operation node when associating the target data, target interface, and target verification logic according to the preset case structure. For example, when the task type is only a data preparation task, both the target interface and the target verification logic are null values. In this case, the preset case structure only contains the data preparation node, while the transaction sending node and result verification node are skipped, and the generated automated test case is a test case that only contains the data preparation action.

[0051] In one example, reference Figure 2 , Figure 2This is the overall architecture diagram of the test case generation method in this application. The core inference service is completed by three layers of progressive inference. The bottom layer services include the LLM large language model and the MCP Server. The LLM large language model provides natural language understanding and generation capabilities for the entire device, while the MCP Server provides model context protocol services to support standardized access and invocation of external tools. The core inference service further includes four parts: a user intent recognition module, a static inference module, an agent dynamic inference module, and a toolset. The user intent recognition module performs semantic parsing on the user's input natural language test requirements using the large model Prompt, extracting variable information, interface information, and message and database verification requirements, and outputting the intent recognition result. The static inference module uses the LLM + Agent + Few-shot method based on the intent recognition result. The system employs various technologies, including learning mechanisms, self-trained models, RAG (Retrieval Enhanced Generation), NLP2SQL, Agent+Agent multi-agent collaboration, and Agent+MCP service calls, to perform inference tasks such as general language expression generation, acquisition of interface information for product-personalized encapsulation components, database data retrieval, and expected value verification. It then outputs the static inference results, model graph information, and historical inference experience to the Agent dynamic inference module. The Agent dynamic inference module, through the Agent, performs comprehensive dynamic inference decisions based on the static inference results, model graph information, and historical inference experience, and outputs the decision results to the toolset. The toolset includes a number expression generation tool, an interface reasoning tool, a test case generation tool, and a product personalization MCP service. These tools are used to generate expression for target data, perform matching reasoning for target interfaces, assemble and generate automated test cases, and extend the product personalization capabilities based on the intermediate and decision results of static and dynamic reasoning, respectively. The application layer includes a model diagram platform and an automated test case management platform. The model diagram platform provides users with a visual interface for drawing flowcharts, allowing users to describe test intents in natural language at each node of the model diagram. The automated test case management platform is used to uniformly store, view, edit, execute, and manage the generated automated test cases.

[0052] In one example, reference Figure 3 , Figure 3This is a flowchart of the case inference process for this application. The main inference process for the Agent case uses pre-input information as the starting point. The pre-input includes test data, interface information, historical successful inference records, and expected result verification. The test data provides the identified or generated target data. The interface information provides the complete definition information of the matched or identified target interface. The historical successful inference records provide the configuration information of previously verified automated cases and their corresponding natural language description information. The expected result verification provides the identified or generated target verification logic. After the pre-input is ready, the process enters the start node, followed by the inference result reuse judgment step, which utilizes context memory and a cache. The system determines the similarity between the current natural language testing requirement and the cached historical natural language testing requirements by performing node similarity matching, variable similarity matching, and interface similarity matching respectively. Node similarity matching calculates the structural similarity between the current model graph nodes and nodes in historical cases; variable similarity matching calculates the semantic similarity between the current data variables and variables in historical cases; and interface similarity matching calculates the functional similarity between the current interface to be matched and interfaces in historical cases. If a match is successful, the cached inference result is directly reused, and subsequent inference steps are skipped to improve efficiency. If a match fails, the system enters the Agent toolset invocation phase. The Agent toolset includes a TDM parsing tool, a TDM generation tool, an expected result verification tool, and a dynamic parameter parsing tool. The TDM parsing tool parses test data retrieved from a database. The TDM generation tool generates general test data expressions based on natural language descriptions. The expected result verification tool performs automated verification of transaction sending results. The dynamic parameter parsing tool dynamically parses the input parameter values ​​required for interface calls based on interface definitions and context. The Agent sends transactions by calling different tools in the Agent toolset, trying different combinations of interfaces and parameters, and observes the transaction results after each sending. During the transaction sending and result observation process, the Agent invokes the interface reasoning tool to select the optimal interface from the candidate interfaces and invokes the error analysis tool to record the reasons for failure when a transaction fails and determine the adjustment strategy based on the reasons for failure. After the Agent completes the transaction sending and obtains the expected transaction results, the process enters the automation action conversion stage. This stage converts the automation steps of each node in the model diagram into automation components available to FA (Flow Automation). These automation components are standardized executable units that can be recognized and executed by the automation testing framework. Finally, the process enters the end node, completing the full automation test case generation process.

[0053] In this embodiment, by acquiring the user's natural language test requirements and performing intent recognition, the task type is obtained. Then, based on the task type, test configuration information including target data, target interface, and target verification logic is determined, and finally, complete automated test cases are automatically generated. Users only need to describe their test intent in natural language to transform manual, sequential configuration into end-to-end automatic generation. No specialized configuration syntax or scripting language is required; a complete automated test case can be generated with a single click, reducing the learning cost to near zero and significantly lowering the development threshold and time consumption for test cases.

[0054] Reference Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the test case generation method of this application. Based on the first embodiment described above, a second embodiment of the test case generation method of this application is proposed.

[0055] In the second embodiment, step S30 includes: Step S301: Perform static reasoning on the natural language testing requirements based on the task type to determine the target data and target interface.

[0056] It should be noted that static inference involves semantic parsing and information mapping of the natural language testing requirements based on the task type to determine the input data required to execute test cases and the target interfaces to be invoked. This static inference does not rely on the response messages returned by the actual transaction execution; instead, it performs offline inference based on existing knowledge bases, rule bases, and pre-stored interface definition information.

[0057] It is understood that the target data refers to the input data required to execute test cases, including but not limited to general generated data, data retrieved from the product database or data pool, data generated by user-defined scripts, and data obtained through external data generation interfaces. The target interface is the target application interface to be tested, including at least one of registered interfaces and custom component interfaces.

[0058] In the specific implementation process, different target data determination methods can be adopted according to different types of data acquisition rules, so that different types of data acquisition needs can be handled efficiently and in a targeted manner. This covers both general data generation scenarios and is compatible with diverse data source scenarios such as database data retrieval, script-based data generation, and interface-based data generation, improving the comprehensiveness and flexibility of test data preparation. At this point, step S301 may include: Step S3011: Obtain the data acquisition rules for the task type.

[0059] It should be noted that the data acquisition rules are used to characterize the data preparation methods adopted for the current natural language testing requirements, including a first type and a second type. The first type corresponds to a general data generation method, which obtains the target data by parsing the natural language testing requirements and generating corresponding data expressions. The second type corresponds to any one of the following methods: database data retrieval, script-based data generation, and interface-based data generation, which obtains the target data by interacting with external data sources or executing preset scripts.

[0060] Step S3012: If the data acquisition rule is of the first type, the natural language test requirement is parsed to generate a data expression, and the data expression is used as the target data.

[0061] It is understood that, in the case of the data acquisition rule being of the first type, the data expression can be an executable code snippet, function call statement, or configuration expression, which can be invoked during the execution of automated test cases to generate specific data values ​​that meet the requirements. The parsing of the natural language test requirements can involve semantic understanding, information extraction, and format conversion of the descriptive information related to data preparation in the natural language test requirements to determine the required data type, data format, data range, and constraints, and then converting this information into a structured data expression.

[0062] In the specific implementation process, in order to ensure high accuracy while keeping the generation time to a very low level, thus balancing the efficiency and quality of data generation, the step of parsing the natural language testing requirements and generating data expressions may include: When the natural language testing requirements meet the preset format requirements, a data expression is generated according to the preset matching rules; When the natural language testing requirements do not meet the preset format requirements, the natural language testing requirements are parsed based on the first model to obtain the parsing results; If the first model is successfully parsed, the parsing result is mapped to a preset data processing function to generate a data expression; If the first model fails to parse, the second model is used to reason about the natural language testing requirements and generate a data expression.

[0063] It is understood that the preset format requirement means that the natural language testing requirements conform to a preset regular expression pattern or keyword combination pattern, and the preset format requirement is used to quickly identify the format. The preset matching rules include regular expression matching rules and keyword mapping rules. The regular expression matching rules are used to quickly match the natural language testing requirements using pre-compiled regular expressions, and the keyword mapping rules are used to map the keywords in the natural language testing requirements to the corresponding data processing functions through a keyword mapping table.

[0064] It should be understood that the preset matching rules pre-configure regular expression templates for various common data generation scenarios and their corresponding data processing function mapping relationships. For example, for instructions conforming to the format "AB integer", they are directly mapped to a random integer generation function within a specified range after regular expression matching; instructions conforming to the format "A random number" are mapped to a random number generation function with a specified number of digits; instructions conforming to the format "random mobile phone number" are mapped to a mobile phone number generation function; instructions conforming to the format "YYYY-MM-DD" are mapped to a date generation function; and instructions conforming to the format "random ID card number" are mapped to an ID card number generation function. Through these preset matching rules, approximately 40% of high-frequency, simple requests can be quickly intercepted and processed before entering the large language model, ensuring inference efficiency.

[0065] It is understood that the first model is a lightweight semantic model, smaller in scale than the second model, used to map natural language understanding input to a preset method space and extract parameters such as numerical values ​​and date formats. The first model includes, but is not limited to, small semantic parsing models based on the Transformer architecture or slot-filling-based intent recognition and slot parsing models, suitable for handling personalized expressions with diverse semantics but fixed patterns. The first model maps natural language input to a preset data processing method space, extracts key parameters such as numerical range, date format, string length, and data type from the natural language testing requirements, and fills the extracted parameters into the corresponding data processing functions to generate executable data expressions.

[0066] It is understood that the second model is a large language model, larger in scale than the first model, used for reasoning on complex nested scenarios through Few-shot Learning when the first model cannot parse the data. The second model includes, but is not limited to, the Qwen series of large language models, the GPT series of large language models, or the LLaMA series of large language models. The second model uses Few-shot Learning, that is, by providing multiple examples of data expressions generated in the prompt words (i.e., example learning samples), to guide the large language model to understand the data generation logic corresponding to the current natural language testing requirements and output data expressions that meet the requirements. Optionally, the examples are a pre-built example library containing multiple pairs of natural language descriptions and corresponding data expressions.

[0067] Specifically, the process first determines whether the natural language testing requirement meets the preset format requirements. If it does, the system quickly matches and generates the corresponding data expression using preset matching rules (such as a pre-compiled regular expression engine combined with a keyword mapping table). This ensures that approximately 40% of high-frequency, simple requests are quickly intercepted and processed before the large language model intervenes, guaranteeing inference efficiency. If the natural language testing requirement does not meet the preset format requirements, the system calls a first model (a lightweight semantic model) to perform semantic parsing on the natural language testing requirement. This first model maps the natural language input to a preset method space and extracts key parameters such as numerical values ​​and date formats. If the first model parses successfully, the parsing result is mapped to a preset data processing function to generate a data expression, supporting personalized expressions with diverse semantics but fixed patterns. If the first model fails to parse (e.g., when facing natural language testing requirements with complex constraints or nested structures), the system calls a second model (a large language model) to perform inference on the natural language testing requirement using a Few-shot Learning approach. By providing multiple sample data expression generation examples in the prompts, the system guides the large language model to understand the data generation logic of the current requirement and output the data expression, thus ensuring the accuracy of data expression generation in complex scenarios.

[0068] Step S3013: If the data acquisition rule is of the second type, acquire the target data corresponding to the natural language testing requirements according to the preset rule corresponding to the second type.

[0069] It should be noted that the second type can include database data retrieval, script-based data generation, and interface-based data generation. The database data retrieval method obtains target data by querying a database; the script-based data generation method generates target data by executing a user-defined script (such as a Python script); and the interface-based data generation method obtains target data by calling an external data generation interface. The preset rules corresponding to the second type include database data retrieval rules for the database data retrieval method, script-based data generation rules for the script-based data generation method, and interface-based data generation rules for the interface-based data generation method. Obtaining the target data corresponding to the natural language testing requirements according to the preset rules corresponding to the second type can be achieved by using preset rules matching the specific data acquisition method corresponding to the data acquisition rule to obtain the target data from the corresponding data source.

[0070] Specifically, as an optional implementation, when the data acquisition rule is the database retrieval method in the second type, the step of acquiring the target data corresponding to the natural language testing requirement according to the preset rule corresponding to the second type includes: when the natural language testing requirement contains a database table name, displaying the database connection information corresponding to the database table name; acquiring a selection instruction for the database connection information, and determining the target database connection information according to the selection instruction; converting the natural language testing requirement into a database query statement according to the target database connection information; executing the database query statement to obtain the query result, and using the query result as the target data.

[0071] The database connection information includes connection parameters such as database address, database name, username, and password, used to establish a connection with the target database. Displaying the database connection information corresponding to the database table name specifically involves dynamically displaying a list of database connection information associated with the table name when the user enters the table name via a prompt word plugin. After the user selects a table, the correct database connection information is automatically provided. The generation of the database query statement uses NLP2SQL technology, which utilizes a large language model to convert the database operation requirements described in natural language into structured query statements (such as SQL statements).

[0072] Optionally, converting the natural language testing requirement into a database query statement based on the target database connection information includes: determining the target data table corresponding to the database query statement based on the target database connection information; when the target data table is a partitioned table, determining the actual table name corresponding to the partitioned table based on the current system time; and generating the database query statement based on the actual table name and the natural language testing requirement. The partitioned table is a data table stored in a partitioned database according to a time dimension (such as year, month) or other dimensions, for example, an order table stored by year as order_202x, order_202y, etc. Optionally, when converting the natural language testing requirement into a database query statement, if the number of data table fields involved in the natural language testing requirement exceeds a preset threshold, then using Embedding vector retrieval, the Top N fields with the highest semantic relevance to the natural language testing requirement are selected from all fields of the data table, and only the Top N fields are included in the prompt words of the large language model to avoid the token length problem. The preset threshold can be pre-configured according to the context window size of the large language model. Optionally, after executing the database query statement to obtain the query result, the method further includes: associating the query result with the natural language testing requirement and storing it in the query cache to accelerate the subsequent query speed for the same or similar natural language testing requirements.

[0073] In one example, the user's input natural language test requirement is "Query an order number with a paid status from the order table," where the task type includes a data preparation task, and the data retrieval rule is determined to be the database retrieval method in the second type. The natural language test requirement includes the database table name "order table." The system dynamically displays a list of database connection information associated with this table name (such as test environment database, pre-release environment database, etc.) when the user inputs "order table" via a prompt word plugin. The user selects the test environment database as the target database connection information by clicking. After determining the target database connection information, the system uses NLP2SQL technology to convert "Query an order number with a paid status from the order table" into the database query statement "SELECT order_id FROM order WHERE status='paid' LIMIT 1". If the `order` table is a partitioned table stored by year (e.g., `order_202x`, `order_202y`), and the current system time is 202y, then the actual table name is determined to be `order_202y` based on the current system time, and the database query statement "SELECT order_id FROM order_202y WHERE status='Paid' LIMIT 1" is generated. Executing this query statement yields the query results as the target data.

[0074] Optionally, when the data acquisition rule is the script-based data generation method in the second type, the step of acquiring the target data corresponding to the natural language testing requirements according to the preset rule corresponding to the second type includes retrieving a matching target script from a preset script library according to the natural language testing requirements; executing the target script to obtain the script execution result, and using the script execution result as the target data.

[0075] Optionally, when the data acquisition rule is the interface data generation method in the second type, the step of acquiring the target data corresponding to the natural language testing requirements according to the preset rule corresponding to the second type includes sending the natural language testing requirements to an external data generation interface, receiving the data generation result returned by the external data generation interface, and using the data generation result as the target data.

[0076] In the specific implementation process, semantic retrieval can accurately recall semantically relevant candidate interfaces, and the Agent decision engine can intelligently select the best interface by combining the process context. The entire process can automatically complete interface matching and optimal selection without requiring users to manually search for interfaces, compare documents, or debug parameters, thus improving the efficiency and accuracy of interface matching. At this point, the step of performing static reasoning on the natural language testing requirements based on the task type to determine the target interface may include: Determine the target vector of the natural language testing requirements, and obtain the candidate interfaces corresponding to the target vector from the interface vector database; Obtain the interface metadata information of the candidate interfaces; The interface metadata information and the context information of the current test case are input into the agent so that the agent can determine the target interface from the candidate interfaces.

[0077] It should be noted that determining the target vector for the natural language testing requirements can be achieved by converting the descriptive information related to interface calls in the natural language testing requirements into a fixed-dimensional vector representation using a natural language model. The interface vector database is a database formed by pre-converting the names, descriptions, scenarios, and other information of each interface into vectors using a natural language model and storing them. It is used to support semantic retrieval based on vector similarity calculations. The interface metadata information includes complete definition information of the interface, such as interface name, input parameter list, output parameter list, parameter type, parameter format constraints, the product line to which the interface belongs, and the interface version number.

[0078] The context information of the current test case includes, but is not limited to, the node type of the current model graph (such as a transaction sending node), the configured data flow information (including the output fields and data types of the preceding data preparation nodes), the processing results of the preceding nodes, and the preceding node identifier of the current node. The agent is an autonomous decision-making agent built based on a large language model, capable of reasoning and making decisions based on input information. The agent comprehensively analyzes the interface metadata information and the context information of the current test case by calling the large language model, and determines the target interface that best matches the natural language testing requirements from the candidate interfaces.

[0079] Specifically, as an optional implementation, converting the natural language testing requirement into a vector can be achieved by inputting the second clause corresponding to the transaction sending task in the natural language testing requirement into an embedding model, which then converts the second clause into a dense vector of fixed dimensions, serving as the target vector of the natural language testing requirement. Obtaining candidate interfaces corresponding to the target vector from the interface vector database can be achieved by calculating the vector similarity (e.g., cosine similarity or Euclidean distance) between the target vector and each interface vector in the interface vector database; based on the vector similarity, selecting the Top K interface vectors with the highest similarity from the interface vector database, and using the interfaces corresponding to each of the Top K interface vectors as candidate interfaces. The K value of Top K can be pre-configured according to actual retrieval accuracy requirements, for example, set to 5 or 10.

[0080] Step S302: Perform dynamic reasoning based on the task type, the target data, and the target interface to determine the target verification logic.

[0081] In the specific implementation process, the expected results described in natural language can be converted into executable verification logic to handle constant values, variable extraction, and complex processing logic respectively. This eliminates the need for manually writing complex verification expressions, significantly reducing the difficulty and error rate of verification configuration, especially in complex scenarios such as nested messages. At this point, step S302 may include: Based on the task type, determine the verification object and corresponding expected value of the natural language testing requirement; Determine the verification baseline value based on the expected value, the target data, and the response message of the target interface; Target verification logic is generated based on the verification object and the verification benchmark value.

[0082] It should be noted that the target verification logic is used to verify whether the execution results of automated test cases meet expectations. It may include message expected value verification logic and database expected value verification logic. Specifically, the message expected value verification logic is used to verify the field values ​​in the response message of the target interface, and the database expected value verification logic is used to verify the field values ​​in the database.

[0083] It should be understood that the dynamic reasoning differs from static reasoning. It relies on the response message structure information of the target interface and the already determined target data and target interface information for reasoning, rather than solely on the natural language testing requirements themselves. The verification object is the target to be verified, including messages and databases. When the verification object is a message, it specifically refers to a specific field in the response message of the target interface; when the verification object is a database, it specifically refers to a specific field in a specific table within the database. The expected value is the value or condition that the user expects the verification object to reach or satisfy after transaction execution. The verification benchmark value is a standard value used to compare with the actual value of the verification object.

[0084] Optionally, the dynamic reasoning is performed when the task type includes a result verification task; when the task type does not include a result verification task, the target verification logic can be determined according to default rules or set to a null value.

[0085] Specifically, the clauses in the natural language testing requirements that correspond to the result verification task are input into the verification parsing model, which then outputs the verification object and the expected value corresponding to the verification object. For example, if the user inputs the natural language testing requirement as "expected successful transfer and account balance increase by the corresponding amount," the verification parsing model extracts the verification object as the "transaction status" field and the "account balance" field in the response message, with the corresponding expected values ​​being "success" and "original balance + transaction amount," respectively.

[0086] Next, the type of the expected value is identified, including constant type, variable type, and processing logic type; based on the type of the expected value, a verification benchmark value is determined. Specifically, the expected value for the constant type is a fixed numerical value or string. The expected value for the variable type is a value that needs to be dynamically extracted from the determined target data, or a value that needs to be dynamically extracted from the response message of the target interface. The expected value for the processing logic type is a value that needs to be obtained after computation or logical processing.

[0087] When the expected value is a constant, it is directly used as the verification benchmark value. For example, if the expected value is "success" or "0", then "success" or "0" is directly used as the verification benchmark value to generate a verification expression to verify whether the actual value of the verification object is equal to the constant value.

[0088] When the expected value is a variable type, the source of the expected value is determined, including the target data and the response message of the target interface. When the source of the expected value is the target data, the corresponding field value is extracted from the determined target data as a verification benchmark value; when the source of the expected value is the response message of the target interface, a JSONPath format extraction expression is generated to extract the corresponding field value from the response message of the target interface as a verification benchmark value.

[0089] When the expected value is of the processing logic type, the fields in the target data and / or the response message of the target interface are processed to obtain the verification baseline value. The processing includes, but is not limited to, arithmetic operations, logical operations, aggregation operations, and string operations.

[0090] Finally, the target verification logic is generated based on the verification object and the verification baseline value. When the verification object is a message, the verification object is converted into an extraction expression in JSONPath format to locate and extract the actual value of the corresponding field from the response message of the target interface; the verification baseline value is combined with the extraction expression to generate a message verification expression, which serves as the target verification logic.

[0091] When the verification object is a database, the verification object is converted into a database query verification expression. The database query verification expression includes the target data table name, the target field name, and the corresponding verification benchmark value, so that the corresponding field value is queried from the database and compared with the verification benchmark value during execution.

[0092] In this embodiment, the static reasoning stage uses a knowledge base and rules to quickly lock in basic configuration information, while the dynamic reasoning stage uses actual data and interface responses to accurately deduce the verification logic, which not only ensures reasoning efficiency but also improves the accuracy of matching the verification logic with the actual execution results.

[0093] For example, to help understand the implementation flow of the test case generation method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 5 , Figure 5 This is a simplified flowchart of a test case generation method. Specifically, the process is divided into three main stages: user intent recognition, static reasoning, and dynamic reasoning.

[0094] User intent recognition begins with the creation of user prompts. During this process, the system utilizes a small-parameter model for slice-based inference enhancement, while simultaneously processing node prompts using personalized user predictions. This integrated information is then driven by LLM prompts and instance JSON information. Next, the system executes three parallel actions: extracting test data variables, extracting interfaces, and identifying expected message values ​​and database expectations. Finally, it integrates information including node constraint information, interface information, and expected value information to generate JSON information for the intent-recognized instance. This information will be used as input for the next stage of static inference.

[0095] After receiving the JSON information of the user intent during the static inference phase, the system proceeds to the "Data Preparation Inference Service." This service performs inference through four parallel paths: general function expression inference using the self-trained model SLM; database data retrieval inference using TEXT2SQL; custom continuous inference using RAG retrieval; and agent function inference using Agent-MCP. The results of these four inference paths are converged in the test data inference result verification stage. After verification, the data flows to the interface inference service. In the interface inference service, the system retrieves the FA-registered interfaces through the vector database RAG retrieval, obtains the single-interface dimension group component through RAG retrieval, and performs vector database RAG retrieval in conjunction with FastAPI. Subsequently, the interface inference is cached, and the system proceeds to the expected result inference service. This service again uses TEXT2SQL to calculate the expected DB value and the expected message value, ultimately generating static inference post-inference instance JSON information containing the TDM expression, interface information, and expected result verification. This information forms the basis for entering the dynamic inference phase.

[0096] The dynamic inference phase begins by parsing the static values ​​of the functions. The system checks if all parsing was successful. If it fails, a function repair tool is used to fix the issues until successful. After successful parsing, the system enters the interface dynamic inference phase, calling the traditional Agent to retrieve N forward and backward interfaces from the vector database. During this process, the system calls the React Agent execution module, which combines the context memory, cache database, model inference context, and Agent long-term memory to execute tool calls, result verification, and result validation. After dynamic inference is complete, the system sends the transaction and checks if the transaction was sent successfully. If the sending fails, variable and interface issues are fixed, and the process is retried. If the sending is successful, an automated FA case is generated, and the inference results are stored in the database as a cache. The entire process then ends.

[0097] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the test case generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0098] This application also provides a test case generation device, please refer to... Figure 6 The test case generation device includes: Module 10 is used to acquire the user's input of natural language testing requirements; The recognition module 20 is used to perform intent recognition on the natural language test requirements input by the user, and obtain the task type corresponding to the user's test intent; Inference module 30 is used to infer the natural language testing requirements based on the task type and determine test configuration information, the test configuration information including target data, target interface and target verification logic; The generation module 40 is used to generate automated test cases based on the test configuration information.

[0099] The test case generation device provided in this application, employing the test case generation method in the above embodiments, can solve the technical problems of low efficiency and error-proneness caused by the reliance on manual configuration of current automated test cases. Compared with the prior art, the beneficial effects of the test case generation device provided in this application are the same as those of the test case generation method provided in the above embodiments, and other technical features in the test case generation device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0100] This application provides a test case generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the test case generation method in Embodiment 1 above.

[0101] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a test case generation device suitable for implementing embodiments of this application. The test case generation device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The test case generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0102] like Figure 7 As shown, the test case generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the test case generation device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the test case generation device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows test case generation devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0103] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0104] The test case generation device provided in this application, employing the test case generation method in the above embodiments, can solve the technical problems of low efficiency and error-proneness caused by the reliance on manual configuration of current automated test cases. Compared with the prior art, the beneficial effects of the test case generation device provided in this application are the same as those of the test case generation method provided in the above embodiments, and other technical features in this test case generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0105] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0107] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the test case generation method in the above embodiments.

[0108] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0109] The aforementioned computer-readable storage medium may be included in the test case generation device; or it may exist independently and not assembled into the test case generation device.

[0110] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the test case generation device, cause the test case generation device to perform the test case generation method described above.

[0111] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0113] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0114] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described test case generation method. This solves the technical problem of low efficiency and error-proneness caused by the reliance on manual configuration for automated test cases. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the test case generation method provided in the above embodiments, and will not be repeated here.

[0115] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0116] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

Claims

1. A test case generation method, characterized in that, The test case generation method includes: Natural language testing requirements for obtaining user input; The user's input of natural language testing requirements is subjected to intent recognition to obtain the task type corresponding to the user's testing intent; Based on the task type, the natural language testing requirements are inferred to determine the test configuration information, which includes target data, target interface, and target verification logic. Automated test cases are generated based on the test configuration information.

2. The test case generation method as described in claim 1, characterized in that, The step of reasoning about the natural language testing requirements based on the task type to determine the test configuration information includes: Based on the task type, perform static reasoning on the natural language testing requirements to determine the target data and target interface; Dynamic reasoning is performed based on the task type, the target data, and the target interface to determine the target verification logic.

3. The test case generation method as described in claim 2, characterized in that, The step of performing static reasoning on the natural language testing requirements based on the task type to determine the target data includes: Obtain the data acquisition rules for the task type; When the data acquisition rule is of the first type, the natural language testing requirements are parsed to generate a data expression, and the data expression is used as the target data. When the data acquisition rule is of the second type, target data corresponding to the natural language testing requirements is acquired according to the preset rule corresponding to the second type.

4. The test case generation method as described in claim 3, characterized in that, The process of parsing the natural language testing requirements and generating data expressions includes: When the natural language testing requirements meet the preset format requirements, a data expression is generated according to the preset matching rules; When the natural language testing requirements do not meet the preset format requirements, the natural language testing requirements are parsed based on the first model to obtain the parsing results; If the first model is successfully parsed, the parsing result is mapped to a preset data processing function to generate a data expression; If the first model fails to parse, the second model is used to reason about the natural language testing requirements and generate a data expression.

5. The test case generation method as described in claim 2, characterized in that, The step of performing static reasoning on the natural language testing requirements based on the task type to determine the target interface includes: Determine the target vector of the natural language testing requirements, and obtain the candidate interfaces corresponding to the target vector from the interface vector database; Obtain the interface metadata information of the candidate interfaces; The interface metadata information and the context information of the current test case are input into the agent so that the agent can determine the target interface from the candidate interfaces.

6. The test case generation method as described in claim 2, characterized in that, The step of dynamically reasoning based on the task type, the target data, and the target interface to determine the target verification logic includes: Based on the task type, determine the verification object and corresponding expected value of the natural language testing requirement; Determine the verification baseline value based on the expected value, the target data, and the response message of the target interface; Target verification logic is generated based on the verification object and the verification benchmark value.

7. The test case generation method according to any one of claims 1 to 6, characterized in that, The process of performing intent recognition on the natural language testing requests input by the user to obtain the task type corresponding to the user's testing intent includes: Input the natural language testing requirements into the prompt word template and obtain the data extraction results; The task type for the natural language testing requirement is determined based on the data extraction results. The task type includes data preparation tasks, transaction sending tasks, and result verification tasks.

8. A test case generation device, characterized in that, The device includes: The acquisition module is used to acquire the user's input of natural language testing requirements; The recognition module is used to identify the intent of the natural language test request input by the user and obtain the task type corresponding to the user's test intent; The reasoning module is used to reason about the natural language testing requirements based on the task type and determine the test configuration information, which includes target data, target interface and target verification logic. The generation module is used to generate automated test cases based on the test configuration information.

9. A test case generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the test case generation method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the test case generation method as described in any one of claims 1 to 7.

Images