Lezione 14. Testing

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
  nellosservare output inattesi
• se loutput corretto è definito formalmente, la
  verifica è automatizzabile
• Sebbene tecniche formali di analisi statica si
  stiano diffondendo, il testing rimane la tecnica
  predominante di VV (ma vale un principio di
  complementarietà)

3
Testing stages

• 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)

4
The V-model of development
Unit (procedure, class) testing a volte è fatto
direttamente dal programmatore, con il
rischio di dati addomesticati...
Puo far parte del Contratto
5
Component testing / integration testing

• Component testing
• Testing of individual program components
• Usually the responsibility of the component
  developer (except for critical systems)
• Tests are derived from the developers 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
9
Defect testing e debugging

• Defect testing
• I test sono concepiti in modo da rivelare
  lesistenza di errori (software faults) in unit,
  module, subsystem, system
• Per contrasto, acceptance (validation) testing
  mira a esibire il lassenza 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 lerrore
• 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
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
moduli consente di ottimizzare regression
testing, limitandolo allelemento incriminato e
quelli da lui dipendenti.
11
Testing statistico

• 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 duso (viewpoint).

Input possibili
Producono output erronei, esponendo software
faults (da localizzare con defect testing)
user1
Input erronei
user2
user3
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

Fino a metà del budget per lo sviluppo può
essere speso per il TESTING
VV costs
Reliability
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 (---gt)

14
Incremental (integration) testing
Moduli o subsystems
Tests
15
Top-down integration testing
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
17

• Testa a partire dalle componenti di basso
  livello, e procede verso lalto usando test
  drivers (lopposto degli stubs), che simulano
  lambiente 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
  gt 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
Stress testing (for robustness)

• 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

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
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
24
Equivalence classes of 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 of the 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) Inpu
ts should be tuned to hit the desired elements of
the output partitions
25
Equivalence partitions...
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
element TFIRST lt TLAST 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, TFIRST lt i lt TLAST, 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
29
White-box (or structural) testing

• 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)

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

Binary search (Java) program structure suggests
to consider three input partitions, based on
element mid...
31
Binary search equiv. partitions
32
Binary search - test cases (cfr. pag. 28)
33
Path testing (un caso di white box testing)

• 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
  ---gt

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 leffetto dei dati e lannidamento 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
Grafo fortemente connesso (una componente) Archi
11, Nodi 7 Cyclomatic number 11-71
5 Numero max di cammini linearm. indipendenti
5 b1 abcg b2 a(bc)2g b3 abefg b4
adefg b5 adfg
a
1
2
d
b
6
5
4
archi
3
7
e
8
f
c
9
10
g
Qualunque cammino è una combinazione lineare di
b1-b5 abcbefg b2 b3 - b1 a(bc)3g 2b2 -
b1
37
Esempio Binary search - flow graph and cyclomatic
complexity
CC(G) 17 edges - 13 nodes 1 5 Cinque
cammini linear. indip. 1, 2, 12, 13 1, 2, 3, 4,
12, 13 1, 2, 3, 5, 6, 11, 2, 12, 13 1, 2, 3, 5,
7, 8, 10, 11, 2, 12, 13 1, 2, 3, 5, 7, 9, 10, 11,
2, 12, 13 In programmi strutturati, senza
GOTOs, CC(G) numero di predicati elementari
(2, 3, 5, 7) 1 5 (baco in Sommerville, che
ne conta solo 4)