10.7.06

Un ejemplo de diseño de pruebas con Cactus (II).

Un millón de disculpas por la tardanza, continuamos:

Necesitaremos definir los siguientes elementos para cada caso de prueba: acciones a realizar, valores de prueba, resultado esperado. Por comodidad, vuelvo a poner el comportamiento que el servlet debe tener:


1. El servlet recibe una petición de login con un nombre de usuario y una clave.
1.1. Si el usuario ya se ha registrado, el servlet informa de ello y termina.
1.2. Si el usuario ya lo intentó 3 veces, el servlet informa de ello y termina.
2. En caso contrario, el servlet comprueba el nombre y la clave recibida.
2.1. Si el nombre es válido y la clave coincide, el servlet registra al usuario, informa de ello y termina.
2.2. Si el nombre no es válido o la clave no coincide, el servlet incrementa el número de intentos e informa de ello.


Comencemos.

Las acciones a realizar serán todas las combinaciones posibles, tal y como se muestra a continuación.


c.a) 1 -> 1.1
c.b) 1 -> 1.2
c.c) 1 -> 2 -> 2.1
c.d) 1 -> 2 -> 2.2


La combinación c.a) representa el escenario en el que un usuario solicita el acceso pero ya se había validado. La combinación c.c) representa el escenario en que un usuario solicita el acceso e introduce un nombre y clave correctos, etc.

Además, estás combinaciones pueden repetirse varias veces, tal y como se muestra a continuación:


a) 1 -> 1.1 -> 1 -> 1.1 -> ... (hasta que la sesión expire)
b) 1 -> 1.2 -> 1 -> 1.2 -> ... (hasta que la sesión expire)
c) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1
d) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1
e) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 1.2 -> 1 -> 1.2 -> ... (hasta que la sesión expire)
f) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1 -> 1 -> 1.1 -> 1 -> 1.1 -> ... (hasta que la sesión expire)


Las repeticiones de combinaciones, en principio, no las tendremos en cuenta, aunque sería interesante probar algunas, por ejemplo la c, la d, la e y la f.

Pasemos ahora a los valores de prueba. En primer lugar identificamos los valores o variables y su dominio:


Nombre de usuario (Cadena de texto)
Clave (Cadena de texto)
Número de intentos (Entero)
Está validado (Booleano)


A continuación dividimos el dominio en distintas categorías. Podemos definir, de manera informal, una categoría como un subconjunto de los valores del dominio para los cuales el sistema siempre presenta el mismo comportamiento. Algunos ejemplos de categorías se muestran a continuación:


Nombre de usuario Correcto / Incorrecto
Clave Correcto / Incorrecto
Número de intentos Menor de 3 / igual a 3 *
Registrado Cierto / Falso

*- Debemos investigar si es posible que el número de intentos sea mayor que 3 o menor que 0.


No todas las categorías pueden tomarse siempre. En general, las categorías posibles estarán restringidas por el camino que estemos probando. Por ejemplo para la secuencia c) (la secuencia de acceso correcto), el número de intentos debe ser menos que tres, el usuario no debe estar registrado y el nombre y la clave deben ser correctos. A continuación se expresan las restricciones de cada una de las combinaciones.


c.a) Registrado = Cierto.
c.b) Registrado = Falso && Numero de intentos = 3
c.c) Registrado = Falso && Numero de intentos < 3 && Nombre = Correcto && Clave = Correcto
c.d) Registrado = Falso && Numero de intentos < 3 && ( Nombre = Incorrecto || Clave = Incorrecto )


A partir de estas restricciones vamos a construir los escenarios de prueba. Un escenario de prueba es una combinación concreta, con un conjunto de valores de prueba concretos que cumplen las restricciones. Cada escenario de prueba es una prueba candidata, es decir, puede convertirse en un caso de prueba. En total, para las cuatro combinaciones del principio hemos identificado 10 escenarios de prueba:


Escenario 1:
Camino a)
Registrado = Cierto.

Escenario 2:
Camino b)
Registrado = Falso
Numero de intentos = 3

Escenario 3:
Camino c)
Registrado = Falso
Numero de intentos = 0

Escenario 4:
Camino c)
Registrado = Falso
Numero de intentos = 2
Nombre = correcto
Clave = correcto

Escenario 5:
Camino d)
Registrado = Falso
Numero de intentos = 0
Nombre = correcto
Clave = incorrecto

Escenario 6:
Camino d)
Registrado = Falso
Numero de intentos = 0
Nombre = incorrecto
Clave = correcto

Escenario 7:
Camino d)
Registrado = Falso
Numero de intentos = 0
Nombre = incorrecto
Clave = incorrecto

Escenario 8:
Camino d)
Registrado = Falso
Numero de intentos = 2
Nombre = correcto
Clave = incorrecto

Escenario 9:
Camino d)
Registrado = Falso
Numero de intentos = 2
Nombre = incorrecto
Clave = correcto

Escenario 10:
Camino d)
Registrado = Falso
Numero de intentos = 2
Nombre = incorrecto
Clave = incorrecto


Aún nos falta decidir cuáles de estos escenarios se implementarán como pruebas con Cactus y definir el resultado esperado de cada escenario. Eso lo veremos en la siguiente entrada, que espero que no tarde tanto como esta.

Feliz verano.