What is Volume Testing? Learn with Examples
Thomas Hamilton
⚡ Smart Summary
Volume Testing subjects an application to a very large quantity of data to see how storage, queries, and response times behave as the database grows. It is also called flood testing, and it scales the data rather than the number of users.
What is Volume Testing?
Volume Testing is a type of Software Testing, where the software is subjected to a huge volume of data. It is also referred to as flood testing. Volume testing is done to analyze the system performance by increasing the volume of data in the database.
With the help of Volume testing, the impact on response time and system behavior can be studied when exposed to a high volume of data.
For example, a music streaming service might be tested with a catalogue of 50 million tracks and a listening-history table holding billions of rows, to see whether search and recommendation queries still return in acceptable time.
Note the distinction: volume testing increases the amount of data the system holds. Increasing the number of concurrent users is load testing, which is a different test with a different objective.
Benefits of Volume Testing
- Identifying capacity issues early avoids the far higher cost of fixing them in production
- It helps in a quicker start for scalability plans
- Early identification of bottlenecks
- It assures your system is now capable of real-world usage
Why Do Volume Testing?
The objective of performing the volume testing is to
- Check system performance with increasing volumes of data in the database
- Identify the problems that are likely to appear once the data set becomes large
- To figure out the point at which the stability of the system degrades
- Volume Testing will help to identify the capacity of the system or application – normal and heavy volume
How to Do Volume Testing
In volume testing, following things need to be tested
- Test to check if there is any data loss
- Check the system’s response time
- Check if the data is stored correctly or not
- Verify if the data is overwritten without any notification
- Check that warnings and error messages actually appear when a volume limit is reached
- Check whether high volume data affects the speed of processing
- Confirm the system has the memory and storage resources the volume requires
- Confirm the volume test covers the whole system rather than a single component
- Is there any risk if data volume is greater than specified
- Establish whether any guarantee exists that the data volume will not exceed the specified maximum
Best Practices for High Volume Testing
Several of the practices below are shared with load testing, because the two are usually run against the same environment. The volume-specific ones concern the data set itself:
- Stop all servers and check all logs
- Before the load test manually execute the application scenario
- For most useful results stagger the number of users
- To overcome license constraints, balance think time
- Be cautious with the new build
- Analyze the use case for improvement once a baseline has been established
- A repetition of particular parts of volume testing becomes inevitable in case there is a performance bottleneck
Volume Testing vs Load Testing
| Volume Testing | Load Testing |
|---|---|
|
|
|
|
Challenges in Volume Testing
- Fragmentation of memory difficult to generate
- Dynamic generation of keys
- Relational Integrity of generated data
How This Test Compares With Other Performance Tests
Performance testing is a family of tests that differ in the shape of the load applied, which is why they are so easily confused.
| Test type | What is increased | Question it answers |
|---|---|---|
| Load testing | Concurrent users, to the expected peak | Does it meet targets under normal peak traffic? |
| Volume testing | Data held in the database | Does it cope as the data set grows? |
| Stress testing | Load beyond capacity, until failure | Where does it break, and how? |
| Spike testing | Load, instantly and extremely | Does it survive and recover from a shock? |
| Endurance testing | Duration, at normal load | Does performance degrade over time? |
| Soak testing | Duration, watching resources | Are there memory or handle leaks? |
| Stability testing | Varying conditions | Does it stay reliable as conditions change? |
The distinction that matters most here: volume testing scales the data, load testing scales the users. A report that runs in two seconds against ten thousand rows and two minutes against ten million rows has a volume problem, not a load problem, and no amount of extra server capacity will fix it.
How to Generate Test Data for Volume Testing
The challenges section notes that generating realistic data is the hard part of volume testing. Four approaches are used in practice, and each involves a trade-off.
| Approach | Realism | Main drawback |
|---|---|---|
| Copy of production data | Highest | Privacy and compliance exposure |
| Masked production copy | High | Masking can break referential integrity |
| Synthetic generation | Medium | Distributions may not match reality |
| Replayed production traffic | High | Requires capture infrastructure |
Whichever route you take, three properties must hold or the test measures nothing useful.
- Referential integrity. Every foreign key must resolve. A million orphan rows exercise the storage engine but never the join paths the application actually uses.
- Realistic cardinality. If the production table has ten million rows across two hundred customers, generating ten million rows across ten million customers produces completely different query plans.
- Realistic distribution. Real data is skewed. Uniformly random data hides the hot partitions and index contention that cause production incidents.
A practical warning about privacy. Copying production data into a test environment is the most common cause of a data breach in testing. Mask personal fields before the copy leaves production, not afterwards.
