Un guión grabado puede simular un usuario virtual; sin embargo, una simple grabación puede no ser suficiente para reproducir el "comportamiento real del usuario".
Cuando se graba un guión, cubre el flujo simple y directo de la aplicación del tema. Considerando que, un usuario real puede realizar múltiples iteraciones de cualquier proceso antes de cerrar la sesión. La demora entre hacer clic en los botones (tiempo de pensar) 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 algunos accedan a ella a través de un acceso telefónico. Entonces, para tener la sensación real de usuario final, necesitamos mejorar nuestros scripts para que coincidan exactamente, o al menos muy cerca en el comportamiento de los usuarios reales.
Lo anterior es la consideración más importante al realizar "Pruebas de rendimiento", pero hay más en un VU Script. ¿Cómo evaluará 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 ha pasado o ha fallado en cierto punto? ¿Cuál es la causa del error, si algún proceso de backend falló o los recursos del servidor eran limitados?
Necesitamos mejorar nuestro guión para ayudar a responder todas las preguntas anteriores.
- Usar transacciones
- Comprensión del tiempo de reflexión, los puntos de encuentro y los comentarios
- Insertar funciones a través del menú
- ¿Qué es la parametrización?
- Configuración de tiempo de ejecución y su impacto en la simulación de VU
- Ejecutar lógica
- Estimulación
- Tronco
- Piense en los tiempos
- Simulación de velocidad
- Emulación de navegador
- Apoderado
Usar transacciones
Las transacciones son mecánicas para medir el tiempo de respuesta del servidor para cualquier operación. En palabras simples, el uso de "Transacción" ayuda a medir el tiempo que tarda el sistema en una solicitud en particular. Puede ser tan pequeño como hacer clic en un botón o una llamada AJAX al perder el foco del cuadro de texto.
La aplicación de transacciones es sencilla. Simplemente escriba una línea de código antes de que se realice la solicitud al servidor y cierre la transacción cuando finalice la solicitud. LoadRunner requiere solo una cadena como nombre de transacción.
Para abrir una transacción, use esta línea de código:
lr_start_transaction ("Nombre de la transacción");
Para cerrar la transacción, use esta línea de código:
lr_end_transaction ("Nombre de la transacción", );
El
- LR_AUTO
- LR_PASS
- LR_FAIL
Ejemplo:
lr_end_transaction ("Mi_Inicio", LR_AUTO);
lr_end_transaction (“Nombre de la transacción de flujo de trabajo empresarial”, LR_FAIL);
Puntos a tener en cuenta:
- No olvide que está trabajando con "C" y ese 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 usar espacios y guiones bajos.
- Si ha ramificado bien su código y ha agregado puntos de control para verificar la respuesta del servidor, puede usar el manejo de errores personalizado, como LR_PASS o LR_FAIL. De lo contrario, puede usar LR_AUTO y LoadRunner manejará automáticamente el error del servidor (HTTP 500, 400, etc.)
- Al aplicar transacciones, asegúrese de que no haya una declaración think_time intercalada o, de lo contrario, su transacción siempre incluirá ese período.
- Dado que LoadRunner requiere una cadena constante como nombre de la transacción, un problema común al aplicar la transacción es la falta de coincidencia de la cadena. Si le da un nombre diferente al abrir y cerrar una transacción, tendrá al menos 2 errores. Dado que la transacción que abrió nunca se cerró, LoadRunner producirá un error. Además, la transacción que está intentando 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 su respuesta, ¿por qué no cometer su propio error? Si ha respondido bien, va por buen camino. Si respondió mal, necesita concentrarse.
- 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.
Comprensión del tiempo de reflexión, los puntos de encuentro y los comentarios
Puntos de encuentro
Puntos de encuentro significa "puntos de encuentro". Es solo una línea de declaración que le dice a LoadRunner que introduzca la simultaneidad. Inserta puntos de encuentro en los scripts de VUser para emular una gran carga de usuarios en el servidor.
Los puntos de encuentro indican a VUser que espere durante la ejecución de la prueba a que varios VUser lleguen a un punto determinado, de modo 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 usando Rendezvous.
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:
- Prefije un punto de encuentro con "rdv_" para una mejor legibilidad del código; por ejemplo, "rdv_Login"
- Eliminar cualquier declaración de tiempo de reflexión inmediato
- Aplicar puntos de encuentro en una vista de guión (después de la grabación)
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 se refiera a él en el futuro. Proporcionan información sobre operaciones específicas y separan dos secciones para diferenciarlas.
Puedes agregar comentarios
- Mientras graba (usando la herramienta)
- Después de grabar (escribir directamente en código)
Práctica recomendada: marque los comentarios en la parte superior de cada archivo de secuencia de comandos
Insertar funciones a través del menú
Si bien puede escribir directamente líneas simples de código, es posible que necesite una pista para recuperar una función. También puede usar Steps Toolbox (conocido como Insertar función antes de la versión 12) para buscar e insertar cualquier función directamente en su secuencia de comandos.
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?
Un 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 empresarial ejecute 10 iteraciones pero eligiendo un nombre de usuario único cada vez.
También ayuda a estimular un comportamiento real en el sistema del sujeto. Eche un vistazo al siguiente ejemplo:
Ejemplos de problemas:
El proceso empresarial funciona solo 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 una caché de datos que se envían desde y hacia el servidor. Como resultado, el servidor no recibe un comportamiento de usuario real (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 extraídas 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 que esté 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 tenga éxito al reemplazar la fecha codificada. Estos campos o solicitudes son los candidatos adecuados para la parametrización.
Haga clic 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 tiene tanta importancia como su secuencia de comandos 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 el número 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 en 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 alquiler, Enviar fondos, Verificar saldo y cerrar sesión, entonces, el escenario siguiente se llevará a cabo para cada VUser:
Todos los VUsers iniciarán sesión, ejecutarán la pantalla abierta, calcularán el alquiler, enviarán los fondos, verificarán el saldo y, luego, volverán a abrir la pantalla, calcularán los alquileres ... y así sucesivamente, iterando 10 veces, seguido de cierre de sesión (una vez).
Esta es una configuración poderosa que permite actuar más como un usuario real. Recuerde, un usuario real no se conecta y desconecta cada vez; normalmente, repite los mismos pasos.
¿Cuántas veces hace clic en "bandeja de entrada" cuando revisa su correo electrónico antes de cerrar la sesión?
Estimulación
Esto es importante. La mayoría de las personas son incapaces de entender la diferencia entre el ritmo y el tiempo para pensar. La única diferencia es que "el ritmo se refiere al retraso entre iteraciones", mientras que el tiempo de pensamiento es el retraso entre 2 pasos cualesquiera.
La configuración recomendada depende del diseño de la prueba. Sin embargo, si desea tener una carga agresiva, considere optar por "Tan pronto como finalice la iteración anterior".
Tronco
Un registro (como se entiende generalmente) es una contabilidad de todos los eventos mientras ejecuta LoadRunner. Puede habilitar el registro para saber qué está sucediendo entre su aplicación y su servidor.
LoadRunner ofrece un poderoso mecanismo de registro que es robusto y escalable por sí solo. Le permite mantener solo el "Registro estándar" o un registro extendido detallado y configurable o deshabilitarlo por completo.
Un registro estándar es informativo y fácilmente comprensible. Contiene la cantidad justa de conocimiento que generalmente necesitará para solucionar los 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 se ampliará. Esto incluirá todo el HTML, las etiquetas, los recursos y la información que no sea de recursos incluida en el registro. La opción es buena solo si necesita una solución de problemas seria. Por lo general, esto hace que el archivo de registro sea muy grande y no sea fácilmente comprensible.
Como ya podría haber adivinado, si opta por "Advance Trace", su archivo de registro será enorme. Debes intentarlo. Notará 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 comprende la aplicación en cuestión, la comunicación de cliente a servidor entre su aplicación y el hardware, así como los detalles del nivel de protocolo. Por lo general, esta información está muerta en esencia, ya que requiere un esfuerzo extremo para comprender y solucionar problemas.
Consejos:
- No importa cuánto tiempo tome 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 vanguardia".
- Desactive el registro si no es necesario.
- Desactive el registro cuando haya terminado con sus scripts. La inclusión de scripts con el registro habilitado hará que el controlador se ejecute más lento y notifique mensajes molestos.
- La desactivación del registro aumentará la capacidad del número máximo de usuarios que puede simular desde LoadRunner.
- Considere usar “Enviar mensaje solo cuando ocurra un error”; esto silenciará los mensajes de información innecesarios y reportará solo los mensajes relacionados con el error.
Piense 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 usar una aplicación como una máquina (VUGen). VUGen genera tiempo para pensar automáticamente. Aún tiene el 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 próxima interacción de la aplicación con el servidor ocurrirá cuando haga clic en "Iniciar sesión". El tiempo que un usuario tardó en escribir su nombre de usuario y contraseña es Think Time en LoadRunner.
Si está buscando simular una carga agresiva en la aplicación, considere deshabilitar el tiempo de pensamiento por completo.
Sin embargo, para simular un comportamiento similar real, puede "Tiempo de pensamiento aleatorio del usuario" y establecer los porcentajes como desee.
Considere utilizar Limit Think Time 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 para cada máquina cliente.
Dado que estamos simulando miles de VUser a través de LoadRunner, es sorprendente lo sencillo que ha hecho LoadRunner para controlar la simulación de ancho de banda / velocidad de la red.
Si son clientes que acceden a su aplicación a más de 128 Kbps, pueden controlarla desde aquí. Podrá simular un “comportamiento similar al real” que debería ayudar a obtener las estadísticas de rendimiento correctas.
La mejor recomendación es configurar Usar ancho de banda máximo. Esto ayudará a ignorar cualquier cuello de botella de rendimiento relacionado con la red y se centrará primero en cualquier problema potencial en la aplicación. Siempre puede ejecutar la prueba varias veces para ver el comportamiento variable en diferentes circunstancias.
Emulación de navegador
La experiencia del usuario no depende del navegador que utilice el usuario final. Claramente, esto está más allá del alcance de las medidas de desempeño. Sin embargo, puede elegir qué navegador desea emular.
¿Puede responderse a sí mismo cuándo exactamente será importante para usted seleccionar el navegador correcto en esta configuración?
Utilizará esta configuración si su aplicación sujeta es una aplicación web, que 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 la caché del navegador. Si desea medir el tiempo de respuesta cuando la caché está habilitada, marque esta casilla. Si está buscando la peor situación posible, obviamente esto no es una consideración.
La descarga de recursos que no sean HTML permitirá que LoadRunner descargue cualquier CSS, JS y otros medios enriquecidos. Esto debe permanecer marcado. Sin embargo, si desea eliminar esto del diseño de la prueba de rendimiento, puede desmarcarlo.
Apoderado
Es mejor eliminar el proxy por completo de su 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 sea inevitable. En tal situación, LoadRunner le facilita la configuración del proxy.
Estará trabajando (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 qué configuración de proxy para el navegador predeterminado es.
Si está utilizando un proxy y requiere autenticación (o una secuencia de comandos), puede hacer clic en el botón Autenticar que conduce a 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. Ha terminado con la configuración de su script VUGen. No olvide configurarlo para todos sus scripts de VUser.