programación i - Universidad ORT Uruguay

78 Programación I
8.1.1.2 Caja Blanca
La prueba de caja blanca implica una revisión "dentro" del programa. Se define cobertura como
el grado de revisión del programa. Se puede hacer cobertura de sentencias, de decisiones o
caminos. En el caso de sentencias, se trata de asegurar que toda sentencia es ejecutada al menos
una vez. En el de decisiones se debe verificar que toda decisión alguna vez sea verdadera y
alguna vez sea falsa. En la de caminos, se trata de chequear que todos los caminos posibles en el
programa se dan alguna vez.
8.1.2 Prueba de métodos
Cuando se diseña un método, se puede realizar de dos formas: tratar de desarrollar desde el
comienzo la versión lo más completa posible o realizar aproximaciones sucesivas al método
final, desde una versión inicial simplificada. Así, se podría realizar una primera versión que
devuelva, por ejemplo, un valor constante, un cálculo mínimo o que le solicite al operador el
valor. Cuando se prueban los métodos debe tenerse en cuenta si ya es la versión final o una
intermedia. En el caso de tener versiones intermedias preliminares se tiene la ventaja de que se
puede ir avanzando en diferentes tareas y luego se completa; la desventaja es que interpretar los
resultados puede ser más complicado debido a esos valores ficticios. En el caso que se opte por
poner la versión definitiva, tiene la ventaja de que es más fácil revisar las salidas pero puede
demorarse más en tener la versión completa del sistema.
8.1.3 Pasos para encontrar errores
La depuración de un programa es algo no sistemático y no garantizado. Los pasos sugeridos
para encontrar/corregir errores son:
• Determinar el error;
• Ubicarlo en el programa;
• Corregirlo; y
• Verificarlo.
Se recomienda:
- Llevar un registro: ir anotando qué cosas se han probado, qué falta, qué se descarta, etc.
- Trabajar con listado del código fuente actualizado: en la medida que se realizan
modificaciones al programa y se van realizando anotaciones en los listados impresos, se
complica entender o descubrir errores, pues la versión en papel difiere con la real en la máquina.
- Guardar la versión anterior, antes de hacer "cambios geniales". Recordar guardar una versión
del código completo hasta ese momento.
- Pensar en la posibilidad de reescribir: a veces es más fácil y seguro reescribir el método
problemático que seguir corrigiendo errores sobre el mismo.
- Aprender de los resultados negativos: cuando se supuso que un error estaba en determinado
lugar y se comprueba que no es así, es un resultado negativo pero a su vez permite descartar ese
lugar como posible fuente del error.
¿Cómo se buscan?
- Pensar: analizar cuidadosamente qué es lo que pasa, en qué casos ocurre, descubrir la situación
que lo genera.
- Descansar: luego de dedicar un rato a tratar de entender que es lo que pasa, conviene "alejarse"
del código para luego, al retornar descansado, seguramente se encontrará el error;
- Pedir auxilio: recurrir a la ayuda de otro programador.
- Usar herramientas (debugger): hay software que permite realizar el seguimiento paso a paso
del programa, mostrando las variables y la secuencia de instrucciones que se van ejecutando.
Esta herramienta es útil si se ha pasado por las etapas de pensar, descansar y pedir auxilio. De