Runtime settings:
Extension of RTS is “.cfg” & “.usp”.
Note: RTS will be transferred to controller from vugen script but not vice versa.
1. Run Logic: Indicates number of Iterations.
Note1: Test duration setting will override the Run Logic.
Note2: To make our script iterates for specific number of iterations, we have to choose “run until
complete”.
2. Pacing: Time delay between the Iterations
We have 4 types of Pacing.
1. No pacing/ no delay.
2. Fixed Pacing, waiting time.
3. Random Pacing (generate random value and wait for the same).
4. Interval Pacing: Instructs users to finish with in a time, which includes pacing time, iteration time.
Note1: Pacing is the time delay to start new iteration after finishing previous iteration.
Note2: Pacing will allow you to control the number of iteration and number of transactions.
Note3: Pacing calculation is very important while preparing work load model.
3. Log: Logs will help you to debug the script.
Enable logging: You will receive log messages based on the settings.
Disable log: You are going to use this option while running the test to avoid unnecessary
4. Think time:
Think Time is the time to choose new action after getting previous response.
(or)
Time delay b/w the User actions.
Note: Even you can pass float numbers as a think time.
Q: Why think time is required?
A:
In realistic environment end users are taking sometime to choose the new action after receiving previous response.
But in my script virtual users are not waiting for to choose the new action and they are firing back to back request.
To simulate the realistic environment we have to instruct the users to pause in between the request with the help of think time.
Who is going to provide the think time?
A:
As a performance tester we have to calculate the think time. How long a normal user is waiting
to choose the new action on every page.
Note: we should not use recorded think time.
Think time option:
1. Ignore Think time: It is going the function and execute back to back request.
2. As Recorded: It will pause the script execution as per the function time.
3. Multiply think time: Multiplies the think time.
4. Random Think time: it will generate the random number based on minimum and maximum
percentage and passes the same.
5. Limit Think time: It limits the think time.
Q: Where do you place the think time?
A: We should not place the think time in between start and end transaction.
Q: What is the impact of think time on the response time?
A:
Scenario1:
If you reduce the think time you will receive higher response time. Because of less think time
users will perform more iterations and transactions, which will impact the server
performance.
Lower think time will give less breathing time, which will impact the transaction
response time.
Scenario2:
Higher think time will give good response times.
Due to the higher think time server will get more breathing time which will process the request very fast.
Global think time:
Define the variable in global.h
Ex: int X=10;
lr_think_time(x); (Action)
Note: If we forgot to take out the think time from start to end transaction you can filter those response times in lra file with the help of properties.
5. ADDITIONAL ATTRIBUTES:
To declare the Environment variables.
Q: How to create environment variables in LR?
(or)
How to pass a new value in to the script without opening the script?
A:
char * server;
server = lr_get_attrib_string(“host”);
lr_save_string(server,”url”);
Write the above statement in the script.
Set the value in the RTS and pass vary arguments in runtime.
6. Miscellaneous:
Continue on Error:
Continue script execution even when an Error Occurs.
Generate snap shot on Error:
It will generate the snap shot for every Error you can verify them in Result file (or) Controller
vuser log (by clicking camera symbol).
Q: Where we can find a screen shot?
A: Go to the vuser log and click on the camera symbol. Navigate to the LG results path and you can find HTML page for every error
Multithreading:
Run vuser as a process:
For all client server apps (SAP GUI or Desktop based apps. EX: SAP GUI/ Calculator) you have to run vuser as a Process.If we are running vuser as a process every vuser required one MDRV (Multi Driver Program) Engine.
Every MDRV engine required 5Mb memory in the LG Machine.
Running Vuser as a Thread:
For all web based applications you have to run vuser as a Thread. If you are running vuser as a thread multiple users will share one MDRV engine.
NOTE: Approximately 50 vusers use one MDRV engine.
Automatic Transaction:
Allow you to generate the automatic transactions to measure the response time.
7. Network:
Speed simulation:
It specifies to use maximum/ predefined/ custom band width for your test.
Usually we are using maximum bandwidth option until or unless there is a requirement, we are not going to use custom or advanced bandwidth.
If you like to test your application with a specific network bandwidth, then use custom or advanced bandwidth.
8. Browser Emulation:
It will allow you to use multiple browsers for test.
Note:
Prerequisites:
We should install the browser in the load generator.
1. Simulate browser cache: Enabling this option instructs the users to use or simulate cache
files from browser.
If disable this option, cache files will be deleted or will not be simulated.
2. Simulate a new user on each iteration: If the users are iterating for multiple times, we have
to make him behave like a new user on every iteration by enabling this option.
9. Internet Protocol:
Content check:
It is a global text verification option. Verifies the text on every page.
Note: web_reg_find is a local verification point.
Steps:
1. Create application by clicking new application.
2. Create a rule under the application.
3. Provide the text and match case.
4. You can export or import the rule and extension is “.xml”.
10. Proxy:
It will allow you to configure proxy settings for all requests. It will redirect all the requests to proxy server.
Options are
1) No proxy
2) Obtain proxy settings from browser
3) Custom proxy
11. Preferences:
1. Enable image and text check:
This option has to be enabled for web_find(), and web_image_check().
2. Wininet replay instead of socket:
For NTLM based applications or SSL based applications, you can use wininet replay.
If you don’t want to use web_set_socket option, then use wininet replay.
Options:
HTTP request connection time out: A unit time within which request connection
operation should finish. Default is 120 seconds.
HTTP request receive time out: A time unit within which receive operation should
finish. Default is 120 seconds.
Step Download time out: A time unit within which entire step has to be finished.
Default is 120 seconds.
12. Download filters:
To exclude or include specific URL, use download filter option.
Q: How to design shared RTS? (or) How to configure RTS for multiple scripts?
A: Two ways we can configure the shared RTS
1. Vugen level: Configure RTS in one script, copy “.cfg” and “.usp” files and paste into
remaining script folders.
2. Controller level: Select all scripts and choose shared RTS and configure the same.
Note: Whenever script having vary number of actions and names, you should not create shared RTS or should not copy “.cfg” and “.usp” files to some other scripts.
SLA configuration:
SLA configuration will allow you to compare derived statistics with expected statistics.
Step 1: Click on new under SLA
Step 2: Choose SLA measurement like total, average, throughput, hits per second, response time
and errors.
Step 3: Provide threshold point and click on finish.
Rendezvous test:
Rendezvous point is the point to instruct the users to wait at a certain location once the specified number of users arrived at that point. It will execute the subsequent request.
Syntax:
lr_rendezvous(“xyz”);
Step 1: Write the function in the script.
Step 2: Go to controller and select rendezvous under scenario.
Step 3: Configure the policy by providing number of users and timeout.
see the following screenshot to better understand.
Extension of RTS is “.cfg” & “.usp”.
Note: RTS will be transferred to controller from vugen script but not vice versa.
1. Run Logic: Indicates number of Iterations.
Note1: Test duration setting will override the Run Logic.
Note2: To make our script iterates for specific number of iterations, we have to choose “run until
complete”.
2. Pacing: Time delay between the Iterations
We have 4 types of Pacing.
1. No pacing/ no delay.
2. Fixed Pacing, waiting time.
3. Random Pacing (generate random value and wait for the same).
4. Interval Pacing: Instructs users to finish with in a time, which includes pacing time, iteration time.
Note1: Pacing is the time delay to start new iteration after finishing previous iteration.
Note2: Pacing will allow you to control the number of iteration and number of transactions.
Note3: Pacing calculation is very important while preparing work load model.
3. Log: Logs will help you to debug the script.
Enable logging: You will receive log messages based on the settings.
Disable log: You are going to use this option while running the test to avoid unnecessary
4. Think time:
Think Time is the time to choose new action after getting previous response.
(or)
Time delay b/w the User actions.
Note: Even you can pass float numbers as a think time.
Q: Why think time is required?
A:
In realistic environment end users are taking sometime to choose the new action after receiving previous response.
But in my script virtual users are not waiting for to choose the new action and they are firing back to back request.
To simulate the realistic environment we have to instruct the users to pause in between the request with the help of think time.
Who is going to provide the think time?
A:
As a performance tester we have to calculate the think time. How long a normal user is waiting
to choose the new action on every page.
Note: we should not use recorded think time.
Think time option:
1. Ignore Think time: It is going the function and execute back to back request.
2. As Recorded: It will pause the script execution as per the function time.
3. Multiply think time: Multiplies the think time.
4. Random Think time: it will generate the random number based on minimum and maximum
percentage and passes the same.
5. Limit Think time: It limits the think time.
Q: Where do you place the think time?
A: We should not place the think time in between start and end transaction.
Q: What is the impact of think time on the response time?
A:
Scenario1:
If you reduce the think time you will receive higher response time. Because of less think time
users will perform more iterations and transactions, which will impact the server
performance.
Lower think time will give less breathing time, which will impact the transaction
response time.
Scenario2:
Higher think time will give good response times.
Due to the higher think time server will get more breathing time which will process the request very fast.
Global think time:
Define the variable in global.h
Ex: int X=10;
lr_think_time(x); (Action)
Note: If we forgot to take out the think time from start to end transaction you can filter those response times in lra file with the help of properties.
5. ADDITIONAL ATTRIBUTES:
To declare the Environment variables.
Q: How to create environment variables in LR?
(or)
How to pass a new value in to the script without opening the script?
A:
char * server;
server = lr_get_attrib_string(“host”);
lr_save_string(server,”url”);
Write the above statement in the script.
Set the value in the RTS and pass vary arguments in runtime.
6. Miscellaneous:
Continue on Error:
Continue script execution even when an Error Occurs.
Generate snap shot on Error:
It will generate the snap shot for every Error you can verify them in Result file (or) Controller
vuser log (by clicking camera symbol).
Q: Where we can find a screen shot?
A: Go to the vuser log and click on the camera symbol. Navigate to the LG results path and you can find HTML page for every error
Multithreading:
Run vuser as a process:
For all client server apps (SAP GUI or Desktop based apps. EX: SAP GUI/ Calculator) you have to run vuser as a Process.If we are running vuser as a process every vuser required one MDRV (Multi Driver Program) Engine.
Every MDRV engine required 5Mb memory in the LG Machine.
Running Vuser as a Thread:
For all web based applications you have to run vuser as a Thread. If you are running vuser as a thread multiple users will share one MDRV engine.
NOTE: Approximately 50 vusers use one MDRV engine.
Automatic Transaction:
Allow you to generate the automatic transactions to measure the response time.
7. Network:
Speed simulation:
It specifies to use maximum/ predefined/ custom band width for your test.
Usually we are using maximum bandwidth option until or unless there is a requirement, we are not going to use custom or advanced bandwidth.
If you like to test your application with a specific network bandwidth, then use custom or advanced bandwidth.
8. Browser Emulation:
It will allow you to use multiple browsers for test.
Note:
Prerequisites:
We should install the browser in the load generator.
1. Simulate browser cache: Enabling this option instructs the users to use or simulate cache
files from browser.
If disable this option, cache files will be deleted or will not be simulated.
2. Simulate a new user on each iteration: If the users are iterating for multiple times, we have
to make him behave like a new user on every iteration by enabling this option.
9. Internet Protocol:
Content check:
It is a global text verification option. Verifies the text on every page.
Note: web_reg_find is a local verification point.
Steps:
1. Create application by clicking new application.
2. Create a rule under the application.
3. Provide the text and match case.
4. You can export or import the rule and extension is “.xml”.
10. Proxy:
It will allow you to configure proxy settings for all requests. It will redirect all the requests to proxy server.
Options are
1) No proxy
2) Obtain proxy settings from browser
3) Custom proxy
11. Preferences:
1. Enable image and text check:
This option has to be enabled for web_find(), and web_image_check().
2. Wininet replay instead of socket:
For NTLM based applications or SSL based applications, you can use wininet replay.
If you don’t want to use web_set_socket option, then use wininet replay.
Options:
HTTP request connection time out: A unit time within which request connection
operation should finish. Default is 120 seconds.
HTTP request receive time out: A time unit within which receive operation should
finish. Default is 120 seconds.
Step Download time out: A time unit within which entire step has to be finished.
Default is 120 seconds.
12. Download filters:
To exclude or include specific URL, use download filter option.
Q: How to design shared RTS? (or) How to configure RTS for multiple scripts?
A: Two ways we can configure the shared RTS
1. Vugen level: Configure RTS in one script, copy “.cfg” and “.usp” files and paste into
remaining script folders.
2. Controller level: Select all scripts and choose shared RTS and configure the same.
Note: Whenever script having vary number of actions and names, you should not create shared RTS or should not copy “.cfg” and “.usp” files to some other scripts.
SLA configuration:
SLA configuration will allow you to compare derived statistics with expected statistics.
Step 1: Click on new under SLA
Step 2: Choose SLA measurement like total, average, throughput, hits per second, response time
and errors.
Step 3: Provide threshold point and click on finish.
Rendezvous test:
Rendezvous point is the point to instruct the users to wait at a certain location once the specified number of users arrived at that point. It will execute the subsequent request.
Syntax:
lr_rendezvous(“xyz”);
Step 1: Write the function in the script.
Step 2: Go to controller and select rendezvous under scenario.
Step 3: Configure the policy by providing number of users and timeout.
see the following screenshot to better understand.
No comments:
Post a Comment