Prueba de caja gris

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]}

Descripción general

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]

Necesidad de pruebas de caja gris

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]

Supuestos de pruebas de caja gris para software orientado a objetos

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]

Ejemplos

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

Técnicas

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]

Efectos

Efectos positivos

• 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]

Efectos negativos

• 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]}

Aplicaciones

• 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]}

Alcance futuro

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.

Véase también

• Modelo de caja gris

Referencias

1. "Microsoft Research – Investigación sobre tecnología emergente, informática y software" (PDF) .
2. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 29 de marzo de 2012. Consultado el 17 de octubre de 2011 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
3. "Pruebas de caja gris". Fundamentos de pruebas de software. 4 de noviembre de 2011. Archivado desde el original el 16 de noviembre de 2021. Consultado el 19 de enero de 2012 .
4. "Ejemplo de prueba de caja gris con definición". Geekinterview.com . Consultado el 19 de enero de 2012 .
5. Jake Rogers (8 de agosto de 2016). "Preguntas frecuentes sobre las pruebas de caja gris". cgsec.co.uk . Consultado el 8 de agosto de 2016 .^{[ enlace muerto permanente ]}
6. "Extensiones orientadas a objetos para Pascal". Pascal-central.com. Archivado desde el original el 5 de junio de 2021. Consultado el 19 de enero de 2012 .
7. Patton, Ron (26 de julio de 2005). Pruebas de software . Sams. p. 2. ISBN 978-0-672-32798-8.
8. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 3 de abril de 2012. Consultado el 17 de octubre de 2011 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
9. Nguyen, Hung Q (2001). Pruebas de aplicaciones en la Web: planificación de pruebas para sistemas basados ​​en Internet . John Wiley & Sons. ISBN 9780471437642.
10. "Explore el mundo de las pruebas de caja gris". Extremesoftwaretesting.com . Consultado el 19 de enero de 2012 .
11. "Herramientas de prueba SOA para técnicas de prueba SOA de caja negra, blanca y gris". Crosschecknet.com. Archivado desde el original el 1 de octubre de 2018. Consultado el 19 de enero de 2012 .
12. "Prueba de caja gris E33.PDF" (PDF) .
13. Ramdeo, Anand (5 de mayo de 2011). "Pruebas de caja gris: software". Testing Geek . Consultado el 19 de enero de 2012 .
14. Bach, James (31 de diciembre de 2001). Lecciones aprendidas en pruebas de software. Wiley Computer Publishing. ISBN 978-0-471-08112-8.
15. Falk, Jack (12 de abril de 1999). Testing Computer Software, 2.ª edición. Wiley Computer Publishing. ISBN 978-0-471-35846-6.
16. http://legacy.cleanscape.net/docs_lib/paper_graybox.pdf ^{[ URL básica PDF ]}
17. Li, ZJ; Tan, HF; Liu, HH; Zhu, J.; Mitsumori, NM (6 de abril de 2010). "Pruebas SOA de caja gris impulsadas por procesos de negocio". IBM Systems Journal . 47 (3): 457–472. doi :10.1147/sj.473.0457.