Liderazgo en Pruebas: Cómo Gestionar las Pruebas de Rendimiento
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor en testing de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles como líderes de pruebas y gestores.
En el artículo anterior, exploramos las pruebas de servicios y sus componentes principales: pruebas de rendimiento, pruebas de tolerancia/prolongadas y la capacidad de gestión. Como prometimos, aquí exploraremos las pruebas de rendimiento con un poco más de detalle.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso Liderazgo en Prueba de Paul, el cual recomendamos encarecidamente para profundizar en este y otros temas. Si te decides, usa nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
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:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- 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:
- Cada script de prueba se prepara y prueba de forma aislada para depurarlo.
- 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.
- 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.
- 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.
Ejecución de Pruebas
La ejecución de pruebas requiere cierta gestión de etapas o coordinación. Deberías colaborar con los participantes de soporte que supervisarán el sistema mientras realizas las pruebas. El equipo de “monitoreo de pruebas” puede estar distribuido, así que necesitas mantenerlos informados para que la prueba se ejecute sin problemas y los resultados se capturen correctamente.
Más allá de la coordinación entre los distintos miembros del equipo, la ejecución de pruebas de rendimiento suele seguir una rutina estándar.
- Preparación de la base de datos (restaurar desde cinta si es necesario).
- Preparar el entorno de pruebas según sea necesario y verificar su estado.
- Iniciar los procesos de monitoreo (red, clientes y servidores, base de datos).
- Iniciar la simulación de carga y observar los monitores de sistema.
- Si se emplea una herramienta separada, cuando la carga sea estable, iniciar la herramienta de ejecución de pruebas de la aplicación y la medición del tiempo de respuesta.
- Monitorizar la prueba de cerca durante toda su duración.
- Si las herramientas de ejecución de pruebas no se detienen automáticamente, finalizar la prueba al concluir el periodo establecido.
- Detener las herramientas de monitoreo y guardar los resultados.
- Archivar todos los resultados capturados y asegurarse de que toda la información esté respaldada de forma segura.
- Producir informes intermedios; consultar con otros miembros del equipo sobre cualquier anomalía.
- Preparar análisis e informes.
Coordinar a los diferentes miembros del equipo durante la ejecución de pruebas puede ser un desafío. Facilita este proceso integrando herramientas avanzadas de gestión de pruebas diseñadas para Jira, que ofrecen funciones como colaboración y generación de informes en tiempo real.
El ajuste generalmente sigue a las pruebas cuando hay problemas o cuando se sabe que existen optimizaciones posibles. Si una prueba se repite, es esencial que cualquier cambio en el entorno quede registrado. Así, cualquier diferencia en el comportamiento del sistema y, por ende, en los resultados de rendimiento, podrá relacionarse con los cambios en la configuración.
Cuando se trata de gestionar los casos de prueba para pruebas de rendimiento, un software de gestión de pruebas puede marcar la diferencia. Permite una mejor organización, seguimiento e incluso automatización de los casos de prueba.
Como norma, es recomendable cambiar solo una cosa a la vez para que cuando se detecten diferencias en el comportamiento, puedan rastrearse hasta los cambios realizados.
Análisis de Resultados e Informes
El informe más típico de una ejecución de prueba resumirá estas mediciones y para cada medición tomada se informará lo siguiente:
- El número de mediciones.
- Tiempo mínimo de respuesta.
- Tiempo máximo de respuesta.
- Tiempo medio de respuesta.
- Tiempo de respuesta del percentil n (normalmente 95o).
La herramienta de generación de carga de tu kit debería registrar la cantidad de cada tipo de transacción durante el periodo de la prueba. Dividir estas cantidades entre la duración de la prueba da la tasa de transacciones o rendimiento realmente conseguido.
El conteo de transacciones es la carga aplicada al sistema. Esto supone que las proporciones de transacciones ejecutadas coincidan con el perfil de carga que se quiere aplicar.
La carga aplicada debería coincidir con el perfil de carga simulado - pero podría no hacerlo si el sistema responde lentamente y las transacciones se ejecutan a diferentes velocidades.
Normalmente, ejecutarás una serie de pruebas con diferentes cargas. Usando los resultados de una serie de pruebas, traza un gráfico del tiempo de respuesta de una transacción frente a la carga aplicada.
Las herramientas de monitoreo de recursos generalmente cuentan con funciones de generación de informes estadísticos o gráficos que muestran el uso de los recursos a lo largo del tiempo. Los informes mejorados sobre el uso de recursos frente a la carga aplicada son muy útiles y pueden ayudar a identificar los cuellos de botella en la arquitectura de un sistema.
¡Te deseamos mucho éxito!
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que te recomendamos para profundizar más en este y otros temas. ¡Si lo haces, utiliza nuestro código exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso!
Lectura relacionada: MÉTRICAS DE MONITOREO DE SERVIDORES QUE SEGUIR PARA LA SALUD Y EL RENDIMIENTO DEL SISTEMA
