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 funcionamientos 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 externa o de guerra cibernética sin saber que el sistema 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 pruebas generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada dada, 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, de su estructura interna ni 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 esa 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 las especificaciones, los requisitos y los 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 pruebas selecciona entradas válidas e inválidas y determina la salida correcta, a menudo con la ayuda de un oráculo de pruebas o un resultado anterior 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 tabla de decisiones , pruebas de todos los pares , particionamiento de equivalencia , análisis de valor límite , gráfico de causa-efecto , conjetura 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 pruebas 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 el que se ejecuta el código fuente de un programa cuando se ejecuta un conjunto de pruebas. [8] La medición de la cobertura de pruebas permite detectar y eliminar rápidamente los defectos, crear un conjunto de pruebas más completo y eliminar las pruebas que no son relevantes para los requisitos dados. [8] [9]
Las pruebas de caja negra pueden ser necesarias para asegurar una funcionalidad correcta, pero no son suficientes para protegerse contra situaciones complejas o de alto riesgo. [10] Una ventaja de la técnica de caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan tener 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 una 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 haberse probado con un solo caso de prueba o deja algunas partes del programa sin probar.