Caja negra (sistemas)

La prueba de caja negra, test funcional o prueba comportamental, es un tipo de prueba de software directa, cuya finalidad es analizar la compatibilidad entre las interfaces de cada uno de los componentes del software. No tiene en consideración la lógica interna del sistema. Permite la revisión final de las especificaciones y codificación de un programa. La prueba es considerada aceptable cuando su ejecución conlleva una probabilidad elevada de encontrar un error y es satisfactoria cuando lo detecta.

El propósito es reducir el número de casos de prueba, pero manteniendo la efectividad de ésta, es decir, conseguir localizar el mayor número de errores posible. Esto se consigue mediante la exhaustiva elección de las condiciones de entrada y salida válidas y no válidas, que cubren todas las funcionalidades del sistema.

Este tipo de prueba detecta las siguientes tipologías de errores: funciones incorrectas o ausentes, errores de inicialización y terminación, de rendimiento, errores en estructuras de datos o accesos a bases de datos y en la interfaz.

Existen tres técnicas principales: particiones de equivalencia, análisis de valores límites y conjetura de errores. La prueba de caja negra supone un compendio de todos estos métodos.

Particiones de equivalencia

Se consideran clases de equivalencia a partir de las condiciones de entrada descritas en las especificaciones del sistema. Se considera como clase de equivalencia al conjunto de datos de entrada que se encarga de definir los estados válidos y no válidos del sistema, considerando como clase válida aquella que genera el valor esperado.

Las condiciones de entrada pueden ser estructuras de datos de diversos tipos, tanto un valor específico, como un intervalo, un conjunto de valores o una condición lógica.

El proceso a seguir consta de los siguientes pasos:

• Identificar las clases de equivalencia: por cada condición de entrada se deben identificar clases de equivalencias válidas y no válidas. En función del tipo de entrada, existen una serie de criterios para generar las clases de equivalencia.

• Definir los casos de prueba: los casos de prueba se deben añadir de forma que cubran el mayor número de clases de equivalencia válidas. Por cada clase de equivalencia no válida se debe generar un caso de prueba. Es imprescindible que cada clase esté cubierta en, al menos, un caso de prueba.

Para esclarecer, las particiones de equivalencia aplicadas a un caso de test concreto se visualizan de la forma siguiente: Dada una interfaz sujeta a los vínculos

• x es un entero comprendido entre 5 y 10
• V[ ] es un array de n enteros, n comprendido entre 1 y 5
• C es un conjunto que puede tomar los valores {Rojo, Verde}

Las clases de equivalencia entonces engloban

Elemento	Clases equivalencia válidas	Clases equivalencia no válidas
x	[5,10]	(-${\displaystyle \infty }$,4] [11, ${\displaystyle \infty }$)
V[ ]	array que cumpla longitud(V) = n	array tal que longitud(V) != n
n	[1,5]	(-${\displaystyle \infty }$,0] [6, ${\displaystyle \infty }$)
C	{Rojo} {Verde}	conjunto al que no pertenezca ninguno de los anteriores valores

Y de esta forma los casos de test se corresponden con

Análisis de valores límite

Esta técnica se basa en la evaluación de las condiciones límites, es decir, los valores inmediatamente por encima y por debajo de los márgenes de las clases de equivalencia. La base de este argumento se fundamenta en la evidencia experimental de que la probabilidad de aparición de los errores es mayor en los extremos de los campos de entrada.

Las clases de equivalencia siguen el mismo esquema que el proceso anterior. Mientras que los casos de prueba de este método se generan de forma que cubran todas las condiciones límites de las clases de equivalencia.

Siguiendo esta evaluación, los casos de prueba del ejemplo anterior se corresponderían con

Conjetura de errores

Consiste en la elaboración de un listado de errores que no contemplan los métodos anteriores, y que generan a su vez nuevos casos de prueba.

Este caso contempla casos como intentar iniciar sesión con un correo electrónico no registrado, rellenar un formulario o registrar un usuario sin haber completado todos los campos obligatorios, entre otros.

Véase también

• Teoría de sistemas
• Modularidad
• Interfaz
• Interfaz de usuario
• Diseño estructurado
• Pruebas de software
• Caja blanca (sistemas)
• Abstracto y Abstracción
• Cajanegrizar

Esta página se editó por última vez el 17 nov 2023 a las 17:44.