Vai al contenuto

Appunti del 16-03-2023⚓︎

test e debugging (di nuovo)⚓︎

test verifica sistematica della correttezza del SW.

debugging atto a scovare la causa di un errore.

supporto del compilatore⚓︎

alcuni compilatori emettono dei warning, ovvero messaggi di avvertimento, spesso non bloccanti

es.

C
1
2
if (a = 0) {} // va messo ==
x = x

altri esempi sono

  • nessun return
  • codice orfano
  • condizioni tautologiche

Backward reasoning⚓︎

quando si scopre un bug occorre pensare al contrario, partendo dal risultato occorre risalire alla catena delle cause che l'hanno portato. Una delle cause della catena sarà errata.

scrivere codice leggibile aiuta al Backward reasoning e quindi a localizzare i bug. bisogna avere uno stile di scrittura ben definito.

sviluppo incrementale⚓︎

testare le procedure man mano che vengono sviluppate. se i test hanno successo all'istante \(t\) ma falliscono all'istante \(t+1\), allora molto probabilmente i bug si annidano nel codice sviluppato tra \(t\) e \(t + 1\).

la progettazione modulare del codice aiuta a individuare meglio la posizione dei bug.

questo è più efficiente poiché oltre al poter mostrare subito al cliente un eventuale prototipo. è vantaggioso per lo sviluppo poiché ho un pezzo funzionante che viene messo da parte poiché funziona e non viene più toccato. per di più testare 2/2 funzioni occupa meno tempo che testarne molte di più.

  • esaminare codice simile;
  • non rimandare il debugging: se bug individuato allora elimina subito. trasferimento di un bug nei passi successivi del ciclo di sviluppo di un software fa crescere il costo di debugging;
  • leggere e spiegare il codice: leggere codice e comprenderne il significato. il codice è un pezzo di conoscenza che deve essere compreso dalla macchina e da chi la programma. spiegare il codice ad altri aiuta a ridurre "bias" cognitivi;

rendere riproducibile un bug⚓︎

individuare le tutte le condizioni che portano alla manifestazione del bug come input e altri parametri, condizioni della macchina, seed di numeri casuali, etc.

divide et impera⚓︎

individuare le condizioni minimali che rendono manifesto un bug. es. il più piccolo array, la str più breve il test dei casi limite è fondamentale.

ricerca di regolaità⚓︎

alcuni bug si presentano con regolarità, ma non sempre. il questo caso occorre il modello ("pattern") che genera la regolarità.

es. editor di testo salta la visualizzazione di alcuni caratteri, l'analisi del testo mostra che i caratteri saltati sono intervallati da 1023 char stampati. gli array che memorizzano le stringhe sono da 1024byte ovvero 1023 caratteri più il \0 → BUG.

stampe ausiliarie⚓︎

per segure l'exe di un programma può essere utile introdurre stampe ausiliarie valido soprattutto per situazioni che non possono essere traccaite da debugger

altre tecniche⚓︎

  • visualizzazioni grafiche
  • test statistici
  • strumenti di analisi del testo come
    • grep
    • diff

debugger⚓︎

un debugger guarda "dentro" il programma durante l'exe

  • tracing del programma
  • visualizzazione del contenuto delle varaibili
  • valutazione dinamica di espressioni
  • ha cambiato slide

un debugger ha bisogno di informazioni aggiuntive nel codice compilato, c'è un link tra il codice compilato ...

breakpoint⚓︎

un breakpoint interrompe iìflusso di exe su una linea selezionata. possono essere inseriti o rimossi e quelli inseriti possono essere attivati o disattivati.

categorie progetto⚓︎

  1. gestione di qualcosa
  2. gioco (mastermind, oca, battaglia navale)
  3. funzioni di sistema operativo (vecchi/semplici/editor di testo (ancora più semplice del notepad, EDLIN/EDIT)/operazioni che hanno a che fare col MS-DOS)
  4. c robots (no)

suggerimenti degli anni passati, si possono proporre altre.