Sergio Di Martino » 13.Il Processo di Testing

Obiettivi della lezione

• Comprendere i concetti di Verification & Validation
• Terminologia
• Tecniche per aumentare l’affidabilità del codice
• Inspection
• Testing
• I livelli di testing

Verification and Validation (V&V)

[Sommerville] Verification and Validation (V&V)
‘checking processes which ensure that software conforms to its specification (at each phase in the development) and meets the needs of the software customer’.

[Boehm'79]
Verification: “Have we built the product right”?
Validation: ” Have we built the right product”

La fase di verifica & validazione serve ad accertare che il software rispetti i requisiti e che li rispetti nella maniera dovuta.

Verifica: il software rispetta le specifiche?
E’ stato implementato tutto quello descritto nel documento dei requisiti?
Ho implementato correttamente tutte le funzionalità?
Da sola non basta.

Validazione (o convalida): il software rispetta ciò che voleva il cliente?
In altri termini: i requisiti modellano ciò che il cliente realmente voleva?
Questa fase è molto delicata in quanto, dopo tutto il processo si può ottenere un software perfettamente funzionante, senza errori, ma del tutto inutile in quanto non rispecchia quanto era stato chiesto all’inizio.

La verifica può essere statica, se effettuata su carta, o dinamica, se effettuata attraverso l’esecuzione del software.

Verifica e Convalida

Differenza tra Verifica e Validazione.

Terminologia di Verifica del Software

Affidabilità: La misura di successo con cui il comportamento osservato di un sistema è conforme ad una certa specifica del relativo comportamento.

Fallimento (failure): Qualsiasi deviazione del comportamento osservato dal comportamento specificato.

Stato di Errore (Errore): Il sistema è in uno stato tale che ogni ulteriore elaborazione da parte del sistema porta ad un fallimento.

Difetto (Bug/fault): La causa meccanica o algoritmica di un errore .

Ci sono molti tipi differenti di errori e molti modi per far fronte ad un errore.

Test e Casi di test

Si dice che un programma è “stressato” da un caso di test (insieme di dati di input), o “test case“.

Un test è formato da un insieme di test cases.

L’esecuzione del test consiste nell’esecuzione del programma per tutti i casi di test.

Un test ha successo se rileva uno o più malfunzionamenti del programma.

Problemi del testing: Test Esaustivo?

L'esempio mostra come non sia possibile effettuare test esaustivo, ma siano necessarie strategie più raffinate.

Verifica statica

Le tecniche di verifica possono essere divise in due macro-categorie:

1. Verifica Statica: il software NON viene eseguito
2. Verifica Dinamica: il software va in esecuzione.

La Verifica Statica è basata su tecniche di analisi statica del software senza ricorso alla esecuzione del codice.

Analisi statica: è un processo di valutazione di un sistema o di un suo componente basato sulla sua forma, struttura, contenuto, documentazione

Tecniche: review, ispezione, verifica formale, esecuzione simbolica, etc…

Verifica Statica: Le Review

Reviews: ispezione manuale del codice sorgente
Due tipi di review:

1. Walkthrough. Lo sviluppatore presenta informalmente le API, il codice, la documentazione associata delle componenti al team di review
2. Inspection. Simile al walkthrough, ma la presentazione delle unità è formale.

• Lo sviluppatore non può presentare gli artefatti. Questo è fatto dal team di review che è responsabile del controllo delle interfacce e del codice con i requisiti.
• Controlla l’efficienza degli algoritmi con le richieste non funzionali.
• Lo sviluppatore interviene solo se si richiedono chiarimenti.

Inspection

Le Ispezioni mirano a trovare fault in una componente rivedendo il codice sorgente in meeting formali.

E’ condotta da un team di sviluppatori, incluso l’autore della componente, un moderatore e uno o più revisori che trovano i bug nella componente.

Anomalie del codice possono influenzare in modo scorretto il codice.
Esempi: distribuzione linee bianche, numero linee di commento,…

Tecniche di ispezione di codice possono rilevare ed eliminare anomalie fastidiose e rendere più precisi i risultati una tecnica completamente manuale per trovare e correggere errori, poco tecnologica, ma efficace, ma sono possibili alcuni supporti automatici …

E’ estendibile a progetto, requisiti, … seguendo principi organizzativi analoghi

Attori coinvolti:
Moderatore: tipicamente proviene da un altro progetto. Presiede le sedute, scegli i partecipanti, controlla il processo.
Lettori, addetti al test: leggono il codice al gruppo, cercano difetti
Autore: partecipante passivo; risponde a domande quando richiesto

Il processo di ispezione del software di Fagan

Fagan ha proposto un processo per effettuare le Inspection, basato sui seguenti passi:

1. Pianificazione. Il moderatore scegli i partecipanti e le checklist, pianifica gli incontri.
2. Fasi preliminari. Fornisce le informazioni necessarie e assegna i ruoli.
3. Overview. L’autore presenta l’obiettivo e lo scope del componente e i goal dell’ispezione.
4. Preparation. I revisori analizzano l’implementazione della componente.
5. Inspection meeting. Un reader legge il codice sorgente e spiega ciò che dovrebbe fare, il team di ispezione analizza il componente e evidenzia eventuali fault , il moderatore tiene traccia. La maggior parte del tempo è passata a discutere, ma le soluzioni per riparare il bug non sono esplorate in questo punto.
6. Rework. L’autore rivede la componente.
7. Follow-up. Il moderatore controlla la qualità del rework e determina la componente che deve essere ispezionata di nuovo.

Nelle riunioni

Obiettivo: trovare il maggior numero possibile di difetti:

• massimo 2 riunioni al giorno di 2 ore ciascuna;
• circa 150 linee di codice sorgente all’ora;

Approccio: parafrasare il codice linea per linea:

• ricostruire l’obiettivo del codice dal sorgente;
• può essere “test manuale”.

Necessario restare in tema:

• seguire le checklist;
• trovare e registrare difetti, ma non correggerli;
• il moderatore è responsabile di evitare anarchia.

Checklist – Esempio NASA

Circa 2.5 pagine per codice C , 4 per FORTRAN diviso in: funzionalità, uso dei dati, controllo, connessioni, calcolo, manutenzione, chiarezza
Esempi:

1. ogni modulo contiene una singola funzione?
2. il codice corrisponde al progetto dettagliato?
3. i nomi di constante sono maiuscoli?
4. si usa il cast di tipo dei puntatori?
5. “INCLUDE”annidati di files sono evitati?
6. gli usi non standard sono isolati in sottoprogrammi e ben documentati?
7. i commenti sono sufficienti per capire il codice?

Checklist per Java

Sintassi:

• controlli ortografici, grammaticali e linguistici;
• commenti formattati per javadoc …

Struttura:

• ci sono dati identificativi (titolo, data, versione, autore);
• librerie non standard usate, piattaforma Java richiesta.

Stile:

• non c’è un uso indiscriminato di abbreviazioni;
• non ci sono troppe ripetizioni;
• linguaggio comprensibile e frasi leggibili;
• il commento è presente in ogni classe;
• il commento è ben visibile nel file;
• le variabili sono commentate quando sono dichiarate;
• i commenti non sono dispersivi (mal disposti, interrotti e ripresi);
• i commenti non sono esageratamente densi nel codice (compromettendo la leggibilità del codice).

Perché l’ispezione funziona?

Il metodi di ispezione sono molto efficaci: Circa 85% dei fault può essere individuato.
L’evidenza dice che è cost-effective, perchè?

• Processo formale, dettagliato con tracciamento dei risultati.
• Check-lists: processo che si automigliora.
• Aspetti sociali del processo, specialmente per gli autori.
• Considera l’intero spazio di ingresso.
• Si applica anche a programmi incompleti.

Limiti

• Scala: tecnica inerentemente a livello di unità.
• Non incrementale.

Verifica dinamica

E’ fondata sull’esecuzione del codice.

Analisi dinamica: il processo di valutazione di un sistema software o di un suo componente basato sulla osservazione del suo comportamento in esecuzione

Testing: Approccio strutturato alla selezione di casi di test e dati associati.
Debugging: non c’è uniformità in letteratura.
In generale, riguarda l’individuazione e l’eliminazione dei difetti.
Debugging implica formulare ipotesi osservando il comportamento del programma e quindi verificare queste ipotesi per localizzare gli errori.

Il Testing consiste nel trovare le differenze tra il comportamento atteso, specificato attraverso il modello del sistema e il comportamento osservato dal sistema implementato.
Obiettivo: progettare test per provare il sistema e rivelare problemi.
Massimizzare il numero di errori scoperti che consentirà agli sviluppatori di correggerli.
Questa attività va in contrasto con le altre attività svolte prima: analisi, design, implementazione sono attività “costruttive”. Il testing invece tenta di “rompere” il sistema.
Il testing dovrebbe essere realizzato da persone che non sono state coinvolte nelle attività di sviluppo del sistema.