Analisi dei test e principi di base dei test
Tommaso Hamilton
⚡ Riepilogo intelligente
L'analisi dei test, detta anche base di test, è la revisione strutturata dei requisiti, dei documenti di progettazione e di altri artefatti utilizzati per derivare le condizioni di test. Questo articolo illustra le fonti, il flusso di lavoro passo passo e il posizionamento dell'analisi dei test nel modello V.
L'analisi dei test, nota anche come base di test, si trova proprio all'inizio del ciclo di vita dei test. Ogni condizione di test e caso di test in definitiva tracTorniamo all'argomento. Le sezioni seguenti definiscono il termine, ne spiegano le fonti, illustrano il flusso di lavoro dell'analisi e lo inseriscono nel modello V.
Che cos'è l'analisi dei test?
Analisi di prova Nel test del software, il processo consiste nel rivedere gli input utilizzati per derivare le condizioni di test e i casi di test. Questi input — specifiche, requisiti, documenti di progettazione, storie utente e deliverable simili — sono collettivamente chiamati artefatti di prova. L'obiettivo dell'analisi dei test è quello di esaminaretracobiettivi del test t abbastanza chiari da poter trasformare ciascuno di essi in una condizione di test non ambigua. Poiché il materiale analizzato costituisce la base da cui derivano tutti i test, è anche chiamato Base di prova.
Le fonti tipiche da cui i tester ricavano le informazioni sui test includono:
- SRS — Specifiche dei requisiti software
- BRS — Specifiche dei requisiti aziendali
- Documenti di progettazione funzionale
- Storie utente, criteri di accettazione e wireframe
I tester possono anche generare condizioni di test esplorando direttamente l'Applicazione sotto test o attingendo all'esperienza passata, ma la maggior parte casi test sono derivati da artefatti di test per mantenere tracabilità.
👉 Iscriviti al progetto di test software live gratuito
Perché è importante basarsi sui test?
La base di test è il fattore determinante per stabilire se una suite di test individua difetti reali o ne insegue inesistenti. Considerarla facoltativa è la causa più comune di bug sfuggiti che raggiungono l'ambiente di produzione. Un'analisi dei test accurata offre quattro vantaggi concreti:
- Traccapacità: Ogni caso di test può essere ricondotto a un requisito specifico, il che rende l'analisi dell'impatto delle modifiche rapida e le revisioni di audit indolori.
- Chiarezza della copertura: RevEsaminando le lacune della base, emergono stati di errore non specificati, casi limite mancanti, soglie non funzionali non definite, prima che si trasformino in incidenti di produzione.
- Allineamento delle parti interessate: Quando il team di test ricava le condizioni dagli stessi documenti su cui si basa il team di sviluppo, entrambe le parti condividono una definizione comune di "fatto".
- Rilevamento precoce dei difetti: Molti difetti dei requisiti (ambiguità, contraddizioni, criteri di accettazione mancanti) vengono individuati già durante l'analisi dei test, ben prima che venga scritto qualsiasi codice: è di gran lunga il modo più economico per correggerli.
Fonti comuni della base di test
Artefatti diversi alimentano livelli di test diversi. Utilizza la tabella seguente come riferimento rapido per decidere quale documento consultare durante la scrittura dei casi di test.
| Artefatto sorgente | Adatto a | Cosa ti succede?tract |
|---|---|---|
| Specifiche dei requisiti aziendali (BRS) | Test di accettazione e di sistema | Regole aziendali end-to-end, vincoli normativi, criteri di successo |
| Specifiche dei requisiti software (SRS) | Test di sistema | Requisiti funzionali e non funzionali con soglie misurabili |
| Documenti di progettazione funzionale/tecnica | Test d'integrazione | Interfacce dei moduli, flusso di dati, specifiche per la gestione degli errori |
| Storie utente e criteri di accettazione | Test di sprint Agile | Aspettative comportamentali nella forma “Dato-Quando-Allora” |
| Wireframe e mockup dell'interfaccia utente | Test di usabilità dell'interfaccia utente | Layout, navigazione, regole di convalida dell'input |
| Applicazione in fase di test (esplorativa) | Test esplorativi e di regressione | Comportamenti non documentati, flussi di lavoro reali, casi limite |
Come eseguire un'analisi dei test passo dopo passo
Un'analisi dei test efficace segue un flusso di lavoro ripetibile in cinque fasi, indipendentemente dalle dimensioni del progetto o dalla metodologia utilizzata.
- Raccogliere e inventariare la base di test. Raccogli ogni artefatto che descrive il comportamento previsto: SRS, BRS, documenti di progettazione, user story, mockup. Annota quale documento possiede ogni requisito in modo tracla funzionalità rimane intatta.
- Revvista per la testabilità. Leggete ogni artefatto tenendo a mente tre domande: Questa affermazione è misurabile? È inequivocabile? È completa? Segnalate qualsiasi requisito che non superi una di queste verifiche e riportatelo all'autore prima di scrivere i test relativi ad esso.
- Identificare le condizioni di prova. Per ogni affermazione verificabile, elenca le condizioni che necessitano di verifica (percorsi positivi, percorsi negativi, valori limite, gestione degli errori, sicurezza, prestazioni). Una condizione di test è l'assolutatract “cosa” — ad esempio, “Il sistema rifiuta gli ordini con quantità pari a zero” — distinto dal "come" concreto di un caso di test.
- Assegnare priorità e raggruppare le condizioni. Classifica ogni condizione in base al rischio e alla frequenza di utilizzo. Le condizioni ad alto rischio e ad alta frequenza richiedono una copertura dettagliata; le condizioni a basso rischio possono essere raggruppate o campionate. In questa fase si decide anche quali condizioni sono idonee all'automazione.
- Convertire le condizioni in casi di test. Ogni condizione prioritaria diventa una o più casi test con prerequisiti, passaggi, dati di test e risultati attesi. Mantenere un requisito tracMatrice di fattibilità che collega ogni caso di test al requisito originario.
Seguendo questa sequenza si evitano gli errori più comuni nell'analisi dei test: scrivere casi di test senza una base chiara, trascurare scenari negativi e produrre test che non possono essere ricondotti a un requisito durante la fase di analisi dei difetti.
Analisi dei test nel modello V
Il modello V associa a ogni attività di sviluppo una corrispondente attività di test. L'analisi dei test avviene a ogni livello utilizzando la documentazione disponibile in quel preciso momento del ciclo di vita.
Figura 1: Analisi dei test attraverso le fasi del Modello a V.
Caso di studio: derivazione di casi di test da un requisito del cliente
Consideriamo uno scenario in cui il cliente invia la seguente richiesta, espressa in una sola riga.
Client requirement: Add search functionality to an eCommerce Store
Anche se l'applicazione non è ancora stata realizzata, un tester può già ricavare diverse condizioni di test analizzando ciò che il requisito implica, sia il comportamento ottimale che le modalità di errore non specificate esplicitamente dal cliente. Alcuni esempi includono:
- Verifica il risultato della ricerca quando non viene inserita alcuna parola chiave.
- Verifica il risultato della ricerca se non esiste alcun prodotto corrispondente alla parola chiave inserita.
- Verifica il risultato della ricerca quando sono presenti più prodotti corrispondenti alla parola chiave.
- Verifica il comportamento con caratteri speciali, spazi iniziali/finali e input molto lunghi.
- Verificare la distinzione tra maiuscole e minuscole e il comportamento in caso di corrispondenza parziale.
- Verificare il tempo di risposta della ricerca in condizioni di carico utenti previsto.
Il tester prende i requisiti del cliente (la base di test), li analizza e li converte in condizioni di test. Questo schema si ripete in ogni fase del modello V: i piani di test e i casi di test vengono creati utilizzando il documento disponibile in quel momento del ciclo di vita.
Video: L'analisi dei test spiegata
Se il video non si carica, visualizzalo direttamente su YouTube.
