thumb|320px|Esquema de una caja negra

La prueba de caja negra, test funcional o prueba comportamental, es un tipo de prueba de software directa, cuya finalidad es analizar la compatibilidad ente 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.

Condición entradaClases válidasClases no válidasIntervalo1 intervalo comprendido en el intervalo inicial2 intervalos fuera de rango, uno por debajo y otro por encimaValor específico1 clase que posea ese valor2 clases, un valor por debajo y otro por encimaConjunto de datos1 clase por cada elemento del conjunto1 clase de un elemento que no pertenezca al conjuntoCondición lógica1 clase que cumpla la condición1 clase que no cumpla la condición 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 ElementoClases equivalencia válidasClases equivalencia no válidasx[5,10](-,4] [11, )V[ ]array que cumpla longitud(V) = narray tal que longitud(V) != nn[1,5](-,0] [6, )C{Rojo} {Verde}conjunto al que no pertenezca ninguno de los anteriores valores

Y de esta forma los casos de test se corresponden con +xnV[ ]CValidez72V[1,2]RojoVálido72V[1,2]VerdeVálido12V[1,2]RojoNo válido152V[1,2]RojoNo válido72V[1,2,3]RojoNo válido70V[ ]RojoNo válido77V[1,1,2,1,3,2,1]RojoNo válido72V[1,2]AmarilloNo válido

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. Condición de entradaCasos de prueba válidosCasos de prueba no válidosIntervalo2 casos, uno con el valor máximo y otro con el valor mínimo2 casos, uno que ejecuta el valor justo por encima del máximo, y otro justo por encima del mínimoValor numérico1 caso que ejecute el valor concreto2 casos, uno justo por encima del valor y otro justo por debajoEstructura de datos2 casos que ejecuten el primer y último elemento de la estructura

Siguiendo esta evaluación, los casos de prueba del ejemplo anterior se corresponderían con xnV[ ]CValidez51VRojoVálido105V[1,3,2,3,2]VerdeVálido41VRojoNo válido111VRojoNo válido50V[ ]RojoNo válido56V[1,2,3,1,2,1]RojoNo válido

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

Categoría:Teoría de sistemas Categoría:Programación Categoría:Ingeniería Categoría:Principios de programación Categoría:Patrones de diseño Categoría:Cibernética