Provides access to Mercury Interactive's extensive load testing infrastructure

With LoadRunner Hosted Virtual Users, organizations do not need to invest in additional hardware, software or bandwidth to increase their testing coverage. Mercury Interactive’s load testing infrastructure is available 24x7 and consists of load farms located worldwide. As a result, organizations can generate real-user loads over the Internet to stress their Web-based applications at any time, from anywhere.

Gives customers complete control over all load testing.

Testing groups create the scripts, run the tests and perform their own analyses. They can perform testing at their convenience and easily access all performance data to quickly diagnose performance problems.

Complements in-house solutions to provide comprehensive load testing.

By combining LoadRunner Hosted Virtual Users with Mercury Interactive's LoadRunner or another in-house load testing tool, operations groups can thoroughly load test their Web applications and Internet infrastructures from inside and outside the firewall.

Provides pre- and post-deployment testing.

At any time in the application lifecycle, organizations can use LoadRunner Hosted Virtual Users to verify performance and fine-tune systems for greater efficiency, scalability and availability. The application under test only needs to be accessible via the Web.

Software Testing Features and Benefits

. Provides pre- and post-deployment testing.
. Complements in-house solutions to provide comprehensive load testing.
. Gives customers complete control over all load testing.
. Provides access to Mercury Interactive's extensive load testing infrastucture.

XML Support

With LoadRunner's XML support, you can quickly and easily view and manipulate XML data within the test scripts

Enterprise Java Bean Testing

By testing EJB components with LoadRunner, you can identify and solve problems during the early stages of application development. As a result, you can optimize performance before clients have been developed and thereby save time and resources.

Goal-Oriented Testing with AutoLoad

The new AutoLoad technology allows you to pre-define your testing objectives beyond the number of concurrent users to streamline the testing process.

Data Wizard for Data-Driven Testing

LoadRunner's Data Wizard enables you to quickly create data-driven tests and eliminate manual data manipulation. It connects directly to back-end database servers and imports desired data into test scripts.

Web Transaction Breakdown Monitor for Isolating Performance Problems

Now you can more efficiently isolate performance problems within your architecture. LoadRunner's Web Transaction Breakdown Monitor splits end-to-end transaction response times for the client, network, and server and provides powerful drill-down capabilities.

Native ICA Support for Citrix MetaFrame

LoadRunner now supports Citrix's Independent Computing Architecture (ICA) for the testing of applications being deployed with Citrix MetaFrame. This support is the first native ICA load testing solution of its kind, jointly developed with Citrix.

JBuilder for Java IDE Add-in

LoadRunner now works with Borland's JBuilder integrated development environment (IDE) to create powerful support for J2EE applications. This add-in enables LoadRunner users who create J2EE applications and services with JBuilder to create virtual users based on source code within a JBuilder project.

Sun ONE Studio4 IDE Add-in

Mercury Interactive and Sun Microsystems have worked together to integrate LoadRunner with the Sun ONE Studio4 add-in.

WAN Emulation Support

This powerful feature set enables LoadRunner to quickly point out the effect of the wide area network (WAN) on application reliability, performance, and response time. Provided through technology from Shunra Software, this WAN emulation capability introduces testing for bandwidth limits, latency, network errors, and more to LoadRunner.

New Tuning Module Add-In

The LoadRunner Tuning Module allows customers to isolate and resolve system performance bottlenecks. Once the application has been stress tested using LoadRunner, the Tuning Module provides component test libraries and a knowledgebase that help users isolate and resolve performance bottlenecks.

LoadRunner Features & Benefits

. New Tuning Module Add-In
. WAN Emulation Support
. Sun ONE Studio4 IDE Add-in
. JBuilder for Java IDE Add-in
. Native ICA Support for Citrix MetaFrame
. Web Transaction Breakdown Monitor for Isolating Performance Problems
. Data Wizard for Data-Driven Testing
. Goal-Oriented Testing with AutoLoad
. Enterprise Java Bean Testing
. XML Support

Loadrunner Installation and Configuration

. I recommend that you put downloaded LoadRunner installation files and patches to a separate media such as a CD or USB drive. Then mark those files as read-only.
. Disable your anti-virus software (Symantec, McAfee, etc.) before invoking on installers.
. Virus Detection engines (such as Hauri versions since May 18) may find that program regtlb.exe (which registers/unregisters type libraries) to contain a "virus" they call "Backdoor.Win32.PoeBot.15872". Automatic repair by the virus remover will break those files.
The LR box comes with two CD's and this installation manual. Separate installation manuals are available for the Controller and Analysis modules.
The Windows CD autostarts to this initial screen for v7.8 and this initial screen for v8.0.
You can install just a single component (such as VuGen) by (ironically) selecting "Full install" and then the "Custom" option to check the specific components to install. However, due to a strange bug with v8.0, before you do that, first install the Load Generator, then return to install "custom" components.
The UNIX CD installs only the Load Generator (not the Controller or VuGen) on UNIX machines because the Controller and VuGen only run on Windows machines.
Zero fill machine names to t001, ... t010, etc. The LR Controller sorts machines named t1, t2, ... t10 as t1, t10, t2.

Loadrunner Virtual Users

Unlike a Winrunner workstation which emulates a single user's use of a client, LoadRunner can emulate thousands of Virtual Users.
Load generators are controlled by VuGen scripts which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session.
During run-time, threaded vusers share a common memory pool. So threading supports more Vusers per load generator.
The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded.
No additional license is needed to monitor standard web (HTTP) servers (Apache, IIS, and Netscape).

LoadRunner Architecture

Architecture Overview
LoadRunner works by creating virtual users who take the place of real users operating client software, such as Internet request sending requests using the HTTP protocol to IIS or Apache web servers.
Requests from many virtual user clients are generated by "Load Generators" in order to create a load on various servers under test.
These load generator agents are started and stopped by Mercury's "Controller" program.
The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings".
Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.
With Java clients, VuGen captures calls by hooking within the client JVM.
During runs, the status of each machine is monitored by the Controller.
At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.
Each HTML report page generated by Analysis includes a link to results in a text file which Microsoft Excel can open to perform additional analysis.
Errors during each run are stored in a database which can be read using Microsoft Access

Mercury LoadRunner

. How do you determine if an application or system will meet the needs of the business before going live?
. Are undetected application bottlenecks resulting in slowtime or downtime in production?
. Are you struggling to deploy business systems smoothly, with no performance surprises?
. How do you know if an application or system can scale to the desired level of usage in production?
Mercury LoadRunner® prevents costly performance problems in production by detecting bottlenecks before a new system or upgrade is deployed. You can verify that new or upgraded applications will deliver intended business outcomes before go-live, preventing over-spending on hardware and infrastructure. It is the industry-standard load testing solution for predicting system behavior and performance, and the only integrated load testing, tuning, and diagnostics solution in the market today. With LoadRunner web testing software, you can measure end-to-end performance, diagnose application and system bottlenecks, and tune for better performance – all from a single point of control. It supports a wide range of enterprise environments, including Web Services, J2EE, and .NET.
With LoadRunner, you can:
. Obtain an accurate picture of end-to-end system performance.
. Verify that new or upgraded applications meet specified performance requirements.
. Identify and eliminate performance bottlenecks during the development lifecycle.
Reduce Scripting Time by 80 Percent
LoadRunner now includes game-changing technology that reduces the script creation process down to a few simple mouse clicks. Web (Click and Script) for LoadRunner enables you to record scripts at a higher presentation layer. It automatically captures the most valuable scripting information to create succinct, intuitive, and self-explanatory scripts, reducing scripting time and maintenance by an average of 80 percent. These scripts are also much easier to maintain – since anyone can look at the scripts and quickly see what is going on in each statement. In addition, Web (Click and Script) lowers the technical skills needed to perform load tests.

Loadrunner Analysis

This tool takes the completed scenario result and prepares the necessary graphs for the tester to view.The tester can then make needed adjustments to the graph and then can prepare a Loadrunner report. The LR report is mostly in Word format with all the necessary graphs in them. Also, graphs can be merged to get a good picture of the performance. And This Software is widely used in the Industry.

Loadrunner Controller

Once a script is prepared in Vugen, it is run via the Controller. Each run is called as a scenario with some preset settings. LoadRunner provides for the usage of various machines to act as LoadGenerators. For example, to run a test of 100 users, we can use three or more machines with Loadgenerator installed in them. The tester will then provide the script and the name of the machine which is going to act as a load generator along with the number of users who are going to run from that machine. LoadRunner uses Monitors to monitor the performance of individual components. But each monitor is to be purchased separately from Mercury. Some monitors include Oracle Monitors, WebSphere Monitors, etc... Once a scenario is set and the run is completed, the result of the scenario can be viewed via the Analysis tool

Loadrunner Virtual User Generator

The Virtual User Generator (VuGen) allows a user to record and/or script the test to be performed against the application under test, and enables the performance tester to playback and make modifications to the script as needed. Such modifications may include Parameterization (selecting data for keyword-driven testing), Correlation and Error handling.
During recording, VuGen records a tester's actions by routing data through a proxy. The type of proxy depends upon the protocol being used, and affects the form of the resulting script. For some protocols, various recording modes can be selected to further refine the form of the resulting script. For instance, there are two types of recording modes used in LoadRunner Web/HTTP testing: URL based, and HTML based.

Create a Generic ARM

Associate this discovery policy with an agent group that contains the system running LoadRunner.
Save the policy and wait for LoadRunner to run to record the ARM transactions. Create a listing policy from the discovered transactions.

Schedule the LoadRunner script for playback

When monitoring transactions in a production environment, it is recommended that you check the status of the transaction on a regular basis. For example, you could create a LoadRunner script that logged into your web application every 5 minutes. To schedule LoadRunner to run automatically on a regular schedule, you can use a tool like Windows Scheduler that comes with the Windows operating system.

Click Start -> Control Panel -> Scheduled Tasks.
Click Add Scheduled Task and then click Next to start the wizard.



Click Browse.
Select mdrv.exe and click OK. An example location is C:\\Loadrunner\bin\mdrv.exe
Change the name of the job to be more descriptive. For example, you might use the name of a LoadRunner script, such as PlantsByWebSphere.



Select the frequency to run LoadRunner by clicking Daily and Next. Daily is the shortest interval.



Configure the schedules start date and time and click Next.



Enter the user name and password for the user who runs this job and click Next.



Select Open advanced properties for this task when I click Finish and click Finish.



Edit the Run field with the command line options to invoke the LoadRunner script.

See to the LoadRunner Help documentation for full command reference details. For example:
C:\\Loadrunner\bin\mdrv.exe
-usr C:\\LoadRunner\scripts\PlantsByWebSphere.usr
-out C:\\itcam\logs\PlantsByWebSphere.out
-lr_view -drv_log_flush -drv_log_file C:\\itcam\logs\
PlantsByWebSphere.log
-cci_debug -cci_trace
Select the Schedule tab.



Click Advanced.
Select Repeat task.
Edit the schedule to run as frequently as you want.
Click OK.

Prepare the LoadRunner script

After your LoadRunner script is tested and ready for production, run the instrument command to automatically ARM-instrument the script. The instrument command is located in:
/bin/instrument.cmd.
is the local file encoding.
(Optional)help print this message is the name of the file you want to instrument. Backups are created for all modified *.c files. They have the same file name with the extension .orig. The backups are written to the same directory as the originals.

Create a LoadRunner script

IBM Tivoli Composite Application Manager for Response Time Tracking can monitor any LoadRunner script and record any LoadRunner transaction, but it is specifically designed to correlate LoadRunner HTTP(s) web transactions with J2EE back end servers. Create a new or reuse an existing LoadRunner script.

Install LoadRunner

The following shows a sample environment:
Host 1 -- IBM Tivoli Composite Application Manager for Response Time Tracking management server
Host 2 (Windows only) LoadRunner IBM Tivoli Composite Application Manager for Response Time Tracking management agent Windows Scheduler or an equivalent scheduler.
Host 3 (optional if monitoring J2EE web transactions) IBM WebSphere or BEA WebLogic IBM Tivoli Composite Application Manager for Response Time Tracking management agent.

LoadRunner Introduction

LoadRunner is a test tool that records a set of steps (transactions) and plays them back while recording their availability and performance. Setting up LoadRunner to work IBM Tivoli Composite Application Manager for Response Time Tracking

Software Testing Tools

. LoadRunner
. WinRunner

Introduction

Software Testing is the process of executing a program or system with the intent of finding errors. Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Software is not unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes for software is generally infeasible.
Unlike most physical systems, most of the defects in software are design errors, not manufacturing defects. Software does not suffer from corrosion, wear-and-tear -- generally it will not change until upgrades, or until obsolescence. So once the software is shipped, the design defects -- or bugs -- will be buried in and remain latent until activation.
Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable -- and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out.
Discovering the design defects in software, is equally difficult, for the same reason of complexity. Because software and any digital systems are not continuous, testing boundary values are not sufficient to guarantee correctness. All the possible values need to be tested and verified, but complete testing is infeasible. Exhaustively testing a simple program to add only two integer inputs of 32-bits (yielding 2^64 distinct test cases) would take hundreds of years, even if tests were performed at a rate of thousands per second. Obviously, for a realistic software module, the complexity can be far beyond the example mentioned here. If inputs from the real world are involved, the problem will get worse, because timing and unpredictable environmental effects and human interactions are all possible input parameters under consideration.
A further complication has to do with the dynamic nature of programs. If a failure occurs during preliminary testing and the code is changed, the software may now work for a test case that it didn't work for previously. But its behavior on pre-error test cases that it passed before can no longer be guaranteed. To account for this possibility, testing should be restarted. The expense of doing this is often prohibitive.
An interesting analogy parallels the difficulty in software testing with the pesticide, known as the Pesticide Paradox : Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. But this alone will not guarantee to make the software better, because the Complexity Barrier principle states: Software complexity(and therefore that of bugs) grows to the limits of our ability to manage that complexity. By eliminating the (previous) easy bugs you allowed another escalation of features and complexity, but his time you have subtler bugs to face, just to retain the reliability you had before. Society seems to be unwilling to limit complexity because we all want that extra bell, whistle, and feature interaction. Thus, our users always push us to the complexity barrier and how close we can approach that barrier is largely determined by the strength of the techniques we can wield against ever more complex and subtle bugs.

Software Testing

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality.