Errores comunes en programación y pruebas de software

$^ Se sustituye por todas las dependencias de una regla $< se sustituye por la primera dependencia de una regla $@ se sustituye por el objetivo de una regla # objetivo para enlazar los archivos del proyecto basico1 basico1 main.o gcc –obasico 1 main.o # objetiv para compilar el archiv main.c del proyecto basico1 main.o main.c gcc –c main.c # objetivo para eliminar todos los ficheros generados clean: rm=–f main. reglas: -wall: (warning all) muestra por pantalla todos los warning o avisos especificados por el compilador -ansi: no permite el uso de funciones no pertenecientes al estándar ansi c -c: compilación -o: necesaria para establecer el nombre del ejecutable salida, por defecto a.out -g: incluye en el ejecutable binario información necesaria para la depuración -help: muestra la ayuda -l: especifica librerías adicionales que van a ser enlazadas -o: especifica niveles de optimización de código -i: especifica directorios adicionales para búsqueda de archivos de cabeceras -l: especifica directorios adicionales para búsqueda de librerías valgrind innvalide write of size: acceso indebido a memoria; used of unitialized value, uso de variables no inicializadas. lagunas de memoria: 48 bytes in 1 blocks are definitely lost in loss record 1 of 1; liberar mem de forma incorr: invalid free. control versiones: carpeta: copiar la versión actual en una carpeta temporal posibles nombres: “old”, “temp”, “20150209” editar en la carpeta en caso de borrado accidental o necesidad de recuperar datos: acceder a la carpeta temporal desventajas: espacio en disco, frecuencia óptima, ¿qué ha cambiado?, a nivel de fichero duplicar el fichero que se va a editar posibles nombres: “file-01”, “file-01_sec1”, “file-20150209” editar el fichero en caso de borrado accidental o necesidad de recuperar datos: acceder a la versión anterior desventajas: frecuencia óptima, ¿qué ha cambiado? a nivel de fichero (más profesional) editar el fichero que interesa una vez terminado, se envía un correo (a una cuenta personal) con el fichero describiendo los cambios bonus: fecha y nombre de fichero pueden ir en asunto en caso de borrado accidental o necesidad de recuperar datos: acceder al correo y buscar desventajas: espacio en cuenta de correo, frecuencia óptima, internet diff identifica diferencias entre ficheros línea a línea merge une dos ficheros en uno, teniendo en cuenta la parte común y no común de los mismos Trazas: permiten analizar la ejecución para detectar errores e incongruencias Pruebas: creación de escenarios que fuerzan situaciones específicas para comprobar que la ejecución es la deseada bajo ese escenario ERRORES Sintácticos De acuerdo a un lenguaje de programación Triviales de detectar y corregir El compilador hace la detección y avisa Estáticos El código es sintácticamente correcto pero semánticamente incorrecto P.e. cambio de “>” por “ DOXXY /** * @brief Utilidades de manejo de caracteres * * Este modulo contiene los prototipos de las funciones de manejo de * caracteres. * @file utilcad.h * @author Profesores PPROG * @version 1.0 * @date 23-01-2015 */ EJEC Antes de ejecutar doxygen se recomienda crear el fichero de configuración Doxyfile: doxygen -g Para ejecutar doxygen: doxygen Doxyfile PRUEBAS Un: de caja negra (blackbox-testing): comprobar que para una entrada se obtiene la salida esperada sin examinar la lógica del módulo de caja blanca (whitebox-testing): se estudia qué pasos da el algoritmo y si los valores que han ido tomando los datos en cada caso han sido los correctos Pruebas de integración Prueban varias (o todas) unidades de código de forma conjunta Integración ¿Cómo? Una vez que todas las pruebas unitarias han pasado Los módulos funcionan correctamente de forma individual Hay que garantizar que conjuntamente no produzcan errores Aconsejable: Se deben realizar pruebas de integración incrementales a medida que se van probando que los módulos funcionan de forma individual Garantiza que no se introducen nuevos errores cuando se integran los módulos Pruebas de regresión Al modificar un sistema software se pueden introducir nuevos errores Es preciso no probar sólo el código nuevo/modificado sino garantizar el buen funcionamiento del resto del sistema Una pequeña modificación de una función puede tener efectos negativos en otras funciones y módulos del sistema. Pruebas automatizadas que deben realizarse para comprobar que todo el sistema software sigue funcionando como se espera después de realizar modificaciones