¿Qué es el gris? Box ¿Pruebas? Técnicas, ejemplo

⚡ Resumen inteligente

Gris Box Las pruebas examinan una aplicación con un conocimiento parcial de su estructura interna, combinando la perspectiva del usuario propia de las pruebas de caja negra con suficiente conocimiento arquitectónico para explicar por qué se produjo un fallo, en lugar de simplemente afirmar que se produjo.

🔍 Nivel de conocimiento: La estructura interna se conoce parcialmente, a diferencia de las pruebas de caja blanca, donde se conoce completamente, y de las pruebas de caja negra, donde se desconoce.
🧪 Cuatro técnicas: Las pruebas matriciales, las pruebas de regresión, las pruebas de matrices ortogonales y las pruebas de patrones conforman el conjunto de herramientas básicas.
🪜 Diez pasos: Identifique las entradas, las salidas y las rutas principales, luego divida el sistema en subfunciones y verifique cada una de ellas.
🔗 Mejores ajuste: Pruebas de integración, pruebas de penetración, flujos de trabajo basados en bases de datos, servicios web y API.tracTs
🇧🇷 Compensación: La visibilidad parcial reduce el esfuerzo, pero también limita la profundidad con la que se puede desarrollar cualquier ruta de código. traced.
📋 Pre requisitos: Es fundamental contar con una documentación de diseño precisa, ya que un esquema o especificación obsoleta invalida silenciosamente el diseño de la prueba.

Descubre más

¿Qué es el gris? Box ¿Pruebas?

Gris Box Pruebas (también escrito Gray) Box Las pruebas de software (Grey Testing) son una técnica de prueba de software que prueba un producto o aplicación de software con conocimiento parcial de la estructura interna de la aplicación. El propósito de Grey Testing es... Box Las pruebas consisten en buscar e identificar defectos causados por una estructura de código inadecuada o un uso incorrecto de la aplicación.

En este proceso, se suelen identificar errores específicos del contexto relacionados con los sistemas web. La técnica aumenta prueba de cobertura al concentrarse en todas las capas de un sistema complejo en lugar de en una sola de ellas.

Gris Box Las pruebas son un método de prueba de software que combina Blanco Box Pruebas y Negro Box PruebasLa distinción entre los tres radica en la cantidad de estructura interna que el evaluador puede observar:

En blanco Box Se conoce la forma de probar la estructura interna (código).
En negro Box Se desconoce cómo se está probando la estructura interna (código).
En gris Box Se conoce parcialmente la estructura interna (código) a la que se está probando.

El diagrama que aparece a continuación sitúa los tres métodos en la misma escala de visibilidad.

In Ingeniería de software, Gris Box Las pruebas permiten probar ambos lados de una aplicación, la capa de presentación y el código subyacente. Son principalmente útiles en pruebas de integración y pruebas de penetración.

Ejemplo de gris Box Pruebas: Al probar una función de un sitio web, como enlaces o enlaces huérfanos, si el evaluador encuentra un problema con estos enlaces, el cambio se puede realizar de inmediato en el código HTML y verificarse en tiempo real.

¿Por qué gris? Box Pruebas

Gris Box Las pruebas se realizan por los siguientes motivos:

Ofrece las ventajas combinadas de las pruebas de caja negra y las pruebas de caja blanca.
Combina las aportaciones de los desarrolladores y de los evaluadores, y mejora la calidad general del producto.
Reduce la complejidad del largo proceso de prueba de tipos funcionales y no funcionales.
Esto le da al desarrollador suficiente tiempo libre para corregir los defectos.
Las pruebas se realizan desde el punto de vista del usuario, no desde el del diseñador.
Un fallo puede explicarse en lugar de simplemente informarse, porque el evaluador puede ver la capa en la que se produjo.

Gris Box Pruebas vs Negro Box contra Blanco Box Pruebas

Los tres métodos no son tanto alternativas que compiten entre sí, sino más bien tres niveles de acceso, y cada uno responde a un tipo de pregunta diferente. Al compararlos, la elección se vuelve más concreta.

Base	Negro Box Pruebas	Gris Box Pruebas	Blanco Box Pruebas
Conocimiento de la estructura interna	Ninguna	Parcial	Pleno
Interpretado por	Probadores y usuarios finales	Probadores y desarrolladores que trabajan con probadores.	Desarrolladores e ingenieros de pruebas
Base del diseño de pruebas	Requisitos y especificaciones	Archiarquitectura, algoritmos, estructuras de datos e interfaces	Código fuente y flujo de control
Nivel típico	Pruebas del sistema y de aceptación	Pruebas de integración, penetración y servicios web	Pruebas unitarias y de componentes
Cobertura medida como	Cobertura de requisitos	Cobertura de interfaz, datos y rutas	Declaración, cobertura de ramales y rutas
Limitación principal	La causa de un fallo permanece oculta.	La profundidad está limitada por el acceso concedido.	Costoso y puede que no cumpla con ciertos requisitos.

La mayoría de los equipos utilizan los tres en todo el ciclo de vida de las pruebas de softwarey la capa de la caja gris es donde generalmente se detectan los defectos que se producen entre la interfaz de usuario y el almacenamiento de datos.

Gris Box Estrategia de prueba

Para realizar Grey Box Para realizar pruebas, no es necesario que el evaluador tenga acceso al código fuente. Una prueba se diseña a partir del conocimiento de los algoritmos, las arquitecturas, los estados internos u otras descripciones de alto nivel del comportamiento del programa.

Para realizar Grey Box Pruebas:

Aplica las técnicas sencillas de las pruebas de caja negra.
Se basa en la generación de casos de prueba en función de los requisitos, por lo que preestablece todas las condiciones antes de que el programa sea probado mediante el método de aserción.

Técnicas utilizadas para Grey Box Las pruebas son:

Pruebas de matriz: Esta técnica consiste en definir todas las variables que existen en el programa, junto con el riesgo que conlleva cada una, de modo que se puedan visualizar las variables no utilizadas y las de alto riesgo.
Pruebas de regresión: Comprueba si un cambio en la versión anterior ha provocado una regresión en otros aspectos del programa en la nueva versión. Esto se realiza mediante estrategias como volver a probar todo, volver a probar los casos de uso de riesgo y volver a probar dentro de un cortafuegos.
Pruebas de matrices ortogonales o OAT: Proporciona la máxima cobertura de código con un número mínimo de casos de prueba.
Prueba de patrones: realizado sobre datos históricos de defectos previos del sistema. A diferencia de las pruebas de caja negra, Grey Box Las pruebas analizan el código y determinan por qué se produjo el fallo.

Gris Box La metodología suele utilizar sistemas automatizados. herramientas de prueba de software Para realizar las pruebas, se crean módulos auxiliares y controladores de módulos para que el evaluador no tenga que generar el código manualmente.

Pasos para realizar Grey Box Las pruebas son:

Paso 1: Identificar las entradas.
Paso 2: Identificar los resultados.
Paso 3: Identificar las rutas principales.
Paso 4: Identificar las subfunciones.
Paso 5: Desarrollar las entradas para las subfunciones.
Paso 6: Desarrollar los resultados para las subfunciones.
Paso 7: Ejecutar el caso de prueba para las subfunciones.
Paso 8: Verifique que el resultado de las subfunciones sea correcto.
Paso 9: Repita los pasos 4 a 8 para las demás subfunciones.
Paso 10: Repita los pasos 7 y 8 para las demás subfunciones.

Los casos de prueba para Grey Box Las pruebas pueden abarcar aspectos de la interfaz gráfica de usuario (GUI), seguridad, base de datos, navegador y sistema operativo, entre otros. Cada caso generado aún necesita lo habitual. caso de prueba atributos, ya que un caso que no se puede reproducir a partir de su propia descripción es de poca utilidad durante la regresión.

Donde Gris Box Se utilizan pruebas

Esta técnica resulta útil siempre que un defecto solo pueda diagnosticarse examinando dos capas simultáneamente. Los siguientes son los escenarios en los que se aplica con mayor frecuencia:

Flujos de trabajo basados en bases de datos: Se realiza una acción a través de la interfaz de usuario y, a continuación, se consultan directamente las filas resultantes para confirmar que los valores, los tipos y las relaciones se almacenaron según lo previsto.
Servicios web y API: Se envía una solicitud y se comprueba el estado de la respuesta, los encabezados y la carga útil con respecto a la configuración publicada.tract, que es la forma cotidiana de Pruebas de API.
Puntos de integración: Los mensajes que cruzan el límite entre dos módulos se inspeccionan mientras ambos módulos se tratan como sistemas en ejecución en lugar de como archivos fuente.
Evaluación de seguridad: Un probador de penetración, al que se le proporciona una cuenta de usuario normal y una descripción general de la arquitectura, reproduce la posición de un empleado interno, que es el modelo estándar de participación de caja gris.
Aplicaciones web e interfaces gráficas de usuario (GUI): Los enlaces rotos, las páginas huérfanas, la gestión de sesiones y la validación del lado del cliente se comprueban con visibilidad parcial del marcado y del flujo de la solicitud.

En todos estos casos, el costo general de los defectos del sistema se reduce porque los problemas se detectan y explican antes de que pasen a etapas posteriores del proceso. prueba del sistema o producción.

Gris Box Herramientas de prueba

Ninguna herramienta realiza Grey Box Pruebas por sí solas. Lo que necesita esta categoría es una combinación de un controlador de interfaz, una herramienta de inspección para la capa subyacente y una forma de programar ambas funciones juntas.

Clientes de API y servicios web como Postman y SoapUI, utilizado para emitir solicitudes y afirmar códigos de estado y cuerpos de respuesta.
Clientes de bases de datos y herramientas de consulta SQL, utilizado para verificar el estado persistente después de una acción de interfaz.
Herramientas para desarrolladores de navegadores y proxies HTTP como Burp Suite, utilizado para inspeccionar y modificar solicitudes durante sesiones orientadas a la seguridad.
marcos de automatización de interfaz de usuario como Selenium, utilizado para controlar la capa de presentación dentro de un pruebas de automatización sucesivamente.
Herramientas de registro y monitorización, utilizado para correlacionar un fallo observado con lo que la aplicación registró internamente en ese momento.

La elección importa menos que el cableado: a menos que el controlador de la interfaz y el paso de inspección se ejecuten en el mismo flujo programado, el resultado serán dos comprobaciones manuales separadas en lugar de una única prueba de caja gris.

Gris Box Desafíos de prueba

La visibilidad parcial introduce problemas que ninguno de los métodos puros presenta, y los siguientes son los que los equipos encuentran con mayor frecuencia:

Cuando un componente que se está probando encuentra algún tipo de fallo, puede abortar la operación en curso y dejar el resto de la secuencia sin ejecutar.
Una prueba puede ejecutarse por completo aunque el contenido del resultado sea incorrecto, por lo que el paso de verificación debe comprobar los valores en lugar de la finalización.
No es posible lograr una cobertura completa del código, ya que el evaluador nunca ve todas las ramas a las que llegaría una prueba de caja blanca.
La documentación de diseño en la que se basan las pruebas puede estar desactualizada, y un esquema o especificación de interfaz obsoletos invalidan silenciosamente el diseño de la prueba.
Los evaluadores necesitan tanto conocimiento del dominio como profundidad técnica, lo que supone un perfil de habilidades más específico a la hora de contratar personal.
Distribuido y muy abs.tracLas arquitecturas complejas dificultan atribuir un fallo observado a un componente interno específico.

Estas limitaciones justifican el tratamiento de Grey Box Las pruebas como una capa entre varias en lugar de un reemplazo para las demás, que es el punto que se plantea en el conjunto más amplio de técnicas de prueba de software y tipos de pruebas de softwareSe asienta naturalmente al lado prueba funcional y enfoques basados en especificaciones como pruebas basadas en modelos.

Preguntas Frecuentes

Ambos términos se refieren a la misma técnica. Grey es la grafía británica y gray la estadounidense, y ambos aparecen indistintamente en la documentación de herramientas y los programas de certificación. Ninguno conlleva un significado técnico diferente.

Basta con razonar sobre los aspectos internos sin leer cada línea: diagramas de arquitectura, el modelo de datos, la interfaz.tracts y una cuenta de solo lectura en la base de datos de prueba. El acceso completo al repositorio convierte el ejercicio en una prueba de caja blanca.

Por lo general, participa un ingeniero de pruebas con experiencia en desarrollo, o un probador que trabaja junto a un desarrollador durante la sesión. Las pruebas de seguridad las realizan probadores de penetración a quienes se les proporciona una cuenta de usuario estándar y una sesión informativa sobre la arquitectura del sistema.

En lugar de sentencias, nos centramos en las interfaces y los datos: se ejercitaron todos los puntos finales y códigos de estado, se exploró cada tabla y transición de estado, se recorrió cada ruta de integración. Los porcentajes de sentencias y bifurcaciones pertenecen a la medición de caja blanca.

Un stub representa un componente al que llama el módulo bajo prueba; un controlador representa el componente que lo llamaría. Juntos, permiten que una subfunción se ejecute de forma aislada antes de que exista el sistema completo.

Cuando se requiere un veredicto independiente desde la perspectiva del usuario, dado que el conocimiento parcial predispone al evaluador hacia las rutas esperadas, las pruebas de aceptación y el análisis de usabilidad siguen siendo de caja negra precisamente por esa razón, mientras que el código crítico para la seguridad aún requiere un análisis completo de caja blanca.

El aprendizaje automático analiza el historial de defectos para la fase de prueba de patrones, clasifica las interfaces según el riesgo previsto para que el acceso limitado se utilice correctamente y agrupa los registros para vincular un fallo observado con el componente interno que lo produjo.

Sí, para las partes repetitivas: constructores de solicitudes, aserciones de respuesta, consultas de verificación, stubs y controladores elaborados a partir de una definición de interfaz. Decidir qué estado interno demuestra que el comportamiento es correcto sigue siendo una cuestión de criterio de diseño para el ingeniero.