Las pruebas de rendimiento ( ing . Performance Testing ) en ingeniería de software son pruebas que se llevan a cabo para determinar qué tan rápido funciona un sistema informático o parte de él bajo una determinada carga . También puede servir para probar y validar otros atributos de calidad del sistema, como escalabilidad , confiabilidad y consumo de recursos.
Las pruebas de rendimiento son una de las áreas emergentes de la ingeniería de rendimiento en informática que busca considerar el rendimiento en la fase de modelado y diseño de un sistema, antes de que comience la fase principal de codificación .
En las pruebas de rendimiento, se distinguen las siguientes áreas:
Hay dos enfoques para las pruebas de rendimiento del software [1] :
La prueba de carga es la forma más simple de prueba de rendimiento. Las pruebas de carga generalmente se realizan para evaluar el comportamiento de una aplicación bajo una carga esperada dada. Esta carga puede ser, por ejemplo, el número esperado de usuarios simultáneos de la aplicación que realizan un número determinado de transacciones por intervalo de tiempo. Este tipo de prueba generalmente le permite obtener el tiempo de respuesta de todas las transacciones comerciales más importantes. En el caso de monitorear una base de datos, un servidor de aplicaciones , una red, etc., este tipo de pruebas también pueden identificar algunos cuellos de botella de la aplicación.
Las pruebas de estrés se usan comúnmente para comprender los límites de rendimiento de una aplicación. Este tipo de prueba se lleva a cabo para determinar la confiabilidad del sistema durante cargas extremas o desproporcionadas y responde preguntas sobre el rendimiento suficiente del sistema en caso de que la carga actual supere con creces el máximo esperado.
Las pruebas de estabilidad se realizan para garantizar que la aplicación pueda soportar la carga esperada a largo plazo. Este tipo de prueba monitorea el consumo de memoria de la aplicación para identificar posibles fugas. Además, dichas pruebas revelan una degradación del rendimiento, que se expresa en una disminución de la velocidad de procesamiento de la información y/o un aumento en el tiempo de respuesta de la aplicación después de una larga ejecución en comparación con el comienzo de la prueba.
La prueba de configuración es otro tipo de prueba de rendimiento tradicional. En este caso, en lugar de probar el rendimiento del sistema en términos de la carga aplicada, se prueba el impacto en el rendimiento de los cambios de configuración. Un buen ejemplo de tales pruebas sería experimentar con diferentes métodos de equilibrio de carga. Las pruebas de configuración también se pueden combinar con pruebas de carga, tensión o estabilidad.
En casos generales , las pruebas de rendimiento pueden servir para diferentes propósitos.
Muchas pruebas de rendimiento se realizan sin ningún intento de comprender su propósito real. Antes de comenzar con las pruebas, siempre se debe hacer la pregunta empresarial: "¿Cuál es el objetivo que perseguimos con las pruebas de rendimiento?". Las respuestas a esta pregunta forman parte del estudio de viabilidad (o caso de negocio ) de las pruebas. Los objetivos pueden variar según la tecnología utilizada por la aplicación o su propósito, sin embargo, siempre incluyen uno de los siguientes:
Si se considera que los usuarios finales de la aplicación son usuarios que inician sesión en el sistema de cualquier forma, entonces es muy deseable lograr el paralelismo en este caso. Por definición, este es el número máximo de usuarios en ejecución simultáneos de una aplicación que se espera que admita la aplicación en un momento dado. El patrón de comportamiento del usuario puede afectar significativamente la capacidad de una aplicación para procesar solicitudes en paralelo, especialmente si implica iniciar y cerrar sesión periódicamente en el sistema.
Si el concepto de la aplicación no es trabajar con usuarios finales específicos, entonces el objetivo de rendimiento perseguido se basará en el rendimiento máximo o el número de transacciones por unidad de tiempo. Un buen ejemplo en este caso sería navegar por la web, por ejemplo en el portal de Wikipedia.
Este concepto se basa en el tiempo de respuesta de un nodo de aplicación a una solicitud enviada a otro. Un ejemplo simple es una solicitud HTTP 'GET' desde el navegador de una estación de trabajo a un servidor web. Casi todas las aplicaciones desarrolladas para pruebas de carga funcionan exactamente de acuerdo con este esquema de medición. A veces, tiene sentido establecer objetivos para lograr el rendimiento del tiempo de respuesta del servidor en todos los nodos de la aplicación.
El tiempo de visualización es uno de los conceptos más difíciles para una aplicación de pruebas de carga, ya que por lo general no utilizan el concepto de trabajar con lo que sucede en los nodos individuales del sistema, limitándose únicamente a reconocer un período de tiempo durante el cual no hay actividad de la red. Medir el tiempo de visualización generalmente requiere incluir casos de prueba funcionales en las pruebas comparativas, pero la mayoría de las aplicaciones comparativas no incluyen esta capacidad.
Es muy importante detallar los requisitos de desempeño y documentarlos en algún tipo de plan de prueba de desempeño. Idealmente, esto se hace durante la fase de desarrollo de requisitos del desarrollo del sistema, antes de que se elaboren los detalles del diseño. Véase ingeniería de rendimiento .
Sin embargo , las pruebas de rendimiento a menudo no se llevan a cabo de acuerdo con la especificación, ya que no existe una comprensión fija del tiempo de respuesta máximo para un número determinado de usuarios. Las pruebas de rendimiento se utilizan a menudo como parte del proceso de creación de perfiles de rendimiento. Su idea es encontrar un "eslabón débil", esa parte del sistema, al optimizar el tiempo de reacción del cual puede mejorar el rendimiento general del sistema. Determinar qué parte del sistema se encuentra en esta ruta crítica es a veces una tarea muy difícil, por lo que algunas aplicaciones de prueba incluyen (o se pueden agregar a través de complementos) herramientas que se ejecutan en el servidor (agentes) que monitorean el tiempo de ejecución de las transacciones, el acceso a la base de datos tiempo, gastos generales de la red y otros indicadores de la parte del servidor del sistema que se pueden analizar junto con otras estadísticas de rendimiento.
Las pruebas comparativas se pueden realizar en una red de área amplia e incluso en ubicaciones geográficamente remotas, dado que la velocidad de Internet varía según la ubicación. También se puede realizar de forma local, pero en este caso es necesario configurar los routers de la red de forma que exista un retraso que está presente en todas las redes públicas. La carga aplicada al sistema debe coincidir con el estado actual de las cosas. Entonces, por ejemplo, si el 50% de los usuarios del sistema usan un canal de red de 56K para acceder al sistema y la otra mitad usa un canal óptico, entonces las computadoras que crean una carga de prueba en el sistema deben usar las mismas conexiones (ideal) o emular los retrasos de las conexiones de red anteriores, siguiendo perfiles de usuario dados.
Los requisitos de desempeño deben abordar, como mínimo, las siguientes preguntas:
Hay un malentendido común de que las herramientas de prueba de carga del sistema son las mismas herramientas de grabación y reproducción que las herramientas para automatizar las pruebas de regresión . Las herramientas de prueba de carga funcionan con un protocolo, mientras que las herramientas para automatizar las pruebas de regresión funcionan tanto con un protocolo como con objetos GUI.
| Ejemplo 1:
Hay un navegador de Internet estándar que realiza la función de seguir el enlace especificado cuando se presiona un botón. En este caso, para automatizar las pruebas de regresión, debe escribir una secuencia de comandos que envíe un clic del mouse y un clic de botón al navegador, mientras que para crear una secuencia de comandos para las pruebas de carga, debe escribir una transmisión de hipervínculo desde el navegador a varios usuarios. , incluyendo un nombre de usuario y contraseña únicos para cada uno de ellos. |
Hay varias herramientas para detectar e investigar problemas en varias partes del sistema. Todos los nodos del sistema se pueden clasificar de la siguiente manera:
También cabe destacar la aparición de aplicaciones interempresariales (B2B) en red que utilizan un acuerdo de nivel de servicio (o SLA, Service Level Agreement). La creciente popularidad de las aplicaciones B2B ha llevado a que cada vez más aplicaciones se muevan hacia una arquitectura orientada a servicios , en la que el intercambio de información se produce sin la participación de los navegadores web. Un ejemplo de tal interacción sería una agencia de viajes que solicita información sobre un vuelo específico entre San Petersburgo y Omsk, mientras que la aerolínea debe proporcionar una respuesta en 5 segundos. A menudo, la violación del acuerdo SLA amenaza con una gran multa.
Las herramientas de prueba de carga más populares se enumeran a continuación.
| EN | Nombre del fabricante | Comentarios |
|---|---|---|
| OpenSTA | 'Arquitectura de prueba de sistema abierto' | Software gratuito para pruebas de carga/estrés, con licencia GNU GPL. Utiliza una arquitectura de aplicaciones distribuidas basada en CORBA . Hay disponible una versión de Windows, aunque existen problemas de compatibilidad con Windows Vista. El soporte finalizó en 2007. |
| Probador de rendimiento racional de IBM | IBM | Basado en el entorno de desarrollo Eclipse , software que permite crear una gran carga y medir el tiempo de respuesta para aplicaciones con arquitectura cliente-servidor. Requiere licencia. |
| jmetro | Abra el proyecto Apache Jakarta | Kit de herramientas multiplataforma basado en Java que le permite realizar pruebas de carga utilizando conexiones JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Te permite crear una gran cantidad de solicitudes desde diferentes computadoras y controlar el proceso desde una de ellas. |
| HP LoadRunner | Micro Focus (comprado a HP) | Una herramienta de prueba de carga desarrollada originalmente para emular el trabajo de una gran cantidad de usuarios simultáneos. También se puede utilizar para unidad o integración . |
| Silk_Performer | Microenfoque | |
| Prueba de carga de Visual Studio | microsoft | Visual Studio proporciona una herramienta de prueba de rendimiento que incluye pruebas de carga/unidad |
Uno de los resultados obtenidos durante las pruebas de carga y utilizado para análisis posteriores son los indicadores de rendimiento de la aplicación. Los principales se discuten a continuación.
1. Consumo de recursos de CPU (CPU, %)Una métrica que muestra cuánto tiempo fuera de un intervalo definido determinado pasó el procesador en los cálculos para el proceso seleccionado. En los sistemas modernos, un factor importante es la capacidad de un proceso para ejecutarse en varios subprocesos, de modo que el procesador pueda realizar cálculos en paralelo. El análisis del historial de consumo de recursos de la CPU puede explicar el impacto en el rendimiento general del sistema de los flujos de datos procesados, la configuración del sistema operativo y de la aplicación, la computación de subprocesos múltiples y otros factores.
2. Uso de memoria (Mb)Una métrica que muestra la cantidad de memoria utilizada por la aplicación. La memoria usada se puede dividir en tres categorías:
Cuando la aplicación se está ejecutando, la memoria se llena de referencias a objetos que, si no se utilizan, pueden borrarse mediante un proceso automático especial llamado "recolector de basura" (Eng. Garbage Collector ). El tiempo que tarda el procesador en limpiar la memoria de esta manera puede ser significativo cuando el proceso ha consumido toda la memoria disponible (en Java, el llamado "GC completo persistente") o cuando al proceso se le han asignado grandes cantidades de memoria que necesita ser limpiado. Durante el tiempo que se tarda en limpiar la memoria, se puede bloquear el acceso de un proceso a las páginas de la memoria asignada, lo que puede afectar el tiempo de procesamiento final de ese proceso.
3. Consumo de recursos de redEsta métrica no está directamente relacionada con el rendimiento de la aplicación, pero sus indicadores pueden indicar los límites de rendimiento del sistema en su conjunto.
| Ejemplo 2:
La aplicación del servidor, al procesar la solicitud del usuario, le devuelve un flujo de video utilizando un canal de red de 2 megabits. El requisito establece que el servidor debe procesar 5 solicitudes de usuario al mismo tiempo. Las pruebas de carga mostraron que el servidor puede proporcionar datos de manera efectiva a solo 4 usuarios al mismo tiempo, ya que la transmisión multimedia tiene una tasa de bits de 500 kilobits. Es obvio que la provisión de este flujo a 5 usuarios al mismo tiempo es imposible debido al exceso de ancho de banda del canal de red, lo que significa que el sistema no cumple con los requisitos de rendimiento especificados, aunque su consumo de recursos de procesador y memoria puede abajo. |
Trabajar con el subsistema del disco puede afectar significativamente el rendimiento del sistema, por lo que la recopilación de estadísticas sobre el trabajo con el disco puede ayudar a identificar cuellos de botella en esta área. Una gran cantidad de lecturas o escrituras puede hacer que el procesador quede inactivo mientras espera que los datos se procesen desde el disco y, como resultado, aumente el consumo de CPU y aumente el tiempo de respuesta.
5. Tiempo de respuesta de la solicitud (ms)El tiempo de ejecución de una solicitud por parte de una aplicación sigue siendo uno de los indicadores más importantes del rendimiento de un sistema o aplicación. Este tiempo se puede medir en el lado del servidor como una medida del tiempo que tarda el lado del servidor en procesar una solicitud; y en el cliente, como indicador del tiempo total requerido para la serialización/deserialización , reenvío y procesamiento de la solicitud. Cabe señalar que no todas las aplicaciones de pruebas de rendimiento pueden medir ambos tiempos.
Algunos de los mitos más comunes se enumeran a continuación.
1. Se realizan pruebas de rendimiento para romper el sistema. Las pruebas de estrés se realizan para encontrar el punto crítico de la fuerza del sistema. En otros casos, se realizan las pruebas de carga habituales para investigar el comportamiento del sistema bajo la carga esperada. Según otros requisitos, es posible que se requieran pruebas de estabilidad, pruebas de configuración o pruebas de esfuerzo.
2. Las pruebas comparativas solo se deben realizar después de las pruebas comparativas de integración. Aunque esta es prácticamente la norma en la industria del desarrollo de software, las pruebas de rendimiento también se pueden realizar en la etapa inicial del desarrollo de la aplicación. Este enfoque se denomina Pruebas de rendimiento temprano . Promueve un enfoque holístico del desarrollo que considera los parámetros de rendimiento y, por lo tanto, reduce no solo la posibilidad de encontrar un problema de rendimiento justo antes del lanzamiento, sino también el costo de solucionar dichos problemas.
3. Las pruebas de rendimiento consisten únicamente en escribir scripts y cualquier cambio en la aplicación da como resultado una pequeña refactorización de estos scripts. Las pruebas de rendimiento en sí mismas son una rama en crecimiento de la industria del software . La secuencia de comandos, si bien es importante, es solo una parte de las pruebas de rendimiento. La tarea más difícil para un probador es determinar las pruebas que se llevarán a cabo y analizar varias métricas de rendimiento para identificar los cuellos de botella del sistema.
La otra parte del mito sobre los pequeños cambios en los scripts tampoco es cierta, ya que cualquier cambio en la interfaz de usuario, especialmente en el protocolo de red, conducirá a una reescritura completa de los scripts desde el principio. El problema se vuelve más notorio cuando se utilizan protocolos como Web Services, Siebel, Citrix, SAP.
4. Las pruebas de estrés, las pruebas de carga y las pruebas de estabilidad son lo mismo. Uno de los mitos más comunes asociados con un malentendido de la terminología. Las pruebas de estrés y las pruebas de carga son dos tipos diferentes de actividades, lo que se denomina el término general de pruebas de rendimiento , y resuelven problemas diferentes. La tarea de las pruebas de estrés es encontrar el punto crítico de la resistencia del sistema bajo cargas significativamente superiores a las esperadas o desproporcionadas; La tarea de las pruebas de carga es verificar que el sistema cumpla con los requisitos bajo la carga esperada.
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|