En las pruebas de rendimiento, ¿cuáles son los riesgos asociados con el proceso?

Las pruebas de rendimiento son indispensables para gestionar ciertos riesgos comerciales importantes. Por ejemplo, si su sitio web no puede manejar el volumen de tráfico que recibe, sus clientes comprarán en otro lugar. Más allá de identificar los riesgos obvios, las pruebas de rendimiento pueden ser una forma útil de detectar muchos otros problemas potenciales.

Si bien las pruebas de rendimiento no reemplazan otros tipos de pruebas, pueden revelar información relevante para la usabilidad, la funcionalidad, la seguridad y la imagen corporativa que es difícil de obtener de otras maneras.

Muchas empresas y probadores de rendimiento consideran valioso pensar en los riesgos que las pruebas de rendimiento pueden abordar en términos de tres categorías: velocidad, escalabilidad y estabilidad.

Comprenda cómo se ven la velocidad, la escalabilidad y la estabilidad desde una perspectiva de evaluación del rendimiento.

Conozca cómo se pueden usar las pruebas de rendimiento para mitigar los riesgos relacionados con la velocidad, la escalabilidad y la estabilidad. Conozca los aspectos de estos riesgos que las pruebas de rendimiento no abordan de manera adecuada.

aprenda sobre los riesgos de rendimiento típicos, los tipos de prueba de rendimiento relacionados con esos riesgos y las estrategias comprobadas para mitigar esos riesgos.

La sección “Matriz de resumen” permite comprender los diferentes tipos de pruebas y los riesgos que pueden mitigar. Utilice las diversas secciones de tipos de riesgo para comprender las estrategias relacionadas.

eso puede ayudarlo a determinar el mejor enfoque de prueba para su situación particular.

Riesgos relacionados con la velocidad:

Los riesgos relacionados con la velocidad no se limitan a la satisfacción del usuario final, aunque eso es lo que la mayoría de la gente piensa primero. La velocidad también es un factor en ciertos negocios y datos.

riesgos relacionados Algunos de los riesgos más comunes relacionados con la velocidad que las pruebas de rendimiento pueden abordar incluyen:

  • ¿Es la aplicación lo suficientemente rápida como para satisfacer a los usuarios finales?
  • ¿La empresa puede procesar y utilizar los datos recopilados por la aplicación antes de que los datos se vuelvan obsoletos? (Por ejemplo, los informes de fin de mes vencen dentro de las 24 horas del cierre de operaciones del último día del mes, pero la aplicación tarda 48 horas en procesar los datos).
  • ¿Es la aplicación capaz de presentar la información más reciente (por ejemplo, cotizaciones de bolsa) a sus usuarios?
  • ¿Responde un servicio web dentro del tiempo de respuesta máximo esperado antes de que se produzca un error?

Estrategias de mitigación de riesgos relacionadas con la velocidad:

Las siguientes estrategias son valiosas para mitigar los riesgos relacionados con la velocidad:

  • Asegúrese de que sus requisitos y objetivos de rendimiento representen las necesidades y los deseos de sus usuarios, no de los de otra persona.
  • Compare sus mediciones de velocidad con versiones anteriores y aplicaciones de la competencia.
  • Diseñe pruebas de carga que repliquen la carga de trabajo real tanto en horas pico normales como previstas.
  • Realice pruebas de rendimiento con tipos de datos, distribuciones y volúmenes similares a los utilizados en las operaciones comerciales durante la producción real (por ejemplo, número de productos, pedidos en estado pendiente, tamaño de la base de usuarios). Puede permitir que los datos se acumulen en bases de datos y servidores de archivos, o crear el volumen de datos, antes de la ejecución de la prueba de carga.
  • Utilice los resultados de las pruebas de rendimiento para ayudar a los interesados ​​a tomar decisiones informadas sobre arquitectura y negocios.
  • Solicite comentarios representativos sobre la satisfacción de los usuarios con el sistema mientras se encuentra bajo la carga máxima esperada.
  • Incluya transacciones de tiempo crítico en sus pruebas de rendimiento.
  • Asegúrese de que al menos algunas de sus pruebas de rendimiento se lleven a cabo mientras se ejecutan procesos periódicos del sistema (por ejemplo, descarga de actualizaciones de definiciones de virus o copias de seguridad semanales).
  • Mida la velocidad bajo diversas condiciones, niveles de carga y combinaciones de escenarios. (Los usuarios valoran la velocidad constante)
  • Valide que se hayan visualizado y guardado todos los datos correctos durante la prueba de rendimiento. (Por ejemplo, un usuario actualiza información, pero la pantalla de confirmación aún muestra la información anterior porque la transacción no ha completado la escritura en la base de datos).

Riesgos relacionados con la escalabilidad:

Los riesgos de escalabilidad conciernen no solo a la cantidad de usuarios que puede admitir una aplicación, sino también al volumen de datos que la aplicación puede contener y procesar, así como a la capacidad de identificar cuándo una aplicación se acerca a su capacidad. Los riesgos comunes de escalabilidad que pueden abordarse mediante pruebas de rendimiento incluyen:

¿Puede la aplicación proporcionar tiempos de respuesta consistentes y aceptables para toda la base de usuarios?

  • ¿La aplicación puede almacenar todos los datos que se recopilarán durante la vida de la aplicación?
  • ¿Hay señales de advertencia para indicar que la aplicación se está acercando a la capacidad máxima?
  • ¿La aplicación seguirá siendo segura bajo un uso intensivo?
  • ¿Se verá comprometida la funcionalidad bajo un uso intensivo?
  • ¿Puede la aplicación soportar cargas pico no anticipadas?

Estrategias de mitigación de riesgos relacionadas con la escalabilidad:

Las siguientes estrategias son valiosas para mitigar los riesgos relacionados con la escalabilidad:

Compare las velocidades medidas bajo diversas cargas. (Tenga en cuenta que el usuario final no sabe o no le importa cuántas personas están usando la aplicación al mismo tiempo que él / ella).

  • Diseñe pruebas de carga que repliquen la carga de trabajo real tanto en horas pico normales como previstas.
  • Realice pruebas de rendimiento con tipos de datos, distribuciones y volúmenes similares a los utilizados en las operaciones comerciales durante la producción real (por ejemplo, número de productos, pedidos en estado pendiente, tamaño de la base de usuarios).
  • Puede permitir que los datos se acumulen en bases de datos y servidores de archivos, o crear el volumen de datos, antes de la ejecución de la prueba de carga.
  • Utilice los resultados de las pruebas de rendimiento para ayudar a los interesados ​​a tomar decisiones informadas sobre arquitectura y negocios.
  • Trabaje con pruebas de rendimiento más significativas que se ajusten a los requisitos del mundo real.
  • Cuando encuentre un límite de escalabilidad, reduzca gradualmente la carga y vuelva a realizar la prueba para ayudarlo a identificar una métrica que pueda servir como un indicador confiable de que la aplicación se acerca a ese límite con tiempo suficiente para que pueda aplicar contramedidas.
  • Valide la precisión funcional de la aplicación bajo diversas cargas comprobando las entradas de la base de datos creadas o validando el contenido devuelto en respuesta a solicitudes de usuarios particulares.
  • Realice pruebas de rendimiento más allá de las cargas máximas esperadas y observe el comportamiento haciendo que usuarios representativos y partes interesadas accedan a la aplicación manualmente durante y después de la prueba de rendimiento.

Riesgos relacionados con la estabilidad:

La estabilidad es un término general que abarca áreas como la fiabilidad, el tiempo de actividad y la capacidad de cobertura. Si bien los riesgos de estabilidad suelen abordarse con pruebas de carga, resistencia y estrés, a veces se detectan problemas de estabilidad durante las pruebas de rendimiento más básicas. Algunos riesgos comunes de estabilidad abordados por medio de pruebas de rendimiento incluyen.

  • ¿Puede la aplicación funcionar durante largos períodos de tiempo sin que se reinicien los datos, la ralentización o los servidores que necesitan reiniciarse?
  • Si la aplicación se cierra inesperadamente, ¿qué ocurre con las transacciones parcialmente completadas?
  • Cuando la aplicación vuelve a estar en línea después del tiempo de inactividad programado o no programado, ¿los usuarios podrán ver / hacer todo lo que esperan?
  • Cuando la aplicación vuelve a estar en línea después de un tiempo de inactividad no programado, ¿se reanuda en el punto correcto? En particular, ¿no intenta reanudar transacciones canceladas?
  • ¿Pueden las combinaciones de errores o errores funcionales repetidos causar un bloqueo del sistema?
  • ¿Hay alguna transacción que cause efectos secundarios en todo el sistema?
  • ¿Se puede eliminar una parte del entorno de equilibrio de carga y aún proporcionar un servicio ininterrumpido a los usuarios?
  • ¿Se puede reparar o actualizar el sistema sin quitarlo?

Estrategias de mitigación de riesgos relacionadas con la estabilidad:

Las siguientes estrategias son valiosas para mitigar los riesgos relacionados con la estabilidad:

  • Tómese el tiempo para las pruebas de resistencia realistas.
  • Llevar a cabo pruebas de estrés con los escenarios clave. Trabajar con indicadores clave de rendimiento (red, disco, procesador, memoria) e indicadores de negocio, como el número de pedidos perdidos, fallas de inicio de sesión de usuario, etc.
  • Realice pruebas de estrés con feeds de datos que reproduzcan operaciones comerciales similares a las de un entorno de producción real (p. Ej., Número de productos, pedidos en estado pendiente, tamaño de la base de usuarios). Puede permitir que los datos se acumulen en bases de datos y servidores de archivos, o adicionalmente crear el volumen de datos, antes de la ejecución de la prueba de estrés. Esto le permitirá replicar errores críticos tales como interbloqueos de bases de datos o aplicaciones y otros patrones de fallas de estrés.
  • Ponga un servidor fuera de línea durante una prueba y observe los comportamientos funcionales, de rendimiento y de integridad de datos de los sistemas restantes.
  • Ejecute pruebas idénticas inmediatamente antes y después de un reinicio del sistema. Compara los resultados. Puede usar un enfoque idéntico para reciclar servicios o procesos.
  • Incluya casos de error o excepción en los escenarios de prueba de rendimiento (por ejemplo, usuarios que intentan iniciar sesión con credenciales incorrectas).
  • Aplique un parche al sistema durante una prueba de rendimiento.
  • Fuerce una actualización de la seguridad y / o la copia de seguridad durante una prueba de rendimiento.

Velocidad :

La respuesta rápida a la solicitud es directamente proporcional a la satisfacción del usuario final. Muchos empresarios venden su idea con la velocidad como uno de sus principales puntos de venta. Por lo tanto, la velocidad también puede ser una parte del riesgo comercial. Entonces, ¿cómo abordar los riesgos relacionados con la velocidad?

Estrategias de mitigación de riesgos para riesgos relacionados con la velocidad :

  • Es extremadamente importante asegurarse de que los objetivos de rendimiento sean los requisitos del usuario final y no las aspiraciones de algún administrador.
  • Uno siempre debe comparar los números de tiempo de respuesta y el rendimiento del sistema con sus lanzamientos anteriores / contador comparable del competidor
  • La prueba de rendimiento debe simular el comportamiento de producción y, por lo tanto, la carga de trabajo debe diseñarse teniendo en cuenta la carga de producción en el sistema.
  • Los resultados de la prueba de rendimiento de la versión anterior se deben usar para tomar decisiones con respecto a la aplicación, el diseño del sistema y la arquitectura
  • Las pruebas de rendimiento deben incluir transacciones que consumen más (que otros) recursos, flujos comerciales que son más críticos para el rendimiento y transacciones que son más críticas en términos de tiempo.
  • Tener producción como el volumen de datos en la base de datos de prueba de rendimiento para simular el comportamiento del entorno de producción mientras se prueba
  • Tome medidas para la ejecución de pruebas de rendimiento durante actividades periódicas como lotes diarios, etc.
  • Ejecute varias rondas de pruebas para garantizar la coherencia en los resultados
  • Ejecute pruebas bajo diferentes niveles de carga de transacción y en diferentes escenarios
  • Asegúrese de que los datos generados / almacenados en la base de datos durante la prueba sigan las reglas y la lógica de negocios y no haya datos corruptos.

Escalabilidad :

La escalabilidad es otro aspecto crítico que se considera al diseñar la aplicación y al realizar las pruebas de rendimiento. Todos los equipos aspiran a construir una aplicación escalable que no falle bajo las altas cargas esperadas. En tales escenarios, el objetivo es no mostrar ningún error al usuario final y no perder datos.

Estrategias de mitigación de riesgos para riesgos relacionados con la escalabilidad :

  • Pruebe la aplicación con diferentes cargas de usuarios y compare los resultados en diferentes pruebas
  • Intente replicar la carga de producción y ejecute la prueba con la misma carga en niveles normales y máximos
  • Pruebas de diseño que pueden correlacionar directamente los problemas comerciales del mundo real
  • Cuando se alcanza en el punto de tensión donde se rompe la aplicación, reduzca gradualmente la carga y anote los números de rendimiento para cada volumen de carga. Luego identifique la carga (carga máxima) a la que el sistema puede cumplir los SLA comerciales (en términos de números de rendimiento)
  • Después de la prueba, asegúrese de que la aplicación haya realizado entradas válidas a la base de datos y la ejecución posterior a la ejecución de la respuesta frontal
  • Siempre vaya un poco más allá de la carga máxima esperada y evalúe el comportamiento del sistema bajo tal carga

Estabilidad:

La estabilidad abarca la fiabilidad, el tiempo de actividad y la capacidad de recuperación. Los problemas de estabilidad se identifican a partir del rendimiento, el estrés y las pruebas de larga duración.

Estrategias de mitigación de riesgos para riesgos relacionados con la estabilidad :

  • Las pruebas de resistencia se deben planear bien y deben replicar el escenario de larga duración para la aplicación de esa manera en la producción
  • Monitoree los servidores para sus contadores clave (utilización db, utilización de la memoria) mientras realiza pruebas de estrés
  • Reduzca un componente del sistema (o infraestructura) mientras realiza pruebas de rendimiento y mida su impacto en el sistema durante la prueba.
  • Aplique un parche al sistema mientras se prueba el rendimiento
  • Reinicie toda la infraestructura y luego pruebe el sistema. Compare estos resultados con las pruebas sin reiniciar
  • Fuerce pruebas negativas durante las pruebas de rendimiento

Por lo tanto, utilizando estas estrategias clave de mitigación, se pueden abordar casi todos los riesgos relacionados con el sistema y el negocio.

Asumir que las pruebas de rendimiento solo son útiles para las pruebas de extremo a extremo

Esto ciertamente no es el caso. Puede realizar pruebas de rendimiento de manera útil tan pronto como tenga algo que pueda ejecutarse. Parte del mensaje de DevOps implica hacer que las pruebas funcionales formen parte de la integración continua (IC), ¿por qué no realizar pruebas de rendimiento? Un reciente encargo de consultoría involucró la implementación de pruebas de rendimiento como parte del modelo de desarrollo ágil del cliente; en otras palabras, versiones de código de referencia y tendencias en una etapa muy temprana en las construcciones dentro del sprint para que cualquier regresión de rendimiento o escalabilidad pueda ser identificada y corregida rápidamente . Esto resultó en la victoria doble de mejorar notablemente la calidad de la entrega y mitigar la promoción accidental de defectos de rendimiento en niveles más altos de pruebas o producción.

Gestión del entorno de prueba de rendimiento (mis)

El entorno de prueba de rendimiento debe ser adecuado para el propósito; de lo contrario, corre el riesgo de obtener resultados engañosos. Necesita una comprensión precisa de cómo difiere el entorno de la producción en términos de configuración, escala horizontal y vertical y contenido de la base de datos. Debe haber un proceso confiable para restaurar el entorno a un estado conocido y, quizás lo más importante de todo, los entornos de prueba deben ser de propiedad central, administrados y aprovisionados. Finalmente, a menos que realmente no tenga otra opción, intente mantener los entornos de prueba de rendimiento para las pruebas de rendimiento, ya que el uso compartido aumenta en gran medida el riesgo de incoherencia en el entorno.

No crear un modelo preciso de carga de trabajo

El modelo de carga de trabajo (WLM) es la base de cualquier requisito de prueba de rendimiento, por lo que debe ser un reflejo preciso del uso anticipado de la aplicación. Tomar atajos con los riesgos de diseño invalida su prueba. Debe considerar el WLM como el modelo para su requisito de prueba de rendimiento que describe todos los activos que deben crearse para la prueba de rendimiento de manera efectiva. Siempre debe basarse en datos empíricos recopilados por la empresa y validados por los arquitectos de la solución. El WLM debe describir la distribución de la carga en todos los casos de uso para el volumen, el estrés y los escenarios de prueba de inmersión, incluida la estimulación realista y una distribución y provisión de inyección de carga apropiadas. Siempre que sea posible, también debe describir las métricas de rendimiento que se recopilarán y las tendencias, en particular las específicas para la pila tecnológica de la aplicación.

La falta de métricas ambientales

Es vital que controle el entorno cuando realice pruebas de rendimiento. La cosecha actual de conjuntos de herramientas de prueba de rendimiento proporciona un montón de análisis útiles desde la perspectiva del cliente de la aplicación; sin embargo, para evaluar problemas de manera efectiva o establecer un punto de referencia de rendimiento significativo, debe comprender cómo la carga que genera afecta la infraestructura de alojamiento. En un monitor mínimo absoluto CPU, memoria disponible, disco, E / S de red y cualquier métrica adicional identificada como parte de WLM. Como nota final, asegúrese de que el intervalo de monitoreo que seleccione proporcionará suficientes datos para un análisis estadístico significativo. Recomiendo un mínimo de cada 30 segundos.

Conclusión

Las pruebas de rendimiento efectivas dependen de un modelo de carga de trabajo preciso, un entorno de prueba dedicado que sea realmente adecuado para el propósito y la confianza de que está supervisando, y la captura de todas las métricas de KPI esenciales que se relacionan con su aplicación. Si elige acortar cualquiera de estos requisitos clave, se arriesga a una visión engañosa del verdadero rendimiento y la escalabilidad de su aplicación, lo que podría generar un viernes muy negro.