Parlando di testing, accade spesso che non ci sia accordo sul significato delle parole. I termini usati nel campo della disciplina del testing sono tanti, e sono molte anche le possibilità di confusione.
Nel seguito, alcuni tra i termini più comuni, tratti da riferimenti autorevoli a livello internazionale:
- [Swebok 2004] – Software Engineering Body of Knowledge (SWEBOK), pubblicato dalla IEEE Computer Society
- [IEEE Std 829-1998] – Standard for Software Test Documentation
- [IEEE Stds Glossary] – Software Engineering Glossary – pubblicato da IEEE Software
- [Kaner Bach 2005] – Cem Kaner, James Bach: Black Box Software Testing – Fall 2005 – Overview for Students
Nota: in alcuni casi si è preferito utilizzare due definizioni per un singolo termine (es. test di integrazione), perché ciascuna ne mette in luce un aspetto in modo più chiaro. Le due definizioni vanno quindi intese come complementari, non come alternative.
Questo mini glossario è organizzato per macro argomenti, che contengono le voci individuali.
Poiché a volte vengono usati anche termini inglesi, tali termini sono riportati dopo quelli italiani.
- validazione
- verifica
- test unitari – unit test
- test di integrazione – integration test
- test di sistema – system test
Livello di effettuazione dei test:
- alpha test
- beta test
- test di accettazione – acceptance test
- test funzionali e non funzionali
- test di usabilità
- test prestazionale – performance test
- stress test
- test di installazione
- test a scatola nera – black box test
- test a scatola trasparente – glass box test
- test di regressione – regression test
Documenti tipici delle attività di test:
- piano di test
- specifiche di test
- report di test
Finalità del test
Validazione
Conferma (tramite esame e fornitura di evidenza oggettiva) che i requisiti particolari per uno specifico utilizzo sono stati soddisfatti. In progettazione e sviluppo, la validazione è il processo che esamina un prodotto per determinarne la conformità con le esigenze utente. [IEEE Stds Glossary]
Verifica
Conferma (tramite esame e fornitura di evidenza oggettiva) che i requisiti specificati sono stati soddisfatti.
In progettazione e sviluppo, la verifica è il processo che esamina il risultato di una attività per determinarne la conformità con i requisiti formulati per l’attività stessa. [IEEE Stds Glossary]
Oggetto dei test
Test unitari
Il testing di unità verifica il funzionamento isolato delle parti software che sono testabili separatamente. In funzione del contesto, le parti testate possono essere singoli moduli, oppure un componente di dimensioni maggiori, costituito da unità strettamente correlate tra loro. Tipicamente, il testing di unità viene effettuato con accesso al codice testato e con il supporto di strumenti per il debugging. [Swebok 2004]
Il testing a livello unitario è focalizzato su unità isolate del prodotto (moduli, classi, funzioni). [Kaner Bach 2005]
Test di integrazione
Il testing di integrazione è il processo di verifica dell’interazione tra componenti software. Le strategie classiche di test di integrazione, top-down o bottom-up, vengono utilizzate con il software tradizionale, strutturato in modo gerarchico. Le strategie moderne di integrazione sistematica sono invece guidate dall’architettura, cioè i componenti e sottosistemi software vengono integrati sulla base delle funzionalità identificate.
Il testing a livello di integrazione è un’attività continuativa. Tranne i casi di software molto piccoli e semplici, le strategie di test di integrazione sistematiche ed incrementali sono da preferire rispetto alla strategia di mettere tutti i componenti insieme nello stesso momento, in quello che viene chiamato “big bang” testing. [Swebok 2004]
I test di integrazione verificano come due (o più) unità lavorano insieme. [Kaner Bach 2005]
Test di sistema
Il testing a livello di sistema si preoccupa del comportamento di un sistema nel suo complesso. La maggior parte degli errori dovrebbe essere già stato identificato durante il testing unitario e di integrazione. Il test di sistema viene di solito considerato appropriato per verificare il sistema anche rispetto ai requisiti non funzionali, come quelli di sicurezza, velocità, accuratezza ed affidabilità. A questo livello vengono anche testate le interfacce esterne nei confronti di altre applicazioni, componenti standard, dispositivi hardware e ambiente operativo. [Swebok 2004]
Livello di effettuazione dei test
Alfa e Beta test
Prima che il software venga rilasciato, viene a volte reso disponibile per un utilizzo di prova ad un gruppo, limitato ma rappresentativo, di utenti potenziali. Ciò può accadere presso gli sviluppatori (alpha testing) o presso gli utilizzatori (beta testing). Gli utenti che partecipano al test segnalano i problemi riscontrati nell’utilizzo del prodotto. Alpha e beta test sono spesso svolti in modo poco controllato, e non vengono sempre esplicitati nel piano di test. [Swebok 2004]
Test di accettazione
Il testing di accettazione controlla il comportamento del sistema rispetto ai requisiti (comunque espressi) del committente. I clienti effettuano, o specificano, attività tipiche di uso del sistema, per controllare che i loro requisiti siano stati soddisfatti. Questa attività di test può coinvolgere o meno gli sviluppatori del sistema. [Swebok 2004]
Testing condotto in un ambiente operativo reale per determinare se un sistema soddisfa i propri criteri di accettazione (ad esempio i requisiti iniziali, e le attuali esigenze dei suoi utenti) e per permettere al cliente di determinare se accettare o meno il sistema [IEEE Stds Glossary]
Aspetti sottoposti a test
Test funzionali e non funzionali
Possono essere progettati dei casi di test per verificare che le specifiche funzionali siano state implementate correttamente. Queste tipologie di test sono chiamate in letteratura test di conformità, o test di correttezza, o test funzionale. In ogni caso, possono essere testate anche numerose altre proprietà non funzionali, tra cui le prestazioni, l’affidabilità e l’usabilità. [Swebok 2004]
Il test funzionale è un tipo di test comportamentale (cioè focalizzato sul comportamento osservabile del prodotto) che guarda al sistema come ad una collezione di funzioni. Chi effettua i test funzionali potrebbe focalizzarsi esclusivamente sulla presenza e l’affidabilità delle funzioni, tralasciando le caratteristiche non funzionali, come usabilità, scalabilità, mantenibilità, velocità, sicurezza, adattabilità a condizioni locali, esigenze di supporto, eccetera. [Kaner Bach 2005]
Test di usabilità
Il test di usabilità valuta la facilità di uso e di apprendimento del software da parte degli utilizzatori finali. Vengono presi in considerazione la documentazione per l’utente, l’efficacia di funzionamento del software nel supportare le attività dell’utente, le possibilità che il software offre all’utente di porre rimedio ai propri errori. [Swebok 2004]
Test prestazionale
Il test prestazionale è specificamente effettuato per verificare che il software soddisfi i requisiti di prestazioni specificati, ad esempio i livelli di capacità di utilizzo ed i tempi di risposta. [Swebok 2004]
Test di stress
Lo stress test sollecita il software al livello massimo di carico progettato, ed oltre. [Swebok 2004]
Test di installazione
Il test di installazione consiste nella verifica dell’installazione del software nell’ambiente operativo di destinazione (effettuata di solito dopo la conclusione dei test di accettazione). Il test di installazione può essere visto come un test di sistema condotto in conformità con i requisiti di configurazione hardware. [Swebok 2004]
Modalità di test
Test a scatola nera
Il test è a scatola nera se ci si basa solo sul comportamento riscontrabile analizzando input ed output. [Swebok 2004]
Chi effettua test a scatola nera lavora senza conoscere il codice. Progetta il test a partire dalla specifica (se esiste) e dalla propria conoscenza dei bisogni e delle caratteristiche degli utenti del prodotto, del dominio in cui si opera, dell’ambiente hardware / software e di altri rischi. [Kaner Bach 2005]
Test a scatola bianca (o trasparente)
Il test è a scatola bianca (white-box) se si basa su informazioni relative a come il software è stato progettato o codificato. [Swebok 2004]
Chi effettua test a scatola trasparente (glass-box) lavora conoscendo il codice. Agisce come un programmatore, che diventa esperto nell’implementazione del prodotto testato o nell’implementazione delle relazioni del prodotto con il mondo esterno. [Kaner Bach 2005]
Test di regressione
Il test di regressione consiste nella riesecuzione selettiva di test su un sistema o un componente modificato, per verificare che le modifiche non abbiano provocato effetti indesiderati. In pratica, l’idea è di dimostrare che il software che aveva passato i test prima delle modifiche continua a farlo anche dopo.
Naturalmente è necessario un bilanciamento tra il livello di assicurazione fornito dall’esecuzione dei test di regressione per ogni singolo cambiamento ed il consumo di risorse necessario per eseguirla. Il test di regressione può essere effettuato ad ognuno dei livelli di test (unitario, di integrazione, di sistema), sia per gli aspetti funzionali che per quelli non funzionali. [Swebok 2004]
Documenti tipici delle attività di test
Piano di test
Un documento che descrive l’ambito, l’approccio, le risorse e la schedulazione delle attività di testing che si intendono effettuare. Identifica gli elementi da testare, le caratteristiche da verificare, le singole attività di testing, chi le deve svolgere, e tutti i rischi che richiedono verifiche specifiche. [IEEE 829-1998]
Specifiche di test
Comprendono [IEEE 829-1998]:
- Specifica di progettazione del test – Un documento che specifica i dettagli dell’approccio usato per testare una caratteristica software (o un insieme di caratteristiche), ed identifica i test ad essa associati
- Specifica del caso di test – Un documento che specifica input, risultati previsti, ed un insieme di condizioni di esecuzione per un elemento da testare
- Specifica di procedura di test – Un documento che specifica una sequenza di azioni per l’esecuzione di un test.
Rapporto di esecuzione dei test
Le attività di testing possono essere inserite in un log di test per identificare quando un test è stato eseguito, chi lo ha eseguito, quale configurazione software è stata usata per il test, ed altre informazioni rilevanti.
Risultati di test non previsti o scorretti possono essere registrati in un sistema di reporting dei problemi, i cui dati costituiscono la base per il successivo debugging e per la correzione dei problemi che erano stati riscontrati come errori durante il testing. Inoltre potrebbe essere utile registrare anche anomalie non classificabili come errori, nell’ipotesi che ad un successivo esame risultino più serie di quanto sembrava. I report di test sono anche input al processo di gestione delle richieste di cambiamento. [Swebok 2004]
Formazione sulle tecniche di analisi dei sistemi
I miei corsi di formazione: corsi.analisi-disegno.com