Reading Time: 10 minutes

Come scrivere casi di test potrebbe non sembrare una parte così importante dello sviluppo. Ma al fine di un tester software per svolgere al meglio il loro lavoro, hanno bisogno di una serie cristallina di passi da seguire e una chiara definizione di ciò che viene testato.

Tutti, dalla NASA e GE alle aziende di livello enterprise, possono beneficiare dei team che operano al meglio. Scrivere casi di test eccellenti è solo un altro modo per migliorare l’efficienza e l’efficacia del team e Parasoft si occupa di responsabilizzare i team a fare proprio questo.

In questo blog, copriamo i seguenti argomenti relativi a come scrivere un caso di test:

1. Che cosa è un caso di prova?
2. Test script vs. test case
3. Diversi tipi di test case
4. Come scrivere software test case
5. Formato standard test case
6. Test case writing best practice
7. Test suite vs. piano di test
8. Test case strumenti di scrittura

Che cos’è un test Case nel software?

Un caso di test è esattamente quello che sembra: uno scenario di test che misura la funzionalità in un insieme di azioni o condizioni per verificare il risultato atteso. Si applicano a qualsiasi applicazione software, possono utilizzare test manuali o un test automatico e possono utilizzare strumenti di gestione dei casi di test.

Una cosa fondamentale da ricordare quando si tratta di scrivere casi di test è che sono destinati a testare una variabile o un’attività di base come se un codice sconto si applichi o meno al prodotto giusto su una pagina Web di e-commerce. Ciò consente a un tester software una maggiore flessibilità nel modo di testare il codice e le funzionalità.

Script di test vs Test Case

Anche la differenza tra test case e script di test dovrebbe essere chiarita. Uno script di test è un breve programma pensato per testare determinate funzionalità. Un caso di test è un documento con passaggi da completare come pianificato in anticipo.

Considera i casi di test come un viaggio meticolosamente pianificato e script di test per essere più simile a un rapido viaggio al negozio di alimentari.

Diversi tipi di test Case

I test case possono misurare molti aspetti diversi del codice. I passaggi coinvolti possono anche essere destinati a indurre un risultato negativo in contrapposizione a un risultato atteso positivo, ad esempio quando un utente immette la password errata su una schermata di accesso.

Alcuni esempi comuni di test case sarebbero i seguenti:

I casi di test possono essere applicati a qualsiasi numero di funzionalità presenti in un dato software. Alcuni degli esempi più popolari includono:

• API testing-Vederlo in azione.
• Test dell’interfaccia utente-Vederlo in azione.
• Unit testing-Vederlo in azione.
• Carico & test delle prestazioni-Vederlo in azione.
• Test di sicurezza
• Query SQL
• Test delle applicazioni a basso codice

Un esempio di test case popolare

I test case sono utili in una varietà di scenari software. Tutto, dal settore bancario al software personale richiede un’applicazione test case. Ad esempio, se l’obiettivo è avere dati sensibili crittografati, il software deve disporre di funzionalità che funzionino come previsto.

Ma il test funzionale è solo un aspetto della scrittura di un test case. I test del software dovrebbero sfidare in modo robusto ogni aspetto del codice, dalle prestazioni alla compatibilità alla sicurezza. Ecco perché il software di crittografia personale deve essere testato in modo così approfondito, soprattutto quando si tratta di cose come le API Web.

Come scrivere casi di test software

La scrittura di casi di test varia a seconda di ciò che il caso di test sta misurando o testando. Questa è anche una situazione in cui la condivisione delle risorse di test tra i team di sviluppo e di test può accelerare i test del software. Ma tutto inizia con il saper scrivere un caso di test in modo efficace ed efficiente.

I casi di test hanno alcune parti integrali che dovrebbero essere sempre presenti nei campi. Tuttavia, ogni caso di test può essere suddiviso in 8 passaggi di base.

Passaggio 1: Test Case ID

I test case devono contenere ID univoci per rappresentarli. Nella maggior parte dei casi, seguire una convenzione per questo ID di denominazione aiuta con l’organizzazione, la chiarezza e la comprensione.

Fase 2: Descrizione del test

Questa descrizione dovrebbe descrivere in dettaglio l’unità, la funzione o la funzione in fase di test o ciò che viene verificato.

Fase 3: Ipotesi e pre-condizioni

Ciò comporta qualsiasi condizione da soddisfare prima dell’esecuzione del test case. Un esempio potrebbe richiedere un account Outlook valido per un accesso.

Passaggio 4: Dati di test

Ciò si riferisce alle variabili e ai loro valori nel caso di test. Nell’esempio di un login e-mail, sarebbe il nome utente e la password per l’account.

Punto 5: Passaggi da eseguire

Questi dovrebbero essere passaggi facilmente ripetibili come eseguiti dal punto di vista dell’utente finale. Ad esempio, un caso di test per l’accesso a un server di posta elettronica potrebbe includere questi passaggi:

1. Aprire la pagina web del server di posta elettronica.
2. Inserisci nome utente.
3. Inserire la password.
4. Fare clic sul pulsante “Invio” o “Login”.

Passaggio 6: Risultato atteso

Indica il risultato atteso dopo l’esecuzione della fase del test case. Dopo aver inserito le informazioni di accesso corrette, il risultato previsto sarebbe un accesso riuscito.

Punto 7: Risultato effettivo e post-condizioni

Rispetto al risultato atteso, possiamo determinare lo stato del test case. Nel caso del login e-mail, l’utente avrebbe effettuato l’accesso con successo o meno. La post-condizione è ciò che accade come risultato dell’esecuzione del passo, ad esempio il reindirizzamento alla casella di posta elettronica.

Passo 8: Pass/Fail

Determinare lo stato pass/fail dipende da come il risultato atteso e il risultato effettivo si confrontano tra loro.

Stesso risultato = Passaggio
Risultati diversi = Errore

Standard Unit Test Case Format

Ogni parte di un test unitario ben scritto definirà diversi aspetti fondamentali, tra cui:

1. Funzioni svolte dai test
2. Dati utilizzati nel test
3. risultato Previsto dall’esecuzione del test
4. Assicurare il test è stato eseguito in isolamento da altre parti del codice

e ‘ importante sapere che il formato standard di ben prove scritte si compone delle seguenti parti:

• test Significativi nome del metodo
• dati Controllati o deride per essere utilizzato per il testing
• Metodo o l’unità in prova (la parte di codice che stiamo testando)
• Applicazione di un’asserzione
• l’Esecuzione di test di unità in isolamento

C’È un Caso di Test Modello?

Come accennato, esiste un formato standard di test case. Tuttavia, il modello di test case potrebbe variare da azienda a azienda e persino da squadra a squadra. Invece, un modello di test case è il documento con un elenco di scenari di test e casi di test successivi.

Esempio di test di qualità

Anche se i casi di test variano in base al tipo di test e al campo generale di test, la costruzione di un test di qualità si riduce a quei pochi elementi affidabili sopra. Ricordare: il nome del metodo di prova deve includere il metodo o l’unità in prova e qual è il risultato atteso.

Va anche notato che ogni unità deve essere testata isolatamente. In questo caso, “isolamento” significa mantenere i test concentrati il più possibile per eseguire solo il pezzo dell’applicazione per cui stiamo testando.

Questo esempio proviene da un test case relativo al settore bancario:

Con questo nome di metodo, sappiamo che questo è un test unitario che è:

• Testare il metodo ‘isOverDrawn ()’.
• Il bilanciato utilizzato per i dati controllati era 500.
• Il risultato atteso è vero.

Un nome di metodo significativo consente a chiunque di rivedere i risultati per capire a cosa stava testando l’unit test. Inoltre, segnala i dati da testare, il risultato atteso e ciò che è stato testato.

Se il test fallisce, conoscere il risultato atteso è fondamentale per consentire una più facile risoluzione dei problemi e garantire che non vengano introdotte regressioni.

Dati test Case

I dati utilizzati devono essere sufficienti per eseguire il test. Per il test delle unità, vogliamo rendere il più semplice possibile testare l’unità di base della nostra applicazione. I dati potrebbero essere semplici come creare una stringa o una variabile oggetto per la quale è possibile controllare i dati. Oppure un framework finto può essere utilizzato per il test se una dipendenza non è disponibile o è necessario che la dipendenza si trovi in uno stato specifico.

Avere quanto basta per testare quella parte se sufficiente. Non è necessario configurare ogni parte dell’applicazione per l’esecuzione del test.

Tutto ciò influisce sul comportamento del test unitario poiché questi sono i dati utilizzati per l’esecuzione del test unitario. In quanto tale, questa parte del test delle unità richiede più tempo in quanto richiede una certa comprensione del codice che si sta testando per sapere quali dati utilizzare per il test.

Mantienilo semplice usando solo le parti necessarie per il codice in fase di test. I Mock sono molto utili in questa fase in quanto consentono di controllare il comportamento dei metodi di tali oggetti quando interagiscono con il test.

Ad esempio, dati i seguenti dati:

Abbiamo evitato la “classe cliente reale” utilizzando un mock per la “classe cliente” per testare l’isolamento. Non vogliamo introdurre né configurare un altro oggetto per questo test in quanto aggiunge un altro livello di manutenibilità per quell’oggetto e non influisce sul risultato del metodo in prova.

La variabile successiva da creare è il “saldo iniziale”—qualcosa di noto a causa della conoscenza del codice. La riga successiva mostra l’oggetto Account creato insieme al finto e al saldo iniziale per preparare il metodo che stiamo testando con i dati che abbiamo appena usato.

Quindi in questo esempio, l’oggetto account è configurato con il cliente finto poiché non ci interessa i dati dell’oggetto cliente e abbiamo superato un saldo iniziale che possiamo controllare per il nostro test.

La riga successiva definisce l’input poiché il metodo in esame richiede l’utilizzo di un numero. Abbiamo definito il “saldo” da utilizzare nel metodo che stiamo testando. Quindi il metodo viene eseguito con il risultato che il metodo viene memorizzato nella nostra variabile da utilizzare in seguito.

Applicazione di un’asserzione

Una volta che il test può essere completato correttamente (poiché viene eseguito dall’inizio alla fine senza eccezioni o errori), è il momento di applicare un’asserzione al test unitario. Senza l’asserzione, il test unitario non ha senso poiché non c’è nulla che tu stia applicando per assicurarti che funzioni come previsto.

La raccolta della copertura di quali linee sono state eseguite indica cosa è stato eseguito ma non fornisce dettagli sufficienti per determinare quanto segue:

• Se il codice si comporta come previsto.
• Se il codice soddisfa gli obiettivi di qualità.
• Se i dati restituiti sono i dati previsti.

Un’asserzione può essere di base come:

Finché il test unitario contiene un’asserzione che sta controllando il metodo sotto il risultato del test, questo è un test unitario significativo.

Applicando il formato standard di test unitario, un team può facilmente mantenere, leggere e/o aggiornare i test con più facilità per vedere facilmente dove più test possono essere applicati al resto dell’applicazione.

Quali sono le migliori pratiche per la scrittura di casi di test di qualità?

Come scrivere test efficaci e casi di test possono essere semplificati nel tempo. Alcune best practice includono l’utilizzo di titoli forti, descrizioni forti, e mantenendo il linguaggio conciso e chiaro.

Ma vorrai anche includere precondizioni, ipotesi e anche i risultati attesi. Tutte queste informazioni sono rilevanti per il tester software, specialmente quando si determina se il caso di test deve essere un “pass” o un “fail”.

Un cheat sheet per la creazione di casi di test che funzionano bene è il seguente:

• Mantenere le cose semplici e trasparenti.
• Rendi riutilizzabili i casi di test.
• Mantieni gli ID test case univoci.
• La revisione tra pari è importante.
• I casi di test dovrebbero avere in mente l’utente finale o i requisiti definiti.
• Specificare i risultati e le ipotesi attese.

Semplice, unico, specifico, aperto al feedback e incentrato sulla riusabilità: questo è il modo di un grande caso di test. Per uno sguardo più visivo su come scrivere un caso di test di qualità, controlla il webinar di Parasoft sull’argomento.

Test Suite vs. Test Plan

L’altro aspetto di un test case riguarda suite di test e piani di test. Questi differiscono in modi chiave ed entrambi sono vitali per lo sviluppo accurato del caso di test.

Che cos’è una suite di test?

Una suite di test entra in gioco per i casi di test in relazione al codice sorgente, alla raccolta di dipendenze o alla suite di test da eseguire sul codice. Le suite di test consentono di classificare i casi di test in modo da allinearli a qualsiasi esigenza di analisi o pianificazione.

Ciò significa che le funzionalità del software di base potrebbero avere una propria suite di test mentre un’altra suite di test è per un tipo di test specifico come smoke o security. Pensa alle suite di test come a una libreria su cui organizzare i tuoi casi di test.

Che cos’è un piano di test?

Al contrario, un piano di test è più simile all’ombrello che si trova su tutte le suite di test. Se i casi di test sono libri e le suite di test sono librerie, i piani di test sono la stanza che contiene la libreria.

Generalmente, i piani di test sono impostati in termini di test manuali, test automatizzati e un formato generale su come eseguire i test. Testeranno il software dalla fondazione utilizzando suite di test e casi di test prima di implementare modifiche o aggiungere nuove funzionalità.

Best Test Case Writing Tools

Parasoft sviluppa generalmente i suoi strumenti e suite con la teoria “George Jetson” in mente. Vale a dire che vogliamo che i nostri clienti siano in grado di “premere un pulsante” e avere tutto curato. Anche se questo non è del tutto realistico, gli strumenti che hanno questo focus sull’automazione sono i migliori da usare quando si tratta di scrivere casi di test.

Non solo possono aiutare con l’automazione, ma possono aiutare fin dall’inizio dello sviluppo. Dopo tutto, è troppo facile impantanarsi da piccoli dettagli o caratteristiche. Si potrebbe dimenticare che il software deve solo funzionare prima. Ecco dove uno strumento di test delle unità Java come Parasoft Jtest entra in gioco.

Questo strumento consente sia ai principianti che agli esperti di migliorare più rapidamente le proprie capacità di test unitari, nonché l’esperienza di test unitari. Dopo aver stabilito una fondazione, esegue i test unitari quindi guida l’utente per assicurarsi che i test siano significativi. Quando puoi capire il tipo di cose da cercare in un test, la scrittura del caso di test diventa meno intimidatoria.