1

Lezione 14. Testing

• [S95, Cap. 22-23]

• [GMJ91, Sez. 6.3]

Generalità Testing statistico, Defect testing, Regression testing Top down-, bottom up-, thread-, back to back-, stress-testing. Black box (functional) testing White box (structural) testing

• Path testing e metrica ‘cyclomatic complexity’

2

Generalità

Testing è, principalmente, una forma di analisi dinamica della implementazione del sistema

Rivela la presenza di errori, NON la loro assenza

Consiste nel far funzionare il sistema in situazioni e con dati in input realistici, e nell’osservare output inattesi

• se l’output corretto è definito formalmente, la verifica è automatizzabile

Sebbene tecniche formali di analisi statica si stiano diffondendo, il testing rimane la tecnica predominante di V&V (ma vale un principio di complementarietà)

3

Unit testing• testing of individual components

Module testing• testing of collections of dependent components

Sub-system testing• testing collections of modules integrated into sub-systems. Verify subsystem

interfaces.

System testing• testing the complete system prior to delivery. Functional + nonfunctional

requirements: correttezza, performance, robustezza, interoperabilità, ...

Acceptance testing• testing by users (client), with real user data. Sometimes called alpha testing

• beta testing for systems to be marketed as products: limited distribution to potential customers (final users)

Testing stages

4

The V-model of development

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

Puo far parte del Contratto

Unit (procedure, class…) testinga volte è fatto direttamente dal programmatore, con il rischiodi dati ‘addomesticati’...

5

Component testing / integration testing

Componenttesting

Integrationtesting

Software developer Independent testing team

Component testing • Testing of individual program components

• Usually the responsibility of the component developer (except for critical systems)

• Tests are derived from the developer’s experience

Integration testing• Testing of groups of components integrated to create a system or sub-

system

• The responsibility of an independent testing team

• Tests are based on a system specification

6

Il documento ‘Piano di Test’

Il documento serve a manager e ingegneri per pianificare le attività, allocare risorse, controllare progresso…

Deve contenere questi elementi:• Descrizione delle fasi del processo di testing da seguire

• Relazioni di copertura fra test e requirements (use-case driven…)

• Elenco degli artefatti da testare

• Definizione dei formati di registrazione dei risultati del testing, per eventuali ispezioni successive

• Testing schedule e allocazione di risorse; requisiti hardware e software

• Valutazione dei possibili problemi di staff, o di budget, per anticipare rischi

Lo sviluppo del Piano di Test inizia assieme alla fase dei Requirements, e procede in parallelo con le altre attività del processo.

7

Test data - test cases

Test data • Inputs which have been devised to

test the system

Test cases • Inputs to test the system and the predicted outputs if the

system operates according to its specification

8

Defect testing process

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports

9

Defect testing e debugging

Defect testing• I test sono concepiti in modo da rivelare l’esistenza di errori (software

faults) in unit, module, subsystem, system

• Per contrasto, acceptance (validation) testing mira a esibire il l’assenza di errori a fronte dei soli acceptance test cases concordati con il Cliente...

Debugging• Formulare ipotesi sul comportamento erroneo del programma

• Verificare le ipotesi attraverso nuovi test specifici

• Localizzare precisamente l’errore

• Correggerlo

Debuggers• strumenti interattivi che visualizzano valori intermedi di variabili di

programma, e tracce del flusso di controllo (statement eseguiti)

10

Debugging and regression testing

Locateerror

Designerror repair

Repairerror

Re-testprogram

Regression testing:test del sistema dopo la correzione di uno o piu’ errori,per escludere errori indotti.

Nella fase di test planning,la identificazione di dipendenze fra sotto-sistemi e fra moduliconsente di ottimizzare regression testing, limitandoloall’elemento incriminato e quelli da lui dipendenti.

11

I test sono concepiti in modo da riflettere le caratteristiche statistiche degli user input per i diversi profili di utente (viewpoints). • Non si preoccupa di scoprire e correggere software faults, ma di...

• ... ottenere stime di affidabilità (reliability): probabilità di comportamento error-free, cioè senza software failures, rispetto a

» un dato intervallo temporale, » uno specifico obiettivo (servizio), in un particolare contesto d’uso (viewpoint).

Testing statistico

Input possibili

Input erronei

Producono outputerronei, esponendosoftware faults (da localizzare con defect testing)

user1 user2user3

12

Software faults / software failures

Mills et al. (1987): non tutti i software faults producono la stessa frequenza di software failures. In un caso, la rimozione del 60% dei faults ha ridotto solo del 3% le failures.

• Risultati analoghi confermati da studi in IBM.

• In altri termini, un fault puo’ causare failure dopo anni di uso del software.

• A volte, fault noti (in funzionalità non essenziali) possono essere evitati dagli utenti, senza impatto negativo sulla reliability

V&V costs

Reliability

Fino a metà del budgetper lo sviluppo può esserespeso per il TESTING

13

Testing strategies

Top-down testing Bottom-up testing Thread testing Stress testing Back-to-back testing

La tecnica usata puo’ dipendere dalla fase (module-, subsystem-, system-testing)

In ogni caso, conviene usare un approccio incrementale, che facilita la localizzazione dei difetti (--->)

14

Incremental (integration) testing

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

Moduli o subsystems Tests

15

Top-down integration testing

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

Il sistema è rappresentato da una singola componente astratta, mentre le sotto-comp. son rappresentate da ‘stubs’ (mozzicone, moncherino): versioni a funzionalità limitata, ma interfaccia completa.+ E’ conveniente quando anche il sistema e’ strutturato ad albero (e implementato in modo top-down).- Non sempre è possibile realizzare economicamente ‘stubs’ realistici- Non sempre la componente top produce output da osservare: vanno allora creati output artificiali- Non adatto a sistemi O-O, nei quali spesso non esiste una (unica) componente top

16

Bottom-up integration testing

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

17

Testa a partire dalle componenti di basso livello, e procede verso l’alto usando test drivers (l’opposto degli stubs), che simulano l’ambiente di componenti soprastanti ancora da implementare

• E’ conveniente quando anche il sistema è organizzato a strati (e implementato in modo bottom-up)

Test drivers e relative sequenze e dati di test possono essere distribuiti assieme alle componenti riutilizzabili

- Trova errori nel design tardivamente + Adatto a sistemi O-O

Tempi di sviluppo variabili per system components => necessità di usare simultaneamente test drivers e stubs

18

Thread testing (o ‘transaction-flow’ testing)

Adatto a sistemi real-time e object-oriented Applicabile dopo che processi o oggetti sono stati testati

individualmente Testa la sequenza di passi di calcolo (attraverso processi o

oggetti) che scaturisce da un dato evento esterno.

19

Exercises the system progressively beyond its maximum design load.

• Transactions per second in a DB system

• Number of terminals supported by an operating system

Investigating failure behaviour: systems should not fail catastrophically, with unacceptable loss of service or data

Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded

Stress testing (for robustness)

20

Back-to-back testing

Present the same tests to different versions of the system and compare outputs. Differing outputs imply potential problems

Possible when • a prototype is available or

• with regression testing of a new system version

Reduces the costs of examining test results: automatic comparison of outputs

21

Back-to-back testing

Test data

Programversion A

Programversion B

Resultscomparator

Difference report

22

Black-box (or functional) testing

The program is considered as a ‘black-box’ ‘Functional’: observing the pure input-output relation The program test cases are based on the system specification ...thus test planning can begin early in the software process, as

soon as the specification is available

23

A system from the viewpoint of Black-box testing

Ie

Input test data

OeOutput test results

System

Inputs causinganomalousbehaviour

Outputs which revealthe presence ofdefects

24

Equivalence classes of inputs

System

Outputs

Invalid inputs Valid inputs

Partition system inputs (or outputs) into equivalence classes, based on system spec. and intuition

The program is expected to behave similarly(correctly or incorrectly) for all elements ofthe same class

For each class:- in principle choose one test case- in practice choose average and boundary test cases (the latter are often overlooked by programmers)

Inputs should be tuned to hit the desired elements of the output partitions

25

Equivalence partitions...

Between 10000 and 99999Less than 10000 More than 99999

999910000 50000

10000099999

Input values

Between 4 and 10Less than 4 More than 10

34 7

1110

Number of input values

…for a program accepting 4-10 input values greater than 10.000

26

Search routine specification

procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition-- the array has at least one elementT’FIRST <= T’LAST

Post-condition-- the element is found and is referenced by L( Found and T (L) = Key)

or -- the element is not in the array( not Found and

not (exists i, T’FIRST <= i <= T’LAST, T (i) = Key ))

27

Search routine - testing guidelines (for arrays in general)

Test software with arrays of size 1 Use arrays of different sizes in different tests Derive tests so that the first, middle and last elements of the

array are accessed Test with arrays of zero length (if allowed by programming

language)

28

Search routine - input partitions and test cases

Array ElementSingle value In sequenceSingle value Not in sequenceMore than 1 value First element in sequenceMore than 1 value Last element in sequenceMore than 1 value Middle element in sequenceMore than 1 value Not in sequence

Input sequence (T) Key (Key) Output (Found, L)17 17 true, 117 0 false, ??17, 29, 21, 23 17 true, 141, 18, 9, 31, 30, 16, 45 45 true, 717, 18, 21, 23, 29, 41, 38 23 true, 421, 23, 29, 33, 38 25 false, ??

29

The program is visible: derive of test cases and input partitions from program structure.

Usually applied to small program units (subroutines, object methods)

Objective is to exercise all program statements (not all arcs or all paths of the flow graph)

White-box (or structural) testing

Componentcode

Testoutputs

Test data

DerivesTests

(In Black-box testing, test cases were derived from the specification)

30

class BinSearch {

// This is an encapsulation of a binary search function that takes an array of// ordered objects and a key and returns an object with 2 attributes namely// index - the value of the array index// found - a boolean indicating whether or not the key is in the array// An object is returned because it is not possible in Java to pass basic types by// reference to a function and so return two values// the key is -1 if the element is not found

public static void search ( int key, int [] elemArray, Result r ){

int bottom = 0 ;int top = elemArray.length - 1 ;int mid ;r.found = false ; r.index = -1 ;while ( bottom <= top ){

mid = (top + bottom) / 2 ;if (elemArray [mid] == key){

r.index = mid ;r.found = true ;return ;

} // if partelse{

if (elemArray [mid] < key)bottom = mid + 1 ;

elsetop = mid - 1 ;

}} //while loop

} // search} //BinSearch

Binary search (Java)

program structuresuggests to considerthree input partitions, basedon element mid...

31

Binary search equiv. partitions

Mid-point

Elements < Mid Elements > Mid

Equivalence class boundaries

32

Binary search - test cases (cfr. pag. 28)

Input array (T) Key (Key) Output (Found, L)17 17 true, 117 0 false, ??17, 21, 23, 29 17 true, 19, 16, 18, 30, 31, 41, 45 45 true, 717, 18, 21, 23, 29, 38, 41 23 true, 417, 18, 21, 23, 29, 33, 38 21 true, 312, 18, 21, 23, 32 23 true, 421, 23, 29, 33, 38 25 false, ??

33

Objective is to exercise all program paths (implies exercising all arcs of the flow graph and all program statements)

Based on Program flow graph • which describes the program control flow, focusing on branches and

abstracting from assignements, I/O, procedure calls.

and based on Cyclomatic complexity of flow graph --->

Path testing (un caso di white box testing)

if-then-else loop-while case-of

34

Cyclomatic complexity - una metrica di qualità del software

Cyclomatic complexity • introdotta da Thomas McCabe nel 1976, è forse la più usata metrica statica di programmi

software

• misura il numero di cammini linearmente indipendenti attraverso un programma

• ignora l’effetto dei dati e l’annidamento di strutture di controllo

Cyclomatic Complexity Risk Evaluation 1-10 a simple program, without much risk 11-20 more complex, moderate risk 21-50 complex, high risk program greater than 50 untestable program (very high risk)

Cyclomatic number di un grafo G con n nodi, e archi e una componente connessa:

C(G) = e - n + 1

35

Teorema - In un grafo G fortemente connesso, C(G) è uguale al numero massimo di cammini linearmente indipendenti

Applicazione al testing• associare a un programma strutturato a blocchi il grafo del flusso di controllo

G, che avrà un solo entry point e un solo exit point

• ogni nodo corrisponda a un blocco di statements in cui il flusso di controllo è sequenziale

• gli archi rappresentino scelte del flusso di controllo

• aggiungere un arco da exit point a entry point per ottenere un grafo fortemente connesso

• Calcolare il cyclomatic number per trovare la dimensione della base di cammini linearmente indipendenti da testare, dato che…

• la base garantisce che tutti gli statements vengano eseguiti, e tutte le scelte esplorate.

36

Esempio astratto

a

fc

e

db

g

Grafo fortemente connesso (una componente)Archi = 11, Nodi = 7Cyclomatic number = 11-7+1 = 5

Numero max di cammini linearm. indipendenti = 5

b1: abcgb2: a(bc)*2gb3: abefgb4: adefgb5: adfg

Qualunque cammino è una combinazione lineare di b1-b5:abcbefg = b2 + b3 - b1a(bc)*3g = 2*b2 - b1

1 2

3 45 6

78

9 10

archi

37

Esempio Binary search - flow graph and cyclomatic complexity

1

2

3

54

76

98

10

1112

13

(if not Found then...)

(while Bott <= Top loop)

(If T (mid) = Key then.. .)

(if T (mid) < Key then...)

CC(G) = 17 edges - 13 nodes + 1 = 5

Cinque cammini linear. indip.:

1, 2, 12, 131, 2, 3, 4, 12, 131, 2, 3, 5, 6, 11, 2, 12, 131, 2, 3, 5, 7, 8, 10, 11, 2, 12, 131, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13

In programmi strutturati, senza GOTO’s, CC(G) = numero di predicati elementari (2, 3, 5, 7) + 1

= 5

(baco in Sommerville, che ne conta solo 4…)