Interface test case generation method and computing device

Abstract

Embodiments of the invention relate to an interface test case generation method and a computing device. The method comprises the steps of obtaining a text test case and an HAR file; wherein the text test case is a document describing a test scene through a natural language, and the HAR file is a data file captured by monitoring network interaction in the process of executing the text test case by a user; analyzing the HAR file, and extracting interface request information from the HAR file; and based on the text test case, the interface request information and a preset rule base, generating an interface test case through a large language model. According to the scheme, the text case and the corresponding network flow data in the real service scene are obtained, the interface request information is accurately extracted from the text case, and finally, the rule base is fused to drive the large language model to intelligently generate the test case covering the normal, abnormal and scenarized interface, so that efficient and accurate conversion from manual test to automatic codes is realized, and the test efficiency is improved. And the test efficiency, the coverage rate and the reliability are remarkably improved.

Description

Technical Field

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

[0002] With the rapid development of internet applications, interface testing has become an important means of ensuring software quality. However, currently, the writing of interface test cases mainly relies on manual work. This method is inefficient, cannot cover all normal and abnormal scenarios, and is heavily dependent on the accuracy and completeness of the interface documentation. When the system has a large number of interfaces and frequent iterations, the maintenance cost is extremely high.

[0003] Among related technologies, there are tools that parse and generate basic test cases by capturing packet data or environment logs. However, these technologies can usually only generate isolated single-interface test cases, lacking the ability to automatically identify and connect the business logic relationships and call sequences between multiple interfaces. This makes it difficult to generate test cases that fit real business scenarios, resulting in insufficient test coverage. Summary of the Invention

[0004] This application provides a method for generating interface test cases and a computing device, which can improve testing efficiency and coverage.

[0005] According to a first aspect of the embodiments of this application, an interface test case generation method is provided, the method comprising: Obtain text test cases and HAR files; wherein, the text test cases are documents describing test scenarios in natural language, and the HAR files are data files captured by monitoring network interactions during the execution of the text test cases by the user; Parse the HAR file and extract the interface request information from it; Based on text test cases, interface request information, and a pre-defined rule base, interface test cases are generated using a large language model.

[0006] This solution acquires text test cases and corresponding network traffic data from real business scenarios, accurately extracts interface request information, and finally integrates a rule base to drive a large language model to intelligently generate test cases covering normal, abnormal, and scenario-based interfaces. This achieves an efficient and accurate conversion from manual testing to automated code, significantly improving testing efficiency, coverage, and reliability.

[0007] In one possible implementation, the method further includes, before obtaining the HAR file: Pre-defined pre-injection points and post-injection points are triggered when executing text test cases; The tagging request that identifies the boundaries of a single text test case is logged to a HAR file.

[0008] By introducing these two preliminary steps, this embodiment effectively solves the technical challenge of accurately extracting the interface sequence corresponding to a single test scenario from mixed traffic, laying a reliable data foundation for the subsequent generation of high-fidelity scenario-based interface test cases.

[0009] In one possible implementation, parsing the HAR file includes: Based on the tagging request, the HAR file is split into multiple sub-HAR files; each sub-HAR file corresponds to a sequence of interface requests triggered by a text test case.

[0010] This solution can process overall traffic data into categories and scenarios. Since each sub-HAR file becomes an independent and clean business scenario data package, it can provide a data foundation for the subsequent generation of automated test cases containing multiple interface call sequences that are strictly corresponding to specific test scenarios by large language models. This can solve the problem of the difficulty in automatically identifying and constructing test cases for multiple interface scenarios.

[0011] In one possible implementation, interface test cases are generated using a large language model, including: Based on the large language model and interface request information, determine the data type and value range of the parameters in the interface request; Based on data type, value range, and parameter rules in the rule base, generate single-interface test cases. These single-interface test cases include setting parameter values ​​as boundary conditions or outliers.

[0012] This solution enables test case generation to move beyond simply reproducing normal processes to intelligently covering abnormal scenarios and boundary conditions, significantly improving the depth of generated test cases and the ability to discover defects.

[0013] In one possible implementation, the method further includes: Based on the response information extracted from the HAR file and corresponding to the interface request information, a large language model is used to generate assertion rules for verifying the response content.

[0014] This solution enables the automated and intelligent generation of assertion rules for test cases, freeing testers from the tedious task of manually writing verification logic. This not only ensures that the generated interface test cases are executable entities containing complete request and verification logic, but also significantly improves the accuracy and reliability of the tests, ensuring that automated testing can effectively verify the correctness of interface behavior.

[0015] In one possible implementation, interface test cases are generated using a large language model, including: By using a large language model based on text test cases, multiple interfaces with business logic relationships and their corresponding call sequences were identified. Extract the parameter passing dependencies between multiple interfaces; Based on the call sequence and parameter passing dependencies, construct test cases for multiple interface scenarios.

[0016] This solution enables a leap from isolated single-interface testing to complete business process testing, solving the problem of automatically generating multi-interface scenario test cases with business context in related technologies. It can significantly improve the scenario coverage and business realism of interface testing.

[0017] In one possible implementation, the method further includes: When generating interface test cases through a large language model, structured prompts are provided to the large language model. These prompts are used to constrain the test case format, assertion methods, exception scenario coverage, and parameter extraction rules.

[0018] This solution enables precise control and standardized guidance over the large language model generation process, ensuring that the generated test cases are not only functionally correct, but also maintain high consistency and usability in terms of format, style, and coverage. This greatly reduces the amount of manual adjustment work after generation and improves the overall generation quality and efficiency.

[0019] In one possible implementation, the method further includes: Based on the sensitive information processing rules in the rule base, specific header fields in the HAR file are de-identified, and placeholders are used to replace the de-identified content in the generated test cases.

[0020] This solution effectively addresses two key issues in the test case generation process: first, it prevents sensitive authentication information from being directly exposed in the test scripts, thus avoiding potential security risks; second, it enhances the portability of test cases, enabling the generated test cases to obtain actual authentication credentials through dynamic injection in different testing environments, thereby ensuring the usability and security of the test cases.

[0021] In one possible implementation, the method further includes: When parsing HAR files, filter out non-business-related requests from the interface request information.

[0022] This approach significantly improves the efficiency and quality of subsequent test case generation. On one hand, it reduces noisy data input into the large language model, allowing the model to focus more on analyzing interface logic relevant to business functions. On the other hand, it ensures the purity of the final generated test case set, avoiding the execution of numerous meaningless interface calls during automated testing, thereby improving the efficiency and relevance of test execution. This data preprocessing step provides a reliable data foundation for generating high-quality, high-value interface test cases.

[0023] According to a second aspect of the embodiments of this application, an interface test case generation apparatus is provided, the apparatus comprising: The HAR instrumentation module is used to acquire text test cases and HAR files; wherein, the text test cases are documents describing test scenarios in natural language, and the HAR files are data files captured by monitoring network interactions during the execution of the text test cases by the user; The HAR parsing module is used to parse HAR files and extract interface request information from them. The test case generation module is used to generate interface test cases based on text test cases, interface request information, and a preset rule base, using a large language model.

[0024] According to a third aspect of the embodiments of this application, a computing device is provided. The computing device includes a memory and a processor, the memory storing a computer program, and the processor executing the program to implement the method as described above.

[0025] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in the embodiments of this application.

[0026] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described above in the embodiments of this application. Attached Figure Description

[0027] More details, features, and advantages of embodiments of the present application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A schematic diagram of the architecture of an interface test case generation system provided in an exemplary embodiment of this application; Figure 2 Flowchart of an interface test case generation method provided for an exemplary embodiment of this application; Figure 3 A flowchart illustrating a method for generating HAR files as provided in an exemplary embodiment of this application; Figure 4 A schematic diagram of an interface test case generation method provided as yet another exemplary embodiment of this application; Figure 5 A schematic block diagram of the functional modules of an interface test case generation apparatus provided for an exemplary embodiment of this application; Figure 6 A structural block diagram of a server provided for an exemplary embodiment of this application. Detailed Implementation

[0028] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that embodiments of this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the embodiments of this application. It should be understood that the accompanying drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0029] It should be understood that the various steps described in the method implementation of this application may be performed in different orders and / or in parallel. Furthermore, the method implementation may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0030] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in the embodiments of this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0031] It should be noted that the terms "one" and "more" mentioned in the embodiments of this application are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more". like Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of an interface test case generation system provided for an exemplary embodiment of this application. For example... Figure 1 As shown, the system mainly consists of three parts: terminal 10, server 20, and large model 30. Among them: Terminal 10 is used to execute test scenarios and capture real network interaction data, providing a raw data source for test case generation.

[0032] Terminal 10 is the device on which the user performs test operations, such as a personal computer or mobile terminal. During testing, the user executes text test cases through a browser or HTTP (Hypertext Transfer Protocol) proxy tool on Terminal 10, captures network traffic, and generates a HAR (HTTP Archive Format) file. Simultaneously, an instrumentation platform (such as a web page) on Terminal 10 is used to trigger pre-injection points and post-injection points, recording the marked requests in the HAR file to identify the boundaries of individual test cases.

[0033] HAR is a JSON-formatted archive file used to record the interaction between a web browser and a website; its file extension is usually .har.

[0034] Server 20 is used to process captured data and drive the large model to intelligently generate executable interface test cases. It is the core of the system's analysis and generation.

[0035] Server 20 is the core processing unit of the system, and it can specifically include multiple functional modules: HAR instrumentation module 21 is used to receive HAR files uploaded from terminal 10 and perform preliminary processing, such as verifying file format and managing use case association information.

[0036] In this embodiment, the HAR instrumentation module 21 is primarily used to mark network traffic during the test execution phase. Text test cases for which test case code is to be generated can be imported and managed through an instrumentation platform (e.g., a web page). The platform displays a list of basic information for all test cases and provides a "Query Details" button after each test case. When a tester executes a text test case, clicking this button sends a specific HTTP request to the backend to obtain detailed information about the test case (including preconditions, test steps, expected results, etc.). This click operation acts as a pre-injection point, and the resulting request is recorded in the HAR file, thus marking the starting boundary of a single test case in continuous traffic data. Correspondingly, the "Close" operation after the test case execution is completed serves as a post-injection point.

[0037] HAR parsing module 22 is used to parse HAR files, extract interface request information, and clean and filter the requests, removing non-business-related requests (such as browser self-requests or static resource requests). Furthermore, this module can split a HAR file into multiple sub-HAR files based on the marked requests, with each sub-file corresponding to an interface request sequence for a text test case.

[0038] In this embodiment, the HAR parsing module 22 is responsible for performing structured parsing and data cleaning on the captured HAR file. This module reads the `entries` array from the HAR file and extracts the metadata for each interface, including but not limited to the request URL, HTTP method, request headers, request body, and response body. Subsequently, the module cleans the interfaces according to preset filtering rules, aiming to eliminate requests unrelated to business logic, such as browser-initiated version update checks, security browsing queries, polling requests on the page, and requests to retrieve static resources such as images and style sheets, thereby ensuring that subsequent processing focuses on core business interfaces.

[0039] The test case generation module 23, based on the parsed interface request information, text test cases, and a preset rule base, constructs prompt words and calls the large model 30 to generate interface test cases. This module is also responsible for tasks such as abnormal scenario coverage and parameter passing relationship identification.

[0040] In this embodiment, the test case generation module 23 is the intelligent core of the entire system, responsible for driving the generation of test cases. This module operates based on a preset rule base, which stores parameter generation rules, assertion rules, scenario combination rules, etc. The module first supports the identification and desensitization of sensitive information. For example, it identifies header fields such as Authorization and Cookie based on rules and automatically replaces them with desensitized placeholders (e.g., ${get_extract_data(Cookie)}) in the generated test case code. Subsequently, the module integrates the parsed HAR data, the business description of the text test cases, and the rule base to construct standardized prompts, thereby driving the large language model (LLM) to intelligently generate test case code. The generated content not only includes test cases that reproduce normal processes but also automatically supplements test cases for various abnormal scenarios, such as simulating illegal input situations like missing parameters, incorrect parameter types, input boundary values, and excessively long fields.

[0041] Large Model 30, also known as a large language model, is used for intelligent generation of interface test cases. It receives input from the test case generation module (such as interface request information, text test cases, and rule bases) and outputs executable test case code, including single-interface test cases and multi-interface scenario test cases. Large Model 30 can be deployed in Server 20 as an integrated component of the server; alternatively, it can be deployed independently on a separate server and communicate with Server 20 via an API interface. The embodiments of this application are not limited to the specific deployment method of Large Model 30, and other deployment architectures are also within the scope of protection of this application.

[0042] The above Figure 1 The diagram illustrates the data flow and collaboration among the system's components. Terminal 10 is responsible for data acquisition, server 20 for data processing and scheduling, and large model 30 for intelligent generation. This architecture enables a highly efficient transition from manual testing to automated test case generation, improving test coverage and efficiency.

[0043] Based on the above system architecture, this application also provides an interface test case generation method, which can be applied to servers, such as... Figure 2 As shown, the method may include the following steps: In step S210, text test cases and HAR files are obtained.

[0044] Among them, text test cases are documents that describe the test scenario in natural language, and HAR files are data files captured by monitoring network interactions during the execution of text test cases by users.

[0045] This step involves obtaining two key inputs. The first is the text test case, a test scenario document written in natural language to guide manual testing and describe the test objectives, steps, and expected results. The second is the HAR file, a data file captured and recorded by monitoring (e.g., using an HTTP proxy tool) all network interactions of the user during the execution of the aforementioned text test cases. It objectively records the actual communication data between the browser and the system under test.

[0046] In step S220, the HAR file is parsed, and the interface request information is extracted from the HAR file.

[0047] In this step, the obtained HAR file can be parsed in a structured manner. A HAR file is essentially an archive file conforming to a specific JSON format. The parsing process reads the request entries in the file and extracts key interface request information, which typically includes the request URL, HTTP method, request headers, request parameters, and corresponding response data. Furthermore, this step usually includes a data cleaning process to filter out irrelevant and distracting requests.

[0048] In step S230, interface test cases are generated using a large language model based on text test cases, interface request information, and a preset rule base.

[0049] In this embodiment, the text test cases (providing business scenario semantics) and interface request information (providing specific interface data) obtained in the first two steps can be combined with a preset rule base (providing generation rules for parameters, assertions, scenario combinations, etc.) as input information. This information, after being organized, is submitted to the large language model. Based on this, the large language model automatically generates structured interface test cases that can be directly executed by the testing framework through understanding and reasoning, thereby efficiently and effectively completing the conversion from manual testing to automated test code.

[0050] The implementation example obtains text test cases and corresponding network traffic data from real business scenarios, accurately extracts interface request information from them, and finally integrates a rule base to drive a large language model to intelligently generate test cases covering normal, abnormal, and scenario-based interfaces. This achieves an efficient and accurate conversion from manual testing to automated code, significantly improving testing efficiency, coverage, and reliability.

[0051] In the embodiments provided in this application, as shown in Table 1, Table 1 is the metadata structure of text test cases provided in an exemplary embodiment of this application.

[0052] Table 1:

[0053] Based on the above embodiments, in another embodiment provided in this application, a method for generating HAR files is also provided. Therefore, as... Figure 3 As shown, the method may further include the following steps: In step S240, text test cases are obtained.

[0054] The example first obtains a set of all text test cases that need to be executed, which are test scenario documents described in natural language.

[0055] In step S250, the HAR instrumentation program is started, text test cases are imported, and the application interface displays all basic information about the test cases. It supports sending an HTTP request to obtain test case details by clicking the "View Details" button, and supports triggering a specific HTTP request by clicking the "Close" button.

[0056] In this step, a dedicated HAR instrumentation program (usually presented as a web application interface) can be launched, and the text test cases obtained in step S240 can be imported into the platform. The instrumentation platform's application interface will clearly display a list of basic information for all test cases and provide interactive buttons such as "View Details" and "Close" for each test case. These buttons are designed to trigger specific HTTP requests, with the "View Details" button used for pre-injection and the "Close" button used for post-injection.

[0057] In step S260, the network traffic monitoring agent is started.

[0058] Simultaneously, launch the network traffic monitoring proxy tool and configure it as the system proxy. This proxy will be responsible for intercepting and recording all network interaction data during the test.

[0059] Steps S270 to S280 are executed N times (N is the number of text test cases), and each iteration includes: In step S270, click the button to get the details of the Nth request use case to implement request injection.

[0060] Before executing the Nth specific use case, the operator clicks the "View Details" button corresponding to that use case on the instrumentation platform interface. This operation sends a specific HTTP request to the server, which is captured by the traffic monitoring agent as a pre-mark, thus marking the start boundary of this use case execution in the HAR file.

[0061] In step S280, the Nth use case is executed manually.

[0062] Next, the testers manually performed the corresponding business operations according to the steps specified in the text-based test case. During this period, all business interface requests generated were recorded by the traffic monitoring proxy.

[0063] In step S290, the HAR file is exported.

[0064] After all N text test cases have been executed according to the above loop process, the final HAR file is exported from the network traffic monitoring agent. The resulting HAR file not only contains the complete sequence of business interface calls, but also embeds clear pre- and post-marking requests, providing a well-structured and scenario-specific foundation of data for subsequent scenario-based HAR file parsing and test case generation.

[0065] Combination Figure 3 As shown, the method begins in step S240, obtaining a set of text test cases to be executed. Then, the initialization phase begins. In step S250, the HAR instrumentation program is started and the text test cases are imported into the instrumentation platform. The platform's application interface displays basic information about all test cases and provides interactive buttons such as "View Details" and "Close". Simultaneously, in step S260, a network traffic monitoring agent is started to record all HTTP requests.

[0066] In this embodiment, the instrumentation and execution process is a cyclical process (the number of cycles N is the number of text test cases). For the Nth test case, firstly, in step S270, a specific HTTP request is sent by clicking its corresponding "View Details" button, thereby achieving pre-request injection and marking the start of the test case execution. Next, in step S280, the tester manually executes the operation steps defined in the text test case. At this time, all business interface requests interacting with the backend are captured by the traffic monitoring proxy. After the test case execution is completed, a specific HTTP request is triggered by clicking the "Close" button, thereby achieving post-request injection and marking the end of the test case execution.

[0067] After all text test cases have been executed according to the above steps, in step S290, the final HAR file is exported from the network traffic monitoring agent. This HAR file not only contains all business interface requests, but also embeds the tag requests generated by the pre- and post-injection points, thus providing key structured data for subsequent precise splitting of the HAR file by test case and generation of scenario-based test cases.

[0068] Based on the above embodiments, in another embodiment provided in this application, in order to more accurately associate text test cases with actual network traffic, thereby supporting subsequent scenario-based splitting of HAR files and generation of scenario-based test cases, the method may further include the following steps before step S210: In step S201, preset pre-injection points and post-injection points are triggered when executing text test cases.

[0069] In this step, testers can execute text test cases through an instrumentation platform (such as a web management interface). When a specific test case begins execution, a pre-injection point is triggered by clicking a button such as "View Test Case Details" on the platform; after the test case is completed, a post-injection point is triggered by clicking the "Close" or "Finish" button. These operations essentially send specific HTTP requests to the server.

[0070] In step S202, a tagging request that identifies the boundary of a single text test case is recorded in a HAR file.

[0071] Since all network traffic during the entire testing process (including the requests triggered in step S201) is monitored and recorded by the HTTP proxy tool, these specific HTTP calls, which are marked requests, are fully captured in the final HAR file. These marked requests act as "bookmarks" in the HAR file, clearly identifying the start and end boundaries of the network request sequence corresponding to each independent text test case.

[0072] By introducing these two preliminary steps, this embodiment effectively solves the technical challenge of accurately extracting the interface sequence corresponding to a single test scenario from mixed traffic, laying a reliable data foundation for the subsequent generation of high-fidelity scenario-based interface test cases.

[0073] Based on the above embodiments, in another embodiment provided in this application, step S220 of parsing HAR files is further refined. Therefore, step S220 may further include the following steps: In step S221, the HAR file is split into multiple sub-HAR files according to the tag request; wherein each sub-HAR file corresponds to an interface request sequence triggered by a text test case.

[0074] In this embodiment, the HAR parsing module scans the HAR file for specific tagged requests generated by pre-injection points and post-injection points. After identifying the boundaries defined by these tagged requests, the original HAR file, containing mixed traffic from all test cases, is cut and reassembled into multiple sub-HAR files according to the boundaries. Each sub-HAR file precisely corresponds to the complete sequence of interface requests triggered during the execution of a text test case.

[0075] This embodiment can process the overall traffic data into categories and scenarios. Since each sub-HAR file becomes an independent and pure business scenario data package, it can provide a data foundation for the subsequent large language model to accurately generate automated test cases that strictly correspond to specific test scenarios and contain multiple interface call sequences. This can solve the problem of the difficulty in automatically identifying and constructing test cases for multiple interface scenarios.

[0076] Based on the above embodiments, in another embodiment provided in this application, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the test case generation process provided in the embodiments of this application.

[0077] Combination Figure 4 As shown, the process mainly includes two stages: HAR parsing and use case generation.

[0078] The HAR parsing phase includes the following steps: Step 401: Export the HAR file from the network traffic monitoring agent tool.

[0079] In this embodiment, HAR files can be exported from a network traffic monitoring proxy tool. For example, testers launch a browser and an HTTP proxy tool on their terminal and access a dedicated instrumentation platform (usually a web page). On this platform, testers import and execute text test cases one by one. Whenever a new test case is started, for example, a specific HTTP request is triggered by clicking the "View Details" button, and this request is recorded by the proxy tool as a pre-mark. After all operations of this test case are completed, another specific HTTP request is triggered by clicking the "Close" button, which serves as a post-mark. All business interface requests and marker requests generated throughout the execution process are captured by the proxy tool and ultimately generated into a complete HAR file.

[0080] Step 402, Data preprocessing and cleaning.

[0081] The HAR parsing module on the server begins its work. This module reads the JSON structure of the HAR file, especially the `entries` array, and extracts the metadata (such as URL, method, request headers, request body, response body, etc.) for each network request. This module then performs data cleaning, filtering out non-business-related request entries according to predefined rules, such as browser-specific detection requests and requests for static resources (images, cascading style sheets, JS files, etc.), resulting in a clean dataset of business interfaces.

[0082] Step 403: Split into multiple independent sub-HAR files according to the use case.

[0083] Based on the aforementioned pre- and post-injection tags, the HAR parsing module in the server further splits the cleaned HAR file, which contains mixed traffic from multiple test cases, into multiple independent sub-HAR files (HAR 1, HAR 2, ..., HARN). Each sub-file corresponds precisely to an interface request sequence generated during the execution of a text test case. Here, N is a positive integer. Each sub-file corresponds to an interface sequence triggered by an original text test case. These sub-files, along with their associated text test case descriptions, are organized into structured data and passed to the next module.

[0084] The use case generation phase includes the following steps: Step 404: Create a new project using the IDE (integrated development environment) and import the split test case-level HAR file.

[0085] Testers can launch the IDE in the terminal, create a new project, and import the multiple sub-HAR files (each corresponding to a test scenario) output by the server-side HAR parsing module into the project directory as the direct data source for subsequent code generation.

[0086] Step 405: Write project rules (i.e. prompts) to guide the LLM to generate test case code according to the rules.

[0087] Testers can create and write structured rule documents and prompt word files in the terminal IDE. These files define constraints such as the output format of test cases, assertion specifications, and exception scenario requirements. Subsequently, when the process starts, the server's test case generation module reads these rule files and combines them with specific HAR scenario data to construct the final structured prompt words that conform to the input format of the large language model.

[0088] Step 406: Optimize and verify the test case code.

[0089] The server's test case generation module first sends the constructed prompts to the large language model. The large language model then generates preliminary test case code based on the prompts and HAR data. After the generated code is returned to the server, it can be automatically validated for syntax and basic rule compliance, or it can be manually reviewed and optimized by testers in the terminal's IDE, forming a closed loop of "generation-verification-feedback" to ensure code quality.

[0090] Step 407 yields the final test case code.

[0091] After optimization and verification, the final test case code, which meets all specifications and can be directly executed by the testing framework, is output by the server and is usually saved in the directory of the terminal IDE project.

[0092] pass Figure 4 As shown in the process, this embodiment of the application realizes the automated generation of high-quality, executable interface automated test code from raw network traffic data, which significantly improves the development efficiency and quality of test cases.

[0093] Based on the above embodiments, in another embodiment provided in this application, when generating interface test cases through a large language model, step S230 may further include the following steps: In step S231, based on the large language model and interface request information, the data type and value range of the parameters in the interface request are determined.

[0094] In this embodiment, the large language model intelligently analyzes the interface request information extracted from the HAR file. Based on parameter names, parameter value examples, and contextual information, the model automatically infers the data type (such as integer, string, boolean, etc.) of each parameter and its valid value range or format constraints. For example, for the parameter "age" with an observed value of 25, the model infers that its data type is integer and may combine business common sense to determine that its reasonable value range is 0 to 150.

[0095] In step S232, single-interface test cases are generated based on data type, value range, and parameter rules in the rule base. These single-interface test cases include setting parameter values ​​as boundary conditions or outliers.

[0096] In this step, the data type and value range inferred in step S231 can be combined with the pre-defined parameter rules in the rule base. Based on software testing methodologies such as boundary value analysis and equivalence class partitioning, test cases for individual interfaces are automatically generated. These test cases are specifically designed to verify the system's performance under abnormal and boundary conditions. Their characteristic is that the values ​​of specific parameters are set as boundary conditions (such as the minimum, maximum, minimum-1, and maximum+1 of an integer parameter) or abnormal values ​​(such as providing a string, an empty value, or an excessively long string for an integer parameter).

[0097] This embodiment enables test case generation to move beyond simply reproducing normal processes to intelligently covering abnormal scenarios and boundary conditions, significantly improving the depth of generated test cases and the ability to discover defects.

[0098] Based on the above embodiments, in another embodiment provided in this application, a step for automatically generating test verification logic is further included. This step can be executed during or after the generation of test cases. Therefore, the method may further include the following steps: In step S291, assertion rules for verifying the response content are generated by the large language model based on the response information extracted from the HAR file and corresponding to the interface request information.

[0099] In this step, the reasoning capabilities of the large language model can be leveraged to automate the construction of the verification phase of the interface test. The large language model analyzes historical response information corresponding to specific interface requests (this information is also extracted from HAR files). This response information contains real data samples returned by the server during testing, such as HTTP status codes, response headers, and response bodies (usually in JSON or XML format).

[0100] Based on in-depth analysis of this sample, the large language model can automatically infer key validation points and generate structured assertion rules accordingly. For example, if the model observes that a successful response from an interface always contains "status": 0" and "message": "OK", it will generate assertions validating the values ​​of these two fields. If the response contains a user ID field, the model may generate assertions validating that the field exists and is not empty.

[0101] By introducing this step, this embodiment enables the automated and intelligent generation of test case assertion rules, freeing testers from the tedious task of manually writing verification logic. This not only ensures that the generated interface test case is an executable entity containing complete request and verification logic, but also significantly improves the accuracy and reliability of the test, ensuring that automated testing can effectively verify the correctness of interface behavior.

[0102] Based on the above embodiments, in another embodiment provided in this application, step S230 of generating interface test cases through a large language model is further extended, especially for the automated generation of test cases in multi-interface business scenarios. Therefore, step S230 may further include the following steps: In step S233, multiple interfaces and their corresponding call sequences that are related to business logic are identified using a large language model based on text test cases.

[0103] In this embodiment, the large language model first analyzes the natural language descriptions of the text test cases to understand the underlying business scenarios and test objectives. Based on this understanding, the model intelligently analyzes multiple interface requests recorded in the HAR file, identifies which interfaces are logically related, and determines the correct call sequence between them according to the business process. For example, in the business scenario of "user login - query information - submit order," the model can identify the relationship between these three interfaces and determine that they must be executed in a specific order.

[0104] In step S234, the parameter passing dependencies between multiple interfaces are extracted.

[0105] In this step, the large language model further analyzes the data flow between related interfaces. By comparing the request and response data of different interfaces, the model intelligently identifies and extracts the parameter passing dependencies between interfaces. For example, the model can identify that the request parameters of the second interface need to be extracted from the response results of the first interface (such as using the token returned by the login interface in the request header of a subsequent query interface), or that the third interface needs to rely on some data returned by the second interface as its input parameters.

[0106] In step S235, test cases for multiple interface scenarios are constructed based on the call sequence and parameter passing dependencies.

[0107] In this step, the call sequence identified in step S233 can be combined with the parameter passing dependencies extracted in step S234 to construct complete scenario-based test cases. The generated test cases not only include the correct interface execution order, but also implement the necessary data transfer and state maintenance between interfaces, forming a multi-interface scenario test case that can realistically simulate a complete business process.

[0108] This embodiment enables a leap from isolated single-interface testing to complete business process testing, solving the problem in related technologies of difficulty in automatically generating multi-interface scenario test cases with business context, and can significantly improve the scenario coverage and business authenticity of interface testing.

[0109] Based on the above embodiments, in another embodiment provided in this application, the method further includes a constraint step on key prompt words to ensure that the test cases generated by the large language model meet the expected specifications and quality requirements. Therefore, the method may further include the following steps: In step S292, when generating interface test cases through the large language model, structured prompt words are provided to the large language model. The prompt words are used to constrain the test case format, assertion method, exception scenario coverage, and parameter extraction rules.

[0110] In this embodiment, before invoking the large language model, structured prompts are constructed and provided. These prompts serve as important control instructions, imposing multi-dimensional constraints on the output of the large language model. Test case format constraints: Explicitly require that the output test cases follow specific framework specifications, such as YAML format or specific test script structure.

[0111] Assertion method constraints: Limit the available assertion methods, such as equals, contains, matches, etc., and specify the organization logic of the assertions.

[0112] Abnormal scenario coverage constraints: Explicitly indicate the types of abnormal tests that need to be generated, such as missing parameters, type errors, boundary values, etc.

[0113] Parameter extraction rule constraints: Define the extraction syntax and replacement rules for parameter passing between interfaces.

[0114] By introducing this prompt word engineering step, this embodiment can achieve precise control and standardized guidance of the large language model generation process, ensuring that the generated test cases are not only functionally correct, but also maintain a high degree of consistency and usability in terms of format, style, and coverage. This greatly reduces the amount of manual adjustment work after generation and improves the overall generation quality and efficiency.

[0115] Based on the above embodiments, in another embodiment provided in this application, the method may further include the following steps: In step S293, based on the sensitive information processing rules in the rule base, specific header fields in the HAR file are desensitized, and placeholders are used to replace the desensitized content in the generated test cases.

[0116] In this embodiment, after parsing the HAR file, fields that may contain sensitive data can be automatically identified and processed according to predefined sensitive information processing rules in the rule base. In particular, for authentication credential fields in the HTTP request header, such as Authorization and Cookie, the system will replace their actual values ​​with secure de-identified placeholders, for example, replacing the specific Cookie value with a variable expression like ${get_extract_data(Cookie)}.

[0117] By implementing data anonymization, this method effectively solves two key problems in the test case generation process: first, it prevents sensitive authentication information from being directly exposed in the test scripts, avoiding potential security risks; second, it enhances the portability of test cases, enabling the generated test cases to obtain actual authentication credentials through dynamic injection in different testing environments, thereby ensuring the usability and security of the test cases.

[0118] Based on the above embodiments, in another embodiment provided in this application, the method may further include the following steps: In step S294, when parsing the HAR file, non-business-related requests in the interface request information are filtered out.

[0119] In this embodiment, during the extraction of interface request information, requests recorded in the HAR file can be intelligently filtered according to preset filtering rules. This data cleaning process aims to remove all interfering requests unrelated to core business logic, including: browser-initiated version update check requests, secure browsing service requests, automatic polling requests on the page, and requests to obtain static resources such as images, style sheets, or script files.

[0120] This data cleaning process significantly improves the efficiency and quality of subsequent test case generation. On one hand, it reduces noisy data input into the large language model, allowing the model to focus more on analyzing interface logic relevant to business functions. On the other hand, it ensures the purity of the final generated test case set, avoiding the execution of numerous meaningless interface calls during automated testing, thereby improving the efficiency and relevance of test execution. This data preprocessing step provides a reliable data foundation for generating high-quality, high-value interface test cases.

[0121] Based on the above embodiments, this application provides a test case code generation process based on an integrated development environment (IDE). This process combines structured rule documents with intelligent code generation tools to automate the generation of high-quality test cases.

[0122] In practice, developers use an integrated development environment (IDE) to open the HAR file, which has been broken down by test cases. By writing detailed rule documents and designing prompts, the agent can be guided to generate test case code according to predetermined specifications.

[0123] The rules document contains complete specification requirements for test cases, constrained by multiple specific rules: For example, rule 1: first-level keywords must include `name`, `request`, and `validate`.

[0124] It must include first-level keyword descriptions: `name` (use case name), `request` (HTTP request type, GET / POST / PUT, etc.), and `validate` (assertion configuration).

[0125] Rule 1 stipulates that the first-level keywords of a test case must include three core parts: name, request, and validate. Name defines the test case name, request configures the HTTP request type (GET / POST / PUT, etc.), and validate sets the assertion configuration.

[0126] Rule 2: The `request` keyword must contain the `method` and `url` fields. If a json field exists, the content under the json node must strictly conform to the [JSON format specification].

[0127] Rule 2 specifies the detailed requirements for the content under the `request` keyword, stipulating that it must include the `method` and `url` fields. It also stipulates that if the request contains a `json` field, the content under the `json` node must strictly adhere to JSON format specifications to ensure the standardization of the request data.

[0128] Rule 3: Assertion Method.

[0129] In this embodiment, the assertion method is explicitly defined in the rule base, which supports a multi-level response verification mechanism, specifically including the following three aspects: (1) HTTP response status code assertion: Supports verification of HTTP status codes (such as 200, 404, 500, etc.) returned by the interface.

[0130] (2) Business assertions: Supports rich logical validation of specific business fields in the response body, including: Determine whether a field value is equal to (equals) or not equal to (not_equals) the expected value.

[0131] Determine whether a field value contains or does not contain specific content.

[0132] Determine whether a field value is empty or not empty.

[0133] (3) Logical combination assertions: Supports flexible combination of the above basic assertions through the "and" and "or" logical operators to construct complex assertion logic to meet the test scenario requirements of multi-condition verification.

[0134] In the example, rule 3 defines the assertion mechanism in detail, supporting multi-level verification methods: Supports basic assertions for HTTP response status codes.

[0135] It supports a rich set of business assertion methods, including equals, not_equals, contains, not_contains, empty, and not_empty.

[0136] It supports the combination of AND and OR logic to implement complex assertion logic.

[0137] To more clearly illustrate the implementation of assertion rules, specific code examples are provided, demonstrating the practical application scenarios of various assertion methods, including the usage of single assertions and combined assertions.

[0138] The technical solution provided in this embodiment achieves the standardization and normalization of test case generation, ensuring that the generated code has a consistent format, complete assertion coverage, and reliable business logic verification, which greatly improves the quality and maintainability of interface test cases.

[0139] Based on the above embodiments, this application provides a test case generation interaction method based on an IDE intelligent agent window. This method achieves precise interaction with a large language model through structured prompt word engineering, thereby generating test case code that conforms to specifications.

[0140] In practice, developers select a pre-written rules document file in the agent window of the integrated development environment and enter carefully designed structured prompts. An example of a prompt is as follows: "You are an API automation engineer, skilled at retrieving all files from the [har] directory, with each file representing a test scenario. Please strictly follow the specifications in the [README.md] document to generate YAML format test cases for each file. Specific requirements are as follows:" 1. The first interface in the JSON file is the text description information of the current test case, which includes the test preconditions, test steps and expected results. You can generate assertions by referring to the expected results. 2. If there are multiple APIs in the JSON file, and a later API uses the return value of a previous API, please use the extract function to extract the parameters of the later API. 3. The generated YAML test cases are named using the original file name; 4. For requests where the Cookie content in the request header is not empty, the Cookie value should be uniformly set to ${get_extract_data(Cookie)}; 5. All generated YAML test cases are archived in the [testcases] directory. If this directory does not exist, please create it yourself. 6. You need to consider some abnormal scenarios (such as missing parameters, incorrect parameter types, boundary values, excessively long fields, etc.) and generate corresponding counterexamples. 7. The respose.content.text content in the entry for / api / testcases / start in the JSON file is a detailed description of the current test case, which you can use as reference information for generating YAML test cases; 8. The entries in the JSON file that request / api / testcases / start and / api / testcases / end are used to identify the start and end of the test cases. These two requests do not need to generate YAML test cases.

[0141] The design of this prompt word reflects several key technical points: First, by clearly defining role positioning and professional background settings, it guides the large language model into the correct technical context; second, by explaining each of the six specific requirements, it establishes a complete constraint system to ensure that the generated test cases meet the expected specifications in terms of scenario understanding, interface dependency handling, file management, security authentication, directory structure, and exception coverage.

[0142] In particular, the extract function extraction mechanism specified in the second requirement solves the technical problem of parameter passing in multi-interface scenarios; the unified cookie value setting scheme in the fourth requirement ensures both the security and executability of test cases; and the explicit requirements for abnormal scenarios in the sixth requirement significantly improve the coverage depth and testing effectiveness of generated test cases.

[0143] By combining the aforementioned rule documents with structured prompts, the agent can automatically generate test case code that fully conforms to the automated testing framework specifications, achieving a one-click conversion from requirement description to executable code, and significantly improving the development efficiency and quality of test cases.

[0144] In the case of dividing each functional module according to its corresponding functions, this application embodiment provides an interface test case generation device, which can be a server, a terminal, or a chip applied to a server. Figure 5 A schematic block diagram of the functional modules of an interface test case generation device provided for an exemplary embodiment of this application. (See diagram below.) Figure 5 As shown, the interface test case generation device includes: HAR instrumentation module 51 is used to acquire text test cases and HAR files; wherein, the text test cases are documents describing test scenarios in natural language, and the HAR files are data files captured by monitoring network interactions during the execution of the text test cases by the user; HAR parsing module 52 is used to parse HAR files and extract interface request information from HAR files; The test case generation module 53 is used to generate interface test cases based on text test cases, interface request information, and a preset rule base, using a large language model.

[0145] This solution acquires text test cases and corresponding network traffic data from real business scenarios, accurately extracts interface request information, and finally integrates a rule base to drive a large language model to intelligently generate test cases covering normal, abnormal, and scenario-based interfaces. This achieves an efficient and accurate conversion from manual testing to automated code, significantly improving testing efficiency, coverage, and reliability.

[0146] In another embodiment provided in this application, the device further includes a preprocessing module, specifically used for: Pre-defined pre-injection points and post-injection points are triggered when executing text test cases; The tagging request that identifies the boundaries of a single text test case is logged to a HAR file.

[0147] By introducing these two preliminary steps, this embodiment effectively solves the technical challenge of accurately extracting the interface sequence corresponding to a single test scenario from mixed traffic, laying a reliable data foundation for the subsequent generation of high-fidelity scenario-based interface test cases.

[0148] In another embodiment provided in this application, the HAR parsing module 52 is specifically used for: Based on the tagging request, the HAR file is split into multiple sub-HAR files; each sub-HAR file corresponds to a sequence of interface requests triggered by a text test case.

[0149] This solution can process overall traffic data into categories and scenarios. Since each sub-HAR file becomes an independent and clean business scenario data package, it can provide a data foundation for the subsequent generation of automated test cases containing multiple interface call sequences that are strictly corresponding to specific test scenarios by large language models. This can solve the problem of the difficulty in automatically identifying and constructing test cases for multiple interface scenarios.

[0150] In another embodiment provided in this application, the use case generation module 53 is further used for: Based on the large language model and interface request information, determine the data type and value range of the parameters in the interface request; Based on data type, value range, and parameter rules in the rule base, generate single-interface test cases. These single-interface test cases include setting parameter values ​​as boundary conditions or outliers.

[0151] This solution enables test case generation to move beyond simply reproducing normal processes to intelligently covering abnormal scenarios and boundary conditions, significantly improving the depth of generated test cases and the ability to discover defects.

[0152] In another embodiment provided in this application, the use case generation module 53 is further used for: Based on the response information extracted from the HAR file and corresponding to the interface request information, a large language model is used to generate assertion rules for verifying the response content.

[0153] This solution enables the automated and intelligent generation of assertion rules for test cases, freeing testers from the tedious task of manually writing verification logic. This not only ensures that the generated interface test cases are executable entities containing complete request and verification logic, but also significantly improves the accuracy and reliability of the tests, ensuring that automated testing can effectively verify the correctness of interface behavior.

[0154] In another embodiment provided in this application, the use case generation module 53 is further used for: By using a large language model based on text test cases, multiple interfaces with business logic relationships and their corresponding call sequences were identified. Extract the parameter passing dependencies between multiple interfaces; Based on the call sequence and parameter passing dependencies, construct test cases for multiple interface scenarios.

[0155] This solution enables a leap from isolated single-interface testing to complete business process testing, solving the problem of automatically generating multi-interface scenario test cases with business context in related technologies. It can significantly improve the scenario coverage and business realism of interface testing.

[0156] In another embodiment provided in this application, the device further includes a prompt word sending module, specifically used for: When generating interface test cases through a large language model, structured prompts are provided to the large language model. These prompts are used to constrain the test case format, assertion method, exception scenario coverage, and parameter extraction rules.

[0157] This solution enables precise control and standardized guidance over the large language model generation process, ensuring that the generated test cases are not only functionally correct, but also maintain high consistency and usability in terms of format, style, and coverage. This greatly reduces the amount of manual adjustment work after generation and improves the overall generation quality and efficiency.

[0158] In another embodiment provided in this application, the device further includes a desensitization processing module, as shown in the figure, for: Based on the sensitive information processing rules in the rule base, specific header fields in the HAR file are de-identified, and placeholders are used to replace the de-identified content in the generated test cases.

[0159] This solution effectively addresses two key issues in the test case generation process: first, it prevents sensitive authentication information from being directly exposed in the test scripts, thus avoiding potential security risks; second, it enhances the portability of test cases, enabling the generated test cases to obtain actual authentication credentials through dynamic injection in different testing environments, thereby ensuring the usability and security of the test cases.

[0160] In another embodiment provided in this application, the device further includes a filtering module, specifically used for: When parsing HAR files, filter out non-business-related requests from the interface request information.

[0161] This approach significantly improves the efficiency and quality of subsequent test case generation. On one hand, it reduces noisy data input into the large language model, allowing the model to focus more on analyzing interface logic relevant to business functions. On the other hand, it ensures the purity of the final generated test case set, avoiding the execution of numerous meaningless interface calls during automated testing, thereby improving the efficiency and relevance of test execution. This data preprocessing step provides a reliable data foundation for generating high-quality, high-value interface test cases.

[0162] This application also provides a computing device, including: at least one processor; a memory for storing at least one processor-executable instruction; wherein the at least one processor is configured to execute instructions to implement the methods disclosed in the embodiments of this application.

[0163] The aforementioned processor can also be called a central processing unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this application can be implemented by integrated logic circuits in the processor's hardware or by software instructions. The aforementioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in memory, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0164] Furthermore, the aforementioned computing device can specifically be a server. Depending on the various operations / processes implemented in the embodiments of this application, and via software and / or firmware, it can transmit data from a storage medium or network to a server with a dedicated hardware architecture, such as... Figure 6 The server 1900 shown is equipped with the programs that constitute the software. When various programs are installed on the server, it is able to perform various functions, including those mentioned above. Figure 6 A structural block diagram of a server provided for an exemplary embodiment of this application.

[0165] Server 1900 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0166] like Figure 6 As shown, server 1900 includes a computing unit 1901, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 1902 or loaded into random access memory (RAM) 1903 from storage unit 1908. RAM 1903 may also store various programs and data required for the operation of server 1900. Server 1900 also includes a GPU 1910. Computing unit 1901, ROM 1902, GPU 1910, and RAM 1903 are interconnected via bus 1904. Input / output (I / O) interface 1905 is also connected to bus 1904. The number of GPUs 1910 may include multiple GPUs.

[0167] Multiple components in server 1900 are connected to I / O interface 1905, including: input unit 1906, output unit 1907, storage unit 1908, and communication unit 1909. Input unit 1906 can be any type of device capable of inputting information to server 1900. Input unit 1906 can receive input numeric or character information and generate key signal inputs related to user settings and / or function control of the server. Output unit 1907 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1908 may include, but is not limited to, disks and optical discs. Communication unit 1909 allows server 1900 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0168] The computing unit 1901 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1901 include, but are not limited to, a central processing unit (CPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 1901 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in the embodiments of this application can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 1908. In some embodiments, part or all of the computer program can be loaded and / or installed on a server via ROM 1902 and / or communication unit 1909. In some embodiments, the computing unit 1901 can be configured to perform the methods disclosed in the embodiments of this application by any other suitable means (e.g., by means of firmware).

[0169] This application also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by the processor of a server, the server is able to perform the methods disclosed in the embodiments of this application.

[0170] The computer-readable storage medium in this application embodiment may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.

[0171] The aforementioned computer-readable medium may be included in the aforementioned server; or it may exist independently and not assembled into the server.

[0172] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a processor, implements the methods disclosed in the embodiments of this application.

[0173] In embodiments of this application, computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar 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 it can be connected to an external computer.

[0174] 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, can 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.

[0175] The modules, components, or units described in the embodiments of this application can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0176] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0177] The above description is merely an embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

[0178] While specific embodiments of this application have been described in detail by way of examples, those skilled in the art should understand that the above examples are for illustrative purposes only and are not intended to limit the scope of this application. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this application. The scope of this application is defined by the appended claims.

Claims

1. A method for generating interface test cases, characterized in that, The method includes: Obtain text test cases and HAR files; wherein, the text test cases are documents describing test scenarios in natural language, and the HAR files are data files captured by monitoring network interactions during the execution of the text test cases by the user; The HAR file is parsed, and interface request information is extracted from the HAR file; Based on the text test cases, the interface request information, and the preset rule base, interface test cases are generated through a large language model.

2. The method according to claim 1, characterized in that, Before obtaining the HAR file, the method further includes: When the text test case is executed, preset pre-injection points and post-injection points are triggered; The tagging request that identifies the boundaries of a single text test case is recorded in the HAR file.

3. The method according to claim 2, characterized in that, The parsing of the HAR file includes: According to the tagging request, the HAR file is split into multiple sub-HAR files; wherein each sub-HAR file corresponds to an interface request sequence triggered by one of the text test cases.

4. The method according to claim 1, characterized in that, The generation of interface test cases through a large language model includes: Based on the large language model and the interface request information, determine the data type and value range of the parameters in the interface request; Based on the data type, the value range, and the parameter rules in the rule base, a single interface test case is generated, wherein the single interface test case includes setting the value of the parameter as a boundary condition or an anomaly value.

5. The method according to claim 4, characterized in that, The method further includes: The large language model generates assertion rules for verifying the response content based on the response information extracted from the HAR file and corresponding to the interface request information.

6. The method according to claim 1, characterized in that, The generation of interface test cases through a large language model includes: Based on the text test cases, the large language model identifies multiple interfaces and their corresponding call sequences that are related in business logic. Extract the parameter passing dependencies between the multiple interfaces; Based on the call sequence and the parameter passing dependencies, construct test cases for multiple interface scenarios.

7. The method according to claim 1, characterized in that, The method further includes: When generating interface test cases through the large language model, structured prompts are provided to the large language model. These prompts are used to constrain the test case format, assertion method, exception scenario coverage, and parameter extraction rules.

8. The method according to claim 1, characterized in that, The method further includes: Based on the sensitive information processing rules in the rule base, specific header fields in the HAR file are de-identified, and placeholders are used to replace the de-identified content in the generated test cases.

9. The method according to claim 1, characterized in that, The method further includes: When parsing the HAR file, non-business-related requests in the interface request information are filtered out.

10. A computing device, characterized in that, include: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any one of claims 1-9.

Images