Parameterization and its properties.

What is parameter?

Static input to the server.
The values entered from keyboard are parametrized.Those are static values.

In the script View, select the string and right click on it. Then, select the replace with parameter.

     Type the Name of the parameter in the new opened small window / popup. You can also select it from drop down. Then, select parameter type from the parameter type list. You may select any of the available types:

1. Date/Time
2. File
3. Group Name
4.  Random number
5. Unique number
6. User defined function
7. Iteration Number
8. Table
9. XML
10. Vuser ID 
11.  LG Name
    
    Next, you may select next row as:

• Sequential
• Random
• Unique
• Same line as

At last, you will need to update values on:

Each iteration - It instructs the Vuser to use a new value for each iteration.

Each occurrence - It instructs the Vuser to use a new value for each occurrence of the parameter.

Once - It instructs the Vuser to update the value of the parameter only once during the execution.

Data wizard is a great option for Parametrization in LoadRunner.

Objectives of parametrization:

· One of the main objective of parametrization is to simulate real user behavior while running the test and we also use this to solve below problem.

· Solve Date constraints that may occur during playback

1. Eg : When Second Virtual User accessing the Application user may fail because of the       2/14/99 was yesterday!]

· Solve data caching that may occur during playback
1. Eg : When Second Virtual User accessing the Application, user will get data from Cache.

· Solve unique constraints that may occur during playback

    Eg : Order number 1234 is already here.

· Solve data dependency that may occur during playback

· Emulate real user activity

       Exercise the server (Some times when we are searching with same keyword, the request will not go to database and it will get the data from the webserver cache and it will not exercise the server. Parametrization will solve this problem)

How to create Parameters:

· Right click on the value and select “Replace with parameter” where we need to execute with different set of values.

· On the new window opened just give the Parameter name as user defined variable and Parmeter typeàselect any one from the drop down and Original Value will be default value and click on properties

· After clicking on properties new window will be opened then click on Edit with notepad button and enter some list of values.

Note: After entering values in notepad keep the cursor in new line and save the notepad and close it.



· After entering the different set of values we have to customize the parameter properties to execute the script as user’s perspective.

Parameter Customization:

1. Select Column By Number/ By Name

These values are used when we have multiple columns in the same table with the same parameter type. We can select for each parameter by number as column number or by name as column name.

2. File Format Column Delimiter

• First Data Line

Column Delimiter drop down has values Comma,Tab,Space which are used to separate multiple columns.

First Data Line is a number which it uses that number row data at the time of execution. For eg: if you increase the number to 2 by using up button then the execution starts from 2nd row data.

3. Select Next Row à Sequential

• Random
• Unique

Update Value on Each Iteration

•  Each Occurrence
• Once

If you select Select Next Row as Sequential and Update Value On as Each iteration then the users will execute the data sequentially for each iteration.

Click on close button and press CTRL+L buttons then parameter properties window will open with all parameters in left side and right side parameters data window.

If you click on Simulate Parameter button and then enter the iterations in check box and then click on simulate button then we will get the user behavior when the time of execution how the parameters will pass to the vusers.



If you select Update value on as Each Occurrence we can not simulate the parameter.

If you select Update value on as Once then the Vuser will take only one set of data for all Vusers. For ex: In the above snapshot we will get jojo and bean for each and every vuser we execute.

If you select Select Next Row as Random and Update value on as Each iteration then the user will pick random data for each and every iteration. At that we have to select for one parameter these values and select Same line as that parameter name for remaining parameters

For Ex: If we select Random Each iteration for Username then we have to select Same line as username for password.

If you select Select Next Row as Unique and Update value on as Each Iteration or Each Occurrence then automatically When Out of Values and Allocate Vuser values in the controller will be enabled.

When Out Of Values Abort Vuser

• Continue in a cyclic manner
• Continue with last value

Allocate Vuser values in the controller(Radio Buttons):

Automatically allocate block size
Allocate ______ values for each Vuser

If you have values less than vusers at that time we have to select Unique Each Iteration Abort Vuser then what ever the users extra are aborted from the execution.

OR

We can select Unique Each Iteration-Continue in a cyclic manner

OR

We can select Unique Each Iteration-Continue with last value

And we can select any of the two radio buttons for Allocate vuser values in the controller in the above three different cases

If you select Unique Each Occurrence only
Allocate ______ values for each Vuser will be enabled for all the three cases

And you can click on Simulate Parameter button for each and every different options customized to view how the Vuser behavior.

If you select Unique Once all the Vusers will execute with one set of data.
Once parametrization is done click on close button. Test the data execution procedure in the form of iterations in VUGen.

Performance Test Work Flow

 #1. Requirement Analysis/Gathering

Performance team interacts with the client for identification and gathering of requirement – technical and business. This includes getting information on application’s architecture, technologies and database used, intended users, functionality, application usage, test requirement, hardware & software requirements etc.

#2. POC/Tool selection

Once the key functionality are identified, POC (proof of concept – which is a sort of demonstration of the real time activity but in a limited sense) is done with the available tools. The list of available performance test tools depends on cost of tool, protocol that application is using, the technologies used to build the application, the number of users we are simulating for the test, etc. During POC, scripts are created for the identified key functionality and executed with 10-15 virtual users.

#3. Performance Test Plan & Design

Depending on the information collected in the preceding stages, test planning and designing is conducted.
Test Planning involves information on how the performance test is going to take place – test environment the application, workload, hardware, etc.
Test designing is mainly about the type of test to be conducted, metrics to be measured, Metadata, scripts, number of users and the execution plan.
During this activity, a Performance Test Plan is created. This serves as an agreement before moving ahead and also as a road map for the entire activity. Once created this document is shared to the client to establish transparency on the type of the application, test objectives, prerequisites, deliverable, entry and exit criteria, acceptance criteria etc.

Briefly, a performance test plan includes:

a) Introduction (Objective and Scope) b) Application Overview
c) Performance (Objectives & Goals) d) Test Approach (User Distribution, Test data requirements, Workload criteria, Entry & Exit criteria, Deliverable, etc.) e) In-Scope and Out-of-Scope f) Test Environment (Configuration, Tool, Hardware, Server Monitoring, Database, test configuration, etc.) g) Reporting & Communication h) Test Metrics i) Role & Responsibilities j) Risk & Mitigation k) Configuration Management

#4. Performance Test Development

• Use cases are created for the functionality identified in the test plan as the scope of PT.
• These use cases are shared with the client for their approval. This is to make sure the script will be recorded with correct steps.
• Once approved, script development starts with a recording of the steps in use cases with the performance test tool selected during the POC (Proof of Concepts) and enhanced by performing Correlation (for handling dynamic value), Parameterization (value substitution) and custom functions as per the situation or need. More on these techniques in our video tutorials.
• The Scripts are then validated against different users.
• Parallel to script creation, performance team also keeps working on setting up of the test environment (Software and hardware).
• Performance team will also take care of Metadata (back-end) through scripts if this activity is not taken up by the client.

#5. Performance Test Modeling

Performance Load Model is created for the test execution. The main aim of this step is to validate whether the given Performance metrics (provided by clients) are achieved during the test or not. There are different approaches to create a Load model. “Little’s Law” is used in most cases.

#6. Test Execution

The scenario is designed according to the Load Model in Controller or Performance Center but the initial tests are not executed with maximum users that are in the Load model.
Test execution is done incrementally. For example: If the maximum number of users are 100, the scenarios is first run with 10, 25, 50 users and so on, eventually moving on to 100 users.

#7. Test Results Analysis

Test results are the most important deliverable for the performance tester. This is where we can prove the ROI (Return on Investment) and productivity that a performance testing effort can provide.




Some of the best practices that help the result analysis process:

a) A unique and meaningful name to every test result – this helps in understanding the purpose of the test
b) Include the following information in the test result summary:

• Reason for the failure/s
• Change in the performance of the application compared to the previous test run
• Changes made in the test from the point of application build or test environment.
• It’s a good practice to make a result summary after each test run so that analysis results are not compiled every time test results are referred.
• PT generally requires many test runs to reach at the correct conclusion.
• It is good to have the following points in result summary:
  • Purpose of test
  • Number of virtual users
  • Scenario summary
  • Duration of test
  • Throughput
  • Graphs
  • Graphs comparison
  • Response Time
  • Error occurred
  • Recommendations

There might be recommendations like configuration changes for the next test. Server logs also help in identifying the root cause of the problem (like bottlenecks) – Deep Diagnostic tools are used for this purpose.
In the final report, all the test summaries are consolidated.

#8. Report

Test results should be simplified so the conclusion is clearer and should not need any derivation. Development Team needs more information on analysis, comparison of results, and details of how the results were obtained.
Test report is considered to be good if it is brief, descriptive and to the point.
The following guidelines will smooth this step out:

• Use appropriate heading and summary
• Report should be presentable so that it can be used in the management meetings.
• Provide supporting data to support the results.
• Give meaningful names to the table headers.
• Share the status report periodically, even with the clients
• Report the issues with as much information and evidence as possible in order to avoid unnecessary correspondence

The final report to be shared with the client has the following information:

• Execution Summary
• System Under test
• Testing Strategy
• Summary of test
• Results Strategy
• Problem Identified
• Recommendations

Along with the final report, all the deliverable as per test plan should be shared with the client.

web_url and web_link in LoadRunner

Points to note with web_url and web_link:

• web_url is not a context sensitive function while web_link is a context sensitive function.
  
          Context sensitive functions describe your actions in terms of GUI objects (such as windows, lists, and buttons). Check HTML vs URL recording mode.
  
  
• If web_url statement occurs before a context sensitive statement like web_link, it should hit the server, otherwise your script will get error’ed out.
  
• While recording, if you switch between the actions, the first statement recorded in a given action will never be a context sensitive statement.
  
• The first argument of a web_link, web_url, web_image or in general web_* does not affect the script replay. For example: if your web_link statements were recorded as
  web_link("Hi There", "Text=Hello, ABC", LAST);

  
  

  
  

  web_link("Hi There", "Text=Hello, ABC",       LAST);  Now, when you parameterize/correlate the first argument to web_link("{Welcome to LearnLoadRunner}", "Text=Hello, ABC",

  
  

  web_link("{Welcome to LearnLoadRunner}",          "Text=Hello, ABC",          LAST);

  On executing the above script you won’t find the actual text of the parameter {Welcome to Learn LoadRunner} instead you will find {Welcome to Learn LoadRunner} itself in the execution log. However to show the correlated/parameterized data you can use lr_eval_string to evaluate the parameter.

How to open and run LoadRunner Controller scripts from command line

This feature can decrease tester's manual efforts and thereby to increase your effectiveness and performance.

You can open LoadRunner Controller scenario with:

LoadRunner\bin\Wlrun.exe -Run -TestPath scenario.lrs -ResultName res_folder

For example:

As a result of above command, LoadRunner Controller:

• starts
• opens Controller scenario
• executes it
• saves results to folder 'C:\Temp\LR_Res\result_0'

After that, Controller finishes working and closes.

Please, see files from created 'C:\Temp\LR_Res\result_0' folder:

Tips: As you see, there is LoadRunner Result file (result_0.lrr). You can pass it automatically to LoadRunner Analysis for further processing.
Refer for detailed information: Custom HTML report in LoadRunner Analysis from command line.

Actually, Wlrun.exe can have several settings. There are their descriptions from HP LoadRunner Controller User's Guide (© HP/Mercury Interactive):

TestPath	Path to the scenario. For example, C:\LoadRunner\scenario\Scenario.lrs If the path includes blank spaces, use quotation marks.
Run	Runs the scenario, dumps all output messages into res_dir\output.txt and closes Controller
InvokeAnalysis	Instructs LoadRunner to invoke Analysis upon scenario termination. If this argument is not specified, LoadRunner uses the scenario default setting.
ResultName	Full results path. For example, "C:\Temp\Res_01"
ResultCleanName	Results name. For example, "Res_01"
ResultLocation	Results directory. For example, "C:\Temp"

Note: ResultName (full path) = ResultLocation (directory) + ResultCleanName (name)

Well, let's see different variants of how to open and run LoadRunner Controller script:

Open LoadRunner Controller:

Wlrun.exe

Open LoadRunner Controller scenario 'scenario.lrs' and do not execute it:

Wlrun.exe -TestPath scenario.lrs

Open LoadRunner Controller scenario 'scenario.lrs', execute it, and save results to default folder ('C:\Documents and Settings\user_login\Local Settings\Temp\res'):

Wlrun.exe -Run -TestPath scenario.lrs

Open LoadRunner Controller scenario 'scenario.lrs', execute it, and save results to 'res_folder' folder:

Wlrun.exe -Run -TestPath scenario.lrs -ResultName res_folder

Open LoadRunner Controller scenario 'scenario.lrs', execute it, save results to 'res_folder' folder, and after that start Analysis on created results with default template:

Wlrun.exe -Run -TestPath scenario.lrs -ResultName res_folder -InvokeAnalysis

And please see more complex example for desert :)

Open LoadRunner Controller scenario 'scenario.lrs', execute it, save results to 'res_folder' folder, and after that start Analysis on created results with default template. Repeat all these steps 10 times:

set LR_HOME=C:\Program Files\Mercury\LoadRunner
for /L %%i in (1,1,10) do "%LR_HOME%\bin\Wlrun.exe" -Run -TestPath "%LR_HOME%\scenario\memory_leak_crash.lrs" -ResultName C:\Temp\LR_Res\result%%i

Result is:

Well, where to use execution from a command line?

It can be very useful in some cases, when you plain to:

• run LoadRunner Controller and pass its results to LoadRunner Analysis
• run LoadRunner scripts by schedule

Importance of Transaction response time & how it is calculated in LR.

      Transaction Response Time represents the time taken for the application to complete a defined transaction or business process.

Why is important to measure Transaction Response Time?

     The objective of a performance test is to ensure that the application is working perfectly under load. However, the definition of “perfectly” under load may vary with different systems.

      By defining an initial acceptable response time, we can benchmark the application if it is performing as anticipated.

       The importance of Transaction Response Time is that it gives the project team/ application team an idea of how the application is performing in the measurement of time. With this information, they can relate to the users/customers on the expected time when processing request or understanding how their application performed.

What does Transaction Response Time encompass?

The Transaction Response Time encompasses the time taken for the request made to the web server, there after being process by the Web Server and sent to the Application Server. Which in most instances will make a request to the Database Server. All this will then be repeated again backward from the Database Server, Application Server, Web Server and back to the user. Take note that the time taken for the request or data in the network transmission is also factored in.

To simplify, the Transaction Response Time comprises of the following:

• Processing time on Web Server
• Processing time on Application Server
• Processing time on Database Server
• Network latency between the servers, and the client

The following diagram illustrates Transaction Response Time.

Transaction Response Time = (t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 + t9) X 2
Note:Factoring the time taken for the data to return to the client.

How do we measure Transaction Response Time?

     Measuring of the Transaction Response Time begins when the defined transaction makes a request to the application. From here, till the transaction completes before proceeding with the next subsequent request (in terms of transaction), the time is been measured and will stop when the transaction completes.

Differences with Hits Per Seconds and Transaction Response times?

     Hits per Seconds measures the number of “hits” made to a web server. These “hits” could be a request made to the web server for data or graphics. However, this counter does not represent well to users on how well their applications is performing as it measures the number of times the web server is being accessed.
How can we use Transaction Response Time to analyze performance issue?
     Transaction Response Time allows us to identify abnormalities when performance issues surface. This will be represented as slow response of the transaction, which differs significantly (or slightly) from the average of the Transaction Response Time.

With this, we can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the point of time and the system-related metrics (e.g. CPU Utilization) to identify the root cause.

Bringing all the data that have been collected during the load test, we can correlate the measurements to find trends and bottlenecks between the response time, the amount of load that was generated and the payload of all the components of the application.
How is it beneficial to the Project Team?

     Using Transaction Response Time, Project Team can better relate to their users using transactions as a form of language protocol that their users can comprehend. Users will be able to know that transactions (or business processes) are performing at an acceptable level in terms of time.

      Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance-related issues.

How to use LoadRunner for broken links detection

Broken' link is 'not valid' link. This link usually returns 404 Error - "Page not found".

Another side of broken links is that images other resources are not displayed.

Using LoadRunner for broken links detection can be helpful, when you perform load testing of a site and you have to be sure, that all pages, images, applets, and other resources are available during the high server loading.

LoadRunner allows broken links detection during:

1. Script recording
2. Script execution

1. Broken links detection during LoadRunner script recording
   You have to set appropriate recording options. For that, click 'Options...' button from 'Star Recording' dialog:
   
   'Recording Options' dialog opens. Here, set 'Add comment to script for HTTP errors while recording' option:
   
   
   
   Please, note that you can see a description of the 'Add comment to script for HTTP errors while recording' option.
   
   Now, you are ready to record your script. Click 'OK' button on 'Recording Options' dialog and start recording.
   
   If LoadRunner find any HTTP errors, it will include comment into VuGen script.
   My application had some problems - there were several broken links for images there. So, LoadRunner generated the following script (click the image to view enlarged):
   As you see, my application had several broken links to images and LoadRunner detected it successfully. Also, you can find the point, where these broken links were used. This is previous function - web_url.
   
   LoadRunner inserted comments, which describe all occurred HTTP errors. Comments contain URL and server response.
   Since you have server responses, you can determine reasons of HTTP errors.
   
   Tips: For detailed info on HTTP status codes read this article from wikipedia and this one from w3.org.
   Tips: Read about the most 'popular' HTTP status code - 404.


2. Broken links detection during LoadRunner script execution
   LoadRunner can check broken links during the script execution too.
   You have to turn off one LoadRunner run-time option - 'Non-critical resource errors as warnings':
   
   Uncheck the 'Non-critical resource errors as warnings' option and execute previous script again.
   
   The result is:
   Please, note that LoadRunner's Replay Log contains errors about images we mentioned before. Their links were broken, that's why LoadRunner generated errors.

Brief Explination on Soak Testing

Soak testing :-

     Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify any performance problems that appear after a large number of transactions have been executed.

Also, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed due to memory leaks or other defects. Soak tests provide an opportunity to identify such defects, whereas load tests and stress tests may not find such problems due to their relatively short duration.



The above diagram shows activity for a certain type of site. Each login results in an average session of 12 minutes duration with and average eight business transactions per session.

A soak test would run for as long as possible, given the limitations of the testing situation. For example, weekends are often an opportune time for a soak test. Soak testing for this application would be at a level of 550 logins per hour, using typical activity for each login.

The average number of logins per day in this example is 4,384 per day, but it would only take 8 hours at 550 per hour to run an entire days activity through the system.

By Starting a 60 hour soak test on Friday evening at 6 pm (to finish at 6am Monday morning), 33,000 logins would be put through the system, representing 7½ days of activity. Only with such a test, will it be possible to observe any degradation of performance under controlled conditions. 

Some typical problems identified during soak tests are listed below:
Serious memory leaks that would eventually result in a memory crisis, Failure to close connections between tiers of a multi-tiered system under some circumstances which could stall some or all modules of the system. 

Failure to close database cursors under some conditions which would eventually result in the entire system stalling. Gradual degradation of response time of some functions as internal data-structures become less efficient during a long test.

Apart from monitoring response time, it is also important to measure CPU usage and available memory. If a server process needs to be available for the application to operate, it is often worthwhile to record it's memory usage at the start and end of a soak test. It is also important to monitor internal memory usages of facilities such as Java Virtual Machines, if applicable.

Long Session Soak Testing
When an application is used for long periods of time each day, the above approach should be modified, because the soak test driver is not Logins and transactions per day, but transactions per active user for each user each day.

This type of situation occurs in internal systems, such as ERP and CRM systems, where users login and stay logged in for many hours, executing a number of business transactions during that time. A soak test for such a system should emulate multiple days of activity in a compacted time-frame rather than just pump multiple days worth of transactions through the system.

Long session soak tests should run with realistic user concurrency, but the focus should be on the number of transactions processed. VUGen scripts used in long session soak testing may need to be more sophisticated than short session scripts, as they must be capable of running a long series of business transactions over a prolonged period of time.
Test Duration

The duration of most soak tests is often determined by the available time in the test lab. There are many applications, however, that require extremely long soak tests. Any application that must run, uninterrupted for extended periods of time, may need a soak test to cover all of the activity for a period of time that is agreed to by the stakeholders, such as a month. Most systems have a regular maintenance window, and the time between such windows is usually a key driver for determining the scope of a soak test.

A classic example of a system that requires extensive soak testing is an air traffic control system. A soak test for such a system may have a multi-week or even multi-month duration.

New features in LR 12 Version

New Release of LoadRunner 12 version

   The roadmap for LoadRunner 12 was presented at HP Discover Barcelona in December last year.  Now that the product has been released.



Key observations / new features are:
      Cloud-based load generators. HP describes this feature as "cloud bursting". Users now have the ability to provision load generators on AWS(Amazon Web Service) cloud servers from within LoadRunner or Performance Center. As well as this, the ports used to communicate between LoadRunner components such as Load Generators, Controllers, MI Listeners are user configurable through the new "network security manager" tool. This simplifies the setup process and allows more flexibility in distributed test networks or cloud-based test environments. It is even possible to configure different ports/proxies for each Load Generator.
Licensing - 50 vUsers free

We in the user community have been asking for this for a long time. Providing fully-functional applications that allow small-scale testing allow prolonged evaluations and proof-of-concept exercises. This is great, because it allows more people e.g. developers to get hands-on experience and see the potential benefits of using LoadRunner.

This is likely to improve the adoption rate for LoadRunner and prevent the erosion of market share to low-cost / no-cost providers of performance testing software.

All protocols are included in the "community edition" license, with the exception of GUI (UFT) and COM/DCOM protocols as well as those protocols in the "template" bundle (i.e. those vUser types whose scripts are manually created (rather than record/replay) such as C# .Net, VB .Net vUsers).

VUGEN improvements
There are a variety of improvements as you would expect.

 Key ones are: 

• The ability to review replay statistics for tests after each run.

• Including details on total connections, disconnections and bytes downloaded.

• The ability to edit common file types in the editor.

• Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.

• The ability to create scripts from Wireshark or Fiddler files.

• The ability to record HTML5 or SPDY protocols.

TruClient improvements 

   
TruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.

The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.
Linux Load Generator improvements
Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and Windows Sockets scripts can now be replayed through UNIX load generators.

CI/CD support
Better integration with Jenkins etc.

Platform support
Support for installation on Windows Server 2012.
(LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).
LoadRunner components can now run in a "non-admin" user account with UAC and DEP enabled.

There are numerous other improvements which are well documented in the "About LoadRunner" section in LoadRunner help. Now that the community license is available, there's nothing stopping you from downloading it and giving it a go.

To get your own copy, navigate to www.hp.com/go/loadrunner and follow the links to download LoadRunner .

Way to connect the PC Host with PC11 if firewall is the bottleneck?

Process to connect the PC Host with PC11 if firewall itself is the bottleneck

How to identify the SSL protocols and certificates used by a website when testing with LoadRunner.

Understanding the SSL Protocols and certificates used by a website.
Solution -
   
        To identify the type of SSL and certs used on a web server, type the following commands from a Loadrunner client workstation :

• Go to the Loadrunner/bin directory.
• Type "openssl", this will then display an >openssl prompt.
• Type "s_client - connect www.test.com:443" where test.com is your web site.

This will then return details of the web servers SSL configuration.

Other usefull commands to use in LoadRunner Web protocol scripts are as follows:

web_set_sockets_option("SHUTDOWN_MODE", "FAST"); ----->Allows the disconnection of the SSL session to be completed quickly.

web_set_sockets_option("SSL_VERSION", "TLS");
web_set_sockets_option("SSL_CIPHER_LIST", "RC4-MD5");

These options allow the version and cipher for SSL to be specified. Possible versions and ciphers are detailed in the Loadrunner Function Reference.

web_set_sockets_option("TRACE_SSL_IO","1"); ---> This option will detail all SSL IO in the normal vuser log.

web_set_sockets_option("PRINT_SSL_INFO","1");  ---->This option will detail the version and certificate used in the SSL configuration.

web_set_sockets_option("PROXY_INITIAL_BASIC_AUTH","0"); ---->This option disables the initial Basic authentication.

Errors in LoadRunner

Error: "License cannot be save in your installation directory. (Error code = -4) It will be used only for this session."

Solution:

Make sure that you have administrator privilege to the Controller. If you are accessing the Controller via the network, make sure that you have write access to the network.

 

Error “License security violation. Operation is not allowed”

Solution:

If you are applying “TEMPORARY” license, it will not work if LoadRunner was previously installed with a “TEMPORARY” or valid license key. You need to contact HP Customer Support for a valid license key.

 

Error “License key was generated with a version superior to your license manager. Upgrade your license manager”

Solution:

Make sure the HostID that was sent to HP Customer Support was generated from the correct LoadRunner version. If you sent the HostID of LoadRunner 7.6, but apply the license key on LoadRunner7.0 install, you will get this problem.

 

Error: “Cannot install license information, probably access to system resource was denied”

Solution:

This error indicates that you need to log in with local administrator permission, since you installed the product with administrator permission. If you still get the error after login as local administrator, run setlicensepermissions.exe from the \bin directory to change the registry permissions

 

Error: “License manager does not support objects of this type or license is invalid”

Verify the followings:

Check the properties of the license key. If you apply a license key that has components that does not come with that version of LoadRunner, you will get this error.

Example:Apply WAN emulation license (introduced in LoadRunner 7.6), or J2EE diagnostics (Introduced in LoadRunner 7.8 FP1) license on LoadRunner 7.5
Make sure that you are applying the license key on a machine where the license is generated for. In LoadRunner7.x, license keys are host lock. If you try to apply the license key on a separate machine, you will get this error.

 

"Memory violation error "in Load Runner

Reasons for this:

1. C pointer errors,C programming invalid declarations
2. Memory full
3. Not enough Memory for what you need to place in a defined space
4. Memory not yet allocated before attempting to use it
5. Memory allocated but not deallocated
6. Trying to copy a non pointer version of a datatype to a pointer defined version of a datatype, such as copying a character array to a pointer to a character array
7. Generally unless you have a hardware issue this is a developer error

lr_param_sprintf security issue when run over a firewall(Error: CCI security error: You are running under secure mode and the function lr_param_sprintf is not allowed in this mode. )

The function lr_param_sprintf sometimes causes a security issue in the script when run from Performance Center.

Error Message

Error: CCI security error: You are running under secure mode and the function lr_param_sprintf is not allowed in this mode.

This function causes an issue in Performance Center due to the way the function works and the way the Load Generators have been setup in the environment as this function does not work over a firewall.

Solution:This is an example of how function could be to generate a timestamp value –

lr_param_sprintf( "timeStamp" , "%ld", time(&t) );
An easier and workable way of which is

char strTime[10]; //timestamp variable
/*
-- -- -- -- -- -- -- --
Other code goes here
-- -- -- -- -- -- -- --
*/
lr_save_string( (char*)itoa( time(&t), strTime, 10 ), "timeStamp" );

 

 

 

WAN Emulation in LoadRunner

 

WAN emulation is free software. Developed by TCS, published by Free Software Foundation. It can modify or redistributed on terms of GNU General Public License version 2.

      Rigorous performance testing and optimization is a critical factor in the successful delivery of any business application. Yet frequently the performance of deployed applications doesn’t live up to business requirements or end-user expectations. One reason behind these unpleasant “surprises” is the fact that most performance staging labs only test the application with local users (in a local area network (LAN) environment), while the fully deployed application is used by a variety of end-users, some local and others accessing the application remotely over different network links. The different network conditions that exist between end-users and application servers have a tremendous effect on the overall performance that remote end-users experience. This deviation from performance test results obtained in the lab is further exacerbated for N-Tier applications where each tier may reside in a different geographical location with its own unique set of network conditions.
Network Emulation tools can be used to accurately replicate existing or projected conditions in the distributed production environment – including infrastructure, application traffic and the distribution of end-users.

To sum up on a high level — the benefits of using WAN Emulation tools are:

• WANem is a freeware.
• mitigate applications deployment risk
•  find errors before deployment
• test new WAN topologies and technologies
•  emulate remote users experience
• stress models of the network to find vulnerabilities

2.1 System Requirements:
Minimum an i386 based PC with 1 CPU, 512 MB RAM and 1 Network interface card – 100 Mbps (preferably 1 Gbps).

2.1 Applications supported by the WANem(but not limited to)

1. Web applications,
2. Video Streaming
3. Interactive applications – telnet like application.

2.2 Setting up WANem

WANem is distributed in the form of a bootable CD with Linux Knoppix O/S. This CD comes with WANem preinstalled. There are no installation steps. When an i386 architecture based PC is booted with the PC WANem is ready for use.

*Refer WANem user guide for more information on launching WANem and usage.

Drawbacks of WANem:

1. Multiple NIC cards when there is need for performing distributed load generation.

2. Dedicated PC required for WANem setup.

3. Network address translation needs to be done when a client application is running on a different network.

4. Cannot be integrated with LoadRunner.

5. Installation is relatively difficult.

Conclusion
   WAN emulation is free software and hence cost effective. Advanced network options present in WAN emulation keeps trust and usability of the tool on the same level as of any other contemporary network emulation tool.

wan emulation:

     Some times client may not have Load injectors in different geographic locations and want to generate load from different geographic locations and want to simulate the delays associated with a different geographic distribution using the load injectors in the lab. Then we need WAN emulation.

Below are some tips while using WAN Emulator.Running WAN Emulation over a firewall:

If the agent connection type is defined as HTTP with proxy, the proxy server must be excluded from WAN emulation. Exclude the proxy server using the Load Generators > Details > WAN Emulation dialog.

WAN Emulation does not support the token-ring and Ethernet-token ring hybrid interfaces.

The WAN Emulator driver installation will disconnect your open network connections.

To uninstall the WAN Emulator driver, run Uninstall WanDriver.bat from the WAN Emulator directory on the LoadRunner CD.

To reset the WAN Emulator driver, run msh_reset.exe from the LoadRunner bin directory, or from the WANEmulator directory on the LoadRunner CD.

It is recommended not to install the Network Analyzers software on the same load generator machine where WAN emulation resides. This may cause false readings and affect measurements.