A service interface testing method and related device
By acquiring server-side logs and tracing data through custom post-processors and combining them with assertion rules to generate test result data, this solves the problem that automated interface testing platforms in microservice architectures cannot fully verify the internal processing status of the server, thus improving testing efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING SOHU NEW MEDIA INFORMATION TECH
- Filing Date
- 2025-12-16
- Publication Date
- 2026-06-02
AI Technical Summary
In a microservice architecture, existing automated interface testing platforms cannot fully verify the internal processing status of the server, resulting in limited testing efficiency and quality, requiring testers to invest additional manpower in troubleshooting.
This paper provides a server-side interface testing method that obtains server logs and trace data through a custom post-processor, and generates test result data by combining assertion rules. It supports custom assertions and result visualization.
It enables comprehensive verification of the internal state of the server, shortens testing and troubleshooting time, improves testing efficiency and accuracy, reduces the process of repeatedly interpreting data, and improves team collaboration efficiency.
Smart Images

Figure CN121349898B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of distributed processing technology, and in particular to a server-side interface testing method and related apparatus. Background Technology
[0002] With the widespread adoption of distributed systems and microservice architectures, server-side interfaces, as the core carriers of inter-system interaction, directly determine system availability through their stability, performance, and logical correctness. Automated interface testing, as a crucial means of ensuring interface quality, has become a core component of enterprise R&D processes.
[0003] Most current testing platforms offer features such as test case configuration, multi-protocol support, and test report generation. However, in a microservice architecture, API request processing involves multiple service nodes (such as gateways, business services, and databases), and the internal processing status of the server cannot be verified solely through API response data. This necessitates additional manpower from testers for troubleshooting, thus limiting testing efficiency. Summary of the Invention
[0004] In view of the above problems, this application provides a server-side interface testing method and related apparatus to improve testing efficiency. The specific solution is as follows:
[0005] The first aspect of this application provides a server-side interface testing method, including:
[0006] In response to the completion signal of the interface request, obtain the current interface request identifier;
[0007] The original query data is obtained from the server according to the data query request, which is generated based on the current interface request identifier and the query conditions corresponding to the data type of the query;
[0008] The data parsing logic corresponding to the query data type is invoked to filter the original query data and obtain parsed data in a preset format.
[0009] The parsed data is asserted according to the pre-configured assertion rules to obtain the assertion result data of the parsed data;
[0010] Test result data is generated based on the query data type, the parsed data, and the assertion result data.
[0011] In one possible implementation, when the query data type is log data, the step of obtaining the original query data from the server according to the data query request, wherein the data query request is generated based on the current interface request identifier and the query conditions corresponding to the query data type, including:
[0012] The data query request is generated based on the log type, key field list, and current interface request identifier of the log data;
[0013] The log system interface is invoked to obtain the original query data from the server based on the data query request.
[0014] In one possible implementation, when the query data type is link tracing data, the step of obtaining the original query data from the server according to the data query request, wherein the data query request is generated based on the current interface request identifier and the query conditions corresponding to the query data type, includes:
[0015] The current interface request identifier is used as the link tracing identifier of the link tracing data to generate the data query request;
[0016] The link tracing interface is invoked to obtain the original query data from the server based on the data query request.
[0017] In one possible implementation, the step of invoking the data parsing logic corresponding to the query data type to filter the original query data and obtain parsed data in a preset format includes:
[0018] For each log entry extracted from the original query data, each keyword and its corresponding value are extracted according to the list of key fields, and the keywords and their corresponding values are stored according to the preset format to obtain the parsed data.
[0019] In one possible implementation, the step of invoking the data parsing logic corresponding to the query data type to filter the original query data and obtain parsed data in a preset format includes:
[0020] The original query data is parsed based on the link feature data to obtain the link parsing data;
[0021] For each link parsing data, each keyword and its corresponding value are extracted according to the key field list, and the extraction results are stored according to the preset format to obtain the parsed data.
[0022] In one possible implementation, the process of obtaining the assertion rule includes:
[0023] The assertion rules are generated based on the assertion dimension information, comparison operators, and target values entered in the assertion configuration interface; or,
[0024] The script engine is invoked to parse the assertion script and obtain the assertion rules.
[0025] In one possible implementation, generating test result data based on the query data type, the parsed data, and the assertion result data includes:
[0026] The query data type and the corresponding data volume information are displayed as server overview information;
[0027] The parsed data is displayed as structured data information according to the input order of the key fields;
[0028] The assertion result data is then labeled and distinguished according to the assertion results, and then displayed as assertion result information.
[0029] A second aspect of this application provides a server-side interface testing apparatus, comprising:
[0030] The request information acquisition module is used to obtain the current interface request identifier in response to the response completion signal of the interface request;
[0031] The raw data acquisition module is used to acquire raw query data from the server according to a data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the data type of the query.
[0032] The structured data parsing module is used to call the data parsing logic corresponding to the query data type, filter the original query data, and obtain parsed data in a preset format.
[0033] The data parsing assertion module is used to perform assertion processing on the parsed data according to pre-configured assertion rules to obtain the assertion result data of the parsed data; and,
[0034] The assertion result display module is used to generate test result data based on the query data type, the parsed data, and the assertion result data.
[0035] A third aspect of this application provides a computer program product, including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement the server interface testing method described in the first aspect or any implementation thereof.
[0036] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:
[0037] The memory is used to store computer programs;
[0038] The processor is used to execute the computer program so that the electronic device can implement the server interface testing method of the first aspect or any implementation thereof.
[0039] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the server interface testing method described in the first aspect or any implementation thereof.
[0040] By employing the above technical solution, the server-side interface testing method provided in this application can obtain the current interface request identifier in response to the response completion signal of an interface request. Based on the current interface request identifier and the query conditions corresponding to the query data type, a data query request is generated, and the original query data is obtained based on this data query request. By calling the data parsing logic corresponding to the query data type, the original query data is filtered to obtain parsed data in a preset format. Then, assertions are performed on the parsed data according to pre-configured assertion rules to obtain assertion result data for the parsed data. Finally, test result data is generated and displayed based on the query data type, parsed data, and assertion result data. This achieves targeted acquisition of key data generated by the server when processing interface requests, structured parsing of the acquired server information, and supports configuring custom assertions based on the parsing results and visualizing assertion result information. This improves the comprehensiveness and efficiency of automated server-side interface testing. Attached Figure Description
[0041] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.
[0042] Figure 1 An architecture diagram of a server-side interface testing system provided in this application;
[0043] Figure 2 A flowchart of a server-side interface testing method provided in this application;
[0044] Figure 3 A structural diagram of a server interface testing device provided in this application;
[0045] Figure 4 This is a structural diagram of an electronic device provided in this application. Detailed Implementation
[0046] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0047] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.
[0048] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.
[0049] See Figure 1 , Figure 1 A schematic diagram of the architecture of a server-side interface testing system is shown. The system may include a terminal 100 and a server 200. The server 200 can provide the server-side interface testing method provided in this embodiment to one or more terminals.
[0050] The terminal 100 may have a server-side interface testing application installed on it. The application and webpage can provide an interface. The terminal 100 can receive relevant parameters input by the user on the server-side interface testing interface and send the parameters to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.
[0051] The following description Figure 1 The product form of the mid-terminal 100;
[0052] The terminal 100 in this application embodiment can be a tablet computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.
[0053] Terminal 100 may include a radio frequency unit, memory, input unit, display unit, camera (optional), audio circuitry (optional), speaker (optional), microphone (optional), headphone jack (optional), processor, external interface, power supply, and other components. Those skilled in the art will understand that the above-mentioned components are merely examples and do not constitute a limitation on the terminal or multifunctional device; it may include more or fewer components, or a combination of certain components, or different components.
[0054] The input unit can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit may include a touchscreen (optional) and / or other input devices. Other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.
[0055] Among them, the input device can receive input data, etc.
[0056] The display unit can be used to display information input by the user or information provided to the user, various menus of the terminal, interactive interfaces, file display, and / or playback of any multimedia file. In the embodiments of this application, the display unit can be used to display the interface of server-side interface testing, processing results, etc.
[0057] The memory can be used to store software code related to the server interface testing method, the processor can execute the steps of the server interface testing method, and can also schedule other units (such as the above-mentioned input unit and display unit) to achieve the corresponding functions.
[0058] This radio frequency unit (optional) can be used to receive and send signals during information transmission or calls.
[0059] In this embodiment of the application, the radio frequency unit can send data to the server 200 and receive the processing results sent by the server 200.
[0060] It should be understood that this radio frequency unit is optional and can be replaced with other communication interfaces, such as a network port.
[0061] Terminal 100 also includes a power source (such as a battery) for supplying power to the various components.
[0062] Terminal 100 also includes an external interface, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.
[0063] Server 200 includes a bus, a processor, a communication interface, and memory. The processor, memory, and communication interface communicate with each other via the bus.
[0064] The memory can be used to store software code related to the server interface testing method, the processor can execute the steps of the chip's server interface testing method, and can also schedule other units to achieve the corresponding functions.
[0065] Currently, commonly used open-source testing platforms such as MeterSphere are widely used in the field of API automation testing due to their features such as visual test case configuration, multi-protocol support (HTTP / HTTPS / TCP), and test report generation. Their main testing process is as follows: user creates API test cases → configures API request parameters (such as URL, request headers, and input parameters) → executes tests → displays response data.
[0066] However, in a microservice architecture, the processing of interface requests involves multiple service nodes (such as gateways, business services, and databases). The internal processing status of the server cannot be fully verified by the interface response data alone. For example, the interface may return "success" but the server logs may contain business processing error information, or the tracing chain may show that a certain service node is in an abnormal state or has data errors. These hidden problems cannot be discovered by relying solely on the native MeterSphere platform and require testers to invest additional manpower to investigate, which limits the efficiency and quality of testing.
[0067] To address the aforementioned problems, this application provides a server-side interface testing method. The server-side interface testing method of this application embodiment will be described in detail below with reference to the accompanying drawings.
[0068] Reference Figure 2 , Figure 2 This application provides a flowchart illustrating a server-side interface testing method according to an embodiment of the present application. Figure 2 As shown in the embodiments of this application, the server interface testing method may include steps 201 to 205, which are described in detail below.
[0069] 201. In response to the completion signal of the interface request, obtain the current interface request identifier.
[0070] Specifically, a custom post-processor can be registered as an extension component of MeterSphere. Based on the interface information (server information: domain name & path) and user configuration information (whether the custom post-processor switch is turned on), the system determines whether to call the custom post-processor module. By linking the MeterSphere plugin extension interface with the native test process, the triggering time can be set to obtain server information via HTTP protocol after the interface request is sent and the response is received. At the same time, it is ensured that the post-processor only executes after the interface response is completed, without affecting the native request sending logic.
[0071] The current interface request identifier, such as request ID and request timestamp, transmitted by the receiving platform serves as a key basis for associating server-side information.
[0072] 202. Obtain the original query data from the server based on the data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the data type.
[0073] Specifically, users can create interface test cases in the MeterSphere interface. After completing the native configuration (such as URL, request headers, and response assertions), they can enter the post-processing configuration page and select a custom server-side information processor. In the post-processor configuration interface, users can select the server-side information type, such as log data or tracing data (i.e., distributed tracing data), and can select one or more.
[0074] Server-side information source parameter settings: such as the log system API address, the tracing system query address, etc.
[0075] Information filtering criteria: such as the scope of log retrieval being: unique ID of the interface request, request ID of tracing data = current interface request ID, etc.
[0076] Users trigger test case execution through MeterSphere. MeterSphere's request sending module sends an interface request to the server and records the request ID, request start time, and request end time. After the server returns response data, MeterSphere's test execution engine detects that the current test case is associated with a custom post-processor, triggers the post-processor to execute, and passes the request ID, request start time, and request end time to the post-processor's information acquisition module.
[0077] The subsequent information acquisition module constructs a data query request based on the aforementioned server-side information source parameters, interface request identifier, and query conditions, and then obtains the original query data returned by the server based on the data query request.
[0078] 203. Call the data parsing logic corresponding to the query data type to filter and process the original query data to obtain parsed data in a preset format.
[0079] Specifically, based on the obtained raw query data, specific data parsing logic can be executed for different types of raw query data to generate structured parsed data.
[0080] 204. Perform assertion processing on the parsed data according to the pre-configured assertion rules to obtain the assertion result data of the parsed data.
[0081] Specifically, when configuring the post-processor, users can customize assertions in the assertion rule configuration section. For example, assertion rules can be set through a visual configuration interface, or the corresponding script can be directly input through script configuration. After parsing, the corresponding assertion rules are obtained, thereby enabling the use of rules to perform corresponding assertion processing on the parsed data.
[0082] 205. Generate test result data based on the query data type, parsed data, and assertion result data.
[0083] Specifically, the three types of data can be integrated and displayed according to a unified template by calling the formatted display module. The formatted display data can be converted into HTML fragments and integrated into the native test report through the MeterSphere report generation interface. Users can view it directly in the MeterSphere interface and export a complete report containing server-side information.
[0084] This server-side interface testing method uses a custom post-processor to obtain server-side logs and tracing data, and displays them in conjunction with interface requests. When interface testing fails, testers do not need to log into multiple systems to query information; they can directly view the server's internal status, such as the cause of log errors and abnormal nodes in the tracing chain, in the MeterSphere report. This significantly shortens troubleshooting time. Based on actual project verification, troubleshooting time can be reduced from an average of 10 minutes to less than 2 minutes, improving efficiency by 80%. Furthermore, assertions can be set based on internal server-side data (such as tracing node status, business data, and log data). For example, for an advertising response interface, assertions can be made simultaneously for response code 200, advertising creatives, the status of filtered service nodes in tracing, and intermediate log result fields. Assertion coverage extends from the interface layer to the internal server layer, reducing the test omission rate by more than 70%.
[0085] By integrating server-side information, parsing results, and assertion results into a unified report through formatted display, the system effectively reduces switching between multiple platforms. This allows team members to obtain complete test information through the same report, effectively reducing the process of repeatedly interpreting fragmented data and improving the efficiency of team collaboration.
[0086] In one embodiment, when the data type being queried is log data, the raw query data is obtained from the server based on the data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the data type being queried, and may specifically include:
[0087] Generate a data query request based on the log type, key field list, and current interface request identifier of the log data;
[0088] The log system interface is called to retrieve raw query data from the server based on the data query request.
[0089] The corresponding data parsing logic for the query data type is invoked to filter and process the original query data, obtaining parsed data in a preset format, which may specifically include:
[0090] For each log entry extracted from the original query data, each keyword and its corresponding value are extracted based on the list of key fields. The keywords and their corresponding values are then stored according to a preset format to obtain the parsed data.
[0091] Specifically, when retrieving log data, the log system API is called, passing in the query conditions: Request ID=xxx AND Log Type=as_search AND List of key fields to be extracted, and the associated log data is pulled to obtain log data in string array format.
[0092] Then, the log content of each log entry is extracted, and the target keywords and values are filtered out based on the input list of key fields to be extracted, generating a structured log list.
[0093] For example, the list of key fields to be extracted:
[0094] ["adslotid", "guuid", "os", "osv", "appv", "appid", "newschn", "nets", "carrierid", "abc"].
[0095] The following is a partial excerpt from the log data:
[0096] "2023-02-02 16:00:01 p=1675324801 id=08e020c885e3ee9fe_0_0 newschn=50 os=iOS osv=15.1.0 model=iPhone12%2C3 scs=112502436 nets=1 ssid=SOHU.COM bssid=28:ac:9e:c5:43:8f manufacturer=apple carrierid=3 fold_screen=0 boot_mark=1674868909.74483 update_mark=1576638871.335489249 density=3 appv=6.8.9 sdkv=poid= pageurl= reqid= pid=1020 newsdkpid=0 newswappid= tvpid= h5tvpid= mac=02:00:00:00:00:00 adsid= imei= imsi= androidid= oaid= cid=6588623729554010235 did= sid= suv= yyid= tuv= lsc= ssc= openudid= smuid= ip=36.110.204.2 ip_type=1 geoid1=1156110000 geoid2=1156110000 longitude=0.000000 latitude=0.000000 citycode= adslotid=12715 turn=1 adslottype=4 w=3000 h=1 blacktempls=adslotclass=0 vchn= xid= flag_sensitive=0 reposition= lc= rr= action= rc=1 roomid=0 combined_ad= is_combined_ad=0 link_position= link_campaign_id= con_position= ad_position= tt1=1675324801265 tt2=1675324801303 landpage_ext=showtime= sliding= ad_sell_mode= dyproid= …".
[0097] The structured log extraction result is obtained:
[0098] {'adslotid':'12715','guuid':'This parameter does not exist'
[0099] ','os':'iOS','osv':'15.1.0','appv':'6.8.9','appid':'news','newschn':'50','nets':'1','carrierid':'3','abc':'This parameter does not exist'}).
[0100] The page will be displayed in two neat rows, making it easy to make comparisons.
[0101] In another embodiment, when the data type being queried is link tracing data, the original query data is obtained from the server according to the data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the data type, including:
[0102] Use the current interface request identifier as the link tracing identifier for the link tracing data, and generate a data query request;
[0103] The tracing interface is invoked to retrieve the raw query data from the server based on the data query request.
[0104] The corresponding data parsing logic for the query data type is invoked to filter and process the original query data, obtaining parsed data in a preset format, including:
[0105] The original query data is parsed based on the link feature data to obtain the link parsing data;
[0106] For each link's parsed data, each keyword and its corresponding value are extracted based on the list of key fields, and the extracted results are stored according to a preset format to obtain the parsed data.
[0107] Specifically, when obtaining tracing data, the complete call chain data is retrieved by calling the tracing system API and passing in the query condition "traceID=xxx".
[0108] When parsing tracing data: extract "traceID, service name (serviceName), node duration (duration), node status code (statusCode), and business data (data)". Based on the input list of key fields to be extracted, filter out the target keywords and values to generate structured tracing data. For example, the extracted raw data is:
[0109] 2025-10-27, 14:53:03, p=1761547983:
[0110] {"impression_id":"0a913b016dc463d70","module_level":"0.6","module_name":"auction","module_rt":10,"module_data":"{\"auction_logging\":[{\"ip\":\"10.31.71.92\",\"service_name\":\"as-app-gray\",\"timestamp\":1761547983,\"random_rank\":false,\"platformid\":1,\"appid\":\"news\",\"adslotid\":13016,\"adslottype\":1,\"max_ad_num\":2,\"geoid1\":1156210100,\"geoid2\":1156210100,\"os\":\"iOS\",\"nets\":1,\"browser\":\"UnknownTODO\",\"appv\":\"7.4.0\",\"lc\":5,\"rr\":5,\"triggered_list\":[\"10034894|20168520|40700380|105219287|250|1|9|0|0|2|1|4000000|4000|4000|0.000000|4000000.000000|4000000.000000||1|0|0|0|0.000000|0.000000|11|0|0|0|0000000000000000|1.000000|13016|0|0|0|0.000000|0.000000|0.000000|0.000000||0|0|0|0.000000|11|0|4000000|0|100|0.000000||0||0.000000|702,805,12037,18006,19007,120302,150212,150305,160100,160200,160300,170601,220103,220600,220800,220901,3001005\" ,\"10038638|20168862|40701129|105225038|200|1|1|0|0|2|1|4000000|4000|4000|0.000000|4000000.000000|4000000.000000||1|0|0|0|0.000000|0.000000|4|0|0|0|000000000000000|1.000000|13016|0|0|0|0.000000|0.000000|0.000000|0.000000||0|0|0|0|0.000000|4|0|4000000|0|100|0.000000||0 ||0.000000|702,805,12037,18006,19007,120302,150212,150305,160100,160200 ,160300,170601,220103,220600,220800,220901,3001005\","traffic_flag":2}..
[0111] List of key fields to be extracted:
[0112] ["aid", "campid", "crid", "adslotid", "gsp_charge", "nongspcharge", "is_filtered"].
[0113] The structured extraction results are displayed on the page below:
[0114] [{"aid":"10034894","adgid":"40700380","priority":"250","crid":"105219287","is_filtered":"0","filter_type":"0","campid":"20168520","adslotid":"13016"}.
[0115] {"aid":"10038638","adgid":"40701129","priority":"200","crid":"105225038","is_filtered":"0","filter_type":"0","campid":"20168862","adslotid":"13016"}.
[0116] Finally, the structured data is passed to the assertion module for assertion processing.
[0117] In some embodiments, to facilitate users in formulating and adjusting assertion rules, the process of obtaining assertion rules includes:
[0118] Based on the assertion dimension information, comparison operators, and target values entered in the assertion configuration interface, generate assertion rules; or,
[0119] The script engine is invoked to parse the assertion script and obtain the assertion rules.
[0120] Specifically, when defining assertion rules through visual configuration, you select the assertion dimension (such as "tracing node status" or "log field value"), comparison operator (such as "=" or "≠"), and target value (such as "success" or "1"). For example, "the status of the bs node in the tracing link = success", or "the field is_virtual in the log != 1". The corresponding assertion rules are then generated.
[0121] When configuring via script, the script can be used to determine if the status of the node with the service name "bs" in the structured tracing data equals "success". Since MeterSphere is an interface testing platform based on the JMeter engine, its core test execution capabilities (such as protocol parsing, request sending, response processing, and script execution) rely on JMeter's underlying engine. The script engine integrated into JMeter can be reused to execute script code. The role of the script engine is to: parse the syntax in the script (such as conditional statements, variable operations, and function calls); convert the script logic into JVM-executable bytecode (or interpret execution); and execute the specific logic in conjunction with the context objects provided by JMeter (such as response data, variables, and sampler results).
[0122] Of course, those skilled in the art can select and adjust the above-mentioned script engines according to different application platforms, which will not be elaborated here.
[0123] In other embodiments, to facilitate user viewing of results, the generation of test result data based on the query data type, parsed data, and assertion result data may specifically include:
[0124] The query data type and the corresponding data volume information are displayed as server overview information;
[0125] The parsed data is displayed in a structured manner according to the input order of the key fields;
[0126] After the assertion results are distinguished and labeled according to the assertion results, they are displayed as assertion result information.
[0127] Specifically, the three types of data can be integrated using a unified template:
[0128] Server-side information overview: Information type (log / tracing), data volume (e.g., "log as search 10 records, auction_triggerlist 200 records").
[0129] Structured data details: Key log fields are listed in the order they were entered, and key tracing data is displayed in JSON format; the original logs and tracing data can be viewed in the details.
[0130] Assertion results: Displayed in sorted order by assertion item, with failed assertions highlighted in red, and both expected and actual values indicated; assertion parameter range supports referencing parameter values extracted by custom post-processors.
[0131] Finally, the formatted data is converted into HTML fragments and integrated into the native test report through MeterSphere's report generation interface. Users can view it directly in the MeterSphere interface and export it (a complete report including server-side information).
[0132] The above describes a server-side interface testing method provided by the embodiments of this application. The following describes the apparatus for performing the above-described server-side interface testing method.
[0133] Please see Figure 3 , Figure 3 This is a schematic diagram of a server interface testing device provided in an embodiment of this application. Figure 3 As shown, the server-side interface testing device includes:
[0134] The request information acquisition module 301 is used to acquire the current interface request identifier in response to the response completion signal of the interface request;
[0135] The raw data acquisition module 302 is used to obtain raw query data from the server according to the data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the data type of the query.
[0136] The structured data parsing module 303 is used to call the data parsing logic corresponding to the query data type, filter the original query data, and obtain parsed data in a preset format.
[0137] The data parsing assertion module 304 is used to perform assertion processing on the parsed data according to pre-configured assertion rules to obtain the assertion result data of the parsed data; and,
[0138] The assertion result display module 305 is used to generate test result data based on the query data type, parsed data, and assertion result data.
[0139] In one possible implementation, when the query data type is log data, the raw data acquisition module 302 obtains the raw query data from the server according to the data query request. The data query request is generated by the process of generating the request based on the current interface request identifier and the query conditions corresponding to the query data type, including:
[0140] Generate a data query request based on the log type, key field list, and current interface request identifier of the log data;
[0141] The log system interface is called to retrieve raw query data from the server based on the data query request.
[0142] In one possible implementation, when the query data type is link tracing data, the raw data acquisition module 302 obtains the raw query data from the server according to the data query request. The data query request is generated by a process based on the current interface request identifier and the query conditions corresponding to the query data type, including:
[0143] Use the current interface request identifier as the link tracing identifier for the link tracing data, and generate a data query request;
[0144] The tracing interface is invoked to retrieve the raw query data from the server based on the data query request.
[0145] In one possible implementation, the structured data parsing module 303 calls the data parsing logic corresponding to the query data type to filter and process the original query data to obtain parsed data in a preset format. This process includes:
[0146] For each log entry extracted from the original query data, each keyword and its corresponding value are extracted based on the list of key fields. The keywords and their corresponding values are then stored according to a preset format to obtain the parsed data.
[0147] In one possible implementation, the structured data parsing module 303 calls the data parsing logic corresponding to the query data type to filter and process the original query data to obtain parsed data in a preset format. This process includes:
[0148] The original query data is parsed based on the link feature data to obtain the link parsing data;
[0149] For each link's parsed data, each keyword and its corresponding value are extracted based on the list of key fields, and the extracted results are stored according to a preset format to obtain the parsed data.
[0150] In one possible implementation, the process of obtaining assertion rules in the parsing data assertion module 304 includes:
[0151] Based on the assertion dimension information, comparison operators, and target values entered in the assertion configuration interface, generate assertion rules; or,
[0152] The script engine is invoked to parse the assertion script and obtain the assertion rules.
[0153] In one possible implementation, the process by which the assertion result display module 305 generates test result data based on the query data type, parsed data, and assertion result data includes:
[0154] The query data type and the corresponding data volume information are displayed as server overview information;
[0155] The parsed data is displayed in a structured manner according to the input order of the key fields;
[0156] After the assertion results are distinguished and labeled according to the assertion results, they are displayed as assertion result information.
[0157] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0158] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. When the electronic device is powered on, the RAM 403 also stores various programs and data required for the operation of the electronic device. The processing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0159] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, memory cards, hard drives, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.
[0160] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the server interface testing methods provided in this application.
[0161] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the server interface testing methods provided in this application.
[0162] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0163] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0164] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.
[0165] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
Claims
1. A server-side interface testing method, characterized in that, include: In response to the completion signal of the interface request, obtain the current interface request identifier, including: Register the custom postprocessor as an extension component of MeterSphere, and set the trigger time to obtain server information via the HTTP protocol after the interface request is sent and the response is received, and receive the current interface request identifier transmitted by the platform. The original query data is obtained from the server according to the data query request, which is generated based on the current interface request identifier and the query conditions corresponding to the query data type, including: When the data type of the query is log data, the data query request is generated based on the log type, key field list, and current interface request identifier of the log data; the log system interface is called to obtain the original query data from the server based on the data query request; When the data type of the query is link tracing data, the current interface request identifier is used as the link tracing identifier of the link tracing data, and the data query request is generated; the link tracing interface is called to obtain the original query data from the server according to the data query request; After the server returns the response data, MeterSphere's test execution engine detects that the current test case is associated with a custom post-processor, triggers the execution of the post-processor, and passes the request ID, request start time, and request end time to the post-processor's information acquisition module; The data parsing logic corresponding to the query data type is invoked to filter the original query data and obtain parsed data in a preset format, including: For each log entry extracted from the original query data, each keyword and its corresponding value are extracted according to the key field list, and the keywords and their corresponding values are stored according to the preset format to obtain the parsed data; the original query data is parsed according to the link feature data to obtain link parsing data; for each link parsing data entry, each keyword and its corresponding value are extracted according to the key field list, and the extraction results are stored according to the preset format to obtain the parsed data; The parsed data is asserted according to the pre-configured assertion rules to obtain the assertion result data of the parsed data; Based on the query data type, the parsed data, and the assertion result data, test result data is generated, including: By calling the formatted display module, the three types of data are integrated and displayed according to a unified template, and then integrated into the native test report through the MeterSphere report generation interface.
2. The server-side interface testing method according to claim 1, characterized in that, The process of obtaining the assertion rules includes: The assertion rules are generated based on the assertion dimension information, comparison operators, and target values entered in the assertion configuration interface; or, The script engine is invoked to parse the assertion script and obtain the assertion rules.
3. The server-side interface testing method according to claim 1 or 2, characterized in that, The step of generating test result data based on the query data type, the parsed data, and the assertion result data includes: The query data type and the corresponding data volume information are displayed as server overview information; The parsed data is displayed as structured data information according to the input order of the key fields; The assertion result data is then labeled and distinguished according to the assertion results, and then displayed as assertion result information.
4. A server-side interface testing device, characterized in that, include: The request information acquisition module is used to obtain the current interface request identifier in response to the response completion signal of the interface request, including: Register the custom postprocessor as an extension component of MeterSphere, and set the trigger time to obtain server information via the HTTP protocol after the interface request is sent and the response is received, and receive the current interface request identifier transmitted by the platform. The raw data acquisition module is used to obtain raw query data from the server according to a data query request. The data query request is generated based on the current interface request identifier and the query conditions corresponding to the query data type, including: When the data type of the query is log data, the data query request is generated based on the log type, key field list, and current interface request identifier of the log data; the log system interface is called to obtain the original query data from the server based on the data query request; When the data type of the query is link tracing data, the current interface request identifier is used as the link tracing identifier of the link tracing data, and the data query request is generated; the link tracing interface is called to obtain the original query data from the server according to the data query request; After the server returns the response data, MeterSphere's test execution engine detects that the current test case is associated with a custom post-processor, triggers the execution of the post-processor, and passes the request ID, request start time, and request end time to the post-processor's information acquisition module; The structured data parsing module is used to call the data parsing logic corresponding to the query data type, filter the original query data, and obtain parsed data in a preset format, including: For each log entry extracted from the original query data, each keyword and its corresponding value are extracted according to the key field list, and the keywords and their corresponding values are stored according to the preset format to obtain the parsed data; the original query data is parsed according to the link feature data to obtain link parsing data; for each link parsing data entry, each keyword and its corresponding value are extracted according to the key field list, and the extraction results are stored according to the preset format to obtain the parsed data; The data parsing assertion module is used to perform assertion processing on the parsed data according to pre-configured assertion rules to obtain the assertion result data of the parsed data; and, The assertion result display module is used to generate test result data based on the query data type, the parsed data, and the assertion result data, including: By calling the formatted display module, the three types of data are integrated and displayed according to a unified template, and then integrated into the native test report through the MeterSphere report generation interface.
5. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the server interface testing method as described in any one of claims 1 to 3.
6. A computer storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the server interface testing method as described in any one of claims 1 to 3.