Author:Chaitanya M Bhatt

If your integrating QTP with LoadRunner, the only advantage compared
to RDP protocol is that the rate of success of replays of your
workflow script would be higher due to object recognition capability
of QTP(strictly avoid using analogue mode of recording, which would
defeat the whole purpose of this ordeal!)

Remember QTP approach never gives accurate transaction response time
results what so ever! All the client side activities like page
rendering time, client side internal processing time etc. would be
added to your response time.

Using QTP with LoadRunner is challenging. But I would like to give you few tips to make your job a little more simpler.

1. Make sure of the reason why you have chosen QTP approach. (This is very
very important.)
2. Now that you’re sure you’re left with only one option, make sure
you know the limitation of this approach.(also make sure the client is
informed about this!)
3. Make sure you have Windows NT installed on all the LoadGenerators
(Server OS can allow multiple user accounts to be created, which can
help you reduce total number of LoadGenerators. Example: 1
LoadGenerator with 32 Gb of memory and 2 quadcore processors with
Windows NT or Windows 2003 can probably have approximately 15 user
accounts with QTP installed seperately on all the user accounts.)
4. In the controller loadgenerator options, make sure you have atleast
2 or more terminals per session enabled in your terminal session
manager. This can help you spawn more than one qtp session on one user account.
( This option is very tricky! Do a very detailed proof of
concept before you go ahead with this.)
5. Make sure you have good amount of think time between page loads
which can help you avoid page sync failures.

Author: Mark McWhinney
Company: Portata, Inc. (http://www.portata.com)
Text give below is an extract from the white paper created by Mark McWhinney.

The intent of load testing is the same as functional testing or any other type of testing: to find problems before the end users do. However, load testing is not the same as functional testing. It has its own unique issues and its own critical success factors. This white paper describes some of the critical success factors that are unique or are particularly meaningful to load testing.

Planning
As with any project, the planning stage is the most critical to the project’s success. For load testing projects, the planning stage is even more critical. Load testing involves more parts of an organization than any other activity in application development. The people involved often include business owners, developers, architects, QA, database administrators, system administrators, network administrators, data center support staff, various managers, third party organizations and sometimes customers. Planning, coordinating and communicating must be done well to ensure the project’s success.

To further complicate the planning process, load test activities and load test results tend to be nebulous by their nature. Without good planning, it is all too easy to reach the end of a load test, find that the answer is “42″, and realize that you really do not understand what it means.

Goal Setting. The first step in a successful load test planning process is to define the specific goals of the project in objective terms. We find it useful to express the goals in the form of questions whose answer can only be a number or a yes/no. For example, “how many users can run order entry while maintaining 8 second response time or better for 90% of their transactions?”

SEI process. The goal setting step is the first step in the overall planning process that produces the load test plan. Portata uses the SEI Load Test Planning process. See our white paper on this process.

Staff Skills
Load testers need a variety of skills including many skills that functional testers usually do not have.

Experience. Load testers need in-depth knowledge about load testing and how to use the load test tools. The load test team should have at least one member who has run several successful load test projects.

Test Tool Certifications. Some tool vendors have load test tool certifications. Though the certifications are not a substitute for experience, they indicate that the load testers at least understand how the tools work.

Application. Load testing does not require as much knowledge of the application as functional testing does. In functional testing the testers cover every function, but in load testing the testers will execute just a few common paths through the application. However, the load testers should have some operational knowledge of the application to be tested or at least have access to a knowledgeable application user.

Application Usage. The intent of load testing is to emulate what real users will be doing with the application when it is deployed. Therefore, the load testers must also have access to someone who knows how the application is actually used in production or can at least make an informed estimate. That person will supply information about how users typically accomplish a particular task, how often tasks are performed, and how many users perform the tasks.

Systems. Load testers must have a good working knowledge of the software and hardware components of the application. These components may include web servers, application servers, database servers, operating systems, networks and network elements such as load balancers. The load testers need not have “guru” level knowledge of each of the components but should have operational knowledge and an understanding of the performance issues associated with the components. For example, a load tester should know what multi-way joins, indexes and spin counts are and what affect they have on a database server.

Protocols. Load tests are usually driven at the protocol level instead of the GUI level. This allows load generation machines to emulate many users. Load testers should understand the protocol(s) used at the point where the load test tool interfaces with the application to be tested. For web applications this is typically between the web browser and the web server. For load testing web applications a load tester should know both HTTP and HTML. Other commonly used protocols are SQL*Net, ODBC, and DCOM.

Communication. Load testers will work with many parts of an organization to coordinate activities, schedules and resources. Load testing is not a heads down coding exercise. Daily interaction with a variety of people requires good oral and written communication skills as well as good people skills.

If the load testers do not have sufficient communication and people skills, the project will require more management time to handle the planning, coordination and communication.

Support Staff
The load testers must have access to DBAs, application server administrators, network administrators, and system administrators. They are used on an as-needed basis to set up the test environment, provide access to the components, solve problems, and monitor the load test runs.

Load Test Lab
Test Servers. Management usually will not allow load tests to be performed on productions systems since the high load levels would interfere with production activities. Also, production activities may skew the load test results.

Unlike a lab for functional testing, a load test lab must be configured the same as the production environment in terms of component capacity and speed, otherwise the load test may not be accurate or even meaningful. For example, if a production machine has four CPUs then the test lab should be configured with a four CPU test machine.

Often it is cost prohibitive to duplicate the full production system in the test lab. Some possible workarounds are to use the production equipment in the test lab prior to deployment or to use the production infrastructure during off-business hours. Equipment can be rented or leased but there is typically a long leadtime for acquisition and set up so plan accordingly.

Databases. The database(s) in the test lab must be preloaded with either a copy of production data or dummy data that is similar in size and content to the production data. Databases that are too small will tend to give erroneously fast results and can obscure table scan and index problems.

Load Test Tools. Load test tools range from the low-end URL pingers to commercial-grade multi-protocol load generation and monitoring systems. Most applications that are worth load testing include business critical functions and dynamic data, which require the higher end tools.

The important features to have in a load test tool are:

Ability to parameterize data.
Ability to capture dynamic data and use on subsequent requests.
Application infrastructure monitoring.
Support for the application’s protocols.
The load test tools are not inexpensive, so allocate sufficient budget during the budget planning process.

Load Test Monitoring
Response time measurements indicate whether you have a problem and how bad it is, but they do not tell you why you have a problem, what the root cause is, or how to get rid of it. For that information you need to monitor the individual components in the application architecture. The components may include a web server, application server, database server, network and network elements such as firewalls, operating systems and server hardware.

The better load test tools have built-in monitors which measure the various components in real-time and report results verses the load levels applied at the time. If the load test tool that you will be using has the capability to monitor, the tool may require that monitoring agents be installed on the components and/or authorizations be granted to access the components in real time. If the tool does not have this capability, you must make provisions for staff to manually monitor the key components and integrate the results.

Author: James Pulley (www.powertest.com)
Text pulled out from LoadRunner google groups.

Geography is not destiny. Were that so I would likely be sitting on a farm
tractor bringing in a crop of cotton or tobacco. There are incredibly
competent LoadRunner/Performance testing professionals located all over the
world, India included. What draws the ire of many in the profession,
where I am just one individual willing to call it out, is that there are
many people working in the profession who lack the primary skills to be
successful. Yes, we can answer a question of how to lay a brick, so to
speak, but we really should be working with architects who have already
mastered these primary skills for construction. Such dramatically poor
skill bases damages the reputation of the firms providing the deficient
resources. The lack of success in performance testing efforts damages the
reputation of the industry. The lack of success with a given vendors’ tool
damages the reputation of the tool vendor. The low skill base contributes
dramatically increases the risk of deploying a new application into what
should be a very risk-averse discipline.

I should note that those individuals in India who are very skilled in the
performance discipline command rates which are equal to or higher than what
that same person would receive for superlative services anywhere in the
world. The market for solid performance testing skills is fairly uniform
no matter where you acquire those skills. So….for the price leaders
that do not train, do not mentor, toss your employees to the proverbial
performance test wolves and attack the very value foundation of the
profession to seek to draw revenue from, if you would just hire a little
more carefully, invest in proper education and mentoring, adhere to all of
the tenets of the software licenses for the software that you use (even if
you don’t like some of the restrictions) then you too could bill at a much
higher rate than what you currently command and you would have industry
professionals clamoring to be a part of your organization where they could
learn and expand their skills. Recruitment costs down, Bill Rates Up,
Margins Up, Customers better served, Total amounts paid by customer
engagement hold steady or decline due to improved efficiencies, Employees
higher up on Maslow’s hierarchy of needs, Vendors tool not tarnished by poor
implementation skills. Seems like a Win (employee), Win (organization),
Win (customer), Win (vendor), Win (industry) to me.

Author: Mike Kelly
(http://www.michaeldkelly.com/)

Continuing to learning about performance testing
The activity that you have the most control over is your own learning. I’ve been studying and doing performance testing for eight years, and I honestly still learn something new about performance testing almost every week. It’s a deep and rich specialization in software testing. There’s a lot to performance testing that still needs to be formalized and written down. It’s still a growing body of knowledge.

If your dream is performance testing, then you need to continue to learn. Reading articles, blogs, books and tool documentation is a good place to start. Attending conferences, training, workshops and local groups is a great place to meet others who have similar passions. If you don’t have opportunities like those, then join one of the many online communities where performance testers have a presence. Depending on your learning style, dialog and debate can be as great a teacher as reading, if not greater.

Finally, no learning is complete without practice. I’m so passionate about the topic of practice that I wrote an entire article on it (you can find it here). Many of the materials you read will include exercises. Work through them. Many of the conferences, training, and workshops you attend will show examples. Repeat them. Going through the work on your own, even if you already know the outcome, provides a different kind of learning. Some people learn best when the experience is hands-on.

For performance testing, I think a great place to start practicing is in the open source community. Given the nature of performance testing, most tool knowledge is transferable to other performance testing tools. Learning multiple open source tools will also give you different ideas for how you can solve a performance testing problem. Many times, our available tools anchor our thinking about how to approach the problem. If you’ve practiced with multiple tools, you’re more likely to have variety in your test approaches and solutions.

Once you know how to use a couple of performance testing tools, if you can’t seem to get the project work you need at your current employer, and you’re unwilling or unable to leave for another opportunity, then I recommend volunteering your time. There are a lot of online communities that help connect people who want to volunteer their technical talents to nonprofits or other community-minded organizations. Finding project work outside of your day job can be just as valuable as formal project work.

Start marketing your skills and abilities
If you’re serious about performance testing as a career, I recommend you start pulling together some marketing material. A resume is the place most people focus their limited marketing skills. That could be a good place for you to start as well. What story does your resume tell a potential employer? Is it that you’re a performance tester? How has each of your past experiences helped you develop a specific aspect of performance testing? Remember, one of the great challenges performance testing presents to practitioners is its variety. That makes it easy to relate a variety of experiences to the skills a performance tester needs.

Don’t forget to include your training on your resume. I’ve had to remind several people of classes they’ve attended, workshops they participated in, or people who have been an active member of an online community for years and have not included that on their resume. If it helps you tell the story of your expertise, get it on there. Include anything that shows an employer that you’re passionate about performance testing and you’re continuously learning more about it.

Depending on the types of companies you want to work for, or the types of projects you might want, a certification might be appropriate. Certifications relevant to performance testing aren’t just performance testing tool certifications. Appropriate certifications may also come in the form of programming languages (e.g., Java certification), networking (e.g., CCNA), application servers (e.g., WebSphere administrator certification), databases (e.g., Oracle certification), or even a certification in the context you want to work in (e.g., CPCU certification if you want to work in the Insurance industry). I’m not normally a big fan of certifications, but they are clear marketing products.

Finally, I think the best way to market yourself is to write. Start by being active in an online community. Answer questions on forums or debate ideas on mailing lists. As you learn, catalog your learning in a blog so others can benefit from your hard work. If you feel you’re really starting to understand a specific aspect of performance testing, try writing an article or paper on it (for example, email your idea to an editor at SearchSoftwareQuality.com — they’ll point you in the right direction for help if you need it). Present your idea at a conference or workshop. The more of a public face you develop by writing, the more you learn. My experience has been that people are very vocal in their feedback on what you write. You should get to learn a lot. Even if you don’t become the next Scott Barber, when a potential employer Googles your name, they’ll quickly see that you know something about performance testing and have a passion for it.

Align your project work with performance testing activities
Even if you can’t get performance testing projects at your current employer, you can still get project work that relates to performance testing. Does your team test Web services? See if you can get involved; it will get you experience with XML, various protocols and, often, specialized tools. Does your team test databases? See if you can get involved; it will get you experience with SQL and managing large datasets. Does your team write automated tests? See if you can get involved; it will get you experience programming and dealing with the problems of scheduled and distributed tests. Does your team do risk-based testing? See if you can get involved; it will get you experience modeling the risk of an application or feature and teach you how to make difficult choices about which tests to run. I could go on with more examples. Take your current opportunities and make them relevant for learning more about performance testing.

If you can’t get your own performance testing project, ask if you can work with someone else. What if you volunteer some of your time? What if you work under someone else’s supervision for a while? Work with your current manager to understand what factors are preventing them from giving you the opportunity. Perhaps they can’t give you the opportunity for a number of reasons out of their direct control. Perhaps they can, they just haven’t given it enough attention. After a conversation where you try to figure it out with them, you should have an idea of what opportunities are available at that company. Just recognize that sometimes you have to leave for different opportunities. If you do that, make sure you’re clear with your new employer as to what your expectations are.