Pruebas de caja blanca

Pruebas de caja blanca (también conocido como prueba de caja clara, prueba de caja de vidrio, prueba de caja transparente, y pruebas estructurales) es un método de prueba de software que prueba las estructuras internas o los trabajos de una aplicación, en lugar de su funcionalidad (es decir, pruebas de caja negra). En pruebas de caja blanca, se utiliza una perspectiva interna del sistema para diseñar casos de prueba. El equipo elige entradas para el ejercicio de caminos a través del código y determina los productos esperados. Esto es análogo a los nodos de prueba en un circuito, por ejemplo, pruebas en circuito (TIC). Las pruebas de caja blanca se pueden aplicar en los niveles de unidad, integración y sistema del proceso de prueba de software. Aunque los probadores tradicionales tienden a pensar que las pruebas de caja blanca se hacen a nivel de unidad, se utiliza para la integración y las pruebas de sistema con más frecuencia hoy en día. Puede probar caminos dentro de una unidad, caminos entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de prueba puede descubrir muchos errores o problemas, tiene el potencial de perder partes no implementadas de la especificación o requisitos perdidos. Donde las pruebas de la caja blanca son diseñadas, es decir, impulsadas exclusivamente exclusivamente exclusivamente por especificaciones acordadas de cómo cada componente del software es requerido para comportarse (como en los procesos DO-178C e ISO 26262), las técnicas de prueba de caja blanca pueden realizar la evaluación de requisitos no aplicados o faltantes.

Las técnicas de diseño de pruebas de caja blanca incluyen los siguientes criterios de cobertura de código:

• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de la rama
• Cobertura por declaración
• Cobertura de las decisiones
• Cobertura modificada de las condiciones y la decisión
• Pruebas de primera ruta
• Pruebas de ruta

Descripción general

La prueba de caja blanca es un método para probar la aplicación al nivel del código fuente. Estos casos de prueba se derivan mediante el uso de las técnicas de diseño mencionadas anteriormente: pruebas de flujo de control, pruebas de flujo de datos, pruebas de rama, pruebas de ruta, cobertura de declaraciones y cobertura de decisiones, así como cobertura de condiciones/decisiones modificadas. La prueba de caja blanca es el uso de estas técnicas como pautas para crear un entorno libre de errores examinando todo el código. Estas técnicas de prueba de caja blanca son los componentes básicos de las pruebas de caja blanca, cuya esencia es la prueba cuidadosa de la aplicación a nivel de código fuente para reducir errores ocultos más adelante. Estas diferentes técnicas ejercitan cada ruta visible del código fuente para minimizar los errores y crear un entorno libre de errores. El objetivo de las pruebas de caja blanca es la capacidad de saber qué línea del código se está ejecutando y poder identificar cuál debería ser el resultado correcto.

Niveles

1. Pruebas de unidad. Las pruebas de caja blanca se realizan durante las pruebas unitarias para asegurar que el código esté funcionando según lo previsto, antes de que la integración ocurra con el código previamente probado. Las pruebas de la caja blanca durante las pruebas de unidad potencialmente atrapan muchos defectos temprano y ayudan a abordar los defectos que ocurren más adelante después de que el código se integra con el resto de la aplicación y por lo tanto reduce los impactos de errores más adelante en el desarrollo.
2. Pruebas de integración. Las pruebas de la caja blanca a este nivel están escritas para probar las interacciones de las interfaces entre sí. Las pruebas de nivel de unidad se aseguraron de que cada código se probara y se trabajara en consecuencia en un entorno aislado y la integración examina la corrección del comportamiento en un entorno abierto mediante el uso de pruebas de cajas blancas para cualquier interacción de interfaces conocidas por el programador.
3. Pruebas de regresión. Las pruebas de caja blanca durante las pruebas de regresión son el uso de casos de prueba de caja blanca reciclados en la unidad y niveles de pruebas de integración.

Procedimiento básico

Los procedimientos básicos de las pruebas de caja blanca requieren que el evaluador tenga un conocimiento profundo del código fuente que se está probando. El programador debe tener un conocimiento profundo de la aplicación para saber qué tipos de casos de prueba crear para que se utilicen todos los caminos visibles para las pruebas. Una vez que se comprende el código fuente, se puede analizar para crear casos de prueba. Los siguientes son los tres pasos básicos que siguen las pruebas de caja blanca para crear casos de prueba:

1. La entrada implica diferentes tipos de requisitos, especificaciones funcionales, diseño detallado de documentos, código fuente adecuado y especificaciones de seguridad. Esta es la etapa de preparación de pruebas de caja blanca para establecer toda la información básica.
2. Procesamiento implica realizar análisis de riesgo para guiar el proceso completo de prueba, plan de prueba adecuado, ejecutar casos de prueba y comunicar resultados. Esta es la fase de los casos de prueba de construcción para asegurarse de que prueban a fondo la aplicación los resultados dados se registran en consecuencia.
3. El resultado consiste en preparar el informe final que abarca todos los preparativos y resultados mencionados.

Ventajas

1. Los efectos secundarios de tener el conocimiento del código fuente son beneficiosos para las pruebas exhaustivas.
2. Optimización del código se vuelve fácil a medida que se exponen los cuellos de botella inconmovibles.
3. Da al programador introspección porque los desarrolladores describen cuidadosamente cualquier nueva implementación.
4. Proporciona trazabilidad de las pruebas de la fuente, permitiendo así que los cambios futuros a la fuente sean fácilmente capturados en las pruebas recién agregadas o modificadas.
5. Fácil de automatizar.
6. Proporciona reglas claras basadas en ingeniería para cuándo dejar de probar.

Desventajas

1. Las pruebas de caja blanca están escritas para probar los detalles de una implementación específica. Esto significa que los exámenes fallarán cuando la implementación cambie a medida que el test se acopla estrechamente a la implementación. Hay que hacer un trabajo adicional para actualizar las pruebas para que coincidan con la implementación de nuevo cuando se cambia. Por otro lado, con pruebas en caja negra, las pruebas son independientes de la implementación, por lo que seguirán funcionando con éxito si la implementación cambia, pero la salida o los efectos secundarios de la implementación no lo hacen.
2. El código en examen podría ser reescrito para implementar la misma funcionalidad de una manera diferente que invalida las suposiciones horneadas en la prueba. Esto podría resultar en pruebas que fallan innecesariamente o, en el peor de los casos, pruebas que ahora dan falsos positivos y errores de máscara en el código. La prueba de caja blanca nunca fue escrita de tal manera que prueba el comportamiento deseado del código bajo prueba, pero en cambio sólo tal que la implementación específica hace lo que hace.
3. Las pruebas de la caja blanca traen complejidad a las pruebas porque el probador debe tener conocimiento del programa, o el equipo de pruebas necesita tener al menos un programador muy bueno que pueda entender el programa a nivel de código. Las pruebas de la caja blanca requieren un programador con un alto nivel de conocimiento debido a la complejidad del nivel de pruebas que hay que hacer.
4. En algunas ocasiones, no es realista poder probar todas las condiciones existentes de la aplicación y algunas condiciones no serán comprobadas.
5. Las pruebas se centran en el software tal como existe, y es posible que no se descubra la funcionalidad que falta.

Vista moderna

Una visión más moderna es que la dicotomía entre las pruebas de caja blanca y las pruebas de caja negra se ha desdibujado y se está volviendo menos relevante. Mientras que la "caja blanca" Originalmente significaba usar el código fuente, y caja negra significaba usar requisitos, las pruebas ahora se derivan de muchos documentos en varios niveles de abstracción. El verdadero punto es que las pruebas generalmente se diseñan a partir de una estructura abstracta como el espacio de entrada, un gráfico o predicados lógicos, y la pregunta es de qué nivel de abstracción derivamos esa estructura abstracta. Puede ser el código fuente, los requisitos, las descripciones del espacio de entrada o uno de las docenas de tipos de modelos de diseño. Por lo tanto, la "caja blanca/caja negra" la distinción es menos importante y los términos son menos relevantes.

Hacking

En las pruebas de penetración, las pruebas de caja blanca se refieren a un método donde un hacker de sombrero blanco tiene pleno conocimiento del sistema que está siendo atacado. El objetivo de una prueba de penetración de la caja blanca es simular un interior malicioso que tiene conocimiento y posiblemente credenciales básicas para el sistema de destino.