Esempi di errori/difetti. algoritmi sintassi calcolo e precisione documento stress capacità ricovery sistema hardware e software standard e procedure

Transcript

1 COLLAUDO

2 Esempi di errori/difetti algoritmi sintassi calcolo e precisione documento stress capacità ricovery sistema hardware e software standard e procedure

3 Verifica e Validazione Validazione Requisiti Prodotto intermediare Prodotto intermediare Prodotto Verifica Attività necessarie per essere sicuri di non avere introdotto difetti per essere sicuri di avere realizzato il prodotto giusto Documento di TEST Documento di Collaudo

4 Testing Identificazione dell errore Correzione dell errore Program testing can be used to show the presence of bugs, but never to show their absence!(dijkstra in Dahl et al. 72) Test = processo «distruttivo» Nessun errore trovata (da un altro) = fallimento

5 Processo Coding Test Unitari Specifiche progettazione Requisiti funzionali Altri Requisiti Software Requisiti Cliente Contesto Cliente Coding Test Unitari Test Integrazione Test Funzionali Test Performance Test Accettazione Test Istallazione Sistema In utilizzazione Componenti collaudati Moduli integrati Sistema funzionante Software Verificato e validato Sistema accettato Coding Test Unitari Programmatore Equipe validazione +Test di regressione: verifica che le modifiche non abbiano introdotto rallentamenti

6 Categorie di verifica Verifica statica (white box) non prevede l esecuzione del codice usata specificamente per attività di verifica di alcuni aspetti di qualità o problemi specifici (algoritmi complessi, ) eseguita sulle componenti Verifica dinamica (black box) comporta l esecuzione del codice usate per attività di verifica o validazione eseguite sulle componenti o sul sistema

7 Verifica statica (white box) Verifica senza esecuzione del codice Metodi manuali basati sulla lettura del codice più o meno formalmente documentati Metodi formali basati sulla prova assistita di proprietà del codice verifica di equivalenza o generazione automatica

8 Perché la verifica statica Praticità e intuitività Ideale per alcune caratteristiche di qualità basati sulla lettura del codice più o meno formalmente documentati Convenienza economiche costi dipendente della dimensione del codice bassi costi di infrastruttura (desk-check) buona prevedibilità dei risultati

9 Metodi di lettura Walkthrough più collaborativi Ispezione del codice più formale più rapido

10 Metodi di lettura Tecnica dell ispezione del codice L ispezione del codice consiste a ricercare gli errori tecniche classiche leggendo il codice. L'équipe deve comprendere: l'autore, un animatore competente in programmazione ma non dell equipe, preparando e guidando la riunione, archiviando le anomalie e assicurandosi più tardi che vengono corrette. Può essere fatto da un ingegnere di qualità, il concetto se diverse dal programmatore un specialista dei tests. Esempi di errori da scoprire var. non inizializzate loop infiniti/jump incompatibilità di assegnazione array ultra limiti allocazione risorse parametri procedure float

11 Verifica statica per la verifica della qualità Affidabilità recuperabilità, aderenza alle prescrizione Efficienza algorithme allocazione/desallocazione risorse Manutenibilità modificabile Portabilità ideale

12 Testing in white box Il percentuale di funzioni testate è chiamato tasso di copertura dei tests di validazione. Copertura dell istruzione Copertura delle decisioni e condizioni / cammini Controllo flow-graph (CFG)

13 Testing in white box Controllo flow-graph (CFG) Notazione del CFG Archi (Edges) Nodi (Nodes) Rappresentano il flusso di controllo Rappresentano una o più azioni

14 Testing in white box Esempio di costruzione di un CFG 1:WHILE NOT EOF LOOP! 2: Read Record;! 2: IF field1 equals 0 THEN! 3: Add field1 to Total! 3: Increment Counter! 4: ELSE! 4: IF field2 equals 0 THEN! 5: Print Total, Counter! 5: Reset Counter! 6: ELSE! 6: Subtract field2 from Total! 7: END IF! 8: END IF! 8: Print "End Record! 9: END LOOP! 9: Print Counter!

15 Testing in white box Copertura dei comandi (statement test) Richiede che ogni nodo del CFG venga eseguito almeno una volta durante il testing; E un criterio di copertura debole, che non assicura la copertura sia del ramo true che false di una decisione.

16 Verifica dinamica (black box) Attività che prevede l esecuzione del codice in un ambiente controllato e con input e output definiti sui i moduli sul sistema Metodo intuitivo progettazione, esecuzione, analisi, debugging validazione dei risultati, terminazione delle prove

17 Tests unitari Approcci possibili statico dinamico Responsabilità in genere, il programmatore stesso utilizzo del debugging

18 Tests d integrazione Obiettivo I tests d'integrazione hanno per scopo la validazione del fatto che tutte le parte sviluppate indipendentemente funzionano bene insieme in un modo coerente. Può necessitare la costruzione e l uso di stubs e drivers. Responsabilità equipe di validazione o integratore Errori da verificare errori nella realizzazione delle componenti modifica delle interfacce o cambiamenti dei requisiti problema nel riuso dei componenti integrazione con altre applicazioni

19 Tests d integrazione Drivers e Stubs Stub permette di testare un sistema incomplete Il Driver passa i dati al modulo da collaudare

20 Approcci possibili Verifiche sul sistema dinamico, sul sistema completo.dinamico, durante l integrazione, con la realizzazione di driver e stub Responsabilità gruppi distinti di codifica documentazione delle prove analisi dei malfunzionamenti debugging è responsabilità dei programmatori

21 Tabella de decisione Testing funzionale

22 Testing funzionale Quando non è possibile collaudare tutte le entrate possibile, si procede alla selezione di test di dati rappresentativi. Partizione in classe di equivalenza Esempio: x essere comprese tra 0 e 999 e y tra 0 et 4, il risultato z è Condition externe Classe valide Classe invalide x 0<=x<=999 (1) x<0(2) x>999(3) y 0<=y<=4(4) y<=0(5) y>4(6) Set di tests validi (1&4:x=10,y=2) e invalidi (2:x=-4,y=3), (3:x=2000,y=2), (5:x=10,y=-10), (6:x=6,y=6)

23 Testing funzionale Analisi ai limiti Scegliere i valori ai limiti e leggermente fuori limiti x : 0; 999 ; -0,001; y : -1; 0; 4; 5

24 Test di performanza stress volume configurazione compatibilità regressione sicurezza timing ambiente qualità ricovery maintenimanto doc usabilità

25 Collaudo Validazione del sistema test effettuato in fase di sviluppo prima della distribuzione del prodotto (α-test) attività svolta dal committente (β-test) su casi di prova definiti dal contratto Valore contrattuale il collaudo è un attività ufficiale al collaudo segue il rilascio del sistema conclusione della commessa (a meno di servizi e garanzia)

26 Caratteristiche del testing Il testing deve permettere di localizzare l errore Il testing deve essere ripetibile Il testing deve essere corretto e preciso Il test case deve essere significativo Il testing può essere oggettivo o soggettivo

27 Piano di test Definizione dei casi di test! -!! configurazione materiale e software" pre-condizioni" fasi del test" criterio di riuscita / fallimento Cronologia e durata dei tests per ciascuna fasi, cronologia e preparazione dei diversi test cases" modi dʼintegrazione Equipe coinvolte e responsabilità Procedure di seguito valutazione del grado di realizzazione dei tests" procedure di colletta dei dati statistici " Azioni da prendere nel caso di errore segnalazione ai sviluppatori" seguito dopo correzione"

28 Piano di testing Attesa e tempi di calcolo! Politica di passaggio dei tests (compresi i tests di non regressione) Norme strumenti e metodi raccomandati TESTBED (istruzione, grafi di flusso, grafi uscite)" LOGISCOPE" LOGIMETRE" PCA (analisi e copertura DIGITAL)" STOP dei tests

29 DOCUMENTI Piano! Documento collaudo Documento validazione

30 Libri Libri Software Engineering I.Sommerville cap Software ingegneering, Theory and Practice (cap. 8) S.L.PFleeger -International Edition