¿Qué es LoadRunner?
LoadRunner es una herramienta de prueba de rendimiento que fue pionera en Mercury en 1999. LoadRunner fue posteriormente adquirida por HPE en 2006. En 2016, MicroFocus adquirió LoadRunner.
LoadRunner admite varias herramientas de desarrollo, tecnologías y protocolos de comunicación. De hecho, esta es la única herramienta en el mercado que admite una gran cantidad de protocolos para realizar pruebas de rendimiento. Los resultados de la prueba de rendimiento producidos por el software LoadRunner se utilizan como referencia frente a otras herramientas
En este tutorial, aprenderá:
- ¿Por qué LoadRunner?
- ¿Por qué necesita pruebas de rendimiento?
- ¿Qué es la arquitectura LoadRunner?
- Hoja de ruta de pruebas de rendimiento: pasos detallados
- Preguntas más frecuentes
¿Por qué LoadRunner?
LoadRunner no solo es una herramienta pionera en pruebas de rendimiento, sino que sigue siendo líder del mercado en el paradigma de pruebas de rendimiento. En una evaluación reciente, LoadRunner tiene una participación de mercado de aproximadamente el 85% en la industria de pruebas de rendimiento.
En términos generales, la herramienta LoadRunner es compatible con RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex y Silverlight, etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail y, sobre todo, Windows Socket. No existe ninguna herramienta de la competencia en el mercado que pueda ofrecer una variedad tan amplia de protocolos en una sola herramienta.
Lo que es más convincente para elegir LoadRunner en las pruebas de software es la credibilidad de esta herramienta. La herramienta LoadRunner ha establecido una reputación durante mucho tiempo, ya que a menudo encontrará clientes que verifican sus puntos de referencia de rendimiento utilizando LoadRunner. Encontrará alivio si ya está utilizando LoadRunner para sus necesidades de pruebas de rendimiento.
El software LoadRunner está estrechamente integrado con otras herramientas de HP, como Unified Functional Test (QTP) y ALM (Application Lifecycle Management), lo que le permite realizar sus procesos de prueba de un extremo a otro.
LoadRunner funciona con un principio de simulación de usuarios virtuales en la aplicación en cuestión. Estos usuarios virtuales, también denominados VUsers, replican las solicitudes del cliente y esperan una respuesta correspondiente al pasar una transacción.
¿Por qué necesita pruebas de rendimiento?
Cada año se registra una pérdida estimada de 4.400 millones de ingresos debido al bajo rendimiento web.
En la era actual de la Web 2.0, los usuarios hacen clic si un sitio web no responde en 8 segundos. Imagínese esperando 5 segundos cuando busca en Google o hace una solicitud de amistad en Facebook. Las repercusiones del tiempo de inactividad del rendimiento suelen ser más devastadoras de lo que jamás se hubiera imaginado. Tenemos ejemplos como los que recientemente llegaron a Bank of America Online Banking, Amazon Web Services, Intuit o Blackberry.
Según Dunn & Bradstreet, el 59% de las empresas de Fortune 500 experimentan aproximadamente 1,6 horas de inactividad por semana. Teniendo en cuenta que la compañía Fortune 500 promedio con un mínimo de 10,000 empleados paga $ 56 por hora, la parte laboral de los costos de tiempo de inactividad para dicha organización sería de $ 896,000 por semana, lo que se traduce en más de $ 46 millones por año.
Se estima que solo un tiempo de inactividad de 5 minutos de Google.com (19 de agosto de 2013) le costará al gigante de las búsquedas hasta 545.000 dólares.
Se estima que las empresas perdieron ventas por valor de $ 1100 por segundo debido a una interrupción reciente del servicio web de Amazon.
Cuando una organización implementa un sistema de software, puede encontrar muchos escenarios que posiblemente resulten en una latencia del rendimiento. Varios factores provocan una desaceleración del rendimiento, algunos ejemplos pueden incluir:
- Mayor número de registros presentes en la base de datos
- Mayor número de solicitudes simultáneas realizadas al sistema
- un mayor número de usuarios que acceden al sistema a la vez en comparación con el pasado
¿Qué es la arquitectura LoadRunner?
En términos generales, la arquitectura de HP LoadRunner es compleja, pero fácil de entender.
Suponga que está asignado a comprobar el rendimiento de Amazon.com para 5000 usuarios.
En una situación de la vida real, estos 5000 usuarios no estarán en la página de inicio sino en una sección diferente de los sitios web. ¿Cómo podemos simular de manera diferente?
VUGen:
VUGen o Virtual User Generator es un IDE (entorno de desarrollo integrado) o un editor de codificación enriquecido. VUGen se utiliza para replicar el comportamiento del sistema bajo carga (SUL). VUGen proporciona una función de "grabación" que registra la comunicación hacia y desde el cliente y el servidor en forma de un script codificado, también llamado script VUser.
Entonces, considerando el ejemplo anterior, VUGen puede grabar para simular los siguientes procesos comerciales:
- Navegar por la página de productos de Amazon.com
- Revisa
- Procesando pago
- Comprobación de la página Mi cuenta
Controlador
Una vez que se finaliza un script de VUser, Controller es uno de los componentes principales de LoadRunner que controla la simulación de carga mediante la gestión, por ejemplo:
- Cuántos usuarios virtuales se deben simular en cada proceso empresarial o grupo de usuarios virtuales
- Comportamiento de los usuarios virtuales (aceleración, desaceleración, naturaleza simultánea o concurrente, etc.)
- Escenario de naturaleza de carga, por ejemplo, vida real u orientado a objetivos o verificación de SLA
- Qué inyectores usar, cuántos VUsers contra cada inyector
- Recopilar resultados periódicamente
- Suplantación de IP
- Error al reportar
- Informes de transacciones, etc.
Tomando una analogía de nuestro controlador de ejemplo, se agregará el siguiente parámetro al script VUGen
1) 3500 usuarios navegan por la página de productos de Amazon.com
2) 750 usuarios están en proceso de pago
3) 500 usuarios están realizando el procesamiento de pagos
4) 250 usuarios están comprobando la página de Mi cuenta SOLAMENTE después de que 500 usuarios hayan realizado el procesamiento de pagos
Son posibles escenarios aún más complejos
- Inicie 5 VUsers cada 2 segundos hasta que se logre una carga de 3500 VUsers (navegando en la página del producto de Amazon).
- Iterar durante 30 minutos
- Suspender la iteración para 25 usuarios virtuales
- Reiniciar 20 usuarios de VUS
- Inicie 2 usuarios (en Pago, Procesamiento de pagos, Página Mis cuentas) cada segundo.
- Se generarán 2500 VUsers en la Máquina A
- Se generarán 2500 VUsers en la Máquina B
Agentes Máquina / Generadores de carga / Inyectores
HP LoadRunner Controller es responsable de simular miles de VUsers (estos VUsers consumen recursos de hardware, por ejemplo, procesador y memoria), por lo que ponen un límite a la máquina que los está simulando. Además, Controller simula estos VUsers desde la misma máquina (donde reside Controller) y, por tanto, los resultados pueden no ser precisos. Para abordar esta preocupación, todos los VUsers se distribuyen en varias máquinas, denominadas generadores de carga o inyectores de carga.
Como práctica general, el controlador reside en una máquina diferente y la carga se simula desde otras máquinas. Según el protocolo de los scripts de VUser y las especificaciones de la máquina, es posible que se requieran varios inyectores de carga para una simulación completa. Por ejemplo, los VUsers para un script HTTP requerirán de 2 a 4 MB por VUser para la simulación, por lo tanto, se requerirán 4 máquinas con 4 GB de RAM cada una para simular una carga de 10,000 VUsers.
Tomando la analogía de nuestro ejemplo de Amazon, la salida de este componente será
Análisis:
Una vez que se han ejecutado los escenarios de carga, entra en juego la función de los componentes de " análisis " de LoadRunner.
Durante la ejecución, Controller crea un volcado de resultados en forma sin procesar y contiene información como, qué versión de LoadRunner creó este volcado de resultados y cuáles fueron las configuraciones.
Todos los errores y excepciones se registran en una base de datos de acceso de Microsoft, denominada output.mdb. El componente "Análisis" lee este archivo de base de datos para realizar varios tipos de análisis y genera gráficos.
Estos gráficos muestran varias tendencias para comprender el razonamiento detrás de los errores y fallas bajo carga; por lo tanto, ayude a determinar si se requiere optimización en SUL, Server (por ejemplo, JBoss, Oracle) o infraestructura.
A continuación se muestra un ejemplo en el que el ancho de banda podría estar creando un cuello de botella. Digamos que el servidor web tiene una capacidad de 1GBps mientras que el tráfico de datos excede esta capacidad, lo que hace que los usuarios posteriores sufran. Para determinar que el sistema satisface tales necesidades, Performance Engineer necesita analizar el comportamiento de la aplicación con una carga anormal. A continuación se muestra un gráfico que LoadRunner genera para obtener el ancho de banda.
Hoja de ruta de pruebas de rendimiento: pasos detallados
La hoja de ruta de pruebas de rendimiento se puede dividir en cinco pasos:
- Planificación de la prueba de carga
- Crear secuencias de comandos de VUGen
- Creación de escenarios
- Ejecución del escenario
- Análisis de resultados (seguido de ajustes del sistema)
Ahora que ha instalado LoadRunner, comprendamos los pasos involucrados en el proceso uno por uno.
Pasos involucrados en el proceso de prueba de rendimiento
Planificación de la prueba de carga
La planificación de las pruebas de rendimiento es diferente a la planificación de una SIT (Prueba de integración del sistema) o UAT (Prueba de aceptación del usuario). La planificación se puede dividir en pequeñas etapas como se describe a continuación:
Reúna a su equipo
Al comenzar con LoadRunner Testing, es mejor documentar quién participará en la actividad de cada equipo involucrado durante el proceso.
Gerente de proyecto:
Designe al director del proyecto que será el propietario de esta actividad y actuará como persona de contacto para la escalada.
Experto en funciones / Analista de negocios:
Proporcionar análisis de uso de SUL y proporcionar experiencia en la funcionalidad comercial del sitio web / SUL
Experto en pruebas de rendimiento:
Crea las pruebas de rendimiento automatizadas y ejecuta escenarios de carga.
Sistema arquitecto:
Proporciona un plano del SUL
Desarrollador web y PYME:
- Mantiene el sitio web y proporciona aspectos de seguimiento
- Desarrolla un sitio web y corrige errores
Administrador de sistema:
- Mantiene los servidores involucrados a lo largo de un proyecto de prueba
Describa las aplicaciones y los procesos comerciales involucrados:
Las pruebas de carga exitosas requieren que planee llevar a cabo ciertos procesos comerciales. Un proceso empresarial consta de pasos claramente definidos de conformidad con las transacciones comerciales deseadas, a fin de lograr sus objetivos de prueba de carga.
Se puede preparar una métrica de requisitos para provocar la carga de usuarios en el sistema. A continuación se muestra un ejemplo de un sistema de asistencia en una empresa:
En el ejemplo anterior, las cifras mencionan el número de usuarios conectados a la aplicación (SUL) en una hora determinada. Podemos extraer el número máximo de usuarios conectados a un proceso empresarial a cualquier hora del día, que se calcula en las columnas de la derecha.
Del mismo modo, podemos concluir el número total de usuarios conectados a la aplicación (SUL) a cualquier hora del día. Esto se calcula en la última fila.
Los 2 hechos anteriores combinados nos dan el número total de usuarios con los que necesitamos probar el rendimiento del sistema.
Definir procedimientos de gestión de datos de prueba
Las estadísticas y observaciones extraídas de las pruebas de rendimiento están muy influenciadas por numerosos factores, como se informó anteriormente. Es de vital importancia preparar los datos de prueba para las pruebas de rendimiento. A veces, un proceso empresarial en particular consume un conjunto de datos y produce un conjunto de datos diferente. Tome el siguiente ejemplo:
- Un usuario 'A' crea un contrato financiero y lo envía para su revisión.
- Otro usuario 'B' aprueba 200 contratos por día creados por el usuario 'A'
- Otro usuario 'C' paga alrededor de 150 contratos al día aprobados por el usuario 'B'
En esta situación, el usuario B necesita tener 200 contratos "creados" en el sistema. Además, el usuario C necesita 150 contratos como "aprobados" para simular una carga de 150 usuarios.
Esto significa implícitamente que debe crear al menos 200 + 150 = 350 contratos.
Después de eso, apruebe 150 contratos para que sirvan como datos de prueba para el usuario C; los 200 contratos restantes servirán como datos de prueba para el usuario B.
Monitores de contorno
Especule todos y cada uno de los factores que podrían afectar el rendimiento de un sistema. Por ejemplo, tener hardware reducido tendrá un impacto potencial en el rendimiento de SUL (System Under Load).
Reclute todos los factores y configure monitores para que pueda medirlos. A continuación se muestran algunos ejemplos:
- Procesador (para servidor web, servidor de aplicaciones, servidor de base de datos e inyectores)
- RAM (para servidor web, servidor de aplicaciones, servidor de base de datos e inyectores)
- Servidor web / de aplicaciones (por ejemplo, IIS, JBoss, Jaguar Server, Tomcat, etc.)
- DB Server (tamaño PGA y SGA en caso de Oracle y MSSQL Server, SP, etc.)
- Utilización del ancho de banda de la red
- NIC interna y externa en caso de agrupación
- Load Balancer (y que distribuye la carga de manera uniforme en todos los nodos de los clústeres)
- Flujo de datos (calcule cuántos datos se mueven hacia y desde el cliente y el servidor; luego, calcule si la capacidad de la NIC es suficiente para simular un número X de usuarios)
Crear secuencias de comandos de VUGen
El siguiente paso después de la planificación es crear scripts de VUser.
Creación de escenarios
El siguiente paso es crear su escenario de carga
Ejecución del escenario
La ejecución del escenario es donde se emula la carga del usuario en el servidor al instruir a varios usuarios virtuales para que realicen tareas simultáneamente.
Puede establecer el nivel de una carga aumentando y disminuyendo el número de VUsers que realizan tareas al mismo tiempo.
Esta ejecución puede provocar que el servidor se estrese y se comporte de forma anormal. Este es el verdadero propósito de las pruebas de rendimiento. Los resultados obtenidos se utilizan luego para un análisis detallado y la identificación de la causa raíz.
Análisis de resultados (seguido de ajustes del sistema)
Durante la ejecución del escenario, LoadRunner registra el rendimiento de la aplicación bajo diferentes cargas. Las estadísticas extraídas de la ejecución de la prueba se guardan y se realiza el análisis de detalles. La herramienta 'Análisis de HP' genera varios gráficos que ayudan a identificar las causas fundamentales detrás de un retraso en el rendimiento del sistema, así como una falla del sistema.
Algunas de las gráficas obtenidas incluyen:
- Tiempo hasta el primer búfer
- Tiempo de respuesta de la transacción
- Tiempo medio de respuesta de la transacción
- Golpes por segundo
- Recursos de Windows
- Estadísticas de errores
- Resumen de Transacciones
Preguntas más frecuentes
¿Qué aplicaciones deberíamos probar de rendimiento?
Las pruebas de rendimiento siempre se realizan solo para sistemas basados en cliente-servidor. Esto significa que cualquier aplicación que no sea una arquitectura basada en cliente-servidor, no debe requerir pruebas de rendimiento.
Por ejemplo, Microsoft Calculator no está basado en cliente-servidor ni funciona con varios usuarios; por lo tanto, no es candidato para pruebas de rendimiento.
¿Cuál es la diferencia entre las pruebas de rendimiento y la ingeniería de rendimiento?
Es importante comprender la diferencia entre las pruebas de rendimiento y la ingeniería de rendimiento. Un entendimiento se comparte a continuación:
La prueba de desempeño es una disciplina que se ocupa de probar y reportar el desempeño actual de una aplicación de software bajo varios parámetros.
La ingeniería de rendimiento es el proceso mediante el cual se prueba y ajusta el software con la intención de obtener el rendimiento requerido. Este proceso tiene como objetivo optimizar el rasgo de rendimiento de la aplicación más importante, es decir, la experiencia del usuario.
Históricamente, las pruebas y el ajuste han sido ámbitos claramente separados y, a menudo, en competencia. En los últimos años, sin embargo, varios grupos de probadores y desarrolladores han colaborado de forma independiente para crear equipos de ajuste. Debido a que estos equipos han tenido un éxito significativo, el concepto de acoplar las pruebas de rendimiento con el ajuste del rendimiento se ha popularizado y ahora lo llamamos ingeniería de rendimiento.