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