In jmeter, there is a component that always exudes its dazzling light, so that every time I encounter the case design of a certain test plan, it always reminds me of it
It is logic_controllers
Of course, it is not just a component, but a collection of a series of logic controllers
In my opinion, if the code has a design pattern, it can become beautiful and elegant
So after jmeter has a logic controller, jmeter is not just a performance testing tool
By combining various logic controllers, jmeter can also become very attractive without losing its soul
Let’s take a small example to enter the world of jmeter logic controller together
Load request list from csv
When there are many interfaces to be tested and you want to import them through external files, you can read them through csv.
Here, a simple test csv template is taken as an example to demonstrate how to use the csv config, if controller, and loop controller components in jmeter to implement a more general request template.
Knowledge points
- csv data set config
- logic controller
- if controller
- loop controller
Implementation steps
Suppose the content of the interface csv file you want to import is as follows:
| reqName | method | url | param |
|---|---|---|---|
| getUserInfo | get | user/info/ | |
| updateUserInfo | post | user/update | age=28 |
That is, a csv file like this:
In jmeter, it can be loaded through the loop controller and csv data set config in the controller.
Add a [csv data set config] under [Config Element] in [Thread Group], as shown below.
Then fill in the path of the csv file to be read, and configure the variable name to be read in each column.
Then add a loop controller (Loop Controller), and put the csv data set config added above under this Loop Controller, so as to loop the data of each line of csv.
Then add two if controllers to handle GET requests and POST requests respectively.
Fill in the js expression in the corresponding if controller, such as filling in the GET request:
“${method}” == “get”
Fill in the POST request:
“${method}” == “post”
Then add the corresponding request http request under the respective if controller.
Among them, the configuration information of the http request is filled in through the application of variables. Take the http post request as an example, its configuration is as follows:
Then modify the number of cycles in the loop controller. If there are two data in excel here, fill in the number of cycles as 2, and then click Run to see the running results
beanshell processor big killer
Someone once said: If you don’t know the beanshell processor, you don’t really use jemeter. Personally, that sentence still makes sense.
Take the above example of reading the interface from csv as an example, let’s briefly talk about the feelings:
The above automation of reading request data from csv always feels a bit tasteless, mainly because if the number of data items in csv changes every time it runs, you need to manually modify the number of cycles in the loop controller, which feels a bit semi-automated .
If the program can automatically fill in the number of cycles according to the number of rows in the csv, then it can be truly automated. In order to solve this problem, you can use the beanshell processor to solve this problem.
For more information about beanshell, go to its official website: http://www.beanshell.org
Dynamically get the number of rows of the csv file
Here we take the above case of reading csv files as an example to improve the above example.
Add a BeanShell PreProcessor in jmeter to get the number of specific use cases in csv
Fill in the BeanShell code you want to process in the script:
String testCaseCsvPath = "D:/temp/reqTest.csv";
System.out.println("----->testCaseCsvPath=" + testCaseCsvPath);
BufferedReader br = new BufferedReader(new FileReader(testCaseCsvPath));
String line;
Integer lineCount = 0;
while ((line = br. readLine()) != null) {
lineCount++;
}
vars. put("testCaseCount",(lineCount-1) + "");
log.info("------>>>testCaseCount:{}",(lineCount-1));
br. close();
In the above code, testCaseCount is the number of extracted use cases
When writing beanshell code, in order to facilitate coding, you can first develop it in the development tool and then copy it in
TIPS: The reason why vars and log can be used directly in the above code is because they are built-in variables in jmeter’s beanshell
For more beanshell applications in jmeter, you can view the official examples: https://jmeter.apache.org/usermanual/component_reference.html#BeanShell_Sampler
When you have the beanshell’s definition of variables in jmeter, you can directly use the variables defined by the beanshell above in other places
As here, use this variable in the loop count of the loop controller, fill in: ${testCaseCount}, and then run the test case.
For the convenience of observation, a log is also added to the beanshell, and a Debug Sampler can also be added to view the variable information at runtime.
The overall running results are as follows:
By looking at the processing result tree and log information, we can see that the automatic extraction of the number of csv rows is indeed implemented.
Of course, as stated in the article “Quickly Mastering jmeter (1) – Realizing Automatic Login and Dynamic Variables”, it is not recommended to run the test cases directly in the gui for actual testing, and it is recommended to use the command line for formal testing. The running amount of the test case~