Mock cooperative testing method, system and terminal in multi-protocol invocation link

Abstract

This invention provides a method, system, and terminal for Mock collaborative testing in multi-protocol call chains. By carrying and propagating a Mock context at the test entry point, endpoint signatures are generated at the multi-protocol call boundaries and pre-screened based on local candidate endpoints. A Mock management center performs precise rule matching and response generation. When a Mock hits, a generic response is converted into a return object acceptable to the corresponding protocol; when a Mock misses, the real call is allowed. Request and response samples are collected, anonymized, and reported to update the endpoint request structure, response structure, and initial template drafts. This invention enables unified Mock collaboration in heterogeneous protocol call chains without modifying business code, avoiding duplicate Mock requests, reducing invalid backend access and Mock template configuration costs, and ensuring that business code continues execution along the original call stack. This improves the stability and maintainability of automated testing for complex microservices and payment chains.

Description

Technical Field

[0001] This invention relates to the field of software testing, and in particular to a Mock collaborative testing method, system, and terminal for multi-protocol call chains. Background Technology

[0002] As internet services evolve from monolithic architectures to distributed systems and microservice architectures, services such as payment, risk control, authentication, clearing, and external channel access typically involve multiple stages, including HTTP (Hypertext Transfer Protocol) requests, RPC (Remote Procedure Call) calls, external HTTP services, payment SDKs (Software Development Kits), asynchronous threads, and message tasks. These may simultaneously employ different calling frameworks such as Dubbo (a calling framework), Feign (a declarative HTTP client framework), OkHttp (an HTTP client component), HttpClient (an HTTP client), and Hessian (a remote communication mechanism). To reduce the cost of building real-world dependent systems and improve the repeatability of testing in abnormal scenarios, automated testing typically uses Mock (simulated objects / mechanisms) technology to simulate downstream interfaces or services, combined with Agent (agent / intelligent agent), SDK, distributed tracing, and context propagation technologies to manage the test pipeline.

[0003] In existing technologies, some solutions associate RPC interfaces and mock data by tracking tags, returning cached mock data when business requests carry the corresponding tags; some solutions use SDKs or pull and cache rules such as rate limiting and circuit breaking to intercept requests before they are made; some solutions generate mock data based on metadata and update the corresponding mock data synchronously when the metadata is updated; and some solutions use structured tracing tags to achieve log chain tracing of concurrent requests, or use thread pool decorators to obtain and restore context objects between threads. These technologies respectively solve problems related to interface mocking, rule retrieval, mock data maintenance, log tracing, and thread context propagation.

[0004] However, most existing solutions target a single technical aspect. In complex microservices and payment chains, the same business call may pass through both upper-layer and lower-layer calling frameworks such as Feign, OkHttp, or HttpClient. Without unified governance, duplicate mocking, logs, and rule configurations are prone to occur. Existing mocking solutions also struggle to establish stable and unified endpoint identification for heterogeneous protocols such as Dubbo, Feign, OkHttp, HttpClient, Hessian, and payment SDKs during business JVM runtime. Furthermore, existing agent or SDK solutions primarily focus on traffic governance, lacking a complete test management mechanism for endpoint reporting, mock rule configuration, execution results, hit auditing, and sample maintenance. If complete rules and template rendering are executed on the plugin side, it can easily lead to inconsistencies between the plugin and backend rule semantics; if every call accesses the backend, it increases call overhead and backend pressure.

[0005] Meanwhile, existing context propagation technologies are usually only for log tracing or thread context, making it difficult to continuously propagate information such as Mock scenario codes, test batches, traceId (trace identifier), and signatures between HTTP, RPC, asynchronous threads, and message chains; existing simulation data maintenance methods also mainly rely on manual configuration or metadata updates, lacking the ability to collect request and response samples from real non-Mock calls and use them for subsequent Mock data maintenance. Summary of the Invention

[0006] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a Mock collaborative testing method, system and terminal in a multi-protocol call chain, which can solve the problems that the prior art still has deficiencies in multi-protocol endpoint identification, repeated Mock control, cross-thread and cross-protocol context propagation, unified rule governance and maintenance of real call examples.

[0007] To achieve the above and other related objectives, a first aspect of the present invention provides a method for Mock collaborative testing in a multi-protocol call chain, comprising: obtaining test request information carrying a Mock scenario context; wherein the Mock scenario context includes at least a Mock switch, a scenario code, a test batch identifier, and a link tracing identifier; obtaining link context information based on the Mock scenario context in the test request information, and propagating the link context information in the call chain corresponding to the test request; intercepting the current protocol call at the protocol call boundary in the call chain, and obtaining the protocol type and protocol call information corresponding to the current protocol call; and performing context determination based on the link context information and the protocol call information. The process involves endpoint determination and Mock request deduplication to obtain context determination results, candidate endpoint determination results, and deduplication results. Pre-screening is performed based on these results to obtain pre-screening results. When the pre-screening result indicates that the pre-screening has passed, a Mock execution request is initiated to the Mock management center, and the Mock execution return result is received. When the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates a mismatch, the actual call corresponding to the current protocol call is allowed. After the actual call returns, samples of the actual call request and response are collected and reported to the Mock management center to update the endpoint templates and response structures of the Mock management center.

[0008] In some embodiments of the first aspect of the present invention, obtaining link context information based on the test request information includes: extracting the Mock scenario context from the test request information at the entry point of the call link; writing the Mock scenario context into a request-level context container corresponding to the current test request to obtain the link context information; writing the link tracing identifier, the test batch identifier, and the scenario code into a log context corresponding to the current test request; and cleaning up the link context information in the request-level context container after the current test request has been executed.

[0009] In some embodiments of the first aspect of the present invention, the step of intercepting the current protocol call at the protocol call boundary in the call chain and obtaining the protocol type and protocol call information corresponding to the current protocol call includes: when the current protocol call is detected to enter the corresponding protocol call boundary, intercepting the current protocol call and determining the protocol type corresponding to the current protocol call; extracting the protocol field from the protocol object corresponding to the current protocol call, and obtaining the protocol call information based on the protocol field.

[0010] In some embodiments of the first aspect of the present invention, the step of performing context determination, endpoint determination, and Mock request deduplication processing based on the link context information and the protocol call information to obtain a context determination result, a candidate endpoint determination result, and a deduplication result includes: obtaining the context determination result based on the Mock switch in the link context information and the existence status of the link context information; querying the currently effective endpoint set in the local cache based on the endpoint signature to determine whether the endpoint corresponding to the current protocol call belongs to the currently effective endpoint set in the current system, and obtaining the candidate endpoint determination result; wherein, the endpoint signature is obtained based on the protocol type of the current protocol call and the protocol call information; and performing deduplication processing on the currently existing duplicate Mock requests based on the protocol priority and call stack range marker in the protocol call information to obtain a deduplication result.

[0011] In some embodiments of the first aspect of the present invention, the step of pre-screening based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result includes: when the context determination result indicates that the Mock switch is on and the link context information is valid, the candidate endpoint determination result indicates that the endpoint corresponding to the current protocol call belongs to the current system's active endpoint set, and the deduplication result indicates that the current protocol call is the target protocol call for performing Mock determination, the pre-screening result is determined to be pre-screening passed; otherwise, the pre-screening result is determined to be pre-screening failed, and the actual call corresponding to the current protocol call is directly allowed.

[0012] In some embodiments of the first aspect of the present invention, the step of initiating a Mock execution request to the Mock management center and receiving the Mock execution return result includes: the Mock management center determining the corresponding endpoint based on the Mock execution request and the protocol call information; performing rule matching on the Mock execution request according to the protocol call information, the link context information and the endpoint to obtain the Mock execution return result; and when the Mock execution return result indicates a Mock hit, converting the general Mock response carried by the Mock execution return result into a protocol-acceptable return object according to the current protocol type.

[0013] In some embodiments of the first aspect of the present invention, the step of collecting real call request and response samples and reporting them to the Mock management center after the real call returns includes: collecting request data and response data corresponding to the real call to form the real call request and response samples; performing desensitization processing on the real call request and response samples, and writing the desensitized real call request and response samples into a local buffer; reporting the real call request and response samples in the local buffer to the Mock management center according to a scheduled task; and updating the request structure, response structure, and template draft of the corresponding endpoint based on the real call request and response samples.

[0014] In some embodiments of the first aspect of the present invention, the method further includes: allowing the real call corresponding to the current protocol call when the Mock management center response times out, rule parsing fails, response construction fails, or Mock is not enabled in the current environment.

[0015] To achieve the above and other related objectives, a second aspect of the present invention provides a Mock collaborative testing system for multi-protocol call chains, applying the Mock collaborative testing method for multi-protocol call chains as described above. The system includes: a test request acquisition module, used to acquire test request information carrying a Mock scenario context; wherein the Mock scenario context includes at least a Mock switch, a scenario code, a test batch identifier, and a link tracing identifier; an entry context module, connected to the test request acquisition module, used to obtain link context information based on the Mock scenario context in the test request information, and propagate the link context information in the call chain corresponding to the test request; a protocol interception module, connected to the entry context module, used to intercept the current protocol call at the protocol call boundary in the call chain, and obtain the protocol type and protocol call information corresponding to the current protocol call; and a determination module, connected to the protocol interception module, used to determine the link context information based on the Mock scenario context in the test request information. The system performs context determination, endpoint determination, and Mock request deduplication processing based on context information and the protocol call information to obtain context determination results, candidate endpoint determination results, and deduplication results. A pre-screening module, connected to the determination module, performs pre-screening based on the context determination results, candidate endpoint determination results, and deduplication results to obtain pre-screening results. A Mock execution decision module, connected to the pre-screening module, initiates a Mock execution request to the Mock management center and receives the Mock execution return result when the pre-screening result indicates that the pre-screening has passed. A result processing module, connected to the Mock execution decision module, allows the actual call corresponding to the current protocol call to proceed when the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates a mismatch. After the actual call returns, it collects actual call request and response samples and reports them to the Mock management center to update the endpoint templates and response structures of the Mock management center.

[0016] To achieve the above and other related objectives, a third aspect of the present invention provides an electronic terminal, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the method described above.

[0017] As described above, the Mock collaborative testing method, system, and terminal in the multi-protocol call chain of the present invention have the following beneficial effects:

[0018] This invention provides a method, system, and terminal for Mock collaborative testing in multi-protocol call chains. By carrying and propagating a Mock context at the test entry point, endpoint signatures are generated at the multi-protocol call boundaries and pre-screened based on local candidate endpoints. A Mock management center performs precise rule matching and response generation. When a Mock hits, a generic response is converted into a return object acceptable to the corresponding protocol; when a Mock misses, the real call is allowed. Request and response samples are collected, anonymized, and reported to update the endpoint request structure, response structure, and initial template drafts. This invention enables unified Mock collaboration in heterogeneous protocol call chains without modifying business code, avoiding duplicate Mock requests, reducing invalid backend access and Mock template configuration costs, and ensuring that business code continues execution along the original call stack. This improves the stability and maintainability of automated testing for complex microservices and payment chains. Attached Figure Description

[0019] Figure 1 The diagram shows a flowchart of a Mock collaborative testing method in a multi-protocol call chain according to an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram illustrating the process of the Mock management center initiating a Mock execution request in one embodiment of the present invention.

[0021] Figure 3 The diagram shows the structure of a Mock collaborative testing system in a multi-protocol call chain according to an embodiment of the present invention.

[0022] Figure 4 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of the present invention. Detailed Implementation

[0023] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0024] In embodiments of the present invention, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0025] It should be noted that in the embodiments of the present invention, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present invention should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0026] In this embodiment of the invention, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0027] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0028] <1> Mock (simulated object / simulation mechanism): refers to a pre-defined substitute object or processing mechanism used in software development, testing, or system verification to simulate real objects, modules, interfaces, services, devices, or data sources. Mock can return corresponding simulated data, status information, or processing results based on pre-defined rules, input conditions, or call requests, allowing for the testing and verification of target functions, business processes, interface interactions, or exception handling without actually calling the corresponding real objects, services, or external systems.

[0029] <2> JVM (Java Virtual Machine) is a virtualized execution environment used to run Java bytecode. It sits between Java applications and the underlying operating system and hardware resources, loading, verifying, and executing the compiled bytecode, and providing functions such as memory management, garbage collection, thread scheduling, and runtime resource management. Through the JVM, programs developed using the Java language can execute on different operating systems or hardware platforms using a unified runtime mechanism, thereby reducing the application's dependence on the specific underlying runtime environment.

[0030] <3> RPC (Remote Procedure Call) is a mechanism for communication between different processes, devices, or services. It allows the caller to request a remote service to perform a corresponding operation and obtain the result, similar to calling a local program or method. RPC typically includes request parameter encapsulation, network transmission, remote method execution, and response return. It can be used for inter-service calls in distributed systems or microservice architectures.

[0031] <4> SDK (Software Development Kit): A SDK is a set of software tools and resources provided for the development and integration of a specific software platform, service, or function. It typically includes interface programs, libraries, sample code, development documentation, and related auxiliary components. Through an SDK, applications can call corresponding functions or services according to preset interfaces, thereby reducing the difficulty of integration development between different systems or functional modules.

[0032] <5> Header (or request header): This is a data area in a network communication message used to carry message attributes, control information, or context information. Headers can carry identity identifiers, link tracing identifiers, test scenario information, signature information, and other communication control parameters, and can be transmitted between different services with each request or response. The specific data structure and delivery method of the header can vary depending on the communication protocol.

[0033] <6> Context refers to the set of information related to the current processing procedure and that needs to be maintained or passed between different execution nodes during a business request, task execution, or call chain processing. It can include tracing information, test scenario information, identity information, request attributes, and other information used to determine the current execution state. It can be propagated between different threads, services, or protocols through thread variables, HTTP headers, RPC attachments, message attributes, or other data carriers.

[0034] <7> traceId (trace identifier): This refers to identification information used to identify a business request or call chain. It is used to associate the processing of the same business request in different services, threads, processes, or calling nodes, so as to trace and identify the call path of the business request in a distributed system. The traceId can be passed between different nodes during service calls.

[0035] <8> An endpoint is a identifiable and locatable call target or boundary within a business system, used to characterize the target location corresponding to a service call, interface call, or method call. An endpoint can be determined based on the protocol type, service name, interface name, method name, request path, or other information that characterizes the call target.

[0036] <9> An Agent (or Smart Agent) is a software component deployed in the runtime environment of a business system to monitor, intercept, control, or extend the program's execution process without altering or minimizing changes to the original business code. An Agent can perform operations such as call interception, data collection, rule loading, context processing, and result reporting according to preset rules. In the Java runtime environment, an Agent can enhance target classes or methods through the extension mechanisms provided by the JVM.

[0037] <10> Boolean decision, also known as logical decision or true / false decision, is the decision-making process of a computer program during execution, which evaluates a conditional expression based on Boolean logic and outputs one of two possible results: True or False. In software systems, Boolean decision is the basic execution unit for all branching logic (such as conditional statements, loop control, and assertion verification), and its result directly determines the direction of the subsequent execution path of the program.

[0038] To facilitate understanding of the embodiments of the present invention, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 This document illustrates a flowchart of a Mock collaborative testing method for a multi-protocol call chain according to an embodiment of the present invention. The Mock collaborative testing method for a multi-protocol call chain in this embodiment mainly includes the following steps:

[0039] Step S11: Obtain test request information carrying Mock scenario context; wherein, the Mock scenario context includes at least a Mock switch, scenario code, test batch identifier, and link tracing identifier.

[0040] Specifically, this invention utilizes a test orchestration platform to create automated test cases and test plans, and triggers test requests based on the automated test cases and test plans. The test requests carry a Mock scenario context, including at least a link tracing identifier, a test batch identifier, a Mock switch, and a scenario code, to obtain test request information carrying the Mock scenario context. The test request information is then used to trigger the tested service to enter a call chain with the Mock scenario context.

[0041] It should be noted that the test orchestration platform is responsible for creating automated test cases and test plans, and for ensuring that test requests carry the aforementioned Mock scenario context. However, the test orchestration platform does not directly execute Mock rule matching. The test orchestration platform triggers the service under test through the test request, causing the service under test to enter the call chain with the aforementioned Mock context.

[0042] Step S12: Obtain link context information based on the Mock scenario context in the test request information, and propagate the link context information in the call chain corresponding to the test request.

[0043] In one embodiment, obtaining the link context information based on the test request information includes: extracting the Mock scenario context from the test request information at the entry point of the call link; writing the Mock scenario context into a request-level context container corresponding to the current test request to obtain the link context information; writing the link tracing identifier, the test batch identifier, and the scenario code into a log context corresponding to the current test request; and cleaning up the link context information in the request-level context container after the current test request is executed.

[0044] Specifically, the Mock context field carried in the test request information is extracted. This processing is executed within the business Java Virtual Machine (JVM) plugin, which is the runtime environment for running the corresponding business program. For example, at the Hypertext Transfer Protocol (HTTP) entry point or equivalent entry point, the Mock context field is extracted from the request header of the test request information, where the header is the data portion that transmits request-related information along with the HTTP request.

[0045] After extracting the Mock context field, it is determined whether the test request information carries a link tracing identifier. When the test request information carries a link tracing identifier, the link context information corresponding to the current call chain is obtained based on the carried link tracing identifier; when the test request information does not carry a link tracing identifier, a new link tracing identifier is generated, and the link context information is obtained based on the Mock context field and the newly generated link tracing identifier.

[0046] After obtaining the link context information, it is written into a request-level context container. This container stores the link context information corresponding to the current test request. Simultaneously, the link tracing identifier, test batch identifier, and scenario code are written into a Mapped Diagnostic Context (MDC) or an equivalent log context. The MDC is used to store information corresponding to the current execution context during log processing. This allows the link tracing identifier, test batch identifier, and scenario code corresponding to the current test request to be associated with the corresponding log context.

[0047] After the request processing corresponding to the test request is completed, the link context information corresponding to the current request is cleaned up, including the link context information in the request-level context container, so as to avoid retaining the context corresponding to the previous request when the thread is reused, which would cause context interference between different requests.

[0048] Furthermore, after obtaining the link context information, the link context information is propagated within the same JVM and during cross-service calls to achieve cross-thread or cross-protocol transmission of the link context information in the call chain. Specifically: when a thread switch occurs in the call chain, the link context information is propagated from the current thread to the target thread; when a cross-service call occurs in the call chain, the link context information is written into the context bearer field corresponding to the current cross-service call, and the link context information is restored on the called service side based on the context bearer field.

[0049] For example, in an asynchronous thread pool scenario, when an asynchronous task is submitted, a context snapshot of the current link context information is captured. This context snapshot records the link context state corresponding to the task submission. Before the asynchronous task is executed, the corresponding link context information is restored based on the context snapshot. After the asynchronous task is executed, the original thread state is restored or the corresponding link context information is cleaned up. Through the above processing, the link context information corresponding to the task submission stage can be propagated to the task execution stage along with the asynchronous task.

[0050] For RPC (Remote Procedure Call) protocols such as Dubbo (the calling framework), the link context information is written into attachments, and the service provider recovers the link context information from the attachment. The attachment is the carrier for transmitting the attachment context information with the RPC call, and the provider is the side that receives and processes the corresponding RPC call. Thus, the link context information can be propagated between different services with each RPC call.

[0051] For scenarios involving calls based on HTTP carriers, the link context information is written into the header, and then restored from the header at the service entry point of the called service. The HTTP carriers include Feign, OkHttp, HttpClient, and Hessian. By writing the link context information into the header, it can be passed to downstream services with the corresponding call and restored at the service entry point.

[0052] For message-based scenarios, the context field from the link context information is written into the message attributes, and the link context information is recovered from the message attributes on the consumer side. Here, the message attributes are the data portion of the context information that is transmitted along with the message, and the consumer side is the side that receives and processes the corresponding message. Thus, during message transmission, the link context information can propagate from the sending side to the consumer side along with the message.

[0053] Through the above processing, at the call chain entry point, the Mock context field is first extracted from the test request information, and a corresponding link tracing identifier is generated when no link tracing identifier is carried, so as to form link context information including at least the Mock switch, scenario code, test batch identifier, and link tracing identifier; then, the link context information is written into the request-level context container, and the link tracing identifier, test batch identifier, and scenario code are written into the log MDC or equivalent log context; in subsequent calls, the link context information is propagated and restored according to the context carrying method corresponding to the asynchronous thread pool, RPC protocol, HTTP carrier, or message-type scenario, and context restoration or cleanup is performed after the corresponding request or asynchronous task processing is completed.

[0054] Step S13: Intercept the current protocol call at the protocol call boundary in the call chain to obtain the protocol type and protocol call information corresponding to the current protocol call.

[0055] In one embodiment, intercepting the current protocol call at the protocol call boundary in the call chain to obtain the protocol type and protocol call information corresponding to the current protocol call includes: when the current protocol call is detected to enter the corresponding protocol call boundary, intercepting the current protocol call and determining the protocol type corresponding to the current protocol call; extracting protocol fields from the protocol object corresponding to the current protocol call, and obtaining the protocol call information based on the protocol fields.

[0056] Specifically, when the current protocol call in the call chain enters its corresponding protocol call boundary, the current protocol call is intercepted, and the corresponding protocol type is determined based on the protocol boundary where the current protocol call is located. After determining the protocol type corresponding to the current protocol call, the relevant protocol fields are extracted from the protocol object corresponding to the current protocol call. Here, the protocol object refers to the object that carries information related to the current protocol call during the current protocol call process; the protocol fields refer to information fields that can be obtained from the protocol object and used to characterize the current protocol call.

[0057] Based on the protocol object corresponding to different protocols or calling frameworks, necessary information such as interface name, method name, parameter type, HTTP method, path, header information, request body, service code, or SDK request object can be extracted. Specifically, the interface name identifies the interface corresponding to the current call, the method name identifies the method corresponding to the current call, and the parameter type identifies the type of the parameters in the current call; the HTTP method identifies the request method used in the current HTTP request, the path identifies the request path corresponding to the current HTTP call, the header information carried with the request, the request body carries the request data in the current request, the service code identifies the corresponding service, and the SDK request object refers to the object carrying the request information when the call is executed through the corresponding SDK.

[0058] It should be noted that different protocols or calling frameworks have different protocol objects and the protocol fields that can be extracted from them. Therefore, in this embodiment, corresponding protocol adaptation processing is performed separately for Dubbo, Feign, OkHttp, HttpClient, Hessian, payment SDK, or other protocol boundaries. Each protocol adaptation process only addresses the differences between the corresponding protocols. The protocol differences involved include interception point selection, request information extraction, acquisition of fields required to generate endpoint signatures, header or attachment injection, and construction of protocol return objects, etc., without performing complete Mock rule matching processing in each protocol adaptation process.

[0059] For step S13, the protocol adaptation process mainly performs boundary identification and interception of the current protocol call, and extracts the protocol fields required for subsequent processing from the current protocol object.

[0060] Furthermore, based on the protocol fields extracted from the current protocol object, such as interface name, method name, parameter type, HTTP method, path, header, request body, service code, or SDK request object, the protocol call information corresponding to the current protocol call is obtained. Here, "protocol call information" is a general term for the relevant information extracted during the current protocol call. The specific fields it includes are determined by the protocol type and protocol object corresponding to the current protocol call; different protocol types are not required to have completely identical field compositions.

[0061] Step S14: Perform context determination, endpoint determination, and Mock request deduplication processing based on the link context information and the protocol call information to obtain context determination results, candidate endpoint determination results, and deduplication results.

[0062] In one embodiment, the step of performing context determination, endpoint determination, and Mock request deduplication processing based on the link context information and the protocol call information to obtain the context determination result, candidate endpoint determination result, and deduplication result includes: obtaining the context determination result based on the Mock switch in the link context information and the existence status of the link context information; querying the currently effective endpoint set in the local cache based on the endpoint signature to determine whether the endpoint corresponding to the current protocol call belongs to the currently effective endpoint set in the current system, and obtaining the candidate endpoint determination result; wherein, the endpoint signature is obtained based on the protocol type of the current protocol call and the protocol call information; and performing deduplication processing on the currently existing duplicate Mock requests based on the protocol priority and call stack range marker in the protocol call information to obtain the deduplication result.

[0063] Specifically, the context determination result is obtained based on the Mock switch in the link context information and the existence status of the link context information. Therefore, when the current protocol call reaches the corresponding processing position, the existence of the Mock switch and the link context information is determined, and the context determination result is formed based on the determination result for subsequent candidate pre-screening. The context determination result includes: context valid or invalid, Mock switch on or off.

[0064] Furthermore, the endpoint signature is used to query the locally stored set of currently active endpoints in the system to determine whether the endpoint corresponding to the current protocol call belongs to the set of currently active endpoints in the system, and the candidate endpoint determination result is obtained accordingly. The set of currently active endpoints in the system is a set of endpoints that are issued by the Mock management center and stored locally on the call processing side, used to represent endpoints that are currently active in the system. In addition to the set of currently active endpoints in the system, the corresponding rule version and necessary metadata are also stored locally, wherein the necessary metadata is data used to support the processing of the corresponding endpoints that are stored together with the set of active endpoints.

[0065] The endpoint signature is obtained based on the protocol type of the current protocol call and the protocol call information. That is, according to different protocol types, a stable endpoint signature is constructed using information corresponding to the corresponding protocol type, so that similar protocol calls can form corresponding endpoint identifiers according to the corresponding protocol fields.

[0066] For example, when the current protocol call is an RPC-type call, the RPC-type endpoint can consist of an interface name, a method name, and parameter types. The interface name represents the interface corresponding to the current remote call, the method name represents the method that initiates the call under that interface, and the parameter types represent the parameter types used in the corresponding method call. Based on the interface name, method name, and parameter types, an endpoint signature corresponding to the current RPC-type protocol call can be formed.

[0067] When the current protocol call is an HTTP class call, the HTTP class endpoint can be composed of a protocol type, an HTTP method, a host, and a path template. Based on the protocol type, HTTP method, host, and path template, an endpoint signature corresponding to the current HTTP class protocol call can be formed.

[0068] When the current protocol call is a Hessian-type call, the Hessian-type endpoint can consist of a service port and a business service code. Based on the service port and business service code, an endpoint signature corresponding to the current Hessian-type protocol call can be generated.

[0069] When the current protocol call is a payment SDK class call, request information is extracted based on the SDK object corresponding to the payment SDK, and an endpoint signature corresponding to the current payment SDK class call is formed based on the extracted request information. Here, the SDK object refers to the object used to carry the corresponding request information during the payment SDK call. For the payment SDK class call, request information is extracted according to the corresponding SDK object within the current call chain. In subsequent interactions with the backend, the endpoint corresponding to this payment SDK class call can be represented as a generic HTTP endpoint.

[0070] When determining candidate endpoints, the endpoint signature corresponding to the current protocol call is used as the query basis to search the set of currently active endpoints in the system. If the endpoint corresponding to the current protocol call can be determined based on the endpoint signature to belong to the set of currently active endpoints in the system, a candidate endpoint determination result is formed, indicating that the current endpoint meets the candidate endpoint conditions. Conversely, if the endpoint corresponding to the current protocol call does not belong to the set of currently active endpoints in the system, a corresponding candidate endpoint determination result is formed. Through this process, candidate determination is performed locally only based on conditions such as the presence of Mock switch, link context information, and whether the endpoint is already enabled.

[0071] It should be noted that the local processing described above does not save complete rule expressions, nor does it render complex response templates locally. Complete rule matching and complex response template processing are not executed during the current local candidate evaluation process. Therefore, the local process only handles candidate pre-screening and does not form another complete set of rule processing logic. This also reduces the performance overhead caused by accessing the backend for each actual call.

[0072] Furthermore, Mock request deduplication is performed based on the aforementioned protocol call information. This deduplication process addresses situations where a higher-level logic protocol call within the same call chain further triggers a lower-level transport protocol call. The protocol call requiring Mock determination is determined based on its protocol priority and call stack range marker.

[0073] Specifically, when an upper-layer logic protocol triggers an lower-layer transport protocol, deduplication is performed based on the protocol priority and the call stack range marker to avoid the upper-layer logic protocol call and the lower-layer transport protocol call it triggers repeatedly sending Mock requests to the Mock management center. Taking a Feign call that further triggers an underlying OkHttp or HttpClient call as an example, Feign, as the logical endpoint, is responsible for the Mock determination of the current call, while the underlying OkHttp or HttpClient only acts as a transport endpoint for recording or sampling, and does not make a second request to the Mock management center for the same call. Here, Feign corresponds to the upper-layer logic call, and OkHttp and HttpClient correspond to the underlying HTTP transport calls triggered by this logic call.

[0074] After processing the current call relationship based on the aforementioned protocol priority and call stack range markings, the deduplication result is obtained. In principle, only one endpoint is allowed to execute the mock within the same call chain, thereby avoiding repeated execution of mock requests for the same logical call when multiple layers of protocol calls are involved.

[0075] Step S15: Perform pre-screening based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result.

[0076] In one embodiment, the pre-screening based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result includes: when the context determination result indicates that the Mock switch is on and the link context information is valid, the candidate endpoint determination result indicates that the endpoint corresponding to the current protocol call belongs to the current system's active endpoint set, and the deduplication result indicates that the current protocol call is the target protocol call for performing Mock determination, the pre-screening result is determined to be pre-screening passed; otherwise, the pre-screening result is determined to be pre-screening failed, and the actual call corresponding to the current protocol call is directly allowed.

[0077] Specifically, Boolean decision is used to pre-screen the context determination result, the candidate endpoint determination result, and the deduplication result to obtain a pre-screening result. The pre-screening decision can be expressed as:

[0078] ;

[0079] in, This indicates the pre-screening results, including those who passed and those who failed. Indicates the first One protocol call; Indicates the contextual determination result; Indicates the candidate endpoint determination result; This indicates the result of deduplication; Represents the logical AND operator.

[0080] That is, based on the context determination result, it is determined whether the link context information corresponding to the current protocol call meets the Mock processing conditions. When the Mock context exists and the Mock switch in the link context information is in the on state, it indicates that the current protocol call meets the corresponding Mock processing conditions at the context level; when the Mock context does not exist or the Mock switch is not in the on state, the corresponding conditions are not met.

[0081] Further, based on the candidate endpoint determination result, it is determined whether the endpoint corresponding to the current protocol call meets the Mock candidate condition. Specifically, based on the aforementioned candidate endpoint determination result, it is determined whether the endpoint corresponding to the current protocol call belongs to the locally stored set of currently active endpoints in the system. When the endpoint corresponding to the current protocol call belongs to the set of currently active endpoints in the system, it indicates that the endpoint meets the candidate endpoint condition; when the endpoint does not exist in the locally enabled candidate set, the corresponding candidate endpoint condition is not met.

[0082] Further, based on the deduplication result, it is determined whether the current protocol call is the target protocol call for performing Mock determination in the current call chain. The target protocol call refers to the protocol call retained in the current call chain for performing Mock determination after the aforementioned Mock request deduplication processing. When the deduplication result indicates that the current protocol call is the target protocol call for performing Mock determination, the current protocol call meets the pre-screening conditions for deduplication; when the deduplication result indicates that the current protocol call is not the target protocol call for performing Mock determination, the current protocol call will not be allowed to enter the subsequent Mock execution process.

[0083] Based on this, when the context determination result indicates that the Mock switch is on and the link context information is valid, the candidate endpoint determination result indicates that the endpoint corresponding to the current protocol call belongs to the current system's active endpoint set, and the deduplication result indicates that the current protocol call is the target protocol call for performing Mock determination, the pre-screening result is determined to be pre-screened and passed, so that the current protocol call can continue to enter the subsequent Mock processing process.

[0084] If any of the above pre-screening conditions is not met, the pre-screening result is determined to be a failure. The corresponding protocol call will not proceed to the subsequent Mock processing; instead, the actual call corresponding to the current protocol call will be allowed to proceed directly. Here, the actual call refers to a call that does not use the Mock return result to replace the current protocol call, but continues to execute the corresponding call according to the original call process of the current protocol call.

[0085] Step S16: When the pre-screening result indicates that the pre-screening has passed, initiate a Mock execution request to the Mock management center and receive the Mock execution return result; when the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates that the match has not occurred, allow the real call corresponding to the current protocol call, and collect real call request and response samples after the real call returns and report them to the Mock management center to update the endpoint template and response structure of the Mock management center.

[0086] In one embodiment, initiating a Mock execution request to the Mock management center and receiving the Mock execution return result includes: the Mock management center determining the corresponding endpoint based on the Mock execution request and the protocol call information; performing rule matching on the Mock execution request according to the protocol call information, the link context information, and the endpoint to obtain the Mock execution return result; and when the Mock execution return result indicates a Mock hit, converting the general Mock response carried by the Mock execution return result into a protocol-acceptable return object according to the current protocol type.

[0087] In one embodiment, the step of collecting real call request and response samples and reporting them to the Mock management center after the real call returns includes: collecting request data and response data corresponding to the real call to form real call request and response samples; performing desensitization processing on the real call request and response samples and writing the desensitized real call request and response samples into a local buffer; reporting the real call request and response samples in the local buffer to the Mock management center according to a scheduled task; and updating the request structure, response structure, and template draft of the corresponding endpoint based on the real call request and response samples.

[0088] In one embodiment, the method further includes: allowing the real call corresponding to the current protocol call when the Mock management center response times out, rule parsing fails, response construction fails, or Mock is not enabled in the current environment.

[0089] Specifically, after obtaining the pre-screening result in step S15, it is determined whether the current protocol call should enter the Mock execution process or continue executing the corresponding real call based on the pre-screening result. When the pre-screening result indicates that the pre-screening has passed, a Mock execution request for the current protocol call is initiated to the Mock management center; when the pre-screening result indicates that the pre-screening has failed, the Mock execution request is not initiated to the Mock management center, and the real call corresponding to the current protocol call is allowed to proceed.

[0090] like Figure 2As shown, the process of the Mock management center initiating a Mock execution request is represented as follows:

[0091] Step S611: Determine whether the Mock management center should initiate a Mock execution request based on the pre-screening results;

[0092] Step S612: When the pre-screening result indicates that the pre-screening has passed, initiate a Mock execution request to the Mock management center;

[0093] Step S613: Receive the return result of the Mock execution;

[0094] Step S614: When the Mock execution return result indicates a hit, convert the general Mock response carried by the Mock execution return result into a protocol-acceptable return object according to the current protocol type;

[0095] Step S615: When the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates that the match has not occurred, allow the real call corresponding to the current protocol call;

[0096] Step S616: Collect the request data and response data corresponding to the actual call, form the actual call request and response sample, perform desensitization processing on the actual call request and response sample, and write the desensitized actual call request and response sample into the local buffer.

[0097] Step S617: Report the actual call requests and response samples in the local buffer to the Mock management center according to the scheduled task;

[0098] Step S618: Based on the actual call request and response examples, the Mock management center updates the request structure, response structure, and template draft of the corresponding endpoint.

[0099] Furthermore, when the pre-screening result indicates that the pre-screening has passed, a Mock execution request is generated and sent. The Mock execution request includes a system identifier, endpoint signature, request header, request body, or necessary protocol parameters, and performs subsequent matching in conjunction with the scenario code in the aforementioned link context information.

[0100] After receiving the Mock execution request, the Mock management center can determine the endpoint corresponding to the current Mock execution request based on the system identifier and the endpoint signature, and perform rule matching on the determined endpoint.

[0101] During rule matching, precise matching is performed based on the scenario code, request header, request body, rule priority, and template configuration. The rule priority represents the priority relationship among multiple rules being matched; the template configuration limits the request matching fields and response structure that can be configured for the corresponding endpoint. After precise matching is completed, a corresponding Mock response is generated based on the matching result, and the Mock execution return result is obtained. This process can be expressed by the following formula:

[0102] ;

[0103] in, This indicates the return result after the current protocol calls Mock to execute the request; Indicates the protocol to which the current endpoint signature belongs; This indicates the preliminary screening results; Indicates the matching result; Indicates a Boolean decision; Represents the logical AND operation.

[0104] The mock execution return result includes mock hit and mock miss. In one specific implementation, a mock hit corresponds to `matched=true`, indicating that the current mock execution request successfully matches the corresponding mock rule; a mock miss corresponds to `matched=false`, indicating that the current mock execution request did not successfully match the corresponding mock rule. Therefore, the mock execution return result determines whether the current protocol call should use a mock response or continue executing the corresponding real call.

[0105] When the Mock execution returns a result indicating a Mock hit, a generic Mock response is obtained from the Mock management center, and the generic Mock response is converted into a return object acceptable to the current protocol call point according to the current protocol type.

[0106] For example, for Remote Procedure Call (RPC), the generic Mock response is converted into a return object or exception wrapper corresponding to the business method declaration.

[0107] For Hypertext Transfer Protocol (HTTP) client calls, the generic Mock response is converted into the response object of the corresponding HTTP client to adapt to the return format accepted by the current HTTP client.

[0108] For calls to the Payment Software Development Kit (SDK), the generic mock response is converted into a response encapsulation that can be further deserialized by the Payment SDK. Deserialization refers to converting the received response data into an object format that the Payment SDK can subsequently process.

[0109] For streaming interface calls, the generic Mock response is converted into a streaming response that can be further read by the corresponding streaming interface. By performing the above-mentioned return object conversion according to the current protocol type, the return object formed after a Mock hit can continue execution along the original call stack of the current business code, so that the business code does not need to be aware that the current return data comes from the Mock management center. Here, the call stack is used to represent the execution relationship formed between different call layers during the current business call.

[0110] Furthermore, when the Mock execution returns a result indicating a Mock miss, the actual call corresponding to the current protocol call is allowed to proceed. Besides Mock misses, when there is a timeout in the Mock management center response, rule parsing failure, response construction failure, or when Mock is not enabled in the current environment, the Mock response is not used to replace the current protocol call; instead, the actual call corresponding to the current protocol call is downgraded. Here, downgrading to a real call means stopping the current Mock execution path and continuing to execute the actual call according to the original method of the current protocol call.

[0111] When the endpoint corresponding to the current protocol call has not been configured or the Mock execution return result indicates that the Mock was not hit, after the real call is completed and the real return is obtained, the request data and response data corresponding to the real call are collected to form a real call request and response example.

[0112] After obtaining the actual call request and response samples, the collected samples are anonymized, and the anonymized actual call request and response samples are written to a local buffer. The anonymization process is used to filter sensitive data from the collected samples; the local buffer is used to temporarily store the anonymized actual call request and response samples. Subsequently, a scheduled task reports the actual call request and response samples in the local buffer to the Mock management center.

[0113] After receiving the reported real call requests and response samples, the Mock management center updates the request structure, response structure, and initial template draft of the corresponding endpoint based on the real call requests and response samples. The updated content can then be used by testers or developers to configure subsequent Mock rules.

[0114] Preferably, the content managed by the Mock management center includes endpoint directories, templates, scenarios, rules, examples, hit logs, permissions, and auditing. Specifically, the endpoint directory manages the corresponding endpoints and supports unconfirmed, confirmed, configured, and published states; the templates define the configurable request matching fields and response structures for the corresponding endpoints; the scenarios combine multiple endpoint rules; the rules perform final matching on Mock execution requests and generate corresponding responses; the examples correspond to the collected and reported request and response examples; the hit logs record the hit status of Mock rules; and the permissions and auditing correspond to the permission management and auditing content for Mock-related operations. The Mock management center does not intrude on business code and does not directly execute the aforementioned construction of protocol return objects for different protocol types.

[0115] To better illustrate the technical effects of the Mock collaborative testing method in the multi-protocol call chain of the present invention, the following specific embodiments are provided.

[0116] Example 1: Internal RPC Call Mock

[0117] An automated test case needs to verify that a downstream service returns a specified status after a successful order creation. The test orchestration platform sends a request to the entry service, carrying the traceId, test batch, Mock switch, and scenario code. The business JVM plugin establishes a Mock context at the entry point. When the entry service calls the downstream RPC interface, the RPC protocol interception module generates an endpoint. The plugin then makes a judgment. After all values ​​are true, a request is made to the Mock management center to perform rule matching. The backend returns matched=true and a Mock response based on the scenario code and request parameters. The plugin converts this response into a return object acceptable to the RPC framework and short-circuits the actual downstream call.

[0118] Technical benefits: Testers can return preset results for specified RPC calls without starting real downstream services or modifying business code; at the same time, the hit logs are associated with the traceId, which facilitates report display.

[0119] Example 2: Deduplication between Feign and the underlying HTTP client

[0120] A certain business service calls an external interface through the Feign Client. Feign uses OkHttp or HttpClient at its underlying level. When the Feign module enters the interception, it generates a logical endpoint and sets the source protocol flag within the call stack. If the Feign endpoint has been mocked, the underlying HTTP call will not occur; if Feign has not been mocked and allows the real call, the underlying HTTP module, after detecting the source protocol flag, will not access the Mock management center again, but will only perform necessary trace injection or sample collection.

[0121] Technical benefits: Avoids repeated mocking of the same business call in the Feign layer and HTTP client layer, reduces duplicate rule configurations and duplicate hit records, and improves the determinism of test results.

[0122] Example 3: Payment SDK calls Mock

[0123] A business service calls a third-party payment SDK. This SDK internally encapsulates HTTP requests, and the business code cannot directly obtain the URL (Uniform Resource Locator), header, or response object construction details. A plugin intercepts the SDK's request method, extracts the request method, path, header, and request body through reflection or an adapter, and exposes them to the backend as a generic HTTP endpoint. When a backend rule is matched, the plugin does not directly return a plain JSON (JavaScript Object Notation) string, but instead constructs a response encapsulation that the payment SDK can further deserialize; if it is a streaming response, it constructs a readable streaming response object.

[0124] Technical effect: Without adding a new dedicated backend protocol for payment channels, it supports the mocking of requests encapsulated within the SDK, reducing the complexity of the backend protocol, while ensuring that the business side still processes and returns according to the original SDK logic.

[0125] Example 4: Asynchronous Threads and Downstream Call Context Propagation

[0126] After a request enters the business service from an entry point, it submits an asynchronous task. This asynchronous task then calls downstream services. The plugin captures a snapshot of the Mock context and log context when the task is submitted, restores them before task execution, and cleans them up after the task ends. Downstream protocol calls within the asynchronous task can still read the same traceId and scene code and enter the Mock judgment according to the same rules.

[0127] Technical effect: Avoids the loss of Mock context caused by asynchronous thread pools, and ensures the continuity of test scenarios in complex asynchronous business chains.

[0128] Example 5: Feedback on Missed Samples

[0129] If a certain endpoint lacks configured rules, the plugin's pre-screening fails, or the backend returns `matched=false`. The plugin then allows the actual call and collects the request header, request body, response body, and status information upon receiving the actual response. The collected data is anonymized and written to a local buffer, then sent to the Mock management center via a reporting task. The backend updates the request and response structures for this endpoint based on the sample, allowing testers to quickly generate templates and rules.

[0130] Technical benefits: Reduces the workload of manually writing complex request / response templates and makes the Mock rule configuration closer to the real call structure.

[0131] Figure 3 This is a schematic diagram of the structure of a Mock collaborative testing system in a multi-protocol call chain provided by an embodiment of the present invention. Figure 3 As shown, the system includes:

[0132] Test request acquisition module 1 is used to acquire test request information carrying Mock scene context; wherein, the Mock scene context includes at least Mock switch, scene code, test batch identifier and link tracing identifier;

[0133] Entry context module 2, connected to the test request acquisition module 1, is used to obtain link context information based on the Mock scenario context in the test request information, and to propagate the link context information in the call chain corresponding to the test request;

[0134] Protocol interception module 3, connected to the entry context module 2, is used to intercept the current protocol call at the protocol call boundary in the call chain and obtain the protocol type and protocol call information corresponding to the current protocol call;

[0135] The determination module 4, connected to the protocol interception module 3, is used to perform context determination, endpoint determination, and Mock request deduplication processing based on the link context information and the protocol call information, and to obtain the context determination result, candidate endpoint determination result, and deduplication result.

[0136] The pre-screening module 5 is connected to the determination module 4 and is used to perform pre-screening based on the context determination result, the candidate endpoint determination result and the deduplication result to obtain the pre-screening result.

[0137] The Mock execution decision module 6 is connected to the pre-screening module 5 and is used to initiate a Mock execution request to the Mock management center and receive the Mock execution return result when the pre-screening result indicates that the pre-screening has passed.

[0138] The result processing module 7 is connected to the Mock execution decision module 6. When the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates that the real call corresponding to the current protocol call is allowed, and after the real call returns, the real call request and response sample is collected and reported to the Mock management center to update the endpoint template and response structure of the Mock management center.

[0139] It should be understood that the specific process of each module performing the above-mentioned steps has been described in detail in the above method embodiments, and will not be repeated here for the sake of brevity.

[0140] It should also be understood that the module division in the embodiments of the present invention is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of the present invention can be integrated into a single processor, exist as separate physical entities, or two or more modules can be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0141] Figure 4 This is a schematic block diagram of an electronic terminal provided in an embodiment of the present invention. Figure 4 As shown, the electronic terminal 400 includes at least one processor 401, a memory 402, at least one network interface 403, and a user interface 405. The various components in the electronic terminal 400 are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 4 The general will label all buses as bus systems.

[0142] The user interface 405 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0143] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0144] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the electronic terminal 400. Examples of this data include: any executable program for operation on the electronic terminal 400, such as the operating system 4021 and application program 4022; the operating system 4021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 4022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The Mock collaborative testing method in the multi-protocol call chain provided in this embodiment of the invention can be included in the application program 4022.

[0145] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the Mock collaborative testing method in the multi-protocol call link provided in the embodiments of the present invention can be directly reflected as the hardware decoding processor executing the steps, or by combining the hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0146] In an exemplary embodiment, the electronic terminal 400 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0147] In summary, this invention provides a method, system, and terminal for Mock collaborative testing in multi-protocol call chains. By carrying and propagating the Mock context at the test entry point, endpoint signatures are generated at the multi-protocol call boundaries and pre-screened based on local candidate endpoints. The Mock management center performs precise rule matching and response generation. When a Mock hits, the general response is converted into a return object acceptable to the corresponding protocol; when a Mock misses, the real call is allowed. Request and response samples are collected, anonymized, and reported to update the endpoint request structure, response structure, and initial template draft. This invention enables unified Mock collaboration in heterogeneous protocol call chains without modifying business code, avoiding duplicate Mock requests, reducing invalid backend access and Mock template configuration costs, and ensuring that business code continues execution along the original call stack, thus improving the stability and maintainability of automated testing for complex microservices and payment chains.

[0148] Therefore, this invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0149] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for mock collaborative testing in a multi-protocol call chain, characterized in that, include: Obtain test request information carrying a Mock scenario context; wherein, the Mock scenario context includes at least a Mock switch, a scenario code, a test batch identifier, and a link tracing identifier; Based on the Mock scenario context in the test request information, the link context information is obtained and propagated in the call chain corresponding to the test request. Intercept the current protocol call at the protocol call boundary in the call chain to obtain the protocol type and protocol call information corresponding to the current protocol call. Based on the link context information and the protocol call information, perform context determination, endpoint determination and Mock request deduplication to obtain context determination result, candidate endpoint determination result and deduplication result; Pre-screening is performed based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result; When the pre-screening result indicates that the pre-screening has passed, a Mock execution request is initiated to the Mock management center, and the Mock execution return result is received; when the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates that the match has not occurred, the real call corresponding to the current protocol call is allowed, and after the real call returns, the real call request and response sample is collected and reported to the Mock management center to update the endpoint template and response structure of the Mock management center.

2. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The process of obtaining link context information based on the test request information includes: Extract the Mock scenario context from the test request information at the entry point of the call chain; Write the Mock scenario context into the request-level context container corresponding to the current test request to obtain the link context information; Write the link tracing identifier, the test batch identifier, and the scenario code into the log context corresponding to the current test request; After the current test request is completed, the link context information in the request-level context container is cleaned up.

3. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The step of intercepting the current protocol call at the protocol call boundary in the call chain and obtaining the protocol type and protocol call information corresponding to the current protocol call includes: When the current protocol call is detected to have entered the corresponding protocol call boundary, the current protocol call is intercepted, and the protocol type corresponding to the current protocol call is determined. Extract the protocol fields from the protocol object corresponding to the current protocol call, and obtain the protocol call information based on the protocol fields.

4. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The step of performing context determination, endpoint determination, and Mock request deduplication based on the link context information and the protocol call information to obtain context determination results, candidate endpoint determination results, and deduplication results includes: The context determination result is obtained based on the Mock switch in the link context information and the existence status of the link context information; The endpoint signature is used to query the set of currently active endpoints in the local cache to determine whether the endpoint corresponding to the current protocol call belongs to the set of currently active endpoints in the system, and to obtain the candidate endpoint determination result; wherein, the endpoint signature is obtained based on the protocol type of the current protocol call and the protocol call information; Based on the protocol priority and call stack range marker in the protocol call information, the existing duplicate Mock requests are deduplicated to obtain the deduplication result.

5. The Mock collaborative testing method in a multi-protocol call chain according to claim 4, characterized in that, The step of performing pre-screening based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result includes: When the context determination result indicates that the Mock switch is on and the link context information is valid, the candidate endpoint determination result indicates that the endpoint corresponding to the current protocol call belongs to the current system's active endpoint set, and the deduplication result indicates that the current protocol call is the target protocol call for performing Mock determination, the pre-screening result is determined to be pre-screened and passed. Otherwise, if the pre-screening result is determined to be a failure, the actual call corresponding to the current protocol call will be directly allowed.

6. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The process of initiating a Mock execution request to the Mock management center and receiving the Mock execution return result includes: The Mock management center determines the corresponding endpoint based on the Mock execution request and the protocol call information; Based on the protocol call information, the link context information, and the endpoint, the Mock execution request is matched according to rules to obtain the Mock execution return result. When the Mock execution return result indicates that the Mock is hit, the general Mock response carried by the Mock execution return result is converted into a protocol-acceptable return object according to the current protocol type.

7. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The step of collecting real call request and response samples after the real call returns and reporting them to the Mock management center includes: Collect the request and response data corresponding to the actual call to form the actual call request and response examples; The actual call request and response samples are de-identified, and the de-identified actual call request and response samples are written into the local buffer. The actual call requests and response samples in the local buffer are reported to the Mock management center according to the scheduled task. Based on the actual call request and response examples, the Mock management center updates the request structure, response structure, and initial template draft of the corresponding endpoint.

8. The Mock collaborative testing method in a multi-protocol call chain according to claim 1, characterized in that, The method further includes: When the Mock management center responds with a timeout, rule parsing fails, response construction fails, or Mock is not enabled in the current environment, the actual call corresponding to the current protocol call is allowed.

9. A Mock collaborative testing system for multi-protocol call chains, employing the Mock collaborative testing method for multi-protocol call chains as described in any one of claims 1 to 8, characterized in that, The system includes: The test request acquisition module is used to acquire test request information carrying a Mock scenario context; wherein, the Mock scenario context includes at least a Mock switch, a scenario code, a test batch identifier, and a link tracing identifier; The entry context module, connected to the test request acquisition module, is used to obtain link context information based on the Mock scenario context in the test request information, and to propagate the link context information in the call chain corresponding to the test request. The protocol interception module, connected to the entry context module, is used to intercept the current protocol call at the protocol call boundary in the call chain and obtain the protocol type and protocol call information corresponding to the current protocol call. The determination module, connected to the protocol interception module, is used to perform context determination, endpoint determination, and Mock request deduplication processing based on the link context information and the protocol call information, and to obtain the context determination result, candidate endpoint determination result, and deduplication result. A pre-screening module, connected to the determination module, is used to perform pre-screening based on the context determination result, the candidate endpoint determination result, and the deduplication result to obtain the pre-screening result; The Mock execution decision module, connected to the pre-screening module, is used to initiate a Mock execution request to the Mock management center and receive the Mock execution return result when the pre-screening result indicates that the pre-screening has passed. The result processing module, connected to the Mock execution decision module, is used to allow the real call corresponding to the current protocol call when the pre-screening result indicates that the pre-screening has failed or the received Mock execution return result indicates that the call has not been hit. After the real call returns, the module collects real call request and response samples and reports them to the Mock management center to update the endpoint template and response structure of the Mock management center.

10. An electronic terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1 to 8.

Images