Il test

1. Il test

2. Sommario • Introduzione al test • Teoria del test • Tecniche e metodologie di test • Qualità del software • Metriche per la stima di qualità • Test e qualità dell’applicazione sviluppata • Conclusioni

3. Cos’è il test? • Insieme di misure di controllo utili a verificare la qualità di un software.

4. Scopo • Rilevare gli errori

5. Teoria del test

6. Definizioni • Dato un programma P, D ed R siano i domini di ingresso e uscita, P definisce una relazione tra D ed R. • Un caso di test è un elemento di D. • Un insieme di test T è un insieme finito di casi test, quindi un sottoinsieme finito di D. • P è corretto per T se risulta corretto per tutti gli elementi di T. Si dice che T ha avuto successo per P. • Un insieme di test si dice ideale se, tutte le volte che P è scorretto, esiste un d e T tale che P risulta scorretto per d. • Un test ideale mostra sempre l’esistenza di un errore in un programma, se tale errore esiste. • Per un programma corretto qualunque insieme di test risulta ideala. • Se T è un insieme ideale e T ha successo per P allora P è corretto.

7. Teoria del test Criterio di selezione del test Definizione Dato un programma P e le relative specifiche S, un criterio di selezione del test specifica le condizioni che devono essere soddisfatte da un insieme T di casi di test. Es. il criterio specifica che tutti gli statements nel programma devono essere eseguiti almeno una volta durante il test allora un insieme di casi di test T soddisfa il criterio per un programma P se l’esecuzione di P su T assicura che ogni statement in P sia eseguito almeno una volta.

8. Proprietà • Proprietà del criterio di test: • Affidabilità • Validità Definizione Un criterio di test è affidabile se tutti gli insiemi (di casi di test) che soddisfano il criterio individuano gli stessi errori Definizione Un criterio di test è valido se per ogni errore nel programma c’è un qualche insieme che soddisfa il criterio che rileva l’errore.

9. Tesi di Dijkstra • Indecidibilità della correttezza dei programmi • Tesi di Dijkstra: il test di un programma può rilevare la presenza di malfunzionamenti, ma non dimostra la loro assenza. • Il test non può dare garanzia completa di correttezza dovendo essere limitato il numero dei casi di test per ragioni legate al costo • Teorema di Goodenough e Gerhart: • Un criterio di test è affidabile se tutti gli insiemi (di casi di test) che soddisfano il criterio individuano gli stessi errori • Corollario • Teorema di Howden: dato un programma P, non esiste un algoritmo che generi un test ideale finito, cioè selezionato da un criterio affidabile e valido

10. Assiomi di Weyunker • Assioma di applicabilità • Per ogni programma (con relative specifiche) esiste un insieme di test T che soddisfa il criterio • Per tutti i programmi è possibile avere un insieme di casi di test che soddisfa il criterio • Assioma di antiestensionalità • Esistono due programmi P e Q, che soddisfino entrambi le stesse specifiche, tali che un set di test T soddisfa il criterio per P ma non per Q. • La struttura del programma ha un ruolo importante nel decidere i casi di test • Assioma di antidecomposizione • Esiste un programma P ed un suo componente Q tale che un set di test T soddisfa il criterio per P e T’ è l’insieme dei valori che le variabili possono assumere fornendo Q per qualche caso di test In T e T’ non soddisfa il criterio per Q. • Se il criterio è soddisfatto per l’intero programma non è detto che sia soddisfatto per ogni suo componente. • Assioma di anticomposizione • (duale dell’assioma di anticomposizione) • Esistono due programmi P e Q tali che T soddisfi il criterio per P e gli output di P per T (rappresentati da P(T)) soddisfano il criterio per Q, ma T non soddisfa il criterio per P;Q. • Se il criterio soddisfa separatamente le parti P e Q

11. Osservazioni • Molti dei criteri sono essi stessi indecidibili: • Non è decidibile se dato un dato insieme di test soddisfi i criteri o se esista un insieme di test che li soddisfi. • Ciò significa che non è possibile automatizzare la soluzione del problema.

12. Riferimenti bibliografici • Teorema di Goodenough e Gerhart: • J. Goodenough and S.L. Gerhart, “Towards a theory of test data selection”, IEEE Transactions on software engineering, SE-1:156-173,1975. • Tesi di E.W. Dijkstra (1969): “Program testing can be used to show the presence of bugs, but never to show their absence!”. • J.N. Buxton and B. Randell, eds, Software Engineering Techniques, April 1970, p. 16. Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27–31 October 1969. • Teorema di Howden: • W.E.Howden,” Symbolic Testing and the DISSECT Symbolic Evaluation System”, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-3, NO. 4, JULY 1977. • Assiomi di Weyunker • E.J. Weyunker ,"Axiomatizing software test data adequacy”, IEEE transaction on software engineering, 12(12):1128-1138, Dec. 1986

13. Livelli di test

14. Livelli di test • test di unità • test di integrazione • test di sistema • test di accettazione • test di regressione

15. Test di unità • Controllare separatamente le diverse parti di un modulo di un programma, per rilevare gli errori e migliorarle durante la codifica

16. Test d’integrazione • I moduli sono integrati in sottosistemi più grandi i quali a loro volta sono integrati in sistemi più complessi. • Il test d’integrazione si effettua durante l’integrazione e consiste in un controllo delle interfacce dei moduli integrati

17. Test di sistema • Consiste nel verificare che le specifiche di progetto di un programma siano state soddisfatte e i miglioramenti apportati

18. Test di accettazione • Imposto dal cliente per verificare che il programma soddisfi le richieste del cliente stesso

19. Test di regressione • Verifica che non si siano introdotti errori in versioni successive

20. Processo di test • Test plan: • descrive • tutte le attività di test che devono essere eseguite • le risorse da allocare • le linee guida • Le condizioni di test per ogni singolo modulo • Le modalità con cui i vari moduli dovranno essere integrati • Documento sui casi di test: • Contiene • l’elenco di tutti i differenti casi di test • I risultati ottenuti • Le uscite che ci si aspettava • Test report: • Una serie di casi di test • Il risultato dell’esecuzione del codice ottenuto applicando i casi di test • Error report: • Descrive gli errori che si sono presentati • Le azioni intraprese per rimuoverli

21. 2. Principali tecniche e metodologie di test • Ogni fase del ciclo di vita si conclude con un’attività di verifica • Molte di queste attività nelle prime fasi di sviluppo si basano su valutazioni umane e non permettono di rilevare tutti gli errori: • Il test si occupa dell’ultima fase del ciclo di vita del software e ha la responsabilità di rilevare qualsiasi tipo di errore • Esistono errori di diverso tipo, che possono avvenire durante qualunque fase, per cui esistono diversi livelli di test: ognuno aspira a testare aspetti differenti del sistema

22. Tecniche di test • Analisi statica: • Processo di valutazione di un sistema o di un suo componente basato sulla sua forma, struttura contenuto, documentazione senza che esso sia eseguito: • Ispezioni, revisioni, recensioni, analisi data flow • Analisi dinamica: • Processo di valutazione di un sistema software o di un suo componente basato sull’osservazione del suo comportamento in esecuzione (tipicamente il test) • Analisi formale: • Processo che usa rigorose tecniche matematiche per l’analisi di algoritmi • Adoperato soprattutto per la verifica del codice e dei requisiti specie se non sono specificati con linguaggi formali

23. Tecniche di analisi statica • Analisi statica in compilazione • Code reading • Control flow analysis • Data flow analysis • Code inspections or reviews • Esecuzione simbolica

24. Tecniche di analisi dinamica • Black Box Testing o Testing Funzionale: • Testa il programma per esaminare come dovrebbe essere • È fondato sull’analisi degli output generati dal sistema o dai suoi componenti in risposta ad input definiti sulla base della sola conoscenza dei requisiti specificati del sistema o di suoi componenti • Analizza • requisiti funzionali, specifiche, decomposizioni funzionali, requisiti di performance • White Box Testing o Testing Strutturale: • Testa il programma per esaminare com’è • È fondato sulla definizione dei casi di test, degli input associati e dell’oracolo, sulla base della conoscenza della struttura del software ed in particolare del codice • Analizza • Tipi di dati, Dati, strutture di controllo, Control flow, Data flow, Callgraph, Dominanze, dipendenze

25. Tecniche di testing funzionale • … cosa testare • Funzionalità esterne (visibili all’utente e definite dai requisiti e dalle specifiche) • Funzionalità interne ( non visibili all’utente e definite dal progetto di high e low level) • …. partendo da • Definizione Funzionalità: • Insieme dei dati d’ingresso, dati d’uscita, precondizioni e postcondizioni

26. Effettuare un test • È necessario conoscere il comportamento atteso per poterlo confrontare con quello osservato e per poter definire l’oracolo • L’oracolo conosce il comportamento atteso per ogni caso di test e può essere: • Umano, se si basa sulle specifiche o sul giudizio • Automatico se è generato dalle specifiche formali • Lo stesso software scritto da altri • Una versione precedente ( test di regressione) • Ogni funzionalità deve essere eseguita almeno una volta e per ogni funzionalità bisogna effettuare un numero di esecuzioni dedotte dai dati di ingresso e di uscita, da precondizioni e postcondizioni

27. Test case • Vanno effettuati una volta definito il dominio dei dati di I/O selezionando: • Valori in posizione centrale • Valori ai bordi • Valori speciali • Selezionando precondizioni e postcondizioni • Positivi • Negativi • Neutrali

28. Documentazione dei test • I test eseguiti vanno documentati producendo una check list:

29. Definizione della check list • Si parte dall’analisi dei documenti che definiscono i requisiti e la specifica • Si estraggono le funzionalità esterne ed altre features, dati di I/O, pre e post condizioni, definizione priorità, nomi dei test • Si procede con l’analisi dei documenti di progetto di high e low level e con l’estrazione delle funzionalità interne, dati di I/O, pre e post condizioni, definizione priorità e nomi dei test • Si definiscono i test case e le procedure di test • Si genera la tabella di copertura (o dei test case) e la tabella delle procedure

30. Tecniche di testing strutturale • Si basa sulla scelta dei dati di test in base alla struttura del codice testato • Per effettuare una completa analisi strutturale si applicano i seguenti criteri • criterio di inadeguatezza • Se parti significative della struttura del programma non sono coperte il test è inadeguato • criteri di glass box (criteri di copertura strutturale del flusso di controllo) • Copertura delle istruzioni (statement coverage) • Copertura delle diramazioni (edge coverage) • Copertura delle condizioni (condition coverage) • Copertura dei cammini (path coverage)

31. Copertura • Un insieme di casi di test (input data) tale che gli oggetti di una definita classe (strutture di controllo, istruzioni, predicati) siano attivati almeno una volta nell’esecuzione dei casi di test.

32. Metodo di copertura delle istruzioni • Si seleziona un insieme T di dati di test per cui ogni istruzione viene eseguita almeno una volta da qualche dato di T. • In questo caso, fissato il criterio, si cerca di trovare il T di cardinalità minima, che soddisfa il criterio.

33. Metodo di copertura delle istruzioni • Si seleziona un insieme T di dati di test tali che ogni istruzione viene eseguita almeno una volta da qualche dato di T. • Non è possibile individuare un errore se la parte del programma che contiene l’errore e che genera il fallimento non viene eseguita

34. Metodo di copertura delle diramazioni • Si seleziona un insieme T di dati di test tale che ogni diramazione del flusso di controllo viene selezionata almeno una volta da qualche elemento di T.

35. Metodo di copertura delle condizioni • Si seleziona un insieme T per cui si percorre ogni diramazione e tutti i possibili valori dei costituenti della condizione che controlla la diramazione sono esercitati almeno una volta.

36. Metodo di copertura dei cammini • Si seleziona un insieme T che attraversa tutti i cammini del programma. • Problema: presenza di un numero infinito di cammini e/o non percorribili • Soluzione: numero finito di cammini eseguibili • Trovare un insieme di test case che assicuri l’attraversamento almeno una volta di almeno un cammino per ogni classe

37. Metodo di copertura dei cammini minimi • Metodi fondati sui grafi di controllo • Metodo dei cammini esemplari • Metodo dei cammini linearmente indipendenti (McCabe) • Metodi data flow: • Garantire il test delle variabili e dei loro usi

38. Mutation testing • Mutanti: testing strutturale • Obiettivo: garantire che, durante la fase di test, ogni mutante (variazione del programma) produca un’uscita diversa dall’uscita del programma originale.

39. Test di software OO • Concetti di OO: • Modularizzazione • Information hiding • Tipi di dati astratti • Progettazione per il cambiamento • Ereditarietà • Polimorfismo • Binding dinamico • Test di software OO: • Information hiding • Shadow invocations • Polimorfismo e dynamic binding • Ereditarietà • Genericità

40. Ereditarietà • Flattering inheritance • Test incrementale • Genericità • Data-flow analysis • Polimorfismo • Data-flow analysis

41. Problemi • Ereditarietà: i metodi sono riutilizzati in classi diverse • Information hiding: gli oggetti, avendo uno stato violano le ipotesi di un comportamento funzionale • Shadow invocations: i metodi possono essere invocati implicitamente (problemi relativi al conteggio delle percentuali di copertura) • Polimorfismo e dynamic binding: i metodi invocati non possono essere identificati staticamente • Genericità: le classi generiche devono essere istanziate per essere testate

42. Test ed ereditarietà • Alcune operazioni possono non essere modificate nelle sottoclassi, altre possono essere ridefinite o cancellate: • Problema: • Come fare il test? • Quali operazioni possono essere ri-testate?

43. 1a Soluzione • Appiattire l’intera gerarchia e considerare ogni classe come una componente totalmente indipendente: Flattering inheritance • Svantaggio: • Si perde l’incrementalità e la riusabilità

44. 2a Soluzione • Test incrementale • Evitare di ripetere il test di elementi che sono ereditati senza cambiamenti, mentre si dovrebbero testare i nuovi elementi e quelli che sono stati ridefiniti • Tecnica usata per testare classi appartenenti ad una gerarchia con ereditarietà • Quando una classe eredita da una classe base già testate, il test della sottoclasse richiede il test solo di alcuni elementi • Una sottoclasse R può essere definita come una classe base P più una modifier M • A seconda del tipo di elemento il test può avvenire riusando un caso di test esistente in modo totale o parziale

45. Test dei costrutti generici • Costrutti generici e polimorfismo sono strumenti essenziali per ottenere generalità e riusabilità dei programmi, ma sono sorgente di complessità nel test e nella verifica • Genericità: • A differenza della programmazione procedurale i moduli generici sono molto presenti e rappresentano la base per la costruzione di librerie e componenti riusabili • Problemi nel test: • assunzioni sul parametro • metodo da usare nel test di un componente generico già riutilizzato

46. Test del polimorfismo • Molte implementazioni per una singola operazione • La selezione dell’effettivo codice da chiamare è proposta a run-time • Problemi nel test: • Scelta di come coprire tutte le chiamate alle operazioni polimorfiche • Come esercitare tutte le implementazioni di un’operazione • Come trattare parametri polimorfici

47. Soluzioni al problema del test del polimorfismo e costrutti generici • Nel caso del polimorfismo, invece, mentre nella programmazione procedurale le chiamate di procedura sono legate staticamente, nella programmazione OO, un’entità può riferire oggetti di classi diverse di una gerarchia, quindi si hanno molte implementazioni per una singola operazione. La selezione dell’effettivo codice da chiamare è proposta a run-time. • I problemi che s’incontrano nell’ambito del test sono dovuti alla scelta di come coprire tutte le chiamate alle operazioni polimorfiche, come esercitare tutte le implementazioni di un’operazione o come trattare parametri polimorfici. • Il testing strutturale, in questo caso, non può essere trattato statisticamente. • Si può dimostrare che tutte le possibili combinazioni di chiamate polimorfiche e parametri polimorfici rischiano di far esplodere in modo combinatorio il numero dei casi di test. • Si può ottenere una riduzione di questo effetto attraverso tecniche di analisi statica che permettano d’individuare le effettive chiamate delle unità interessate (data-flow analysis).

48. Tecniche tradizionali per OO • Test di sistema e di accettazione, che si basano su requisiti funzionali • gli approcci tradizionali al testing strutturale, che possono essere usati per testare metodi singoli • il test di regressione, il quale richiede solo di scrivere nuovi test per le caratteristiche nuove o modificate • l’esecuzione di tali test richiede solo modifiche sintattiche

49. Fattori di qualità ISO 9126 metriche Metriche di prodotto per il software

50. I fattori di qualità ISO 9126 • Funzionalità Opportunità Precisione Interoperabilità Conformità Sicurezza Maturità Resistenza ai guasti Ricuperabilità • Affidabilità