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