Pruebas de Caja Blanca
¿Que es?
Las
pruebas de caja blanca se centran en diseñar casos de prueba, para la
comprensión de la estructura y lógica interna del sistema, por lo que su diseño
está fuertemente ligado al código fuente. En estas se dan evaluaciones de
pruebas dinámicas para la búsqueda de fallos en el software, además la prueba
de caja blanca se basa en un detallado examen y revisión del código con el fin
de conocer la lógica del software desarrollado.
De
tal forma que se puedan diseñar casos de prueba para la evaluación verdadera o
falsa de todas las sentencias que se ejecuten en el programa. Es por ello por
lo que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas
más importantes que se le aplican al software, logrando como resultado que
disminuya en un gran porciento(%) el número de errores existentes en los sistemas
y por ende una mayor calidad y confiabilidad.
Pero
a pesar de todas las ventajas que se pueden obtener de las pruebas de caja
blanca, hay que tener claro que no todos los errores de software se pueden
descubrir verificando todas las rutas de un programa, hay errores que se
descubren al integrar unidades del sistema y pueden existir errores que no
tengan relación con el código específicamente.
¡Pero!
Pero a pesar de todas las ventajas que se pueden obtener de
las pruebas de caja blanca, hay que tener claro que no todos los errores de
software se pueden descubrir verificando todas las rutas de un programa.
Hay errores que se descubren al integrar unidades del
sistema y pueden existir errores que no tengan relación con el código
específicamente.
Objetivo de la técnica
El objetivo de la técnica es diseñar casos de prueba para
que se ejecuten, al menos una vez, todas las sentencias del programa, y/o todas
las condiciones tanto en su vertiente verdadera como falsa.
Características
En
resumen, esta prueba usa la estructura de control del diseño procedimental para
obtener los casos de prueba. También conocidas como: como pruebas de caja de cristal o pruebas estructurales. Mediante
la prueba de la caja blanca se debe garantizar lo siguiente:
- Que se ejercita por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
- Que se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
- Que se ejecuten todos los bucles en sus límites operacionales.
- Que se ejerciten las estructuras internas de datos para asegurar su validez.
Ventajas
Es recomendable hacer estas pruebas, si se tiene la oportunidad,ya que por estas pruebas se conoce el funcionamiento interno de un sistema, lo que en el caso de la caja negra este funcionamiento se aísla los campos de un sistema (componentes), mientras que en la caja blanca se puede hacer una prueba a cada componente lo que en consecuencia puede llegar a da el funcionamiento de ese sistema o cómo es qué se trabaja.
Desventajas
Para hacer una prueba de caja blanca se debe tener mucho cuidado en examinar los componentes de un sistema ya que cualquier dato incorrecto o datos perdidos ya sea por no vistos o incorrecto uso puede llevar a un sistema al colapso y si el sistema no es ensamblado correctamente puede tenerse por seguro que el sistema no cumplirá o bien todas sus funciones o no las cumplirá correctamente o simplemente no las cumplirá. Estos es del punto de visto físico pero a estudiar un sistema del punto de vista logarítmico, solo se deben aislar los logaritmos e identificar su funcionamiento aparte y luego su funcionamiento como un todo.
Criterios
de coberturas
Puede ser impracticable
realizar una prueba exhaustiva de todos los caminos o sentencias de un
programa, ya que se han definido distintos criterios de cobertura lógica, que
permiten decidir qué sentencias o caminos se deben examinar con los casos de
prueba (basados en la cobertura):
- Técnicas de cobertura de caminos: Esta técnica se encarga de realizar una secuencia de sentencias desde el inicio hasta el fin del software. Para esta técnica se tiene en cuenta los siguientes criterios: Todos los caminos, Cobertura de sentencias, Ramas, etc.
- Técnicas de control de flujo: el análisis de control de flujo es una técnica para determinar las estructuras de control de un programa, estructurada de la siguiente forma: Decisión, Condiciones, Decisión/Condición y de Condición Múltiple.
- Técnicas de cobertura de ciclos, que es el tema a profundizar, respectivamente a lo que son las técnicas de prueba de caja blanca.
Cobertura
de ciclos
La Cobertura de ciclos es una técnica de Caja Blanca,
en donde el objetivo es verificar los ciclos de un programa software. Estas
técnicas se caracterizan por usar grafos para describir su funcionamiento.
Estos grafos siempre se componen de: Aristas, Nodos y Regiones.
Para realizar una evaluación del software con esta técnica se debe tener el código del programa, con el fin de buscar los algoritmos que contengan los ciclos para proceder a dibujar el grafo y poder identificar la lógica del código. Es importante tener en cuenta que hay diferentes tipos de ciclos.
- Simples.
- Anidados.
- Concatenados.
- Y No Estructurados.
- While.
- Repeat.
- For.
¿Usar esta técnica?
Para usar esta técnica es
importante tener el código del programa que estamos evaluando, buscando los
algoritmos que contengan los ciclos. Una vez seleccionados los segmentos de
código que contienen ciclos se procede a dibujar el grafo, esto se hace para poder
identificar el recorrido lógico del código. Con el grafo y el código se
identifica que criterio usar para aplicar pruebas. A continuación, se explican
los diferentes tipos de ciclos y sentencias que se usan como criterios para
evaluar ciclos.
1. Pruebas para Bucles simples: Estos ciclos son sencillos, generalmente tienen una
condición. Para probar estos ciclos tenemos unas reglas. Teniendo en cuenta que
n es el número de
iteraciones del ciclo:
- Pasar por alto el bucle.
- Pasar una sola vez.
- Pasar 2 veces por el bucle.
- Pasar m veces por el bucle, siendo m<n.
- Pasar n-1.
2. Pruebas para Bucles anidados:Estos
ciclos son aquellos que tienen un ciclo en su interior. Tenemos las siguientes
reglas:
- Comenzar con el bucle más interno, estableciendo los demás bucles a los valores mínimos.
- Llevar a cabo las pruebas de bucles simples para el bucle más interno, conservando los valores de iteración de los bucles más externos a los valores mínimos.
- Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los bucles más externos a sus valores mínimos.
- Continuar hasta que se hayan probado todos los bucles.
3. Pruebas para Bucles concatenados: Estos ciclos son
aquellos que tienen un ciclo en su interior, pero a diferencia del anterior
vuelve no hasta el inicio del ciclo externo, si no hasta si mismo. Para estos
hay que verificar que forma de concatenación tiene, si es concatenación independiente se prueba igual
que los bucles simples, pero si es concatenación no independiente, se
trata como bucles anidados.
4. Ciclos No Estructurados: Estos ciclos son
aquellos que utilizan programación no Estructurada. Para
este tipo de bucles se recomienda no hacer pruebas y replantearlos, pues son
una muy mala práctica de programación y seria altamente riesgoso para el
software.
Sentencias:
1. Sentencias de
ciclo While: A este tipo de sentencias, por teoría se
les deben aplicar como
mínimo 3 pruebas:
- De cero ejecuciones.
- De 1 ejecución.
- De más de 1 ejecución
2. Sentencias de
ciclo Repeat: A este tipo de sentencias, por teoría se
les deben aplicar como mínimo 2 pruebas:
- De 1 Ejecución.
- De más de 1 Ejecución.
3. Sentencias de
ciclo For: Con este aparentemente sería sencillo
sólo se tendría que hacer
1 prueba, pues él ya tiene el número de veces que se va ejecutar en
la cabecera, y las decisiones se pueden revisar con la técnica de cobertura de
ramas, pero el For tiene sus "trampitas", como que en su interior la variable
incremente más de lo debido, que existan Loop, Goto, Exit, Breaks, que
alteraría por completo el comportamiento del ciclo, por lo tanto, no podría
hablar de 1 prueba, si no de un número incalculable de pruebas.
Conclusión
Las diferentes técnicas de pruebas en caja blanca, son muy importantes para detectar de manera eficiente y practica los diferentes problemas u error que puede aparecer en el desarrollo del los proyectos, estas pruebas software nos permiten ejecutar un programa cuya intención principal es detectar errores presentes en el software con el fin de disminuirlos y obviamente corregirlos, de tal manera que se mejore la calidad con la que se producen los proyectos. Estas pruebas deben ser ejecutadas de manera planeada, las pruebas de caja blanca no solo evalúan el comportamiento del usuario con la interfaz, sino que busca errores en el código fuente, recordando que esta posee criterios basados en el contenido y la estructura del código. Para concluir, tenemos que tener algo muy claro, no es posible garantizar que un software o sistema falle, tan solo se puede realizar pruebas que disminuyan el riesgo.
Referencias Bibliográficas
Referencias Bibliográficas
[1] Andrades, J. B. (1 de
noviembre de 2012). Slideshare. Obtenido de Realizacion de pruebas:
https://es.slideshare.net/jabenitez88/8realizacion-de-pruebas-14981770
[2] Cano, J. E. (1 de
noviembre de 2013). Slideshare. Obtenido de cobertura de bucles. https://es.slideshare.net/juanestebanpuertacano/cobertura-de-bucles
[3] Carmona, C. R. (2 de
julio de 2013). Slideshare. Obtenido de Prueba caja blanca:
https://es.slideshare.net/cristalramirezcarmona/prueba-caja-blanca
[4] GAVIRIA, B. F. (2013). Universidad
del Valle. Obtenido de CLASE # 5 Tecnicas de Caja Blanca: https://campusvirtual.univalle.edu.co/moodle/pluginfile.php/480081/mod_resource/content/1/2013A_TPSW_Clase05_CajaBlanca.pdf
[5] López, R. (13 de enero de
2017). Slideshare. Obtenido de Estructuras repetitivas(while, for,
repeat): https://es.slideshare.net/RommelLpez/estructuras-repetitivaswhile-for-repeat
[6] Luna, J. M. (3 de junio
de 2009). ingenierogestion.blogspot.com. Obtenido de Pruebas de Caja
Negra y Caja Blanca:
http://ingenierogestion.blogspot.com/2009/06/pruebas-de-caja-negra-y-caja-blanca.html
Comentarios
Publicar un comentario