Client zero-intrusion interaction test method under dependency decoupling

Abstract

The invention relates to the technical field of software control, and particularly provides a client zero-intrusion interaction test method under dependency decoupling, which comprises the following steps: splitting a business scene to be tested into a plurality of business steps, each business step corresponding to at least one interaction, the interaction comprising interface interaction or message interaction; based on a unified JSON data interaction model, interface interaction or message interaction of each service step is subjected to configuration definition, client zero-intrusion flow control and bidirectional interaction, and request flow sent by a to-be-tested project of a client is transparently intercepted through a service grid or a similar flow interception technology. Codes of to-be-tested projects of the client do not need to be modified; according to the level self-adaptive cache mechanism, a multi-level cache system comprising a local cache and a distributed remote cache is constructed, and simulated interface interaction data, message interaction data, service step configuration information and service flow state data are stored and quickly inquired; the method does not invade the client, parameters can be flexibly set, and the flexibility is greatly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software control, and in particular to a client zero-invasion interaction test method under dependence decoupling. BACKGROUND

[0002] In today's digital age, the functions of information systems are increasingly large, and the interaction between systems and within systems is complex, and the dependence between each other leads to increasingly strong dependence of business process execution on resources. In the development and self-test stage, insufficient dependence resources caused by cost or environmental problems will cause the business chain to be unable to self-test and execute, blocking the development and self-test, and a flexible decoupling solution is urgently needed to realize flexible self-test of the self module under the condition of decoupling dependence resources, so as to cover the self-test needs of the current module.

[0003] Currently, there are mainly two compatibility solutions, including: Solution one: directly configure the simulation return in the to-be-tested project, and directly return the default value when the current module calls the missing resource, so as to ensure that the code flow in the current module is executable, but additional code and configuration modification are needed, which has great invasiveness, and the default value is a fixed value, which cannot be flexibly adjusted, and is very inconvenient.

[0004] Solution two: realize interface-level simulation self-test through a unified interface management platform (such as ApiFox).

[0005] The existing compatibility solution one needs to modify the calling end code in the to-be-tested project, which has great invasiveness, and as the number of dependence resources and projects increases, the modification difficulty increases exponentially, and at the same time, it is difficult to flexibly set different response parameters according to request parameters, and it is also difficult to simulate boundary and abnormal scenes, so it is only suitable for simple simulation of small scenes, and has poor compatibility and promotion.

[0006] In the above compatibility solution two, the to-be-tested project is decoupled through a unified interface management platform and dependence resources, realizes interface-level parameter response configuration, and the to-be-tested project only needs to dynamically adjust the calling end address pointing to the interface management platform in the configuration file, so as to reuse the interface simulation capability, but cannot simulate message interaction scenes, and cannot perform end-to-end self-test based on business, and has no driving capability, that is, cannot simulate asynchronous feedback, including interface and message scenes, and cannot track the entire business flow.

[0007] In view of the defects of the prior art, the present application provides a client zero-invasion interaction test method under dependence decoupling. SUMMARY

[0008] To achieve the above purpose, the present application adopts the following technical solutions: In one aspect of the present application, a client zero-invasion interaction test method under dependence decoupling is provided, comprising the following steps: The system features custom dynamic orchestration and tracking of business flows. It breaks down the business scenario under test into multiple business steps, each corresponding to at least one interaction, including interface interactions or message interactions. Based on a unified JSON data interaction model, it defines the interface or message interactions for each business step in a configurable manner, including request data models, response / message data models, protocol types, and interaction rules. Multiple business steps are dynamically assembled through preset relationships to form a complete custom business flow. The system drives the execution of the custom business flow, displaying the execution status, interaction data, and path of each business step in real time through a top-level view. It also provides a compensation mechanism to intervene and adjust the flow when execution is abnormal or when preset boundary conditions are reached. Zero-intrusive traffic control and bidirectional interaction on the client side: Through service mesh or similar traffic interception technologies, it transparently intercepts request traffic from the client-side project under test (DUT) without modifying the DUT's code. Based on preset traffic splitting labels and rules, it judges and forwards intercepted traffic, flexibly directing requests from the client-side DUT to the real or simulated server. When traffic is directed to the simulated server, the simulated server interacts bidirectionally with the client-side DUT according to defined interface or message interaction rules, including receiving client requests and returning simulated responses, or proactively pushing simulated messages to the client. Based on a two-layer subscription relationship formed by business, client, and communication channels, the simulated server or business flow engine uses HTTP protocol server event sending capabilities or WebSocket protocol to push the business flow execution status to the client or test management platform for real-time display. A multi-level adaptive caching mechanism is constructed, including a local cache and a distributed remote cache, to store and quickly query simulated interface interaction data, message interaction data, business step configuration information, and business flow status data. Based on preset data access frequency thresholds, data size thresholds, and business flow execution context information, the storage location and granularity of data between the local and remote caches are dynamically adjusted. A preset eviction policy is used to manage cached data, and data consistency between the local and remote caches is maintained through a cache update notification mechanism or version control mechanism, so as to improve query speed while reducing the processing pressure on the simulated server nodes.

[0009] In one optional implementation, the unified JSON data interaction model further includes: The request / response protocol model for interface interaction defines the interface's URL, method, request header, request body, response header, response body, status code, and expected response time; The publish / subscribe / consume protocol model for message interaction defines message topic / queue name, message body, message attributes, sending mode, expected delivery time, and message acknowledgment mechanism.

[0010] In one optional implementation, the dynamic assembly further includes allowing users to drag and drop or configure flow conditions, parallel / serial execution logic, and exception jump logic between steps through a visual interface to construct complex business scenarios. The compensation mechanism includes allowing users to configure retry strategies, degradation strategies, or preset alternative response messages for specific business steps to cover business boundary conditions and abnormal scenarios.

[0011] In one optional implementation, the service mesh implements traffic interception by deploying a Sidecar proxy. The Sidecar proxy is deployed in the same environment as the client-side project under test and transparently intercepts all external service requests issued by the client. The traffic splitting tags include, but are not limited to, client application identifiers, test scenario identifiers, user identifiers, or specific request header fields. The traffic splitting rules allow traffic routing decisions based on the combined logic of the traffic splitting tags.

[0012] In one optional implementation, the simulation server supports forward interaction simulation and reverse interaction simulation. The forward interaction simulation involves the simulation server receiving a client request and returning a simulated response. The reverse interaction simulation involves the simulation server actively pushing simulated messages to the client's test project or its monitored message queue based on the business flow execution logic or preset conditions, in order to simulate asynchronous feedback scenarios. The two-layer subscription relationship is as follows: the client subscribes to a specific business flow, and the communication channel subscribes to a specific combination of client and business flow. When the state of the combined business flow changes, the state event is actively pushed to the subscribed client through the corresponding communication channel.

[0013] In one optional implementation, the local cache is a cache that simulates the memory of the server node, and prioritizes storing configuration and interaction data of frequently accessed hot business steps; the distributed remote cache is an independently deployed cache cluster that stores globally shared business flow definitions, low-frequency but important interaction data, and backup data when the local cache is missed.

[0014] In one optional implementation, the adaptive caching strategy specifically includes: When the frequency of access to interactive data in a certain business step exceeds a first preset threshold, it is promoted from the remote cache to the local cache. When the local cache space reaches the second preset threshold, low-frequency access data will be moved from the local cache to the remote cache or cleared according to the eviction policy. When a specific context is detected during the execution of a business flow, the cache priority and expiration time of the corresponding data are adjusted.

[0015] Another aspect of the present invention provides a client-side zero-intrusion interaction testing system under dependency decoupling, comprising: Based on a unified JSON data interaction model, interface interaction and message interaction are configurably defined. Multiple business steps are dynamically assembled into a custom business flow through a doubly linked list. The custom business flow is driven to execute, and the execution status, interaction data and link direction of each business step are tracked in real time. A compensation mechanism is provided to cover business boundary scenarios. Based on the two-layer subscription relationship formed by business, client and communication channel, the business flow status is pushed to the client or test management platform in real time through HTTP event stream or WebSocket protocol. The client-side zero-intrusion traffic control and two-way interaction module includes: Service mesh technology is used to transparently intercept request traffic from the client-side project under test without modifying the client code; based on preset traffic splitting labels and rules, the intercepted traffic is routed flexibly to the real server or the simulated server; when the traffic is routed to the simulated server, the simulated server is controlled to interact bidirectionally with the client-side project under test, including receiving client requests and returning simulated responses, or actively pushing simulated messages to the client; A multi-level adaptive caching module includes: A multi-level caching system consisting of local cache and distributed remote cache is constructed to store simulated interaction data, business step configuration information, and business flow status data; the storage location and granularity of data between local cache and remote cache are dynamically adjusted based on data access frequency, data size, and business flow execution context; and a business priority-based eviction strategy and cache consistency mechanism are adopted to maintain the validity of cached data and reduce the processing pressure on simulated server nodes. The simulated server is communicatively connected to the business flow custom dynamic orchestration and tracking module, the client-side zero-intrusion traffic control and bidirectional interaction module, and the multi-level adaptive caching module, including: Based on the interaction rules issued by the custom dynamic orchestration and tracing module of the business flow, execute bidirectional interaction with the client-side project under test; query or update simulated interaction data from the multi-level adaptive caching module; and provide feedback on the execution status of business steps to the custom dynamic orchestration and tracing module of the business flow.

[0016] In another aspect, the present invention provides an electronic device comprising: At least one memory stores computer-executable instructions non-transitory; At least one processor, configured to run the computer-executable instructions, The computer-executable instructions are executed by the processor to implement the aforementioned client-side zero-intrusion interaction testing method under dependency decoupling.

[0017] In another aspect, the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by at least one processor, implement the aforementioned client-side zero-intrusion interaction testing method under dependency decoupling.

[0018] Effects of the invention: Conventional API platforms can only return sample responses in a one-way manner for display. However, this solution is based on business chain simulation, rather than API simulation, which is closer to real-world usage scenarios. It can simulate message interaction and asynchronous feedback scenarios, providing a two-way interaction mechanism instead of a simple one-way call, and can track the execution status of the self-testing business chain in real time. Conventional simulation mechanisms require code and configuration modifications to implement call simulation, and there is no mechanism to manage data adjustments, which are inconsistent and mechanical. This solution is non-intrusive to the client, allows for flexible parameter settings, and greatly improves versatility and flexibility. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a client-side zero-intrusion interaction testing method under dependency decoupling provided in Embodiment 1 of the present invention; Figure 2 This is a framework for a client-side zero-intrusion interaction testing system under dependency decoupling, as provided in Embodiment 2 of the present invention. Figure 3 This is a diagram illustrating the scheduled task execution strategy in this embodiment; Figure 4 This is a diagram of the subscription relationship mapping structure in this embodiment; Figure 5 This is a block diagram of the electronic device provided in Embodiment 4 of the present invention; Figure 6 This is a block diagram of a computer-readable storage medium provided in Embodiment 4 of the present invention. Detailed Implementation

[0020] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0021] Hereinafter, the terms "first," "second," etc., are used for descriptive convenience only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0022] In this invention, unless otherwise explicitly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed mechanical connection, a detachable mechanical connection, or an integral part; or, "connection" can be a direct connection or an indirect connection through an intermediate medium. Furthermore, unless otherwise explicitly specified and limited, the term "coupling" should be interpreted broadly. For example, "coupling" can be a direct electrical connection, such as physical contact and electrical conduction between two components; it can also be understood as an electrical connection between different components in a circuit structure through physical lines capable of transmitting electrical signals, such as copper foil or wires on a printed circuit board (PCB), to transmit electrical signals; or, "coupling" can be an indirect electrical connection between two components through an intermediate medium; or, "coupling" can be an electrical connection between two components in a non-contact manner, such as an electrical connection between two components using capacitive coupling to transmit electrical signals.

[0023] In this embodiment of the invention, directional terms such as "up," "down," "left," and "right" may be defined relative to the orientation of the components shown in the accompanying drawings. It should be understood that these directional terms can be relative concepts, used for relative description and clarification, and can change accordingly depending on the orientation of the components in the accompanying drawings.

[0024] Example 1: like Figure 1 , Figure 3 , Figure 4 As shown, this embodiment of the invention provides a client-side zero-intrusion interaction testing method under dependency decoupling, comprising the following steps: Step S100: Custom dynamic orchestration and tracking of business flow. The business scenario to be tested is broken down into multiple business steps, each corresponding to at least one interaction, including interface interaction or message interaction. Based on a unified JSON data interaction model, the interface interaction or message interaction of each business step is configurably defined, including request data model, response / message data model, protocol type, and interaction rules. Multiple business steps are dynamically assembled through preset association relationships to form a complete custom business flow. The custom business flow is driven to execute, and the execution status, interaction data, and link direction of each business step in the business flow are displayed in real time through a top-level view. A compensation mechanism is provided to intervene and adjust when the business flow execution is abnormal or reaches preset boundary conditions. Step S200: Zero-intrusive traffic control and bidirectional interaction on the client side. Through service mesh or similar traffic interception technology, request traffic from the client-side project under test is transparently intercepted without modifying the project's code. Based on preset traffic splitting labels and rules, the intercepted traffic is judged and forwarded, flexibly directing requests from the client-side project under test to the real or simulated server. When traffic is directed to the simulated server, the simulated server interacts bidirectionally with the client-side project under test according to defined interface or message interaction rules, including receiving client requests and returning simulated responses, or proactively pushing simulated messages to the client. Based on the two-layer subscription relationship formed by the business, client, and communication channel, the simulated server or business flow engine uses the HTTP protocol's server event sending capability or the WebSocket protocol to push the business flow execution status to the client or test management platform for real-time display. Step S300: A multi-level adaptive caching mechanism is constructed, including a local cache and a distributed remote cache, to store and quickly query simulated interface interaction data, message interaction data, business step configuration information, and business flow status data. Based on preset data access frequency thresholds, data size thresholds, and business flow execution context information, the storage location and granularity of data between the local cache and the remote cache are dynamically adjusted. A preset eviction policy is used to manage cached data, and data consistency between the local cache and the remote cache is maintained through a cache update notification mechanism or version control mechanism, so as to improve query speed while reducing the processing pressure on the simulated server node.

[0025] In the above embodiments, within the current distributed microservice architecture, a business process traverses multiple modules or systems. Any business scenario can be decomposed; that is, the business can be assembled from steps, and the execution of these steps drives the entire business flow. These steps involve interactions, mostly interface interactions, with a small number of decoupled scenarios using message interactions. Analysis reveals that the basic business model consists of a series of interface and message interactions. Both interfaces and messages can be artificially simulated based on independent data and protocol models to construct business flows and perform custom assembly.

[0026] JSON, as a lightweight data exchange format, stores and represents data in a text format independent of programming languages. It is widely used in data transmission, including front-end and back-end interactions, back-end interactions, middleware interactions, and other scenarios. Therefore, it can be used as a general data interaction model.

[0027] The business flow is customized through a doubly linked list. It allows for flexible setting of business scenarios through the concepts of steps and operations, without being coupled with operations. Steps can be dynamically adjusted in real time, and steps can be linked together through driving relationships.

[0028] Example 2: like Figure 1 As shown, based on Embodiment 1, the steps provided in this embodiment of the invention, including the unified JSON data interaction model, further include: The request / response protocol model for interface interaction defines the interface's URL, method, request header, request body, response header, response body, status code, and expected response time; The publish / subscribe / consume protocol model for message interaction defines message topic / queue name, message body, message attributes, sending mode, expected delivery time, and message acknowledgment mechanism.

[0029] Specifically, the dynamic assembly also includes allowing users to drag and drop or configure the flow conditions between steps, parallel / serial execution logic, and exception jump logic through a visual interface to construct complex business scenarios. The compensation mechanism includes allowing users to configure retry strategies, degradation strategies, or preset alternative response messages for specific business steps to cover business boundary situations and abnormal scenarios.

[0030] Specifically, the service mesh implements traffic interception by deploying a Sidecar proxy. The Sidecar proxy is deployed in the same environment as the client-side project under test and transparently intercepts all external service requests issued by the client. The traffic splitting tags include, but are not limited to, client application identifiers, test scenario identifiers, user identifiers, or specific request header fields. The traffic splitting rules allow traffic routing decisions based on the combined logic of the traffic splitting tags.

[0031] Specifically, the simulation server supports forward interaction simulation and reverse interaction simulation. Forward interaction simulation involves the simulation server receiving client requests and returning simulated responses. Reverse interaction simulation involves the simulation server actively pushing simulated messages to the client's test project or its monitored message queue based on business flow execution logic or preset conditions to simulate asynchronous feedback scenarios. The two-layer subscription relationship is as follows: the client subscribes to a specific business flow, and the communication channel subscribes to a specific combination of client and business flow. When the state of the combined business flow changes, the state event is actively pushed to the subscribed client through the corresponding communication channel.

[0032] Specifically, the local cache is a cache that simulates the memory of the server node, prioritizing the storage of configuration and interaction data for frequently accessed hot business steps; the distributed remote cache is an independently deployed cache cluster that stores globally shared business flow definitions, low-frequency but important interaction data, and backup data when the local cache misses.

[0033] Specifically, the adaptive caching strategy includes: When the frequency of access to interactive data in a certain business step exceeds a first preset threshold, it is promoted from the remote cache to the local cache. When the local cache space reaches the second preset threshold, low-frequency access data will be moved from the local cache to the remote cache or cleared according to the eviction policy. When a specific context is detected during the execution of a business flow, the cache priority and expiration time of the corresponding data are adjusted.

[0034] In the above embodiments, interface interactions include synchronous interfaces and asynchronous feedback interfaces. This solution separately models these two scenarios. A forward interface is defined as the resource simulation platform actively calling the project under test. In this scenario, the resource simulation platform is responsible for initiating requests according to the configured message elements. The platform only needs to simulate the request message because the project under test needs external feedback to trigger the business flow. A reverse interface is defined as the project under test calling the resource simulation platform, which returns the expected response. In this scenario, the platform is responsible for returning response headers, response bodies, status codes, etc., according to the configured message elements (such as path, method, request headers, request body, request parameters, etc.). The platform only needs to simulate the response message because the project under test needs a response to enable the business flow, as shown in the table below. The resource simulation platform has different focuses in these two scenarios. In the forward interface scenario, it only needs to be concerned with how to construct the request message, while in the reverse interface scenario, it only needs to be concerned with how to find the matching response body and response header based on the received request parameters and return them.

[0035] Table 1. Summary of Forward Interface Configuration Items

[0036] Table 2 Summary of Reverse Interface Configuration Items

[0037] Unlike API scenarios, messaging scenarios do not involve direct interaction between the project under test (TBT) and the resource simulation platform. Instead, they interact indirectly through a message middleware. Based on actual needs, the bottleneck affecting TBT's business logic is that TBT needs to act as a consumer to consume messages to drive business flow. However, the act of TBT sending messages as a producer can be entirely supported by the message middleware, without relying on the resource side or requiring the cooperation of the resource simulation platform. Therefore, message simulation is unidirectional and forward-moving; that is, the resource simulation platform drives the business flow within TBT by simulating message sending.

[0038] Table 3 Forward MQ Configuration Items

[0039] In the scenario of business self-driving adaptation to reverse interface, the resource simulation platform synchronously updates the current step status when returning the expected response, and updates the next step status to pending execution. It sets the preconditions for timed driving, making it easier to retrieve and execute the steps to be triggered.

[0040] Scheduled task driven (forward driven).

[0041] Operations initiated by the resource simulation platform, including sending requests and messages, are positive steps that require polling and triggering by a scheduled task. At this time, the scheduled task needs to retrieve the appropriate steps and assemble the message.

[0042] Scheduled task mechanisms can drive the automatic execution of forward steps, but the forward step must be in the "pending execution" state to be detected by the scanning mechanism. Therefore, forward steps are somewhat dependent on preceding steps. In real-world business scenarios, local or distributed caching mechanisms exist. This means that the reverse interface will trigger a real request when the cache expires, but will not trigger a real request when the cache is valid. In other words, the reverse interface has uncertainty. Therefore, manual compensation is needed for boundary conditions. Compensation mechanisms are divided into state compensation mechanisms and trigger compensation mechanisms.

[0043] The state compensation mechanism updates the state to a pending state by triggering a task, thereby satisfying the scanning conditions of the scheduled task.

[0044] The compensation mechanism is triggered directly by manually sending positive messages or using positive interfaces, bypassing scheduled task scanning and allowing for real-time triggering by humans, thus improving the interactive experience and providing better real-time performance.

[0045] Business flow status tracking and display involves executing corresponding operations through a resource simulation platform, which then links them back to steps and business processes, and finally updates the status. This status update has time uncertainty, and traditional request interaction modes cannot track this uncertainty. Therefore, developers cannot perceive the current execution progress of the business flow in a timely manner, thus requiring a server-side push technology.

[0046] Because HTTP is a stateless transport protocol, each request requires the client to establish a connection with the server. HTTPS also requires the exchange of keys. Therefore, the connection establishment process accounts for a large proportion of a single request. While HTTP 1.1 added keep-alive to maintain a long-term connection with the server, saving much of the connection establishment process, the communication process is still a 1:1 response-based approach. That is, to receive data, a request must first be sent to receive a response. Therefore, it is still not very suitable for scenarios with high real-time requirements or tight bandwidth utilization, such as real-time monitoring, push notifications, and live video streaming. SSE technology, because it can maintain the connection and continuously receive data from the server, overcomes this shortcoming.

[0047] The front-end client registers with the resource simulation platform using randomly generated clientId and taskId, generating a corresponding connection channel. It maintains the mapping relationship between the business, client, and connection through a client / connection mapping table and a business / client mapping table. When the business status is updated, the resource simulation platform finds the corresponding clientId list using the taskId, obtains the corresponding connection object through the clientId, and proactively pushes the latest business flow status to the corresponding client. If the server detects a connection timeout or the client actively closes the connection, it cleans up the mapping table.

[0048] In the resource simulation platform, there may be multiple front-end clients. Each client corresponds to a separate channel establishment and data transmission with the resource simulation platform. Therefore, the relationship between the client and the channel is 1:1. At the same time, a business flow can be listened to by multiple clients simultaneously. Therefore, the relationship between the business flow and the client is 1:n. When the business flow status is updated, the latest status data needs to be actively pushed to all clients listening to the business flow.

[0049] Subscription Channel: The front-end generates a random ID as the clientId and passes the taskId as the business flow to be listened to, subscribes to the channel from the resource simulation platform, and registers the subscription relationship.

[0050] Status push: The project under test interacts with the resource simulation platform to drive the business flow. When updating the steps and business flow status, the resource simulation platform obtains the clients listening to the business through the subscription relationship mapping table, and pushes the latest step status to these clients in turn, so as to realize the real-time update and display of the business flow status on the client.

[0051] Closing the channel: Client-side closure: The front-end actively closes the channel via the close button, and the resource simulation platform updates the subscription relationship table.

[0052] Server shutdown: Automatic protection is triggered when the channel times out or an execution error occurs. The resource simulation platform actively shuts down the channel and updates the subscription relationship table.

[0053] The business side, i.e., the project under test, typically requires specifying a URL prefix or complete URL in the configuration for the dependent resources it connects to. If a new platform needs to be connected, the destination address needs to be modified synchronously to direct traffic to the new service (the simulation platform itself is also a service). This operation is somewhat intrusive to the project under test at the configuration level, and the switching operation is very inconvenient. Therefore, a non-intrusive traffic interception and forwarding capability is needed.

[0054] This solution separates traffic forwarding logic from the client and implements it through a service mesh traffic proxy, upgrading static control to dynamic control based on traffic tags, thus improving flexibility. The usage of the service mesh in this solution differs from conventional methods. Conventional methods select service versions, i.e., multiple subsets of a service, but this solution adopts an atomic routing forwarding approach, routing forwards by attaching two different service instances to a single path or service name. This allows the project under test to simultaneously connect to real and simulated resources and enables flexible switching of traffic between the two types of resources. The invocation scenarios are divided into internal traffic invocation models and external traffic invocation models based on traffic type.

[0055] Based on transparent interception and forwarding using traffic tags, the project under test connects to both the real and simulated resource ends through a single call address. A new request element is needed as a traffic splitting tag for rule-based traffic forwarding. This solution uses the traffic splitting tag header x-mop-gray-tag as the judgment element. After receiving the x-mop-gray-tag sent by the client, the project under test passes it through, carrying the x-mop-gray-tag into the downstream module. Traffic sent by the project under test is intercepted by the service mesh as outbound traffic and forwarded to the actual destination. Therefore, the project under test needs to have the function of passing through traffic splitting tags.

[0056] The internal traffic originates within the Kubernetes cluster, calling the target resource via service name. The project under test (DUT) and the target resource reside within the same cluster. In this scenario, the DUT needs to inject the Envoy component, running as a sidecar, to intercept and forward outbound traffic. This allows the DUT to connect to both the real and simulated resource endpoints via a single path address. Simultaneously, a virtualservice resource is created for the DUT, and forwarding rules are configured within the virtualservice resource to forward traffic to either the real resource endpoint (serviceB) or the simulated resource endpoint (mock-svc) based on the same path using traffic splitting labels, as illustrated below.

[0057] Explanation: serviceA is the service under test. It is associated with both serviceB and mock-svc resources through VS resources. The rule in VS resources is that if traffic from serviceA carries an x-mop-gray-tag request header with a value of gray, it is forwarded to the mock-svc service; otherwise, it is forwarded to serviceB. For serviceA, its request address for dependent resources is http: / / serviceB:18080 / xxx. serviceB itself is unaware that there are two versions of the downstream service and forwards the request to serviceA. B or mock-svc is entirely controlled by the Envoy component, and the control strategy is the request header x-mop-gray-tag. Since serviceA itself implements the pass-through of the traffic splitting tag, the development self-testing personnel can completely determine whether serviceA accesses the real resource or the simulated resource by adding x-mop-gray-tag in the browser. When serviceB fails and blocks self-testing, the business process in serviceA can be kept running by inserting x-mop-gray-tag in the client, thereby enabling self-testing of the project under test in a decoupled resource dependency scenario.

[0058] The external traffic originates outside the Kubernetes cluster, meaning the business under test and the target resource are not in the same cluster. The business calls the target resource through the load balancing component. Therefore, the gateway component (using istio-ingressgateway here) needs to have traffic splitting capabilities to act as a reverse proxy for the business under test, enabling two services to be mounted on one path and traffic to be forwarded to the real destination through the splitting label.

[0059] Explanation: serviceA is the service to be tested, which is associated with both serviceB and mock-svc resources through VS resources. Since it is an external traffic call, the call method is not directed to the service name, but to the load balancing component (HAproxy). Assuming the call address is http: / / eop.vip.ha.core:18080 / serviceB / xxx, the traffic forwarding rules of VS are slightly different from the internal call method. It is necessary to determine the path prefix in the call path and bind it with the current forwarding rules. Then, the request traffic is forwarded to the real resource or the simulated resource by whether the x-mop-gray-tag is carried in the request header. At the same time, the traffic splitting engine is replaced by isiti-ingressgateway. isiti-ingressgateway, as the cluster ingress gateway, is responsible for intercepting and forwarding all external traffic.

[0060] In the Mybatis framework used in this solution, the first-level cache is the localCache of the PerpetualCache type of BaseExecutor. It is essentially a simple map, which is relatively primitive, has low configurability, and does not have memory protection. However, it is a session-level cache. Since the session manager can close it in a timely manner, this cache block will not be occupied by long-term saturation, so it is not expanded.

[0061] This solution extends the second-level cache in Mybatis. In a second-level cache, the cache is cross-session, thus performing better in terms of cache hit rate. Also, as a local cache, better performance is required; therefore, this solution uses Caffeine instead of the built-in Cache implementation. As a local cache, machine load needs to be considered. Therefore, when the data volume exceeds a certain threshold, dynamic adjustment is required, storing some data in a distributed caching middleware, such as Redis, i.e., adaptive adjustment, which necessitates a three-level caching mechanism.

[0062] Level 3 caching, also known as remote caching, typically uses Redis or MongoDB as storage media. This is because the storage media itself is based on memory, avoiding the overhead of memory and disk interaction, thus resulting in faster speed and cross-node (i.e., multiple instances sharing one cache).

[0063] In a three-level caching mechanism, data storage requires an adaptive strategy, dynamically adjusting based on the data volume. Data volume refers to the size of the data. First and second-level caches are local caches with limited memory space. First-level caches can be cleared when the session is closed, preventing long-term memory occupation. However, second-level caches span sessions. When the data volume is large, storing it locally puts significant memory pressure. Therefore, a threshold can be set. Data exceeding this threshold is directly cached in the third level; data below the threshold is cached locally in the second-level cache. The threshold can be dynamically adjusted based on business characteristics, enabling hot updates (when the threshold is updated, a listener detects and updates the container). The advantage of this adaptive approach is finding a balance between time and space. Traditional caching methods access the actual data source when the data is not currently cached, then store it in the current cache. However, for small datasets, directly storing them in a remote cache results in network I / O latency on subsequent database accesses, with less space pressure but greater time pressure. Conversely, storing this data locally increases memory pressure on project nodes, with greater space pressure but less time pressure. Adaptive adjustment can solve this problem.

[0064] This invention utilizes Redis's publish-subscribe model, storing a separate key-value pair in Redis as an identifier for the second-level cache. When the first node stores data in the second-level cache, it simultaneously stores a key-value pair in Redis, indicating that the second-level cache is valid. When the second node receives the same request, it stores another key-value pair in Redis; because the key is the same, this overwrites the key-value pair stored by the first node, and the same applies to the third node. All three nodes are configured to listen to this key (listen to this topic). When any node clears its local second-level cache, it simultaneously clears the second-level cache flag in the remote cache. Since two other nodes are still listening to this key, they can receive the command to clear their respective second-level caches.

[0065] This invention considers the importance of distributed cache consistency and sets up a safety mechanism for the second-level cache. A bus mechanism is used to facilitate communication between microservice nodes and clear the second-level cache. When the Redis service communication mechanism fails, the bus mechanism is activated. When one node clears its second-level cache, it publishes a message to the other two nodes. Upon receiving the message from the bus, each node clears its local second-level cache. A lightweight message broker connects the distributed nodes, which can be used to broadcast state changes (e.g., configuration changes) or other message commands. The core idea is to extend Spring Boot applications through a distributed starter, which can also be used to establish a communication channel between multiple applications. Currently, the only implementation uses an AMQP message broker as the channel.

[0066] Message buses are typically used for hot configuration updates, which involves sending a notification to each node to pull the latest configuration from the configuration center. The cache invalidation mechanism in this case adopts this idea.

[0067] When the Redis message subscription communication mechanism fails, dirty data in the local level 2 cache of each node cannot be cleared in a timely manner.

[0068] For any node, trigger the interface (curl trigger) to manually clear the cache. For example, clientA will clear its local cache and send a command to the bus. ClientB and clientC will receive the broadcast on the bus and start clearing their respective local second-level caches.

[0069] The purpose of the local cache persistence mechanism is to address the issue of the initial penalty. When the project restarts, both the first and second-level local caches are cleared. At this time, requests to the project's APIs will suddenly increase the pressure on the database, slowing down API responses and potentially crashing the database. The local cache persistence mechanism is merely a supplement to the caching mechanism in this solution for a specific scenario.

[0070] Each time data is stored in the first or second-level cache, the configuration in the configuration file determines whether the key should be persisted locally (providing flexibility at the business level). For data deemed important, it can be written back to the local file system. This step is done asynchronously by submitting a task to a queue and using a loop coroutine. When the project starts, a file with the same name as the project (on first startup) is created to store the locally persisted data. When the project restarts, the data in the file is read first to populate the local cache. Subsequent data generation checks whether it should be persisted locally; if so, it is stored in the cache file.

[0071] If data in the local cache becomes invalid, the task for invalidating the data is added to the task queue, and a dedicated loop coroutine deletes the data from the file, ensuring that expired data in the persistent file can be deleted in a timely manner.

[0072] Example 3: like Figure 2 As shown, based on Embodiment 1, this embodiment of the invention provides a client-side zero-intrusion interaction testing system under dependency decoupling, comprising: Based on a unified JSON data interaction model, interface interaction and message interaction are configurably defined. Multiple business steps are dynamically assembled into a custom business flow through a doubly linked list. The custom business flow is driven to execute, and the execution status, interaction data and link direction of each business step are tracked in real time. A compensation mechanism is provided to cover business boundary scenarios. Based on the two-layer subscription relationship formed by business, client and communication channel, the business flow status is pushed to the client or test management platform in real time through HTTP event stream or WebSocket protocol. The client-side zero-intrusion traffic control and two-way interaction module includes: Service mesh technology is used to transparently intercept request traffic from the client-side project under test without modifying the client code; based on preset traffic splitting labels and rules, the intercepted traffic is routed flexibly to the real server or the simulated server; when the traffic is routed to the simulated server, the simulated server is controlled to interact bidirectionally with the client-side project under test, including receiving client requests and returning simulated responses, or actively pushing simulated messages to the client; A multi-level adaptive caching module includes: A multi-level caching system consisting of local cache and distributed remote cache is constructed to store simulated interaction data, business step configuration information, and business flow status data; the storage location and granularity of data between local cache and remote cache are dynamically adjusted based on data access frequency, data size, and business flow execution context; and a business priority-based eviction strategy and cache consistency mechanism are adopted to maintain the validity of cached data and reduce the processing pressure on simulated server nodes. The simulated server is communicatively connected to the business flow custom dynamic orchestration and tracking module, the client-side zero-intrusion traffic control and bidirectional interaction module, and the multi-level adaptive caching module, including: Based on the interaction rules issued by the custom dynamic orchestration and tracing module of the business flow, execute bidirectional interaction with the client-side project under test; query or update simulated interaction data from the multi-level adaptive caching module; and provide feedback on the execution status of business steps to the custom dynamic orchestration and tracing module of the business flow.

[0073] Example 4 Figure 5A block diagram of an exemplary electronic device suitable for implementing embodiments of the present invention is shown.

[0074] The electronic device may include a central processing unit / microprocessor / main control chip, etc. 4; and a storage medium 5, coupled to the central processing unit / microprocessor / main control chip, etc. 4, and storing computer-executable instructions therein for performing the steps of various methods of embodiments of the present invention when executed by the processor.

[0075] The central processing unit / microprocessor / main control chip, etc., can include, but are not limited to, one or more processors or microprocessors.

[0076] Storage medium 5 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, computer storage media (e.g., hard disk, floppy disk, solid-state drive, removable disk, CD-ROM, DVD-ROM, Blu-ray disc, etc.).

[0077] In addition, the electronic device may also include (but is not limited to) a data bus 6, an input / output bus / external bus / device bus 7, a display 8, and input / output devices 9 (e.g., keyboard, mouse, speaker, etc.).

[0078] The central processing unit / microprocessor / main control chip, etc. 4 can communicate with external devices (8, 9, etc.) via I / O bus 7 through wired or wireless network (not shown).

[0079] The storage medium 5 may also store at least one computer-executable instruction for performing the steps of various functions and / or methods in the embodiments described herein when the central processing unit / microprocessor / main control chip, etc., 4 is running.

[0080] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0081] Figure 6 A schematic diagram of a computer-readable storage medium according to an embodiment of the present invention is shown.

[0082] like Figure 6As shown, the non-transitory computer-readable storage medium 11 stores instructions, such as computer-readable instructions 10. When the computer-readable instructions 10 are executed by a processor, the various methods described above can be performed. The non-transitory computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-transitory non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. For example, the non-transitory computer-readable storage medium 11 can be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions 10 stored on the computer-readable storage medium 11, the various methods described above can be performed.

[0083] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0085] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0086] If the integrated unit 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, in essence, or the part that contributes to the prior art, or all or 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 for executing all or part of the steps of the methods of the various embodiments of this invention through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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 the present invention.

Claims

1. A client-side zero-intrusion interaction testing method under dependency decoupling, characterized in that, Includes the following steps: The system features custom dynamic orchestration and tracking of business flows. It breaks down the business scenario under test into multiple business steps, each corresponding to at least one interaction, including interface interactions or message interactions. Based on a unified JSON data interaction model, it defines the interface or message interactions for each business step in a configurable manner, including request data models, response / message data models, protocol types, and interaction rules. Multiple business steps are dynamically assembled through preset relationships to form a complete custom business flow. The system drives the execution of the custom business flow, displaying the execution status, interaction data, and path of each business step in real time through a top-level view. It also provides a compensation mechanism to intervene and adjust the flow when execution is abnormal or when preset boundary conditions are reached. Zero-intrusive traffic control and bidirectional interaction on the client side: Through service mesh or similar traffic interception technology, request traffic from the client-side project under test is transparently intercepted without modifying the code of the client-side project under test. Based on preset traffic splitting labels and rules, the intercepted traffic is judged and forwarded to flexibly direct the client's project under test to the real server or the simulated server. When the traffic is directed to the simulated server, the simulated server interacts bidirectionally with the client's project under test according to the defined interface interaction or message interaction rules, including receiving client requests and returning simulated responses, or actively pushing simulated messages to the client. Based on the two-layer subscription relationship formed by business, client, and communication channels, the simulated server or business flow engine can send events through the HTTP protocol or WebSocket protocol to push the execution status of the business flow to the client or test management platform for display in real time. A multi-level adaptive caching mechanism is constructed to build a multi-level caching system including local caching and distributed remote caching, which is used to store and quickly query simulated interface interaction data, message interaction data, business step configuration information and business flow status data; Based on preset data access frequency thresholds, data size thresholds, and business flow execution context information, the storage location and granularity of data between local and remote caches are dynamically adjusted; a preset eviction policy is used to manage cached data, and data consistency between local and remote caches is maintained through a cache update notification mechanism or version control mechanism, so as to improve query speed while reducing the processing pressure on simulated server nodes.

2. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 1, characterized in that, The unified JSON data interaction model further includes: The request / response protocol model for interface interaction defines the interface's URL, method, request header, request body, response header, response body, status code, and expected response time; The publish / subscribe / consume protocol model for message interaction defines message topic / queue name, message body, message attributes, sending mode, expected delivery time, and message acknowledgment mechanism.

3. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 1, characterized in that, The dynamic assembly also allows users to drag and drop or configure the flow conditions between steps, parallel / serial execution logic, and exception jump logic through a visual interface to construct complex business scenarios. The compensation mechanism includes allowing users to configure retry strategies, degradation strategies, or preset alternative response messages for specific business steps to cover business boundary situations and abnormal scenarios.

4. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 1, characterized in that, The service mesh achieves traffic interception by deploying a Sidecar proxy. The Sidecar proxy is deployed in the same environment as the client-side project under test and transparently intercepts all external service requests issued by the client. The traffic splitting tags include, but are not limited to: client application identifier, test scenario identifier, user identifier, or specific request header fields. The traffic splitting rules allow traffic routing decisions based on the combined logic of the traffic splitting tags.

5. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 2, characterized in that, The simulation server supports both forward and reverse interaction simulations. Forward interaction simulation involves the simulation server receiving client requests and returning simulated responses. Reverse interaction simulation involves the simulation server proactively pushing simulated messages to the client's test project or its monitored message queue based on business flow execution logic or preset conditions, thereby simulating asynchronous feedback scenarios. The two-layer subscription relationship specifically involves: the client subscribing to a specific business flow, and the communication channel subscribing to a specific combination of client and business flow. When the state of the combined business flow changes, the state event is proactively pushed to the subscribed client through the corresponding communication channel.

6. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 1, characterized in that, The local cache is a cache that simulates the memory of the server node, and prioritizes storing configuration and interaction data of frequently accessed hot business steps; the distributed remote cache is an independently deployed cache cluster that stores globally shared business flow definitions, low-frequency but important interaction data, and backup data when the local cache is missed.

7. The client-side zero-intrusion interaction testing method under dependency decoupling as described in claim 1, characterized in that, The adaptive caching strategy specifically includes: When the frequency of access to interactive data in a certain business step exceeds a first preset threshold, it is promoted from the remote cache to the local cache. When the local cache space reaches the second preset threshold, low-frequency access data will be moved from the local cache to the remote cache or cleared according to the eviction policy. When a specific context is detected during the execution of a business flow, the cache priority and expiration time of the corresponding data are adjusted.

8. A client-side zero-intrusion interaction testing system under dependency decoupling, as described in any one of claims 1 to 7, characterized in that, include: The business flow custom dynamic orchestration and tracking module includes: Based on a unified JSON data interaction model, interface interaction and message interaction are configurably defined. Multiple business steps are dynamically assembled into a custom business flow through a doubly linked list. The custom business flow is driven to execute, and the execution status, interaction data and link direction of each business step are tracked in real time. A compensation mechanism is provided to cover business boundary scenarios. Based on the two-layer subscription relationship formed by business, client and communication channel, the business flow status is pushed to the client or test management platform in real time through HTTP event stream or WebSocket protocol. The client-side zero-intrusion traffic control and two-way interaction module includes: Service mesh technology is used to transparently intercept request traffic from the client-side project under test without modifying the client code; based on preset traffic splitting labels and rules, the intercepted traffic is routed flexibly to the real server or the simulated server; when the traffic is routed to the simulated server, the simulated server is controlled to interact bidirectionally with the client-side project under test, including receiving client requests and returning simulated responses, or actively pushing simulated messages to the client; A multi-level adaptive caching module includes: A multi-level caching system consisting of local cache and distributed remote cache is constructed to store simulated interaction data, business step configuration information, and business flow status data; the storage location and granularity of data between local cache and remote cache are dynamically adjusted based on data access frequency, data size, and business flow execution context; and a business priority-based eviction strategy and cache consistency mechanism are adopted to maintain the validity of cached data and reduce the processing pressure on simulated server nodes. The simulated server is communicatively connected to the business flow custom dynamic orchestration and tracking module, the client-side zero-intrusion traffic control and bidirectional interaction module, and the multi-level adaptive caching module, including: Based on the interaction rules issued by the custom dynamic orchestration and tracing module of the business flow, execute bidirectional interaction with the client-side project under test; query or update simulated interaction data from the multi-level adaptive caching module; and provide feedback on the execution status of business steps to the custom dynamic orchestration and tracing module of the business flow.

9. An electronic device, comprising: At least one memory stores computer-executable instructions non-transiently; At least one processor, configured to run the computer-executable instructions, The computer-executable instructions are implemented by the processor at runtime according to any one of claims 1-7, which is a client-side zero-intrusion interaction testing method under dependency decoupling.

10. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer-executable instructions, which, when executed by at least one processor, implement a client-side zero-intrusion interaction testing method under dependency decoupling as described in any one of claims 1-7.

Images