white box testing complete guide with techniques
¿Qué son las pruebas de caja blanca?
Si nos atenemos a la definición, “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.
Lo que vas a aprender:
- Mi experiencia
- 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
- Tipos y técnicas de prueba de caja blanca
- Ejemplo de prueba de caja blanca
- Herramientas de prueba de caja blanca
- Conclusión
- Lectura recomendada
Mi experiencia
Ha pasado casi una década desde que me dediqué al campo de las pruebas de software y hasta ahora me di cuenta de que los probadores son los más entusiastas de toda la industria del software.
La razón principal detrás de esto es que el evaluador siempre tiene algo en su alcance para aprender. Ya sea un dominio, un proceso o una tecnología, un tester puede tener un desarrollo completo si lo desea.
Pero como dicen 'Siempre hay un lado más oscuro' .
Los probadores también evitan un tipo de prueba que consideran muy complicado y fácil para el desarrollador. Sí, la 'Prueba de caja blanca'.
Cobertura
White Box Testing es la cobertura de la especificación en el código:
1. Cobertura de código
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 donde se 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:
- 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.
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.
Lectura recomendada => Una guía completa para las pruebas de Black Box
Pasos para realizar WBT
Paso 1 - Comprender la funcionalidad de una aplicación a través de su código fuente. Lo que significa que un evaluador debe estar bien versado en el lenguaje de programación y las otras herramientas, así como las técnicas utilizadas para desarrollar el software.
Paso 2 - Cree las pruebas y ejecútelas.
Cuando hablamos del concepto de prueba, ' cobertura ”Se considera el factor más importante. Aquí explicaré cómo tener la máxima cobertura desde el contexto de las pruebas de caja blanca.
También leer=> Gráfico de causa y efecto - Técnica de escritura de casos de prueba dinámica para una cobertura máxima
Tipos y técnicas de prueba de caja blanca
Hay varios tipos y métodos diferentes para cada tipo de prueba de caja blanca.
Vea la imagen de abajo para su referencia.
Hoy nos vamos a centrar principalmente en el tipos de pruebas de ejecución de 'técnica de caja blanca de pruebas unitarias'.
3 técnicas principales de prueba de caja blanca:
- Cobertura de estados de cuenta
- Cobertura de sucursales
- Cobertura de ruta
Tenga en cuenta que la cobertura de la declaración, rama o ruta no identifica ningún error o defecto que deba solucionarse. Solo identifica aquellas líneas de código que nunca se ejecutan o que permanecen intactas. En base a esto, se pueden enfocar las pruebas adicionales.
Comprendamos estas técnicas una por una con un ejemplo simple.
# 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 ruda 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, Branch Coverage 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.
Tomemos un ejemplo simple para comprender todas estas técnicas de prueba de caja blanca.
También comprobar=> Diferentes tipos de pruebas
solicitando promoción en muestra de tasación
Ejemplo de prueba de caja blanca
Considere el siguiente pseudocódigo simple:
|_+_|Para Cobertura de estados de cuenta - Solo necesitaríamos un caso de prueba para verificar todas las líneas del código.
Eso significa:
Si considero TestCase_01 sea (A = 40 y B = 70), entonces se ejecutarán todas las líneas de código.
Ahora surge la pregunta:
- ¿Eso es suficiente?
- ¿Qué pasa si considero mi caso de prueba como A = 33 y B = 45?
Debido a que la cobertura de la declaración solo cubrirá el lado verdadero, para el pseudocódigo, solo un caso de prueba NO sería suficiente para probarlo. Como tester, también tenemos que considerar los casos negativos.
Por lo tanto, para una cobertura máxima, debemos considerar “ Cobertura de sucursales ” , que evaluará las condiciones “FALSAS”.
En el mundo real, puede agregar declaraciones apropiadas cuando la condición falla.
Entonces ahora el pseudocódigo se convierte en:
|_+_|Dado que la cobertura de la declaración no es suficiente para probar todo el pseudocódigo, necesitaríamos cobertura de sucursal para garantizar la máxima cobertura .
Entonces, para la cobertura de la sucursal, necesitaríamos dos casos de prueba para completar la prueba de este pseudocódigo.
TestCase_01 : A = 33, B = 45
TestCase_02 : A = 25, B = 30
Con esto, podemos ver que todas y cada una de las líneas del código se ejecutan al menos una vez.
Aquí están las Conclusiones que se derivan hasta ahora:
- La cobertura de sucursal garantiza más cobertura que la cobertura de estado de cuenta.
- La cobertura de sucursales es más poderosa que la cobertura de estados de cuenta.
- La cobertura del 100% de la sucursal en sí significa una cobertura del 100% del estado de cuenta.
- Pero la cobertura del estado de cuenta del 100% no garantiza la cobertura de la sucursal al 100%.
Ahora pasemos a Cobertura de ruta:
Como se dijo anteriormente, la cobertura de ruta se usa para probar los fragmentos de código complejos, que básicamente involucran declaraciones de bucle o una combinación de bucles y declaraciones de decisión.
Considere este pseudocódigo:
|_+_|Ahora, para garantizar la máxima cobertura, necesitaríamos 4 casos de prueba.
¿Cómo? Simplemente, hay 2 declaraciones de decisión, por lo que para cada declaración de decisión, necesitaríamos dos ramas para probar. Uno para verdadero y otro para la condición falsa. Entonces, para 2 declaraciones de decisión, necesitaríamos 2 casos de prueba para probar el lado verdadero y 2 casos de prueba para probar el lado falso, lo que hace un total de 4 casos de prueba.
Para simplificarlos, consideremos el siguiente diagrama de flujo del pseudocódigo que tenemos:
Para tener la cobertura completa, necesitaríamos los siguientes casos de prueba:
TestCase_01: A = 50, B = 60
TestCase_02 : A = 55, B = 40
TestCase_03: A = 40, B = 65
TestCase_04: A = 30, B = 30
Entonces el camino recorrido será:
Línea roja - TestCase_01 = (A = 50, B = 60)
Línea azul = TestCase_02 = (A = 55, B = 40)
Línea naranja = TestCase_03 = (A = 40, B = 65)
Línea verde = TestCase_04 = (A = 30, B = 30)
******************
=>> Contáctenos para sugerir su listado aquí
*****************
Herramientas de prueba de caja blanca
A continuación se muestra una lista de las principales herramientas de prueba de caja blanca.
# 1) Veracode
Las herramientas de prueba de caja blanca de Veracode lo ayudarán a identificar y resolver las fallas del software de manera rápida y sencilla a un costo reducido. Es compatible con varios lenguajes de aplicaciones como .NET, C ++, JAVA, etc. y también le permite probar la seguridad de las aplicaciones de escritorio, web y móviles. Aún así, hay varios otros beneficios de la herramienta Veracode. Para obtener información detallada sobre las herramientas de prueba de caja blanca de Veracode, consulte el siguiente enlace.
Enlace de página web: Veracode
# 2) EclEmma
EclEmma se diseñó inicialmente para pruebas y análisis dentro del banco de trabajo Eclipse. Se considera una herramienta de cobertura de código Java gratuita y también tiene varias características. Para instalar o saber más sobre EclEmma, consulte el siguiente enlace.
Enlace de página web: EclEmma
# 3) UNIDAD DE CONTROL
Un marco que se utiliza para probar programas C se conoce como RCUNIT. RCUNIT se puede utilizar en consecuencia según los términos de la licencia MIT. Es de uso gratuito y para instalarlo o saber más sobre él, consulte el siguiente enlace.
Python múltiples declaraciones if en una línea
Enlace de página web: RCUNIT
# 4) cfix
cfix es uno de los marcos de pruebas unitarias para C / C ++ que solo tiene como objetivo hacer que el desarrollo de conjuntos de pruebas sea lo más simple y fácil posible. Mientras tanto, cfix está típicamente especializado para el modo NT Kernel y Win32. Para instalar y saber más sobre cfix, consulte el siguiente enlace
Enlace de página web: cfix
# 5) Prueba de Google
Googletest es el marco de prueba de C ++ de Google. Prueba de descubrimiento, pruebas de muerte, pruebas con parámetros de valor, fallas fatales y no fatales, generación de informes de prueba XML, etc. son algunas de las características de GoogleTest, pero también hay varias otras características. Linux, Windows, Symbian, Mac OS X son algunas de las plataformas en las que se ha utilizado GoogleTest. Con el fin deDescarga, por favor revisa el siguiente enlace.
Enlace de descarga: Prueba de Google
# 6) EMMA
Emma es una herramienta de cobertura de código JAVA gratuita y fácil de usar. Incluye varias características y beneficios. Para descargar y saber más sobre Emma, consulte el siguiente enlace.
Enlace de descarga: EMMA
# 7) NUnit
NUnit es un marco de prueba unitario de código abierto fácil de usar que no requiere ninguna intervención manual para juzgar los resultados de la prueba. Es compatible con todos los lenguajes .NET. También admite pruebas basadas en datos y las pruebas se ejecutan en paralelo con NUnit. Las versiones anteriores de NUnit usaban la licencia NUnit, pero NUnit 3 se publica bajo la licencia MIT. Pero ambas licencias permiten el uso gratuito sin restricciones. Para descargar y saber más sobre NUnit, consulte el siguiente enlace.
Enlace de descarga: NUnit
# 8) Unidad Cpp
CppUnit es un marco de prueba unitario escrito en C ++ y se considera el puerto de JUnit. La salida de prueba para CppUnit puede estar en formato XML o de texto. Crea pruebas unitarias con su propia clase y ejecuta pruebas en los conjuntos de pruebas. Tiene licencia LGPL. Para descargar y saber más sobre CppUnit, consulte el siguiente enlace.
Enlace de descarga: CppUnit
# 9) JUnit
JUnit es un marco de prueba unitario simple y silencioso que admite la automatización de pruebas en el lenguaje de programación Java. Es principalmente compatible con el desarrollo basado en pruebas y también proporciona el informe de cobertura de prueba. Tiene licencia de Eclipse Public License. Para descarga gratuita y para saber más sobre JUnit, consulte el siguiente enlace.
Enlace de descarga: JUnit
# 10) JsUnit
Se considera que JsUnit es el puerto de JUnit a javascript. Y es un marco de prueba unitario de código abierto para admitir Javascript del lado del cliente. Tiene licencia GNU Public License 2.0, GNU Lesser Public License 2.1 y Mozilla Public License 1.1. Para descargar y saber más sobre JsUnit, consulte el siguiente enlace.
Enlace de descarga: JsUnit
Además, consulte todas las herramientas que hemos enumerado en Análisis de código estático aquí .
No dude en sugerir herramientas más simples o avanzadas que esté utilizando para la técnica de caja blanca.
Conclusión
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. :)
Háganos saber si tiene alguna pregunta sobre los métodos que discutimos en este artículo.
Lectura recomendada
- Diferencias clave entre las pruebas de caja negra y las pruebas de caja blanca
- Prueba de caja negra: un tutorial detallado con ejemplos y técnicas
- Pruebas funcionales versus pruebas no funcionales
- Mejores herramientas de prueba de software 2021 [Herramientas de automatización de pruebas de control de calidad]
- ¡Pensando fuera de la caja mientras prueba el software!
- Guía de pruebas de portabilidad con ejemplos prácticos
- Pruebas alfa y beta (una guía completa)
- Tipos de pruebas de software: diferentes tipos de pruebas con detalles
");jQuery('.end_h1').load(get_h1);jQuery('.last-art').unwrap();id = jQuery('.last-art').attr('id');//console.log('id = ',id);jQuery('#'+id).after(jQuery("
"));busy = false;var mLazyLoad = new LazyLoad({elements_selector: "[lazy='lazy']"});}, 1000);jQuery('.last-art').removeClass('last-art');jQuery('.end_h1').removeClass('end_h1');try {history.pushState(null, null, urls[atr]);return;}catch(e) {}};}}}
