Interface case data processing method and device, electronic equipment and readable storage medium

Abstract

The invention relates to the technical field of data processing, and provides an interface case data processing method and device, electronic equipment and a readable storage medium. The method comprises the steps that clustering processing is carried out on to-be-processed flow data based on a preset sorting condition, an ordered interface calling chain is obtained, and the ordered interface calling chain comprises response data and request data; performing full-field value matching processing on the response data and the request data to obtain a data dependency graph; performing parameterization processing on the request data based on the ordered interface call chain and the data dependency graph to obtain target interface case data; and the target interface is verified based on the target interface case data, so that the automation degree of interface testing is improved, the fitting degree of the case data and a real business scene is improved, the verification accuracy, continuity and maintainability are enhanced, the interface verification accuracy and efficiency are improved, the interface case implementation efficiency is improved, the maintenance difficulty is reduced, and the user experience is improved. And the reusability of the interface case data is enhanced.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to an interface use case data processing method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] In the field of software testing, to verify interface functionality, testers mainly rely on manually analyzing interface documentation and business processes, writing requests for each interface one by one, and manually setting parameter passing relationships. However, this method is inefficient, and when the interface definition or business logic changes, the scripts need to be re-maintained. Test cases lack robustness due to strong coupling with specific data. It is also possible to automatically generate interface request sequences by recording network traffic, but this method can only generate static test cases containing fixed data, does not identify dynamic dependencies between data, cannot achieve parameterization, and makes test cases unusable.

[0003] It is evident that existing technologies suffer from low efficiency in test case generation and maintenance, and the inability to parameterize test cases, resulting in low efficiency, difficult maintenance, and poor reusability in interface automation test case technology. Summary of the Invention

[0004] In view of this, the present disclosure provides an interface test case data processing method, apparatus, electronic device, and readable storage medium to solve the problems in the prior art where the low efficiency of test case generation and maintenance, the inability to parameterize test cases, and the resulting low efficiency, difficult maintenance, and poor reusability of interface automated test case technology.

[0005] A first aspect of this disclosure provides an interface use case data processing method, comprising: clustering traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data; performing full field value matching processing on the response data and request data to obtain a data dependency graph; parameterizing the request data based on the ordered interface call chain and the data dependency graph to obtain target interface use case data; and verifying the target interface based on the target interface use case data.

[0006] In some embodiments, performing full-field value matching on response data and request data to obtain a data dependency graph includes: performing full-field value extraction on response data to obtain an upstream value set; performing full-field parameter extraction on request data to obtain a downstream parameter set; performing precise value matching on the upstream value set and downstream parameter set to obtain a field lineage mapping table; and constructing a data dependency graph based on the field lineage mapping table.

[0007] In some embodiments, parameterizing request data based on an ordered interface call chain and a data dependency graph to obtain target interface use case data includes: performing variable path marking on the data dependency graph to obtain variable expressions; performing matching and replacement processing on the request data and variable expressions to obtain parameterized request data; and performing sequential encapsulation processing on the parameterized request data based on the ordered interface call chain to obtain target interface use case data.

[0008] In some embodiments, the traffic data to be processed includes a timestamp field, a Uniform Resource Identifier (URI) field, and a business identifier field. Clustering the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain includes: sorting the traffic data to be processed in ascending order based on the timestamp field to obtain a time-series request-response set; performing same-origin aggregation on the time-series request-response set based on the URI field to obtain an interface call group; and clustering the interface call group based on the business identifier field to obtain an ordered interface call chain.

[0009] In some embodiments, verifying a target interface based on target interface use case data includes: performing assertion feature extraction processing on the target interface use case data to obtain baseline verification conditions; performing environment variable injection processing on the target interface use case data to obtain environment adaptation request data; performing replay processing on the environment adaptation request data to obtain real-time response data; and performing consistency verification processing on the baseline verification conditions and real-time response data to obtain interface verification results.

[0010] In some embodiments, the consistency verification process of the benchmark verification conditions and the real-time response data is performed to obtain the interface verification result, including: performing status code extraction processing on the real-time response data to obtain the real-time status result; performing expected status extraction processing on the benchmark verification conditions to obtain the expected status result; and performing equivalence judgment processing on the real-time status result and the expected status result to obtain the interface verification result.

[0011] In some embodiments, after verifying the target interface based on the target interface use case data, the method further includes: obtaining historical test execution results; performing regression testing on the target interface use case data to obtain real-time test execution results; performing difference comparison processing on the historical test execution results and the real-time test execution results to obtain change impact data; and performing incremental update processing on the data dependency graph based on the change impact data to obtain target interface use case update data.

[0012] A second aspect of this disclosure provides an interface use case data processing apparatus, comprising: a first processing module, configured to perform clustering processing on traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data; a second processing module, configured to perform full field value matching processing on the response data and request data to obtain a data dependency graph; a third processing module, configured to perform parameterization processing on the request data based on the ordered interface call chain and the data dependency graph to obtain target interface use case data; and a fourth processing module, configured to verify a target interface based on the target interface use case data.

[0013] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0014] A fourth aspect of this disclosure provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0015] The beneficial effects of this disclosed embodiment compared with the prior art are as follows: Clustering of the traffic data to be processed is performed using preset sorting conditions to obtain an ordered interface call chain containing response data and request data; full-field value matching is performed on the response data and request data to generate a data dependency graph; based on the ordered interface call chain and data dependency graph, parameterization processing is performed on the request data to output target interface test case data; the target interface is verified using the target interface test case data. This improves the automation level of interface testing, enhances the fit between test case data and real business scenarios, improves the accuracy and efficiency of interface verification, increases the efficiency of interface test case implementation, reduces maintenance difficulty, and enhances the reusability of interface test case data. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure; Figure 2 This is a flowchart illustrating an interface use case data processing method provided in an embodiment of this disclosure; Figure 3This is a flowchart illustrating another interface use case data processing method provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of an interface use case data processing device provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this disclosure. However, those skilled in the art will understand that this disclosure may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this disclosure with unnecessary detail.

[0019] It should be noted that the user information (including but not limited to terminal device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0020] The following will describe in detail, with reference to the accompanying drawings, an interface use case data processing method and apparatus according to an embodiment of the present disclosure.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure. The application scenario may include terminal devices 1, 2, and 3, server 4, and network 5.

[0022] Terminal devices 1, 2, and 3 can be hardware or software. When terminal devices 1, 2, and 3 are hardware, they can be various electronic devices with displays and supporting communication with server 4, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 1, 2, and 3 are software, they can be installed in the aforementioned electronic devices. Terminal devices 1, 2, and 3 can be implemented as multiple software programs or software modules, or as a single software program or software module; this disclosure does not limit this. Furthermore, various applications can be installed on terminal devices 1, 2, and 3, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0023] Server 4 can be a server that provides various services, such as a backend server that receives requests sent by terminal devices with which it has established communication connections. This backend server can receive and analyze the requests sent by the terminal devices and generate processing results. Server 4 can be a single server, a server cluster consisting of several servers, or a cloud computing service center. This disclosure embodiment does not limit this.

[0024] It should be noted that server 4 can be either hardware or software. When server 4 is hardware, it can be various electronic devices that provide various services to terminal devices 1, 2, and 3. When server 4 is software, it can be multiple software programs or software modules that provide various services to terminal devices 1, 2, and 3, or it can be a single software program or software module that provides various services to terminal devices 1, 2, and 3. This disclosure does not limit the scope of the embodiments.

[0025] Network 5 can be a wired network using coaxial cable, twisted pair, and fiber optic connection, or it can be a wireless network that enables interconnection of various communication devices without wiring, such as Bluetooth, Near Field Communication (NFC), and Infrared. This disclosure does not limit the scope of the network.

[0026] Users can establish a communication connection with server 4 via network 5 through terminal devices 1, 2, and 3 to receive or send information. Specifically, server 4 can obtain traffic data to be processed through terminal devices 1, 2, and 3, perform clustering processing on the traffic data to be processed according to preset sorting conditions, and obtain an ordered interface call chain containing response data and request data; perform full field value matching processing on the response data and request data to generate a data dependency graph; based on the ordered interface call chain and data dependency graph, perform parameterization processing on the request data and output target interface use case data; and verify the target interface through the target interface use case data.

[0027] It should be noted that the specific types, quantities, and combinations of terminal devices 1, 2, and 3, server 4, and network 5 can be adjusted according to the actual needs of the application scenario, and this disclosure embodiment does not impose any restrictions on this.

[0028] Figure 2 This is a flowchart illustrating an interface use case data processing method provided in an embodiment of this disclosure. Figure 2 The interface test case data processing method can be provided by Figure 1 The server executes this. For example... Figure 2 As shown, the data processing method for this interface use case includes: S201, cluster the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data.

[0029] Specifically, the traffic data to be processed can be a collection of raw interface communication records captured through network interaction that has not been structured. The form of the traffic data to be processed can be a sequence of data packets including but not limited to timestamps, source addresses, destination addresses, request content and / or response content. The traffic data to be processed can be captured in real time and preliminarily structured by a traffic recording proxy or network monitoring tool when the user performs specific business operations, after authorization by the user. For example, when the user performs operations such as login, query, and submission on the client interface, all Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure (HTTP / HTTPS) requests and responses exchanged between the interaction record and the server can be recorded as traffic data to be processed.

[0030] The preset sorting conditions can be predefined rules or algorithms, which can be used to guide the classification and sequential arrangement of discrete interface call records. The preset sorting conditions include, but are not limited to, the order of interface calls, the path similarity based on the Uniform Resource Locator, the preset scenario template based on business logic, or the dependency relationship of parameter passing between interfaces. The preset sorting conditions can be preset according to the interaction mode of the target business system or the test requirements.

[0031] Clustering can be a data processing process that groups and arranges multiple discrete interface call records in the traffic data to be processed into a sequence with inherent logical relationships based on preset sorting conditions. This clustering can be a data organization and pattern recognition operation, which can transform the traffic data to be processed into structured data units that can be used to characterize specific business scenarios or user operation paths. This clustering can also be an analysis and reorganization of the traffic data to be processed by applying sorting conditions.

[0032] Furthermore, the clustering process can specifically involve receiving the original request / response pairs from the traffic recording agent through a scenario parser, performing initial grouping based on the continuity of timestamps, and classifying multiple interface calls occurring consecutively within a short period of time into a potential business scenario unit; it can then combine the path pattern of the Uniform Resource Locator (URL) or perform secondary clustering and verification based on preset business keywords (such as "login process", "payment process", etc.) to obtain one or more clear scenario sequences that can be used to represent the complete user operation loop, i.e., ordered interface call chains.

[0033] In addition, an ordered interface call chain can be a structured representation of traffic data to be processed. This ordered interface call chain can be a sequence of interface calls arranged based on a specific logical order (e.g., business execution steps). Each element in the ordered interface call chain contains a complete set of interface interaction information.

[0034] The request data can be a component of each interface call record in the ordered interface call chain, and can be used to characterize the information carried when the server initiates an operation. The request data can include Hypertext Transfer Protocol (HTTP) methods, request headers, request parameters, and / or request bodies, etc., without limitation here. The request data can be used to characterize the client's intent and operation input. For example, in a test scenario, the request data can be the core input part that simulates user behavior and drives business logic. In the ordered interface call chain, the request data and the corresponding response data appear in pairs to form a complete call record.

[0035] Response data can be an important component of each interface call record in an ordered interface call chain. This response data can be used to characterize the information returned by the server to the client after processing the request. This response data may include, but is not limited to, status codes, response headers, and / or response bodies.

[0036] For example, during the testing phase of an online marketplace, a traffic recording proxy can capture the interface interactions between the user's browser and the marketplace's backend server, generating pending traffic data. This pending traffic data can be sent to a scenario parser, which can process the data based on preset sorting conditions. Based on the close continuity of timestamps, all interface calls generated by the user from clicking on a product to completing payment can be initially clustered into a business scenario cluster. Further analysis of the URL paths of the interfaces can identify that multiple call records belong to the "placing an order" business process. This allows for the confirmation and construction of an ordered interface call chain. This call chain arranges the aforementioned interface calls in chronological order, and each call contains the request data at that time (such as the specific product specification number and quantity in the add-to-cart request) and the response data returned by the server (such as the product inventory information in the product details response and the generated temporary order number in the create order preview response).

[0037] This application embodiment uses a scenario parser to cluster traffic data to be processed based on preset sorting conditions: according to the continuity of timestamps, interface calls that occur consecutively within a short period of time are classified into potential business scenario units, and secondary clustering and verification are performed according to URL path patterns or preset business keywords to obtain an ordered interface call chain. In this way, the threshold and cost of creating interface test case data are reduced; the automation level of interface testing is improved; the fit between test case data and real business scenarios is enhanced; and the accuracy and efficiency of interface verification are improved.

[0038] S202, perform full field value matching on the response data and request data to obtain a data dependency graph.

[0039] Specifically, full-field value matching can be a data association process based on precise value comparison. This can be achieved by iterating through the parameter field values ​​of the current request data and comparing each parameter field value with the field values ​​in the historical response data for equality.

[0040] Furthermore, the full-field value matching process may include traversing parameters at different locations in the request data, including but not limited to URL query string parameters, request header parameters, and nested field values ​​in the request body represented by JavaScript Object Notation (JSON) paths or Extensible Markup Path Language (XPath).

[0041] Furthermore, the full field value matching process may include iterating through all accessible field values ​​in the historical response data and focusing on the leaf node values ​​in the nested data structures represented by JSON paths or XPaths in the response body.

[0042] A data dependency graph can be a directed graph data structure used to visualize the data flow relationship between interfaces. The basic components of the data dependency graph can include nodes and edges. Nodes can be used to represent interface testing steps, and edges can be used to represent the data dependency relationship from the response of one step to the request of another step.

[0043] For example, based on the above application scenario, the traffic recording proxy can capture three API calls: the login API (Login) returns a JSON response containing `userId: "U12345"` and `token: "T67890"`; the product details query API (GetGoodsDetail) returns a response containing `goodsId: "G001"`; and the create order API (CreateOrder) sends a request body containing `buyerId: "U12345"` and `productId: "G001"` fields, with its request header containing `Authorization: Bearer`. The T67890 can perform full field value matching on response and request data using a lineage analysis engine. By iterating through the values ​​of each field in the CreateOrder request, it compares the value of the `buyerId` field "U12345" with all field values ​​in the historical response data, finding that it matches the value of the `userId` field in the Login interface response; it can also compare the value of the `productId` field "G001" with all field values ​​in the historical response data, finding that it matches the value of the `goodsId` field in the GetGoodsDetail interface response; and it can also match the value of the `Authorization` field in the request header "Bearer...". By performing substring or rule matching on all field values ​​of "T67890" in the historical response data, it was found that the value of the `token` field "T67890" in the Login interface response was included. This yielded a data dependency graph, which represents the flow of the `userId` and `token` output data from the Login step to the corresponding input parameters of the CreateOrder step, and the flow of the `goodsId` output data from the GetGoodsDetail step to the corresponding input parameters of the CreateOrder step.

[0044] This application embodiment uses a lineage analysis engine to perform full field value matching on response and request data in an ordered interface call chain. By traversing parameter field values ​​at different positions in the current request data and comparing the parameter field values ​​with all accessible field values ​​in the historical response data one by one for equality, when a request field value is found to be equal to a certain historical response field value or a holding substring is found to match in the authorization header, a directed dependency edge is established, generating a data dependency graph composed of nodes and directed edges. In this way, the accuracy of identifying data dependency relationships between interfaces is improved, the fit between interface use case data and real business lineage is enhanced, and the integrity and maintainability of interface verification are strengthened.

[0045] S203, based on the ordered interface call chain and data dependency graph, performs parameterization on the request data to obtain the target interface use case data.

[0046] Specifically, parameterization can be a data processing procedure that replaces specific numerical values ​​in the request data with variable references to the data source, thereby decoupling test cases from specific test data. The target interface test case data can be a set of test case data obtained through parameterization, in which all hard-coded values ​​are replaced with variable references. The target interface test case data can be in the form of a set of structured, executable test instructions.

[0047] Furthermore, parameterization can include traversing each dependency edge in the data dependency graph; for each dependency edge, locating the field that uses the upstream data in the request data of the target interface; and replacing the original hard-coded value of the field with a variable expression pointing to the upstream data source, wherein the format of the variable expression can be a reference path pointing to a specific data item in the upstream interface response.

[0048] In addition, after replacing the parameters of all dependent edges, the remaining request data fields in the ordered interface call chain that are not covered by the data dependency graph can retain their original hard-coded values ​​or be generalized according to predefined rules, such as by filling them with pre-set test data templates.

[0049] For example, after inputting the ordered interface call chain and corresponding data dependency graph of the login, product details query, and order creation interfaces recorded in the online mall, each dependency edge of the data dependency graph can be traversed through parameterized processing: the hard-coded buyer ID field value in the order creation interface request body can be located as "U12345", which can be replaced with the variable expression "user ID returned by the login step"; the product ID field value "G001" can be replaced with "product ID returned by the product details query step"; the "holding T67890" in the authorization field of the request header can be replaced with "term returned by the login step"; for the shipping address field not covered by the dependency graph, the hard-coded value can be retained according to the preset test data template, and target interface use case data in which all hard-coded values ​​are replaced with variable references can be generated.

[0050] This application embodiment traverses each dependency edge in the data dependency graph through parameterized processing using an ordered interface call chain and a data dependency graph. It locates the field in the target interface's request data that uses the upstream data, and replaces the original hard-coded value of that field with a variable expression pointing to the upstream data source. For the remaining request data fields in the ordered interface call chain that are not covered by the data dependency graph, their original hard-coded values ​​are retained, or they are generalized according to predefined rules using a pre-defined test data template. This results in target interface test case data where all hard-coded values ​​are replaced with variable references. This improves the decoupling between test cases and specific data, enhances the reusability of interface test case data across multiple environments and datasets, and strengthens the maintenance efficiency and execution flexibility of interface test data.

[0051] S204, Verify the target interface based on target interface use case data.

[0052] Specifically, during the verification process, the test execution engine can load the target interface test case data, parse the variable references in the target interface test case data to obtain real-time parameter values, construct an HTTP / HTTPS request that conforms to the interface specification, and send the request to the server address of the target interface.

[0053] Furthermore, after sending the request, the response data returned by the target interface can be captured, including the status code, response headers, and response body content. The verification process can include comparing the actual response with the expected response rules defined in the target interface use case data. For example, it can check whether the status code meets expectations, or use query languages ​​such as JSON path or XPath to verify whether the value of a specific field in the response body meets the assertion conditions.

[0054] The target interface can be the application programming interface to be tested, which provides specific functions or services; the verification target interface can be checked by executing test cases to see if the actual behavior of the target interface meets its design specifications and business logic expectations. The verification operation can receive target interface test case data as input, execute test logic, and output verification results.

[0055] In addition, during the verification process, dynamic resolution and replacement of variable references can be supported. When the target interface use case data contains variables in the form of `{{step1.response.body.orderId}}`, the execution result of step 1 (i.e. an upstream interface call) can be traced back, the actual value of the `orderId` field can be extracted from its response body, and the value can be filled into the corresponding position of the current request.

[0056] For example, in an online marketplace testing environment, the test execution engine can load parameterized target interface test case data, parse the variable reference "{{login steps.response.body.word}}" in the "Create Order" request, and replace it in real time with "T67890" just returned by the login interface. The "Buyer ID" field can be filled with "U12345" from the upstream login response, and the "Product ID" field can be filled with "G001" from the upstream query response. An HTTP request conforming to the interface specification can be constructed and sent to the Create Order interface. After the server returns a status code 200 and a JSON response body, the response data can be captured. The "Order Status" value in the response body can be verified to be "Created" and the "User ID" to be consistent with the request through the JSON path query. The status code is consistent with expectations, and the verification result is output.

[0057] This application embodiment loads target interface test case data through a test execution engine, parses variable references to obtain real-time parameter values, constructs an HTTP / HTTPS request conforming to the interface specification, and sends it to the target interface server address. By capturing the response data returned by the target interface, the actual response is compared with the expected response rules defined in the target interface test case data. It checks whether the status code meets expectations or uses JSON path or XPath query language to verify whether the values ​​of specific fields in the response body meet assertion conditions, and outputs the verification results. In this way, the real-time adaptability of test cases to dynamic data is improved, the accuracy and automation of interface verification are enhanced, the coherence and maintainability of the test process are strengthened, the robustness and reusability of test cases are improved, the complexity of verification execution is reduced, and the efficiency of test feedback is improved.

[0058] According to the technical solution provided in this disclosure, a scenario parser performs clustering based on preset sorting conditions to obtain an ordered interface call chain containing request and response data. A lineage analysis engine performs full-field value matching on the request and response data within the ordered interface call chain to establish dependency edges and generate a data dependency graph. Parameterized processing traverses the data dependency graph, replacing hard-coded values ​​in the request data with variable expressions pointing to upstream data sources. Remaining fields can be retained or generalized according to preset templates, outputting target interface test case data. A test execution engine loads this target interface test case data, parses and replaces variable references in real time, constructs a compliant HTTP / HTTPS request, sends it to the target interface, captures the returned status code, response header, and response body, compares it with expected rules, and outputs the verification result. This improves the automation level of interface testing, enhances the fit between test case data and real business scenarios, strengthens the accuracy, consistency, and maintainability of verification, improves the accuracy and efficiency of interface verification, increases the efficiency of interface test case implementation, reduces maintenance difficulty, and enhances the reusability of interface test case data.

[0059] In some embodiments, performing full-field value matching on response data and request data to obtain a data dependency graph includes: performing full-field value extraction on response data to obtain an upstream value set; performing full-field parameter extraction on request data to obtain a downstream parameter set; performing precise value matching on the upstream value set and downstream parameter set to obtain a field lineage mapping table; and constructing a data dependency graph based on the field lineage mapping table.

[0060] Specifically, the full field value extraction and full field parameter extraction processes can include all leaf node values ​​or parameters in structured data formats such as JSON and Extensible Markup Language (XML), without selective ignoring them, to ensure the comprehensiveness of dependency identification.

[0061] In addition, exact value matching can be a complete equivalence comparison of strings or numbers. Strong constraints can be set for value equality. In this way, the mapping relationship from the specific value of the response field to the same or different field parameters in subsequent requests can be found and established in the recorded interface traffic sequence. Based on the result of exact value matching, a field lineage mapping table is generated.

[0062] A field lineage mapping table can be a structured record table. It can be used to record each successfully matched pair of data relationships, including the upstream interface identifier, upstream field path, specific upstream value, downstream interface identifier, downstream field path, and specific downstream parameter value. This provides accurate mapping relationship data for subsequent graph construction. The field lineage mapping table can be obtained by structured recording of each successfully matched pair of upstream values ​​and downstream parameters.

[0063] Furthermore, the exact value matching process can be implemented through hash table lookup. All values ​​in the upstream value set can be used as keys to build a hash table. Each parameter value in the downstream parameter set can be traversed and searched in the hash table. If the exact same value is found, it can be considered that there is a potential lineage relationship, which needs to be recorded.

[0064] In addition, the process of constructing a data dependency graph can include creating graph nodes, each of which can correspond to an interface step in the scene sequence; creating directed edges based on a field lineage mapping table, with the direction of the edges pointing from the interface node that serves as the data source to the interface node that consumes the data; and attaching attribute information to each edge, including the specific field names passed and variable reference expressions used for parameterized replacement.

[0065] For example, in the JSON response of the login interface recorded by the online mall, the value of "User ID" can be U12345 and the value of "Term" can be T67890. In the JSON response of the product details query interface, the value of "Product ID" can be G001. In the JSON request body of the order creation interface, the value of "Buyer ID" can be U12345 and the value of "Product ID" can be G001. The value of "Authorization" in the request header can be Bearer T67890. All fields of the responses can be extracted to form an upstream value set, and all fields of the requests can be extracted to form a downstream parameter set. A hash table query can be used to compare each downstream value with the upstream value one by one to obtain three pairs of completely equal relationships and write them into the field lineage mapping table. Then, two directed edges from the login node to the order creation node and one directed edge from the query node to the order creation node can be generated in the data dependency graph. The edge attributes carry field paths and variable reference expressions, thus completing the construction of the data dependency graph.

[0066] According to the technical solution provided in this disclosure, an upstream value set is obtained by extracting all field values ​​from the response data, and a downstream parameter set is obtained by extracting all field parameters from the request data. The upstream value set is used as the key to construct a hash table, and the downstream parameter set is traversed for precise value matching. Each successfully matched relationship is recorded in a field lineage mapping table. Graph nodes and directed edges are created based on the field lineage mapping table, and attribute information is attached to them to construct a data dependency graph. This improves the comprehensiveness and accuracy of dependency discovery, increases the efficiency of data dependency graph construction, and enhances the reliability of subsequent parameterization and verification.

[0067] In some embodiments, parameterizing request data based on an ordered interface call chain and a data dependency graph to obtain target interface use case data includes: performing variable path marking on the data dependency graph to obtain variable expressions; performing matching and replacement processing on the request data and variable expressions to obtain parameterized request data; and performing sequential encapsulation processing on the parameterized request data based on the ordered interface call chain to obtain target interface use case data.

[0068] Specifically, variable path tagging can be a data processing procedure that standardizes the representation of identified dependencies in a data dependency graph. This variable path tagging can generate a unique variable expression for each data dependency edge in the data dependency graph. This variable expression can be used to represent the specific dependency relationship identified in the data dependency graph. For example, a field value in the response body of interface A is used by the request parameter of interface B. Variable path tagging can also be used to transform implicit data dependencies into explicit string templates that can be understood and replaced by the script engine. For example, for a dependency from the `token` field in the response body of the "Login" interface to the `Authorization` field in the request header of the "Get Data" interface, the generated variable expression can be represented as `{{step_1.response.headers.Authorization}}`, where `step_1` can represent the step number of the "Login" interface in an ordered interface call chain.

[0069] Furthermore, the generation of variable expressions can follow predefined template rules, which may include interface step indexes, data source types (request or response), data hierarchy, and specific field paths, thereby ensuring the accuracy and unambiguity of variable references.

[0070] In addition, the request data and variable expressions are matched and replaced to obtain parameterized request data. The matching and replacement process can be a data processing procedure that replaces the specific hard-coded values ​​corresponding to the variable expressions in the original request data with the data processing procedures of the variable expressions. The parameterized request data can be an interface request description in which some or all of the specific values ​​have been replaced by the variable expressions. This matching and replacement process can be used to decouple test data from test logic, replacing specific test data used in a recording (such as user ID "U123") with dynamic references to the output of the upstream interface (such as `{{step_0.response.body.userId}}`).

[0071] Furthermore, the matching and replacement process can traverse each interface request in the ordered interface call chain. Based on the data dependency graph and the generated variable expressions, it can search and replace within the URL parameters, request headers, or request body of the request. For example, in the request body of the "Add to Cart" interface, if the value of the field `specId` is found to be "S1001", the data dependency graph shows that this value originates from the response of the "Product Details" interface, and the corresponding variable expression can be `{{step_2.response.body.specId}}`. Therefore, "S1001" can be replaced with this variable expression.

[0072] Furthermore, parameterized request data is sequentially encapsulated based on an ordered interface call chain to obtain target interface test case data. The sequential encapsulation process can be based on the order defined by the ordered interface call chain. It can combine a series of parameterized request data and their associated expected response verification points, variable extraction rules, etc., into a complete test case data processing process. The sequential encapsulation process can be used to maintain the integrity of the business process and generate structured, executable test assets.

[0073] Furthermore, the encapsulation process not only includes the request sequence, but can also attach basic assertion rules to each request step based on the response data at the time of recording, such as verifying status codes, or extracting variables from the response for use in subsequent steps.

[0074] For example, the "Specification Number" value in the response body of the "Product Details" interface recorded by the online mall can be S1001, and the same field in the subsequent "Add to Cart" interface request body is also hardcoded as S1001. Variable path marking processing can be performed on the data dependency graph to generate a unique variable expression "{{Step 2.response.body.specId}}". The "Add to Cart" request can be traversed, the hardcoded value can be found in the request body and replaced with the variable expression. Then, the three parameterized requests of login, product details, and add to cart can be encapsulated based on the ordered interface call chain, with the addition of status code assertions and variable extraction rules, to obtain the target interface use case data.

[0075] According to the technical solution provided in this disclosure, variable expressions are obtained by performing variable path marking on the data dependency graph. The request data and variable expressions are then matched and replaced to replace the original hard-coded values ​​with variable expressions, thereby obtaining parameterized request data. The parameterized request data is then sequentially encapsulated based on the ordered interface call chain. The expected response verification points and variable extraction rules are then merged to obtain target interface test case data. This improves the decoupling degree between test data and logic, enhances the reusability of test cases in multiple environments, and strengthens the structure and maintainability of test assets.

[0076] In some embodiments, the traffic data to be processed includes a timestamp field, a Uniform Resource Identifier (URI) field, and a business identifier field. Clustering the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain includes: sorting the traffic data to be processed in ascending order based on the timestamp field to obtain a time-series request-response set; performing same-origin aggregation on the time-series request-response set based on the URI field to obtain an interface call group; and clustering the interface call group based on the business identifier field to obtain an ordered interface call chain.

[0077] Specifically, the traffic data to be processed can be raw interface call records captured and structured by a traffic recording proxy. This data can be used to represent a collection of network requests and responses that record the interaction process between the client and server. The timestamp field records the time point of each request or response, the Uniform Resource Identifier (URI) field identifies the target resource path accessed by the interface, and the business identifier field associates different interface calls within the same business process. The timestamp field can be time information obtained and recorded by the traffic recording proxy from the protocol header or system clock of the network data packets during capture. The URI field can be the Uniform Resource Identifier (URI) resource path extracted from the HTTP or HTTPS request line by the traffic recording proxy. The business identifier field can be a session identifier injected by the proxy during traffic recording, or generated in the post-processing stage by analyzing specific business parameters (such as user ID, order number, etc.) in the request header, request body, or response body and associating them.

[0078] Furthermore, the traffic data to be processed is sorted in ascending order based on the timestamp field to obtain a time-series request-response set. The ascending order sorting process can refer to arranging the data records in order from earliest to latest according to the timestamp. The ascending order sorting process can be used to restore the natural timeline of the user's interface requests during the operation process, ensuring that the logical order of subsequent analysis is consistent with the user's actual operation process, and avoiding business scenario confusion caused by out-of-order request records. The time-series request-response set can be a list of request-response pairs arranged in chronological order of occurrence.

[0079] Furthermore, the ascending sorting process can be specifically achieved by parsing the timestamp field in each traffic data entry and sorting all records based on a sorting algorithm (such as quicksort or mergesort) to obtain an ordered list.

[0080] In addition, the time-series request-response set is subjected to same-origin aggregation processing based on the Uniform Resource Identifier field to obtain interface call groups. Same-origin aggregation processing can refer to grouping request-response pairs that point to the same resource path or the same interface together. Same-origin aggregation processing can be used to initially filter out multiple calls to the same interface. Interface call groups can be a collection of all request-response pairs that share the same URI (or are considered to be the same interface after normalization processing). Each interface call group can be used to represent a series of call records to a specific functional interface.

[0081] In addition, the interface call groups are clustered based on the business identifier field to obtain an ordered interface call chain. This clustering process can recombine call groups from different interfaces into larger sequence units based on business logic correlation according to the business identifier. Clustering can be used to aggregate physically dispersed multiple calls to different interfaces into a logically continuous complete business process according to their inherent business affiliation.

[0082] Furthermore, clustering can traverse all interface call groups, check the value of the business identifier field of the records in each group, extract the call records with the same business identifier value, and reorganize them into a coherent call sequence based on the original time order in the time sequence request and response set, thus obtaining an ordered interface call chain representing a single business scenario.

[0083] For example, a traffic recording proxy can treat the entire process of a user's "login, product search, and order placement" as traffic data to be processed. This traffic data can include timestamp fields, Uniform Resource Identifier fields, and injected session-level business identifier fields. It can sort the data in ascending order from earliest to latest based on the timestamp fields, restore the real operation timeline, and obtain a time-series request-response set. Paths pointing to the same URI can be grouped together to form three interface call groups: login, product search, and order placement. Then, based on the same business identifier field, the above three groups of records can be regrouped and linked together according to the original time order to generate an ordered interface call chain.

[0084] According to the technical solution provided in this disclosure, the traffic data to be processed is sorted in ascending order based on the timestamp field to obtain a time-series request-response set. The set is then aggregated based on the same source based on the Uniform Resource Identifier field to obtain an interface call group. The interface call group is then clustered based on the business identifier field. Finally, the ordered interface call chain is reorganized according to the original time order. This improves the accuracy of business scenario reconstruction, increases clustering efficiency, enhances the fit between interface use cases and real operation processes, improves the accuracy and efficiency of lineage analysis, and avoids scenario fragmentation or association errors caused by improper data preprocessing.

[0085] In some embodiments, verifying a target interface based on target interface use case data includes: performing assertion feature extraction processing on the target interface use case data to obtain baseline verification conditions; performing environment variable injection processing on the target interface use case data to obtain environment adaptation request data; performing replay processing on the environment adaptation request data to obtain real-time response data; and performing consistency verification processing on the baseline verification conditions and real-time response data to obtain interface verification results.

[0086] Specifically, assertion feature extraction can be a data processing process that parses and extracts a set of rules or conditions from the target interface use case data, which can be used to determine whether the interface response meets expectations. This assertion feature extraction process can be used to generate benchmark verification conditions.

[0087] In addition, environment variable injection can be a data processing procedure that dynamically replaces the configuration parameters of a specific runtime environment (such as a test environment or a pre-release environment) with the corresponding variable placeholders in the interface test case data. This environment variable injection can be used to ensure that test case data is adapted to different deployment environments.

[0088] Furthermore, the environment adaptation request data can be interface request data that has completed environment variable replacement and includes runtime parameters such as the actual target server address, port, and authentication information. This environment adaptation request data can be an instantiation of the target interface use case data in a specific environment, thereby providing a data payload for the next step of initiating a request to the real service.

[0089] In addition, replay processing can adapt the constructed environment to request data and, according to its defined protocol, format and order, initiate an actual network call to the target service interface. This can simulate the original user operation or business process to trigger the service's real processing logic.

[0090] Furthermore, real-time response data can be the actual response content returned by the target service interface after processing the replay request. This can include status codes, response headers, and response bodies. This real-time response data can be the actual output of the service to a specific input in the current state, which can be compared with the pre-set expected results to verify the correctness of the service behavior.

[0091] For example, in an online marketplace testing environment, assertion feature extraction can be performed on the target interface test case data. Rules such as the status code should be 200 in the "Create Order" step and the "Order Status" field in the response body should be "Created" can be extracted as baseline verification conditions. Then, environment variable injection can be used to replace the placeholder "{{host}}" with the current test environment domain name and set the port variable to 8080 to obtain environment-adapted request data. This environment-adapted request data can be replayed to initiate an HTTP call to the real service to obtain real-time response data containing status code 200 and "Order Status: Created". The baseline verification conditions and real-time response data can be checked for consistency. If all assertions pass, the interface verification result is output as successful.

[0092] According to the technical solution provided in this disclosure, benchmark verification conditions are obtained by extracting assertion features from the target interface test case data, environment variable injection is performed on the target interface test case data to obtain environment adaptation request data, replay processing is performed on the environment adaptation request data to obtain real-time response data, and consistency verification processing is performed on the benchmark verification conditions and real-time response data to output the interface verification result. In this way, the efficiency of multi-environment adaptation is improved, the verification accuracy is increased, the robustness and maintainability of automated testing are enhanced, the integrity, accuracy and efficiency of the verification process are ensured, and the reliability and execution efficiency of interface testing are improved.

[0093] In some embodiments, the consistency verification process of the benchmark verification conditions and the real-time response data is performed to obtain the interface verification result, including: performing status code extraction processing on the real-time response data to obtain the real-time status result; performing expected status extraction processing on the benchmark verification conditions to obtain the expected status result; and performing equivalence judgment processing on the real-time status result and the expected status result to obtain the interface verification result.

[0094] Specifically, status code extraction processing can be a data processing procedure that locates and reads status identifiers that can represent the result of the current request processing from structured interface response data. In this way, the status information of the interface response can be obtained. Status code extraction processing can obtain specific status values ​​by parsing fixed fields (such as HTTP status code fields) in the response header of real-time response data, and obtain the real-time status result. The real-time status result can be a status identifier that represents the result of the current request processing of the interface, which can be extracted from the real-time response data and used as a representative of the actual status for comparison with the expected status.

[0095] In addition, the expected state extraction process can be a data processing procedure that parses the rules or data contained in the benchmark verification conditions to obtain the expected state identifier that the interface response should return. This process can be used to clarify the expected target of the verification. Specifically, it can be based on the benchmark verification conditions containing status code verification rules, and extract the preset status code value by parsing the condition rules to obtain the expected state result. The expected state result can be the status identifier that the interface response should satisfy, which is extracted from the benchmark verification conditions. This expected state result can be obtained by performing expected state extraction processing on the benchmark verification conditions.

[0096] In addition, the equivalence judgment process can be a data processing procedure that logically compares the real-time state result and the expected state result to determine whether they are completely identical; in this way, a conclusion can be drawn as to whether the interface response meets the expectations at the state level; the equivalence judgment process can receive the real-time state result and the expected state result as input, and make a judgment through numerical or string matching logic to obtain the interface verification result.

[0097] For example, in an online marketplace testing environment, the status code can be extracted from the real-time response data returned by the order creation interface, and 200 can be read from the response header as the real-time status result; the expected status can be extracted from the baseline verification conditions, and the 200 preset in the rule can be parsed to obtain the expected status result; then the real-time status result and the expected status result can be compared for equivalence, and if the two are completely consistent, the interface verification result is determined to be passed.

[0098] According to the technical solution provided in this disclosure, real-time status results are obtained by extracting status codes from real-time response data, and expected status results are obtained by extracting expected status from benchmark verification conditions. The real-time status results and expected status results are then compared and processed to output the interface verification results. This improves the automation level of status verification, enhances verification efficiency and accuracy, strengthens the reliability of test results, improves the automation level of the interface status verification process, and improves the efficiency and consistency of interface testing.

[0099] In some embodiments, after verifying the target interface based on the target interface use case data, the method further includes: obtaining historical test execution results; performing regression testing on the target interface use case data to obtain real-time test execution results; performing difference comparison processing on the historical test execution results and the real-time test execution results to obtain change impact data; and performing incremental update processing on the data dependency graph based on the change impact data to obtain target interface use case update data.

[0100] Specifically, historical test execution results can be a collection of test results recorded after executing the same or similar test scenarios in a historical test cycle. The form of these historical test execution results can be structured data stored in the test script repository, associated with a specific test script, and containing information such as interface request and response status, time consumption, and assertion results. These historical test execution results can be used to identify the changes that have occurred in the current test execution relative to the previous execution. These historical test execution results can also be detailed execution logs generated and returned by the test execution tool (such as product A) after extracting past parameterized test scripts from the test script repository.

[0101] In addition, regression testing is performed on the target interface test case data to obtain real-time test execution results. Regression testing can be a data processing process that re-executes the complete test process in a specified test environment using the target interface test case data that has been generated or updated (i.e., parameterized test scripts). This can be used to verify whether the target interface's functionality meets expectations after code or configuration changes, and to generate real-time test results that represent the current system state. The real-time test execution results can be test result records that represent the current actual behavior of the interface, obtained by executing this regression test. These real-time test execution results can serve as current samples for comparison with historical results to identify changes in system behavior.

[0102] In addition, the historical test execution results and real-time test execution results are compared to obtain change impact data. The difference comparison process can be an algorithm or data processing logic process that calculates and identifies the differences between two datasets. By comparing the execution results of the same test cases at different time points, inconsistencies in status, response content, or performance indicators can be identified. The change impact data can be a structured set of information extracted through the difference comparison process that can be used to describe test cases, interface parameters, or business assertions that have changed due to system changes. For example, it can identify a list of test cases that changed from "pass" to "fail", or fields added or deleted in the response body.

[0103] Furthermore, based on the change impact data, the data dependency graph is incrementally updated to obtain the target interface test case update data. The incremental update process can be a data processing procedure that modifies the attributes or relationships of affected nodes and edges in the data dependency graph according to the local changes indicated by the change impact data. The target interface test case update data can be a parameterized test script that is regenerated or partially modified by the parameterization generator after the data dependency graph is incrementally updated and synchronized with the real-time system state.

[0104] For example, if all the previously recorded "order placement" scripts passed the test of the inventory system, the historical test execution results can be read and compared with the current real-time test execution results to determine that the "pre-deducted inventory" interface has changed from a passed state to a failed state, and the response body lacks an available inventory field. Then, the data affecting this change can be written back to the data dependency graph, the relevant nodes and edges can be updated incrementally, and new target interface use cases can be generated to update the data.

[0105] According to the technical solution provided in this disclosure, by obtaining historical test execution results, regression testing is performed on the target interface test case data to obtain real-time test execution results. The difference between the historical test execution results and the real-time test execution results is compared and processed to extract change impact data. Based on the change impact data, incremental update processing is performed on the data dependency graph to output target interface test case update data. In this way, the synchronization speed of test assets and system evolution is improved, the accuracy of change risk identification is improved, and the automation and maintainability of regression testing are enhanced.

[0106] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0107] Figure 3 This is a schematic diagram of another interface use case data processing method provided in an embodiment of this disclosure. For example... Figure 3 As shown, the data processing method for this interface use case includes: Recording Proxy: Acts as a man-in-the-middle proxy or browser plugin, capturing all HTTP / HTTPS requests and responses between the client and server and recording them in a structured manner (traffic data to be processed).

[0108] Scenario Parser: Cleans and preprocesses the recorded raw traffic, and combines discrete request / response pairs into "scenario sequences" (ordered API call chains) with business meaning based on rules such as timestamps and URL relevance.

[0109] Lineage Engine: Receives scene sequences and constructs a data dependency graph (DAG) between interfaces through feature extraction and lineage matching algorithms (exact value matching).

[0110] The Parameterization Generator generates parameterized test scripts by replacing hard-coded values ​​in the scene sequence with variable references (such as {{step_0.response.body.token}}) based on the data dependency graph.

[0111] Playbook Repository: Stores and manages generated parameterized test playbooks (target interface use case data) and integrates with test execution tools.

[0112] The specific steps for processing the test case data for this interface are as follows: Start Recording: When the user clicks "Start Recording" in the system, the traffic recording agent begins monitoring network traffic after user authorization.

[0113] Perform business operations: Users perform normal operations on the front-end interface, such as completing a complete process of "login, view profile, change nickname, and log out".

[0114] Capture and Parse: The agent captures all API requests and responses generated in this process and hands them over to the scene parser to organize them into an ordered scene sequence.

[0115] Triggered analysis: The user clicks "Stop recording and generate test cases". The scenario sequence is sent to the lineage analysis engine.

[0116] Lineage identification: The engine executes a lineage matching algorithm to identify tokens and userIds, such as those in the login interface response, which are then used in requests to obtain profile information (getProfile) and update nickname (updateNickname), respectively.

[0117] Generate parameterized scripts: Based on the recognition results, the parameterization generator replaces the hard-coded userId in the getProfile request with a reference to the login interface response, and replaces the Authorization header with a reference to the token.

[0118] Storage and Usage: The generated, fully parameterized test scripts are stored in a repository, which users can open and execute in the test execution tool.

[0119] According to the technical solution provided in the embodiments of this disclosure, the algorithm automatically discovers and constructs a dynamic data dependency graph between interfaces; it fully automates and backends the complex parameterization process, generating reusable test cases; and it supports merging changes by comparing the lineage graphs and structures of new and old scripts, thereby reducing maintenance costs.

[0120] The following are embodiments of the apparatus disclosed herein, which can be used to execute embodiments of the method disclosed herein. For details not disclosed in the apparatus embodiments of this disclosure, please refer to the embodiments of the method disclosed herein.

[0121] Figure 4 This is a schematic diagram of an interface use case data processing device provided in an embodiment of this disclosure. Figure 4 As shown, the interface use case data processing device includes: The first processing module 401 is used to perform clustering processing on the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data. The second processing module 402 is used to perform full field value matching processing on the response data and the request data to obtain a data dependency graph; The third processing module 403 is used to perform parameterization processing on the request data based on the ordered interface call chain and data dependency graph to obtain target interface use case data. The fourth processing module 404 is used to verify the target interface based on the target interface use case data.

[0122] According to the technical solution provided in this disclosure, a scenario parser performs clustering based on preset sorting conditions to obtain an ordered interface call chain containing request and response data. A lineage analysis engine performs full-field value matching on the request and response data within the ordered interface call chain to establish dependency edges and generate a data dependency graph. Parameterized processing traverses the data dependency graph, replacing hard-coded values ​​in the request data with variable expressions pointing to upstream data sources. Remaining fields can be retained or generalized according to preset templates, outputting target interface test case data. A test execution engine loads this target interface test case data, parses and replaces variable references in real time, constructs a compliant HTTP / HTTPS request, sends it to the target interface, captures the returned status code, response header, and response body, compares it with expected rules, and outputs the verification result. This improves the automation level of interface testing, enhances the fit between test case data and real business scenarios, strengthens the accuracy, consistency, and maintainability of verification, improves the accuracy and efficiency of interface verification, increases the efficiency of interface test case implementation, reduces maintenance difficulty, and enhances the reusability of interface test case data.

[0123] In some embodiments, the second processing module 402 is specifically used to: perform full field value extraction processing on the response data to obtain an upstream value set; perform full field parameter extraction processing on the request data to obtain a downstream parameter set; perform precise value matching processing on the upstream value set and the downstream parameter set to obtain a field lineage mapping table; and construct a data dependency graph based on the field lineage mapping table.

[0124] In some embodiments, the third processing module 403 is specifically used to: perform variable path marking processing on the data dependency graph to obtain variable expressions; perform matching and replacement processing on the request data and variable expressions to obtain parameterized request data; and perform sequential encapsulation processing on the parameterized request data based on the ordered interface call chain to obtain target interface use case data.

[0125] In some embodiments, the first processing module 401 is specifically used to: sort the traffic data to be processed in ascending order based on the timestamp field to obtain a time-series request-response set; perform homogeneous aggregation processing on the time-series request-response set based on the Uniform Resource Identifier field to obtain an interface call group; and perform clustering processing on the interface call group based on the business identifier field to obtain an ordered interface call chain.

[0126] In some embodiments, the fourth processing module 404 is specifically used to: perform assertion feature extraction processing on the target interface use case data to obtain benchmark verification conditions; perform environment variable injection processing on the target interface use case data to obtain environment adaptation request data; perform replay processing on the environment adaptation request data to obtain real-time response data; and perform consistency verification processing on the benchmark verification conditions and real-time response data to obtain interface verification results.

[0127] In some embodiments, the process of performing consistency verification on the benchmark verification conditions and real-time response data to obtain the interface verification result is specifically used as follows: performing status code extraction processing on the real-time response data to obtain the real-time status result; performing expected status extraction processing on the benchmark verification conditions to obtain the expected status result; and performing equivalence judgment processing on the real-time status result and the expected status result to obtain the interface verification result.

[0128] In some embodiments, the interface use case data processing device is further configured to: obtain historical test execution results; perform regression testing on the target interface use case data to obtain real-time test execution results; perform difference comparison processing on the historical test execution results and the real-time test execution results to obtain change impact data; and perform incremental update processing on the data dependency graph based on the change impact data to obtain target interface use case update data.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0130] Figure 5 This is a schematic diagram of the electronic device 5 provided in an embodiment of this disclosure. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, it implements the steps in the various method embodiments described above. Alternatively, when the processor 501 executes the computer program 503, it implements the functions of each module / unit in the various device embodiments described above.

[0131] Electronic device 5 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 5 may include, but is not limited to, processor 501 and memory 502. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or different components.

[0132] The processor 501 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0133] The memory 502 can be an internal storage unit of the electronic device 5, such as a hard disk or RAM of the electronic device 5. The memory 502 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 5. The memory 502 can also include both internal and external storage units of the electronic device 5. The memory 502 is used to store computer programs and other programs and data required by the electronic device.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0135] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0136] The above embodiments are only used to illustrate the technical solutions of this disclosure, and are not intended to limit it. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be included within the protection scope of this disclosure.

Claims

1. A method for processing interface use case data, characterized in that, include: Clustering is performed on the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data. Perform full-field value matching on the response data and the request data to obtain a data dependency graph; Based on the ordered interface call chain and the data dependency graph, the request data is parameterized to obtain target interface use case data; Verify the target interface based on the target interface use case data.

2. The interface use case data processing method according to claim 1, characterized in that, The step of performing full-field value matching on the response data and the request data to obtain a data dependency graph includes: The response data is processed by extracting all field values ​​to obtain the upstream value set; The request data is processed by extracting all fields of parameters to obtain a set of downstream parameters; The upstream value set and the downstream parameter set are subjected to precise value matching to obtain a field lineage mapping table; The data dependency graph is constructed based on the aforementioned lineage mapping table.

3. The interface use case data processing method according to claim 1, characterized in that, The parameterization of the request data based on the ordered interface call chain and the data dependency graph to obtain target interface use case data includes: The data dependency graph is processed by variable path labeling to obtain variable expressions; The request data and the variable expression are matched and replaced to obtain parameterized request data; Based on the ordered interface call chain, the parameterized request data is sequentially encapsulated to obtain the target interface use case data.

4. The interface use case data processing method according to claim 1, characterized in that, The traffic data to be processed includes a timestamp field, a Uniform Resource Identifier field, and a service identifier field; The clustering process based on preset sorting conditions to obtain an ordered interface call chain includes: The traffic data to be processed is sorted in ascending order based on the timestamp field to obtain a time-series request-response set. Based on the Uniform Resource Identifier field, the time-series request-response set is subjected to same-origin aggregation processing to obtain the interface call group; The interface call group is clustered based on the business identifier field to obtain the ordered interface call chain.

5. The interface use case data processing method according to claim 1, characterized in that, The verification of the target interface based on the target interface use case data includes: Assertion feature extraction processing is performed on the target interface use case data to obtain the benchmark verification conditions; The target interface use case data is processed by environment variable injection to obtain environment adaptation request data; The environment adaptation request data is replayed to obtain real-time response data; The benchmark verification conditions and the real-time response data are subjected to consistency verification processing to obtain the interface verification result.

6. The interface use case data processing method according to claim 5, characterized in that, The step of performing consistency verification processing on the benchmark verification conditions and the real-time response data to obtain the interface verification result includes: The real-time response data is processed by extracting status codes to obtain real-time status results; The expected state extraction process is performed on the benchmark verification conditions to obtain the expected state result; The real-time status result and the expected status result are compared and treated equally to obtain the interface verification result.

7. The interface use case data processing method according to claim 1, characterized in that, After verifying the target interface based on the target interface use case data, the process further includes: Retrieve historical test execution results; Regression testing is performed on the target interface test case data to obtain real-time test execution results; The historical test execution results and the real-time test execution results are compared to obtain the change impact data. Based on the change impact data, the data dependency graph is incrementally updated to obtain the target interface use case update data.

8. An interface use case data processing device, characterized in that, include: The first processing module is used to perform clustering processing on the traffic data to be processed based on preset sorting conditions to obtain an ordered interface call chain, wherein the ordered interface call chain includes response data and request data. The second processing module is used to perform full field value matching processing on the response data and the request data to obtain a data dependency graph. The third processing module is used to perform parameterization processing on the request data based on the ordered interface call chain and the data dependency graph to obtain target interface use case data. The fourth processing module is used to verify the target interface based on the target interface use case data.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images