Interface offline comparison test method and device, equipment and storage medium

Abstract

The invention belongs to the technical field of smart home / smart home, and particularly relates to an interface offline comparison test method and device, equipment and a storage medium, and the method comprises the steps: receiving production record data, the production record data comprises a first request processed by an actual interface in the production environment, a corresponding first actual return value and a second actual return value returned by an external interface called by the actual interface; reading a first request from the production record data, and calling a corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates a corresponding first test return value, or generates a corresponding first test return value based on a second actual return value corresponding to an external interface needing to be called; and comparing the first actual return value with the first test return value to determine whether the test interface is abnormal or not. According to the method, various business scenes can be comprehensively covered, and meanwhile, the offline execution mode avoids the influence on the performance of a production system.

Description

Technical Field

[0001] This application belongs to the field of smart home / intelligent home technology, specifically relating to an interface offline comparison test method, device, equipment and storage medium. Background Technology

[0002] As enterprises accelerate their digital transformation, the complexity and volume of system functions are growing exponentially, especially with increasingly frequent demands for the reconstruction of core business interfaces (such as home appliance control interfaces, payment interfaces, and data aggregation interfaces). For example, in the field of home appliance control, the same interface may need to be adapted to dozens of equipment models, such as refrigerators, air conditioners, and water heaters, and must be compatible with the differentiated needs of new and discontinued models.

[0003] When system architecture is upgraded or code logic is refactored, the development team needs to ensure that the new and old interfaces are fully aligned in terms of functional consistency, data processing logic, and external system interaction. However, traditional testing methods have many problems: first, test data preparation is costly, requiring coverage of a massive number of device models and complex scenarios; second, the testing cycle is long, requiring the quality department to repeatedly verify tens of thousands of test cases; and third, testing risks are high, as insufficient testing may lead to production environment failures.

[0004] In this scenario, there is an urgent need for a testing method that can efficiently cover real business scenarios without relying on additional resource investment, so as to ensure the stability of system reconstruction. Summary of the Invention

[0005] To address the above issues, this application provides an offline interface comparison testing method, including:

[0006] Receive production record data, wherein the production record data includes: a first request processed by the actual interface in the production environment, a corresponding first actual return value, and a second actual return value returned by the external interface called by the actual interface;

[0007] Read the first request from the production record data, and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value of the external interface to be called;

[0008] The first actual return value and the first test return value are compared to determine whether the test interface has any abnormalities.

[0009] In one possible implementation, after invoking the corresponding test interface in the acceptance environment according to the first request, the method further includes:

[0010] During the process of the test interface processing the first request, the target operation of the test interface calling the external interface is intercepted.

[0011] Based on the production record data, determine the second actual return value returned by the external interface based on the first request, and simulate the second actual return value as the second test return value returned by the external interface in the acceptance environment;

[0012] Obtain the first test return value generated by the test interface based on the second test return value.

[0013] In one possible implementation, the production record data further includes: scenario information corresponding to the first request, and at least one exception return value returned by the external interface based on the first request;

[0014] The method further includes:

[0015] Based on the scenario information corresponding to the first request and the preset triggering rules, it is determined whether the first request belongs to the target request. The triggering rules are used to indicate the correspondence between the scenario information and the target request.

[0016] If so, then based on at least one abnormal return value returned by the external interface in the production environment, perform abnormal response testing on the test interface;

[0017] If not, then no exception response test will be performed on the test interface.

[0018] In one possible implementation, the production record data further includes: a third actual return value generated by the actual interface based on each exception return value;

[0019] The abnormal response test of the test interface based on at least one abnormal return value returned by the external interface in the production environment includes:

[0020] Based on a preset mapping relationship, the target abnormal return value corresponding to the scene information is determined, and the mapping relationship is used to indicate the correspondence between the scene information and the target abnormal return value;

[0021] Call the test interface and intercept the target operation of the test interface calling the external interface; simulate the target exception return value as the test exception return value returned by the external interface in the acceptance environment;

[0022] Obtain the third test return value generated by the test interface based on the test exception return value;

[0023] The third actual return value and the third test return value are compared to determine whether the abnormal response test of the test interface is normal.

[0024] In one possible implementation, the production record data also includes actual processing information corresponding to the first request;

[0025] If the test interface is determined to be abnormal, the method further includes:

[0026] Obtain the test processing information of the test interface that processes the first request;

[0027] Based on the actual processing information and the test processing information, the root cause analysis results are determined;

[0028] Based on the results of the differential root cause analysis, corresponding remediation recommendations are determined;

[0029] Based on the root cause analysis results and the repair suggestions, a task work order is generated and sent to the operations team so that the operations team can repair the anomaly in the test interface.

[0030] In one possible implementation, after receiving the production record data, the method further includes:

[0031] Based on the production record data, an identifier corresponding to each set of target data is determined. The target data includes a first request, a first actual return value corresponding to the first request, and a second actual return value.

[0032] Each set of target data is categorized and stored in a preset data table structure, wherein the data table structure includes a request parameter table storing the first request and its corresponding identifier, a first return table storing the first actual return value and its corresponding identifier, and a second return table storing the second actual return value and its corresponding identifier.

[0033] Correspondingly, the first request and its corresponding identifier are read from the request parameter table, and the first actual return value is determined from the first return table based on the identifier, and the second actual return value is determined from the second return table.

[0034] In one possible implementation, before determining the target abnormal return value corresponding to the scene information according to a preset mapping relationship, the method further includes:

[0035] Extract complete link records from historical production record data. The complete link records include scenario information, at least one abnormal return value returned by the corresponding external interface, and a corresponding third actual return value generated by the actual interface.

[0036] Based on the complete link record, an associated knowledge base is established, which is used to indicate the relationship between scenario information, abnormal return values, and factors affecting the results.

[0037] Based on the associated knowledge base and the preset test coverage strategy, at least one target abnormal return value is determined for each scenario information; wherein, the test coverage strategy is used to indicate the coverage of abnormal return values ​​with high impact level and / or, abnormal return values ​​that occur frequently.

[0038] Secondly, this application provides an offline interface comparison testing device, the device comprising:

[0039] A receiving module is used to receive production record data, wherein the production record data includes: a first request processed by the actual interface in the production environment, a corresponding first actual return value, and a second actual return value returned by the external interface called by the actual interface;

[0040] The calling module is used to read the first request from the production record data and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value of the external interface to be called.

[0041] The comparison module is used to compare the first actual return value with the first test return value to determine whether the test interface has any abnormalities.

[0042] In one possible implementation, the calling module is specifically used for:

[0043] During the process of the test interface processing the first request, the target operation of the test interface calling the external interface is intercepted.

[0044] Based on the production record data, determine the second actual return value returned by the external interface based on the first request, and simulate the second actual return value as the second test return value returned by the external interface in the acceptance environment;

[0045] Obtain the first test return value generated by the test interface based on the second test return value.

[0046] In one possible implementation, the production record data further includes: scenario information corresponding to the first request, and at least one exception return value returned by the external interface based on the first request; the comparison module is further configured to:

[0047] Based on the scenario information corresponding to the first request and the preset triggering rules, it is determined whether the first request belongs to the target request. The triggering rules are used to indicate the correspondence between the scenario information and the target request.

[0048] If so, then based on at least one abnormal return value returned by the external interface in the production environment, perform abnormal response testing on the test interface;

[0049] If not, then no exception response test will be performed on the test interface.

[0050] In one possible implementation, the production record data further includes: a third actual return value generated by the actual interface based on each exception return value; the comparison module is specifically used for:

[0051] Based on a preset mapping relationship, the target abnormal return value corresponding to the scene information is determined, and the mapping relationship is used to indicate the correspondence between the scene information and the target abnormal return value;

[0052] Call the test interface and intercept the target operation of the test interface calling the external interface; simulate the target exception return value as the test exception return value returned by the external interface in the acceptance environment;

[0053] Obtain the third test return value generated by the test interface based on the test exception return value;

[0054] The third actual return value and the third test return value are compared to determine whether the abnormal response test of the test interface is normal.

[0055] In one possible implementation, the production record data further includes actual processing information corresponding to the first request; the comparison module is also used for:

[0056] Obtain the test processing information of the test interface that processes the first request;

[0057] Based on the actual processing information and the test processing information, the root cause analysis results are determined;

[0058] Based on the results of the differential root cause analysis, corresponding remediation recommendations are determined;

[0059] Based on the root cause analysis results and the repair suggestions, a task work order is generated and sent to the operations team so that the operations team can repair the anomaly in the test interface.

[0060] In one possible implementation, the receiving module is also used for:

[0061] Based on the production record data, an identifier corresponding to each set of target data is determined. The target data includes a first request, a first actual return value corresponding to the first request, and a second actual return value.

[0062] Each set of target data is categorized and stored in a preset data table structure, wherein the data table structure includes a request parameter table storing the first request and its corresponding identifier, a first return table storing the first actual return value and its corresponding identifier, and a second return table storing the second actual return value and its corresponding identifier.

[0063] Correspondingly, the first request and its corresponding identifier are read from the request parameter table, and the first actual return value is determined from the first return table based on the identifier, and the second actual return value is determined from the second return table.

[0064] In one possible implementation, the comparison module is also used for:

[0065] Extract complete link records from historical production record data. The complete link records include scenario information, at least one abnormal return value returned by the corresponding external interface, and a corresponding third actual return value generated by the actual interface.

[0066] Based on the complete link record, an associated knowledge base is established, which is used to indicate the relationship between scenario information, abnormal return values, and factors affecting the results.

[0067] Based on the associated knowledge base and the preset test coverage strategy, at least one target abnormal return value is determined for each scenario information; wherein, the test coverage strategy is used to indicate the coverage of abnormal return values ​​with high impact level and / or, abnormal return values ​​that occur frequently.

[0068] Thirdly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0069] Fourthly, this application provides an electronic device, comprising: at least one processor and a memory; wherein,

[0070] The memory stores computer-executed instructions;

[0071] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any of the first aspects.

[0072] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps of the method as described in any one of the first and / or second aspects.

[0073] The offline comparison testing method, apparatus, equipment, and storage medium provided in this application first receive production record data, then invoke the test interface by replaying the first request. During this process, a recorded second actual return value is used to simulate the external interface response. Finally, the first test return value generated by the test interface is compared with the first actual return value recorded online to determine whether the test interface has any anomalies. This method overcomes the shortcomings of traditional manual test cases, such as incomplete coverage and high resource consumption in online dual-run tests. By utilizing real online traffic as test data, it can comprehensively cover various business scenarios, while the offline execution method avoids impacting the performance of the production system. Using recorded external interface return values ​​for simulation effectively solves the uncertainty problem of external dependencies during the testing process, ensuring the accuracy and reliability of the test results. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 The flowchart of the interface offline comparison test method provided in the embodiments of this application Figure 1 ;

[0076] Figure 2 The flowchart of the interface offline comparison test method provided in the embodiments of this application Figure 2 ;

[0077] Figure 3 This is an offline comparison test diagram of the interface provided in an embodiment of the present invention;

[0078] Figure 4 This is a hardware schematic diagram of an electronic device provided in an embodiment of the present invention.

[0079] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0081] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented, for example, in orders other than those illustrated or described herein.

[0082] In this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0083] The existing technologies mainly employ two interface testing methods: traditional manual testing and online dual-run testing.

[0084] Traditional manual testing involves the development team manually constructing test cases and preparing test data based on requirements documents and historical data. Testers then use automated scripts or testing tools to call APIs and verify whether the returned results meet expectations. The drawbacks of this method are: incomplete test case coverage, making it difficult to simulate real-world online request scenarios (such as device model, network environment, concurrent calls, etc.); test data quality relies heavily on human experience, with significant gaps in information for new device models or edge scenarios; and the testing cycle is long, requiring the quality department to invest substantial resources in data preparation and result verification.

[0085] Online dual-run test: While retaining the old interface logic, deploy the new interface and call it asynchronously. Verify consistency by comparing the return results of the old and new interfaces. Although this method can simulate real online requests, it has the following problems: high system resource consumption, with the doubling of call volume leading to increased server load and response latency; high data storage costs, requiring long-term storage of massive request and response data; complex maintenance, with coexistence of old and new code easily causing version conflicts and maintenance difficulties; and inability to handle external interface dependencies, as the dual-run test cannot simulate real external interface responses when the interface needs to call third-party services.

[0086] To address the aforementioned technical issues, this application provides an offline comparison testing method for interfaces. First, production record data is received. The test interface is invoked by replaying the first request. During this process, the recorded second actual return value simulates the external interface response. Finally, the first test return value generated by the test interface is compared with the first actual return value recorded online to determine if the test interface has any anomalies. This method overcomes the shortcomings of traditional manual test cases, such as incomplete coverage and high resource consumption during online dual-run tests. By utilizing real online traffic as test data, it can comprehensively cover various business scenarios, while the offline execution method avoids impacting the performance of the production system. Using recorded external interface return values ​​for simulation effectively solves the uncertainty problem of external dependencies during the testing process, ensuring the accuracy and reliability of the test results.

[0087] According to one aspect of the embodiments of this application, an offline interface comparison testing method is provided. This offline interface comparison testing method can be widely applied to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and smart residential ecosystems. The source of the requests processed in the method of this application is not limited to smart air conditioners, smart range hoods, smart refrigerators, smart ovens, smart stoves, smart washing machines, smart water heaters, smart washing equipment, smart dishwashers, smart projectors, smart TVs, smart clothes racks, smart curtains, smart audio-visual equipment, smart sockets, smart speakers, smart speakers, smart fresh air systems, smart kitchen and bathroom equipment, smart bathroom fixtures, smart robotic vacuum cleaners, smart window cleaning robots, smart robotic mopping robots, smart air purifiers, smart steam ovens, smart microwave ovens, smart water heaters, smart air purifiers, smart water dispensers, smart door locks, etc.

[0088] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0089] The technical solutions of this application and how they solve the aforementioned technical problems are described in detail below with specific embodiments. These specific embodiments may exist independently or in combination with each other. Identical or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0090] This embodiment provides a method for offline comparison testing of interfaces. Figure 1 The flowchart of the interface offline comparison test method provided in the embodiments of this application Figure 1 The method includes:

[0091] S101, Receive production record data.

[0092] The production record data includes: the first request processed by the actual interface in the production environment, the corresponding first actual return value, and the second actual return value returned by the external interface called by the actual interface.

[0093] In this step, production record data refers to snapshot data from a single user request that has been fully recorded in the production environment. This includes, but is not limited to:

[0094] The first request: The raw request data sent by the user, including the interface path, parameters, header information, etc. This refers to any input event that triggers an actual interface to perform processing in the production environment. Examples include user requests, requests initiated by other business systems or third parties, requests triggered by scheduled tasks, requests from message queue consumers, and requests for internal service calls.

[0095] First actual return value: The final result data returned by the actual interface in the production environment after processing the first request.

[0096] The second actual return value: In the process of processing the first request in the production environment, if the actual interface needs to call other third-party services (external interfaces), then the actual return data obtained from these third-party services.

[0097] S102. Read the first request from the production record data, and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value of the external interface to be called.

[0098] It should be noted that the test interface refers to the interface code to be tested, deployed on the current processing server. This is typically a refactored, modified, or optimized version. The first test return value refers to the final return result generated by the test interface in the acceptance environment after processing the second actual return value obtained from the first request input, according to its own logic.

[0099] For example, after calling the corresponding test interface in the acceptance environment according to the first request, the process also includes:

[0100] During the process of the test interface processing the first request, intercept the target operation of the test interface calling the external interface;

[0101] Based on the production record data, determine the second actual return value returned by the external interface based on the first request, and simulate the second actual return value as the second test return value returned by the external interface in the acceptance environment;

[0102] Obtain the first test return value generated by the test interface based on the second test return value.

[0103] In this example, in the test application of the acceptance environment, a pointcut can be set on the underlying client method that calls the external interface using aspect-oriented programming. When the test interface executes this external call, the aspect intercepts it and, based on the unique serial number of the current request, queries the database for the corresponding second actual return value and returns it, thus simulating the external interface response. Alternatively, during code design, the external interface call can be abstracted into an interface, and its implementation can be managed through a dependency injection framework. In the acceptance environment, the testing framework uses a mock library to create mock implementations for these interfaces and dynamically returns the corresponding second actual return value from imported production data based on the context of the currently executing test case.

[0104] This example ensures a high degree of consistency between the test and production environments in handling external dependencies by precisely intercepting external interface calls and injecting historical real data. It effectively eliminates test interference caused by the uncertainty of external interface responses, allowing any differences in comparison results to be accurately attributed to changes in the test interface's own logic, thus improving the efficiency of problem localization and the reliability of test results.

[0105] S103. Compare the first actual return value with the first test return value to determine whether there is an anomaly in the test interface.

[0106] In this step, for example, the first actual return value and the first test return value can be deserialized into memory objects and traversed using a recursive algorithm with a depth-first approach. This compares data types, data values, array lengths and orders, nested object structures, etc., field by field to ensure complete consistency down to the leaf nodes. During the comparison, the complete field path is recorded. When any differences are found (such as missing fields, mismatched values, incompatible types, or changes in array element order), the difference details are immediately recorded, including the difference path, expected value, and actual value.

[0107] Alternatively, for scenarios where minor differences are permissible, a rule engine can be used for comparison. For example, dynamic fields (such as timestamps and random IDs) can be ignored; numeric fields can be allowed to fluctuate within a specified error range; only specific key business fields can be compared while ignoring auxiliary fields; and even custom functions can be called to determine whether two values ​​are logically equivalent. Comparisons are performed according to the rule set, and only those violating core rules are marked as failing.

[0108] For example, the production record data also includes information on the actual processing of the first request. If the test interface is determined to be abnormal, the method further includes:

[0109] Obtain test processing information for the first request handled by the test interface;

[0110] Based on the actual processing information and the test processing information, determine the root cause analysis results;

[0111] Based on the results of the differential root cause analysis, corresponding remediation recommendations were determined;

[0112] Based on the root cause analysis results and remediation suggestions, a task ticket is generated and sent to the operations team so that the operations team can fix the anomalies in the test interface.

[0113] In this example, actual processing information refers to the complete execution trajectory data generated when the actual interface processes the first request in the production environment. This includes, but is not limited to, detailed information constituting the complete request lifecycle, such as internal method call chains, key logic branch judgment results, database operation records, and cache access records. Test processing information refers to the corresponding execution trajectory data generated when the test interface processes the same first request in the acceptance environment. It has the same structure and dimensions as the actual processing information and is used for comparative analysis.

[0114] For example, diagnostic probes can be implanted at key execution nodes of the test interface (such as method entry points, external calls, database operations, and important conditional branches). These probes are identified by unique serial numbers and record process data such as method call stacks, parameter values, return results, and execution time in real time. When comparative testing finds inconsistencies, the root cause analysis engine is automatically triggered. This engine first performs time-series alignment and structured comparison between the test processing information and the actual processing information to identify differences in key logic branches, data operation sequences, or external dependency calls. Then, it combines change records from the code version management system and calls preset rule bases (such as business rule consistency checks) and algorithm models (such as call path similarity analysis) to accurately locate the root cause code segment causing the difference. Finally, based on the identified code segment and the type of difference, it matches the corresponding repair mode from the repair knowledge base (such as adding null pointer checks, adjusting conditional branches, and correcting transaction boundaries), automatically generates a detailed report containing specific code locations and modification suggestions, and automatically creates a task ticket through the integration interface with the project management system, pushing the analysis results, repair suggestions, and relevant code links to the corresponding development manager.

[0115] This example can quickly and accurately locate the root cause of interface anomalies, significantly shortening the troubleshooting time. At the same time, the intelligent analysis-based repair suggestions effectively improve the quality of code repair, forming a complete automated closed loop from problem discovery to task assignment.

[0116] For example, after receiving production record data sent by the production environment server, the process also includes:

[0117] Based on the production record data, determine the identifier corresponding to each set of target data. The target data includes the first request, the first actual return value corresponding to the first request, and the second actual return value.

[0118] Each set of target data is classified and stored in a preset data table structure, wherein the data table structure includes a request parameter table storing the first request and its corresponding identifier, a first return table storing the first actual return value and its corresponding identifier, and a second return table storing the second actual return value and its corresponding identifier.

[0119] Correspondingly, the first request and its corresponding identifier are read from the request parameter table, and the first actual return value is determined from the first return table and the second actual return value is determined from the second return table based on the identifier.

[0120] In this example, the identifier refers to the unique identification code assigned to each group of associated production record data. This can be a serial number or a unique key with business significance, used to establish relationships between multiple data tables and ensure that various types of data from the same request can be correctly matched. The data table structure refers to the pre-designed database tables for categorizing and storing production record data, including table names, field definitions, and indexing strategies. By splitting different types of data (such as request parameters and return values) into different tables, structured data storage and efficient management are achieved.

[0121] For example, the received production record data can be parsed and verified first, generating a globally unique identifier for each complete set of data (including the first request, the first actual return value, and the related second actual return value). Then, according to the preset data table structure, the request parameters and their identifiers are stored in the request parameter table, the final return value and its identifier are stored in the first return table, and the return values ​​of each external interface are associated with their identifiers and stored in the second return table. In the subsequent comparative testing phase, when reading the first request from the request parameter table, its identifier is obtained synchronously. Using this identifier as the association key, the corresponding first and second actual return values ​​are accurately queried from the first and second return tables, respectively, to ensure the accuracy and completeness of data retrieval.

[0122] This example achieves highly structured and standardized management of test data, ensuring the integrity and consistency of request and response data. It also improves data query and access efficiency through table structure optimization, providing a reliable data foundation for large-scale automated comparative testing. At the same time, the clear table structure design greatly simplifies subsequent data maintenance and expansion work.

[0123] For example, in this embodiment of the application, the execution entity can be an acceptance environment server. Correspondingly, the processes of collecting and sending production record data are completed by the production environment server. For example:

[0124] The production environment server receives data collection tasks sent by the operations team.

[0125] During the process of processing requests in the production environment, the production environment server asynchronously collects production record data as indicated by the data collection task.

[0126] The production environment server sends production record data to the acceptance environment server.

[0127] It's important to note that production environment servers refer to the software systems running online and providing real services, along with their underlying hardware infrastructure; this is the environment directly accessed by users. Acceptance environment servers, on the other hand, are isolated from the production environment and used for final testing and verification. The software versions and configurations on these servers are consistent with the versions about to be deployed.

[0128] A data collection task refers to specific instruction configurations that define what data to collect. Its core parameters include, but are not limited to: target interface name (which interface's traffic to collect), sampling time window (from when to when), filtering conditions (such as specific user identifiers, device types, call sources, etc.), and specific production record data. The purpose is to conduct targeted data collection and avoid excessive data volume.

[0129] Asynchronous collection refers to the process where, after the production environment server processes a user request and returns a response, instead of immediately waiting for the data recording to be completed, the logging operation is placed in a separate, low-priority queue or process and executed in the background.

[0130] For example, production environment servers can intercept qualified requests in the request processing chain using aspect-oriented programming, encapsulate the data to be collected into messages, and immediately send them to a high-performance message queue (such as Kafka or RocketMQ). A separate consumer service then consumes the messages from the queue and batches them into log files, thereby achieving the collection of production log data. Alternatively, the collected data can be directly written to a circular buffer in memory using an asynchronous appender of the logging framework, with a background thread periodically or quantitatively flushing the buffer contents to the local disk log files.

[0131] The offline interface comparison testing method provided in this embodiment first receives these production record data, calls the test interface by replaying the first request, and simulates the external interface response using the recorded second actual return value during this process. Finally, it compares the first test return value generated by the test interface with the first actual return value recorded online to determine whether the test interface has any anomalies. This method overcomes the shortcomings of traditional manual test cases, such as incomplete coverage and high resource consumption in online dual-run tests. By using real online traffic as test data, it can comprehensively cover various business scenarios, while the offline execution method avoids impacting the performance of the production system. Using recorded external interface return values ​​for simulation effectively solves the uncertainty problem of external dependencies during the testing process, ensuring the accuracy and reliability of the test results.

[0132] This embodiment provides a method for offline comparison testing of interfaces. Figure 2 The flowchart of the interface offline comparison test method provided in the embodiments of this application Figure 2 The production record data also includes: scenario information corresponding to the first request, and at least one exception return value returned by the external interface based on the first request. The method includes:

[0133] S201. Based on the scenario information corresponding to the first request and the preset triggering rules, determine whether the first request belongs to the target request.

[0134] Among them, the triggering rules are used to indicate the correspondence between scene information and target requests.

[0135] In this step, scenario information refers to the contextual environment data describing when the request occurs, including but not limited to device model, operating system version, user identity characteristics, network environment, geographical location, request time, and other dimensional information that can define a specific test scenario. Triggering rules refer to a pre-configured set of logical conditions used to determine whether a request needs to undergo anomaly response testing.

[0136] It's important to note that the complexity of production environments means that external dependent services can experience various anomalies (such as timeouts and errors) at any time. Refactoring code can easily and unintentionally break or weaken existing exception handling logic. By systematically simulating these real-world anomaly scenarios in a controlled acceptance environment, we can proactively verify whether the refactored interfaces still possess fault tolerance and stable error recovery mechanisms. This allows us to identify potential risks and ensures that after system deployment, a chance failure of an external interface will not cause a cascading failure in core business logic or produce erroneous business results. This comprehensively improves the quality of code refactoring and the robustness of the online system.

[0137] For example, preset trigger rules (e.g., device model: A, and network environment: 4G) can be loaded into the engine. When processing a request, the engine automatically matches and calculates the scene information, outputting a boolean value to determine whether it is the target request. Alternatively, all trigger rules can be materialized and stored in a specific configuration table in the database. When processing a request, the configuration table is directly queried based on the scene information in the request (such as device model and user tag). If any valid rule record is matched, the request is determined to be the target request.

[0138] S202. If not, then no abnormal response test will be performed on the test interface.

[0139] S203. If so, then determine the target abnormal return value corresponding to the scene information according to the preset mapping relationship.

[0140] The mapping relationship is used to indicate the correspondence between scenario information and target abnormal return values. The production record data also includes: the third actual return value generated by the actual interface based on each abnormal return value.

[0141] It should be noted that abnormal return values ​​refer to response data under various abnormal conditions that external interfaces may return, including but not limited to business error codes, timeouts without response, abnormal data formats, and other abnormal responses.

[0142] For example, a scenario-exception mapping table can be maintained. After determining that an exception test needs to be triggered, the scenario information of the current request (such as scenario identifier or key dimension) is used as the key to retrieve the unique identifier or template of the pre-configured target exception return value from the configuration center, and then the specific exception response content is loaded from the locally cached production record data. Alternatively, the correspondence between common scenarios and exception return values ​​can be defined in an enumeration class or constant class in the code. Through a dedicated mapping service, based on the input scenario information, the corresponding exception enumeration value is returned through switch-case or if-else logic, thereby finding the specific exception return value stored in memory or the database.

[0143] For example, before determining the target exception return value corresponding to the scene information based on a preset mapping relationship, the method further includes:

[0144] Extract complete link records from historical production data. The complete link records include scenario information, at least one abnormal return value returned by the corresponding external interface, and the corresponding third actual return value generated by the actual interface.

[0145] Based on the complete link record, an associated knowledge base is established. The associated knowledge base is used to indicate the relationship between scenario information, abnormal return values, and factors affecting the result.

[0146] Based on the associated knowledge base and the preset test coverage strategy, at least one target abnormal return value is determined for each scenario information; wherein, the test coverage strategy is used to indicate the coverage of abnormal return values ​​with high impact level and / or, abnormal return values ​​that occur frequently.

[0147] In this example, by forcibly associating exception return values ​​with the final impact, it is ensured that the generation logic of the mapping relationship always revolves around business risks, rather than merely relying on technical appearances (such as error codes). At the same time, the introduction of a test coverage strategy as a selection criterion gives this automation process a clear goal orientation (such as ensuring stability or covering high-risk scenarios), thus achieving a balance between coverage and testing efficiency in the generated mapping relationship.

[0148] For example, in a smart home scenario, suppose an automation rule is: if the outdoor temperature exceeds 35℃, automatically turn on the living room air conditioner to cooling mode. This rule relies on an external weather interface. Historical production records show that in a typical scenario with the following conditions: summer afternoon, user preference = energy-saving mode, and device status = air conditioner standby, the external weather interface has returned two exceptions: data unavailable (A) and service timeout (B). Analysis of the corresponding third actual return values ​​reveals that exception A triggered a degradation logic, causing the system to use the previously cached temperature data (let's say 32℃). Because the threshold was not reached, the air conditioner was not turned on (impact: potentially leading to a decline in user experience, but the logic is controllable); exception B caused the rule engine to completely fail, not only preventing the air conditioner from turning on but also pushing an automation service exception alert to the user (impact: functional failure and causing unnecessary user anxiety). If the preset test coverage strategy is to prioritize covering exceptions that lead to user alerts and complete functional failure, then the target exception return value pre-determined for this scenario could be service timeout (B).

[0149] S204. Call the test interface and intercept the target operation of the test interface calling the external interface; simulate the target exception return value as the test exception return value returned by the external interface in the acceptance environment.

[0150] S205. Obtain the third test return value generated by the test interface based on the test exception return value.

[0151] S206. Compare the third actual return value with the third test return value to determine whether the abnormal response test of the test interface is normal.

[0152] For example, a recursive algorithm can be used to perform a depth-first comparison of the third actual return value and the third test return value, parsing the data structure layer by layer and rigorously verifying the integrity of each field's name, data type, value, and nested structure. For array types, not only the element content is checked, but the consistency of the element order is also verified. During the comparison process, all difference paths and their specific details (such as expected value A and actual value B) are fully recorded. This method can discover all subtle differences, including missing fields, type conversion errors, and data truncation, ensuring that the reconstructed exception handling logic remains completely consistent with the online historical version.

[0153] Alternatively, a corresponding key assertion rule base can be pre-configured based on different exception types. For example, for external interface timeout scenarios, it might only be necessary to verify core business characteristics such as a 503 status code, the existence of an error code field containing a specific timeout code, and the presence of the keyword "timeout" in the returned message. During the comparison, non-business dynamic fields such as timestamps and request identifiers are ignored, and only the pre-defined key assertion rules are verified one by one. This approach can effectively filter out interference differences caused by non-functional modifications such as changes in link identifier generation strategies and enhanced logging, directly focusing on whether exception handling maintains correct business semantics.

[0154] The offline comparison testing method for interfaces provided in this embodiment records real abnormal scenarios and corresponding responses in production data, and triggers simulated abnormalities in an acceptance environment. This method can systematically verify the fault tolerance capability and the correctness of the exception handling logic of the reconstructed interface, effectively avoiding the risk of exception handling logic degradation or failure due to code modification, thereby significantly improving the stability and robustness of the system when facing external dependency exceptions.

[0155] This embodiment also provides an offline interface comparison testing device. Figure 3 The interface offline comparison test diagram provided in the embodiments of the present invention is as follows: Figure 3 As shown, the interface offline comparison test device 30 includes:

[0156] The receiving module 301 is used to receive production record data, wherein the production record data includes: the first request processed by the actual interface in the production environment, the corresponding first actual return value, and the second actual return value returned by the external interface called by the actual interface;

[0157] The calling module 302 is used to read the first request from the production record data and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value corresponding to the external interface to be called.

[0158] The comparison module 303 is used to compare the first actual return value with the first test return value to determine whether there is an anomaly in the test interface.

[0159] In one possible implementation, module 302 is specifically used for:

[0160] During the process of the test interface processing the first request, intercept the target operation of the test interface calling the external interface;

[0161] Based on the production record data, determine the second actual return value returned by the external interface based on the first request, and simulate the second actual return value as the second test return value returned by the external interface in the acceptance environment;

[0162] Obtain the first test return value generated by the test interface based on the second test return value.

[0163] In one possible implementation, the production record data further includes: scenario information corresponding to the first request, and at least one exception return value returned by the external interface based on the first request; the comparison module 303 is also used for:

[0164] Based on the scenario information corresponding to the first request and the preset triggering rules, determine whether the first request belongs to the target request. The triggering rules are used to indicate the correspondence between the scenario information and the target request.

[0165] If so, then perform abnormal response testing on the test interface based on at least one abnormal return value returned by the external interface in the production environment;

[0166] If not, then no exception response test will be performed on the test interface.

[0167] In one possible implementation, the production record data further includes: a third actual return value generated by the actual interface based on each exception return value; the comparison module 303 is specifically used for:

[0168] Based on the preset mapping relationship, the target abnormal return value corresponding to the scene information is determined. The mapping relationship is used to indicate the correspondence between the scene information and the target abnormal return value.

[0169] Call the test interface and intercept the target operation of the test interface calling the external interface; simulate the target exception return value as the test exception return value returned by the external interface in the acceptance environment;

[0170] Obtain the third test return value generated by the test interface based on the test exception return value;

[0171] Compare the third actual return value with the third test return value to determine whether the abnormal response test of the test interface is normal.

[0172] In one possible implementation, the production record data also includes actual processing information corresponding to the first request; the comparison module 303 is further used for:

[0173] Obtain test processing information for the first request handled by the test interface;

[0174] Based on the actual processing information and the test processing information, determine the root cause analysis results;

[0175] Based on the results of the differential root cause analysis, corresponding remediation recommendations were determined;

[0176] Based on the root cause analysis results and remediation suggestions, a task ticket is generated and sent to the operations team so that the operations team can fix the anomalies in the test interface.

[0177] In one possible implementation, the receiving module 301 is further configured to:

[0178] Based on the production record data, determine the identifier corresponding to each set of target data. The target data includes the first request, the first actual return value corresponding to the first request, and the second actual return value.

[0179] Each set of target data is classified and stored in a preset data table structure, wherein the data table structure includes a request parameter table storing the first request and its corresponding identifier, a first return table storing the first actual return value and its corresponding identifier, and a second return table storing the second actual return value and its corresponding identifier.

[0180] Correspondingly, the first request and its corresponding identifier are read from the request parameter table, and the first actual return value is determined from the first return table based on the identifier, and the second actual return value is determined from the second return table.

[0181] In one possible implementation, the comparison module 303 is also used for:

[0182] Extract complete link records from historical production data. The complete link records include scenario information, at least one abnormal return value returned by the corresponding external interface, and the corresponding third actual return value generated by the actual interface.

[0183] Based on the complete link record, an associated knowledge base is established. The associated knowledge base is used to indicate the relationship between scenario information, abnormal return values, and factors affecting the result.

[0184] Based on the associated knowledge base and the preset test coverage strategy, at least one target abnormal return value is determined for each scenario information; wherein, the test coverage strategy is used to indicate the coverage of abnormal return values ​​with high impact level and / or, abnormal return values ​​that occur frequently.

[0185] This embodiment provides an interface offline comparison testing device that can execute the interface offline comparison testing method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0186] Figure 4 This is a hardware schematic diagram of an electronic device provided in an embodiment of the present invention. For example... Figure 4 As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. The device 40 also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0187] In the specific implementation process, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above method.

[0188] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0189] In the above Figure 4 In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0190] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0191] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0192] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described above.

[0193] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0194] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0195] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0196] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0197] In addition, the functional units in the various embodiments of the present invention 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.

[0198] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0199] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0200] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application 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 or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for offline interface comparison testing, characterized in that, include: Receive production record data, wherein the production record data includes: a first request processed by the actual interface in the production environment, a corresponding first actual return value, and a second actual return value returned by the external interface called by the actual interface; Read the first request from the production record data, and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value of the external interface to be called; The first actual return value and the first test return value are compared to determine whether the test interface has any abnormalities.

2. The method according to claim 1, characterized in that, After invoking the corresponding test interface in the acceptance environment according to the first request, the method further includes: During the process of the test interface processing the first request, the target operation of the test interface calling the external interface is intercepted. Based on the production record data, determine the second actual return value returned by the external interface based on the first request, and simulate the second actual return value as the second test return value returned by the external interface in the acceptance environment; Obtain the first test return value generated by the test interface based on the second test return value.

3. The method according to claim 1, characterized in that, The production record data also includes: scenario information corresponding to the first request, and at least one abnormal return value returned by the external interface based on the first request; The method further includes: Based on the scenario information corresponding to the first request and the preset triggering rules, it is determined whether the first request belongs to the target request. The triggering rules are used to indicate the correspondence between the scenario information and the target request. If so, then based on at least one abnormal return value returned by the external interface in the production environment, perform abnormal response testing on the test interface; If not, then no exception response test will be performed on the test interface.

4. The method according to claim 3, characterized in that, The production record data also includes: a third actual return value generated by the actual interface based on each exception return value; The abnormal response test of the test interface based on at least one abnormal return value returned by the external interface in the production environment includes: Based on a preset mapping relationship, the target abnormal return value corresponding to the scene information is determined, and the mapping relationship is used to indicate the correspondence between the scene information and the target abnormal return value; Call the test interface and intercept the target operation of the test interface calling the external interface; simulate the target exception return value as the test exception return value returned by the external interface in the acceptance environment; Obtain the third test return value generated by the test interface based on the test exception return value; The third actual return value and the third test return value are compared to determine whether the abnormal response test of the test interface is normal.

5. The method according to claim 1, characterized in that, The production record data also includes information on the actual processing of the first request; If the test interface is determined to be abnormal, the method further includes: Obtain the test processing information of the test interface that processes the first request; Based on the actual processing information and the test processing information, the root cause analysis results are determined; Based on the results of the differential root cause analysis, corresponding remediation recommendations are determined; Based on the root cause analysis results and the repair suggestions, a task work order is generated and sent to the operations team so that the operations team can repair the anomaly in the test interface.

6. The method according to claim 1, characterized in that, After receiving the production record data, the method further includes: Based on the production record data, an identifier corresponding to each set of target data is determined. The target data includes a first request, a first actual return value corresponding to the first request, and a second actual return value. Each set of target data is categorized and stored in a preset data table structure, wherein the data table structure includes a request parameter table storing the first request and its corresponding identifier, a first return table storing the first actual return value and its corresponding identifier, and a second return table storing the second actual return value and its corresponding identifier. Correspondingly, the first request and its corresponding identifier are read from the request parameter table, and the first actual return value is determined from the first return table based on the identifier, and the second actual return value is determined from the second return table.

7. The method according to claim 4, characterized in that, Before determining the target abnormal return value corresponding to the scene information according to the preset mapping relationship, the method further includes: Extract complete link records from historical production record data. The complete link records include scenario information, at least one abnormal return value returned by the corresponding external interface, and a corresponding third actual return value generated by the actual interface. Based on the complete link record, an associated knowledge base is established, which is used to indicate the relationship between scenario information, abnormal return values, and factors affecting the results. Based on the associated knowledge base and the preset test coverage strategy, at least one target abnormal return value is determined for each scenario information; wherein, the test coverage strategy is used to indicate the coverage of abnormal return values ​​with high impact level and / or, abnormal return values ​​that occur frequently.

8. An offline interface comparison testing device, characterized in that, The device includes: A receiving module is used to receive production record data, wherein the production record data includes: a first request processed by the actual interface in the production environment, a corresponding first actual return value, and a second actual return value returned by the external interface called by the actual interface; The calling module is used to read the first request from the production record data and call the corresponding test interface in the acceptance environment according to the first request, so that the test interface directly generates the corresponding first test return value, or generates the corresponding first test return value based on the second actual return value of the external interface to be called. The comparison module is used to compare the first actual return value with the first test return value to determine whether the test interface has any abnormalities.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. An electronic device, characterized in that, include: At least one processor and memory; wherein, The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any one of claims 1-7.

Images