Verifica e Convalida

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A Verifica e Convalida E. TINELLI

2 Definizioni Le attività di Verifica (Verification) e Convalida (Validation) si svolgono dopo ogni stadio del processo SW: dalla revisione dei requisiti, alla revisione del progetto, all ispezione del codice fino al test del prodotto SW portano all individuazione di: Malfunzionamenti o guasti Difetti o anomalie Errori Verifica: attività di controllo atta a verificare che un prodotto sia conforme alle sue specifiche (funzionali e non) Stiamo costruendo il prodotto nel modo giusto? Validazione: processo di valutazione di un sistema o componente durante o alla fine del processo di sviluppo per determinare se esso soddisfa le esigenze del committente Stiamo costruendo il prodotto giusto? Piano delle Verifiche - Dovrebbe comprendere una descrizione degli elementi da verificare, la tempistica della verifica, i requisiti HW e SW necessari alla verifica e qualsiasi altro problema che potrebbe sorgere durante la verifica 2

3 Cause di errori Requisiti difettosi (Errati, Mancanti, Incompleti, Inutili) Incomprensioni cliente-sviluppatore Deviazioni deliberate dai requisiti (Riuso effettuato senza una corretta analisi, Omissioni ufficiali, Omissioni non ufficiali di requisiti valutati meno importanti) Errori di progetto (Errori algoritmici, Errori di processo (tipicamente sulle sequenze degli avvenimenti), Mancata definizione del comportamento del sistema a fronte di operazioni/input errati) Processo di test affrettato (Piano di test incompleto, Mancata o inadeguata notifica di errori scoperti durante il test, Correzione incompleta di errori (negligenza o vincoli stringenti)) Errori di documentazione (Omissioni, descrizione di funzionalità inesistenti, mancato allineamento con la versione corrente, Errori nei documenti di progetto e documentazione del sw, Errori nella documentazione utente) Errori di codifica 3

4 Qualità del SW La qualità del software è definita come l insieme delle caratteristiche che incidono sulla capacità del prodotto di soddisfare requisiti espliciti od impliciti. (norma ISO/IEC 9126) Il prodotto software è definito come l insieme di programmi, procedure, regole, documenti, pertinenti all utilizzo di un sistema informatico Alla base di un qualunque tentativo di produrre sw di qualità c'è la necessità di avere una ottima documentazione dei requisiti In particolare, oltre alla definizione corretta di specifiche funzionali e non, occorre includere tutti gli aspetti di qualità ritenuti essenziali per l'applicazione [McCall (1977)] Fattori relativi al funzionamento (Correttezza, Affidabilità, Efficienza, Integrità, Usabilità) Fattori relativi alle attività di revisione (Manutenibilità, Flessibilità, Provabilità (Testability)) Fattori relativi alle attività di transizione (Portabilità, Riusabilità, Interoperabilità) A determinare la qualità complessiva di un software concorrono 3 diverse tipologie di qualità [ISO/IEC 9126]: Interna (intrinseca) - Esprime la misura in cui il codice software possiede una serie di attributi, indipendentemente dall ambiente di utilizzo e dall utente. Esterna - Esprime le prestazioni e le funzionalità del software Percepita (in uso) - Esprime l efficacia ed efficienza con cui il software serve le esigenze dell utente, ed è correlata all usabilità del prodotto. 4

5 Approcci di V&V Verifica Statica - riguarda l'analisi di una rappresentazione statica del sistema per individuare difetti Verifica e Convalida Dinamici - riguardano la fase di test con cui si esercita e osserva il comportamento dinamico del sistema N.B La Convalida può essere solo dinamica V&V statica SRS Progetto di alto livello Specifiche formali Progetto di dettaglio Codice Prototipo Validation 5

6 Tecniche di analisi statica del codice Analisi statica in compilazione consiste nel generare delle Cross Reference List, ossia dei rapporti, molto utili nelle analisi successive del codice, per l individuazione di anomalie non rilevabili dal compilatore. Code reading è una tecnica di controllo che consiste in un attenta lettura del codice per individuare errori e/o discrepanze con il progetto. Control Flow Analysis Il codice è rappresentato tramite un grafo, il grafo del flusso di controllo (Control Flow Graph - CFG), i cui nodi rappresentano statement (istruzioni e/o predicati) del programma e gli archi il passaggio del flusso di controllo. Il grafo è esaminato per identificare ramificazioni del flusso di controllo e verificare l esistenza di eventuali anomalie, quali codice irraggiungibile e non strutturazione. Data flow analysis analizza l evoluzione del valore delle variabili durante l esecuzione di un programma, permettendo di rilevare anomalie. Code inspections o reviews sono delle riunioni formali cui partecipa un gruppo di persone tra cui almeno una del gruppo di sviluppo. Il codice è esaminato linea per linea e i partecipanti fanno commenti e/o annotazioni. Esecuzione simbolica: il programma non è eseguito con i valori effettivi ma con valori simbolici dei dati di input. L esecuzione procede come un esecuzione normale ma non sono elaborati valori bensì formule formate dai valori simbolici degli input. Gli output sono formule dei valori simbolici degli input. 6

7 Ispezione del SW Si analizzano e controllano le rappresentazioni statiche del sistema L ispezione è eseguita sui manufatti prodotti da una fase considerando come requisiti della stessa i manufatti sorgente in input ad essa L ispezione scopre i difetti e non le modalità di correggerle I ruoli in un ispezione sono: Il moderatore responsabile della conduzione dell ispezione Il produttore responsabile del prodotto da ispezionare I revisori o ispettori interessati e conoscitori del prodotto da ispezionare Il registratore raccoglie i risultati più significativi dell ispezione Tecniche di ispezione: Ad Hoc - L ispettore decide autonomamente, dipendentemente dalla sua esperienza e dal tipo di manufatto da ispezionare, i difetti da scoprire e le modalità di ispezione da seguire Check List - L ispettore ha una check list di possibili difetti che devono essere scoperti nel manufatto da ispezionare 7

8 Processo di Ispezione Criteri di entrata per l ispezione Il produttore certifica che la componente da ispezionare è pronta Sono disponibili le componenti del fascicolo dell ispezione I produttori decidono che il prodotto è pronto per l ispezione Si individuano gli obiettivi dell ispezione coerentemente con quanto definito nel piano di qualità Sono identificati i partecipanti e sono costituite tutte le condizioni di partenza dell ispezione Il moderatore convoca la riunione di ispezione e la conduce secondo le regole. Durante il meeting il produttore discute le osservazioni per decidere se esse devono essere difetti da eliminare I dati delle ispezioni sono raccolti per: rivelare punti di analisi sul processo o sui prodotti verificare che le azioni migliorative sui processi o sui prodotti siano efficaci valutare lo stato di progresso del processo 8

9 Controlli di ispezione del codice (1/2) Errori di riferimento ai dati Ci si riferisce ad una variabile non inizializzata? Una variabile ha tipo diverso da quello previsto dal programma? Esistono variabili con nome simile (pratica pericolosa)? Errori di calcolo I calcoli coinvolgono tipi inconsistenti (ad es., stringhe e interi)? Esistono dei calcoli che coinvolgono tipi compatibili ma di precisione differente? È possibile una condizione di overflow (ad esempio nei calcoli intermedi, o nelle conversioni)? Nelle espressioni che contengono vari operatori aritmetici, le assunzioni sull ordine di valutazione e di precedenza degli operatori sono corrette? Il valore di una variabile esce dall intervallo ragionevole? (ad es., il peso dovrebbe essere positivo, ) Errori di confronto Ci sono confronti fra variabili di diverso tipo? Le espressioni booleane sono corrette (uso appropriato di and, or, not)? Nelle espressioni che contengono vari operatori booleani, le assunzioni sull ordine di valutazione e di precedenza degli operatori sono corrette? Gli operandi di un espressione booleana sono booleani? 9

10 Controlli di ispezione del codice (2/2) Errori di controllo I cicli terminano? Le funzioni/procedure terminano? È possibile che, a causa delle condizioni di ingresso, un ciclo non venga mai eseguito? Le condizioni di uscita dal ciclo sono corrette? Esistono delle decisioni non esaustive (ad es., in un istruzione switch)? Errori di interfaccia Il numero e l ordine dei parametri attuali corrisponde a quello dei parametri formali? Le assunzioni sulla conversione di tipo fra parametri attuali e formali sono corrette? La modalità di passaggio dei parametri (valore, riferimento) è corretta? Errori di I/O La lettura da file avviene rispettando il formato? Input imprevisti possono causare corruzione? Altro Esistono delle variabili dichiarate ma che non vengono usate? Il programma è sufficientemente robusto? Controlla la validità dell input? Sono presenti tutte le funzionalità previste per il programma? 10

11 Tipi di Difetti Omissione Alcune delle specifiche previste nel manufatto sorgente mancano o sono incomplete Commissione Informazione ambigua: Una frase od un termine essenziale alla comprensione del comportamento del sistema è rimasto indefinito oppure è definito in modo che può causare confusione o cattive interpretazioni Informazione inconsistente: Due affermazioni o concetti sono in contraddizione o esprimono azioni che non possono essere corrette o non possono essere entrambe soddisfatte Fatti incorretti: Una affermazione asserisce un fatto che non può essere vero sotto le condizioni specificate in altra parte del manufatto ispezionato od in quello sorgente Sezioni sbagliate: Informazioni essenziali sono messe in una sezione sbagliata del manufatto ispezionato 11

12 Tassonomia dei Difetti Funzioni: sono stati omessi alcuni dei comportamenti interni o esterni delle funzioni Interfacce: sono state omesse informazioni su come il sistema interagirà con altri oggetti Dati: mancano dati o la loro descrizione Prestazione: sono state omesse informazioni circa le specifiche di prestazioni o descritte in modo insufficiente per le prove di accettazione Manutenibilità: sono violati alcuni principi per facilitare la manutenzione dell applicazione Standards: sono violati gli standards predefiniti per i documenti o per il codice Documentazione: la documentazione è incompleta o ha difetti di inconsistenza Fattori Umani: hanno un insufficiente definizione o sono contrastanti con le caratteristiche dell ambiente Ambiente: l ambiente operativo o tecnico non è sufficientemente definito o ha contraddizioni 12

13 Convocazione di Ispezione - Esempio PROGETTO: DATA: NOME SISTEMA: UNITA. MODERATORE: TIPO DI RIUNIONE: PRESENTAZIONE: REISPEZIONE: REQUISITI: PROGETTO: CODICE: NUMERO DI ISPEZIONE: NUMERO TOTALE ISPETTORI: NUMERO LINEE DA ISPEZIONARE: PAGINE DI DOCUMENTAZIONE DA ISPEZIONARE: PRODUTTORE(I): SCRITTORE: MODERATORE: DATE: ULTERIORI COMMENTI: Distribuzione: Capo Progetto Assicurazione di Qualità Gruppo di Processo Produttore(i) Coordinatore di Ispezione 13

14 Report dell Ispettore/Meeting: Esempio PROGETTO: NUMERO DI REISPEZIONE: DATA ISPEZIONE: COMPONENTE ISPEZIONATA. DURATA ISPEZIONE TEMPO ISPEZIONE ISPETTORE: COMMENTI ADDIZIONALI: 14

15 Lista dei Difetti dell Ispettore - Esempio Num. Tipo Tassonomia Descrizione Collocazione Gravità Azione Rilievo (Om/Comm) (Prim/Sec) Correttiva 15

16 Check List di Analisi Esempio (1/2) Checklist per l Analisi dei Casi d Uso Attori 1) Sono stati omessi degli attori necessari? Vale a dire, il sistema ha bisogno di interagire con qualche altro utente, sistema, o dispositivo hardware descritto nei requisiti? 2) C è una classe di utenti, un sistema esterno, o un dispositivo hardware descritto nei requisiti che non interagisce in realtà con il sistema? Comunicazioni tra attori e casi d uso 3) Ci sono dei casi d uso che non sono compatibili con la descrizione dell attore? 4) Ci sono dei casi d uso per i quali non è specificato nessun attore? Descrizione dei casi d uso 5) Sono chiare le condizioni di avvio di ciascun caso d uso? 6) E stata omessa qualche funzione che dovrebbe comparire in un caso d uso? 7) Sono state omesse delle funzioni necessarie? 8) La descrizione dettagliata di come un sistema interagisce con un attore è consistente con i requisiti generali? I requisiti sono oscuri o inconsistenti circa questa interazione? 16

17 Check List di Analisi Esempio (2/2) Checklist per l Analisi Orientata agli Oggetti Classi di oggetti 1) Sono state specificate tutte e solo le classi rilevanti per il problema? 2) Gli oggetti delle classi hanno identità distinte? Gerarchie di classificazione 3) Sono stati generalizzati gli stati e i comportamenti e riportate le classi necessarie? Checklist per i Requisiti Omissione 1) Le funzioni descritte sono sufficienti per soddisfare gli obiettivi del sistema? 3) Sono presi in considerazione gli eventi non desiderati e sono specificate le risposte richieste? 4) Il sistema può essere ispezionato per mostrare che soddisfa i requisiti di prestazione? 5) Sono specificati i requisiti non funzionali? Informazione ambigua 6) Un requisito ammette più di una interpretazione? Inconsistenza 7) Ci sono requisiti specifici in conflitto tra loro? (conflitti logici, temporali, di formato, ecc.) Fatto incorretto 8) Ci sono requisiti specifici che contraddicono gli obiettivi, le definizioni e la descrizione generale del sistema? 17

18 Ispezione del Doc di Analisi - Esempio Tipologia Tassonomia Descrizione Correzione Gravità Omissione Funzioni Nelle classi di analisi non c è traccia della capacità del sistema di gestire gli errori Ommissione Funzioni Nel diagramma delle classi non ci sono metodi che permettono di gestire gli errori Informazione ambigua Funzioni La descrizione del calcolo degli costi e dei ricavi è poco chiara Omissione Interfacce Manca informazioni su come si può interagire con il sistema Sezioni sbagliate Dati Descrizione troppo dettagliata dei dati di utilizzo del sistema Commissione Funzioni Nella descrizione del caso d uso del Controllo di Gestione non sono chiari gli scenari alternativi. Integrazione delle classi esistenti con la classe Gestione errori Aggiunta al diagramma delle classi della classe Gestore errore Modifica della parte riguardante i calcoli nei Requisiti Modifica del diagramma delle classi e aggiunta delle classi boundary Eliminazione di tali dettagli nella descrizione dei dati che vanno inserite nel progetto Tale scenari sono stati descritti nuovamente Primaria Primaria Primaria Secondaria Primaria Secondaria 18

19 Check List di Progetto - Esempio 1. Il progetto è tracciabile con le specifiche? 2. E prevista la gestione degli errori? 3. I servizi sono adeguatamente localizzati in componenti software? 4. Devono essere apportate modifiche al progetto in funzione del linguaggio di programmazione o dell ambiente operativo? 5. È descritta l organizzazione in sotto-sistemi? 6. L interazione con l utente è gestita da componenti specifiche? 7. Le entità concettuali sono gestite da un apposito DBInterface? 8. Tutte le tabelle sono in terza forma normale? 9. Il numero di campi per ogni tabella è adeguato? 10. Tutte le decisioni di progetto sono giustificate adeguatamente? 11. Contiene le classi utili per la restituzione all esterno dei dati gestiti dal sistema? 12. Contiene le classi utili per la comunicazione di messaggi all utente? 13. Tutti gli oggetti riconosciuti dal dominio applicativo sono adeguatamente descritti in classi specifiche? 14. Contiene le classi che implementano i servizi generali utilizzati dalle altre classi del sistema? 19

20 Ispezione del Doc di Progetto - Esempio Tipologia Tassonomia Descrizione Correzione Gravità Omissione Interfacce Nella classe UserInterface sono state omesse informazioni su come l utente interagirà con le finestre di dialogo del sistema. Informazione ambigua Funzioni Nel diagramma delle classi i metodi relativi all Analisi costi/ricavi e all Analisi statistica non erano ben descritti Omissione Funzioni Nella descrizione dei componenti mancava la componente di gestione dell errore Informazione ambigua Dati La descrizione del calcolo dell avanzamento era poco chiara Omissione Documentazione Mancava la descrizione delle decisioni di progetto Informazione ambigua Funzioni Nella descrizione delle funzionalità di stampa e salvataggio non era esplicitato il fatto che l attivazione di tali funzioni dovesse avvenire dopo la visualizzazione Omissione Funzioni L interfaccia VisualizzaHelp era usata soltanto dalla componente Selezionatore Aggiunta degli attributi DatiDB, DatiInput, Dir, Drive, File e Nomefile. Aggiunta delle descrizioni delle operazioni svolte sui dati Aggiunta al diagramma dei componenti della componente Error Handler Aggiunta nella specifica della classe X delle operazioni per il calcolo dell avanzamento Aggiunta del paragrafo 5.5 Decisioni di progetto Le descrizioni delle funzionalità di stampa e salvataggio sono state perfezionate Anche la componente InterfacciaUtente usa tale interfaccia Primaria Primaria Primaria Primaria Secondaria Secondaria Primaria 20

21 Check list x componente Esempio (1/2) 21

22 Check list x componente Esempio (2/2) 22

23 Test del SW Il software deve essere testato con il preciso scopo di trovare degli errori prima di essere consegnato al cliente Il collaudo è un insieme di attività pianificate per testare il software (progettazione dei casi di prova, esecuzione, raccolta e valutazione dei risultati): Efficace revisione tecnico-formale (per eliminare diversi errori prima della fase di collaudo) Procedimento: Quale Strategia? Dipendono dal linguaggio di programmazione? dal piccolo al grande Test delle unità, di integrazione e di sistema: sviluppatore (o gruppo indipendente) Alfa test: cliente Beta test: utente finale Documento di specifica del collaudo (gli errori che si sono presentati e le azioni intraprese per rimuoverli, l elenco di tutti i differenti casi di test, i risultati ottenuti, le uscite che ci si aspettava) 23

24 Livelli di test test di unità - Controllare separatamente le diverse parti di un modulo di un programma, per rilevare gli errori e migliorarle durante la codifica mirato alla correttezza degli algoritmi test di 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 mirato alla correttezza delle interfacce test di sistema - Consiste nel verificare che le specifiche di progetto di un programma siano state soddisfatte e i miglioramenti apportati mirato a garantire la qualità del SW test di accettazione - imposto dal cliente per verificare che il programma soddisfi le richieste del cliente stesso (alfa, beta test) test di regressione test di regressione - Verifica che non si siano introdotti errori in versioni successive 24

25 Test di unità Il controllo su un modulo ha come obiettivo principale la correttezza funzionale delle operazioni esportate dal modulo a fronte della specifica definita nel progetto di dettaglio. Per il controllo sui moduli sono in realtà usati metodi sia statici (ispezione e code reading) sia dinamici. Fare test sui moduli significa dover effettuare i test su sistemi che sono incompleti: driver, le componenti che invocano le funzionalità esportate dai moduli sottoposti a test letteralmente pilotando la loro esecuzione; un driver deve anche definire il contesto di esecuzione, eventualmente definendo i dati globali cui accedono i moduli sottoposti a test. stub (letteralmente mozzicone ), le componenti usate per realizzare in modo fittizio le funzionalità invocate dai moduli sottoposti a test e necessarie per la loro esecuzione. 25

26 Test di integrazione Obiettivi delle strategie d integrazione sono la minimizzazione del lavoro e delle risorse necessarie all integrazione e la massimizzazione del numero di difetti scoperti prima dei controlli sul sistema completo. Le strategie di integrazione fanno riferimento al grafo della relazione di uso dei moduli: Big-bang: tutti i moduli sono controllati singolarmente, l integrazione avviene in un solo passo e si procede direttamente ai controlli di sistema. Bottom-up: Tutti i moduli che non dipendono da altri moduli sono controllati singolarmente. Quindi si integrano i moduli controllati e si sale nell albero eseguendo un nuovo livello di controlli. Il procedimento si ripete fino a raggiungere il modulo radice per eseguire i test ai vari livelli sono necessari solamente driver. Top-down: Il modulo radice dell albero viene controllato singolarmente, quindi si integrano alla radice i moduli figli e si scende nell albero eseguendo un nuovo livello di controlli. Il procedimento si ripete fino all integrazione completa del sistema sono necessari solamente stub. Sandwich: consiste nell adottare entrambe le strategie bottom-up e top-down con l obiettivo di minimizzare i costi per la realizzazione di stub e driver. 26

27 Test di sistema Attività di convalida che valuta ogni caratteristica di qualità del prodotto software nella sua completezza, avendo come documento di riscontro i requisiti dell utente: Facility test - controlla che ogni funzionalità del prodotto stabilita nei requisiti sia stata realizzata correttamente. Security test - controlla l efficacia dei meccanismi di sicurezza del sistema. Usability test - valuta la facilità d uso del prodotto da parte dell utente finale. Performance test - valutare l efficienza di un sistema soprattutto rispetto ai tempi di elaborazione e ai tempi di risposta. Storage use test - controllo della richiesta di risorse la memoria in particolare durante il funzionamento Volume test (test di carico) - il sistema è sottoposto al carico di lavoro massimo previsto dai requisiti e le sue funzionalità sono controllate in queste condizioni. Stress test - Il sistema è sottoposto a carichi di lavoro superiori a quelli previsti dai requisiti o è portato in condizioni operative eccezionali in genere sottraendogli risorse di memoria e di calcolo. Configuration test - prova del sistema in tutte le configurazioni previste. Compatibility test - valutare la compatibilità del sistema con altri prodotti SW. 27

28 Check List di Usabilità della UI Esempio (1/2) Modello degli Utenti (definite 6 categorie di utenti) l utente che appartiene alla categoria 1 è quello che più di tutti conosce il dominio applicativo ma è anche quello meno esperto di applicazioni web e che ha meno familiarità con il sistema (l obiettivo è di testare il sistema in tutte le sue funzionalità, a cui solo la categoria 1 ha accesso, utilizzando un valutatore non esperto); gli utenti che appartengono alle categorie 2, 3, 4 e 5 hanno una conoscenza specifica del dominio relativa al proprio ruolo ma con una differente familiarità con i sistemi informatici; l utente che appartiene all ultima categoria risulta poco esperto del dominio applicativo ma con una maggiore conoscenza delle applicazioni web. Funzionalità Front-end Content Management Le funzioni disponibili sono usufruibili senza lasciare il sito 3 5 Le funzioni implementate sono usufruibili senza il download di plug-in 3 2 Il sito è visualizzabile con tutti i principali browsers 3 4 Tutte le funzionalità sono chiaramente rappresentate 3 5 Tutte le funzionalità sono raggruppate logicamente 2 5 Tutte le funzionalità sono facili da utilizzare 4 4 Tutte le funzionalità del Portale sono utili 4 5 Tutte le funzionalità implementate rispettano le specifiche dei requisiti

29 Check List di Usabilità della UI Esempio (2/2) Chiarezza visiva Front-end Content Management Il layout è chiaro e gli spazi sono adeguati tra box, immagini e parti di testo 3 4 La grafica è coerente con obiettivi e target del sito 4 4 Visibilità del testo sugli sfondi 2 4 Immagini e animazioni inutili sono evitate 2 3 Le pagine non sono troppo lunghe 3 3 Controllo Front-end Content Management L utente può cancellare tutte le operazioni 2 5 Nel caso di implementazione di funzioni come esecuzione guidata di diversi passi, l utente può cancellare l operazione di ogni singolo passo 2 5 C è una chiara opzione di uscita in ogni pagina 2 4 Il peso delle pagine è adeguato 3 2 Correzione e prevenzione degli errori Front-end Content Management Non vengono proposti messaggi di errore inutili 3 4 I messaggi di errore sono in formato testo 4 4 I messaggi di errore illustrano le azioni da compiere 2 4 I messaggi di errore forniscono una chiara opzione di uscita 2 3 I messaggi di errore forniscono la possibilità di ottenere assistenza

30 Progettare i casi di test Collaudo whitebox - Partendo dalla conoscenza della struttura interna del prodotto, il collaudo mira a verificare che le strutture interne funzionino secondo le specifiche progettuali Collaudo blackbox - Partendo dalle specifiche del progetto si va a verificare che tutte le funzionalità richieste nei requisiti siano presenti Test delle unità whitebox & blackbox Test di integrazione whitebox & blackbox Test di sistema blackbox Test di accettazione blackbox Limiti del testing Non può essere esaustivo a causa dell esplosione combinatoria del numero dei possibili casi di test Anche se fosse possibile fare un test per ogni possibile cammino d esecuzione non si potrebbe comunque garantire di aver trovato ogni difetto: il testing può rilevare la presenza di malfunzionamenti nel SW ma non dimostrarne l assenza (Dijkstra) 30

31 Report di Test Identificativo Caso di Test - contiene il codice che identifica univocamente ogni caso di test Descrizione - contiene la descrizione testuale del caso di test (cosa viene testato) Dipendenze - contiene l elenco dei casi di test dal cui risultato dipende il caso di test corrente Stato del Sistema - specifica lo stato in cui deve trovarsi il sistema per poter eseguire il caso di test corrente Input - indica i dati di input che si devono fornire al sistema per effettuare il caso di test corrente Note - contiene tutte le ulteriori informazioni utili per la comprensione o l esecuzione del caso di test corrente e che non sono specificate dagli altri campi Procedura di Esecuzione - indica la procedura che deve essere rigorosamente seguita per poter eseguire il caso di test corrente Valore Atteso - indica il valore che ci si attende dall esecuzione del caso di test. Si noti che per valore si intende non necessariamente un dato di output, ma anche un cambiamento nello stato del sistema senza produzione di output. Tale campo deve essere specificato prima dell esecuzione del caso di test Valore Ottenuto - indica il valore che si ottiene dopo aver eseguito il caso di test. Si noti che per valore si intende non necessariamente un dato di output, ma anche un cambiamento nello stato del sistema senza produzione di output Impatti - indica l insieme di altri casi di test su cui ha impatto un eventuale risultato positivo del caso di test corrente 31

32 Tecniche di testing funzionale (Blackbox( Blackbox) I criteri di progettazione si basano solo sui requisiti del sistema e NON è necessaria la conoscenza della sua realizzazione. Criteri di progettazione: Statistico - I casi di test sono selezionati in base alla distribuzione di probabilità dei dati di ingresso del programma (casi di test sui valori di ingresso più probabili per l utilizzo del sistema a regime) vantaggio - nota la distribuzione di probabilità, la generazione dei dati di test è facilmente automatizzabile. svantaggio NON è sempre possibile ricavare dalle specifiche una distribuzione di probabilità (o una che corrisponda alle specifiche) Partizione dei dati di ingresso - Il dominio dei dati di ingresso è ripartito in classi di equivalenza: due valori d ingresso appartengono alla stessa classe di equivalenza se, in base ai requisiti, dovrebbero produrre lo stesso comportamento del programma. Si procede esercitando il programma su valori rappresentanti di ognuna delle classi di equivalenza. Valori di frontiera - le classi di equivalenza possono essere realizzate o in base all eguaglianza del comportamento indotto sul programma o in base a considerazioni inerenti il tipo dei valori d ingresso. Come dati di test sono considerati i valori estremi di ogni classe di equivalenza. Svantaggio - è possibile che non siano noti i risultati del programma in corrispondenza dei valori scelti necessità dell oracolo 32

33 Tecniche di testing strutturale (whitebox( whitebox) Si basa sulla scelta dei casi di test in base alla struttura del codice testato e sull analisi del flusso di controllo o del flusso dei dati di un programma La progettazione dei test fa riferimento a un grafo di flusso ricavato dall analisi del codice del programma. 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. Criteri di copertura strutturale del flusso di controllo: Copertura delle istruzioni (statement coverage) - 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. Non è possibile individuare un errore se la parte del programma che contiene l errore e che genera il fallimento non viene eseguita Copertura delle diramazioni (edge coverage) - 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. Copertura delle condizioni (condition coverage) - 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. Copertura dei cammini (path coverage) - 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 33