Ingegneria del Software

Транскрипт

1 Ingegneria del Software Testing - Strategie di del Software Testing del Software Il testing è quell attivit attività di esercizio del software tesa all individuazione dei malfunzionamenti prima della messa in esercizio Construction Testing Deployment

2 Cosa mostra il Testing? malfunzionamenti conformità coi requisiti indicazioni di performance indicazione di qualità Failure Faults, Errors e Failures Si manifesta quando il servizio offerto dal sistema devia dalle specifiche Error Si ha quando il sistema si porta in uno stato scorretto che può essere causa di un fallimento Fault E la causa che provoca un errore

3 Un Esempio di Software Fault Un sistema di gestione degli accessi a servizi pubblici e privati. Specifiche: Gli utenti possono avere due livelli di diritti 1 e 0. I servizi privati richiedono livello di diritti pari ad 1 L accesso ad un servizio è accordato se il servizio è disponibile ed il livello di diritti utente coincide col livello richiesto Un Esempio di Software Fault (2) if(servizioprivato) Fault { if(diritti = 1) Autorizzato = true; else } Caso 1 Utente Marco Rossi Diritti = 1 Richiede Servizio Pubblico Servizio disponibile Fault Latente Nessun Errore Nessun Fallimento Autorizzato = false; if(autorizzato && ServizioDisponibile) cout<<"accesso garantito"<<endl; Caso 2 Utente Marco Rossi Diritti = 1 Richiede Servizio Privato Servizio disponibile Caso 3 Utente Giorgio Bianchi Diritti = 0 Richiede Servizio Privato Servizio NON disponibile Caso 4 Utente Giorgio Bianchi Diritti = 0 Richiede Servizio Privato Servizio Ing. Antonio disponibile Coronato Fault Mascherato Nessun Errore Nessun Fallimento Fault Attivo Errore Nessun Fallimento Fault Attivo Errore Fallimento

4 Software Faults nel Ciclo di Vita del Sistema La presenza di errori nel software sviluppato è da considerarsi una condizione normale Per sistemi software complessi non è realistico pensare di ottenere dalla fase di sviluppo release immuni da errori Adottare processi di sviluppo di qualità riduce la quantità di errori presenti nel software sviluppato E necessario eliminare (o quantomeno ridurre) gli errori software prima della messa in esercizio del sistema Azioni di collaudo guidate da opportune strategie individuano errori presenti nel software Azioni correttive aumentano la qualità del prodotto finale Tesi di Dijkiastra Il testing NON PUÒ dimostrare l assenza di difetti, ma può solo dimostrare la presenza di difetti

5 Chi Testa il Software? developer Comprende bene il sistema ma è inconsciamente gentile nell attivit attività di testing Testing guidato dalla consegna independent tester Deve imparare il sistema ma è più critico ed esigente Testing guidato dalla qualità Sviluppatori e tester indipendenti cooperano e svolgono entrambi attività di testing Verifica Verifica e Convalida Insieme delle attività tese ad accertare la correttezza funzionale Convalida (o Validazione) Insieme delle attività tese a verificare la implementazione dei requisiti software

6 ! "#$#%$##% & ' (()) ' '* (( "#$#%$##%

7 Strategie di Testing Le attività di testing necessitanto di una vera e propria strategia Pianificazione Progettazione dei test case Esecuzione dei test case Raccolta dei risultati Valutazione dei risultati Pianificazione del Testing Quando possiamo ritenere concluse le attività di testing? Diversi criteri per decidere quando terminare il testing Criterio temporale Si definisce un periodo di tempo massimo per le attività di testing Criterio di costo Si assegna un badget massimo per le attività di testing Criterio di copertura Percentuale predefinita degli elementi di un modello di programma Legato ad un criterio di selezione dei casi di test Criterio statistico Si ripetono attività di testing fino al raggiungimento di un MTBF (mean time between failures) obiettivo Legato ad un criterio di selezione dei casi di test

8 + * *'*,,, "#$#%$##%

9 Progettazione dei Casi di Test Un caso di test è un sottoinsieme dei possibili dati di input Un test è formato da un insieme di casi di test L esecuzione del test consiste nell esecuzione del programma per tutti i casi di test Un test ha successo se rileva uno o più malfunzionamenti del programma Progettazione dei Casi di Test (2) Un test è ideale se l insuccesso del test implica la correttezza del programma Un test esaustivo è un test che contiene tutti i dati di ingresso al programma Un test esaustivo è un test ideale Un test esaustivo non è pratico e quasi sempre non è fattibile Obiettivo realistico Selezionare casi di test che approssimano un test ideale Obiettivi pratici Massimizzare il numero di malfunzionamenti scoperti (richiede molti casi di test) Minimizzare il numero di casi di test (e quindi il costo del testing)

10 Valutazione dei Risultati del Test Condizione necessaria per effettuare un test: conoscere il comportamento atteso per poterlo confrontare con quello osservato L oracolo conosce il comportamento atteso per ogni caso di prova Oracolo umano si basa sulle specifiche o sul giudizio Oracolo automatico generato dalle specifiche (formali) stesso software ma sviluppato da altri versione precedente (test di regressione) Strategie di Testing unit test integration test system test validation test

11 Approccio Bottom-Up Si parte dal testing in piccolo e si va verso il testing in grande di Sistema di Convalida di Integrazione Unità Unità Unità Due ruoli coinvolti Chi fa cosa? di Sistema di Convalida independent tester di Integrazione Unità Unità Unità developer

12 Altre Attività di Testing Testing del produttore Testing di unità Testing di integrazione Testing di convalida Testing di sistema Testing cooperativo produttore-cliente (privilegiato) Alpha testing uso del sistema da parte di utenti reali ma nell'ambiente di produzione e prima della immissione sul mercato Beta testing uso del sistema da parte di utenti reali ma nell'ambiente di produzione e prima della immissione sul mercato Testing del cliente Testing di accettazione Testing delle Applicazioni Applicazioni Function-Oriented Le unità di testing sono rappresentate dai moduli sorgente Focus sulle funzionalità Applicazioni Object-Oriented Le unità di testing sono rappresentate dalle singole classi Focus sulle comunicazioni e collaborazioni tra classi (oltre che sulle funzionalità) Applicazioni Component-Based Le unità di testing sono rappresentate dai singoli componenti o dalle classi dei singoli componenti Focus sulle problematiche di integrazione (oltre che sulle collaborazioni e sulle funzionalità)

13 Testing di Unità Unità da Testare results software engineer test cases Testing di Unità (2) Modulo da testare Interfacce Strutture dati locali Cammini indipendenti Cammini di gestione degli errori test cases

14 Ambiente di Testing per le Unità Generalmente le unità di testing non costituisco elementi software eseguibili indipendentemente => E necessario definire ambienti di testing Modulo pilota Modulo Da testare Modulo Modulo fittizio fittizio Interfacce Strutture dati locali Cammini indipendenti Cammini di gestione degli errori Risultati test cases Strategie di Testing di Integrazione Testing dell intero sistema Si integrano tutte le unità del sistema e successivamente si procede al testing Può essere particolarmente oneroso nel caso di sistemi complessi Testing incrementale Le unità sono integrate in maniera incrementale Dopo ogni incremento si procede al testing di integrazione

15 Integrazione con approccio Top-Down Passi del processo di integrazione: 1. Testing del modulo di controllo (modulo pilota) 2. Sostituzione di un modulo fittizio con il corrispondente reale 3. Test di integrazione dopo ogni sostituzione 4. Ritorna al passo 2 fino al completamento dell integrazione Modi di integrazione: Depth-first Breadth-first Modulo reale D C E B A F Modulo pilota G Modulo fittizio Difficoltà di testing per i moduli fittizzi che devono restituire risultati di elaborazione Integrazione con approccio Bottom-Up Passi del processo di integrazione: 1. Aggregazione delle unità di basso livello in gruppi (cluster) 2. Predisposizione di un modulo pilota per il cluster 3. Test del cluster 4. Sostituzione dei moduli pilota (fittizi) con i moduli reali 5. Ritorna al passo 2 fino al completamento dell integrazione D C E cluster B A F G

16 Integrazione con approccio a Sandwitch A I moduli di controllo sono testati con moduli fittizzi B F G D C E I moduli che sviluppano funzionalità sono ragruppati in cluster cluster Ulteriori Livelli di Testing Testing di Convalida Verifica che il sistema funzioni secondo le aspettative del cliente Le aspettative del cliente sono stabilite dai requisiti Le prove di convalida possono essere specificate nel documento SRS Può includere alpha e beta testing Alpha/Beta testing Focus sull utilizzo da parte dell utente -

17 . ( +/( +/( )) "%$#%$##%

18 Ulteriori Livelli di Testing (2) Testing di sistema Focalizza sull intero sistema Può includere testing di affidabilità, sicurezza, performance e stress Testing di affidabilità Si forza il sistema a fallire per verificarne le capacità di recovery Si sollecita il sistema con dati scorretti, iniettando errori, esercitando le sezioni di gestione delle eccezioni Ulteriori Livelli di Testing (3) Testing di sicurezza Si attenta alle caratteristiche di sicurezza del sistema per evidenziare vulnerabilità Si esercitano i servizi di: Authentication Access control Privacy Testing di performance Si esercita il sistema in condizioni operative normali per verificarene le performace Testing di stress Si sollecita il sistema con volumi di carico particolarmente elevati, ad esempio un ordine di grandezza superiore alle normali condizioni

19 Debugging Definizione Il Debugging è il processo di scoperta dei fault a partire dai malfunzionamenti (failures) individuati dal testing Include l ispezione del software, cioè l analisi del codice sorgente

20 Risultati del Testing Nel caso del sistema di gestione degli accessi a servizi pubblici e privati Test Case Utente Giorgio Bianchi Diritti = 0 Richiede Servizio Privato Servizio disponibile? Failure! Qual è la causa? Grant Access! tester Risultati delle Attività di Debugging Individuare le cause dei fallimenti evidenziati dal testing if(servizioprivato) Fault { if(diritti = 1) Autorizzato = true; else Autorizzato = false; if(autorizzato && ServizioDisponibile) cout<<"accesso garantito"<<endl; }

21 Il Processo di Debugging test cases Testing regression tests new test cases suspected causes corrections identified causes Debugging results Degugging Effort tempo necessario per correggere l errore e condurre test di regressione tempo necessario per diagnosticare il fallimento, analizzare I sintomi e determinare la causa

22 Sintomi e Cause Sintomi e cause possono essere geograficamente separati I sintomi possono scomparire quando un altro errore viene corretto Correlazione tra errori symptom cause Casi di failure intermittenti Sincronizzazione di thread Fault d ambiente Malfunzionamenti introdotti da compilatori, sistemi operativi Conseguenze di un Software Fault damage infectious mild annoying serious disturbing catastrophic extreme Bug Type Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc.

23 Tecniche di debugging brute force / testing backtracking induction deduction Pressman, cap. 13 Riferimenti Bibliografici