Cos’è l’automazione dei test? Un’introduzione semplice e chiara
Ci sono due tipi di test nel mondo del software: manuale e automatico. Alcuni tipi di test manuali, come i test di scoperta e i test di usabilità, sono inestimabili. Si possono fare altri tipi di test, come i test di regressione e i test funzionali, manualmente, ma è una pratica abbastanza dispendiosa per gli umani continuare a fare la stessa cosa più e più volte. Sono questi tipi di test ripetitivi che si prestano all’automazione dei test.
L’automazione dei test è la pratica di eseguire automaticamente i test, gestire i dati dei test e utilizzare i risultati per migliorare la qualità del software. È principalmente una misura di assicurazione della qualità, ma le sue attività coinvolgono l’impegno dell’intero team di produzione del software. Dagli analisti di business agli sviluppatori e agli ingegneri DevOps, ottenere il massimo dall’automazione dei test richiede l’inclusione di tutti.
Questo post vi darà una comprensione di alto livello di cosa sia l’automazione dei test. Ci sono tutti i tipi di test, ma non tutti dovrebbero essere automatizzati; quindi, iniziamo con i criteri generali per l’automazione dei test.
Criteri per l’automazione
Un test deve soddisfare alcuni criteri per essere automatizzato – altrimenti, potrebbe finire per costare più di quanto risparmia. Dopo tutto, uno dei principali obiettivi dell’automazione è quello di risparmiare tempo, fatica e denaro. Ecco alcuni criteri generali per l’automazione dei test. Questi sono punti di partenza, attenzione. I vostri criteri possono essere diversi a seconda delle circostanze.
Ripetibile
Il test deve essere ripetibile. Non ha senso automatizzare un test che può essere eseguito solo una volta. Un test ripetibile ha i seguenti tre passi:
- Impostare il test, inclusi i dati e l’ambiente.
- Eseguire la funzione e misurare il risultato.
- Pulire i dati e l’ambiente.
Nel primo passo, vogliamo essere capaci di mettere l’ambiente in uno stato coerente. In altre parole, se abbiamo un test per tentare di aggiungere un utente esistente, dobbiamo assicurarci che l’utente esista prima di eseguire il test. Una volta che il test è completato, l’ambiente dovrebbe essere riportato allo stato base.
Determinante
Quando una funzione è determinante, significa che il risultato è lo stesso ogni volta che viene eseguita con lo stesso input. Lo stesso vale per i test che possono essere automatizzati. Per esempio, diciamo che vogliamo testare una funzione di addizione. Sappiamo che 1 + 1 = 2 e che 394,19 + 5,81 = 400,00. L’addizione è una funzione determinante.
Il software, d’altra parte, può utilizzare un numero così alto di input variabili che è difficile avere lo stesso risultato nel tempo. Alcune variabili possono anche essere casuali, il che può rendere difficile determinare il risultato specifico. La progettazione del software può compensare questo aspetto consentendo input di test attraverso un’infrastruttura di test.
Altre caratteristiche di un’applicazione possono essere additive; per esempio, la creazione di un nuovo utente si aggiungerebbe al numero di utenti. Almeno quando aggiungiamo un utente sappiamo che il numero di utenti dovrebbe crescere solo di uno. Tuttavia, l’esecuzione di test in parallelo può causare risultati inaspettati. L’isolamento può prevenire questo tipo di falso positivo.
Senza opinioni
Non è possibile automatizzare le questioni di opinione. È qui che i test di usabilità, i beta test e così via brillano davvero. Il feedback degli utenti è importante, ma non può essere automatizzato… mi dispiace!
Tipi di test automatizzati
Ci sono così tanti tipi di test, molti dei quali possono essere automatizzati, che non possiamo davvero metterli tutti in un post. Ma qui ce ne sono abbastanza per darvi un buon punto di partenza.
Analisi del codice
Ci sono in realtà molti tipi diversi di strumenti di analisi del codice, compresa l’analisi statica e l’analisi dinamica. Alcuni di questi test cercano difetti di sicurezza, altri controllano lo stile e la forma. Questi test vengono eseguiti quando uno sviluppatore controlla il codice. Oltre a configurare le regole e mantenere gli strumenti aggiornati, non c’è molto da scrivere con questi test automatizzati.
Test unitari
Si può anche automatizzare una suite di test unitari. I test unitari sono progettati per testare una singola funzione, o unità, di funzionamento in isolamento. Di solito vengono eseguiti su un server di compilazione. Questi test non dipendono da database, API esterne o memorizzazione di file. Devono essere veloci e sono progettati per testare solo il codice, non le dipendenze esterne.
Test di integrazione
I test di integrazione sono un tipo diverso di animale quando si tratta di automazione. Poiché un test di integrazione, a volte chiamato test end-to-end, ha bisogno di interagire con dipendenze esterne, è più complicato da impostare. Spesso, è meglio creare false risorse esterne, specialmente quando si ha a che fare con risorse al di fuori del proprio controllo.
Se, per esempio, avete un’applicazione di logistica che dipende da un servizio web di un fornitore, il vostro test potrebbe fallire inaspettatamente se il servizio del fornitore è fuori uso. Questo significa che la vostra app è rotta? Potrebbe, ma dovreste avere abbastanza controllo sull’intero ambiente di test per creare esplicitamente ogni scenario. Non dipendete mai da un fattore esterno per determinare il risultato del vostro scenario di test.
Test di accettazione automatizzati
Oggi ci sono diverse pratiche che utilizzano test di accettazione automatizzati (AAT), ma fondamentalmente stanno facendo la stessa cosa. Lo sviluppo guidato dal comportamento (BDD) e lo sviluppo guidato dai test di accettazione automatizzati (AATDD) sono simili. Entrambi seguono la stessa pratica di creare il test di accettazione prima che la caratteristica sia sviluppata.
Alla fine, il test di accettazione automatico viene eseguito per determinare se la caratteristica fornisce ciò che è stato concordato. Pertanto, è fondamentale per gli sviluppatori, l’azienda e il QA scrivere questi test insieme. Servono come test di regressione in futuro, e assicurano che la caratteristica regga a ciò che ci si aspetta.
Test di regressione
Senza AAT in atto, si devono scrivere test di regressione dopo il fatto. Mentre entrambi sono forme di test funzionali, come sono scritti, quando sono scritti e da chi sono scritti sono molto diversi. Come gli AAT, possono essere guidati attraverso un’API dal codice o da un’interfaccia utente. Esistono strumenti per scrivere questi test usando una GUI.
Test di performance
Esistono molti tipi di test di performance, ma tutti testano qualche aspetto della performance di un’applicazione. Reggerà a pressioni estreme? Stiamo testando il sistema per il calore elevato? Stiamo cercando il semplice tempo di risposta sotto carico? E la scalabilità?
A volte questi test richiedono l’emulazione di un numero enorme di utenti. In questo caso, è importante avere un ambiente che sia in grado di eseguire una tale impresa. Le risorse cloud sono disponibili per aiutare con questo tipo di test, ma è possibile utilizzare anche risorse on-premises.
Test di fumo
Cos’è uno smoke test? È un test di base che di solito viene eseguito dopo un deployment o una finestra di manutenzione. Lo scopo di uno smoke test è di assicurare che tutti i servizi e le dipendenze siano attivi e funzionanti. Uno smoke test non è pensato per essere un test funzionale completo. Può essere eseguito come parte di un deployment automatico o attivato attraverso un passo manuale.
Processo generale di automazione dei test
Ora che abbiamo visto i criteri di automazione e abbastanza tipi di test automatizzati per avere un’idea delle cose, ecco il processo generale di automazione dei test. Ci sono tre passi principali nell’automazione dei test: preparare, agire, riportare i risultati.
Preparare
Prima di tutto, dobbiamo preparare lo stato, i dati di test e l’ambiente in cui si svolgono i test. Come abbiamo visto, la maggior parte dei test richiede che l’ambiente sia in un certo stato prima che un’azione abbia luogo. In uno scenario tipico, questo richiede una certa preparazione. O i dati dovranno essere manipolati o l’applicazione dovrà essere messa in uno stato specifico o entrambi!
Take Action
Una volta che lo stato e/o l’ambiente è nello stato predefinito, è il momento di agire! Il test driver eseguirà il test, sia chiamando l’API di un’applicazione o l’interfaccia utente, sia eseguendo direttamente il codice. Il test driver è responsabile di “guidare” i test, ma il sistema di gestione dei test si assume la responsabilità di coordinare tutto, compreso il reporting dei risultati.
Report Results
Un sistema di automazione dei test registrerà e riporterà i risultati. Questi risultati possono arrivare in un certo numero di formati diversi e possono anche creare ticket di problemi o bug in un sistema di tracciamento del lavoro. Il risultato di base, comunque, è un passaggio o un fallimento. Di solito, c’è un indicatore verde o rosso per ogni scenario di test per indicare il passaggio o il fallimento.
A volte, i test sono inconcludenti o non vengono eseguiti per qualche motivo. Quando questo accade, il sistema di automazione avrà un log completo dell’output per gli sviluppatori da rivedere. Questo registro li aiuta a rintracciare il problema. Idealmente, saranno in grado di riprodurre lo scenario una volta che hanno messo in atto una correzione.
La linea di fondo
La linea di fondo è questa: l’automazione dei test aiuta a migliorare la qualità con la velocità. Ma non tutti i test possono essere automatizzati. C’è sicuramente un investimento coinvolto. Con così tanti tipi di test, è importante avere il giusto mix. La piramide dei test è una semplice regola empirica per aiutare ad ottenere questo risultato. Dice che la maggior parte dei test dovrebbe essere costituita da test unitari, seguiti da test di servizio e poi da test UI.
Un sistema di automazione dei test coordina le attività di test, compresa la gestione dei dati di test, l’esecuzione dei test e il monitoraggio dei risultati. L’automazione dei test è il passo successivo per i team che stanno diventando sopraffatti dal peso di ripetere gli stessi test manuali che dovrebbero essere automatizzati.
Biografia dell’autore: Questo post è stato scritto da Phil Vuollet. Phil usa il software per automatizzare i processi per migliorare l’efficienza e la ripetibilità. Scrive su argomenti rilevanti per la tecnologia e il business, occasionalmente tiene conferenze sugli stessi argomenti, ed è un padre di famiglia che si diverte a giocare a calcio e a giochi da tavolo con i suoi figli.