Prueba de caja gris

Sistemas de caja negra
Sistema
Caja negra , máquina Oracle
Métodos y técnicas
Prueba de caja negra , Blackboxing
Técnicas relacionadas
Retroalimentación , Ofuscación , Reconocimiento de patrones , Caja blanca , Pruebas de caja blanca , Pruebas de caja gris, Identificación del sistema
Fundamentos
Información a priori , Sistemas de control , Sistemas abiertos , Investigación de operaciones , Sistemas termodinámicos
en a mi

La prueba de caja gris (en inglés: grey-box testing ) es una combinación de la prueba de caja blanca y la prueba de caja negra . El objetivo de esta prueba es buscar defectos, si los hay, debidos a una estructura o un uso inadecuados de las aplicaciones. ^{[1] [2]}

Un tester de caja negra desconoce la estructura interna de la aplicación que se va a probar, mientras que un tester de caja blanca tiene acceso a la estructura interna de la aplicación. Un tester de caja gris conoce parcialmente la estructura interna, lo que incluye el acceso a la documentación de las estructuras de datos internas, así como a los algoritmos utilizados. ^[3]

Los probadores de caja gris requieren documentos tanto de alto nivel como detallados que describan la aplicación, que recopilan para definir los casos de prueba. ^[4]

Las pruebas de caja gris son beneficiosas porque toman la técnica sencilla de las pruebas de caja negra y la combinan con los sistemas orientados al código en las pruebas de caja blanca.

Las pruebas de caja gris se basan en la generación de casos de prueba de requisitos, ya que presentan todas las condiciones antes de que se pruebe el programa mediante el método de aserción. Se utiliza un lenguaje de especificación de requisitos para facilitar la comprensión de los requisitos y verificar su corrección. ^[5]

El software orientado a objetos se compone principalmente de objetos, donde los objetos son unidades individuales indivisibles que tienen código ejecutable y/o datos. A continuación se indican algunas suposiciones que son necesarias para la aplicación de las pruebas de caja gris.

• Activación de métodos ^[6]
• Informes estatales en clase bajo prueba (CUT).
• La prueba de informes es inherente a la clase bajo prueba. ^[5]

• Modelo arquitectónico
• Lenguaje de modelado unificado : modelo de diseño UML
• Máquina de estados finitos - Modelo de estados. ^{[7] [8]}

Cem Kaner define las "pruebas de caja gris" como aquellas que implican entradas y salidas, pero el diseño de las pruebas se basa en información sobre el código o el funcionamiento del programa que normalmente no estaría a la vista del evaluador. ^[9] Las técnicas de pruebas de caja gris son:

• Prueba matricial: establece el informe de estado del proyecto.
• Prueba de regresión : implica volver a ejecutar los casos de prueba si se realizan nuevos cambios.
• Prueba de patrones: verificar la buena aplicación por su diseño o arquitectura y patrones.
• Prueba de matriz ortogonal : se utiliza como subconjunto de todas las combinaciones posibles. ^[10]

• Ofrece beneficios combinados: como las pruebas de caja gris son una combinación de pruebas de caja blanca y caja negra, ofrecen ventajas de ambas pruebas.
• No intrusivo: se basa en la especificación funcional, la vista arquitectónica y no en el código fuente o binarios, lo que también lo hace invasivo.
• Creación de pruebas inteligentes: el probador de caja gris maneja escenarios de pruebas inteligentes, por ejemplo, manejo de tipos de datos, protocolo de comunicación y manejo de excepciones .
• Pruebas imparciales: a pesar de todas las ventajas y funcionalidades mencionadas anteriormente, las pruebas de caja gris mantienen el límite para las pruebas entre el evaluador y el desarrollador. ^[11]

• Cobertura parcial del código: en las pruebas de caja gris, faltan el código fuente o los archivos binarios debido al acceso limitado a la estructura o al interior de las aplicaciones, lo que genera un acceso limitado para atravesar la ruta del código.
• Identificación de defectos: en aplicaciones distribuidas, es difícil asociar la identificación de defectos. Sin embargo, las pruebas de caja gris son una gran ayuda para determinar con qué precisión estos sistemas generan excepciones y con qué precisión se gestionan estas excepciones en sistemas distribuidos que tienen un entorno de servicios web. ^{[11] [12]}

• Las pruebas de caja gris son muy adecuadas para aplicaciones web. Las aplicaciones web tienen redes o sistemas distribuidos; debido a la ausencia de código fuente o binarios, no es posible utilizar pruebas de caja blanca. Las pruebas de caja negra tampoco se utilizan debido a que solo se trata de un contrato entre el cliente y el desarrollador, por lo que es más eficiente utilizar pruebas de caja gris, ya que hay información importante disponible en el lenguaje de descripción de servicios web (WSDL). ^[13]
• Las pruebas de caja gris son adecuadas para pruebas funcionales o de dominio empresarial. Las pruebas funcionales se realizan básicamente como una prueba de las interacciones del usuario con sistemas externos. Las pruebas de caja gris son adecuadas para pruebas funcionales debido a sus características; también ayudan a confirmar que el software cumple con los requisitos definidos para el software. ^{[14] [15] [16] [17]}

La naturaleza distribuida de los servicios web permite que las pruebas de caja gris detecten defectos dentro de una arquitectura orientada a servicios (SOA). Como sabemos, las pruebas de caja blanca no son adecuadas para los servicios web, ya que tratan directamente con las estructuras internas. Las pruebas de caja blanca se pueden utilizar para métodos de última generación; por ejemplo, la mutación de mensajes que genera pruebas automáticas para matrices grandes para ayudar a gestionar estados de excepción, flujo sin código fuente ni binarios. Esta estrategia es útil para acercar las pruebas de caja gris a los resultados de las pruebas de caja blanca.

• Modelo de caja gris