Comprende el servicio

El diseño de tu prueba y las expectativas de un nuevo servicio no serán necesariamente las mismas que las de uno que ha estado trabajando en la producción durante años. Un servicio que es escribe en la base de datos se desempeñará de manera diferente de uno que simplemente lee de una base de datos.

Otras cosas a considerar:

¿Es el servicio parte de una arquitectura de micro servicio, con muchas dependencias en otros servicios?

¿Otros servicios dependen del servicio?

¿Necesita el servicio manejar carga de archivos, como ilustraciones o archivos de sonido?

¿Dónde está la ubicación física del servicio en comparación con el host de la base de datos o la base de clientes?

¿Cómo se compara el entorno de prueba con el entorno de producción en cuanto a número de cajas, CPU, memoria, red, etc.? Debería ser relación 1::1

Conocer estos datos te ayudará a identificar datos importantes de tu prueba.

Comprende la aplicación

Una vez que el servicio esté en producción, no será tu script el que generará carga; Será su aplicación de cliente en manos de clientes reales. Comprender cómo la aplicación utiliza el servicio es clave para diseñar un script de prueba de rendimiento relevante. Entonces, antes de abrir Loadrunner/JMeter, ejecute su aplicación a través de un proxy y analice las solicitudes.

Algunas cosas importantes para buscar incluyen:

¿Cuál es la secuencia de llamadas al inicio? ¿Es diferente para los usuarios que regresan?

¿Cuál es la secuencia de solicitud para el escenario de uso principal? ¿Hay múltiples escenarios comunes?

¿En qué se diferencia el perfil de solicitud de los usuarios anónimos frente a los usuarios registrados?

¿Hay puntos en los que la aplicación está notablemente detenida, esperando el servidor?

¿La aplicación está creando una carga innecesaria al duplicar solicitudes o realizar solicitudes con demasiada frecuencia?

Perfilar la aplicación de cliente al principio del proceso de prueba lo ayudará a hacer una prueba realista y encontrar posibles problemas antes de que afecten negativamente a sus clientes (Response Profile Test).

Comprende el Negocio

Para crear una línea de base para su servicio/aplicacion, necesitas conocer el tamaño y los patrones de uso esperados de sus clientes. Un servicio destinado a manejar las transacciones de compras en todo el mundo en Cyber ​​Monday tendrá diferentes expectativas de uno que admita pocas transacciones.

Otras cosas a considerar:

¿Hay momentos pico en los que se espera que el uso de la aplicación aumente? Si es así, ¿qué tan grande es ese pico?

¿Cuánto dura una sesión promedio dentro de la aplicación?

¿Cuántas veces al día utiliza la aplicación un cliente típico?

¿Qué porcentaje de su base de clientes se autentica en lugar de anónimo?

¿Cuáles son las expectativas de sus clientes para la capacidad de respuesta de la aplicación?

Conocer el tamaño general y la composición de su base de clientes te ayudará a ajustar tu script para garantizar que su servicio/aplicación coincida con el comportamiento deseado.

Entiende el objetivo de las pruebas

No es suficiente tener una tarea para “pruebas de rendimiento”. Pregúntate qué es lo más importante que necesitas aprender de esta ronda de pruebas. Por ejemplo:

¿Será este servicio capaz de manejar la carga esperada?

¿Cuál es el rendimiento máximo que el servicio puede procesar dentro de una tasa de error aceptable?

¿Cómo afectará la adición de una nueva característica/componente/servicio al rendimiento general del servidor?

¿Qué tan rápido puede el servicio responder a las solicitudes con carga Pico (Peak)?

¿Qué tan rápido puede el servicio responder a las solicitudes bajo la carga esperada (Baseline)?

Una vez que hayas determinado lo que quieres revisar, puedes diseñar una prueba para centrarte en esos objetivos.