Correlation Using Load Runner - Part1 - Chapter13

• Correlation General Description : Capturing Dynamic values from the preceding requests and substituting in the post request. 
• Example: for every login, you would notice "Welcome Login User". This login user will vary for the next user login. But our script which we recorded will have hard coded value of login user and when replayed it will try to login with same user and same login session. In this case, the existing session has already gone, but our script will try to make a login request with existing session, which make no sense and will return in failed request.
• Hence, correlation concepts helps us in identifying dynamic values, especially dynamic session ids, and will handle, so that the every requests, goes with updated or latest values returned from server.
• As a beginner, To identify dynamic values in the newly captured, we need to record same flow twice a time compare line by line and should trace the difference.
• Once the changes in values are identified, we need to take that dynamic value and should go to Generation Log(Output Pane-->Replay Drop down-->Code Generation). 
• Once Generation log is opened,Ctrl+home and search for the dynamic value occurrence.
• We should search the dynamic value and trace out that the dynamic value should be found in the response header.
• Once the dynamic value is found in the first response header, search for "add event", which is a key to identify on which particular request, this dynamic value is triggered from server.
• Once the request url is identified, go to script Action part--> search for the request name, and on the above the request name, we need to add correlation function "web_reg_save_param".
• Stay tuned for more learnings.

Parameterization Using Load Runner - Chapter-12

• Not all the users will use same username or password to access any application, hence to achieve this real world scenario, we have parameterization concepts, from which we can provide different data for every iteration.
• Parameter settings can be opened by doing two ways
• Press Ctrl+L in Vugen
• Double clicking below option.

• 
  

• Click New -->Parameter name example "p_Username" --> Click Create Table --> Typer actual user name(jojo) to be substituted. --> Close
• Search for the actual username in the script. i.e find "jojo" in script. Select the value to be handled for parameterizing--> right click --> Replace Parameter --> p_Username. Accept alert message. Similarly for Password.
• Now you can add more usernames and their respect passwords by clicking "add Row" in the parameter table, so that for every iteration, new username or new parameter value would be selected.
• On the Parameter dialog box, we have option, to pick same parameter for all iterations, or unique values etc. You can choose according to your need.
• We have another settings that will help us during scripting. i.e parameter types.
• Date/Time
• Iteration number
• Random Number and so on.
• We have one more option called "Simulate parameter", Using this, we can simulate how the parameters values should be segregated according to number of users. Simulate parameter option is available in the same Parameter dialog box.
• Stay Tuned for more learning's.

Page Validation Using Load Runner - Part2 - Chapter11

• Continuing Page validation from Part1-Chapter11..
• The text which we picked to compare with response body, if it is converted to Capital letters or small letters.Then the error messages would be thrown as text not found. 
• Hence to overcome this, we can use additional attribute("IC") to suffix the attribute "Text=". Example : web_reg_find("Text\IC=Welcome Yasir", "SaveCount=TxtChk_Login", LAST);
• We have two ways to add web_reg_find. 
• One is by typing the code manually
• The second one is by following below
• vugen--> Right click on Request-->Show Snapshots --> Replay-->Page View -->Drag and Select the text from web page that needs validation-->Right click on the selected text --> Select "Add Text Check Setup" --> Modify Text Check settings and click OK.

• To view the number of occurances of the SaveCount in output log, we need to enable Log prior to it. Run time Settings-->Log-->Extended Log-->"Parameter Substitution".
• Once SaveCount value is found, based on it, we can write customized page validation code below to validate webpage. if the expected page is not loaded, then we will fail the transaction with customized error message as expected page is not loaded.
• web_reg_find("Text=jojo",
          "SaveCount=TxtChk_Login",
          "Fail=NotFound",
          "Search=ALL",
          LAST);
• if(atoi(lr_eval_string("{loginChk}"))==0)
      {
              lr_end_transaction("UC01_Webtours_Login_01_Login",LR_FAIL);
              lr_error_message("Login Failed for %s",lr_eval_string("{p_LoginUser}"));
              lr_exit(LR_EXIT_ITERATION_AND_CONTINUE,LR_FAIL);
      }
      else
      {
      lr_end_transaction("UC01_Webtours_Login_01_Login",LR_AUTO);
      }
• Stay tuned for more leanings.

Page Validation using Load Runner - Part1- Chapter11

• Page validation is nothing but verifying, that the expected web page is loaded or not.
• This can be achieved using load runner function "web_reg_find".
• If expected text is not found in the response body of the request or in webpage, then it will fail the transaction and stop the script run.
• web_reg_find function should be placed before web requests.
• The important attributes of web_reg_find are "Text=", "SaveCount=", "Fail=", "Search=" and "RealFrameID".
• "Text=" : In this attribute, we will keep the particular text from the web page which should be validated. Example: web_reg_find("Text =Welcome Yasir"
• "SaveCount=" : SaveCount plays a vital role in page validation. The notable thing is, if the SaveCount attribute is specified in web_reg_find, though the expected text is not found, the transaction will pass and the script will run till the end of line. If the log is enable run time settings, then the number of occurances of the expected text will be printed in output under save count parameter name. Example: "web_reg_find("Text=Welcome Yasir", "SaveCount=TxtChk_Login"  where TxtChk_Login is a user-defined text to store the number of occurances of the expected text "Welcome Yasir".
• "Search=": In this attribute, we will specify that the search should be made on body or request header or response headers or ALL. Example: web_reg_save_param("Text=Welcome Yasir", "SaveCount=TxtChk_Login, "Search=Body",LAST"). LAST is the load runner default attribute which denotes till last line of the request, the search should be made.
• "RealFrameID=": RealFrame id attributes are used if the expected text is not able to find by just keeping "Text=Welcome Yasir". We can check the response body and check for the RealFrameID, in which the particular text is exist and then we can specify the same. Important thing to not about RealFrameID is as per load runner limitation, RealFrameID is not supported in GUI level scripts. The minimum/default value is 1 and  zero is not permitted. If you are not aware on which frame the expected text exists, you can keep attribute value as "ALL". Example.web_reg_find("Text=Welcome Yasir", "SaveCount=TxtChk_Login", "RealFrameID=ALL", LAST);
• "Fail=" : This attribute can be used to check two different conditions.
• If the expected text is found, then pass/faill transactions
• If the expected text is notfound, then pass/fail the transactions. 
• Example: web_reg_find("Text=Welcome Yasir", "SaveCount=TxtChk_Login", "Search=Body", "Fail=NotFound", LAST);
• Example: web_reg_find("Text=Welcome Yasir", "SaveCount=TxtChk_Login", "Search=Body", "Fail=Found", LAST);
• "Fail=Found" can be used to check if any error message or error code is received from the server response, and the respective transaction can be made to fail.
• Example: web_reg_find("Text=HTTP Internal Server Error 500", "SaveCount=TxtChk_Login", "Search=Body", "Fail=Found", LAST);
• Stay tuned for more learnings.

Run Time/Replay Settings - Load Runner - Part_3 - Chapter10

• In Part2, we have covered, General -->Additional Attribute, Miscellaneous, Browser settings and Network. And Now, we will continue covering other run time settings.
• Internet Protocol:
• Content Check: If this is enabled, page validation concepts can be enabled.
• Proxy: 
• No Proxy: If selected, proxy would be disabled
• Use default browser's proxy settings: If selected, our script will use same proxy configured in browser.
• Use Custom Proxy: If selected, we can specify proxy url or proxy ip address so that the script will replay with proxy enabled.
• Authentication: This is were we will pass-on our proxy authentication credentials with domain. example: office\yasir.
• Preferences:
• In this section ,we have different runtime settings, in which let me list out only useful/important settings.
• Advanced : checkbox "Use wininet replay instead of socket", this option should be selected if the script is recorded with WINET recording options. The above option will helps to get successful replay many times. Particularly in web services scripts.
• HTTP: HTTP requests, replay timeout settings can be configured here.
• General: Step download timeout can be increased if received replay errors that exceeds step download timed out.
• Authentication: Enable/disable below options helps us in successful replay.
• Integrated authentication mode 
• Use the native Windows NTML implementation
• Override credentials in a Windows native NTML implementation
• JavaScript: Enable javascript to capture response time of java script function time.
• Download Filters:
• This feature helps us in including/excluding requests/url's implicitly.
• Data Format Extension:
• Enabling this will helps is formatting complex data.
• Stay tuned for more learnings. :-)

Run Time/Replay Settings - Load Runner - Part_2 - Chapter10

• In Part1, we have covered, General -->Run Logic, Pacing, Log and Think Time. And Now, we will continue covering other run time settings.
• Additional Attribute:
• Additional attributes are input values(Parameters) which can be passed during the run time or execution or load test.
• Using lr_get_attrib_string function, we can achieve this.
• Miscellaneous:
• Miscellaneous divided into three parts as below
• Error Handling
• Continue on Error: If this checkbox is enabled, the script will not exit until it reaches the last line of code. Though the errors are triggered.
• Fail open Transactions on lr_error _message: If this check box is enabled and if lr_error_message is placed inside transactions, the specific transactions will fail.
• Generate snapshot on error : If this option is enabled, then the page which failed to used will be captured as snapshot and would saved in script folder.
• Multi Threading: 
• Thread: If this radio button is selected, then the script will run with seperate threads/users.
• Process:If this radio button is selected, then the script for each user will run as a separate process which actually consume more memory and not advisable.
• Automatic Transactions: 
• Define Each action as a transaction: If this selection is made, then each actions inside script would be considered as transaction. i.e Vuser_Init, Vuser_End also would be considered as a transactions and that would be updated in result file.
• Define Each step as a transaction: If this selection is made, each step/requests in script would be treated as a transactions.
• Browser:
• Browser Emulation:
• Use Browser: This option can be selected if general details of browser names, versions are known and to emulate testing with different browsers.
• Use Custom: This option can be selected if clients wants to check particular version of browser with browser agent. This info would be provided by client.
• Browser Cache: Browser cache settings, this can be selected according to our needs. Notable, "Download Non-Html Resources" place vital role. If this option is disabled, the transaction response time would be less. But as a proper tester, this option should be enabled, so that all the components like .html, .css, .png would be downloaded and their respective response time would be calculated under transaction response time.
• Network:
• This option would not much used, but still based on the client requirement, the application can be testing different network speed.
• Stay Tuned for more learnings.

Run Time/Replay Settings - Load Runner - Part_1 - Chapter10

• Run time Settings are an important configurations, which should be adjusted according to our needs.
• Run time Settings are divided into four parts.
• General
• Browser
• Network
• Internet Protocol
• Data Format Extension:

• All the above cannot be explained in a single post as they will have sub sections. Hence we will segregate as different parts.
• General:
• Number of iterations can be configured.
• Run time order can be configured. i.e Action blocks can be re-arranged according to our needs.
• Pacing: 
• Pacing is an important topic that needs attentions. As of now will explain in general what is pacing and its standard options available. Later on another post, will explain in details about pacing.
• Pacing is a time different between every iteration.
• Three basic options available in Load Runner as below
• Start new iteration as soon as the previous iteration ends: This option can be selection if NO pacing is required. 
• Start new iteration after the previous iterations ends, with Fixed/Random delay of 60.00 second(s) : This option can be selected to enable pacing with specifying time in seconds, so that, the next iteration would wait till the specified threshold reaches and then starts new iteration.
• Start new iteration at Fixed/Random intervals, every 60.00 seconds(s): This option can be selected, if at any cost, the new iteration should be started with fixed or random time specified. i.e if kept 10 seconds as interval time, then for sure after 10 sec, the new iteration would be initiated, not waiting for the previous iteration to complete.
• Log:  
• Log is actually a trace.
• Enabling logging checkbox enables log.
• There are two options available for logging.
• Log Options:
• "Always option", enables log every time, you replay the script.
• "Log when error occurs and limit" : Log messages would be printed in replay log, if log size reached the specified threshold.
• Detail Level:
• Standard Log: if enabled, it will print what is the transactions called, and what is the status of the requests, whether it passed or not. 
• Extended Log: if enabled, it will print below details informations
• Parameters values subtitued
• Data returned by server. i.e server response for our web request. This helps us in correlations.(This will be explained later)
• Advance trace will print indepth details of the communication happened between request from client and response from server.
• Think Time: 
• This is to emulate the user interaction time delay. For example. the user hits the url and types username and password and click login button. this would take some 20 to 30 sec approx. so we would keep 20 sec think time above the login transaction to emulate the real world scenario.
• Four different options available as below
• Ignore think time
• Replay think time as recorded : This option enables the think time specified in our script.
• Multiple recorded think time by 1 : hardly we will use this.
• Use random think time: Approximate average think time can be configured.
• The remaining setting would be explained in different posts.
• Stay tuned for more learning's.