Parametrización, Funciones, Transacciones en LoadRunner

Un guión grabado puede simular un usuario virtual; sin embargo, una simple grabación puede no ser suficiente para replicar el “comportamiento real del usuario”.

Cuando se graba un guión, cubre el flujo único y directo de la aplicación en cuestión. Mientras que un usuario real puede realizar múltiples iteraciones de cualquier proceso antes de cerrar sesión. El retraso entre hacer clic en los botones (tiempo de pensamiento) variará de persona a persona. Lo más probable es que algunos usuarios reales accedan a su aplicación a través de DSL y otros accedan a ella a través de un acceso telefónico. Entonces, para tener una sensación real del usuario final, necesitamos mejorar nuestros scripts para que coincidan exactamente, o al menos tengan un comportamiento muy cercano al de los usuarios reales.

Lo anterior es la consideración más importante a la hora de realizar “Test de rendimiento”, pero hay más en un VU Script. ¿Cómo medirá la cantidad precisa de tiempo que tarda un VUser cuando SUL se somete a una prueba de rendimiento? ¿Cómo sabría si el VUser pasó o falló en cierto punto? ¿Cuál es la causa detrás del error, si algún proceso de backend falló o los recursos del servidor fueron limitados?

Necesitamos mejorar nuestro guión para ayudar a responder todas las preguntas anteriores.

Uso de transacciones

Las transacciones son mecanismos para medir el tiempo de respuesta del servidor ante cualquier operación. En palabras simples, el uso de “Transacción” ayuda a medir el tiempo que tarda el sistema en responder a una solicitud en particular. Puede ser algo tan pequeño como hacer clic en un botón o una llamada AJAX al perder el foco del cuadro de texto.

Aplicar transacciones es sencillo. Simplemente escriba una línea de código antes de realizar la solicitud al servidor y cierre la transacción cuando finalice la solicitud. LoadRunner requiere sólo una cadena como nombre de transacción.

Para abrir una transacción, use esta línea de código:

lr_start_transaction(“Transaction Name”);

Para cerrar la transacción, use esta línea de código:

lr_end_transaction(“Transaction Name”, <status>);

El le dice a LoadRunner si esta transacción en particular fue exitosa o no. Los posibles parámetros podrían ser:

• LR_AUTO
• LR_PASS
• LR_FAIL

Ejemplo:

lr_end_transaction(“Mi_inicio de sesión”, LR_AUTO);
lr_end_transaction(“001_Nombre del panel de apertura”, LR_PASS);
lr_end_transaction(“Nombre de transacción_flujo_de_negocio”, LR_FAIL);

Puntos a tener en cuenta:

• No olvide que está trabajando con "C" y que es un lenguaje que distingue entre mayúsculas y minúsculas.
• El carácter de punto (.) no está permitido en el nombre de la transacción, aunque puede utilizar espacios y guiones bajos.
• Si ha ramificado bien su código y ha añadido puntos de control para verificar la respuesta del servidor, puede utilizar un control de errores personalizado, como LR_PASS o LR_FAIL. De lo contrario, puede utilizar LR_AUTO y LoadRunner controlará automáticamente los errores del servidor (HTTP 500, 400, etc.).
• Al aplicar transacciones, asegúrese de que no haya tiempo_pensar estado de cuenta intercalado o, de lo contrario, su transacción siempre incluirá ese período.
• Dado que LoadRunner requiere una cadena constante como nombre de transacción, un problema común al aplicar la transacción es la falta de coincidencia de la cadena. Si proporciona un nombre diferente al abrir y cerrar una transacción, cometerá al menos 2 errores. Dado que la transacción que abrió nunca se cerró, LoadRunner generará un error. Además, la transacción que intenta cerrar nunca se abrió, por lo que se produjo un error.
• ¿Puedes usar tu inteligencia y responderte a ti mismo cuál de los errores anteriores se informará primero? Para validar tu respuesta, ¿por qué no cometer tu propio error? Si respondió correctamente, va por buen camino. Si respondiste mal, debes concentrarte.
• Dado que LoadRunner se encarga automáticamente de la sincronización de solicitudes y respuestas, no tendrá que preocuparse por la respuesta al aplicar transacciones.

Comprender el tiempo para pensar, los puntos de encuentro y los comentarios

Puntos de encuentro

Rendezvous Points significa "puntos de encuentro". Es solo una línea de declaración que le dice a LoadRunner que introduzca concurrencia. Inserta puntos de encuentro en los scripts de VUser para emular una gran carga de usuarios en el servidor.

Los puntos de encuentro indican al VUser que espere durante la ejecución de la prueba a que varios VUser lleguen a un punto determinado, para que puedan realizar una tarea al mismo tiempo. Por ejemplo, para emular la carga máxima en el servidor del banco, puede insertar un punto de encuentro que indique a 100 VUser que depositen efectivo en sus cuentas al mismo tiempo. Esto se puede lograr fácilmente mediante el encuentro.

Si los puntos de encuentro no están ubicados correctamente, el VUser accederá a diferentes partes de la aplicación, incluso para el mismo script. Esto se debe a que cada VUser obtiene un tiempo de respuesta diferente y, por lo tanto, pocos usuarios se quedan atrás.

Sintaxis: lr_rendesvous(“Nombre lógico”);

Mejores Prácticas:

• Anteponga un punto de encuentro con “rdv_” para mejorar la legibilidad del código; p.ej. “rdv_Iniciar sesión”
• Elimine cualquier declaración de tiempo de reflexión inmediata
• Aplicar puntos de encuentro en una vista de guión (después de grabar)

Comentarios

Agregue comentarios para describir una actividad, un fragmento de código o una línea de código. Los comentarios ayudan a que el código sea comprensible para cualquiera que haga referencia a él en el futuro. Proporcionan información sobre operaciones específicas y separan dos secciones para distinguirlas.

Puedes agregar comentarios

• Mientras graba (usando la herramienta)
• Después de grabar (escribir directamente en código)

Práctica mejorada: Marque cualquier comentario en la parte superior de cada archivo de script

Insertar funciones a través del menú

Si bien puedes escribir líneas de código simples directamente, es posible que necesites una pista para recordar una función. También puedes usar Steps Toolbox (conocida como Insertar función antes de la versión 12) para buscar e insertar cualquier función directamente en tu script.

Puede encontrar la barra de herramientas de Pasos en Ver à Caja de herramientas de Pasos.

Esto abrirá una ventana lateral, mira la instantánea:

¿Qué es la parametrización?

A parámetro en VUGen es un contenedor que contiene un valor registrado que se reemplaza para varios usuarios.

Durante la ejecución del script (en VUGen o Controller), el valor de una fuente externa (como .txt, XML o base de datos) sustituye el valor anterior del parámetro.

La parametrización es útil para enviar valores dinámicos (o únicos) al servidor, por ejemplo; Se desea que un proceso de negocio ejecute 10 iteraciones pero elija un nombre de usuario único cada vez.

También ayuda a estimular un comportamiento real en el sistema sujeto. Eche un vistazo al siguiente ejemplo:

Ejemplos de problemas:

El proceso de negocio funciona sólo para la fecha actual que proviene del servidor, por lo que no se puede pasar como una solicitud codificada.

A veces, la aplicación cliente pasa una ID única al servidor (por ejemplo, session_id) para que el proceso continúe (incluso para un solo usuario). En tal caso, la parametrización ayuda.

A menudo, la aplicación cliente mantiene un caché de los datos que se envían hacia y desde el servidor. Como resultado, el servidor no recibe un comportamiento real del usuario (en caso de que el servidor ejecute un algoritmo diferente según los criterios de búsqueda). Si bien el script VUser se ejecutará correctamente, las estadísticas de rendimiento obtenidas no serán significativas. El uso de diferentes datos a través de la parametrización ayuda a emular la actividad del lado del servidor (procedimientos, etc.) y ejercita el sistema.

Es posible que una fecha codificada en el VUser durante la grabación ya no sea válida cuando esa fecha haya pasado. La parametrización de la fecha permite que la ejecución de VUser se realice correctamente reemplazando la fecha codificada. Estos campos o solicitudes son los candidatos adecuados para la parametrización.

Haga clic en aquí si el video no es accesible

Configuración de tiempo de ejecución y su impacto en la simulación de VU

La configuración de tiempo de ejecución es tan importante como su script VUGen. Con diferentes configuraciones, puede obtener diferentes diseños de prueba. Por este motivo, es posible que obtenga resultados no repetibles si la configuración del tiempo de ejecución no es coherente. Analicemos cada atributo uno por uno.

Ejecutar lógica

Run Logic define la cantidad de veces que se ejecutarán todas las acciones, excepto vuser_init y vuser_end.

Probablemente esto aclare por qué LoadRunner sugiere mantener todo el código de inicio de sesión dentro de vuser_init y la parte de cierre de sesión en vuser_end, ambos exclusivamente.

Si ha creado varias acciones, digamos, iniciar sesión, abrir pantalla, calcular el alquiler, enviar fondos, verificar el saldo y cerrar sesión, se llevará a cabo el siguiente escenario para cada VUser:

Todos los VUsers iniciarán sesión, ejecutarán Abrir pantalla, Calcular alquiler, Enviar fondos, Verificar saldo – luego – nuevamente Abrir pantalla, Calcular alquileres… y así sucesivamente – iterando 10 veces – seguido de cerrar sesión (una vez).

Esta es una configuración poderosa que permite actuar más como un usuario real. Recuerde, un usuario real no inicia y cierra sesión cada vez; normalmente, repite los mismos pasos.

¿Cuántas veces haces clic en “Bandeja de entrada” cuando revisas tu correo electrónico antes de cerrar sesión?

El ritmo del texto

Esto es importante. La mayoría de las personas no pueden comprender la diferencia entre caminar y pensar. La única diferencia es, "El ritmo se refiere al retraso entre iteraciones", mientras que el tiempo de pensamiento es el retraso entre dos pasos cualesquiera.

La configuración recomendada depende del diseño de la prueba. Sin embargo, si busca tener una carga agresiva, considere optar por "Tan pronto como finalice la iteración anterior".

Registros

Un registro (como se entiende generalmente) es una contabilidad de todos los eventos mientras ejecuta LoadRunner. Puede habilitar el registro para saber qué sucede entre su aplicación y su servidor.

LoadRunner ofrece un potente mecanismo de registro que es robusto y escalable por sí solo. Le permite mantener sólo el "Registro estándar" o un registro extendido detallado y configurable o desactivarlo por completo.

Un registro estándar es informativo y fácilmente comprensible. Contiene la cantidad justa de conocimientos que generalmente necesitará para solucionar problemas de sus scripts de VUser.

En el caso del registro extendido, toda la información del registro estándar es un subconjunto. Además, puede tener sustitución de parámetros. Esto le dice al componente LoadRunner que incluya información completa de todos los parámetros (desde la parametrización), incluidas las solicitudes, así como los datos de respuesta.

Si incluye "Datos devueltos por el servidor", su registro será más extenso. Esto incluirá todo el HTML, etiquetas, recursos e información no relacionada con recursos incluidos directamente en el registro. La opción es buena sólo si necesita solucionar problemas serios. Por lo general, esto hace que el archivo de registro sea muy grande y no sea fácilmente comprensible.

Como ya habrás adivinado, si optas por “Advance Trace”, tu archivo de registro será enorme. Debes probarlo. Notarás que la cantidad de tiempo que tarda VUGen también ha aumentado significativamente, aunque esto no tendrá ningún impacto en el tiempo de respuesta de la transacción informado por VUGen. Sin embargo, esta es información muy avanzada y puede ser útil si entiendes la aplicación en cuestión, la comunicación de cliente a servidor entre tu aplicación y el hardware, así como los detalles a nivel de protocolo. Por lo general, esta información está muerta en esencia, ya que requiere un esfuerzo extremo para comprenderla y solucionar los problemas.

Consejos:

• No importa cuánto tiempo demore VUGen cuando el registro está habilitado, no tiene ningún impacto en el tiempo de respuesta de la transacción. HP llama a este fenómeno “tecnología de punta”.
• Deshabilite el registro si no es necesario.
• Deshabilite el registro cuando haya terminado con sus scripts. Incluir scripts con el registro habilitado hará que el controlador se ejecute más lento y reporte mensajes molestos.
• Deshabilitar el registro aumentará la capacidad de la cantidad máxima de usuarios que puede simular desde LoadRunner.
• Considere utilizar "Enviar mensaje sólo cuando se produzca un error": esto silenciará los mensajes de información innecesarios y solo informará los mensajes relacionados con errores.

Piensa en los tiempos

Think Time es simplemente el retraso entre dos pasos.

Think Time ayuda a replicar el comportamiento del usuario, ya que ningún usuario real puede utilizar ninguna aplicación como una máquina (VUGen). VUGen genera tiempo para pensar automáticamente. Aún tienes control total para eliminar, multiplicar o fluctuar la duración del tiempo de reflexión.

Para comprender más, por ejemplo, un usuario puede abrir una pantalla (es decir, una respuesta seguida de una solicitud) y luego proporcionar su nombre de usuario y contraseña antes de presionar Intro. La siguiente interacción de la aplicación con el servidor se producirá cuando haga clic en "Iniciar sesión". El tiempo que tardó un usuario en escribir su nombre de usuario y contraseña es Think Time en LoadRunner.

Si busca simular una carga agresiva en la aplicación, considere desactivar completamente el tiempo de reflexión.

Sin embargo, para simular un comportamiento real, puede "Tiempo de pensamiento aleatorio del usuario" y establecer los porcentajes como desee.

Considere usar Limitar el tiempo para pensar a un período legítimo. Por lo general, 30 segundos es suficiente.

Simulación de velocidad

La simulación de velocidad simplemente se refiere a la capacidad de ancho de banda de cada máquina cliente.

Dado que estamos simulando miles de VUser a través de LoadRunner, es sorprendente lo simple que ha hecho LoadRunner para controlar la simulación de ancho de banda/velocidad de red.

Si sois clientes acceden a vuestra aplicación a más de 128 Kbps, podéis controlarla desde aquí. Podrás simular un "comportamiento real", lo que debería ayudarte a obtener las estadísticas de rendimiento correctas.

La mejor recomendación es configurarlo en Usar ancho de banda máximo. Esto ayudará a ignorar cualquier cuello de botella de rendimiento relacionado con la red y centrarse primero en cualquier problema potencial en la aplicación. Siempre puedes ejecutar la prueba varias veces para ver diferentes comportamientos en diferentes circunstancias.

Emulación de navegador

La experiencia del usuario no depende del navegador que esté utilizando el usuario final. Claramente, esto está más allá del alcance de las medidas de desempeño. Sin embargo, puedes elegir qué navegador deseas emular.

¿Puedes responderte a ti mismo cuándo exactamente será importante que selecciones el navegador correcto en esta configuración?

Utilizará esta configuración si la aplicación en cuestión es una aplicación web y devuelve diferentes respuestas para diferentes navegadores. Por ejemplo, puedes ver diferentes imágenes y contenidos para IE y Firefox etc.

Otra configuración importante es Simular caché del navegador. Si desea medir el tiempo de respuesta cuando la caché está habilitada, marque esta casilla. Si busca la situación más desfavorable, obviamente no debe tenerla en cuenta.

La descarga de recursos que no sean HTML permitirá a LoadRunner descargar cualquier CSS, JS y otros medios enriquecidos. Esto debería permanecer controlado. Sin embargo, si desea eliminar esto del diseño de su prueba de rendimiento, puede desmarcarlo.

apoderado

Lo mejor es eliminar el proxy por completo de tu Entorno de prueba – esto hará que los resultados de la prueba no sean confiables. Sin embargo, es posible que se enfrente a situaciones en las que esto sea inevitable. En tal situación, LoadRunner le facilita la configuración del proxy.

Trabajará (o debería estar trabajando) sin configuración de proxy. Puede obtenerlo desde su navegador predeterminado. Sin embargo, no olvide comprobar qué navegador está configurado como predeterminado y cuál es la configuración de proxy para el navegador predeterminado.

Si está utilizando un proxy y requiere autenticación (o un script), puede hacer clic en el botón Autenticar que abre una nueva ventana. Consulte la siguiente captura de pantalla.

Utilice esta pantalla para proporcionar el nombre de usuario y la contraseña para autenticarse en el servidor proxy. Haga clic en Aceptar para cerrar la pantalla.

Felicidades. Ya ha terminado con la configuración de su script VUGen. No olvide configurarlo para todos sus scripts de VUser.