Técnicas de Caja Negra

En primera instancia, indicamos que la función del testing de software independiente de la técnica, busca mediante la construcción de un diseño de pruebas, el cual se compone de plan de pruebas y casos prueba, realizar pruebas en un sistema en particular con el fin de certificar su correcto funcionamiento. 

Este funcionamiento está definido tanto en la especificación de requisitos del software como también en el diseño detallado del sistema.

Entonces para esta finalidad poseemos varias técnicas, estas buscan realizar pruebas y evaluar el software desde diferentes perspectivas, la cuales pueden ser la forma en la que hace las operaciones, rendimiento o bien solo que los procesos realicen las operaciones esperadas.

Cuando hablamos de técnicas de caja negra, estamos enfocando nuestras pruebas a que el sistema realice las operaciones esperadas, es decir que no es del alcance de estas pruebas conocer el como lo hace ni el rendimiento, solo que con la información de entrada se obtenga la información de salida esperada.

Esta técnica, consiste entonces en la construcción de casos prueba por cada entrada posible sin importar su valides. Sin embargo sería una tarea  fuera de los límites de un proyecto de común, para lo cual existen entonces algunos métodos que se encargan de simplificar esta labor y que cubren los aspectos esperados de una prueba de certificación de software.

Los métodos a tratar en esta entrada entonces son:

Método de clases de equivalencia:

Este método consiste en realizar agrupaciones de clases por comportamientos, se agrupan entonces los datos de entrada y de salida en clases diferentes en la que todos los componentes de cada clase están relacionados por su comportamiento.

Cada una de estas clases será llamada una partición de equivalencia en la que el programa posee el mismo comportamiento indiferente de cual sea la entrada.

Se debe seleccionar un elemento representativo de la clase, donde se supone que si la agrupación es correcta, el sistema tendrá el mismo comportamiento para cualquier otro valor.

Para la aplicación de este método debemos de seguir 2 pasos:

1. Identificación de las clases de equivalencia

Identificamos las clases según el posible comportamiento de los valores

Si se considera o existe una razón para detectar que los valores de una clase no son idénticos,  se debe dividir en clases menores.

2. Identificación de los casos prueba.

Por cada dato de entrada y salida elegimos un valor perteneciente a una clase de equivalencia.

Un caso de prueba está formado por un dato de prueba para cada dato de entrada y salida (resultado esperado)

Basados en esto, estructuramos nuestros casos prueba, bajo las siguientes pautas:

• El objetivo es probar todas las clases válidas y no válidas al menos una vez cada una de ellas
• Cada caso debe cubrir el máximo numero de entradas
• En un caso de prueba pueden aparecer varias clases de entrada válidas
• En un caso de prueba solamente puede aparecer una entrada no válida. El criterio para las clases no válidas impide que los errores se enmascaren mutuamente
• Se debe especificar el resultado esperado

Con estas pautas seguimos los siguientes pasos:

• Asignar un número único a cada clase de equivalencia 
• Escribir casos de prueba hasta que sean cubiertas todas las clases de equivalencias validas, intentando cubrir en cada caso tantas como sea posible 
• Para cada Clase de Equivalencia Invalida, escribir un caso de prueba, cubriendo en cada caso tantas como sea posible.

Ejemplo:  result function (x, y, z) . Sean Vi las clases válidas y Ni las clases inválidas

Clases de x: V1, N1,N2

Clases de y: V2,N3

Clases de z: V3, N4, N5

Clases de result: V4, N6, N7

Un posible caso de prueba sería: ( x1 en V1, y1 en V2, z1 en V3, r1 en V4)

Método de Análisis de valores frontera o valores limite:

Este método parte de del método de clases de equivalencia, su diferencia radica en el modo de generar los casos prueba, en este caso mas que seleccionar cualquier elemento como representativo de la clase de equivalencia, el análisis de valor limite requiere que se seleccionen uno o más elementos de forma tal que cada margen de la clase de equivalencia sea sujeto  a una prueba .

Los casos de prueba se derivan también de considerando el espacio de resultados (clases de equivalencia de salida) .

La diferencia entre esta técnica y la de las particiones de equivalencia es que se exploran en estas situaciones existentes sobre y alrededor de los bordes de las particiones de equivalencia.

con estas premisas, entonces estructurar los casos de salida de la siguiente forma:

1. Usar el rango de valores para los valores de salida, o sea su calculo debe dar entre 1 y 100. escribir casos de prueba que causen salidas de 1 y 100.

2. Usar el numero de valores para la salida

3. Analizar las posibles situaciones para encontrar otros limites.

Método Grafos Causa/Efecto y tablas de decisión:

El uso de grafos de causa - efecto es una técnica de casos de prueba que proporciona una concisa representación de las condiciones lógicas y sus correspondientes acciones. La técnica sigue cuatro pasos:

1. Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones), asignando un identificador a cada uno de ellos.

2. Se desarrolla un grafo causa - efecto

3. Se convierte el grafo en una tabla de decisión

4. Se convierten las reglas de la tabla de decisión a casos de prueba

Si se ha usado una tabla de decisión como herramienta de diseño, los grafos causa - efecto ya no son necesarios.

Para la construcción del grafo entonces se parte de los operadores booleanos, partimos de los siguientes conceptos:

Seguimos entonces los siguientes pasos para la construcción:

1. Dividir la especificación en piezas que sean ‘trabajables’.No intentar crear un simple grafo para toda la especificación.

2. Identificar Causas y Efectos:

• Una causa es una única condición de entrada.
• Un efecto es una condición de salida o transformación del sistema.

3. Traducir las relaciones semánticas en cada segmento en relaciones booleanas enlazando causas con efectos. Es decir, construir los grafos.

4. Colocar las restricciones que se aplican a las causas y efectos

5. Crear una Tabla de Decisión resumiendo todas las posibles combinaciones de estados

• Las Causas son las entradas
• Los Efectos son las salidas
• Las Columnas son los casos de prueba

6. Dividir las entradas de la tabla en reglas, una por cada combinación única de estados en el grafo.

• Indicar cuales combinación de estados están asociados con los efectos colocando una X (o un 1) en la columna que representa esa combinación estado condición.
• Convertir cada columna (regla) de la tabla de decisión en un caso de test

Ejemplo

Requerimientos para calcular primas en seguros de autos :

• Para mujeres de menos de 65 años, la prima es de $500
• Para hombres de menos de 25 años, la prima es de $3000
• Para hombres entre 25 y 64 años, la prima es de $1000
• Para cualquiera de mas de 65 años, la prima es de $1500

Primer paso, Identificar Causas y efectos

Segundo paso, Elaboramos grafos

Tercer paso, Elaboramos la Tabla de decisión

Cuarto paso, elaboramos casos prueba

Método Adivinación de errores:

Este método de testing se basa en la experiencia del ejecutor. Consiste en realizar un análisis de los requisitos y el diseño del sistema, buscando intuir en que puntos del sistema se pudieron insertar errores y elaborar el diseño de las pruebas enfocado a atacar el sistema sobre estos casos.

Es curioso, pero en la gran mayoría de las ocasiones este método es utilizado por los tester,  no existe mucha documentación del método ni una estructuración de los pasos a seguir para este tipo de prueba.

Las historias de defectos pueden ser útiles; hay una alta probabilidad de que los errores que han aparecido en el pasado, puedan volver a aparecer. Generalmente se enfocan en:

• listas o strings vacíos o nulos
• cero ocurrencias o instancias
• números negativos

Fuentes de la información:

Métodos de Caja Negra, (2010), www.fing.edu.uy, Obtenida desde: http://www.fing.edu.uy/~bperez/protest/guias/guias/tecnicas/cubrimiento.htm

Técnicas de testing caja negra, (2009), indalog.ual.es, Obtenida desde: http://indalog.ual.es/mtorres/LP/Prueba.pdf

Black box testing, (2009), agile.csc.ncsu.edu, Obtenida desde: http://agile.csc.ncsu.edu/SEMaterials/BlackBox.pdf