Parameterization in Load Runner About LoadRunner:

Load runner is a load testing tool used for Performance and Stress test by test engineers. It was released by Mercury Interactive which is now under HP software https://h !!"#.www .hp.com/cda/hpms/display/main/hpms$content.%sp&'n(bto)cp( * * +,* "-#$.!!!$ !!$$. Loadrunner has /01en component for recording and generating scripts to be automated for performance test with virtual users./01en records a script for one user and the same can be used in setting the scenario for multiple users in 2ontroller. /u1en3 when recording a script3 simply listens to the client 4browser5 tal6ing to the server 47eb server5 and writes it all down. 8he complete transcript of everything that was said3 the dates and time3 content3 re9uests3 and replies can be found in the :ecording Log 4for Single Protocol5 or 1eneration Log 4for Multiple Protocol5. 8he script is an easier to read version of this. 8he main difference is that the script only contains the client;s communication.

What is Parameterization?
If you imagine that /u1en is an impersonator pretending to be the client 4browser53 the script tells /u1en what to say to the server to successfully fool it. <ou want the server to believe that /u1en is a real client3 and thus send it the re9uested information. 8his script has the hard*coded information of the original conversation 4=rowser session5 that occurred between the client and server. 8his hard coded information may not be enough to fool the server during replay however> it may have to be correlated. Parameteri'ation is where the script is modified so that some of the hard*coded values in the script are no longer hard*coded. :ather then sending the original value to the server3 we may need to send different values. ?or e@ample3 the original recorded script may have included the server sending the client a session identification number3 something to identify the client during that particular session. 8his Session IA was hard*coded into the script during recording. Auring replay3 the server will send the client a new Session IA. <ou need to capture this value3 and incorporate it into the script so you can send it bac6 to the server to correctly identify yourself for this new session. If you leave the script unmodified3 you will send the old hard*coded Session IA to the server. 8he server will loo6 at it and thin6 it invalid or un6nown3 and so will not send the pages that have been re9uested. :eplaying a script with an old Session IA will not successfully fool the server into believing it is a client.

Parameteri'ation is the capturing of dynamic values passed from the server to the client and bac6. <ou save this captured value into a parameter3 and then use this parameter in the script in place of the original value. Auring replay3 the replay engine will now listen to what the server sends to it3 and when it ma6es re9uests of the server3 send this new3 valid value bac6 to the server> thus fooling the server into believing it is tal6ing to a real client.

What errors mean I have to Parameterize?

8here are no specific errors that are associated with Parameteri'ation3 but there are errors that could occur because a value has not been correlated. ?or e@ample3 if an invalid Session IA is sent to a 7eb server3 how that server responds depends on the implementation of that server. It might send a page specifically stating the Session IA is invalid and as6 you to log in again. It might send an H88P .!. Page not found error because the re9uesting user did not have permissions for the specified page3 and so the server could not find the page.

In general3 any error message returned from the server after the script ma6es a re9uest that complains about permissions can point to a hard*coded value that needs to be correlated. 7hat values in the script need to be correlated& 8he simplest answer is BCny value that changes between sessions re9uired for the script to replay.D A hypothetical example <ou are logging onto a website. 7hen you send the server your user name and password3 it replies with a Session IA that is good for that session. 8he Session IA needs to be correlated for replay. <ou need to capture this value during replay to use in the script in place of the hard*coded value.

Functions for Parameterization

8here are three functions that you can use for Parameteri'ation: Function web$reg$save$param escription 8his is the latest function with some e@tra features for a more powerful usage. 8he synta@ is as following: web$reg$save$param 4 BParameter EameD 3 FList of CttributesG3 LCS8 5> Hach of these parameters is a pointer to a string. 8hat means that if they are entered as literal te@t3 they need to be enclosed in 9uotes3 with each parameter separated by a comma. 8he supported attributes include L= 4Left boundary53 := 4:ight boundary53 :el?rameIA3 I:A3 Search3 SaveIffset3 SaveLen3 and 2onvert. 8hese attributes can appear in any order because they contain within them what they are. Aetail information about each attribute can be found on the function reference online. 7eb$create$html$param =oth of these functions are for bac6ward compatibility only. It is recommended that you use the web$reg$save$param function. If you need to use this 7eb$create$html$param$e@ function for some reason3 please refer to the function help reference. C list of all the three functions3 along with documentation and e@amples3 can be found in the on*line documentation. ?rom /u1en3 go to Help ?unction reference 2ontents 7eb and 7ireless /user ?unctions Parameteri'ation ?unctions.

Automatic Rules Parameterization !Record"

8o record with the :ules Parameteri'ation mechanism3 follow the steps below. . Hnable auto*Parameteri'ation. a. Hnable the auto*Parameteri'ation option in /u1en;s 8ools menu3 under :ecording options Internet Protocol: Parameteri'ation. 2lic6 on BHnable Parameteri'ation during recordingD to turn on the feature. b. 4 =uilt*in Parameteri'ation 5 Indicate the servers to which you want to apply the Parameteri'ation rules. Select the chec6bo@es ad%acent to the server names to enable the rules for that server. 8o enable specific rules within a server group3 clic6 the plus sign to e@pand the tree and select the desired rules. c. 40ser*define rule Parameteri'ation5 8o add a new rule to an e@isting server3 select one of the e@isting entries and clic6 BEew :ule.D Set the properties for the rule in the right pane. d. Set the option on how you want the recorder to behave when there is a dynamic value matching the rule being detected. 8he available options are Issue a pop*up message and let me decide online .Perform Parameteri'ation in script e. :ecord the script

#orrelation $tudio !Replay"

/ery often3 you will notice that not all the dynamic values are correlated with the use of :ules Parameteri'ation. 8his is li6ely to happen when you are recording against a session on an unsupported application server whose conte@t is not 6nown3 and you cannot determine any Parameteri'ation rules. 8o handle this3 the 7eb protocol comes with the 2orrelation Studio3 where after running the script> it will automatically compare the server;s response for record and replay3 to loo6 for dynamic values for Parameteri'ation. 8he list of differences will be reported to you3 for you to choose the ones to correlate. 8o invo6e this feature3 . :un the script once. +. Cfter the run3 you will see the following pop*up alert prompting for BScan Cction for correlation.D 2lic6 on B<esD to start the scan.

J. Auring the scan3 the 2orrelation Studio will automatically compare the record and replay response for dynamic values and report the differences to you. <ou can see the dynamic values that are detected on the lower panel3 under the B2orrelation :esultsD tab. .. Loo6 through the differences reported by the 2orrelation Studio. 2orrelate the values on those necessary. 8o ma6e the Parameteri'ation process easy3 you can choose the option to correlate them either one at a time 4Correlate5 or all at once 4Correlate All5. %ote: Parameteri'ation Studio often reports all the dynamic values3 including those where you do not need to correlate. =ecause of this3 Mercury recommends you to use the Correlate option3 and loo6 at the value to correlate one at a time. K. In general3 you will need to repeat steps *. a few times3 before you can correlate all the dynamic values. 8he Parameteri'ation Studio is not li6ely to report all the differences with %ust one run because your script is prone to fail on a very early stage. 8his causes the subse9uent dynamic values to go undetected.

&anual Parameterization
$teps to Perform &anual Parameterization

'( Record t)o copies of the script )ith the same business process and data:
:ecord a script on the desired business process and save it. :ecord another copy of the script3 repeating all the steps as in step a. Cs much as possible3 during recording3 enter the same values in both scripts3 for e@ample3 user IA3 password3 and fields and edit selections. *( Identify the values to correlate )ith the help of the Win iff tool: a. ?rom the second script3 go to 8ools 2ompare with /user3 and choose the first recorded script. b. 7inAiff will open and display the two scripts side by side. It will automatically highlight the lines with differences in them3 showing the differences in red. 4If not3 go to Iptions /iew Show inline differences.5 c. Locate the first difference3 ta6e note of it3 and search the script open in /u1en for that difference. 8hat is the original value hard*coded into the script that was different in the second script. Highlight it and copy it. %ote: Aifferences li6e Llr$thin6$timeL can be ignored. 8hey are pacing functions3 and do not represent data sent to the server. a. b.

d. 1o to the :ecording Log 4for Single Protocol5 or 1eneration Log 4for Multiple

Protocol5 and place your cursor at the top. Press 2ontrol*? 428:LM?5 to bring up the ?ind window.

Paste the value copied from step +c and search downwards. <ou are loo6ing for the first occurrence of this value in the :ecording Log or 1eneration Log. If you do not find the value3 verify you are loo6ing in the correct script;s :ecording Log or 1eneration Log. :emember you have two almost identical scripts here. If you find the value3 scroll up in the log3 and ma6e sure the value was sent as part of a response from the server. 8he first header you come across while loo6ing up the script should be prefaced by a receiving response. 8his indicates that the server sent the value to the client. If the value first appears as part of a sending re9uest3 then the value originated on the client side and does not need to be correlated3 but rather parameteri'ed. 8hat is a different topic all together. 8he response will have a comment before it that loo6s li6e this: NNN Otid(bP int.com:#! Cction 4 +Q :eceiving response from host astra.merc* +K/ /+!!+ +:!.:!!5

e.

So3 you have a value that is different between subse9uent recordings3 it was sent from the server to the client> this value most li6ely needs to be correlated. If the value is not different between recordings and not originating on the server and sent to the client then the value probably does not need to be correlated.

+( &anually correlate the script )ith the )eb,re-,save,param function( Cfter confirming that the first occurrence was part of a received response from the server3 you need to figure out where to place the web$reg$save$param4 5 function and what to put in it before creating the function a. 7here to place the web$reg$save$param function& ?rom the last step3 you located the dynamic value inside the H@ecution Log. Pic6 up the te@t that is before the dynamic value. 8his te@t should remain constant no matter how many times you replay the script> highlight it and copy it. 8his is the te@t that will identify where to find the start of the value you are capturing.

Eow3 to identify the place to put the function3 you need to replay the script once in e@tended log. 8o do this3 i. 1o to the /user menu and select B:un*8ime Settings.D ii. 1o to 1eneral:Log iii. Select BHnable Logging3D BClways sends messages3D BH@tended log3D and all the options under e@tended log. Cfter replay3 go to the H@ecution Log and search for the te@t that you %ust copied from the :ecording Log 4for Single Protocol5 or 1eneration Log 4for Multiple Protocol5. <ou should see a corresponding Cction .c45 at the beginning of that line with a number in the brac6ets. 8hat is the number of the line in the script where you need to put web$reg$save$param4 5 function. 8he function should go right above that line in the script. So3 add a couple of blan6 lines to your script before the function at that line3 and then type in web$reg$save$param4B0serSessionD3 but give it a name that means more to you than 0serSession.

b. i.

Identifying the boundaries for web$reg$save$param function. Identifying the left boundary * 8he starting point to correlate. 1o bac6 to the :ecording Log 4for Single Protocol5 or 1eneration Log 4for Multiple Protocol53 highlight the te@t to the left of the dynamic value and copy it. 8he amount of te@t you highlight should be sufficient so that it is uni9ue in this reply from the server. It is suggested that you copy as much as possible without copying any special characters. 8his is shown in the H@ecution Log as blac6 s9uares3 and the actual character they represent is uncertain. Cfter selecting a boundary3 go to the top of the Servers reply3 and press 28:LM? and do a search for that boundary. <ou want to ma6e certain what you have selected is the first occurrence in the Servers reply. If it is not select3 use more te@t to ma6e it uni9ue3 or consider using the I:A parameter of the web$reg$save$param function. Ince you have finali'ed the static te@t that represents the left boundary3 copy it into the web$reg$save$param statement. 8he function you will have so far would be web$reg$save$param 4B0serSessionD3 name(userSession value(D3 ii. BL=(input type(hidden

Identifying the right boundary * 8he ending point to correlate.

<ou are now going to tell the replay engine how to identify the end of the value you are trying to capture3 that is3 the right boundary of what you are loo6ing for. Cgain3 loo6 in the H@ecution Log and copy the static te@t that appears to the right of the dynamic value you are loo6ing for. ?or e@ample3 let;s say the H@ecution Log contained the following: R userSession value("K#PJ.!##.K,#,K ASCAHfCpHAHfcAtccpfCttcfGR 8hen3 the e@ample so far to save the number into the parameter 0serSession would be web$reg$save$param4B0serSessionD3 BL=(input name(userSession value(D3 B:=(GD3LCS85> type(hidden

%ote: In choosing a right boundary3 ma6e sure you choose enough static te@t to specify the end of the value. If the boundary you specify appears in the value that you are trying to capture3 then you will not capture the whole value.

.( Replace the hard/coded value in the script )ith the parameter(

Ince you have created the parameter3 the ne@t step is to replace the hard*coded occurrences with the parameter. Loo6 through the script for the original value. 7here you find it3 delete the value and replace it with the parameter. Eote3 only the value you want replaced is deleted. 8he characters around it remain. 0xample: 2hange: "Name=userSession", "Value=75893.0884568651D AD!"A#!D!"$Dt$$#"Att$"", , 8o: "Name=userSession", "Value= %&serSession'", (ND)*(+, R

Ct this point3 you are ready to run the script to test if it wor6s3 or if it needs further Parameteri'ation3 more wor6 on this Parameteri'ation.

$ummary

8hat was a lot of loo6ing through the logs and chec6ing of values. Let;s %ust recap what you have done. <ou have identified a value that you thin6 needs to be correlated. <ou then identified in the script where to place the statement that would ultimately capture and save the value into a parameter. <ou then placed the statement3 and gave the te@t strings that appear on either side of the value that you are loo6ing for so that it can be found. 8he flow of logic for this is the Parameteri'ation functions tell the replay engine3 what to loo6 for in the ne@t set of replies from the server. 8he replay engine ma6es a re9uest of the server. 8he server replies. 8he replay engine loo6s thorough the replies for the left and right boundaries. If it finds them3 what is in*between is then saved to a parameter of the name specified. :emember3 the parameter cannot have a value until after the ne@t statement is e@ecuted. 8he Parameteri'ation statement only tells the replay what to loo6 for> it does not assign a value to the parameter. Cssignment of a value to the parameter does not happen until after generating re9uest to the server and loo6s in the reply. If you have a case where a Parameteri'ation statement is followed by a function that attempts to use the parameter3 the statement is in the wrong place3 and the script will fail. 8his is always incorrect: web$reg$save$param4R5> 7eb$submit$data 4R TParameterUR5> In*between the two3 there needs to be a re9uest of the server that causes it to reply with the value you are trying to capture. 7hen you are done with the above3 the ne@t step is to replace the hard*coded occurrences with the parameter. 8he script is then ready for replay.