Pruebas con caja gris

El texto que sigue es una traducción defectuosa. Si quieres colaborar con Wikipedia, busca el artículo original y mejora esta traducción. Copia y pega el siguiente código en la página de discusión del autor de este artículo: {{subst:Aviso mal traducido|Pruebas con caja gris}} ~~~~

Las pruebas de caja gris (del inglés: Gray box testing) son una combinación de pruebas de caja blanca y pruebas de caja negra. El objetivo de este tipo de pruebas es buscar defectos debidos a una estructura incorrecta o al uso incorrecto de aplicaciones.

Una probador de caja negra no conoce la estructura interna de la aplicación probada, mientras que un probador de caja blanca tiene acceso a la estructura interna de la aplicación. Un probador de caja gris conoce parcialmente la estructura interna, la cual incluye acceso a la documentación de estructuras de datos internas así como a los algoritmos utilizados.

Los probadores de caja gris necesitan documentación que describa la aplicación tanto a nivel de detalle como a alto nivel, la cual reúnen para definir casos de prueba.^[1]​

Las pruebas de caja gris son útiles porque usan la técnica directa de las pruebas de caja negra y la combinan con los sistemas basados en código de las pruebas de caja blanca.

Las pruebas de caja gris están basadas en la generación de casos de prueba como requisitos porque así se presentan todas las condiciones antes de que el programa sea probado utilizando el método de las aserciones (asserts). Se usa un lenguaje de especificación de requisitos para que estos sean más fáciles de entender y verificar que son correctos.

El software orientado a objetos consiste principalmente en el uso de objetos, donde los objetos son unidades únicas indivisibles que contienen código ejecutable y/o datos. Algunas suposiciones que son necesarias para la aplicación de una prueba de caja gris se describen a continuación:

• Activación de Métodos.
• Estado Informando en la Clase En Pruebas (Class Under Test - CUT).
• Pruebas con informe es inherente a la Clase En Pruebas.

• Architectural model
• Unified Modeling Language - UML Design Model
• Finite-state machine - State Model.

Cem Kaner define las pruebas de caja gris como aquellas que "involucran entradas y salidas, pero en las que el diseño de las pruebas es mejorado con información sobre el código o el funcionamiento del programa de una manera a la que normalmente no tendría acceso el probador". Las técnicas de pruebas de caja gris son:

• Prueba de Matriz: indica el informe de estado del proyecto.
• Pruebas de regresión: implica volver a ejecutar los casos de prueba si se realizan nuevos cambios.
• Prueba de patrones: comprueban la buena aplicación para su diseño o la arquitectura y los patrones.
• Pruebas de matriz ortogonal: se utiliza como subconjunto de todas las combinaciones posibles.^[2]​

• Ofrece beneficios combinados: Como las pruebas de caja gris son una combinación de pruebas de caja blanca y pruebas de caja negra, tienen las ventajas de ambas pruebas.
• No intrusivo: Se basa en la especificación funcional y vista arquitectónica, y no en el código fuente o binarios que también son invasivos.
• Autoría de prueba inteligente: Un probador de caja gris maneja escenarios de prueba inteligentes, por ejemplo, el manejo de tipo de datos, protocolo de comunicación, manejo de excepciones.
• Prueba Imparcial: A pesar de todas las ventajas y funcionalidades anteriores, las pruebas de caja gris mantienen un límite para la prueba entre el probador y el desarrollador.

• Cobertura parcial de código: En las pruebas de caja gris, el código fuente o binarios no están disponibles debido al acceso limitado al sistema interno o la estructura de las aplicaciones que se traduce en un acceso limitado para el recorrido de ruta de código.
• Identificación de defectos: En aplicaciones distribuidas, es difícil asociar la identificación de defectos. Aun así, las pruebas de caja gris son una gran ayuda para encontrar la forma adecuada en que estos sistemas generan excepciones y que tan bien son manejadas estas excepciones en los sistemas distribuidos que tienen entorno de servicios Web.

• las pruebas de caja gris son adecuadas para aplicaciones web. Las aplicaciones Web tienen redes distribuidas o sistemas; debido a la ausencia de código fuente o binarios que no es posible utilizar las pruebas de caja blanca. las pruebas de caja negra tampoco se utilizan debido al contrato entre el cliente y el desarrollador, por lo que es más eficaz utilizar las pruebas de caja gris como información importante disponible en Web Services Despriction Language (WSDL).
• las pruebas de caja gris son adecuadas para las pruebas de dominio funcional o de negocio. Las pruebas funcionales se realizan básicamente como una prueba de las interacciones del usuario que puede ser con sistemas externos. las pruebas de caja gris están bien adaptadas para las pruebas funcionales, debido a sus características; También ayuda a confirmar que el software cumple con los requisitos definidos para el software.

La naturaleza distribuida de servicios Web permite realizar pruebas de caja gris para detectar defectos dentro de una arquitectura orientada al servicio (Service-oriented architecture - SOA). Como sabemos, las pruebas de caja blanca no son adecuadas para los servicios Web, ya que trata directamente con las estructuras internas. Las pruebas de caja blanca se puede utilizar para métodos de la técnica del estado; por ejemplo, la mutación de mensajes que genera las pruebas automáticas para grandes matrices para ayudar a los estados de control de excepciones, fluir sin código fuente o binarios. Esta estrategia es útil para encaminar las pruebas de caja gris más cerca de los resultados de las pruebas de caja blanca.

• Modelo de caja Gris