Performance testing can be done with QTP, but in a limited scope – only from a single user standpoint, for functional testing. Years ago when the “QTP VUser” for LoadRunner was introduced they incorporated the “start_transaction” & “end_transaction” functions. These are used by LoadRunner for tracking performance timings for load testing, but you can also use them in a regular QTP test script. for functional testing. These statements have been updated to “Services.StartTransaction “<transaction name>” ” and “Services.EndTransaction “<same transaction name>” “.
These statements will log the duration time to the Test Results Report, which will tell you how long the “process” that resides between the two statements took to execute. Typically what you would do is wrap a submission or transaction process to see how long it is taking; like submitting an order or new user profile. In using the QTP training application we will time the submission of the order, so find the “Insert Order” button statement and your synchronization statement to know when the insert process has completed.
So just before the “Insert Order” button you would put a Services.StartTransaction “InsertOrder” statement and once you are synchronized on the success of the submission of the order you will have an Services.EndTransaction “InsertOrder” statement (placed right after the sychronization statement).
This will tell you how long it took to insert a new order and you can pass or fail this test step based on your functional requirements as to how long is an acceptable timeframe. These statements will log the results to the Test Results Report directly and appear like this:
The disadvantage of this statement is that it only logs the results to the Test Results Report, so you don’t have the actual time within the test script. in order to code your own logic on passing or failing the statement. People complained about this for many years and finally they came out with a new function prior to the sale of “Mercury Interactive” to “HP”, so the function name actually has the old company name contained in it. The functions are “MercuryTimers(“<timer name>”).Start” and “MercuryTimers(“<timer name>”).Stop”. The Stop function returns the duration time as a return code so you can use it within your test script. You would use this function the same as the StartTransaction statements; identify were in the test script. you want the statements and then type these statements in (note that using the Step Generator will produce the wrong syntax so it is best to just manually type the statement in your test script. in the Expert View.
Notice that I added a “msgbox” statement to display the duration time so that you can see how it is returned as a return value into a variable and can be used in the test script. Notice that the time is returned in milliseconds.
The odd thing is that when Mercury added this function to QTP in order to provide you with the duration time as a return code within the script, they didn’t keep the feature of also logging it to the Test Results Report. Notice in this image that there is no reference to the fact that the “MercuryTimers” function was executed.
So if you want to log the time to the Test Results Report (which I highly recommend so that you have a log of the duration time) then you will want to add your own “Reporter.ReportEvent” statement.
And then the report will have entries for each timing and because I used a conditional statement to verify the duration time against the functional requirement of taking less than 6 seconds, I can then pass and fail the statement automatically.