Cuando se trata de pruebas de carga, siempre existe la pregunta del millón: “En términos de rendimiento, ¿qué quiere hacer el cliente con su aplicación y sistema?” Estoy bastante seguro de que nunca obtendrá una respuesta fácil a esa pregunta, y la mayoría de nosotros siempre asumimos algunas cosas y llevar a cabo las pruebas de rendimiento, que pueden terminar faltando piezas críticas de prueba, y terminar con un cliente infeliz. Un cliente infeliz significa la pérdida de negocio para su organización y una carrera en declive como ingeniero de rendimiento. Pero no te preocupes, en este artículo vamos a hablar de crear una lista de verificación que te ayudará con esas preguntas.

Esta lista de verificación es más como un proceso paso a paso que puede seguir y adaptar al ciclo de vida de sus pruebas de rendimiento. En el escenario discutido, no siempre podemos culpar a nuestros clientes, porque inicialmente es posible que no sepan cuáles son los resultados de rendimiento exactos que desean, pero tienen un conocimiento claro sobre cómo funciona la aplicación en diferentes condiciones. Un buen probador de rendimiento puede manejar esta ambigüedad con un cuestionario bien definido. Y ese es el primer punto de la lista de verificación, el cuestionario de recopilación de requisitos.

Cuestionario de recopilación de requisitos

A continuación se muestra un formato de cuestionario que puede seguir en su proyecto. Necesitamos obtener tantas respuestas como sea posible para estas preguntas. Será mejor si usted puede tener una llamada para discutir estas preguntas. Asegúrese de que el arquitecto o desarrollador de la aplicación se une a la llamada con usted y el cliente. Tener personal adicional puede ayudar a proporcionar información y descubrir preguntas que es posible que no haya tenido en cuenta anteriormente. Las siguientes preguntas le proporcionan una hoja de ruta para crear una prueba de carga más eficiente y eficaz.

No Tema Preguntas
1 Aplicación Tipo de aplicación a tener en cuenta para las pruebas (por ejemplo, aplicación web / aplicación móvil, etc.).
2 Arquitectura de aplicaciones y tecnología/plataforma.
3 Técnica de equilibrio de carga utilizada.
4 Protocolo de comunicación entre cliente y servidor (por ejemplo: HTTP/S, FTP).
5 Objetivo de pruebas de rendimiento. Métricas de rendimiento que se van a supervisar (por ejemplo, tiempo de respuesta para cada una de las acciones, usuarios simultáneos, etc.).
6 Escenarios críticos que se deben tener en cuenta para las pruebas de rendimiento.
7 Detalles de los trabajos/procesos programados en segundo plano, si los hay.
8 Técnica utilizada para la administración de sesiones y el número de sesiones paralelas admitidas.
 
9 SLA del cliente/Requisitos Número esperado de usuarios simultáneos y base de usuarios total. Distribución de usuarios para escenarios en el ámbito.
10 SLA para todas las transacciones en el ámbito de PT (rendimiento esperado, tiempo de respuesta, etc.).
11 Tipos de pruebas de rendimiento a realizar (pruebas de carga, pruebas de resistencia, etc.).
 
12 Sistema/Medio ambiente Detalles del entorno de prueba (web/app/DB, etc., junto con el número de nodos). Entorno de producción recomendado para la ejecución de pruebas de rendimiento.
13 Comparación del entorno de producción y el entorno de prueba de rendimiento.
14 Si la aplicación se va a aislar durante la ejecución de la prueba de rendimiento para evitar la interacción con otra aplicación.
15 Detalles del mecanismo de registro integrado o del mecanismo de supervisión.
 
16 Otros Resultados de la línea base de rendimiento de la aplicación.
17 Problemas de rendimiento actuales, si los hay.

Las respuestas a estas preguntas le ayudarán a crear una estrategia de prueba de calidad / plan de prueba. Si el cliente no es capaz de proporcionar respuestas a todas estas preguntas, no hay necesidad de preocuparse. Siempre podemos explorar la aplicación bajo prueba y encontrar las respuestas. Por ejemplo, si una herramienta APM/log está en su lugar, podemos derivar usuarios simultáneos, rendimiento y tiempo de respuesta del sistema de producción. Nunca asuma que obtendrá lo que necesita sin preguntar.

Encuentre una herramienta de prueba de rendimiento adecuada

Un probador de rendimiento debe elegir cuidadosamente la mejor herramienta de prueba de rendimiento. Hay muchos factores que deben tenerse en cuenta antes de finalizar y proponer la herramienta. Recuerde, el presupuesto del cliente siempre es un factor importante al elegir la herramienta de prueba de rendimiento.

Si está buscando una herramienta de pruebas de rendimiento que sea rentable, fácil de usar y que pueda proporcionar una solución de rendimiento completa, definitivamente debe probar LoadView. En comparación con las herramientas de prueba de carga tradicionales, LoadView no requiere ninguna inversión costosa, configuración que requiera mucho tiempo o conocimientos previos de marcos de scripting. Además, la plataforma proporciona más de 20 ubicaciones globales desde las que los inyectores de carga derivada, por lo que puede probar y medir el rendimiento desde varias ubicaciones durante cada prueba.

Todos los tipos de pruebas de rendimiento requieren tiempo y esfuerzo. Realizar pruebas de carga puede salvar a una organización de una posible humillación, pero al mismo tiempo las pruebas en herramientas gratuitas de código abierto como JMeter no justificarán la inversión. Cuando se trata de comprender realmente el rendimiento del sitio web o la aplicación desde la perspectiva del usuario final, las pruebas basadas en protocolos no son suficientes. También debe medir el rendimiento de las interacciones y pasos del lado cliente. A continuación se ofrece una comparación de LoadView con otras soluciones de pruebas de rendimiento y carga y por qué debe elegir LoadView para sus requisitos de pruebas de rendimiento.

Cuando se trata de sitios y aplicaciones de carga lenta, los clientes pueden impacientarse rápidamente y se irán y encontrarán un reemplazo si su sitio / aplicación no cumple con sus expectativas. Saber cuánto puede manejar su sitio/aplicación es muy importante debido a varias razones, pero hay varios escenarios significativos con los que la plataforma LoadView puede ayudar:

  • Adaptabilidad y escalabilidad. Determinar por qué su sitio o aplicación se ralentiza cuando varios usuarios acceden a él.
  • Infraestructura. Comprender qué actualizaciones de hardware se necesitan, si las hay. El costo de implementar hardware adicional y mantenerlo podría ser un posible desperdicio de recursos.
  • Requisitos de rendimiento. Su sitio o aplicación puede manejar correctamente algunos usuarios, pero ¿qué sucede en situaciones del mundo real?
  • Servicios de terceros. Vea cómo se comportan los servicios externos cuando se presentan las condiciones de carga normales, o incluso pico.

Plan/Estrategia de Pruebas de Desempeño

Una vez que haya recopilado los requisitos del cliente y seleccionado la herramienta de pruebas de rendimiento adecuada, necesitamos documentar nuestra estrategia de plan de prueba/prueba. Asegúrese de obtener la firma del plan de prueba del cliente antes de iniciar cualquier actividad de rendimiento. Esto es muy importante, y le ayudará a evitar cualquier fallo innecesario más adelante. Estos son algunos puntos que deben incluirse en el plan de pruebas.

  • Objetivos de prueba de rendimiento. Lo que vamos a lograr.
  • Alcance del proyecto. Cuál es el alcance del proyecto, ejemplo: Número de scripts, cuánto tiempo necesitamos probar, etc.
  • Arquitectura de aplicaciones. Detalles de la aplicación, como servidor de aplicaciones, servidor de base de datos, puede incluir diagrama arquitectónico si lo tiene.
  • Detalles del entorno. Detalles sobre el entorno que vamos a probar. Siempre es bueno tener un entorno aislado para las pruebas de rendimiento.
  • Configuración de infraestructura. Configuración inicial para las pruebas de rendimiento (por ejemplo, entorno en la nube, instalación de herramientas, etc.).
  • Enfoque de prueba de rendimiento. Cómo vamos a llevar a cabo la prueba. Debemos comenzar con una prueba de línea de base con un número menor de usuarios, y luego gradualmente podemos aumentar los usuarios y realizar diferentes tipos de pruebas como estrés, resistencia, etc.
  • Criterios de entrada y salida. Esto es muy importante. Siempre debemos iniciar las pruebas de rendimiento cuando no hay defectos funcionales. De la misma manera que debemos documentar cuándo podemos detener las pruebas de rendimiento.
  • Gestión de defectos. Debemos seguir la misma herramienta y prácticas seguidas por el cliente para registrar defectos relacionados con las pruebas de rendimiento.
  • Funciones y responsabilidades. Detalles sobre los accionistas involucrados en las diferentes actividades durante las pruebas de rendimiento.
  • Suposiciones y riesgos. Si hay objetivos que pueden ser un riesgo para las pruebas de rendimiento, debemos documentarlo.
  • Estrategia de datos de prueba. Detalles sobre la estrategia de datos de prueba y cómo podemos extraerla.
  • Cronología del plan de pruebas y entregas clave. Cronología de secuencias de comandos, ejecución de pruebas, análisis y entregables para la revisión del cliente.

Las pruebas de rendimiento reales se basan en una combinación de técnicas. Para lograr los objetivos esperados, necesitamos preparar una estrategia diferente para diferentes requisitos de pruebas de rendimiento. Hay diferentes métricas, como la carga del usuario, los usuarios simultáneos, los modelos de carga de trabajo, etc., que deben tenerse en cuenta antes de planificar la carga. Si usted ha trabajado en el modelado de carga de trabajo antes, usted habría oído hablar de la ley de Little. Debe aprenderlo e implementarlo antes de planificar una prueba para obtener los resultados deseados.

Scripts/Escenarios de Rendimiento en Tiempo Real

Una vez que hayamos llegado a un acuerdo con el cliente sobre el plan/estrategia de rendimiento, debemos comenzar la preparación para el scripting utilizando la herramienta de pruebas de rendimiento acordada.

Los siguientes elementos con viñetas son algunos de los puntos que debemos recordar para crear scripts de calidad:

  • Siempre vaya con los pasos documentados del caso de prueba mientras realiza scripts.
  • Reproduzca y corrija los requisitos de correlación para un solo usuario.
  • Reproduzca y corrija los requisitos de parametrización para un solo usuario. La parametrización puede estar en cualquier lugar de los encabezados, cookies y parámetros del cuerpo.
  • Una vez que el script se realiza correctamente con datos de un solo usuario, ejecute varias iteraciones con diferentes usuarios. Es posible que se requiera correlación/parametrización adicional para diferentes datos de usuario.
  • En algunos casos, para lograr ciertos casos de uso, es posible que necesitemos escribir bloques de código. Por ejemplo, seleccionar datos de respuesta concretos para un usuario y manipularlo a otra solicitud.
  • Agregue tiempo de pensar, ritmo, control de errores para el script según el modelo de carga de trabajo.
  • Comprobación de texto/Comprobación de imagen también paso muy importante en el scripting.

Además de los pasos anteriores, habrá requisitos para la simulación de caché/cookies y condiciones de red. Un buen ingeniero de rendimiento debe tener en cuenta todos estos factores antes de iniciar la ejecución. El ingeniero de pruebas de rendimiento también debe desarrollar los patrones más realistas del comportamiento del usuario virtual. Para ello, es crucial obtener la respuesta correcta a través del cuestionario de recopilación de requisitos.

  • ¿Cuál es el número total de usuarios que trabajan con la aplicación, asumiendo un número medio por horario comercial?
  • ¿Qué acciones realizan los usuarios y con qué frecuencia?
  • ¿Cuántos usuarios están trabajando con la aplicación durante las horas de carga máxima?

Las respuestas a las preguntas anteriores se pueden obtener a través de un cuestionario de recopilación de requisitos o de un cuestionario estadístico recopilado con la ayuda de herramientas de análisis web como APM tools/Google Analytics. El análisis de transacciones permite encontrar transacciones empresariales importantes y diseñar escenarios de pruebas de rendimiento que se usarán para la ejecución de pruebas de rendimiento.

Modelado de cargas de trabajo

Podemos planificar nuestro modelo de carga de trabajo de diferentes maneras. Los ingenieros de rendimiento deben aprender y practicar el concepto de “Ley de poca ley” antes de seleccionar un modelo de carga de trabajo. A continuación se muestran algunos de los modelos de carga de trabajo existentes. Una vez más, el ingeniero de rendimiento debe elegir el modelo de carga de trabajo en función de los requisitos en cuestión.

Modelo de carga de trabajo 1. Es sólo un modelo simple, donde el número de usuarios se incrementará continuamente a medida que avance la prueba. Ejemplo: un usuario por segundo hasta que se complete la prueba.

Workload Model 2. En este modelo, el número de usuarios se incrementará como un paso durante toda la prueba. Por ejemplo, los primeros 15 minutos serán 100 usuarios y los próximos 15 minutos serán 200, etc. Podemos planear este tipo de prueba para pruebas de resistencia.

Modelo de carga de trabajo 3. Este es el modelo de prueba de rendimiento más común. El número de usuarios se incrementará continuamente durante cierto tiempo (Llamamos a esto el período de aumento). Después de eso, los usuarios tendrán un estado estable durante cierto tiempo. A continuación, los usuarios comenzarán la rampa hacia abajo y la prueba terminará. Por ejemplo, si estamos planeando 1,5 horas de pruebas, podemos dar 15 minutos para aumentar los usuarios y 15 minutos para la rampa hacia abajo. El estado estable será de una hora. Cuando analicemos los resultados, tomaremos sólo el estado estacionario para su consideración.

Modelo de carga de trabajo 4. En este modelo, el número de usuarios se incrementará y disminuirá repentinamente durante toda la duración. Hay diferentes nombres para este tipo de pruebas, como pruebas de monos, pruebas de picos, etc.

Necesitamos establecer un conjunto completo de objetivos y requisitos para las pruebas de rendimiento. Defina los parámetros de prueba de rendimiento y lo que constituye criterios de aceptación para cada uno. Si no conoce los requisitos de la prueba, ni el resultado deseado, entonces la prueba de rendimiento es una pérdida de tiempo.

Recopilación de datos

A continuación se presentan algunas de las métricas muy importantes a observar durante el modelado de cargas de trabajo de rendimiento.

Tiempo de respuesta: El tiempo de respuesta es el tiempo que el servidor tardó en responder a la solicitud de cliente. Hay muchos factores que afectarán al tiempo de respuesta del servidor. La prueba de carga ayudará a encontrar y eliminar aquellos factores que están degradando el tiempo de respuesta.

Tiempo medio de respuesta: Este será el valor medio del tiempo de respuesta durante toda la duración del estado estable en una prueba de carga.

Tiempo de respuesta del percentil 90: El tiempo de respuesta del percentil 90 significa que el 90 por ciento del tiempo de respuesta cae por debajo de ese valor. Por ejemplo, si tenía 500 solicitudes y cada una tiene un tiempo de respuesta diferente, el percentil 90 es cualquier valor cuyo 90 por ciento de todos los demás valores están por debajo de 90 el percentil. Solo el 10 por ciento del tiempo de respuesta será superior al valor del percentil 90. Esto será útil si parte de su solicitud tiene un tiempo de respuesta enorme y están sesgando el resultado del tiempo de respuesta promedio.

Solicitudes por segundo: Necesitamos encontrar este valor de las herramientas de APM o con la ayuda de registros de producción. En función de los usuarios simultáneos, podemos planificar la solicitud por segundo al servidor.

Utilización de memoria: Estas son métricas del lado de la infraestructura que le ayudan a descubrir cuellos de botella. Además, debe planificar la carga de trabajo en tiempo real lo antes posible. Asegúrese de que no estamos bombardeando el servidor con solicitudes continuas.

Utilización de la CPU: Igual que la memoria y la necesidad de tener en cuenta estas métricas mientras se ejecutan las pruebas de rendimiento.

Tasa de error: Debemos realizar un seguimiento de la relación de transacción pasada/error. La tasa de error no debe ser superior al 2 por ciento de las transacciones pasadas. Si las tasas de error están aumentando a medida que los usuarios simultáneos están aumentando, puede haber un posible cuello de botella.

Usuarios simultáneos: Necesitamos encontrar este valor de las herramientas de APM o con la ayuda de registros de producción. Por lo general, encontramos este valor basado en un día hábil típico.

Rendimiento: El rendimiento mostrará la capacidad del servidor para controlar a los usuarios simultáneos. Hay una conexión directa entre los usuarios simultáneos frente al rendimiento. El rendimiento debe aumentar a medida que aumenta el número de usuarios para acceder a la aplicación. Si el rendimiento está disminuyendo a medida que aumenta el número de usuarios, es una posible indicación de cuellos de botella.

Distribución de carga del usuario: La distribución de la carga del usuario es uno de los factores importantes que deben tenerse en cuenta al diseñar la carga de trabajo. Si tenemos cinco scripts que llevan a cabo cinco funcionalidades diferentes de una aplicación, necesitamos dividir la carga del usuario a real como sea posible en función de nuestra investigación sobre la producción o las herramientas APM.

Estas son métricas muy importantes que debemos tener en cuenta al diseñar el modelo de carga de trabajo. Habrá otras métricas, así como depende de la arquitectura y los requisitos de la aplicación cliente.

Lista de comprobación para el entorno de pruebas de rendimiento (antes de la ejecución)

El ejemplo de lista de comprobación siguiente suele ir seguido de pruebas de rendimiento de extremo a extremo de nivel empresarial, donde hay un gran número de sistemas implicados. Siempre se recomienda seguir una lista de verificación del entorno para pruebas de rendimiento a pequeña escala también. Las actividades cambiarán en función de los entornos de aplicación, ya que hay una gran diferencia cuando la comparamos con la aplicación en la nube frente a la aplicación local.

Lista de verificación de pruebas de rendimiento

Conclusión: Lista de verificación de preparación de pruebas de carga

Las pruebas de rendimiento de software exitosas no se producen por accidente. Los arquitectos, propietarios de productos, desarrolladores y el equipo de pruebas de rendimiento deben trabajar juntos y abordar los requisitos de pruebas de rendimiento antes de evaluar el software. Para obtener un fondo más detallado en la plataforma LoadView, lea nuestro artículo Información general técnica para ver cómo puede aprovechar al máximo las pruebas de rendimiento. Las pruebas de rendimiento deben ser un proceso continuo. Cuando su sitio web o aplicación web comience a crecer, deberá realizar cambios para dar cabida a una base de usuarios más amplia. Siempre hay una posibilidad de mejora en cualquier aplicación y pruebas.

Esperamos que esto le haya dado una buena visión sobre las mejores prácticas en las pruebas de rendimiento. Si desea una demostración completa de la solución LoadView, regístrese para obtener una demostración con un ingeniero de rendimiento. Le llevarán paso a paso a través de cada parte del proceso, desde la creación de scripts de pruebas de carga y la configuración de pruebas, hasta la ejecución de pruebas y el análisis de resultados.

O regístrese en la prueba gratuita de LoadView para empezar a ejecutar pruebas de carga ahora. ¡Le daremos pruebas de carga gratuitas para comenzar! ¡Feliz prueba de carga!