Usuarios Concurrentes (Concurrent Users)

Un tema que siempre es difícil de entender o asimilar es el tema de los Usuarios Concurrentes. Buscando en la red diversos artículos que explicaran esto pude encontrar un articulo de Alberto Savoia, un referente en Performance Testing (con solo poner su nombre en google lo veran ;)) llamado “Three Web load testing blunders, and how to avoid them” el cual explica de forma muy sencilla este concepto. Voy a tomar la primer parte de este y mas adelante haré lo mismo con los demas puntos ya que son muy importantes tambien.
En este articulo resalta:

El número de usuarios concurrentes no debe considerarse como entrada para el Load Testing , sino como el resultado de una serie de factores.

Esto viene al caso de que comúnmente uno define los escenarios de Performance o de pruebas de Carga de la manera: “La aplicación debe soportar un máximo de 250 usuarios concurrentes” poniendo implícitamente la cantidad e usuarios concurrentes como parámetro de entrada para las pruebas.

Se puede observar como ese valor no puede ser entrada con un ejemplo (Similar al del articulo de Alberto):
Hay 3 usuarios distintos que no se conocen entre si (van a tener acciones diferentes y desincronizadas)  y visitan la pagina de estado de cuenta de su banco 3 días consecutivos.
1º  Día
El Usuario 1 inicia sesión a las 12:00; el Usuario 2 inicia sesión a las 12:01 y el Usuario 3 inicia sesión a las 12:02 y cada uno de sus escenarios consiste en Login-> Home Page-> Cuenta Pesos ->Cuenta Dolares. Cada uno de los usuarios se toma 10 segundos mirando cada pagina (Think Time) antes de pasar a la siguiente; Si el tiempo de respuesta de cada pagina es de5 segundos  (tiempo que tarda en cargar) las sesiones de los 3 usuarios no se solaparan por lo que no habría usuarios concurrentes ya que el Usuario 1 va a recibir y ver cada una de las paginas antes de que el Usuario 2 inicie su sesión y el Usuario 2 va poder hacer lo mismo antes de que el Usuario 3 inicie su sesión.

Fig 1. No se da concurrencia de Usuarios

2º Día
En el 2º día el tiempo de respuesta de cada pagina aumenta al doble (10 segundos) pero el tiempo que le toma a cada usuario leer la pagina sigue siendo de 10 segundos, por lo que cada sesión tendra un tiempo total de 80 segundos en lugar de los 60 segundos que antes tomaba. Este cambio en la velocidad de carga de pagina (Response Time) produce 2 usuarios concurrentes donde antes no los había, superponiendo las tareas del Usuario 1 con las del Usuario 2 y luego las del Usuario 2 con las del Usuario 3 como se ve en el gráfico.

Fig 2. Hay 2 Usuarios concurrentes debido al cambio en el tiempo de respuesta

3º Día
En el 3º día el tiempo de respuesta baja aun mas, llegando a 30 segundos el tiempo de respuesta de cada pagina, tardando 160 segundos cada sesión de usuario. Esto provoca que las sesiones del Usuario 1 y Usuario 2 se superpongan por 60 segundos generando 2 usuarios concurrentes, luego se genera 3 usuarios son currentes con la superposición de las sesiones del Usuario 1, Usuario 2 y Usuario 3 para luego quedar en 2 usuarios concurrentes.

Fig 3. La cantidad de Usuarios Concurrentes llega a 3

Como se ve en los ejemplos el número de usuarios concurrentes no es una medida de la prueba de carga, ya que la carga fue idéntica en los 3 casos: tres usuarios, entrando al sistema en lapsos de un minuto, ven cuatro páginas cada uno con 10 segundos de Think Time por página.
En conclusión:

El número de usuarios concurrentes fue el resultado de la prueba de Carga:  es una medida de la habilidad del sitio web para manejar una carga especifica. Un sitio web más lento da lugar a más usuarios concurrentes.

Cuando se trata de medir la escalabilidad de un sitio Web, resulta que el número de usuarios concurrentes  ni siquiera es útil como resultado de la prueba de carga.
Si el sitio Web es un poco lento, el número de usuarios concurrentes aumenta. Si es realmente lento, una gran cantidad de usuarios reales lo abandonan, lo que reduce el número de usuarios concurrentes. Pero, por otra parte, si un sitio Web es muy rápido las sesiones se completan más rápidamente, reduciendo también el número de usuarios concurrentes.

La conclusión es que los usuarios concurrentes es una medida peligrosamente engañosa, es un indicador que puede ser utilizada de muchas maneras pero es prácticamente garantizado que da resultados cuestionables.

La pregunta inmediata es: ¿Qué medida debería usar en su lugar?
Para describir una entrada de carga, se puede utilizar la métrica inicio de sesiones de usuario por hora ya que es constante e independiente de la performance de la aplicación.

Fuente: http://josepablosarco.wordpress.com/2009/01/13/usuarios-concurrentes-concurrent-users/

Pruebas de Integración

La prueba de integración se realiza posteriormente a las pruebas de unidad y su foco de atención es el diseño y la construcción de la arquitectura del software. 

Después de la integración viene la validación y por último la prueba del sistema, ésta última consiste en probar el software junto con los otros elementos de la empresa o entidad, como la gente, departamentos, la base de datos.

Las pruebas de integración pueden ser descendentes o ascendentes o en sandwich, pero estas tienen sentido con ese nombre en los sistemas hechos en lenguajes estructurados, en los que el diagrama de la estructura de módulos del sistema permite definir un tipo dado de integración.
 En los orientados a objeto, otra vez cobra importancia el concepto de caso de uso, pues éste guía a la prueba en cuanto a los requisitos que deben satisfacer un determinado número de clases de programación que tienen que interactuar entre sí gobernadas por alguna clase de control del caso de uso.

Pruebas de validación

Pruebas de validación

 

La validación se logra cuando el software funciona de acuerdo a las expectativas del cliente.

La validación seconsigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que negociar con el cliente un método para resolverlas.

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entrono controlado.

La prueba beta se lleva a cabo en uno o más lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no está presente. 
La prueba beta es una aplicación "en vivo" del software en un entrono que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. 
Como resultado, el equipo de desarrollo lleva a cabo modificaciones y así prepara una versión del producto para toda la base de clientes.

Técnica de Particion Equivalente - Pruebas de Caja Negra

Una partición equivalente es una técnica de prueba de Caja Negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
El diseño de estos casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.

Regularmente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.

Si una entrada es booleana, hay 2 clases: si o no.

Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.

Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor número de atributos de cada clase de equivalencia a la vez.

Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:

• Primero se deben identificar las clases de equivalencia lo cual se hace tomandocada condición de entrada y aplicándole las directrices antes expuestas.

Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condición de entrada especifica un rango, entonces se confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición de entrada especifica la cantidad de valores, identificar una clase de equivalencia válida y dos inválidas.
Si una condición de entrada especifica un conjunto de valores de entrada y existen razones para creer que el programa trata en forma diferente a cada uno de ellos, identificar una clase válida para cada uno de ellos y una clase inválida.
Si una condición de entrada especifica una situación de tipo “debe ser”, identificar una clase válida y una inválida.
Si existe una razón para creer que el programa no trata de forma idéntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.

• Luego de tener las clases válidas e inválidas definidas, se procede a definir los casos de pruebas, pero para ello antes se debe haber asignado un identificador único a cada clase de equivalencia.

• Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:

1. Escribir un nuevo caso de cubra tantas clases de equivalencia válidas no cubiertas como sea posible hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba.
2. Escribir un nuevo caso de prueba que cubra una y solo una clase de equivalencia inválida hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de pruebas.

Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el programa está llevando a cabo una prueba.

Aplicando el diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número de errores antes de que comiencen las “pruebas del cliente”. 

Como ejemplo, consideremos los datos contenidos en una aplicación de automatización bancaria. Este software acepta datos en la siguiente forma:
Código de área: En blanco ó un número de 3 dígitos
Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Sufijo: Número de 4 dígitos
Contraseña: Vvalor alfanumérico de 6 dígitos
Ordenes: "Comprobar", "Depositar","Pagar factura", etc.

Las condiciones de entrada relacionadas con cada elemento de la aplicación bancaria se pueden especificar como:
Código de área: Condición de entrada lógica - el código de área puede estar o no presente
Condición de entrada rango - valores definidos entre 200 y 999
Prefijo: Condición de entrada rango - valor especificado > 200
Sufijo: Condición de entrada valor- longitud de 4 dígitos
Contraseña: Condición de entrada lógica - la palabra clave puede estar o no presente
Condición de entrada valor - cadena de seis caracteres
Orden: Condición de entrada conjunto, contenida en las órdenes listadas anteriormente.

Los casos de prueba se seleccionan de manera que se ejercite el mayor número de atributos de cada clase de equivalencia a la vez.

Pruebas de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Técnica de Camino básico

La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por Tom McCabe.

Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar esta medida como guía para la definición de un conjunto básico.

La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son:

1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
2. Se calcula la complejidad ciclomática del grafo.
3. Se determina un conjunto básico de caminos independientes.
4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.

Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Técnica de Notación de Grafo de Flujo

Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la representación del flujo de control, el cual puede representarse por un Grafo de Flujo. Cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar que el trabajo se está haciendo adecuadamente.

Los componentes son:

Nodo

Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan principalmente al inicio y final del grafo.

Aristas

Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.

Regiones

Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo. Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND, NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más complicada.

Técnica Complejidad Ciclomática

La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente.

Pruebas Software

Las pruebas de software consisten en la dinámica de la verificación del comportamiento de un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son una serie de actividades que se realizan con el propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de un programa u ordenador; probando el comportamiento del mismo.

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan:

• La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.
• La principal dificultad del proceso de prueba es decidir cuándo parar.
• Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.
• Una parte necesaria de un caso de prueba es la definición del resultado esperado.
• Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.
• El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.

1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.
2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.
3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.
4. Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.
5. Ejecutar los casos de prueba.