Herramienta de prueba LoadRunner: componentes y Architectura

¿Qué es LoadRunner?

LoadRunner es una herramienta de pruebas de rendimiento de la que fue pionera Mercury en 1999. LoadRunner fue posteriormente adquirida por HPE en 2006. En 2016, LoadRunner fue adquirida por MicroFocus.

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 cantidad tan grande de protocolos para realizar Test de rendimiento. Los resultados de las pruebas de rendimiento producidos por el software LoadRunner se utilizan como punto de referencia frente a otras herramientas.

Vídeo de LoadRunner

¿Por qué LoadRunner?

LoadRunner No sólo 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 aproximadamente el 85% de participación de mercado en la industria de pruebas de rendimiento.

En términos generales, la herramienta LoadRunner es compatible con RIA (aplicaciones enriquecidas de Internet), Web 2.0 (HTTP/HTML, Ajax, Flex y Silverlight, etc.), dispositivos móviles, SAP, Oracle, MS SQL Servidor, Citrix, RTE, Mail y sobre todo, Windows Enchufe. 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 se ha ganado una reputación desde hace mucho tiempo, ya que a menudo encontrará Los clientes verifican cruzadamente 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 (Administración del ciclo de vida de las aplicaciones) le permiten llevar a cabo sus procesos de prueba de extremo a extremo.

LoadRunner funciona según el principio de simular usuarios virtuales en la aplicación en cuestión. Estos usuarios virtuales, también denominados VUsers, replican las solicitudes de los clientes y esperan una respuesta correspondiente al realizar una transacción.

¿Por qué necesita pruebas de rendimiento?

Se estima que el Pérdida de 4.4 millones de dólares en ingresos se registra anualmente debido al mal rendimiento de la web.

En la era actual de la Web 2.0, los usuarios abandonan un sitio web si no responde en 8 segundos. Imagínese esperando 5 segundos al buscar Google o hacer una solicitud de amistad en Facebook. Las repercusiones del tiempo de inactividad del rendimiento suelen ser más devastadoras de lo que se imaginaba. Tenemos ejemplos como los que afectaron recientemente a la banca en línea de Bank of America, Amazon Servicios Web, Intuit o Blackberry.

Según Dunn & Bradstreet, el 59 % de las empresas de Fortune 500 experimentan aproximadamente 1.6 horas de inactividad cada semana. Si se tiene en cuenta que la empresa promedio de Fortune 500 con un mínimo de 10,000 56 empleados paga 896,000 dólares por hora, la parte laboral de los costos de inactividad para una organización de este tipo ascendería a 46 XNUMX dólares semanales, lo que se traduce en más de XNUMX millones de dólares al año.

Solo un tiempo de inactividad de 5 minutos GoogleSe estima que la adquisición de .com (19 de agosto de 13) le costará al gigante de las búsquedas hasta 545,000 dólares.

Se estima que las empresas perdieron ventas por valor de 1100 dólares por segundo debido a una reciente Amazon Interrupción del servicio web.

Cuando una organización implementa un sistema de software, puede encontrarse con muchas situaciones que pueden generar latencia en el rendimiento. Una serie de factores provocan una desaceleración del rendimiento. Algunos ejemplos pueden incluir:

• Mayor número de registros presentes en la base de datos.
• Aumento del 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 LoadRunner? Archi¿Tectura?

En términos generales, la arquitectura de HP LoadRunner es compleja, pero fácil de entender.

Suponga que le asignan la tarea de comprobar el rendimiento de Amazon.com para 5000 usuarios

En una situación de la vida real, todos 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 Usuario Virtual 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.

Teniendo en cuenta el ejemplo anterior, VUGen puede grabar para simular los siguientes procesos de negocio:

1. Navegando por la página de productos de Amazon.com
2. Finalizar Compra
3. Procesamiento de Negocios
4. Comprobando la página Mi cuenta

Control

Una vez finalizado un script VUser, Controller es uno de los componentes principales de LoadRunner que controla la simulación de carga gestionando, por ejemplo:

• Cuántos VUsers simular en cada proceso de negocio o grupo de VUser
• Comportamiento de los VUsers (aumento, disminución, naturaleza simultánea o concurrente, etc.)
• Escenario de naturaleza de carga, p. Vida real u orientada a objetivos o verificación de SLA
• Qué inyectores usar, cuántos VUsers contra cada inyector
• Cotejar resultados periódicamente
• IP Spoofing
• Error al reportar
• Informes de transacciones, etc.

Tomando una analogía de nuestro controlador de ejemplo, agregaremos el siguiente parámetro al script VUGen

1) 3500 usuarios son Navegando por la página de productos de Amazon.com

2) 750 usuarios están en Finalizar Compra

3) 500 usuarios son realizar procesamiento de pagos

4) 250 usuarios son Verificar la página Mi cuenta SÓLO después de que 500 usuarios hayan realizado el procesamiento de pagos

Son posibles escenarios aún más complejos

1. Inicie 5 VUsers cada 2 segundos hasta una carga de 3500 VUsers (navegación Amazon página del producto).
2. Iterar durante 30 minutos
3. Suspender la iteración para 25 VUsers
4. Reiniciar 20 VUSers
5. Inicie 2 usuarios (en Pago, Procesamiento de pagos, Página Mis cuentas) cada segundo.
6. Se generarán 2500 VUsers en la Máquina A
7. Se generarán 2500 VUsers en la Máquina B

Agentes Máquina/Carga Generators/Inyectores

El controlador HP LoadRunner es responsable de simular miles de VUsers (estos VUsers consumen recursos de hardware, por ejemplo, procesador y memoria), por lo que impone un límite a la máquina que los simula. Además, Controller simula estos VUsers desde la misma máquina (donde reside el Controlador) y, por lo tanto, los resultados pueden no ser precisos. Para abordar esta preocupación, todos los VUsers están distribuidos en varias máquinas, llamadas Carga Generators o cargar inyectores.

Como práctica general, el controlador reside en una máquina diferente y la carga se simula desde otras máquinas. Dependiendo del 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 necesitarán 4 máquinas con 4 GB de RAM cada una para simular una carga de 10,000 XNUMX VUsers.

Tomando analogía de nuestra Amazon Por ejemplo, la salida de este componente será

Análisis

Una vez ejecutados los escenarios de carga, el rol de “Análisis”Entran los componentes de LoadRunner.

Durante la ejecución, el Controlador crea un volcado de resultados en formato 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 un Microsoft acceder a la base de datos, denominada, salida.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, ayuda 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 1 GBps, mientras que el tráfico de datos excede esta capacidad, lo que provoca que los usuarios posteriores sufran. Para determinar que el sistema satisface dichas necesidades, el ingeniero de rendimiento debe analizar el comportamiento de la aplicación con una carga anormal. A continuación se muestra un gráfico que LoadRunner genera para obtener ancho de banda.

Cómo hacer pruebas de rendimiento

La hoja de ruta de pruebas de rendimiento se puede dividir en términos generales en 5 pasos:

• Planificación de la prueba de carga
• Crear secuencias de comandos 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 pruebas de rendimiento

Paso 1) Planificación de la prueba de carga

La planificación de pruebas de rendimiento es diferente de la planificación de una SIT (Pruebas de integración de sistemas) or UAT (Pruebas de aceptación del usuario). La planificación se puede dividir en pequeñas etapas como se describe a continuación:

Reúne a tu equipo

Al comenzar con LoadRunner Testing, es mejor documentar quién participará en la actividad de cada equipo involucrado durante el proceso.

Director del proyecto:

Nomine al director del proyecto que será el propietario de esta actividad y actuará como persona clave para la escalada.

Experto en Funciones/Analista de Negocios:

Proporcionar análisis de uso de SUL y proporciona experiencia en la funcionalidad empresarial del sitio web/SUL

Experto en pruebas de rendimiento:

Crea pruebas de rendimiento automatizadas y ejecuta escenarios de carga.

Sistema Architectar:

Proporciona plano del SUL.

Desarrollador Web y Pyme:

• Mantiene el sitio web y proporciona aspectos de seguimiento.
• Desarrolla sitio web y corrige errores.

Administrador de sistema:

• Mantiene los servidores involucrados durante todo un proyecto de prueba.

Describa las aplicaciones y los procesos de negocio involucrados:

Consolidación Exitosa Prueba de carga requiere que planee llevar a cabo cierto proceso comercial. Un proceso de negocio consta de pasos claramente definidos que cumplen con las transacciones comerciales deseadas, para lograr sus objetivos de prueba de carga.

Se puede preparar una métrica de requisitos para generar 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) a una hora determinada. Podemos extract el número máximo de usuarios conectados a un proceso de negocio en cualquier hora del día, que se calcula en las columnas de la derecha.

Asimismo, 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 datos 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 datos de prueba para las pruebas de rendimiento. A veces, un proceso de negocio particular consume un conjunto de datos y produce un conjunto de datos diferente. Tome el siguiente ejemplo:

• Un usuario 'A' crea una cuenta financieratracy lo envía para su revisión.
• Otro usuario 'B' aprueba 200 contraces un día creado por el usuario 'A'
• Otro usuario 'C' paga alrededor de 150 contraces un día aprobado por el usuario 'B'

En esta situación, el usuario B necesita tener 200 contracts 'creado' en el sistema. Además, el usuario C necesita 150 contracts como “aprobado” para simular una carga de 150 usuarios.

Esto implica que debes crear al menos 200+150= 350 contracTs

Después de eso, apruebe 150 contracts para servir como datos de prueba para el usuario C: los 200 restantes contracts servirá como datos de prueba para el usuario B.

Monitores de esquema

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 del SUL (sistema bajo carga).

Registre todos los factores y configure monitores para poder evaluarlos. 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.)
• Servidor DB (tamaño PGA y SGA en caso de Oracle y servidor MSSQL, SP, etc.)
• Utilización del ancho de banda de la red
• NIC interna y externa en caso de clusterización
• Balanceador de carga (y que distribuye la carga de manera uniforme en todos los nodos de los clústeres)
• Datos flux (Calcular la cantidad de datos que se transfieren entre el cliente y el servidor, y luego calcular si la capacidad de la tarjeta de red es suficiente para simular un número X de usuarios).

Paso 2) Crear scripts VUGen

El siguiente paso después de la planificación es crear Guiones de VUser.

Paso 3) Creación de escenarios

El siguiente paso es crear su escenario de carga.

Paso 4) Ejecución del escenario

La ejecución del escenario es donde se emula la carga de usuarios en el servidor al indicar a varios VUsers que realicen tareas simultáneamente.

Puede establecer el nivel de una carga aumentando y disminuyendo la cantidad de VUsers que realizan tareas al mismo tiempo.

Esta ejecución puede provocar que el servidor sufra estrés y se comporte de manera 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.

Paso 5) 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 un análisis detallado. La herramienta "Análisis de HP" genera varios gráficos que ayudan a identificar las causas principales de un retraso en el rendimiento del sistema, así como de una falla del sistema.

Algunas de las gráficas obtenidas incluyen:

• Hora del primer buffer
• Tiempo de respuesta de la transacción
• Tiempo promedio de respuesta de transacción
• Golpes por segundo
• Windows Recursos
• Estadísticas de errores
• Resumen de Transacciones

Preguntas Frecuentes