This page contains summary descriptions of a number of load and performance tests. 
Load Tests
Load Tests are end to end performance tests under anticipated production load.  The primary objective of this test is to determine the response times for various time critical transactions and business processes and that they are within documented expectations (or Service Level Agreements - SLAs).  The test also measures the capability of the application to function correctly under load, by measuring transaction pass/fail/error rates.  This test is one of the most fundamental load and performance tests and needs to be well understood.
This is a major test, requiring substantial input from the business, so that anticipated activity can be accurately simulated in a test situation.  If the project has a pilot in production then logs from the pilot can be used to generate ‘usage profiles’ that can be used as part of the testing process, and can even be used to ‘drive’ large portions of the Load Test. 
Load testing must be executed on “today’s” production size database, and optionally with a “projected” database.  If some database tables will be much larger in some months time, then Load testing should also be conducted against a projected database.  It is important that such tests are repeatable as they may need to be executed several times in the first year of wide scale deployment, to ensure that new releases and changes in database size do not push response times beyond prescribed SLAs.

Failover Tests
Failover Tests verify of redundancy mechanisms while under load.  For example, such testing determines what will happen if multiple web servers are being used under peak anticipated load, and one of them dies.  Does the load balancer react quickly enough? Can the other web servers handle the sudden dumping of extra load?  This sort of testing allows technicians to address problems in advance, in the comfort of a testing situation, rather than in the heat of a production outage.

Soak Tests
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 and performance problems that appear after a large number of transactions have been executed.  Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed.  It is important to identify such situations in a test environment.

Stress Tests
Stress Tests determine the load under which a system fails, and how it fails.  This is in contrast to Load Testing, which attempts to simulate anticipated load.  It is important to know in advance if a ‘stress’ situation will result in a catastrophic system failure, or if everything just “goes really slow”.  There are various varieties of Stress Tests, including spike, stepped and gradual ramp-up tests.  Catastrophic failures require restarting various infrastructure and contribute to downtime, a stress-full environment for support staff and managers, as well as possible financial losses.  This test is one of the most fundamental load and performance tests and needs to be well understood.

Targeted Infrastructure Test
Targeted Infrastructure Tests are Isolated tests of each layer and or component in an end to end application configuration.  It includes communications infrastructure, Load Balancers, Web Servers, Application Servers, Crypto cards, Citrix Servers, Database… allowing for identification of any performance issues that would fundamentally limit the overall ability of a system to deliver at a given performance level.
Each test can be quite simple, For example, a test ensuring that 500 concurrent (idle) sessions can be maintained by Web Servers and related equipment, should be executed prior to a full 500 user end to end performance test, as a configuration file somewhere in the system may limit the number of users to less than 500.  It is much easier to identify such a configuration issue in a Targeted Infrastructure Test than in a full end to end test.

Performance Tests
Performance Tests are tests that determine end to end timing (benchmarking) of various time critical business processes and transactions, while the system is under low load, but with a production sized database.  This sets ‘best possible’ performance expectation under a given configuration of infrastructure.  It also highlights very early in the testing process if changes need to be made before load testing should be undertaken.  For example, a customer search may take 15 seconds in a full sized database if indexes had not been applied correctly, or if an SQL 'hint' was incorporated in a statement that had been optimized with a much smaller database.  Such performance testing would highlight such a slow customer search transaction, which could be remediated prior to a full end to end load test.

Network Sensitivity Tests
Network sensitivity tests are tests that set up scenarios of varying types of network activity (traffic, error rates...), and then measure the impact of that traffic on various applications that are bandwidth dependant.  Very 'chatty' applications can appear to be more prone to response time degradation under certain conditions than other applications that actually use more bandwidth.  For example, some applications may degrade to unacceptable levels of response time when a certain pattern of network traffic uses 50% of available bandwidth, while other applications are virtually un-changed in response time even with 85% of available bandwidth consumed elsewhere.
This is a particularly important test for deployment of a time critical application over a WAN.

Volume Tests
Volume Tests are often most appropriate to Messaging, Batch and Conversion processing type situations.  In a Volume Test, there is often no such measure as Response time.  Instead, there is usually a concept of Throughput. 
A key to effective volume testing is the identification of the relevant capacity drivers.  A capacity driver is something that directly impacts on the total processing capacity.  For a messaging system, a capacity driver may well be the size of messages being processed.  For batch processing, the type of records in the batch as well as the size of the database that the batch process interfaces with will have an impact on the number of batch records that can be processed per second.

Sociability (sensitivity) Tests
Sensitivity analysis testing can determine impact of activities in one system on another related system.  Such testing involves a mathematical approach to determine the impact that one system will have on another system.  For example, web enabling a customer 'order status' facility may impact on performance of telemarketing screens that interrogate the same tables in the same database.  The issue of web enabling can be that it is more successful than anticipated and can result in many more enquiries than originally envisioned, which loads the IT systems with more work than had been planned. 

Tuning Cycle Tests
A series of test cycles can be executed with a primary purpose of identifying tuning opportunities.  Tests can be refined and re-targeted 'on the fly' to allow technology support staff to make configuration changes so that the impact of those changes can be immediately measured.

Protocol Tests
Protocol tests involve the mechanisms used in an application, rather than the applications themselves.  For example, a protocol test of a web server may will involve a number of HTTP interactions that would typically occur if a web browser were to interact with a web server - but the test would not be done using a web browser.  LoadRunner is usually used to drive load into a system using VUGen at a protocol level, so that a small number of computers (Load Generators) can be used to simulate many thousands of users.

Thick Client Application Tests
A Thick Client (also referred to as a fat client) is a purpose built piece of software that has been developed to work as a client with a server.  It often has substantial business logic embedded within it, beyond the simple validation that is able to be achieved through a web  browser.  A thick client is often able to be very efficient with the amount of data that is transferred between it and its server, but is also often sensitive to any poor communications links.  Testing tools such as WinRunner are able to be used to drive a Thick Client, so that response time can be measured under a variety of circumstances within a testing regime.
Developing a load test based on thick client activity usually requires significantly more effort for the coding stage of testing, as VUGen must be used to simulate the protocol between the client and the server.  That protocol may be database connection based, COM/DCOM based,  a proprietary communications protocol or even a combination of protocols.

Thin Client Application Tests
An internet browser that is used to run an application is said to be a thin client.  But even thin clients can consume substantial amounts of  CPU time on the computer that they are running on.  This is particularly the case with complex web pages that utilize many recently introduced features to liven up a web page.  Rendering a page after hitting a SUBMIT button may take several seconds even though the server may have responded to the request in less than one second.  Testing tools such as WinRunner are able to be used to drive a Thin Client, so that response time can be measured from a users perspective, rather than from a protocol level.