Relación entre Usuarios Virtuales y Usuarios Reales en pruebas de carga (II)

¿Cómo cálculo cuantos usuarios reales estoy simulando?
En primer lugar, vamos a calcular la carga real que se generaría.

Cálculo de la carga generada por un usuario real
Un usuario real, ejecutando una transacción determinada en el sistema, tardaría un tiempo determinado y generaría un numero de peticiones en los servidores



La carga generada por este usuario, a lo largo del tiempo, la podemos calcular como

siendo número_de_peticiones el de la transacción (3 en el gráfico) y número_de_ejecuciones las veces que ejecutamos la transacción con ese usuario (una única vez el gráfico). Si ejecutamos 2 veces la transacción, la carga generada será

La carga generada será, igual que anteriomente:

Leer más...

Relación entre Usuarios Virtuales y Usuarios Reales en pruebas de carga (I)

Estas son unas de las grandes preguntas de las pruebas de carga (stress, rendimiento o como quieras denominarlas) ¿A cuantos usuarios reales representan los usuarios virtuales utilizados en la prueba? ¿Cuantos usuarios virtuales necesito para simular el numero de usuarios reales que habrá en el sistema? Aquí os dejo mi aproximación al problema, y mi solución (discutible, como todas)

La justificación que se presenta a continuación es una forma básica de estimar el número de usuarios virtuales por cada usuario real, que puede ser complementada con factores correctores que dependen del sistema bajo prueba, pero no modifican la esencia del planteamiento. En general, el coste de averiguar estos factores y su relación con el sistema no compensa los beneficios de su aplicación

Para justificar la fórmula utilizada en el cálculo del ratio entre usuarios reales (UR) y virtuales (UV), presentamos a continuación los conceptos y razonamientos utilizados:

¿Qué incluye una transacción contra el sistema?

• Lo denominado como thinking time o tiempo del usuario
  • Tiempo que el usuario tarda en leer, reaccionar y escribir en la pantalla (factor humano)
  • Tiempo de procesamiento de la capa cliente (navegador) de la aplicación
• El resto, tiempo asociado al sistema servidor
  • Tiempo empleado en las comunicaciones cliente-servidor
  • Tiempo empleado en el procesamiento en servidor

¿Qué es un usuario virtual?

Las herramientas de pruebas de carga simulan usuarios humanos o reales (UR) por “usuarios virtuales”(UV). Cada UV emula las acciones de usuarios reales ejecutando los mismos procesos de negocio. Por cada acción que realiza el UV, la herramienta envia las paquetes de datos al servidor o sistema de servidores, y espera la respuesta. Incrementando el número de usuarios virtuales, se incrementa la carga en el sistema. Mientras que una estación de trabajo únicamente puede ser utilizada simultáneamente por un usuario real, varios usuarios virtuales pueden ejecutarse concurrentemente en un único puesto.

¿Cuál es el objetivo de una prueba de carga?
Lanzar contra el sistema bajo prueba una carga similar a la esperada en
producción, para obtener los indicadores más significativos que nos permitan
evaluar el comportamiento de este respecto a la demanda realizada.

¿Cuál es la mejor forma de realizar la prueba de carga?

• Con usuarios reales.
• Un usuario Virtual por cada Usuario real, realizando la ejecución tal y como se grabó (es decir, con los “think time” que se grabaron). Si se tiene la posibilidad de utilizar tantos usuarios virtuales como reales se estiman en producción, esta es la forma recomendada.

¿Por qué utilizamos un número de Usuarios Virtuales inferior al de Reales?

• Coste de las herramientas: las licencias de las herramientas de pruebas de carga suelen estar asociadas al numero de usuarios virtuales concurrentes. A mayor número de UV concurrentes, mayor coste.
• Recursos necesarios para la ejecución: generalmente, cada usuario virtual es un hilo o proceso, al que se le asignan unos determinados recursos físicos (RAM, %CPU, etc). A mayor número de UV, más recursos son necesarios.
  

Leer más...

Optimizando la realización de pruebas: uso de métricas

Durante el diseño y la ejecución de las pruebas debemos recoger diferentes métricas. La utilidad más habitual es informar al responsable del proyecto del estado del sistema bajo prueba: defectos encontrados, severidad de los mismos, etc.

Habitualmente también se recogen métricas para conocer el grado de cobertura que se ha conseguido con la ejecución de las pruebas: casos de prueba propuestos, ejecutados, fallidos, no ejecutados, bloqueados, etc.

Pero el responsable de pruebas debe prever también la recogida de información suficiente para hacer más efectivas las pruebas realizadas en cada iteración. "Hacer más efectiva" significa aquí detectar el mayor numero posible de errores, o errores más importantes.

Para esto, debemos pensar con antelación cual será nuestra estrategia de mejora de la efectividad, de cara a recoger la información necesaria. Algunas de las suposiciones que podemos seguir son:

Los errores tienden a "agruparse" (1):

• Por zonas de código: un módulo o conjunto de funciones que presenta problemas en un ciclo de pruebas es propenso a presentar problemas en los siguientes
• Por equipos de trabajo de desarrolladores: un equipo que crea código con incidencias tiene a generar incidencias en nuevo código o correcciones
• Por equipos de trabajo de testers: un equipo o grupo de testers es capaz de identificar mayor numero de errores que otro, o un grupo levanta mas errores no reales (que luego, al ser revisados, resultan no ser errores) que otro.

En este caso, deberemos recoger información que nos permita trazar cada error detectado durante las pruebas con la zona en la que se ha producido. Una vez finalizado el ciclo de pruebas, podremos ver las zonas en las que debemos poner mayor atención en los siguientes ciclos de pruebas y en cuales podemos disminuir la intensidad o tomar medidas de mejora.

A la hora de determinar o analizar las zonas, podemos tener en cuenta los distintos factores que determinan el éxito o fracaso durante un proceso de test (2):

• Producción
• Personal
• Comunicaciones
• Operaciones
• Mantenimiento
• Entorno
  

Referencias

1. McGowen, D.J. “C4I Operational Test and Evaluation in Support of Evolutionary Acquisition Strategy.” ITEA Journal of Test and Evaluation 21.2 (2000): 34-39.
2. Phadke, M.S. “Planning Efficient Software Tests.” CrossTalk Oct. 1997 <www.stsc.hill.af.mil/crosstalk/1997/10/index.html>.
   

Leer más...

Sistemas que usan periféricos especiales

Muchos sistemas utilizan o se comunican con periféricos o dispositivos no estándares, como puede ser una puerta automática, una barrera, una impresora de billetes de metro o tren, etc.

En general, es difícil disponer de estos elementos en el entorno de pruebas, especialmente el interno (pruebas alfa, en las instalaciones del desarrollador, de verificación, como queramos llamarlas) ya sea por su tamaño, coste, disponibilidad en el tiempo o pertenecer a otra compañía.

Si no hemos tenido en cuenta esta circunstancia al realizar nuestra estrategia de pruebas (y por tanto, en el planteamiento general del proyecto) nos encontraremos con que el número de pruebas que podemos hacer antes de entregar nuestro producto está limitado por esta causa, y además en elementos cuyo fallo puede suponer un impacto importante en la calidad percibida por el cliente.

Una táctica para solventar este inconveniente es que cualquier implementación de comunicaciones con dichos dispositivos tenga un modo "de prueba" o "test", de tal forma que cuando el sistema está en este modo, la comunicación con el dispositivo es sustiuida por un metodo posible en el entorno de pruebas definido, como puede ser un fichero o impresora.

Este modo "test" debe cumplir con algunas características que nos permitan asegurar que su uso no desvirtua la prueba:

• Debe contruirse de forma que su activación o desactivación no implique la modificación y/o recompilación de código: mediante un valor en un fichero de configuración, entrada de registro, etc
• Para la interpretación/ generación del mensaje, debe ejecutarse el mismo código en el modo "test" que en el modo "en producción".

Ya que esta estrategia implica que el equipo de desarrollo tenga en cuenta en su trabajo las necesidades de pruebas (algo no muy habitual), es necesario conseguir que estas decisiones se tomen lo antes posible en el proyecto, y en el nivel de decisión adecuado que garantice que no se dejaran en el olvido cuando las presiones de tiempo lleguen.

Esta tactica puede extrapolarse a cualquier comunicación que nuestro sistema tenga que realizar con otro sistema del que no dispondremos en nuestro entorno de pruebas, aplicando como siempre el criterio de coste/riesgo correspondiente.

Leer más...