Service testing method and device and electronic equipment
By receiving test instructions to determine the target RPC interface and generating trace tags for Mock data, the problem of testers having difficulty determining the Mock interface in microservice architecture is solved. This achieves efficient Mock data processing without needing to understand the call chain, thus improving test accuracy and efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU NETEASE CLOUD MUSIC TECH CO LTD
- Filing Date
- 2026-01-09
- Publication Date
- 2026-05-19
AI Technical Summary
In a microservice architecture, testers often struggle to understand complex call chains and accurately identify the RPC interfaces that need to be mocked. Manually constructing mock data is time-consuming, laborious, and prone to errors, resulting in low test accuracy and efficiency.
By receiving test commands to determine the target RPC interface, generating Mock data that conforms to the Mock intent and setting tracking tags, storing it in the cache space, and using the tracking tags and interface names to retrieve the Mock data, Mock data processing can be achieved without needing to delve into the call chain.
It lowers the testing threshold, avoids testing bias caused by manually constructing mock data, and improves testing accuracy and efficiency.
Smart Images
Figure CN122064585A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of software testing technology, and in particular to a service testing method, apparatus, and electronic device. Background Technology
[0002] In a microservice architecture, an externally exposed HTTP interface may internally call multiple downstream service RPC interfaces, forming a complex call chain. When testing this HTTP interface, testers often need to mock the return values of one or more of these RPC interfaces to simulate downstream service anomalies, test specific business scenarios, or isolate faults. However, with existing mocking methods, testers find it difficult to clearly understand the entire call chain and do not know which specific RPC interface to mock to achieve the desired testing effect. In addition, manually constructed mock data is time-consuming, laborious, and prone to errors. Summary of the Invention
[0003] In view of this, the purpose of this disclosure is to provide a service testing method, apparatus and electronic device that allows testers to determine the target RPC interface to be called by subsequent business requests and the Mock data that conforms to the Mock intent in advance by means of test instructions, without having to understand the entire call chain and data structure. This reduces the testing threshold, avoids test deviations caused by manually constructing Mock data, and thus improves test accuracy, test effect and test efficiency.
[0004] In a first aspect, embodiments of this disclosure provide a service testing method, the method comprising: receiving a test instruction, the test instruction including: a target HTTP interface to be tested and a Mock intent; determining a target RPC interface matching the test instruction, and generating Mock data conforming to the Mock intent, and a tracking tag for the Mock data; associating the target RPC interface, the tracking tag, and the Mock data, and storing them in a target cache space; receiving a business request, if the business request carries a tracking tag and an interface name used to indicate the target RPC interface, retrieving the corresponding Mock data from the target cache space according to the tracking tag and the interface name; and returning the Mock data as a request response to the business request to complete the service test corresponding to the business request.
[0005] Secondly, embodiments of this disclosure provide a service testing apparatus, comprising: a receiving module for receiving a test instruction, the test instruction including: a target HTTP interface to be tested and a Mock intent; a generating module for determining a target RPC interface matching the test instruction and generating Mock data conforming to the Mock intent, as well as a tracking tag for the Mock data; a caching module for associating the target RPC interface, the tracking tag, and the Mock data, and storing them in a target cache space; an obtaining module for receiving a business request, and if the business request carries a tracking tag and an interface name indicating the target RPC interface, obtaining the corresponding Mock data from the target cache space based on the tracking tag and the interface name; and a returning module for returning the Mock data as a request response to the business request to complete the service test corresponding to the business request.
[0006] Thirdly, embodiments of this disclosure provide an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the service testing method of any of the first aspects.
[0007] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the service testing method of any one of the first aspects.
[0008] The embodiments disclosed herein bring the following beneficial effects: This disclosure provides a service testing method, apparatus, and electronic device. The method includes receiving a test instruction, which includes: a target HTTP interface to be tested and a mock intent; determining a target RPC interface matching the test instruction and generating mock data conforming to the mock intent, as well as a tracking tag for the mock data; associating the target RPC interface, tracking tag, and mock data, and storing them in a target cache space; receiving a business request; if the business request carries a tracking tag and an interface name indicating the target RPC interface, retrieving the corresponding mock data from the target cache space based on the tracking tag and interface name; and returning the mock data as the request response to the business request to complete the service test corresponding to the business request. In this method, testers do not need to have in-depth knowledge of the entire call chain and data structure. They can pre-determine the target RPC interface to be called by subsequent business requests and the mock data conforming to the mock intent through the test instruction, lowering the testing threshold, avoiding test deviations caused by manually constructing mock data, and thus improving test accuracy, test effectiveness, and test efficiency.
[0009] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.
[0010] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0011] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0012] Figure 1 A schematic diagram illustrating a service testing method provided in an embodiment of this disclosure; Figure 2 An architecture diagram of a service testing method provided in an embodiment of this disclosure; Figure 3 A complete flowchart of a service testing method provided in this disclosure embodiment; Figure 4 An interactive flowchart of a service testing method provided in this embodiment of the disclosure; Figure 5 This is a schematic diagram of the structure of a service testing device provided in an embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation
[0013] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0014] Currently, in microservice architectures, a single external HTTP interface may internally call multiple downstream service RPC interfaces, forming a complex call chain. When testing this HTTP interface, testers often need to mock the return values of one or more RPC interfaces to simulate downstream service anomalies, test specific business scenarios, or isolate faults. However, with existing mocking methods, testers find it difficult to clearly understand the entire call chain and don't know which specific RPC interface to mock to achieve the desired testing effect. Furthermore, the return data structure of RPC interfaces can be very complex, with deep nesting levels. Manually constructing mock data that conforms to the interface specification and triggers specific front-end logic is time-consuming, laborious, and prone to errors. Therefore, this disclosure provides a service testing method, apparatus, and electronic device, which can be applied to devices with software installed that requires service testing.
[0015] To facilitate understanding of this embodiment, a service testing method disclosed in this disclosure will first be described in detail, such as... Figure 1 As shown, the method includes the following steps: Step S102: Receive test instructions, which include: the target HTTP interface to be tested and the Mock intent; Optionally, the system can receive test instructions sent by the front-end device. These instructions are input by the tester into the front-end device before the formal service test. Specifically, the tester inputs the target HTTP (Hypertext Transfer Protocol) interface to be tested and the Mock intent.
[0016] In an optional example, when testers need to test the front-end's prompt logic when songs in a playlist are copyright-free, the test instruction could be: "In the Mock HTTP interface / api / XXX / playlist / detail, make the RPC call responsible for obtaining the song's copyright status return 'no copyright'." Here, "Mock HTTP interface / api / XXX / playlist / detail" is the target HTTP interface, and "make the RPC call responsible for obtaining the song's copyright status return 'no copyright'" is the Mock intent.
[0017] Step S104: Determine the target RPC interface that matches the test instructions, and generate Mock data that conforms to the Mock intent, as well as tracking tags for the Mock data; After receiving a test command, the backend device parses the command using the target model deployed on the device. The goal is to inform the target model of the tester's intent. Based on the parsing result, the target RPC interface matching the test command is determined. Optionally, the target RPC interface matching the test command can be determined from a call chain knowledge base. For example, if the call chain knowledge base contains call chains with the same parsing result, the RPC interface called in that call chain can be identified as the target RPC interface.
[0018] Optionally, based on the data structure and Mock intent in the call chain, Mock data conforming to the Mock intent can be generated, and a tracking tag for the Mock data can be generated. This tracking tag is used to carry human business requests and pass through the distributed context, realizing accurate Mock without code intrusion and at the request granularity.
[0019] The above method generates mock data based on mock intents, ensuring the semantic correctness of the mock data and conforming to business logic.
[0020] Step S106: Associate the target RPC interface, tracking tag, and Mock data, and store them in the target cache space; The target cache space can be a Mock cache. In actual implementation, the target RPC interface, tracking tags and Mock data are associated to obtain associated data, and the associated data is stored in the target cache space. The purpose of association is to use the target RPC interface and / or tracking tags as indexes for the Mock data, so that the corresponding Mock data can be accurately obtained when subsequent business requests are made.
[0021] Step S108: Receive a business request. If the business request carries a tracking tag and an interface name used to indicate the target RPC interface, obtain the corresponding Mock data from the target cache space according to the tracking tag and the interface name. Optionally, the system receives business requests sent by the front-end device. These requests are set by the tester in the front-end device after completing the test instructions, and they match the aforementioned Mock intent. Upon receiving the business request, the back-end device typically does not call the back-end service to complete it. Instead, it intercepts the request before the back-end service and determines whether it carries a tracking tag. If so, it does not call the actual back-end service but retrieves the corresponding Mock data from the target cache space based on the tracking tag and interface name. If not, it calls the back-end service and executes the subsequent content as a normal business request.
[0022] For example, testers use tools like Postman to initiate business requests and set a tracking tag in the request header. Based on this tracking tag, the request will not actually be sent to the backend service during execution.
[0023] Step S110: Return the Mock data as the request response to the business request to complete the service test corresponding to the business request.
[0024] After obtaining the Mock data corresponding to the business request, the Mock data is returned to the front-end device through the target HTTP interface, thereby triggering the front-end to provide the correct UI prompts.
[0025] This disclosure provides a service testing method. The method involves receiving a test instruction, which includes a target HTTP interface to be tested and a mock intent; determining a target RPC interface matching the test instruction and generating mock data conforming to the mock intent, as well as a tracking tag for the mock data; associating the target RPC interface, tracking tag, and mock data, and storing them in a target cache space; receiving a business request; if the business request carries a tracking tag and an interface name indicating the target RPC interface, retrieving the corresponding mock data from the target cache space based on the tracking tag and interface name; and returning the mock data as a request response to the business request to complete the service test corresponding to the business request. In this method, testers do not need to have in-depth knowledge of the entire call chain and data structure. They can pre-determine the target RPC interface to be called by subsequent business requests and the mock data conforming to the mock intent through the test instruction, lowering the testing threshold, avoiding test deviations caused by manually constructing mock data, and thus improving test accuracy, test effectiveness, and test efficiency.
[0026] One possible implementation of the above steps for determining the target RPC interface that matches the test instruction is as follows: based on the test instruction, query the call link of the target HTTP interface from the link knowledge base; determine the target RPC interface that matches the test instruction from the call link.
[0027] Optionally, the test command is parsed using a target model, and the call links of the target HTTP interface are queried from the link knowledge base. The target model can be a large language model, etc., and the link knowledge base typically stores all historical call links of the target HTTP interface. The target RPC interface matching the test command is then determined from the call links using the target model. In an optional example, when testers need to test when songs in a playlist are copyright-free, they can query the link knowledge base through the target model and find that there is an RPC interface named SongCopyrightService.getCopyrightStatus in the call chain of the target HTTP interface. This RPC interface matches the Mock intent in the test instructions, so this RPC interface is identified as the target RPC interface.
[0028] One possible implementation of the steps described above for generating Mock data that conforms to the Mock intent and the tracking label for the Mock data is as follows: determine the target historical response data that matches the Mock intent from the historical response data of the target RPC interface; generate Mock data that conforms to the Mock intent based on the data structure of the target historical response data; and set a unique tracking label for the Mock data.
[0029] Optionally, the historical response data of the target RPC interface can be analyzed through the target model (such as a large language model) to determine the target historical response data that matches the Mock intent; based on the Mock intent in the test instructions and the data structure of the target historical response data, Mock data that conforms to the Mock intent can be generated, and a unique tracking label can be set for the Mock data.
[0030] In an optional example, when testers need to test when songs in a playlist are copyright-free, they analyze the historical response data of the target RPC interface using a target model (such as a large language model). They determine if one of the historical response data contains the data structure {"songId": "123", "hasCopyright": true, "reason": ""}, thus identifying that historical response data as the target historical response data. Then, according to the test instruction to "return copyright-free status", the target model generates mock data that matches this data structure: {"songId": "${matching the requested songId}", "hasCopyright": false, "reason": "due to regional restrictions"}, and sets a unique trace tag: trace_tag:mock_playlist_copyright_5678 for the mock data.
[0031] In an optional example, when the Mock intent in the test instruction is "Mock the scenario where the user has insufficient points", when generating the Mock data for UserService.getPoints, it can not only return a number { "points": 50}, but also ensure that this number is consistent with the logic of the order amount in the subsequent OrderService.calculateCost (i.e., 50 < order amount), thereby ensuring the logical consistency of the entire test chain.
[0032] In the above approach, learning is based on real call chains and return results collected from the production environment. The generated Mock data is not only syntactically correct (conforming to the interface schema), but more importantly, semantically correct (conforming to the business logic context).
[0033] After associating the target RPC interface, tracking tag, and Mock data and storing them in the target cache space, the above method further includes returning the interface name and tracking tag of the target RPC interface to the front-end device.
[0034] After caching is completed, in order for subsequent service tests of business requests to proceed smoothly, the backend device needs to return the interface name and tracking tag of the target RPC interface to the frontend device.
[0035] After receiving the business request, the above method further includes: intercepting the business request through the interceptor of the target HTTP interface; if the business request includes a tracking tag and a target RPC interface, saving the tracking tag to the context; and sending the business request to the target RPC interface.
[0036] Backend devices typically deploy interceptors for the target HTTP interface. When a business request reaches the target HTTP interface, the interceptor intercepts the business request and then determines whether the business request includes a tracking tag and the target RPC interface. If so, the tracking tag is stored in the request context. The business request is then forwarded to an intermediate business service, which calls the target RPC interface based on the interface name of the target RPC interface.
[0037] In an optional example, when testers need to test when songs in a playlist are copyright-free, the header of the above business request is set to X-Mock-Tag: mock_playlist_copyright_5678 (i.e., the tracking tag) and SongCopyrightService.getCopyrightStatus (i.e., the interface name).
[0038] By using traffic coloring technology (i.e. tracking tags), we achieved request-level mocking, reducing interference with normal business traffic. The interception logic is implemented at the framework level, requiring no modification to business code, thus achieving non-intrusiveness and automating the process of "understanding the link -> locating the interface -> constructing data," thereby improving testing efficiency.
[0039] Among the above approaches, a lightweight, tag-based mock routing mechanism is proposed. This mechanism adds a tag at the source of the call chain and transmits it losslessly throughout the entire chain, enabling RPC interceptors located at any node in the chain to intelligently identify and execute mock logic. This achieves precise intervention in specific links of complex microservice call chains without affecting the operation of other normal requests and services.
[0040] The steps described above for obtaining the corresponding Mock data from the target cache space based on the tracking tag and interface name include: intercepting business requests through the interceptor of the target RPC interface; generating a data identifier based on the tracking tag and interface name; and determining the Mock data that matches the data identifier from the target cache space.
[0041] After the target RPC interface is called based on its interface name, the interceptor of the target RPC interface is triggered. The interceptor of the target RPC interface intercepts the business request. A data identifier key is generated based on the tracking tag and the interface name. Mock data matching the data identifier is determined from the target cache space.
[0042] Then, the interceptor of the target RPC interface directly returns the mock data { "hasCopyright": false, ...} to the caller (intermediate business service), without ever actually calling the downstream copyright service. After receiving the "no copyright" return, the intermediate business service continues with subsequent logic, and finally, in the data returned to the front end by the HTTP interface, the relevant song is displayed as "no copyright," thus triggering the front end to display the correct UI prompt.
[0043] The above method also includes: obtaining the target RPC interface and Mock data based on the tracking tag; if the target RPC interface and Mock data do not meet the preset requirements corresponding to the test instruction, updating the test instruction based on the input information; and updating the target RPC interface, tracking tag, and Mock data based on the updated test instruction so that the updated target RPC interface, tracking tag, and Mock data meet the preset requirements.
[0044] In other words, if the target RPC interface and Mock data generated by the large language model do not meet the Mock intent, the tester will update the test instructions and send the updated test instructions to the backend device to re-establish a more accurate target RPC interface, tracking tags, and Mock data.
[0045] See Figure 2 The architecture diagram of the service testing method shown illustrates the static relationships between the four core modules of the system. First, testers input the HTTP interface and mock intent. The intelligent decision layer (i.e., the large language model) determines the target RPC interface through semantic parsing and call chain analysis, thereby generating mock data. (This corresponds to the steps above: "Based on the test instructions, query the call links of the target HTTP interface from the call chain knowledge base; determine the target RPC interface matching the test instructions from the call links," and "Based on the data structure of the target's historical response data, generate mock data that conforms to the mock intent; set a unique tracking label for the mock data"). During the execution of these steps, the call chain knowledge base needs to be invoked, which is done through the data acquisition and learning layer. After determining the target RPC interface, generating mock data and tracking labels, the mock data management layer associates and caches this data.
[0046] Testers initiate test requests (i.e., the aforementioned business requests), which are intercepted by the HTTP request interceptor in the traffic execution and interception layer. The interceptor then determines the stored traffic staining (i.e., the request carries a tracking label). The RPC call interceptor identifies the staining, retrieves the corresponding Mock data from the cache, and returns the Mock data.
[0047] See Figure 3 The flowchart shown illustrates the complete service testing method. After initiating a business request, the process first determines if a trace_tag exists in the request. If so, the corresponding Mock data is retrieved from the cache based on the determined key (i.e., data identifier). If not, a normal RPC call is initiated. Similarly, if the corresponding Mock data does not exist in the cache, a normal RPC call is still initiated.
[0048] See Figure 4 The interactive flowchart of the service testing method shown illustrates the flow and interception of requests in the backend device. First, the tester initiates a test command (i.e., a Mock command), which is sent to the LLM (Large Language Model Layer) of the backend device. The LLM determines the target RPC interface, Mock data, and tracking tags. The diagram only shows the tracking tags being returned to the frontend; in reality, the interface name of the target RPC interface is also returned to the frontend.
[0049] Then, the tester can initiate a request carrying a tracking tag. Based on the tracking tag, various interceptors can intercept the request. Finally, the tester retrieves the Mock data corresponding to the business request from the Mock cache and returns it to the front end. In this method, the downstream business services are not called.
[0050] Corresponding to the above, this disclosure provides a service testing apparatus, such as... Figure 5 As shown, the device includes: The receiving module 501 is used to receive test instructions, which include: the target HTTP interface to be tested and the Mock intent; The generation module 502 is used to determine the target RPC interface that matches the test instructions, and to generate Mock data that conforms to the Mock intent, as well as tracking tags for the Mock data; The caching module 503 is used to associate the target RPC interface, tracking tags, and Mock data, and store them in the target cache space; The acquisition module 504 is used to receive business requests. If the business request carries a tracking tag and an interface name that indicates the target RPC interface, it retrieves the corresponding Mock data from the target cache space based on the tracking tag and the interface name. Return module 505 is used to return Mock data as the request response to the business request in order to complete the service test corresponding to the business request.
[0051] This disclosure provides a service testing apparatus that receives a test instruction, which includes: a target HTTP interface to be tested and a mock intent; determines a target RPC interface matching the test instruction and generates mock data conforming to the mock intent, as well as a tracking tag for the mock data; associates the target RPC interface, tracking tag, and mock data and stores them in a target cache space; receives a business request, and if the business request carries a tracking tag and an interface name indicating the target RPC interface, retrieves the corresponding mock data from the target cache space based on the tracking tag and interface name; and returns the mock data as a request response to the business request to complete the service test corresponding to the business request. In this approach, testers do not need to have in-depth knowledge of the entire call chain and data structure; they can pre-determine the target RPC interface to be called by subsequent business requests and the mock data conforming to the mock intent through the test instruction, lowering the testing threshold, avoiding test deviations caused by manually constructing mock data, and thus improving test accuracy, test effectiveness, and test efficiency.
[0052] The aforementioned generation module is also used to: query the call links of the target HTTP interface from the link knowledge base according to the test instructions; and determine the target RPC interface that matches the test instructions from the call links.
[0053] The aforementioned generation module is also used to: determine target historical response data that matches the Mock intent from the historical response data of the target RPC interface; generate Mock data that conforms to the Mock intent based on the data structure of the target historical response data; and set a unique tracking tag for the Mock data.
[0054] The aforementioned device also includes a tag return module, used to return the interface name and tracking tag of the target RPC interface to the front-end device.
[0055] The aforementioned device also includes an interception module, used to: intercept business requests through an interceptor of the target HTTP interface; if the business request includes a tracking tag and a target RPC interface, save the tracking tag to the context; and send the business request to the target RPC interface.
[0056] The aforementioned acquisition module is also used to: intercept business requests through the interceptor of the target RPC interface; generate a data identifier based on the tracking tag and interface name; and determine the Mock data that matches the data identifier from the target cache space.
[0057] The aforementioned device also includes an update module, used for: acquiring the target RPC interface and Mock data based on the tracking tag; updating the test command based on the input information if the target RPC interface and Mock data do not meet the preset requirements corresponding to the test command; and updating the target RPC interface, tracking tag, and Mock data based on the updated test command so that the updated target RPC interface, tracking tag, and Mock data meet the preset requirements.
[0058] The service testing apparatus provided in this embodiment has the same technical features as the service testing method provided in the above embodiments, so it can also solve the same technical problems and achieve the same technical effects.
[0059] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described service testing method. This electronic device can be a server or a terminal device.
[0060] See Figure 6 As shown, the electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-described service testing method.
[0061] Furthermore, Figure 6The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103 and the memory 101 connected via the bus 102.
[0062] The memory 101 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 102 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0063] The processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 100 or by instructions in software form. The processor 100 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101, and the processor 100 reads the information from memory 101 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.
[0064] The processor in the aforementioned electronic device, by executing machine-executable instructions, can perform the following operations in the aforementioned service testing method: The test process involves receiving test instructions, which include the target HTTP interface to be tested and the mock intent. It then determines the target RPC interface matching the test instructions and generates mock data that conforms to the mock intent, along with tracking tags for the mock data. The target RPC interface, tracking tags, and mock data are associated and stored in the target cache space. Next, a business request is received. If the business request carries a tracking tag and an interface name indicating the target RPC interface, the corresponding mock data is retrieved from the target cache space based on the tracking tag and interface name. Finally, the mock data is returned as the request response to the business request, completing the service test corresponding to the business request. In this approach, testers do not need to have in-depth knowledge of the entire call chain and data structure. They can pre-determine the target RPC interface to be called by subsequent business requests and the mock data that conforms to the mock intent through test instructions. This lowers the testing threshold, avoids test deviations caused by manually constructing mock data, and thus improves test accuracy, test effectiveness, and test efficiency.
[0065] The steps for determining the target RPC interface that matches the test instruction include: querying the call link of the target HTTP interface from the link knowledge base according to the test instruction; and determining the target RPC interface that matches the test instruction from the call link.
[0066] The steps described above for generating Mock data that conforms to the Mock intent and the tracking tags for the Mock data include: determining target historical response data that matches the Mock intent from the historical response data of the target RPC interface; generating Mock data that conforms to the Mock intent based on the data structure of the target historical response data; and setting a unique tracking tag for the Mock data.
[0067] After associating the target RPC interface, tracking tag, and Mock data with the above steps and storing them in the target cache space, the method further includes: returning the interface name and tracking tag of the target RPC interface to the front-end device.
[0068] Following the steps of receiving the business request described above, the method further includes: intercepting the business request through the interceptor of the target HTTP interface; if the business request includes a tracking tag and a target RPC interface, saving the tracking tag to the context; and sending the business request to the target RPC interface.
[0069] The steps described above for obtaining the corresponding Mock data from the target cache space based on the tracking tag and interface name include: intercepting business requests through the interceptor of the target RPC interface; generating a data identifier based on the tracking tag and interface name; and determining the Mock data that matches the data identifier from the target cache space.
[0070] The above method also includes: obtaining the target RPC interface and Mock data based on the tracking tag; if the target RPC interface and Mock data do not meet the preset requirements corresponding to the test instruction, updating the test instruction based on the input information; and updating the target RPC interface, tracking tag, and Mock data based on the updated test instruction so that the updated target RPC interface, tracking tag, and Mock data meet the preset requirements.
[0071] This embodiment also provides a machine-readable storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by the processor, the machine-executable instructions cause the processor to implement the above-mentioned service testing method.
[0072] The machine-executable instructions stored in the aforementioned machine-readable storage medium can be executed to perform the following operations in the aforementioned service testing method: The test process involves receiving test instructions, which include the target HTTP interface to be tested and the mock intent. It then determines the target RPC interface matching the test instructions and generates mock data that conforms to the mock intent, along with tracking tags for the mock data. The target RPC interface, tracking tags, and mock data are associated and stored in the target cache space. Next, a business request is received. If the business request carries a tracking tag and an interface name indicating the target RPC interface, the corresponding mock data is retrieved from the target cache space based on the tracking tag and interface name. Finally, the mock data is returned as the request response to the business request, completing the service test corresponding to the business request. In this approach, testers do not need to have in-depth knowledge of the entire call chain and data structure. They can pre-determine the target RPC interface to be called by subsequent business requests and the mock data that conforms to the mock intent through test instructions. This lowers the testing threshold, avoids test deviations caused by manually constructing mock data, and thus improves test accuracy, test effectiveness, and test efficiency.
[0073] The steps for determining the target RPC interface that matches the test instruction include: querying the call link of the target HTTP interface from the link knowledge base according to the test instruction; and determining the target RPC interface that matches the test instruction from the call link.
[0074] The steps described above for generating Mock data that conforms to the Mock intent and the tracking tags for the Mock data include: determining target historical response data that matches the Mock intent from the historical response data of the target RPC interface; generating Mock data that conforms to the Mock intent based on the data structure of the target historical response data; and setting a unique tracking tag for the Mock data.
[0075] After associating the target RPC interface, tracking tag, and Mock data with the above steps and storing them in the target cache space, the method further includes: returning the interface name and tracking tag of the target RPC interface to the front-end device.
[0076] Following the steps of receiving the business request described above, the method further includes: intercepting the business request through the interceptor of the target HTTP interface; if the business request includes a tracking tag and a target RPC interface, saving the tracking tag to the context; and sending the business request to the target RPC interface.
[0077] The steps described above for obtaining the corresponding Mock data from the target cache space based on the tracking tag and interface name include: intercepting business requests through the interceptor of the target RPC interface; generating a data identifier based on the tracking tag and interface name; and determining the Mock data that matches the data identifier from the target cache space.
[0078] The above method also includes: obtaining the target RPC interface and Mock data based on the tracking tag; if the target RPC interface and Mock data do not meet the preset requirements corresponding to the test instruction, updating the test instruction based on the input information; and updating the target RPC interface, tracking tag, and Mock data based on the updated test instruction so that the updated target RPC interface, tracking tag, and Mock data meet the preset requirements.
[0079] The computer program products of the service testing methods, apparatus and systems provided in this disclosure include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.
[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0081] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.
[0082] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0083] In the description of this disclosure, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0084] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.
Claims
1. A service testing method, characterized in that, The method includes: Receive test instructions, which include: the target HTTP interface to be tested and the Mock intent; Identify the target RPC interface that matches the test instructions, and generate Mock data that conforms to the Mock intent, as well as tracking tags for the Mock data; The target RPC interface, the tracking tag, and the Mock data are associated and stored in the target cache space; Upon receiving a service request, if the service request carries the tracking tag and an interface name for indicating the target RPC interface, obtain the corresponding Mock data from the target cache space based on the tracking tag and the interface name; The mock data is returned as the request response to the business request to complete the service test corresponding to the business request.
2. The method according to claim 1, characterized in that, The steps for determining the target RPC interface that matches the test instructions include: According to the test instructions, query the call link of the target HTTP interface from the link knowledge base; Determine the target RPC interface that matches the test instruction from the call link.
3. The method according to claim 1, characterized in that, The steps of generating Mock data that conforms to the Mock intent, and the tracking tags of the Mock data, include: From the historical response data of the target RPC interface, determine the target historical response data that matches the Mock intent; Based on the data structure of the target historical response data, generate Mock data that conforms to the Mock intent; Set a unique tracking tag for the Mock data.
4. The method according to claim 1, characterized in that, After associating the target RPC interface, the tracking tag, and the Mock data and storing them in the target cache space, the method further includes: The interface name of the target RPC interface and the tracking tag are returned to the front-end device.
5. The method according to claim 1, characterized in that, After the step of receiving the service request, the method further includes: The business request is intercepted through the interceptor of the target HTTP interface; If the business request includes a tracking tag and a target RPC interface, save the tracking tag to the context; The service request is then sent to the target RPC interface.
6. The method according to claim 5, characterized in that, The step of obtaining the corresponding Mock data from the target cache space based on the tracking tag and the interface name includes: The service request is intercepted through the interceptor of the target RPC interface; Generate a data identifier based on the tracking tag and the interface name; Determine the Mock data that matches the data identifier from the target cache space.
7. The method according to claim 4, characterized in that, The method further includes: Based on the tracking tag, obtain the target RPC interface and the Mock data; If the target RPC interface and the Mock data do not meet the preset requirements corresponding to the test instruction, update the test instruction based on the input information; Based on the updated test instructions, the target RPC interface, the tracking tag, and the Mock data are updated to ensure that the updated target RPC interface, tracking tag, and Mock data meet the preset requirements.
8. A service testing apparatus, characterized in that, The device includes: A receiving module is used to receive test instructions, which include: the target HTTP interface to be tested and a mock intent; The generation module is used to determine the target RPC interface that matches the test instruction, and generate Mock data that conforms to the Mock intent, as well as the tracking tags of the Mock data; A caching module is used to associate the target RPC interface, the tracking tag, and the Mock data, and store them in the target cache space; The acquisition module is used to receive business requests. If the business request carries the tracking tag and the interface name used to indicate the target RPC interface, it acquires the corresponding Mock data from the target cache space according to the tracking tag and the interface name. The return module is used to return the Mock data as the request response to the business request, so as to complete the service test corresponding to the business request.
9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the service testing method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the service testing method according to any one of claims 1-7.