Prove di convalida Iniziano al termine del collaudo di integrazione A questo punto la distinzione fra software convenzionale ed orientato agli oggetti sparisce in quanto il collaudo si concentra sulle azioni visibili e sull output del sistema Le prove di convalida hanno successo se il software funziona secondo le ragionevoli aspettative del cliente (SRS) Vengono eseguite seguendo un piano (classi di prove da eseguire) 1
Prove di convalida Al termine delle prove di convalida sono possibili due casi: 1. Le caratteristiche di funzione e prestazione sono conformi alle specifiche (accettazione) 2. Si rileva una deviazione dalle specifiche e viene stilato un elenco delle lacune riscontrate 2
Correzione degli errori Una volta rilevato, un errore va corretto. Tuttavia l eliminazione di un errore può introdurne altri, tanto da risultare controproducente. 1. La causa dell errore si ripresenta in altri punti del programma? 2. Quali nuovi errori potrebbe introdurre la correzione in corso? 3. Cosa si sarebbe potuto fare per prevenire questo errore? 3
Difetti di coordinazione e concorrenza Difetto: deadlock e livelock Strategie di testing: ispezione del codice White box testing Black box testing Fare girare un ampio numero di thread concorrentemente Negare deliberatamente delle risorse ad uno o più thread 4
Difetti di coordinazione e concorrenza Difetto: corse critiche Strategie di testing: analoghe a quelle utilizzate per il deadlock e il livelock 5
Difetti nella gestione di situazioni di stress e inusuali Prove di utilizzo pesante per il sistema Testare il sistema in modo intensivo Fornirgli input di grandi dimensioni Far girare diverse copie in ambienti affollati (altri processi) Fallimenti in questa direzione indicano mancanza di robustezza 6
Tempo di risposta su configurazioni minimali Difetto: se il sistema viene testato su una configurazione minimale la sua velocità di trasmissione dei dati e il suo tempo di risposta sono insufficienti Strategie di testing: eseguire il testing usando vecchie release del sistema operativo e CPU lente. Per assicurare maggiormente l affidabilità si può testare il sistema su una configurazione peggiore del minimo 7
Incompatibilità con configurazioni specifiche di hardware o di software Difetto: capita spesso che un sistema funzioni correttamente su certe configurazioni di hardware, sistema operativo e librerie esterne, ma fallisce se viene fatto girare usando configurazioni diverse Strategie di testing: eseguire più volte il sistema con un ampia varietà di configurazioni che potrebbero essere incontrate dagli utenti 8
Gestione di carico massimo o della mancanza di risorse Difetto: la mancanza o l insufficienza di risorse necessarie all esecuzione non sono gestite elegantemente (il programma deve riferire il problema all utente) Strategie di testing: il collaudatore deve negare al programma le risorse da esso normalmente utilizzate 9
Gestione non appropriata delle risorse Difetto: un programma non gestisce le risorse in modo efficiente se le utilizza ma non le rende disponibili agli altri programmi una volta che non ne ha più bisogno Strategia di testing: eseguire il programma intensivamente su un periodo di tempo piuttosto lungo in modo che possa utilizzare varie risorse, rilasciarle e poi usarle nuovamente 10
Recupero da un crash Difetto: in seguito ad un crash il sistema resta in uno stato di instabilità e quindi non è in grado di riprendersi completamente. E un difetto anche se un sistema non gestisce correttamente i crash di altri sistemi Strategie di testing: provare ad uccidere il programma o i programmi che con esso comunicano varie volte durante l esecuzione 11
Collaudo basato sui guasti Progettazione di collaudi che abbiano la maggiore probabilità possibile di individuare guasti La pianificazione dei collaudi basati sui guasti comincia dalle specifiche dei requisiti e architetturali Ricerca di guasti plausibili (es. operazioni di interfaccia, concorrenza) 12
Collaudo basato su scenari Si concentra sulle operazioni svolte dall utente, ed è in grado di individuare gli errori di interazione (gli utenti infatti non si limitano all uso di un sottosistema per volta) Riesce ad individuare: 1. Specifiche errate 2. Errori di interazioni fra i sottosistemi 13
Esempio: editor di testi Caso d uso 1: correggere la bozza finale 1. Stampare l intero documento 2. Modificare determinate pagine del documento 3. Stampare un intervallo di pagine 14
Esempio: editor di testi Caso d uso 2: stampa di una nuova copia 1. Aprire il documento 2. Stampare il documento 3. Chiudere il documento 15
Esempio: editor di testo Caso d uso 2bis: stampa di una nuova copia 1. Aprire il documento 2. Selezionare il comando di stampa nel menu 3. Controllare se è impostata la stampa di un intervallo di pagine; in caso affermativo fare click per stampare l intero documento 4. Fare click sul pulsante di stampa 5. Chiudere il documento 16
Collaudo delle strutture di superficie e delle strutture profonde Il collaudo della struttura immediatamente visibile all utente finale viene guidato dall interfaccia. I migliori collaudi si hanno quando il sistema viene testato in modo non convenzionale Il collaudo della struttura profonda viene guidato dalle specifiche architetturali e dal codice 17
Collaudi alfa e beta Alfa: eseguito dall utente o dal cliente sotto la supervisione del team di sviluppo del software (normalmente il team invita qualche utente a lavorare con il software e guarda i problemi che incontra) Beta: viene eseguito normalmente dall utente o dal cliente nel loro normale ambiente di lavoro. I beta tester vengono scelti fra la popolazione di possibili utenti. Ad essi viene fornita una prerelease. 18
Difetti di documentazione Difetto: il manuale utente o l help online danno informazioni non corrette o non danno informazioni rilevanti per il problema Strategie di testing: esaminare tutta la documentazione per l utente finale (elettronica e cartacea) per verificare la correttezza. Soluzioni corrette ai problemi che l utente potrebbe incontrare Istruzioni corrette per aiutare i principianti Usare i casi d uso per verificare se ciascuno è spiegato adeguatamente all utente Valutazione dell usabilità da parte dell utente 19
Piano dei test e di integrazione Descrive la strategia globale di integrazione e i test che vengono svolti Prove corrispondenti a: Integrità delle interfacce Validità funzionale Contenuto informativo Prestazioni 20
Piano dei test e di integrazione Si descrive l ordine di integrazione e le prove corrispondenti ad ogni passo di integrazione Viene aggiunto un elenco di tutti i casi di prova e dei risultati attesi Alle specifiche di collaudo vengono aggiunti i risultati dei test, eventuali particolarità e problemi riscontrati 21
Informazioni da includere in un caso di test formale Ogni caso di test deve avere le seguenti informazioni 1. Identificazione e classificazione: ogni caso di test ha un numero e un titolo descrittivo che indica il suo scopo Il sistema, sottosistema, o modulo testato deve essere anch esso chiaramente indicato, facendo pure riferimento ai documenti di specifica dei requisiti e architetturale L importanza del caso di test deve essere indicata 2. Istruzioni: queste dicono al collaudatore cosa deve fare esattamente Come mettere il sistema nello stato iniziale richiesto Quali input fornire Il collaudatore non deve fare riferimento a nessun altro documento quando fa i test 22
Informazioni da includere in un caso di test formale 3. Risultato atteso: dice al collaudatore come il sistema dovrebbe comportarsi in risposta alle istruzioni (output atteso, in quale stato si deve trovare). Il collaudatore riferisce un fallimento se non trova il risultato atteso 4. Clean up: indica al collaudatore come fare tornare il sistema indietro allo stato normale o arrestarlo dopo il test I test possono essere organizzati in gruppi o tabelle. 23