A pressure test method, device, computer equipment and readable storage medium

Abstract

Embodiments of the present application provide a pressure test method, device, computer equipment and readable storage medium. The method is executed by a pressure test platform device, the pressure test platform device comprises a pressure test management node, a pressure test scheduling node and a pressure test device cluster. The method comprises the following steps: the pressure test management node acquires task parameters of a pressure test task, and sends the task parameters to the pressure test scheduling node; the pressure test scheduling node acquires S pressure test devices for executing the pressure test task from the pressure test device cluster according to the task parameters, acquires pressure test parameters corresponding to the S pressure test devices respectively from the task parameters, and sends the S pressure test parameters to the corresponding pressure test devices respectively; S is a positive integer; the S pressure test devices acquire pressure test case resources of the pressure test task from a case database respectively according to the corresponding pressure test parameters, and execute the acquired pressure test case resources. By using the present application, the stability of the pressure test platform device can be improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a stress testing method, apparatus, computer equipment, and readable storage medium. Background Technology

[0002] Existing load testing systems can store load testing case resources through the test case management node of the load testing platform device. After acquiring the load testing device for executing the load testing task, the test case resources are sent to the load testing device through the test case management node. However, the test case management node needs to store a large number of load testing case resources on its local disk, which can lead to disk overflow on a single machine over time, thereby reducing the stability of the load testing platform device. Summary of the Invention

[0003] This application provides a stress testing method, apparatus, computer equipment, and readable storage medium, which can improve the stability of stress testing platform equipment.

[0004] This application provides a stress testing method, which is executed by a stress testing platform device. The stress testing platform device includes a stress testing management node, a stress testing scheduling node, and a stress testing device cluster. The stress testing method includes:

[0005] The load testing management node obtains the task parameters of the load testing task and sends the task parameters to the load testing scheduling node;

[0006] The load testing scheduling node obtains S load testing devices from the load testing device cluster to execute the load testing task based on the task parameters, obtains the load testing parameters corresponding to the S load testing devices from the task parameters, and sends the S load testing parameters to the corresponding load testing devices respectively; S is a positive integer;

[0007] Each of the S load testing devices retrieves load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and executes the retrieved load testing case resources.

[0008] One embodiment of this application provides a pressure testing device, which is applied to a pressure testing platform device. The pressure testing platform device includes a pressure testing equipment cluster, and the pressure testing device includes:

[0009] The load testing management module is used to obtain the task parameters of the load testing task and send the task parameters to the load testing scheduling module.

[0010] The load testing scheduling module is used to obtain S load testing devices from the load testing device cluster to execute the load testing task according to the task parameters, obtain the load testing parameters corresponding to the S load testing devices respectively from the task parameters, and send the S load testing parameters to the corresponding load testing devices respectively; S is a positive integer;

[0011] The control module is used to control S load testing devices to obtain load testing case resources for load testing tasks from the case database according to the corresponding load testing parameters, and to execute the obtained load testing case resources.

[0012] The load testing management module is specifically used to respond to the creation operation of the task creation function and display the task creation parameters of the created load testing task; the load testing task includes N load testing test case resources; N is a positive integer;

[0013] The load testing management module is specifically used to respond to confirmation operations for load testing tasks, store N load testing case resources in the case database, and obtain the storage addresses of the N load testing case resources in the case database.

[0014] The load testing management module is specifically used to replace the N load testing case resources in the task creation parameters according to N storage addresses, obtain the task parameters of the load testing task, and send the task parameters to the load testing scheduling module.

[0015] Among them, the load testing scheduling module is specifically used to obtain the machine configuration parameters of the load testing task from the task parameters, and obtain S load testing devices from the load testing device cluster to execute the load testing task according to the machine configuration parameters;

[0016] The load testing scheduling module is specifically used to allocate addresses to the N storage addresses in the task parameters, resulting in storage addresses corresponding to S load testing devices; the S load testing devices are used to execute the load testing case resources corresponding to the allocated storage addresses.

[0017] The load testing scheduling module is specifically used to obtain the execution parameters that meet the execution conditions from the task parameters, and to determine the execution parameters and the storage addresses corresponding to the S load testing devices as the load testing parameters corresponding to the S load testing devices respectively.

[0018] The machine configuration parameters include machine type configuration parameters, region configuration parameters, and quantity configuration parameters;

[0019] The load testing scheduling module is specifically used to obtain load testing devices with idle status from the load testing device cluster, and to obtain load testing devices that meet the model configuration parameters and regional configuration parameters from the idle load testing devices.

[0020] The load testing scheduling module is specifically used to match the number of load testing devices that meet the model configuration parameters and regional configuration parameters with the quantity configuration parameters. If the number of load testing devices that meet the model configuration parameters and regional configuration parameters is greater than or equal to the quantity configuration parameters, then S load testing devices are selected from the load testing devices that meet the model configuration parameters and regional configuration parameters to perform the load testing task.

[0021] The load testing scheduling module is also specifically used to send an insufficient number of devices message to the load testing management module if the number of load testing devices that meet the model configuration parameters and regional configuration parameters is less than the quantity configuration parameters.

[0022] Wherein, S load testing devices include target load testing devices; S load testing parameters include target load testing parameters corresponding to the target load testing devices; the number of load testing test case resources for the load testing task is N; N is a positive integer;

[0023] The control module is specifically used to control the target load testing device to retrieve the target load testing case resource corresponding to the target load testing device from the case database according to the storage address in the target load testing parameters, and to determine that the target load testing device has successfully deployed the target load testing case resource; the target load testing case resource belongs to N load testing case resources;

[0024] The control module is specifically used to control the target load testing equipment to execute target load testing test case resources.

[0025] The control module is specifically used to assemble the execution parameters in the target stress test parameters to obtain command line parameters.

[0026] The control module is specifically used to parse command-line parameters to obtain the load distribution method of the load testing task;

[0027] The control module is specifically used to initiate load testing traffic for the stressed objects in the target load testing test case resources based on the load sending method, and to send load testing execution status messages to the load testing scheduling module.

[0028] The control module is also specifically used to stop the load testing traffic to the target object and send a load testing failure message to the load testing scheduling module when there is a syntax error in the target load testing test resource.

[0029] Among them, the load testing scheduling module is also specifically used to obtain the deployment results corresponding to the S load testing devices respectively. When the deployment results corresponding to the S load testing devices indicate that the load testing test case resources of the load testing task have been successfully deployed on the S load testing devices, the load testing start command is sent to the S load testing devices respectively.

[0030] The control module is also specifically used to execute the steps of the target load testing device executing the target load testing test case resources after the target load testing device receives the start load testing command.

[0031] The control module is also used to control the S load testing devices to acquire the performance data of the load testing test case resources they are executing, integrate the acquired performance data within the target time period to obtain integrated performance data, and send the obtained integrated performance data to the data aggregation module.

[0032] The data aggregation module is used to aggregate the integrated performance data sent by S load testing devices to obtain aggregated performance data.

[0033] The data aggregation module is also used to store aggregated performance data in the task database and to store the task identifiers of the load testing tasks in the identifier database.

[0034] The data aggregation module is also used to send the aggregation performance data to the circuit breaker detection module.

[0035] The circuit breaker detection module is used to compare the polymerization performance data with the data threshold to obtain the data comparison result;

[0036] The circuit breaker detection module is also used to send a task circuit breaker message to the load test scheduling module if the data comparison result indicates that the aggregate performance data meets the circuit breaker condition, so that the load test scheduling module stops the load test task.

[0037] The data aggregation module is also used to send aggregated performance data to the load test management module.

[0038] The load testing management module is also used to respond to viewing operations for the load testing report function and display aggregated performance data.

[0039] The load testing management module is also used to respond to the trigger operation of the task stop function, and send a task stop command to the load testing scheduling module. The load testing scheduling module forwards the task stop command to S load testing devices; the S load testing devices include the target load testing device; the S load testing parameters include the target load testing parameters corresponding to the target load testing device.

[0040] The control module is also used to control the target load testing device to return a task exit message to the load testing scheduling module if the device status of the target load testing device is idle.

[0041] The control module is also used to control the target load testing device to stop executing the target load testing test case resources if the device status of the target load testing device is in the working state, return a task stop message to the load testing scheduling module, and update the device status of the target load testing device to the idle state.

[0042] One embodiment of this application provides a computer device, including: a processor and a memory;

[0043] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0044] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0045] One embodiment of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method provided in this application embodiment.

[0046] This application provides a financial-grade distributed load testing system that supports tens of millions of QPS (Queries Per Second). This load testing system can obtain the load testing parameters corresponding to the load testing devices used to execute the load testing tasks from the task parameters of the load testing tasks through the load testing scheduling node, and distribute the load testing parameters to the load testing devices used to execute the load testing tasks. This allows the load testing devices to actively obtain load testing case resources for the load testing tasks from the test case database based on the load testing parameters, without having to passively receive load testing case resources issued by the test case management node. This eliminates the need to store a large number of load testing case resources through the test case management node, thereby avoiding single-machine disk overflow and improving the stability of the load testing platform devices. Attached Figure Description

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

[0048] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0049] Figure 2 This is a schematic diagram of a data interaction scenario provided in an embodiment of this application;

[0050] Figure 3 This is a schematic flowchart of a stress testing method provided in an embodiment of this application;

[0051] Figure 4a This is a schematic diagram of a scenario for creating a single use case task provided in an embodiment of this application;

[0052] Figure 4b This is a schematic diagram of a scenario for creating a single use case task provided in an embodiment of this application;

[0053] Figure 5 This is a schematic diagram illustrating a scenario for creating a multi-use case task, provided in an embodiment of this application.

[0054] Figure 6 This is a schematic diagram illustrating a scenario for executing load testing test case resources provided in an embodiment of this application;

[0055] Figure 7 This is a flowchart illustrating a method for stopping a load testing task, as provided in an embodiment of this application.

[0056] Figure 8a This is a schematic diagram illustrating a scenario for viewing a single-use test report, as provided in an embodiment of this application.

[0057] Figure 8b This is a schematic diagram illustrating a scenario for viewing a single-use test report, as provided in an embodiment of this application.

[0058] Figure 9 This is a schematic diagram illustrating a scenario for viewing multi-use test reports provided in an embodiment of this application;

[0059] Figure 10 This is a schematic diagram of a stress test process provided in an embodiment of this application;

[0060] Figure 11 This is a schematic diagram of a data interaction process provided in an embodiment of this application;

[0061] Figure 12 This is a structural schematic diagram of a pressure testing platform device provided in an embodiment of this application;

[0062] Figure 13 This is a schematic diagram of the structure of a pressure testing device provided in an embodiment of this application;

[0063] Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0065] For details, please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 1The network architecture shown may include server clusters and terminal device clusters. A terminal device cluster may include one or more terminal devices; the number of terminal devices in a terminal device cluster is not limited here. A server cluster may include one or more servers; the number of servers in a server cluster is not limited here.

[0066] like Figure 1 As shown, multiple terminal devices may include terminal device 3000a, terminal device 3000b, terminal device 3000c, ..., terminal device 3000n, and multiple servers may include server 2000a, server 2000b, ..., server 2000m. The terminal devices in the terminal device cluster and the servers in the server cluster can be directly or indirectly connected to the network through wired or wireless communication, so that each terminal device and each server can interact with each other through the network connection. For example, terminal device 3000c and server 2000a can be directly or indirectly connected to the network through wired or wireless communication, so that terminal device 3000c and server 2000a can interact with each other through the network connection.

[0067] The terminal devices in the terminal device cluster can include: smartphones, tablets, laptops, desktop computers, intelligent voice interaction devices, smart home appliances (e.g., smart TVs), wearable devices, vehicle terminals, aircraft, and other intelligent terminals with stress testing functions. The vehicle terminals can be terminal devices for intelligent transportation scenarios and assisted driving scenarios. For ease of understanding, embodiments of this application can... Figure 1 From the multiple terminal devices shown, one terminal device is selected as the target terminal device. For example, in the embodiments of this application, it can be... Figure 1 The terminal device 3000c shown is used as the target terminal device.

[0068] The servers in the server cluster can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0069] It is understood that the stress testing method provided in this application embodiment can be executed by a stress testing platform device. The stress testing platform device can perform stress testing on the stressed object (stress testing is a performance testing method used to evaluate the behavior and performance of the stressed object under extreme or beyond normal operating conditions (or extremely heavy load conditions)). The stress testing platform device can constitute a stress testing system (or stress testing platform). The stressed object refers to the system, component or service that needs to withstand stress during the stress testing process. For example, the stressed object can be a software application (e.g., game software), network infrastructure (e.g., switch), or database system (e.g., relational database management system).

[0070] It is understood that the load testing platform equipment may include servers in a server cluster, or it may include both servers in a server cluster and terminal devices (e.g., target terminal devices) in a terminal device cluster. The load testing platform equipment may include load testing management nodes, load testing scheduling nodes, data aggregation nodes, circuit breaker detection nodes, and load testing equipment clusters. The load testing management nodes, load testing scheduling nodes, data aggregation nodes, circuit breaker detection nodes, and load testing equipment clusters may be deployed on servers in a server cluster or on terminal devices in a terminal device cluster. When the load testing platform device includes both servers in a server cluster and terminal devices in a terminal device cluster, the target terminal device can be used to create load testing tasks. The load testing management node can be deployed on a server, and the server deployed by the load testing management node can be the backend server corresponding to the target terminal device. The target terminal device can send the created load testing task to the load testing management node. Alternatively, when the load testing platform device includes both servers in a server cluster and terminal devices in a terminal device cluster, the load testing management node can be deployed on the target terminal device, and the target terminal device deployed by the load testing management node can be used to create load testing tasks. When the load testing platform device includes servers in a server cluster, the load testing management node can be deployed on the server, and the server deployed by the load testing management node can be used to create load testing tasks. For ease of understanding, this application uses an example where the load testing platform device includes servers in a server cluster but does not include terminal devices in a terminal device cluster.

[0071] The load testing management node (i.e., load testing management device, also known as load testing management web terminal) supports users in writing test cases, orchestrating traffic (e.g., number of machines, incrementing steps, increment per step, continuous per step, continuous load testing), starting and stopping load testing tasks in real time, setting load testing SLA (Service Level Agreement) metrics (e.g., total number of requests, total number of failures, total number of errors) and displaying load testing reports. The load testing scheduling node (i.e., load testing scheduling device, also known as scheduling center scheduler) is responsible for load testing resource scheduling (i.e., load testing machine scheduling), task distribution and load testing machine allocation. The data aggregation node (i.e., data aggregation device) is responsible for data aggregation. The circuit breaker detection node (i.e., circuit breaker detection device) is responsible for circuit breaker detection. The load testing devices (also known as load testing machines, load testing machines, or load application machines) in the load testing device cluster are responsible for executing the load testing test case resources in the load testing tasks.

[0072] The load testing equipment cluster can include at least one load testing device. A load testing device can be at least one server in a server cluster (e.g., a load testing device can be two servers in a server cluster, such as server 2000a and server 2000b). A load testing device refers to a machine used to initiate load testing traffic (i.e., the traffic used for stress testing). Each load testing machine may have a load testing task agent (i.e., a worker; the load testing task agent can be a client program on the load testing machine, referred to as a task agent). The load testing task agent is responsible for receiving task instructions from the scheduling center and executing corresponding operations (e.g., starting or stopping the load testing task). It should be understood that this application does not limit the operating system of the load testing device; for example, the operating system of the load testing device can be Windows, macOS, or Linux.

[0073] It is understandable that the load testing management node, load testing scheduling node, data aggregation node, circuit breaker detection node, and load testing equipment cluster can be deployed on at least one server in the server cluster. The load testing management node, load testing scheduling node, data aggregation node, circuit breaker detection node, and load testing equipment in the load testing equipment cluster can be deployed on the same server or on different servers. In other words, the load testing platform equipment can include at least one server in the server cluster, thereby improving the maintainability of the load testing platform through distributed deployment.

[0074] The load testing platform includes load testing management nodes, load testing scheduling nodes, data aggregation nodes, circuit breaker detection nodes, and load testing equipment clusters, which provide different services. Load testing management nodes provide load testing management services, load testing scheduling nodes provide load testing scheduling services, data aggregation nodes provide data aggregation services (stats), circuit breaker detection nodes provide circuit breaker detection services, and load testing equipment clusters provide load testing services. For example, the load testing management node could be server 2000a, the load testing scheduling node could be server 2000b, and the data aggregation and circuit breaker detection nodes could be server 2000m. The load testing equipment cluster could include servers other than server 2000a, server 2000b, and server 2000m (e.g., server 2000c, not shown in the diagram). Alternatively, the load testing management node, load testing scheduling node, data aggregation node, and circuit breaker detection node could all be server 2000a, and the load testing equipment cluster could include server 2000b, ..., server 2000m.

[0075] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating a data interaction scenario provided in an embodiment of this application. For example... Figure 2 As shown, the load testing platform equipment may include a load testing management node 20a, a load testing scheduling node 20b, and a load testing device cluster. The load testing device cluster may include load testing devices 21a, 21b, ..., 21c. For ease of understanding, this example illustrates the deployment of load testing management node 20a, load testing scheduling node 20b, load testing devices 21a, 21b, ..., 21c on different servers.

[0076] like Figure 2 As shown, the load testing management node 20a can obtain the task parameters of the load testing task and send them to the load testing scheduling node 20b. The load testing scheduling node 20b can then obtain the load testing devices in the load testing device cluster and, based on the task parameters, select S load testing devices from the cluster to execute the load testing task. Here, S can be a positive integer. For ease of understanding, we will use an example where S equals 2; for instance, the two load testing devices could be load testing device 21a and load testing device 21b.

[0077] Furthermore, the load testing scheduling node 20b can obtain the load testing parameters corresponding to the S load testing devices (i.e., load testing device 21a and load testing device 21b) from the task parameters (e.g., load testing parameter 22a corresponding to load testing device 21a and load testing parameter 22b corresponding to load testing device 21b), and send the S load testing parameters (i.e., load testing parameter 22a and load testing parameter 22b) to the corresponding load testing devices respectively. Specifically, the load testing scheduling node 20b can send load testing parameter 22a to load testing device 21a and load testing parameter 22b to load testing device 21b.

[0078] like Figure 2 As shown, load testing device 21a can obtain load testing case resources for the load testing task from the test case database (which can be an object storage database, cos) according to load testing parameters 22a, and execute the obtained load testing case resources. Similarly, load testing device 21b can obtain load testing case resources for the load testing task from the test case database according to load testing parameters 22b, and execute the obtained load testing case resources.

[0079] Among them, load testing devices 21a and 21b can be used to execute the same load testing case resources (i.e., obtain the same load testing case resources) or to execute different load testing case resources (i.e., obtain different load testing case resources). That is, the load testing case resources executed by load testing devices 21a and 21b can be the same or different. Here, we take the example of load testing devices 21a and 21b executing different load testing case resources. Load testing device 21a is used to execute load testing case resource 23a, and load testing device 21b is used to execute load testing case resource 23b.

[0080] Therefore, the embodiments of this application can obtain the load testing parameters corresponding to the load testing device used to execute the load testing task from the task parameters of the load testing task through the load testing scheduling node, and distribute the load testing parameters to the load testing device used to execute the load testing task. This allows the load testing device to actively obtain the load testing test case resources of the load testing task from the test case database according to the load testing parameters, without having to passively receive the load testing test case resources issued by the test case management node. This eliminates the need to store a large number of load testing test case resources through the test case management node, thereby avoiding single-machine disk overflow and improving the stability of the load testing platform device.

[0081] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a stress testing method provided in an embodiment of this application. The stress testing method can be executed by a stress testing platform device, which includes a stress testing management node, a stress testing scheduling node, a data aggregation node, a circuit breaker detection node, and a stress testing device cluster. The stress testing method may include steps S101-S103:

[0082] Step S101: The load test management node obtains the task parameters of the load test task and sends the task parameters to the load test scheduling node.

[0083] Specifically, the load testing management node can respond to the creation operation of the task creation function and display the task creation parameters of the created load testing task (i.e., the load testing management node can obtain the task creation parameters of the created load testing task). The load testing task includes N load testing case resources (i.e., the task creation parameters include N load testing case resources), where N can be a positive integer. This application can support single-case deployment (i.e., single-case load testing) or multi-case deployment (i.e., multi-case load testing). Single-case load testing refers to a load testing task including one load testing case resource, and multi-case load testing refers to a load testing task including at least two load testing case resources. Further, the load testing management node can respond to the confirmation operation for the load testing task (i.e., the confirmation operation for the task creation parameters), storing the N load testing case resources in the case database, obtaining the storage addresses of the N load testing case resources in the case database. The confirmation operation for the load testing task can be for the user to confirm the load control (e.g., the following...). Figure 4b The corresponding embodiment triggers the pressure control 40a). Further, the load testing management node can replace the N load testing case resources in the task creation parameters with N storage addresses to obtain the task parameters of the load testing task, and then send the task parameters to the load testing scheduling node.

[0084] The test case database may include at least one storage bucket. The load testing management node can store N load testing test case resources into different storage buckets within the test case database. These N test case resources can be stored in the same bucket or in different buckets. This application does not limit the specific method of storing the N load testing test case resources. For example, the load testing management node can randomly store the N load testing test case resources into the storage buckets of the test case database, or it can store the N load testing test case resources evenly across the storage buckets of the test case database. Optionally, when the required load testing test case resources exist in the test case database, the load testing management node does not need to repeatedly store the load testing test case resources already existing in the test case database (here, the load testing test case resources already existing in the test case database are the required load testing test case resources). Instead, it can directly obtain the storage address of the load testing test case resources already existing in the test case database, thereby avoiding the repeated storage of the same load testing test case resources in the test case database.

[0085] The task creation parameters include N load testing test case resources, excluding N storage addresses. The task parameters include N storage addresses, excluding N load testing test case resources. Load testing test case resources refer to test case configurations. The task creation parameters and task parameters also include load configuration (including the load testing task's load generation method (i.e., concurrent mode, load testing mode, load generation mode, load testing method) and load generation parameters for the load generation method, including the number of machines (i.e., the number of load testing devices), increment steps (i.e., the number of users incremented per step), increment per step (i.e., the number of machines incremented per step), duration per step (i.e., the duration of each step), continuous load testing (i.e., the duration of continuous load testing), etc.), machine configuration (including region, RPS, execution count, etc.), end-to-end detection, and task information (task information includes task name, warm-up time, continuous load testing after warm-up, log level, etc.).

[0086] Understandably, the load testing management node can display task creation controls in the task creation interface, respond to trigger operations on the task creation controls, and display the task configuration interface of the created load testing task. Furthermore, the load testing management node can respond to input operations on the task configuration interface and display the entered task creation parameters. Therefore, this application can create low-code test cases (i.e., support low-code test case writing) through the load testing management node, and the test cases support debugging in a local IDE (Integrated Development Environment), thereby enabling online debugging of test cases, reducing test case writing costs, improving the efficiency of load testing test case resource creation, and quickly adjusting and optimizing load testing test cases to improve the accuracy and reliability of load testing.

[0087] Optionally, the load testing management node can display a task creation control in the task creation interface, and respond to trigger operations on the task creation control to display the task configuration interface of the created load testing task. The task configuration interface includes a parameter upload control. Further, the load testing management node can respond to trigger operations on the parameter upload control to display a file selection interface for selecting parameter files. Further, the load testing management node can respond to file selection operations on the file selection interface, and determine the parameter file selected based on the file selection operation as the target parameter file. The target parameter file can be in the format of txt (Text), doc (Document), docx (Office Open XmlDocument), or pdf (Portable Document Format); these file formats will not be listed here. Furthermore, this application does not limit the load testing framework and test case writing language (i.e., test case scripting language). For example, the load testing framework can be ego, and the test case writing language can be Go. Furthermore, the load testing management node can respond to the confirmation operation of the file selection interface, determine the text data in the target parameter file as the task creation parameters of the load testing task, and display the task creation parameters in the task configuration interface.

[0088] The load testing case resources include load testing cases (i.e., stress test cases) and test case data (i.e., load test data) for the load testing task. Load testing cases and test case data work together to achieve load testing. Load testing case resources can be obtained by inputting them into the task configuration interface or by uploading them through the same interface. A load testing case is the test script for the load test (i.e., the load test script), while test case data is additional data required during the load testing process (e.g., username and password). For example, a load test can simulate a large number of users simultaneously logging into the system to test the system's processing capacity and response time. The load test needs to simulate users sending login requests to the system, and these login requests need to carry the username and password (correct or incorrect) from the test case data.

[0089] Optionally, the target terminal device can respond to the creation operation for the task creation function and display the task creation parameters of the created load testing task. The specific process of the target terminal device obtaining the task creation parameters can be found in the description of the load testing management node obtaining task creation parameters, and will not be repeated here. Further, the target terminal device can respond to the confirmation operation for the load testing task and send the task creation parameters to the load testing management node. The load testing task includes N load testing case resources. Further, the load testing management node can store the N load testing case resources in the test case database, obtaining the storage addresses of the N load testing case resources in the test case database. Further, the load testing management node can replace the N load testing case resources in the task creation parameters according to the N storage addresses to obtain the task parameters of the load testing task, and send the task parameters to the load testing scheduling node.

[0090] For easier understanding, please refer to Figure 4a and Figure 4b , Figure 4a This is a schematic diagram illustrating a scenario for creating a single use case task, as provided in an embodiment of this application. Figure 4a The image shows the interface for configuring test cases in a single-use case task. Figure 4b The image shows the interface for configuring stress on a single use case task.

[0091] like Figure 4a As shown, the test case configuration includes load test cases and test case data (i.e., load test data). Load test cases include global variables and interface links. Global variables are used to define variables used in the interface links, including variable names (e.g., user) and variable values ​​(e.g., name). Interface links are used to define the interfaces used for load testing (i.e., load test interfaces), including descriptions (e.g., post), requests (e.g., GET, POST, PUT, DELETE), target URLs, request parameters, request headers, request bodies, checkpoints, and variable extraction. Target URLs include URL type, target URL (e.g., https: / / AAA / zh-cn / ), and request timeout (e.g., 4 seconds).

[0092] like Figure 4bAs shown, the stress configuration includes the stress testing task's stress distribution method, the stress distribution parameters for the stress distribution method, and a concurrency model line graph. The stress testing task's stress distribution method includes RPS (Requests Per Second) mode and VU (Virtual User) mode. The horizontal axis of the concurrency model line graph represents time, and the vertical axis represents the number of users. The VU mode focuses on simulating user operations and business processes, while the RPS mode focuses on the number of requests that can be processed per unit of time. Among them, the stress distribution parameters of the VU mode include the number of machines (e.g., 11 machines), the number of increments (e.g., 10 steps), the increment per step (e.g., 1), the duration of each step (e.g., 1 second), continuous stress testing (e.g., 60 seconds), request rate limiting (e.g., 0 requests), a specified number of times (e.g., 0 requests), and traffic distribution. The traffic distribution includes the region (e.g., Guangzhou) and the traffic percentage (e.g., Guangzhou 100%).

[0093] For easier understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario for creating a multi-use case task, as provided in an embodiment of this application. Figure 5 The image shows the task information interface for multi-test case tasks. Here, we will use three load test case resources as an example for explanation.

[0094] like Figure 5 As shown, the task information includes the task name (e.g., scenario load testing), warm-up time (e.g., 10 seconds), continuous load testing after warm-up (e.g., 300 seconds), log level (e.g., DEBUG, INFO, ERROR), concurrency ratio (e.g., 100%), micro-load testing (e.g., not selected), target RPS (e.g., 24 transactions / second), estimated number of machines (e.g., 3 machines), and remarks (e.g., for demonstration purposes). The log level records different levels of information: DEBUG provides detailed information about the program's execution, INFO provides general information about the program's execution, and ERROR provides information about errors and exceptions that occur during program execution.

[0095] Step S102: The load testing scheduling node obtains S load testing devices from the load testing device cluster to execute the load testing task according to the task parameters, obtains the load testing parameters corresponding to the S load testing devices respectively from the task parameters, and sends the S load testing parameters to the corresponding load testing devices respectively.

[0096] Specifically, the load testing scheduler can obtain the machine configuration parameters for the load testing task from the task parameters, and then obtain S load testing devices from the load testing device cluster to execute the load testing task based on the machine configuration parameters. Here, S can be a positive integer. Further, the load testing scheduler can allocate addresses to the N storage addresses in the task parameters, obtaining the storage addresses corresponding to the S load testing devices. In other words, the load testing scheduler can allocate resources to the N load testing case resources, obtaining the load testing case resources corresponding to the S load testing devices. The S load testing devices are used to execute the load testing case resources corresponding to the allocated storage addresses; that is, the S load testing devices are used to execute the allocated load testing case resources. Further, the load testing scheduler can obtain the execution parameters that meet the execution conditions from the task parameters, and determine the execution parameters and the storage addresses corresponding to the S load testing devices as the load testing parameters corresponding to the S load testing devices. The system comprises S load testing devices, including a target load testing device (which can be any one of the S load testing devices), and S load testing parameters, including the target load testing parameters corresponding to the target load testing device. The load testing scheduling node can determine the target load testing parameters (i.e., the target load testing parameters) by combining the execution parameters and the storage address corresponding to the target load testing device. Furthermore, the load testing scheduling node can send the S load testing parameters to the corresponding load testing devices. Specifically, the load testing scheduling node can send the S load testing parameters to the load testing task agent (i.e., the worker service) within the corresponding load testing device; the load testing scheduling node can also send the target load testing parameters to the target load testing device, and vice versa.

[0097] Execution parameters refer to the parameters required to execute load test case resources, while execution conditions refer to the conditions for obtaining the parameters required to execute load test case resources. For example, execution parameters may include load parameters for RPS mode, load parameters for VU mode, and task information. Task parameters may include log level, warm-up time, and continuous load testing after warm-up.

[0098] The load testing scheduling node can obtain machine information (e.g., IP address, domain name, location) of the load testing devices in the load testing device cluster from the device database, and then retrieve the load testing devices in the cluster based on this information. The device database is a database within a service discovery platform (e.g., the Polaris service discovery platform). After deploying the load testing task agent, the load testing devices in the cluster can automatically register with the service discovery platform, which then manages all the load testing devices in the cluster.

[0099] The machine configuration parameters include machine type configuration parameters, region configuration parameters, and quantity configuration parameters. Machine type configuration parameters include hardware and software configuration parameters. Hardware configuration parameters include CPU (Central Processing Unit), number of CPU cores (e.g., 4 cores), memory (e.g., 16GB), hard drive (e.g., solid-state drive), and RPS level (i.e., the maximum number of RPS supported per second). Software configuration includes the operating system (e.g., CentOS) and programming language (e.g., Java). Region configuration parameters include region (e.g., Guangzhou), traffic percentage (e.g., 100%), RPS (e.g., 921 transactions), and execution count (e.g., unlimited). Quantity configuration parameters indicate the number of machines (e.g., 11 units).

[0100] It should be understood that the load testing scheduling node can obtain idle load testing devices from the load testing device cluster, and from these idle devices, obtain load testing devices that meet the machine type configuration parameters and regional configuration parameters. Furthermore, the load testing scheduling node can match the number of load testing devices meeting the machine type configuration parameters and regional configuration parameters with the quantity configuration parameters. If the number of load testing devices meeting the machine type configuration parameters and regional configuration parameters is greater than or equal to the quantity configuration parameters (i.e., there are enough load testing devices), the load testing scheduling node can obtain S load testing devices from these devices to execute the load testing task. These S load testing devices simultaneously meet the machine type configuration parameters, regional configuration parameters, and quantity configuration parameters. The load testing scheduling node can randomly select these S load testing devices from the machine type configuration parameters and regional configuration parameters to execute the load testing task. Optionally, if the number of load testing devices that meet the model configuration parameters and region configuration parameters is less than the quantity configuration parameters (i.e., there are insufficient load testing devices), the load testing scheduling node can send an insufficient device message to the load testing management node. This insufficient device message indicates that idle load testing devices cannot simultaneously meet the model configuration parameters, region configuration parameters, and quantity configuration parameters.

[0101] Optionally, the load testing scheduling node can obtain idle load testing devices from the load testing device cluster, and from these idle devices, obtain load testing devices that meet the device configuration parameters. Further, the load testing scheduling node can obtain load testing devices that meet the regional configuration parameters from the load testing devices that meet the device configuration parameters (i.e., load testing devices that meet both the device configuration parameters and the regional configuration parameters). The number of load testing devices that meet the regional configuration parameters is matched with the quantity configuration parameters. If the number of load testing devices that meet the regional configuration parameters is greater than or equal to the quantity configuration parameters (i.e., there are enough load testing devices), the load testing scheduling node can obtain S load testing devices from the load testing devices that meet the regional configuration parameters to execute the load testing task. The load testing scheduling node can randomly obtain S load testing devices from the load testing devices that meet the regional configuration parameters to execute the load testing task. Optionally, if the number of load testing devices that meet the regional configuration parameters is less than the quantity configuration parameters (i.e., there are insufficient load testing devices), the load testing scheduling node can send an insufficient device message to the load testing management node.

[0102] The number of machine configuration parameters can be at least one, the number of regional configuration parameters can be at least one, and the number of quantity configuration parameters can be at least one. The load test scheduling node can match the number of load test devices that meet the machine configuration parameters and regional configuration parameters with at least one quantity configuration parameter. Alternatively, the load test scheduling node can match the number of load test devices that meet the regional configuration parameters with at least one quantity configuration parameter. For example, the number of device configuration parameters can be one, which can be 16GB of memory; the number of region configuration parameters can be two, which can be (region D1) and (region D2); the number of quantity configuration parameters can be two, which can be 10 (the number of load testing devices in region D1) and 5 (the number of load testing devices in region D2); the number of load testing devices that meet the device configuration parameters (i.e., 16GB of memory) and region configuration parameters (region D1) (or, the number of load testing devices that meet the region configuration parameters (region D1)) must be greater than or equal to the quantity configuration parameter 10, and the number of load testing devices that meet the device configuration parameters (i.e., 16GB of memory) and region configuration parameters (region D2) (or, the number of load testing devices that meet the region configuration parameters (region D2)) must be greater than or equal to the quantity configuration parameter 5, otherwise there will be insufficient load testing devices. For example, the number of machine configuration parameters can be three, which can be 16GB of memory, a quad-core CPU, and 921 RPS; the number of region configuration parameters can be one, which can be (region D1); the number of quantity configuration parameters can be one, which can be 10 (the number of load testing devices in region D1); the number of load testing devices that meet the machine configuration parameters (i.e., 16GB of memory, a quad-core CPU, and 921 RPS) and the region configuration parameter (region D1) (or, the number of load testing devices that meet the region configuration parameter (region D1)) must be greater than or equal to the quantity configuration parameter 10, otherwise there will be insufficient load testing devices.

[0103] Understandably, the load testing scheduling node can send a device status retrieval request to the load testing devices in the load testing device cluster. The load testing devices in the cluster can then respond to this request, sending their own device status (i.e., their own device status) to the load testing scheduling node. This allows the scheduling node to retrieve load testing devices with an idle status from the cluster. The device status of a load testing device in the cluster can be either active or idle. Active status indicates that the device is executing load testing test cases, while idle status indicates that the device is not executing load testing test cases.

[0104] Step S103: The S load testing devices retrieve load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and execute the retrieved load testing case resources.

[0105] Specifically, the target load testing device can retrieve the target load testing case resource corresponding to the target load testing device from the test case database based on the storage address in the target load testing parameters, thus confirming the successful deployment of the target load testing case resource. The target load testing case resource belongs to N load testing case resources, and can be any one of these N resources. The target load testing device can retrieve the target load testing case resource from the test case database through a load testing task agent. The target load testing device can retrieve the target load testing case resource corresponding to the target load testing device from the storage bucket of the test case database based on the storage address in the target load testing parameters. In other words, the load testing task agent can retrieve the target load testing case resource corresponding to the target load testing device from the storage bucket of the test case database based on the storage address in the target load testing parameters. Furthermore, the target load testing device can execute the target load testing case resource, thereby realizing parallel load testing of multiple tasks (including the load testing task created in step S101) on the load testing platform. The target load testing case resource can include load testing cases and test case data; the target load testing device actually executes the load testing cases within the target load testing case resource. In addition, a load testing device can have a test case process. The load testing device can call the test case process through the load testing task agent to execute the target load testing test case resource (or the load testing test cases in the target load testing test case resource) through the test case process.

[0106] Since a storage address can be assigned to at least one load testing device (i.e., a load test case resource can be assigned to at least one load testing device), at least one load testing device can have the same storage address (i.e., at least one load testing device can be used to execute the same load test case resource). For example, three load testing devices can obtain the same load test case resource from the test case database and execute the same load test case resource based on the same allocated storage address.

[0107] In this process, each of the S load testing devices can incrementally retrieve load test case resources for the load testing task from the test case database based on its corresponding load testing parameters (i.e., incrementally download the load test case resources for the load testing task), thereby improving resource deployment efficiency. This is illustrated using the target load testing device as an example. If the target load testing device stores target load test case resources, it does not need to retrieve these resources from the test case database based on the storage address in the target load testing parameters; instead, it directly retrieves the stored resources. If the target load testing device does not store target load test case resources, it can retrieve them from the test case database based on the storage address in the target load testing parameters. The presence of target load test case resources means that the target load testing device executed the target load test case resources before participating in the load testing task. These resources belong to other load testing tasks executed by the target load testing device before participating in the load testing task, and they also belong to the load testing task created in step S101.

[0108] It is understandable that the target load testing device can assemble the execution parameters in the target load testing parameters to obtain command-line parameters. These command-line parameters are used to execute the load testing cases in the target load testing case resource, or the command-line parameters and the test case data in the target load testing case resource are used together to execute the load testing cases in the target load testing case resource. The load testing cases in the target load testing case resource are binary files (i.e., test case binary files, binary test case files). Furthermore, the target load testing device can perform command-line parsing on the command-line parameters (e.g., parsing command-line parameters through the load testing framework ego) to obtain the load testing task's load distribution method. Further, the target load testing device can initiate load testing traffic against the stressed objects in the target load testing case resource based on the load distribution method (i.e., transmitting load testing traffic to the stressed objects in the target load testing case resource based on the load distribution method), and send a load testing execution status message to the load testing scheduling node. The load testing execution status message indicates that the target load testing device is performing a load test; this application does not limit the communication protocol used to transmit load testing traffic, for example, the communication protocol can be HTTP (Hypertext Transfer Protocol).

[0109] Optionally, when a syntax error exists in the target load test case resource, the target load test device can stop the load test traffic to the target object and send a load test failure message to the load test scheduling node. The load test failure message indicates that a syntax error exists in the load test case resource.

[0110] For easier understanding, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating a scenario for executing load testing test case resources, as provided in an embodiment of this application. Figure 6As shown, the load testing scheduling node can send corresponding load testing parameters to each of the S load testing devices in the load testing device cluster. This means sending the S load testing parameters to their respective load testing devices. The S load testing devices can include load processor 1 (i.e., load testing device 1), load processor 2 (i.e., load testing device 2), ..., load processor n (i.e., load testing device n). For example, load processor 1 can be the target load testing device. The load testing scheduling node can send target load testing parameters to the target load testing device. The internal interaction flow of the target load testing device's test case process is used as an example for illustration. Therefore, the load testing scheduling node can send corresponding load testing parameters to the test case processes of the S load testing devices (e.g., the test case process of the target load testing device).

[0111] like Figure 6 As shown, the test case process can execute step S61, which assembles the execution parameters in the target load testing parameters to obtain command-line parameters, and then parses the command-line parameters to start the load test. Further, the test case process can execute step S62, which obtains the log level of the load testing task (e.g., ERROR) from the target load testing parameters, and sets the logs based on the log level, i.e., recording different levels of information based on the log level. Further, the test case process can execute step S63, which loads the test case configuration, i.e., retrieves the target load testing test case resources corresponding to the target load testing device from the test case database according to the storage address in the target load testing parameters, and loads (or reads) the load testing test case resources.

[0112] like Figure 6 As shown, after executing step S61, the test case process can execute step S64 to obtain the load testing task's load distribution method (i.e., parallel acquisition), which is to load the traffic model. The load distribution method can be RPS mode or VU mode. Further, the test case process can execute step S65 to initialize the stress test, which involves a series of configuration and preparation tasks for the test environment and test tools before conducting the stress test (e.g., configuring test parameters, preparing test data, and setting up the test environment) to ensure the stress test can proceed smoothly and achieve the expected results. Further, the test case process can execute step S66 to start the load testing traffic (i.e., schedule traffic), which involves starting the load testing traffic for the stressed object in the target load testing test case resource based on the load distribution method.

[0113] The test case process can sequentially execute steps S67-S69, which represent different stages of the stress test. These steps can be implemented through different interfaces (e.g., step S67 can be implemented using the `beforeAttack` interface, step S68 using the `attack_xxx` interface, and step S69 using the `afterAttack` interface). Step S68 indicates that the `attack_xxx` function is executed in a loop. These stages help organize and manage the stress test process, ensuring the comprehensiveness and systematic nature of the stress test. Step S67 represents the preparation stage before the stress test begins, ensuring the test environment is ready. Step S68 represents the stress test execution stage, simulating different load conditions to test the performance and stability of the stressed object. Step S69 represents the wrap-up stage after the stress test is completed, restoring the test environment.

[0114] like Figure 6 As shown, when the stress test ends or a syntax error exists in the target stress test case resource, the test case process can execute step S70. Step S70 determines the end of the stress test, and then executes step S71. Step S71 calls the afterstop interface, which performs a series of operations and steps after the stress test is completed. This ensures that the test environment is properly cleaned and restored to its pre-test state, and that test data is collected and analyzed to provide a basis for subsequent reporting and improvement. Specifically, the stress test ends after the stress test duration is reached or after receiving other exit signals. Further, step S72 indicates the end of the stress test (i.e., the end of the stress test on the target stress test device). At this point, the target stress test device can terminate the stress test process.

[0115] It should be understood that the load testing scheduling node can obtain the deployment results corresponding to S load testing devices. When the deployment results of the S load testing devices indicate that all S load testing devices have successfully deployed the load testing test case resources, a start load testing command is sent to each of the S load testing devices. Specifically, the load testing scheduling node can poll to obtain the deployment results corresponding to the S load testing devices; the S load testing devices can also send their deployment results to the load testing scheduling node after successfully deploying the load testing test case resources. Furthermore, after the target load testing device receives the start load testing command, it can execute the target load testing test case resources. In other words, after the S load testing devices receive the start load testing command, each of the S load testing devices can execute the obtained load testing test case resources. Therefore, when all S load testing devices have successfully deployed the load testing test case resources, each of the S load testing devices can execute the obtained load testing test case resources.

[0116] It should be understood that the load testing management node can respond to the trigger operation for the task stop function by sending a task stop command to the load testing scheduling node. The load testing scheduling node can then forward the task stop command to the S load testing devices. The task stop command is used to actively stop the load testing task chain. The load testing management node can send a stop load testing task request to the load testing scheduling node. The stop load testing task request includes the task stop command and the task identifier of the load testing task, which is used to uniquely identify the load testing task. The trigger operation for the task stop function can be a user-triggered operation on the task stop control. Here, we take the target load testing device responding to the task stop command as an example. For the specific process of the load testing devices other than the target load testing device responding to the task stop command, please refer to the description of the target load testing device responding to the task stop command. Further, if the target load testing device is in an idle state, it can return a task exit message to the load testing scheduling node. Optionally, if the target load testing device is in a working state, it can stop executing the target load testing test case resources, return a task stop message to the load testing scheduling node, and update the target load testing device's state to idle. Among them, the idle state indicates that the load test case resource has not been executed, the working state indicates that the load test case resource is being executed (i.e., the load test case resource of other load test tasks), the task exit message indicates that the target load test case resource has been completed, and the task stop message indicates that the target load test case resource has stopped executing.

[0117] Similarly, the load testing management node can respond to the trigger operation for the test case stop function, sending a test case stop command to the load testing scheduling node to stop the load testing test case resource. The load testing scheduling node can then forward the test case stop command to the load testing device corresponding to the stopped test case resource. The test case stop command is used to actively stop the load testing test case resource in the load testing task chain. The load testing management node can send a stop test case resource request to the load testing scheduling node. The stop test case resource request includes the test case stop command and the resource identifier of the stopped test case resource. The resource identifier is used to uniquely identify the stopped test case resource. The trigger operation for the test case stop function can be a user-defined stop control for the test case (e.g., the following...). Figure 8a The use case stop control 80b in the corresponding embodiment can stop the load testing use case resources as follows: Figure 8aThe triggering operation of the load test case resource (to which load test case 666 belongs in the corresponding embodiment) refers to stopping the execution of the load test case resource. Stopping the load test case resource means stopping the execution of the load test case resource. The load test device corresponding to the stopped load test case resource refers to the load test device used to execute the stopped load test case resource. Here, we take an example where the load test device corresponding to the stopped load test case resource includes the target load test device, and the target load test device responds to the load test case stop command. For the specific process of the load test devices other than the target load test device responding to the load test case stop command, please refer to the description of the target load test device responding to the load test case stop command. Further, if the device state of the target load test device is idle, the target load test device can return a load test case exit message to the load test scheduling node. Optionally, if the device state of the target load test device is working, the target load test device can stop executing the target load test case resource (i.e., stop the load test case resource), return a load test case stop message to the load test scheduling node, and update the device state of the target load test device to idle. Among them, the idle state indicates that the load test case resource has not been executed, the working state indicates that the load test case resource is being executed, the test case exit message indicates that the target load test case resource (i.e., the stopped load test case resource) has been executed, and the test case stop message indicates that the target load test case resource (i.e., the stopped load test case resource) has stopped executing.

[0118] It should be understood that after responding to a trigger operation for the task stop function, the load testing management node can respond to a trigger operation for the task start function by sending a task start command to the load testing scheduling node. The load testing scheduling node can then forward the task start command to the S load testing devices. The task start command is used to actively initiate the load testing task chain. The load testing management node can send a task start request to the load testing scheduling node. The task start request includes the task start command and the task identifier of the load testing task, which uniquely identifies the load testing task. The trigger operation for the task start function can be a user-triggered operation on the task start control. This explanation uses the target load testing device responding to the task start command as an example. For the specific process of the load testing devices other than the target load testing device responding to the task start command, please refer to the description of the target load testing device responding to the task start command. Furthermore, if the target load testing case resource has not been completed, the target load testing device can start executing the target load testing case resource (i.e., continue executing the target load testing case resource), return a task start message to the load testing scheduling node, and update the device status of the target load testing device to the working state. Optionally, if the target load test case resource has already been executed, the target load test device does not need to start executing the target load test case resource (i.e., it does not need to continue executing the target load test case resource) and returns a task exit message to the load test scheduling node. The task exit message indicates that the target load test case resource has been executed, while the task start message indicates that the target load test case resource has continued execution (or has been restarted).

[0119] Similarly, after responding to the trigger operation for the test case stop function, the load testing management node can respond to the trigger operation for the test case start function and send a test case start instruction to the load testing scheduling node for stopping the load testing test case resource (also known as starting the load testing test case resource). The load testing scheduling node can forward the test case start instruction to the load testing device corresponding to the stopped load testing test case resource. The test case start command is used to actively start the test case resources in the load testing task chain. The load testing management node can send a request to start the test case resources to the load testing scheduling node. The request to start the test case resources includes the test case start command and the resource identifier of the stop test case resources. The resource identifier is used to uniquely identify the stop test case resources. The trigger operation for the test case start function can be the user's trigger operation on the test case start control. Stop test case resources refer to test case resources that have stopped execution and need to be restarted. The load testing device corresponding to the stop test case resources refers to the load testing device used to execute the stop test case resources. Here, we take the example where the load testing device corresponding to the stop test case resources includes the target load testing device and the target load testing device responds to the test case start command. For the specific process of the load testing devices other than the target load testing device responding to the test case start command, please refer to the description of the target load testing device responding to the test case start command. Furthermore, if the target load test case resource (i.e., the stopped load test case resource) has not been completed, the target load test device can start executing the target load test case resource (i.e., continue executing the target load test case resource), return a test case start message to the load test scheduling node, and update the device status of the target load test device to the working state. Optionally, if the target load test case resource (i.e., the stopped load test case resource) has already been completed, the target load test device does not need to start executing the target load test case resource (i.e., does not need to continue executing the target load test case resource), and returns a test case exit message to the load test scheduling node. The test case exit message indicates that the target load test case resource (i.e., the stopped load test case resource) has been completed, and the test case start message indicates that the target load test case resource (i.e., the stopped load test case resource) has continued execution (or has been restarted).

[0120] For easier understanding, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating a process for stopping a load testing task, as provided in an embodiment of this application. Figure 7 The load testing platform equipment shown may include load testing management nodes, load testing scheduling nodes, and load testing equipment (e.g., target load testing equipment) in the load testing equipment cluster.

[0121] like Figure 7As shown, the user can execute step S11 through the load testing management node to stop the load testing task, i.e., trigger an operation for the task stop function (i.e., click "Stop Load Testing" on the load testing platform). The load testing management node can then respond to this trigger operation by executing step S12, stopping the load testing task by sending a task stop command to the load testing scheduling node. Further, the load testing scheduling node can execute step S13 to stop the load testing task, forwarding the task stop command to S load testing devices. Here, we will use the target load testing device as an example. The load testing scheduling node can obtain the IP addresses of the load testing devices (i.e., the S load testing devices) used to execute the load testing task and send the task stop command in batches to the S load testing devices based on their IP addresses. Further, the target load testing device can execute step S14 to check its status, i.e., check its own device status. The target load testing device's status can be either active or idle.

[0122] like Figure 7 As shown, if the target load testing device is in an idle state, it can execute step S15 to determine that the target load testing case resource has exited and return the device status to the load testing scheduling node, i.e., return a task exit message to the load testing scheduling node. Optionally, if the target load testing device is in a working state, it can execute steps S16 and S18. Step S16 interrupts the test case process, i.e., stops the execution of the target load testing case resource. Step S18 determines that the target load testing case resource has stopped and returns the device status to the load testing scheduling node, i.e., return a task stop message to the load testing scheduling node. Further, the target load testing device can execute step S19 to release the machine, i.e., update the device status from working to idle. At the same time, the load testing device can execute step S17 to assist the data aggregation node and the circuit breaker detection node in implementing circuit breaker detection.

[0123] It should be understood that the S load testing devices can each acquire performance data (i.e., single-machine performance data) of the executed load testing test case resources. Within a target time period, the acquired performance data is integrated to obtain integrated performance data (i.e., integrated single-machine performance data), which is then sent to the data aggregation node. The performance data of the load testing test case resources refers to the real-time performance data acquired by the S load testing devices, while the aggregated performance data refers to the performance data acquired by the S load testing devices within the target time period. This application does not limit the specific duration of the target time period; for example, the target time period can be 1 second, meaning that the S load testing devices can send integrated single-machine performance data to the data aggregation node every second. Furthermore, the data aggregation node can aggregate the integrated performance data sent separately by the S load testing devices to obtain aggregated performance data. In this context, data integration refers to summarizing (i.e., aggregating) the performance data of a single load testing device within a target time period. Data aggregation refers to summarizing (i.e., aggregating) the performance data of load testing tasks from S load testing devices (i.e., aggregating performance data). The S load testing devices can send the aggregated performance data to the data aggregation node every target time period. The data aggregation node can obtain the aggregated performance data sent by the S load testing devices in multiple target time periods, thereby achieving a combination of single-machine cohesion and service aggregation. Furthermore, the data aggregation node can store the aggregated performance data in a task database (the task database can be a time-series database CTSDB, which is a database designed for processing time-series data, and the aggregated performance data in the time-series database is recorded in chronological order), and store the task identifiers of the load testing tasks in an identifier database (the identifier database can be a key-value database Redis). In this way, the data aggregation node does not need to store the aggregation performance data and the task identifier of the load test task to the local disk. Instead, it stores the aggregation performance data and the task identifier of the load test task through the task database and the identifier database. This prevents the single machine disk from overflowing during long-term load testing, thus eliminating the need to continuously expand the disk of the data aggregation node and improving the data migration efficiency when the data aggregation node is removed.

[0124] The data aggregation node can aggregate the integrated performance data sent by the S load testing devices according to the interface dimension, or it can directly aggregate the integrated performance data sent by the S load testing devices (i.e., aggregate the integrated performance data sent by the S load testing devices according to the task dimension), or it can aggregate the integrated performance data sent by the S load testing devices according to the time dimension (for example, aggregate the integrated performance data sent by the S load testing devices every 10 minutes). This application embodiment does not limit the specific method of data aggregation.

[0125] It should be understood that data aggregation nodes can send aggregated performance data to the load testing management node. Specifically, the load testing management node can proactively poll aggregated performance data from the data aggregation nodes, and the data aggregation nodes can also proactively send aggregated performance data to the load testing management node. Furthermore, the load testing management node can respond to viewing operations related to the load testing report function, displaying the aggregated performance data. These viewing operations can be for viewing report controls (e.g., as described below). Figure 8a The report viewing control 80a in the corresponding embodiment and the following Figure 9 When the report viewing control 90 in the corresponding embodiment is triggered, the aggregated performance data is displayed in the form of a load test report (or query report). The load test report indicates the display method of the aggregated performance data. Since the data aggregation node can continuously send the aggregated performance data obtained from data aggregation to the load test management node, the aggregated performance data can be displayed in real time in the load test management node (i.e., dynamically displayed).

[0126] It is understood that aggregated performance data (or performance data, integrated performance data) may include, but is not limited to, RPS (instantaneous value), QPS (instantaneous value), failure rate (instantaneous value), total number of requests, total number of failures, total number of errors, average QPS, average failure rate, average response time, 95-line time, 99-line time, and maximum response time.

[0127] Among them, RPS (instantaneous value) represents the number of requests processed per unit of time under a certain number of concurrent users; QPS (instantaneous value) represents the number of queries that can be responded to per second; failure rate (instantaneous value) represents the proportion of failed requests to total requests within a certain period of time; total requests represent the total number of all requests within a specific time period (i.e., the number of requests initiated by the load testing device); total failures represent the total number of all failed requests processed within a specific time period; total errors represent the total number of errors generated within a specific time period, which may include various types of anomalies or errors; average QPS represents the average number of requests processed within a certain time period. The number of requests that can be processed per second; the average failure rate represents the average proportion of failed requests to total requests over a certain period of time; the average response time represents the average response time of all requests, that is, the average time from when the load testing platform device initiates a request to when it receives the response result from the object being tested; 95th percentile time represents the 95th percentile response time, that is, 95% of the request response times are lower than this value; 99th percentile time represents the 99th percentile response time, that is, 99% of the request response times are lower than this value; the maximum response time represents the longest time taken for a single request from start to finish among all requests.

[0128] It should be understood that the data aggregation node can obtain and display the execution data corresponding to each of the N load test case resources. This execution data can include, but is not limited to, "Deploying," "Deployment Completed," "RPS," "Execution Successful," "Executing," "Execution Exception," "Manual Stop," and "Circuit Breaker Stopped." Specifically, "Deploying" indicates the number of load test devices being deployed; "Deployment Completed" indicates the number of load test devices that have completed deployment; "RPS" represents the number of requests processed per second; "Execution Successful" indicates the number of load test devices that have successfully executed; "Execution Successful" indicates the number of load test devices that are currently executing; "Execution Exception" indicates the number of load test devices that have encountered execution errors; "Manual Stopped" indicates the number of load test devices that have been manually stopped; and "Circuit Breaker Stopped" indicates the number of load test devices that have been stopped by circuit breakers.

[0129] For easier understanding, please refer to Figure 8a and Figure 8b , Figure 8a and Figure 8b This is a schematic diagram illustrating a scenario for viewing a single-use case load test report, as provided in an embodiment of this application. Figure 8a The image shows the interface displaying the execution data for a single test case, as follows: Figure 8b The image shows the interface displaying aggregated performance data for a single test case, while the load testing task is currently running.

[0130] like Figure 8a As shown, the task name for the load testing task can be "First Load Testing," the executor can be "zw," the concurrency mode can be RPS mode, the start time can be "2024-11-06 16:12:57," the warm-up time can be 10 seconds, the continuous load testing after warm-up can be 60 seconds, the task status can be "Executing," and the task type can be "Normal Task." The load testing task can include load testing case 666. The execution data corresponding to load testing case 666 can include "Deploying (e.g., 0), Deployment Completed (e.g., 0), RPS (e.g., 10), Execution Successful (e.g., 0), Executing (e.g., 1), Execution Exception (e.g., 0), Manual Stop (e.g., 0), and Circuit Breaker Stop (e.g., 0).

[0131] like Figure 8bAs shown, there can be two load testing interfaces, which can include interface api_1 and interface api_2. Total represents the aggregation of the aggregated performance data of interface api_1 and interface api_2. The aggregated performance data of Total, interface api_1, and interface api_2 are aggregated performance data of different dimensions. Here, we take the aggregated performance data of Total as an example for explanation. The aggregated performance data may include RPS (instantaneous value) (e.g., 20 reqs / s), QPS (instantaneous value) (e.g., 20 reqs / s), failure rate (instantaneous value) (e.g., 50%), total number of requests (e.g., 528 reqs), total number of failures (e.g., 264 reqs), total number of errors (e.g., 0 reqs), average QPS (e.g., 17.1 reqs / s), average failure rate (e.g., 50%), average response time (e.g., 0 ms), 95-line time (e.g., 0 ms), 99-line time (e.g., 0 ms), and maximum response time (e.g., 0.01 ms).

[0132] like Figure 8b As shown, the load testing management node can also display relationship graphs between different aggregated performance data (e.g., line graphs between QPS and RPS, line graphs between average response time and RPS; the specific form of the relationship graph will not be limited here), thereby providing real-time graphical display of performance data during execution and intuitive chart display of the analysis results (i.e., performance data) of the load testing model, making it easier for users to understand and analyze performance data.

[0133] For easier understanding, please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating a scenario for viewing multi-use case load test reports, provided in an embodiment of this application. For example... Figure 9 The image shows the interface displaying the execution data of multiple test cases. Here, we will use three load test case resources as an example for explanation. At this time, the load test task is being executed.

[0134] like Figure 9As shown, the task name for the load testing task can be "Scenario Load Testing", the executor can be "zw", the concurrency mode can be "RPS mode", the start time can be "2024-11-7 16:12:57", the warm-up time can be 10 seconds, the continuous load testing after warm-up can be 300 seconds, the task status can be "Executing", the task type can be "Normal Task", the scenario template can be "Create New Plan", and the remarks can be "For Demonstration". The load testing task may include load test case 245, load test case 5, and load test case 593. The execution data corresponding to load test case 245 may include deployment in progress (e.g., 0), deployment completed (e.g., 0), RPS (e.g., 4), execution successful (e.g., 0), execution in progress (e.g., 1), execution exception (e.g., 0), manual stop (e.g., 0), and circuit breaker stop (e.g., 0). The execution data corresponding to load test case 5 may include deployment in progress (e.g., 0), deployment completed (e.g., 0), RPS (e.g., 10), execution successful (e.g., 0), execution in progress (e.g., 0), execution exception (e.g., 1), manual stop (e.g., 0), and circuit breaker stop (e.g., 0). The execution data corresponding to load test case 593 may include deployment in progress (e.g., 0), deployment completed (e.g., 0), RPS (e.g., 10), execution successful (e.g., 0), execution in progress (e.g., 1), execution exception (e.g., 0), manual stop (e.g., 0), and circuit breaker stop (e.g., 0).

[0135] For easier understanding, please refer to Figure 10 , Figure 10 This is a schematic diagram of a stress test process provided in an embodiment of this application. Figure 10 As shown, multi-use case load testing may include steps S51, S52, S53, S54, S55, and S56, while single-use case load testing may include steps S57, S58, S53, S54, S55, and S56. Therefore, the load testing pipeline of this application can reduce user operations and eliminate the need to deploy dependencies, thereby improving the usability and deployment efficiency of the load testing platform.

[0136] like Figure 10As shown, in multi-test case load testing, the user can execute step S51 to orchestrate the scenario, ensuring that the test scenario contains at least two load test case resources. Then, step S52 creates a load test task containing at least two load test case resources. In single-test case load testing, the user can execute step S57 to determine that the load test task contains one load test case resource. Then, step S58 creates a load test task containing one load test case resource (i.e., initiating load testing directly with a single test case). Scenario orchestration refers to the process of designing and organizing test scenarios based on actual business needs and test objectives during load testing. Scenario orchestration can design the execution order and logic of a series of requests based on actual business processes to simulate real user operations and business scenarios. Furthermore, the load test management node can obtain the task parameters of the load test task and send them to the load test scheduling node.

[0137] like Figure 10 As shown, in single-use case load testing and multi-use case load testing, the load testing scheduling node can execute step S53, which allocates machines by obtaining S load testing devices from the load testing device cluster to execute the load testing task according to the task parameters. Further, the load testing scheduling node can execute step S54, which deploys resources by obtaining the load testing parameters corresponding to the S load testing devices from the task parameters and sending these parameters to the corresponding load testing devices, so that each of the S load testing devices can obtain load testing case resources for the load testing task from the use case database according to the corresponding load testing parameters. Further, the S load testing devices can execute step S55, which executes the obtained load testing case resources. Further, the user can execute step S56, which allows viewing the report; that is, the load testing management node can respond to the viewing operation of the load testing report function and display aggregated performance data.

[0138] It should be understood that the data aggregation node can send aggregated performance data to the circuit breaker detection node. Further, the circuit breaker detection node can compare the aggregated performance data with data thresholds to obtain a comparison result. Further, if the comparison result indicates that the aggregated performance data meets the circuit breaker condition (i.e., a data anomaly is detected), the circuit breaker detection node can send a task circuit breaker message to the load testing scheduling node to stop the load testing task. Optionally, if the comparison result indicates that the aggregated performance data does not meet the circuit breaker detection condition (i.e., no data anomaly is detected), the circuit breaker detection node does not need to send a task circuit breaker message to the load testing scheduling node (i.e., it does not need to notify the load testing scheduling node to perform circuit breaker processing). The task circuit breaker message indicates that the load testing task needs to be stopped, and the load testing scheduling node can stop the load testing task by sending a task stop command to the load testing device.

[0139] Different aggregation performance data can correspond to different data thresholds. When the aggregation performance data is greater than the data threshold, a data comparison result is generated to indicate that the aggregation performance data meets the circuit breaker condition. When the aggregation performance data is less than or equal to the data threshold, a data comparison result is generated to indicate that the aggregation performance data does not meet the circuit breaker condition. It should be understood that this application does not limit the specific value of the data threshold. For example, the data threshold corresponding to the total number of errors can be 3, the data threshold corresponding to the average response time can be 1 second, and the data threshold corresponding to the failure rate (instantaneous value) can be 80%.

[0140] For easier understanding, please refer to Figure 11 , Figure 11 This is a schematic diagram illustrating a data interaction process provided in an embodiment of this application. For example... Figure 11 As shown, the stress testing platform equipment includes a stress testing management node, a stress testing scheduling node, a data aggregation node, a circuit breaker detection node, and a stress testing equipment cluster.

[0141] like Figure 11 As shown, the user can execute step S21 to start the load test, which involves creating a load test task on the load test platform. The load test management node can then respond to this creation operation and execute step S22 to verify the user's permissions. If the user does not have permission (permission verification fails), the load test management node can execute step S23 to deny access, preventing the user from creating the load test task. Optionally, if the user has permission to create the load test task (permission verification passes), the load test management node can determine the task parameters based on the task creation parameters of the created load test task. The task status of the load test task is initialized. Further, the load test management node can execute step S24 to start the load test, sending the task parameters to the load test scheduling node.

[0142] like Figure 11As shown, the load testing scheduling node can execute step S25, which involves obtaining machines by sending a device status acquisition request to the load testing devices in the load testing device cluster. The load testing devices in the cluster can then execute step S26, returning the machine status to the load testing scheduling node. Further, the load testing scheduling node can execute step S27, performing machine matching by obtaining S load testing devices from the load testing device cluster based on the machine configuration parameters of the load testing task. The load testing scheduling node can obtain currently available idle load testing machines in real time and perform machine matching accordingly. If there are insufficient load testing devices (i.e., matching fails), the load testing scheduling node can execute step S28, sending a message indicating insufficient machines (i.e., insufficient device quantity) to the load testing management node. In this case, the task status of the load testing task is "matching failed." Optionally, if there are enough load testing devices (i.e., a successful match), the load testing scheduling node can execute step S29, which involves deploying resources by obtaining the load testing parameters corresponding to the S load testing devices from the task parameters and sending the S load testing parameters to the corresponding load testing devices. Here, the task status of the load testing task is "successfully matched," and the S load testing parameters represent the start deployment command.

[0143] like Figure 11 As shown, the S load testing devices can each obtain the corresponding load testing parameters (i.e., pull resources) to determine the successful deployment of load testing test case resources, and then execute step S30, sending the deployment result to the load testing scheduling node. The task status of the load testing task is "deploying". Further, the S load testing devices can each execute step S31, pulling files according to the corresponding load testing parameters from the test case database. Simultaneously, the load testing scheduling node can execute step S32, polling the deployment results of the S load testing devices. If the deployment results of the S load testing devices do not indicate that all S load testing devices have successfully deployed the load testing test case resources (at least one of the S load testing devices failed to deploy the load testing test case resources), step S33 is executed to determine if the deployment has timed out or failed.

[0144] like Figure 11As shown, when the deployment results for the S load testing devices indicate that all S load testing devices have successfully deployed the load testing test case resources, the load testing scheduling node can confirm that all resources have been deployed and then execute step S34 to start the load testing, i.e., send a start command (start command) to each of the S load testing devices. After receiving the start command, each of the S load testing devices can execute step S35 to execute the acquired load testing test case resources. Simultaneously, each of the S load testing devices can execute step S36 to send a load testing status message (i.e., a load testing execution status message) to the load testing scheduling node. If no load testing execution status message is received from each of the S load testing devices, the load testing scheduling node can execute step S37 to return a start failure message (i.e., a start failure message) to the load testing management node. The start failure message indicates that some of the S load testing devices have not executed the load testing test case resources.

[0145] like Figure 11 As shown, upon receiving load test execution status messages from the S load testing devices, the load test scheduling node can determine that the startup was successful, set the task status of the load test task to "load test in progress," and then execute step S38. In step S38, it sends a command to the circuit breaker detection node to start circuit breaker detection (i.e., a circuit breaker detection start command), causing the circuit breaker detection node to begin circuit breaker detection. Optionally, the load test scheduling node can also send a command to the data aggregation node to start data aggregation (i.e., a data aggregation start command), causing the data aggregation node to begin data aggregation. Thus, after the S load testing devices obtain the performance data of the executed load test case resources, they can integrate the obtained performance data within the target time period to obtain integrated performance data. Then, step S39 is executed, and the obtained integrated performance data is sent to the data aggregation node. Further, the data aggregation node can execute step S40, sending performance data, i.e., aggregating the integrated performance data sent by the S load testing devices to obtain aggregated performance data, and then sending the aggregated performance data to the circuit breaker detection node.

[0146] like Figure 11As shown, after acquiring the aggregated performance data, the circuit breaker detection node can execute step S41 to perform circuit breaker detection, which compares the aggregated performance data with the data threshold. In other words, the circuit breaker detection node can detect in real time whether the aggregated performance data has reached the circuit breaker threshold. Further, if the aggregated performance data meets the circuit breaker conditions, the circuit breaker detection node can execute step S42 to send a circuit breaker notification (i.e., a task circuit breaker message) to the load testing scheduling node. Simultaneously, the user can execute step S43 to view the report, i.e., perform a viewing operation on the load testing report function, so that the load testing management node displays the aggregated performance data acquired from the data aggregation node.

[0147] For easier understanding, please refer to Figure 12 , Figure 12 This is a structural schematic diagram of a pressure testing platform device provided in an embodiment of this application. For example... Figure 12 As shown, the load testing platform equipment includes load testing management (i.e., load testing management node), scheduling center (i.e., load testing scheduling node), data aggregation (i.e., data aggregation node), circuit breaker detection (i.e., circuit breaker detection node), and load testing equipment cluster. The load testing equipment cluster can include load testing equipment 1, ..., load testing equipment n; the number of load testing equipment in the load testing equipment cluster is not limited here.

[0148] like Figure 12 As shown, the load testing management node can be used to implement resource management, test case management, scenario orchestration, load testing start / stop, and load testing reports. Resource management refers to load testing resource scheduling; test case management refers to acquiring load testing test case resources; scenario orchestration refers to managing load testing test case resources in test scenarios; load testing start / stop refers to starting and stopping load testing tasks; and load testing reports refer to displaying aggregated performance data. Furthermore, the load testing management node can perform data management, storing the acquired data in a management database (which can be a MySQL database); it can store interface data (or tokens) in an interface database (which can be a key-value database like Redis), where interface data refers to the interfaces accessing the load testing platform; it can send commands to the scheduling center to start load testing (e.g., task start command) and stop load testing (e.g., task stop command); and it can obtain and display aggregated performance data from the data aggregation node.

[0149] like Figure 12As shown, the scheduling center can forward commands to start and stop load testing to the load testing devices in the load testing device cluster; the scheduling center can obtain machine information of the load testing devices in the load testing device cluster from the device database, and the load testing devices in the load testing device cluster can automatically register with the service discovery platform to which the device database belongs, so that the machine information of the load testing devices in the load testing device cluster can be stored in the device database; the scheduling center can send commands to start circuit breaker detection nodes.

[0150] like Figure 12 As shown, the data aggregation node can obtain single-machine performance data (i.e., integrated single-machine performance data) from the load testing devices in the load testing device cluster. This single-machine performance data is obtained by the load testing devices executing load testing test case resources (including load testing test cases and test case data) obtained from the test case database. The data aggregation node can store the aggregated performance data (i.e., task performance data) in the task database and store the task identifier of the load testing task in the identifier database. The data aggregation node can send the aggregated performance data to the circuit breaker detection node. The data aggregation node can also send the performance data (i.e., aggregated performance data) to the load testing management node for display.

[0151] like Figure 12 As shown, after receiving the instruction to start circuit breaker detection sent by the scheduling center, the circuit breaker detection node can obtain aggregated performance data from the data aggregation node, compare the aggregated performance data with the data threshold, and thus realize circuit breaker detection.

[0152] Therefore, this application provides a financial-grade distributed load testing system that supports tens of millions of QPS (Queries Per Second). This load testing system can obtain the load testing parameters corresponding to the load testing devices used to execute the load testing tasks from the task parameters of the load testing tasks through the load testing scheduling node, and distribute the load testing parameters to the load testing devices used to execute the load testing tasks. This allows the load testing devices to actively obtain load testing case resources for the load testing tasks from the test case database based on the load testing parameters, without having to passively receive load testing case resources issued by the test case management node. This eliminates the need to store a large number of load testing case resources through the test case management node, thereby avoiding single-machine disk overflow and improving the stability of the load testing platform devices.

[0153] Further, please see Figure 13 , Figure 13This is a structural schematic diagram of a stress testing device provided in an embodiment of this application. The stress testing device 1 is applied to a stress testing platform device, which includes a stress testing equipment cluster. The stress testing device 1 may include: a stress testing management module (i.e., a stress testing management node) 11, a stress testing scheduling module (i.e., a stress testing scheduling node) 12, a control module 13, a data aggregation module (i.e., a data aggregation node) 14, and a circuit breaker detection module (i.e., a circuit breaker detection node) 15.

[0154] The load testing management module 11 is used to obtain the task parameters of the load testing task and send the task parameters to the load testing scheduling module.

[0155] The load testing scheduling module 12 is used to obtain S load testing devices for executing load testing tasks from the load testing device cluster according to the task parameters, obtain the load testing parameters corresponding to the S load testing devices respectively from the task parameters, and send the S load testing parameters to the corresponding load testing devices respectively; S is a positive integer;

[0156] The control module 13 is used to control the S load testing devices to obtain load testing test case resources for the load testing task from the test case database according to the corresponding load testing parameters, and to execute the obtained load testing test case resources.

[0157] Among them, the load testing management module 11 is specifically used to respond to the creation operation of the task creation function and display the task creation parameters of the created load testing task; the load testing task includes N load testing test case resources; N is a positive integer;

[0158] The load testing management module 11 is specifically used to respond to the confirmation operation for the load testing task, store N load testing case resources to the case database, and obtain the storage addresses of the N load testing case resources in the case database respectively;

[0159] The load testing management module 11 is specifically used to replace the N load testing case resources in the task creation parameters according to the N storage addresses, obtain the task parameters of the load testing task, and send the task parameters to the load testing scheduling module.

[0160] Among them, the load testing scheduling module 12 is specifically used to obtain the machine configuration parameters of the load testing task from the task parameters, and obtain S load testing devices from the load testing device cluster to execute the load testing task according to the machine configuration parameters;

[0161] The load testing scheduling module 12 is specifically used to allocate addresses to the N storage addresses in the task parameters, thereby obtaining the storage addresses corresponding to the S load testing devices; the S load testing devices are used to execute the load testing test case resources corresponding to the allocated storage addresses.

[0162] The load testing scheduling module 12 is specifically used to obtain the execution parameters that meet the execution conditions from the task parameters, and to determine the execution parameters and the storage addresses corresponding to the S load testing devices as the load testing parameters corresponding to the S load testing devices respectively.

[0163] The machine configuration parameters include machine type configuration parameters, region configuration parameters, and quantity configuration parameters;

[0164] The load testing scheduling module 12 is specifically used to obtain load testing equipment with an idle state from the load testing equipment cluster, and to obtain load testing equipment that meets the model configuration parameters and regional configuration parameters from the load testing equipment with an idle state.

[0165] The load testing scheduling module 12 is specifically used to match the number of load testing devices that meet the model configuration parameters and regional configuration parameters with the quantity configuration parameters. If the number of load testing devices that meet the model configuration parameters and regional configuration parameters is greater than or equal to the quantity configuration parameters, then S load testing devices for executing the load testing task are obtained from the load testing devices that meet the model configuration parameters and regional configuration parameters.

[0166] The load testing scheduling module 12 is also specifically used to send an insufficient number of devices message to the load testing management module if the number of load testing devices that meet the model configuration parameters and regional configuration parameters is less than the quantity configuration parameters.

[0167] Wherein, S load testing devices include target load testing devices; S load testing parameters include target load testing parameters corresponding to the target load testing devices; the number of load testing test case resources for the load testing task is N; N is a positive integer;

[0168] Control module 13 is specifically used to control the target load testing device to retrieve the target load testing case resource corresponding to the target load testing device from the case database according to the storage address in the target load testing parameters, and to determine that the target load testing device has successfully deployed the target load testing case resource; the target load testing case resource belongs to N load testing case resources;

[0169] The control module 13 is specifically used to control the target load testing equipment to execute target load testing test case resources.

[0170] Specifically, the control module 13 is used to assemble the execution parameters in the target stress test parameters to obtain command line parameters;

[0171] Control module 13 is specifically used to parse command line parameters to obtain the load distribution method of the load testing task;

[0172] Control module 13 is specifically used to initiate load test traffic for the stressed object in the target load test case resource based on the load sending method, and send load test execution status messages to the load test scheduling module;

[0173] The control module 13 is also specifically used to stop the load testing traffic to the target object and send a load testing failure message to the load testing scheduling module when there is a syntax error in the target load testing test resource.

[0174] Among them, the load testing scheduling module 12 is also specifically used to obtain the deployment results corresponding to the S load testing devices respectively. When the deployment results corresponding to the S load testing devices indicate that the load testing test case resources of the load testing task have been successfully deployed by the S load testing devices, the load testing start command is sent to the S load testing devices respectively.

[0175] The control module 13 is also specifically used to execute the steps of the target load testing device executing the target load testing test case resources after the target load testing device receives the start load testing command.

[0176] Among them, the control module 13 is also used to control the S load testing devices to obtain the performance data of the load testing test case resources to be executed, to integrate the obtained performance data within the target time period, to obtain integrated performance data, and to send the obtained integrated performance data to the data aggregation module.

[0177] Data aggregation module 14 is used to aggregate the integrated performance data sent by S stress testing devices to obtain aggregated performance data;

[0178] The data aggregation module 14 is also used to store aggregated performance data in the task database and to store the task identifiers of the load testing tasks in the identifier database.

[0179] Among them, the data aggregation module 14 is also used to send the aggregation performance data to the circuit breaker detection module;

[0180] The fuse detection module 15 is used to compare the polymerization performance data with the data threshold to obtain the data comparison result.

[0181] The circuit breaker detection module 15 is also used to send a task circuit breaker message to the load test scheduling module if the data comparison result indicates that the aggregate performance data meets the circuit breaker condition, so that the load test scheduling module stops the load test task.

[0182] Among them, the data aggregation module 14 is also used to send the aggregated performance data to the load test management module;

[0183] The load testing management module 11 is also used to respond to viewing operations for the load testing report function and display aggregated performance data.

[0184] The load testing management module 11 is also used to respond to the trigger operation for the task stop function, and send a task stop command to the load testing scheduling module. The load testing scheduling module forwards the task stop command to S load testing devices; the S load testing devices include target load testing devices; the S load testing parameters include target load testing parameters corresponding to the target load testing devices.

[0185] The control module 13 is also used to control the target load testing device to return a task exit message to the load testing scheduling module if the device status of the target load testing device is idle.

[0186] The control module 13 is also used to control the target load testing device to stop executing the target load testing test case resources if the device status of the target load testing device is working, return a task stop message to the load testing scheduling module, and update the device status of the target load testing device to idle status.

[0187] The specific implementation methods of the load testing management module 11, load testing scheduling module 12, control module 13, data aggregation module 14, and circuit breaker detection module 15 can be found in the above description. Figure 3 The descriptions of steps S101-S103 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0188] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0189] Further, please see Figure 14 , Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device can be a terminal device or a server, or it can be a load testing platform device, which includes a load testing management node, a load testing scheduling node, and a load testing device cluster. Figure 14As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. In some embodiments, the user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. Optionally, the network interface 1004 may include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 14 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0190] In such Figure 14 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call computer programs stored in the memory 1005 to achieve:

[0191] The load testing management node obtains the task parameters of the load testing task and sends the task parameters to the load testing scheduling node;

[0192] The load testing scheduling node obtains S load testing devices from the load testing device cluster to execute the load testing task based on the task parameters, obtains the load testing parameters corresponding to the S load testing devices from the task parameters, and sends the S load testing parameters to the corresponding load testing devices respectively; S is a positive integer;

[0193] Each of the S load testing devices retrieves load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and executes the retrieved load testing case resources.

[0194] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 The description of the stress testing method in the corresponding embodiments can also be performed as described above. Figure 13 The description of the pressure testing device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0195] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores the computer program executed by the aforementioned pressure testing device 1. When the processor executes the computer program, it can execute the aforementioned... Figure 3 The description of the stress testing method in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0196] Furthermore, it should be noted that this application also provides a computer program product, which may include a computer program that can be stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium, and the processor can execute the computer program, causing the computer device to perform the aforementioned... Figure 3 The description of the stress testing method in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program product embodiments related to this application, please refer to the description of the method embodiments of this application.

[0197] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0198] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A pressure testing method, characterized in that, The stress testing method is executed by a stress testing platform device, which includes a stress testing management node, a stress testing scheduling node, and a stress testing device cluster. The stress testing method includes: The load testing management node obtains the task parameters of the load testing task and sends the task parameters to the load testing scheduling node; The load testing scheduling node obtains S load testing devices from the load testing device cluster to execute the load testing task according to the task parameters, obtains the load testing parameters corresponding to the S load testing devices respectively from the task parameters, and sends the S load testing parameters to the corresponding load testing devices respectively; where S is a positive integer; The S load testing devices each obtain load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and execute the obtained load testing case resources.

2. The method according to claim 1, characterized in that, The step of obtaining the task parameters for the load testing task and sending the task parameters to the load testing scheduling node includes: In response to a creation operation for the task creation function, the task creation parameters of the created load testing task are displayed; the load testing task includes N load testing test case resources; N is a positive integer. In response to the confirmation operation for the load testing task, the N load testing case resources are stored in the case database, and the storage addresses of the N load testing case resources in the case database are obtained respectively. The task parameters of the load testing task are obtained by replacing the N load testing test case resources in the task creation parameters with the N storage addresses, and the task parameters are sent to the load testing scheduling node.

3. The method according to claim 2, characterized in that, The step of obtaining S load testing devices from the load testing device cluster to perform the load testing task according to the task parameters, and obtaining the load testing parameters corresponding to the S load testing devices respectively from the task parameters, includes: Obtain the machine configuration parameters of the load testing task from the task parameters, and obtain S load testing devices from the load testing device cluster to execute the load testing task according to the machine configuration parameters; The N storage addresses in the task parameters are allocated to obtain the storage addresses corresponding to the S load testing devices; the S load testing devices are used to execute the load testing case resources corresponding to the allocated storage addresses. The execution parameters that meet the execution conditions are obtained from the task parameters, and the execution parameters and the storage addresses corresponding to the S load testing devices are determined as the load testing parameters corresponding to the S load testing devices respectively.

4. The method according to claim 3, characterized in that, The machine configuration parameters include machine type configuration parameters, region configuration parameters, and quantity configuration parameters; The step of obtaining S load testing devices from the load testing device cluster to perform the load testing task according to the machine configuration parameters includes: Obtain a load testing device with an idle state from the load testing device cluster, and obtain a load testing device that meets the model configuration parameters and the regional configuration parameters from the load testing devices with the idle state; The number of load testing devices that meet the model configuration parameters and the regional configuration parameters is matched with the quantity configuration parameters. If the number of load testing devices that meet the model configuration parameters and the regional configuration parameters is greater than or equal to the quantity configuration parameters, then S load testing devices for performing the load testing task are obtained from the load testing devices that meet the model configuration parameters and the regional configuration parameters. The method further includes: If the number of load testing devices that meet the model configuration parameters and the region configuration parameters is less than the quantity configuration parameters, then an insufficient number of devices message is sent to the load testing management node.

5. The method according to claim 1, characterized in that, The S load testing devices include target load testing devices; the S load testing parameters include target load testing parameters corresponding to the target load testing devices; the number of load testing case resources for the load testing task is N; where N is a positive integer; The S load testing devices each retrieve load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and execute the retrieved load testing case resources, including: The target load testing device retrieves the target load testing case resource corresponding to the target load testing device from the case database based on the storage address in the target load testing parameters, and determines that the target load testing device has successfully deployed the target load testing case resource; the target load testing case resource belongs to the N load testing case resources; The target load testing device executes the target load testing case resources.

6. The method according to claim 5, characterized in that, The resources for executing the target load test case include: The execution parameters in the target stress test parameters are assembled to obtain command line parameters; The command line parameters are parsed to obtain the load distribution method of the load testing task; Based on the pressure generation method, start the pressure test traffic for the pressured object in the target pressure test case resource, and send a pressure test execution status message to the pressure test scheduling node; The method further includes: When the target load test case resource has a syntax error, stop the load test traffic for the target object and send a load test failure message to the load test scheduling node.

7. The method according to claim 5, characterized in that, The method further includes: The load testing scheduling node obtains the deployment results corresponding to the S load testing devices respectively. When the deployment results corresponding to the S load testing devices indicate that the S load testing devices have successfully deployed the load testing test case resources of the load testing task, the node sends a start load testing command to the S load testing devices respectively. After the target load testing device receives the start load testing command, it executes the step of the target load testing device executing the target load testing case resources.

8. The method according to claim 1, characterized in that, The stress testing platform equipment also includes a data aggregation node; The method further includes: The S load testing devices respectively acquire the performance data of the executed load testing test cases, integrate the acquired performance data within the target time period to obtain integrated performance data, and send the obtained integrated performance data to the data aggregation node. The data aggregation node aggregates the integrated performance data sent by the S stress testing devices to obtain aggregated performance data. The data aggregation node stores the aggregated performance data in the task database and the task identifier of the load testing task in the identifier database.

9. The method according to claim 8, characterized in that, The pressure testing platform equipment also includes a fuse detection node; The method further includes: The data aggregation node sends the aggregation performance data to the circuit breaker detection node; The fracturing detection node compares the polymerization performance data with the data threshold to obtain the data comparison result. If the data comparison result indicates that the aggregate performance data meets the circuit breaker condition, the circuit breaker detection node sends a task circuit breaker message to the load test scheduling node so that the load test scheduling node stops the load test task.

10. The method according to claim 8, characterized in that, The method further includes: The data aggregation node sends the aggregated performance data to the load testing management node; The load testing management node responds to the load testing report viewing operation and displays the aggregated performance data.

11. The method according to claim 1, characterized in that, The method further includes: In response to the triggering operation of the task stop function, the load testing management node sends a task stop command to the load testing scheduling node, and the load testing scheduling node forwards the task stop command to the S load testing devices; the S load testing devices include a target load testing device; the S load testing parameters include the target load testing parameters corresponding to the target load testing device; If the target load testing device is in an idle state, the target load testing device returns a task exit message to the load testing scheduling node; If the target load testing device is in a working state, the target load testing device stops executing the target load testing case resources, returns a task stop message to the load testing scheduling node, and updates the target load testing device's device status to an idle state.

12. A pressure testing device, characterized in that, The pressure testing device is applied to a pressure testing platform equipment, which includes a cluster of pressure testing devices. The pressure testing device includes: The load testing management module is used to obtain the task parameters of the load testing task and send the task parameters to the load testing scheduling module. The load testing scheduling module is configured to obtain S load testing devices from the load testing device cluster to execute the load testing task according to the task parameters, obtain the load testing parameters corresponding to the S load testing devices respectively from the task parameters, and send the S load testing parameters to the corresponding load testing devices respectively; where S is a positive integer; The control module is used to control the S load testing devices to obtain load testing case resources for the load testing task from the case database according to the corresponding load testing parameters, and to execute the obtained load testing case resources.

13. A computer device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the computer device to perform the method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method according to any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-11.

Images