Automatic interface testing method and device, equipment, medium and program product

Abstract

The invention relates to an automatic interface testing method and device, equipment, a medium and a computer program product. The method comprises the following steps: acquiring and analyzing a target data packet to obtain an interface calling sequence; the interface calling sequence comprises at least one test step; generating an initial test script according to the interface calling sequence; wherein the initial test script comprises parameter values corresponding to the test steps; generating a corresponding value expression for each parameter value to obtain a value mapping relationship between the parameter value and the value expression; according to the value mapping relationship, replacing each parameter value in the initial test script with a corresponding value expression to obtain a target test script; and executing the target test script to complete the test task of the to-be-tested interface. By adopting the method, the execution efficiency of interface testing can be improved.

Description

Technical Field

[0001] This application relates to the field of interface testing technology, and in particular to an automated interface testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] As software systems become increasingly complex, automated interface testing has become a key means of ensuring software quality.

[0003] Currently, related technologies generate test scripts through traffic recording, which can quickly generate basic API call sequences. However, in test scripts generated through traffic recording, the API call parameters are all fixed values. In actual API testing scenarios, subsequent API calls depend on the data returned by preceding APIs. Testers must manually analyze the data dependencies between APIs and write a lot of code to extract parameters and implement data transfer.

[0004] This manual processing method is not only extremely labor-intensive, but also requires constant modification of the parameter extraction and transmission code, especially when the interface structure changes frequently. When the test scenario is complex and involves continuous calls to multiple interfaces, the parameter dependencies become intricate, and the cost of manual maintenance increases exponentially. This results in low development efficiency of interface test scripts, making it impossible to keep up with the rapid iteration pace of software development. Summary of the Invention

[0005] Therefore, it is necessary to provide an interface automation testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the execution efficiency of interface testing in response to the above-mentioned technical problems.

[0006] Firstly, this application provides an automated interface testing method, including:

[0007] Acquire and parse the target data packet to obtain the interface call sequence; the interface call sequence includes at least one test step.

[0008] An initial test script is generated based on the interface call sequence; wherein, the initial test script includes parameter values ​​corresponding to each of the test steps;

[0009] Generate corresponding value expressions for each of the parameter values ​​to obtain the value mapping relationship between the parameter values ​​and the value expressions;

[0010] Based on the value mapping relationship, each parameter value in the initial test script is replaced with the corresponding value expression to obtain the target test script;

[0011] Execute the target test script to complete the test task of the interface to be tested.

[0012] In one embodiment, generating the initial test script based on the interface call sequence includes:

[0013] Based on the interface call sequence, assign a step identifier to each test step and obtain the original request data for each test step;

[0014] Based on the original request data, extract at least one parameter name and the parameter value corresponding to each of the test steps;

[0015] An initial test script is generated based on the step identifier, the parameter name, and the parameter value.

[0016] In one embodiment, generating corresponding value expressions for each parameter value and obtaining a value mapping relationship between the parameter value and the value expressions includes:

[0017] Parse the data structure of the response data of each interface to be tested to obtain the parameter values ​​and corresponding access paths of the response data;

[0018] Determine the step identifier corresponding to each of the parameter values;

[0019] Based on the step identifier and the access path, generate the value expression corresponding to the parameter value;

[0020] The mapping relationship between the value expression and the parameter value is recorded in the value mapping relationship.

[0021] In one embodiment, the step of replacing each parameter value in the initial test script with the corresponding value expression according to the value mapping relationship to obtain the target test script includes:

[0022] For each parameter value in the initial test script, the value mapping relationship is queried to obtain the corresponding value expression;

[0023] When the parameter value corresponds to multiple candidate value expressions, calculate the similarity between the parameter name of the parameter value and the field name in each of the value expressions;

[0024] The target value expression is selected based on the similarity to replace the parameter value, thus obtaining the target test script.

[0025] In one embodiment, executing the target test script to complete the testing task of the interface to be tested includes:

[0026] Execute each test step sequentially according to the order of the test steps in the target test script, and perform the following steps for each test step:

[0027] If the request parameters of the test step include a value expression, the actual parameter value corresponding to the value expression is obtained from the global data storage space;

[0028] Use the actual parameter values ​​to call the corresponding interface to be tested;

[0029] The response data of the interface to be tested is saved to the global data storage space.

[0030] In one embodiment, the method further includes:

[0031] During the execution of the target test script, for the response data of each test step, the corresponding verification rule is retrieved from the verification rule base according to the interface identifier of the interface to be tested and the response status code of the response data; wherein, the verification rule base is constructed based on the historical version return data of the interface to be tested;

[0032] According to the verification rules, the parameter values ​​in the response data are verified to obtain the verification results.

[0033] Secondly, this application also provides an automated interface testing device, comprising:

[0034] The data acquisition module is used to acquire and parse the target data packet to obtain the interface call sequence; the interface call sequence includes at least one test step.

[0035] The script generation module is used to generate an initial test script based on the interface call sequence; wherein, the initial test script includes parameter values ​​corresponding to each of the test steps;

[0036] The value processing module is used to generate corresponding value expressions for each of the parameter values, and to obtain the value mapping relationship between the parameter values ​​and the value expressions.

[0037] The value replacement module is used to replace each parameter value in the initial test script with the corresponding value expression according to the value mapping relationship, so as to obtain the target test script;

[0038] The script execution module is used to execute the target test script to complete the test task of the interface to be tested.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the first aspect.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps described in the first aspect.

[0041] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described in the first aspect.

[0042] The aforementioned automated interface testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, by acquiring and parsing target data packets, can capture actual network communication data, extract the interface call process, and obtain an interface call sequence including at least one test step. Based on the interface call sequence, the captured interface calls are transformed into an executable test code framework, generating an initial test script containing parameter values ​​corresponding to each test step. Corresponding value expressions are generated for each parameter value, obtaining a value mapping relationship between parameter values ​​and value expressions. Then, based on the value mapping relationship, each parameter value in the initial test script is replaced with its corresponding value expression to obtain the target test script. The value expressions replace manually written parameters, realizing a shift from fixed parameter values ​​to dynamic parameter references. The test script no longer depends on specific fixed values ​​but dynamically obtains the required parameters through value expressions, enabling subsequent interface calls to automatically use the data returned by the preceding interface without manual intervention. Finally, the target test script is executed to complete the test task of the interface under test. It can dynamically parse value expressions and extract the required parameter values ​​in real time during operation, realizing automatic data flow during the testing process and improving the execution efficiency of interface testing. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a diagram illustrating the application environment of an interface automation testing method in one embodiment.

[0045] Figure 2 This is a flowchart illustrating an interface automated testing method in one embodiment;

[0046] Figure 3 This is a flowchart illustrating an interface automation testing method in another embodiment;

[0047] Figure 4This is a structural block diagram of an interface automated testing device in one embodiment;

[0048] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0051] The interface automated testing method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. Terminal 102 can obtain interface test results processed by server 104 and display these results. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on the cloud or other network servers. The data storage system can be used to store target data packets and value mapping relationships, etc. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0052] In one exemplary embodiment, such as Figure 2 As shown, an interface automation testing method is provided, which can be applied to... Figure 1Taking server 104 as an example, the explanation includes the following steps S202 to S210. Wherein:

[0053] Step S202: Obtain and parse the target data packet to obtain the interface call sequence.

[0054] The target data packet refers to the HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Protocol Secure) data packet transmitted between the client and server during network communication, containing request and response messages. The interface call sequence refers to a series of interface calls arranged chronologically, each call containing the interface's request parameters and response data, and including at least one test step. A test step is a single operational unit in the interface automated testing process, corresponding to one interface call, and includes information such as the interface URL (Uniform Resource Locator), HTTP method, request headers, request body, response status code, and response body.

[0055] For example, server 104 can capture HTTP / HTTPS communication packets between the client and server as target packets by establishing a network proxy or using a packet capture tool. Server 104 can set up a listening point at the network layer to record all network data traffic passing through. When users or testers operate the system under test, server 104 can capture all network request and response data generated in real time.

[0056] Next, server 104 can perform protocol parsing on the captured data packets, extracting the various parts of the HTTP / HTTPS protocol from the raw binary data. For HTTP requests, server 104 can extract the request method, URL path, request headers, and request body content; for HTTP responses, server 104 can extract the response status code, response headers, and response body content.

[0057] Furthermore, server 104 can also perform structured processing on the parsed HTTP / HTTPS data. For example, it can parse JSON (JavaScript Object Notation) or XML (eXtensible Markup Language) format data in the request and response bodies. Based on the request's timestamp, session identifier, or context, it can pair related request and response data to reconstruct the complete interface call process. Thus, server 104 can automatically identify the functional characteristics and types of different interfaces, such as login interfaces, query interfaces, and update interfaces, by analyzing the patterns and parameter structures of the request URLs, and assign a unique identifier to each interface.

[0058] Subsequently, server 104 can reassemble the processed data in chronological order to generate a complete interface call sequence, which contains multiple test steps. Each step corresponds to a complete interface call, including the interface request information and the corresponding response information. For example, an e-commerce system test scenario may include multiple interface call steps such as login, product search, adding to cart, and checkout. Server 104 can assign a unique sequence number or ID (Identification) to each test step in the sequence for easy subsequent processing and referencing.

[0059] Step S204: Generate the initial test script based on the interface call sequence.

[0060] The initial test script includes parameter values ​​for each test step. It may contain API call information and fixed parameter values ​​for each test step. Parameter values ​​refer to the values ​​of specific data items in the request or response data of the API call, such as user ID, token, timestamp, etc. Parameter names refer to the identifiers or keys of each data item in the API request or response, such as "userId", "token", "timestamp", etc.

[0061] For example, server 104 can analyze the overall structure of the interface call sequence, identifying all interfaces involved in the test process and their call order. Server 104 can standardize the interface call sequence, unify the data format of interface requests and responses, remove redundant information unrelated to testing (such as some HTTP header information, debugging information, etc.), and retain necessary test data. Server 104 can determine the basic structure of the test script according to the requirements of the test framework, including importing necessary libraries and modules, initializing the test environment, defining test classes and methods, and other basic code frameworks.

[0062] In some embodiments, server 104 can assign a unique step identifier to each test step in the interface call sequence, such as "s01", "s02", "s03", etc. For each test step, server 104 can extract its original HTTP request data, including the request method, URL, request headers, and request body content. The original request data, such as JSON or XML format content in the request body, is then parsed to extract all parameter names and their corresponding values.

[0063] For example, from the request body {"username":"testuser","password":"123456"}, server 104 can extract the parameter names "username" and "password" and their corresponding parameter values ​​"testuser" and "123456". Next, server 104 can organize the extracted parameters into the format of the target test framework according to the interface characteristics of each test step. For example, for REST (Representational State Transfer) API (Application Programming Interface) testing, server 104 can format the parameters as JSON or form data; for SOAP (Simple Object Access Protocol) interface testing, it can format them as an XML structure. Server 104 can generate code snippets for calling the interface, including the complete process of setting request headers, constructing the request body, sending the request, and receiving the response. For each interface call, server 104 can construct request data using fixed parameter values ​​from the original request.

[0064] Next, server 104 can assemble the code snippets for each test step according to the original order of the interface calls to form a complete test case. In some embodiments, server 104 can add test assertion code to verify whether the status code or basic structure of the interface response meets expectations. Finally, server 104 can output a complete initial test script, which contains all the steps and parameters required for the test, but the parameter values ​​are still fixed at this point.

[0065] The process of generating initial test scripts can adapt to different testing frameworks and programming languages. Server 104 can generate code that conforms to the syntax rules and structural requirements of the target testing framework (such as JUnit, TestNG, Pytest, etc.). For different programming languages ​​(such as Java, Python, JavaScript, etc.), Server 104 can use corresponding language templates and syntax structures. When handling complex request parameters, Server 104 can correctly identify and process nested structures, arrays, special characters, and escape sequences. For special types of requests such as binary data or file uploads, Server 104 can adopt corresponding encoding and processing methods.

[0066] For example, server 104 can assign a step identifier to each test step according to the interface call sequence and obtain the original request data of each test step; based on the original request data, it can extract at least one parameter name and the corresponding parameter value for each test step; and generate an initial test script based on the step identifier, parameter name, and parameter value. Here, the step identifier is a unique identifier assigned to each test step to distinguish and reference different test steps. Server 104 can assign step variable names in the form of "s01", "s02", etc., sequentially to each test step in the sequence. Then, server 104 can parse the HTTP request for each step, extracting all parameter name-parameter value pairs from the URL query parameters, request headers, and request body. For JSON format request bodies, server 104 uses a JSON parser to extract all leaf nodes in the nested structure; for form data, it parses key-value pairs; and for XML, it extracts elements and attributes. After extraction, server 104 can use a code template to populate these parameter names and values ​​into a predefined script structure.

[0067] Through the steps described above, server 104 automatically converts the interface call sequence into an executable test script, significantly reducing the workload of testers manually writing test code. For complex test scenarios involving dozens or even hundreds of interface calls, manually writing test scripts may take several days, while automatic generation can be completed in minutes. The automatically generated initial script retains the precise information of the original interface calls, including all parameter names and values, ensuring the accuracy and completeness of the test.

[0068] Step S206: Generate corresponding value expressions for each parameter value to obtain the value mapping relationship between the parameter value and the value expression.

[0069] Among them, the value expression refers to the expression used to extract parameter values ​​from the response data of the test step, and the value mapping relationship refers to the correspondence table established between the parameter value and its corresponding value expression, which is used to record which position of which test step each parameter value can be extracted from.

[0070] For example, server 104 can first initialize an empty value mapping table to store the correspondence between parameter values ​​and value expressions, and then process each test step in the interface call sequence, analyzing the response data structure of each step. For each test step, server 104 can use a JSON parser or an XML parser (depending on the response format) to parse the response data and construct an in-memory data structure tree. Subsequently, server 104 can traverse the parsed response data structure to identify all data nodes that may be referenced in subsequent steps. For each data node, server 104 can extract its parameter value and complete access path.

[0071] For example, server 104 can parse the data structure of the response data of each interface to be tested, obtain the parameter values ​​of the response data and the corresponding access paths; determine the step identifier corresponding to each parameter value; generate the value expression corresponding to the parameter value based on the step identifier and the access path; and record the mapping relationship between the value expression and the parameter value in the value mapping relationship. The access path can be a path expression described using JSON Path syntax to locate a specific node in the JSON data structure, such as "data.user.id". JSON Path is a path expression language used to extract data from a JSON structure.

[0072] For example, given the response data {"code":200,"data":{"token":"abc123","userId":"u001"}}, server 104 can extract the parameter values ​​"abc123" and "u001", as well as their access paths "data.token" and "data.userId". Next, server 104 can record the test step identifier corresponding to each parameter value. This identifier is a unique step ID assigned in step S204, such as "s01", "s02", etc. Finally, server 104 can construct a value expression for each parameter value based on the step identifier and access path.

[0073] The format of the value retrieval expression can be "step identifier.Response.access path", which indicates that the parameter value is extracted from the response data of the specified step using the given access path. For example, for the parameter value "abc123" with the path "data.token" in step "s01", the generated value retrieval expression can be "s01.Response.data.token". Server 104 can add each parameter value and its corresponding value retrieval expression to the value mapping table. If the same parameter value appears multiple times in different steps or different positions, server 104 can record all possible value retrieval expressions, forming a one-to-many mapping relationship. Server 104 can also optimize the value mapping table, merging duplicates and sorting to improve subsequent search efficiency. For some special types of parameter values ​​(such as date, time, etc.), server 104 can apply corresponding matching rules to improve the accuracy of parameter replacement.

[0074] Furthermore, when handling nested JSON or XML structures, server 104 can handle various situations, such as arrays, nested objects, and special characters. For array-type nodes, server 104 can generate appropriate index expressions, such as "data.items[0].id" or using wildcards "data.items[*].id". Server 104 can also handle various data types, including strings, numbers, booleans, and null values, ensuring that the generated retrieval expressions can correctly extract parameter values ​​of various types. In some complex scenarios, a parameter value may need to be generated from multiple data sources; server 104 can also support the construction of compound expressions.

[0075] Through the above steps, server 104 establishes a mapping relationship between parameter values ​​and their source locations, enabling the system to track the source of each parameter value and clarify the dependencies between parameters. By using JSON Path expressions as the value retrieval mechanism, server 104 can handle various complex data structures. The establishment of the value mapping relationship enables dynamic parameter passing, making parameter extraction more flexible and adaptable to changes in data structures.

[0076] Step S208: Based on the value mapping relationship, replace each parameter value in the initial test script with the corresponding value expression to obtain the target test script.

[0077] The target test script refers to the test script after the parameters are dynamically replaced, where fixed parameter values ​​are replaced by corresponding value expressions, enabling automatic data transfer between test steps.

[0078] For example, server 104 can load the initial test script and the value mapping table, and sequentially traverse each test step in the initial test script. For each test step, server 104 can parse its request parameters, identify all parameter values ​​that may need to be replaced, and for each identified parameter value, query the value mapping table to check if a corresponding value expression exists. If the parameter value does not exist in the mapping table, the original parameter value can be kept unchanged, and the next parameter can be processed. If the parameter value has a unique value expression in the mapping table, server 104 can directly use that expression to replace the original parameter value. If there are multiple candidate value expressions in the mapping table, server 104 can perform additional analysis and selection to determine the most suitable expression.

[0079] For example, server 104 can query the value mapping relationship for each parameter value in the initial test script to obtain the corresponding value expression; when a parameter value corresponds to multiple candidate value expressions, it calculates the similarity between the parameter name of the parameter value and the field name in each value expression; based on the similarity, it selects the target value expression to replace the parameter value, thus obtaining the target test script. Here, similarity refers to the degree of similarity between two strings, which can be calculated using string similarity algorithms (such as Levenshtein distance, Jaccard similarity coefficient, etc.) and is used to select the best match among multiple candidate expressions. Field name refers to the name that identifies a data item in a JSON or XML structure, such as "userId" or "token".

[0080] Furthermore, server 104 can check the length of parameter values. For shorter parameter values ​​(e.g., less than 6 characters), the same value is more likely to have different meanings in different contexts. Server 104 can extract the parameter name of the current parameter, such as a key name in a JSON object or a tag name in an XML element. Server 104 can analyze the access path of each candidate value expression and extract the last field name. For example, extract the field name "userId" from the expression "s01.Response.data.userId". Server 104 can use a string similarity algorithm to calculate the similarity between the parameter name and the field names of each candidate expression. Similarity algorithms may include Levenshtein distance (edit distance), Jaccard similarity coefficient, cosine similarity, etc. Server 104 can sort the candidate expressions according to the calculated similarity and select the expression with the highest similarity as the target value expression. In some embodiments, if the highest similarity is still lower than a preset threshold, server 104 can retain the original parameter value without replacement to avoid incorrect association.

[0081] After determining the target value expression, server 104 can replace the fixed parameter values ​​in the initial test script with the corresponding value expressions. After completing the replacement of all parameter values, it generates the final target test script. The parameters in this script have been made dynamic and can automatically extract the required values ​​from the responses of the preceding steps at runtime.

[0082] Step S210: Execute the target test script to complete the test task of the interface to be tested.

[0083] For example, server 104 can first initialize the test execution environment, including creating a global data storage space, setting necessary test parameters, and initializing the test report. The global data storage space can be implemented as a key-value store structure, where the key format can be "step identifier.Request / Response", and the value can be the corresponding complete request or response data. Server 104 can load the target test script and parse the test step sequence and execution logic within it. Next, server 104 can execute each test step sequentially according to the order defined in the script.

[0084] For example, server 104 can execute each test step sequentially according to the order of the test steps in the target test script, and perform the following steps for each test step: if the request parameters of the test step contain a value expression, obtain the actual parameter value corresponding to the value expression from the global data storage space; call the corresponding interface to be tested using the actual parameter value; and save the response data of the interface to be tested to the global data storage space. Here, the global data storage space refers to the memory area used to store the request and response data of all test steps during test execution, serving as an intermediary for data transfer between steps. The actual parameter value refers to the specific numerical value extracted from the response data of the preceding step by parsing the value expression during test execution, used to replace the expression placeholder in the request. For example, for each test step, server 104 can check whether its request parameters contain a value expression, which can be checked according to a specific format identifier. If no value expression is contained, server 104 can directly call the interface using the original parameters; if a value expression is contained, server 104 can first parse these expressions to obtain the actual parameter value.

[0085] In some embodiments, the process of server 104 parsing a value expression may include: extracting the step identifier and data type (Request / Response) from the expression, retrieving the corresponding complete data from the global data storage space; extracting the JSON Path from the expression; and using the JSON Path engine to execute a query in the complete data to extract the target parameter value.

[0086] For example, for the expression "#{s01.Response.data.token}", server 104 can retrieve data with the key "s01.Response" from the global data storage space, and then use the JSON path "data.token" to query that data and extract the token value, such as "abc123". Server 104 can then replace the corresponding expression in the request parameters with the extracted actual parameter value to obtain the complete actual request parameters. A single request may contain multiple value expressions; server 104 can process all expressions sequentially, and only after all replacements are completed can the final request data be constructed.

[0087] Next, server 104 can construct an HTTP request using the replaced actual parameter values, including setting the appropriate request method, URL, request headers, and request body. Then, server 104 can send the HTTP request to the target interface, wait for and receive the interface's response data. Server 104 parses the response data returned by the interface, extracting information such as the status code, response headers, and response body. Server 104 can save the complete request and response data to the global data storage space respectively, with keys such as "current step identifier.Request" and "current step identifier.Response".

[0088] Subsequently, server 104 can verify the interface response, checking whether the response status code matches expectations and whether the response format is correct. If a test step fails (e.g., request timeout, interface error return), server 104 can record the error information and decide whether to continue executing subsequent steps based on the error handling strategy in the script. After executing each test step, server 104 can update the test report, recording the execution result, time consumption, and key data of the step. Next, server 104 can continue to execute the next test step, repeating the above process until all steps are completed or a termination condition is encountered (e.g., a critical step fails). After completing all test steps, server 104 can generate a final test report, which may include the overall test results, detailed information on each step, and key statistical data.

[0089] In the aforementioned automated interface testing method, by acquiring and parsing target data packets, actual network communication data can be captured, the interface call process can be extracted, and an interface call sequence including at least one test step can be obtained. Based on the interface call sequence, the captured interface calls are transformed into an executable test code framework, generating an initial test script including parameter values ​​corresponding to each test step. A corresponding value expression is generated for each parameter value, obtaining the value mapping relationship between parameter values ​​and value expressions. Then, based on the value mapping relationship, each parameter value in the initial test script is replaced with the corresponding value expression to obtain the target test script. The value expression replaces the parameters that need to be manually written, realizing the transformation from fixed parameter values ​​to dynamic parameter references. The test script no longer depends on specific fixed values, but dynamically obtains the required parameters through value expressions, so that subsequent interface calls can automatically use the data returned by the preceding interface without manual intervention. Finally, the target test script is executed to complete the test task of the interface to be tested. It can dynamically parse value expressions and extract the required parameter values ​​in real time during the running process, realizing automatic data flow in the testing process and improving the execution efficiency of interface testing.

[0090] In one exemplary embodiment, such as Figure 3 As shown, the above method may further include steps S302 to S304. Wherein:

[0091] Step S302: During the execution of the target test script, for the response data of each test step, the corresponding verification rule is retrieved from the verification rule base according to the interface identifier of the interface to be tested and the response status code of the response data.

[0092] The validation rule base is built based on the historical version return data of the interface under test. It refers to a set of rules generated by analyzing the historical version return data of the interface, used to verify the correctness of the current interface response data. The interface identifier is information that uniquely identifies an interface, which may include the interface's URL path, HTTP method, etc. The response status code refers to the status code in the HTTP response, such as 200 (success), 404 (not found), 500 (server error), etc., indicating the result status of the request processing.

[0093] The validation rules can include data type, value range, format requirements, etc.

[0094] For example, server 104 can retrieve validation rules applicable to the current test step from the validation rule base. The validation rule base can be organized into a multi-level index structure, using the interface identifier and response status code as the primary index keys. When a test step in the target test script completes execution and receives response data from the interface, server 104 can extract the identifier information of the current interface. The interface identifier may include the interface's URL path and HTTP method, and may also include a specific version number or other identifying information. Server 104 can extract the response status code from the interface response and use the extracted interface identifier and response status code as index keys to look up the corresponding validation rule set in the validation rule base.

[0095] In some embodiments, situations may arise where no exact match exists in the rule base, such as when a new interface is added to the test, the interface path is changed, or a new response status code is added. In such cases, server 104 can employ a fuzzy matching strategy: it can match prefixes or patterns of the interface path, as well as similar response status codes. If server 104 finds a matching rule set in the validation rule base, it can check the rule's version and applicable conditions to ensure compatibility with the current test environment and context. Server 104 can load all validation rules, including those for different parameter paths. For each rule in the rule set, server 104 can parse its parameter path, data type, value range, format requirements, and other constraints.

[0096] Server 104 can collect historical response data from the interface, perform statistical analysis on each parameter, and extract its data characteristics to construct a validation rule base. For example, for numeric parameters, it can analyze their minimum, maximum, and precision; for string parameters, it can analyze their length range and format pattern; and for enumerated parameters, it can analyze all possible values. Through this data feature analysis, server 104 can generate validation rules for each parameter, forming a complete validation rule base. The validation rule base can be continuously updated and improved as the interface evolves, ensuring that the rules remain consistent with the latest behavior of the interface. For example, the completed validation rule base is shown in Table 1 below:

[0097] Table 1

[0098]

[0099] Step S304: According to the verification rules, verify the values ​​of each parameter in the response data to obtain the verification result.

[0100] For example, server 104 can parse the structure of the response data, convert it into an in-memory data structure, and process each rule in the validation rule set sequentially. For each rule, server 104 can extract the parameter path from the rule, such as "data.user.id". For ordinary paths, server 104 can directly look up the corresponding parameter value in the response data; for paths containing wildcards (such as array elements), server 104 can match all parameter values ​​that match the path pattern. For example, for the path "data.items[].price", server 104 can find the price values ​​of all product items for validation.

[0101] After obtaining the parameter value, server 104 can perform multi-faceted validation on the parameter value based on the various constraints in the rules. First, it can perform data type validation, checking whether the actual type of the parameter value conforms to the rule requirements. For example, if the rule requires the parameter to be an integer, but the actual value is a string, it is marked as a type mismatch. For numeric parameters, server 104 can also check its precision (decimal places) to ensure compliance with the rule requirements.

[0102] Next, the value range can be validated. Server 104 can verify whether the parameter value is within the allowed range based on the range restrictions defined in the rules. For example, for the age parameter, it checks whether it is within a reasonable range of 0-120; for the percentage parameter, it checks whether it is within the range of 0-100. For enumeration type parameters, server 104 can check whether the parameter value is in the predefined set of optional values. For example, for the status parameter, it checks whether it is an allowed value such as "active", "inactive", or "pending".

[0103] Then, data length validation can be performed. For string parameters, server 104 can check whether their length is within the required range. For example, whether the username length is between 3 and 20 characters, and whether the password length is at least 8 characters. For strings with specific formats, such as email addresses, URLs, and phone numbers, server 104 can use regular expressions for format validation to ensure that the parameter values ​​meet the format requirements.

[0104] Server 104 can also perform non-empty validation. For parameters marked as required in the rules, Server 104 can check if they have a value, disallowing null or empty strings. For optional parameters, even if the value is empty, the validation is considered successful. In some cases, the requirement of a parameter may be conditional, meaning it is only required if a specific condition is met. For example, if the user type is "Enterprise User," then "Company Name" is required; if it is "Individual User," it can be empty. Server 104 can determine the requirement of a parameter based on contextual conditions.

[0105] For each validation of each parameter value, server 104 can record the validation result and related details, such as the reason for failure, expected value, and actual value. If the parameter value passes all applicable validations, the entire value is marked as valid; if any validation fails, the entire value is marked as invalid. Server 104 can collect the validation results of all parameters to form a complete validation result set.

[0106] Through the steps described above, Server 104 achieves comprehensive automated verification of interface response data. Traditional interface testing only focuses on response status codes and a few key fields, failing to comprehensively verify the response data. Server 104, based on a verification rule base, can perform multi-dimensional verification of each parameter in the interface response, including data type, value range, and format requirements, ensuring data integrity and accuracy. This significantly improves the effectiveness of testing and can detect subtle issues that are difficult to detect using traditional methods, such as insufficient data precision or non-standard formatting. The automated verification process not only improves efficiency but also eliminates omissions and inconsistencies that may result from manual verification, achieving automated, comprehensive, and standardized test data verification, thus enhancing the quality and efficiency of interface testing.

[0107] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0108] Based on the same inventive concept, this application also provides an interface automation testing apparatus for implementing the interface automation testing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more interface automation testing apparatus embodiments provided below can be found in the limitations of the interface automation testing method described above, and will not be repeated here.

[0109] In one exemplary embodiment, such as Figure 4As shown, an automated interface testing device is provided, comprising: a data acquisition module 402, a script generation module 404, a value processing module 406, a value replacement module 408, and a script execution module 410, wherein:

[0110] Data acquisition module 402 is used to acquire and parse target data packets to obtain an interface call sequence; the interface call sequence includes at least one test step;

[0111] The script generation module 404 is used to generate an initial test script based on the interface call sequence; the initial test script includes the parameter values ​​corresponding to each test step.

[0112] The value processing module 406 is used to generate corresponding value expressions for each parameter value and obtain the value mapping relationship between the parameter value and the value expression.

[0113] The value replacement module 408 is used to replace each parameter value in the initial test script with the corresponding value expression according to the value mapping relationship, so as to obtain the target test script;

[0114] The script execution module 410 is used to execute the target test script to complete the test task of the interface to be tested.

[0115] In one embodiment, the script generation module 404 is specifically used to assign a step identifier to each test step according to the interface call sequence, and obtain the original request data of each test step; extract at least one parameter name and the parameter value corresponding to the parameter name of each test step according to the original request data; and generate an initial test script according to the step identifier, parameter name and parameter value.

[0116] In one embodiment, the value retrieval processing module 406 is specifically used to parse the data structure of the response data of each interface to be tested, obtain the parameter values ​​of the response data and the corresponding access paths; determine the step identifiers corresponding to each parameter value; generate the value retrieval expressions corresponding to the parameter values ​​according to the step identifiers and access paths; and record the mapping relationship between the value retrieval expressions and parameter values ​​in the value retrieval mapping relationship.

[0117] In one embodiment, the value replacement module 408 is specifically used to query the value mapping relationship for each parameter value in the initial test script to obtain the corresponding value expression; when the parameter value corresponds to multiple candidate value expressions, calculate the similarity between the parameter name of the parameter value and the field name in each value expression; select the target value expression to replace the parameter value based on the similarity to obtain the target test script.

[0118] In one embodiment, the script execution module 410 is specifically used to execute each test step sequentially according to the order of each test step in the target test script, and to perform the following steps for each test step: if the request parameter of the test step contains a value expression, obtain the actual parameter value corresponding to the value expression from the global data storage space; use the actual parameter value to call the corresponding interface to be tested; and save the response data of the interface to be tested to the global data storage space.

[0119] In one embodiment, the apparatus further includes: a data verification module, used to, during the execution of the target test script, retrieve corresponding verification rules from a verification rule base for each test step's response data based on the interface identifier of the interface to be tested and the response status code of the response data; wherein the verification rule base is constructed based on historical version return data of the interface to be tested; and verify each parameter value in the response data according to the verification rules to obtain a verification result.

[0120] Each module in the aforementioned automated interface testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0121] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores target data packets and value mapping relationships. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements an automated interface testing method.

[0122] Those skilled in the art will understand that Figure 5The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0123] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0124] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0125] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0126] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0127] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0128] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0129] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An automated interface testing method, characterized in that, The method includes: Acquire and parse the target data packet to obtain the interface call sequence; the interface call sequence includes at least one test step. An initial test script is generated based on the interface call sequence; wherein, the initial test script includes parameter values ​​corresponding to each of the test steps; Generate corresponding value expressions for each of the parameter values ​​to obtain the value mapping relationship between the parameter values ​​and the value expressions; Based on the value mapping relationship, each parameter value in the initial test script is replaced with the corresponding value expression to obtain the target test script; Execute the target test script to complete the test task of the interface to be tested.

2. The method according to claim 1, characterized in that, The step of generating an initial test script based on the interface call sequence includes: Based on the interface call sequence, assign a step identifier to each test step and obtain the original request data for each test step; Based on the original request data, extract at least one parameter name and the parameter value corresponding to each of the test steps; An initial test script is generated based on the step identifier, the parameter name, and the parameter value.

3. The method according to claim 2, characterized in that, The step of generating corresponding value expressions for each of the parameter values ​​to obtain the value mapping relationship between the parameter values ​​and the value expressions includes: Parse the data structure of the response data of each interface to be tested to obtain the parameter values ​​and corresponding access paths of the response data; Determine the step identifier corresponding to each of the parameter values; Based on the step identifier and the access path, generate the value expression corresponding to the parameter value; The mapping relationship between the value expression and the parameter value is recorded in the value mapping relationship.

4. The method according to claim 1, characterized in that, The step of replacing each parameter value in the initial test script with the corresponding value expression according to the value mapping relationship to obtain the target test script includes: For each parameter value in the initial test script, the value mapping relationship is queried to obtain the corresponding value expression; When the parameter value corresponds to multiple candidate value expressions, calculate the similarity between the parameter name of the parameter value and the field name in each of the value expressions; The target value expression is selected based on the similarity to replace the parameter value, thus obtaining the target test script.

5. The method according to any one of claims 1 to 4, characterized in that, The execution of the target test script to complete the testing task of the interface to be tested includes: Execute each test step sequentially according to the order of the test steps in the target test script, and perform the following steps for each test step: If the request parameters of the test step include a value expression, the actual parameter value corresponding to the value expression is obtained from the global data storage space; Use the actual parameter values ​​to call the corresponding interface to be tested; The response data of the interface to be tested is saved to the global data storage space.

6. The method according to claim 1, characterized in that, The method further includes: During the execution of the target test script, for the response data of each test step, the corresponding verification rule is retrieved from the verification rule base according to the interface identifier of the interface to be tested and the response status code of the response data; wherein, the verification rule base is constructed based on the historical version return data of the interface to be tested; According to the verification rules, the parameter values ​​in the response data are verified to obtain the verification results.

7. An automated interface testing device, characterized in that, The device includes: The data acquisition module is used to acquire and parse the target data packet to obtain the interface call sequence; the interface call sequence includes at least one test step. The script generation module is used to generate an initial test script based on the interface call sequence; wherein, the initial test script includes parameter values ​​corresponding to each of the test steps; The value processing module is used to generate corresponding value expressions for each of the parameter values, and to obtain the value mapping relationship between the parameter values ​​and the value expressions. The value replacement module is used to replace each parameter value in the initial test script with the corresponding value expression according to the value mapping relationship, so as to obtain the target test script; The script execution module is used to execute the target test script to complete the test task of the interface to be tested.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the 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 computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images