content
3. Develop an Advanced Web Testing Plan
1 Introduction
In the previous article, Brother Zhonghong has introduced his theoretical knowledge. In this article, Brother Hong will take you step by step to put the theoretical knowledge introduced in the previous article into practice, and then talk about how to create an advanced web test plan.
2. Network plan actual combat
Through the study of the previous article, Brother Hong classified it as:
(1) It can be operated without logging in to verify the identity.
(2) You need to log in to verify your identity before you can operate.
2.1 No login required
Here, Brother Hong takes the blog garden as an example. For example, in the blog garden, you can read, find and browse the articles in the blog garden without logging in to verify your identity (provided that these articles are not set to "only allow registered users to access"" ).
2.1.1 Capture packets
1. I have written in my previous articles, you can search on my homepage
2. The fiddler packet capture tool crawls the blog garden search process. From the red circled part in the figure below, you can see the URL of the search and the parameters sent by the request to search. As shown below:
2.1.2 Reading articles
According to the parameters captured by the packet capture, our next step is to use Jmeter to simulate and search in my homepage
1. Create a test plan named: Test Blog Read Plan. As shown below:
2. Select the test plan, add a thread group user and name it: Blog User. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! Brother Hong, this is to be read once by one user. If you want to stress test, you can set multiple users to read at the same time.
3. Select the thread group and add an HTTP Header Manager (HTTP header manager). This is mainly to avoid the error of status code 403 in the returned result after Jmeter sends the request. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! Here, the HTTP header manager mainly adds a parameter User-Agent. You can fill in the header according to the header you captured.
4. Select the thread group, set an http, send the default request value of http, and put it in the address you need to test. The advantage of this is that you no longer need to write this test address repeatedly for all subsequent http requests. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! The Jenkins application built by Hongge locally, then the test address is very clear, and the request value here is filled in as follows:
(1) Protocol (protocol: http or https): At present, the blog park is https protocol, so fill in Protocol here: https
(2) The test address is: the address of the blog garden, no need to be verbose, everyone knows it, Sever Name or IP: www.cnblogs.com
(3) Port: (Blog Park has no port)
5. Select the thread group and add an http request named: Read. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! The Jenkins application built locally by Brother Hong, then the Read request value, we can see that we have captured the login request package ( 2.2.1 ), and the request value here is filled in as follows:
(1) Protocol (protocol: http or https): Currently this is a locally built http protocol, so fill in Protocol here: https
(2) The test address is: local build, no need to be verbose, everyone knows it, Sever Name or IP: www.cnblogs.com
(3) Port: (Blog Park has no port)
(4) Method: Choose that type of request, choose get here
(5) Path: The request path for reading blog garden articles
(6) Content Encoding: Encoding Macro is not filled in here. If there are garbled characters, you can fill in utf-8 and Gb2312 and try it out.
6. Select the thread group, add a result tree, name it: Check Read Results, and monitor whether the reading of the blog post is successful. As shown below:
2.2 Login required
Similarly, here is an example of a blog garden. If you want to publish a series of operations such as essays, comments, and recommendations, you need to log in and verify your identity before you can perform these operations. However, due to the change of the login mechanism of the blog garden, Brother Hong does not take the blog garden as an example. Brother Hong takes one, and the web application of Jenkins built by Brother Hong locally is used to fight and delete a job. However, the job must be deleted after logging in. If there is no login, the deletion will fail.
2.2.1 Capture packets
1. Login
1. Log in to Jenkins on the browser, enter the account and password, and click Login. As shown below:
2. The fiddler package capture tool captures the process of jenkins login. From the part circled in red in the figure below, you can see the login URL and the parameters sent to request the login. As shown below:
2. Delete
1. We mentioned before that after logging in to create a new task, you can continue to operate: delete the newly created task. As shown below:
2. Use fiddler to capture the packet, and capture the request to delete the new task. From the packet capture result, it can be seen that the data parameter passed is Jenkins-Crumb. As shown below:
3. Where did this Jenkins-Crumb come from? You can see the body of the previous request. As shown below:
2.2.2 Login
According to the parameters captured by the packet capture, our next step is to use Jmeter to simulate logging in to Jenkins.
1. Create a test plan named: Test Jenkins Plan. As shown below:
2. Select the test plan, add a thread group user, and name it: Jenkins User. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! Brother Hong, this is one user login once. If you want to stress test, you can set up multiple users to log in at the same time.
3. Select the thread group and add an HTTP Header Manager (HTTP header manager). This is mainly to avoid the error of status code 403 in the returned result after Jmeter sends the request. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! Here, the HTTP header manager mainly adds two parameters User-Agent and Content-Type. You can fill in the header according to the header you captured.
4. Select the thread group, set an http, send the default request value of http, and put it in the address you need to test. The advantage of this is that you no longer need to write this test address repeatedly for all subsequent http requests. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! The Jenkins application built by Hongge locally, then the test address is very clear, and the request value here is filled in as follows:
(1) Protocol (protocol: http or https): Currently this is a locally built http protocol, so fill in Protocol here: http
(2) The test address is: local build, no need to be verbose, everyone knows, Sever Name or IP: localhost
(3) Port: 8080 (the default port 8080 built by Hongge here, you can also modify this port in the Tomcat configuration file)
5. Select the thread group and add an http request named: Login. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! The Jenkins application built locally by Brother Hong, then the value of the Login request, we can see that the login request package ( 2.2.1 ) is captured. The request value here is filled in as follows:
(1) Protocol (protocol: http or https): Currently this is a locally built http protocol, so fill in Protocol here: http
(2) The test address is: local build, no need to be verbose, everyone knows, Sever Name or IP: localhost
(3) Port: 8080 (the default port 8080 built by Hongge here, you can also modify this port in the Tomcat configuration file)
(4) Method: choose that type of request, here choose post
(5) Path: The request path for login
(6) Content Encoding: Encoding Macro is not filled in here. If there are garbled characters, you can fill in utf-8 and Gb2312 and try it out.
6. Select the thread group and add a cookie manager to manage cookies after login. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! Add a value to the cookie, which can also be viewed in the header of the packet capture login request. Brother Hong will not go into details here.
（1）Name：JSESSIONID
(2) Value: a string of numbers and letters
（3）Domain：localhost
7. Select the thread group, add a result tree named: Check Login Results, monitor whether the login is successful. As shown below:
8. Select the thread group and add an http request named: Delete Item. As shown below:
Note: Knock on the skull, knock on the blackboard! ! ! The Jenkins application built locally by Brother Hong, then the Delete request value, we can see that the delete request package ( 2.2.1 ) is very clear. Here the request value is filled in as follows:
(1) Protocol (protocol: http or https): Currently this is a locally built http protocol, so fill in Protocol here: http
(2) The test address is: local build, no need to be verbose, everyone knows, Sever Name or IP: localhost
(3) Port: 8080 (the default port 8080 built by Hongge here, you can also modify this port in the Tomcat configuration file)
(4) Method: choose that type of request, here choose post
(5) Path: Deleted request path
(6) Content Encoding: Encoding Macro is not filled in here. If there are garbled characters, you can fill in utf-8 and Gb2312 and try it out.
9. Select the thread group, add a result tree named: Check Delete Results, monitor whether the deletion job is successful. As shown below:
2.3 JMeter running to view the running results
2.3.1 No login required
1. Click the green button to run Jmeter, as shown below:
2. Check the running result of JMeter. The monitoring results of a request are all green, indicating that the request is successful. As shown below:
(1) Check whether the reading is successful, and see the content of the blog post from the result, indicating that the reading is successful. As shown below:
2.3.2 Login
1. There is "Beijing-Hongge" in the new task of Jenkins, as shown in the following figure:
2. Click the green button to run Jmeter, as shown below:
3. Check the running result of JMeter. The monitoring results of both requests are green, indicating that the request is successful. As shown below:
(1) Check whether the login is successful, and see "admin" and "logout" from the result, indicating that the login is successful. As shown below:
(2) You can see that after successful login, there is "Beijing-Hongge" in the task. As shown below:
(3) Check whether the deletion is successful. If you do not see "Beijing-Hongge" in the results, it means that the deletion is successful. As shown below:
4. Check the newly created task of Jenkins, and do not see "Beijing-Hongge", indicating that the deletion is successful, as shown in the following figure:
3. Develop an Advanced Web Testing Plan
In this section, Hong'er will explain how to create an advanced test plan to test a website.
For an example of a basic test plan, see Building a Web Test Plan.
3.1 Handling user sessions with URL rewriting
If your web application uses URL rewriting instead of cookies to save session information, you will need to do some extra work to test your site.
In order to properly respond to URL rewrites, JMeter needs to parse the HTML received from the server and retrieve the unique session ID. This can be done with the appropriate HTTP URL rewrite modifiers. Just put the name of your session ID parameter into the modifier and it will find it and add it to every request. If the request already has a value, it will be replaced. If "Cache session ID?" If checked, the last found session ID will be saved, which will be used if the previous HTTP example did not contain a session ID.
URL rewriting example
Download this example. A test plan using URL rewriting is shown in Figure 1. Note that the URL Re-writing modifier has been added to the SimpleController, ensuring that it will only affect requests under that SimpleController.
Figure 1 - Test tree
In Figure 2, we see the URL rewrite modifier GUI, which has only one field for the user to specify the name of the session ID parameter. There is also a checkbox to indicate that the session ID should be part of the path (separated by ";"), not a request parameter.
Figure 2 - Request Parameters
3.2 Using the Title Manager
The HTTP Header Manager allows you to customize what information JMeter sends in HTTP request headers. This header contains attributes like "user-agent", "pragma", "referrer", etc.
The HTTP header manager, like the HTTP Cookie Manager, should probably be added at the thread group level, unless for some reason you want to specify different headers for different HTTP requests on your test objects.
4. Summary
4.1 Login and delete the first three parameters blank
1. Careful friends or children's shoes will find from the screenshots that the first three parameters of Hongge's login and deletion are blank, and nothing is filled in. That is because of the HTTP default request in front, so there is no need to fill in here, the benefit It can be seen from here. At present, only two requests are listed. If hundreds or thousands of requests are effective, it will be more obvious.
Well, today I will share here about creating a web plan and creating an advanced web test plan. Thank you very much for reading this. If you think it's good, please give me a recommendation.
Your affirmation is the driving force for my progress. If you feel good, please encourage it!