Cuando se trata de pruebas de carga, siempre está la pregunta de un millón de dólares: “En términos de rendimiento, ¿qué quiere hacer el cliente con su aplicación y sistema?” Estoy bastante seguro de que nunca obtendrás una respuesta fácil a esa pregunta, y la mayoría de nosotros siempre asumimos algunas cosas y llevamos a cabo las pruebas de rendimiento, lo que puede terminar omitiendo pruebas de piezas críticas y terminar con un cliente insatisfecho. Un cliente insatisfecho significa la pérdida de negocio para tu organización y una carrera en declive como ingeniero de rendimiento. Pero no te preocupes, en este artículo vamos a hablar sobre cómo crear una lista de verificación que te ayudará con esas preguntas.
Esta lista de verificación es más bien un proceso paso a paso que puedes seguir y adaptar a tu ciclo de vida de pruebas de rendimiento. En el escenario discutido, no siempre podemos culpar a nuestros clientes, porque inicialmente puede que no sepan cuáles son los resultados exactos de rendimiento que desean, pero tienen un conocimiento claro de cómo funciona la aplicación bajo diferentes condiciones. Un buen tester de rendimiento puede manejar esta ambigüedad con un cuestionario bien definido. Y ese es el primer ítem en la lista de verificación, el cuestionario de recolección de requisitos.
Cuestionario de Recolección de Requisitos
A continuación hay un formato de cuestionario que puedes seguir en tu proyecto. Necesitamos obtener tantas respuestas como sea posible para estas preguntas. Será mejor si puedes tener una llamada para discutir estas preguntas. Asegúrate de que el arquitecto o desarrollador de la aplicación participe en la llamada contigo y con el cliente. Contar con personal adicional puede ayudar a proporcionar perspectiva y descubrir preguntas que quizás no habías considerado antes. Las preguntas a continuación te brindan una hoja de ruta para crear una prueba de carga más eficiente y efectiva.
| No | Tema | Preguntas |
| 1 | Aplicación | Tipo de aplicación a considerar para la prueba (por ejemplo, aplicación web/ aplicación móvil, etc.). |
| 2 | Arquitectura y tecnología/plataforma de la aplicación. | |
| 3 | Técnica de balanceo de carga utilizada. | |
| 4 | Protocolo de comunicación entre cliente y servidor (por ejemplo: HTTP/S, FTP). | |
| 5 | Objetivo de la prueba de rendimiento. Métricas de rendimiento a monitorear (por ejemplo, tiempo de respuesta para cada una de las acciones, usuarios concurrentes, etc.). | |
| 6 | Escenarios críticos a considerar para la prueba de rendimiento. | |
| 7 | Detalles de trabajos/procesos programados en segundo plano, si los hay. | |
| 8 | Técnica utilizada para la gestión de sesiones y número de sesiones paralelas soportadas. | |
| 9 | SLA/Requisitos del Cliente | Número esperado de usuarios concurrentes y base total de usuarios. Distribución de usuarios para escenarios en alcance. |
| 10 | SLA para todas las transacciones en alcance para PT (rendimiento esperado, tiempo de respuesta, etc.). | |
| 11 | Tipos de pruebas de rendimiento a realizar (pruebas de carga, pruebas de resistencia, etc.). | |
| 12 | Sistema/Ambiente | Detalles del entorno de prueba (web/app/BD, etc., junto con número de nodos). Se recomienda un entorno similar a producción para la ejecución de la prueba de rendimiento. |
| 13 | Comparación entre el entorno de producción y el entorno de prueba de rendimiento. | |
| 14 | Si la aplicación debe estar aislada durante la ejecución de la prueba de rendimiento para evitar interacción con otras aplicaciones. | |
| 15 | Detalles del mecanismo incorporado de registro o del mecanismo de monitoreo. | |
| 16 | Otros | Resultados de línea base del rendimiento de la aplicación. |
| 17 | Problemas actuales de rendimiento, si los hay. | |
Las respuestas a estas preguntas te ayudarán a crear una estrategia de prueba/plan de prueba de calidad. Si el cliente no puede 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 hay una herramienta APM/log en su lugar, podemos derivar los usuarios concurrentes, rendimiento y tiempo de respuesta desde el sistema de producción. Nunca asumas que obtendrás lo que necesitas sin preguntar.
Encuentra una Herramienta de Pruebas de Rendimiento Adecuada
Un tester de rendimiento debe elegir cuidadosamente la mejor herramienta de pruebas de rendimiento. Hay muchos factores que deben considerarse antes de que finalices y propongas la herramienta. Recuerda, el presupuesto del cliente siempre es un factor importante al elegir la herramienta de pruebas de rendimiento.
Si buscas una herramienta de pruebas de rendimiento que sea rentable, fácil de usar y que pueda proporcionar una solución completa de rendimiento, definitivamente deberías probar LoadView. En comparación con las herramientas tradicionales de pruebas de carga, LoadView no requiere ninguna inversión costosa, configuración que consume tiempo, ni conocimiento previo de marcos de scripting. Además, la plataforma ofrece más de 20 ubicaciones globales para desplegar inyectores de carga, por lo que puedes probar y medir el rendimiento desde múltiples 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 con herramientas gratuitas y de código abierto como JMeter no justifican la inversión. Cuando se trata de entender verdaderamente el rendimiento de un sitio web o aplicación desde la perspectiva del usuario final, las pruebas basadas en protocolo no son suficientes. También debes medir el rendimiento de las interacciones y pasos del lado cliente. Aquí tienes una comparación de LoadView con otras soluciones de pruebas de rendimiento/carga y por qué deberías elegir LoadView para tus requisitos de pruebas de rendimiento.
Cuando se trata de sitios y aplicaciones que cargan lentamente, los clientes pueden volverse rápidamente impacientes y se irán a buscar un reemplazo si tu sitio/aplicación no cumple con sus expectativas. Saber cuántos usuarios puede manejar tu sitio/aplicación es muy importante por varias razones, pero hay varios escenarios significativos en los que la plataforma LoadView puede ayudar:
- Adaptabilidad y escalabilidad. Determinar por qué tu sitio o aplicación se ralentiza cuando múltiples usuarios acceden a él.
- Infraestructura. Entender qué actualizaciones de hardware son necesarias, si las hay. El costo de implementar hardware adicional y mantenerlo podría ser un gasto de recursos innecesario.
- Requisitos de rendimiento. Tu sitio o aplicación puede manejar adecuadamente a pocos usuarios, pero ¿qué sucede en situaciones del mundo real?
- Servicios de terceros. Ver cómo se comportan los servicios externos cuando se presentan condiciones de carga normales o hasta de pico.
Plan/Estrategia de Pruebas de Rendimiento
Una vez que hayas recopilado los requisitos del cliente y seleccionado una herramienta de pruebas de rendimiento adecuada, necesitamos documentar nuestro plan de prueba/estrategia de prueba. Asegúrate de obtener la aprobación del plan de prueba por parte del cliente antes de comenzar cualquier actividad de rendimiento. Esto es muy importante y te ayudará a evitar problemas innecesarios más adelante. Estos son algunos puntos que debe incluir el plan de prueba.
- Objetivos de la prueba de rendimiento. Lo que vamos a lograr.
- Alcance del proyecto. Cuál es el alcance del proyecto, por ejemplo: número de scripts, cuánto tiempo necesitamos probar, etc.
- Arquitectura de la aplicación. Detalles de la aplicación como servidor de aplicaciones, servidor de BD, puedes incluir un diagrama arquitectónico si lo tienes.
- Detalles del ambiente. 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 la prueba de rendimiento (por ejemplo, entorno en la nube, instalación de herramientas, etc.).
- Enfoque de la prueba de rendimiento. Cómo vamos a llevar a cabo la prueba. Deberíamos comenzar con una prueba base con un número pequeño de usuarios, y luego gradualmente aumentar los usuarios y realizar diferentes tipos de pruebas como estrés, resistencia, etc.
- Criterios de entrada y salida. Esto es muy importante. Siempre deberíamos comenzar las pruebas de rendimiento cuando no haya defectos funcionales. De igual forma debemos documentar cuándo podemos detener las pruebas de rendimiento.
- Gestión de defectos. Deberíamos seguir la misma herramienta y prácticas que el cliente utiliza para registrar defectos relacionados con pruebas de rendimiento.
- Roles y responsabilidades. Detalles sobre los interesados involucrados en las diferentes actividades durante las pruebas de rendimiento.
- Suposiciones y riesgos. Si hay objetivos que pueden representar un riesgo para las pruebas de rendimiento, deberíamos documentarlo.
- Estrategia de datos de prueba. Detalles sobre la estrategia de datos de prueba y cómo podemos extraerlos.
- Línea de tiempo del plan de prueba y entregables. Cronograma de scripting, ejecución de prueba, análisis y entregables para 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 carga de usuario, usuarios concurrentes, modelos de carga de trabajo, etc., que deben considerarse antes de planificar la carga. Si has trabajado en modelado de carga de trabajo antes, habrás oído hablar de la ley de Little. Deberías aprenderla e implementarla antes de planificar una prueba para obtener los resultados deseados.
Scripts/Escenarios de Rendimiento en Tiempo Real
Una vez que hemos acordado un plan o estrategia de rendimiento con el cliente, es hora de prepararnos para el scripting utilizando la herramienta de pruebas de rendimiento elegida. Construir scripts de calidad es clave para el éxito de las pruebas de rendimiento, y hay varias consideraciones importantes a tener en cuenta a lo largo del proceso.
Primero, sigue siempre los pasos documentados en los casos de prueba al crear scripts para asegurar la precisión. Comienza reproduciendo el script para un solo usuario y aborda cualquier necesidad de correlación o parametrización. La parametrización puede incluir encabezados, cookies o parámetros en el cuerpo. Una vez que el script funcione perfectamente para un solo usuario, pruébalo con múltiples iteraciones y diferentes datos de usuario. Prepárate para ajustar la correlación o parametrización, ya que nuevos datos pueden revelar requisitos adicionales.
En algunos casos, alcanzar ciertos casos de uso puede requerir escribir bloques personalizados de código. Por ejemplo, podrías necesitar extraer datos específicos de respuesta para un usuario y manipularlos para otra solicitud. Además, no olvides incluir tiempo de pensamiento, ritmo y mecanismos de manejo de errores basados en el modelo de carga de trabajo. Verificar la funcionalidad del script con comprobaciones de texto o imagen también es importante para asegurar los resultados deseados.
Más allá del scripting, considera factores como simular cache, cookies y condiciones de red variables para reflejar escenarios realistas. Como ingeniero de rendimiento, crear un comportamiento realista de usuario virtual es fundamental. Este proceso comienza recopilando detalles precisos durante la fase de requisitos.
Preguntas clave a responder incluyen:
- ¿Cuál es el número total de usuarios que interactúan con la aplicación durante el horario laboral?
- ¿Qué acciones suelen realizar los usuarios, y con qué frecuencia?
- ¿Cuántos usuarios acceden a la aplicación durante los momentos de carga máxima?
Estas respuestas se pueden obtener mediante un cuestionario de recolección de requisitos o analizando datos estadísticos recopilados de herramientas como soluciones APM o Google Analytics. El análisis de transacciones es especialmente útil para identificar transacciones comerciales críticas y diseñar escenarios de prueba de rendimiento que reflejen con precisión el uso del mundo real. Al abordar estos pasos, estarás bien preparado para ejecutar pruebas de rendimiento efectivas y entregar resultados confiables.
Modelado de Carga de Trabajo
Podemos planificar nuestro modelo de carga de trabajo de diferentes maneras. Los ingenieros de rendimiento deberían aprender y practicar el concepto de “ley de Little” antes de seleccionar un modelo de carga de trabajo. A continuación se presentan algunos de los modelos de carga de trabajo existentes. Nuevamente, el ingeniero de rendimiento debe elegir el modelo de carga de trabajo basado en los requerimientos en mano.
Modelo de Carga 1. Es un modelo simple, donde el número de usuarios se aumentará continuamente a medida que avance la prueba. Ejemplo: un usuario por segundo hasta que la prueba se complete.
Modelo de Carga 2. En este modelo, el número de usuarios aumentará en pasos durante toda la duración de la prueba. Por ejemplo, los primeros 15 minutos serán 100 usuarios y los siguientes 15 minutos 200, etc. Podemos planear este tipo de prueba para pruebas de resistencia.
Modelo de Carga 3. Este es el modelo de prueba de rendimiento más común. El número de usuarios aumentará continuamente durante cierto tiempo (llamamos a esto el período de subida). Después de eso, los usuarios tendrán un estado estable durante cierta duración. Luego los usuarios comenzarán a disminuir y la prueba finalizará. Por ejemplo, si planeamos 1.5 horas de prueba, podemos dar 15 minutos para aumentar usuarios y 15 minutos para disminuir. El estado estable será una hora. Cuando analicemos los resultados, tomaremos solo el estado estable en consideración.
Modelo de Carga 4. En este modelo, el número de usuarios aumentará y disminuirá repentinamente durante toda la duración. Hay diferentes nombres para este tipo de pruebas, como pruebas mono, pruebas de pico, etc.
Necesitamos establecer un conjunto completo de metas y requisitos para las pruebas de rendimiento. Definir los parámetros de las pruebas de rendimiento y qué constituye los criterios de aceptación para cada uno. Si no conoces los requisitos de prueba ni el resultado deseado, entonces la prueba de rendimiento es una pérdida de tiempo.
Recolección de Datos
A continuación solo algunos de los métricas muy importantes a observar durante el modelado de carga de trabajo de rendimiento.
Tiempo de respuesta: El tiempo de respuesta es el tiempo que el servidor tardó en responder a la solicitud del cliente. Hay muchos factores que afectarán el tiempo de respuesta del servidor. La prueba de carga ayudará a encontrar y eliminar esos factores que están degradando el tiempo de respuesta.
Tiempo promedio de respuesta: Será el valor promedio del tiempo de respuesta para toda la duración del estado estable en una prueba de carga.
Tiempo de respuesta percentil 90: El tiempo de respuesta del percentil 90 significa que el 90 por ciento del tiempo de respuesta está por debajo de ese valor. Por ejemplo, si tuviste 500 solicitudes y cada una tiene un tiempo de respuesta diferente, entonces el percentil 90 es cualquier valor por debajo del cual el 90 por ciento de todos los demás valores están. Solo el 10 por ciento del tiempo de respuesta será mayor que el valor del percentil 90. Esto será útil si algunas de tus solicitudes tienen un gran tiempo de respuesta y están sesgando el resultado del tiempo promedio de respuesta.
Solicitudes por segundo: Necesitamos encontrar este valor de las herramientas APM o con la ayuda de los registros de producción. Basado en los usuarios concurrentes podemos planear las solicitudes por segundo al servidor.
Utilización de memoria: Estas son métricas del lado de infraestructura que te ayudan a descubrir cuellos de botella. También, debes planear tu carga de trabajo tan en tiempo real como sea posible. Asegúrate de no bombardear el servidor con solicitudes continuas.
Utilización de CPU: Igual que la memoria y se debe observar esta métrica mientras se ejecutan las pruebas de rendimiento.
Tasa de error: Debemos seguir la proporción de transacciones aprobadas/errores. La tasa de error no debe ser mayor al 2 por ciento de las transacciones aprobadas. Si la tasa de errores aumenta conforme aumentan los usuarios concurrentes, puede haber un posible cuello de botella.
Usuarios concurrentes: Necesitamos encontrar este valor de las herramientas APM o con ayuda de logs de producción. Usualmente, obtenemos este valor basándonos en un día típico de negocio.
Rendimiento: El rendimiento mostrará la capacidad del servidor para manejar los usuarios concurrentes. Hay una conexión directa entre usuarios concurrentes versus rendimiento. El rendimiento debería aumentar a medida que el número de usuarios accede a la aplicación. Si el rendimiento disminuye conforme el número de usuarios aumenta, es una posible indicación de cuellos de botella.
Distribución de la carga de usuario: La distribución de la carga de usuario es uno de los factores importantes que deben considerarse 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 de usuario para que sea lo más real posible basado en nuestra investigación en producción o herramientas APM.
Estas son métricas muy importantes que debemos tener en cuenta al diseñar el modelo de carga de trabajo. También habrá otras métricas que dependerán de la arquitectura y requerimientos de la aplicación del cliente.
Lista de Verificación para el Entorno de Pruebas de Rendimiento (Antes de la Ejecución)
El ejemplo de lista de verificación a continuación generalmente se sigue en pruebas de rendimiento a nivel empresarial de extremo a extremo, donde hay un gran número de sistemas involucrados. Siempre se recomienda seguir una lista de verificación de entorno para pruebas de rendimiento a escala pequeña también. Las actividades cambiarán según los entornos de aplicación, ya que hay una gran diferencia al compararlo con la aplicación en la nube versus la aplicación local.
Conclusión: Lista de Verificación para la Preparación de Pruebas de Carga
Las pruebas de rendimiento de software exitosas no ocurren por accidente. Arquitectos, propietarios de producto, 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 un trasfondo más detallado sobre la plataforma LoadView, lee nuestro artículo Technical Overview para ver cómo puedes aprovechar al máximo tus pruebas de rendimiento. Las pruebas de rendimiento deberían ser un proceso continuo. Cuando tu sitio web o aplicación web comience a crecer, necesitarás hacer cambios para acomodar una base de usuarios más grande. Siempre hay oportunidad de mejora en cualquier aplicación y pruebas.
Esperamos que esto te haya dado una buena perspectiva sobre las mejores prácticas en pruebas de rendimiento. Si deseas una demostración completa de la solución LoadView, regístrate para un demo con un ingeniero de rendimiento. Ellos te llevarán paso a paso por cada parte del proceso, desde crear scripts de prueba de carga y configuración de prueba, hasta la ejecución de la prueba y análisis de resultados.
O regístrate para la prueba gratuita de LoadView para comenzar a ejecutar pruebas de carga ahora. ¡Te daremos pruebas de carga gratuitas para empezar! ¡Feliz prueba de carga!