En la ingeniería del software, las pruebas de rendimiento son las pruebas que se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. Las pruebas de rendimiento son un subconjunto de la ingeniería de pruebas, una práctica informática que se esfuerza por mejorar el rendimiento, englobándose en el diseño y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificación.

Contenido 1 Introducción 1.1 Pruebas de carga 1.2 Prueba de estrés 1.3 Prueba de estabilidad (soak testing) 1.4 Pruebas de picos (spike testing) 1.5 Pre-requisitos para las pruebas de carga 2 Mitos de las pruebas de rendimiento 3 Tecnología 4 Especificaciones del rendimiento 5 Tareas a realizar 6 Metodología 6.1 Metodología de pruebas de rendimiento de aplicaciones Web

Introducción

Las pruebas de rendimiento pueden servir para diferentes propósitos. Pueden demostrar que el sistema cumple los criterios de rendimiento. Pueden comparar dos sistemas para encontrar cual de ellos funciona mejor. O pueden medir que partes del sistema o de carga de trabajo provocan que el conjunto rinda mal. Para su diagnóstico, los ingenieros de software utilizan herramientas como pueden ser monitorizaciones que midan qué partes de un dispositivo o software contribuyen más al mal rendimiento o para establecer niveles (y umbrales) del mismo que mantenga un tiempo de respuesta aceptable.

Es fundamental para alcanzar un buen nivel de rendimiento de un nuevo sistema, que los esfuerzos en estas pruebas comiencen en el inicio del proyecto de desarrollo y se amplie durante su construcción. Cuanto más se tarde en detectar un defecto de rendimiento, mayor es el coste de la solución. Esto es cierto en el caso de las pruebas funcionales, pero mucho más en las pruebas de rendimiento, debido a que su ámbito de aplicación es de principio a fin.

En las pruebas de rendimiento, a menudo es crucial (y con frecuencia difícil de conseguir) que las condiciones de prueba sean similares a las esperadas en el uso real. Esto es, sin embargo, casi imposible en la práctica. La razón es que los sistemas en producción tienen un carácter aleatorio de la carga de trabajo y aunque en las pruebas se intente dar lo mejor de sí para imitar el volumen de trabajo que pueda tener el entorno de producción, es imposible reproducir exactamente la variabilidad de ese trabajo, salvo en el sistema más simple.

Los nuevos conceptos en la implementación de la arquitectura (por ejemplo: SOA) han añadido complejidad adicional a las pruebas de rendimiento. Los servicios o recursos de la empresa (que comparten infraestructura o plataforma) requieren pruebas de rendimiento coordinadas (con la creación del volumen y carga de todos los sistemas que comparten la infraestructura o plataformas) para reproducir realmente el estado del entorno de producción. Debido a la complejidad, coste y tiempo necesario en torno a esta actividad, algunas organizaciones emplean herramientas que pueden mostrar y crear condiciones (también conocido como "ruido") en los entornos de pruebas de rendimiento para comprender la capacidad y las necesidades de recursos y verificar/validar los niveles de calidad.

Pruebas de carga

Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la aplicación y que realizan un número específico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicación. Si la base de datos, el servidor de aplicaciones, etc también se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la aplicación.

Prueba de estrés

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la carga real supere a la carga esperada.

Prueba de estabilidad (soak testing)

Esta prueba normalmente se hace para determinar si la aplicación puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicación.

Pruebas de picos (spike testing)

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el número de usuarios, tanto cuando bajan, como cuando tiene cambios drásticos en su carga. Este prueba se recomienda que sea realizada con un software automatizado que permita realizar cambios en el numero de usuraios mientras que los administradores llevan un registro de los valores a ser monitoreados.

Pre-requisitos para las pruebas de carga

Un desarrollo estable de la aplicación instalado en un entorno lo más parecido al de producción.

El entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptación de usuarios ni con el entorno de desarrollo. Esto es tan peligroso que si las pruebas de aceptación de usuarios, o las pruebas de integración o cualquier otra prueba se ejecutan en el mismo entorno, entonces los resultados no son fiables. Como buena práctica, siempre es aconsejable disponer de un entorno de pruebas de rendimiento lo más parecido como se pueda al entorno de producción.

Mitos de las pruebas de rendimiento

Algunos de los mitos más comunes son los siguientes.

1. Las pruebas de rendimiento se hacen para romper el sistema: Las pruebas de estrés se hacen para observar el punto de ruptura del sistema. Por el contrario, las pruebas normales de carga se hacen generalmente para ver el comportamiento de la aplicación bajo una carga de usuarios esperada, y dependen de otros requisitos, tales como el aumento de carga esperado, la carga continuada por un periodo prolongado de tiempo mientras la demanda aumenta, la resistencia a las caídas o las pruebas de estrés.
2. Las pruebas de rendimiento sólo deben hacerse después de las pruebas de integración del sistema: Aunque esta es la norma común en la industria, las pruebas de rendimiento también pueden realizarse mientras se realiza el desarrollo inicial de la aplicación. Este tipo de enfoque se conoce como pruebas de rendimiento tempranas. Este enfoque garantizaría un desarrollo holístico de la aplicación manteniendo los parámetros de rendimiento en mente. Por lo tanto, la búsqueda de un problema en el rendimiento justo antes de la terminación de la aplicación y el coste de corregir el error, se reduce en gran medida.
3. El probar el rendimiento sólo implica la creación de scripts y cualquier cambio en la aplicación solo puede causar una simple refactorización dichos scripts: Las pruebas de rendimiento son en sí mismas una ciencia evolucionada de la industria del software. En sí mismos, los scripts, aunque importantes, son sólo uno de los componentes de las pruebas de rendimiento. El principal desafío para cualquier persona que pruebe el rendimiento es determinar el tipo de pruebas necesarias y analizar los distintos medidores de rendimiento para determinar el cuello de botella de rendimiento.

Por otro lado, en relación con este mito, también es falso que cualquier cambio en la interfaz de usuario, especialmente en el ámbito Web, supone un completo desarrollo de los scripts desde cero. Este problema se vuelve mayor si los protocolos involucrados incluyen Web Services, Siebel, scripts de acciones, Citrix o SAP.

Tecnología

La tecnología de las pruebas de rendimiento utiliza uno o más PC o servidores para actuar como peticionarios. Cada uno emula la presencia de un número de usuarios y cada uno ejecuta una secuencia automática de las interacciones (registrada como una secuencia de comandos, o como una serie de scripts para simular los distintos tipos de uso por parte de los usuarios) con la aplicación cuyo rendimiento se pone a prueba. Por lo general, un PC actúa como gestor de prueba, coordinando, recopilando las métricas de cada uno de los ejecutores y acumulando los datos de rendimiento para la realización de los informes.

La secuencia habitual es incrementar la carga, comenzando con un pequeño número de usuarios virtuales y aumentando el número durante un periodo hasta alcanzar el máximo. El resultado de la prueba muestra la forma en que el rendimiento varía con la carga, mostrando como el número de usuarios modifica el tiempo de respuesta. Existen diversas herramientas disponibles para la realización de tales pruebas. Estas herramientas suelen ejecutar un conjunto de pruebas que simulan usuarios reales utilizando el sistema. A veces los resultados pueden revelar curiosidades, por ejemplo, si el promedio de tiempo de respuesta puede ser aceptable, si existen valores anómalos en las peticiones que necesitan tiempos considerablemente más largo para ejecutarse - algo que puede ser causado por peticiones poco eficientes a la base de datos, fotos, etc.

Las pruebas de rendimiento se pueden combinar con pruebas de estrés, con el fin de ver qué pasa cuando una carga aceptable se supera ¿Se cae el sistema? ¿Cuánto tiempo tarda en recuperarse si se reduce una gran carga? ¿Un fallo produce daños colaterales?

El modelo de análisis de rendimiento es un método para modelar el comportamiento de una aplicación en una hoja de cálculo. El modelo se alimenta con las mediciones de los recursos solicictados por las peticiones (CPU, IO, LAN, WAN), ponderado por el nivel de transacción (las peticiones realizadas por unidad de tiempo, habitualmente una hora).

La demanda de recursos de las peticiones son acumuladas para obtener la demanda de recursos por unidad de tiempo y divididas por la capacidad total de recursos por la misma unidad, obteniendo así la carga de recursos. Usando la formula de tiempo de respuesta (R=S/(1-U), R=tiempo de respuesta, S=tiempo del servicio, U=carga), los tiempos de respuesta pueden ser calculados y calibrados con los resultados de las pruebas de rendimiento. El modelo de análisis del rendimiento permite la evaluación de diferentes opciones de diseño y dimensionamiento del sistema sobre la base actual o la prevista del uso de la aplicación. Por lo tanto, es mucho más rápido y más barato que las pruebas de rendimiento, aunque requiere una alta comprensión de las plataformas de hardware.

Especificaciones del rendimiento

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en algún plan de pruebas de rendimiento. Idealmente, esto se hace durante la fase de requisitos del desarrollo de cualquier proyecto de desarrollo de sistemas, antes de cualquier esfuerzo de diseño.

Sin embargo, con frecuencia las pruebas de rendimiento no se realizan teniendo en cuenta alguna especificación, es decir, nadie ha expresado cual es el tiempo máximo de respuesta aceptable para un número determinado de usuarios. Las pruebas de rendimiento se utiliza con frecuencia como parte del proceso de ajuste de la ejecución. La idea es identificar el "eslabón más débil" - hay, inevitablemente, una parte del sistema que, si responde con mayor rapidez, eso se traducirá en un funcionamiento del sistema global más rápido.

A veces es una difícil tarea determinar qué parte del sistema representa esta ruta crítica, y algunas herramientas de prueba incluyen (o puede tener añadidos que lo proporcionan) instrumentos que se ejecuta en el servidor (agentes) y que informan de tiempos de transacción, número de accesos a bases de datos, sobrecarga de la red, y otros monitores del servidor, que pueden ser analizados junto con los datos principales de las estadísticas de rendimiento. Sin estos instrumentos se podría tener a alguien encargado de observar el administrador de tareas de Microsoft Windows del servidor para ver como se carga la CPU en las pruebas de rendimiento (suponiendo que se prueba un sistema de Windows).

Hay una supuesta historia de una empresa que gastó una gran cantidad para optimizar su software sin haber realizado un análisis adecuado del problema. La empresa terminó reescribiendo el proceso de sistema ‘idle loop’, que es donde habían encontrado que el pasaba la mayor parte de su tiempo, pero incluso con el más eficiente proceso de espera en el mundo, obviamente, no mejoraron el rendimiento general ni un ápice.

Las pruebas de rendimiento se pueden realizar a través de la web, e incluso hacerse en diferentes partes del país, ya que es sabido que los tiempos de respuesta de Internet varían regionalmente. También se puede hacer en local, aunque el hardware de enrutamiento debe estar configurado para introducir el desfase de lo que suele ocurrir en las redes públicas. Las cargas deben ser realizadas en puntos realistas del sistema. Por ejemplo, si el 50% de usuarios de un sistema accede a través de una conexión de módem de 56K y la otra mitad a través de una T1, entonces la carga simulada (ordenadores que simulan los usuarios reales) se debe realizar, ya sea con las mismas conexiones (caso ideal) o simular la latencia de la red de conexiones de este tipo, siguiendo el mismo perfil de usuario.

Siempre es útil disponer de una estimación del pico de número de usuarios que se espera que utilicen el sistema en las horas punta. Si puede ser también una estimación del máximo tiempo de respuesta permitido en el percentil 95, para que la configuración de la ejecución de las pruebas se ejuste a estas especificaciones.

La especificación de rendimiento, como mínimo, debería respponder a las siguientes preguntas:

• ¿Cuál es el alcance, en detalle, de la prueba de rendimiento? ¿Qué subsistemas, interfaces, componentes, etc están dentro y fuera del ámbito de ejecución de esta prueba?
• Para las interfaces de usuario involucradas, ¿Cual es el número de usuarios concurrentes que se esperan para cada uno (especificando picos y medias?
• ¿Cuál es la estructura objetivo del sistema (hardware, especificandor todos los servidores de red y configuraciones de dispositivo)?
• ¿Cuál es la distribución del volumen de trabajo de la aplicación para cada componente? (por ejemplo: 20% login, 40% buscando, 30% seleccionando elemento, 10% comprando).
• ¿Cual es la distribución del trabajo del sistema? [Las cargas de trabajo múltiples pueden ser simuladas en una sola prueba de eficacia] (por ejemplo: 30% del volumen de trabajo para A, 20% del volumen de trabajo para B, 50% del volumen de trabajo para C)
• ¿Cuáles son los requisitos de tiempo para cada uno y para todos los procesos por lotes (especificando picos y medias)?

Tareas a realizar

Las tareas para realizar una prueba de este tipo serían las siguientes:

• Decidir usar recursos internos o externos para ejecutar las pruebas, en función de la experiencia de la casa (o falta de ella).
• Reunir u obtener requisitos de rendimiento (especificaciones) de los usuarios y/o analistas.
• Desarrollar un plan de alto nivel, incluyendo los requisitos, recursos, plazos e hitos.
• Elaborar un plan de pruebas de rendimiento detallado (incluyendo los escenarios detallados y casos de prueba, cargas de trabajo, información del entorno, etc).
• Elegir la/s herramienta/s de prueba.
• Especificar los datos de prueba necesarios y la distribución de ellos (a menudo pasado por alto, y a menudo el fracaso de una prueba de rendimiento válida).
• Desarrollar scripts de prueba de concepto para cada aplicación/componente sometido a la prueba, utilizando la herramienta de prueba elegida y estrategias.
• Desarrollar un plan de prueba de rendimiento detallado, incluyendo todas las dependencias y los plazos.
• Instalar y configurar los simuladores de peticiones y controladores.
• Configurar el entorno de prueba (lo ideal es que sea idéntico hardware a la plataforma de producción), configurar los router, aislar la red (no queremos alterar los resultados por parte de otros usuarios), desplegar la aplicación en el servidor, desarrollar la base de datos de prueba, etc.
• Ejecutar las pruebas, probablemente en repetidas ocasiones (iterativamente), a fin de ver si el desconocimiento de cualquier factor podría afectar a los resultados.
• Analizar los resultados - ya sea de aceptando/rechazando, o investigación el camino crítico y recomendando medidas correctivas .

Metodología

Metodología de pruebas de rendimiento de aplicaciones Web

Según Microsoft Developer Network, la Metodología de las Pruebas de Rendimiento consiste en las siguientes actividades:

• Actividad 1. Identificar el entorno de pruebas. Identificar el entorno físico de pruebas y el entorno de producción, así como las herramientas y recursos de que dispone el equipo de prueba. El entorno físico incluye hardware, software y configuraciones de red. Tener un profundo conocimiento de todo el entorno de prueba desde el principio permite diseños más eficientes de pruebas y la planificación y ayuda a identificar problemas en las pruebas en fases tempranas del proyecto. En algunas situaciones, este proceso debe ser revisado periódicamente durante todo el ciclo de vida del proyecto.
• Actividad 2. Identificar los criterios de aceptación de rendimiento. Determinar el tiempo de respuesta, el rendimiento, la utilización de los recursos y los objetivos y limitaciones. En general, el tiempo de respuesta concierne al [[usuario+], el rendimiento al negocio, y la utilización de los recursos al sistema. Además, identificar criterios de éxito del proyecto que no hayan sido recogidos por los objetivos y limitaciones, por ejemplo, mediante pruebas de rendimiento para evaluar qué combinación de la configuración da lugar a un funcionamiento óptimo.
• Actividad 3. Planificar y diseñar las pruebas. Identificar los principales escenarios, determinar la variabilidad de los usuarios y la forma de simular esa variabilidad, definir los datos de las pruebas, y establecer las métricas a recoger. Consolidar esta información en uno o más modelos de uso del sistema a implantar, ejecutarlo y analizarlo.
• Actividad 4. Configurar el entorno de prueba. Preparar el entorno de prueba, herramientas y recursos necesarios para ejecutar cada una de las estrategias, así como las características y componentes disponibles para la prueba. Asegúrarse de que el entorno de prueba se ha preparado para la monitorización de los recursos según sea necesario.
• Actividad 5. Aplicar el diseño de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el diseño del plan.
• Actividad 6. Ejecutar la prueba. Ejecutar y monitorizar las pruebas. Validar las pruebas, los datos de las pruebas, y recoger los resultados. Ejecutar pruebas validas para analizar, mientras se monitoriza la prueba y su entorno.
• Actividad 7. Analizar los resultados, realizar un informe y repetirlo. Consolidar y compartir los resultados de la prueba. Analizar los datos, tanto individualmente, como con un equipo multidisciplinario. Volver a priorizar el resto de las pruebas y volver a ejecutarlas de ser necesario. Cuando todas las métricas estén dentro de los límites aceptados, ninguno de los umbrales establecidos han sido rebasados, y toda la información deseada se ha reunido, las pruebas han acabado para el escenario definido por la configuración.