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...

Convertirse en un experto en pruebas del software

En esta presentación James Bach habla de las posibilidades a nuestro alcance para pasar de ser un tester experimentado a un verdadero experto.

Cuando alcanzas un determinado grado de experiencia, es dificil encontrar cursos o programas que realmente supongan un avance sobre lo que ya conoces. Entonces, tienes que empezar a gestionar tu formación tu mismo.

Resumen del autor acerca de la presentación:
You're already an experienced tester. You know how to design tests and report bugs. Now what? Do you feel like an expert? Unfortunately, if you want to become very good at testing, there aren't many classes or programs available to help you. This means you must manage your own education. This tutorial is about finding a path from experience to expertise. It's based on the context-driven school of test methodology. It focuses on what it means to think like a tester and how to design and critique testing practices (rather than just copy what the "gurus" tell you to do). You'll also get self- study strategies and methods for developing a colleague network. It's an ideal tutorial if testing is your career and you intend to excel in it.

Leer más...

Novedades para Testing en Microsoft

Microsoft ha dado un paso para facilitar la vida a los equipos de pruebas con el lanzamiento de su Tester Center , una web que pone de relieve que la pruebas son una parte integral del ciclo de vida del desarrollo de aplicaciones.

Además de proporcionar herramientas, se supone que el Tester Center servirá como lugar donde los desarrolladores de software y testers pueden ver vídeos, leer artículos técnicos, e interactuar con testers de Microsoft a través de blogs y foros.

Creo que es una buena vía para incorporar a las proyectos un poco de metodología, técnicas y herramientas de pruebas y mejorar algunas de esas actividades generalmente tan tediosas que nadie quiere hacer.

Los que tengais el ánimo y el interés de utilizar algo de esta web, no dejeis de comentarnos vuestra opinión, para extender su uso si es que vale para algo.

Leer más...

Generación automática de test JUnit gratis

Según una encuesta reciente llevada a cabo por Evans Data para Agitar Software, las pruebas unitarias son una práctica cada vez más frecuente, gracias en gran parte a la aparición y desarrollo de JUnit. El estudio reveló que casi las tres cuartas partes de los desarrolladores de Java en todo el mundo utilizan JUnit, el framework ha sido descargado más de 2 millones de veces y se incluye como un "plug-in" en los principales IDEs.

Entre otras cosas, el estudio reveló que el 87 por ciento de los desarrolladores Java utilizan herramientas de pruebas unitarias y el 71 por ciento son JUnit. También reveló que sólo el 19 por ciento de los desarrolladores de Java han adoptado herramientas de automatización de pruebas unitarias y que las pruebas unitarias se utilizan con más frecuencia en América del Norte y menos en el área EMEA (Europa-Oriente Medio-Asia). También es proporcionalmente más utilizada en las empresas con más de 1.000 empleados.

Una idea del éxito y las posibilidades de JUnit es la acogida que ha tenido el servicio GRATUITO de JUnit Factory (http://www.junitfactory.com/) de AgitarLab, que permite a los usuarios enviar su código y les devuelve test JUnit generados automáticamente.
Incluso proporciona un plug-in para hacerlo desde Eclipse, que además incluye un runtime de JUnit con análisis de la cobertura de código. Como era de esperar, esta versión gratuita es una introducción a una versión de pago con funcionalidades más avanzadas, pero algún beneficio debe aportar cuando ya se han realizado más de un millón de solicitudes de generaciones de tests desde su puesta en funcionamiento en enero del 2007.

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...