Where you find that you can't use WinRunner for automation?

Winrunner through the time and tide has proved to be quite a useful functional testing tool. This tool developed by HP has proved to be outstanding when it comes to testing of the automated functional graphical user interfaces. 

With the aid of this wonderful testing tool the user interactions that took place on the graphical user interfaces of the software systems or applications can be successfully recorded and playedback. 

Winrunner is a complete functional test suite and can even be extended to work with the QTP (quick test pro). Through the years this functional test suite has been continuously providing its support to the enterprises for quality assurance. 

Out of all its functions three are considered to be the most important ones and have been mentioned below:

1. Captures the user interactions taking place on the GUI of the application software.

2.  Verifies the captured user interactions.

3.  Automatically replays all the recorded user interactions.

   All the above three functions ensure that the defects are identified and it is ensured that all the business processes are being carried out well. The Winrunner introduced the use of TSL in parameterization and customization of the input supplied by the user. 

    

    Even though there are many benefits of the winrunner, it does suffer from some limitations. One of those limitations is that the winrunner cannot be used everywhere for automation. This is the topic of discussion of this article that where and all the winrunner can’t be used for automation. 

   1.Testers have figured out a number of uses for the winrunner, however, its primary role will always be to act as a testing tool for functional testing of the software systems and applications.

    2. In many conditions the winrunner is often used for load testing by some of the developers. 

   3. What makes the winrunner so powerful is its realization of the real world user. 

   4. Using winrunner in cooperation with the loadrunner achieves even better result. All these reasons have made the winrunner quite important software in the market.

  Winrunner can’t be used for automation in three situations as mentioned below:

     1.The size of the project is quite small i.e., it is a small scale project.

    2.The project calls for the need of manual intervention and cannot do without  it.

     3.The project is quite complex and exhibits a different behavior every time.

    There are certain instances when it has been observed that the winrunner does not even take the protocol layer in to consideration.

    But however, in such instances it has recorded the user interactions and played them. The winrunner program has been coded in such a way that it appears as if the various commands are being carried out by a real human user. 

   

   For the winrunner to function properly, it is needed that it gains full control over the computer system. Once it gains control over the system, it is ready to record and play back the user events. This is the reason why a load test cannot be initiated whenever the generation of load is required. 

  

    For the winrunner to simulate n number of users you need to have n number of computers and install winrunner software on all of them. 

   For the winrunner to record the response time of the user it is necessary that it is implemented within a load test since it has to deal with the processing that will take place in the hardware components of the computer system.

What is meant by concurrency testing?

INTRODUCTION TO CONCURRENT TESTING

1. Concurrency testing employs many users at a time and therefore it is considered to be a type of multi- user testing.

2. Concurrency testing was invented in order to determine what happens if many users are accessing the same data base records, modules or application code.

3. Other than this, concurrency testing also identifies the use of single threaded code, dead locking, locking semaphores and locking and it is also effective in measuring the level of these aspects.

4. While carrying out the concurrency testing several users perform same kind of task on the same application and that too at the same time.

5. The application serves too many users at a time.

TOOLS FOR PERFORMING CONCURRENT TESTING
Several tools are available for performing concurrency testing but we would recommend you loadRunner since it helps you create concurrency at a point you wish.

- All you need to do is create a test scenario after you have recorded and improved your scripts using the virtual user generator.

- You can decide and add how many users you want your scripts to support.

- You should input the number of users in the controller component of this testing tool.

- There are several ways to add user like gradual ramp- up or spike, stepped etc.

- You can choose for yourself which way you want the users to be added.

- This is the most effective way to create concurrency.

- Apart from the multi user testing, the concurrency testing tests one application over the other one.

LEVELS OF CONCURRENCY TESTING
Two levels of concurrency testing have been developed so far and they have been discussed below:

# 1st Level:
- This involves concurrency tsting of one application being executed on the top of another application.

- We can illustrate this by a simple example; you receive an incoming call while playing some game on your cell phone. The game will go to paused state. This is the simplest example we can give.

# 2nd Level:
- This involves concurrency testing of one application being executed on the top of other two applications.

- This can also be illustrated with a similar example, you receive an incoming call while playing games and while you are on the call you receive an SMS. The game is paused.

- Apart from just testing the multi user capacity of the software, concurrency is also responsible for finding out the bugs like dead lock, live lock, data race and data corruption.

- These bugs usually occur when the parallel processing is implemented in the application.

- If you are also using the user scenario apart from the test scenario your concurrency testing will yield much better results.

- Some applications make use of more than one module where some accept parallel processing and other are sequential.

- Identifying the type of modules can help you in writing effective test cases against them which in turn will reflect in your testing.

This is the internet era. Almost everyone is using web and web applications all over the world. Such a huge number of users require great stress handling capacity for the servers. If the servers are not able to take the load they often slip in to the position of the dead lock.

Concurrency testing is a way to ensure that such kinds of situations do not occur. Therefore concurrency testing is important. Performance is the basic aspect that is tested most in the concurrency testing.

Number of users using the application at a time equals to the number of hits per second. With the growing number of internet users world wide more and more security is needed over the web. Concurrency testing is one such measure which has helped to a great extent for improving the cyber standards.

What is the need to execute Network Sensitivity Tests?

The three principle reasons for executing network sensitivity tests are as follows:
- Determine the impact on response time of WAN link.
- Determine the capacity of a system based on a given WAN link.
- Determine the impact on the system under test that is under dirty communications load.
Execution of performance and load tests for analysis of network sensitivity require test system configuration to emulate a WAN. Once a WAN link has been configured, performance and load tests conducted will become Network Sensitivity Tests.

There are two ways of configuring such tests:
- Use a simulated WAN and inject appropriate background traffic
This can be achieved by putting back to back routers between a load generator and the system under test. The routers can be configured to allow the required level of bandwidth, and instead of connecting to a real WAN, they connect directly through to each other.
When back to back routers are configured to be part of a test, they will basically limit the bandwidth. If the test is to be realistic, then additional traffic will need to be applied to the routers. This can be achieved by a web server at one end of the link serving pages and another load generator generating
requests. It is important that the mix of traffic is realistic.

For example, a few continuous file transfers may impact response time in a different way to a large number of small transmissions. By forcing extra more traffic over the simulated WAN link, the latency will increase and some packet loss may even occur. While this is much more realistic than testing over a high speed LAN, it does not take into account many features of a congested WAN such as out of sequence packets.

- Use the WAN emulation facility within LoadRunner
The WAN emulation facility within LoadRunner supports a variety of WAN scenarios. Each load generator can be assigned a number of WAN emulation parameters, such as error rates and latency. WAN parameters can be set individually, or WAN link types can be selected from a list of pre-set configurations.

It is important to ensure that measured response times incorporate the impact of WAN effects both at an individual session, as part of a performance test, and under load as part of a load test, because a system under WAN affected load may work much harder than a system doing the same actions over a clean communications link.

Overview of Reporting on response time at various levels of load, Fail-over Tests, Fail-back Testing

REPORTING ON RESPONSE TIME AT VARIOUS LEVELS OF LOAD
Expected output from a load test often includes a series of response time measures at various levels of load. It is important when determining the response time at any particular level of load, that the system has run in a stable manner for a significant amount of time before taking measurements.
For example, a ramp-up to 500 users may take ten minutes, but another ten minutes may be required to let the system activity stabilize. Taking measurements over the next ten minutes would then give a meaningful result. The next measurement can be taken after ramping up to the next level and waiting a further ten minutes for stabilization and ten minutes for the measurement period and so on for each level of load requiring detailed response time measures.

FAIL-OVER TESTS
Failover tests verify of redundancy mechanisms while the system is under load. This is in contrast to load tests which are conducted under anticipated load with no component failure during the course of a test. For example, in a web environment, failover testing determines what will happen if multiple web servers are being used under peak anticipated load, and one of them dies.
Failover testing allows technicians to address problems in advance, in the comfort of a testing situation, rather than in the heat of a production outrage. It also provides a baseline of failover capability so that a sick server can be shutdown with confidence, in the knowledge that the remaining infrastructure will cope with the surge of failover load.

FAIL-BACK TESTING
After verifying that a system can sustain a component outage, it is also important to verify that when the component is back up, that it is available to take load again, and that it can sustain the influx of activity when it comes back online.

How to set up a Load Test using LoadRunner?

The important thing to understand in executing such a load test is that the load is generated at a protocol level, by the load generators, that are running scripts that are developed with the VUGen tool. Transaction times derived from the VUGen scripts do not include processing time on the client PC, such as rendering (drawing parts of the screen) or execution of client side scripts such as JavaScript.The WinRunner PC(s) is utilized to measure end user experience response times. Most load tests would not employ a WinRunner PC to measure actual response times from the client perspective but is highly recommended where complex and variable processing is performed on the desktop after data has been delivered to the client.

The LoadRunner controller is capable of displaying real-time graphs of response times as well as other measures such as CPU utilization on each of the components behind the firewall. Internal measures from products such as Oracle, Websphere are also available for monitoring during test execution.
After completion of a test, the analysis engine can generate a number of graphs and correlations to help locate any performance bottlenecks.

In simplified load test, the controller communicates directly to a load generator that can communicate directly to the load balancer. No WinRunner PC is utilized to measure actual user experience. The collection of statistics from various components is simplified as there is no firewall between the controller and the web components being measured.

Drawbacks of Manual Performance testing and how does a LoadRunner work ?

Working of LoadRunner

- The Controller is the central console from which the load test was managed and monitored.
- Thousands of virtual users perform real-life transactions on a system to emulate traf c.
- Real time monitors capture performance data across all tiers, servers and network resources and display information on the Controller.
- Results are stored in the database repository, allowing users to generate the reports and perform analysis.

The LoadRunner automated solution addresses the drawbacks of manual performance testing:
• LoadRunner reduces the personnel requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users operating real applications.
• Because numerous Vusers can run on a single computer, LoadRunner reduces the hardware requirements.
• The LoadRunner Controller allows you to easily and effectively control all the Vusers from a single point of control.
• LoadRunner monitors the application performance online, enabling you to fine-tune your system during test execution.
- LoadRunner automatically records the performance of the application during a test. - LoadRunner checks where performance delays occur: network or client delays, CPU performance, I/O delays, database locking, or other issues at the database server.
- LoadRunner monitors the network and server resources to help you improve
performance.

What are different terminologies used in LoadRunner ?

Application performance testing requirements are divided into scenarios using LoadRunner.
- A scenario defines the events that occur during each testing sessions.
- A scenario defines and controls the number of users to emulate, the actions that they perform, and the machines on which they run their emulations.

Vusers
LoadRunner works by creating virtual users who take the place of real users operating client software. LoadRunner works by creating virtual users who take the place of real users operating client software. Vusers emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of
Vusers.

Vusers Scripts
The actions that a Vuser performs during the scenario are described in a
Vuser script. When you run a scenario, each Vuser executes a Vuser script. Vuser scripts include functions that measure and record the performance of the server during the scenario.

Transactions
Transactions are defined to measure the performance of the server. Transactions measure the time that it takes for the server to respond to tasks submitted by Vusers.

Rendezvous Points
Rendezvous points are inserted into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct multiple Vusers to perform tasks at exactly the same time.

Controller
LoadRunner Controller is used to manage and maintain your scenarios. Using the Controller, you control all the Vusers in a scenario from a single workstation.

Hosts
The LoadRunner Controller distributes each Vuser in the scenario to a host when the scenario is executed. The host is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user.

Performance Analysis
Vuser scripts include functions that measure and record system performance during load-testing sessions. During a scenario run, you can monitor the network and server resources. Following a scenario run, you can view performance analysis data in reports and graphs.

Overview of Mercury Interactive's LoadRunner and its Components

To test the performance requirements such as transaction response time of a database application or response time in the case of multiple users accessing a web site, LoadRunner is an excellent tool that reduces the infrastructure and manpower costs.
Mercury Interactive's LoadRunner is used to test the client/server applications such as databases and websites. Using LoadRunner, with minimal infrastructure and manpower, performance testing can be carried out.
- LoadRunner simulates multiple transactions from the same machine and hence it creates a scenario of multiple simultaneous access to to the application. So, instead of t=real users, virtual users are simulated. With virtual users simultaneously accessing the application, LoadRunner accurately measures and analyzes the performance of the client/server application.
In LoadRunner, we divide the performance testing requirements into various scenarios. A scenario is a series of actions that are to be tested. LoadRunner creates virtual users. The Vusers submit the requests to the server. Vuser script is generated and this script is executed for simulating multiple users.

LoadRunner Components

LoadRunner contains the following components:
- The Virtual User Generator captures end-user business processes and creates
an automated performance testing script, also known as a virtual user script.
- The Controller organizes, drives, manages, and monitors the load test.
- The Load Generators create the load by running virtual users.
- The Analysis helps you view, dissect, and compare the performance results.
- The Launcher provides a single point of access for all of the LoadRunner
components.