Pruebas de rendimiento de software

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) Este artículo necesita citas adicionales para su verificación .Por favor, ayude a mejorar este artículo añadiendo citas de fuentes confiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Pruebas de rendimiento de software» – noticias  · periódicos  · libros  · académico  · JSTOR ( Febrero de 2024 )( Aprenda cómo y cuándo eliminar este mensaje ) Este artículo posiblemente contiene investigación original . Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (August 2021) (Learn how and when to remove this message) (Learn how and when to remove this message)

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

Las pruebas de rendimiento, un subconjunto de la ingeniería de rendimiento, son una práctica de la informática que busca incorporar estándares de rendimiento en la implementación, el diseño y la arquitectura de un sistema.

La prueba de carga es la forma más simple de prueba de rendimiento. Una prueba de carga se realiza generalmente para comprender el comportamiento del sistema bajo una carga específica esperada. Esta carga puede ser la cantidad esperada de usuarios simultáneos en la aplicación que realizan una cantidad específica de transacciones dentro de la duración establecida. Esta prueba proporcionará los tiempos de respuesta de todas las transacciones críticas importantes para el negocio. La base de datos , el servidor de aplicaciones , etc. también se monitorean durante la prueba, lo que ayudará a identificar cuellos de botella en el software de la aplicación y el hardware en el que está instalado el software.

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 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.

Las pruebas de resistencia , también conocidas como pruebas de inmersión, se realizan generalmente para determinar si el sistema puede soportar la carga continua esperada. Durante las pruebas de inmersión, se monitorea 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, para 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. Básicamente, 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.

Las pruebas de picos de carga se realizan 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, si el sistema fallará o si podrá manejar cambios drásticos en la carga.

Las pruebas de puntos de interrupción son similares a las pruebas de estrés. Se aplica una carga incremental a lo largo del tiempo mientras se monitorea el sistema para detectar condiciones de falla predeterminadas. Las pruebas de puntos de interrupción a veces se denominan pruebas de capacidad porque se puede decir que determinan 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 escalamiento óptima en términos del hardware requerido o las condiciones que deberían desencadenar eventos de escalamiento horizontal en un entorno de nube.

En lugar de probar el rendimiento desde una perspectiva de carga, se crean pruebas para determinar los efectos de los cambios de configuración de 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 .

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. Estas pruebas suelen poder aislar y confirmar el dominio de la falla.

Se trata de una forma relativamente nueva de realizar pruebas de rendimiento en la que se prueba el rendimiento de aplicaciones globales como Facebook, Google y Wikipedia desde generadores de carga ubicados en el continente de destino real, 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 ejecutarse con éxito.

Las pruebas de rendimiento pueden tener diferentes propósitos:

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

Muchas pruebas de rendimiento se realizan sin establecer objetivos de rendimiento lo suficientemente realistas y orientados a objetivos. La primera pregunta desde una perspectiva empresarial siempre debería ser "¿por qué estamos realizando pruebas de rendimiento?". Estas consideraciones forman parte del análisis de negocio de las pruebas. Los objetivos de rendimiento variarán según la tecnología y el propósito del sistema, pero siempre deberían incluir algunos de los siguientes:

Si un sistema identifica a los usuarios finales mediante algún tipo de procedimiento de inicio de sesión, entonces es muy deseable que se alcance un objetivo de concurrencia. Por definición, se trata de la mayor cantidad de usuarios simultáneos del sistema que se espera que admita el sistema en un momento determinado. El flujo de trabajo de una transacción programada puede afectar la concurrencia real , especialmente si la parte iterativa contiene la actividad de inicio y cierre de sesión.

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

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' del cliente del navegador al servidor web. En términos de tiempo de respuesta, esto es lo que miden realmente todas las herramientas de prueba de carga . Puede ser relevante establecer objetivos de tiempo de respuesta del servidor entre todos los nodos del sistema.

Las herramientas de prueba de carga tienen dificultades para medir el tiempo de respuesta de renderizado, 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 la red". Para medir el tiempo de respuesta de renderizado, generalmente es necesario incluir scripts de prueba funcional como parte del escenario de prueba de rendimiento. Muchas herramientas de prueba de carga no ofrecen esta función.

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en cualquier plan de pruebas de rendimiento. Lo ideal es que esto se haga 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 no suelen realizarse en función de una especificación; por ejemplo, nadie habrá expresado cuál debería ser el tiempo de respuesta máximo aceptable para una población determinada 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 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 proporcionen) 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, la sobrecarga de la red y otros monitores del servidor, que se pueden analizar junto con las estadísticas de rendimiento sin procesar. Sin dicha instrumentación, es posible que haya 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 varían regionalmente. También se pueden realizar internamente, aunque en ese caso sería necesario configurar los enrutadores para introducir el retraso que normalmente se produciría en las redes públicas. Las cargas se deben introducir 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 56K y la otra mitad a través de una T1 , entonces los inyectores de carga (computadoras que simulan usuarios reales) deberían inyectar carga sobre la misma combinación 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 utilicen el sistema en las horas pico. Si también se puede indicar qué constituye el tiempo de respuesta máximo permitido del percentil 95, se podría utilizar una configuración de inyector para comprobar si el sistema propuesto cumple con esa especificación.

Las especificaciones de rendimiento deben 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 dentro y fuera del alcance de esta prueba?
• Para las interfaces de usuario (UI) involucradas, ¿cuántos usuarios simultáneos se esperan para cada una (especifique pico vs. nominal)?
• ¿Cómo se ve el sistema de destino (hardware) (especifique todas las configuraciones del servidor y del dispositivo de red)?
• ¿Cuál es la combinación de carga de trabajo de la aplicación de cada componente del sistema? (por ejemplo: 20 % de inicio de sesión, 40 % de búsqueda, 30 % de selección de artículos, 10 % de pago).
• ¿Cuál es la combinación de cargas de trabajo del sistema? [Se pueden simular múltiples cargas de trabajo en una sola prueba de rendimiento] (por ejemplo: 30 % carga de trabajo A, 20 % carga de trabajo B, 50 % carga de trabajo C).
• ¿Cuáles son los requisitos de tiempo para todos los procesos por lotes back-end (especifique pico vs. nominal)?

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

Para garantizar resultados consistentes, 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 pruebas de rendimiento separado que se parezca lo más posible al entorno de producción.

En las pruebas de rendimiento, suele ser fundamental que las condiciones de prueba sean similares a las del uso real previsto. Sin embargo, en la práctica esto es difícil de conseguir 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 en la medida de lo posible las situaciones del entorno de producción, pero solo en los sistemas más sencillos se puede reproducir exactamente esta variabilidad de la carga de trabajo.

Las implementaciones de arquitecturas acopladas de forma flexible (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, en las que todos los consumidores crean volúmenes de transacciones y cargas similares a los de producción en infraestructuras o plataformas compartidas. Debido a que esta actividad es tan compleja y costosa en términos de 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 pruebas de rendimiento ( PTE ) para comprender los requisitos de capacidad y recursos y verificar/validar los atributos de calidad.

Para la rentabilidad de un nuevo sistema es fundamental que las pruebas 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 coste de su reparación. Esto es así en el caso de las pruebas funcionales, pero más aún en el de las pruebas de rendimiento, debido a la naturaleza integral de su alcance. Es fundamental que un equipo de pruebas de rendimiento participe lo antes posible, porque adquirir y preparar el entorno de prueba y otros requisitos clave de rendimiento lleva mucho tiempo.

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

Esta parte de las pruebas de rendimiento se ocupa principalmente de crear o programar los flujos de trabajo de los procesos empresariales clave identificados. Esto se puede hacer 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 programación (C, Java, JS) o alguna forma de representación visual (arrastrar y soltar) para crear y simular flujos de trabajo del usuario final. La mayoría de las herramientas permiten algo llamado "Grabar y reproducir", donde el evaluador de rendimiento iniciará 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 o modificar para emular varios escenarios comerciales.

Esta es la otra cara de las pruebas de rendimiento. Con la supervisión del rendimiento, se observan las características de comportamiento y respuesta de la aplicación que se está probando. Los siguientes parámetros se suelen supervisar durante la ejecución de una prueba de rendimiento.

Parámetros del hardware del servidor

• Utilización de 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 proporcionan 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 utilizan herramientas como los 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.

La tecnología de pruebas de rendimiento emplea una o más PC o servidores Unix para actuar como inyectores, cada uno emulando la presencia de una cantidad de usuarios y ejecutando una secuencia automatizada de interacciones (registradas 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 la prueba, coordinando y recopilando métricas de cada uno de los inyectores y cotejando datos de rendimiento para fines de informes. La secuencia habitual es aumentar la carga: comenzar con unos pocos usuarios virtuales y aumentar la cantidad con el tiempo hasta un máximo predeterminado. El resultado de la prueba muestra cómo varía el rendimiento con la carga, dado como cantidad de usuarios versus tiempo de respuesta. Hay varias herramientas disponibles para realizar tales pruebas. Las herramientas de esta categoría generalmente ejecutan un conjunto de pruebas que emulan 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 considerablemente más en completarse, algo que puede deberse a consultas de bases 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 tarda en recuperarse si se reduce una carga importante? ¿Su falla causa daños colaterales?

El modelado analítico del rendimiento 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 transacción ( CPU , E/S de disco, LAN , WAN ), ponderadas por la combinación de transacciones (transacciones comerciales por hora). Las demandas ponderadas de recursos de transacción 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. Utilizando la fórmula del tiempo de respuesta (R=S/(1-U), R=tiempo de respuesta, S=tiempo de servicio, U=carga), se pueden calcular y calibrar los tiempos de respuesta con los resultados de las pruebas de rendimiento. El modelado analítico del rendimiento 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.

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).
• Recopilar o solicitar requisitos de rendimiento (especificaciones) de los usuarios y/o analistas de negocios.
• Desarrollar un plan de alto nivel (o carta del proyecto), que incluya requisitos, recursos, cronogramas e hitos.
• Desarrollar un plan de pruebas de rendimiento detallado (que incluya escenarios y casos de prueba detallados , cargas de trabajo, información del entorno, etc.).
• Seleccione la(s) herramienta (s) de prueba.
• Especificar los datos de prueba necesarios y el esfuerzo asignado (que a menudo se pasa por alto, pero es vital para llevar a cabo una prueba de rendimiento válida).
• Desarrollar scripts de prueba de concepto para cada aplicación/componente bajo prueba, utilizando herramientas y estrategias de prueba elegidas.
• Desarrollar un plan detallado del proyecto de pruebas de rendimiento, incluidas todas las dependencias y los cronogramas asociados.
• Instalar y configurar inyectores/controladores.
• Configurar el entorno de pruebas (idealmente hardware idéntico a la plataforma de producción), configuración del enrutador, red silenciosa (no queremos que los resultados se alteren por otros usuarios), despliegue de la instrumentación del servidor, conjuntos de pruebas de bases de datos desarrollados, etc.
• Ejecutar las pruebas en seco: antes de ejecutar realmente la prueba de carga con usuarios predefinidos, se realiza una ejecución en seco para verificar la corrección del script.
• Ejecutar pruebas, probablemente de forma repetida (iterativamente), para ver si algún factor no tenido en cuenta podría afectar los resultados.
• Analizar los resultados, ya sea aprobado/reprobado, o investigación de la ruta crítica y recomendación de acciones correctivas.

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

1. Identificar el entorno de prueba. Identifique el entorno de prueba físico y el entorno de producción, así como las herramientas y los recursos disponibles para el equipo de prueba. El entorno físico incluye configuraciones de hardware, software y red. Tener un conocimiento profundo de todo el entorno de prueba desde el principio permite un diseño y una planificación de pruebas más eficientes y lo ayuda a identificar los desafíos de las pruebas en las primeras etapas del proyecto. En algunas situaciones, este proceso debe revisarse periódicamente durante el ciclo de vida del proyecto .
2. Identificar los criterios de aceptación del rendimiento. Identificar 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, identificar los criterios de éxito del proyecto que pueden no estar incluidos en esos objetivos y limitaciones; por ejemplo, utilizar pruebas de rendimiento para evaluar qué combinación de ajustes de configuración 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 simular esa variabilidad, definir datos de prueba y establecer métricas que se recopilarán. Consolidar esta información en uno o más modelos de uso del sistema para implementar, ejecutar y analizar.
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 características y los componentes estén disponibles para la prueba. Asegurarse de que el entorno de prueba esté instrumentado para la supervisió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. Ejecutar la prueba. Ejecutar y supervisar las pruebas. Validar las pruebas, los datos de prueba y la recopilación de resultados. Ejecutar pruebas validadas para su análisis mientras se supervisa la prueba y el entorno de prueba.
7. Analizar resultados, ajustar y volver a probar. Analizar, consolidar y compartir los datos de los resultados. Realizar un cambio de ajuste y volver a probar. Comparar los resultados de ambas pruebas. Cada mejora realizada arrojará una mejora menor que la mejora anterior. ¿Cuándo detenerse? Cuando se llega a un cuello de botella de la CPU, las opciones son mejorar el código o agregar más CPU.

• Benchmark (informática)  – Evaluación estandarizada del desempeño
• Evaluación comparativa de servidores web  : estimación del rendimiento de los servidores web
• Medición de respuesta de aplicaciones  : estándar para gestionar cuellos de botella