¿Qué es volume testing?

¿Qué es volume testing?

El volume testing (prueba de volumen) es un test de rendimiento en el que el sistema se somete a grandes volúmenes de datos, y el tamaño de los datos es la variable que cambias. El número de usuarios se mantiene realista mientras crecen las bases de datos, los almacenes de archivos y las colas, para ver qué ocurre con el tiempo de respuesta, la memoria y el disco. A veces se llama flood testing.

Es una disciplina del flujo de datos, no de la concurrencia. Un solo usuario exportando cinco años de pedidos ya es un volume test.

Para un ejemplo desarrollado, las herramientas y cómo leer la curva, consulta volume testing in software testing en el blog de LoadFocus (en inglés).

Volume testing frente a test de carga

Ambos son tests de rendimiento, pero varían cosas distintas. Un test de carga fija los datos y escala la concurrencia: ¿qué pasa cuando 5.000 usuarios llegan a un sistema de tamaño normal? Un volume test fija la concurrencia y escala los datos: ¿qué pasa cuando el mismo sistema tiene cien veces más filas? Aprobar uno dice poco del otro. Un sistema puede pasar todos los tests de carga contra una base de staging pequeña y fallar en producción, donde las tablas son mucho mayores.

Hay dos vecinos fáciles de confundir. El test de capacidad busca la carga máxima que soporta el sistema, y el test de escalabilidad pregunta cómo se comporta al añadir recursos o tráfico. El volume test mantiene fijos la infraestructura y el tráfico y solo hace crecer los datos.

Cómo funciona un volume test

1. Construye datos realistas en varios tamaños. Restaura una copia de seguridad reciente en una copia de pruebas, o genera registros con dispersión realista (muchos clientes, fechas y estados). Elimina antes los datos personales.
2. Ejecuta la misma carga en cada tamaño. Un número fijo de usuarios virtuales, las mismas operaciones.
3. Compara las curvas. Representa el tiempo de respuesta p95, la memoria y el disco frente al tamaño de datos. Un valor que crece más rápido que los datos es el hallazgo.

Ejemplo (cifras hipotéticas): una tienda online tiene 50.000 pedidos y espera 2 millones en dos años. Se prueba con 50.000, 2 millones y 10 millones de pedidos. En cada tamaño se ejecuta la misma mezcla de historial de pedidos, búsquedas de administración y pedidos nuevos, y se compara el p95 de cada operación. Si la búsqueda de administración se mantiene plana hasta 2 millones y luego se dispara, has encontrado el tamaño a partir del cual su consulta deja de usar un índice.

Qué falla con grandes volúmenes de datos

• Índices ausentes o no usados. Una consulta instantánea con 10.000 filas puede recorrer toda la tabla con 10 millones, y los planes de consulta pueden cambiar al crecer las tablas.
• Resultados sin límite. Código que carga una tabla entera para filtrarla o contarla en memoria.
• Paginación y recuentos. "Página 1 de N" exige contar filas, y los desplazamientos profundos son más lentos en cada página.
• Exportaciones, informes y migraciones. Suelen escribirse contra un conjunto de datos de desarrollo y no se revisan.
• Colas. Una gran acumulación o un solo mensaje defectuoso puede bloquear consumidores que nunca vieron más que unos pocos elementos.
• Copias de seguridad, restauraciones y reconstrucción de índices. Su duración crece con los datos y a menudo solo se descubre durante una incidencia.

Errores comunes

• Probar un solo tamaño. Un punto no muestra una curva. Usa al menos tres tamaños.
• Datos poco realistas. Millones de filas idénticas afectan a la caché y al índice de forma muy distinta a los datos reales.
• Ignorar el futuro. Prueba el tamaño que esperas dentro de uno o dos años, no solo el actual.
• Solo el camino feliz. Prueba los caminos lentos: informes, exportaciones, importaciones masivas, tareas en segundo plano.
• Usar datos de producción sin anonimizar. Enmascara los datos personales en cualquier copia.

Volume testing, monitorización y LoadFocus

LoadFocus aporta el tráfico, no los datos: tú preparas el gran conjunto de datos en tu entorno de pruebas, ejecutas contra él un test de carga de tamaño fijo con k6 o JMeter y comparas los percentiles de tiempo de respuesta entre ejecuciones. Mantén el mismo número de usuarios para que solo cambien los datos. El volume testing es distinto del soak testing, que mantiene la carga durante horas para encontrar fugas: consulta endurance y soak testing (en inglés). Tras el lanzamiento, la monitorización de APIs muestra si los endpoints probados siguen siendo rápidos a medida que crecen los datos reales.

Preguntas frecuentes

¿Cuál es la diferencia entre volume testing y test de carga?

El volume testing aumenta la cantidad de datos manteniendo constantes los usuarios. El test de carga aumenta el número de usuarios concurrentes manteniendo constantes los datos.

¿Es lo mismo volume testing que test de estrés?

No. El test de estrés lleva la carga de usuarios más allá del límite para encontrar dónde se rompe el sistema. El volume testing lleva el tamaño de los datos, y los fallos son distintos: consultas lentas, presión de memoria, tareas largas.

¿Con cuántos datos debo probar?

Usa el tamaño actual de producción como punto bajo, el esperado dentro de uno o dos años como punto medio y una cifra mayor como margen. Compara los resultados entre tamaños en lugar de juzgar una sola ejecución.

¿Puedo hacer un volume test en producción?

Es más seguro en una copia con datos del tamaño de producción y datos personales enmascarados. Llenar producción con datos de prueba arriesga registros e informes reales.