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 inputrealistici, 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. 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 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

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 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 all’elemento 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 d’uso (viewpoint). Input possibili Producono output erronei, esponendo software faults (da localizzare con defect testing) user1 user2 Input erronei 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 V&V 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 (--->)

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 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 simultaneamentetest 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) Inputs 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 T’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

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

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 numberdi un grafo G connnodi,earchi eunacomponente 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 controlloG, 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-7+1 = 5 Numero max di cammini linearm. indipendenti = 5 b1: abcg b2: a(bc)*2g b3: abefg b4: adefg b5: adfg a 1 2 b d 6 5 4 archi 3 7 e 8 c f 9 10 g Qualunque cammino è una combinazione lineare di b1-b5: abcbefg = b2 + b3 - b1 a(bc)*3g = 2*b2 - 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 GOTO’s, CC(G) = numero di predicati elementari(2, 3, 5, 7) + 1 = 5 (baco in Sommerville, che ne conta solo 4…)