complete functional testing guide with its types
Un tutorial approfondito sul test funzionale completo con tipi, tecniche ed esempi:
Cos'è il test funzionale?
Il test funzionale è una sorta di test black-box che viene eseguito per confermare che la funzionalità di un'applicazione o di un sistema si sta comportando come previsto.
Viene fatto per verificare tutte le funzionalità di un'applicazione.
ELENCO dei tutorial trattati in questa serie:
Tutorial n. 1: Cos'è il test funzionale (questo tutorial)
Tutorial n. 2: Domande di intervista sul test di funzionalità
Tutorial n. 3: I migliori strumenti di test dell'automazione funzionale
Tutorial n. 4: Che cosa sono i test non funzionali?
Tutorial n. 5: Differenza tra unità, funzionale e Integrazione Test
Tutorial # 6 : Perché i test funzionali e delle prestazioni dovrebbero essere eseguiti contemporaneamente
Utensili:
Tutorial # 7: Automazione del test funzionale con Ranorex Studio
Tutorial n. 8: Nuove funzionalità dello strumento funzionale UFT
Tutorial n. 9: Automazione funzionale cross browser utilizzando lo strumento QA Parrot
Tutorial n.10: Tutorial Jubula Open Source Tool per test di funzionalità
Cosa imparerai:
- Introduzione al test funzionale
Introduzione al test funzionale
Deve esserci qualcosa che definisce cosa è un comportamento accettabile e cosa non lo è.
Ciò è specificato in una specifica funzionale o di requisito. È un documento che descrive ciò che un utente è autorizzato a fare in modo che possa determinare la conformità dell'applicazione o del sistema ad esso. Inoltre, a volte ciò potrebbe anche comportare la convalida degli scenari effettivi del lato aziendale.
Pertanto, il test di funzionalità può essere eseguito tramite due tecniche popolari :
- Test basati sui requisiti: Contiene tutte le specifiche funzionali che costituiscono la base per tutti i test da condurre.
- Test basati su scenari aziendali: Contiene le informazioni su come il sistema verrà percepito dal punto di vista dei processi aziendali.
I test e la garanzia della qualità sono una parte importante del processo SDLC. In qualità di tester, dobbiamo essere consapevoli di tutti i tipi di test, anche se non ne siamo direttamente coinvolti quotidianamente.
Poiché il test è un oceano, la sua portata è davvero vasta e abbiamo tester dedicati che si esibiscono diversi tipi di test . Molto probabilmente tutti noi dobbiamo avere familiarità con la maggior parte dei concetti, ma non farà male organizzare tutto qui.
Tipi di test funzionali
Il test funzionale ha molte categorie e queste possono essere utilizzate in base allo scenario.
I tipi più importanti sono discussi brevemente di seguito:
Il test di unità viene solitamente eseguito da uno sviluppatore che scrive diverse unità di codice che potrebbero essere correlate o non correlate per ottenere una particolare funzionalità. Il suo, questo di solito comporta la scrittura di unit test che chiamano i metodi in ciascuna unità e convalidano quelli quando vengono passati i parametri richiesti, e il suo valore di ritorno è quello previsto.
La copertura del codice è una parte importante del test unitario in cui i casi di test devono esistere per coprire i tre seguenti:
i) Copertura di linea
ii) Copertura del percorso del codice
iii) Copertura del metodo
Test di sanità mentale : Il test viene eseguito per garantire che tutte le funzionalità principali e vitali dell'applicazione / del sistema funzionino correttamente. Questo viene generalmente fatto dopo un test del fumo.
Test del fumo : Test che viene eseguito dopo il rilascio di ogni build per testare la stabilità della build. È anche chiamato test di verifica della build.
Test di regressione : Test eseguiti per garantire che l'aggiunta di nuovo codice, miglioramenti, correzione di bug non rompa la funzionalità esistente o causi instabilità e funzioni ancora secondo le specifiche.
I test di regressione non devono essere estesi quanto i test funzionali effettivi, ma dovrebbero garantire solo la quantità di copertura per certificare che la funzionalità è stabile.
Test di integrazione : Quando il sistema si basa su più moduli funzionali che potrebbero funzionare perfettamente individualmente, ma devono funzionare in modo coerente quando vengono riuniti insieme per ottenere uno scenario end-to-end, la convalida di tali scenari viene chiamata test di integrazione.
Beta / test di usabilità : Il prodotto è esposto al cliente reale in una produzione come un ambiente e testano il prodotto. Il comfort dell'utente è derivato da questo e il feedback viene preso. Questo è simile a quello del test di accettazione dell'utente.
Rappresentiamo questo in un semplice diagramma di flusso:
Test del sistema funzionale:
Test di sistema è un test che viene eseguito su un sistema completo per verificare se funziona come previsto una volta integrati tutti i moduli o componenti.
Test end to end viene eseguito per verificare la funzionalità del prodotto. Questo test viene eseguito solo quando il test di integrazione del sistema è completo, inclusi i requisiti funzionali e non funzionali.
=> Differenza tra test unitari, funzionali e di integrazione
Processi
Questo processo di test ha tre fasi principali:
Approccio, tecniche ed esempi
Il test funzionale o comportamentale genera un output in base agli input forniti e determina se il sistema funziona correttamente secondo le specifiche.
Quindi, la rappresentazione pittorica apparirà come mostrato di seguito:
Criteri di ingresso / uscita
Criteri di ingresso:
- Il documento di specifica dei requisiti viene definito e approvato.
- I casi di test sono stati preparati.
- I dati del test sono stati creati.
- L'ambiente per il test è pronto, tutti gli strumenti necessari sono disponibili e pronti.
- L'applicazione completa o parziale viene sviluppata e testata in unità ed è pronta per il test.
Criteri di uscita:
- L'esecuzione di tutti i casi di test funzionali è stata completata.
- Nessun bug critico o P1, P2 sono aperti.
- I bug segnalati sono stati riconosciuti.
Passaggi coinvolti
I vari passaggi coinvolti in questo test sono menzionati di seguito:
- Il primo passo in questione è determinare la funzionalità del prodotto che deve essere testato e include test delle funzionalità principali, condizioni di errore e messaggi, test di usabilità, ovvero se il prodotto è facile da usare o meno, ecc.
- Il passaggio successivo consiste nel creare i dati di input per la funzionalità da testare secondo la specifica del requisito.
- Successivamente, dalla specifica del requisito, viene determinato l'output per la funzionalità in prova.
- Vengono eseguiti casi di test preparati.
- L'output effettivo, ovvero l'output dopo l'esecuzione del test case e l'output previsto (determinato dalla specifica dei requisiti) vengono confrontati per scoprire se la funzionalità funziona come previsto o meno.
Approccio
Diversi tipi di scenari possono essere pensati e creati sotto forma di 'casi di test'. Come persone addette al QA, sappiamo tutti come appare lo scheletro di un caso di test.
Per lo più ha quattro parti:
- Riepilogo del test
- Prerequisiti
- Passaggi di prova e
- Risultati aspettati.
Tentare di creare ogni tipo di test non solo è impossibile, ma richiede anche tempo e denaro.
Tipicamente, vorremmo scoprire il massimo dei bug senza alcuna fuga con i test esistenti. Pertanto, il QA deve utilizzare tecniche di ottimizzazione e strategizzare il modo in cui si approcciano al test.
Spieghiamo questo con un esempio.
Esempi di casi d'uso dei test funzionali:
Prendi un portale HRMS online in cui il dipendente accede con il suo account utente e password. Nella pagina di accesso sono presenti due campi di testo per nome utente e password e due pulsanti: Accedi e Annulla. L'accesso riuscito porta l'utente alla home page di HRMS e l'annullamento annullerà l'accesso.
Le specifiche sono come mostrato di seguito:
# 1) Il campo ID utente richiede un minimo di 6 caratteri, un massimo di 10 caratteri, numeri (0-9), lettere (a-z, A-z), caratteri speciali (solo trattino basso, punto, trattino consentito) e non può essere lasciato vuoto. L'ID utente deve iniziare con un carattere o un numero e non con caratteri speciali.
#Due) Il campo della password può contenere un minimo di 6 caratteri, un massimo di 8 caratteri, numeri (0-9), lettere (a-z, A-Z), caratteri speciali (tutti) e non può essere lasciato vuoto.
L'approccio di base per testare questo scenario può essere classificato in due grandi categorie:
- Test positivi e
- Test negativo
Ovviamente ciascuna di queste categorie ha la sua sottosezione di test che verranno eseguiti.
Test positivi sono test di percorso felici che vengono eseguiti per garantire che il prodotto soddisfi, almeno i requisiti di base che sono vitali per l'utilizzo del cliente.
Scenari negativi assicurarsi che il prodotto si comporti correttamente anche se sottoposto a dati imprevisti.
Lettura suggerita => Che cos'è il test negativo e come scrivere casi di test negativi
Ora, provo a strutturare le tecniche di test utilizzando un diagramma di flusso di seguito. Entreremo nei dettagli di ciascuno di questi test.
Tecniche di test funzionale
# 1) Test di sistema / basati sull'utente finale
Il sistema in prova può avere molti componenti che, se accoppiati insieme, realizzano lo scenario utente.
Nel Esempio , uno scenario del cliente includerebbe attività come il caricamento dell'applicazione HRMS, l'inserimento delle credenziali corrette, l'accesso alla home page, l'esecuzione di alcune azioni e la disconnessione dal sistema. Questo flusso particolare deve funzionare senza errori per uno scenario aziendale di base.
quale non è un esempio di data mining?
Di seguito sono riportati alcuni esempi:
Sl No | Sommario | Pre-requisito | Scenario di prova | Risultati aspettati. |
---|---|---|---|---|
1. | L'utente con privilegi completi può apportare modifiche all'account | 1) L'account utente deve esistere 2) L'utente deve disporre dei privilegi richiesti | 1) L'utente inserisce l'ID utente e la password 2) L'utente vede i permessi di modifica per modificare l'account stesso 3) L'utente modifica le informazioni sull'account e le salva. 4) L'utente si disconnette. | 1) L'utente è loggato nella home page 2) La schermata di modifica viene presentata all'utente. 3) Le informazioni sull'account vengono salvate 4) L'utente viene riportato alla pagina di accesso |
2. | Un altro utente valido senza privilegi completi | 1) L'account utente deve esistere 2) L'utente deve disporre dei privilegi minimi | 1) L'utente inserisce l'ID utente e la password 2) L'utente vede i permessi di modifica per modificare solo alcuni campi. 3) L'utente modifica solo quei campi e salva. 4) L'utente si disconnette. | 1) L'utente è loggato nella home page 2) La schermata di modifica viene presentata all'utente solo su determinati campi. I campi dell'account sono disattivati. 3) I campi modificati vengono salvati 4) L'utente viene riportato alla pagina di accesso |
Questo è un esempio di base di come vengono creati i casi di test per le situazioni. Il formato sopra si applicherà anche a tutti i test seguenti. Per motivi di solida base concettuale, ho inserito solo alcuni semplici test sopra e sotto.
# 2) Test di equivalenza
Nel Partizionamento di equivalenza , i dati di test sono separati in varie partizioni chiamate classi di dati di equivalenza. I dati in ciascuna partizione devono comportarsi allo stesso modo, quindi è necessario testare solo una condizione. Allo stesso modo, se una condizione in una partizione non funziona, nessuna delle altre funzionerà.
Per esempio , nello scenario precedente il campo ID utente può contenere un massimo di 10 caratteri, quindi l'inserimento di dati> 10 dovrebbe comportarsi allo stesso modo.
# 3) Test del valore limite
I test di confine implicano limiti di dati per l'applicazione e convalidano il modo in cui si comporta.
Pertanto, se gli input vengono forniti oltre i valori limite, viene considerato un test negativo. Quindi un minimo di 6 caratteri per l'utente imposta il limite di confine. Test scritti per avere l'ID utente<6 characters are boundary analysis tests.
# 4) Test basati sulla decisione
I test basati sulle decisioni sono incentrati sull'ideologia dei possibili risultati del sistema quando viene soddisfatta una particolare condizione.
Nello scenario sopra indicato, è possibile derivare immediatamente i seguenti test basati sulla decisione:
- Se vengono inserite credenziali sbagliate, dovrebbe indicarlo all'utente e ricaricare la pagina di accesso.
- Se l'utente immette le credenziali corrette, dovrebbe portarlo all'interfaccia utente successiva.
- Se l'utente immette le credenziali corrette ma desidera annullare il login, non dovrebbe portarlo alla successiva interfaccia utente e ricaricare la pagina di login.
# 5) Test di flusso alternativo
Vengono eseguiti test del percorso alternativo per convalidare tutti i possibili modi esistenti, oltre al flusso principale, per eseguire una funzione.
# 6) Test ad hoc
Quando la maggior parte dei bug vengono scoperti attraverso le tecniche di cui sopra, test ad hoc sono un ottimo modo per scoprire eventuali discrepanze che non sono state osservate in precedenza. Questi vengono eseguiti con la mentalità di rompere il sistema e vedere se risponde con grazia.
Per esempio , un esempio di test case sarebbe:
- Un utente ha effettuato l'accesso, ma l'amministratore elimina l'account utente mentre esegue alcune operazioni. Sarebbe interessante vedere come l'applicazione gestisce questo con garbo.
Test funzionali vs non funzionali:
Test non funzionali concentrarsi sulla qualità dell'applicazione / sistema nel suo complesso. Quindi, cerca di dedurre quanto bene il sistema si comporta secondo i requisiti del cliente in contrasto con la funzione che svolge.
=> Leggi la differenza esatta qui
Automazione del test funzionale
Possiamo automatizzare i test funzionali?
Con l'automazione è possibile ridurre lo sforzo manuale, risparmiare tempo, evitare errori e aumentare l'efficienza.
Tuttavia, non è possibile automatizzare tutto e tutti. Questo test può essere automatizzato, ma l'utente deve elaborare i casi di test affinché l'automazione venga eseguita. È importante trovare i casi di test giusti da automatizzare insieme a uno strumento appropriato.
L'automazione dei casi funzionali può avere svantaggi, ad esempio se il numero di casi di test è molto maggiore e viene regredito ancora e ancora (cosa che deve essere eseguita), lo sviluppatore potrebbe dover affrontare un problema nel confermare le modifiche al codice.
Molte volte durante l'esecuzione dell'analisi di fuga dei difetti, la causa principale e perenne delle fughe sembra avere una mancanza di copertura del test in una particolare funzione.
Ancora una volta, ci sono diverse cause per cui ciò si verifica come la mancanza di ambienti, la mancanza di tester, troppe funzioni fornite, meno tempo per coprire tutti gli aspetti del test e talvolta semplicemente trascurarlo.
Sebbene team di test dedicati possano eseguire test dettagliati su ogni sprint o ciclo di test, i difetti esisteranno sempre e ci saranno sempre difetti che potrebbero essere persi. Questa è una delle esigenze fondamentali per avere in atto l'automazione dei test, con un netto miglioramento dell'efficienza del processo di test complessivo e della copertura dei casi di test.
Sebbene i test automatizzati non possano mai sostituire i test manuali, disporre di un mix ideale dei due si rivelerà fondamentale per ottenere la qualità desiderata nei progetti software.
Considerazioni sull'automazione:
# 1) Seleziona lo strumento di automazione corretto : Ci sono diversi strumenti disponibili sul mercato, scegliere uno strumento di automazione è un compito davvero arduo! Tuttavia, è possibile creare un elenco di requisiti, in base al quale è possibile selezionare lo strumento di automazione da utilizzare.
Alcuni aspetti principali a cui pensare includono:
- Seleziona uno strumento che sarà facile da usare da tutti i membri del team QA, se non hanno già le competenze richieste.
- Lo strumento può essere utilizzato in diversi ambienti. Per Esempio : Gli script possono essere creati su una piattaforma OS ed essere eseguiti su un'altra? Hai bisogno di automazione CLI, automazione dell'interfaccia utente, automazione delle applicazioni mobili o tutto?
- Lo strumento deve avere tutte le funzionalità richieste. Per Esempio : Se alcuni tester non sono esperti con un linguaggio di scripting, lo strumento dovrebbe avere una funzione di registrazione e riproduzione e quindi supportare la conversione dello script registrato nel linguaggio di scripting desiderato. Allo stesso modo, se è necessario che lo strumento supporti anche test di compilazione automatizzati, rapporti specifici e registrazione, deve essere in grado di farlo anche.
- Lo strumento deve essere in grado di supportare la riusabilità dei casi di test in caso di modifiche all'interfaccia utente.
Strumenti di automazione : Ci sono alcuni strumenti disponibili per l'automazione funzionale. Il selenio è probabilmente uno dei preferiti, ma ci sono anche altri strumenti open source come Sahi, Watir, Robotium, AutoIt, ecc.
Sul mercato sono disponibili diversi strumenti di automazione dei test. Ma la scelta dello strumento appropriato è molto importante per l'organizzazione. Potrebbe dipendere dai requisiti, dalla facilità d'uso e dal costo gioca un ruolo importante qui.
Di seguito sono riportati alcuni dei migliori strumenti di test funzionale:
- Selenio
- QTP
- Junit
- Loadrunner
- SAPONE
- TestComplete
=> Controlla questo elenco completo dei migliori strumenti di automazione funzionale
#Due) Scegli i casi di test giusti da automatizzare : Se vuoi ottenere il meglio dall'automazione, è fondamentale essere intelligenti riguardo al tipo di test che scegli di automatizzare. Se ci sono test che richiedono alcune impostazioni e configurazioni attive e disattivate durante l'esecuzione del test, è meglio lasciarli non automatizzati.
Pertanto, puoi automatizzare i test che:
- Devono essere eseguiti ripetutamente.
- Esegui con diversi tipi di dati.
- Alcuni casi di test P1 e P2 richiedono molto tempo e impegno.
- Test soggetti a errori.
- Insieme di test che devono essere eseguiti in diversi ambienti, browser, ecc.
# 3) Team dedicato all'automazione : Questo aspetto è probabilmente trascurato nella maggior parte delle organizzazioni e l'automazione è imposta a tutti i membri del team QA.
Ogni membro del team ha diversi livelli di esperienza, set di abilità, livelli di interesse, larghezza di banda per supportare l'automazione, ecc. Alcuni individui sono forse più abili nell'esecuzione di test manuali, mentre altri potrebbero conoscere strumenti di scripting e automazione.
In situazioni come questa, è buona norma fare un'analisi di tutti i membri del team e avere alcuni membri dedicati a fare solo automazione.
L'attività di automazione richiede tempo, impegno, conoscenza e un team dedicato che aiuterà a ottenere i risultati richiesti invece di sovraccaricare tutti i membri del team con test manuali e di automazione.
# 4) Test basati sui dati: I casi di test automatizzati che richiedono più set di dati devono essere scritti correttamente in modo che possano essere riutilizzati. I dati possono essere scritti in sorgenti come file di testo o proprietà, file XML o letti da un database.
Qualunque sia l'origine dati, la creazione di dati di automazione ben strutturati semplifica la manutenzione del framework e rende gli script di test esistenti utilizzati al massimo delle loro potenzialità.
# 5) Le modifiche all'interfaccia utente non devono interrompere i test: I casi di test che crei utilizzando lo strumento selezionato devono essere in grado di gestire le potenziali modifiche dell'interfaccia utente. Ad esempio, le versioni precedenti del selenio utilizzavano una posizione per identificare gli elementi della pagina.
Quindi, se l'interfaccia utente è cambiata, quegli elementi non sono stati più trovati in quelle posizioni e, a loro volta, porteranno al fallimento di massa dei test.
Pertanto, è importante comprendere in anticipo le carenze dello strumento e creare i casi di test in modo tale che siano necessarie solo modifiche minime in caso di modifiche dell'interfaccia utente.
# 6) Test frequenti: Una volta che hai pronto un bucket di test di automazione di base, pianifica un'esecuzione più frequente di questo bucket. Questo ha un vantaggio a due vie: uno è che puoi migliorare il framework di automazione e renderlo più robusto e il secondo è che rileverai più bug nel processo.
Vantaggi
Di seguito sono elencati i vari vantaggi del test funzionale:
- Questo test riproduce o è una replica di ciò che è il sistema effettivo, ovvero è una replica di ciò che il prodotto è nell'ambiente live. Il test si concentra sulle specifiche in base all'utilizzo del cliente, ad esempio specifiche di sistema, sistema operativo, browser, ecc.
- Non funziona su alcun se e ma o su qualsiasi ipotesi sulla struttura del sistema.
- Questo test garantisce la fornitura di un prodotto di alta qualità che soddisfi i requisiti del cliente e si assicura che il cliente sia soddisfatto dei risultati finali.
- Garantisce la fornitura di un prodotto privo di bug che ha tutte le funzionalità che funzionano secondo le esigenze del cliente.
- Il test basato sul rischio viene eseguito per ridurre le possibilità di qualsiasi tipo di rischio nel prodotto.
Limitazioni
Questo test viene eseguito per assicurarsi che il prodotto funzioni come previsto e che l'intero requisito sia implementato e che il prodotto sia esattamente come richiesto dal cliente.
Tuttavia, non considera gli altri fattori come le prestazioni del prodotto, ovvero la reattività, il tempo di elaborazione, ecc., Che sono importanti e molto richiesti per essere parte del test prima di rilasciare il prodotto.
Svantaggi
- Ci sono molte possibilità di eseguire test ridondanti.
- Gli errori logici possono essere persi nel prodotto.
- Questo test si basa sul requisito, se nel caso in cui il requisito non è completo o complicato o non è chiaro, eseguire questo test in tale scenario diventa difficile e può richiedere anche molto tempo.
Quindi, fondamentalmente, entrambi questi tipi di test sono necessari per un prodotto di qualità.
Conclusione
Questo tutorial ha discusso in modo esauriente tutto ciò che è necessario sapere sui test funzionali, fin dalle basi.
Il test funzionale è uno dei processi di test più importanti in quanto verifica la funzionalità di un prodotto che è l'aspetto più richiesto e anzi importante di qualsiasi prodotto o applicazione.
Circa l'autore: Sanjay Zalavadia - come vicepresidente del servizio clienti per Zephyr , porta oltre 15 anni di esperienza di leadership nei servizi di supporto tecnico e IT.
Spero che alcune delle tecniche che abbiamo suggerito torneranno utili per tutti i lettori. Fateci sapere i vostri pensieri nei commenti qui sotto.
Lettura suggerita => Esercitazione sul test delle funzionalità
Lettura consigliata
- Test funzionale vs test non funzionale
- Alpha test e beta test (una guida completa)
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Le differenze tra test unitari, test di integrazione e test funzionali
- Tipi di test del software: diversi tipi di test con dettagli
- Spock per integrazione e test funzionali con selenio
- Guida completa al test di verifica della costruzione (test BVT)
- Una guida completa ai test non funzionali per principianti