|
|
|
|
VUGen - As a protocol replay tool
VUGen is also used as a scripting language for Topaz. Visit mercuryinteractive.com/products/topaz/ for more information on Topaz. The following diagram shows how a protocol level recording and playback tool, such as VUGen works. Note that only the communications is captured and recorded for subsequent playback. Events that do not generate communications such as moving the mouse, or editing data in a field on a web form are not recorded because those events do not interact with the system under test.
During a load test we need to run many virtual user sessions, and we do it by replaying the protocol that is described in a VUGen script under the control of a LoadRunner Controller. A copy of the client application (a web browser in the case of a web application) does not need to run for each session, as all of the protocol information is contained within the VUGen script. The example below relates to an Internet Explorer session starting up and connecting to www.google.com.au and then performing a search on "Mercury Interactive". As can be seen, protocol based tools such as VUGen records each of the interactions between the browser and the Google web site, including the setting of cookies and the transmission of the search request containing the text "Mercury Interactive". The tool needs to do the following:
Each of the above steps can be seen in the screen print shown below.
The concept of 'protocol replay' is central to the way that Load testers are able to generate substantial load with minimal load generation hardware. This is a direct contrast to the way that GUI based testing tools, such as WinRunner operate, as GUI based tools need to use an entire instance of the client software for each virtual user. Refer to the page on WinRunner for more information on the way that GUI based testing tools can be used in the context of load testing. The concept of protocol replay can be better understood by looking at other examples using different protocols. COM/DCOM protocol exampleLoadRunner comes with various sample applications, so that a tester can get some practice on a simple application before attempting to script a test for a complex application. One such sample is the COM based 'flights' application. The following screen shows what the Virtual User Generator script looks like for a COM/DCOM protocol. You can see from script example that this portion of code relates to the end of the login process and the start of the process to select a flight (because of the start and end transaction marks that I inserted). You can also see the SQL statement showing that the list of flights relate to 'Denver to Los Angeles on Tuesday'. For a realistic test, these values need to be paramatised so that the same SQL statement is not executed over and over again. The script also needs to be correlated so that the values returned from such an SQL statements is able to be used later in the script. For example, if the first flight from Denver to LA on Tuesday were selected when the script was recorded, that flight may have a flight number of 12345. However, if the locations were changed from LA to New York then the first flight may have a number of 23456. VUGen needs to know to send 23456 instead of 12345 in subsequent communications to the server, and this is achieved by correlation.
As can be seen from this example, some logic is required to replay the COM protocol, but much less processing power is required than the actual application that was recorded. This means that a large number of such Virtual Users can be simulated with a single load generator computer.
|
Send mail to
webmaster@loadtest.com.au with
questions or comments about this web site.
|
