Distributed performance test method based on jmeter

Abstract

The invention relates to a distributed performance test method based on jmeter. The method comprises the following steps: S1, generating timed task execution time in batches through an excel formula; s2, based on a jmx script of a jmeter, setting a plurality of pressure measurement scenes expected to be executed according to parameters of the pressure measurement scenes; s3, traversing jmx scripts needing to be executed, and obtaining the name and the total number of the jmx scripts; s4, calculating a concurrent number needing to be executed by each jmeter press machine according to the parameters of the pressure measurement scene, circularly generating an execution command and writing the execution command into a file; s5, combining the existing timed task execution time of excel, splicing execution commands in the file in batches, and generating a spliced command file; s6, the spliced command file is uploaded to an execution jmeter press, and a command deployment timing task is executed; and S7, generating a JTL test result file named according to a rule. According to the invention, under the condition that the jmeter press does not meet the required pressure, the automatic performance test process can be completed, and the test efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software performance testing, and particularly relates to a distributed performance testing method based on jmeter. Background Art

[0002] The existing literature on the performance testing method based on Jmeter is as follows: Document 1 (CN116383025A) proposes an execution method for triggering jmeter scripts based on jenkins job scheduling; Document 2 (CN110417613A) proposes a jmeter distributed execution scheduling method; Document 3 (CN108540349A) proposes a single-client execution method and result collection method.

[0003] The existing technologies have the following defects: (1) It cannot complete the automated performance testing process and improve the testing efficiency when the required pressure is not met by a single Jmeter client; (2) It does not involve the multi-scenario execution strategy under the condition of multiple jmeter clients; (3) It does not involve the merging of test execution report data for multiple jmeter clients; (4) It does not involve the automatic interception of test execution results.

[0004] Therefore, it is necessary to provide a distributed performance testing method based on jmeter to increase the pressure concurrency by deploying multiple execution jmeter presses when the execution jmeter press does not meet the required pressure, complete the automated performance testing process, and improve the testing efficiency. Summary of the Invention

[0005] The purpose of the present invention is to provide a distributed performance testing method based on jmeter to increase the pressure concurrency by deploying multiple execution jmeter presses when the required pressure is not met by a single execution jmeter press, complete the automated performance testing process, and improve the testing efficiency.

[0006] To solve the problems existing in the prior art, the present invention provides a distributed performance testing method based on jmeter, including the following steps: S1: Batch generate the execution time of scheduled tasks through excel formulas; S2: Based on the jmx script of jmeter, set multiple expected load testing scenarios according to the parameters of the load testing scenario, and the jmx script corresponds to the load testing scenario one by one; S3: Traverse the jmx scripts to be executed, and obtain the jmx script name and total number; S4: Calculate the concurrency number of the load testing scenarios that each execution jmeter press needs to execute according to the parameters of the load testing scenario, loop to generate the execution commands for executing the jmx scripts, and write the execution commands into a file; S5: Combine the execution times of existing scheduled tasks in Excel, batch splice the execution commands in the file, and generate a spliced command file. S6: Upload the spliced command file to the JMeter executor, and the JMeter executor executes the scheduled tasks deployed by the commands in the spliced command file. S7: Generate a JTL test result file named according to the rules.

[0007] Optionally, in the distributed performance testing method based on JMeter, the stress testing scenario includes three parameters, namely: the total number of different concurrencies in the scenario, the actual number of executors set in the script, and the number of thread groups.

[0008] Optionally, in the distributed performance testing method based on JMeter, the following steps are further included: S8: Merge the test results of multiple JMeter executors and generate a qualified test result. The steps include preprocessing the JTL test result file, file merging, generating an aggregation report, and enhancing the report information.

[0009] Optionally, in the distributed performance testing method based on JMeter, in the preprocessing stage of the JTL test result file, first extract the names of all JTL test result files to be executed in the directory and store them in the jtlList file, and then process the JTL test result files. The processing method is as follows: check whether the connection time of the JTL test result file is empty. If it is empty, delete the first and last two lines of the JTL test result file. If it is not empty, delete the first line; rename the processed JTL test result file to SRC_original file name; In the file merging stage, first obtain the scenario name from the scenario list file, create a new JTL file, write the header, and append the contents of all JTL test result files named with SRC_original file name to the new JTL file according to the scenario name. In the aggregation report generation stage, use the jpgc-cmd-simple component in the JMeter plugin, generate an aggregation report by executing the JMeterPluginsCMD.sh command, and perform data cleaning on the generated CSV file. In the report information enhancement stage, first extract the time information, extract the maximum timestamp and minimum timestamp from the new JTL file and convert them into a readable time format, parse the scenario name and the number of threads from the new JTL file name, append the start time, end time, number of threads, and scenario name of the scenario to the first line of the CSV file, and at the same time save the information to the senceTime.txt file and update the header of the CSV file.

[0010] Optionally, in the JMeter-based distributed performance testing method, the following steps are further included: S9: Automatically take screenshots of the required test execution results and automatically save them in a Word document.

[0011] Optionally, in the JMeter-based distributed performance testing method, the screenshot and saving method is as follows: Generate a blank Word document through the Apache toolkit, loop through and read the scenario list file, use the JMeterPluginsCMD plugin manager to generate a trend chart scenario of the response time varying with the test time, and use the JMeterPluginsCMD plugin manager to generate a trend chart of the throughput varying with the test time; Use the Apache POI tool to add the scenario name as a subheading of the document, and add the trend chart scenario and trend chart to the blank Word document.

[0012] Optionally, in the JMeter-based distributed performance testing method, the following steps are further included: S10: Automatically generate a resource monitoring Excel file based on the test execution start time and end time in the senceTime.txt file.

[0013] Optionally, in the JMeter-based distributed performance testing method, the method for generating the resource monitoring Excel file is as follows: Obtain the test execution time, obtain the resource usage data through the Prometheus api interface, and write it into the Excel.

[0014] Optionally, in the JMeter-based distributed performance testing method, the resource usage data includes the average CPU usage rate, the average memory usage rate, and the disk I / O busy rate.

[0015] Compared with the prior art, the present invention has the following advantages: (1) In the case where a single JMeter press does not meet the required pressure, the present invention increases the pressure concurrency by deploying multiple JMeter presses, completes the automated performance testing process and improves the testing efficiency, thereby reducing manual operations and reducing the overall time-consuming of non-functional testing.

[0016] (2) In the JTL merging stage of the present invention, first obtain the scenario name from the scenario list file, and there is no limit to the number of merged files.

[0017] (3) The present invention supports multiple JMeter presses as performance testing clients, and in the case of needing to execute multiple test scenarios, quickly completes the testing process and automatically generates the relevant content of the process index data required for the test report.

[0018] (4)The performance test scenario of the present invention is automatically generated and executed by generating a timed task scenario. After execution when multiple JMeter stress machines are simultaneously applying pressure, the distributed performance test data is automatically merged, and the report screenshots are automatically generated and saved to a specified Word document, while the application resource usage data is automatically generated and stored in an Excel file. Description of the Drawings

[0019] Figure 1 It is a flowchart of the distributed performance test method provided by an embodiment of the present invention. Detailed Embodiments

[0020] The following will describe the detailed embodiments of the present invention in more detail with reference to the schematic diagrams. According to the following description, the advantages and features of the present invention will be clearer. It should be noted that the drawings are all in a very simplified form and use non-precise scales, only for conveniently and clearly assisting in explaining the purpose of the embodiments of the present invention.

[0021] Hereinafter, if the methods described herein include a series of steps, the order of these steps presented herein is not necessarily the only order in which these steps can be executed, and some of the described steps may be omitted and / or some other steps not described herein may be added to the method.

[0022] The prior art has the following defects: (1) It cannot complete the automated performance test process and improve the test efficiency when the required pressure is not met by a single JMeter client; (2) It does not involve the multi-scenario execution strategy under the condition of multiple JMeter clients; (3) It does not involve the merging of test execution report data for multiple JMeter clients; (4) It does not involve the automatic capture of test execution results.

[0023] To solve the problems existing in the prior art, the present invention provides a distributed performance test method based on JMeter. In the case of multiple JMeter stress machines, this method automatically generates timed tasks for distributed execution of multiple scenarios through Excel and shell scripts; automatically merges the test results of the JMeter stress machines through scripts to generate execution summary data; automatically captures the execution result pictures through scripts and stores them in a Word document, and automatically generates and stores the application resource usage data in an Excel file.

[0024] As Figure 1 shown, the distributed performance test method based on JMeter includes the following steps: S1: Batch generate the execution time of the timed tasks through Excel formulas; S2: Based on the jmx script of jmeter, multiple stress test scenarios to be executed are set according to the parameters of the stress test scenario, and the jmx script corresponds to the stress test scenario one by one; among them, the stress test scenario includes 3 parameters, namely: the total number of different concurrencies in the scenario, the number of stress machines actually executed set by the script, and the number of thread groups.

[0025] S3: Traverse the jmx scripts to be executed, and obtain the jmx script name and total number; S4: Calculate the concurrency number of the stress test scenario that each jmeter stress machine needs to execute according to the parameters of the stress test scenario, loop to generate the execution commands for executing the jmx script, and write the execution commands into a file; S5: Combine the existing scheduled task execution time in the excel, batch splice the execution commands in the file, and generate a spliced command file; S6: Upload the spliced command file to the jmeter stress machine, and the jmeter stress machine executes the scheduled task deployed by the commands in the spliced command file; S7: Generate a JTL test result file named according to the rules.

[0026] S8: Merge the test results of multiple jmeter stress machines and generate a test result that meets the requirements. The steps include preprocessing of the JTL test result file, file merging, generation of an aggregated report, and enhancement of report information.

[0027] Specifically, in the preprocessing stage of the JTL test result file, first extract the names of all JTL test result files to be executed in the directory and store them in the jtlList file, and then process the JTL test result file. The processing method is as follows: check whether the Connect connection time (in the 11th column of the last row) of the JTL test result file is empty. If it is empty, delete the first and last two rows (header and invalid data) of the JTL test result file. If it is not empty, delete the first row (header); the processed JTL test result file is renamed to SRC_original file name, and the original file is deleted; In the file merging stage, first obtain the scenario name from the scenario list file sceneList, create a new JTL file (for example: M_scenario name.jtl), and write the header. Append the contents of all JTL test result files named with SRC_original file name to the new JTL file according to the scenario name; In the aggregation report generation stage, use the jpgc-cmd-simple component in the JMeter plugin to generate an aggregation report by executing the JMeterPluginsCMD.sh command, and perform data cleaning on the generated CSV file; the cleaning steps include deleting the header, deleting the TOTAL row and the Chinese TOTAL row (to avoid duplicate statistics), sorting the report by sampler name, then traversing each sampler in the report, and according to the new JTL file, counting its total number of requests, number of failures, calculating the failure rate, and updating to columns 10-12 of the report. At the same time, add a summary row, calculate the total response time of all samplers, and add a TOTAL row to the end of the report.

[0028] In the report information enhancement stage, first extract time information, extract the maximum timestamp and minimum timestamp from the new JTL file and convert them to a readable time format (e.g., yyyy-MM-dd HH:mm:ss), parse the scenario name and number of threads from the new JTL file name, append the start time, end time, number of threads and scenario name of the scenario to the first row of the CSV file, and at the same time save the information to the senceTime.txt file, and update the header of the CSV file with more understandable names.

[0029] S9: Automatically take screenshots of the required test execution results and automatically save them in a word document.

[0030] Specifically, the screenshot and saving method is as follows: Generate a blank word document through the apache toolkit, loop to read the scene list file sceneLis, use the JMeterPluginsCMD plugin manager to generate a trend chart scene of the response time changing with the test time, with the naming rule of scene name_ART.png, use the JMeterPluginsCMD plugin manager to generate a trend chart of the throughput changing with the test time, with the naming rule of scene name_TPS.png; use the Apache POI tool to add the scene name as the document subtitle, and add the trend chart scene (i.e., scene name_ART.png) and the trend chart (i.e., scene name_TPS.png) to the blank word document.

[0031] S10: Based on the test execution start time and end time in the senceTime.txt file, automatically generate a resource monitoring excel file. The method of generating the resource monitoring excel file is as follows: Obtain the test execution time, obtain the resource usage data through the Prometheus api interface, and write it into the excel. The resource usage data includes the average CPU usage rate, the average memory usage rate, and the disk I / O busy rate.

[0032] In one embodiment, the method for generating a resource monitoring Excel file is as follows: First, according to the actual scenario, customize the Prometheus dashboard template, and group and classify the monitored applications through jobs; use the Apache POI tool to generate a blank Excel document; obtain the start time and end time in the senceTime.txt file as the initialization values of the jmeter data extraction script. Calculate the time difference based on the start time and end time. If the time difference is greater than 2 minutes, both the start time and the end time are advanced 1 minute to the right and left. If the time difference is less than two minutes, no processing is done and the calculation is performed directly. Call the prometheus api interface to obtain the average CPU usage rate data of the application on different instances within the interval. The calculation method is (1 - average CPU idle rate) * 100%. Extract the application name, instance name, and average CPU usage rate from the returned results; call the prometheus api interface to obtain the average memory usage rate data of the application on different instances within the interval. The calculation method is (total memory - free memory - buffer - cache) / total memory * 100%. Extract the instance name and average memory usage rate from the returned results; call the prometheus api interface to obtain the peak value of the disk I / O busy rate of the application on different instances within the interval. The calculation method is the time for the disk to process I / O / total time * 100%. Extract the instance name and disk I / O busy rate from the returned results. According to the application and IP address information, splice and sort the application name and instance IP address. Based on the sorted IP, obtain the average CPU usage rate, average memory usage rate, and disk I / O busy rate, and write the query time interval, application name and IP, average CPU usage rate, average memory usage rate, and disk I / O busy rate into the corresponding columns of the Excel.

[0033] Compared with the prior art, the present invention has the following advantages: (1) In the case where a single jmeter stress machine does not meet the required pressure, the present invention increases the pressure concurrency by deploying multiple jmeter stress machines, completes the automated performance test process and improves the test efficiency, thereby reducing manual operations and reducing the overall time-consuming of non-functional tests.

[0034] (2) In the JTL merging stage of the present invention, first obtain the scenario name from the scenario list file, and there is no limit to the number of merged files.

[0035] (3) The present invention supports multiple jmeter stress machines as performance test clients, and in the case of needing to execute multiple test scenarios, quickly completes the test process and automatically generates the relevant content of the process metrics data required for the test report.

[0036] (4)The performance test scenario of the present invention is automatically generated and executed by generating a timed task scenario. After execution, when multiple JMeter pressure machines are simultaneously applying pressure, the distributed performance test data is automatically merged, the report screenshots are automatically generated and saved to a specified Word document, and the application resource usage data is automatically generated and stored in an Excel file.

[0037] The above are only the preferred embodiments of the present invention and do not impose any limitation on the present invention. Any person skilled in the art within the technical field, without departing from the technical solution of the present invention, making any form of equivalent substitution or modification and other changes to the technical solution and technical content disclosed by the present invention, all fall within the content of the technical solution of the present invention and still belong to the protection scope of the present invention.

Claims

1. A distributed performance testing method based on JMeter, characterized in that, It includes the following steps: S1: Batch generate the execution time of scheduled tasks through excel formulas; S2: Based on the jmx script of jmeter, set multiple stress test scenarios to be expected according to the parameters of the stress test scenario, and the jmx script corresponds to the stress test scenario one by one; S3: Traverse the jmx scripts to be executed, and obtain the jmx script name and total number; S4: Calculate the concurrency number of the stress test scenarios that each jmeter stress machine needs to execute according to the parameters of the stress test scenario, loop to generate the execution commands for executing the jmx script, and write the execution commands into a file; S5: Combine the existing scheduled task execution time in excel, batch splice the execution commands in the file, and generate a spliced command file; S6: Upload the spliced command file to the jmeter stress machine, and the jmeter stress machine executes the scheduled tasks deployed by the commands in the spliced command file; S7: Generate JTL test result files named according to rules.

2. The distributed performance testing method based on jmeter according to claim 1, wherein The stress test scenario includes 3 parameters, namely: the total number of different concurrencies in the scenario, the actual number of stress machines set in the script, and the number of thread groups.

3. The distributed performance testing method based on jmeter according to claim 1, characterized in that, It also includes the following steps: S8: Merge the test results of multiple jmeter stress machines and generate test results that meet the requirements. The steps include preprocessing of JTL test result files, file merging, generation of aggregation reports, and enhancement of report information.

4. The distributed performance testing method based on jmeter according to claim 3, characterized in that In the preprocessing stage of JTL test result files, first extract the names of all JTL test result files to be executed in the directory and store them in the jtlList file, and then process the JTL test result files. The processing method is as follows: check whether the connection time of the JTL test result file is empty. If it is empty, delete the first and last two lines of the JTL test result file. If it is not empty, delete the first line; rename the processed JTL test result file to SRC_original file name; In the file merging stage, first obtain the scenario name from the scenario list file, create a new JTL file, and write the header. Append the content of all JTL test result files named with SRC_original file name to the new JTL file according to the scenario name; In the stage of generating aggregation reports, use the jpgc-cmd-simple component in the JMeter plugin, generate an aggregation report by executing the JMeterPluginsCMD.sh command, and perform data cleaning on the generated CSV file; In the stage of enhancing report information, first extract time information, extract the maximum timestamp and minimum timestamp from the new JTL file and convert them into a readable time format, parse the scenario name and number of threads from the new JTL file name, append the start time, end time, number of threads and scenario name of the scenario to the first line of the CSV file, and at the same time save the information to the senceTime.txt file and update the header of the CSV file.

5. The distributed performance testing method based on jmeter according to claim 4, characterized in that, It also includes the following steps: S9: Automatically take screenshots of the required test execution results and automatically save them in a word document.

6. The distributed performance testing method based on jmeter according to claim 5, wherein The screenshots and the way of preservation are as follows: By using the apache toolkit, a blank word document is generated, the scenario list file is read cyclically, the JMeterPluginsCMD plugin manager is used to generate a trend chart scenario of the response time varying with the test time, and the JMeterPluginsCMD plugin manager is used to generate a trend chart of the throughput varying with the test time; The Apache POI tool is used to add the scenario name as the document subtitle, and add the trend chart scenario and the trend chart to the blank word document.

7. The distributed performance testing method based on jmeter according to claim 4, characterized in that It further includes the following steps: S10: Based on the test execution start time and end time in the senceTime.txt file, an automatic resource monitoring excel file is generated.

8. The distributed performance testing method based on jmeter according to claim 7, characterized in that The way of generating the resource monitoring excel file is as follows: Obtain the test execution time, obtain the resource usage data through the Prometheus api interface, and write it into the excel.

9. The distributed performance testing method based on jmeter according to claim 8, characterized in that The resource usage data includes the average CPU usage rate, the average memory usage rate, and the disk I / O busy rate.

Images