INTRODUCCION

“prueba de caja blanca” (también conocida como prueba transparente, de caja

de vidrio o estructural) es una técnica de prueba que evalúa el código y la
estructura interna de un programa.

Las pruebas de caja blanca implican observar la estructura del código. Cuando
se conoce la estructura interna de un producto, se pueden realizar pruebas
para garantizar que las operaciones internas se realizan de acuerdo con la
especificación. Y todos los componentes internos se han ejercitado
adecuadamente.

TEMAS SOBRE LA PRUEBA DE LA CAJA BLANCA


 Cobertura
 ¿Por qué realizamos WBT?
 ¿Esta prueba requiere habilidades de programación detalladas?
 Limitaciones
 Diferencia entre pruebas de caja blanca y caja negra
 Pasos para realizar WBT
 Conclusión

White Box Testing es la cobertura de la especificación en el código:

1. Cobertura de código
# 1) Cobertura de la declaración:
En un lenguaje de programación, una declaración no es más que la línea de
código o instrucción para que la computadora la comprenda y actúe en
consecuencia. Una instrucción se convierte en una instrucción ejecutable
cuando se compila y se convierte en el código objeto y realiza la acción cuando
el programa está en modo de ejecución.

Por eso 'Cobertura de la declaración' , como sugiere el propio nombre, es el

método para validar si todas y cada una de las líneas del código se ejecutan al
menos una vez.
# 2) Cobertura de sucursales:
'Rama' en un lenguaje de programación es como las 'declaraciones IF'. Una
instrucción IF tiene dos ramas: T verdadero y falso .
Entonces, en Cobertura de sucursales (también llamada Cobertura de
decisiones), validamos si cada sucursal se ejecuta al menos una vez.

En caso de una 'declaración IF', habrá dos condiciones de prueba:

 Uno para validar la verdadera rama y,
 Otro para validar la rama falsa.

Por lo tanto, en teoría Cobertura de sucursales: es un método de prueba

que, cuando se ejecuta, garantiza que se ejecuten todas y cada una de las
ramas desde cada punto de decisión.

# 3) Cobertura de ruta
La cobertura de ruta prueba todas las rutas del programa. Esta es una técnica
integral que asegura que todas las rutas del programa se recorran al menos
una vez. La cobertura de ruta es incluso más poderosa que la cobertura de
sucursal. Esta técnica es útil para probar programas complejos.

2.
2. Cobertura de segmento: Asegúrese de que cada declaración de código se
ejecute una vez.
3. Cobertura de rama o prueba de nodo: La cobertura de cada rama de
código de todas las posibles era.
4. Cobertura de condiciones compuestas: Para múltiples condiciones,
pruebe cada condición con múltiples rutas y una combinación de las diferentes
rutas para alcanzar esa condición.
5. Prueba de ruta básica: Cada ruta independiente en el código se toma para
probar.
6. Prueba de flujo de datos (DFT): En este enfoque, rastrea las variables
específicas a través de cada cálculo posible, definiendo así el conjunto de rutas
intermedias a través del código. DFT tiende a reflejar dependencias, pero es
principalmente a través de secuencias de manipulación de datos. En resumen,
se realiza un seguimiento de cada variable de datos y se verifica su uso. Este
enfoque tiende a descubrir errores como las variables utilizadas pero no
inicializadas, declaradas pero no utilizadas, etc.

7. Prueba de ruta: La prueba de ruta es dondese definen y cubren todas las

rutas posibles a través del código. Es una tarea que requiere mucho tiempo.

8. Prueba de bucle: Estas estrategias se relacionan con la prueba de bucles

únicos, bucles concatenados y bucles anidados. Este enfoque prueba los
valores y bucles de código independientes y dependientes.

¿Por qué realizamos WBT?

Para asegurar:
 Que todas las rutas independientes dentro de un módulo se hayan
ejercitado al menos una vez.
 Todas las decisiones lógicas verificadas sobre sus valores verdaderos y
falsos.
 Todos los bucles ejecutados en sus límites y dentro de sus límites
operativos validez de estructuras de datos internos.
Para descubrir los siguientes tipos de errores:
Ads by optAd360
  Los errores lógicos tienden a infiltrarse en nuestro trabajo cuando
diseñamos e implementamos funciones, condiciones o controles que están
fuera del programa.
 Los errores de diseño debidos a la diferencia entre el flujo lógico del
programa y la implementación real
 Errores tipográficos y comprobación de sintaxis

¿Esta prueba requiere habilidades de programación

detalladas?
Tenemos que escribir Casos de prueba que garantizan la cobertura completa
de la lógica del programa.
Para esto, necesitamos conocer bien el programa, es decir, debemos conocer
la especificación y el código a probar. Se requiere conocimiento de lenguajes
de programación y lógica para este tipo de pruebas.

Limitaciones
No es posible probar todas y cada una de las rutas de los bucles en el
programa. Esto significa que las pruebas exhaustivas son imposibles para
sistemas grandes.

Ads by optAd360

Esto no significa que WBT no sea eficaz. La selección de rutas lógicas y

estructuras de datos importantes para las pruebas es prácticamente posible y
eficaz.
Diferencia entre pruebas de caja blanca y caja negra
Para ponerlo en términos simples:

En las pruebas de caja negra, probamos el software desde el punto de vista del
usuario, pero en la caja blanca, vemos y probamos el código real.

En las pruebas de caja negra, realizamos pruebas sin ver el código interno del
sistema, pero en WBT sí vemos y probamos el código interno.

Tanto los desarrolladores como los evaluadores utilizan la técnica de prueba

de caja blanca. Les ayuda a comprender qué línea de código se ejecuta
realmente y cuál no. Esto puede indicar que falta una lógica o un error
tipográfico, lo que eventualmente puede dar lugar a algunas consecuencias
negativas.

conclusion

Depender únicamente de las pruebas de caja negra no es suficiente para

obtener la máxima cobertura de prueba. Necesitamos tener una combinación
de técnicas de prueba de caja negra y caja blanca para cubrir defectos
máximos .

Si se hace correctamente, las pruebas de caja blanca ciertamente contribuirán

a la calidad del software. También es bueno para los probadores participar en
esta prueba, ya que puede proporcionar la opinión más 'imparcial' sobre el
código.