Depurar programas
30-09-2005 | Desarrollo |Que el software tiene fallos, lo sabe todo el mundo y lo que saben quienes se dedican a su desarrollo es lo imposible que resulta hacer que no salga ninguno.
Prácticas para intentar acercarse a la meta utópica de 0 fallos hay muchas:
- Buen análisis y diseño
- Escribir código limpio y sencillo
- Desarrollar tests unitarios
- Y… probar, probar y probar
Y a este último punto es al que quería llegar. Porque hacer pruebas no es una cosa trivial, hay que ser muy perspicaz y probar todas las combinaciones posibles, todas las guarradas que se nos ocurran.
En las pruebas hay un componente humano muy elevado, y por muchos tests utitarios y automatizados que se hagan no suplen la imaginación (o mala leche) de una persona, lo único que ayudan es a hacer menos tediosa la labor de pruebas. Hay que diseñarlos de forma que abarquen la mayor cantidad posible de situaciones, incluso las que pensamos que no se podrían llegar a dar, porque seguro que se darán (Murphy es así, que le vamos a hacer).
Si la aplicación a depurar trabaja con bases de datos, en los tests unitarios realizaremos cargas de las tablas para tener datos, esas cargas influiran en los resultados de los tests, por ello debemos diseñar las pruebas para que se ejecuten en diversos entornos: con datos, sin datos, con datos erroneos, con datos parciales, con una cantidad de datos enorme.
Además las pruebas previas pueden influir en las pruebas posteriores, por ejemplo, si ponemos datos en una tabla, puede ser que una prueba no falle porque hay datos, pero puede ser que falle precisamente porque hay datos.
Esto es como un laboratorio de bioquimica, hay que controlar el entorno para que los resultados sean fiables. Hay que aislar cada prueba del resto de pruebas para que no se produzcan, como dicen en CSI, contaminaciones.
01-10-2005 09:36
Es muy difícil cubrir todas las combinaciones posibles de pruebas, pero se intenta que es lo importante.
También a veces puede ser un problema de imaginación, de que no se nos ha ocurrido esta o aquella burrada que el usuario puede hacer, y que una vez analizada se convierte en un comportamiento posible y no en una burrada
07-10-2005 12:21
Para mí las pruebas son fundamentales. Además creo que es la única manera de garantizar un buen soft.
Y cierto que es muy difícil hacer una buena batería de pruebas. El equipo de pruebas – que debe ser personas diferentes a quienes desarrollan – tienen que tener conocimientos del dominio de la aplicación y de desarrollo de programas. A veces prefiero tener un desarrllador menos y una persona que se dedique a probar. Más vale entregar cosas que funcionen que mucho pero que nada funciones.
Lástima que esta percepción no la tenga todo el mundo.
09-10-2005 07:28
«Probar todas las combinaciones posibles» es imposible incluso para el programa más sencillo. Un programa que sólo tuviese dos enteros de 32 bits de entrada tendría 1.18e+19 combinaciones posibles; suponiendo que probar cada combinación llevase 1 milisegundo, en probar todas las combinaciones se tardarían ¡más de 58494 años! (Si no me he equivocado en los cálculos.)
Por eso existen técnicas de prueba como análisis de valores límite y pruebas de cobertura, para probar las combinaciones más importantes.
10-10-2005 07:32
Joaquín: Efectivamente, probar todo es imposible. Precisamente eso quería indicar, pero leyendo de nuevo el artículo, no queda claro del todo.