Key takeaways
- Volume testing increases the amount of DATA, not the number of users. That is what separates it from load testing.
- Most volume failures are queries that were fine against a small table and are not fine against a large one.
- Test at several data sizes rather than one. The shape of the curve is the finding, not any single number.
The quick answer
Volume testing measures how a system behaves as the volume of data it holds grows. The user count stays realistic; the database, the file store and the queues get large. It answers a question load testing cannot: does this application still work in two years, when the tables have a hundred times more rows in them?
Is Your Infrastructure Ready for Global Traffic Spikes?
Unexpected load surges can disrupt your services. With LoadFocus’s cutting-edge Load Testing solutions, simulate real-world traffic from multiple global locations in a single test. Our advanced engine dynamically upscales and downscales virtual users in real time, delivering comprehensive reports that empower you to identify and resolve performance bottlenecks before they affect your users.
What is volume testing in software testing?
Volume testing is a performance test where the variable is stored data. You seed the system with a realistic quantity of records, then run the same operations you always run and watch what happens to response times, memory and disk.
The failures it finds are specific and they rarely appear in any other kind of test. A query with no index returns instantly against ten thousand rows and takes thirty seconds against ten million. A report that builds its result set in memory works until the result set no longer fits. A page that loads every record to count them is fast on an empty system and unusable on a full one.
None of these are visible in a load test, because a load test usually runs against a small seeded database. You can put a thousand concurrent users through an empty system and see excellent numbers.
Think your website can handle a traffic spike?
Fair enough, but why leave it to chance? Uncover your website’s true limits with LoadFocus’s cloud-based Load Testing for Web Apps, Websites, and APIs. Avoid the risk of costly downtimes and missed opportunities—find out before your users do!
Volume testing vs load testing vs stress testing
The three are routinely confused because all of them are performance tests. The difference is what you vary.
- Load testing varies the number of concurrent users at an expected level, and asks whether the system copes with the traffic you predict.
- Stress testing pushes the user count past that level to find where it breaks and how.
- Volume testing holds users roughly constant and varies the data, asking whether the system copes with the scale it will eventually hold.
A system can pass all the load testing you throw at it and still fail in production eighteen months later, because the load never changed and the data did.
What actually breaks under data volume
- Missing or unused indexes. The most common finding by a wide margin. The query plan changes as the table grows and a scan replaces a seek.
- Unbounded result sets. Anything that loads a whole table to filter or count it in application code.
- Pagination that counts. Showing “page 1 of N” requires counting every row, and that cost grows with the table.
- Report and export paths. These are usually written against a development dataset and never revisited.
- Storage that grows quietly. Logs, audit tables, soft-deleted rows and attachment stores fill disks that nobody is watching.
- Backup and restore windows. Restores get slower with data and only get tested during an incident.
How to run a volume test
Seed the system with data that looks like production, not with a million copies of the same record. Realistic distribution matters, because a table where every row has the same value indexes very differently from one where values are spread out.
Then run the same set of operations at several data sizes. Current volume, the volume you expect in a year, and something well beyond it. Keep the user load constant across all three so the only thing changing is the data.
LoadFocus is an all-in-one Cloud Testing Platform for Websites and APIs for Load Testing, Apache JMeter Load Testing, Page Speed Monitoring and API Monitoring!
Measure the operations users actually perform: the main list views, the search, the exports, the busiest API endpoints. Include at least one write path, because inserts slow down as indexes grow too.
Reading the result
You are looking for the shape of the curve rather than any single measurement.
Linear growth
Response time rising in proportion to the data is usually acceptable and predictable. You can plan for it.
Non-linear growth
Response time rising much faster than the data is the finding. It nearly always points at a specific query rather than at general slowness, and it is usually cheap to fix once identified.
A cliff
Performance that is level and then collapses at a particular size normally means something stopped fitting: an index no longer in memory, a cache no longer holding the working set, a result set no longer fitting in a buffer.
What good looks like
A system that passes volume testing has response times that grow predictably and slowly with data, and no operation whose cost is proportional to total table size when it should be proportional to the page being shown. The practical target is that the curve at ten times today’s data is still inside your acceptable response time, because that is the horizon you can plan around.
Frequently Asked Questions
Is volume testing the same as load testing?
No. Load testing varies the number of concurrent users; volume testing varies the amount of stored data. A system can pass one and fail the other, which is why both exist.
How much data should I test with?
At least the volume you expect within your planning horizon, and ideally several multiples so you can see the shape of the curve. One measurement at one size tells you the current cost, not how it grows.
Can I use copied production data?
Only if it is anonymised properly. Real records in a test environment are a data protection problem, and test environments are usually less protected than production. Generated data with a realistic distribution avoids the issue.