Las pruebas de caja negra, también conocidas como pruebas de comportamiento, son un método de pruebas de software en el que la estructura interna/diseño/implementación del elemento que se está probando no es conocida por el probador. Estas pruebas pueden ser funcionales o no funcionales, aunque normalmente son funcionales.
Definición de ISQB
- Pruebas de caja negra: Pruebas, funcionales o no funcionales, sin referencia a la estructura interna del componente o sistema.
- Técnica de diseño de pruebas de caja negra: Procedimiento para derivar y/o seleccionar casos de prueba basados en un análisis de la especificación, ya sea funcional o no funcional, de un componente o sistema sin referencia a su estructura interna.
- Funciones incorrectas o ausentes
- Errores de interfaz
- Errores en las estructuras de datos o en el acceso a la base de datos externa
- Errores de comportamiento o de rendimiento
- Errores de inicialización y de terminación
- Pruebas de integración
- Pruebas de sistema
- Pruebas de aceptación
- Partición de equivalencias: Es una técnica de diseño de pruebas de software que consiste en dividir los valores de entrada en particiones válidas e inválidas y seleccionar valores representativos de cada partición como datos de prueba.
- Análisis de valores límite: Es una técnica de diseño de pruebas de software que implica la determinación de los límites para los valores de entrada y la selección de valores que se encuentran en los límites y justo dentro/fuera de los límites como datos de prueba.
- Graficación Causa-Efecto: Es una técnica de diseño de pruebas de software que implica la identificación de los casos (condiciones de entrada) y los efectos (condiciones de salida), la producción de un gráfico Causa-Efecto y la generación de casos de prueba en consecuencia.
- Las pruebas se realizan desde el punto de vista del usuario y ayudarán a exponer las discrepancias en las especificaciones.
- El probador no necesita conocer los lenguajes de programación o cómo se ha implementado el software.
- Las pruebas pueden ser realizadas por un organismo independiente de los desarrolladores, lo que permite una perspectiva objetiva y evitar el sesgo de los desarrolladores.
- Los casos de prueba pueden ser diseñados tan pronto como las especificaciones estén completas.
- Sólo un pequeño número de posibles entradas pueden ser probadas y muchas rutas del programa quedarán sin probar.
- Sin especificaciones claras, que es la situación en muchos proyectos, los casos de prueba serán difíciles de diseñar.
- Las pruebas pueden ser redundantes si el diseñador/desarrollador de software ya ha ejecutado un caso de prueba.
- ¿Te has preguntado alguna vez por qué un adivino cierra los ojos cuando predice eventos? Así es casi el caso en las Pruebas de Caja Negra.
Tabla de contenidos
Elaboración
Este método se llama así porque el programa de software, a ojos del probador, es como una caja negra; dentro de la cual no se puede ver. Este método intenta encontrar errores en las siguientes categorías:
Ejemplo
Un probador, sin conocimiento de las estructuras internas de un sitio web, prueba las páginas web utilizando un navegador; proporcionando entradas (clics, pulsaciones de teclas) y verificando las salidas con el resultado esperado.
Niveles
El método de pruebas de caja negra es aplicable a los siguientes niveles de pruebas de software:
Cuanto más alto sea el nivel, y por tanto más grande y compleja sea la caja, más se utiliza el método de pruebas de caja negra.
Técnicas
Las siguientes son algunas técnicas que se pueden utilizar para el diseño de pruebas de caja negra.
Ventajas
Desventajas
Las Pruebas de Caja Negra se contrastan con las Pruebas de Caja Blanca. Lea las diferencias entre las Pruebas de Caja Negra y las Pruebas de Caja Blanca.
.
A medida que la industria del software se aleja del enfoque de desarrollo de software en cascada hacia el ágil, también DEBE aprender sobre las PRUEBAS ÁGILES.
.
Última actualización el 17 de septiembre de 2020 por STF