Software Testing (2 Parte)

Transcript

1 Software Testing (2 Parte) Software Testing (2 parte) 1 Outline 1. Testing Automation 2. Analisi Mutazionale 3. Tecniche di Testing Statico Software Testing (2 parte) 2 1

2 L automazione nel Processo di Testing Software Testing (2 parte) 3 Processo di Testing Test cases Test data Test results Test repor ts Design test cases Prepare test data Run pr ogram with test da ta Compare results to test cases Software Testing (2 parte) 4 2

3 Testing Automation È l insieme delle tecniche e delle tecnologie che consentono di automatizzare (anche parzialmente) alcune attività del Processo di Testing. Alcune aree di intervento: A) Generazione dei Casi di Test B) Preparazione ed Esecuzione del Test C) Valutazione dell efficacia di Test Suite Software Testing (2 parte) 5 A) Tecniche di Generazione dei casi di test Negli approcci al testing presentati finora, si è sempre considerato il task di Test Case Design come un task svolto manualmente dal tester A causa del numero di casi di test necessari per un testing efficace, l operazione di progettazione manuale dei casi di test può essere molto onerosa Tecniche per la generazione automatica dei casi di test possono ridurre drasticamente i costi e I tempi legati alla fase di test design Può però essere necessaria una fase di valutazione dell efficacia dei casi di test e una fase di riduzione dei casi di test ridondanti Software Testing (2 parte) 6 3

4 Un esempio: Il Testing basato su Sessioni Utente Tecnica per la generazione automatica di casi di test per il testing black box partendo dall analisidelle sessioni utente (User Session), ovvero delle sequenze dei valori di input immessi e di output ottenuti in utilizzireali del software. In pratica, vengono installati strumenti che siano in grado di mantenere un log di tutte le interazioni che avvengono tra gli utenti dell applicazione da testare e l applicazione stessa (fase di Capture) A partire da tali dati vengono formalizzati casi di test che replichino le interazioni catturate (fase di Replay) In questo modo è possibile ottenere casi di test che siano rappresentativi dei reali utilizzidell applicazione da parte dei suoi utenti Software Testing (2 parte) 7 Problemi legati allo User Session Testing Il numero di sessioni da prendere in considerazione al fine di poter avere un insieme significativodi casi di test può essere molto elevato Si possono applicare tecniche di minimizzazione per la riduzione del numero di casi di test Il sistema di logging deve essere in grado di monitorare il piùpossibile anche gli elementi legati all ambiente di esecuzione Per poter ottenere esecuzioni significative può essere necessario raccogliere sessioni per molto tempo Per ridurre tale tempo, si possono utilizzare tecniche di Testing Mutazionale allo scopo di ottenere nuovi test case da una combinazione di quelli esistenti Difficoltà nel riprodurre le reali condizioni di utilizzo dell applicazione prima del suo rilascioreale Software Testing (2 parte) 8 4

5 Un ulteriore Approccio: il Testing Mutazionale Il Testing Mutazionale è una tecnica per la generazione di casi di test. A partire da un sottoinsieme di casi di test, si applicano alcuni operatori di mutazione che vadano a modificare/incrociare I dati deitest case esistenti, in modo da ottenere nuovi test case. Es. Si cambia il segno degli input, si raddoppiano I valori di input, si combinano sequenze di input in nuove sequenze, etc Due concetti distinti: Analisi Mutazionale e Testing Mutazionale L Analisimutazionale non è una tecnica di testing a tutti gli effetti ma un processo a supporto della valutazione dell efficacia di test suite esistenti. Software Testing (2 parte) 9 Testing Mutazionale Con tale tecnica si possono ottenere Test Suites più piccole (meno test cases) con maggiore copertura con uno sforzo minore rispetto a quelle ottenute semplicemente collezionando sessioni utente Bisogna però eliminare tutti i test cases che risultano inapplicabili. Questa tecnica è spesso utilizzata per il testing di interfacce o di protocolli. Software Testing (2 parte) 10 5

6 Ulteriori tecniche Ulteriori tecniche per la proposizione di casi di test si basano sulla valutazione analitica dei vincoli e dei valori critici dei dati in input Domain Analysis Analisideivalori limite (boundaries) Ad esempio, nel caso dell input mese, noto che il suo insieme di validità è [1..12] (valori interi), valori limite saranno 0, 1, 12, 13 La possibilità di automatizzare tali tecniche dipende dalla disponibilità di strumenti per l analisiautomatica di specifiche, codice, o altro Software Testing (2 parte) 11 B) Preparazione ed Esecuzione del Test Una soluzione per l automazione del testing Black Box consiste nell utilizzare appositi framework di supporto all esecuzione dei casi di test. Tra questi framework, molto noti sono quelli della famiglia XUnit, come ad esempio: JUnit (Java) CppUnit (C++) csunit (C#) NUnit (.NET framework) HttpUnit e HtmlUnit (Web Application) Tali framework sono nati nell ambito della extreme Programming per automatizzare il testing di unità, ma possono essere generalizzati anche alle problematiche di testing black box. Software Testing (2 parte) 12 6

7 Unit Testing Basics Il testing a livello di unità dei comportamenti di una classe dovrebbe essere progettato ed eseguito dallo sviluppatore della classe, contemporaneamente allo sviluppo stesso della classe Di questa opinione sono in particolare Erich Gamma e Kent Beck, meglio conosciuti come gli autori dei Design Pattern e dell extreme Programming Vantaggi: Lo sviluppatore conosce esattamente le responsabilità della classe che ha sviluppato e I risultati che da essa si attende Lo sviluppatore conosce esattamente come si accede alla classe, ad esempio: Quali precondizione devono essere poste prima di poter eseguire un caso di test; Quali postcondizioni sui valori dello stato degli oggetti devono verificarsi Svantaggi: Lo sviluppatore tende a difendere il suo lavoro troverà meno errori di quanto possa fare un tester! Software Testing (2 parte) 13 Vantaggi dell esecuzione automatica del Test Se la progettazione dei casi di test é un lavoro duro e difficile, l esecuzione dei casi di test é un lavoro noioso e gramo! L automatizzazione dell esecuzione dei casi di test porta innumerevoli vantaggi: Tempo risparmiato (nell esecuzione dei test) Affidabilità dei test (non c é rischio di errore umano nell esecuzione dei test) Riuso (parziale) dei test a seguito di modifiche nella classe Software Testing (2 parte) 14 7

8 a) Unit Testing ed esecuzione automatica dei test Nel caso di Unit Testing di una classe, una tecnica per l esecuzione automatica del test richiede di scrivere in ogni classe un metodo main capace di testare i comportamenti della classe. Problemi Tale codice verrà distribuito anche nel prodotto finale, appesantendolo La classe potrebbe già avere un main Come strutturare i test case? Come eseguirli separatamente? Per ovviare a questi problemi, cerchiamo un approccio sistematico: Che separi il codice di test da quello della classe Che supporti la strutturazione dei casi di test in test suite Che fornisca un output separato dall output dovuto all esecuzione della classe. Software Testing (2 parte) 15 b) Black Box testing e Testing Automation Nel caso testing black box, inevitabilmente il codice di test sarà separato dal codice del programma da testare (cui non si ha accesso) Le classi di test si occuperanno di eseguire le operazioni rese accessibili dal sistema da testare Nel caso di sistemi a componenti, si eseguiranno le operazioni nell interfaccia dei componenti Nel caso di sistemi a oggetti, I metodi pubblici Nel caso di sistemi a linea di comando, i comandi accessibili variando I parametri passati Nel caso di sistemi interattivi, I metodi messi a disposizione da un emulatore che emuli il comportamento dell utente nell accesso al sistema Software Testing (2 parte) 16 8

9 L approccio di JUnit JUnit é un framework (in pratica consiste di un archivio.jar contenente una collezione di classi) che permette la scrittura di test in maniera ripetibile. Fu sviluppato originariamente da Erich Gamma and Kent Beck, nell ambito degli strumenti a supporto dell extreme Programming. Plug-ins che supportano il processo di scrittura ed esecuzione dei test JUnit su classi Java sono previsti da alcuni ambienti di sviluppo in particolare mostreremo il funzionamento del plug-in JUnit di Eclipse. Software Testing (2 parte) 17 Risorse per JUnit Using JUnit in Eclipse, An Introduction to JUnit, JUnit Testing Utility Tutorial, als/junit/junit.html Tools for automated software testing, Introduzione a Test-First Design e JUnit, testing+introjunit.pdf JUnit Testing Utility Tutorial, als/junit/junit.html Sito ufficiale di JUnit, Progetto sourceforge di JUnit, Software Testing (2 parte) 18 9

10 Plug-in di Eclipse per JUnit Eclipse é dotato di un plug-in, di pubblico dominio, che supporta tutte le operazioni legate al testing di unità con JUnit. In particolare, esso fornisce dei wizard per: Creare classi contenenti test cases Automatizzare l esecuzione di tutti i test cases Mostrare i risultati dell esecuzione dei casi di test Organizzare i test cases in test suites Software Testing (2 parte) 19 Breve Tutorial Creiamo un nuovo progetto Eclipse, con un package (calcolatrice) All interno di questo package generiamo una classe calcolatrice: package calcolatrice; public class calcolatrice { public calcolatrice(){}; } public int somma (int a, int b) {return a+b;} Software Testing (2 parte) 20 10

11 Scrittura dei test Software Testing (2 parte) 21 Inserimento di JUnit nel progetto Nelle proprietà del progetto, aggiungiamo JUnit.jar tra le librerie previste nel Classpath del progetto Add External Jars Una copia di junit.jar dovrebbe trovarsi tra i plug-in di Eclipse; in alternativa la si può scaricare da Software Testing (2 parte) 22 11

12 Creazione di una classe test All interno dello STESSO package della classe da testare, creare una nuova classe, scegliendo la tipologia JUnit Test Case Software Testing (2 parte) 23 Generazione della classe dei test Il Wizard di Eclipse ci permette di indicare il nome della classe che si vuole testare (calcolatrice), il nome della classe da generare (abbiamo usato per convenzione il nome calcolatricetest), gli ulteriori metodi da aggiungere (abbiamo selezionato setup e teardown) Software Testing (2 parte) 24 12

13 Scrittura della classe test Il Wizard ha generato una classe che eredita dalla classe TestCase, cuore della libreria JUnit Il metodo setup()puòessere completato, accodando tutte quelle operazioni da effettuare preliminarmente a qualsiasi test che sarà descritto in questa classe; Il metodo teardown() conterrà il codice relativo a tutte le operazioni comuni da effettuare dopo l esecuzione di ogni test di questa classe (ad esempio per ripristinare lo stato della classe prima dell esecuzione del prossimo test package calcolatrice; import junit.framework.testcase; public class calcolatricetest extends TestCase { protected void setup() throws Exception { super.setup(); } protected void teardown() throws Exception { super.teardown(); } /* Test method for 'calcolatrice.calcolatrice.somma(int, int)'*/ public void testsomma() { } Software Testing } (2 parte) 25 Scrittura di un caso di test Scriviamo un metodo testsomma che rappresenti un caso di test per il metodo Somma; Siccome il metodo appartiene ad una classe calcolatricetestnello stesso package della classe da testare, il metodo test può istanziare oggetti della classe ed accedere ai suoi metodi public void testsomma() { } calcolatrice c=new calcolatrice(); int a=5,b=7; int s=c.somma(a,b); assertequals("somma non corretta!",12,s); Software Testing (2 parte) 26 13

14 Asserzioni Il metodo assertequals verifica se s (valore ottenuto dall esecuzione del metodo somma) é uguale a 12 (valore atteso); in caso contrario conta questo fatto come una failure e genera il messaggio di errore indicato assertequals("somma non corretta!",12,s); Software Testing (2 parte) 27 Principali asserzioni static void assertequals(boolean expected, boolean actual) Asserts that two booleans are equal. static void assertequals(int expected, int actual) Asserts that two ints are equal. static void assertequals(java.lang.string expected, java.lang.string actual) Asserts that two Strings are equal. static void assertfalse(boolean condition) Asserts that a condition is false. static void asserttrue(boolean condition) Asserts that a condition is true. static void assertnull(java.lang.object object) Asserts that an object is null. static void fail() Fails a test with no message. static void fail(java.lang.string message) Fails a test with the given message. Elenco completo disponibile presso: Software Testing (2 parte) 28 14

15 Esecuzione dei casi di test Per eseguire I test, basta seguire una procedura simile a quella usata per eseguire applicazioni Software Testing (2 parte) 29 Test che rilevano errori public double divisione (int a, int b) {return a/b;} public void testdivisione(){ } calcolatrice c=new calcolatrice(); int a=15,b=2; double s=c.divisione(a,b); asserttrue(s==7.5); In realtà il metodo divisione restituisce la divisione intera Grazie a JUnit possiamo prontamente trovare il rigo con l asserzione errata e avviare il debugging Quando pensiamo di aver correttol errore rieseguiamo il test Software Testing (2 parte) 30 15

16 Raggruppare test cases in test suite Ulteriori classi di test possono essere aggiunte in seguito modificando il codice generato package calcolatrice; import junit.framework.test; import junit.framework.testsuite; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("Test for calcolatrice"); //$JUnit-BEGIN$ suite.addtestsuite(calcolatricetest.class); //$JUnit-END$ return suite; } } Software Testing (2 parte) 31 Ricapitolando Precondizioni metodo setup (se comuni a più casi di test), altrimenti all inizio del metodo di test Input si inseriscono sotto forma di assegnazioni all inizio del codice del test case oppure si passano come parametri della chiamata della funzione da testare Output si valutano tramite asserzioni sui valori restituiti dalla funzione testata Postcondizioni si valutano tramite asserzioni su oggetti in qualche modo coinvolti nell esecuzione del caso di test Ripristino delle condizioni iniziali metodo teardown (se comuni a più casi di test) oppure al termine del metodo di test. Sono necessari per poter ripristinare lo stato del sistema al fine di automatizzare l esecuzione in sequenza dei test Software Testing (2 parte) 32 16

17 Limiti di JUnit Se una classe é in associazione/dependency con altre e JUnit rileva l errore, esso potrebbe dipendere dall altra classe (se non é stata testata adeguatamente) oppure dall integrazione JUnit é uno strumento che é in grado di risolvere SOLO le problematiche relative al testing di unità dà solo qualche utile indicazione rispetto al testing di integrazione! JUnit supporta unicamente il testing, non il debugging L utilizzo di molte asserzioni può, però, portare ad indicazioni dettagliate sulle ragioni del successo del test case Software Testing (2 parte) 33 Limiti di JUnit Si é data per scontata la correttezza del codice delle classi di test se avessimo voluto esserne sicuri al massimo avremmo potuto fare il test di unità delle classi di test stesse (paradossale!) Il codice delle classi di test é comunque estremamente lineare e ripetitivo: la possibilità di sbagliare é ridotta! La generazione del codice delle classi di test è automatizzabile Software Testing (2 parte) 34 17

18 Altre applicazioni di Testing Automation: La valutazione dell efficacia di Test Suite Generazione di moduli Driver e Stub Software Testing (2 parte) 35 La Valutazione dell Efficacia di una Test Suite Una misura di efficacia è data dal grado di Copertura raggiunto dalla test suite. In generale, dato un criterio di copertura, è abbastanza semplice valutare la sua effettiva copertura mentre non è per nulla semplice generare dei casi di test che siano in grado di garantire tale copertura. Una possibile sinergia fra White Box e Black Box Testing: La valutazione della copertura con criteri white box è un metodo per valutare, in sede sperimentale, in maniera indiretta, l efficacia delle tecniche di generazione di test black box. Software Testing (2 parte) 36 18

19 Sviluppo di Strumenti automatici a supporto É possibile sviluppare programmi che inseriscano automaticamente sonde all interno di un programma in un determinato linguaggio di programmazione, allo scopo di valutare l efficacia di una test suite rispetto a criteri di copertura strutturali Ad esempio, se venisse inserita una sonda in corrispondenza di ogni linea di codice eseguibile e che produca in output la linea di codice visitata, allora si potrebbe valutare, a seguito dell esecuzione di una certa test suite, l insieme delle linee di codice visitate Software Testing (2 parte) 37 Ausili per il Testing d integrazione il testing é applicato ad un aggregato di due o più unità di un sistema software; l'obiettivo é quello di rilevare errori nelle interazioni fra le unità e nelle funzioni che l'aggregato deve assolvere; non é compito dei programmatori che hanno prodotto le unità componenti le unità da integrare sono selezionabili in base a criteri funzionali ricavabili dal progetto (architettura del sistema); partendo da una architettura organizzata gerarchicamente, le integrazioni possono essere realizzate con approccio top-down o bottom-up o misto Software Testing (2 parte) 38 19

20 Strategie per il testing di integrazione Top-down testing Bottom-up testing Sandwich testing UI Layer stub stub stub driver driver driver Database Network layer layer UI Layer stub stub stub UI Layer Functional layer stub stub stub driver driver driver Functional layer Database Network layer layer driver driver driver Database Network layer layer UI Layer Fully integrated system Functional layer Database Network layer layer Software Testing (2 parte) 39 Esecuzione del test Costruzione di Moduli guida (driver) invocano l unità sotto test, inviandole opportuni valori, relativi al test case Moduli fittizi (stub) sono invocati dall unità sotto test; emulano il funzionamento della funzione chiamata rispetto al caso di test richiesto (tenendo conto delle specifiche della funzione chiamata) Quando la funzione chiamata viene realizzata e testata, si sostituisce lo stub con la funzione stessa Modulo guida Unità sotto test Modulo fittizio Software Testing (2 parte) 40 20

21 Driver Tramite un framework di Testing Automation come JUnit è possibile realizzare driver e stub necessari per testare un modulo non terminale Le classi di test per JUnit rappresentano dei driver quando si riferiscono ad una classe non accessibile dall esterno Un driver deve avere la visibilità dei componenti da testare (o quanto meno dell interfaccia che vogliamo esercitare) Software Testing (2 parte) 41 Stub Uno stub è una funzione fittizia la cui correttezza è vera per ipotesi Esempio, se stiamo testando una funzione prod_scal(v1,v2) che richiama una funzione prodotto(a,b) ma non abbiamo ancora realizzato tale funzione Nel metodo driver scriviamo il codice per eseguire alcuni casi di test Ad esempio chiamiamo prod_scal([2,4],[4,7]) Il metodo stub potrà essere scritto così: int prodotto (int a, int b){ if (a==2 && b==4) return 8; if (a==4 && b==7) return 28; } La correttezza di questo metodo stub è data per ipotesi Ovviamente per poter impostare tale testing, bisognerà avere precise informazioni sul comportamento interno richiesto al modulo da testare Software Testing (2 parte) 42 21

22 Il Testing di Sistemi Interattivi Software Testing (2 parte) 43 Testing di sistemi interattivi Il testing di sistemi interattivi (in particolare di interfacce utente) viene condotto tipicamente in maniera black box Tipicamente i casi di test sono progettati tenendo in conto le possibili interazioni che un utente può eseguire sull interfaccia utente Per poter approcciare il problema del testing è fondamentale la disponibilità di un modello descrittivo delle interazioni utentemacchina Quali modelli sono utilizzabili per modellare UI? Software Testing (2 parte) 44 22

23 Modellazione delle interazioni Il modello più comune è un modello di Macchina a stati: Gli elementi fondamentali di una UI sono: Finestre e relativi Widget, dotati di Eventi che possono essere eseguiti dagli utenti Campi, che possono essere eventualmente settati Si suppone che l interfaccia utente non esegua alcuna operazione se non in seguito a sollecitazioni da parte degli utenti Lo stato dell interfaccia utente viene modellato da uno stato di un automa L esecuzione di eventisulla UI (es. Click su button ) viene modellata come ingressi impulsivi che scatenano transizioni nell automa Gli input immessi sono modellati come ingressi a livelli da cui dipende la transizione che si verifica Software Testing (2 parte) 45 Esempio- modello di FSM per una UI Click on "Add new film" Search Movie Click on "Search" Logged As Admin Click on "Cancel" Click on "Back" List of Films Click on "Search" Click on "Cancel" Click on "film's link" Click on "film's link" Click on "OK" Movie Inserted Click on "Insert" Film Information Click on "Cancel" Click on "Back" Click on "Back" Film Information + list of film Film Information + Search Movie Es.: L FSM che descrive l evoluzione di una UI per l esecuzione di un Caso d Uso Software Testing (2 parte) 46 23

24 Testing delle interfacce Gli input dei casi di test devono essere indicati sotto forma di sequenze di valori di input ed eventi da eseguire. A seconda dei criteri di copertura (es. Stati, Eventi, Transizioni, path ), si progetteranno diversi TC Es.: click (add-film),click(search), click(film link),click(insert), click(ok) è il TC che permette di eseguire il cammino in rosso (Scenario: Inserimento Film OK) Ad una sequenza di valori di input dovrebbe corrispondere una sequenza di stati visitati e di output riscontrati. Software Testing (2 parte) 47 Esempio- modello di FSM per una UI Click on "Add new film" Search Movie Click on "Search" Logged As Admin Click on "Cancel" Click on "Back" List of Films Click on "Search" Click on "Cancel" Click on "film's link" Click on "film's link" Click on "OK" Movie Inserted Click on "Insert" Film Information Click on "Cancel" Click on "Back" Click on "Back" Film Information + list of film Film Information + Search Movie Es.: Cammino di esecuzione che esercita un certo scenario del Caso d Uso Software Testing (2 parte) 48 24

25 Possibile problema Come ottenere un FSM che descriva adeguatamente l UI e che possa essere usato per progettare i casi di Test? Due possibilità: FSM prodotto in fase di sviluppo dell applicazione (ma può essere poco aderente all effettiva implementazione fatta dell UI) FSM ricostruito per Reverse Engineering a partire dalla UI effettivamente implementata (richiede tecniche di analisi statica o dinamica) Nel caso di Interfacce Dinamicamente Configurabili (es. di Rich Internet Applications) piuttosto che Statiche, l analisi statica non è sufficiente! Necessità di definire tecniche e strumenti di RE per la generazione (semi-automatica) del modello. Software Testing (2 parte) 49 Automatizzazione Per poter eseguire automaticamente casi di test su interfacce utente sono necessari: Strumenti che consentano di emulare il comportamento dell utente, in particolare: Settare valori di input Scatenare eventi Strumenti che consentano di analizzare le interfacce restituite Tramite asserzioni sui widget presenti nell interfaccia e I loro valori Software Testing (2 parte) 50 25

26 Un esempio: Selenium Consideriamo il framework Selenium, a supporto del testing di interfacce utente di applicazioni Web Selenium offre quattro modalità di utilizzo: Selenium IDE Selenium Core Selenium Remote Control Selenium Grid Software Testing (2 parte) 51 Selenium IDE Si tratta di un estensione di un browser che consente di: catturare le interazioni tra un utente e una applicazione web (fase di Capture) suggerire asserzioni relative alla presenza di widget sull interfaccia utente replicare l esecuzione di casi di test, mantenendo un log degli esiti deitest (fase di Replay) Selenium è dunque usabile per progettare TC anche a prescindere da un modello formalizzato (es. FSM) della UI. Usabile per l esecuzione di Testing di Accettazione Software Testing (2 parte) 52 26

27 Capture In fase di capture, Selenium IDE mantiene un log delle operazioni effettuate dall utente e delle asserzioni da egli proposte Software Testing (2 parte) 53 Replay In fase di replay, Selenium IDE esegue automaticamente test generati in fase di capture, mantenendo statistiche sul numero di test terminati con successo e falliti Software Testing (2 parte) 54 27

28 Codice generato In fase di capture, Selenium IDE genera anche del codice sorgente (a scelta in Java, C#, Perl, PHP, Python o Ruby) che può essere eseguito indipendentemente da Selenium IDE Il codice generato necessita, per essere eseguito, di packages forniti con Selenium (che formano il Selenium Core) Software Testing (2 parte) 55 Testing di regressione e Ripple effect Dopo un intervento di manutenzione, è probabile che la modifica effettuata influisca sul resto del sistema, generando nuovi difetti (è il cosiddetto ripple effect). Chi corregge potrebbe non avere una adeguata conoscenza di tutto il sistema e delle sue connessioni Il sistema può regredire ( invecchiare ) verso uno stato più difettoso Occorre eseguire il Testing di Regressione E però molto costoso ripetere tutti i singoli test, a seguito di un unica modifica fatta. Sarebbe utile poter automatizzare tale attività Software Testing (2 parte) 56 28

29 Testing di regressione Si applica in seguito ad un intervento di manutenzione su di un software esistente, per il quale esiste già un piano di test Un problema: quali test devono essere riprogettati? E quali test possono essereriusati? Sicuramente devono essere riprogettati tutti i casi di test relativi alla nuova funzionalità implementata (o alla funzionalità modificata) Quali altri test dovranno essere rieseguiti? Per determinare quali test preesistenti devono essere rieseguiti, occorre valutare quali altre funzionalità potrebbero essere state influenzate dalla modifica realizzata, ossia eseguire l Impact Analysis: Quale sarà stato l impatto della modifica sul sistema? Software Testing (2 parte) 57 Impact Analysis e grafo delle dipendenze L analisidi impatto è la disciplina che permette di conoscere, data una modifica, quali parti del software possono esserne influenzate (e quindi devono essere ri-testate) Una tecnica semplice per la valutazione dell impatto è basata sul Grafo delle Dipendenze Un grafo delle dipendenze ha tanti nodi quanti sono I moduli (classi/funzioni), e un arco per ogni associazione/dependency tra i moduli Nei sistemi object oriented il grafo delle dipendenze può essere banalmente ricavato dal diagramma di progetto di dettaglio Data una modifica su di un modulo m tutti i moduli m che da essi dipendono (per i quali esista un arco m m) sono sicuramente impattati dalla modifica di m Tutti I moduli m che dipendono da uno qualunque dei moduli m saranno a loro volta impattati, e così via Software Testing (2 parte) 58 29

30 Grafo delle dipendenze ed Analisi dell Impatto <<dependency>> m <<dependency>> Se m è stato modificato, occorrerà controllare (e ritestare) tutti i moduli che dipendono da m (direttamente, come m, ed indirettamente, come m e m1 ) m <<dependency>> m m1 Se in fase di progettazione del software, tutte le dipendenze fra artifatti fossero registrate esplicitamente, si potrebbe facilmente eseguire tale Analisi di Impatto [A.R. Fasolino, G. Visaggio Improving Software Comprehension through an Automated Dependency Tracer, IEEE Workshop on Program Comprehension,1999] Software Testing (2 parte) 59 Testing di regressione I casi di test relativi ai moduli impattati (oppure tutti i moduli, nel casoin cui non sia stato possibile effettuare impact analysis) devono essere rieseguiti L oracolo del testing di regressione è fornito dall esito dei test che si otteneva prima di eseguire la modifica Il testing di regressione si presta, quindi, facilmente ad essere automatizzato Qualora invece non fosse automatizzato, il testing di regressione diventerebbe una pratica molto onerosa e renderebbe molto costosa l adozione di un ciclo di vita evolutivo, come ad esempio quelli di sviluppo agile che fanno uso di tecniche di extreme Programming Software Testing (2 parte) 60 30

31 Analisi Mutazionale Software Testing (2 parte) 61 Analisi Mutazionale I criteri di copertura finora presentati cercano di coprire: Le funzionalità dichiarate dell applicazione (testing funzionale) Gli elementi della struttura dell applicazione (testing strutturale) Un criterio di copertura ideale sarebbe quello di riuscire a coprire tutti gli elementi difettosi presenti nell applicazione. Come è possibile valutare la capacità potenziale di una data test suite nella rilevazione dei difetti? Software Testing (2 parte) 62 31

32 Analisi Mutazionale Il primo passoconsiste nell immaginare quali possano essere i possibili errori (fault model) E necessario proporre un modello degli errori e dei corrispondenti operatori di mutazione Un operatore di mutazione introduce in un programma, supposto corretto, un difetto (realizzando un operazione di fault injection), trasformando il programma originale in un mutante Fault Program Mutant Software Testing (2 parte) 63 Analisi Mutazionale I difetti (fault) sono inseriti automaticamente nei programmi, ottenendo dei mutanti Su ogni mutante generato si vanno ad eseguire i test case progettati per l applicazione originale L oracolo per l esecuzione di tali test è dato dall output che veniva generato dal programma originale Se l esito del test è positivo (l output del mutante differisce da quello del programma originale), allora si dice che il mutante è stato ucciso (killed) Altrimenti, il mutante non è stato rivelato dal test, ed è sopravvissuto. Più mutantisono uccisi, maggiore fiducia si può avere nella capacità della Test Suite di scoprire difetti! Software Testing (2 parte) 64 32

33 Analisi Mutazionale L efficacia di una test suite si può misurare come TER = # killed Mutants / # Mutants In conclusione: Una test suite che riesca a rivelare il maggior numero possibile di mutanti è da considerarsipiù promettente nella rivelazione di potenziali difettinell applicazione Software Testing (2 parte) 65 Problemi dell analisi mutazionale Difficoltà nella modellazione dei difetti di un sistema software Di solito vengono proposti degli operatori di mutazione Basandosi sull esperienza generica di chi propone il testing mutazionale riguardo le possibili cause di errore Basandosi su di un analisi statistica dei difetti rilevati in altri software Gli operatori proposti sono di solito estremamente generici, per poter essere applicabili ad ogni software, indipendentemente dal linguaggio adottato e dalle caratteristiche della singola applicazione Esempi: Operatore che sostituisce un operazione aritmetica con un altra Operatore che sostituisce un operatore relazionale con un altro Operatore che inverte la posizione di due righe di programma, etc. Software Testing (2 parte) 66 33

34 Problemi dell analisi mutazionale Il numero di possibili difetti è estremamente elevato, già per un piccolo frammento di software Il numero di mutanti generati da un piccolo insieme di operatori è estremamente elevato Per ogni mutante dovrebbero essere eseguiti tutti i casi di test di una test suite L approccio è possibile solo in presenza di un ambiente per la testing automation, e anche in questo caso è molto oneroso Spesso si decide di applicare gli operatori di mutazione solo a campione Software Testing (2 parte) 67 Problemi dell analisi mutazionale Altri problemi: Non tutti i difetti di un sistema software sono legati ad errori nel codice sorgente Si pensi a difetti del tipo di: mancanza di un requisito, scorretta interpretazione di un requisito, etc. Alcuni difetti portano ad errori sintattici e sono giàrivelati dal compilatore Non è possibile proporre operatori generali che riproducano gli errori semantici Software Testing (2 parte) 68 34

35 Vantaggi L analisi mutazionale è una tecnica completamente automatica, che può essere eseguita in batch senza l assistenza del tester. Occorre però disporre di strumenti automatici per la generazione dei mutanti, l esecuzione dei test, la valutazione dei risultati ( ) Si rivela utile come banco di prova per il confronto in ambiente sperimentale tra diverse test suite, per valutare quale sia in grado di rilevare più difetti. Software Testing (2 parte) 69 Il Testing Statico Software Testing (2 parte) 70 35

36 Tecniche di Verifica e Validazione Analisi statica: processo di valutazione di un sistema o di un suo componente basato sulla sua forma, struttura, contenuto, documentazione senza che esso sia eseguito. Esempi sono: revisioni, ispezioni, recensioni, analisi data flow Analisi dinamica: processo di valutazione di un sistema software o di un suo componente basato sulla osservazione del suo comportamento in esecuzione. Di solito solo queste tecniche si identificano come testing Analisi formale: uso di rigorose tecniche matematiche per l analisi di algoritmi. E usata soprattutto per la verifica del codice e dei requisiti specie quando questi sono specificati con linguaggi formali (es. Z, VDM). Software Testing (2 parte) 71 Principali tecniche di analisi statica Analisi statica in compilazione Code reading Code inspections or reviews Walktrough Control flow analysis Data flow analysis Esecuzione simbolica Software Testing (2 parte) 72 36

37 Analisi statica in compilazione I compilatori effettuano una analisi statica del codice per verificare che un programma soddisfi particolari caratteristiche di correttezza statica, per poter generare il codice oggetto. Tipiche anomalie identificabili: nomi di identificatori non dichiarati, incoerenza tra tipi di dati coinvolti in una istruzione, incoerenza tra parametri formali ed effettivi in chiamate a subroutine, codice non raggiungibile dal flusso di controllo Software Testing (2 parte) 73 Code Reading (o Desk Checking) E effettuata un attenta lettura individuale del codice per individuare errori e/o discrepanze con il progetto. Il lettore effettua mentalmente una pseudo-esecuzione del codice e processi di astrazione che lo conducono a verificare la correttezza del codice rispetto alle specifiche e il rispetto di standard adottati. Tipici difetti identificabili: nomi di identificatori errati, errato innesto di strutture di controllo, loop infiniti, inversione di predicati, commenti non consistenti con il codice, incorretto accesso ad array o altre strutture dati, incoerenza tra tipi di dati coinvolti in una istruzione, incoerenza tra parametri formali ed effettivi in chiamate a subroutine, inefficienza dell algoritmo, non strutturazione del codice, codice morto, etc. L efficacia di tale tecnica è limitata se chi la esegue è la stessa persona che ha scritto il codice. Software Testing (2 parte) 74 37

38 Code Inspections (o review) Riunioni formali cui partecipa un gruppo di persone tra cui almeno una del gruppo di sviluppo, un moderatore ed altri esperti. Lo sviluppatore legge il codice ad alta voce, linea per linea, e i partecipanti fanno commenti e/o annotazioni. Tipicamente queste riunioni sono preannunciate ai partecipanti cui viene fornita la documentazione necessaria (codice e relativi documenti) per la revisione. È una tecnica che riesce ad individuare fra il 30 e il 70% degli errori nella logica del programma. Software Testing (2 parte) 75 Code Inspection L obiettivo della riunione è scoprire difetti, non correggerli. Comunque, spesso l analisi dei difetti effettuata viene discussa e vengono decise le eventuali azioni da intraprendere accettazione del codice, rigetto, annotazioni su eventuali non aderenze a specifiche, indicazioni delle modifiche da apportare Il codice è analizzato usando checklist dei tipici errori di programmazione, quali: Errori di data reference, data declaration, di calcolo, di confronto, sul flusso di controllo, di interfaccia, di I/O. Le checklist sono generiche (indipendenti dal linguaggio) ma possono essere adattate agli specifici linguaggi analizzati. Software Testing (2 parte) 76 38

39 Esempio di Checklist per le Ispezioni Software Testing (2 parte) 77 Walkthrough Analisi informale del codice svolta da vari partecipanti i quali operano come il computer : in pratica, si scelgono alcuni casi di test e si simula l esecuzione del codice a mano (si attraversa- walkthrough- il codice). L organizzazione della riunione è simile a quella della tecnica delle Ispezioni: Tra 3 e 5 partecipanti; Riunioni brevi (max. 120 minuti); Attenzione sulla ricerca dei difetti, piuttosto che sulla correzione; Attenzione a non criminalizzare il programmatore (autore del difetto)! Software Testing (2 parte) 78 39

40 Control Flow Analysis Il flusso di controllo è esaminato per verificarne la correttezza. Il codice è rappresentato tramite un grafo, il grafo del flusso di controllo (Control flow Graph - CfG), i cui nodi rappresentano statement (istruzioni eo predicati) del programma e gli archi il passaggio del flusso di controllo. Il grafo è esaminato per identificare ramificazioni del flusso di controllo e verificare l esistenza di eventuali anomalie quali codice irraggiungibile e non strutturazione. Software Testing (2 parte) 79 Data flow analysis - statica Analisi dell evoluzione del valore delle variabili durante l esecuzione di un programma, permettendo di rilevare anomalie. Intrinsecamente è dinamica, ma alcuni aspetti possono essere analizzati staticamente. L analisi statica è legata alle operazioni eseguite su una variabile: definizione: alla variabile è assegnato un valore uso: il valore della variabile è usato in un espressione oun predicato annullamento: al termine di un istruzione il valore associato alla variabile non è più significativo Es.: nell espressione a:=b+c; la variabile a è definita mentre b e c sono usate Software Testing (2 parte) 80 40

41 Data Flow Analysis La definizione (d) di una variabile, così come un annullamento (a), cancella l effetto di una precedente definizione della stessa variabile, ovvero ad essa è associato il nuovo valore derivante dalla nuova definizione (o il valore nullo) Una corretta sequenza di operazioni prevede che: L uso (u) di una variabile deve essere sempre preceduto da una definizione della stessa variabile senza annullamenti intermedi (Sequenza valida : du) Una variabile non definita ha un valore sporco Una definizione di una variabile deve essere sempre seguita da un uso della variabile, prima di un altra definizione o di un annullamento della stessa variabile (Sequenze non valide: dd, da) Una doppia definizione è indice del fatto che la prima definizione è risultata inutile Software Testing (2 parte) 81 Data Flow Analysis Software Testing (2 parte) 82 41

42 Data Flow Analysis-esempio Software Testing (2 parte) 83 Data Flow Analysis- esempio Software Testing (2 parte) 84 42

43 Esecuzione simbolica Il programma non è eseguito con i valori effettivi ma con valori simbolici dei dati di input. L esecuzione procede come una esecuzione normale ma non sono elaborati valori, bensì formule formate dai valori simbolici degli input Gli output sono formule dei valori simbolici degli input L esecuzione simbolica anche di programmi di modeste dimensioni può risultare molto difficile. Ciò è dovuto all esecuzione delle istruzioni condizionali: deve essere valutato ciascun caso (vero e falso); in programmi con cicli ciò può portare a situazioni difficilmente gestibili. Software Testing (2 parte) 85 Esecuzione simbolica Software Testing (2 parte) 86 43

44 Esempio Software Testing (2 parte) 87 Path Conditions Nel caso di esecuzioni simboliche con condizioni, alcuni statement sono eseguiti solo se gli input soddisfano determinate condizioni. Una Path Condition (pc), per un determinato statement, indica le condizioni che gli input devono soddisfare affinchè una esecuzione percorra un cammino lungo cui lo statement sia eseguito. Una pc è un espressione Booleana sugli input simbolici di un programma. Software Testing (2 parte) 88 44

45 Path Condition All inizio dell esecuzione simbolica essa assume il valore vero (pc := true ). Per ogni condizione che si incontrerà lungo l esecuzione, pc assumerà differenti valori a seconda dei differenti casi relativi ai diversi cammini dell esecuzione. Software Testing (2 parte) 89 Software Testing (2 parte) 90 45

46 Software Testing (2 parte) 91 Path Condition 92 Software Testing (2 parte) 92 46

47 Analisi dell Execution Tree Ogni foglia dello execution tree rappresenta un cammino che sarà percorso per certi valori di input Le Pc associate a due differenti foglie sono distinte; ciascuna foglia dello execution tree rappresenta un cammino che sarà percorso per la Pc ad essa associata. Non esistono esecuzioni per cui sono vere contemporaneamente più Pc (vero solo per programmi sequenziali) Feasible Path: un cammino per il quale esiste un insieme di dati di ingresso che soddisfa la path condition. Unfeasible Path: un cammino per il quale non esiste un insieme di dati di ingresso che soddisfa la path condition. Se l output ad ogni foglia è corretto allora il programma è corretto. Ma, quanti rami può avere un execution tree? Software Testing (2 parte) 93 DETERMINAZIONE DELLA ESEGUIBILITA DI UN CAMMINO (Path feasibility) Davis (1973) Il problema di stabilire se esiste una soluzione per un sistema di diseguaglianze é indecidibile. Un cammino é eseguibile se esiste un punto del dominio di ingresso che rende soddisfatta la sua path condition (..un sistema di diseguaglianze). La determinazione della feasibility o della infeasibility di un cammino è indecidibile. NB. se si riesce a dimostrare che ciascun predicato nella path condition è dipendente linearmente dalle variabili di ingresso, allora il problema è risolubile con algoritmi di programmazione lineare. Software Testing (2 parte) 94 47

48 Call Directed Graph Software Testing (2 parte) 95 Alberi di Dominanza Software Testing (2 parte) 96 48

49 Alberi di Dominanza Software Testing (2 parte) 97 Software Testing (2 parte) 98 49

50 Il Debugging Software Testing (2 parte) 99 Debugging Attività di ricerca e correzione dei difetti che sono causa di malfunzionamenti. É l attività conseguenziale all esecuzione di un test che ha avuto successo. Il debugging è ben lungi dall essere stato formalizzato Metodologie e tecniche di debugging rappresentano soprattutto un elemento dell esperienza del programmatore/tester Software Testing (2 parte)

51 Difficoltà del debugging 1. Il sintomo e la causa possono essere lontani. 2. Il sintomo può scomparire solo temporaneamente (a seguito di correzione di altro errore) 3. Il sintomo può non essere causato da errori specifici (ma intrinseci all ambiente di esecuz.-es errori di arrotondamento) 4. Può dipendere da errori di temporizzazione e non di elaborazione. 5. Può essere difficile riprodurre le condizioni di partenza 6. Il sintomo può essere intermittente. Software Testing (2 parte) 101 Localizzazione dei difetti Ridurre la distanza tra difetto e malfunzionamento Mantenendo un immagine dello stato del processo in esecuzione in corrispondenza dell esecuzione di specifiche istruzioni Watch point e variabili di watch Un watch, in generale, è una semplice istruzione che inoltra il valore di una variabile verso un canale di output» L inserimento di un watch (sonda) è un operazione invasiva nel codice: anche nel watch potrebbe annidarsi un difetto» In particolare l inserimento di sonde potrebbe modificare sensibilmente il comportamento di un software concorrente Asserzioni, espressioni booleane dipendenti da uno o più valori di variabili legate allo stato dell esecuzione Software Testing (2 parte)

52 Metodologie per il Debugging Forza Bruta Ragionamento Induttivo Ragionamento deduttivo Backtracking Software Testing (2 parte) 103 Forza Bruta Il modo più inefficace per fare debugging. Diversi approcci possibili: Usare storage dump (stampe dello stato della memoria in esadecimale o ottale ) Disseminare il codice di sonde per catturare quante più informazioni possibili e valutarle, in cerca di indizi Usare qualche strumento di debugging automatico (che permette di analizzare l esecuzione del programma inserendo punti di break, osservazione di variabili, etc..) Largamente inefficace perché può produrre eccessive informazioni da comprendere Ricorrervi solo quando altre tecniche hanno fallito! Software Testing (2 parte)

53 Debugging usando l approccio Induttivo Processo di ragionamento Induttivo: dal particolare al generale. Basato sulla raccolta di dati ed indizi sul fallimento, formulazione e verifica di ipotesi sulle possibili cause, in modo iterativo. Software Testing (2 parte) 105 Un modo per strutturare la raccolta di indizi Software Testing (2 parte)

54 Debugging usando l approccio Deduttivo Si procede dal generale al particolare: Si formulano varie ipotesi sulla causa dell errore e si raccolgono dati per validarle o scartarle Software Testing (2 parte) 107 Debugging per BackTracking Si cerca di ripercorrere il codice all indietro a partire dal punto dove si è verificato il malfunzionamento (istruzione di output oppure eccezione) Analogamente alla tecnica delle Path Condition, diventa via via più difficile procedere all indietro all allargarsi del campo di possibilità. Software Testing (2 parte)

55 Automatizzazione del debugging Il debugging è un attività estremamente intuitiva, che però deve essere operata nell ambito dell ambiente di sviluppo e di esecuzione del codice Strumenti a supporto del debugging sono quindi convenientemente integrati nelle piattaforme di sviluppo (IDE), in modo da poter accedere ai dati del programma, anche durante la sua esecuzione, senza essere invasivi rispetto al codice In assenza di ambienti di sviluppo, l inserimento di codice di debugging invasivo rimane l unica alternativa Software Testing (2 parte) 109 Funzionalità comuni di debugging Inserimento break point Esecuzione passo passo del codice Entrando o meno all interno dei metodi chiamati Uscendo Verifica di asserzioni Le asserzioni possono anche essere utilizzate come parametri per break point condizionali Valutazione (watch) del valore delle variabili, mentre l esecuzione è in stato di interruzione Nei linguaggi interpretati (tra cui anche Java), è possibile anche fornire la possibilità di modificare in fase di esecuzione il valore di variabili, semplificando notevolmente il problema della ricerca di casi di test in grado di replicare il malfunzionamento Software Testing (2 parte)