Test script generation method and device, electronic equipment, storage medium and product

Abstract

The invention discloses a test script generation method and device, electronic equipment, a storage medium and a product. The test script generation method comprises the steps of obtaining an interface file; if the interface file is not the file in the general format, the interface file is converted into the file in the general format for storing the HTTP request and response, and the general format is an HAR format; and generating an interface test script according to the file in the general format. According to the technical scheme, the interface files are unified into the files in the HAR format, and the interface test script is automatically generated for the files in the HAR format, so that complete test scripts are automatically and efficiently generated for different types of interface files, and the test efficiency is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of interface testing technology, and in particular to a test script generation method, device, electronic device, storage medium and product. Background Art

[0002] Interface testing is a critical step in the software development and testing process, and the automation of interface testing impacts development efficiency and product quality. Test projects often involve multiple interface sources, such as HAR files exported by browsers, Postman Collection request sets, Swagger interface description documents, and PCAP / CAP files obtained through network packet capture. These files vary significantly in structure, ranging from tree structures to pure Hypertext Transfer Protocol (HTTP) messages, complete parameter definitions, and only raw Transmission Control Protocol (TCP) data streams.

[0003] Most existing tools only offer good support for Swagger (OpenAPI), with weaker support for HAR and PostmanCollection, and virtually no ability to process raw packet capture files like PCAP / CAP. Testing teams cannot directly use these tools to generate scripts when restoring real user requests or replaying historical network communications. Even if some tools can generate code snippets, the results are often just simple HTTP request statements, lacking script organization, parameter management, response validation, and test case management capabilities. The generated content cannot be directly used for automated testing and still requires manual organization and supplementation by developers. Furthermore, most existing solutions default to generating scripts in a format compatible with certain public testing frameworks (such as Postman Runner and pytest), while enterprise-level testing platforms often have independent script structures, command systems, and context variable mechanisms. Existing tools are unable to directly adapt to these platforms, resulting in the need for secondary conversion or even complete rewriting of generated content. In this case, faced with different types of interface files, testers often need to switch between multiple tools for preprocessing, disassembly, and organization. The entire process is highly dependent on experience and manual operation, which is inefficient and error-prone. There is a lack of a unified, configurable, and automated workflow tool chain.

[0004] Generally speaking, while existing solutions can cover some interface test automation needs, they generally suffer from poor compatibility, low automation levels, and implementation difficulties. These solutions fail to meet the engineering requirements for quickly generating high-quality test scripts that can be run on enterprise-level test platforms. Automatically and efficiently generating complete test scripts for different types of interface files is an urgent problem to be solved. Summary of the Invention

[0005] The present application provides a test script generation method, device, electronic device, storage medium and product to automatically and efficiently generate complete test scripts for different types of interface files.

[0006] In a first aspect, an embodiment of the present application provides a test script generation method, comprising:

[0007] Get the interface file;

[0008] If the interface file is not in a universal format, converting the interface file into a universal format file for storing HTTP requests and responses, wherein the universal format is HAR format;

[0009] Generate an interface test script according to the file in the general format.

[0010] In a second aspect, an embodiment of the present application further provides a test script generating device, comprising:

[0011] Acquisition module, used to obtain interface files;

[0012] a conversion module, configured to convert the interface file into a file in a common format for storing HTTP requests and responses, if the interface file is not in a common format, wherein the common format is HAR format;

[0013] A generation module is used to generate an interface test script according to the file in the general format.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0015] one or more processors;

[0016] a storage device for storing one or more programs;

[0017] When the one or more programs are executed by the one or more processors, the one or more processors implement the test script generating method as described in the first aspect.

[0018] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the test script generation method as described in the first aspect.

[0019] In a fifth aspect, an embodiment of the present application further provides a computer program product, comprising a computer program and / or instructions, which, when executed by a processor, implements the test script generation method as described in any of the above embodiments.

[0020] The embodiments of the present application provide a test script generation method, device, electronic device, storage medium, and product. The test script generation method includes: obtaining an interface file; if the interface file is not in a universal format, converting the interface file into a universal format file for storing HTTP requests and responses, wherein the universal format is the HAR format; and generating an interface test script based on the universal format file. The above technical solution unifies the interface file into a file in the HAR format and automatically generates an interface test script for the HAR format file, thereby achieving automatic and efficient generation of complete test scripts for different types of interface files, thereby improving test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that the originals and elements are not necessarily drawn to scale.

[0022] Figure 1 A flowchart of a test script generation method provided in an embodiment of the present application;

[0023] Figure 2 A schematic diagram of the structure of a test script generation device provided in an embodiment of the present application;

[0024] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are intended only to illustrate the present application and are not intended to limit the present application. It should also be noted that, for ease of description, the accompanying drawings only illustrate portions of the present application, not all of the structures.

[0026] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the steps as sequential processes, many of the steps can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the steps can be rearranged. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0027] It should be noted that the concepts of "first" and "second" mentioned in the embodiments of this application are only used to distinguish different devices, modules, units or other objects, and are not used to limit the order or interdependence of the functions performed by these devices, modules, units or other objects.

[0028] In addition, the embodiments and features in the embodiments of the present application may be combined with each other unless there is any conflict.

[0029] The acquisition, storage, use, and processing of data in this application's technical solution comply with relevant national laws and regulations.

[0030] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned. They should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the relevant content of the solution.

[0031] Figure 1 A flowchart of a test script generation method provided in an embodiment of the present application is provided. This embodiment is applicable to the case where a test script is generated from an interface file. Specifically, the test script generation method can be executed by a test script generation device, which can be implemented by software and / or hardware and integrated into an electronic device. The electronic device includes but is not limited to devices such as computers, smartphones, or servers, and can also be a central processing unit (CPU) or a microcontroller (MCU).

[0032] like Figure 1 As shown, the method specifically includes the following steps:

[0033] S110: Obtain interface file.

[0034] In this embodiment, the interface file may refer to a structured data file that describes the interface request and response content in a standard format, including but not limited to the HAR (HTTP Archive) format, the API request collection (Postman Collection) format, the interface description specification Swagger (also known as OpenAPI), the network data packet capture file (PCAP / CAP) format, etc. These interface files may contain information such as the interface's Uniform Resource Locator (URL), request method, request parameters, response structure and / or sample data, and are an important data source for interface testing.

[0035] S120: If the interface file is not in a universal format, convert the interface file into a universal format file for storing HTTP requests and responses, where the universal format is HAR format.

[0036] In this embodiment, before generating a test script for the interface file, the interface file can be converted into a unified format (i.e., a universal format). The universal format can be HAR format. HAR is a JSON-based HTTP request and response log format, usually exported by a browser or packet capture tool. The interface file in this format can record the complete request path, header information, request body, and response body, which is an important basis for reproducing the real access scenario of the front end. Files in HAR format focus on the request (Request) and response (Response) information in the record (Entries).

[0037] The interface file to be tested obtained may not be in HAR format, but in other formats such as PostmanCollection, Swagger or PCAP / CAP file format. In this case, the interface file can be converted to HAR format first. This format conversion process can be understood as a preprocessing process before automatically generating the test script. Among them, the file in PostmanCollection (hereinafter referred to as Postman) format is an API request collection file generated by the Postman tool. It is a JSON file that can be used to structuredly describe the basic information and execution sequence of multiple interface requests. It contains a collection of interface information for easy batch management; Swagger is a widely used REST API description specification that supports describing the API path, parameters, request and response structure in YAML or JSON format, and is often used for automatic generation and test integration of interface documents; PCAP / CAP files usually contain raw data transmitted over the network. The HTTP request content can be restored through protocol parsing. It is used to restore service behavior and extract interface information in scenarios where there is a lack of interface documentation.

[0038] S130: Generate an interface test script according to the file in the general format.

[0039] In this embodiment, the test script can be understood as an interface test logic file, which does not rely on a third-party library and is dedicated to automated testing tasks such as interface verification, regression testing, and data comparison. For files in the HAR format, an interface test script can be automatically generated. For example, the entire process from parsing the interface file to generating the test script can be automatically completed through a graphical interface or command operation without the need to manually write a script. Exemplarily, for interface files in the HAR format, a Python test script that meets the standards of an enterprise-level testing platform can be automatically generated. Optionally, the generated test script can include assertion logic to verify whether the interface response meets the expected data judgment logic, such as status code matching, field structure comparison, and / or field value verification.

[0040] The embodiment of the present application provides a test script generation method that supports multiple mainstream interface file formats. This method converts interface files from different sources into a middle-layer HAR structure with a unified structure and complete expression, and then performs script generation processing uniformly through standardized conversion logic to generate test scripts that comply with enterprise-level test platform specifications. This method automatically and efficiently generates complete test scripts for different types of interface files, enhances the degree of interface test automation, improves test efficiency and reduces labor costs, and has high consistency, high scalability and engineering feasibility. This solution does not rely on any third-party test framework and can generate test scripts according to the syntax and structure specifications of the enterprise-level test framework.

[0041] In one embodiment, converting the interface file into a file in a common format for storing HTTP requests and responses includes:

[0042] 1) If the interface file is a Postman file, each request in the interface file is converted into a HAR record (HAREntry) to obtain a file in a universal format. The HAR record retains the method field (Method), URL field (url), request header field (headers), request body field (body), and request parameter field (params); in addition, the default response field can be set to maintain the integrity of the structure, thereby obtaining an interface file in HAR format;

[0043] 2) If the interface file is a Swagger file, a HAR record is generated based on the path information (paths) and API model information (schemas) in the interface file. For example, the interface path, method, request structure, and response example can be parsed from the paths and schemas to generate an equivalent HAR request and obtain a file in a universal format.

[0044] 3) If the interface file is a network packet capture file, the TCP data packets in the network packet capture file are reassembled and the complete request header and response are converted into HAR records. That is, the HTTP request message can be restored through protocol analysis, and the complete request-response pair can be transcribed into a HAR structure to obtain a file in a universal format.

[0045] In addition, if the interface file is in native HAR format, you can directly use the HAR file exported by the browser or proxy tool without format conversion.

[0046] The above-mentioned unified format process can make all subsequent operations unnecessary to distinguish the file source, thereby improving the consistency and scalability of the script generation process.

[0047] In one embodiment, generating an interface test script based on a file in a universal format includes: extracting core fields from the file in the universal format and encapsulating the extracted content into a standard structure; generating an interface test script based on the standard structure; wherein the core fields include: a request method field (such as GET, POST, etc.); a URL and query parameter field (Query); a request header field (Headers); a request body field (PostData); and a sequence information field for determining the request sequence and transaction composition. Optionally,

[0048] For example, in the process of generating an interface test script, a standard interface structure model can be extracted first. In the unified HAR file, each entry[] can be regarded as an independent interface request unit. The core fields can be extracted from the HAR file and encapsulated into a standard structure. Optionally, the core fields can also include a response status code and a content type field, which can be used for assertion prompts). This standard structure can provide standardized input for subsequent template rendering and script generation.

[0049] In one embodiment, an interface test script is generated based on a standard structure, including: orderly mapping each HAR record in the standard structure to a corresponding task function, each task function containing request information and a request method; organizing each task function into a transaction class, an action class, and a user class for defining user task loop behavior to obtain an interface test script.

[0050] Exemplarily, the structure of a test script includes:

[0051] Task method (@task): Each HAR request is mapped to a task function, such as task_0, task_1;

[0052] Transaction class (SerialTransaction): Multiple tasks are organized into a transaction class;

[0053] Action class (BrowserAction): The transaction is bound to the Action by the @transaction annotation;

[0054] Virtual user class (CFastHttpUser): script entry, defines the user task loop behavior.

[0055] Among them, each task_xx() contains complete request information (URL, headers, params, data) and request method (GET, POST), and the execution order is preserved according to the HAR record order.

[0056] As an example, the generated test script is as follows:

[0057] Python

[0058] @task

[0059] def task_0(self):

[0060] url"https: / / api.example.com / user"

[0061] headers{"Accept":"application / json"}

[0062] params{"id":"123"}

[0063] data None

[0064] res self.get(url,headers=headers,params=params,data=data)

[0065] #application / json,res.text

[0066] All tasks can be combined into the following structure:

[0067] Python

[0068] python class Transaction_All(SerialTransaction):...

[0069] class WebrunnerAction(BrowserAction):..

[0070] class WebrunnerUser(CFastHttpUser):..

[0071] In one embodiment, generating an interface test script according to a standard structure further includes:

[0072] For any HAR record in the standard structure,

[0073] 1) If the HAR record indicates a redirect request (e.g., a request with a status code of 302), set the field for controlling whether to prohibit redirect requests to allow the redirect request, and pass the redirection parameters according to the response header field indicating the redirection destination address. For example, set allow_redirects to False, parse the Location field in the response header, and pass the redirection parameters to subsequent requests.

[0074] 2) If the HAR record is a static resource request (such as images, JS, CSS, etc.), identify the request interface to be tested by marking an annotation. You can mark the annotation or exclude the generated script. For example, before generating the script, you can check the request link to confirm which requests are the business interfaces that need to be tested.

[0075] 3) If the HAR record is a request using a token or data stored on the user's local terminal (cookie), automatic variable replacement and injection strategies (such as global.token) are supported. Parameterized configuration can be used in the generated script configuration to automatically replace this variable or inject (add) request parameter variables;

[0076] 4) If the HAR record corresponds to an empty response or a mock response, a placeholder comment or mock data prompt is generated. That is, the test script supports parameterized mock configuration of mocks. By generating placeholder comments and mocks, you can test whether the request meets the interface requirements before sending the request.

[0077] As an example, for converting Postman Collection to HAR file:

[0078] The interface collection file in Postman format can be converted into a HAR file format with a standardized structure and compatible with the enterprise-level test platform script generator. The conversion result is a standard HAR JSON file that can be reused by the subsequent unified HAR to script logic.

[0079] For example, the input format of Postman Collection (v2.1) is as follows:

[0080]

[0081] The converted HAR file should follow the standard HTTP Archive format. Each Postman item is converted into a HAR entry. For nested items (folders), the lowest request node must be recursively extracted. For example, the structure of the HAR file converted by Postman can be as follows:

[0082]

[0083] Exemplarily, in the process of converting the interface file in the Postman format into the interface file in the HAR format, for the request part (request), the field mapping relationship is as shown in Table 1.

[0084] Table 1 Mapping relationship between Postman fields and HAR fields

[0085]

[0086] For example, the response part has the following structure:

[0087]

[0088] Optionally, a more detailed mock response can be generated as needed; this can be used as an "expected status code" or for logging purposes in subsequent test scripts.

[0089] For the time field, its structure is as follows:

[0090] "startedDateTime":"2025-06-05T10:00:00.000Z",

[0091] "time":0

[0092] As a specific example, a Postman primitive might be:

[0093]

[0094] The converted HAR entry can be:

[0095]

[0096]

[0097] Optionally, when converting a Postman-formatted interface file to a HAR-formatted interface file, if the request body is JSON, you can attempt to parse and format postData.text; all variables (such as {{baseUrl}}) can be retained or replaced in advance; support merging environment files for variable injection (advanced); and support automatic construction of response examples (in combination with Swagger) to enhance subsequent assertion capabilities (advanced).

[0098] As an example, for the conversion of an interface document (YAML or JSON format) described in the Swagger (OpenAPI) specification to a HAR file, taking OpenAPI 3.0 as an example, the input format is as follows:

[0099]

[0100]

[0101] For example, the converted HAR file is consistent with Chrome export or Charles packet capture. Its core is the log.entries[] array, where each entry represents an HTTP request or response. The field mapping is shown in Table 2.

[0102] Table 2 Mapping relationship between Swagger fields and HAR fields

[0103] Swagger fields HAR corresponding fields servers[].url Request URL prefix (joined path) paths[" / xxx"][method] Each request is mapped to a HAR entry parameters[].in=query / path Mapped to queryString parameters or URL parameters parameters[].in=header Mapping to headers requestBody.content.* Mapped to postData and processed by mimeType responses

[200] .content.*.example as response.content.text(mock)

[0104] For example, in the process of converting a Swagger format interface file into a HAR format interface file, the HARentry construction process may include:

[0105] Step 1: Path concatenation and method identification, where the final concatenated URL can be: servers[].url+path; the request method can come from paths[path][method], such as get, post;

[0106] Step 2: Construct a request object, for example:

[0107]

[0108] Among them, headers can be obtained from the parameter in:header; queryString can be obtained from the parameter in:query; postData.text can be extracted from requestBody.content.application / json.example; postData.mimeType can be filled in according to the content type, such as application / json;

[0109] Step 3: Construct a virtual response object. Since Swagger does not have a real response, a mock response structure can be generated:

[0110]

[0111] If the example field is not provided, {} can be used as a placeholder response.

[0112] As a specific example, the Swagger Path is converted to a HAR Entry. The Swagger definition can be:

[0113]

[0114] The converted HAR Entry can be:

[0115]

[0116] As an example, for converting PCAP / CAP packet capture files to HAR files, the input interface file formats are .pcap and .cap, which are standard network packet capture file formats that record the original TCP / UDP data packets during network communication. They can be generated by packet capture tools such as Wireshark, tcpdump, Fiddler, Charles, etc. HTTP request information is often embedded in the TCP stream and requires protocol reassembly and parsing.

[0117] The HAR format file structure obtained by converting the PCAP / CAP packet capture file is as follows:

[0118]

[0119] The process of converting a PCAP / CAP packet capture file to a HAR file may include:

[0120] Step 1: TCP Reassembly and HTTP Protocol Restoration, including reading.pcap / .cap files; grouping and sorting all TCP packets by TCP stream; detecting whether there is a complete HTTP request header (such as GET / path HTTP / 1.1) in each TCP stream; distinguishing requests from responses and forming HAR entries in the "request + response" structure.

[0121] Step 2: Extract HTTP request information. The captured packet content of the following fields can be extracted from the TCP stream and filled into the request section of the HAR, as shown in Table 3 specifically.

[0122] Table 3 Mapping Relationship Table between Captured Packet Content and HAR Fields

[0123] Capture packet content HAR field illustrate Request line: GET / path request.method、url Concatenate hosts to get the complete URL Header row request.headers[] Convert to {name, value} array Body (if present) request.postData.text Usually the body of a POST request Content-Type request.postData.mimeType If the Content-Type header is present

[0124] As a specific example, the captured packet content can be:

[0125] POST / user HTTP / 1.1

[0126] Host: api.example.com

[0127] Content-Type: application / json

[0128] {"name": "Zhang San", "age": 25}

[0129] The HAR file structure obtained after conversion is:

[0130] "method": "POST",

[0131] "url": "https: / / api.example.com / user", <00003,16>"headers": [...],

[0133] "postData": {

[0134] "mimeType": "application / json",

[0135] "text": "{\"name\": \"Zhang San\", \"age\": 25}"

[0136] }

[0137] As an example, the process of automatically converting interface request data in standard HAR format into a complete Python script structure that conforms to the syntax of an enterprise-level testing platform can generate complete virtual users, transactions, tasks, and request codes based on a unified data model and combined with platform class definition specifications.

[0138] For example, a standard HAR file is in JSON format, and the core field path is as follows:

[0139]

[0140] The mapping relationship between the elements in HAR and the test script structure is shown in Table 4.

[0141] Table 4 Mapping relationship between elements in HAR and test script structure

[0142]

[0143] For example, in the process of generating a test script from a HAR file, the conversion rules between the request method and the request body are as follows:

[0144] GET request can be converted to self.get(url, headers = ..., params = ..., data = None);

[0145] POST request can be converted to self.post(url,headers=...,data=...);

[0146] PUT, DELETE, etc. are similarly mapped to the request methods in WebRunner;

[0147] It should be noted that GET does not contain body, and POST must have data.

[0148] For example, the conversion rules between URL and query parameters are as follows:

[0149] The full URL path in HAR is parsed to get base_url+params;

[0150] The fields in the queryString are converted to a Python dictionary and passed as params. For example, the queryString field is as follows:

[0151] json

[0152] "querystring":[

[0153] {"name":"id","va1ue":"123"},

[0154] {"name":"type","value":"detail"} 1

[0156] The queryString can be converted to:

[0157] json

[0158] python params = {"id":"123","type":"detail"}

[0159] Exemplarily, for the Headers field, all request header fields can be reconstructed in dictionary form; pseudo headers such as :authority, :method, :path, etc. can be excluded; the Cookie field can also be specially processed and merged into a single string. For example, the Headers field can be converted to:

[0160] python

[0161] headers = {

[0162] "Accept":"...",

[0163] "User-Agent":"...",

[0164] "Cookie":"key1 = val1; key2 = val2"

[0165] }

[0166] Exemplarily, for the request body, if postData.mimeType is JSON, then parse postData.text as a dict and use it as data; if it is application / x-www-form-urlencode, then convert postData.params to data = {...} dictionary; unstructured content remains the original string. For example, the converted request body is as follows:

[0167] python

[0168] data = ‘{"name":"张三","age":25}

[0169] For example, for the task generation strategy, each HAR entry corresponds to a @task method: such as task_0, task_1,...; the request function contains the complete URL, headers, params, data, and request method call; if a request is a source request for a redirect jump (such as status code 302), the allow_redirects=False parameter is automatically added during generation, and the jump target is recorded (as shown in task_3).

[0170] For example, when generating a test script, the following basic structure can be automatically generated:

[0171] Python

[0172] class Transaction_All(SerialTransaction):...

[0173] Among them, all task_xx() are placed in a transaction (such as Transaction_All); a transaction corresponds to a WebRunner test business process (HTTP sequence); all transactions are injected into an Action class (through the @transaction() annotation); all actions belong to a user class, and the final running script is a standard WebRunner user behavior script. For example:

[0174] Python

[0175] class Transaction_All(SerialTransaction):...

[0176] class WebrunnerAction(BrowserAction):...

[0177] class WebrunnerUser(CFastHttpuser):..

[0178] For example, the following special processing logic can be used when generating a test script:

[0179] If response.status is 302 or Location exists, add jump judgment logic and record redirect parameters to self.userstorage;

[0180] If the mimeType is a static resource such as image, js, css, etc., it can be marked with a comment or used as a front-end resource request evaluation;

[0181] If there is an obvious page loading order for multiple requests (such as HTML → JS → image), organize the task order in chronological order.

[0182] As a concrete example, a snippet of a HAR record looks like this:

[0183]

[0184] The code for generating the corresponding test script from the above HAR record is as follows:

[0185]

[0186] In one embodiment, the interface file is imported through a command line interface (CLI) and / or a graphical user interface (GUI), and supports batch import of Postman, Swagger, PCAP, HAR and other files; the CLI and / or GUI are also used to automatically perform format recognition, format conversion and script generation processes, and are also used to identify the format of the interface file, configure the naming rules of transactions in the test script, and define the output path of the test script.

[0187] The test script generation method provided in the embodiments of the present application addresses the problems of inconsistent formats, high difficulty in script generation, and low automation in existing interface testing processes. By using the HAR file as a unified intermediate structure, it provides an automated conversion process and a structured script automatic generation mechanism, which has the following advantages and effects:

[0188] 1) Support multiple interface file formats and have a wide range of applications;

[0189] Specifically, this method supports not only Swagger and Postman interface files, but also PCAP / CAP packet capture data and native HAR files. By converting these files to a HAR structure, various heterogeneous interface files are unified into a single data representation, resolving the existing incompatibility issue with multiple interface description formats.

[0190] 2) Standardized script structure facilitates maintenance and platform integration;

[0191] Specifically, this method uses standardized HAR-to-script conversion logic to ensure that the generated test scripts conform to the syntax and structure requirements of enterprise-level test platforms. All interface requests are organized according to a unified template, avoiding inconsistent script styles and parameter formats due to different interface sources, and improving script readability and maintainability.

[0192] 3) High degree of automation, no human intervention is required in the generation process;

[0193] Specifically, this method automatically completes the process of parsing the interface file, extracting request parameters, constructing the request body, and generating the script without human intervention. The generated script contains complete test logic and can be run directly on the test platform, solving the problem of manual editing and debugging of scripts in the existing technology and significantly improving work efficiency.

[0194] 4) Test behavior can be reconstructed based on real network data;

[0195] Specifically, the method supports converting PCAP / CAP network packet capture data into HAR files, and further generates replayable interface test scripts, supports parsing raw network data into HTTP requests, and then uniformly converting them into HAR structures to generate replayable interface test scripts, thereby achieving real interface reproduction and verification without documentation. This technical path combines network protocol parsing, HAR construction, and automated script generation to achieve the reconstruction and retesting functions of real online requests. Compared with testing methods that rely solely on interface documents, the present invention has higher simulation and problem location capabilities, making up for the shortcomings of traditional tools in packet capture data processing capabilities.

[0196] 5) Adapt to enterprise-level testing processes and have engineering implementation capabilities;

[0197] Specifically, this method not only considers script generation itself, but also designs command-line tools and interfaces to support linkage with version control and continuous integration systems. When the interface definition changes, it can automatically trigger the reconstruction of the test script, effectively supporting the enterprise-level automated testing system.

[0198] The above-mentioned method of using the HAR format as the standard format for interface modeling breaks through the limitations of independent parsing, logical duplication, and structural fragmentation of existing tools, and solves key problems such as format incompatibility, process fragmentation, and manual reliance on script generation in existing methods. It significantly improves the efficiency, accuracy, and maintainability of interface testing, and has significant technological advancement and application value. Unlike traditional testing tools that generate scripts separately according to different interface formats, this method only designs a script generation engine for the HAR format, so that all interface request behaviors are expressed in a unified structure with consistent parsing logic, script structure, and running semantics. This method simplifies the generation process and improves the scalability and stability of the system. In addition, the scripts generated by HAR are all Python scripts that can be directly run on enterprise-level test platforms, with complete transaction structure, parameter control, request injection, and assertion logic, and have clear engineering implementation value and platform compatibility.

[0199] Figure 2This is a schematic diagram of the structure of a test script generation device provided in an embodiment of the present application. The test script generation device provided in this embodiment includes:

[0200] An acquisition module 210 is used to acquire an interface file;

[0201] a conversion module 220 configured to convert the interface file into a file in a common format for storing HTTP requests and responses, the common format being HAR format, if the interface file is not in a common format;

[0202] The generating module 230 is configured to generate an interface test script according to the file in the general format.

[0203] The device unifies interface files into files in HAR format and automatically generates interface test scripts for files in HAR format, thereby automatically and efficiently generating complete test scripts for different types of interface files, thereby improving test efficiency.

[0204] Based on any of the above embodiments, the conversion module 220 is specifically configured to:

[0205] If the interface file is a Postman file, each request in the interface file is converted into a HAR record to obtain a file in a universal format, wherein the HAR record retains a method field, a uniform resource locator URL field, a request header field, a request body field, and a request parameter field;

[0206] If the interface file is a Swagger file, a HAR record is generated according to the path information and API model information in the interface file to obtain a file in a universal format;

[0207] If the interface file is a network packet capture file, the TCP data packets in the network packet capture file are reassembled and the complete request header and response are converted into HAR records to obtain a file in a universal format.

[0208] Based on any of the above embodiments, the generating module 230 is specifically configured to:

[0209] Extracting core fields from the file in the general format and encapsulating the extracted content into a standard structure;

[0210] Generate an interface test script according to the standard structure;

[0211] The core fields include:

[0212] Request method field; URL and query parameter field; request header field; request body field; sequence information field.

[0213] Based on any of the above embodiments, the generating module 230 is specifically configured to:

[0214] Mapping each HAR record in the standard structure to a corresponding task function in order, where each task function includes request information and a request method;

[0215] Each task function is organized into a transaction class, an action class, and a user class for defining the user task loop behavior to obtain an interface test script.

[0216] Based on any of the above embodiments, the generating module 230 is further configured to:

[0217] For any of the HAR records in the standard structure,

[0218] If the HAR record is a request for redirection, a field for controlling whether to prohibit the redirection request is set to allow the redirection request, and a redirection parameter is passed according to a response header field indicating the redirection destination address;

[0219] If the HAR record is a static resource request, the request interface to be tested is determined by marking annotations;

[0220] If the HAR record is a request using a token or data stored on the user's local terminal, it supports variables that can be injected or replaced with request parameters;

[0221] If the HAR record corresponds to a null response or a simulated response, a placeholder annotation or a simulated data prompt is generated.

[0222] Based on any of the above embodiments, the interface file is imported via a command line interface CLI and / or a graphical user interface GUI;

[0223] The CLI and / or the GUI are further configured to:

[0224] Identify the format of the interface file, configure the naming rules of the transactions in the test script, and define the output path of the test script.

[0225] The test script generation device provided in the embodiment of the present application can be used to execute the test script generation method provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0226] Figure 3A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present application is shown. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device 10 can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, user equipment, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided for example only and are not intended to limit the implementation of the present application as described and / or claimed herein.

[0227] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0228] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks and wireless networks.

[0229] The processor 11 may be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above.

[0230] In some embodiments, the methods of the above embodiments may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to perform any of the above-described methods in any suitable manner (e.g., by means of firmware).

[0231] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0232] Computer programs for implementing the methods of the present application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0233] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0234] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device 10 having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device 10. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0235] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0236] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0237] An embodiment of the present application further provides a computer program product, comprising a computer program and / or instructions, which, when executed by a processor, implements the test script generation method as described in any of the above embodiments.

[0238] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of this application can be achieved. This is not limited herein.

[0239] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A test script generation method, characterized in that: include: Get the interface file; If the interface file is not in a universal format, converting the interface file into a universal format file for storing HTTP requests and responses, wherein the universal format is HAR format; Generate an interface test script according to the file in the general format.

2. The method according to claim 1, characterized in that The step of converting the interface file into a file in a general format for storing HTTP requests and responses comprises: If the interface file is a Postman file, each request in the interface file is converted into a HAR record to obtain a file in a universal format, wherein the HAR record retains a method field, a uniform resource locator URL field, a request header field, a request body field, and a request parameter field; If the interface file is a Swagger file, a HAR record is generated according to the path information and API model information in the interface file to obtain a file in a universal format; If the interface file is a network packet capture file, the TCP data packets in the network packet capture file are reassembled and the complete request header and response are converted into HAR records to obtain a file in a universal format.

3. The method according to claim 1, characterized in that Generate an interface test script according to the file in the general format, including: Extracting core fields from the file in the general format and encapsulating the extracted content into a standard structure; Generate an interface test script according to the standard structure; The core fields include: Request method field; URL and query parameter field; request header field; request body field; sequence information field.

4. The method according to claim 3, characterized in that Generate an interface test script according to the standard structure, including: Mapping each HAR record in the standard structure to a corresponding task function in order, where each task function includes request information and a request method; Each task function is organized into a transaction class, an action class, and a user class for defining the user task loop behavior to obtain an interface test script.

5. The method according to claim 4, characterized in that , generating an interface test script according to the standard structure, further comprising: For any of the HAR records in the standard structure, If the HAR record is a request for redirection, a field for controlling whether to prohibit the redirection request is set to allow the redirection request, and a redirection parameter is passed according to a response header field indicating the redirection destination address; If the HAR record is a static resource request, the request interface to be tested is determined by marking annotations; If the HAR record is a request using a token or data stored on the user's local terminal, it supports variables that can be injected or replaced with request parameters; If the HAR record corresponds to a null response or a simulated response, a placeholder annotation or a simulated data prompt is generated.

6. The method according to claim 1, wherein The interface file is imported via a command line interface CLI and / or a graphical user interface GUI; The CLI and / or the GUI are further configured to: Identify the format of the interface file, configure the naming rules of the transactions in the test script, and define the output path of the test script.

7. A test script generating device, characterized in that: include: Acquisition module, used to obtain interface files; a conversion module, configured to convert the interface file into a file in a common format for storing HTTP requests and responses, if the interface file is not in a common format, wherein the common format is HAR format; A generation module is used to generate an interface test script according to the file in the general format.

8. An electronic device, characterized in that: include: at least one processor; a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to execute the test script generating method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the test script generation method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program and / or instructions, characterized in that When the computer program and / or instructions are executed by a processor, the test script generating method according to any one of claims 1 to 6 is implemented.

Images