1. Prueba de caja negra :
la prueba de caja negra es un tipo de prueba de software en la que se desconoce la funcionalidad del software. La prueba se realiza sin el conocimiento interno de los productos. También se le llama prueba funcional. Las pruebas de caja negra se centran en los atributos y el comportamiento externos del software. Este tipo de prueba analiza el comportamiento esperado del software de una aplicación desde el punto de vista del usuario.
2. Pruebas de caja blanca :
las pruebas de caja blanca o pruebas de caja de vidrio son una técnica de prueba de software que prueba el software utilizando el conocimiento de las estructuras de datos internas, el flujo lógico físico y la arquitectura a nivel de código fuente. Esta prueba funciona mirando las pruebas desde el punto de vista del desarrollador. Esta prueba también se conoce como prueba de caja de vidrio, prueba de caja transparente, prueba estructural o prueba no funcional.
3. Pruebas de Caja Gris :
Las Pruebas de Caja Gris son una combinación de la técnica de Pruebas de Caja Negra y la técnica de Pruebas de Caja Blanca en las pruebas de software. La prueba de caja gris implica entradas y salidas de un programa con fines de prueba, pero el diseño de la prueba se prueba utilizando la información sobre el código. Las pruebas de caja gris son muy adecuadas para las pruebas de aplicaciones web porque tienen en cuenta un entorno de diseño de alto nivel y las condiciones de interoperabilidad.
Veamos las diferencias tabulares entre ellos.
| Pruebas de caja negra | Pruebas de caja gris | Pruebas de caja blanca |
| Esta prueba tiene una granularidad baja. | Esta prueba tiene un nivel medio de granularidad. | Esta prueba tiene granularidad de alto nivel. |
| Lo realizan los usuarios finales y también los probadores, los desarrolladores. | Lo realizan los usuarios finales (llamado prueba de aceptación del usuario), también lo realizan los evaluadores y los desarrolladores. | Generalmente lo hacen probadores y desarrolladores. |
| Aquí, no se requiere que se conozcan los internos. | Aquí, se conocen los elementos internos relevantes para las pruebas. | Aquí se conoce el código interno de la aplicación y de la base de datos. |
| Es probable que sea menos exhaustivo que los otros dos. | Es una especie de intermedio. | El más exhaustivo de los tres. |
| Se basa en requisitos, casos de prueba en las especificaciones funcionales, ya que no se conocen las partes internas. | Proporciona una mejor variedad/profundidad en los casos de prueba debido al conocimiento de alto nivel de las partes internas. | Tiene la capacidad de ejercitar el código con una variedad relevante de datos. |
| Si se usa la prueba de algoritmos, no es el más adecuado para eso. | Si se usa la prueba de algoritmos, tampoco es el más adecuado para eso. | Si se usa la prueba de algoritmos, es el más adecuado para eso. |
| Es adecuado para pruebas funcionales o comerciales. | Es adecuado para pruebas de dominio funcionales o comerciales en profundidad. | Se usa para todos. |
| Esta prueba implica validar las salidas para entradas dadas, la aplicación se prueba como una técnica de caja negra. | Aquí, tenemos una mejor variedad de entradas y la capacidad de extraer los resultados de las pruebas de la base de datos para compararlos con los resultados esperados. | Implica pruebas estructurales y permite cobertura lógica, decisiones, etc. dentro del código. |
| Esto también se denomina prueba de caja opaca, prueba de caja cerrada, prueba de entrada-salida, prueba basada en datos, prueba de comportamiento, prueba funcional | Esto también se llama prueba de caja translúcida. | Esto también se denomina prueba de caja de vidrio, prueba de caja transparente, prueba basada en diseño, prueba basada en lógica, prueba estructural, prueba basada en código. |
Publicación traducida automáticamente
Artículo escrito por tarunsinghwap7 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA