LoadRunner : Save Dynamic Parameter value in Text File

I have a  value which dynamic for each iteration. I have captured that value using web_reg_save_param(correlation) function. Please any enahncement in the script is most welcome….

Action_Main_URL()

{

 char MainID; 

 int i; 

 char Length[100]; 

 long file; 

 char * filename = “c:\\Session.txt”; 

 if ((file = fopen(filename, “a+” )) == NULL) 

 { 

 lr_output_message(“Unable to create %s”, filename); 

 return -1; 

 }

 web_reg_save_param( “Cor_Session_Id”, “LB= value=’”, “RB=’”, “Ord=6″, “IgnoreRedirections=Yes”, “Search=Body”, “RelFrameId=1″, LAST );

 web_url(“Workplace”,

  ”URL=http://server/Workplace”,

  ”Resource=0″,

  ”RecContentType=text/html”,

  ”Referer=”,

  ”Snapshot=t1.inf”,

  ”Mode=HTML”,

  LAST);

 lr_start_transaction(“TS_Main_URL_Login”);

 web_reg_find(“Text=Record Search and Check-In”, “SaveCount=Value_Count”,

  LAST);

 web_submit_data(“WcmSignIn.jsp”,

  ”Action=http://server/Workplace/WcmSignIn.jsp?eventTarget=signInModule&eventName=SignIn”,

  ”Method=POST”,

  ”RecContentType=text/html”,

  ”Referer=http://server/Workplace/WcmSignIn.jsp?targetUrl=WcmDefault.jsp&targetBase=http%3A%2F%2Fserver%2FWorkplace&sessionId={Cor_Session_Id}&originIp=10.x.x.x&originPort=”,

  ”Snapshot=t2.inf”,

  ”Mode=HTML”,

  ITEMDATA,

  ”Name=targetBase”, “Value=http://server/Workplace”, ENDITEM,

  ”Name=originPort”, “Value=”, ENDITEM,

  ”Name=targetUrl”, “Value=Default.jsp”, ENDITEM,

  ”Name=encodedSessionId”, “Value=null”, ENDITEM,

  ”Name=originIp”, “Value=10.x.x.x”, ENDITEM,

  ”Name=sessionId”, “Value={Cor_Session_Id}”, ENDITEM,

  ”Name=browserTime1″, “Value=Sat Jan 1 05 EST 2011″, ENDITEM,

  ”Name=browserTime2″, “Value=Wed Jun 15 05 EDT 2011″, ENDITEM,

  ”Name=browserOffset1″, “Value=300″, ENDITEM,

  ”Name=browserOffset2″, “Value=240″, ENDITEM,

  ”Name=clientTimeZone”, “Value=”, ENDITEM,

  ”Name=appId”, “Value=Workplace”, ENDITEM,

  ”Name=userId”, “Value=userid”, ENDITEM,

  ”Name=password”, “Value=password”, ENDITEM,

  EXTRARES,

  ”Url=images/web/common/Banner.jpg”, “Referer=http://server/Workplace/HomePage.jsp?mode=reset”, ENDITEM,

  LAST);

 if (atoi(lr_eval_string(“{Value_Count}”)) > 0)

  {

  lr_output_message(“Page found successfully.”);

  }

  else

   {

   lr_error_message(“Page is not found.”);

   lr_exit( LR_EXIT_MAIN_ITERATION_AND_CONTINUE,LR_FAIL );

  return(0);

   }

 lr_end_transaction(“TS_Main_URL_Login”,LR_AUTO);

 sprintf(Length,”\n%s,”,lr_eval_string(“{Cor_Session_Id}”)); 

 i = fwrite(&Length,sizeof(Length), 1, file); 

 if ( i > 0) 

 lr_output_message(“Successfully wrote %d record”, i ); 

 fclose(file);

 return 0;

}

Loadrunner tutorial

Loadrunner Tutorial 1

Advanced Load Runner from telab

LoadRunner Tutorial 2

Loadrunner presentation from abc

Requirement Gathering for Performance test Project

Here are the Ideal Requirements to be included while developing a Performance test plan.

• Deadlines available to complete performance testing, including the scheduled deployment date.

• Whether to use internal or external resources to perform the tests. This will largely depend on time scales and in-house expertise (or lack thereof).

• Test environment design agreed upon. Remember that the test environment should be as close an approximation of the live environment as you can achieve and will require longer to create than you estimate.

• Ensuring that a code freeze applies to the test environment within each testing cycle.

• Ensuring that the test environment will not be affected by other user activity. Nobody else should be using the test environment while performance test execution is taking place; otherwise, there is a danger that the test execution and results may be compromised.

• All performance targets identified and agreed to by appropriate business stakeholders. This means consensus from all involved and interested parties on the performance targets for the application. 

• The key application transactions identified, documented, and ready to script. Remember how vital it is to have correctly identified the key transactions to script. Otherwise, your performance testing is in danger of becoming a wasted exercise.

• Which parts of transactions (such as login or time spent on a search) should be monitored separately. This will be used in Step 3 for “checkpointing.”

• Identify the input, target, and runtime data requirements for the transactions that you  select. This critical consideration ensures that the transactions you script run correctly and that the target database is realistically populated in terms of size and content. Data is critical to performance testing. Make sure that you can create enough test data of the correct type within the time frames of your testing project. You may need to look at some form of automated data management, and don’t forget to consider data security and confidentiality.

• Performance tests identified in terms of number, type, transaction content, and virtual user deployment. You should also have decided on the think time, pacing, and injection profile for each test transaction deployment.

• Identify and document server, application server, and network KPIs. Remember that you must monitor the application landscape as comprehensively as possible to ensure that you have the necessary information available to identify and resolve any problems that occur.

• Identify the deliverables from the performance test in terms of a report on the test’s outcome versus the agreed performance targets. It’s a good practice to produce a document template that can be used for this purpose.

• A procedure is defined for submission of performance defects discovered during testing cycles to the development or application vendor. This is an important consideration that is often overlooked. What happens if, despite your best efforts, you find major application, related problems? You need to build contingency into your test plan to accommodate this possibility. There may also be the added complexity of involving offshore resources in the defect submission process. If your plan is to carry out the performance testing in-house then you will also need to address the following points, relating to the testing team.

How to Define Pacing in Load Testing

 Pacing Calculation :-



 D = Duration of the test(test window/time frame)
 B = Baseline time(total time taken by 1 Vu to complete 1 whole iteration)

 T = Total amount of Think time in the script

 I = Expected/Target iteration

 R = Residual time of the test window.

 R = ( D - (T + B)*I)

 P = Pacing interval

 Dividing the residual time by target iteration gives pacing interval

Hence:
 P = R/I 


D is pacing time.
(T + B)*I represents the duration of a scenario
and P is the waiting time before the next scenario