Las pruebas de caja negra, a veces denominadas pruebas basadas en especificaciones , [1] son un método de prueba de software que examina la funcionalidad de una aplicación sin examinar sus estructuras o funcionamiento internos. Este método de prueba se puede aplicar prácticamente a todos los niveles de prueba de software: unidad , integración , sistema y aceptación . Las pruebas de caja negra también se utilizan como método en las pruebas de penetración , donde un hacker ético simula un ataque de piratería informática externo o de guerra cibernética sin conocimiento del sistema que está siendo atacado.
Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [2] Este nivel de prueba generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada determinada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba.
No se requieren conocimientos específicos del código de la aplicación, estructura interna ni conocimientos de programación en general. [3] El evaluador sabe lo que se supone que debe hacer el software, pero no sabe cómo lo hace. Por ejemplo, el evaluador sabe que una entrada particular devuelve una salida determinada e invariable, pero no sabe cómo el software produce la salida en primer lugar. [4]
Los casos de prueba se construyen en torno a especificaciones y requisitos , es decir, lo que se supone que debe hacer la aplicación. Los casos de prueba generalmente se derivan de descripciones externas del software, incluidas especificaciones, requisitos y parámetros de diseño. Aunque las pruebas utilizadas son principalmente de naturaleza funcional , también se pueden utilizar pruebas no funcionales . El diseñador de la prueba selecciona entradas válidas e inválidas y determina la salida correcta, a menudo con la ayuda de un oráculo de prueba o un resultado previo que se sabe que es bueno, sin ningún conocimiento de la estructura interna del objeto de prueba.
Las técnicas típicas de diseño de pruebas de caja negra incluyen pruebas de tablas de decisión , pruebas de todos los pares , partición de equivalencia , análisis de valores límite , gráficos de causa-efecto , adivinanzas de errores , pruebas de transición de estado , pruebas de casos de uso , pruebas de historias de usuario , análisis de dominio y pruebas de sintaxis. . [5] [6]
La cobertura de la prueba se refiere al porcentaje de requisitos de software que se prueban mediante pruebas de caja negra para un sistema o aplicación. [7] Esto contrasta con la cobertura de código , que examina el funcionamiento interno de un programa y mide el grado en que se ejecuta el código fuente de un programa cuando se ejecuta un conjunto de pruebas. [8] Medir la cobertura de las pruebas permite detectar y eliminar rápidamente defectos para crear un conjunto de pruebas más completo . y eliminar pruebas que no sean relevantes para los requisitos dados. [8] [9]
Las pruebas de caja negra pueden ser necesarias para garantizar el funcionamiento correcto, pero son insuficientes para proteger contra situaciones complejas o de alto riesgo. [10] Una ventaja de la técnica de la caja negra es que no se requieren conocimientos de programación. Cualesquiera que sean los prejuicios que hayan tenido los programadores, es probable que el evaluador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como un paseo por un laberinto oscuro sin linterna". [11] Debido a que no examinan el código fuente, hay situaciones en las que un evaluador escribe muchos casos de prueba para verificar algo que podría haber sido probado por un solo caso de prueba o deja algunas partes del programa sin probar.