Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
1
Ingegneria del software Modulo 1 - Introduzione al processo software Unità didattica 5 -Test e verifica Ernesto Damiani Università degli Studi di Milano Lezione 4 – I fault
2
Tipi di fault (1) Algorithmic fault – Salti anticipati o ritardati (errori sugli indici: fencepost) – Mancata inizializzazione di variabili – Errori di cast o traduzione di tipi Computation/precision fault – Ad es. aggiungere 1 a Integer.MAX_VALUE in Java Requirements/documentation fault
3
Tipi di fault (2) Capacity/boundary fault – Troppi processi o file aperti Performance fault – Risposta richiesta in < n msec, arriva tardi Recovery fault – Ad es. file illeggibili dopo un black-out Standard/procedure fault – Linee guida di programmazione non seguite
4
Commenti (1) È impossibile eseguire un test esaustivo di qualsiasi sistema software non banale – Vincoli tempo/costo – Esplosione combinatoria degli input da provare – Esempio: for i from 1 to 100 do print(if a[i]=true then 1 else 0 endif); – Questo programma ha 2 100 possibili risultati; un test esaustivo richiederebbe 3 x 10 14 anni
![Commenti (1) È impossibile eseguire un test esaustivo di qualsiasi sistema software non banale – Vincoli tempo/costo – Esplosione combinatoria degli input da provare – Esempio: for i from 1 to 100 do print(if a[i]=true then 1 else 0 endif); – Questo programma ha possibili risultati; un test esaustivo richiederebbe 3 x anni](http://images.slideplayer.it/16/5245047/slides/slide_4.jpg "Commenti (1) È impossibile eseguire un test esaustivo di qualsiasi sistema software non banale – Vincoli tempo/costo – Esplosione combinatoria degli input da provare – Esempio: for i from 1 to 100 do print(if a[i]=true then 1 else 0 endif); – Questo programma ha possibili risultati; un test esaustivo richiederebbe 3 x anni")
5
Commenti (2) Tutti i test devono far riferimento ai requisiti Il principio di Pareto vale anche per il software testing; l’80% di tutti i fault identificati dal testing sono dovuti al 20% dei moduli del programma
6
Quando fermarsi Il testing in linea di principio non ha mai fine Si possono creare modelli stocastici basati su dati storici per stimare il rischio associato all’interrompere il testing a un certo punto Ancora un’area di ricerca
7
Test funzionali Creare dei casi di test con dati di test ed eseguire il codice con quelli – I casi di test vanno pianificati già in fase di analisi, compresi gli output attesi Pianificare in anticipo la procedura di test (piano dei test) rispettando un processo di test
8
Fasi di testing Programmatore Unità Integrazione Componente Sistema Usabilità Regressione Validazione (Accettazione) Alpha/Beta (FUT/OT) FINE
Presentazioni simili
