ali e non funzionali con priorità (high, medium, low) Use Case con un Activity Diagram o uno State Diagr ram

Transcript

1 Riassunto deriva able 4 novembre Lista dei requisiti iti funziona ali e non funzionali con priorità (high, medium, low) Diagramma degli Use Case dell intero progetto Descrizione di almeno uno Use Case con un Activity Diagram o uno State Diagr ram Descrizione di un gruppo di Use Case con un Sequence Diagram Diagramma ER generale dell'intero progetto Mockup interfaces per 4 o 5 pagine web Lista dei casi di test sui requisiti trovati Alessandro Tomasi 1

2 Introduzion e al ltesting Alessandr ro Tomasi (tomasi@dit.unitn.it) 29 ottobre 2008 Alessandro Tomasi 2

3 Il Tes sting Verifica del codice implementato tramite una serie di Casi di Test Due fasi del Testing: verifica del codice da parte del programmatore verifica del codice da par rte di altre persone Alessandro Tomasi 3

4 Metodologie di Testing - Analisi Statica - Analisi Dinamica Alessandro Tomasi 4

5 Analisi Statica Ricerca di eventuali anomalie analizzando il codice, anche usando tool appositi, ma nonn eseguendo il software NOTA: analisi ora non affrontata, ci sarà un corso apposito al Secondo Anno della Laurea Specialistica, indirizzo Tecnologie del Software, denominato Analis si e Testing del Software Alessandro Tomasi 5

6 Analisi Dinamica Ricerca di eventuali malfunzionamenti del prodotto software tramite l esecuzione del codic ce stesso fornendo opportuni dati in ingresso. Alessandro Tomasi 6

7 Logica invertita rispetto alla fasi di Analisi dei Requisiti, Progettazione ed Implementazione. Prima dovevo pormi domande di questo tipo: Com è possibile implementar re questa funzionalità? Come posso indurre l utente a compiere queste azioni? Ora le domande diventano: Cosa può generare un errore e in questa funzionalità? Cosa accade se l utente compie queste azioni? Alessandro Tomasi 7

8 Indicatori chiave An nalisi Dinamica - Quantità dei test effettuati - Copertura del codice da testare Alessandro Tomasi 8

9 Elementi chiave Ana alisi Dinamica - Analisi Funzionale (Black Box) - Analisi Strutturale (White Box) Alessandro Tomasi 9

10 Analisi Funzionale (Black Box) considera la Quantità dei test effettuati Analisi Strutturale (W White Box) considera la Copertura del codice da testare Alessandro Tomasi 10

11 Fase di Testing Analisi Statica Analisi Dinamica Analisi Funzionale Analisi Strutturale (Black Box) (White Box) Alessandro Tomasi 11

12 Analisi Funzionale (Black Box) SCOPO: sottoporre il software ad una serie di casi di test per verificare i requisiti richiesti (dato un requisito si possono avere 1..n casi di test) CARATTERISTICHE: o o il codice non viene considerato verifica sul campo dei requ isiti richiesti Alessandro Tomasi 12

13 Analisi Funzionale (Black Box) DERIVABLE: per ogni caso di test l analisi de eve riportare: o descrizione caso di test o dati di input utlizzati per il test o eventuali precondizioni neces ssarie a questo test o eventuali dipendenze con altri casi di test o risultato atteso o risultato riscontrato o nel caso di risultato riscontrato diverso da quello atteso, descrizione dell anomalie che ha prodotto il malfunzionamento. Alessandro Tomasi 13

14 Impatto sull indicatore: ottimo indicatore se risultato riscontrato atteso sempre uguale a quello Ma non basta: è necessario garantire un adeguato set di casi di test (più casi di test per ogni requisito ) Alessandro Tomasi 14

15 Analisi Strutturale (White Box) SCOPO: software sottoposto ad una serie di casi di test al fine di eseguire la maggior quantità possibile di righe di codice CARATTERISTICHE: o o o il codice è considerato garantisce la correttezza del software anche in casi estremi individua id eventuali parti del codice non utilizzate t Alessandro Tomasi 15

16 Analisi Strutturale (White Box) DERIVABLE: la copertura di almeno il 90% del codice utilizzando un opportuna serie di casi di test Alessandro Tomasi 16

17 Impatto sull indicatore di copertura del codice: più è alta la percentuale di codice coperta più l indicatore sarà ottimale Alessandro Tomasi 17

18 Definizione dei Cas i di Test Per ogni requisito si individuano alcuni casi di test. In particolare: o o o almeno un caso di test con il requisito rispettato almeno un caso di test con il requisito non rispettato almeno un caso di test in situazioni di frontiera Ognuno di questi casi di test sarà caratterizzato da particolari dati di input del software da testare Alessandro Tomasi 18

19 Casi di Test associ iati ad un requisito Requisito: Il software da sviluppare deve e as ssegnare e un account (nome utente a password) agli utenti che ne facciano richiesta. Casi di Test: - richiesta di un account in modoo corretto - richiesta di un account non specificando il nome utente - richiesta di un account inserendo un nome utente già presente - richiesta di un account specificando una password che non rispetta le politiche di sicurezza Sono questi Casi di Test (quelli di frontiera) che fanno la differenza Alessandro Tomasi 19

20 Analisi i strutturale tt e funzional le sono da farsi ovviamente dopo la fase di sviluppo del codice ma la definizione i i dei Casi di Test viene fatta nella fase di Analisi dei Requisiti! Alessandro Tomasi 20

21 NOTE: Introduzion - non sarete voi ad eseguire questo caso di test - chi legge il caso di test devee essere in grado di sapere cosa fare e sapere cosa aspettarsi, senza conoscere nel dettaglio l'applicazione - chi legge il caso di test devee anche saper valutare se il risultato t ottenuto t e' corretto o meno Alessandro Tomasi 21

22 Esempio di tabella di casi di test: Numero Descrizione Test Test Data Precondizion ni Dipendenze Risultato Atteso Risultato Note: Test Case Case riscontrato 1 Creazione di <username> <username> --- Viene creata un account in modo non vuota l account corretto <password> rispettosa mai inserita prima nel sistema specificato. Il sistema risponde delle politiche di sicurezza con <messaggio_ok> 1.1 Creazione di <username> <username> Questo caso di Viene mostrato un un account già inserita nel già inserita nel test deve messaggio di errore specificando ca uno username già esistente 2 Creazione di un account non specificando lo username sistema sste sistema sste <username> Vuota 3 Creazione di account <password> --- violando le politiche di non rispettosa sicurezza (password banale, conferma delle politiche di sicurezza password errata, ) --- essere e fatto dopo il caso di testo numero 1 specificando la stessa <username> <messaggio errore_user_exists>, l account non viene creata ed il sistema mostra alcuni username disponibili da utilizzare --- Viene mostrato <messaggio errore_emptyuser> e l account non viene creato --- Viene mostrato un messaggio di errore e l account non viene creata Alessandro Tomasi 22

23 Esercizio: Individuare una serie di possibili casi di test per il progetto. Inserire, in un apposita tabella a, la descrizione di tali casi di test corredata da tutte le informazioni necessarie per l esecuzione di questo caso di test. Alessandro Tomasi 23