Liderazgo en Pruebas: Cómo Gestionar las Pruebas de Rendimiento

Hola y bienvenido a la serie Liderazgo en Pruebas. En el último artículo, analizamos las pruebas de servicios para aplicaciones web. 

El propósito de este capítulo es dar algunos consejos y mejores prácticas para gestionar un componente crítico de las pruebas de servicios mencionado en ese artículo, que es, redoble de tambores por favor... ¡las pruebas de rendimiento!

Cubriremos:

• Objetivos de las pruebas de rendimiento
• Cuatro prerrequisitos para una prueba de rendimiento
• Kit de herramientas para pruebas de rendimiento
• El proceso de prueba de rendimiento

Vamos allá.

Objetivos de las pruebas de rendimiento

Como un pequeño recordatorio, podemos definir el objetivo principal de las pruebas de rendimiento como:

“Demostrar que el sistema funciona según especificación, con tiempos de respuesta aceptables, procesando los volúmenes de transacciones requeridos sobre una base de datos de tamaño de producción.”

Tu entorno de pruebas de rendimiento es un banco de pruebas que puede usarse para otros tests, con objetivos más amplios, que podemos resumir como:

• Evaluar la capacidad de crecimiento del sistema (Si no sabes qué software puede cubrir tus necesidades, nuestra lista de mejores soluciones de gestión de bases de datos puede guiarte).
• Identificar puntos débiles en la arquitectura
• Ajustar el sistema
• Detectar errores ocultos en el software
• Verificar la resiliencia y la fiabilidad.

Tu estrategia de pruebas debe definir los requisitos para una infraestructura de pruebas que permita cumplir todos estos objetivos.

Cuatro prerrequisitos para una prueba de rendimiento

"Si falta alguno de estos prerrequisitos, ten mucho cuidado antes de proceder a ejecutar pruebas y publicar resultados. Utilizar herramientas de automatización de aseguramiento de calidad puede ayudarte a asegurar que estos requisitos previos se cumplan. Las pruebas pueden ser difíciles o imposibles de realizar, o la credibilidad de cualquier resultado que publiques puede verse seriamente comprometida y ser fácil de refutar.

1. Requisitos cuantitativos, relevantes, medibles, realistas y alcanzables

Como base para todas las pruebas, los requisitos de rendimiento (objetivos) deben ser acordados antes de la prueba para que pueda determinarse si el sistema cumple estos requisitos. 

Para que sean útiles como línea de base al comparar resultados de rendimiento, los requisitos de rendimiento del sistema en cuanto a rendimiento o tiempos de respuesta deben tener los siguientes atributos. Deben ser:

• Expresados en términos cuantificables.
• Relevantes para la tarea que un usuario desea realizar.
• Medibles usando una herramienta (o cronómetro) y a un coste razonable.
• Realistas en comparación con la duración de la tarea del usuario.
• Alcanzables a un coste razonable.

A menudo, los requisitos de rendimiento son vagos o inexistentes. Busca cualquier requisito documentado que puedas. Si hay huecos, puede que tengas que documentarlos a posteriori. 

Antes de que se pueda especificar y diseñar una prueba de rendimiento, hay que acordar los requisitos para:

• Tiempos de respuesta de las transacciones.
• Perfiles de carga (el número de usuarios y volúmenes de transacciones a simular).
• Volúmenes de la base de datos (el número de registros en las tablas de la base de datos que se esperan en producción).

Es común que los requisitos de rendimiento se definan en términos vagos. Estos requisitos suelen estar basados en volúmenes empresariales previstos de manera estimativa; puede ser necesario que los usuarios de negocio piensen de manera realista sobre los requisitos de rendimiento. 

También puede que tengas que realizar un análisis de requisitos tú mismo y documentar estos requisitos como los objetivos de rendimiento esperados. 

2. Un sistema estable

Si el sistema es propenso a errores y poco fiable, no llegarás muy lejos con una prueba de rendimiento. Las pruebas de rendimiento exigen a todos los componentes de la arquitectura hasta cierto punto. Pero para que las pruebas de rendimiento den resultados útiles, el sistema y la infraestructura técnica deben ser razonablemente confiables y resilientes desde el principio.

3. Entorno de pruebas realista

El entorno de pruebas debe configurarse de forma que las pruebas tengan sentido. Probablemente no podrás replicar el sistema objetivo o de producción, pero el entorno de pruebas debe ser comparable, en todo o en parte, al entorno de producción final. Necesitarás acordar con el arquitecto del sistema qué compromisos son aceptables y cuáles no, o al menos, qué interpretación útil se podría hacer de los resultados de las pruebas.

Crear un entorno de pruebas realista es esencial para que las pruebas de rendimiento tengan significado. Para herramientas que pueden ayudarte a simular condiciones del mundo real, echa un vistazo a nuestra selección de plataformas de pruebas de software

4. Entorno de pruebas controlado

Los probadores de rendimiento requieren estabilidad. No solo en términos de la fiabilidad y resiliencia de hardware y software, sino también en la minimización de cambios en el entorno o el software bajo prueba. Por ejemplo, si la interfaz cambia aunque sea mínimamente, los scripts de prueba diseñados para operar interfaces de usuario suelen fallar inmediatamente.

Cualquier cambio en el entorno debe estar estrictamente controlado. Si el cambio corrige errores que probablemente no afectarán el rendimiento, podrías considerar no aceptar la versión. Solo se deberían aceptar cambios destinados a mejorar el rendimiento o la fiabilidad.

Kit de herramientas para pruebas de rendimiento

Tu kit de herramientas para pruebas de rendimiento consta de cinco herramientas principales:

• Creación/mantenimiento de datos de prueba - para crear los grandes volúmenes de datos en la base de datos que se requerirán para la prueba. Esperaríamos que fuera una utilidad basada en SQL, o quizá un producto para PC como Microsoft Access, conectado a tu base de datos de prueba.
• Generación de carga – las herramientas más comunes utilizan drivers de prueba que simulan clientes virtuales enviando mensajes HTTP a servidores web.
• Herramienta de ejecución de la aplicación – conduce una o más instancias de la aplicación usando la interfaz del navegador y registra tiempos de respuesta. (Por lo general, es la misma herramienta utilizada para la generación de carga, pero no tiene por qué serlo).
• Supervisión de recursos - utilidades que monitorean y registran recursos del sistema cliente y servidor, tráfico de red, actividad de bases de datos, etc.
• Análisis y reporte de resultados - las herramientas de ejecución de pruebas y monitoreo de recursos generan grandes volúmenes de datos de resultados para analizar.

Lectura relacionada: LOS 10 MEJORES SERVICIOS DE ANALÍTICA SQL PARA EQUIPOS DE QA

El proceso de la prueba de rendimiento

A continuación se muestra una figura que presenta un proceso genérico para pruebas y ajustes de rendimiento. El ajuste no es realmente parte del proceso de prueba, pero es una parte inseparable de la tarea de mejorar el rendimiento y la fiabilidad. El tuning puede conllevar cambios en la infraestructura arquitectónica, pero no debe afectar la funcionalidad del sistema bajo prueba.

Ahora veremos cómo desarrollar, ejecutar, analizar y reportar una prueba de rendimiento.

Desarrollo incremental de pruebas

El desarrollo de las pruebas habitualmente se realiza de forma incremental en cuatro etapas:

1. Cada script de prueba se prepara y prueba de forma aislada para depurarlo.
2. Los scripts se integran en la versión de desarrollo de la carga de trabajo y se ejecuta la carga de trabajo para probar que el nuevo script sea compatible.
3. A medida que la carga de trabajo crece, el marco de pruebas en desarrollo se va refinando, depurando y volviendo más confiable de forma continua. También aumenta la experiencia y familiaridad con las herramientas.
4. Cuando se integra el último script en la carga de trabajo, se ejecuta una "prueba en seco" para asegurar que sea completamente repetible y confiable, y esté lista para las pruebas formales.

Las pruebas intermedias pueden proporcionar resultados útiles

Las ejecuciones de la carga de trabajo parcial y las transacciones de prueba pueden exponer problemas de rendimiento. Las pruebas con cargas de bajo volumen también pueden dar una indicación temprana del tráfico de red y cuellos de botella potenciales cuando la prueba escale.

Los tiempos de respuesta deficientes pueden deberse a un mal diseño de la aplicación y pueden ser investigados y resueltos antes por los desarrolladores. Las pruebas tempranas también pueden ejecutarse durante largos periodos como pruebas de resistencia.