Che cosa sono i test funzionali?
- 10 minuti
In questa sezione si collabora con il team Tailspin mentre definisce i test funzionali per la sua pipeline. I test funzionali verificano che ogni funzione del software esegua le operazioni previste.
Il team definisce innanzitutto l'ambito di applicazione di un test funzionale. Prende in esame alcuni tipi di test funzionali. Decide quindi di aggiungere il primo test alla propria pipeline.
Riunione settimanale
Il team sta svolgendo la riunione settimanale. Andy sta presentando la pipeline di versione. Il team osserva il percorso di una build di buon livello lungo la pipeline, da una fase a un'altra. Infine, l'app Web viene promossa a Staging.
Amita: Sono molto soddisfatta della pipeline. Mi è di grandissimo aiuto. Innanzitutto, ottengo automaticamente una versione distribuita nell'ambiente di test. Non devo scaricare e installare manualmente gli artefatti della compilazione nei server di test. Per me è un notevole risparmio di tempo.
Inoltre, gli unit test scritti da Mara e Andy eliminano tutti i bug di regressione prima che io riceva la versione. Questo elimina un grande motivo di frustrazione. Non devo dedicare tempo a cercare e documentare i bug di regressione.
Ma temo che tutti i miei test siano ancora manuali. Il processo è lento e non possiamo mostrare nulla alla dirigenza finché io non ho finito. È difficile perché i test sono importanti. I test garantiscono che gli utenti ottengano l'esperienza corretta. Ma i tempi sono sempre molto stretti.
Andy: Sono sicuro che possiamo aiutarti. Quali tipi di test richiedono più tempo?
Amita: Credo che siano i test dell'interfaccia utente. Devo fare clic su ogni passaggio per assicurarsi di ottenere il risultato corretto e devo farlo per ogni browser che supportiamo. Si tratta di un lavoro molto lungo. Inoltre, man mano che il sito Web diventa più complesso, i test dell'interfaccia utente saranno sempre meno praticabili sul lungo periodo.
Mara: I test dell'interfaccia utente vengono considerati test funzionali .
Tim: Rispetto a cosa, ai test non funzionali?
Mara: Esattamente. E i test non funzionali sono molto importanti, soprattutto per te.
Tim: Ok, sono confuso.
Che cosa sono i test funzionali e non funzionali?
Mara:I test funzionali verificano che ogni funzione del software operi come previsto. Il modo in cui il software implementa ogni funzione non è rilevante in questi test. Ciò che conta è che il software si comporti correttamente. Si fornisce un input e si verifica che l'output sia quello previsto. È così che Amita testa l'interfaccia utente. Ad esempio, se seleziona il giocatore in vetta al tabellone punteggi, si aspetta di visualizzare il profilo di quel giocatore.
I test non funzionali controllano caratteristiche come prestazioni e affidabilità. Un esempio di test non funzionale è la verifica del numero di persone che possono accedere contemporaneamente all'app. Il test di carico è un altro esempio di test non funzionale. Quei problemi di prestazioni e affidabilità sono particolarmente importanti per te, Tim.
Tim: Sono, anzi. Devo rifletterci un attimo. Mi sarebbe utile un certo livello di automazione della pipeline, ma non so bene cosa posso fare. Quali tipi di test automatizzati posso eseguire?
Mara: Per il momento, è possibile concentrarsi sui test funzionali. È la tipologia di test che fa Amita, e sembra un'area in cui vogliamo migliorare.
Quali tipi di test funzionali posso eseguire?
Esistono molti tipi di test funzionali. Variano in base alle funzionalità da testare e al tempo o al lavoro generalmente richiesto per l'esecuzione.
Le sezioni seguenti illustrano alcuni test funzionali di uso comune.
Test di verifica della compilazione
Smoke testing verifica la funzionalità di base dell'applicazione o del servizio. Questi test vengono spesso eseguiti prima di test più completi ed esaustivi. I test di verifica della compilazione dovrebbero essere eseguiti rapidamente.
Si supponga, ad esempio, di sviluppare un sito Web. Il test di verifica della compilazione potrebbe usare curl per verificare che il sito sia raggiungibile e che il recupero della home page generi uno stato HTTP 200 (OK). Se il recupero della home page produce un altro codice di stato, ad esempio 404 (Non trovato) o 500 (Errore interno del server), significa che il sito Web non funziona. Significa anche che non c'è motivo per eseguire altri test. Occorre invece diagnosticare l'errore, correggerlo e riavviare i test.
Testing unità
In breve, unit test verifica i componenti più fondamentali del programma o della libreria, ad esempio una singola funzione o metodo. Si specificano uno o più input insieme ai risultati previsti. Il tester esegue ogni test e verifica se i risultati effettivi corrispondono a quelli previsti.
Si supponga ad esempio di avere una funzione che esegue un'operazione aritmetica che include la divisione. Si potrebbero specificare alcuni valori che si prevede vengano immessi dagli utenti. Si specificano anche i valori edge-case come 0 e -1. Se si prevede che un determinato input generi un errore o un'eccezione, è possibile verificare che la funzione produca tale errore.
I test dell'interfaccia utente che verranno eseguiti più avanti in questo modulo sono unit test.
Test di integrazione
Il test di integrazione verifica che più componenti software interagiscono per formare un sistema completo. Ad esempio, un sistema di e-commerce potrebbe includere un sito Web, un database dei prodotti e un sistema di pagamento. È possibile scrivere un test di integrazione che aggiunga articoli al carrello ed esegua l'acquisto. Il test verifica che l'applicazione Web sia in grado di connettersi al database dei prodotti e quindi evadere l'ordine.
È possibile combinare unit test e test di integrazione per creare una strategia di testing a più livelli. Ad esempio, è possibile eseguire unit test sui singoli componenti prima di eseguire i test di integrazione. Se tutti gli unit test vengono superati, si può passare ai test di integrazione con maggiore sicurezza.
Test di regressione
Una regressione si verifica quando il comportamento esistente cambia o si interrompe dopo l'aggiunta o la modifica di una funzionalità. I test di regressione consentono di determinare se il codice, la configurazione o altre modifiche influiscono sul comportamento complessivo del software.
I test di regressione sono importante perché una modifica in un componente può influire sul comportamento di un altro componente. Si immagini, ad esempio, di ottimizzare un database per le prestazioni di scrittura. Le prestazioni di lettura di quel database, gestite da un altro componente, potrebbero calare in modo imprevisto. Il calo delle prestazioni di lettura è una regressione.
È possibile usare diverse strategie per testare la regressione. Queste strategie variano in genere in base al numero di test eseguiti per verificare che una nuova funzionalità o correzione di bug non interrompa le funzionalità esistenti. Con l'automazione dei test, invece, i test di regressione potrebbero comportare semplicemente l'esecuzione di tutti gli unit test e i test di integrazione ogni volta che il software viene modificato.
Test di integrità
I test di integrità comportano il test di ogni componente principale di un componente software per verificare che il software funzioni e possa essere sottoposto a test più approfonditi. È possibile pensare ai test di sanità come meno accurati rispetto ai test di regressione o agli unit test, ma i test di sanità sono più estesi rispetto ai test di fumo.
Sebbene possano essere automatizzati, i test di integrità vengono spesso eseguiti manualmente a seguito di una modifica delle funzionalità o di una correzione di bug. Ad esempio, un tester di software che sta convalidando una correzione di bug potrebbe verificare anche il funzionamento di altre funzionalità inserendo alcuni valori tipici. Se il software sembra funzionare come previsto, può essere sottoposto a test più completi.
Test dell'interfaccia utente
Il test dell'interfaccia utente verifica il comportamento dell'interfaccia utente di un'applicazione. I test dell'interfaccia utente consentono di verificare che la sequenza, o l'ordine, delle interazioni utente produca il risultato previsto. Questi test consentono anche di verificare che i dispositivi di input, come la tastiera o il mouse, interagiscano correttamente con l'interfaccia utente. È possibile eseguire test dell'interfaccia utente per verificare il comportamento di un'applicazione Windows, macOS o Linux nativa. oppure per verificare che l'interfaccia utente si comporti come previsto nei Web browser.
Uno unit test o un test di integrazione potrebbe verificare che l'interfaccia utente riceva correttamente i dati. Tuttavia, il test dell'interfaccia utente consente di verificare che l'interfaccia utente venga visualizzata correttamente e che il risultato funzioni come previsto per l'utente.
Ad esempio, un test dell'interfaccia utente potrebbe verificare che venga visualizzata l'animazione corretta in risposta al clic su un pulsante. Un secondo test potrebbe verificare che la stessa animazione venga visualizzata correttamente quando la finestra viene ridimensionata.
In questo modulo vengono utilizzati test dell'interfaccia utente codificati manualmente. Tuttavia, è anche possibile usare un sistema di acquisizione e riproduzione per creare automaticamente i test dell'interfaccia utente.
Test di usabilità
Il test di usabilità è una forma di test manuale che verifica il comportamento di un'applicazione dal punto di vista dell'utente. Il team che compila il software generalmente esegue i test di usabilità.
Mentre i test dell'interfaccia utente verificano principalmente che una funzionalità si comporti nel modo previsto, i test di usabilità consentono di verificare che il software sia intuitivo e soddisfi le esigenze dell'utente. In altre parole, i test di usabilità consentono di verificare che il software sia "utilizzabile".
Si immagini, ad esempio, di disporre di un sito Web che include un collegamento al profilo dell'utente. Un test dell'interfaccia utente può verificare che il collegamento sia presente e che venga visualizzato il profilo dell'utente quando viene selezionato il collegamento. Se però questo collegamento non è facile da individuare, gli utenti potrebbero essere delusi quando tentano di accedere al proprio profilo.
Test di accettazione utente
I test di accettazione dell'utente, come i test di usabilità, sono incentrati sul comportamento di un'applicazione dal punto di vista dell'utente. A differenza dei test di usabilità, i test di accettazione utente vengono generalmente eseguiti dagli utenti finali reali.
A seconda del software, agli utenti finali potrebbe essere richiesto di completare attività specifiche. In alternativa, gli utenti potrebbero essere in grado di esplorare il software senza seguire specifiche linee guida. Per il software personalizzato, i test di accettazione utente vengono in genere eseguiti direttamente con il client. Per un software più generico, i team potrebbero eseguire test beta . Nei test beta, gli utenti di diverse aree geografiche o che hanno determinati interessi ricevono in anticipo l'accesso al software.
Il feedback dei tester può essere diretto o indiretto. Il feedback diretto può assumere la forma di commenti verbali. Il feedback indiretto può corrispondere alla misurazione del linguaggio del corpo o dei movimenti oculari dei tester oppure del tempo necessario per completare determinate attività.
Abbiamo già parlato dell'importanza della scrittura dei test. Per ribadire il concetto, ecco un breve video in cui Abel Wang, Cloud Advocate presso Microsoft, spiega come assicurare la qualità in un piano DevOps.
Chiedi a Abel
Che cosa sceglie il team?
Tim: Tutti questi test sono importanti. Da quale dovremmo iniziare?
Andy: Abbiamo già dei unit test funzionanti. Non siamo ancora pronti ad eseguire test di accettazione utente. Da ciò che sento, penso che dovremmo concentrarci sul test dell'interfaccia utente. Attualmente, è la parte più lenta del nostro processo. Amita, sei d'accordo?
Amita: Sì, sono d'accordo. Ci resta ancora un po' di tempo in questa riunione. Andy o Mara, vuoi aiutarmi a pianificare un test dell'interfaccia utente automatizzato?
Mara: Assolutamente. Ma prima affrontiamo alcune questioni preliminari. Vorrei parlare dello strumento che dovremmo usare e di come verranno eseguiti i test.
Quali strumenti è possibile usare per scrivere test dell'interfaccia utente?
Mara: Quando si tratta di scrivere test dell'interfaccia utente, quali sono le opzioni disponibili? So che ne esistono molte. Alcuni strumenti sono open source. Altri offrono supporto commerciale a pagamento. Ecco alcune opzioni da tenere presenti:
- Windows Application Driver (WinAppDriver): WinAppDriver consente di automatizzare i test dell'interfaccia utente nelle app di Windows. Queste app possono essere scritte nella piattaforma UWP (Universal Windows Platform) o in Windows Forms (WinForms). Ci serve una soluzione che funzioni in un browser.
- Selenium: Selenium è un framework di test software open source portatile per le applicazioni Web. Viene eseguito nella maggior parte dei sistemi operativi e supporta tutti i browser moderni. È possibile scrivere test di Selenium in diversi linguaggi di programmazione, tra cui C#. Sono infatti disponibili pacchetti NuGet che semplificano l'esecuzione di Selenium come test NUnit. Noi usiamo già NUnit per i nostri unit test.
- SpecFlow: SpecFlow è per i progetti .NET. Si ispira a uno strumento denominato Cucumber. Sia SpecFlow che Cucumber supportano lo sviluppo basato su comportamento (BDD). BDD usa un parser del linguaggio naturale denominato Gherkin per consentire ai team tecnici e non tecnici di definire le regole e i requisiti aziendali. È possibile combinare SpecFlow o Cucumber con Selenium per creare test dell'interfaccia utente.
Andy guarda Amita.
Andy: So che queste opzioni sono nuove per te, quindi ti dispiace se scegliamo Selenium? L'ho già utilizzato e supporta linguaggi che conosco già. Selenium offre anche il supporto automatico per più browser.
Amita: Certo. Se uno di noi ha una certa esperienza, è meglio.
Come si eseguono i test funzionali nella pipeline?
In Azure Pipelines è possibile eseguire test funzionali come qualsiasi altro processo o test. Porsi le domande seguenti:
- In quale fase vengono eseguiti i test?
- Su quale sistema vengono eseguiti i test? Verranno eseguiti nell'agente o nell'infrastruttura che ospita l'applicazione?
Vediamo le risposte del team a queste domande.
Mara: Una cosa di cui sono entusiasta è che ora è possibile testare in un ambiente simile a quello di produzione, in cui l'app è effettivamente in esecuzione. I test funzionali come i test dell'interfaccia utente hanno senso in quel contesto. È possibile eseguirli nella fase di Test della nostra pipeline.
Amita: Sono d'accordo. Possiamo mantenere lo stesso flusso di lavoro se eseguiamo test automatizzati dell'interfaccia utente nella stessa fase in cui eseguo i test manuali. I test automatizzati ci consentiranno di risparmiare tempo e di concentrarci sull'usabilità.
Tim: Amita testa il sito Web dal suo portatile Windows perché è così che la maggior parte dei nostri utenti visita il sito. Però noi compiliamo in Linux e quindi distribuiamo Servizio app di Azure in Linux. Come possiamo gestire questa situazione?
Mara: Grande domanda. È anche possibile scegliere dove eseguire i test. Possiamo eseguirli:
- Nell'agente: un agente Microsoft o un agente che ospitiamo.
- Nell'infrastruttura di test: locale o nel cloud.
La fase Test esistente include un solo processo. Questo processo distribuisce il sito Web al servizio app da un agente Linux. Possiamo aggiungere un secondo processo che esegue i test dell'interfaccia utente da un agente Windows. L'agente Windows ospitato da Microsoft è già configurato per l'esecuzione di test di Selenium.
Andy: Ancora una volta, restiamo con quello che sappiamo. Usiamo un agente Windows ospitato da Microsoft. In seguito, possiamo eseguire gli stessi test da agenti che eseguono macOS e Linux se è necessario estendere la copertura dei test.
Il piano
Mara: OK. Verranno effettuate le operazioni seguenti.
- Eseguire test dell'interfaccia utente di Selenium da un agente Windows ospitato da Microsoft.
- Fare in modo che i test recuperino il contenuto Web dall'app in esecuzione in Servizio app, nella fase di Test.
- Eseguire i test in tutti i browser supportati.
Andy: Lavorerò con Amita su questo. Amita, ci vediamo domani mattina. Farò qualche ricerca prima del nostro incontro.
Amita: Benissimo! A domani.
Creare un piano di test funzionali
Abbiamo appena visto il team prendere alcune decisioni in merito all'implementazione dei primi test funzionali. Se il team sta iniziando a incorporare test funzionali nella propria pipeline (o anche se questo succede già), tenere presente che è sempre necessario un piano.
Molte volte, quando ai membri del team vengono chieste informazioni sul piano di test delle prestazioni, spesso la risposta è un elenco di strumenti che verranno usati. Un elenco di strumenti, però, non è un piano. È anche necessario stabilire come verranno configurati gli ambienti di test. Devi determinare il processo da utilizzare e come si presentano risultati positivi o negativi.
Il piano deve:
- Prendere in considerazione le aspettative dell'azienda.
- Prendere in considerazione le aspettative degli utenti di destinazione.
- Definire le metriche che verranno usate.
- Definire gli indicatori KPI che si useranno.
Il test delle prestazioni deve essere incluso nella pianificazione fin dalle prime fasi. Se si usa uno storyboard o una lavagna Kanban, può essere utile predisporre un'area in cui pianificare la strategia di test. Come parte della pianificazione dell'iterazione, è necessario evidenziare le lacune nella strategia di test. È anche importante stabilire come verranno monitorate le prestazioni dopo la distribuzione dell'applicazione e non solo misurare le prestazioni prima del rilascio.