Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
1
11
Corso di Laurea MagistraleCorso di Laurea Magistralein in
Ingegneria InformaticaIngegneria Informaticaper la Gestione dper la Gestione d’’aziendaaziendaGestione della Qualità-II parte
La produzione del software: metodologie estandards
a.a.a.a. 20102010--20112011Docente: Gigliola Docente: Gigliola VagliniVaglini
22
Lezione 11,12Lezione 11,12
Software Software Verification&ValidationVerification&Validation
2
33
Tecniche di verifica: analisi dinamica
44
Problemi Problemi
Il comportamento aspettatoIl comportamento aspettato I criteri da usareI criteri da usare
3
55
Oracolo Condizione necessaria per effettuare un test:
– conoscere il comportamento atteso per poterlo confrontare con quello osservato per poter definire l’oracolo
L’oracolo conosce il comportamento atteso per ogni caso di prova– Oracolo umano
si basa sulle specifiche o sul giudizio– Oracolo automatico
generato dalle specifiche (formali) stesso software ma sviluppato da altri versione precedente (test di regressione)
66
Criteri empirici
Risolvere problemi insolubili con soluzioni ad hoc– D è diviso in sottodomini D1, D2, …, Dn tali
che ogni elemento di ogni Di ha più o meno lo stesso comportamento
– D = D1 D2 … Dn– Si sceglie un test per ogni sottodominio Se Dj ∩ Dk ≠ si usa un elemento
dell’intersezione D’=Dj ∩ Dk per ridurre i test
4
77
TestingTesting strutturalestrutturale
88
TestingTesting strutturalestrutturale
Il criterio che deriva i test è basato sul codice interno dei moduli Se parti significative della struttura del
programma non sono testate, il testing èinadeguato
5
99
Tecniche di Tecniche di testingtesting strutturalestrutturale Tecniche in generale fondate sull'adozione di
metodi di copertura degli oggetti che compongono la struttura dei programmi
COPERTURA: definizione di un insieme di casi di test ( in particolare dati di input) in modo tale che gli oggetti di una definita classe (es. strutture di controllo, istruzioni, archi del CFG, predicati,..etc.) siano attivati almeno una volta nell'esecuzione dei casi di test
1010
Criteri di copertura basati sul flusso del controllo
Statement coverage Edge coverage Condition coverage Path coverage Data flow (syntactic dependency)
coverage
6
1111
1212
7
1313
1414
Il caso di test è sufficiente per garantire la copertura delle istruzioni?
Quali possibili fault non rivela?– Fault nel trattamento di valori positivi di A[i]
8
1515
1616
9
1717
1818
Il caso di test usato in precedenza copre tutti rami del grafo?– No. Non viene coperto l’arco corrispondente al caso
false dell’istruzione if E se aggiungo il caso (N=1, A[0]=7, X=9)?
– Posso scoprire eventuali fault per valori positivi di A[i].
Quali fault sicuramente non rivelerò?– Fault in uscita dal loop per la condizione A[i] ≥ X
10
1919
Copertura delle condizioni
Dato un programma P, viene definito un insieme di casi di test tale che tutti i possibili valori delle componenti di condizioni composte sono provati almeno una volta. La copertura di tutte le condizioni NON
implica la copertura di tutte le decisioni
2020
11
2121
2222
Copro tutte le condizioni?– No
Quali casi devo aggiungere?– Entrambe le condizioni (i<N), (A[i]<X) devono essere
false e vere in differenti test.– Devo aggiungere un test i cui dati causino l’uscita dal
loop per un valore più grande di X Quali fault eventualmente non scoprirò?
– Fault che si verificano dopo diverse iterazioni del loop.
12
2323
Copertura di condizioni multiple
Dato un programma P, viene definito un insieme di casi di test la cui esecuzione implica l'esecuzione, per ogni decisione, di tutte le combinazioni di condizioni
La copertura di tutte le combinazioni di condizioni implica la copertura di tutte le condizioni e di tutte le decisioni
2424
13
2525
N-copertura dei cicli
Un test T soddisfa il criterio di n-copertura dei cicli se e solo se ogni cammino contenente un numero intero di iterazioni di ogni ciclo non superiore ad n è eseguito per almeno un caso di test T
Problema: stabilire il numero ottimale di iterazioni....
2626
Copertura dei cammini DEVE ESSERE ATTIVATO OGNI CAMMINO
DEL GRAFO I problema: il numero dei cammino è,
generalmente, infinito II problema: infeasible path Soluzione: selezione in base a condizioni di un
numero finito ed eseguibile di cammini:– metodi fondati sui grafi di controllo– metodi data flow
(… naturalmente un buon testatore cerca anche le ragioni della presenza di infeasible path …)
14
2727
Metodi basati sui CFG L’insieme (o un sottoinsieme definito) dei
cammini di un CFG viene partizionato in un numero finito di classi di equivalenza– Metodo dei cammini esemplari– Metodo dei cammini linearmente indipendenti
(McCabe)
Criterio di copertura: un insieme di casi di test che assicuri l’attraversamento almeno una volta di almeno un cammino per ogni classe.
2828
Cammini esemplari Un cammino privo di circuiti è detto cammino
elementare– Il numero di cammini elementari in un grafo è finito
Si considerano i cammini elementari e totali di CFG(P)
Classi di cammini: un cammino elementare totale e tutti i cammini che da esso differiscono unicamente per il numero di attraversamenti di circuiti che sul cammino giacciono
15
2929
3030
Cammini linearmente indipendenti
Un cammino si dice linearmente indipendente se introduce almeno un nuovo inseme di istruzioni o una nuova condizione; in un CFG un cammino è l. indipendente se attraversa almeno un arco non ancora percorso (teoria dei grafi)
16
3131
Cammini linearmente indipendenti
Il numero dei cammini linearmente indipendenti di un programma è pari al numero ciclomatico di McCabe(metrica del SW basata sull’analisi della complessità del flusso di controllo):
V(G) = E - N +2– E: n.ro di archi in G– N: n.ro di nodi in G
V(G) = P + 1– P: n.ro di predicati in G
V(G) = n.ro di regioni chiuse in G + 1 Test case esercitanti questi cammini garantiscono
l’esecuzione di ciascuna istruzione almeno una volta
3232
17
3333
3434
18
3535
3636
19
3737
TestingTesting funzionalefunzionale
3838
TestingTesting funzionalefunzionale Cosa testare
– Funzionalità esterne: funzionalità visibili all’utente e definite dai requisiti e dalle specifiche
– Funzionalità interne: funzionalità non visibili all’utente e definite dal progetto di high e low level
Si parte da– Definizione Funzionalità: dati di ingresso, dati
di uscita, precondizioni, postcondizioni
20
3939
TestingTesting funzionalefunzionale
3 passi fondamentali– Decomporre la specifica in funzionalità
testabili indipendentemente– Identificare valori rilevanti– Generare specifiche di test imponendo vincoli
4040
Decomporre la specifica in funzionalitàtestabili indipendentemente
Identificare unità funzionali Per ogni unità identificata individuare:
– parametri dell’unità funzionale– ambiente dell’unità funzionale– elementi nell’ambiente che possono influenzare il
comportamento funzionale dell’unità– Per ogni parametro o elemento di ambiente
identificare le caratteristiche elementari (categorie)
21
4141
Identificare valori rilevanti Per ogni categoria identificata al passo
precedente definire i valori rilevanti– Casi normali– Casi di confine– Casi speciali– Casi errati
Necessità di vincoli: ogni combinazione di valori rilevanti per i parametri e gli elementi di ambiente considerati è un possibile caso di test– Le combinazioni sono molte e molte combinazioni sono
impossibili
4242
Vincoli per ridurre il numero di combinazioni
Definire i casi di errore per cui èsufficiente un caso di test Definire i vincoli tra valori di parametri
diversi Definire i casi singolari per cui è
sufficiente un solo caso di test– I casi di test possono passare da centinaia di
migliaia a poche decine
22
4343
Criteri di copertura per il testingfunzionale
Ogni funzionalità deve essere eseguita almeno una volta
Per ogni funzionalità si effettua il numero di esecuzioni dedotte dai dati di ingresso e di uscita, da precondizioni e postcondizioni
Definito il dominio dei dati di I/O si effettuano test case ottenuti selezionando– valori in posizione centrale– valori di frontiera (tra sottodomini)– valori “speciali”– Precondizioni e postcondizioni per test case
positivi negativi (invalid input data, invalid output data) neutrali
4444
Come fareCome fare
Molto dipende da come sono date le specifiche del sistema– Linguaggio naturale– Specifiche formali
23
4545
Linguaggio naturaleLinguaggio naturale La selezione dei test consiste nello scomporre una
specifica in un insieme di casi rilevanti e proporre per ciascun caso uno o più test
Questo processo non è automatizzabile, ma dipende dall’esperienza di chi porta avanti i test, ad esempio, tuttavia– una qualche struttura, ad es. gli standard dell’organizzazione,
può aiutare: si costruisce un catalogo dei casi di test;– come pure delle linee guida per ridurre la discrezionalità, tipo:
almeno un caso di test per ogni sottoinsieme di dati omogenei e validi combinazioni di dati “non validi” dati “di frontiera”
4646
Esercizio Esercizio Una “event queue” in un sistema di simulazione è
una coda con priorità dove gli eventi sono estratti secondo i loro “time-stamp”– si estrae per primo l’elemento con il timestamp più
precoce– l’ultimo entrato tra eventi con lo stesso time-stamp è
l’ultimo ad uscire Determinare un insieme di casi di test per una
“event queue”
24
4747
Comportamenti attesiComportamenti attesi Funzionamento corretto
– Inserzione Inserzione al più di tanti elementi quanti previsti dalla
dimensione (se fissata) nell’ordine dei time-stamp– Estrazione
Estrazione dell’elemento con time-stamp più precoce inserito da più tempo
Funzionamento scorretto– Inserzione
Inserire un elemento in una coda non inizializzata– Estrazione
Estrarre un evento prima di averne inserito alcuno
4848
Cosa fareCosa fare Si devono considerare almeno i seguenti casi
– Si vuole estrarre un elemento da una coda che ne contiene solo uno
– Diverse inserzioni seguite da altrettante estrazioni– Inserzioni ed estrazioni alternate– Si inseriscono tanti elementi da riempire la coda (se un massimo
è definito)– Si inseriscono solo elementi con time-stamp diverso nell’ordine
dei time-stamp– Inserzione di elementi con differente timestamp fuori ordine– Due elementi con lo stesso time-stamp vengono inseriti di
seguito– Due elementi con lo stesso time-stamp vengono inseriti
intervallati da elementi con time-stamp diversi
25
4949
Cosa fareCosa fare
Estrazione di un evento prima che ne sia mai stato inserito uno Estrazione di più elementi di quelli inseriti Inserzione di più elementi della capacità
massima Operazioni su una coda non inizializzata
(in alcuni linguaggi non è possibile
5050
Testing basato sulla tabella delledecisioni
Si costruisce una tabella con tante righe quante sono le possibili decisioni e tante colonne quanti sono i possibili risultati
Si verifica che il risultato sia consistente con la decisione presa.
26
5151
Esempio Esempio Un word-processor può presentare porzioni di
testo in tre differenti formati : plain text (p), boldface (b), italics (i).
Si possono applicare comandi ad ogni porzione di testo: text plain (P), boldface (B), italics (I), emphasize (E), superemphasize (SE).
Sono inoltre disponibili comandi per settare E=Bo E=I; SE=B oppure SE=I, oppure SE=B+I
5252
Tabella Tabella
b,ib,iiibbpp**SE=B+ISE=B+I
**SE=BSE=B**SE=ISE=I
**E=BE=B**E=IE=I
******SESE****EE
****II****BB
**PP
27
5353
Procedura generale: condizioni Procedura generale: condizioni basebase
5454
Procedura generale: condizioni Procedura generale: condizioni compostecomposte
28
5555
Procedura generale: condizioni Procedura generale: condizioni modificatemodificate
5656
Grafi causaGrafi causa--effettoeffetto
29
5757
Vincoli Vincoli
5858
Esempio: vincoliEsempio: vincoli
B e I escludono entrambi P (uno non può chiedere sia plain text che, per esempio, italics per la stessa porzione di testo) E e SE sono mutuamente esclusivi.
30
5959
6060
Copertura Copertura
Generare tutte le possibili combinazioni di input e controllare gli output– Si può ridurre il numero procedendo
all’indietro a partire dagli output– Per ogni nodo OR con output true si usano le
combinazioni di input con un solo true– Per ogni nodo AND node con output false: si
usano le combinazioni di input con solo un false
31
6161
TestingTesting guidato dalla sintassiguidato dalla sintassi
6262
Tecniche meno empiricheTecniche meno empiriche
Il dominio dei dati di ingresso è suddiviso in classi di casi di test in modo tale che, se il programma è corretto per un caso di test, si possa dedurre ragionevolmente che è corretto per ogni caso di test in quella classe– Una classe di equivalenza rappresenta un
insieme di stati validi o non validi per una condizione sulle variabili d’ingresso
32
6363
Classi in base alla condizione sulle Classi in base alla condizione sulle variabili dvariabili d’’ingressoingresso
Se la condizione specifica– Intervallo di valori Una classe valida per valori interni all’intervallo,
una non valida per valori inferiori al minimo, e una non valida per valori superiori al massimo; una classe per valori uguali o vicini agli estremi dell’intervallo
– Valore specifico Una classe valida per il valore specificato, una non
valida per valori inferiori, e una non valida per valori superiori
6464
Classi in base alla condizione sulle Classi in base alla condizione sulle variabili dvariabili d’’ingressoingresso
– Elemento di un insieme discreto Una classe valida per ogni elemento dell’insieme, una non valida per un elemento non appartenente
– Valore booleano Una classe valida per il valore TRUE, una classe
non valida per il valore FALSE
33
6565
Selezione dei casi di test
Ogni classe di equivalenza deve essere coperta da almeno un caso di test Un caso di test per ogni classe non valida Ciascun caso di test per le classi valide
deve comprendere il maggior numero di classi valide ancora scoperte
6666
Casi limiteCasi limite I casi di test che esplorano condizioni limite
spesso rilevano la presenza di malfunzionamenti Le condizioni limite
– Sono direttamente agli estremi– Immediatamente al di sopra– Immediatamente al di sotto degli estremi di:
Classi di equivalenza di ingresso Classi di equivalenza di uscita
Usare la creatività per cercare situazioni estreme
34
6767
Tecniche di verifica: analisi statica
6868
Analisi staticaAnalisi statica È il processo di valutazione di un sistema
o di un suo componente basato sulla forma, struttura, contenuto, documentazione senza esecuzione. L’analisi formale usa rigorose tecniche
matematiche: è usata soprattutto per la verifica del codice e dei requisiti specie quando questi sono specificati con linguaggi formali
35
6969
Tecniche principaliTecniche principali
Analisi statica in compilazione Code reading Code inspections - reviews Control flow analysis Data flow analysis Esecuzione simbolica
7070
Analisi statica in compilazione I compilatori effettuano analisi statica del
codice per verificare che un programma soddisfi particolari caratteristiche di correttezza prima di generare il codice oggetto.
Le informazioni e le anomalie che può rilevare un compilatore dipendono dalle caratteristiche del linguaggio e dalle facilities di cui dispone.
Es. linguaggi con regole di visibilità statica dei nomi permettono la rilevazione di un maggiore numero di anomalie di quelli con regole di visibilità dinamiche.
36
7171
Analisi statica in compilazione
Tipiche anomalie identificabili: nomi di identificatori non dichiarati, incoerenza tra tipi di dati coinvolti in una istruzione, incoerenza tra parametri formali ed effettivi in chiamate a sottoprogramma, codice non raggiungibile dal flusso di controllo
7272
Code reading E’ effettuata un’attenta lettura del
codice per individuare errori e/o discrepanze con il progetto. Il lettore effettua mentalmente una
pseudoesecuzione del codice e processi di astrazione che lo conducono a verificare la correttezza del codice rispetto alle specifiche e il rispetto di standard adottati.
37
7373
Code reading Tipici errori identificabili: nomi di identificatori
errati, errato innesto di strutture di controllo, loop infiniti, inversione di predicati, commenti non consistenti con il codice, incorretto accesso ad array o altre strutture dati, incoerenza tra tipi di dati coinvolti in una istruzione, incoerenza tra parametri formali ed effettivi in chiamate a sottoprogramma, inefficienza dell’algoritmo, non strutturazione del codice, codice morto, etc.
Il code reading è talvolta indicato anche con le dizioni desk review o desk checking
7474
Code inspection - review Riunioni formali cui partecipa un gruppo di persone che
include almeno una persona del team di sviluppo Il codice è esaminato linea per linea e i partecipanti
fanno commenti e/o annotazioni Ai partecipanti viene fornita per tempo la
documentazione necessaria (codice e relativi documenti) per preparare la revisione
L’analisi effettuata viene discussa nella riunione dove vengono decise le azioni eventualmente da intraprendere (accettazione del codice, rigetto, annotazioni su eventuali non aderenze a specifiche, indicazioni delle modifiche da apportare).
38
7575
Control-flow analysis Il codice è rappresentato tramite un Control
Flow Graph – CFG Il grafo è esaminato per identificare
ramificazioni del flusso del controllo e verificare l’esistenza di eventuali anomalie quali codice irraggiungibile e non strutturazione.
L’identificazione dei loop (goto e ricorsione) èl’attività più importante: la maggior parte del tempo in esecuzione e la gran parte delle ottimizzazioni
7676
Riducibilità La riducibilità formalizza la well structuredness
di un CFG Un grafo si riduce applicando due semplici
regole finché possibile:– I loop su un nodo si sostituiscono con un nodo– Sequenze di nodi in cui si entra solo dal primo nodo e
si esce dall’ultimo si possono sostituire con un nodo Se il codice è strutturato (loop naturali=si entra
solo da un nodo e si esce solo da un nodo), il CFG si può ridurre ad un solo blocco
39
7777
ControlControl--flowflow analysisanalysis
Anche in presenza di CFG non strutturato è necessario scoprire– Quali sono gli archi indietro (back edge)– Quali sono i nodi e gli archi compresi nel ciclo Importanza dei dominatori.
– L’arco da m a n è un arco “indietro” se n domina m– Calcolare i dominatori di ogni nodo richiede l’esame
del CFG varie volte a seconda di come si visita il grafo
7878
Data-flow analysis L’evoluzione del valore delle variabili è intrinsecamente
dinamica, ma alcuni aspetti possono essere analizzati staticamente in base alle operazioni eseguite – definizione: alla variabile è assegnato un valore– uso: il valore della variabile è usato in un’espressione o un
predicato– annullamento: al termine di un’istruzione il valore associato alla
variabile non è più significativo Il codice è rappresentato da un CFG associato con un
DFG definito in base alla relazione DEF_USO, oppure associato ad altre cose derivate dalla relazione DEF_USO.
40
7979
DataData--flowflow analysisanalysis La definizione di una variabile, così come un
annullamento, cancella l’effetto di una precedente definizione della stessa variabile, ovvero ad essa è associato un nuovo valore (o il valore nullo)
Una corretta sequenza di operazioni prevede che:– L’uso di una variabile x sia sempre preceduto da una
sua definizione, senza annullamenti intermedi– Un uso non preceduto da una definizione può
corrispondere all’utilizzo di un valore non determinato
8080
DataData--flowflow analysisanalysis
La definizione di una variabile x dovrebbe essere sempre seguita da un uso, prima di un’altra sua definizione o annullamento Una definizione non seguita da un uso
corrisponde ad un valore assegnato ma non utilizzato e quindi inutile
41
8181
DataData--flowflow analysisanalysis
8282
DataData--flowflow analysisanalysis
42
8383
DataData--flowflow analysisanalysis La sequenza (auu) di x e la sequenza (ddd) di x2
in swap sono indicative di una qualche anomalia Non sempre però le sequenze ...au... o ...dd..
corrispondono ad anomalie– au può comparire in un generatore di numeri casuali (è
letto il contenuto di una cella di memoria non inizializzata per determinare il seme della generazione)
– dd può dipendere da una cattiva strutturazione del programma (la prima definizione non è usata nella esecuzione considerata ma lo è un un’altra, su un altro cammino)
8484
Esempio: Esempio: gcdgcd
43
8585
Esempio Esempio
È stato introdotto un errore nella riga 7:– a:=y invece di b:=y
Si costruisce CFG(gcd)– i nodi corrispondenti alle istruzioni delle
righe 11 e 12 sono stati spezzati in due per avere un solo tipo di operazione su ogni variabile
8686
CFG(CFG(gcdgcd))
44
8787
DataData--flowflow analysisanalysis di di gcdgcd
8888
Considerazioni Considerazioni
In presenza di cicli il numero di sequenze di operazioni non è limitabile a priori Si possono usare “espressioni regolari”
per rappresentare insiemi di cammini
45
8989
Espressioni regolariEspressioni regolari
9090
CheckCheck listlist: metodo top: metodo top--down di down di produzioneproduzione
Produzione, uso e archiviazione di check list Analisi dei documenti di definizione dei requisiti e di
specifica, estrazione delle funzionalitò esterne e di altre features, dati di I/O e pre e post condizioni, definizioni priorità
Analisi dei documenti di progetto di high e low level, estrazione delle funzionalità interne, dati di I/O e pre e post condizioni, definizioni priorità
Definizione dei test case e delle procedure di test Generazione tabella di copertura (o dei test case)
46
9191
Lezioni 13,14Lezioni 13,14
Oltre il test del moduloOltre il test del modulo
9292
Tecniche di verificaTecniche di verifica
Testing di integrazione,sistema, accettazione,
regressione
47
9393
NecessitNecessitàà del test di integrazionedel test di integrazione Correttezza dei singoli non garantisce correttezza del tutto
– Causa prima: specifiche incomplete– Specificare tutte le interazioni può essere:
difficile, non cost-effective, impossibile
Esempio 4 luglio 1996: Ariane 5. Dal rapporto ufficiale: <<The specification of the inertial reference system and the tests
performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently the realignment functionwas not tested under simulated Ariane 5 flight conditions, and the design error was not discovered. >>
9494
48
9595
Errori di integrazioneErrori di integrazione Interpretazione inconsistente di parametri o valori
– Esempio: Uso di unità di misura diverse Violazione di valori di dominio o capacità
– Esempio: Buffer overflow Effetti collaterali su parametri o risorse
– Esempio: stesso file temporaneo condiviso inavvertitamente Funzionalità omesse o non capite Problemi non funzionali
– Esempio: Diversi requisiti di prestazione Mancate corrispondenze dinamiche
– Esempio: Chiamate polimorfe
9696
Strategie di integrazione: Bigbang
Tutti i moduli sono integrati contemporaneamente– Non richiede scaffolding– Minimizza osservabilità, diagnosticabilità,
efficacia,feedback– Non permette la rilevazione in anticipo di
difetti di integrazione
49
9797
Strategie di integrazione: strutturali
Moduli costruiti, integrati e testati in base alla struttura gerarchica del progetto– Bottom-up (drivers)– Top-down (stubs)– Sandwich o backbone Dagli estremi al centro seguendo uso/inclusione. Servono (meno) drivers e stubs Flessibile e adattabile Maggior complessità di pianificazione
9898
Strategie di integrazione: orientate alle funzionalità
I moduli sono integrati in base alle caratteristiche dell’applicazione– Threads
Moduli integrati seguendo le funzionalità del sistema Enfatizza le relazioni tra moduli che cooperano per
realizzare funzionalità del sistema– Moduli critici
Moduli integrati seguendo la loro criticità, considerando sia Rischi esterni (es:sicurezza) che Rischi interni (es: pianificazione)
Permette di ridurre i rischi
50
9999
Confronti Strategie orientate alle funzionalità richiedono
maggior attenzione a pianificazione rispetto a quelle strutturali– Utili quando i maggiori costi di gestione sono
bilanciati da miglior test– Di solito per sistemi complessi
Spesso si combinano più strategie– Strategie top-down, bottom-up e sandwich per piccoli
sottosistemi– Combinazione di thread e moduli critici per grossi
sottosistemi
100100
Necessità del test di sistema
Verificare il sistema nella sua interezza Test di unità e integrazione non bastano
– Alcuni errori non si evidenziano prima che il sistema sia completo
– Alcune proprietà sono tipiche del sistema Prestazioni Affidabilità (Reliability)
51
101101
Quando e come I test di sistema dovrebbero essere generati
prima del progetto– Si evitano “influssi negativi”– Verifica di requisiti come effetti collaterali
Possono essere arricchiti in fase di progetto e codifica– Sintomi di problemi non identificati in fasi iniziali
Test funzionali da specifiche dei requisiti Test basato su difetti Può sovrapporsi (parzialmente) con integrazione
102102
UnitUnitàà--integrazioneintegrazione--sistemasistema
52
103103
Accettazione Accettazione Verificare che il prodotto sia pronto per la
consegna– Non trovare ulteriori difetti
Misurare affidabilità come frequenza di difetti– MTBF (Mean Time Between Failures): tempo medio
tra difetti consecutivi– disponibilità del prodotto: tempo di funzionamento
corretto rispetto a tempo totale di servizio atteso
104104
Regressione: perché
Nuove versioni possono introdurre nuovi errori o metterne in rilievo altri prima non visibili Vogliamo che una nuova versione non sia
peggiore della precedente: NON REGREDISCA
53
105105
Regressione: come Rieseguire tutti i test Importanza di progettazione dei test
– Scaffolding– Oracoli– Documentazione
Necessità di revisione e manutenzione dei test– Validi– Non validi– Obsoleti
106106
Ridurre il test di regressione Tecniche basate sul codice
– Selezione basata su grafo di flusso– Selezione basata su flusso ei dati
Tecniche basate sulle specifiche– Dipende da tecnica di test funzionale
Tecniche basate su priorità ed esecuzione selettiva– Storie di esecuzione: priorità ai test eseguiti più tempo fa– Rilevamento di difetti: priorità a test che hanno rilevato difetti– Massima copertura: priorità a test che garantiscono maggior
copertura
54
107107
Tecniche di verifica: il Tecniche di verifica: il testingtestingnei linguaggi Onei linguaggi O--OO
108108
Nuovi concettiNuovi concetti Caratteristiche: astrazione sui dati, ereditarietà, polimorfismo,
binding dinamico, genericità, …. Nuovi livelli di test
– Il concetto di classe come dati + operazioni cambia il concetto di unità– Il test di integrazione di oggetti è diverso dal test di integrazione
tradizionale: driver e stub devono considerare lo stato (information hiding)
Nuove tecniche di generazione di casi di test che tengano conto di– Stato– Polimorfismo e binding dinamico– Ereditarietà– Genericità– Eccezioni– Lo stato non può essere ispezionato con tecniche tradizionali
55
109109
Livelli di test Cosa è un modulo in un sistema OO? …esistono
diverse scuole di pensiero, una possibilità:– Basic unit testing: test di una singola operazione di
una classe– Unit testing: test di una classe nella sua globalità– Integration testing: test delle interazioni tra classi
L’opacità (information hiding) rende più difficile la costruzione di oracoli
110110
Lo stato Linguaggi procedurali standard
– Componente base: procedura– Metodo di test: test della procedura basato su input/output
Linguaggi orientati a oggetti– Componente base: Classe = struttura dati + insieme di operazioni– Oggetti sono istanze di classi– La correttezza non è legata solo all’output, ma anche allo stato
E’ sufficiente osservare le relazioni tra input e output?– Lo stato di un oggetto può essere inaccessibile– Lo stato “privato” può essere osservato solo utilizzando metodi
pubblici della classe (e quindi affidandosi a codice sotto test)
56
111111
Polimorfismo e binding dinamico Linguaggi procedurali classici
– Le chiamate a procedura sono associate staticamente al codice corrispondente
Linguaggi orientati a oggetti– Un riferimento (variabile) può denotare oggetti
appartenenti a diverse classi in relazione tipo/sottotipo ( polimorfismo), ovvero il tipo dinamico e il tipo statico dell’oggetto possono essere differenti Più implementazioni di una stessa operazione Il codice effettivamente eseguito è identificato a runtime,
in base alla classe di appartenenza dell’oggetto (bindingdinamico)
112112
Polimorfismo e binding dinamico: problemi
Il test strutturale può diventare non praticabile– Come definisco la copertura in un’invocazione
su un oggetto polimorfo?– Come creo test per “coprire” tutte le possibili
chiamate di un metodo in presenza di bindingdinamico?
– Come gestisco i parametri polimorfi?
57
113113
Ereditarietà Linguaggi procedurali classici
– Il codice è strutturato in procedure– Una volta eseguito il test di unità di una procedura,
generalmente, non è necessario rieseguirlo (salvo modifiche)
Linguaggi orientati a oggetti– Il codice è strutturato in classi– L'ereditarietà è una relazione fondamentale tra
classi– Nelle relazioni di ereditarietà alcune operazioni
restano invariate nella sotto-classe, altre sono ridefinite, altre aggiunte (o eliminate)
114114
Ereditarietà: problemi Posso “fidarmi” delle proprietà ereditate? È necessario identificare le proprietà che
devo ri-testare: Operazioni aggiunte, operazioni ridefinite,
operazioni invariate, ma influenzate dal nuovo contesto
Può essere necessario verificare la compatibilità di comportamento tra metodi omonimi in una relazione classe-sottoclasse
58
115115
Genericità
Linguaggi procedurali– In generale non è possibile definire moduli
generici Linguaggi orientati a oggetti
– I moduli generici sono presenti nella maggior parte dei linguaggi OO
– La genericità è un concetto chiave per la costruzione di librerie di componenti riusabili
116116
Genericità: problemi
Le classi parametriche devono essere instanziate per poter essere testate– Che ipotesi fare sui parametri? Servono classi “fidate” da utilizzare come
parametri
59
117117
Testing basato sullo stato Tecnica per testare se i metodi di una classe interagiscono
correttamente tra loro, monitorando i data members della classe Si testano tutti i metodi di una classe, uno per uno, rispetto
all’insieme degli stati che un oggetto può assumere: se qualche elemento non cambia lo stato dell’oggetto secondo il modo aspettato, allora il metodo è dichiarato contenente errori
Ciascun metodo è invocato in tutti i possibili stati che l’oggetto può assumere e dopo ciascuna invocazione si controlla se lo stato risultante è quello atteso
Enfasi sulla interazione tra metodi, cioè se il metodo comunica propriamente con gli altri metodi dell’oggetto attraverso lo stato dell’oggetto.– Gli stati di un oggetto possono essere innumerevoli– Necessità di ridurre lo spazio degli stati da esaminare– Valori specifici– Gruppi di valori generali (suddivisione in classi di equivalenza)
118118
Testing incrementale per sottoclassi
Tecnica per testare classi appartenenti ad un gerarchia– quando una classe eredita da una classe già
testata, il testing della sottoclasse riguarda solo alcuni elementi
– una sottoclasse R è definita come una classe base P più un modifier M
60
119119
Testing incrementale per sottoclassi
Con riferimento alla ereditarietà singola, gli elementi di una sottoclasse possono essere classificati in– New: elementi non esistenti nella classe base;– Virtual-new: elementi specifici della sottoclasse con binding dinamico;– Redefined: elementi ereditati ma la cui definizione è modificata nella
sottoclasse;– Virtual-redefined: elementi ereditati e modificati e con binding
dinamico;– Recursive: elementi ereditati;– Virtual-recursive: elementi ereditati ma con binding dinamico.
A seconda del tipo l’elemento viene testato riusando eventualmente casi di test in modo totale o parziale (con aggiunta di altri specifici).
120120
Tracciamento del processo di Tracciamento del processo di testingtesting
61
121121
Tracciamento del processo di testing
Lo scopo è tracciare i progressi nei test e paragonarli al piano
Test progress S Curve Asse Y: Test case Asse X: time (week) 3 informazioni: Attempted, Successful, Planned
– Una S Curve rappresenta il fatto che i dati sono cumulativi nel tempo e la forma ad S risulta da un periodo di intensa attività di test
122122
62
123123
124124
63
125125
Tracciamento del processo di testing
Sistemi che richiedono alta stabilità: uso sotto stress (20 ore per giorno)– Utilizzo della CPU– Si traccia il tempo di utilizzo durante il
funzionamento tra release differenti– Associato alla misurazione dei crash non
previsti nelle varie release
126126
64
127127
128128
65
129129
130130
Tracciamento del processo di testing
Misure dello sforzo
Matrice di celle che confronta l’effettività del testing (righe) con il numero di difetti trovati (colonne)
66
131131
132132
67
133133
Alcuni esempi di processoAlcuni esempi di processo
134134
CleanroomCleanroom
68
135135
Il processo Cleanroom Il “Cleanroom Software Engineering process” è
un processo di sviluppo teso a produrre software con un livello certificabile di reliability.
Il processo fu sviluppato da Harlan Mills e altri all’IBM nella metà degli anni ‘80.
Cleanroom mira alla prevenzione dei difetti, piuttosto che alla loro rimozione (il nome richiama le camere pulite usate nell’industria elettronica per prevenire l’introduzione di difetti nella fabbricazione di circuiti integrati).
136136
Principi base Lo sviluppo del software è basato sull’uso di metodi formali. La verifica che la specifica è rispettata dal progetto è realizzata
tramite “team review”. L’implementazione è sviluppata in modo incrementale con un
“controllo di qualità statistico”.– La qualità di ogni incremento è misurata a confronto di standard
prestabiliti per verificare che il processo sta procedendo in modo accettabile. Un fallimento nel raggiungere uno standard produce l’interruzione del testing per l’incremento attuale e il ritorno alla fase di progetto.
– Il testing viene portato avanti come un esperimento statistico. I comportamenti di input/output selezionati e testati sono poi analizzati statisticamente per ottenere una stima dell’affidabilità del software e un livello di confidenza in quella stima.
69
137137
138138
ExtremeExtreme programmingprogramming
70
139139
Extreme programming
Extreme Programming (XP) è una metodologia di tipo “agile”: cioè mette l’accento più sull’adattabilità che sulla predicibilità. Successivi cambiamenti dei requisiti sono
visti come naturali durante il progetto, anzi più naturali che il tentativo di definire tutti i requisiti all’inizio.
140140
Scopo Scopo The main aim of XP is to reduce the cost of
change. In traditional system developmentmethods the cost of changing the requirementsat a later stage will be high.
XP sets out to reduce the cost of change byintroducing basic values, principles and practices.
By applying XP, a system development project should be more flexible with respect tochanges.
71
141141
Principi basePrincipi base
XP fornisce un insieme di pratiche che incoraggiano particolari valori. I valori sono 5
– Communication– Simplicity– Feedback– Courage– Respect (the latest value)
142142
72
143143
144144
TestingTesting per una proprietper una proprietààspecifica: usabilitspecifica: usabilitàà
73
145145
Cosa è l’usabilità
L’usabilità è un requisito non funzionale e non può essere misurato direttamente, ma deve essere quantificato in modo indiretto, misurando, ad esempio, il numero di problemi riportati dagli utilizzatori.
146146
Definizione ISO A set of attributes that bear on the effort
needed for use, and on the individualassessment of such use, by a stated or impliedset of users. (ISO 9126, 1991)
The extent to which a product can be used byspecified users to achieve specified goals witheffectiveness, efficiency and satisfaction in a specified context of use. (ISO 9241, 1998)
Scomposizione del concetto di usabilità in un insieme di parametri misurabili.
74
147147
I processi
Analisi esigenze utente (--> parametri di usabilità) Progetto di esperimenti di valutazione Esecuzione degli esperimenti Valutazione dei risultati
148148
Esperimenti Osservazioni naturalistiche (esperimenti con singoli soggetti, qualitativi) Esperimenti in senso stretto, quantitativi:– Variabili indipendenti, variabili dipendenti– Obiettivo: verificare l’esistenza di
un’effettiva correlazione tra var. indip. e var. dip.
– Tecniche statistiche
75
149149
Progettazione dell’Esperimento Obiettivo sperimentale Identificazione dei soggetti
– Numero, capacità, omogeneità, casualità Procedura sperimentale
– Come eseguire, con quali task,quando, dove, con quali fasi, con quale training
Esecuzione e Raccolta dei Dati sperimentali– Misure sui risultati, sul processo, log,
videoregistrazione, protocolli verbali (think aloud, think about), questionari
150150
Progettazione dell’Esperimento
Elaborazione dei Dati raccolti– Validazione dei dati, calcolo degli indici che
interessano, analisi statistiche per verificare le ipotesi (valutazione della correlazione tra indici e variabili indipendenti)
Valutazione dei Risultati– Interpretazione, cause, conclusioni, decisioni
76
151151
Sviluppo incrementale