Pressure testing method, device, computer equipment, readable storage medium and program product

Abstract

The application relates to a pressure test method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: obtaining service request data of a service to be tested when a pressure test request is received; recording downstream service request data sent to a downstream service and service response data returned by the downstream service in a process in which the service to be tested processes a service processing request, obtaining service recording data; returning service response data corresponding to a service pressure test request to the service to be tested in a pressure test process through the service recording data; collecting monitoring data in a pressure test process of the service to be tested; and performing pressure test analysis and processing to obtain a pressure test result of the service to be tested. The application can simulate real downstream results and return the same, guarantees the consistency of service processing logic in the pressure test process, and thus improves the test accuracy of pressure test on a single service.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a stress testing method and device, a computer device, a readable storage medium, and a program product. BACKGROUND

[0002] With the development of computer technology and Internet technology, stress testing technology for single services has emerged. This stress testing method simulates a large number of users accessing or high-load running a specific service at the same time to evaluate its performance and stability under extreme conditions.

[0003] Currently, if stress testing is performed on a service, the upstream and downstream data of the service need to be shielded to view the data indicators processed by the logic of the service itself. The request data sent to the service can usually be obtained, but in addition to the internal logic of the service, a large number of downstream calls and waiting for a return are often required before the internal logic of the service is processed again to return the data. Sometimes, the processing of the downstream may become a bottleneck, causing the true performance of the stress testing service to be unable to be truly seen, thereby affecting the testing accuracy of stress testing on a single service. SUMMARY

[0004] Therefore, it is necessary to provide a stress testing method, device, computer device, computer readable storage medium, and computer program product capable of improving testing accuracy to solve the above technical problems.

[0005] In a first aspect, the present application provides a stress testing method, comprising:

[0006] In the case of receiving a stress testing request for a service to be tested, service request data of the service to be tested is obtained;

[0007] Based on the service request data, a service processing request is sent to the service to be tested in an online environment, and downstream service request data sent to a downstream service and service response data returned by the downstream service in the process of the service to be tested processing the service processing request are recorded to obtain service recording data;

[0008] Based on the service request data, a service stress testing request is sent to the service to be tested in an offline environment to perform stress testing on the service to be tested, and the service response data corresponding to the service stress testing request is returned to the service to be tested through the service recording data;

[0009] Pressure testing monitoring data of the process of the service to be tested processing the service stress testing request and the service response data is collected;

[0010] Perform pressure test analysis processing according to the pressure test monitoring data to obtain a pressure test result of the service to be tested.

[0011] In one embodiment, the service processing request is sent to the service to be tested in the online environment based on the service request data, and downstream service request data sent to a downstream service and service response data returned by the downstream service in a process in which the service to be tested processes the service processing request are recorded to obtain service recording data.

[0012] The address data and the port data of the downstream service accessed by the service to be tested are obtained, and the address data is modified into recording address data and the port data is modified into recording port data.

[0013] The service processing request is sent to the service to be tested in the online environment based on the service request data, and downstream service request data sent to a downstream service in a process in which the service to be tested processes the service processing request is intercepted based on the recording address data and the recording port data.

[0014] The downstream service request data is processed by protocol conversion to obtain protocol conversion request data.

[0015] The protocol conversion request data is sent to the downstream service, and service response data returned by the downstream service is recorded.

[0016] Service recording data is obtained according to the recorded downstream service request data and the service response data.

[0017] In one embodiment, the service recording data is obtained according to the recorded downstream service request data and the service response data, including:

[0018] A unique key corresponding to the recorded downstream service request data and the service response data is determined.

[0019] The downstream service request data and the service response data are saved based on the unique key to obtain service recording data.

[0020] In one embodiment, the service response data corresponding to the service pressure test request is returned to the service to be tested based on the service recording data, including:

[0021] Downstream service request data of the service to be tested for the service pressure test request is obtained.

[0022] A target unique key corresponding to the downstream service request data of the service pressure test request is determined.

[0023] Using the target unique key, locate the corresponding service response data in the service recording data;

[0024] Return the found service response data to the service to be tested.

[0025] In one embodiment, the method further includes:

[0026] Obtain the iterative version service corresponding to the service to be tested;

[0027] Based on the service request data, an iterative version service test request is sent to the iterative version service to perform stress testing on the iterative version service, and the iterative version service response data corresponding to the iterative version service test request is returned to the iterative version service through the service recording data.

[0028] Collect target monitoring data corresponding to the iterative version service;

[0029] The stress test results of the iterative version service are generated based on the target monitoring data.

[0030] In one embodiment, the target monitoring data includes response difference data, and the stress test results include anomaly location results;

[0031] The target monitoring data collected for the iterative version service includes:

[0032] By comparing the service response data with the iterative version service response data, response difference data is obtained;

[0033] The stress test results generated based on the target monitoring data for the iterative version service include:

[0034] Based on the response difference data, anomaly localization processing is performed on the iterative version service to obtain the anomaly localization result of the iterative version service.

[0035] Secondly, this application also provides a pressure testing device, comprising:

[0036] The data acquisition module is used to acquire service request data of the service under test when a stress test request for the service under test is received.

[0037] The load test recording module is used to send a service processing request to the service under test in the online environment based on the service request data, and record the downstream service request data sent to the downstream service and the service response data returned by the downstream service during the process of the service under test processing the service processing request, so as to obtain service recording data.

[0038] The load test replay module is used to send a service stress test request to the service under test in the offline environment based on the service request data, so as to perform stress test on the service under test, and return the service response data corresponding to the service stress test request to the service under test through the service recording data;

[0039] The test data acquisition module is used to collect stress test monitoring data of the process by which the service under test processes the service stress test request and the downstream service request data;

[0040] The test result generation module is used to perform stress test analysis and processing based on the stress test monitoring data to obtain the stress test results of the service to be tested.

[0041] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0042] Upon receiving a stress test request for the service to be tested, obtain the service request data of the service to be tested;

[0043] Based on the service request data, a service processing request is sent to the service under test in the online environment, and the downstream service request data sent to the downstream service and the service response data returned by the downstream service are recorded during the process of the service under test processing the service processing request, to obtain service recording data.

[0044] Based on the service request data, a service stress test request is sent to the service under test in the offline environment to perform stress test on the service under test, and the service response data corresponding to the service stress test request is returned to the service under test through the service recording data.

[0045] Collect stress test monitoring data of the process by which the service under test processes the service stress test request and the service response data;

[0046] The stress test results of the service to be tested are obtained by performing stress test analysis and processing based on the stress test monitoring data.

[0047] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0048] Upon receiving a stress test request for the service to be tested, obtain the service request data of the service to be tested;

[0049] Based on the service request data, a service processing request is sent to the service under test in the online environment, and the downstream service request data sent to the downstream service and the service response data returned by the downstream service are recorded during the process of the service under test processing the service processing request, to obtain service recording data.

[0050] Based on the service request data, a service stress test request is sent to the service under test in the offline environment to perform stress test on the service under test, and the service response data corresponding to the service stress test request is returned to the service under test through the service recording data.

[0051] Collect stress test monitoring data of the process by which the service under test processes the service stress test request and the service response data;

[0052] The stress test results of the service to be tested are obtained by performing stress test analysis and processing based on the stress test monitoring data.

[0053] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0054] Upon receiving a stress test request for the service to be tested, obtain the service request data of the service to be tested;

[0055] Based on the service request data, a service processing request is sent to the service under test in the online environment, and the downstream service request data sent to the downstream service and the service response data returned by the downstream service are recorded during the process of the service under test processing the service processing request, to obtain service recording data.

[0056] Based on the service request data, a service stress test request is sent to the service under test in the offline environment to perform stress test on the service under test, and the service response data corresponding to the service stress test request is returned to the service under test through the service recording data.

[0057] Collect stress test monitoring data of the process by which the service under test processes the service stress test request and the service response data;

[0058] The stress test results of the service to be tested are obtained by performing stress test analysis and processing based on the stress test monitoring data.

[0059] The aforementioned stress testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, upon receiving a stress test request for the service under test, acquire service request data of the service under test; based on the service request data, send a service processing request to the service under test in the online environment, and record the downstream service request data sent to downstream services and the service response data returned by downstream services during the processing of the service processing request, thus obtaining service recording data; based on the service request data, send a service stress test request to the service under test in the offline environment to perform stress testing on the service under test, and return the service response data corresponding to the service stress test request to the service under test through the service recording data; collect stress test monitoring data during the process of the service under test processing the service stress test request and service response data; and perform stress test analysis and processing based on the stress test monitoring data to obtain the stress test result of the service under test. The solution in this application, by pre-recording the downstream requests and responses in the online environment, allows the service stress test request to bypass the real downstream and return directly during the stress test through a replay function, thus shielding the downstream processing. This ensures the request logic of the stress test service in the process and simultaneously shields the downstream logic processing in the handling. This stress testing method can simulate and return real downstream results, ensuring the consistency of service processing logic during stress testing. It also ensures that the return of a single result does not affect the logical processing of the stress test service, thereby improving the accuracy of stress testing for individual services. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This is a diagram illustrating the application environment of a stress testing method in one embodiment;

[0062] Figure 2 This is a flowchart illustrating a stress testing method in one embodiment;

[0063] Figure 3 This is a schematic diagram illustrating the process of a service under test requesting downstream data in one embodiment.

[0064] Figure 4 This is a schematic diagram illustrating the process of recording and processing downstream data of a service request to be tested in one embodiment.

[0065] Figure 5This is a schematic diagram of the process of replaying the stress test in one embodiment;

[0066] Figure 6 This is a schematic diagram illustrating the process of recording and processing downstream data of a service request to be tested in one embodiment.

[0067] Figure 7 This is a structural block diagram of the pressure testing device in one embodiment;

[0068] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0070] The stress testing method provided in this application embodiment can be applied to, for example... Figure 1 The application environment is shown. Server 102 communicates with test server 104 via a network, and test server 104 communicates with various downstream servers 106 via a network. A data storage system can store the data that test server 104 needs to process. The data storage system can be integrated onto test server 104, or it can be located in the cloud or on other network servers. When stress testing is required on the services hosted on server 102, the user can send a corresponding stress test request to test server 104. Upon receiving the stress test request for the service under test, test server 104 obtains the service request data of the service under test; based on the service request data, it sends a service processing request to server 102 in the online environment (i.e., the service under test), and records the downstream service request data sent to downstream server 106 and the service response data returned by the downstream service during the processing of the service processing request, thus obtaining service recording data; based on the service request data, it sends a service stress test request to the service under test in the offline environment to perform stress testing on the service under test, and returns the service response data corresponding to the service stress test request to the service under test through the service recording data; it collects stress test monitoring data during the process of the service under test processing the service stress test request and service response data; and it performs stress test analysis and processing based on the stress test monitoring data to obtain the stress test results of the service under test. Server 102, test server 104, and downstream server 106 can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud computing services.

[0071] In one exemplary embodiment, such asFigure 2 As shown, a stress testing method is provided, which is applied to... Figure 1 Taking test server 104 as an example, the explanation includes the following steps 201 to 209. Wherein:

[0072] Step 201: Upon receiving a stress test request for the service to be tested, obtain the service request data of the service to be tested.

[0073] The service to be tested is the test object of the stress testing method in this application. Specifically, the service to be tested refers to an independent, runnable software service unit, usually a component of the system architecture. It can be a microservice, an API interface, a functional module, or a complete backend application. For example, an application authentication service can serve as the service to be tested, as can a search interface providing keyword search functionality. Stress testing, on the other hand, involves simulating high-load scenarios (such as a large number of concurrent users and high-frequency requests) to observe the system's performance under extreme conditions, aiming to evaluate its performance, stability, and fault tolerance. Service request data is the input content sent to the service to be tested, that is, the actual information carried in each HTTP request. Depending on the interface type, request data may include: URL parameters, request body, request headers, file upload information, etc. This request data can be obtained from online traffic, test traffic, or traffic data written by any tool; as long as there are requests, it can be recorded.

[0074] For example, during software operation, it is often necessary to perform stress tests on a specific service to determine its performance under extreme conditions. After identifying the service to be tested, the testers can generate a stress test request to the test server 104 based on the identified service. The test server will then determine the server 102 hosting the service to be tested based on the received stress test request, and simultaneously search for a batch of service request data corresponding to that service (in a real-world scenario, this could involve hundreds of thousands of requests).

[0075] Step 203: Based on the service request data, send a service processing request to the service to be tested in the online environment, and record the downstream service request data sent to the downstream service and the service response data returned by the downstream service during the service processing process of the service to be tested, to obtain service recording data.

[0076] In this context, a service processing request refers to an online request sent to the service under test based on service request data. The service under test then executes its internal logic based on the service request data, and also needs to call numerous downstream services and wait for responses before performing further internal logic processing to obtain the return data for the service request data. The recording process, on the other hand, primarily aims to acquire and save the actual service response data returned by the downstream services corresponding to the service under test.

[0077] For example, during service stress testing, since the stress test service typically has downstream data, when initiating a request, it needs to wait for the downstream to process and return the data. Sometimes, the stress test service also needs to perform a large amount of logical processing on the downstream data, making it impossible to obtain the real metrics of the service's independent processing logic, such as time consumption, QPS, memory usage, and CPU usage. Therefore, the solution in this application obtains the real downstream service's response in advance through a recording function. During the stress test, the recorded playback can simulate the real downstream results and ensure the consistency of the stress test service's processing logic. Therefore, a recording process needs to be executed before the test. This process specifically requires sending the prepared service request data to the service under test in the online environment, and simultaneously recording the downstream service request data sent to the downstream service and the service response data returned by the downstream service during the service under test's processing of the service request, completing the data preparation process for the stress test. Regarding the traffic recording process, the solution in this application can record any traffic, does not require test traffic labeling, and does not necessarily need to be processed in the production environment. It is highly flexible and can effectively record the downstream service response of the service under test, thereby ensuring the test effect of the service stress test.

[0078] Step 205: Based on the service request data, send a service stress test request to the service to be tested in the offline environment to perform stress testing on the service to be tested, and return the service response data corresponding to the service stress test request to the service to be tested through the service recording data.

[0079] For example, after recording the service request processing process, stress testing can be performed based on the recorded data. At this point, the service under test can be placed in an offline environment for stress testing, while its corresponding upstream and downstream services are shielded. During the test, service request data is sent to the service under test, and the entire stress test process is a relatively long one (in actual business scenarios, it might take 10 hours). During this process, the test server 104 can directly replace the original downstream service and return the corresponding data from the downstream service directly to the service under test based on the recorded service data, ensuring the accuracy of the logical processing. The stress test recording and playback process in this application is specifically implemented in an offline environment. As long as the machine of the service under test meets the stress test requirements, it does not need to access any storage media outside its own module, does not depend on other services or storage, and a single stress test auxiliary service can solve downstream issues such as databases and caches, achieving complete shielding and independence, thereby ensuring the effectiveness of the stress test.

[0080] Step 207: Collect stress test monitoring data on the process of the service under test processing service stress test requests and service response data.

[0081] Step 209: Perform stress test analysis and processing based on the stress test monitoring data to obtain the stress test results of the service to be tested.

[0082] For example, during long-term stress testing, it is necessary to collect various system metrics in real time and analyze them after the test. This involves collecting various stress test monitoring data generated from the processes of the service under test handling stress test requests and service response data. For instance, application layer performance data, including QPS / TPS, average response time, and error rate, needs to be collected. Service resource monitoring data for server 102 also needs to be collected, such as CPU utilization, memory usage, and network bandwidth. After data collection, stress test analysis and processing are required based on the collected stress test monitoring data. For example, a time period can be specified, and various stress test monitoring data collected within that time period can be obtained. Then, data such as performance inflection points, resource bottlenecks, and latency sources can be analyzed to summarize and analyze the stress test process and obtain the required stress test results.

[0083] The aforementioned stress testing method involves: upon receiving a stress test request for the service under test, acquiring service request data of the service under test; sending a service processing request to the service under test in the online environment based on the service request data, and recording the downstream service request data sent to downstream services and the service response data returned by downstream services during the processing of the service processing request, thus obtaining service recording data; sending a service stress test request to the service under test in the offline environment based on the service request data to perform stress testing on the service under test, and returning the service response data corresponding to the service stress test request to the service under test based on the service recording data; collecting stress test monitoring data during the processing of service stress test requests and service response data by the service under test; and performing stress test analysis and processing based on the stress test monitoring data to obtain the stress test results of the service under test. The solution in this application, by pre-recording the downstream requests and responses in the online environment, allows the service stress test request to bypass the real downstream and return directly during the stress test through a replay function, thus shielding the downstream processing. This ensures the request logic of the stress test service in the process and simultaneously shields the downstream logic processing in the handling. This stress testing method can simulate and return real downstream results, ensuring the consistency of service processing logic during stress testing. It also ensures that the return of a single result does not affect the logical processing of the stress test service, thereby improving the accuracy of stress testing for individual services.

[0084] In an exemplary embodiment, step 203 includes: obtaining address data and port data of the service under test accessing downstream services, modifying the address data to record address data, and modifying the port data to record port data; sending a service processing request to the service under test in the online environment based on the service request data, and intercepting the downstream service request data sent to the downstream service during the process of the service under test processing the service processing request based on the recorded address data and recorded port data; performing protocol transformation processing on the downstream service request data to obtain protocol transformation request data; sending the protocol transformation request data to the downstream service, and recording the service response data returned by the downstream service; and obtaining service recording data based on the recorded downstream service request data and service response data.

[0085] Ports are logical identifiers used by the operating system to distinguish different network services. By modifying the way the service under test accesses downstream services, it is possible to intercept the downstream service request data sent from the service under test to the downstream service.

[0086] For example, the current stress testing process can be specifically referred to as follows: Figure 3As shown, the service under test receives a request from the upstream. After processing, it determines, based on its internal logic, to request a large number of downstream services. The obvious attributes of these downstream services include protocol type, access IP address, and access port number. The service under test sends different requests (request1) to different downstream services, accessing them according to their different protocols and addresses. The downstream services process their own internal logic and return results to the service under test (response1, 2...n). The service under test then incorporates the downstream return results into its internal logic for further processing, finally returning the result to the upstream (response), thus completing a full request. The solution in this application, however, records the downstream response process by intercepting the different requests sent by the service under test to different downstream services. The recording and playback process can be implemented using the load testing auxiliary service module. The specific processing procedure of this module can be found in [reference needed]. Figure 4 As shown, the main function of the recording process is to obtain the actual response from the downstream service and save the data. First, the address of the service under test accessing the downstream service is configured, changing it to the address of the load testing auxiliary service and a different port number. This establishes a one-to-one relationship between the downstream service and the load testing auxiliary service's port. When a real request (request1, 2...n) accesses the downstream service, it actually requests the load testing auxiliary service. The load testing auxiliary service, by configuring various attributes of the original downstream service, transforms the request through protocol conversion, converting it into protocol-transformed request data before sending it to the real downstream service. Simultaneously, it waits for and obtains the actual response from the downstream service. These operations are imperceptible to the downstream service because the upstream request remains unchanged. At this point, both the upstream request and the downstream response have passed through the load testing auxiliary service. Due to the corresponding protocol settings, it can be parsed according to the appropriate protocol. In this embodiment, by configuring the load testing auxiliary service to modify the address and port data of the service under test accessing the downstream service, request data is intercepted to complete the request-response recording process, effectively ensuring the efficiency and accuracy of the recording process.

[0087] In an exemplary embodiment, obtaining service recording data based on recorded downstream service request data and service response data includes: determining a unique key corresponding to the recorded downstream service request data and service response data; and saving the downstream service request data and service response data based on the unique key to obtain service recording data.

[0088] For example, a unique key refers to a field or attribute that uniquely identifies each data record. This unique key ensures that each data record is unique within the system, preventing duplication, and allows for quick and accurate retrieval, updating, or deletion of the corresponding data. In the solution of this application, downstream service request data and service response data can be stored using a unique key. The unique key represents the uniqueness of the request and response, thereby achieving the purpose of recording requests. (See reference...) Figure 4 As shown, for request 1, its unique key is id. For request 2, its unique key is header. And for request n, its unique key is newKey. In this embodiment, using unique keys to associate and store downstream service request data and service response data can effectively ensure the accuracy of data recording and the efficiency of test response processing based on the recorded data. Moreover, this recorded data can be stored continuously without undergoing specific downstream logic processing, enabling repeated load testing of the same batch of requests.

[0089] In an exemplary embodiment, step 205 includes: obtaining downstream service request data of the service under test in response to the service stress test request; determining the target unique key corresponding to the downstream service request data of the service stress test request; searching for the corresponding service response data in the service recording data using the target unique key; and returning the searched service response data to the service under test.

[0090] For example, after data recording and processing are complete, the specific testing process can also be implemented through a load testing auxiliary service. Throughout the service load testing process, enabling the replay mode of the load testing auxiliary service can achieve the goal of shielding downstream logic from the load testing. For example... Figure 5As shown, the downstream access address of the load testing service can first be configured to the address and port of the load testing auxiliary service. When a request is sent to the service under test, after internal logic processing, a request (request1, 2...n) is sent to the corresponding downstream service. At this time, the downstream address is the address of the load testing auxiliary service. The load testing auxiliary service will quickly select the corresponding downstream result (response1, 2...n) based on the sent request and the configured unique key, and then return the found return data to the load testing service. At this time, not only is the downstream logic shielded, but the correct result is also returned to the upstream service, ensuring the correctness of the load testing service's further logical processing. Since the load testing may last for a long time, these service load testing requests can be reused without being returned incorrectly due to downstream logic, thus ensuring the real metric data of the load testing service throughout the entire load testing time. In this embodiment, by obtaining the downstream service request data and then determining the response based on the searched target unique key, the service response processing of the load testing process is completed while shielding the downstream service, ensuring the consistency of the load testing service processing logic and ensuring that a single result return does not affect the logical processing of the load testing service.

[0091] In an exemplary embodiment, the method further includes: obtaining the iterative version service corresponding to the service to be tested; sending an iterative version service test request to the iterative version service based on the service request data to perform stress testing on the iterative version service, and returning the iterative version service response data corresponding to the iterative version service test request to the iterative version service through service recording data; collecting target monitoring data corresponding to the iterative version service; and generating stress test results of the iterative version service based on the target monitoring data.

[0092] For example, when the logic of the service under test iterates, it becomes an iterative version of the service. Current stress testing methods, while obtaining real online data, only target the online version of the service. A module often iterates rapidly. If a new version is to be stress tested offline, the current method cannot record it because it cannot deploy the new version to the production environment for traffic recording; that is, it cannot achieve on-demand recording and playback. The solution proposed in this application, however, is still applicable to testing this iterative version of the application, achieving on-demand recording and playback. After obtaining the iterative version service corresponding to the service under test, an iterative version service test request can be sent to the iterative version service based on service request data to perform stress testing on the iterative version service. The iterative version service response data corresponding to the test request is returned to the iterative version service using service recording data. In other words, the iterative version service is tested using pre-recorded service recording data, and target monitoring data corresponding to the iterative version service is collected according to testing needs. The stress test results of the iterative version service are then generated based on the collected target monitoring data. Furthermore, for the testing process of the iterative version service, the service response data can be compared with the iterative version service response data to obtain response difference data. Then, based on the response difference data, anomaly localization processing is performed on the iterative version service to obtain the anomaly localization results. For example... Figure 6 As shown, the responses of the iterative version service and the main version service under test can be compared to complete the testing of the iterative version service. By sending the recorded requests (request1, 2...n) to the two versions of the service respectively, since they are both connected to the load testing auxiliary service, the processing results for the downstream are exactly the same. Thus, the differences can only come from internal logic modifications of the service. By comparing the differences, the corresponding difference results can be obtained, thereby further locating the logic problem and obtaining the anomaly location results of the iterative version service.

[0093] In this embodiment, by determining the iterative version service corresponding to the service to be tested, and then obtaining the response of the iterative version service through stress testing, and combining it with comparative testing, the abnormal location and handling of the iterative version service can be completed, which can effectively locate the logical abnormality problem of the iterative version service.

[0094] In a specific embodiment, for the stress testing process of this application, a batch of stress test data (which may be hundreds of thousands of requests in a real scenario) can be prepared in advance. Then, the recording mode of the stress test auxiliary service is opened. The stress test auxiliary service will automatically allocate a batch of port numbers according to the actual situation. At this time, the downstream of the stress test service is configured with the corresponding port number and the corresponding protocol is configured (in a real scenario, there is downstream configuration, and only the port number needs to be modified). Requests are sent to the stress test service according to the normal request QPS. When the request is sent, the stress test auxiliary service has completed the recording process. At this time, the stress test auxiliary service can be a cluster. The recording mode is a kind of forwarding and will not increase the time overhead. Therefore, under normal conditions, the time spent sending a batch of data is no different from the time spent forwarding requests through the stress test auxiliary service. When the process reaches the stress testing step, the replay mode of the stress testing auxiliary service is activated. At this point, the actual downstream service is no longer part of the stress testing process; it is completely replaced by the stress testing auxiliary service. When the recorded request data is sent repeatedly, the service under test quickly retrieves the corresponding result from the storage medium and returns it to the upstream. This time consumption is negligible (approximately 10ms in real-world scenarios). The service under test can then smoothly execute subsequent logic, ensuring the correctness of the service stress testing process. The importance of the correctness of the stress testing service process lies in the fact that part of the stress testing service's logic relies on the downstream's returned data. Different downstream data leads to different processing logic in the stress testing service, directly affecting stress testing metrics such as latency, QPS, memory usage, and CPU usage. Therefore, correct returns are essential to obtain accurate metric data. The recorded request and return data in this stress testing solution can be reused. Even with long stress testing times, downstream data can still be masked while correct data is returned, effectively ensuring the test results.

[0095] Currently, the challenge of load testing individual modules is the bottleneck between different systems. When the bottleneck is in the load testing service, it can connect to the real downstream systems. However, when the bottleneck is in the downstream services, no matter how the load parameters are adjusted, it's impossible to obtain the true metric data from the load testing service. Load testing auxiliary services can shield downstream logic processing, preventing the downstream from becoming a bottleneck in the load testing process. Typical load testing auxiliary services return fixed data, but this doesn't guarantee the consistency of the load testing service's logic. When the load testing service handles different requests, it executes different processing logic based on the request parameters. If the downstream data returns the same result, load testing metrics from different logics cannot be obtained, making the load testing results unreliable. Load testing auxiliary services, while returning data, can guarantee data correctness, ensuring the consistency of the load testing service's processing logic and further guaranteeing the reliability of the load testing results.

[0096] The stress testing method presented in this application provides a stress testing auxiliary service whose main internal logic includes port number allocation, configuration parsing, configuration generation, protocol parsing, protocol result generation, data storage, and rapid processing. The protocol parsing and result generation ensure that regardless of the service's protocol, as long as the protocol definition exists, parsing and result storage can be performed, and results can be generated according to the protocol. Because it is deployed in a cluster, it ensures rapid and iterative processing even with large amounts of data, thereby guaranteeing the effectiveness of the stress test.

[0097] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0098] Based on the same inventive concept, this application also provides a pressure testing device for implementing the pressure testing method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more pressure testing device embodiments provided below can be found in the limitations of the pressure testing method described above, and will not be repeated here.

[0099] In one exemplary embodiment, such as Figure 7 As shown, a pressure testing device is provided, comprising:

[0100] The data acquisition module 702 is used to acquire service request data of the service to be tested when a stress test request for the service to be tested is received.

[0101] The load testing recording module 704 is used to send service processing requests to the service under test in the online environment based on service request data, and record the downstream service request data sent to the downstream service and the service response data returned by the downstream service during the service processing process of the service under test, so as to obtain service recording data.

[0102] The load test replay module 706 is used to send service stress test requests to the service under test in the offline environment based on service request data, so as to perform stress tests on the service under test, and return the service response data corresponding to the service stress test request to the service under test through service recording data.

[0103] The test data acquisition module 708 is used to collect stress test monitoring data during the process of the service under test processing service stress test requests and downstream service request data.

[0104] The test result generation module 710 is used to perform stress test analysis and processing based on stress test monitoring data to obtain the stress test results of the service to be tested.

[0105] In one embodiment, the load testing recording module 704 is specifically used to: obtain the address data and port data of the service under test accessing the downstream service, modify the address data to record address data, and modify the port data to record port data; send a service processing request to the service under test in the online environment based on the service request data, and based on the recorded address data and recorded port data, intercept the downstream service request data sent to the downstream service during the process of the service under test processing the service processing request; perform protocol transformation processing on the downstream service request data to obtain protocol transformation request data; send the protocol transformation request data to the downstream service and record the service response data returned by the downstream service; and obtain service recording data based on the recorded downstream service request data and service response data.

[0106] In one embodiment, the load test recording module 704 is specifically used to: determine the unique key corresponding to the recorded downstream service request data and service response data; and save the downstream service request data and service response data based on the unique key to obtain service recording data.

[0107] In one embodiment, the load test replay module 706 is specifically used to: obtain downstream service request data of the service under test in response to the service load test request; determine the target unique key corresponding to the downstream service request data of the service load test request; search for the corresponding service response data in the service recording data through the target unique key; and return the searched service response data to the service under test.

[0108] In one embodiment, the system further includes an iterative service testing module, configured to: obtain the iterative version service corresponding to the service to be tested; send an iterative version service test request to the iterative version service based on the service request data to perform stress testing on the iterative version service, and return the iterative version service response data corresponding to the iterative version service test request to the iterative version service through service recording data; collect target monitoring data corresponding to the iterative version service; and generate stress test results for the iterative version service based on the target monitoring data.

[0109] In one embodiment, the iterative service testing module is specifically used to: compare the service response data and the iterative version service response data to obtain response difference data; and perform anomaly localization processing on the iterative version service based on the response difference data to obtain the anomaly localization result of the iterative version service.

[0110] Each module in the aforementioned pressure testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0111] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to stress testing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a stress testing method.

[0112] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0113] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0114] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0115] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in the above-described method embodiments.

[0116] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0117] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0119] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of pressure testing, characterized by, The method comprises: In the case of receiving a stress test request for a service to be tested, obtaining service request data of the service to be tested; Based on the service request data, send a service processing request to the service to be tested in the online environment, and record the downstream service request data sent to the downstream service and the service response data returned by the downstream service in the process of the service to be tested processing the service processing request, to obtain service recording data; Based on the service request data, send a service stress test request to the service to be tested in the offline environment to test the service to be tested, and return the service response data corresponding to the service stress test request to the service to be tested through the service recording data; Collect stress test monitoring data of the process of the service to be tested processing the service stress test request and the service response data; According to the stress test monitoring data, perform stress test analysis processing to obtain the stress test result of the service to be tested; Obtain the iterative version service corresponding to the service to be tested; Based on the service request data, send an iterative version service test request to the iterative version service to test the iterative version service, and return the iterative version service response data corresponding to the iterative version service test request to the iterative version service through the service recording data; Collect target monitoring data corresponding to the iterative version service; Based on the target monitoring data, generate the stress test result of the iterative version service.

2. The method of claim 1, wherein, The method comprises: Obtain address data and port data of the service to be tested accessing downstream services, and modify the address data to recording address data and the port data to recording port data; Based on the service request data, send a service processing request to the service to be tested in the online environment, and based on the recording address data and recording port data, intercept downstream service request data sent to the downstream service in the process of the service to be tested processing the service processing request; Perform protocol conversion processing on the downstream service request data to obtain protocol conversion request data; Send the protocol conversion request data to the downstream service, and record the service response data returned by the downstream service; According to the recorded downstream service request data and service response data, obtain service recording data.

3. The method of claim 2, wherein, The method comprises: Determine the unique key corresponding to the recorded downstream service request data and service response data; Based on the unique key, save the downstream service request data and service response data to obtain service recording data.

4. The method of claim 3, wherein, The method comprises: acquire downstream service request data of the service pressure test request of the to-be-tested service; determine a target unique key corresponding to the downstream service request data of the service pressure test request; find corresponding service response data in the service recording data through the target unique key; return the found service response data to the to-be-tested service.

5. The method of claim 1, wherein, The target monitoring data includes response difference data, and the pressure test result includes an abnormality positioning result; The acquiring of the target monitoring data corresponding to the iterative version service includes: comparing the service response data and the iterative version service response data to obtain response difference data; The generating of the pressure test result of the iterative version service based on the target monitoring data includes: performing abnormality positioning processing on the iterative version service based on the response difference data to obtain an abnormality positioning result of the iterative version service.

6. A pressure testing device, characterized by The device includes: a data acquisition module configured to acquire service request data of a to-be-tested service when a pressure test request for the to-be-tested service is received; a pressure test recording module configured to send a service processing request to the to-be-tested service in an online environment based on the service request data, and record downstream service request data sent by the to-be-tested service to a downstream service and service response data returned by the downstream service during processing of the service processing request by the to-be-tested service, to obtain service recording data; a pressure test playback module configured to send a service pressure test request to the to-be-tested service in an offline environment based on the service request data, to perform pressure test on the to-be-tested service, and return service response data corresponding to the service pressure test request to the to-be-tested service through the service recording data; a test data acquisition module configured to acquire pressure test monitoring data of a process in which the to-be-tested service processes the service pressure test request and the downstream service request data; a test result generation module configured to perform pressure test analysis processing according to the pressure test monitoring data to obtain a pressure test result of the to-be-tested service; an iterative service test module configured to acquire an iterative version service corresponding to the to-be-tested service, send an iterative version service test request to the iterative version service based on the service request data, to perform pressure test on the iterative version service, return iterative version service response data corresponding to the iterative version service test request to the iterative version service through the service recording data, acquire target monitoring data corresponding to the iterative version service, and generate a pressure test result of the iterative version service based on the target monitoring data.

7. The apparatus of claim 6, wherein, The pressure test recording module is specifically configured to acquire address data and port data of the to-be-tested service accessing a downstream service, modify the address data into recording address data, and modify the port data into recording port data; send a service processing request to the to-be-tested service in an online environment based on the service request data, and intercept downstream service request data sent by the to-be-tested service to a downstream service during processing of the service processing request by the to-be-tested service based on the recording address data and the recording port data; performing protocol conversion processing on the downstream service request data to obtain protocol conversion request data; sending the protocol conversion request data to a downstream service and recording service response data returned by the downstream service; obtaining service recording data according to the recorded downstream service request data and the service response data.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor implements the steps of the method of any one of claims 1 to 5 when executing the computer program.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 5.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 5.

Images