1 Lezione 14. Testing [S95, Cap ] [GMJ91, Sez. 6.3] u Generalità u Testing statistico, Defect testing, Regression testing u Top down-, bottom up-, thread-, back to back-, stress-testing. u Black box (functional) testing u White box (structural) testing Path testing e metrica cyclomatic complexity

2 Generalità u Testing è, principalmente, una forma di analisi dinamica della implementazione del sistema u Rivela la presenza di errori, NON la loro assenza u 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 u 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 u Unit testing testing of individual components u Module testing testing of collections of dependent components u Sub-system testing testing collections of modules integrated into sub-systems. Verify subsystem interfaces. u System testing testing the complete system prior to delivery. Functional + nonfunctional requirements: correttezza, performance, robustezza, interoperabilità,... u 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 Puo far parte del Contratto Unit (procedure, class…) testing a volte è fatto direttamente dal programmatore, con il rischio di dati addomesticati...

5 Component testing / integration testing u 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 u 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 u Il documento serve a manager e ingegneri per pianificare le attività, allocare risorse, controllare progresso… u 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 u 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 u Test data Inputs which have been devised to test the system u 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 u 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... u Debugging Formulare ipotesi sul comportamento erroneo del programma Verificare le ipotesi attraverso nuovi test specifici Localizzare precisamente lerrore Correggerlo u 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 u 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). Testing statistico Input possibili Input erronei Producono output erronei, esponendo software faults (da localizzare con defect testing) user1 user2 user3

12 Software faults / software failures u 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 budget per lo sviluppo può essere speso per il TESTING

13 Testing strategies u Top-down testing u Bottom-up testing u Thread testing u Stress testing u Back-to-back testing u La tecnica usata puo dipendere dalla fase (module-, subsystem-, system-testing) u 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 u 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) u Test drivers e relative sequenze e dati di test possono essere distribuiti assieme alle componenti riutilizzabili u - Trova errori nel design tardivamente u + Adatto a sistemi O-O u Tempi di sviluppo variabili per system components => necessità di usare simultaneamente test drivers e stubs

18 Thread testing (o transaction-flow testing) u Adatto a sistemi real-time e object-oriented u Applicabile dopo che processi o oggetti sono stati testati individualmente u Testa la sequenza di passi di calcolo (attraverso processi o oggetti) che scaturisce da un dato evento esterno.

19 u Exercises the system progressively beyond its maximum design load. Transactions per second in a DB system Number of terminals supported by an operating system u Investigating failure behaviour: systems should not fail catastrophically, with unacceptable loss of service or data u Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded Stress testing (for robustness)

20 Back-to-back testing u Present the same tests to different versions of the system and compare outputs. Differing outputs imply potential problems u Possible when a prototype is available or with regression testing of a new system version u Reduces the costs of examining test results: automatic comparison of outputs

21 Back-to-back testing

22 Black-box (or functional) testing u The program is considered as a black-box u Functional: observing the pure input-output relation u The program test cases are based on the system specification u...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

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 <= 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 <= i <= TLAST, T (i) = Key ))

27 Search routine - testing guidelines (for arrays in general) u Test software with arrays of size 1 u Use arrays of different sizes in different tests u Derive tests so that the first, middle and last elements of the array are accessed u Test with arrays of zero length (if allowed by programming language)

28 Search routine - input partitions and test cases

29 u The program is visible: derive of test cases and input partitions from program structure. u Usually applied to small program units (subroutines, object methods) u Objective is to exercise all program statements (not all arcs or all paths of the flow graph) White-box (or structural) testing (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 u Objective is to exercise all program paths (implies exercising all arcs of the flow graph and all program statements) u Based on Program flow graph which describes the program control flow, focusing on branches and abstracting from assignements, I/O, procedure calls. u and based on Cyclomatic complexity of flow graph ---> Path testing (un caso di white box testing)

34 Cyclomatic complexity - una metrica di qualità del software u 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 u Cyclomatic ComplexityRisk Evaluation u 1-10a simple program, without much risk u 11-20more complex, moderate risk u 21-50complex, high risk program u greater than 50untestable program (very high risk) u Cyclomatic number di un grafo G con n nodi, e archi e una componente connessa: u C(G) = e - n + 1

35 u Teorema - In un grafo G fortemente connesso, C(G) è uguale al numero massimo di cammini linearmente indipendenti u 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 = 7 Cyclomatic number = = 5 Numero max di cammini linearm. indipendenti = 5 b1: abcg b2: a(bc)*2g b3: abefg b4: adefg b5: adfg Qualunque cammino è una combinazione lineare di b1-b5: abcbefg = b2 + b3 - b1 a(bc)*3g = 2*b2 - b archi

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