Técnica de diseño

“Partición en Clases de Equivalencia” es una técnica de diseño de casos de prueba de Caja Negra (Ver Anexo).

Pasos de la técnica:

1. Identificar las clases de equivalencia
2. Definir los casos de prueba

Paso 1: Identificar las clases de equivalencia

Para identificar las clases de equivalencia, se consideran los valores de entrada y los valores de salida del programa bajo prueba.

Se definen 2 tipos de clases de equivalencia: clases válidas y clases inválidas. Las cuales corresponden a entradas válidas e inválidas, respectivamente.

Para empezar:

• Identificamos las variables existentes y sus posibles valores.
• Identificamos las clases de equivalencia.

¿Cómo identificar las clases de equivalencia?

Pasos:

1. Si la condición de entrada corresponde a un rango de valores (por ejemplo: “un número entre 1 y 999”) → se define 1 clase de equivalencia válida (CEV) y 2 inválidas (CEI). En el ejemplo:
   1. CEV: 1 <= valor <= 999
   2. CEI: valor < 1 y valor > 999
2. Si la condición de entrada corresponde a un valor específico (por ejemplo: “el primer carácter tiene que ser una letra”) → 1 CEV (una letra) y 1 CEI (no es una letra).
3. Si la condición de entrada corresponde a un conjunto de valores posibles (por ejemplo: “el tipo de vehículo puede ser {moto, auto, camión}”) → se define una CEV para cada uno de los valores válidos, y una CEI (ejemplo: bicicleta) para un valor no esperado.
4. Si la condición de entrada especifica el número de valores (por ejemplo: “una casa puede tener de uno a seis propietarios”) → definir 1 CEV y 2 CEI (0 propietarios y más de 6 propietarios).

Si tenemos la duda de que el software bajo prueba no trata a todos los elementos de una clase de equivalencia en forma idéntica, entonces hay que subdividir la clase de equivalencia en subclases más chicas.

Paso 2: Definir los casos de prueba

Procedimiento:

1. Asignar un identificador único a cada clase de equivalencia.
2. Definir casos de prueba hasta contemplar todas las clases de equivalencia válidas. Intentando incluir la mayor cantidad de clases válidas en cada caso de prueba (de modo de minimizar la cantidad de casos de prueba).
3. Para las clases de equivalencia inválidas, definir un caso de prueba por cada clase de equivalencia inválida.
   1. Notar la diferencia con el paso anterior, ¿por qué la diferencia de criterio? porque queremos evitar enmascarar errores! O sea, si mezclamos varias clases de equivalencia inválidas y obtenemos un error (Ok, es el resultado esperado) pero no podemos confirmar cuál fue el valor que originó el error. No estamos seguros de que cada entrada que esperamos ocasione un error, realmente lo provoque.

Por ejemplo (valga la redundancia), se puede usar el ejemplo que presenta acá:

http://www.bstriker.com/3encuentro_Tecnicas.pdf

Referencias

• “The Art of Software Testing” by Glenford J. Myers.