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.