Test dei casi d'uso con esempi

By: Tommaso Hamilton Tommaso Hamilton
Hours aggiornato

⚡ Riepilogo intelligente

Il test dei casi d'uso convalida le transazioni end-to-end simulando le interazioni tra un utente e il sistema. Questa tecnica guida i casi di test a livello di sistema e di accettazione, evidenzia le lacune di integrazione e integra i controlli a livello di unità con flussi di lavoro utente realistici.

  • 🎭 Rappresentazione chiara delle interazioni: Etichetta ogni flusso con l'attore (A) e il sistema (S) in modo che i tester possano trace ogni fase della transazione.
  • 🛤️ Descrivi prima il percorso più felice: Convalida lo scenario di successo principale, quindi aggiungi estensioni e percorsi di eccezione che rispecchino errori reali commessi dagli utenti.
  • 🧩 Anchor con alcune condizioni: Associa a ciascun passaggio precondizioni e postcondizioni esplicite, in modo che l'esito del test sia inequivocabile.
  • 🔗 Trace all'accettazione: Mappa i casi d'uso ai criteri di accettazione in modo che le parti interessate aziendali possano approvare la copertura al momento del rilascio.
  • 🤖 Utilizzare l'assistenza dell'intelligenza artificiale: Converti le user story in linguaggio semplice in bozze di casi d'uso, accelerando la progettazione dei test e riducendo le perdite di flusso.
Scopri di più

Test dei casi d'uso: esempio

Cos'è il test dei casi d'uso?

Usa il test dei casi Il test dei casi d'uso è una tecnica di test del software che identifica casi di test che coprono un intero sistema, transazione per transazione, dall'inizio alla fine. I casi di test descrivono le interazioni tra gli utenti e l'applicazione software. Il test dei casi d'uso rivela lacune che potrebbero non essere individuate testando i singoli componenti software in isolamento.

A caso d'uso Nel testing, una breve descrizione di un particolare utilizzo del software da parte di un attore o utente. I casi d'uso sono scritti a partire dalle azioni dell'utente e dalle corrispondenti risposte dell'applicazione e sono ampiamente utilizzati per derivare casi test a livello di sistema e di accettazione.

Componenti chiave di un caso d'uso

Ogni caso d'uso è costruito a partire dallo stesso insieme di elementi costitutivi. Conoscere i componenti in anticipo semplifica la progettazione di una copertura che si adatti perfettamente ai casi di test:

  • Attore: L'utente o il sistema esterno che avvia un'interazione. Rappresentato come "A" nei flussi testuali.
  • Sistema: Il software in fase di test che risponde all'attore. Rappresentato come “S”.
  • Prerequisiti: lo stato in cui deve trovarsi il sistema prima che il caso d'uso possa iniziare.
  • Scenario di successo principale: la sequenza ottimale dei passaggi dell'attore e del sistema.
  • Estensioni / flussi alternativi: rami che gestiscono eccezioni, errori di convalida o scelte alternative.
  • Post-condizioni: lo stato in cui si trova il sistema al termine del caso d'uso.

Come eseguire il test dei casi d'uso: esempio

In un caso d'uso, l'attore è rappresentato da "A" e il sistema da "S". L'esempio seguente descrive la funzionalità di accesso di un'applicazione web.

Test dei casi d'uso: esempio

Principale scenario di successo step Descrizione
A: Attore S: Sistema 1 A: Inserisci il nome dell'agente e la password
2 S: Convalida la password
3 S: Consenti l'accesso all'account
Estensioni 2a Password non valida   S: Visualizza il messaggio e chiedi di riprovare (fino a 4 volte)
2b Password non valida 4 volte   S: Chiudi l'applicazione

Il diagramma di flusso sopra descrive un percorso ideale e due possibili estensioni. Leggendolo passo dopo passo:

  • L'utente inserisce un indirizzo email e una password come primo passaggio del flusso di accesso completo.
  • Il sistema convalida la password.
  • Se la password è corretta, l'accesso viene consentito.
  • Se la password non è valida, il sistema visualizza un messaggio e consente fino a quattro tentativi di inserimento.
  • Se la password rimane non valida dopo quattro tentativi, il sistema blocca ulteriori tentativi (in questo esempio, bloccando l'indirizzo IP).

Partendo da questo caso d'uso, si dovrebbe testare lo scenario di successo più un caso per ciascuna estensione. Ciò si traduce in un minimo di tre casi di test: un accesso valido, una password non valida recuperabile e un blocco dopo ripetuti tentativi falliti.

ARTICOLI CORRELATI

Vantaggi del test dei casi d'uso

Il testing dei casi d'uso si inserisce naturalmente tra i requisiti e i casi di test. I principali vantaggi sono:

  • Copertura completa end-to-end: verifica le transazioni tra i moduli, non le singole funzioni.
  • Validazione incentrata sull'utente: Ciascuno scenario riflette il modo in cui un attore reale utilizza il sistema.
  • Trasparente traccapacità: I casi d'uso corrispondono direttamente ai criteri di accettazione per l'approvazione da parte delle parti interessate.
  • Prevenzione dei difetti: le lacune di integrazione delle superfici prima dell'inizio dei cicli di regressione.
  • Manufatti riutilizzabili: Lo stesso caso d'uso alimenta i casi di test, il materiale formativo e la documentazione per l'utente.

Limitazioni dei test sui casi d'uso

Questa tecnica è efficace ma non esaustiva. Si prega di tenere presente le seguenti limitazioni:

  • Non sostituisce i test unitari: I guasti ai componenti di basso livello necessitano comunque di test mirati.
  • Dipende da casi d'uso specifici: I flussi ambigui producono test ambigui.
  • Copertura limitata per funzioni non essenziali: Prestazioni, sicurezza e accessibilità richiedono tecniche specifiche.
  • Spese di manutenzione: I casi d'uso devono essere aggiornati quando cambiano le regole aziendali.

Domande Frequenti

Un caso d'uso descrive come un attore e il sistema interagiscono per raggiungere un obiettivo. Un caso di test verifica se il sistema si comporta effettivamente in quel modo. Un caso d'uso solitamente genera più casi di test.

I test dei casi d'uso sono più efficaci se applicati a livello di sistema e di accettazione, dopo i test unitari e di integrazione, quando l'obiettivo è convalidare flussi di lavoro utente completi piuttosto che singole funzioni.

L'attore "A" rappresenta l'utente o il sistema esterno che avvia l'interazione. Il sistema "S" rappresenta il software che risponde a tali azioni. La notazione mantiene i flussi compatti e leggibili.

Le estensioni sono flussi alternativi che gestiscono le eccezioni o si diramano dallo scenario principale di successo. Descrivono come il sistema reagisce quando un attore inserisce dati non validi, abbandona una fase o segue un percorso decisionale diverso.

Come minimo, è necessario un caso di test per lo scenario di successo principale, più uno per ogni estensione. Le varianti di confine, di equivalenza e negative possono aggiungerne altre, a seconda del profilo di rischio dell'applicazione.

No. I test sui casi d'uso convalidano i flussi di lavoro noti, mentre i test esplorativi fanno emergere difetti sconosciuti attraverso interazioni non predefinite. Le due tecniche si completano a vicenda e coprono diverse categorie di rischio.

Gli assistenti basati sull'intelligenza artificiale convertono le user story scritte in linguaggio naturale in casi d'uso strutturati, completi di attori, scenari di successo ed estensioni. Inoltre, segnalano la mancanza di flussi alternativi confrontando la bozza con i modelli tipici.

Sì. Gli strumenti di intelligenza artificiale leggono un caso d'uso e generano bozze di casi di test per il flusso principale e per ogni estensione, insieme a dati di esempio. Un tester esamina comunque l'output per confermare che le regole aziendali e le priorità di rischio siano corrette.

Riassumi questo post con: