Dependencias y Objetivos en Compilación
$^ 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.
Ejemplo de Objetivos
- Objetivo: Enlazar los archivos del proyecto basico1
- Comando: gcc –o basico1 main.o
- Objetivo: Compilar el archivo main.c del proyecto basico1
- Comando: gcc –c main.c
- Objetivo: Eliminar todos los ficheros generados
- Comando: clean: rm –f main.o
Opciones del Compilador
- -Wall: (warning all) muestra por pantalla todos los warnings 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.
- -i: especifica directorios adicionales para búsqueda de archivos de cabeceras.
Errores Comunes en Programación
- Errores Sintácticos: De acuerdo a un lenguaje de programación, triviales de detectar y corregir. El compilador hace la detección y avisa.
- Errores Estáticos: El código es sintácticamente correcto pero semánticamente incorrecto. Ejemplo: cambio de “>” por “<”.
Utilidades de Manejo de Caracteres
/**
* @brief Utilidades de manejo de caracteres
*
* Este módulo contiene los prototipos de las funciones de manejo de
* caracteres.
* @file utilcad.h
* @author Profesores PPROG
* @version 1.0
* @date 23-01-2015
*/
Pruebas de Software
- Pruebas de Caja Negra: Comprobar que para una entrada se obtiene la salida esperada sin examinar la lógica del módulo.
- Pruebas de Caja Blanca: 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. Esto 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.
Se deben realizar pruebas automatizadas para comprobar que todo el sistema software sigue funcionando como se espera después de realizar modificaciones.