Pruebas de rendimiento del software

En el aseguramiento de la calidad del software, las pruebas de rendimiento son, en general, una práctica de prueba realizada para determinar cómo se desempeña un sistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como escalabilidad, confiabilidad y uso de recursos.

La prueba de rendimiento, un subconjunto de la ingeniería de rendimiento, es una práctica informática que se esfuerza por incorporar estándares de rendimiento en la implementación, el diseño y la arquitectura de un sistema.

Tipos de prueba

Pruebas de carga

La prueba de carga es la forma más simple de prueba de rendimiento. Por lo general, se realiza una prueba de carga para comprender el comportamiento del sistema bajo una carga esperada específica. Esta carga puede ser el número simultáneo esperado de usuarios en la aplicación que realizan un número específico de transacciones dentro de la duración establecida. Esta prueba dará a conocer los tiempos de respuesta de todas las transacciones comerciales críticas importantes. La base de datos, el servidor de aplicaciones, etc. también se monitorean durante la prueba, esto ayudará a identificar cuellos de botella en el software de la aplicación y el hardware en el que está instalado el software.

Pruebas de estrés

Las pruebas de estrés normalmente se usan para comprender los límites superiores de capacidad dentro del sistema. Este tipo de prueba se realiza para determinar la solidez del sistema en términos de carga extrema y ayuda a los administradores de aplicaciones a determinar si el sistema funcionará lo suficiente si la carga actual supera con creces el máximo esperado.

Prueba de remojo

La prueba de inmersión, también conocida como prueba de resistencia, generalmente se realiza para determinar si el sistema puede soportar la carga esperada continua. Durante las pruebas de remojo, se supervisa la utilización de la memoria para detectar posibles fugas. También es importante, pero a menudo se pasa por alto, la degradación del rendimiento, es decir, garantizar que el rendimiento y/o los tiempos de respuesta después de un largo período de actividad sostenida sean tan buenos o mejores que al comienzo de la prueba. Esencialmente implica aplicar una carga significativa a un sistema durante un período de tiempo prolongado y significativo. El objetivo es descubrir cómo se comporta el sistema bajo un uso sostenido.

Prueba de picos

La prueba de picos se realiza aumentando o disminuyendo repentinamente la carga generada por una gran cantidad de usuarios y observando el comportamiento del sistema. El objetivo es determinar si el rendimiento se verá afectado, el sistema fallará o podrá manejar cambios drásticos en la carga.

Pruebas de puntos de ruptura

Las pruebas de punto de interrupción son similares a las pruebas de estrés. Se aplica una carga incremental a lo largo del tiempo mientras se supervisa el sistema en busca de condiciones de falla predeterminadas. La prueba de punto de interrupción a veces se denomina prueba de capacidad porque se puede decir que determina la capacidad máxima por debajo de la cual el sistema funcionará según las especificaciones requeridas o los acuerdos de nivel de servicio. Los resultados del análisis de puntos de interrupción aplicados a un entorno fijo se pueden utilizar para determinar la estrategia de escalado óptima en términos de hardware requerido o condiciones que deberían desencadenar eventos de escalamiento horizontal en un entorno de nube.

Pruebas de configuración

En lugar de probar el rendimiento desde una perspectiva de carga, las pruebas se crean para determinar los efectos de los cambios de configuración en los componentes del sistema en el rendimiento y el comportamiento del sistema. Un ejemplo común sería experimentar con diferentes métodos de equilibrio de carga.

Pruebas de aislamiento

Las pruebas de aislamiento no son exclusivas de las pruebas de rendimiento, sino que implican repetir una ejecución de prueba que resultó en un problema del sistema. Tales pruebas a menudo pueden aislar y confirmar el dominio de falla.

Pruebas de Internet

Esta es una forma relativamente nueva de prueba de rendimiento cuando se prueba el rendimiento de aplicaciones globales como Facebook, Google y Wikipedia desde generadores de carga que se colocan en el continente de destino real, ya sean máquinas físicas o máquinas virtuales en la nube. Estas pruebas generalmente requieren una inmensa cantidad de preparación y monitoreo para ejecutarse con éxito.

Establecer objetivos de rendimiento

Las pruebas de rendimiento pueden servir para diferentes propósitos:

• Puede demostrar que el sistema cumple los criterios de rendimiento.
• Puede comparar dos sistemas para encontrar qué funciona mejor.
• Puede medir qué partes del sistema o la carga de trabajo hacen que el sistema funcione mal.

Muchas pruebas de rendimiento se llevan a cabo sin establecer objetivos de rendimiento lo suficientemente realistas y orientados a objetivos. La primera pregunta desde una perspectiva empresarial siempre debe ser, "¿por qué estamos realizando pruebas de rendimiento?". Estas consideraciones son parte del caso comercial de las pruebas. Los objetivos de rendimiento diferirán según la tecnología y el propósito del sistema, pero siempre deben incluir algunos de los siguientes:

Simultaneidad y rendimiento

Si un sistema identifica a los usuarios finales mediante algún tipo de procedimiento de inicio de sesión, es muy deseable un objetivo de simultaneidad. Por definición, este es el mayor número de usuarios simultáneos del sistema que se espera que admita el sistema en un momento dado. El flujo de trabajo de una transacción con script puede afectar la verdadera concurrencia, especialmente si la parte iterativa contiene la actividad de inicio y cierre de sesión.

Si el sistema no tiene un concepto de usuarios finales, es probable que el objetivo de rendimiento se base en un rendimiento máximo o tasa de transacciones.

Tiempo de respuesta del servidor

Esto se refiere al tiempo que tarda un nodo del sistema en responder a la solicitud de otro. Un ejemplo simple sería un HTTP 'GET' solicitud del cliente del navegador al servidor web. En términos de tiempo de respuesta, esto es lo que realmente miden todas las herramientas de prueba de carga. Puede ser relevante establecer objetivos de tiempo de respuesta del servidor entre todos los nodos del sistema.

Tiempo de respuesta de procesamiento

Las herramientas de prueba de carga tienen dificultades para medir el tiempo de respuesta de procesamiento, ya que generalmente no tienen idea de lo que sucede dentro de un nodo, aparte de reconocer un período de tiempo en el que no hay actividad 'en el cable'. Para medir el tiempo de respuesta de renderización, generalmente es necesario incluir scripts de prueba funcionales como parte del escenario de prueba de rendimiento. Muchas herramientas de prueba de carga no ofrecen esta función.

Especificaciones de rendimiento

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlos en cualquier plan de prueba de rendimiento. Idealmente, esto se hace durante la fase de desarrollo de requisitos de cualquier proyecto de desarrollo de sistemas, antes de cualquier esfuerzo de diseño. Consulte Ingeniería de rendimiento para obtener más detalles.

Sin embargo, las pruebas de rendimiento con frecuencia no se realizan según una especificación; por ejemplo, nadie habrá expresado cuál debería ser el tiempo de respuesta máximo aceptable para una determinada población de usuarios. Las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de ajuste del perfil de rendimiento. La idea es identificar el "eslabón más débil" – inevitablemente hay una parte del sistema que, si se hace que responda más rápido, hará que el sistema en general funcione más rápido. A veces es una tarea difícil identificar qué parte del sistema representa esta ruta crítica, y algunas herramientas de prueba incluyen (o pueden tener complementos que proporcionan) instrumentación que se ejecuta en el servidor (agentes) e informa los tiempos de transacción, los tiempos de acceso a la base de datos, sobrecarga de red y otros monitores de servidor, que se pueden analizar junto con las estadísticas de rendimiento sin procesar. Sin tal instrumentación, es posible que tenga que tener a alguien agachado sobre el Administrador de tareas de Windows en el servidor para ver cuánta carga de CPU están generando las pruebas de rendimiento (suponiendo que se esté probando un sistema Windows).

Las pruebas de rendimiento se pueden realizar en toda la web, e incluso en diferentes partes del país, ya que se sabe que los tiempos de respuesta de Internet en sí varían regionalmente. También se puede hacer internamente, aunque los enrutadores luego deberían configurarse para introducir el retraso que normalmente ocurriría en las redes públicas. Las cargas deben introducirse en el sistema desde puntos realistas. Por ejemplo, si el 50 % de la base de usuarios de un sistema accederá al sistema a través de una conexión de módem de 56 K y la otra mitad a través de un T1, entonces los inyectores de carga (computadoras que simulan usuarios reales) deben inyectar carga a través de la mismo mix de conexiones (ideal) o simular la latencia de red de dichas conexiones, siguiendo el mismo perfil de usuario.

Siempre es útil tener una declaración del número máximo probable de usuarios que se espera que usen el sistema en las horas pico. Si también puede haber una declaración de lo que constituye el tiempo de respuesta del percentil 95 máximo permitido, entonces se podría usar una configuración de inyector para probar si el sistema propuesto cumple con esa especificación.

Preguntas para hacer

Las especificaciones de rendimiento deben hacer las siguientes preguntas, como mínimo:

• En detalle, ¿cuál es el alcance de la prueba de rendimiento? ¿Qué subsistemas, interfaces, componentes, etc. están dentro y fuera de alcance para esta prueba?
• Para las interfaces de usuario (UIs) implicadas, ¿cuántos usuarios concurrentes se esperan para cada (especifique pico vs nominal)?
• ¿Cómo se ve el sistema de destino (hardware) (especifique todas las configuraciones de aplicaciones de servidor y red)?
• ¿Cuál es la mezcla de trabajo de aplicaciones de cada componente del sistema? (por ejemplo: 20% de registro, 40% de búsqueda, 30% de selección, 10% de pago).
• ¿Cuál es la mezcla de volumen de trabajo del sistema? [Las cargas de trabajo mínimas pueden simularse en una sola prueba de rendimiento] (por ejemplo: 30% Workload A, 20% Workload B, 50% Workload C).
• ¿Cuáles son los requisitos de tiempo para cualquier / todos los procesos de lote de back-end (especifique pico vs nominal)?

Requisitos

Una compilación estable del sistema que debe parecerse lo más posible al entorno de producción.

Para garantizar resultados coherentes, el entorno de pruebas de rendimiento debe estar aislado de otros entornos, como las pruebas de aceptación del usuario (UAT) o el desarrollo. Como práctica recomendada, siempre es recomendable tener un entorno de prueba de rendimiento independiente que se asemeje lo más posible al entorno de producción.

Condiciones de prueba

En las pruebas de rendimiento, a menudo es crucial que las condiciones de prueba sean similares al uso real esperado. Sin embargo, en la práctica esto es difícil de organizar y no del todo posible, ya que los sistemas de producción están sujetos a cargas de trabajo impredecibles. Las cargas de trabajo de prueba pueden imitar las ocurrencias en el entorno de producción en la medida de lo posible, pero solo en los sistemas más simples se puede replicar exactamente esta variabilidad de la carga de trabajo.

Las implementaciones arquitectónicas poco acopladas (por ejemplo, SOA) han creado complejidades adicionales con las pruebas de rendimiento. Para replicar verdaderamente estados similares a los de producción, los servicios o activos empresariales que comparten una infraestructura o plataforma común requieren pruebas de rendimiento coordinadas, con todos los consumidores creando volúmenes de transacciones y cargas similares a las de producción en infraestructuras o plataformas compartidas. Debido a que esta actividad es tan compleja y costosa en dinero y tiempo, algunas organizaciones ahora usan herramientas para monitorear y simular condiciones similares a las de producción (también conocidas como "ruido") en sus entornos de prueba de rendimiento (PTE) para comprender la capacidad. y requisitos de recursos y verificar/validar los atributos de calidad.

Tiempo

Es fundamental para el rendimiento de costos de un nuevo sistema que los esfuerzos de prueba de rendimiento comiencen al inicio del proyecto de desarrollo y se extiendan hasta la implementación. Cuanto más tarde se detecte un defecto de rendimiento, mayor será el costo de la reparación. Esto es cierto en el caso de las pruebas funcionales, pero más aún en las pruebas de rendimiento, debido a la naturaleza de extremo a extremo de su alcance. Es fundamental que un equipo de pruebas de rendimiento se involucre lo antes posible, ya que requiere mucho tiempo adquirir y preparar el entorno de prueba y otros requisitos clave de rendimiento.

Herramientas

Las pruebas de rendimiento se dividen principalmente en dos categorías principales:

Secuencias de comandos de rendimiento

Esta parte de las pruebas de rendimiento se ocupa principalmente de la creación/programación de los flujos de trabajo de los procesos comerciales clave identificados. Esto se puede hacer usando una amplia variedad de herramientas.

Cada una de las herramientas mencionadas en la lista anterior (que no es exhaustiva ni completa) emplea un lenguaje de secuencias de comandos (C, Java, JS) o alguna forma de representación visual (arrastrar y soltar) para crear y simular el trabajo del usuario final. fluye La mayoría de las herramientas permiten algo llamado "Record & Replay", donde el probador de rendimiento lanzará la herramienta de prueba, la conectará a un navegador o cliente pesado y capturará todas las transacciones de red que ocurren entre el cliente y el servidor. Al hacerlo, se desarrolla un script que se puede mejorar/modificar para emular varios escenarios comerciales.

Supervisión del rendimiento

Esto constituye la otra cara de las pruebas de rendimiento. Con el monitoreo del rendimiento, se observan las características de comportamiento y respuesta de la aplicación bajo prueba. Los siguientes parámetros generalmente se monitorean durante la ejecución de una prueba de rendimiento

Parámetros de hardware del servidor

• CPU Utilización
• Utilización de la memoria
• Utilización de los discos
• Utilización de redes

Como primer paso, los patrones generados por estos 4 parámetros brindan una buena indicación de dónde se encuentra el cuello de botella. Para determinar la causa raíz exacta del problema, los ingenieros de software usan herramientas como generadores de perfiles para medir qué partes de un dispositivo o software contribuyen más al bajo rendimiento, o para establecer niveles de rendimiento (y umbrales) para mantener un tiempo de respuesta aceptable.

Tecnología

La tecnología de prueba de rendimiento emplea una o más PC o servidores Unix para actuar como inyectores, cada uno de los cuales emula la presencia de un número de usuarios y cada uno ejecuta una secuencia automatizada de interacciones (grabadas como un script o como una serie de scripts para emular diferentes tipos de interacción del usuario) con el host cuyo rendimiento se está probando. Por lo general, una PC separada actúa como conductor de prueba, coordinando y recopilando métricas de cada uno de los inyectores y recopilando datos de rendimiento para fines de informes. La secuencia habitual es aumentar la carga: comenzar con unos pocos usuarios virtuales y aumentar el número con el tiempo hasta un máximo predeterminado. El resultado de la prueba muestra cómo varía el rendimiento con la carga, expresado como número de usuarios frente al tiempo de respuesta. Hay varias herramientas disponibles para realizar dichas pruebas. Las herramientas de esta categoría suelen ejecutar un conjunto de pruebas que emulan a usuarios reales contra el sistema. A veces, los resultados pueden revelar rarezas, por ejemplo, que si bien el tiempo de respuesta promedio puede ser aceptable, hay valores atípicos de algunas transacciones clave que tardan mucho más en completarse, algo que podría deberse a consultas de base de datos ineficientes, imágenes, etc.

Las pruebas de rendimiento se pueden combinar con pruebas de estrés para ver qué sucede cuando se excede una carga aceptable. ¿Se bloquea el sistema? ¿Cuánto tiempo se tarda en recuperarse si se reduce una carga grande? ¿Causa su falla daños colaterales?

El modelado de rendimiento analítico es un método para modelar el comportamiento de un sistema en una hoja de cálculo. El modelo se alimenta con mediciones de demandas de recursos de transacciones (CPU, E/S de disco, LAN, WAN), ponderadas por la combinación de transacciones (transacciones comerciales por hora). Las demandas de recursos de transacciones ponderadas se suman para obtener las demandas de recursos por hora y se dividen por la capacidad de recursos por hora para obtener las cargas de recursos. Con la fórmula del tiempo de respuesta (R=S/(1-U), R=tiempo de respuesta, S=tiempo de servicio, U=carga), los tiempos de respuesta se pueden calcular y calibrar con los resultados de las pruebas de rendimiento. El modelado de rendimiento analítico permite la evaluación de las opciones de diseño y el dimensionamiento del sistema en función del uso comercial real o previsto. Por lo tanto, es mucho más rápido y económico que las pruebas de rendimiento, aunque requiere un conocimiento profundo de las plataformas de hardware.

Tareas a realizar

Las tareas para realizar dicha prueba incluirían:

• Decidir si utilizar recursos internos o externos para realizar las pruebas, dependiendo de la experiencia interna (o la falta de ella).
• Reunir o obtener requisitos de rendimiento (especciones) de usuarios y/o analistas de negocios.
• Elaborar un plan de alto nivel (o una carta de proyectos), que incluya necesidades, recursos, plazos y hitos.
• Desarrollar un plan detallado de pruebas de rendimiento (incluyendo escenarios detallados y casos de prueba, cargas de trabajo, información ambiental, etc.).
• Elija la herramienta de prueba.
• Especifique los datos de prueba necesarios y el esfuerzo de alquiler (a menudo pasado por alto, pero vital para realizar una prueba de rendimiento válida).
• Desarrollar scripts de prueba de conceptos para cada aplicación/componente bajo prueba, utilizando herramientas y estrategias de prueba seleccionadas.
• Elaborar un plan detallado de proyectos de prueba de ejecución, incluidas todas las dependencias y plazos conexos.
• Instalar y configurar inyectores/controlador.
• Configurar el entorno de prueba (herramienta idealmente idéntica a la plataforma de producción), configuración del router, red silenciosa (no queremos que los resultados sean alterados por otros usuarios), implementación de instrumentación del servidor, conjuntos de pruebas de bases de datos desarrollados, etc.
• Seca ejecutar las pruebas - antes de ejecutar la prueba de carga con los usuarios predefinidos, se realiza una ejecución seca para comprobar la corrección del script.
• Ejecutar pruebas – probablemente repetidamente (es decir,) para ver si algún factor no contabilizado podría afectar los resultados.
• Analizar los resultados - ya sea el paso/fail, o la investigación de la trayectoria crítica y recomendación de la acción correctiva.

Metodología

Pruebas de rendimiento de aplicaciones web

Según Microsoft Developer Network, la Metodología de prueba de rendimiento consta de las siguientes actividades:

1. Identificar el ambiente de prueba. Identificar el entorno de pruebas físicas y el entorno de producción, así como las herramientas y recursos disponibles para el equipo de pruebas. El entorno físico incluye configuraciones de hardware, software y red. Tener una comprensión completa de todo el entorno de prueba al principio permite un diseño y planificación de pruebas más eficientes y le ayuda a identificar los retos de prueba a principios del proyecto. En algunas situaciones, este proceso debe ser revisado periódicamente a lo largo del ciclo de vida del proyecto.
2. Identificar criterios de aceptación de rendimiento. Identificar el tiempo de respuesta, el rendimiento y los objetivos y limitaciones del uso de los recursos. En general, el tiempo de respuesta es una preocupación del usuario, el rendimiento es una preocupación empresarial y el uso de los recursos es una preocupación del sistema. Además, determinar los criterios de éxito del proyecto que tal vez no sean capturados por esos objetivos y limitaciones; por ejemplo, utilizar pruebas de rendimiento para evaluar qué combinación de ajustes de configuración dará lugar a las características de rendimiento más deseables.
3. Pruebas de Plan y Diseño. Identificar escenarios clave, determinar la variabilidad entre los usuarios representativos y cómo simular esa variabilidad, definir datos de prueba y establecer métricas para ser recolectadas. Consolidar esta información en uno o más modelos de uso del sistema para implementar, ejecutar y analizar.
4. Configure el ambiente de prueba. Prepare el entorno de prueba, herramientas y recursos necesarios para ejecutar cada estrategia, ya que las características y componentes están disponibles para la prueba. Asegurarse de que el entorno de prueba se instrumente para la vigilancia de los recursos según sea necesario.
5. Implementar el Diseño de Pruebas. Desarrollar las pruebas de rendimiento de acuerdo con el diseño de prueba.
6. Ejecute el examen. Ejecute y vigile sus pruebas. Validar las pruebas, datos de prueba y la colección de resultados. Ejecute pruebas validadas para el análisis mientras monitorea el ambiente de prueba y de prueba.
7. Analizar resultados, sintonía y protesta. Analizar, consolidar y compartir datos de resultados. Haz un cambio de afinación y reprueba. Compare los resultados de ambas pruebas. Cada mejora realizada devolverá una mejora más pequeña que la mejora anterior. ¿Cuándo te detienes? Cuando llegue a un cuello de botella CPU, las opciones entonces son mejorar el código o añadir más CPU.