Lección 3
Tipos de prueba
Hay varios tipos de pruebas y son demasiadas para mencionar en el presente curso, además la intención no es atiborrarlos de información que por la complejidad de las mismas no van a poder entender, por ejemplo hay pruebas de software que solo están enfocadas en mejorar el rendimiento del software a través del manejo adecuado de los recursos de hardware.
Por lo anterior en esta lección hablaremos de 2 tipos de pruebas.
Pruebas de caja blanca
La primera de la que hablaremos es la prueba de caja blanca, esta se basa en como diseñamos los casos de uso. Esta prueba también es conocida como caja de cristal. En la prueba de caja blanca el código de programación es fundamental, y se centraliza más en identificar que los bucles se ejecuten en sus límites operacionales, realizar los caminos de decisión tales como los if por las ramificaciones posibles con el fin de comprobar que en todas se consiga el resultado esperado.
A partir del código o del caso de uso se dibuja un diagrama de flujo como si estuviera realizándose antes de programar, pero el objetivo de este diagrama de flujo es el de ayudarnos a realizar las pruebas de escritorio con el objetivo de comprobar el funcionamiento adecuado.
Realizar una prueba de caja blanca parece relativamente fácil cuando son códigos cortos y sin muchas bifurcaciones pero supongamos que estamos ante un código con más de 900 líneas y con varios if anidados y varios ciclos ¿se complejiza la situación, cierto? Para esto tenemos el proceso de Complejidad Ciclomática
La complejidad ciclomática se define como una medición cuantitativa de complejidad lógica de un programo, en otras palabras nos dice la cantidad de caminos diferentes que tiene un código de software por medio de la siguiente formula.
v(G) = e – n + 2, donde e representa el número de aristas y n el número de nodos.
Un nodo es el circulo o cuadrado dentro de un diagrama de flujo, y una arista es la flecha o unión entre cada nodo.
Para el ejemplo anterior el cálculo de la complejidad ciclomática sería la siguiente
v(G) = 8 -7 + 2 = 3, siendo e = 8; n = 7
Entre mayor sea el resultado, mayor será el riesgo de que el código se vuelva inestable.
Pruebas de caja negra
Son complementarias a las pruebas de caja blanca y están diseñadas para tratar de descubrir diferentes tipos de errores a los encontrados en la caja blanca.
Las pruebas de caja negra permiten probar la funcionalidad del código a partir de unos datos y ver el resultado que estos arrojan y comprobar que el resultado arrojado sea el correcto, como su nombre lo dice, a la prueba no le importa lo que hay dentro de la caja, es decir no se enfoca en como se realiza el resultado sino en el resultado mismo y la interacción para llegar a este resultado.
Para la ejecución de la prueba de caja negra solo es necesario tener un dato de entrada y esperar la ejecución.
Supongamos que realizamos un desarrollo web de una calculadora y vamos a realizar la suma de 2 + 2, el resultado esperado es el 4 pero al realizar la prueba da un defecto y nos arroja por error 5. La caja negra no nos permitiría saber que esta mal con el código solo nos mostraría que hay algo malo con el código.