complete performance testing guide with examples
¿Qué son las pruebas de rendimiento?
Las pruebas de rendimiento, también conocidas como 'pruebas de rendimiento', son un tipo de prueba que se realiza para comprobar cómo funciona la aplicación o el software bajo carga de trabajo en términos de capacidad de respuesta y estabilidad. El objetivo de la prueba de rendimiento es identificar y eliminar los cuellos de botella de rendimiento de una aplicación.
Esta prueba se realiza principalmente para verificar si el software cumple con los requisitos esperados de velocidad, escalabilidad y estabilidad de la aplicación.
el mejor software para clonar hdd a ssd
En esta serie de tutoriales, cubriremos detalles completos como: tipos de prueba de rendimiento, proceso y documento de estrategia de prueba de rendimiento de escritura desde cero.
Esta es una serie de tutoriales detallados que quizás desee agregar a favoritos.
¡Vamos a explorar!
Lista de TODOS los tutoriales de pruebas de rendimiento de esta serie:
Tutorial #1: Guía completa de pruebas de rendimiento (Este tutorial)
Tutorial #2: Diferencia entre pruebas de rendimiento, carga y estrés
Tutorial #3: Pruebas funcionales frente a pruebas de rendimiento
Tutorial #4: Plan de prueba de rendimiento y estrategia de prueba
Tutorial #5: Formas de potenciar sus pruebas de rendimiento
Tutorial #6: Guía de pruebas de rendimiento en la nube
Tutorial #7: Guía de pruebas de rendimiento de aplicaciones móviles
Tutorial #8: Cómo realizar pruebas de rendimiento manuales
Tutorial #9: Tutorial de pruebas de rendimiento del sitio web
Tutorial #10: Empresas de pruebas de rendimiento
Tutorial #11: Pruebas de rendimiento con LoadRunner (Serie)
Instrumentos:
Tutorial #12: Herramientas de prueba de rendimiento superior
Tutorial #13: Tutorial de prueba de rendimiento de Neoload
Tutorial #14: Tutorial de prueba de rendimiento de BlazeMeter Mobile
Tutorial #15: Tutorial de prueba de carga, estrés y rendimiento de WAPT
Tutorial #16: Tutorial de prueba de rendimiento del sitio web SmartMeter.io
Lo que vas a aprender:
- Tipos de pruebas de rendimiento
- Proceso de prueba de rendimiento
- ¿Cómo escribir un documento de estrategia de prueba de rendimiento?
- Ejemplo de plantilla de estrategia de prueba de rendimiento
- #1. Introducción
- #2. Alcance
- # 3) Enfoque
- # 4) Datos de prueba
- # 5) Criterios de entrada y salida
- # 6) Gestión de defectos
- # 7) Herramientas y técnicas de prueba
- # 8) Criterios de suspensión y reanudación
- # 9) Entrega de prueba
- # 10) Roles y responsabilidades
- # 11) Riesgos potenciales y plan de mitigación
- # 12) Supuestos
- # 13) Dependencias
- # 14) Abreviaturas
- Mejores prácticas para pruebas de rendimiento realistas
Tipos de pruebas de rendimiento
Prueba de carga
La prueba de carga es un tipo de prueba de rendimiento en la que se prueba el rendimiento de la aplicación con un uso normal y pico. El rendimiento de una aplicación se verifica con respecto a su respuesta a la solicitud del usuario y su capacidad para responder de manera coherente dentro de una tolerancia aceptada en diferentes cargas de usuarios.
Las consideraciones clave son:
- ¿Cuál es la carga máxima que puede contener la aplicación antes de que comience a comportarse de forma inesperada?
- ¿Cuántos datos puede manejar la base de datos antes de que el sistema se ralentice o se observe el bloqueo?
- ¿Hay algún problema relacionado con la red que deba abordarse?
Pruebas de estrés
Las pruebas de estrés se utilizan para encontrar formas de romper el sistema. La prueba también proporciona el rango de carga máxima que puede soportar el sistema.
Generalmente, la prueba de esfuerzo tiene un enfoque incremental donde la carga se incrementa gradualmente. La prueba se inicia con una carga para la que ya se ha probado la aplicación. Luego, se agrega más carga lentamente para estresar el sistema. El punto en el que comenzamos a ver que los servidores no responden a las solicitudes se considera el punto de ruptura.
Deben abordarse las siguientes preguntas:
- ¿Cuál es la carga máxima que puede soportar un sistema antes de averiarse?
- ¿Cómo se descompone el sistema?
- ¿El sistema puede recuperarse una vez que se bloquea?
- ¿De cuántas formas puede romperse un sistema y cuáles son los nodos débiles al manejar la carga inesperada?
Prueba de volumen
La prueba de volumen es para verificar que el rendimiento de la aplicación no se vea afectado por el volumen de datos que maneja la aplicación. Para ejecutar una prueba de volumen, se ingresa un gran volumen de datos en la base de datos. Esta prueba puede ser incremental o constante. En la prueba incremental, el volumen de datos aumenta gradualmente.
Generalmente, con el uso de la aplicación, el tamaño de la base de datos crece y es necesario probar la aplicación contra una base de datos pesada. Un buen ejemplo de esto podría ser un sitio web de una nueva escuela o una universidad que tiene pequeñas cantidades de datos para almacenar inicialmente, pero después de 5 a 10 años, los datos almacenados en la base de datos del sitio web son mucho más.
Prueba de capacidad
=> ¿La aplicación es capaz de cumplir con el volumen de negocios tanto en condiciones de carga normales como pico?
Las pruebas de capacidad se realizan generalmente para prospectos futuros. La prueba de capacidad aborda lo siguiente:
- ¿La aplicación podrá soportar la carga futura?
- ¿Es el entorno capaz de soportar el aumento de carga que se avecina?
- ¿Cuáles son los recursos adicionales necesarios para que el entorno sea lo suficientemente capaz?
La prueba de capacidad se utiliza para determinar cuántos usuarios y / o transacciones admitirá una aplicación web determinada y aún así alcanzará el rendimiento. Durante esta prueba, los recursos como la capacidad del procesador, el ancho de banda de la red, el uso de la memoria, la capacidad del disco, etc. se consideran y modifican para cumplir con el objetivo.
La banca en línea es un ejemplo perfecto de dónde las pruebas de capacidad podrían desempeñar un papel importante.
Fiabilidad / Recuperación Pruebas
Prueba de confiabilidad o prueba de recuperación: es para verificar si la aplicación puede o no regresar a su estado normal después de una falla o comportamiento anormal y cuánto tiempo tarda en hacerlo (en otras palabras, estimación de tiempo).
Si un sitio de comercio en línea experimenta una falla en la que los usuarios no pueden comprar / vender acciones en un momento determinado del día (horas pico) pero pueden hacerlo después de una hora o dos, podemos decir que la aplicación es confiable o recuperado del comportamiento anormal.
Proceso de prueba de rendimiento
Aquí están todas las actividades realizadas en esta prueba:
# 1) Análisis / recopilación de requisitos
El equipo de desempeño interactúa con el cliente para la identificación y recopilación de requisitos, técnicos y comerciales. Esto incluye obtener información sobre la arquitectura de la aplicación, las tecnologías y la base de datos utilizada, los usuarios previstos, la funcionalidad, el uso de la aplicación, requisito de prueba , requisitos de hardware y software, etc.
# 2) POCO / Tool selection
Una vez que se identifica la funcionalidad clave, POC (Prueba de concepto, que es una especie de demostración de la actividad en tiempo real, pero en un sentido limitado) se realiza con las herramientas disponibles.
La lista de herramientas disponibles depende del costo de la herramienta, el protocolo que utiliza la aplicación, las tecnologías utilizadas para construir la aplicación, la cantidad de usuarios que estamos simulando para la prueba, etc. Durante el POC, se crean scripts para la clave identificada. funcionalidad y ejecutado con 10-15 usuarios virtuales.
# 3) Plan y diseño de pruebas de rendimiento
Dependiendo de la información recopilada en las etapas anteriores, se llevan a cabo la planificación y el diseño de pruebas.
La planificación de pruebas implica información sobre cómo se llevará a cabo la prueba de rendimiento: entorno de prueba, carga de trabajo, hardware, etc.
Más sobre el documento de estrategia de prueba a continuación.
# 4) Desarrollo de pruebas de rendimiento
- Los casos de uso se crean para la funcionalidad identificada en el plan de prueba como el alcance de PT.
- Estos casos de uso se comparten con el cliente para su aprobación. Esto es para asegurarse de que el guión se grabe con los pasos correctos.
- Una vez aprobado, el desarrollo del script comienza con un registro de los pasos en los casos de uso con la herramienta de prueba de rendimiento seleccionada durante el POC (Prueba de conceptos) y mejorada mediante la realización de Correlación (para manejar el valor dinámico), Parametrización (sustitución de valor) y funciones personalizadas como según la situación o necesidad. Más sobre estas técnicas en nuestros videos tutoriales.
- Luego, los scripts se validan con diferentes usuarios.
- Paralelamente a la creación del script, el equipo de desempeño también sigue trabajando en la configuración del entorno de prueba (software y hardware).
- El equipo de rendimiento también se ocupará de los metadatos (back-end) a través de scripts si el cliente no se ocupa de esta actividad.
# 5) Modelado de prueba de rendimiento
El modelo de carga de rendimiento se crea para la ejecución de la prueba. El objetivo principal de este paso es validar si las métricas de rendimiento proporcionadas (proporcionadas por los clientes) se logran durante la prueba o no. Existen diferentes enfoques para crear un modelo de carga. ' Ley de Little ”Se utiliza en la mayoría de los casos.
# 6) Ejecución de prueba
El escenario se diseña según el Modelo de Carga en Controller o Performance Center pero las pruebas iniciales no se ejecutan con el máximo de usuarios que están en el modelo de Carga.
La ejecución de la prueba se realiza de forma incremental. Por ejemplo, Si el número máximo de usuarios es 100, los escenarios se ejecutan primero con 10, 25, 50 usuarios y así sucesivamente, pasando finalmente a 100 usuarios.
# 7) Análisis de los resultados de la prueba
Los resultados de las pruebas son el producto más importante para el evaluador de rendimiento. Aquí es donde podemos demostrar el ROI (retorno de la inversión) y la productividad que puede proporcionar un esfuerzo de prueba de rendimiento.
Algunas de las mejores prácticas que ayudan al proceso de análisis de resultados:
- Un nombre único y significativo para cada resultado de la prueba: esto ayuda a comprender el propósito de la prueba.
- Incluya la siguiente información en el resumen de resultados de la prueba:
- Razón de la falla
- Cambio en el rendimiento de la aplicación en comparación con la ejecución de prueba anterior
- Cambios realizados en la prueba desde el punto de creación de la aplicación o el entorno de prueba.
- Es una buena práctica hacer un resumen de resultados después de cada ejecución de prueba para que los resultados de los análisis no se compilen cada vez que se refieren los resultados de las pruebas.
- PT generalmente requiere muchas pruebas para llegar a la conclusión correcta.
- Es bueno tener los siguientes puntos en el resumen de resultados:
- Propósito de la prueba
- Número de usuarios virtuales
- Resumen del escenario
- Duración de la prueba
- Rendimiento
- Gráficos
- Comparación de gráficos
- Tiempo de respuesta
- Se produjo un error
- Recomendaciones
# 8) Informe
Los resultados de la prueba deben simplificarse para que la conclusión sea más clara y no necesite ninguna derivación. El equipo de desarrollo necesita más información sobre análisis, comparación de resultados y detalles sobre cómo se obtuvieron los resultados.
Se considera que el informe de prueba es bueno si es breve, descriptivo y directo.
¿Cómo escribir un documento de estrategia de prueba de rendimiento?
Este tutorial explica cómo escribir una estrategia de prueba de rendimiento de muestra para una aplicación de mensajería.
Recuerde que esto es solo un ejemplo y los requisitos serán diferentes de un cliente a otro, también conoceremos las mejores prácticas para Performance Testing en este tutorial.
diferencia entre las pruebas de caja blanca y las pruebas de caja negra
Ejemplo de plantilla de estrategia de prueba de rendimiento
Acerca de la aplicación de chat ABC - Supongamos que se trata de un banco de trabajo de chat que utiliza en una empresa su agente de atención al cliente, esta aplicación de chat utiliza el protocolo XMPP, es decir, el protocolo de presencia y mensajería extensible y el servidor de fuego abierto para enviar y recibir mensajes instantáneos.
Se han realizado algunas mejoras en este cliente de chat existente, como control remoto de PC, diagnóstico de PC, herramientas de reparación, chat en línea, etc., por lo que esta estrategia de prueba de rendimiento es una muestra de dichas aplicaciones.
Para esta aplicación, supongamos que el equipo del proyecto ha decidido utilizar JMeter para pruebas de rendimiento y JIRA para seguimiento de defectos.
La primera página del documento de estrategia de prueba de rendimiento debe contener el título del documento y los derechos de autor de la empresa.
La segunda página debe contener el control de documentos, que incluye el historial de versiones del documento, la lista de revisores y aprobadores y la lista de colaboradores.
La tercera página debe contener el índice, seguida de los temas siguientes.
#1. Introducción
El propósito de este documento es definir / explicar cómo se realizarán las pruebas de rendimiento en la aplicación de chat ABC para el estado actual y futuro.
La aplicación de chat ABC es un banco de trabajo de agente de soporte remoto interno. Este banco de trabajo se utilizará para satisfacer las solicitudes de los clientes. Este banco de trabajo tiene capacidades como chat en línea, identificación de clientes, control remoto de PC, diagnóstico de PC y herramientas de reparación.
Objetivo
Los objetivos clave de las pruebas de rendimiento son los siguientes:
- Ganar la confianza de que los cambios en la aplicación de chat existente están en línea con el Acuerdo de nivel de servicio definido.
- Para garantizar que el rendimiento de la aplicación, la disponibilidad del servicio y la estabilidad de la aplicación no se vean afectados como resultado de las nuevas mejoras.
- Los tiempos de respuesta de las transacciones permanecen dentro de la tolerancia aceptable sobre el perfil de carga creciente.
- Las JVM muestran un uso de memoria estable sobre los perfiles de carga crecientes.
La siguiente imagen explica claramente el proceso de optimización y pruebas de rendimiento:
Arquitectura
Necesita incorporar el diagrama de arquitectura de su proyecto en esta sesión.
#2. Alcance
En alcance
A continuación se muestra el alcance de las pruebas de rendimiento para el banco de trabajo de chat ABC:
- Adquisición de conocimiento de las transacciones comerciales clave y distribución de carga de construcción después de un estudio detallado del sistema.
- Identifique los escenarios críticos para las pruebas de rendimiento con la ayuda de diferentes pistas del proyecto.
- Utilice los resultados de la versión anterior como referencia para futuras versiones.
- Verifique y valide el entorno de prueba de rendimiento y la infraestructura de la herramienta de prueba de rendimiento / carga para cualquier máquina agente adicional.
- Preparación de scripts de prueba de rendimiento utilizando JMeter para los escenarios identificados que imitan la carga máxima identificada.
- Configure la supervisión del rendimiento en los servidores para supervisar la prueba con el fin de identificar los cuellos de botella durante la fase de ejecución de la prueba.
- Publique los resultados de la prueba de rendimiento.
- Coordinar con varias partes interesadas para resolver los problemas de desempeño identificados.
- Haga referencia al nivel de rendimiento para versiones futuras.
Fuera del ámbito
- Pruebas funcionales , UAT, pruebas de sistemas y pruebas de seguridad.
- Prueba de rendimiento / monitoreo de cualquier interfaz de terceros.
- La optimización del rendimiento. (La mayoría de las veces, el ajuste lo realiza un equipo diferente, si tiene ingenieros de rendimiento para ajustar el sistema, puede agregarlo en el Inscope).
- Creación de perfiles de código / dimensionamiento de hardware / planificación de capacidad.
- Seguridad / Pruebas de vulnerabilidad / UAT / Prueba de caja blanca .
- Generación de datos para pruebas de rendimiento.
- Pruebas no funcionales ( Por ejemplo, conmutación por error, recuperación ante desastres, copia de seguridad, usabilidad) además de las pruebas de rendimiento.
- Prueba de cualquier solución móvil.
- Pruebas y ajustes de rendimiento de aplicaciones de terceros.
- La realización de las recomendaciones de rendimiento, los cambios en el código de la aplicación y los productos admitidos por el proveedor / cambios en la configuración del servidor estarán fuera del alcance desde la perspectiva del Equipo de rendimiento.
- Soporte de infraestructura / Implementación de compilación / Preparación del entorno / Restauración de base de datos / Soporte de red, etc.
# 3) Enfoque
Las pruebas de rendimiento para el chat ABC se llevarán a cabo utilizando Jmeter escribiendo complementos XMPP personalizados que utilizan una biblioteca de smack para conexiones XMPP. Estas bibliotecas se utilizan para configurar conexiones, iniciar sesión y enviar mensajes de chat al servidor XMPP.
Estas bibliotecas están empaquetadas en un archivo jar que se implementa en Jmeter y está diseñado en función de los escenarios que se probarán. El banco de trabajo Jmeter se instala en la máquina local que se conecta al servidor JMeter que tiene los generadores de carga para generar la carga requerida en el sistema del servidor de chat para monitorear el comportamiento del sistema.
El escenario de prueba se escribirá mediante la herramienta JMeter. Los scripts se personalizarán según sea necesario. El cronograma se creará con la aceleración necesaria para simular los escenarios del mundo real.
El escenario de prueba se dividiría y mediría en los siguientes aspectos:
a) Prueba de referencia: Ejecutar cada escenario con 1 Vuser y varias iteraciones para identificar si el rendimiento de la aplicación cumple o no con el Acuerdo de nivel de servicio empresarial.
b) Prueba de carga base: Para cumplir con el Business Benchmark bajo prueba de carga, el equipo de Performance Testing realizará una prueba de carga base que ayudará a identificar cualquier problema de rendimiento del sistema con el aumento de la carga y crea la línea de base para el siguiente nivel de prueba de rendimiento.
c) Prueba de carga máxima / escalabilidad: El equipo de pruebas de rendimiento realizará varias pruebas con Vusers cada vez mayores para cumplir con la carga esperada y también para medir el rendimiento de la aplicación para establecer la curva de rendimiento e identificar si la implementación puede admitir los acuerdos de nivel de servicio bajo la carga máxima de usuarios.
Ayuda a ajustar o planificar la capacidad de las máquinas virtuales Java individuales (JVM), el número total de JVM necesarias y los procesadores. Esto se logrará aumentando el número de Vusers al 50%, 75%, 100% y 125% de la capacidad máxima.
D) Test de resistencia: El equipo de pruebas de rendimiento ejecutará esta prueba durante un período de 8 horas / 16 horas / 24 horas para identificar fugas de memoria, problemas de rendimiento a lo largo del tiempo y estabilidad general del sistema. Durante las pruebas de resistencia, el equipo de pruebas de rendimiento supervisa los indicadores clave de rendimiento, como los tiempos de respuesta de las transacciones y la estabilidad del uso de la memoria.
Los recursos del sistema como CPU, memoria e IO deben monitorearse con la ayuda del equipo del proyecto.
Se supone que el entorno de prueba de rendimiento es una réplica del entorno de producción. Las pruebas se ejecutarán con una carga incremental para identificar dónde falla la aplicación.
Escenarios de prueba de rendimiento
Incluya el Excel con el conjunto de escenarios.
Por ejemplo,
Escenario 1: Para validar el chat de agente y cliente para X no. de sesiones concurrentes.
Tipos de prueba de rendimiento
La tabla que se muestra a continuación explica los distintos tipos de pruebas de rendimiento junto con sus objetivos.
| Tipo de prueba | Objetivo |
|---|---|
| UAT | Pruebas de aceptación del usuario |
| Prueba de referencia | Establecer el mejor rendimiento bajo volúmenes específicos que se utilizarán como referencia para posteriores mediciones. |
| Prueba de carga | Mida el rendimiento del sistema bajo la carga máxima de producción anticipada. |
| Test de resistencia | Medición de la estabilidad del sistema a gran volumen durante un período prolongado. |
| Prueba de estrés | Mida el rendimiento del sistema en condiciones desfavorables. |
Métricas de rendimiento
- Métricas del lado del cliente
| S.No | Métrico | Descripción | Formato |
|---|---|---|---|
| 1 | Tiempo de respuesta de la transacción | Tiempo de respuesta de las páginas durante el estado estable de la prueba de rendimiento | Grafico |
| 2 | Rendimiento | La cantidad de datos que los VUsers recibieron del servidor a lo largo del tiempo. | Grafico |
| 3 | Golpes / segundo | El número de solicitudes HTTP realizadas por VUsers al servidor web durante la ejecución del escenario. | Grafico |
| 4 | Número de transacciones aprobadas / fallidas | Número total de transacciones que pasaron y fallaron durante la ejecución de la prueba | Excel |
| 5 | Tasa de error de transacción | El porcentaje de transacciones que fallaron durante la ejecución de la prueba | Grafico |
- Métricas de rendimiento del sistema y la red
Actividades y entregables de pruebas de rendimiento
# 4) Datos de prueba
Se supone que los datos del entorno de rendimiento serán una copia de los datos de producción y el equipo del proyecto proporcionará los datos de prueba necesarios.
# 5) Criterios de entrada y salida
- Acceso a todas las aplicaciones del entorno.
- Preparación ambiental completa.
- Disponibilidad de datos de prueba de rendimiento.
# 6) Gestión de defectos
- El módulo de gestión de defectos en JIRA se utilizará en el proyecto para el registro de defectos y para el seguimiento hasta el cierre.
- La identificación de los defectos que se encuentren durante la fase de ejecución de la prueba se capturará en JIRA y estos defectos serán resueltos por el equipo de desarrollo de acuerdo con las siguientes severidades.
- Las reuniones de revisión de defectos se llevarían a cabo a diario con la participación de los equipos de prueba, desarrollo, calidad y negocios.
- Los criterios para corregir los defectos se volverán más estrictos a medida que el proyecto se acerque a la fecha de lanzamiento. Directrices para los criterios de corrección de defectos que se publicarán en las reuniones de revisión de defectos.
Definición de gravedad del defecto
Las definiciones de los códigos de gravedad son las siguientes:
| Gravedad | Descripción para problemas de desarrollo y mejora |
|---|---|
| Bloqueador | Error del sistema, mostrar tope, problemas de red |
| Crítico | Errores del sistema, ninguna solución clara, interrupción o falta de funcionalidad empresarial |
| Importante | Se detectó un problema grave para el cual existe una solución alternativa que podría no estar clara para todos los usuarios; sin embargo, el producto no debe lanzarse sin solucionarlo. |
| Medio | Existe un problema con una solución fácil / simple, pero este tipo de defecto puede ser liberado con la aprobación de la empresa y / o el gerente de proyecto. |
| Bajo | Problemas cosméticos que no interfieren con la funcionalidad comercial u otros problemas intermitentes que no son reproducibles en todo momento. |
# 7) Herramientas y técnicas de prueba
| Instrumentos | Propósito |
|---|---|
| Jmeter | Verificar la Carga y Rendimiento de la aplicación ABC Chat. |
# 8) Criterios de suspensión y reanudación
A continuación se detallan los criterios de suspensión crítica y reanudación que afectarán las actividades de prueba:
| Suspensión | Impacto | Reanudación |
|---|---|---|
| Entorno no configurado | La prueba no puede continuar | Preparación del medio ambiente. |
| Aplicación inestable | La prueba no puede continuar. | Problema resuelto |
| Datos de prueba no disponibles | La prueba no puede continuar. | Datos de prueba listos |
# 9) Entrega de prueba
Los entregables de la prueba de rendimiento incluyen:
preguntas y respuestas de la entrevista básica sql pdf
- Estrategia de prueba de rendimiento
- Documento de requisitos de desempeño
- Documento de escenario de prueba de rendimiento
- Scripts de prueba de rendimiento
- Resultados de la prueba de rendimiento
# 10) Roles y responsabilidades
Los roles y responsabilidades se explican claramente en la tabla que se proporciona a continuación.
# 11) Riesgos potenciales y plan de mitigación
| S.No | Riesgo | Probabilidad | Impacto | Plan de mitigación | Dueño |
|---|---|---|---|---|---|
| 1 | No disponibilidad de datos de prueba para ejecuciones de prueba de carga de rendimiento | H | H | Deben revisarse y actualizarse las fechas estimadas para las ejecuciones de las pruebas de rendimiento. Se requiere soporte funcional / del equipo de desarrollo para la recopilación de datos. | -- |
| 2 | Cuestiones ambientales | L | METRO | Volver a priorizar los entregables | -- |
| 3 | Cambio en la funcionalidad / diseño durante la ejecución de la prueba de rendimiento | METRO | H | Esto requiere volver a trabajar en los escenarios de prueba de rendimiento. | -- |
| 4 | Se ejecuta un rendimiento adicional para solucionar problemas de rendimiento | METRO | H | Los programas de pruebas de rendimiento se modificarían y actualizarían para el equipo de producto. | -- |
| 5 | Las estimaciones se preparan en base a una compilación de corrección de errores para el rendimiento. Varias compilaciones de corrección de errores retrasarán los ciclos de prueba y, finalmente, depende de cuándo estará disponible la siguiente compilación para volver a ejecutarla. | H | H | Vuelva a priorizar los ciclos de ejecución de las pruebas de rendimiento. | -- |
| 6 | Disponibilidad de hardware | METRO | H | La fecha de inicio del programa se moverá en consecuencia. | -- |
# 12) Supuestos
- Performance Test Environment será una réplica del panorama de la arquitectura del producto. (es decir, hardware, software, interfaces, capas de integración, etc. correctos).
- Los scripts de rendimiento se diseñarán en función de los flujos críticos para los que el uso sea elevado.
- Todos los problemas de infraestructura deben resolverse antes del comienzo de las pruebas de rendimiento. Cualquier cambio de configuración del sistema realizado más tarde invalidará los resultados de la prueba.
- Una aplicación es estable y está lista para usarse en el entorno de prueba de rendimiento.
- Los recursos de hardware y software necesarios (como máquinas / software de generación de carga, máquinas de controlador / agente) están disponibles.
- Cualquier cambio en el alcance pasará por un proceso de control de cambios y el equipo de pruebas de desempeño evaluará el impacto de los plazos y los recursos.
- Se espera que los respectivos servidores manejen la carga.
- Los registros de seguimiento de aplicaciones deben habilitarse para los sistemas de soporte con fines de monitoreo.
# 13) Dependencias
- Disponibilidad del entorno de prueba de rendimiento, que es una réplica del panorama de la arquitectura del producto.
- Soporte requerido de varios equipos de Funcionalidad, Desarrollo, Base de Datos e Infraestructura durante las etapas de preparación y ejecución de la prueba.
- No se implementan cambios de código durante toda la fase de prueba de rendimiento, ya que el tiempo es muy limitado.
- En el caso de problemas imprevistos que lleven a restricciones dentro de los plazos, si los plazos no permiten que se cumplan todos los alcances de la prueba dentro de las fechas del hito original, los gerentes de versiones brindan soporte para proporcionar una decisión sobre el alcance y la priorización.
- Los usuarios comerciales de aplicaciones / expertos en la materia estarán disponibles para aclaraciones funcionales y aprobación de transacciones comerciales.
- El administrador del programa de chat ABC revisará y cerrará.
# 14) Abreviaturas
| Abreviatura | Descripción |
|---|---|
| DB | Base de datos |
| Http | Protocolo de Transferencia de Hipertexto |
| JDBC | Conectividad de base de datos Java |
| QA | Seguro de calidad |
| LECHUGA | Acuerdo de nivel de servicio |
| PYME | Experto en la materia |
A estas alturas, debe haber entendido claramente cómo escribir una estrategia de prueba de rendimiento eficaz para una aplicación de mensajería.
Mejores prácticas para pruebas de rendimiento realistas
Para completar un proyecto de prueba de rendimiento con éxito, debemos asegurarnos de que lo estamos haciendo de la manera correcta desde la etapa de planificación, es decir, planificación, desarrollo, ejecución y análisis.
Echemos un vistazo a cada etapa en detalle para realizar pruebas de rendimiento de manera efectiva.
# 1) Planificación
- Intente identificar los flujos de trabajo más comunes, es decir, los escenarios comerciales que deben probarse. Si la aplicación es una existente, verifique los registros del servidor para comprender los escenarios a los que se accede con más frecuencia. Si la aplicación es nueva, hable con el equipo de gestión del proyecto para comprender el flujo comercial principal.
- Planifique la prueba de carga de tal manera que cubra una amplia gama de flujos de trabajo como uso ligero, uso medio y cargas máximas.
- Necesita realizar muchos ciclos de la prueba de carga, así que intente crear un marco para que pueda usar los mismos scripts una y otra vez. Además, intente tener una copia de seguridad de los scripts.
- Intente analizar cuánto tiempo debe ejecutarse una prueba, ¿es una hora? ¿8 horas? ¿Un día o una semana? Por lo general, las pruebas de larga duración descubrirán muchos defectos importantes, como errores del sistema operativo, fugas de memoria, etc.
- Si su organización utiliza alguna APM (herramienta de supervisión de aplicaciones), puede incluirla durante las ejecuciones de prueba para que pueda identificar fácilmente los problemas de rendimiento e identificar la causa raíz más fácilmente.
# 2) Desarrollo
- Mientras desarrolla los scripts, es decir, la grabación, intente dar un nombre de transacción más significativo en función de los nombres de los flujos comerciales que se mencionan en el plan.
- No grabe ninguna aplicación de terceros y, si se graba, intente filtrarla mientras mejora los scripts.
- No todos los valores dinámicos pueden correlacionarse usando la función de Autocorrelación en la herramienta, así que intente hacer una correlación manual para evitar errores.
- Intente diseñar sus pruebas de rendimiento de tal manera que llegue al backend de la aplicación y no solo al servidor de caché.
# 3) Ejecución
- Asegúrese de ejecutar las pruebas en un entorno de producción, incluidos factores como SSL, Load Balancer y Firewalls. Esto es necesario para simular una carga realista en el sistema.
- Intente crear una carga de trabajo que sea muy realista, puede obtenerla verificando los registros del servidor si es una aplicación existente y si es una aplicación nueva, necesita obtener esta información del equipo comercial. Recuerde que la carga de trabajo es muy importante para realizar pruebas de desempeño exitosas.
- Nunca llegue a una conclusión ejecutando pruebas con la mitad del tamaño del entorno de producción, siempre se recomienda realizar las pruebas en un entorno que sea igual al de producción.
- Mientras realiza pruebas de ejecución prolongada, intente observar la ejecución a intervalos frecuentes para asegurarse de que la prueba se esté ejecutando sin problemas.
# 4) Análisis
- Intente analizar la aplicación agregando primero algunos contadores importantes, cuando se encuentre un cuello de botella, intente agregar contadores adicionales con respecto al cuello de botella. Esto, a su vez, ayudará a encontrar el problema más fácilmente.
- Una aplicación puede fallar por muchas razones, como no responder a una solicitud, responder con un código de error, fallar en la lógica de validación o responder con demasiada lentitud. Así que intente analizar todo esto antes de llegar a una conclusión.
Conclusión
Estoy seguro de que este tutorial le habría proporcionado un inmenso conocimiento sobre las pruebas de rendimiento y cómo escribir un documento de estrategia de prueba de rendimiento con ejemplos detallados.
En nuestro próximo tutorial, aprenderemos las diferencias entre Performance, Load y Stress Testing en detalle.
Además, Check => Serie de entrenamiento en profundidad Free LoadRunner
Lectura recomendada
- Pruebas de rendimiento frente a pruebas de carga frente a pruebas de estrés (diferencia)
- Pruebas de carga con tutoriales de HP LoadRunner
- Prueba de rendimiento en la nube: proveedores de servicios de prueba de carga basados en la nube
- Pruebas de carga, estrés y rendimiento de aplicaciones web con WAPT
- Herramientas y servicios de pruebas de rendimiento del sitio web
- ¿Cómo realizar pruebas de rendimiento manuales?
- Pruebas de rendimiento de aplicaciones móviles con BlazeMeter
- Pruebas de rendimiento de servicios web mediante secuencias de comandos LoadRunner VuGen