Interface automation test adaptation method and device for gRPC proxy encapsulation mechanism
Patent Information
- Application Number
- CN202611379953.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-07
- Publication Date
- 2026-11-03
AI Technical Summary
Existing automated interface testing solutions suffer from problems such as complex request construction, unreadable response data, difficulty in anomaly diagnosis, and difficulty in reusing assertion logic when dealing with gRPC proxy encapsulation mechanisms.
This paper presents an interface automation testing adaptation method for gRPC proxy encapsulation mechanism. By building an adaptive adaptation layer on the test execution engine side, it automatically identifies parameter forms and performs serialization and encoding conversion, decodes response data, and encapsulates it into a unified response object, thereby achieving automation of request construction and response parsing and unification of assertions.
It lowers the barrier to entry for writing test cases, avoids errors in manual coding, improves the readability and efficiency of tests, supports unified processing of exception information and batch verification calls, and enhances the completeness and execution efficiency of tests.
Smart Images
Figure CN123030508A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of software testing, interface automated testing, gRPC communication, and serialized data processing, specifically to an interface automated testing adaptation method and apparatus for gRPC proxy encapsulation mechanism. Background Technology
[0002] In a microservice architecture, backend services often communicate with each other using a Remote Procedure Call (RPC) framework. To reduce external debugging and testing costs, some systems provide a unified gRPC proxy service. This service receives the target service identifier, target method identifier, parameter type list, and parameter data through a proxy interface, and then forwards them to the actual business method.
[0003] However, existing automated interface testing solutions have significant drawbacks when dealing with such gRPC proxy encapsulation mechanisms: on the one hand, testers need to manually construct complex object parameters according to the binary serialization rules and outer encoding rules agreed upon by the proxy interface, which is prone to call failure due to inconsistencies in type or encoding level, resulting in high request construction costs; on the other hand, the business data in the proxy response is usually returned as byte fields, which cannot be directly used for structured assertions or report display, and the underlying gRPC status codes, proxy business codes, and error details are scattered in different locations, lacking a unified response encapsulation mechanism, resulting in poor readability of test results, difficulty in anomaly diagnosis, and difficulty in reusing assertion logic. Summary of the Invention
[0004] Purpose of the invention: The purpose of this invention is to solve the technical problems in the prior art and provide an automated testing adaptation method and apparatus for gRPC proxy encapsulation mechanism.
[0005] Technical solution:
[0006] In the first aspect, this application provides an interface automation testing adaptation method for gRPC proxy encapsulation mechanism, including: reading test case configuration to obtain the proxy service address, target service identifier, target method identifier, parameter type list and parameter data of the gRPC proxy interface to be tested;
[0007] The parameter carrying method is determined based on the parameter form of the parameter data, and a gRPC proxy request message is constructed based on the target service identifier, the target method identifier, the parameter type list, and the parameter carrying method.
[0008] Send the gRPC proxy request message to the proxy service address via the gRPC channel, and receive the proxy response message;
[0009] When the proxy response message contains byte response data, the byte response data is restored based on the response decoding and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism to obtain a structured response object or a scalar response value.
[0010] The gRPC status code, gRPC status description, proxy business information, and the structured response object or scalar response value are encapsulated into a unified response object.
[0011] Perform test assertions based on the unified response object.
[0012] The above solution establishes an adaptive adaptation layer for the gRPC proxy encapsulation mechanism on the test execution engine side. It can automatically route request construction logic according to parameter form and reverse restore the byte data in the response. Finally, it integrates multi-dimensional state information and business data into a unified response object, thereby eliminating the testing barriers caused by proxy encapsulation and realizing configurable automatic testing of complex proxy interfaces.
[0013] As one implementation method, the parameter format of the parameter data determines the parameter carrying method, including:
[0014] When the parameter data is a list of ordinary parameters, the list of ordinary parameters is mapped to the ordinary parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism;
[0015] When the parameter data is a list of complex object parameters, based on the parameter type list and the serialization and encoding rules agreed upon by the gRPC proxy encapsulation mechanism, each complex object parameter in the list of complex object parameters is parsed into a byte parameter, and the byte parameter is mapped to the byte parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism.
[0016] This implementation method ensures that the test engine is compatible with the existing mixed parameter passing mode of the proxy interface by distinguishing the carrying paths of ordinary parameters and complex object parameters, thus avoiding protocol format errors caused by misjudgment of parameter types.
[0017] As one implementation, the serialization rule includes Hessian2 serialization rules, the encoding rule includes Base64 encoding rules, and the step of parsing each complex object parameter in the complex object parameter list into byte parameters includes: determining the type name corresponding to the current complex object parameter; generating a Hessian2 class definition based on the type name and the field set of the current complex object parameter; generating byte sequences of Hessian2 basic type, list type, mapping type, or object type according to the field value type of each field in the field set; performing Base64 encoding on the generated Hessian2 byte sequence to obtain a Base64 encoded string; decoding the Base64 encoded string into a byte array, and writing the byte array into the byte parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism.
[0018] This implementation accurately reproduces the "Hessian2 serialization + Base64 encoding" dual conversion link specific to the proxy interface under test, ensuring that the byte payload in the test request is strictly consistent with the expected format of the server, and solving the technical problem that complex object parameters are difficult to construct manually.
[0019] As one implementation, the response decoding rules include Base64 decoding rules, the deserialization rules include Hessian2 deserialization rules, and the restoration of the byte response data includes:
[0020] The byte response data is parsed into a Base64 string; the Base64 string is decoded to obtain a Hessian2 byte sequence; the flag bits in the Hessian2 byte sequence are read using a read cursor; null values, boolean values, integers, long integers, floating-point numbers, dates, strings, binary numbers, class definitions, object references, lists, or mappings are identified and parsed based on the flag bits; the structured response object or scalar response value is generated based on the parsing results.
[0021] This implementation, by simulating the underlying parsing logic of the Hessian2 protocol, can accurately restore unreadable byte stream responses into structured data that can be recognized by the testing framework, thus opening up the data path from binary responses to automated assertions.
[0022] As one implementation method, a class definition cache is maintained during the parsing of the Hessian2 byte sequence; when a class definition flag is read, the type name and field name set are written into the class definition cache; when an object reference flag is read, the class definition reference value is determined according to the object reference flag, and the corresponding type name and field name set are read from the class definition cache based on the class definition reference value, and then the field values are read sequentially according to the field name set to generate an object structure containing type name and field value.
[0023] This implementation utilizes a caching mechanism to handle the compact reference format in the Hessian2 protocol, ensuring the complete restoration of nested objects and repetitive type definitions, thus improving the accuracy and efficiency of deserialization.
[0024] In one implementation, the unified response object includes gRPC status code, gRPC status description, structured error details, proxy response business code, proxy response business message, structured response object field, scalar response value field, original request data field, and original response data field. When the result obtained by Hessian2 deserialization is an object, list, or mapping, the result is written to the structured response object field of the unified response object. When the result obtained by Hessian2 deserialization is a string, number, or boolean value, the result is written to the scalar response value field of the unified response object.
[0025] This implementation normalizes the communication layer state, service layer state, and decoded data payload into the same object structure, and intelligently distributes and stores them according to data type. This allows subsequent assertion logic to access response information at any level directly through a unified field without needing to worry about differences in the underlying protocol.
[0026] As one implementation, the method further includes: when the gRPC proxy request message call fails, obtaining the status code and error description in the gRPC exception; extracting business error information from the structured error details or trailing metadata of the gRPC exception; writing the status code, the error description, and the business error information into the unified response object, so as to perform an exception scenario assertion based on the unified response object.
[0027] This implementation aggregates scattered error information in abnormal situations into a unified response object, enabling test cases to verify the exception handling logic using the same assertion syntax as in normal scenarios, thus improving the automation level of exception testing.
[0028] As one implementation method, when the parameter data in the test case configuration is an array, each element in the array is treated as a call item, and parameter encoding, proxy request construction, proxy call, response decoding, and unified response object encapsulation are executed sequentially according to the order of the call items in the array, and the resulting multiple unified response objects are combined into a response array.
[0029] This implementation supports batch proxy call verification within a single test step, meeting the testing requirements for state change verification or continuous calls to multiple interfaces.
[0030] As one implementation, the step of performing test assertions based on the unified response object includes: reading actual values from the unified response object according to variable expressions in the test case configuration; comparing the actual values with expected values in the test case configuration or performing a structured object comparison; when performing a structured object comparison, preprocessing the actual values and the expected values according to the ignored fields, whitelist fields, or sorting fields in the test case configuration before performing the comparison.
[0031] This implementation, combined with a unified response object, provides flexible assertion preprocessing capabilities, effectively shielding the assertion results from interference by dynamic fields or unordered sets in the response, and enhancing the stability of the test script.
[0032] Secondly, this application also provides an interface automation testing adapter for gRPC proxy encapsulation mechanisms, including:
[0033] The configuration reading module is used to read the test case configuration and obtain the proxy service address, target service identifier, target method identifier, parameter type list and parameter data of the gRPC proxy interface to be tested.
[0034] The parameter encoding module is used to determine the parameter carrying method according to the parameter form of the parameter data; the request construction module is used to construct a gRPC proxy request message based on the target service identifier, the target method identifier, the parameter type list and the parameter carrying method.
[0035] The proxy invocation module is used to send the gRPC proxy request message to the proxy service address through the gRPC channel and receive the proxy response message.
[0036] The response decoding module is used to restore the byte response data based on the response decoding rules and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism when the proxy response message contains byte response data, so as to obtain a structured response object or a scalar response value.
[0037] The response encapsulation module is used to encapsulate the gRPC status code, gRPC status description, proxy business information, and the structured response object or scalar response value into a unified response object.
[0038] The assertion execution module is used to execute test assertions based on the unified response object. The above device implements all the functions of the aforementioned method through modular design, enabling it to independently complete the entire automated testing process from configuration parsing and protocol adaptation to result assertions without intruding on the proxy service under test.
[0039] Thirdly, this application proposes an electronic device including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and when the computer program is executed by the processor, the processor causes the processor to perform the method described in the above embodiments.
[0040] Fourthly, this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the above embodiments.
[0041] Beneficial effects:
[0042] The technical solution provided in this application involves building an adaptive adaptation layer for the gRPC proxy encapsulation mechanism on the testing side:
[0043] First, by automatically identifying parameter forms and performing serialization and encoding conversion according to proxy conventions, the construction process of complex object parameters is transformed from manual operation to automatic processing by the engine, which significantly reduces the threshold for writing test cases and maintenance costs, while avoiding invalid tests caused by manual coding errors.
[0044] Secondly, by automatically decoding and deserializing the response byte data, and merging the communication status, business status, and data payload into a unified response object, the black box state of unreadable and unassertable gRPC proxy interface response data is broken, enabling general assertion capabilities such as JSONPath extraction and structured comparison to be directly reused for proxy interface testing.
[0045] Finally, by unifying the encapsulation of exception information and supporting batch calls, the scenario coverage capability of proxy interface testing has been improved, enabling exception verification and state transition verification to be incorporated into a standardized automated testing system, thereby improving the overall completeness and execution efficiency of testing. Attached Figure Description
[0046] Figure 1 This is a schematic diagram of the interface automated testing and adaptation method for gRPC proxy encapsulation mechanism according to an embodiment of this application;
[0047] Figure 2 This is a schematic diagram of the gRPC proxy request message construction process according to an embodiment of this application;
[0048] Figure 3 This is a schematic diagram of the gRPC proxy response decoding and unified object encapsulation process according to an embodiment of this application;
[0049] Figure 4 This is a schematic diagram of the assertion execution and report generation process based on the unified response object in an embodiment of this application.
[0050] Figure 5 This is a schematic diagram of the method according to an embodiment of the present invention;
[0051] Figure 6 This is a schematic diagram of the system structure provided in an embodiment of the present invention.
[0052] Figure 7 This is a block diagram of an electronic device structure provided in an embodiment of the present invention. Detailed Implementation
[0053] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art.
[0055] Example 1:
[0056] like Figure 1 , Figure 5 As shown, this embodiment provides an automated testing adaptation method for interfaces using gRPC proxy encapsulation mechanisms, where gRPC stands for Remote Procedure Call. This method is primarily executed on the test execution engine side, requiring no modification to the code or configuration of the proxy server under test, thus enabling automated testing of proxy interfaces employing specific encapsulation mechanisms.
[0057] A method for automated testing and adaptation of interfaces oriented towards gRPC proxy encapsulation mechanisms is proposed, including:
[0058] S100. Read the test case configuration to obtain the proxy service address, target service identifier, target method identifier, parameter type list, and parameter data of the gRPC proxy interface to be tested.
[0059] In this embodiment, test case configurations are typically stored in structured file formats such as YAML or JSON, and are pre-written by testers. The test execution engine parses this configuration file to extract the basic metadata required to establish a connection and initiate a call. For example, the proxy service address is used to locate the network endpoint; the target service identifier and target method identifier are used to route to the specific business implementation class and method within the proxy server; the parameter type list provides type information such as the fully qualified Java class name, used for subsequent parameter serialization and reflection calls; and the parameter data is the actual business payload passed in for this test. By using a configuration-driven approach, the test logic is decoupled from the underlying protocol details, allowing the same test framework to adapt to different versions of the proxy interface convention.
[0060] S200. Determine the parameter carrying method based on the parameter form of the parameter data, and construct a gRPC proxy request message based on the target service identifier, the target method identifier, the parameter type list and the parameter carrying method;
[0061] It's important to note that the parameter delivery method here is not a fixed, single format, but rather dynamically determined based on the actual form of the parameter data. Specifically, the test execution engine determines whether the parameter data is a simple list of ordinary parameters or a complex list of object parameters containing nested structures. When identified as an ordinary parameter, it is directly mapped to the ordinary parameter field agreed upon by the proxy interface; when identified as a complex object, a specific encoding conversion process is triggered, parsing it into a byte stream and mapping it to the byte parameter delivery field. This dynamic routing mechanism ensures that the test engine is compatible with the existing mixed parameter passing mode of the proxy interface, avoiding protocol format errors caused by misjudgment of parameter types, and also provides a unified scheduling entry point for the specific processing logic of different parameter types in subsequent embodiments.
[0062] S300: Send the gRPC proxy request message to the proxy service address through the gRPC channel, and receive the proxy response message;
[0063] The test execution engine establishes or reuses a gRPC long connection channel using the proxy service address obtained in step S100, and sends the request message constructed in step S200 that conforms to the proxy encapsulation agreement to the server. After processing, the server returns a proxy response message, which may contain normal business data or exception information indicating call failure. This step realizes the physical communication interaction between the test engine and the system under test.
[0064] S400. When the proxy response message contains byte response data, the byte response data is restored based on the response decoding rules and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism to obtain a structured response object or a scalar response value.
[0065] Because gRPC proxy interfaces often serialize business return values into binary byte streams (such as bytes fields) for the sake of universality, conventional testing tools cannot directly read them. This embodiment automatically reverse-engineers unreadable byte data into objects or basic type values in memory by building the same decoding and deserialization logic as the server into the testing engine. This process is completed entirely on the client side, shielding the complexity of the underlying binary protocol, allowing upper-layer testing logic to process gRPC proxy interface response data as if it were a regular JSON interface.
[0066] S500. Encapsulate the gRPC status code, gRPC status description, proxy business information, and the structured response object or scalar response value into a unified response object.
[0067] The unified response object is a composite data structure that integrates multi-dimensional information. It not only contains the business data (structured response object or scalar response value) restored in step S400, but also integrates the underlying gRPC communication status (such as status codes OK, UNAVAILABLE, etc. and their descriptions) and the business status information at the proxy level (such as proxy-defined business codes and business messages). Through this normalized encapsulation, regardless of whether the underlying call succeeds, the business fails, or there is a network error, the test script can obtain all relevant information by accessing the properties of the same object, thereby supporting standardized assertion logic and solving the problems of scattered error information and inconsistent assertion syntax in traditional solutions.
[0068] S600. Perform test assertions based on the unified response object.
[0069] The test execution engine extracts actual values from the unified response object for comparison and verification based on the expected results configured in the test cases. Since the preceding steps have standardized various heterogeneous data into a unified response object, the assertion execution here can use general expression parsing and comparison algorithms, eliminating the need to write special verification code for the gRPC proxy interface. This not only reduces the difficulty of writing test cases but also improves the reusability of test scripts across different interfaces.
[0070] Through the above-mentioned full-process adaptation, this embodiment builds a complete protocol conversion and data normalization layer on the test engine side without intruding on the server under test, effectively solving the technical pain points of difficult request construction, black box response parsing, and poor assertion reusability in automated testing of gRPC proxy interfaces.
[0071] Example 2:
[0072] This embodiment further refines step S200 in Embodiment 1, focusing on how the test execution engine adapts parameter encoding according to the existing conventions of the proxy interface when the parameter data is a complex object. Figure 2 As shown, determining the parameter carrying method based on the parameter format of the parameter data includes:
[0073] When the parameter data is a list of ordinary parameters, the list of ordinary parameters is mapped to the ordinary parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism;
[0074] When the parameter data is a list of complex object parameters, based on the parameter type list and the serialization and encoding rules agreed upon by the gRPC proxy encapsulation mechanism, each complex object parameter in the list of complex object parameters is parsed into a byte parameter, and the byte parameter is mapped to the byte parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism.
[0075] Specifically, in order to support generic calls, gRPC proxy interfaces typically define two parameter passing channels: one is for passing ordinary parameter carrying fields (such as parameters) of basic types such as strings and integers.
[0076] Another type is the byte parameter carrying field (e.g., parametersByte) used to pass complex types such as custom objects and nested structures. Before constructing the request, the test execution engine first parses the parameter data structure in the test case configuration. If the parameter is identified as a simple key-value pair or a list of basic types, it is directly populated into the ordinary parameter carrying field; if the parameter contains complex forms such as nested objects or custom class instances, it automatically switches to the byte parameter processing branch. This dynamic routing mechanism ensures that the test engine can be compatible with the existing mixed parameter passing mode of the proxy interface, avoids protocol format errors caused by misjudgment of parameter types, and also provides a unified scheduling entry point for subsequent processing of different types of parameters.
[0077] In one specific implementation, the serialization rules for converting complex object parameters include Hessian2 serialization rules, and the encoding rules include Base64 encoding rules. The process of parsing each complex object parameter in the complex object parameter list into byte parameters specifically includes the following sub-steps:
[0078] Step S201: Determine the type name corresponding to the current complex object parameter. The test execution engine reads the fully qualified Java class name corresponding to the current parameter position from the parameter type list (parameterTypes) configured in the test case, such as "com.example.PaymentRequest". This type name is necessary metadata for generating the Hessian2 class definition later, used to accurately restore the object type during server-side deserialization.
[0079] Step S202: Based on the type name and the field set of the current complex object parameters, a Hessian2 class definition is generated. The test execution engine constructs the class definition structure according to the Hessian2 protocol specification based on the type name and all field names (such as amount, currency, items, etc.) contained in the parameter object. This class definition describes the object's type identifier and the order of its fields, serving as a structural blueprint for the server to parse the byte stream.
[0080] Step S203: Based on the field value type of each field in the field set, generate byte sequences for Hessian2 basic types, list types, mapping types, or object types respectively. The test execution engine iterates through each field of the parameter object, recursively applying the Hessian2 serialization algorithm according to the type of its actual value. For example, for integer fields, generate compact integer encoding; for string fields, generate a UTF-8 byte stream; for nested objects, recursively generate new class definitions and object references; and for lists or mappings, generate corresponding set markers and element sequences. Finally, concatenate the serialization results of all fields into a complete Hessian2 binary byte stream.
[0081] Step S204 involves Base64 encoding the generated Hessian2 byte sequence to obtain a Base64 encoded string. Because some proxy interface configurations or intermediate transport layers may require parameters to be passed in text format, or for ease of debugging and logging, the test execution engine first parses the original binary byte stream into a Base64 string. This step demonstrates adaptation to the existing outer encoding conventions of the proxy interface.
[0082] Step S205 involves decoding the Base64-encoded string into a byte array and writing the byte array into the byte parameter field specified by the gRPC proxy encapsulation mechanism. Although Base64 text conversion occurs, the gRPC protocol's bytes field essentially still needs to receive pure binary data. Therefore, before writing the request message, the test execution engine re-decodes the Base64 string into a byte array and finally fills it into the parametersByte field. This complete conversion chain of "serialization → Base64 encoding → Base64 decoding → writing to the byte field" accurately replicates the parameter encapsulation protocol specific to the proxy interface under test, ensuring strict consistency between the test request and the server's expected format.
[0083] It should be understood that although this embodiment uses Hessian2 serialization and Base64 encoding as examples for detailed explanation, this is only one specific manifestation of the existing conventions of the proxy interface. In other embodiments, if the proxy interface uses other serialization protocols such as Protobuf and Thrift, or other outer encoding methods such as Hex and URL Safe Base64, the test execution engine can also load the corresponding encoder and serializer in a configurable manner to perform a similar conversion process. The core of this application lies in the test engine's ability to automatically identify and adapt to the established encoding rules of the proxy interface, rather than in improving a specific serialization algorithm itself. Through the above mechanism, testers do not need to manually write complex binary construction code; they only need to provide a readable JSON object in the configuration file, and the engine can automatically complete the conversion of the underlying protocol, significantly reducing the threshold and maintenance cost of writing test cases with complex object parameters.
[0084] Example 3:
[0085] Based on Example 1, this embodiment further refines the process of restoring byte response data in step S400 and the encapsulation logic of the unified response object in step S500.
[0086] The response decoding rules include Base64 decoding rules, the deserialization rules include Hessian2 deserialization rules, and the restoration of the byte response data includes:
[0087] The response decoding rules include Base64 decoding rules, and the deserialization rules include Hessian2 deserialization rules.
[0088] The byte response data is parsed into a Base64 string;
[0089] Decoding the Base64 string yields a Hessian2 byte sequence;
[0090] The marker bits in the Hessian2 byte sequence are read based on the read cursor;
[0091] The system identifies and parses null values, boolean values, integers, long integers, floating-point numbers, dates, strings, binary numbers, class definitions, object references, lists, or mappings based on the flag bits.
[0092] The structured response object or scalar response value is generated based on the parsing results.
[0093] Maintain a class definition cache during the parsing of the Hessian2 byte sequence;
[0094] When the class definition flag is read, the set of type name and field name is written to the class definition cache;
[0095] When an object reference flag is read, the class definition reference value is determined based on the object reference flag. Then, the corresponding type name and field name set are read from the class definition cache based on the class definition reference value. Finally, the field values are read sequentially according to the field name set to generate an object structure containing type names and field values.
[0096] Specifically, the response decoding rules include Base64 decoding rules, and the deserialization rules include Hessian2 deserialization rules. The test execution engine first parses the byte response data into a Base64 string. This step is typically to adapt to certain proxy interfaces' textual processing conventions for binary data at the transport or log layers, or to facilitate displaying the original encoded content in the test report for debugging purposes. Then, the Base64 string is decoded to obtain the original Hessian2 byte sequence. Next, the test execution engine reads the marker bits in the Hessian2 byte sequence based on the read cursor, identifying and parsing various data types such as null values, boolean values, integers, long integers, floating-point numbers, dates, strings, binary data, class definitions, object references, lists, or maps based on the marker bits. For example, when a compact integer marker is read, subsequent bytes are directly parsed as integer values; when a string marker is read, a UTF-8 byte stream is read based on the length field and parsed as a string; when a list or map marker is read, the elements or key-value pairs are recursively parsed. Finally, a structured response object or scalar response value is generated based on the parsing results. Through this low-level protocol-level reverse parsing, the test engine can accurately restore the unreadable binary stream returned by the server into an operable data structure in memory, thus opening up the data path from binary response to automated assertions.
[0097] During the parsing of Hessian2 byte sequences, to ensure the correct reconstruction of complex nested objects and improve parsing efficiency, the test execution engine also maintains a class definition cache. Specifically, when a class definition flag is read, it indicates that a new object type has been encountered. At this time, the test execution engine writes the type name and field name set of that type into the class definition cache as a metadata template for subsequent parsing of objects of the same type. When an object reference flag is read subsequently, it indicates that a previously defined type instance has been encountered. The test execution engine determines the class definition reference value based on the object reference flag and reads the corresponding type name and field name set from the class definition cache based on this class definition reference value. Then, it reads the field values sequentially according to the field name set, thereby generating a complete object structure containing type names and field values. This caching mechanism is the core support for the compact serialization format of the Hessian2 protocol. Without this mechanism, the test engine will be unable to correctly process complex response data containing duplicate type definitions or circular references, leading to deserialization failure or data loss. Therefore, cache maintenance is not only a performance optimization method but also a necessary technical feature to ensure the accuracy of response reconstruction.
[0098] The unified response object includes gRPC status code, gRPC status description, structured error details, proxy response business code, proxy response business message, structured response object fields, scalar response value fields, original request data fields, and original response data fields;
[0099] When the result of Hessian2 deserialization is an object, list, or map, the result is written to the structured response object field of the unified response object; when the result of Hessian2 deserialization is a string, number, or boolean value, the result is written to the scalar response value field of the unified response object.
[0100] After restoring the byte response data, the test execution engine needs to integrate the multi-dimensional call results into a standardized data structure. The unified response object includes gRPC status codes, gRPC status descriptions, structured error details, proxy response business codes, proxy response business messages, structured response object fields, scalar response value fields, raw request data fields, and raw response data fields. Specifically, the gRPC status codes and gRPC status descriptions reflect the call results of the underlying communication layer (e.g., OK, UNAVAILABLE); the structured error details carry rich text error information from gRPC exceptions; the proxy response business codes and proxy response business messages reflect the business processing status at the proxy service layer; and the raw request data fields and raw response data fields retain the original messages before and after serialization, facilitating traceability and diagnosis in case of test failures. By normalizing the above heterogeneous information into a single object, test scripts do not need to concern themselves with the underlying protocol details and can obtain response information at any level through a unified attribute access path, greatly simplifying the writing and maintenance of assertion logic.
[0101] For the restored business data, the test execution engine uses a split-writing rule to populate the corresponding fields of the unified response object. When the result of Hessian2 deserialization is an object, list, or mapping, the result is written to the structured response object field (e.g., the json field) of the unified response object; when the result of Hessian2 deserialization is a string, number, or boolean value, the result is written to the scalar response value field (e.g., the raw field) of the unified response object. The technical consideration for this split-writing design is that structured data typically needs to support complex assertion operations such as JSONPath extraction and nested field comparison; placing it in a dedicated field allows the assertion engine to directly apply structured comparison algorithms. Scalar data, on the other hand, usually only requires simple equality or range checks; placing it in a separate field avoids unnecessary structured parsing overhead. This also makes test case configuration more intuitive, allowing testers to explicitly specify the assertion target field based on the expected return value type. It should be understood that although this embodiment uses json and raw as field naming examples, other names such as data, value, and payload can be used in other implementations, as long as the distinction between structured and scalar data for storage and access can be achieved. Through the complete chain of decoding, caching, encapsulation, and splitting the write, this embodiment constructs a complete defense depth for response processing, proving that byte response data restoration and unified response object generation are an inseparable technical whole, providing a solid data foundation for standardized assertions in subsequent embodiments.
[0102] Example 4
[0103] This embodiment, based on embodiment 1, further supplements the exception handling mechanism when the gRPC proxy request message call fails. It also includes:
[0104] When the gRPC proxy request message call fails, obtain the status code and error description from the gRPC exception;
[0105] Extract business error information from the structured error details or trailing metadata of the gRPC exception;
[0106] The status code, the error description, and the business error information are written into the unified response object to perform an exception scenario assertion based on the unified response object.
[0107] During gRPC communication, when the proxy service address becomes unreachable, authentication fails, times out, or the server throws an internal exception, the client typically catches a StatusRuntimeException. The test execution engine first extracts the underlying gRPC status code and error description from this exception object. This information reflects the basic state of network transmission or protocol interaction; for example, UNAVAILABLE indicates service unavailability, and DEADLINE_EXCEEDED indicates a call timeout. However, relying solely on the underlying status code often cannot meet the verification needs of business tests, because many business validation failures (such as invalid parameters or insufficient balance) may only manifest as general INVALID_ARGUMENT or INTERNAL states at the gRPC level, lacking specific business semantics.
[0108] To address this issue, the test execution engine also attempts to parse business error information from the additional information carried by gRPC exceptions. Specifically, the parsing sources include Structured Error Details or Trailing Metadata. Trailing metadata refers to the set of key-value pairs returned along with the status code at the end of the gRPC response stream; the English term "trailing metadata" is uniformly translated as "tailing metadata" in this application. Some proxy frameworks serialize custom business error codes and error messages and return them in the trailing metadata; while other frameworks may utilize the gRPC error details mechanism to embed Protobuf-formatted error objects into the exception. The test execution engine will, according to a preset parsing strategy, first attempt to read the Structured Error Details. If no valid business information is obtained, it will fall back to the trailing metadata for extraction. For example, the value of key "x-biz-code" is read from the trailing metadata as the proxy response business code, and the value of key "x-biz-msg" is read as the proxy response business message.
[0109] After extracting the aforementioned multi-dimensional anomaly information, the test execution engine populates it into the corresponding fields of the unified response object defined in Example 3. Specifically, the gRPC status code is written to the `status_code` field, the gRPC error description is written to the `status_message` field, the parsed structured error object is written to the `status_details` field, and the extracted business error code and business message are written to the `code` and `msg` fields, respectively. Through this normalization process, regardless of whether the call succeeds or fails, test cases can access the response data using the exact same variable expressions (such as `response.statuscode`, `{response.code}`).
[0110] The technical advantage of this exception handling mechanism lies in its complete elimination of the difference in assertion syntax between abnormal and normal scenarios. In traditional testing solutions, testers typically need to write dedicated exception handling blocks to verify error information, resulting in complex and difficult-to-maintain test script logic branches. However, in this embodiment, since the exception information has been transformed into standardized unified response object fields, testers can directly reuse normal JSONPath assertions or value comparison assertions to verify abnormal scenarios. For example, when verifying the "insufficient balance" scenario, it is only necessary to configure the expected value as {"status_code": "INVALID_ARGUMENT", "code": "INSUFFICIENT_BALANCE"}, without needing to care whether the underlying data is passed through tail metadata or error details.
[0111] This not only lowers the barrier to writing abnormal test cases, but also enables test reports to display detailed information on successes and failures in a unified format, significantly improving the completeness and maintainability of the automated testing system.
[0112] Example 5
[0113] This embodiment, based on the unified response object generated in Embodiment 3, further elaborates on the specific mechanism for executing test assertions based on this unified response object. For example... Figure 4 As shown, the process of performing test assertions based on the unified response object mainly includes variable resolution, value acquisition, comparison mode selection, and preprocessing.
[0114] The execution of test assertions based on the unified response object includes:
[0115] The actual value is read from the unified response object based on the variable expression in the test case configuration;
[0116] Compare the actual value with the expected value in the test case configuration using either a value comparison or a structured object comparison.
[0117] When performing a structured object comparison, the actual value and the expected value are preprocessed according to the ignored fields, whitelist fields, or sorting fields in the test case configuration before the comparison is performed.
[0118] Specifically, the test execution engine first reads the actual values from the unified response object based on the variable expressions in the test case configuration. Variable expressions are typically defined in the form of `response.field` or `{response.json.path}`. Since the preceding steps have normalized the heterogeneous gRPC proxy responses into a unified response object containing standard fields such as `status_code`, `msg`, `json`, and `raw`, the test engine can map variable expressions to the corresponding properties of the object using a unified parser. For example, the expression `response.statuscode` directly reads the communication status code, while `{response.json.orderId}` extracts nested business data from the structured response object fields using JSONPath syntax. This variable parsing mechanism based on a unified object allows test cases to obtain response data at any level, just like accessing a regular JSON interface, without needing to be aware of the underlying gRPC protocol details or byte decoding process, achieving complete decoupling between assertion logic and the protocol adaptation layer.
[0119] After obtaining the actual value, the test execution engine compares the actual value with the expected value in the test case configuration using either a value comparison or a structured object comparison. The choice of comparison mode typically depends on the type of the expected value or the explicit configuration in the test case. When the expected value is a basic type such as a string, number, or boolean, the engine performs a simple value comparison operation, suitable for verifying status codes, business codes, or scalar return values. When the expected value is a JSON object or array, the engine automatically switches to structured object comparison mode, recursively comparing the key-value pair structures of the two objects. This dual-mode comparison strategy ensures both the efficiency of basic verification and supports in-depth verification of complex business return bodies, meeting the needs of different granularity testing scenarios.
[0120] For structured object comparison scenarios, to shield the assertion results from interference from dynamic fields or unordered sets in the response data, the test execution engine preprocesses the actual and expected values according to the ignored fields, whitelisted fields, or sorting fields configured in the test case configuration before performing the comparison. Specifically, the ignored field configuration specifies attribute paths that should be excluded during the comparison process, such as server-generated request IDs, timestamps, or random tokens. These fields change with each call and do not affect business correctness; excluding them can avoid frequent false alarms in assertions. The whitelisted field configuration uses a positive filtering strategy, retaining only specified key business fields for comparison and ignoring all unlisted fields. This is particularly effective in regression tests that only need to verify some core data and do not need to concern themselves with the complete response structure. The sorting field configuration specifies the sorting criteria for array elements. When the order of list data in the response is not fixed but the content is determined, the engine will reorder the arrays in the actual and expected values according to the specified fields before comparing them one by one, thereby eliminating comparison failures caused by unordered sets. Through the above preprocessing mechanism, this embodiment effectively solves the problem of assertion instability caused by the dynamic or disordered nature of data in gRPC proxy interface testing, significantly improves the robustness and maintenance efficiency of automated test scripts, and forms a complete technical closed loop from protocol adaptation and data encapsulation to intelligent assertions.
[0121] This embodiment provides an automated testing adaptation device for interfaces oriented towards the gRPC proxy encapsulation mechanism, combined with... Figure 6 ,include:
[0122] The configuration reading module 201 is used to read the test case configuration and obtain the proxy service address, target service identifier, target method identifier, parameter type list and parameter data of the gRPC proxy interface to be tested.
[0123] Parameter encoding module 202 is used to determine the parameter carrying method according to the parameter form of the parameter data;
[0124] The request construction module 203 is used to construct a gRPC proxy request message based on the target service identifier, the target method identifier, the parameter type list, and the parameter carrying method.
[0125] Proxy invocation module 204 is used to send the gRPC proxy request message to the proxy service address through the gRPC channel and receive the proxy response message;
[0126] The response decoding module 205 is used to restore the byte response data based on the response decoding rules and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism when the proxy response message contains byte response data, so as to obtain a structured response object or a scalar response value.
[0127] The response encapsulation module 206 is used to encapsulate the gRPC status code, gRPC status description, proxy business information and the structured response object or scalar response value into a unified response object.
[0128] Assertion execution module 207 is used to execute test assertions based on the unified response object.
[0129] In other embodiments of the present invention, an electronic device 400 is disclosed, such as... Figure 7 As shown, the electronic device may include: one or more processors 401; a memory 402; a display 403; one or more application programs (not shown); and one or more computer programs 404. These devices can be connected via one or more communication buses 405. The one or more computer programs 404 are stored in the memory 402 and configured to be executed by the one or more processors 401. The one or more computer programs 404 include instructions that can be used to perform actions such as... Figure 1 And the various steps in the corresponding embodiments.
[0130] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0131] In the various embodiments of this invention, the functional units 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.
[0132] 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 the embodiments of the present 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.
[0133] The above description is merely a specific implementation of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of the present invention should be covered within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.
Claims
1. A method for automated testing and adaptation of interfaces for gRPC proxy encapsulation mechanisms, characterized in that, include: Read the test case configuration to obtain the proxy service address, target service identifier, target method identifier, parameter type list, and parameter data of the gRPC proxy interface to be tested; The parameter carrying method is determined based on the parameter form of the parameter data, and a gRPC proxy request message is constructed based on the target service identifier, the target method identifier, the parameter type list, and the parameter carrying method. Send the gRPC proxy request message to the proxy service address via the gRPC channel, and receive the proxy response message; When the proxy response message contains byte response data, the byte response data is restored based on the response decoding and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism to obtain a structured response object or a scalar response value. The gRPC status code, gRPC status description, proxy business information, and the structured response object or scalar response value are encapsulated into a unified response object. Perform test assertions based on the unified response object.
2. The method according to claim 1, characterized in that, Determining the parameter carrying method based on the parameter format of the parameter data includes: When the parameter data is a list of ordinary parameters, the list of ordinary parameters is mapped to the ordinary parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism; When the parameter data is a list of complex object parameters, based on the parameter type list and the serialization and encoding rules agreed upon by the gRPC proxy encapsulation mechanism, each complex object parameter in the list of complex object parameters is parsed into a byte parameter, and the byte parameter is mapped to the byte parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism.
3. The method according to claim 2, characterized in that, The serialization rules include Hessian2 serialization rules, the encoding rules include Base64 encoding rules, and parsing each complex object parameter in the complex object parameter list into byte parameters includes: Determine the type name corresponding to the parameter of the current complex object; Based on the type name and the field set of the current complex object parameters, generate a Hessian2 class definition; Generate byte sequences of Hessian2 basic type, list type, mapping type or object type according to the field value type of each field in the field set; The generated Hessian2 byte sequence is Base64 encoded to obtain a Base64 encoded string; The Base64 encoded string is decoded into a byte array, and the byte array is written into the byte parameter carrying field agreed upon by the gRPC proxy encapsulation mechanism.
4. The method according to claim 1, characterized in that, The response decoding rules include Base64 decoding rules, the deserialization rules include Hessian2 deserialization rules, and the restoration of the byte response data includes: The byte response data is parsed into a Base64 string; Decoding the Base64 string yields a Hessian2 byte sequence; The marker bits in the Hessian2 byte sequence are read based on the read cursor; The system identifies and parses null values, boolean values, integers, long integers, floating-point numbers, dates, strings, binary numbers, class definitions, object references, lists, or mappings based on the flag bits. The structured response object or scalar response value is generated based on the parsing results.
5. The method according to claim 4, characterized in that, Maintain a class definition cache during the parsing of the Hessian2 byte sequence; When the class definition flag is read, the set of type name and field name is written to the class definition cache; When an object reference flag is read, the class definition reference value is determined based on the object reference flag. Then, the corresponding type name and field name set are read from the class definition cache based on the class definition reference value. Finally, the field values are read sequentially according to the field name set to generate an object structure containing type names and field values.
6. The method according to claim 4, characterized in that, The unified response object includes gRPC status code, gRPC status description, structured error details, proxy response business code, proxy response business message, structured response object fields, scalar response value fields, original request data fields, and original response data fields; When the result of Hessian2 deserialization is an object, list, or map, the result is written to the structured response object field of the unified response object; when the result of Hessian2 deserialization is a string, number, or boolean value, the result is written to the scalar response value field of the unified response object.
7. The method according to claim 1, characterized in that, Also includes: When the gRPC proxy request message call fails, obtain the status code and error description from the gRPC exception; Extract business error information from the structured error details or trailing metadata of the gRPC exception; The status code, the error description, and the business error information are written into the unified response object to perform an exception scenario assertion based on the unified response object.
8. The method according to claim 1, characterized in that, When the parameter data in the test case configuration is an array, each element in the array is treated as a call item. The parameter encoding, proxy request construction, proxy call, response decoding, and unified response object encapsulation are executed sequentially according to the order of the call items in the array, and the resulting multiple unified response objects are combined into a response array.
9. The method according to claim 1, characterized in that, The execution of test assertions based on the unified response object includes: The actual value is read from the unified response object based on the variable expression in the test case configuration; Compare the actual value with the expected value in the test case configuration using either a value comparison or a structured object comparison. When performing a structured object comparison, the actual value and the expected value are preprocessed according to the ignored fields, whitelist fields, or sorting fields in the test case configuration before the comparison is performed.
10. An automated testing and adaptation device for interfaces oriented towards gRPC proxy encapsulation mechanisms, characterized in that, include: The configuration reading module is used to read the test case configuration and obtain the proxy service address, target service identifier, target method identifier, parameter type list and parameter data of the gRPC proxy interface to be tested. The parameter encoding module is used to determine the parameter carrying method based on the parameter format of the parameter data; The request construction module is used to construct a gRPC proxy request message based on the target service identifier, the target method identifier, the parameter type list, and the parameter carrying method. The proxy invocation module is used to send the gRPC proxy request message to the proxy service address through the gRPC channel and receive the proxy response message. The response decoding module is used to restore the byte response data based on the response decoding rules and deserialization rules agreed upon by the gRPC proxy encapsulation mechanism when the proxy response message contains byte response data, so as to obtain a structured response object or a scalar response value. The response encapsulation module is used to encapsulate the gRPC status code, gRPC status description, proxy business information, and the structured response object or scalar response value into a unified response object. The assertion execution module is used to execute test assertions based on the unified response object.