Caso di test
In ingegneria del software, un caso di test è un insieme di condizioni o variabili sotto le quali un tester determina se una applicazione o sistema software risponde correttamente o meno. Il meccanismo per determinare se un programma software o un sistema ha superato un test è conosciuto come oracolo di test.
Casi di test formali[modifica | modifica wikitesto]
Allo scopo di provare in maniera esaustiva che tutti i requisiti di una applicazione software siano soddisfatti, si devono predisporre almeno due casi di test per ciascun requisito: un test positivo ed uno negativo. Se un requisito prevede sotto-requisiti, ciascun sotto-requisito deve avere almeno due casi di test. La tracciabilità tra il requisito e i relativi test è ottenuta grazie alla matrice di tracciabilità. I documenti dei casi di test devono includere una descrizione della funzionalità oggetto di test e la preparazione alla esecuzione del test.
Un documento di caso di test è caratterizzata da un input (fornito) e da un output atteso, specificati prima dell'esecuzione del test. L'input fornito deve testare una precondizione mentre l'output atteso una postcondizione.
Casi di test informali[modifica | modifica wikitesto]
Per applicazioni o sistemi sprovvisti di formali requisiti, i documenti di casi di test possono basarsi sulle normali operazioni accettate dei programmi.
In uno scenario di test, vengono usate storie ipotetiche per aiutare il tester a pensare attraverso un problema o un sistema complesso. Di solito, questi scenari non sono scritti in dettaglio. Possono essere semplici come un diagramma o possono essere una descrizione scritta in linguaggio naturale. Lo scenario di test ideale è una storia motivata, credibile, complessa e semplice da valutare.
Formato tipico di un caso di test[modifica | modifica wikitesto]
Un caso di test rappresenta un singolo passo, o alle volte una sequenza di passi, per testare la correttezza del comportamento e/o delle funzionalità, che sono peculiarità di una applicazione software. Di solito viene fornito un risultato o comportamento atteso.
Le informazioni aggiuntive che un caso di test può comprendere riguardano:
- ID caso di test
- Descrizione del caso di test
- passo di test o numero di ordine di esecuzione
- requisito(i) correlati
- profondità
- categoria del test
- autore
- check box per indicare se il test può essere automatizzato e se è stato automatizzato
- Risultato atteso e risultato riscontrato.
- Campi addizionali che possono essere inclusi e completati a valle dell'esecuzione del test:
- superato o fallito
- commenti
Casi di test complessi possono anche contenere la descrizione delle precondizioni e delle postcondizioni. Un caso di test deve prevedere un campo in cui verrà riportato il risultato riscontrato a seguito dell'esecuzione.
Questi passi possono essere registrati in un documento di testo, foglio di calcolo, database o in altri formati.
Quando memorizzati in un database, è possibile visualizzare i risultati di test passati e chi ha generato tali risultati, oltre alla configurazione di sistema utilizzata per produrli. Queste informazioni vengono solitamente memorizzate in tabelle differenti.
Le Test suites solitamente contengono
- Un sommario dei test
- La configurazione testata
Oltre alla descrizione della funzionalità da testare ed ai requisiti da preparare per assicurare che il test possa essere condotto, la parte che richiede un maggiore investimento di tempo nella redazione di un test case è la creazione dei test e la loro modifica in caso di cambi nel sistema.
In particolari circostanze è necessario eseguire un test, produrne i risultati ed avere un team di esperti che valuti questi ultimi per determinare se il test è fallito o passato. Questo succede spesso nella valutazione delle performance di un nuovo prodotto. Il primo test viene quindi utilizzato come base per i test seguenti e per valutare i cicli di rilascio successivi del prodotto.
I test di acceptance, che usano una versione modificata dei test case, sono solitamente eseguiti da un gruppo di utenti o clienti del sistema per assicurare che lo sviluppo corrisponda ai requisiti specificati od al contratto. I test di acceptance si differenziano per l'inclusione degli happy path o dei test positivi e la quasi completa esclusione di test case negativi.
Collegamenti esterni[modifica | modifica wikitesto]
- Writing Software Security Test Cases - Putting security test cases into your test plan by Robert Auger
- How to write test cases Archiviato il 26 luglio 2012 in Internet Archive. by Oan Bota
- Software Test Case Engineering By Ajay Bhagwat
