Use JMeter to complete common stress tests
Login.jsp and welcome.jsp. Where login.jsp is responsible for generating the user object and invoking user login. When login returns to True, turn to welcome.jsp. The code for its validation section:
<% if (Request.getparameter ("Submit")! = null) { User ur= New User (Request.getparameter ("user"), Request.getparameter ("pwd"); if (Ur.login ()) { Session.setattribute ("User", UR); Response.sendredirect ("/gweb/welcome.jsp"); } else{ Session.setattribute ("login_error_msg", "Invalid user, possible cause: the user does not exist or is disabled.") "); Response.sendredirect ("/gweb/index.jsp"); Return } } %> |
Web. XML, configuring filter to intercept all requests to access JSP pages:
<filter> <filter-name>authorizen</filter-name> <filter-class>org.foxgem.jmeter.AuthorizenFilter</filter-class> </filter> <filter-mapping > <filter-name>authorizen</filter-name> <url-pattern>*.jsp</url-pattern> </filter-mapping> |
2. Create a Web test plan with the following structure:
The main test elements are described as follows:
The HTTP request default is responsible for logging the default values for requests, such as servers, protocols, ports, and so on.
The first HTTP request, request login.jsp, and attach the required parameters (User=foxgem,pwd=12345678,submit=submit) for the validation, which contains the response assertion validation URL contains "welcome.jsp", This can be reflected from the program.
The second HTTP request, the request is welcome.jsp, contains the response assertion validation response text that contains "Foxgem", which is part of the welcome.jsp page logic.
The HTTP cookie Manager is responsible for managing the cookie used throughout the testing process, and it does not need to set any attributes.
The loop controller sets the number of cycles to send a second request, and the table listener is responsible for collecting and displaying the test results for the second request.
After you start the test plan, the order of execution is: first, the first request login page to log on, and after successful login, the second request is executed using the loop controller. When welcome.jsp is requested, the response assertion is used to verify that it is indeed welocme.jsp to process the request, not because of another page. In this test plan you need to be aware of the HTTP cookie manager. It is because of its role that the second request can be successfully sent to welcome.jsp for processing, rather than being forwarded to login.jsp because of a lack of user security information.
In this case, we didn't use cookies in our program (using the session), so how does the HTTP cookie manager work? This is because there are 2 ways to track the session status in the SERVLET/JSP specification:
Use cookies to retain and transfer sessionid. It does not require the program to have any special handling of URLs, but requires the browser to allow cookies. In this case, this is the case.
Use URL rewriting to pass SessionID between the browser and the server each time explicitly. It requires the program to encode the URL, which is not required for the browser. For the second case, you can do so using the HTTP URL rewrite modifier in the JMeter predecessor manager. For the tomcat,session parameter is Jsessionid, the path extension uses ";". Use URL encoding to be aware that the browser's cookie function must be turned off. Because URL-encoded functions, such as Encodeurl, determine whether you need to encode sessionid into a URL. When a browser allows a cookie, it is not encoded.
If the cookie is not the session to save the user's security information, then use the HTTP cookie manager directly. At this point, you need to write the cookie parameters and values used directly into the manager, which is administered by it. This is also true for other cookie use.
After the login problem is resolved, there is no difficulty in testing the WEB server. The rest is based on the actual needs, flexible use of relevant test components to build a test plan. (There are, of course, other usage scenarios for security issues.) It needs to be clear when it is used: whether JMeter is supported, and which test component is used to resolve it. )
Database server
The database server is indispensable in most enterprise projects, and it is stress-tested to find out whether a database object can effectively withstand access from multiple users. These objects are mainly: indexes, triggers, stored procedures, and locks. By testing SQL statements and stored procedures, JMeter can indirectly react to the need for optimization of database objects.
JMeter uses JDBC to send the request to complete the test for the database. A database test plan, set up the following structure:
which
A JDBC connection configuration that is responsible for configuring database connection-related information. such as: Database URL, database driver class name, user name and password, and so on. In these configurations, the variable name bound to the pool (Variable name Bound to pool) is a very important property that is referenced in the JDBC request. Through it, the JDBC request is associated with the JDBC connection configuration. (Before testing, put the required database drivers in the JMeter classpath). The JDBC request is responsible for sending the request for testing. Graphical results, collected to display the test results.
In a real project, there are at least 2 types of JDBC requests that need attention: SELECT statements and stored procedures. The former reflects the efficiency of the SELECT statement and whether the index of the table needs to be optimized, and the latter is the efficiency of the algorithm for the reaction stored procedure. If they are inefficient, they will inevitably lead to unsatisfactory response. For both of these requests, the configuration of the JDBC request is slightly different:
SELECT statement
Stored Procedures
If for Oracle, if you are testing a function, you can also use the SELECT statement to configure it, you can use the: Select function (entry parameter) from the dual form of the statement to test, where dual is the Oracle keyword, representing the dumb table. For other vendors ' database products, please find the manual.
"Go" use JMeter to complete common stress tests (II.)