Il Testing

1
Il Testing

• A. Fantechi
• Area di Ricerca di Trieste
• 19-20/4/2001

2
Attivita di Verifica sul codice

• Verifica che il codice soddisfi le sue specifiche
• Testing Attivita mirante alla scoperta di
  eventuali malfunzionamenti del prodotto software
  dovuti a guasti (anomalie difetti faults
  bugs - bachi) tramite lesecuzione del codice
  stesso, fornendogli opportuni dati in ingresso
  (analisi dinamica)
• Debugging attivita di localizzazione e
  rimozione dei guasti.

3
Teoria del testing
Programma P P D --gt R ok(P,d)
sse P sul dato di ingresso d X D
da il risultato aspettato ok(P) sse per
ogni d X D ok(P,d) (P è corretto) Test T
sottoinsieme di D. (test suite) t dato di
test se tX T P è corretto per un test T sse
  per ogni tX T ok(P,t)
4
Scopo dell'attività di testing è la rilevazione
di malfunzionamenti, quindi un test T ha
successo per un programma T se rileva uno o più
malfunzionamenti in P, successo(T,P) not
ok(P,T) un test che non rileva malfunzionamenti
manifesta non la correttezza del programma, ma la
sua inadeguatezza un test T per P e' detto
ideale se l'insuccesso di T implica la
correttezza di P OK(P,T) gt ok(P)
5
Dipende da quale si considera sia lo scopo
dellattivita di testing questa definizione va
bene se vediamo il testing come attivita
rivolta alla caccia di guasti (bug finding) Il
testing puo essere visto anche come attivita
mirata ad aumentare la confidenza nella bonta
del prodotto ? assenza di guasti Testing come
attivita svolta da un ente indipendente da
quello di sviluppo.
6
Criteri di selezione di test (per approssimare
test ideali) Un criterio di selezione C per un
programma P è un insieme di predicati sul domino
di ingresso D Un test T è selezionato da C
se per ogni t X T esiste cX C tale che c(t)
è vero e per ogni c X C esiste t X T tale che
c(t) è vero Esempio C (esiste t X T
tlt0),(0 X T),(esiste t XT tgt0) test
selezionati da C
-4,0,5-2,9,0,8,-12,6 Criterio di test
C ( t X D gt t X T) test esaustivo
7
Un criterio di selezione C è affidabile per P
se, per ogni coppia di test T1, T2 selezionati
da C, successo(T1,P) ltgt
successo(T2,P) Un criterio di selezione C è
valido per P se, qualora P non sia corretto,
esiste almeno un test T selezionato da C
successo(T,P) Teorema di Goodenough e
Gerhart affidabile(C,P) and valido(C,P)
and selezionato(C,T) and not successo(T,P)
gt ok(P)
8

• Teorema di Howden
• Non esiste un algoritmo che, dato P qualsiasi,
  generi un test ideale finito (test definito da
  un criterio affidabile e valido)
• Tesi di Dijkstra
• Il test di un programma può rilevare la presenza
  di malfunzionamenti, ma non dimostrarne l'assenza
• Teorema di Weyuker
• Dato P qualsiasi, i seguenti problemi sono
  indecidbili
• esiste almeno un dato di ingresso che causa
  l'esecuzione di un particolare comando?
• esiste un particolare dato di ingresso che causa
  l'esecuzione di una particolare condizione
  (branch)?
• è possibile trovare almeno un dato di ingresso
  che causa l'esecuzione di ogni comando di P?
• è possibile trovare almeno un dato di ingresso
  che causa l'esecuzione di ogni condizione
  (branch) di P?
• è possibile trovare almeno un dato di ingresso
  che causa l'esecuzione di ogni cammino di P?

9
LIVELLI DI TEST

• test di unità - mirato alla correttezza degli
  algoritmi.
• test di integrazione - mirato alla correttezza
  delle interfacce.
• test di sistema - affidabilità, sicurezza e
  prestazioni.
• test di accettazione - imposto dal cliente,
  verifica che il programma fa quello che voleva.
• test di regressione - verifica che non si siano
  introdotti errori in versioni successive

10
Test di Unità

• Test funzionale (black box)
• Test strutturale (white box)
• Test statistico

Variano per il principio su cui si basa il
criterio di selezione dei test.
11
Test funzionale (black box)
Il criterio di selezione si basa sulle specifiche
funzionali dellunita sotto test, ad esempio
attraverso EQUIVALENCE PARTITIONING Si divide
il dominio di input del programma in classi con
l'ipotesi che un caso di test per ciascuna classe
sia rappresentativo di tutti i valori della
classe. Per ciascuna condizione di input si
associano almeno due classi di equivalenza, una
valida ed una invalida. BOUNDARY VALUE
ANALYSIS Si scelgono i casi di test in prossimità
della frontiera delle classi.
12

Es. Supponiamo di avere una unita che si puo
comportare differentemente per valori negativi
o positivi dei dati in ingresso, ma il valore
effettivo non e particolarmente interessante.
Un criterio di test basato sul partizionamento
puo essere C (esiste t X T tlt0)(esiste t
XT tgt0) Cioe si testa lunita con almeno un
valore negativo e uno positivo. Se vogliamo
prestare attenzione ai valori di forntiera
(boundary analysis), possiamo includere lo
zero C (esiste t X T tlt0),(0 X T),(esiste t
XT tgt0)
13

Altre tecniche CAUSE-EFFECT GRAPHING Si disegna
un grafo dove gli archi rappresentano operatori
logici ? le specifiche vanno ridotte a
condizioni booleane, rappresentanti fatti di
ingresso o uscita (stanza doppia, alta
stagione, ). Ogni condizione booleana in
ingresso (uscita) identifica un sottoinsieme dei
dati in ingresso (in uscita).   ERROR
GUESSING Tecnica ad-hoc basata sull' intuito e
sull' esperienza di chi esegue il test.
14
Testing basato sulla specifica

•          specifica formale
• Possono essere identificate piu facilmente le
  partizioni
• e i boundary cases.
• puo essere automatizzato
• Es. Generazione di Test case da Finite state
  automata
• (UML state diagrams)

15
Test strutturale (white box)
Il criterio di selezione dei test si deriva dalla
struttura stessa del programma ? (in
particolare, dal grafo di flusso) Si selezionano
quei test che esercitano tutte le strutture del
programma Occorre decidere quali sono le
strutture di riferimento ? vari tipi di
testing a seconda della struttura scelta Occore
una misura che ci permette di decidere se sono
state esercitate tutte le strutture ? misura
di copertura (coverage)
16
Statement testing

• I test sono selezionati in base alla loro
  capacita di coprire i comandi (nodi del grafo di
  flusso)
• Coverage numero comandi eseguiti / numero
  totale comandi
• Un test e selezionato se garantisce una
  copertura dei comandi uguale a 1
• In questo modo si garantisce che I comandi sono
  tutti eseguiti almeno una volta.
• Non si garantisce di aver percorso tutte le
  strade (rami) almeno una volta
• if (c) comando1
• comando2
• Un test che rende la condizione c vera esegue
  tutti i comandi, ma non tutti i rami

17
Branch testing

• Si richiede che in questo caso vengano percorsi
  dai test tutti i rami del programma almeno una
  volta. (ogni arco del grafo di flusso deve
  appartenere almeno ad un cammino di esecuzione
  esercitato dal test).
• Coverage numero rami percorsi / numero totale
  rami
• Un test e selezionato se garantisce una
  copertura dei rami uguale a 1
• La copertura dei rami implica la copertura
  dei cammini

18
Condition testing

• if (xgt1 y0)
• comando1
• else
• comando2
• In questo caso sia la copertura dei comandi che
  quella dei rami non garantiscono che si siano
  testate tutte le combinazioni delle due
  condizioni in and.
• Ad esempio, un test potrebbe esercitare solamente
  le situazioni
• x 2, y 0 e x2, y1, garantendo la piena
  coperura dei rami e quindi dei comandi
• Cfr. con programma equivalente
• if (xgt1)
• if (y0) comando1
• else comando2
• else comando2
• In cui lo stesso test da una copertura rami e
  comandi del 60

19

• Basic condition coverage
• numero totale dei valori di verita assunti da
  tutte le condizioni basiche numero totale dei
  valori di verita delle condizioni basiche
• dove per numero totale dei valori di verita
  delle condizioni basiche si intende 2 volte il
  numero delle condizioni basiche, considerando
  cioe ogni condizione valutata sia a true che a
  false, ma senza considerare tute le possibili
  combinazioni dei due valori di verita su tutte
  le condizioni basiche.
• Nel caso precedente, I due casi di test x 0, y
  0 e x2, y1, peremettono di avere una
  copertura del 100 delle condizioni basiche.
• Come e evidente in questo caso, la piena
  copertura delle condizioni basiche non garantisce
  la copertura dei rami.

20

Daltra parte, se si considerano tutte le
possibili combinazioni dei valori di verita di
tutte le condizioni basiche (compound condition
coverage), le possibilita da coprire sono in
numero di 2 elevato al numero di condizioni
basiche, e quindi diventano un numero eccessivo
per condizioni appena complesse.

• Vengono percio utilizzati altri criteri, che
  considerano non solo i valori di verita delle
  condizioni basiche, ma anche la decisione finale
• MCDC Modified Condition / Decision Coverage
• MCDC implica copertura dei rami
• esempio ?

21

if (pos lt parseArray.length
(parseArraypos parseArraypos
parseArraypos ))
continue
22

room
open
if (pos lt parseArray.length
(parseArraypos parseArraypos
parseArraypos ))
continue
close
bar
Test case room open close bar result
1 false false
2 true true true
3 true false true true
4 true false false true true
5 true false false false false
23
Path testing

• I criteri di copertura finora visti non sempre
  consentono di rilevare quei guasti che vengono
  attivati solo da particolari cammini di
  esecuzione nel programma.
• Copertura dei cammini
• Cpath
• numero dei cammini eseguiti / numero totale dei
  cammini

24
test C1 C2 cammino
T1 0 0 S1 S3
T2 0 1 S1 S4
T3 1 0 S2 S3
T4 1 1 S2 S4
25

• Sono sufficienti i due casi di test T1 e T4 per
  ottenere una copertura del 100 dei rami.
  Alternativamente, sono sufficienti i due casi di
  test T2 e T3.
• Per una copertura del 100 dei cammini sarebbero
  necessari tutti i casi di test T1, T2, T3, T4.
• Il caso precedente è il solo caso, in assenza di
  cicli, in cui la copertura dei cammini e la
  copertura dei rami differiscono nel caso in cui
  ho due if then else annidati, infatti, sia i rami
  che i cammini sono 3.
• Si noti che il numero dei cammini e esponenziale
  con il numero degli if.

26
Il numero dei cammini e peroin generale
illimitato, per la presenza di cicli.

• Per questo motivo la path coverage non viene
  spesso nemmeno presa in considerazione in quanto
  tale. Semmai, quando si parla di copertura di
  cammini in presenza di cicli si pone in genere un
  limite superiore al numero di iterazioni che
  vengono svolte. Seguendo la terminologia
  introdotta da Miller, si parla di copertura Ct k,
  dove k è il numero di possibili diverse
  iterazioni che si vogliono considerare. Ad
  esempio, k2 significa che si vuole eseguire il
  ciclo con 0, 1, 2 iterazioni.
• Un modo comune di considerare la copertura dei
  cammini è quello di utilizzare k1. Se si adotta
  quindi la copertura Ct(k1) per ogni ciclo si
  considererà sia il cammino che non esegue affatto
  le azioni interne al ciclo sia quello che le
  segue (almeno) una volta. In questo modo si
  ottiene comunque la copertura dei rami. Anche qui
  occorre fare attenzione che si parla di "almeno"
  perchè non sempre sarà possibile individuare
  facilmente il caso di test che fa eseguire
  esattamente una volta le azioni del ciclo
  inoltre, il caso del for con numero di iterazioni
  fissato staticamente sarà sempre eseguito
  esattamente quel numero di volte.
• Si parla anche di criterio di N-copertura
  copertura legata al numero di iterazioni del
  loop.

27
Cyclomatic testing

• Si noti comunque che il numero dei cammini, anche
  limitando il numero delle iterazioni, rimane
  esponenziale con il numero if indipendenti tra
  loro.
• Sono stati definiti vari criteri di copertura
  basati sui cammini, tra cui il testing
  ciclomatico, che si basa sul numero di Mc Cabe
  si conta il numero di cammini linearmente
  indipendenti testati, e si considera soddisfatto
  il criterio quando il numero dei cammini testati
  raggiunge il numero ciclomatico della unita
  sotto test.

28
Copertura (coverage)

• Il concetto di copertura può essere utilizzato
  come metrica per valutare l'effettività dei test
  effettuati ad esempio, i casi di test T1 e T4
  forniscono il 100 di copertura dei rami e il 50
  di copertura dei cammini.
• Un criterio quantitativo di copertura viene
  spesso utilizzato come soglia, (es. 90 dei
  cammini) raggiunta la quale l'attività di testing
  viene considerata troppo costosa e viene quindi
  interrotta.
• Si puo usare una misura di copertura
  strutturale per valutare lefficacia di una fase
  preliminare di testing funzionale e per capire se
  questa ha lasciato scoperte (non esercitandole)
  alcune strutture del programma

29
Unfeasible paths

• Ritornando all'esempio di cui sopra, si noti però
  che potrebbe accadere che le condizioni C1 e C2
  siano dipendenti tra loro si consideri ad
  esempio il caso più banale, in cui C1C2. In
  questo caso si potranno al massimo esercitare due
  cammini, S1-S3 e S2-S4. Non si potrà cioè
  ottenere la copertura del 100 dei cammini, ma
  solo il 50 . Questo se si considerano i cammini
  sul grafo, ma i cammini possibili del programma
  (feasible paths o achievable paths) sono coperti
  al 100.
• La possibile presenza di cammini unfeasible (o
  Infeasible) rende quindi più difficoltosa la
  misurazione della copertura di cammini tale
  presenza in generale non può essere rilevata da
  un'analisi statica, ed anche la completa
  rilevazione dei cammini unfeasible attraverso
  un'analisi dinamica è stata dimostrata essere
  teoricamente impossibile

30
Unfeasible paths

• In alcuni casi, la presenza di cammini Unfeasible
  e voluta
• Defensive Programming si testano
  condizioni normalmente vere, che possono
  risultare false solo in presenza di guasti
  hardware/software nel caso risultino false si
  effettuano percioopportune azioni di trattamento
  del guasto.
• In altri casi, la presenza di cammini Unfeasible
  e indice di disattenzione nella stesura (o nel
  riutilizzo)del codice.
• A fronte di percentuali di copertura minori del
  100, si dovra giustificarne il motivo
  (normative DO-178B) si potra cosi
  duistinguere i casi di Defensive Programming da
  quelli di codice non sufficientemente curato.

31
Data flow testing

• Nella più recente produzione scientifica sul
  testing, non si tenta di ottenere la copertura
  dei cammini, ma semmai qualcosa di intermedio tra
  la copertura dei rami e quella dei cammini. Viene
  infatti definita una "data-flow" coverage, in cui
  i casi di test sono selezionati sulla base
  dell'utilizzo dei dati ad esempio un cammino
  dove la stessa variabile viene prima scritta e
  poi letta si considerano solo i cammini da
  assegnamenti a variabili a usi successivi della
  variabili i cammini analizzati hanno dunque una
  rilevanza diretta sul modo con cui i programmi
  trattano i dati.

32
Ordinamento dei criteri di copertura
Path testing
Compound cond. testing
N-Path testing
Cyclomatic t.
MCDC testing
Basic cond. testing
Branch testing
Statement testing
33
Ordinamento dei criteri di copertura
TEORICI
Path testing
Compound cond. testing
N-Path testing
Cyclomatic t.
MCDC testing
Basic cond. testing
Branch testing
Statement testing
34
Funzionale vs. strutturale

• Il testing funzionale e quello strutturale sono
  complementari
• Una specifica di una tabella lascia
  allimplementatore la scelta della struttura dati
  da utilizzare. Se la scelta e per una tabella
  hash, vi saranno diverse porzioni di codice
  eseguite a seconda che vi siano o meno
  collisioni. Test derivati dalla specifica non
  possono garantire di coprire sia il caso di
  collisione che quello di non collisione, mentre
  il piu semplice criterio di copertura
  strutturale lo garantisce.
• Viceversa, il caso dei missing paths. Questi
  guasti derivano dal non aver considerato alcuni
  aspetti dalla specifca, e possono essere rivelati
  solo da un testing basato sulla specifica, e non
  da un testing strutturale.

35
Test statistico
Mentre nei test funzionale e strutturale i dati
di test sono forniti da un criterio
deterministico, nel test statistico sono
casuali. In realtà posso usarlo in combinazione
con i precedenti ed ottenere 4 tipi di
test funzionale deterministico, funzionale
statistico, strutturale deterministico, strutt
urale statistico. ( il criterio di selezione
dei test e deterministico e definisce degli
intervalli i dati di test possono essere scelti
casualmente in tali intervalli)
36
Il test di una unita richiede la costruzione di

• Stub
• Modulo fittizio che presenta la stessa
  interfaccia di un modulo invocato dallunita
  sotto test.
• Drivers
• Modulo che ha la funzione di invocare l unita
  sotto test passandole I casi di test individuati
• Oracolo
• Puo essere un programma, ma anche lutente
  umano, e rappresenta lentita che decide se il
  test e passato o fallito.
• Automazione del testing strumenti di supporto
  alle attivita di costruzione di Drivers, Stubs,
  e Oracoli
• ? Cantata, Adatest,
  Logiscope,..

37
Test di integrazione

• In seguito al test dei singoli moduli, si esegue
  il test di integrazione per verificare la
  correttezza del programma complessivo, e
  lassenza di anomalie sulle interfacce tra i
  moduli. Per questo si seguono due metodi
•  
•    approccio non incrementale
•    approccio incrementale
•    Lapproccio non incrementale prevede di
  assemblare tutti i moduli e realizzare
  immediatamente lanalisi globale del sistema. È
  detto anche big bang test. Suppone di aver
  completato il test di unita per ogni modulo.

38
Test di integrazione

• Nellapproccio incrementale si parte testando dei
  singoli moduli, collegandoli poi con i moduli
  chiamanti o chiamati, e testando il sottosistema
  ottenuto, e cosi via fino a costituire il
  sistema complessivo.
• Non richiede di aver svolto il test di unita di
  tutti i moduli
• Esercita piu a lungo ogni singolo modulo
• Permette di localizzare piu facilmente le
  anomalie di interfaccia tra moduli.

39
Test di integrazione - STRATEGIE DI TEST
TopDown
Bottom Up Risultati veloci
inizia a sistema ultimato stub complessi
(emulatori, tabelle) driver
semplici output artificiale per simulare
parallelismo i moduli sottostanti
40
Test di integrazione - Criteri di copertura
Criteri di copertura sono stati definiti anche
per lattivita di test di integrazione. In
particolare, il criterio di copertura delle
chiamate di procedura ci dice se il testing di
integrazione ha esercitato tutte le procedure.
Con una granularita piu fine, il criterio di
copertura dei punti di ingresso e dei punti di
uscita dalle procedure consente di sapere se sono
stati esercitati tutti i punti di ingresso e i
punti di ritorno da una procedura o funzione.
41
Test di sistema

• Con il test di integrazione si è già realizzato
  il test delle funzionalità dellintero sistema,
  ora si vogliono analizzare alcune proprietà
  globali che non hanno senso se viste nellambito
  del singolo modulo. Esempi
• -    Test di stress ( overload ) si vuole
  verificare non solo che il programma funzioni
  secondo le specifiche, ma anche che si comporti
  in modo corretto in condizioni di carico di
  lavoro eccezionale. Per esempio un sistema per
  basi di dati normalmente viene interrogato in
  modo tale da produrre venti transazioni per unità
  di tempo. È progettato per sopportare fino a
  trenta transazioni.
• -     Test di sicurezza il sistema può essere
  usato in condizioni non corrette, ad esempio si
  sottopone a delle violazioni, anche di tipo
  accidentale.
• -    Test di robustezza si forniscono al
  sistema dei dati sbagliati, e si osserva il
  comportamento del sistema rispetto a tali dati.
  (esempio tipico si digitano sequenze casuali di
  tasti sulla tastiera per controllare se
  linterfaccia utente di un programma si pianta)

42
Test di sistema

• In alcuni casi, si usano strumenti specifici per
  il test di sistema
• ad esempio quando il codice software viene
  caricato su un microprocessore dedicato a qualche
  funzione di controllo (sistema embedded), si
  ricorre alluso di strumenti di simulazione
  dellambiente esterno al processore, o alluso di
  emulatori su macchina host della macchina target
  su cui verra caricato il software, o ai
  cosiddetti In-circuit emulator, che permettono
  alla macchina host di emulare il comportamento di
  un microprocessore target, ricevendone - tramite
  un apposito connettore che si sostituisce al
  processore sulla scheda del sistema target -
  direttamente gli input reali, e producendo valori
  in uscita direttamente al sistema.

43
Test di accettazione

• Nel test di sistema il software viene confrontato
  con la specifica dei requisiti (verifica).
• Questo test e normalmente responsabilita dello
  sviluppatore.
• Nel Test di accettazione il software viene
  confrontato con i requisiti dellutente finale
  (validazione)
• Questo test e normalmente svolto dal cliente.
• Una caratteristica del test di accettazione e
  che viene usualmente svolto senza avere a
  disposizione il codice sorgente
• Per prodotti di largo consumo si utilizzano i
  concetto di ?-test e ?-test.

44
Test di accettazione

• ?-test il software viene già usato allinterno
  della casa produttrice per verificarne le
  funzionalità, però ancora non è stato rilasciato
  allesterno
•  
• ?-test il software viene rilasciato a un numero
  selezionato di utenti che lo usano sapendo che
  non è una versione stabile, e che possono
  interagire con chi ha prodotto il software.

45
Test di regressione

• Testing di una nuova release come si puo
  minimizzare lo sforzo usando risultati del
  testing di versioni precedenti?
• Mantenere i drivers, gli stubs, gli oracoli e
• memorizzare i test cases della vecchia
  versione
• Nel corso del testing della nuova versione
• Tenere traccia dei cambiamenti
• Valutare limpatto dei cambiamenti
• ? Strumenti di supporto al testing di regressione

46
Problema dellincrementalita dei test

• Sarebbe auspicabile che il costo di ritestare un
  programma dopo una piccola modifica sia
  marginale, e non paragonabile al primo testing
  del programma
• I criteri di copertura strutturale non sono
  incrementali le percentuali di copertura possono
  venir sconvolte da una piccola modifica.

47
Analisi mutazionale

•  
• Dopo aver esercitato P su T, si verifica P
  corretto rispetto a T. Si vuole fare una verifica
  più profonda sulla correttezza di P introduco
  degli errori ( piccoli ) su P e chiamo il
  programma modificato P. Questo P viene detto
  mutante. Si eseguono su P gli stessi test di T.
  Il test dovrebbe rilevare gli errori. Se il test
  non rileva questi errori, allora significa che il
  test non era valido. Questo è un metodo per
  valutare la capacità di un test, e vedere se è il
  caso di introdurre test più sofisticati.
• ? Fault based testing
• ? Software Fault injection

48
Object-Oriented Testing

• Caratteristiche principali del paradigma object
  oriented
• Gli oggetti hanno uno stato, accessibile solo
  attraverso le loro interfacce
• Ereditarieta nuove classi possono essere
  derivate per specializzazione di classi esistenti
• Polimorfismo e dynamic binding le invocazioni
  dei metodi possono essere legate dinamicamente a
  codice diverso
• Genericita

49
Problemi per il testing

• Information hiding
• Gli oggetti, avendo uno stato, violano le
  ipotesi di un comportamento funzionale
• Shadow invocations
• I metodi possono essere invocati
  implicitamente (problemi relativi al conteggio
  delle percentuali di copertura)
• Polimorfismo e dynamic binding
• I metodi invocati non possono essere
  identificati staticamente
• Ereditarieta
• I metodi sono riutilizzati in classi diverse
  
• Genericita
• Le classi generiche devono essere
  instanziate per essere testate

50
Object Oriented ereditarieta
        Programmazione Procedurale Il codice e
strutturato in subroutines e moduli I moduli
sono composti in modo bottom-up o top-down
Quando una subroutine e stata testata, non lo
deve essere piu        Programmazione Object
oriented Il codice e strutturato in classi. L
ereditarieta e la relazione fondamentale tra
classi L ereditarieta favorisce il riuso e lo
sviluppo incrementale alcune operazioni non sono
modificate nelle sotto-classi, altre sono
ridefinite o cancellate       Problemi Come
fare test incrementale? Quali operazioni
ereditate devono essere ri-testate?
51
Problemi dovuti allereditarieta
class Shape private Point reference_point
public void put_reference_point(Point) point
get_reference_point() void move_to(Point)
void erase() virtual void rotate(int)
virtual void draw() 0 virtual float area()
shape(point) shape() class Circle public
Shape private int radius // new attribute
public void rotate(int) // redefined void
draw() // redefined void circle(point p, int
r)
Il metodo Circlemove_to deve essere testato?
52
Possibili approcci

• Flattering inheritance ogni sottoclasse viene
  testata come se tutte le caratteristiche
  ereditate fossere definite ex-novo
• I tests usati nelle super-classi possono essere
  riusati
• Molti tests sono ridondanti
• Testing incrementale ridurre i tests solo alle
  features nuove o modificate
• Si basa sulla storia del testing
• Insieme di tests ridotto

53
Caratteristiche Object Oriented la Genericita

• Programmazione Procedurale
• Non ci sono moduli generici (con leccezione di
  Ada)
•  
• Programmazione Object oriented
• I moduli generici sono presenti nella maggior
  parte dei linguaggi OO
• Concetto basilare per la costruzione di librerie
  di componenti riusabili
•       Problemi
• Quali assunzioni si possono fare sul parametro?
• Quale metodo usare nel testing di un componente
  generico gia riutilizzato?

54
Problemi dovuti alla Genericity
template vector T v int sz public
vector(int) void sort() ...
vector(complex) complex_vector(100)
vector(int) integer_vector(100) Quali
assunzioni devono essere fatte su int e complex
per chiamare il corrispondente metodo sort?
55
Caratteristiche Object Oriented Polimorfismo e
dynamic binding

• Programmazione Procedurale
• Le chiamate di procedura sono legate
  staticamente
• Programmazione Object oriented
• Un entita puo riferire oggetti di classi
  diverse di una gerarchia. ? Molte
  implementazioni di un operazione?
• La selezione delleffettivo codice da chiamare
  e posposta a run-time
•       Problemi
• Come coprire tutte le chiamate alle operazioni
  polimorfiche?
• Come esercitare tutte le implementazionidi
  unoperazione?
• Come trattare parametri polimorfici?
• Il testing strutturale non puo essere
  determinato staticamente

56
Un esempio di Problema dovuto al Dynamic Binding
void foo(Shape polygon) ... data
polygon.area ... Polygon puo essere un
triangolo, un pentagono, un quadrilatero Quale
implementazione di area viene effettivamente
chiamata?
57
Possibili approcci

• Tutte le possibili combinazioni di chiamate
  polimorfiche e parametri polimorfici rischiano di
  fare esplodere in modo combinatorio il numero dei
  casi di test.
• Si puo ottenere una riduzione di questo effetto
  attraverso tecniche di analisi statica che
  permettano di individuare le effettive chiamate
  delle unita interessate (data-flow analysis)

58
Tecniche tradizionali che funzionano anche per OO

• I test di sistema e di accettazione non sono
  influenzati, perche si basano sui requisiti
  funzionali.
• Gli approcci tradizionali al testing strutturale
  possono essere utilizzati per testare metodi
  singoli.
• Il test di regressione richiede solo di scrivere
  nuovi test per le caratteristiche nuove o
  modificate
• Lesecuzione dei test richiede solo modifiche
  sintattiche

59
Altre tecniche di verifica

• Analisi statica
• Analisi lessicale
• Analisi sintattica
• Controllo dei tipi
• Analisi del flusso dei dati (data flow analysis)
  

• Ispezione/ Review/ Walkthrough