Software Testing

Transcript

Software Testing - Università degli Studi di Firenze

Software Testing
Dott. Ing. Michele Banci
DSI – Università degli Studi di Firenze
1
Introduzione

Attività atta alla valutazione di un programma (sistema) determinando
che esso verifichi un determinato risultato atteso.

Sebbene sia cruciale per la qualità del software e sia largamente
utilizzato, Il testing del software rimane ancora un’arte, ciò deriva
dalla ridotta comprensione dei principi del software.

La difficoltà deriva dalla complessità del software: Non si potrà mai
testare completamente un programma di una certa complessità.

Testing non vuol dire solo debugging

Scopo del Testing: assicurazione di qualità, V&V, stima
dell’affidabilità.

Le più importanti: testing di correttezza e di affidabilità.

trade-off fra budget, tempo e qualità.
2
Introduzione

È quel processo di esecuzione dei un programma (o sistema) con lo
scopo di trovare errori.

Il software è “simile” a altri sistemi fisici in cui si hanno ingressi e si
producono risultati (uscite).

La differenza del software consiste nel modo in cui esso fallisce.

º
Sistemi fisici: falliscono in un fissato (“piccolo”) insieme di modi.
º
Il software può fallire in molti modi BIZZARRI.
Individuare tutti i diversi modi di fallimento di un software è
impossibile in generale.
3
Introduzione

A differenza dei sistemi fisici il software contempla esclusivamente
errori di design, non sono presenti errori di costruzione (di
produzione).
º
No Corrosione
º
No Deterioramento
º
Non si modifica nel tempo
I difetti di design permangono indefinitamente e resteranno latenti
fino a quando non saranno attivati.
4
Introduzione

I “bugs” esistono quasi sempre in qualsiasi programma di una certa
dimensione:
º
Poca cura Æ NO
º
Irresponsabilità Æ NO
Generalmente la complessità del software è intrattabile in generale
º
la mente umana ha una ridotta abilità nel trattare la
complessità.
5
Introduzione

Il software, e anche i sistemi digitali, sono sistemi non continui, pertanto
testare i valori di soglia non è sufficiente per garantirne la correttezza.

Devono essere testati TUTTI i possibili valori Æ un test completo
sarebbe irrealizzabile.
º
E.g. Testare un programma che somma due numeri interi di 32 bit
in ingresso.
• Produce 264 test cases distinti = 18.446.744.073.709.551.616
• 31.536.000 secondi = 1 anno

Inoltre per applicazioni che interagiscono con il mondo esterno:
º
Timing
º
unpredictable environmental effects
º
human interactions
6
Introduzione

Se si verifica un fallimento durante il testing e a seguito il codice viene
cambiato Î
º
il programma potrebbe superare altri test eseguiti in precedenza e
non superati.
º
Il programma potrebbe non superare test fatti in precedenza e già
superati.

Il testing dovrebbe ricominciare. Il costo di una tale attività risulterebbe
proibitivo.

Pesticide Paradox: Every method you use to prevent or find bugs
leaves a residue of subtler bugs against which those methods are
ineffectual.
7
Introduzione

Il testing è parte integrante dello sviluppo del
software.

Esso viene distribuito in ogni fase del ciclo di
sviluppo del software.

In genere, più del 50% del tempo di sviluppo viene
utilizzato per il testing.
8
Lo scopo del testing
1.
Migliorare la qualità;
2.
Verifica e Validazione (V&V);
3.
Stimare l’affidabilità.
9
Migliorare la qualità.

Computer e software usati in applicazioni critiche possono causare danni a
cose e persone a causa dei “BUGS”.
º
airplane crashes,
º
space shuttle missions to go awry,
º
halted trading on the stock market,
º
Bugs can kill.
º
Bugs can cause disasters.

la qualità e l’affidabilità di un software = vita o di morte.

Qualità = conformità con i requisiti specificati in fase di design.

Il Debugging (~ testing) viene eseguito dai programmatori al fine di
individuare difetti di progettazione. La natura imperfetta dell’uomo rende
impossibile creare un programma corretto fin da subito.

Lo scopo del debugging consiste nel trovare i problemi e risolverli durante la
fase di programmazione.
10
Verification & Validation (V&V)

V&V (Verification & Validation) è un altro scopo importante del
testing.

Il testing può essere utilizzato come metrica.
º
Basandoci sul risultato dei medesimi test è possibile eseguire
un confronto comparativo fra prodotti diversi ma basati sulle
medesime specifiche.

Non è possibile testare la qualità in modo diretto, ma è possibile
testare quei fattori correlati con la qualità.

La qualità è costituita da 3 insiemi di fattori
º
functionality, engineering, e adaptability.
• Questi 3 insiemi di fattori si possono pensare come una
dimensioni nello spazio della qualità del software.
• Ciascuna dimensione può inoltre essere scomposta nei sui
singoli fattori.
11
Software Quality Factors
Functionality
Engineering
Adaptability
(exterior quality)
(interior quality)
(future quality)
Correctness
Efficiency
Flexibility
Reliability
Testability
Reusability
Usability
Documentation
Maintainability
Integrity
Structure
12
Misura della qualità

Un buon testing deve poter fornire delle misure per i fattori di qualità rilevanti.
L’importanza dei fattori varia dal tipo di applicazione in esame.
º
I sistemi in cui è in gioco la vita umana: reliability e integrity.
º
Sistemi gestionali: usability e maintainability.
º
Per programmi usati una sola volta per scopo scientifico: nessun fattore.

Il nostro testing deve essere efficace, creato in modo tale da misurare i fattori di qualità
in modo tale da rendere tangibile e visibile la qualità.

Clean tests, o positive tests : Test atti a validare se il prodotto fa quello che deve
fare.
º
In realtà si riesce ad affermare che il programma funziona correttamente per
quello specifico caso di test. Un numero finito di test non può garantire che il
programma funziona correttamente in tutte le possibili situazioni.

Dirty tests, o negative tests: al contrario dei precedenti anche un solo test fallito è
sufficiente per dimostrare che il programma non funziona. Alcune parti del programma
devono avere una sufficiente gestione delle eccezioni in grado di superare un certo
livello di test negativi.

Design for testing: è una parte importante dello sviluppo del software il quale rende
più semplice il testing del programma stesso (riduce tempi e costi).
13
For reliability estimation

L’affidabilità del software è spesso in relazione con la struttura dello stesso e la
quantità del testing a cui è stato sottoposto.

Basandosi su un approccio operazionale (stima della frequenza di uso dei vari
input), il testing può fungere da campionamento statistico in modo tale da
creare i dati di fallimento per stimare l’affidabilità.

Si utilizzano le medesime tecniche di testing inventate 20-30 anni fa.

Il testing del sw può essere molto costoso, ma in certi casi catastrofici il non
fare testing può esserlo molto di più.

Risolvere il problema del testing del software può essere paragonabile al
problema della terminazione di Turing (halting problem): data una macchina di
Turing M ed una stringa x, stabilire se M termina la computazione avendo x
come input.
º
Non possiamo mai essere sicuri della correttezza di un programma.
º
Non possiamo mai essere sicuri della correttezza delle specifiche
º
Non possiamo mai essere sicuri della correttezza del sistema di
verifica
14
Classificazione di metodi di testing (Livelli di test)
By purpose:
By life-cycle phase:

correctness testing,

requirements phase testing,

performance testing,

design phase testing,

reliability testing

program phase testing,

security testing.

evaluating test results,

installation phase testing,

acceptance testing
By scope:

unit testing,
º
mirato alla correttezza degli algoritmi
º

component testing,

integration testing,
º

mirato alla correttezza delle interfacce
system testing.
º

maintenance testing. (Test di
regressione)
º
affidabilità, sicurezza e prestazioni
imposto dal cliente, verifica che il
programma soddisfi le richieste del
cliente stesso.
verifica che non si siano introdotti
errori in versioni successive
15
Correctness testing (for unit test)

La correttezza è il requisito minimo per un programma, è lo scopo
primario del testing. Necessita di un “Oracolo” per poter discriminare
un comportamento corretto da uno non corretto.

Tester e sua conoscenza del modulo sotto test:
º
White box (Test Strutturale) e.g. control flow, data flow, etc.
º
Black box (test funzionale)

Variano per il principio su cui si basa il criterio di selezione dei test.

L’approccio black-box e white-box non si limitano solo al test di
correttezza.
16
Test Funzionale - Black-box testing

È un metodo in cui i dati di test sono derivati dalle specifiche
funzionali senza considerare la struttura finale del software.

Viene chiamato: data-driven, input/output driven, or
requirements-based testing.

Infatti ci si interessa soltanto delle funzionalità del modulo.

Test funzionale: enfatizza l’esecuzione delle funzioni e l’analisi dei
loro dati di ingresso e uscita.

Il tester considera il software come una scatola nera – sono visibili
solo gli ingressi, le uscite e le specifiche funzionali, la funzionalità
viene determinata osservando le uscite prodotte da determinati
ingressi (funzioni di trasferimento).

Vengono inviati (esercitati) vari input e le corrispondenti uscite sono
confrontate con le specifiche così da validarne la correttezza. Tutti i
casi di test sono derivati dalle specifiche. Non sono considerati i
dettagli implementativi del codice.
17
Black-box testing – specifiche funzionali

Inoltre, non potremo mai essere sicuri della correttezza e
completezza delle specifiche. Dovuto alle limitazioni del linguaggio
usato per le specifiche (linguaggio naturale), si avranno sicuramente
problemi di ambiguità.

Anche se usassimo formalismi o linguaggi ristretti, si potrebbe
ancora errare nello scrivere tutti i possibili casi nelle specifiche.

Le specifiche in se stesse possono divenire un problema intrattabile:
Non è possibile specificare precisamente ogni situazione che si può
incontrare utilizzando un numero limitato di parole.

Le persone sono in grado di specificare chiaramente quello che
desiderano? Normalmente sono in grado di dire se un prototipo
corrisponde o meno a ciò che si desiderava.

Il problema delle specifiche contribuisce a circa il 30% dei bugs nel
software.
18
Black-box testing – spazio degli ingressi

Maggiore è lo spazio di ingresso coperto e maggiori saranno i bugs
individuati, pertanto si avrà maggior confidenza sulla qualità del sw.

Idealmente si potrebbe tentare di testare esaustivamente lo spazio degli
ingressi. Î IMPOSSIBILE

L’esplosione combinatoria è il maggior problema del testing funzionale.
19
Black-box testing research forse eliminare

La ricerca nel campo del black-box testing si rivolge a massimizzare l’efficacia del
testing col minor costo possibile (minor numero di casi di test). Non è possibile
esaustivamente usare tutto lo spazio degli stati degli ingressi, ma è possibile sollecitare
esaustivamente un sottospazio di tale spazio.

Equivalence Class Partitiong (ECPT)
º
Il partitioning una tecnica molto comune. Se abbiamo partizionato lo spazio degli
ingressi e assunto che tutti i valori in una partizione sono equivalenti, allora si può
testare solo un solo valore rappresentativo di ciascuna partizione per coprire tutto
lo spazio degli ingressi.

Il domain testing partiziona il dominio di ingresso in regioni, e considera i valori di
ingresso in ciascun dominio come una classe di equivalenza. I domini possono essere
testati esaustivamente e coperti selezionando un valore rappresentativo per ciascun
dominio. Ovviamente i valori di confine rivestono un certo interesse. I test cases che
esplorano i valori di confine hanno maggior valore rispetto a test con valori contenuti
all’interno del dominio.

BOUNDARY VALUE ANALYSIS (BVAN)
º

richiede uno o più valori limite selezionato come rappresentativo. Il problema con
questo tipo di analisi sta nella errata definizione dei domini, questa definizione
non può essere scoperta correttamente solo sulla base delle specifiche.
Un buon partizionamento richiede la conoscenza della struttura del software.
20
Black-box testing research

Random testing
º

Utilizzato per valutare l’affidabilità e le performance ma non
per la ricerca degli errori.
I metodi basati sulle specifiche si riassumono in:
1.
EQUIVALENCE CLASS PARTITIONING (ECPT)
• 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.
2.
BOUNDARY VALUE ANALYSIS (BVAN)
• Si scelgono i casi di test in prossimità della frontiera
delle classi.
3.
TEST CASE by ERROR GUESSING (TCEG)
• Tecnica ad-hoc basata sull' intuito e sull' esperienza di
chi esegue il test.
21
Random Testing

I dati utilizzati per i test cases sono selezionati casualmente nel
dominio di ingressso del programma.

Random testing non vuol dire che si abbandona completamente la
input/output analysis del programma o del modulo.

Lo scopo della maggior parte delle applicazioni è di creare un profilo
operazionale del programma o del modulo.

Definizione 1: Operational Profile
º
Il “Profilo operazionale” di un programma nel dominio dei dati di
ingresso è la distribuzione di probabilità di selezionare ciascun
punto del dominio dei dati di ingresso mentre il programma
viene utilizzato in condizioni normali di lavoro.
22
Random Testing

Una delle maggiori applicazioni del random testing è il fornire dati per
la stima dell’affidabilità del software.

I Test case sono generati casualmente in accordo con il proofilo
operazionale, e i dati di fallimento vengono acquisiti. I dati ottenuti
dal random testing posso essere usati per la stima dell’affidabilità.
Nessun altro metodo di testing può essere utilizzato per tale stima.

Qualsiasi stima di affidabilità non è corretta se il profilo operazionale
non è corretto.
23
Svantaggi del Random Testing
1.
Può essere necessario creare un gran numero (proibitivo) di tests
per poter essere confidenti di avere sufficientemente coperto il
dominio di ingresso;
2.
La distribuzione casuale degli ingressi identifica soltanto i guasti del
programma
º
3.
Principio di Pareto-Zipf (“legge 80/20”): i valori 80% e 20%
sono ottenuti mediante osservazioni empiriche di numerosi
fenomeni e sono solo indicativi, in genere l'80% dei risultati
dipende dal 20% delle cause.
È difficile stimare la copertura o determinare se abbiamo
adeguatamente il dominio di ingresso.
24
Random Testing - Testing Oracles

Il gran numero di casi di test che sono tipicamente necessari per
avere risultati statisticamente significativi impone la necessità di
creare automaticamente i casi di test.
º
Casi di test automaticamente generati (TVG) – è corretto se
abbiamo il profilo operazionale e un buon modo di generazione
casuale;
º
Inoltre occorre un metodo per decidere se il risultato del test è
un risultato atteso oppure no.
º
Un programma o un insieme di dati o un processo che decide
se i risultati sono quelli attesi è chiamato: Testing Oracle!
25

Esempio: Consideriamo la specifica di una funzione toLower la
quale prende una stringa dallo standard input e pone la stringa
corrispondente sullo standard output, con tutte le lettere
maiuscole sostituite nelle corrispondenti lettere minuscole (i.e. ’A’
to ’a’, ’B’ to ’b’, etc.).

Le stringhe possono essere formate da tutti i caratteri ASCII fra 32
e 126 inclusi; i caratteri al di fuori da questo range sono caratteri
di controllo e causeranno un messaggio di errore.
º
Come possiamo determinare se l’output della funzione
toLower coincide con con il risultato atteso?
26

Specifications – Specifica formale scritta in una forma matematica (pseudo)
risultano migliori al fine di selezionare e creare testing oracles piuttosto che
specifiche informali scritte in linguaggio naturale.

Solved examples – sono sviluppati a mano.

Parametric oracles – caratterizzano una vasta classe di soluzioni per
l’ingresso del test scegliendo parametri appropriati.

Built in tests and checks – sono asserzioni che vengono aggiunte al codice
per specificare quando un risultato è valido oppure invalido. Alternativamente
si possono sviluppare procedure di self test.

Data and Databases - Dati in forma di tabelle, documenti, grafi o altro
formato contenenti i risultati.

Golden program – Utilizza specifiche eseguibili, versioni precedenti del
programma, oppure eseguire un test in parallelo con un altro sistema che
fornisce le stesse funzionalità.
27
Equivalence Partitioning

Come si possono creare casi di test in modo tale da coprire i
guasti del programma. La risposta adottata il molti metodi di
partitioning consiste nel dividere il dominio di ingresso e di uscita
in modo tale che:
1.
Occorrono meno casi di test per coprire grandi domini di
ingresso;
2.
Si hanno maggiori chance di scoprire guasti del programma;
3.
Si ha una buona idea di quanto del dominio di ingresso si è
coperto con i casi di test.
28

Lo scopo consiste nel dividere il dominio di ingresso in classi
(insiemi!) di casi di test i quali abbiano un effetto simile sul
programma.

Tali classi sono denominate CLASSI DI EQUIVALENZA.

Definizione: Equivalence Class (EC)
º
È un insieme di inputs che il programma tratta in modo
identico quando il programma viene testato.
29

Ciascuna Classe di equivalenza viene utilizzata per rappresentare
certe condizioni (o predicati) sul dominio dei dati di ingresso.

Per il partitioning si è soliti considerare sia gli ingressi validi che
invalidi.

Definizione:
º
Una condizione sugli input (Input Condition) è un predicato sui
valori degli ingressi.
º
Un ingresso valido (Valid input) al programma o modulo è un
elemento del dominio che si attende sia correttamente gestito
dal programma restituendo un valore di non-errore (non errato).
º
Un ingresso invalido ci si aspetta restituisca un valore di errore
(valore errato).
30

Input Conditions
º
Sono usate tipicamente per partizionare il dominio di ingressi in
classi di equivalenza allo scopo di selezionare certi ingressi.

Consideriamo una versione modificata della specifica del quadrato
di un numero questo dovrà restituire un intero di 32 bit:

∀ x ∈ {0, ……. , 65535} • square(x) = x * x

Il dominio di ingresso dedotto dalla (scarna) specifica è l’insieme di
integer;

La condizione di input è: x ∈ {0, ……. , 65535}
31
1.
È un metodo sistematico per identificare gli insiemi di classi di
interesse di condizioni di ingresso da testare.
2.
Ciascuna classe è rappresentativa di (copre) un insieme di altri
possibili test.

Ci si aspetta che il programma si comporti nello stesso modo fer
tutti gli elementi della classe di equivalenza. Anziché scrivere test
per tutti gli elementi della classe, si prende un test case
rappresentativo e inferire le proprietà della classe da questo test
case.

Occorre fare attenzione assicurarsi che tutti i membri della classe
si comportino allo stesso modo.
32
Equivalence Partitioning: metodologia

Lo scopo è quello di minimizzare il numero di casi di test necessari
per coprire il dominio degli ingressi.
1.
Identificare le classi di equivalenza (ECs);
2.
Identificare i casi di test.
33
Identifying Equivalence Classes: Guidelines

1. Se una condizione di ingresso specifica un range di valori,
identificare una classe di equivalenza valida e due invalide.
º
Esempio: Se abbiamo l’insieme di valori {1, . . . . , 99} allora
occorreranno le seguenti classi:
• Classe di equivalenza valida {1, . . . , 99};
• Classi di equivalenza invalide {x | x < 1} and {x | x > 99}.
34
2. Se una condizione di ingresso specifica un insieme di valori di
ingresso e ciascuno è gestito in modo diverso, identificare una
classe di equivalenza per ciascun elemento dell’insieme e una
invalida EC.
ºEsempio: Se l’ingresso è selezionato da un insieme di N
“distinti” elementi allora occorreranno N + 1 ECs:
• Una valida EC per ciascun elemento dell’insieme {M1}, . .
. , {MN};
• Una invalida EC per gli elementi fuori dall’insieme {x | x ∉
{M1, . . . , MN}}.
3. Se si ritiene che il programma maneggia ciascun ingresso
valido in modo distinto, allora occorre definire una valida EC per
ciascun ingresso valido.
ºEsempio: Se l’ingresso viene da un menu allora si definisce
una valida EC per ciascun item del menu.
35

4. Se le specifiche indicano N ingressi validi, si devono definire una
valida EC e due invalide EC per ciascun valore N dell’ingresso –
Una per zero valori, e una per valori > N.

5. Se un condizione di ingresso specifica una situazione del tipo
“must be”, identificare una valida EC e una invalida EC.
º
Esempio: Il primo carattere di un input deve essere numerico
allora occorreranno due EC –
• una valida EC {s | il primo carattere di s è numerico}
• una invalida EC {s | il primo carattere non è numerico}

6. Se gli elementi in una EC sono trattati in modi diversi dal
programma, allora la EC deve essere splittata in EC più piccole.
36
Identifying Test Cases

1. Assegnare un unico numero a ciascuna EC.

2. while
º
Non tutte le valide ECs sono state coperte dai casi di test
do

3. scrivere un nuovo caso di test che copra il maggior numero di
ECs non coperte.

4. while
º
Tutte le invalide ECs non sono state coperte dai casi di test
do

5. Scrivere un caso di test che copra uno e solo uno delle non
coperte invalide ECs.
37
Equivalence Partitioning: Esempio 1

Consideriamo la seguente specifica informale per il problema
seguente: Classificazione di triangoli.
1.
Il programma legge i 3 valori positivi dallo standard input.
2.
I 3 valori sono interpretati come rappresentativi delle
lunghezze dei lati di un triangolo.
3.
Il programma stampa un messaggio sullo standard output che
indica se il triangolo, se può essere creato, è scaleno,
isoscele, equilatero o rettangolo.
38
Equivalence Partitioning: Esempio 1

Quale è il dominio di ingresso per il suddetto programma? Le
possibilità includono:
º
L’insieme di tutte le possibili stringhe in ingresso – siamo
testando la robustezza e vogliamo sapere se stringhe non
corrette vengono rigettare dal programma;
º
L’insieme di tutti i possibili interi, sia positivi che negativi;
º
L’insieme di tutti i possibili interi positivi. Quali sono le
condizioni degli ingressi?
Requirement Input Condition
º
3 interi in ingresso (x; y; z) int int int
º
Gli interi devono essere positivi: x>0, y>0, z>0.
Nota: si sta utilizzando la regola 6 per determinare le classi di
equivalenza.
39
Equivalence Partitioning: ECs

Le classi di equivalenza sono:
Equivalence class
Test Case
scalene triangle
{(3, 5, 7), . . . }
isosceles triangle
{(2, 3, 3), . . . }
right-angled triangle
{(3, 4, 5), . . . }
non-triangle
{(1, 1, 3), . . . }
non-positive input
{(-1, 0, 3), (-2,-3,-3),. . . }
equilateral triangle
{(7, 7, 7), . . . }
40
Boundary Value Analysis

Lo scopo è l’analisi delle frontiere delle ECs.

Intuitivamente si ha che i difetti (faults o failures) sono più probabili
al confine fra due ECs.

Sceglie i test cases sulla frontiera o intorno ad essa.

È un raffinamento e estensione del partizionamento in ECs.

Il partizionamento richiede la scelta di un solo caso di test mentre la
BVA ne richiede di più.
41
Boundary Conditions

Definizione: Boundary Conditions sono predicati applicati sui valori
di frontiera e su intorni delle ECs degli input e output.

Le due differenze introdotte dalla BVA sono:
1.
Sia le condizioni di ingresso che di uscita vengono usate per
selezionare i casi di test.
2.
Anziché un solo caso di test da una EC, BVA consiglia di
prendere più casi di test in un intorno della frontiera.
42
Boundary Conditions

Se una condizione sugli input specifica un range di valori, allora si
devono creare test case validi per gli estremi del range, e invalidi
per i punti oltre la frontiera.

Se una condizione sugli input specifica un numero di valori, si
devono creare test case per il valore minimo e massimo,minotre
uno all’interno dei valori e all’esterno di questi.

Analogamente deve essere fatto per le condizioni sugli output.

Le condizioni di frontiera possono essere difficili da identificare
soprattutto per quel che riguarda il dominio delle uscite.
43
The Triangle Program Revisited
Specifica del problema:
ºIl programma legge valori floating dal std input. I 3 valori sno i 3
lati del triangolo. Il programma stampa a video il risultato del tipo
di triangolo (se è un triangolo)
• Isoscele, scaleno, equilatero, rettangolo
44
The Triangle Program Revisted
1. dati i lati (A, B, C) per essere scaleno la somma dei qualsiasi coppia di
lati deve essere > del terzo lato
ºboundary conditions
•A+B>C
•B+C>A
•A+C>B
ºPer la condizione A + B > C possiamo esplorare la frontiera usando i
seguenti casi di test (1, 2, 3), (1, 2, 2.999), (1, 2, 3.001) ….
2. dati i lati (A, B, C) per essere isoscele due lati devono essere uguali
ºboundary conditions
•A=B
•B=C
•A=C
ºPer la condizione A = C possiamo esplorare la frontiera usando i
seguenti casi di test (2, 2, 3), (2, 1.999, 3), (2, 2.001, 3), …..
45
The Triangle Program Revisted
3. dati i lati (A, B, C) per essere equilatero tutti i lati dovranno essere uguali
ºboundary
•A=B=C
ºpossiamo esplorare la frontiera usando i seguenti casi di test (3, 3, 3),
(3, 2.999, 3), (3, 3.001, 3), …..
4. dati i lati (A, B, C) per essere rettangolo si deve avere
• A2 + B2 = C2
• possiamo esplorare la frontiera usando i seguenti casi di test (3, 4,
5), (3, 4, 4.999), (3, 4, 5.001), …..
5. dati i lati (A, B, C) per non essere un triangolo si deve avere
• Frontiere simili alle precedenti
º(1, 2, 3), (1, 2, 2.999), (1, 2, 3.001), …..
6. per dati di ingresso non positivi si avrà
º (0, 1, 2), (-0.001, 1, 2), (0.001, 1, 2), …..
46
White-box testing

Il software viene considerato come una white-box, le strutture e il flusso del
sw sono visibili al tester.

I piani di test sono creati in base ai dettagli implementativi del software: il tipo
di linguaggio usato, la logica , lo stile, …...

I casi di test si deriveranno dalla struttura del programma.

White-box testing = glass-box testing = logic-driven testing = design-based
testing.

Esistono molte tecniche disponibili per il white-box testing,

L’intrattabilità del problema viene facilitata dalla conoscenza specifica della
struttura del programma da testare.

Si possono ottenere gradi di “esaustività”:
º
Si esegue ciascuna riga di codice almeno una volta (statement
coverage),
º
Ogni branch statements viene attraversato (branch coverage),
º
Copre tutte le possibili combinazioni di condizioni booleane (Multiple
condition coverage).
47
When to stop testing?

Il testing è potenzialmente senza fine. Quando fermiamo l’attività di
testing?

È un compromesso fra budget, tempo e qualità. Sarà guidato da
modelli di profitto.

Uno dei più usati metodi (non corretto) consiste nel terminare
l’attività quando il budget o il tempo o i casi di test sono finiti.

Un metodo sicuramente migliore consiste nel terminare l’attività
quando l’affidabilità ha raggiunto il livello richiesto o quando i
benefici nel continuare il testing sarebbero minimi. Questo richiede
l’uso di modelli di affidabilità per stimare l’affidabilità del software
sotto test.
48
Alternatives to testing (1)

Software testing è considerato un metodo problematico per migliorare la
qualità. Usare il testing per individuare e correggere i difetti può essere un
processo senza fine. I bugs non possono essere completamente eliminati.
Testare e fissare i problemi può non necessariamente migliorare la qualità e
l’affidabilità. Talvolta risolvere un problema può introdurne altri più severi.
º
Item: In the summer of 1991, telephone outages occurred in local
telephone systems in California and along the Eastern seaboard. These
breakdowns were all the fault of an error in signaling software. Right
before the outages, DSC Communications (Plano, TX) introduced a bug
when it changed three lines of code in the several-million-line signaling
program. After this tiny change, nobody thought it necessary to retest
the program.

Coverage testing: si può considerare che code coverage e branch coverage
siano collegati alla qualità del software? Non ne esiste la prova. Il così detto
"human testing" -- ispezione del codice, walkthroughs, reviews – sono
suggerite come una possibile alternativa. Alcuni risultati sperimentali
indicano che la rilettura del codice tramite astrazione è efficienteb tanto
quanto functional and structural testing in termini di numero di guasti
osservati.

I formal methods per “provare” la correttezza sono un’altra strada possibile.
Cmq non sono in grado di superare la barriera della complessità.
49
Conclusioni

Software testing è un’arte. Molti metodi di test non sono molto diversi da
quelli utilizzati 20 anni fa.

Una buona attività di test richiede la creatività del tester, esperienza e
intuito, insieme a tecniche e tool appropriati.

Testing non è soltanto debugging. Testing non viene usato solo per
individuare i difetti e correggerli. Viene inoltre utilizzato per validazione e
verifica, e anche per misure di affidabilità.

Il testing è molto costoso. La sua automatizzazione è un modo per ridurre
costi e tempi. La sua efficienza ed efficacia è il criterio alla base delle
tecniche coverage-based.

Un testing completo è irrealizzabile. Il problema principale è la complessità.
Ad un certo punto il testing del software deve essere interrotto e il prodotto
deve essere venduto. L’istante in cui arrestare l’attività di testing deve
essere deciso sulla base del tempo e del budget. Oppure se la stima
dell’affidabilità del sw incontra i requisiti.

Il Testing può anche non essere il modo migliore per migliorare la qualità del
sw. Ci sono metodi alternativi, quali inspection, e clean-room
engineering, che possono anche risultare migliori.
50
References

E. Spinicci, Il Testing. 24 marzo 2002
http://www.dsi.unifi.it/users/spinicci/teaching/InfInd/Testing.pdf

Jiantao Pan, Software Testing, 1999
http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/

Software Engineering Methods, Course Notes for 433-342 Engineering Methods,
Ed. Kazmierczak; The Department of Computer Science and Software Engineering,
The University of Melbourne, Second Semester, 2005.

R. Hamlet, “Random Testing”, In Enciclopedia of Software Engineering, J.
Marciniak ed., pp. 970–978, Wiley, 1994.
51