Software testing

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!


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)

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

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

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


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


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


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

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

Software Testing – Tecniche – Test Dinamico

White-Box Testing

Copertura delle istruzioni

Copertura delle decisioni

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


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



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


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



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



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


Diagramma degli stati

Conto Attivo Conto

Coperto Conto

Scoperto

Deposito Prelievo

Conto NON

Attivo

Prelievo [Prelievi disponibili > 0 & Saldo Conto > -500 €]

Prelievo

Saldo ≤ -500 €

TC1= 1 – A – 2 – C – 3 – D – 4

1 2 3

4

A

B

C

D Deposito

E

TC2= 1 – A – 2 – B – 2 – B – 2


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


Albero delle Transizioni

TC1= 1 – A – 2 – C – 3 – D – 4

TC2= 1 – A – 2 – B – 2 – B – 2

1

A

2

B

2

B

2

C

3

D

4


Use Cases

I Test Cases sono ricavati dagli Use Cases dell’analisi

Test Cases business oriented

Particolarmente utili per il test d’integrazione

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


Grafo del Flusso di Controllo

TC= A – B – F – G – H – D – E IF

IF

DO

WHILE

END IF

END IF

A

L

E

C

B

F

G

H

I

D


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

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

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

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

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

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à

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


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


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)


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)


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


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


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

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

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

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

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

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

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)

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

Contatti

Via Chiomonte, 26 – 10141 – Torino www.ixmasoft.it 0039.011.04.37.746 [email protected]

Documents

Software testing