The main topics I think are really important and I'm going to talk here are:
1. RPT script
I suggest to have in mind very clear the scenario you want to record, so first try manually it for a couple of times and take notes of the steps. So let you record navigating the webui of your application inserting RPT notes before each click-step, then finally after the recording phase, you can start the interesting one to customize the generated RPT script.
The datapool contains the variables to need to pass at runtime during the execution of the test script. A tipical example of datapool is the login username and password you enter at the very beginning step of every enterprise web interface. To pass the value of the datapool you have to create a substitution on the data, header or on the URL of the HTTP request. The values of the datapool can be fetched and passed with different policies (random, sequential, wrap or not).
3. Correlation
The most important thing is that RPT correlates automatically the attributes in the URLs, POST data, headers, etc. creating like a chain of HTTP requests linked with one or more of the previous HTTP responses. This is a point really important to understand. During the development of a RPT script after recording it happens that you have to work manually and change or parametrize some correlations. One correlation consists of two parts:
- the reference that is defined on a piece of the HTTP response
- the substitution that is defined on a piece of the HTTP request, URL, header, POST data
For example with the first HTTP request, RPT creates two references, one to the host of the URL opened and another to the port. This particular references are grouped in the Server Connection variables container. Then for each request recorded the first part of the URL will be substituted with the reference variable of host and with that of the port. This is nice because you can switch to another host simply changing the variable values.
References and substitution can be created even manually where you need. Also there is one important reference type you can create and is called: "field reference". Basically it consists on a variable that refers to the whole content of a response. This is useful when you have to customize your script and pass this content to some custom code that has to process it or simply because you want to debug displaying that content.
4. Custom code
Sometimes you need to introduce some additional processing in order to pass to some HTTP request the specific parameters calculated on the base of particular logic.
For example if you have a table of elements and the user want to select one row randomly, then you first have to process with a java class the HTTP response that is displaying the whole table, in order to extract the identifiers of each row, then with a random java API custom code you can return the identifier of the row to be passed to the next HTTP request in the URL or in the POST data depending on how is made the HTTP request that select the element of the row.
5. Regular expression
RPT creates automatically many references using regular expression. Sometimes you need use the same approach to extract specific string or values. For example you want to define a new reference to the extract the value of a html field and pass it this referenced value to another HTTP request, or to pass this value to a custom code and implement some logic on that value.
During recording the user can wait some seconds before to click on the web page, this is the think time, and after the click the HTTP requests starts from the browser with some delay of ms or seconds.
So put attention, do not forget them. If you start playing a script without modifying the think time of the recording phase, RPT will execute the script at the same speed, so the response time that will be reported will sum also the think time of each step executed. And the same the delay will be added to the actual response time if you keep for each HTTP request the same delay of the recording phase. You can simply disable think time and delays on the RPT script.
7. Substitute multiple items.
When defining a substitution it is useful to find out if there are other strings with the same value. If so, RPT can substitute all with the same reference or variable.
8. Rules
When creating some references and substitution is a recurring activity, it is time to create rules to accumulate and automatize this effort to be applied easily on new scripts. Basically a rule contains a regular expression to find the string to be extracted from a HTTP data or URI etc, depending on the rule, and it also contains the substitution to create.
9. Verification points
The preparation of the script consists not only to record and customize the steps to navigate in the interface, but also it needs verify that each steps is correctly executed. You can verify this introducing for each test step a verification point on the HTTP response content related to the HTTP request performed for the step. Each verification point can be also a regular expression to verify the specific text is present on the response.
10. Schedule
Is the object where you can define the RPT scripts to run specifying the workload in terms of number of concurrent (and virtual) users and in terms of frequency.
11.Reporting.
Once the schedule is ready you can start running (but do not forget at the same time start the nmon process to start collecting CPU metrics and other system info from the target machine). The nice is you can watch at different charts showing how is performing the application. The main interesting is the response times of the worst steps of the scripts, the throughput in terms of web pages and bytes. So you can verify easly if/where there is a bottleneck. Also you can calculate the number of transactions for each test script.
You have to study and practice the technique, but I ensure you RPT is a very powerful performance tool.
Enjoy!
For official reference and documentation check here:
http://www-01.ibm.com/support/knowledgecenter/SSMMM5/welcome
Nessun commento:
Posta un commento