Interface automation case test method, device and equipment and storage medium

Abstract

The invention discloses an interface automation case test method, device and equipment and a storage medium. Comprising the steps of obtaining a target server address, and configuring a proxy platform according to the target server address; reading a historical request message in the proxy platform database, generating an initial case according to the historical request message, and performing parameterization processing on the initial case to generate an interface automation case; and performing version verification based on the interface automation case to generate an interface test result. Through configuration of the proxy platform, automatic interception and storage of communication messages are realized, test data are ensured to be real and complete, and a data collection process is simplified. By reading the historical request message and performing parameterization processing, the test case adaptive to multiple scenes can be efficiently generated, the reusability and flexibility of the case are improved, and the maintenance cost is reduced. The version verification is carried out based on the automatic case, the interface compatibility and function difference are rapidly and accurately detected, the test period is shortened, the version verification efficiency is improved, and the stability of software iteration is guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of interface testing, and in particular to an interface automation case testing method, device, equipment and storage medium. Background Art

[0002] In today's era of accelerating digital transformation, the scale and complexity of software systems continue to rise, and enterprises are placing increasingly stringent demands on software quality and delivery efficiency. Interfaces, as the critical hub for data exchange between systems, have a direct impact on the smooth operation of business processes. Traditional manual interface testing methods, due to inefficiency and incomplete coverage, are unable to adapt to the rapid pace of iterative development. Therefore, automated testing technology has emerged as a key means of ensuring interface quality.

[0003] Currently, the industry has a variety of automated interface testing solutions. Among them, a Chinese patent (A method and system for generating automated test cases, application number CN202111149454.1) proposes a solution for processing streaming messages based on regular expressions. This solution obtains message content by performing regular expression matching on streaming messages in message logs, and then segments, extracts, and fills them according to interface documentation to ultimately generate automated test cases.

[0004] However, the aforementioned patented solution primarily targets streaming messages and relies on regular expressions for parsing, making it incompatible with other mainstream data formats such as XML and JSON, limiting its applicability. Furthermore, existing solutions typically generate test cases based on historical message logs within a fixed time period, failing to fully consider the actual business scenarios and context of the messages. This results in the generated cases being insufficiently targeted in actual testing. Summary of the Invention

[0005] The present invention provides an interface automation case testing method, device, equipment and storage medium, which automatically generate interface test cases based on an agent platform and verify their correctness, thereby reducing the testing cycle.

[0006] According to one aspect of the present invention, a method for automated interface case testing is provided, the method comprising:

[0007] Obtain the target server address and configure a proxy platform based on the target server address, wherein the proxy platform is used to intercept and store communication messages between the client and the target server;

[0008] Read historical request messages from the proxy platform database, generate initial cases based on the historical request messages, and parameterize the initial cases to generate interface automation cases;

[0009] Perform version verification based on interface automation cases to generate interface test results.

[0010] Optionally, the method further includes: sending a test message to a proxy platform, and determining that the test has passed when the proxy platform forwards the test message to a target server and obtains a response message returned by the target server.

[0011] Optionally, an initial case is generated based on historical request messages, including: displaying the historical request messages to the user to obtain a valid request message selected by the user; adding case description information input by the user to the valid request message to generate a message to be parsed, wherein the case description information includes a usage scenario; splitting the message to be parsed according to a preset parsing format to generate various parsing structures; and splicing the various parsing structures according to a preset format to generate an initial case.

[0012] Optionally, the parsing structure includes a URL, a public domain input, a private domain input, a public domain output, and a private domain output.

[0013] Optionally, the initial case is parameterized to generate an interface automation case, including: determining each target data type included in the initial case; obtaining a parameterization processing list, wherein the parameterization processing list includes a parameterization method corresponding to each data type; matching each target data type separately through the parameterization processing list to determine a target parameterization method corresponding to each target data type; and parameterizing the initial case based on the target parameterization method to generate an interface automation case.

[0014] Optionally, version verification is performed based on the interface automation case to generate interface test results, including: executing the interface automation case to obtain the execution results; reading the historical response messages in the proxy platform database, comparing the execution results with the historical response messages to generate various comparison verification results, and summarizing the various comparison verification results to generate the interface test results.

[0015] Optionally, the comparison verification results include status line comparison results, response header comparison results and response body comparison results. The execution result and the historical response message are compared to generate various comparison verification results, including: performing a string comparison between the execution result and the status line in the historical response message to generate a status line comparison result; performing a string comparison between the execution result and the response header line in the historical response message to generate a response header comparison result; performing a structural comparison between the execution result and the response body in the historical response message to generate a response body comparison result.

[0016] According to another aspect of the present invention, there is provided an interface automation case testing device, the device comprising:

[0017] A proxy platform configuration module, configured to obtain a target server address and configure a proxy platform according to the target server address, wherein the proxy platform is configured to intercept and store communication messages between the client and the target server;

[0018] An automation case generation module is used to read historical request messages in the proxy platform database, generate an initial case based on the historical request messages, and perform parameterization processing on the initial case to generate an interface automation case;

[0019] The interface test result generation module is used to perform version verification based on the interface automation case to generate an interface test result.

[0020] According to another aspect of the present invention, an electronic device is provided, comprising:

[0021] at least one processor;

[0022] and a memory communicatively coupled to the at least one processor;

[0023] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute an interface automation case testing method described in any embodiment of the present invention.

[0024] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement an interface automation case testing method according to any embodiment of the present invention when executed.

[0025] The technical solution of the embodiment of the present invention, by configuring a proxy platform, realizes automatic interception and storage of communication messages, ensures the authenticity and completeness of test data, and simplifies the data collection process. By reading historical request messages and performing parameterized processing, it is possible to efficiently generate test cases adapted to multiple scenarios, improving case reusability and flexibility and reducing maintenance costs. Version verification based on automated cases allows for rapid and accurate detection of interface compatibility and functional differences, shortening the test cycle, improving version verification efficiency, and ensuring the stability of software iterations.

[0026] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0028] Figure 1 This is a flowchart of an interface automation case testing method provided according to the first embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of the structure of an agent platform provided according to the first embodiment of the present invention;

[0030] Figure 3 This is a flowchart of another interface automation case testing method provided according to the second embodiment of the present invention;

[0031] Figure 4 This is a structural diagram of an interface automation case testing device provided according to a third embodiment of the present invention;

[0032] Figure 5 The present invention is a schematic structural diagram of an electronic device for implementing an interface automation case testing method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0035] Example 1

[0036] Figure 1A flowchart of an interface automation case test method is provided for the first embodiment of the present invention. This embodiment is applicable to interface test scenarios. The method can be executed by an interface automation case test device. The interface automation case test device can be implemented in the form of hardware and / or software. The interface automation case test device can be configured in a browser / server (B / S) architecture. Figure 1 As shown, the method includes:

[0037] S110 , obtaining a target server address, and configuring a proxy platform according to the target server address, wherein the proxy platform is used to intercept and store communication messages between the client and the target server.

[0038] The target server address refers to the network address of the server with which the client browser will communicate and exchange data during the interface test. When configuring the proxy platform, you can use this address to set the target direction for data forwarding, letting the proxy platform know where to send client request messages and where to receive responses from the target server. The proxy platform is built on a B / S architecture, acting as middleware between the client and the target server.

[0039] Specifically, Figure 2 A schematic diagram of the structure of an agent platform is provided for the first embodiment of the present invention. Figure 2 The proxy platform consists of four modules: a front-end interface, core services, a database, and a configuration service. The front-end interface is used to configure the proxy address and view request and response logs. Core services include request and response sending and receiving, a logging module, and a conversion module. The request sending and receiving module receives client requests and forwards them to the target server based on configured routing rules. This function can be implemented using a high-performance asynchronous communication framework suitable for high-concurrency request forwarding. The response sending and receiving module receives responses from the target server and forwards the response data back to the original client. This function can also be implemented using a high-performance asynchronous communication framework suitable for high-concurrency request forwarding. The logging module stores request and response messages in a database or file system. The conversion module processes raw messages and generates automation cases that meet specific formats. The database stores key data such as request and response messages, logs, and configuration information, providing data storage and query support during the testing process. The configuration service manages proxy rules and selects communication protocols to ensure that the proxy platform operates according to established rules. Communication messages are the units of data transmitted between the client and server during interface testing, including request and response messages. A request message contains all the information a client needs to send a request to a server, such as the request line, request headers, and request body. A response message is a collection of information that the server uses to respond to a client request, including a status line, response headers, and response body.

[0040] Optionally, the method further includes: sending a test message to a proxy platform, and determining that the test has passed when the proxy platform forwards the test message to a target server and obtains a response message returned by the target server.

[0041] It should be noted that the proxy platform must be configured with the target server address and proxy port in advance. If the target server uses HTTPS, the proxy platform must install and trust the corresponding SSL certificate.

[0042] Specifically, the proxy platform acts as an intermediary, responsible for receiving test messages—that is, receiving requests from the client—and forwarding them to the actual server based on the configured target server address. It then captures the response from the target server and records key information such as the status code, response headers, and response body. By implementing a closed-loop test of request, forwarding, and verification through the proxy platform, we can ensure the correctness of the interface in a real-world environment.

[0043] S120 , reading historical request messages from the proxy platform database, generating an initial case according to the historical request messages, and parameterizing the initial case to generate an interface automation case.

[0044] Historical request messages refer to request messages sent from clients to target servers in the past, stored in the proxy platform database. Accumulated during previous testing or system operation, these historical request messages contain rich request information and serve as a crucial data source for generating initial test cases. For example, the database may store request messages from different users to a product query interface at different times, each containing different query conditions and request methods. Initial test cases are preliminary test cases generated based on the historical request messages in the proxy platform database. Initial test cases are intermediate products in the automated test case generation process, containing key information extracted from historical request messages. However, they are not yet fully executable or reusable and require further parameterization. Parameterization is the process of replacing fixed values in a test script with variables or parameters. Different methods are used for different data types. For example, for meaningless data, such as log numbers and serial numbers, the platform provides functions to generate specific strings. For business-dependent data, such as contract numbers, parameterization is supported by binding to data documents or through SQL query linkage. Parameterization makes test cases more flexible and reusable, solving the problem of reusing data-intensive test cases. Interface automation cases refer to practical examples used to verify whether API behavior meets expectations. They can be executed automatically to simulate real request and response interactions to ensure that the interface works as expected.

[0045] S130. Perform version verification based on the interface automation case to generate an interface test result.

[0046] Version verification is performed by testing based on interface automation cases and comparing them with the response messages from the previous confirmation test phase to ensure program consistency between the production version and the test version, while also verifying the quality of the generated interface automation cases. Interface test results refer to the test conclusions drawn after version verification based on interface automation cases, reflecting whether the target server interface meets the expected requirements in terms of functionality and performance. Interface test results can help developers and testers determine whether there are any problems with the interface, such as whether the interface returns correct data or whether the interface response time is within a reasonable range, providing a basis for subsequent program optimization and problem fixing.

[0047] Specifically, after a software version is updated, the generated interface automation case can be used for version verification. The newly generated automation case is executed in the new version environment and compared with the response message saved during the confirmation test phase. By comparing the status line, response header, response body, and other content, it is verified whether the new version of the interface is consistent with the previous version and whether the function is normal. For example, for an interface that returns data in JSON format, compare whether the status line is completely consistent, whether the key information in the response header is as expected, and whether the key set and nested structure of the response body are correct.

[0048] Optionally, version verification is performed based on the interface automation case to generate interface test results, including: executing the interface automation case to obtain the execution results; reading the historical response messages in the proxy platform database, comparing the execution results with the historical response messages to generate various comparison verification results, and summarizing the various comparison verification results to generate the interface test results.

[0049] It's clear that because parameterization was used during the initial generation of the interface automation case, replacing fixed values with variables, the parameterized variables must be replaced with actual values before execution. These actual values can be data-driven, such as reading from a CSV file or database, or generated through dynamic functions, such as generating random numbers, timestamps, or unique identifiers. After parameter replacement, the test request is sent to the target server through the proxy platform. The proxy platform forwards the request to the configured target server address to retrieve the execution results. The proxy platform's database stores historical response messages from previous validation test phases. During version verification, the historical response messages corresponding to the current test request are retrieved from the database. Request identifiers, such as a unique ID or a combination of the request URL and method, can be used to accurately locate the corresponding historical record. If multiple versions of historical data exist, the most recently successful execution result is used as the baseline for comparison.

[0050] It should be noted that if an interface involves the comparison of multiple requests and responses, then all the comparisons must be combined to determine the overall test status of the interface. For example, most of the key comparisons of the status line, response header, and response body of an interface have passed, and only the comparison of a non-critical field has failed. After evaluation, it has little impact on the overall function. Then, the test result of the interface can be determined as passed or failed based on the specific evaluation criteria. Finally, the test results of all interface automation cases are summarized to form the final interface test report. The report will include the test status of each interface, as well as the overall pass rate statistics. Through the interface test report, you can clearly understand the overall operation of the interface in the new version, determine whether it meets the online requirements, and provide developers with detailed information so that they can carry out targeted repairs and optimizations on problematic interfaces.

[0051] Optionally, the comparison verification results include status line comparison results, response header comparison results and response body comparison results. The execution result and the historical response message are compared to generate various comparison verification results, including: performing a string comparison between the execution result and the status line in the historical response message to generate a status line comparison result; performing a string comparison between the execution result and the response header line in the historical response message to generate a response header comparison result; performing a structural comparison between the execution result and the response body in the historical response message to generate a response body comparison result.

[0052] Specifically, during the version verification process of the interface automation test, the execution result and the historical response message can be compared to generate various comparison verification results, including status line comparison results, response header comparison results and response body comparison results.

[0053] The status line includes the protocol version, status code, and status description. For example, "HTTP / 1.1 200 OK" represents the protocol version, "200" represents the status code, and "OK" represents the status description. When performing a comparison, a string comparison is performed between the status line in the current execution result and the status line in the previous response message. Generally, the comparison is considered successful only if the protocol version, status code, and status description of the two status lines are identical. For example, if the historical status line is "HTTP / 1.1 200 OK" and the status line of the current execution result is "HTTP / 1.1 404 Not Found," the status line comparison will fail because both the status code and status description have changed. However, under certain special settings, such as ignoring case in the status description or having specific tolerance rules for differences in status descriptions, the comparison may be considered successful even if the status descriptions are not identical, provided these pre-set rules are met. If the status lines are inconsistent, it indicates that the interface function is abnormal. For example, if the status code becomes 404, it means that the requested resource may not exist; if it becomes 500, it means that an error may have occurred inside the server.

[0054] Specifically, a response header can include multiple fields, such as "Content-Type," which specifies the type of response data ("application / json" indicates the data is in JSON format), "Cache-Control," which controls caching policies, and "Authorization," which is used for authentication. When comparing response headers, the first step is to check whether the required fields included in the previous response header are also present in the current execution result's response header. For example, if the previous response header contains the "Content-Type" and "X-Token" fields, but the current execution result's response header does not contain "X-Token," the comparison will fail. Furthermore, for fields that are present, the field values are compared. Some fields require an exact value match, such as "Content-Type." If the previous response header contains "application / json," while the current execution result contains "application / json; charset=utf-8," while similar, they are not identical, and the comparison will fail. However, for dynamically changing values, such as timestamps and version numbers, regular expressions can be used to perform matching verification. For example, for the "Date" field, the historical response is "Date:Mon,10May 202312:00:00GMT", and the current response is "Date:Tue,11May 202313:00:00GMT". By setting the regular expression "Date:.*", as long as the format matches "Date:" plus some characters, the specific time difference can be ignored and the field will be considered to have passed the comparison. In addition, a whitelist mechanism can be set up. For some less important and non-critical header fields, such as "Server:nginx", it can be chosen to ignore its comparison. Even if the fields in the two responses are different, it will not affect the overall response header comparison result. Moreover, the order of the fields in the response header does not affect the comparison result. For example, "A:1,B:2" and "B:2,A:1" will be considered the same.

[0055] Specifically, the response body comparison is mainly carried out from two aspects: structure and key set. From a structural perspective, it is necessary to check whether the response body of the current execution result and the response body of the historical response message are consistent in the key set and nesting level of JSON or XML data. From the key set perspective, the keys of the current response body should at least contain all the keys of the historical response body, and some new keys are acceptable. For example, the historical response body is {"id":1,"name":"test"}, and the current response body is {"id":1,"name":"test","age":25}. Because the current response body contains all the keys of the historical response body and also adds the "age" key, it can be considered a structural match. However, if the current response body lacks a key in the historical response body, it will be considered a structural mismatch. In terms of nesting level consistency, the nesting structure of objects and arrays must be the same. For example, the historical response body is {"user":{"id":1}}, and the current response body is {"user":[1]}. Since one is an object nesting structure and the other is an array structure, the nesting level is inconsistent and the structural comparison fails. From a value perspective, for fixed-value fields, such as the "code" field, which should always be "SUCCESS" or the "status" field, which should always be "1," the values of these fields in the current execution result must be exactly the same as those in the previous response message for the values to match. For dynamically changing values, such as timestamps and serial numbers, which may vary with each request, you can configure them to be ignored in the comparison or set a regular expression to verify that the format meets the requirements. For example, if the previous response body has a "timestamp" field with a value of "2023-05-10T12:00:00Z" and the current response body has a "timestamp" field with a value of "2023-05-11T13:00:00Z," setting the regular expression "timestamp":"\\d{4}-\\d{2}-\\d{2}T.*Z" will ignore the specific time difference and consider the value comparison to pass as long as the format matches "year-month-day T time Z." If the response body contains an array, for unordered arrays, as long as all elements in the array exist, the order of the elements is not required to be consistent. For example, [1,2,3] and [3,2,1] will be considered a match. By comparing the status line, response header, and response body, the corresponding comparison results can be obtained, which can fully reflect the differences between the current execution results and the historical response messages, providing important basis for determining whether the new version of the interface is compatible with the previous version and whether the function is stable.

[0056] The technical solution of the embodiment of the present invention, by configuring a proxy platform, realizes automatic interception and storage of communication messages, ensures the authenticity and completeness of test data, and simplifies the data collection process. By reading historical request messages and performing parameterized processing, it is possible to efficiently generate test cases adapted to multiple scenarios, improving case reusability and flexibility and reducing maintenance costs. Version verification based on automated cases allows for rapid and accurate detection of interface compatibility and functional differences, shortening the test cycle, improving version verification efficiency, and ensuring the stability of software iterations.

[0057] Example 2

[0058] Figure 3 This is a flowchart of an interface automation case testing method provided by the second embodiment of the present invention. This embodiment adds a specific process of generating an initial case based on a historical request message and parameterizing the initial case to generate an interface automation case based on the above-mentioned first embodiment. Among them, the specific contents of steps S210 and S300 are roughly the same as those of steps S110 and S130 in the first embodiment, so they will not be repeated in this embodiment. Figure 3 As shown, the method includes:

[0059] S210: Obtain the target server address, and configure a proxy platform according to the target server address, wherein the proxy platform is used to intercept and store communication messages between the client and the target server.

[0060] Optionally, the method further includes: sending a test message to a proxy platform, and determining that the test has passed when the proxy platform forwards the test message to a target server and obtains a response message returned by the target server.

[0061] S220 : Read historical request messages from the proxy platform database, and display the historical request messages to the user to obtain a valid request message selected by the user.

[0062] Specifically, to facilitate user filtering, the platform displays historical request messages according to certain rules. For example, it sorts by request time, placing the latest requests first so that users can prioritize recent interactions. It also displays the request path, such as " / api / users / 123," to quickly identify which interface the request is targeting. It also marks the response status, clearly distinguishing between successful and failed responses, and prioritizes successful requests. Furthermore, the platform automatically associates business tags to facilitate user categorization and filtering by business module. Users can select valid request messages based on their own judgment.

[0063] S230: Add case description information input by the user to the valid request message to generate a message to be parsed, wherein the case description information includes a usage scenario.

[0064] Specifically, after selecting a valid request message, the user will add a case description to facilitate future reuse. This case description includes the usage scenario, which explains the specific business context of the test case, such as the successful user registration process. The case description can also include the expected result, which specifies the status code that the interface should return and some key field values, such as the expected status code of 200 and the token field in the returned information.

[0065] S240: Split the message to be parsed according to a preset parsing format to generate parsing structures.

[0066] Optionally, the parsing structure includes a URL, a public domain input, a private domain input, a public domain output, and a private domain output.

[0067] Specifically, the URL refers to the full path of the request. Public domain input includes request header information and some public parameters. Private domain input refers to parameters related to specific business, such as the username and password in the login interface. Public domain output includes the response status code and public response headers. Private domain output includes the content of the business response body. During the splitting process, parameters in the URL can be automatically identified through regular expressions, and public parameters and business parameters can be distinguished according to pre-set rules. Sensitive information, such as passwords and tokens, will be automatically shielded or processed according to the desensitization rules specified in the configuration file.

[0068] S250: splicing the parsed structures according to a preset format to generate an initial case.

[0069] Specifically, during splicing, relevant information will be integrated into a standardized framework, including basic information such as case number, case description, priority, related business modules, and detailed content of the request part, such as the requested URL, method, request header, request body, as well as the status code, response header, response body and other information of the expected response part.

[0070] S260: Determine the target data types included in the initial case.

[0071] The initial case is a preliminary test case generated based on historical request messages and contains a variety of data types. For example, there may be ID data representing user identity, which requires different values in different test scenarios; there are also data such as timestamps, serial numbers, and log numbers, which often have specific formats and generation rules; and data such as contract numbers and product numbers are often closely related to actual business operations.

[0072] S270: Obtain a parameterized processing list, wherein the parameterized processing list includes parameterization methods corresponding to each data type.

[0073] Specifically, a parameterized processing checklist is a pre-defined document or configuration information that details the parameterization methods corresponding to various data types. For example, for data with no actual business significance, such as timestamps, serial numbers, and log numbers, a specific function may be set to generate data that meets the requirements. For data with actual business dependencies, such as contract numbers and product numbers, the checklist will specify the corresponding processing method. This may involve binding data documents and obtaining different values from the documents, or it may involve querying SQL databases through linked queries to dynamically obtain parameter values based on the data in the database.

[0074] S280: Match each target data type respectively through the parameterization processing list to determine the target parameterization method corresponding to each target data type.

[0075] For example, if the target data type of a serial number is identified in the initial case, searching the parameterization processing list reveals that its corresponding parameterization method uses a specific function provided by the platform to generate a fixed-length string. Another example is that for a contract number, if the corresponding method in the list is bound to a data document, it can be determined that the target parameterization method for the contract number is to obtain data from the bound data document. Through matching, the corresponding parameterization processing method for each target data type can be determined.

[0076] S290. Parameterize the initial case based on the target parameterization method to generate an interface automation case.

[0077] Specifically, through parameterization, the fixed values in the initial case are replaced with dynamic parameters, generating a more flexible and reusable interface automation case. The generated interface automation case can be reused in different test scenarios, and parameters can be dynamically adjusted according to actual needs, improving test efficiency and accuracy.

[0078] S300: Perform version verification based on the interface automation case to generate interface test results.

[0079] Optionally, version verification is performed based on the interface automation case to generate interface test results, including: executing the interface automation case to obtain the execution results; reading the historical response messages in the proxy platform database, comparing the execution results with the historical response messages to generate various comparison verification results, and summarizing the various comparison verification results to generate the interface test results.

[0080] Optionally, the comparison verification results include status line comparison results, response header comparison results and response body comparison results. The execution result and the historical response message are compared to generate various comparison verification results, including: performing a string comparison between the execution result and the status line in the historical response message to generate a status line comparison result; performing a string comparison between the execution result and the response header line in the historical response message to generate a response header comparison result; performing a structural comparison between the execution result and the response body in the historical response message to generate a response body comparison result.

[0081] The technical solution of the embodiment of the present invention, by displaying historical request messages for users to select valid requests, combined with case description information, ensures that the test cases are deeply bound to real business scenarios, improves the pertinence and effectiveness of the test, and avoids invalid or redundant tests. The standardized construction of test cases is achieved by performing structured parsing and standardized splicing of messages. The parameterization method is automatically matched based on data types to avoid the subjectivity and error-proneness of manual intervention, ensure the accuracy and consistency of parameterized processing, and better adapt to multi-type data processing scenarios of complex interfaces. Through the parameterization mechanism, a single test case can cover a variety of data combinations and business scenarios, significantly improving the case reuse rate and reducing the maintenance cost of test cases.

[0082] Example 3

[0083] Figure 4 This is a schematic diagram of the structure of an interface automation case test device provided by the third embodiment of the present invention. Figure 4 As shown, the device includes: a proxy platform configuration module 310, which is used to obtain the target server address and configure the proxy platform according to the target server address, wherein the proxy platform is used to intercept and store communication messages between the client and the target server;

[0084] The automation case generation module 320 is used to read the historical request messages in the proxy platform database, generate an initial case according to the historical request messages, and parameterize the initial case to generate an interface automation case;

[0085] The interface test result generating module 330 is configured to perform version verification based on the interface automation case to generate an interface test result.

[0086] Optionally, the device further includes: a platform testing module, configured to: send a test message to the proxy platform, and determine that the test has passed when the proxy platform forwards the test message to the target server and obtains a response message returned by the target server.

[0087] Optionally, the automated case generation module 320 specifically includes: an initial case generation unit, which is used to: display historical request messages to the user to obtain a valid request message selected by the user; add case description information input by the user to the valid request message to generate a message to be parsed, wherein the case description information includes a usage scenario; split the message to be parsed according to a preset parsing format to generate various parsing structures; and splice the various parsing structures according to a preset format to generate an initial case.

[0088] Optionally, the parsing structure includes a URL, a public domain input, a private domain input, a public domain output, and a private domain output.

[0089] Optionally, the automation case generation module 320 specifically includes: an automation case generation unit, which is used to: parameterize the initial case to generate an interface automation case, including: determining each target data type included in the initial case; obtaining a parameterization processing list, wherein the parameterization processing list includes a parameterization method corresponding to each data type; matching each target data type respectively through the parameterization processing list to determine the target parameterization method corresponding to each target data type; parameterizing the initial case based on the target parameterization method to generate an interface automation case.

[0090] Optionally, the interface test result generation module 330 specifically includes: an interface test result generation unit, used to: execute the interface automation case to obtain the execution result; read the historical response message in the proxy platform database, compare the execution result with the historical response message to generate various comparison verification results, and summarize the various comparison verification results to generate the interface test result.

[0091] Optionally, the interface test result generation unit specifically includes: a comparison and verification sub-unit, which is used to: perform a string comparison between the execution result and the status line in the historical response message to generate a status line comparison result; perform a string comparison between the execution result and the response header line in the historical response message to generate a response header comparison result; perform a structural comparison between the execution result and the response body in the historical response message to generate a response body comparison result.

[0092] The technical solution of the embodiment of the present invention, by configuring a proxy platform, realizes automatic interception and storage of communication messages, ensures the authenticity and completeness of test data, and simplifies the data collection process. By reading historical request messages and performing parameterized processing, it is possible to efficiently generate test cases adapted to multiple scenarios, improving case reusability and flexibility and reducing maintenance costs. Version verification based on automated cases allows for rapid and accurate detection of interface compatibility and functional differences, shortening the test cycle, improving version verification efficiency, and ensuring the stability of software iterations.

[0093] An interface automation case testing device provided by an embodiment of the present invention can execute an interface automation case testing method provided by any embodiment of the present invention, and has functional modules and beneficial effects corresponding to the execution method.

[0094] Example 4

[0095] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device 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 can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0096] like Figure 5 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.

[0097] 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.

[0098] The processor 11 can 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 that run 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, such as an interface automation case testing method.

[0099] In some embodiments, an interface automation case test method can 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 can 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 interface automation case test method described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute an interface automation case test method in any other appropriate manner (for example, by means of firmware).

[0100] 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.

[0101] Computer programs for implementing the methods of the present invention 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.

[0102] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0103] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device 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. 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).

[0104] 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.

[0105] 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, addressing the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0106] 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 the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0107] The above specific embodiments do not limit the scope of protection of the present invention. 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 the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. An interface automation case testing method, characterized in that: Methods include: Obtaining a target server address, and configuring a proxy platform according to the target server address, wherein the proxy platform is used to intercept and store communication messages between the client and the target server; Reading historical request messages from the proxy platform database, generating an initial case based on the historical request messages, and parameterizing the initial case to generate an interface automation case; Version verification is performed based on the interface automation case to generate interface test results.

2. The method according to claim 1, characterized in that The method further comprises: The test message is sent to the proxy platform. When the proxy platform forwards the test message to the target server and obtains a response message returned by the target server, it is determined that the test has passed.

3. The method according to claim 1, characterized in that Generating an initial case according to the historical request message includes: Displaying the historical request message to the user to obtain a valid request message selected by the user; Adding case description information input by the user to the valid request message to generate a message to be parsed, wherein the case description information includes a usage scenario; Splitting the message to be parsed according to a preset parsing format to generate parsing structures; The analytical structures are spliced according to a preset format to generate an initial case.

4. The method according to claim 3, characterized in that The parsing structure includes a URL, a public domain input, a private domain input, a public domain output, and a private domain output.

5. The method according to claim 1, characterized in that The parameterizing of the initial case to generate an interface automation case includes: determining each target data type included in the initial case; Obtaining a parameterized processing list, wherein the parameterized processing list includes a parameterization method corresponding to each data type; Matching each of the target data types respectively through the parameterization processing list to determine the target parameterization mode corresponding to each of the target data types; The initial case is parameterized based on the target parameterization method to generate an interface automation case.

6. The method according to claim 1, characterized in that The performing version verification based on the interface automation case to generate an interface test result includes: Execute interface automation cases to obtain execution results; Read the historical response message in the proxy platform database, compare the execution result with the historical response message to generate various comparison verification results, and summarize the various comparison verification results to generate an interface test result.

7. The method according to claim 6, characterized in that The comparison verification result includes a status line comparison result, a response header comparison result, and a response body comparison result. The execution result is compared with the historical response message to generate each comparison verification result, including: Performing a character string comparison between the execution result and the status line in the historical response message to generate a status line comparison result; Performing a character string comparison between the execution result and a response header line in the historical response message to generate a response header comparison result; Perform a structural comparison between the execution result and the response body in the historical response message to generate a response body comparison result.

8. An interface automation case testing device, characterized in that: include: A proxy platform configuration module, configured to obtain a target server address and configure a proxy platform according to the target server address, wherein the proxy platform is configured to intercept and store communication messages between the client and the target server; An automation case generation module is used to read historical request messages in the proxy platform database, generate an initial case based on the historical request messages, and perform parameterization processing on the initial case to generate an interface automation case; The interface test result generation module is used to perform version verification based on the interface automation case to generate an interface test result.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that The computer storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the method according to any one of claims 1 to 7 when executed.

Images