Pruebas de rendimiento de software

Las pruebas de referencia se utilizan para establecer un punto de comparación para otros tipos de pruebas, como por ejemplo, una prueba de estrés. Al medir cómo reacciona el sistema en el "mejor de los casos", por ejemplo, con solo 5 usuarios simultáneos, se pueden utilizar otros tipos de pruebas para comparar cómo se degrada el rendimiento en el peor de los casos.

Las pruebas de carga son la forma más sencilla de realizar pruebas de rendimiento. Generalmente, se llevan a cabo para comprender el comportamiento del sistema bajo una carga específica prevista. Esta carga puede ser el número esperado de usuarios concurrentes en la aplicación que realizan un número determinado de transacciones en un período de tiempo establecido. Esta prueba proporcionará los tiempos de respuesta de todas las transacciones críticas para el negocio. Durante la prueba, también se supervisan la base de datos , el servidor de aplicaciones , etc., lo que ayudará a identificar cuellos de botella en el software de la aplicación y en el hardware donde está instalado.

Las pruebas de estrés se utilizan normalmente para comprender los límites superiores de capacidad del sistema. Este tipo de prueba se realiza para determinar la robustez del sistema ante cargas extremas y ayuda a los administradores de aplicaciones a determinar si el sistema funcionará correctamente si la carga actual supera con creces el máximo previsto.

Las pruebas de picos de carga son una forma especial de prueba de estrés que consiste en aumentar o disminuir repentinamente la carga generada por un gran número de usuarios y observar el comportamiento del sistema. El objetivo es determinar si el rendimiento se verá afectado, si el sistema fallará o si podrá gestionar cambios drásticos en la carga.

Las pruebas de punto de ruptura también son una forma de prueba de estrés. Se aplica una carga incremental a lo largo del tiempo mientras se monitoriza el sistema para detectar condiciones de fallo predeterminadas. A veces, las pruebas de punto de ruptura se denominan pruebas de capacidad, ya que permiten determinar la capacidad máxima por debajo de la cual el sistema funcionará según las especificaciones requeridas o los acuerdos de nivel de servicio (SLA). Los resultados del análisis de punto de ruptura aplicado a un entorno fijo pueden utilizarse para determinar la estrategia de escalado óptima en términos del hardware necesario o las condiciones que deberían desencadenar eventos de escalado horizontal en un entorno de nube.

Las pruebas de resistencia , también conocidas como pruebas de estabilidad o de carga continua, se realizan para determinar si el sistema puede soportar la carga prevista. Durante estas pruebas, se monitoriza la utilización de la memoria para detectar posibles fugas. Otro aspecto importante, aunque a menudo pasado por alto, es la degradación del rendimiento, es decir, garantizar que el rendimiento y/o los tiempos de respuesta tras un periodo prolongado de actividad continua sean iguales o mejores que al inicio de la prueba. Consisten básicamente en aplicar una carga significativa al sistema durante un periodo prolongado. El objetivo es descubrir cómo se comporta el sistema bajo un uso continuo.

Las pruebas de aislamiento no son exclusivas de las pruebas de rendimiento, sino que implican repetir la ejecución de una prueba que generó un problema en el sistema. Este tipo de pruebas a menudo permite aislar y confirmar el origen del fallo.

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

Esta es una forma relativamente nueva de pruebas de rendimiento en la que aplicaciones globales como Facebook, Google y Wikipedia se someten a pruebas de rendimiento mediante generadores de carga ubicados en el continente objetivo, ya sean máquinas físicas o máquinas virtuales en la nube. Estas pruebas suelen requerir una gran cantidad de preparación y supervisión para su correcta ejecución.

Si un sistema identifica a los usuarios finales mediante algún procedimiento de inicio de sesión, entonces un objetivo de concurrencia es altamente deseable. Por definición, este es el número máximo de usuarios concurrentes que se espera que el sistema admita en un momento dado. El flujo de trabajo de una transacción programada puede afectar la concurrencia real , especialmente si la parte iterativa incluye la actividad de inicio y cierre de sesión.

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

Esto se refiere al tiempo que tarda un nodo del sistema en responder a la solicitud de otro. Un ejemplo sencillo sería una solicitud HTTP 'GET' desde un navegador a un servidor web. En términos de tiempo de respuesta, esto es lo que miden todas las herramientas de pruebas de carga . Puede ser útil establecer objetivos de tiempo de respuesta del servidor para todos los nodos del sistema.

Las herramientas de pruebas de carga tienen dificultades para medir el tiempo de respuesta de renderizado, ya que generalmente no comprenden lo que sucede dentro de un nodo , más allá de reconocer un período de tiempo sin actividad en la red. Para medir el tiempo de respuesta de renderizado, suele ser necesario incluir scripts de pruebas funcionales como parte del escenario de prueba de rendimiento. Muchas herramientas de pruebas de carga no ofrecen esta función.

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en cualquier plan de pruebas de rendimiento. Idealmente, esto se realiza 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.

La especificación de rendimiento en términos de tiempo de respuesta, concurrencia, etc., generalmente se recoge en un Acuerdo de Nivel de Servicio (SLA). ^{[ 2 ] : 24} Alternativamente, el rendimiento de un caso de prueba se puede comparar con su ejecución anterior para identificar regresiones. Dado que las mediciones de rendimiento no son deterministas, la detección de regresiones de rendimiento requiere la repetición adecuada de la carga de trabajo de las pruebas de rendimiento y pruebas estadísticas apropiadas . ^{[ 3 ]}

Además, las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de optimización del perfil de rendimiento. La idea es identificar el cuello de botella : la parte del sistema que, si se optimiza su respuesta, permitirá que el sistema en general funcione más rápido. A veces resulta 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 sobre los tiempos de transacción, los tiempos de acceso a la base de datos, la sobrecarga de la red y otros parámetros del servidor, que pueden analizarse junto con las estadísticas de rendimiento sin procesar. Sin dicha instrumentación, es posible que sea necesario recurrir a la monitorización del sistema .

Las pruebas de rendimiento pueden realizarse en toda la web, e incluso en diferentes partes del país, dado que se sabe que los tiempos de respuesta de internet varían regionalmente. También pueden realizarse internamente, aunque en ese caso sería necesario configurar los routers para introducir la latencia típica de las redes públicas. La carga debe introducirse en el sistema desde puntos realistas. Por ejemplo, si el 50 % de los usuarios acceden al sistema mediante una conexión de módem de 56K y la otra mitad mediante una T1 , los inyectores de carga (ordenadores que simulan usuarios reales) deberían inyectar carga en la misma combinación de conexiones (lo ideal) o simular la latencia de red de dichas conexiones, siguiendo el mismo perfil de usuario.

Siempre es útil contar con una estimación del número máximo de usuarios que podrían utilizar el sistema en las horas pico. Si además se puede especificar el tiempo de respuesta máximo permitido (percentil 95), se podría utilizar una configuración de inyector para comprobar si el sistema propuesto cumple con dicha especificación.

Las especificaciones de rendimiento deberían plantear, como mínimo, las siguientes preguntas:

• En detalle, ¿cuál es el alcance de la prueba de rendimiento? ¿Qué subsistemas, interfaces, componentes, etc., están incluidos y excluidos de esta prueba?
• Para las interfaces de usuario (UI) involucradas, ¿cuántos usuarios simultáneos se esperan para cada una (especifique el valor máximo frente al valor nominal)?
• ¿Cómo es el sistema de destino (hardware) (especifique todas las configuraciones de servidores y dispositivos de red)?
• ¿Cuál es la distribución de la carga de trabajo de cada componente del sistema? (por ejemplo: 20 % inicio de sesión, 40 % búsqueda, 30 % selección de artículos, 10 % pago).

En las pruebas de rendimiento, suele ser crucial que las condiciones de prueba sean similares al uso real previsto. Sin embargo, en la práctica esto es difícil de lograr y no del todo posible, ya que los sistemas de producción están sometidos a cargas de trabajo impredecibles. Las cargas de trabajo de prueba pueden imitar las del entorno de producción en la medida de lo posible, pero solo en los sistemas más sencillos se puede replicar con exactitud esta variabilidad de la carga de trabajo.

Las implementaciones arquitectónicas poco acopladas (por ejemplo, SOA ) han generado complejidades adicionales en las pruebas de rendimiento. Para replicar fielmente los estados de producción, los servicios o activos empresariales que comparten una infraestructura o plataforma común requieren pruebas de rendimiento coordinadas, donde todos los consumidores generan volúmenes de transacciones y carga similares a los de producción en infraestructuras o plataformas compartidas. Debido a la complejidad y el alto costo que implica esta actividad, algunas organizaciones ahora utilizan herramientas para monitorear y simular condiciones similares a las de producción (también conocidas como "ruido") en sus entornos de pruebas de rendimiento ( PTE ) para comprender los requisitos de capacidad y recursos, y verificar/validar los atributos de calidad.

Para optimizar la relación costo-beneficio de un nuevo sistema, es fundamental que las pruebas de rendimiento comiencen al inicio del proyecto de desarrollo y se extiendan hasta su implementación. Cuanto más tarde se detecte un defecto de rendimiento, mayor será el costo de su corrección. Esto es cierto en el caso de las pruebas funcionales, pero aún más en el de las pruebas de rendimiento, debido a su alcance integral. Es crucial que un equipo de pruebas de rendimiento participe lo antes posible, ya que adquirir y preparar el entorno de pruebas y otros requisitos clave de rendimiento requiere mucho tiempo.

Esta parte de las pruebas de rendimiento se centra principalmente en la creación/programación de los flujos de trabajo de los procesos de negocio clave identificados. Esto se puede realizar utilizando 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 scripting (C, Java, JS) o algún tipo de representación visual (arrastrar y soltar) para crear y simular flujos de trabajo del usuario final. La mayoría de las herramientas permiten la función de "Grabar y Reproducir", mediante la cual el evaluador de rendimiento ejecuta la herramienta de prueba, la conecta a un navegador o cliente de escritorio y captura todas las transacciones de red que se producen entre el cliente y el servidor. De esta forma, se desarrolla un script que puede mejorarse o modificarse para emular diversos escenarios de negocio.

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

Parámetros de hardware del servidor

• Utilización de la CPU
• Utilización de la memoria
• utilización del disco
• utilización de la red

Como primer paso, los patrones generados por estos cuatro parámetros ofrecen una buena indicación de dónde reside el cuello de botella. Para determinar la causa raíz exacta del problema, los ingenieros de software utilizan herramientas como analizadores de rendimiento para medir qué partes de un dispositivo o software contribuyen en mayor medida al bajo rendimiento, o para establecer niveles de rendimiento (y umbrales) que permitan mantener un tiempo de respuesta aceptable.

Según la Red de Desarrolladores de Microsoft, la metodología de pruebas de rendimiento consta de las siguientes actividades:

1. Identificar el entorno de prueba. Identifique el entorno físico de prueba y el entorno de producción, así como las herramientas y los recursos disponibles para el equipo de pruebas. El entorno físico incluye el hardware, el software y las configuraciones de red. Comprender a fondo todo el entorno de prueba desde el principio permite un diseño y una planificación de pruebas más eficientes y ayuda a identificar los desafíos de las pruebas en las primeras etapas del proyecto. En algunos casos, este proceso debe revisarse periódicamente a lo largo del ciclo de vida del proyecto .
2. Identifique los criterios de aceptación del rendimiento. Defina los objetivos y las limitaciones de tiempo de respuesta, rendimiento y uso de recursos. En general, el tiempo de respuesta es una preocupación del usuario, el rendimiento es una preocupación del negocio y el uso de recursos es una preocupación del sistema. Además, identifique criterios de éxito del proyecto que no estén contemplados en dichos objetivos y limitaciones; por ejemplo, el uso de pruebas de rendimiento para evaluar qué combinación de configuraciones dará como resultado las características de rendimiento más deseables.
3. Planificar y diseñar pruebas. Identificar escenarios clave , determinar la variabilidad entre usuarios representativos y cómo simularla , definir los datos de prueba y establecer las métricas que se recopilarán. Consolidar esta información en uno o más modelos de uso del sistema para su implementación, ejecución y análisis.
4. Configurar el entorno de prueba. Preparar el entorno de prueba, las herramientas y los recursos necesarios para ejecutar cada estrategia, a medida que las funciones y los componentes estén disponibles para su prueba. Asegurarse de que el entorno de prueba esté instrumentado para la monitorización de recursos según sea necesario.
5. Implementar el diseño de pruebas. Desarrollar las pruebas de rendimiento de acuerdo con el diseño de pruebas.
6. Ejecuta la prueba. Ejecuta y supervisa tus pruebas. Valida las pruebas, los datos de prueba y la recopilación de resultados . Ejecuta las pruebas validadas para su análisis mientras supervisas la prueba y el entorno de prueba.
7. Analizar resultados, optimizar y volver a probar. Analizar, consolidar y compartir los datos de resultados. Realizar un ajuste y volver a probar. Comparar los resultados de ambas pruebas. Cada mejora realizada generará una mejora menor que la anterior. ¿Cuándo detenerse? Cuando se alcanza un cuello de botella de la CPU, las opciones son mejorar el código o aumentar la capacidad de la CPU.