A method and system for automatically building a stress measurement service model

Abstract

The application relates to a method and system for automatically constructing a stress test service model, and belongs to the field of software testing. The method collects and analyzes log information of a tested service by constructing a log collection platform and a log aggregation and analysis platform, obtains hourly service call distribution information and daily service call distribution information of the tested service in a first preset time period, and aggregates and calculates an average call volume model M1 in hourly units. Meanwhile, the highest call volume model M2 and the model M3 with the largest call volume difference are aggregated and calculated in daily units. The model M2, the model M3 and the average call volume model M1 are combined to respectively calculate the service TPS structure with the highest call volume and the service TPS structure with the largest call volume difference, and the TPS proportion of each service is configured in a stress test script. The application enables a tester to obtain an actual production service model, accurately specify the TPS distribution of a corresponding service, and simulate a stress test scene conforming to the actual production situation.

Description

Technical Field

[0001] This application belongs to the field of software testing, specifically relating to a method and system for automatically constructing a load testing business model. Background Technology

[0002] Stress testing, also known as performance testing, involves establishing a performance testing model for the system's performance metrics, developing a performance testing plan, executing performance scenarios under specific conditions, analyzing and identifying performance bottlenecks, optimizing the system, and ultimately obtaining performance results to evaluate whether the system's performance metrics meet predetermined values.

[0003] Current performance testing processes focus only on the performance of individual service interfaces. Testing only considers whether the performance of a few interfaces meets the standards, and most of the testing is conducted offline, where machine configurations may differ between online and offline environments, and various different services may be running simultaneously online. However, a system service typically provides multiple interfaces, and these interfaces have a specific call ratio structure. If testers cannot obtain the most realistic system business model, they lack a reliable model basis for load testing and cannot accurately allocate the system's TPS (transactions per second). Summary of the Invention

[0004] Therefore, this application provides a method and system for automatically constructing a load testing business model, which helps to solve the problem that existing performance load testing processes cannot obtain the real business model of the system in order to accurately allocate the system's TPS.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, this application provides a method for automatically constructing a load testing business model, including:

[0007] A log collection platform was built using log analysis tools and a distributed search engine, and the log information of the service under test was collected using the log collection platform.

[0008] A log aggregation and parsing platform was built using Python technology.

[0009] The log aggregation and parsing platform calls the interface of the log collection platform, requests log information and parses it to obtain the hourly business call distribution information of the tested service within the first preset time period, and aggregates and calculates the hourly average call volume model M1 on an hourly basis.

[0010] Further analysis of the log information yields the daily business call distribution information of the tested service within the first preset time period, and the model M2 with the highest call volume and the model M3 with the largest difference in call volume are aggregated and calculated on a daily basis.

[0011] By combining the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1, the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume can be calculated.

[0012] Based on the TPS structure of the business with the highest call volume and the business with the largest difference in call volume, configure the TPS ratio of each business in the load testing script.

[0013] Furthermore, the log information specifically refers to the number of service calls per second for all services in the tested service.

[0014] Furthermore, the request log information is parsed to obtain the hourly business call distribution information of the service under test within a first preset time period, and the hourly average call volume model M1 is calculated by aggregating the data on an hourly basis. Specifically, this includes:

[0015] The log aggregation and parsing platform reads the business call distribution information of all services of the service under test within the first preset time period. Through data statistics and calculation, it outputs the hourly business call volume of all services of the service under test within the first preset time period. Within the first preset time period, the hourly business call volume of each service in the service under test is aggregated and calculated separately on an hourly basis to obtain the hourly average call volume of each service. The proportion of the hourly average call volume of each service is used as the average call volume model M1 of the service under test.

[0016] Furthermore, the step of further parsing the log information to obtain the daily business call distribution information of the tested service within the first preset time period, and aggregating and calculating the model M2 with the highest call volume and the model M3 with the largest difference in call volume on a daily basis, specifically includes:

[0017] Based on the business call distribution information of all services of the service under test within the first preset time period, the daily business call volume of each service of the service under test within the first preset time period is obtained through data statistics and calculation. On a daily basis, the total daily business call volume of all services within the first preset time period and the daily business call volume difference between each service are aggregated and calculated. The proportion of business call volume of all services on the day with the highest total business call volume is taken as the model with the highest call volume M2, and the proportion of business call volume of all services on the day with the largest difference in business call volume is taken as the model with the largest difference in call volume M3.

[0018] Furthermore, the step of combining the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume specifically includes:

[0019] Based on the average call volume model M1, the general TPS value of the tested service is calculated.

[0020] Based on model M2 with the highest call volume, the percentage of each service's total call volume on the day with the highest call volume is calculated in each hour, thus obtaining the service TPS ratio of model M2. At the same time, based on the service call volume at the time node where the service peak occurs on the day, the peak TPS of model M2 is calculated. The general TPS value, the service TPS ratio of model M2, and the peak TPS are used as the TPS structure of the service with the highest call volume.

[0021] Based on model M3 with the largest call volume difference, the percentage of each service's call volume difference on the day with the largest difference is calculated in each hour, thus obtaining the service TPS ratio of model M3. At the same time, based on the service call volume at the time node where the service peak occurs on the day, the peak TPS of model M3 is calculated. The general TPS value, the service TPS ratio of model M3, and the peak TPS are used as the TPS structure of the service with the largest call volume difference.

[0022] Secondly, this application provides a system for automatically constructing a load testing business model, comprising:

[0023] A log collection platform used to collect log information from the service under test.

[0024] The log aggregation and parsing platform is used to request log information and parse it to obtain hourly and daily business call distribution information of the tested service within a first preset time period. It then aggregates and calculates the average call volume model M1, the model with the highest call volume M2, and the model with the largest call volume difference M3. Finally, it combines the model with the highest call volume M2 and the model with the largest call volume difference M3 with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest call volume difference.

[0025] The TPS ratio configuration module is used to configure the TPS ratio of the service under test in the load testing script based on the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume.

[0026] The application employs the above technical solution and has at least the following beneficial effects:

[0027] This application provides a method for automatically constructing a load testing business model. The method employs log analysis tools and a distributed search engine to build a log collection platform, which collects log information from the service under test. A log aggregation and parsing platform is built using Python technology. This platform calls the log collection platform's interface to request and parse log information, obtaining hourly business call distribution information for the service under test within a first preset time period. The average hourly call volume model M1 is then calculated. Further parsing of the log information yields daily business call distribution information for the service under test within the first preset time period. The model with the highest call volume (M2) and the model with the largest call volume difference (M3) are then calculated on a daily basis. These two models are combined with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest call volume difference. Based on these two TPS structures, the TPS ratio for each business is configured in the load testing script. This application collects and analyzes log information from the service under test, and performs aggregation calculations based on the analysis results to obtain the average call volume model M1, the model with the highest call volume M2, and the model with the largest difference in call volume M3. This allows testers to obtain the actual business model in production, solving the problem that current load testers cannot understand the specific business model. Then, by calculating the TPS structure of the business with the highest call volume and the business with the largest difference in call volume, load testing scripts are used to accurately specify the TPS allocation for the corresponding business, simulating load testing scenarios that conform to actual production conditions.

[0028] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0030] Figure 1 This is a flowchart illustrating a method for automatically constructing a load testing business model according to an exemplary embodiment;

[0031] Figure 2 This is a system schematic diagram illustrating an automatic construction of a load testing service model, according to an exemplary embodiment.

[0032] Figure 3This is a flowchart illustrating the operation of a system for automatically building a load testing business model, according to an exemplary embodiment. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] Business model research is a crucial step before performance testing. A complete business model accurately reflects production business conditions. Only when the model aligns with actual production operations can performance test results truly and effectively reflect the actual performance of the production system. Analyzing historical production data can determine the proportion of various business volumes within the overall system load, ultimately aiming to establish a business model of the actual operation of the production application system.

[0035] This system uses Python to automatically build business models, supplemented by human analysis, to determine the actual production load testing model for the current service. Testers can use this model to allocate load testing traffic. The human analysis mainly relies on charts generated at various stages using Python's office automation functions, and the main Python libraries involved are openpyxl (for handling Excel files) and requests (for API calls).

[0036] Please see Figure 1 , Figure 1 This is a flowchart illustrating the steps of an automatic method for constructing a load testing business model, according to an exemplary embodiment. Figure 1 As shown, the method includes the following steps:

[0037] S1: Build a log collection platform using log analysis tools and a distributed search engine, and use the log collection platform to collect log information of the service under test;

[0038] S2: A log aggregation and parsing platform built using Python technology;

[0039] S3: The log aggregation and parsing platform calls the interface of the log collection platform, requests log information and parses it to obtain the hourly business call distribution information of the tested service within the first preset time period, and aggregates and calculates the hourly average call volume model M1 on an hourly basis.

[0040] S4: Further analyze the log information to obtain the daily business call distribution information of the tested service within the first preset time period, and aggregate and calculate the model M2 with the highest call volume and the model M3 with the largest difference in call volume on a daily basis.

[0041] S5: Combine the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume.

[0042] S6: Based on the TPS structure of the business with the highest call volume and the business with the largest difference in call volume, configure the TPS ratio of each business in the load testing script.

[0043] TPS stands for Transactions Per Second, which measures the number of transactions processed per second. A transaction refers to the process of a client sending a request to a server and the server responding. In server-side interface performance testing, a transaction can be understood as a single interface call. Therefore, TPS is essentially how many interface calls the server processes per second. A higher TPS indicates better processing capabilities and performance of the server-side application.

[0044] In practice, this application uses the log analysis tool Logstash and the distributed search engine Elasticsearch to build a log collection platform to collect log information from the service under test. Logstash is a tool for collecting, analyzing, and filtering logs. It supports almost any type of log, including system logs, error logs, and custom application logs. Elasticsearch is an open-source distributed search engine that provides three main functions: data collection, analysis, and storage. Its features include: distributed architecture, zero configuration, automatic discovery, automatic index sharding, index replication mechanism, RESTful API, multiple data sources, and automatic search load balancing.

[0045] Furthermore, in one embodiment, the log information specifically refers to the number of service calls per second for all services in the service under test. The first preset time period can be set to 15 days, or it can be set according to its own load testing needs.

[0046] Further, in one embodiment, the request log information is parsed to obtain the hourly business call distribution information of the service under test within a first preset time period, and the hourly average call volume model M1 is calculated by aggregating the data on an hourly basis. This specifically includes:

[0047] S31: The log aggregation and parsing platform reads the business call distribution information of all services under test within a first preset time period. Through data statistics and calculations, it outputs the hourly business call volume of all services under test within the first preset time period, i.e., an hourly chart of business call volume over 15 days. The business call distribution information is generally presented as a business call distribution chart, which is generated by the log aggregation and parsing platform requesting log information from the log collection platform. It automatically identifies representative time points and performs in-depth analysis to derive specific business models. The log collection platform uses Logstash and ElasticSearch as basic components to collect business call volume log information from the system or the service under test.

[0048] S32: Within the first preset time period, the hourly call volume of each service in the tested service is aggregated and calculated in hours to obtain the hourly average call volume of each service. The proportion of the hourly average call volume of each service is used as the average call volume model M1 of the tested service, which is a general model based on hourly distribution.

[0049] Furthermore, in one embodiment, the step of further parsing the log information to obtain the daily business call distribution information of the service under test within a first preset time period, and aggregating and calculating the model M2 with the highest call volume and the model M3 with the largest difference in call volume on a daily basis, specifically includes:

[0050] S41: Based on the business call distribution information of all services of the service under test within the first preset time period, i.e. the business call volume log information of the service under test, the daily business call volume of each service of the service under test within the first preset time period is obtained through data statistics and calculation, i.e., the dimension chart of each day within 15 days.

[0051] S42: On a daily basis, aggregate and calculate the total number of business calls for all services and the difference in the number of business calls between each service on a daily basis within the first preset time period; use the proportion of the number of business calls of all services on the day with the highest total number of business calls as the model with the highest number of calls M2, and use the proportion of the number of business calls of all services on the day with the largest difference in the number of business calls as the model with the largest difference in the number of calls M3.

[0052] Furthermore, in one embodiment, the step of combining the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume specifically includes:

[0053] S51: Based on the average call volume model M1, calculate the general TPS value of the service under test. The general TPS value is applicable to performance stress testing in general business scenarios. For example, if the total business call volume of the service under test on a certain day is 386,000,000, the corresponding general TPS value is calculated as follows: TPS = 386,000,000 / (24 * 3600) = 4467. That is to say, in general business scenarios, the TPS value should not be lower than 4467.

[0054] S52: Based on model M2 with the highest call volume, calculate the percentage of each service's total call volume on the day with the highest call volume, and obtain the service TPS ratio of model M2.

[0055] S53: Based on the business call volume at the time node where the business peak occurs on the day, calculate the TPS peak of model M2, and use the ratio of the general TPS value to the business TPS of model M2 and the TPS peak as the business TPS structure with the highest call volume.

[0056] S54: Based on model M3 with the largest difference in call volume, calculate the percentage of each service's total call volume in each hour on the day with the largest difference in call volume, and obtain the service TPS ratio of model M3; at the same time, calculate the peak TPS of model M3 based on the service call volume at the time node where the peak of the service is located on the day; use the general TPS value, the service TPS ratio of model M3, and the peak TPS as the TPS structure of the service with the largest difference in call volume.

[0057] In practice, when the aggregated calculation shows the day with the highest total number of calls to the tested service or the day with the largest difference in call volume, a detailed analysis of the business on that day is required, outputting the hourly business call data for that day. For example, the tested service includes four services: Service 1, Service 2, Service 3, and Service 4. The peak business volume occurs at 00:00, with a total call volume of 31,103,971, and the call volume ratio for each service is 0:0.43:0.01:0.56. However, it's worth noting that at 23:00, the call volume is also relatively high, with a total call volume of 28,885,649. But the call volume ratio for this hour is completely different from that at 00:00, at 0.01:0.05:0.01:0.93. Under such business scenarios, the performance consumption of the service on the machine is completely different, so this time point can also be used as an analysis object. The specific calculation process for the TPS peak at these two time points is as follows:

[0058] 23:00 TPS: Based on the business call volume at 23:00, we calculate: TPS = 28,885,649 / 3,600 = 8,023. This means that in a 23:00 business scenario, the TPS value cannot be lower than 8,023.

[0059] 00:00 TPS: Based on the business call volume at 00:00, we calculate: TPS = 31103971 / 3600 = 8639. This means that in a business scenario at 00:00, the TPS value cannot be lower than 8639.

[0060] Based on the general TPS values ​​mentioned above, we can derive the business model for the corresponding time points. For example, at 11 PM and 12 AM, although the TPS values ​​are not much different, the proportion of business calls is very different. Under these two business models, the consumption of system resources will be completely different. Therefore, when designing the entire load testing business model, it is necessary to include these two scenarios.

[0061] Therefore, for the 23-point business model, TPS > 8639; the TPS allocation ratio for each business is as follows:

[0062] Business 1 -> 1%, Business 2 -> 5%, Business 3 -> 1%, Business 4 -> 93%.

[0063] For the business model at 00:00, the TPS is greater than 8023; the TPS allocation ratio for each business is as follows:

[0064] Business 1 -> 0%, Business 2 -> 43%, Business 3 -> 1%, Business 4 -> 56%.

[0065] This application analyzes and summarizes data from multiple dimensions to obtain a business TPS distribution that is more consistent with the production scenario. This allows for targeted business allocation during load testing, enabling our load testing to more effectively reflect the overall service performance bottlenecks.

[0066] Reference Figure 2 As shown, this application provides a system for automatically constructing a load testing business model, comprising:

[0067] A log collection platform used to collect log information from the service under test.

[0068] The log aggregation and parsing platform is used to request log information and parse it to obtain hourly and daily business call distribution information of the tested service within a first preset time period. It then aggregates and calculates the average call volume model M1, the model with the highest call volume M2, and the model with the largest call volume difference M3. Finally, it combines the model with the highest call volume M2 and the model with the largest call volume difference M3 with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest call volume difference.

[0069] The TPS ratio configuration module is used to configure the TPS ratio of the service under test in the load testing script based on the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume.

[0070] Reference Figure 3 As shown, the operation flow of the system in this application is as follows:

[0071] 1. The log aggregation and parsing platform (Parse System) calls the log collection platform (Log System) interface to request and parse the required log information to obtain the business call distribution map for each hour over 15 days. The average call volume model M1 (i.e., the general model) is calculated by aggregating the data on an hourly basis.

[0072] 2. Further analysis yields the business call distribution map for each day within 15 days. Using days as the unit, aggregate calculations result in two models: the business model M2 for the day with the highest call volume within 15 days and the business model M3 for the day with the largest difference in call volume among various business lines within 15 days.

[0073] 3. The TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume are calculated by combining M2 and M3 with the M1 model.

[0074] 4. Testers configure the TPS ratio in the load testing script based on the calculated TPS structure.

[0075] This application calculates business model analysis charts for each time dimension based on the actual production traffic, solving the problem that current load testers cannot understand the specific business model. This allows testers to obtain the actual production business model, specify the TPS ratio allocation for the corresponding business, and simulate load test scenarios that conform to the actual production situation.

[0076] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0077] Any process or method description in the flowchart or otherwise herein can be understood as: representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0078] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0079] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0080] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0081] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for automatically constructing a load testing business model, characterized in that, include: A log collection platform was built using log analysis tools and a distributed search engine, and the log information of the service under test was collected using the log collection platform. A log aggregation and parsing platform was built using Python technology. The log aggregation and parsing platform calls the interface of the log collection platform, requests log information and parses it to obtain the hourly business call distribution information of the tested service within the first preset time period, and aggregates and calculates the hourly average call volume model M1 on an hourly basis. Further analysis of the log information yields the daily business call distribution information of the tested service within a first preset time period. The model M2 with the highest call volume and the model M3 with the largest call volume difference are then aggregated and calculated on a daily basis. The model M3 with the largest call volume difference is calculated as follows: the daily business call volume difference between various services within the first preset time period is aggregated and calculated on a daily basis, and the proportion of business call volume of all services on the day with the largest business call volume difference is used as the model M3 with the largest call volume difference. By combining the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1, the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume can be calculated. Based on the TPS structure of the business with the highest call volume and the business with the largest difference in call volume, configure the TPS ratio of each business in the load testing script.

2. The method for automatically constructing a load testing business model according to claim 1, characterized in that, The log information specifically refers to the number of service calls per second for all services in the service under test.

3. The method for automatically constructing a load testing business model according to claim 1, characterized in that, The request log information is parsed to obtain the hourly business call distribution information of the tested service within a first preset time period, and the hourly average call volume model M1 is calculated by aggregating the information on an hourly basis. Specifically, this includes: The log aggregation and parsing platform reads the business call distribution information of all services of the service under test within the first preset time period. Through data statistics and calculation, it outputs the hourly business call volume of all services of the service under test within the first preset time period. Within the first preset time period, the hourly business call volume of each service in the service under test is aggregated and calculated separately on an hourly basis to obtain the hourly average call volume of each service. The proportion of the hourly average call volume of each service is used as the average call volume model M1 of the service under test.

4. The method for automatically constructing a load testing business model according to claim 1, characterized in that, The further analysis of log information to obtain the daily business call distribution information of the tested service within a first preset time period, and the aggregation and calculation of the model M2 with the highest call volume on a daily basis, specifically includes: Based on the business call distribution information of all services of the service under test within the first preset time period, the daily business call volume of each service of the service under test within the first preset time period is obtained through data statistics and calculation. On a daily basis, the total daily business call volume of all services within the first preset time period and the difference in daily business call volume between each service are aggregated and calculated. The proportion of business call volume of all services on the day with the highest total business call volume is used as the model M2 with the highest call volume.

5. The method for automatically constructing a load testing business model according to claim 1, characterized in that, The step of combining the model M2 with the highest call volume and the model M3 with the largest difference in call volume with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume specifically includes: Based on the average call volume model M1, the general TPS value of the tested service is calculated. Based on model M2 with the highest call volume, the percentage of each service's total call volume on the day with the highest call volume is calculated in each hour, thus obtaining the service TPS ratio of model M2. At the same time, based on the service call volume at the time node where the service peak occurs on the day, the peak TPS of model M2 is calculated. The general TPS value, the service TPS ratio of model M2, and the peak TPS are used as the TPS structure of the service with the highest call volume. Based on model M3 with the largest call volume difference, the percentage of each service's call volume difference on the day with the largest difference is calculated in each hour, thus obtaining the service TPS ratio of model M3. At the same time, based on the service call volume at the time node where the service peak occurs on the day, the peak TPS of model M3 is calculated. The general TPS value, the service TPS ratio of model M3, and the peak TPS are used as the TPS structure of the service with the largest call volume difference.

6. A system for automatically constructing a load testing business model, characterized in that, include: A log collection platform used to collect log information from the service under test. The log aggregation and parsing platform is used to request and parse log information to obtain hourly and daily business call distribution information of the tested service within a first preset time period. It then aggregates and calculates the average call volume model M1, the model with the highest call volume M2, and the model with the largest call volume difference M3. Finally, it combines the model with the highest call volume M2 and the model with the largest call volume difference M3 with the average call volume model M1 to calculate the business TPS structure with the highest call volume and the business TPS structure with the largest call volume difference. The calculation method for the model with the largest call volume difference M3 includes: aggregating and calculating the daily business call volume difference between various services within the first preset time period on a daily basis, and using the proportion of business call volume of all services on the day with the largest business call volume difference as the model with the largest call volume difference M3. The TPS ratio configuration module is used to configure the TPS ratio of the service under test in the load testing script based on the business TPS structure with the highest call volume and the business TPS structure with the largest difference in call volume.

Images