• Il collaudo del software (testing) è un procedimento utilizzato per individuare problemi di correttezza, completezza e affidabilità del software
• Consiste nel valutare se il software rispetta i requisiti (specifiche) precedentemente definiti
• Non confondere il testing con
  • il debugging (individuazione dei bug)
  • il profiling (analisi complessità computazionale)
  • il benchmarking (misura delle prestazioni)

• Rispetto a cosa valutiamo correttezza o affidabilità di un programma?
• Idea del programmatore
  • Non formulata, non documentata
  • Incompleta, mutevole, facilmente dimenticata
• Specifiche (formali o informali)
  • Formulate, scritte, studiate e condivise
    → Parte del progetto e del programma
  • Spec. assiomatiche: espressioni logiche o asserzioni
    → Precondizioni, postcondizioni e invarianti

• Scovare bug non è un compito facile
  • Costoso: non è insolito dedicare al testing il 40% del tempo e delle risorse di un progetto
• Far emergere bug in prime fasi dello sviluppo!
  • B. Boehm: se trovare e correggere un problema in fase di specifica dei requisiti costa 1$...
  • 5$ in progetto, $10 in programmazione,
  • $20 in unit testing, fino a $200 dopo consegna
  • Bug possibili già a causa di specifiche non ben chiare e capite

• Il primo volo dell'Ariane 5 fallì e il razzo si autodistrusse per un malfunzionamento del software di controllo
• Un dato a 64 bit in virgola mobile venne convertito in un intero a 16 bit con segno, questa operazione causò una trap del processore
• Per motivi di efficienza i progettisti avevano disabilitato il controllo software sulle trap
• Fu necessario quasi un anno e mezzo per capire quale fosse stato il malfunzionamento e un danno stimato di 500.000.000$
• Video

• Il Mars Polar Lander fa parte di una coppia di sonde del Programma Mars Surveyor, assieme al Mars Climate Orbiter. La missione delle due sonde era di studiare la meteorologia, il clima e le quantità di acqua e di anidride carbonica del pianeta Marte.
• Le comunicazioni con il Mars Polar Lander si persero prima del suo ingresso nell'atmosfera marziana.
• La teoria piu' accreditata e' che un errore di software (una variabile non inizializzata) abbia fatto spegnere i motori ad una quarantina di metri di quota, per cui la sonda avrebbe impattato il suolo ad un centinaio di km/h.
• Le immagini sembrano confermare la teoria, mostrando il terreno contaminato dagli scarichi dei motori

• 1983, sfiorato il conflitto mondiale
  • Il sistema di allarme sovietico invia informazioni sbagliate e si sfiora la 3 guerra mondiale.
  • Colpa di un bug nel software del sistema di allarme che rileva cinque missili balistici in arrivo dagli Stati Uniti.
• 1990, il crollo della rete At&T
  • Un piccolo problema meccanico in una stazione della compagnia telefonica provoca la "caduta" di 75 milioni di telefonate.
  • Colpa di una linea di codice difettosa aggiunta durante un processo di upgrade del software.
  • L'American Airlines per colpa di questo bug ci rimette 200mila prenotazioni.

• Dimostrazione matematica di un programma: alternativa (~ accademica) al testing
  • Annotazione del programma con asserzioni matematiche: comportamento atteso
  • Proprietà valide per i vari costrutti del programma
• Prova che post-condizioni verificate, se:
  • Precondizioni verificate
  • Programma termina
• Dimostrazioni automatiche
  • Se a mano → errori (più che nel programma?)

• Analisi del codice (o pseudocodice) per capirne le caratteristiche e le funzionalità
• Code walk-through
  • Selezione porzioni di codice e valori di input
  • Simulazione su carta comportamento del sistema
• Code inspection, più formale e focalizzato
  • Uso di variabili non inizializzate
  • Loop infiniti
  • Letture di porzioni di memoria non allocata
  • Rilascio improprio della memoria

• Il test di un programma prevede l’esecuzione di una o più serie di test-case
• Struttura di un test-case
  • le precondizioni per la corretta esecuzione del caso
  • le azioni per l’esecuzione del caso
  • i risultati attesi dall’esecuzione e i criteri per dichiarare l’esito positivo o negativo

Le operazioni di testing possono individuare la presenza di errori nel software ma non ne possono dimostrare la correttezza. (E. Dijkstra)

Eseguire un programma con l'intento di trovare errori. (Glen Myers, “The art of Software Testing”)

• Verificare sistema in un insieme abbastanza ampio di casi... → plausibile comportamento analogo anche nelle restanti situazioni

• Black box testing – a scatola chiusa
  • si controllano solo i requisiti di funzionamento
• White box testing – a scatola aperta
  • si cerca di verificare ogni riga del codice

• Statement test
  • Insieme di test T tali che, eseguendo su tutti i casi di T il programma P, ogni istruzione di P venga eseguita almeno una volta
    • Normalmente viene testato il 60% dei possibili path interni a un software
    • Col supporto di test automatizzati si può arrivare all'85-90%
    • Il 100% è utopia ...
  • Branch test (copertura delle decisioni)
  • Branch & condition test (… condizioni)

• Scelto insieme minimo di percorsi per coprire tutte le istruzioni e condizioni (white box)
  • Tracciare diagramma di flusso
  • Astrarre il diagramma in un grafo di flusso
  • Complessità ciclomatica n = metrica di test
  • Trovare n casi di test che seguono ciascun cammino indipendente
• Cammino: sequenza di comandi, da inizio a fine
• Cammino indipendente: aggiunge almeno una nuova istruzione rispetto ai cammini già identificati

• Partizionamento ingressi in classi di equivalenza
  • Irrealistico testare tutti i possibili ingressi (es. sqrt)
  • Ipotesi: sufficiente testare un solo caso per classe
  • Si includono casi limite e valori non validi
  • Precondizioni: riducono il numero di casi di test

def swap_elements(v: list, i: int, j: int):
    '''
    Exchange element i and j in list v
    v: empty, one element, more elements
    i, j: one or both indexes out of range... or both in range: i < j, i > j, i = j
    '''
    # ...

• Scopo: trovare errori di regressione
  • Errori in un programma che prima era corretto, ed è stato modificato di recente
  • Un errore di regressione è un errore che prima non c’era
• Dopo la modifica di una parte P nel programma Q
  • Testare che la parte P funzioni correttamente
  • Testare che l’intero programma Q non sia stato danneggiato dalla modifica

• I test JUnit non richiedono continuo intervento o giudizio da parte dell'utente
• Facile eseguire molti test assieme, su un certo progetto
• Come definire un test:
  • Annotare un metodo di test con @org.junit.Test
  • Per controllare la validità di una espressione, usare assertTrue(boolean)
  • Import statico: import org.junit.Assert.*
  • Non è richiesto di estendere nessuna classe

assertArrayEquals(...) // Asserts that two arrays are equal.
assertEquals(...) // Asserts that two objects are equal.
assertFalse(...) // Asserts that a condition is false.
assertNotNull(...) // Asserts that an object isn't null.
assertNotSame(...) // Asserts that two objects do not refer to the same object.
assertNull(...)
assertSame(...)
assertTrue(...) // Asserts that a condition is true.
fail(...) // Fails a test

• Controllare che una pallina rimbalzi correttamente contro il bordo inferiore

@Test
public void testBounceDown() {
    Ball b = new Ball(8, 11); // dx = 1, dy = 1, w = 16, h = 12
    b.move();
    assertTrue(b.getX() == 9 && b.getY() == 10);
}

• CppUnit is the C++ port of the famous JUnit framework for unit testing.
• Test output is in XML or text format for automatic testing and GUI based for supervised tests.
• If assertion fails, an exception is thrown
• MACRO CppUnit ... #include
• CPPUNIT_ASSERT(condition):
• CPPUNIT_ASSERT_MESSAGE(message,condition):
• CPPUNIT_ASSERT_EQUAL(expected,current):
• CPPUNIT_ASSERT_EQUAL_MESSAGE(message,expected,current):
• CPPUNIT_ASSERT_DOUBLES_EQUAL(expected,current,delta):

• Indentation
• Breaking long lines and strings
• Placing Braces and Spaces
• ...
• Functions
• Commenting

"This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won't force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too. Please at least consider the points made here. First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture [Linus Torvalds]

Linux Kernel Coding Style

• Usare un debugger per valutare espressioni in fase di esecuzione
  • Si può decidere cosa valutare a seconda del flusso di esecuzione e dei valori generati, senza ricompilare
• Istruzioni di stampa all'interno del programma
  • Valore di espressioni scritto a console o su file di log
• Entrambi gli stili, scarsamente automatizzati
  • Necessità di intervento attivo durante l'esecuzione dei test
  • Giudizio dei risultati da parte dell'utente
  • Quali valori analizzare? Sono coerenti?
• Scarsamente componibili
  • Difficile controllare molte espressioni nel debugger
  • "Scroll blindness": troppe istruzioni di stampa ⇒ codice poco leggibile