These are the general guidelines to be followed while creating LoadRunner scripts for performance testing:
Load testing is intended for assessing the behavior of the application when multiple users are accessing the application. Hence the purpose of testing and performance requirements should be clearly defined before start of creation of scripts. This includes figuring out the various business processes, transactions that are widely used by end users, the business critical transactions and transactions that include pages, which will take large amount of time for load testing.
Do not create one script for each transaction or functionality. Group the transactions into multiple sets (different actions) and create minimum number of scripts covering all the transactions. During actual test, the actions, which are not required for that specific test, can be removed from the running list of actions.
Give meaningful names for scripts, transactions and actions in the scripts. Do not leave the default names for actions.
Create separate actions for Login to the application and Log out of the application and keep them in ‘vuser_init’ and ‘vuser_end’ sections.
In the beginning of the script, provide a brief description regarding the script flow. Add appropriate comments for all transactions and major steps.
Insert rendezvous statements when a particular page is to be tested when multiple users are simultaneously accessing it.
If a portion of script is to be executed multiple times in each iteration, include this portion in a ‘for’ loop and indicate through a parameter for how many times this portion is to run rather than putting it in a block (in ‘Pacing’ tab of runtime settings) and specifying how many times to run.By doing this the behavior of script can be better controlled by changing the value in a data file rather than every time going and changing runtime settings.
Add ‘lr_vuser_status_message’ functions at appropriate places with information such as which iteration is being executed. These types of message functions are very useful to find out status of vusers and how the testing is going on
Load testing is intended for assessing the behavior of the application when multiple users are accessing the application. Hence the purpose of testing and performance requirements should be clearly defined before start of creation of scripts. This includes figuring out the various business processes, transactions that are widely used by end users, the business critical transactions and transactions that include pages, which will take large amount of time for load testing.
Do not create one script for each transaction or functionality. Group the transactions into multiple sets (different actions) and create minimum number of scripts covering all the transactions. During actual test, the actions, which are not required for that specific test, can be removed from the running list of actions.
Give meaningful names for scripts, transactions and actions in the scripts. Do not leave the default names for actions.
Create separate actions for Login to the application and Log out of the application and keep them in ‘vuser_init’ and ‘vuser_end’ sections.
In the beginning of the script, provide a brief description regarding the script flow. Add appropriate comments for all transactions and major steps.
Insert rendezvous statements when a particular page is to be tested when multiple users are simultaneously accessing it.
If a portion of script is to be executed multiple times in each iteration, include this portion in a ‘for’ loop and indicate through a parameter for how many times this portion is to run rather than putting it in a block (in ‘Pacing’ tab of runtime settings) and specifying how many times to run.By doing this the behavior of script can be better controlled by changing the value in a data file rather than every time going and changing runtime settings.
Add ‘lr_vuser_status_message’ functions at appropriate places with information such as which iteration is being executed. These types of message functions are very useful to find out status of vusers and how the testing is going on
No comments:
Post a Comment