2. Software Quality Assurance & Control
SQA - Insieme di procedure per assicurare che i processi, metodologie e
standard siano appropriate e correttamente implementate per lo
sviluppo di un prodotto sw
Orientato al Processo
SQC - Insieme di procedure per assicurare che un prodotto sw raggiunga i
propri obiettivi di qualità
Orientato al Prodotto
Software Testing - Principale attività di SQC
Il Testing non assicura la qualità…la controlla!
3. Software Quality Assurance & Control
SQA
Modello di sviluppo (es: Waterfall)
• Raccolta dei requisiti completata Analisi Funzionale Sviluppo
Standard
• ISO 9001
SQC
Requisiti Funzionali
Requisiti NON-Funzionali
Verifica - Corretto funzionamento (Requisiti di Sistema)
Validazione - Corretta implementazione (Requisiti Utente)
4. Software Testing
Indagine condotta per fornire le informazioni relative alla
qualità del sistema sotto esame.
Misura della qualità in termini di numero di difetti rilevati
Rilevando difetti si aumenta la qualità del sistema in seguito alla loro
correzione
L’obiettivo del Testing è rilevare il maggior numero di difetti
5. Software Testing
Il Testing prova la presenza di difetti, non l’assenza
Anche se nessun difetto viene trovato questa non è una prova di correttezza
Il Testing esaustivo non è possibile
Effort troppo elevato per provare tutti i possibili input
Anticipare il Testing il prima possibile
Per abbassare i costi di risoluzione e l’effort di Test successivo
Il Testing dipende dai contesti
Sistemi safe-critical vs E-Commerce
Il Testing non è Debugging
Fallimento vs Causa
6. Software Testing – Tecniche – Test Statico
Test Statico
Basato sulla revisione (esame manuale) della documentazione e sull’analisi
statica (esame automatico) del codice
Un difetto nell’analisi inevitabilmente si ritrova nel software
Mancanze nei requisiti
Si approfondisce la conoscenza del business anticipando il test design
L’obiettivo è trovare anomalie e non fallimenti
Revisione (review)
Revisione Informale
Walkthrough
Revisione Tecnica
Ispezione
7. Software Testing – Tecniche – Test Statico
Revisione Informale
Propedeutica ad una revisione tecnica o walkthrough
Solitamente svolta in coppia (peer)
Documentazione opzionale
Obiettivo: confronto
Walkthrough
Condotta dall’autore
Peer Group
Solitamente documentata se svolta in sessioni
E’ necessaria preparazione dei partecipanti (revisione informale)
Obiettivo: acquisizione di informazione e rilevamento anomalie
8. Software Testing – Tecniche – Test Statico
Revisione Tecnica
Condotta da un moderatore
Peer Group ed esperti tecnici
Documentata, metodi ben definiti
Obiettivo: decisioni, rilevamento di anomalie, aderenza a standard e processi
Ispezione
Condotta da un moderatore
Peer examination e ruoli ben definiti
Documentata, follow-up, checklist con I/U
Obiettivo: rilevare anomalie
9. Software Testing – Tecniche – Test Statico
Analisi Statica
Utilizzo di strumenti (compilatori, control & data flow check)
Uso di metriche rilevazione di elevata misura di complessità
Rilevazione di codice morto, cicli infiniti, dipendenze e inconsistenze
Identificazione di anomalie non facilmente rilevabili con il test dinamico
10. Software Testing – Tecniche – Test Dinamico
Test Dinamico
Basato sull’esecuzione del codice
Vengono rilevati i fallimenti, e cioè esiti negativi (effetti di un anomalia)
Test Funzionale e Non-Funzionale
Black-Box Testing
Partizionamento in classi di equivalenza
Analisi ai valori limite
Tabelle delle decisioni
Diagrammi di transizioni tra stati
Use Cases
11. Software Testing – Tecniche – Test Dinamico
White-Box Testing
Copertura delle istruzioni
Copertura delle decisioni
12. Software Testing – Tecniche – Black-Box
Partizionamento in classi di equivalenza
Viene partizionato il dominio di input: classi valide e non valide
Un Test Case per ogni classe
Si associano due classi (valida-non valida) per ogni condizione di input
Es: Funzione il cui dominio di input siano i mesi dell’anno
... -2 -1 0 1 .............. 12 13 14 15 .....
-------------|-------------------|---------------------
Partizione NON Valida 1 Partizione Valida Partizione NON Valida 2
EC1= 1 ≤ N ≤ 12 Rappresentante: 6
EC2= N < 1 Rappresentante: -3
EC3= N > 12 Rappresentante: 16
13. Software Testing – Tecniche – Black-Box
Analisi ai valori limite
Complementare al metodo precedente
Tiene in considerazione il comportamento ai margini delle classi di
equivalenza
Solitamente vengono trovati più difetti utilizzando i valori limite
(massimo e minimo) di una partizione
EC1= 1 ≤ N ≤ 12 --- EC3= N > 12 ● Valori limite: 12, 13
14. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 4 5 6 7 8
Conto attivo Y Y Y Y N N N N
Conto coperto Y Y N N Y Y N N
Prelievi disponibili Y N Y N Y N Y N
Azioni
Consentire il Prelievo Y N N N N N N N
Trattenere Carta N N Y Y Y Y Y Y
Inviare Comunicazione N N Y Y N N N N
15. Software Testing – Tecniche – Black-Box
Ogni colonna della tabella rappresenta un Caso di Test (2n, n= # condizioni)
Alcuni Casi di Test sono privi di senso:
Conto non attivo & Conto coperto
Conto non attivo & Conto non coperto & Prelievi disponibili
Se il valore di particolari condizioni non incide sulle azioni, relative colonne
possono essere rimosse
Solitamente sono colonne vicine
Le azioni sono le stesse
Si tiene una colonna come rappresentante e si sostituisce il valore delle
condizioni diverse con ‘ – ‘ per indicare che il loro valore è ininfluente
Si continua a rimuovere colonne finchè non ci sono colonne con le stesse
azioni o se la rimozione di una colonna comporta l’eliminazione di una
distinzione importante
16. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 4 5 6 7 8
Conto attivo Y Y Y Y N N N N
Conto coperto Y Y N N Y Y N N
Prelievi disponibili Y N Y N Y N Y N
Azioni
Consentire il Prelievo Y N N N N N N N
Trattenere Carta N N Y Y Y Y Y Y
Inviare Comunicazione N N Y Y N N N N
17. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 5
Conto attivo Y Y Y N
Conto coperto Y Y N -
Prelievi disponibili Y N Y -
Azioni
Consentire il Prelievo Y N N N
Trattenere Carta N N Y Y
Disattiva Conto N N Y N
18. Software Testing – Tecniche – Black-Box
Diagramma degli stati B
Prelievo [Prelievi disponibili > 0 & Saldo Conto > -500 €]
1 A 2 3
Deposito Conto Prelievo Conto
Conto Attivo
Coperto Saldo ≤ -500 € Scoperto
C
D
Deposito Prelievo
TC1= 1 – A – 2 – C – 3 – D – 4 E
TC2= 1 – A – 2 – B – 2 – B – 2 4
Conto
NON
Attivo
19. Software Testing – Tecniche – Black-Box
Diagrammi delle transizioni tra stati
Gli output non sono influenzati solo dagli input ma da eventi
Stato iniziale Stati intermedi Stato finale
Eventi occorsi nel tempo (storia) influenza il comportamento dell’oggetto
di test
Object-oriented
Diagramma degli stati, macchina a stati finiti, tabelle di transizioni degli
stati
20. Software Testing – Tecniche – Black-Box
Albero delle Transizioni
1
TC1= 1 – A – 2 – C – 3 – D – 4
A
TC2= 1 – A – 2 – B – 2 – B – 2
2
B C
2 3
B D
2 4
21. Software Testing – Tecniche – Black-Box
Use Cases
I Test Cases sono ricavati dagli Use Cases dell’analisi
Test Cases business oriented
Particolarmente utili per il test d’integrazione
22. Software Testing – Tecniche – White-Box
Copertura delle istruzioni
Si valuta la % di istruzioni eseguite da una famiglia di test (Test Suite)
L’obiettivo è aumentare la copertura delle istruzioni
# istruzioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di istruzioni eseguibili
Particolarmente utili per il test d’integrazione
Si traduce il codice sorgente in un grafo del flusso di controllo
Nodi = Istruzioni non divisibili
Archi = flusso di controllo
23. Software Testing – Tecniche – White-Box
Grafo del Flusso di Controllo
A
B
TC= A – B – F – G – H – D – E IF
F
IF
DO C
L
G I
WHILE
H
END IF
END IF
D
E
24. Software Testing – Tecniche – White-Box
Copertura delle decisioni (branch coverage)
Si valuta la % di decisioni eseguite da una famiglia di test (Test Suite)
L’obiettivo è aumentare la copertura delle decisioni
# decisioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di decisioni
eseguibili
E’ una forma di testing del flusso di controllo, ma ogni decisione deve
essere eseguita con entrambi i possibili risultati (Vero/Falso)
La copertura del 100% delle decisioni La copertura del 100% delle
istruzioni
Ma non il contrario
25. Software Testing – Tecniche – Test Espolorativo
Test Espolorativo (Exploratory Testing)
Basato sull’esperienza/intuizione dei testers
Partecipazione cognitiva
Usato in unione alle altre tecniche per rafforzarle
Error guessing
Utile quando la documentazione è povera e le tempistiche ristrette
26. Software Testing – Tipologie – Test Funzionale
Test Funzionale
Si verifica il comportamento del sistema in termini di funzionalità:
Idoneità
Correttezza
Interoperabilità
Verifica il software testandolo rispetto a :
Specifica dei requisiti
Specifica Funzionale
Use-Cases
27. Software Testing – Tipologie – Test Funzionale
I Test Cases vengono disegnati applicando tecniche di tipo Black-Box:
Equivalent class partitioning
Boundary Value Analysis
Error Guessing
Può essere applicato a tutti i livelli di test:
Test di Modulo
• Test Funzionale basato sui requisiti (Requirements-based testing)
Test d’Integrazione
• Test Funzionale basato sui processi business
28. Software Testing – Tipologie – Test NON Funzionale
Test NON Funzionale
Si verificano attributi non funzionali, quali:
Affidabilità
Efficienza
Usabilità
Manutenibilità
Portabilità
Compatibilità
Per verificare le caratteristiche non funzionali di un sistema software è
utile riutilizzare i Test Cases disegnati per il test funzionale
Business Process Scenarios – I test funzionali servono per veicolare la
determinazione delle caratteristiche non funzionali
29. Software Testing – Tipologie – Test NON Funzionale
Performance, Load, Stress Test – Efficienza
Endurance Test – Affidabilità
Esecuzione di task predefiniti da parte di un focus group – Usabilità
Thinking –aloud
Interviste,
Questionari
Test della documentazione tecnica e della struttura del software –
Manutenibilità
Test di compatibilità per SO, browser, piattaforme differenti –
Compatibilità
30. Software Testing – Livelli
I livelli del Test
I livelli di test vengono identificati a seconda della fase del processo di
sviluppo software (e indipendentemente dal modello seguito):
Test di Modulo
Test di Integrazione
Test di Sistema
Test Confermativo
Test di Regressione
Test di Accettazione
31. Software Testing – Livelli
Test di Modulo
Verifica del corretto funzionamento di componenti testabili
separatamente
Possono essere applicate sia tecniche White che Black-Box
Unit Testing
Test di copertura (istruzioni/decisioni)
Test Funzionale di Modulo
Test non funzionali di performance (memory leaks, stored procedure
execution time)
Approccio automatico
Test Driven Development
Test il più esaustivo possibile
32. Software Testing – Livelli
Test di Integrazione
Verifica della corretta interazione tra moduli
E’ prioritaria l’interazione rispetto alle funzionalità implementate dai
singoli moduli
Due approcci principali:
Top-down – Vengono integrati per primi i moduli ad alto livello
Bottom-up – Vengono testati per primi i moduli di utilità
Umbrella – Test eseguiti secondo i percorsi funzionali dei dati e del flusso di
controllo (business process oriented)
33. Software Testing – Livelli
Test di Sistema
Verifica il corretto funzionamento dell’intero sistema software
L’ambiente di test deve corrispondere il più possibile a quello finale
Test Cases Business Process Oriented
A differenza degli altri livelli di test è fondamentale l’utilizzo di un team di
test indipendente
Unitamente al Test Confermativo e di Regressione, l’output deve essere la
versione che sarà sottoposta a Test di Accettazione (candidate release)
34. Software Testing – Livelli
Test Confermativo
Per ogni livello di test un certo numero di difetti viene rilevato, e questi
devono essere risolti dal team di sviluppo
Il Test Confermativo ha come obiettivo il test puntuale delle risoluzioni
Il bug fixing viene validato
Molto utili, in fasi avanzate del processo di sviluppo, strumenti che consentono
un fast-forwarding
E’ molto importante tenere traccia della versione del software nella quale
le correzioni sono state validate
In caso di regressioni future è più semplice risalire alla causa
35. Software Testing – Livelli
Test di Regressione
E’ inevitabile che introducendo nuove funzionalità o apportando
correzioni (nuovi sviluppi) vengano introdotte regressioni su funzionalità
positivamente testate in precedenza
L’obiettivo è verificare che il software non sia regredito a fronte di nuovi
sviluppi
Vengono tipicamente esercitati Test Cases Business Process Oriented
Dovrebbe essere automatizzato
36. Software Testing – Livelli
Test di Accettazione
L’obiettivo è valutare il grado di maturità del sistema per approvarne il
rilascio ed utilizzo
Solitamente sotto la responsabilità del Cliente, Stakeholder, Key-User
L’obiettivo non deve essere la ricerca di difetti, ma valutare se il sitema
risponde ai requisiti espressi e se lo fa nel modo corretto/aspettato
37. Processo di Test
Il Processo di Test viene portato avanti in cinque fasi:
Pianificazione
Progettazione/Design
Implementazione
Esecuzione
Gestione delle Anomalie
Ogni fase deve essere ben documentata
Garantire la manutenibilità dei test
Consentire la massima sinergia tra i gruppi di lavoro
38. Processo di Test - Pianificazione
Pianificazione
Produce il Master (o Project) Test Plan Document
Definizione del sistema oggetto di test
Test Scope
Obiettivi del Test
Ruoli e Responsabilità
Assunzioni, vincoli e rischi
Glossario cn tutti i termini tecnici (SQC related) utilizzati
Strategia, metodologia e tecniche di test utilizzate
Strumenti di supporto utilizzati
Ambienti di Test
39. Processo di Test - Pianificazione
Configurazioni hardware e software
Criteri di Ingresso/Uscita del Piano di Test
La pianificazione in termini di date di inizio-fine e le risorse umane necessarie
40. Processo di Test - Progettazione
Progettazione
Creazione delle Famiglie di Test (Test Suites)
Collezione di Casi di Test (Test Cases)
Identificazione di tutti i requisiti e delle “storie” dell’utente (use cases)
Organizzazione gerarchica per area funzionale o cross-section
Creazione dei Casi di Test (Test Cases)
Costituiscono le specifiche di test
Per ogni use case deve esistere almeno un test case (m ↔ n)
Identificazione dei prerequisiti, dati necessari (setup), input, passi, risultato
aspettato
Definizione dei criteri di ingresso/uscita
41. Processo di Test - Implementazione
Implementazione
Si realizza ciò che è stato disegnato/progettato
L’output è costituito da una collezione di:
Test Suites
• Test Cases per l’esecuzione manuale
• Test Scripts per l’esecuzione automatica
Data sets
Configurazioni (scripts e/o documenti) - Riutilizzo
Launch Test Document
• Setup e dati necessari
• Ordine di esecuzione
42. Processo di Test - Esecuzione
Esecuzione
Le Test Suites e i Test Scripts preparati vengono eseguiti
Manualmente
In modo automatico con l’ausilio degli strumenti di supporto
Per ogni Test Case (manuale/automatico) viene preparato il rapporto di
esecuzione (Execution Report)
Stato di esecuzione (Passato, Fallito, Non Eseguito)
Data di esecuzione e Versione del software oggetto di test
Nome del Test Engineer che lo ha eseguito
Viene preparato il Rapporto dei Test (Test Report)
Viene preparato il Rapporto delle Anomalie (Anomalies Report)
43. Processo di Test – Gestione delle Anomalie
Gestione delle Anomalie
Procedura fondamentale per avere un’analisi affidabile e veloce dei difetti
rilevati durante l’esecuzione del test
Standard per il reporting dei difetti
Informazioni per una rapida ricerca e comprensione
Informazioni per la corretta riproducibilità
Classificazione dei difetti
Priorità
Severità
Ciclo di vita dei difetti
Stati dei difetti