14. Verifica e Validazione

Transcript

1 14. Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dell utente? Introdurremo i concetti di verifica e validazione Descriveremo le fasi del processo di testing Parleremo di pianificazione del testing Descriveremo diverse strategie di testing 1 Verifica & validazione Verifica: Stiamo costruendo il prodotto nel modo giusto? Il software deve soddisfare la specifica Validazione: "Stiamo costruendo il prodotto giusto?" Il software deve fare quello che l utente realmente richiede Sono domande che devono percorrere tutto il ciclo di vita del software, per correggere errori e per valutare se il prodotto è usabile dal punto di vista operativo 2

2 Verifica e Validazione requisiti informali verifica spec. livello 1 spec. livello 2 validazione spec. livello n implementaz. 3 Verifica statica/dinamica Verifica e Validazione dinamica Testare il prodotto facendo prove e osservandone il comportamento Verifica Statica Analizzare la rappresentazione statica del sistema per individuare i problemi 4

3 V&V statica e dinamica Static verification Requirements specification High-level design Fo rmal specification Detailed design Program Prototype Dynamic validation 5 Testing La verifica di corretto comportamento corretto su un numero finito di casi non assicura la correttezza del programma Non si può raggiungere una certezza di correttezza attraverso il testing Questo non significa che sia una tecnica di verifica inutile Anche le prove matematiche possono contenere errori 6

4 Terminologia ERRORE la causa di un malfunzionamento, p.es. un errore umano di editing ANOMALIA, GUASTO (fault) difetto del programma dovuto a un errore MALFUNZIONAMENTO (failure) manifestazione visibile della presenza di un anomalia 7 Esempio ERRORE di editing ANOMALIA --> * invece di + MALFUNZIONAMENTO --> la stampa program RADDOPPIA read (x); y := x*x; write (y)... ANOMALIA causata da un errore MALFUNZIONAMENTO causato da un anomalia 8

5 Obiettivo per un test Individuare tecniche empiriche per aumentare la probabilità che una anomalia causi un malfunzionamento 9 Testing Il test può servire per scoprire la presenza di possibili malfunzionamenti, ma non a garantirne l assenza (Dijkstra) Un test ha successo se permette di individuare uno o più errori Per i requisiti non funzionali possono solo essere utilizzate tecniche di validazione 10

6 Testing Testing statistico Il test è progettato in relazione alla frequenza d uso dei vari tipi di input da parte degli utenti. Usato per la stima di affidabilità del sistema e la efficienza del sistema Defect testing I test sono progettati per scoprire i difetti del sistema Debugging Individuare dove si trova l errore e progettarne la correzione 11 Fasi del testing Unit testing Module testing Sub-system testing System testing Acceptance testing Component testing Integration testing User testing 12

7 Testing di sistemi OO Nei sistemi OO i livelli di integrazione sono meno distinti rispetto allo schema precedente Testare le singole classi corrisponde allo unit testing Cluster testing. Corrisponde al module testing. Testare un gruppo di oggetti che cooperano per fornire una serie di servizi 13 Il piano di testing E un documento che deve descrivere: 1. Il processo di testing adottato 2. Tracciabilità dei requisiti 3. Elementi testati 4. Schedule del testing: tempo e risorse allocate 5. Procedure di registrazione dei test 6. Requisiti hardware e software utilizzati 7. Vincoli che condizionano il testing 14

8 Modello a V del processo software Requirements specification System specification System design Detailed design Acceptance test plan System integration test plan Sub-system integration test plan Module and unit code and tess Service Acceptance test System integration test Sub-system integration test 15 Strategie di testing Strategie diverse possono essere applicate nelle diverse fasi del processo di testing 1. Incremental testing 2. Top-down testing 3. Bottom-up testing 4. Thread testing 5. Stress testing 6. Back-to-back testing 16

9 Incremental testing A T1 A T1 A T1 T2 B T2 T2 B T3 B T3 C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequ ence 3 17 Esperienza Sembra che circa il 40% di malfunzionamenti possa essere attribuito a problemi di integrazione essenzialmente errori nell interpretazione che un modulo fa delle specifiche dell altro 18

10 Test di modulo Un modulo fa parte di un sistema è cliente di altri moduli è usato da altri moduli MOD 19 Test di modulo Occorre simulare i moduli usati STUB Occorre simulare i moduli che lo usano DRIVER Caso di MOD sottoprogramma DRIVER inizializza eventuali variabili globali chiama MOD STUB completa i sottoprogrammi mancanti con dei monconi 20

11 Top-down testing Testing Level 1 Level 1 sequence... Level 2 Level 2 Le vel 2 Level 2 Le vel 2 stubs Le vel 3 stubs 21 Top-down testing Inizia con i livelli più alti del sistema e procede all ingiù: le sottocomponenti sono rappresentate da stub (ceppi, monconi), che hanno la stessa interfaccia delle sottocomponenti ma funzionalità limitata E una strategia di testing adatta quando si procede in uno sviluppo top-down Individua rapidamente errori architetturali Può richiedere di aver già completa la struttura del sistema, prima di poter iniziare qualsiasi test Può risultare difficile sviluppare gli stub 22

12 Casi possibili di stub Il chiamato non fa nulla (eventualmente stampa la traccia) Il chiamato colloquia con il programmatore per calcolare il risultato atteso (stub interattivo) Il chiamato è una versione semplificata (un prototipo) del modulo che verrà chiamato 23 Bottom-up testing Test drivers Level N Level N Le vel N Level N Level N Testing sequence Test drivers Level N 1 Level N 1 Level N 1 24

13 Bottom-up testing I vantaggi del bottom-up sono gli svantaggi del top-down (e viceversa) Si inizia dalle componenti più a basso livello e si lavora all insù, realizzando dei drivers che simulano l ambiente nel quale le componenti saranno inserite Non individua errori di progettazione di alto livello se non molto avanti nel processo E appropriato per sistemi object-oriented 25 Thread testing Adatto a sistemi real-time e ad oggetti Si basa sul testare un operazione che comporta una sequenza di passi di processo che sono legati da uno stesso thread (filo) nel sistema Inizia con thread legati a un singolo evento e poi viene reso più complesso testando threads a eventi multipli Può essere impossibile un threading test completo, a causa del numero elevato di combinazioni di eventi 26

14 Esempio: interazione di processi I1 (P1) I1 (P2) I2 (P1) P1 I3 (P1) P2 P5 O1 (P5) I1 (P3) P3 O1 (P4) P4 O2 (P4) 27 Thread testing I1 (P3) P3 P2 P4 O1 (P4) I1 (P1) I2 (P1) P1 P2 P5 O1 (P5) I3 (P1) 28

15 Multiple-thread testing I1 (P1) I1 (P2) I2 (P1) P1 P2 P5 O1 (P5) I3 (P1) P4 O2 (P4) 29 Stress testing Ha come obiettivo verificare che il sistema sopporta il carico massimo previsto in fase di progettazione. Il sistema viene testato oltre i limiti finché fallisce Testa il comportamento del sistema in caso di fallimento, e verifica le conseguenti perdite di dati o di servizi Particolarmente importante in sistemi distribuiti, che possono subire degrado quando la rete è troppo carica 30

16 Back-to-back testing Testa diverse versioni del programma con lo stesso input, e confronta gli output. Se l output è diverso, ci sono errori potenziali Riduce il costo di esaminare il risultato dei test: il confronto degli output può essere automatizzato Si può usare quando è disponibile un proptotipo, quando il sistema vine sviluppato in più versioni (su diverse piattaforme) o un upgrade di sistema 31 Back-to-back testing Test data Program version A Program version B Resu lts comparator Difference report 32