# [[Introduction to load testing]] A common mistake in the industry is to use the terms *performance testing* and *load testing* to mean the same thing. They are not interchangeable! Rather, load testing is a sub-practice of performance testing. Performance testing - verifies how well a system works as a whole, including aspects such as - scalability - elasticity - availability - reliability - resiliency - latency Load testing - just one type of performance testing - It's a specific approach that can be used to test many of aspects of application performance - Not all performance testing involves load testing - specifically focuses on verifying and validating the performance of an application while it has a significant volume of tasks to process - can be done manually, but most teams write automated load testing scripts to programmatically simulate real users accessing the application ### Structure - We know load testing involves scripting user behavior. But what does that look like? To define the kind of tests we want to run, we use test parameters. - VU: independent thread of execution. Often, but not always, 1 VU = 1 real end-user - Iterations: number of times the script is repeated during the test - Throughput: measure of how much load the test generates over time, usually defined in VUs per second, requests per second, or iterations per second - User flows: actions a script carries out and the order they run in - Load profile: shape of traffic generated by test in terms of the delays and the number of virtual users or requests over time - Duration: the time it takes to run the entire test - How to simulate load - Browser-based load testing - simulates the way users interact with the application user interface - Instead of simulating protocol-level requests, browser-based testing automates things like: - clicks on elements of a web app - typing on a form - other actions that real users may take - often involves end-to-end testing. - Protocol-based load testing - simulates the underlying requests going to application servers. These requests are sent over the protocol layer. - Protocol-based load testing varies in scope, including both: - targeted API testing of one or more specific application components, and - end-to-end or more realistic testing that simulates traffic flowing through the entire system, going through multiple components - Hybrid load testing - mixture of protocol-based and browser-based testing - usually employed to test different aspects of performance - The most economical approach involves protocol-based load testing to generate the majority of the load in conjunction with a smaller number of browser-based load-testing users. - Load test scenarios - aka load test types - shorthand for a certain combination of test parameters - recreates a specific situation that the application will be exposed to - Shakeout/Smoke - checks for major issues before spending more time and resources - one or a few VUs that run for a short amount of time - script-related problems that would significantly impact the accuracy of test results - unexpected environment configuration - significant application performance bottlenecks that arise at even low loads - Average Load Test - simulates the user workload during a typical hour in production. - typically includes ramp-up and ramp-down periods to simulate users gradually logging in and interacting with the system. The load test gradually increases the number of VUs until it reaches the desired load to mimic the average load behavior in production. - Between the ramp-up and ramp-down periods is a steady state, a period when the number of virtual users is constant. - In an average load test, the test sustains the steady-state load simulation for an hour or so. - Stress Test - simulates the traffic that the application is expected to experience at the *highest* point of the day or season. - Though a stress test is similar to an average load test in shape, it usually generates a far higher test throughput. Consider an application that typically has 100 accessing users during "normal" hours, but 300 users during the lunch hour. - good test scenario for testing rush hours or sale periods during which the application faces abnormally heavy load. - Soak/Endurance Test - tests with a longer duration than average or peak tests. Some performance bottlenecks, such as ones caused by defects in memory management, appear only during longer periods of time. Soak tests verify whether performance degrades over time - tends to have similar test throughput levels to the average load test, but it is extended to a duration of several hours or even days, depending on the application - Spike Test - recreates a situation where the application experiences a *sudden* and massive increase in traffic - good for simulating timed events like: - prominent product announcements (like in a super-bowl ad) - product launches or sale of concert tickets - deadlines (last days of tax submissions) - opening of sales seasons (Black Friday or Cyber Monday) - high throughput and short steady-state duration. They generally have a negligible ramp-up and ramp-down period. - Instead of a range of typical day-to-day processes, spike tests might prioritize one user flow. - Breakpoint Test - exposes an application to increasing levels of load in an attempt to identify the traffic level at which performance begins to degrade - build confidence in what a system can handle. The results from breakpoint tests provide valuable inputs for capacity planning. - more exploratory in nature, testers can't know in advance how many maximum VUs will be executed or how long the test will last. Teams typically monitor an application closely while a breakpoint test is running and either stop the test manually or program it to stop when it exceeds certain thresholds. - and many more! ### Outro Load testing is one approach to performance testing that involves simulating traffic against an application with the goal of understanding how it behaves when more than one user is accessing it. There are different types of load tests that you can run, and choosing the right one according to your test objectives is essential to getting valuable results that build confidence, define limits, and identify performance bottlenecks as early as possible. ### Related videos and resources