Verifica e validazione della qualità del sw

Transcript

1 Verifica e validazione della qualità del sw Tecniche di Programmazione Lez. 07 Università di Firenze a.a. 2009/10, I semestre 1/40 contenuti Termini e definizioni Tecniche rispetto alle caratteristiche di Q Walkthrough e inspection Progettazione delle prove Valutazione delle prove 2/40 ottenere la qualità Seguire la ricetta (volta per volta) Definire bene e controllare Analisi e definizione dei requisiti Modelli per la qualità del software Strumenti per la definizione dei sistemi Metriche per definire livelli qualitativi Controllo dello sviluppo Vincoli contrattuali e aziendali di assicurazione della q. Verifiche e prove, come strumenti 3/

2 verifica e validazione Ingegneria del software (Bohem) Are we building the product right? Are we building the right product? ISO Conferma, a fronte di evidenze oggettive, che i requisiti sono stati soddisfatti Conferma, a fronte di evidenze oggettive, che i requisiti per un uso o un applicazione specifici sono stati soddisfatti 4/40 collaudo Validazione finale del sistema software Interna Alfa-test o precollaudo Svolta da chi ha sviluppato il sistema Esterna Beta-test o collaudo Svolta dal committente o dall utenza Può essere formale, per accettazione 5/40 termini notevoli Errore (mistake) Causa (umana), può non essere interessante Difetto (fault, bug) Introdotto da un errore, magari latente, va eliminato Malfunzionamento (failure) Prodotto da un difetto, di solito si traduce in un danno Scostamento (error) Differenza fra comportamento osservato e desiderato 6/

3 il primo bug (documentato) 1945, sul Mark II Trovato da G.M. Hopper 7/40 metodi di V&V statici e dinamici Metodi statici Non prevedono l esecuzione del codice Quasi sempre svolte come attività di verifica Adottati per i componenti Metodi dinamici Comportano l esecuzione del codice Attività di verifica o di validazione Adottati per i componenti o per il sistema (validazione) 8/40 metodi statici V&V senza esecuzione del codice Metodi manuali Basati sulla lettura del codice (desk-check) Più comunemente usati Più o meno formalmente documentati Metodi formali Basati sulla prova di proprietà Assistiti da strumenti Fertile terreno di ricerca risultati nella generazione di codice) 9/

4 perché i metodi statici Pratici, spesso intuitivi, generalizzabili Indispensabili per alcune caratteristiche di q. Convenienza economica Costi proporzionali alle dimensioni del codice Bassi costi di infrastruttura (desk-check) Buona prevedibilità dei risultati Necessari in alcuni casi (UKDef Std ) Efficaci per classi di errori Memory leak Dead/livelock, priority inversion,... 10/40 recensione del codice Inspection e Walkthrough Metodi pratici Basati sulla lettura del codice Dipendenti dall esperienza dei verificatori Per organizzare le attività di verifica Per documentare l attività e i suoi risultati Metodi complementari Inspection più pratico e rapido Walktrhrough più collaborativo e formativo 11/40 inspection Caratteristiche Eseguire una lettura mirata del codice Verificatori diversi dai programmatori Focalizzata: caratteristiche di qualità, error guessing Organizzazione Pianificazione Definizione della lista di controllo Lettura del codice Correzione dei difetti Documentazione 12/

5 walkthrough Caratteristiche Eseguire una lettura critica del codice Gruppi misti ispettori/sviluppatori Percorrere il codice simulandone l esecuzione Organizzazione Pianificazione Lettura del codice (separata) Discussione Correzione dei difetti Documentazione 13/40 metodi dinamici (prove) V&V tramite esecuzione del codice Prevedono l esecuzione del software Ambiente controllato, input e output definiti Come verifica (sulle componenti) Come validazione (sul sistema) Idea generale tanto intuitiva quanto complessa Progettazione, esecuzione, analisi, debugging Costi e risultati difficili da stimare e rispettare 14/40 caratteristiche Una prova non è (quasi) mai definitiva È definita e ripetibile I suoi risultati non sono estendibili Evidenzia malfunzionamenti Le prove sono costose Occorrono tempo, macchine, persone È necessario un processo definito Richiedono attività di ricerca dei difetti 15/

6 elementi di una prova Caso di prova (o test case) Una tripla <input, output, ambiente> Batteria di prove (o test suite) Un insieme (una sequenza) di casi di prova Spesso organizzata per condividere/riusare l ambiente Procedura di prova Le procedure (automatiche e non) per eseguire, registrare analizzare e valutare i risultati di una batteria di prove 16/40 ambiente di prova Ripetibilità della prova Ambiente definito (hardware, condizioni, ) Casi di prova definiti Procedure definite Strumenti Driver Stub comp. fittizia per pilotare comp. fittizia per sostituire Registrazione e analisi dei dati di prova 17/40 conduzione di una prova Definizione dell obiettivo della prova Progettazione della prova Realizzazione dell ambiente di prova Esecuzione della prova Analisi dei risultati Valutazione della prova 18/

7 progettazione delle prove Criteri funzionali A scatola chiusa (black box) Basati sulla conoscenza delle funzionalità Funzionalità, affidabilità, efficienza Criteri strutturali A scatola aperta (white box) Basati sulla conoscenza del codice Obiettivo (generale) di esercitare il software Ricerca di difetti 19/40 criteri funzionali Generazione dei casi di prova Obiettivi Ridurre i casi di prova Assicurare la significatività delle prove Non fare ipotesi sul codice Applicabilità Collaudo Progettazione anticipata delle prove 20/40 selezione casuale o statistica Modello dei dati d ingresso Modello dei valori Modello operazionale della loro distribuzione Progettazione Batterie di prove corrispondenti al modello Nei valori e nella distribuzione Variabili casuali, non valori a caso 21/

8 valori di frontiera Modello dei dati di ingresso Partizionato in insiemi con frontiera definita Insiemi di dati validi e non validi Progettazione Prove su ogni limite Valori corrispondenti, inferiori e superiori Esercitare il trattamento dei casi limite 22/40 partizioni equivalenti Modello dei dati di ingresso Insiemi con comportamento equivalente Selezione di valori rappresentanti Progettazione Prove su ogni valore rappresentante Scelta opportunistica dei rappresentanti Esercitare i comportamenti del sistema 23/40 generazione sintattica Modello dei dati di ingresso Definizione sintattica degli ingressi Sequenze, iterazioni e selezioni di simboli Progettazione Batterie di prove come frasi del linguaggio Batterie su frasi valide e non valide Metodo strumentale (sel. casuale) 24/

9 grafi causa-effetto Modello dei dati d ingresso Fatti elementari di ingresso e uscita Specifica booleana come causa-effetto Progettazione Specifica e validazione dei requisiti Casi di prova rappresentativi dei fatti elementari Metodo strumentale (partizioni) 25/40 criteri strutturali Generazione dei casi di prova Obiettivi Ridurre i casi di prova Assicurare la significatività delle prove Sfruttando la conoscenza del codice Applicabilità Verifica delle componenti Necessitano di codice e strumenti 26/40 lcsaj Linear Code Sequence And Jump Struttura elementare di codice Identificabile in ogni programma Progettazione Identificazione delle LCSAJ: <start, end, jump> Casi di prova per esercitare le LCSAJ Indipendente dal linguaggio (liv. binario) 27/

10 transizione di stati Automi a stati finiti Modello della componente Stati, eventi che inducono transizioni, azioni Progettazione Realizzazione del modello Casi di prova per esercitare stati e transizioni Uso a livelli d astrazione diversi 28/40 grafi di flusso Grafo di flusso Definisce la struttura del codice Ottenuto a partire dal codice (con strumenti) Esercitare la maggior parte del codice Comandi, condizioni, decisioni Cammini, n-cicli Assegnamenti e usi Assegnamenti e usi in espressioni e calcoli 29/40 funzionali vs strutturali Generalità degli approcci Rispetto alla validità dei risultati Rispetto alle caratteristiche da provare Rispetto ai costi da sostenere Dipendenze e implicazioni I criteri funzionali non dipendono dal codice I criteri strutturali sono utili per valutare le prove Uso congiunto (gray box) Progettazione funzionale Valutazione strutturale 30/

11 prove di integrazione Costruzione e verifica del sistema Realizzazione parallela delle componenti Realizzazione e verifica indipendenti In condizioni ottime, l integrazione è banale (big bang) Problemi Errori nella realizzazione delle componenti Modifica delle interfacce Cambiamenti nei requisiti Riuso di componenti Progettazione conseguente delle prove 31/40 strategie di integrazione Incrementale bottom-up o top-down Verifica delle funzionalità vs simulazione Sbilanciamento nell esercizio delle componenti Disponibilità dei componenti Ordine di realizzazione (c. iterativo/evolutivo) Prima i componenti critici (alto rischio di difetti) Costi della realizzazione di driver e stub Inutilità dell esercizio di driver e stub Componenti coese implicano stub complicati Sistemi accoppiati implicano molti driver Sfruttamento di driver naturali e sicuri (GUI) 32/40 economia delle prove Costi vs confidenza Le prove devono fornire adeguata confidenza Come strumento di sviluppo interno Come strumento di collaudo e accettazione La confidenza delle prove costa Valutazione di una prova Qualità di una prova in sé Raggiungimento della confidenza desiderata Stima della maturità del prodotto Certificazione dei risultati 33/

12 copertura Quanto la prova esercita il prodotto Copertura del 100% non è assenza di difetti Non è detto che il 100% sia raggiungibile Funzionale, su funzioni e argomenti Requisiti, punteggio funzionale Profili operazionali, valori di frontiera, partizioni,... Strutturale LCSAJ, stati, transizioni Nodi del grafo di flusso, comandi decisioni, n-cicli,... 34/40 fallimenti provocati e mutanti Fallimenti provocati Seminare difetti per ritrovarli con le prove Indicatore di adeguatezza : R = d. trovati / d. seminati Stima della maturità (difettosità residua) Mutanti Programmi costruiti modificando l originale Mutanti morti (non passano le prove) e vivi I vivi sono tali per prove inadeguate o per equivalenza Indicatore di adeguatezza: S = morti / (mutanti-eq) NB: l equivalenza è indecidibile 35/40 certificazione dei risultati Oracolo Lo strumento che genera i risultati attesi necessari per certificare i risultati delle prove In particolare quando i casi di prova sono generati Criteri generali Basati sulle specifiche funzionali Basati sulla semplificazione delle prove Basati su componenti indipendenti Costi e implicazioni sull adeguatezza delle prove 36/

13 risultati dalle specifiche Risultati ricavati dalle specifiche Specifiche formali (generazione di invarianti) Specifiche eseguibili (back-to-back) Es.: grafi causa-effetto Inversione delle funzioni Quando l inversa è più facile A volte disponibile fra le funzionalità Limitazioni per difetti di approssimazione 37/40 semplificazione dei dati Semplificazione dei dati d ingresso Provare le funzionalità su dati semplici Risultati noti o calcolabili con altri mezzi Ipotesi di comportamento costante Semplificazione dei risultati Accontentarsi di risultati plausibili Tramite vincoli fra ingressi e uscite Tramite invarianti sulle uscite 38/40 programmi indipendenti Versioni precedenti dello stesso sistema sw Disponibili (per funzionalità non modificate) Prove di non regressione Versioni multiple indipendenti Programmi pre-esistenti (back-to-back) Sviluppate ad hoc Semplificazione degli algoritmi 39/

14 riferimenti H. Zhu e altri, Software Unit Test Coverage and Adequacy, ACM Computing Surveys, 1997 Standard for Software Component Testing, British Computer Society, SIGIST, 1997 G.A. Cignoni, P. De Risi, Il test e la qualità del software, Il Sole 24 Ore, /