Menu

Che cos'è il test di automazione (Guida definitiva per avviare l'automazione del test)

what is automation testing

Prova Il Nostro Strumento Per Eliminare I Problemi

Una guida completa per avviare il test di automazione sul tuo progetto:

Cos'è il test di automazione?

Il test di automazione è una tecnica di test del software per testare e confrontare il risultato effettivo con il risultato atteso. Ciò può essere ottenuto scrivendo script di test o utilizzando qualsiasi strumento di test di automazione. L'automazione del test viene utilizzata per automatizzare le attività ripetitive e altre attività di test che sono difficili da eseguire manualmente.

guida ai test di automazione

Vuoi iniziare il test di automazione sul tuo progetto ma stai lottando con i passaggi più basilari come indicato di seguito:

  • Come introdurre l'automazione nel tuo progetto?
  • Come selezionare lo strumento di automazione migliore e giusto?
  • Come sviluppare gli script in modo efficace?
  • Come eseguire e mantenere gli script di test?
  • E infine quali sono le migliori pratiche da seguire per eseguire test di automazione di successo?

Oggi abbiamo pianificato di arricchire le tue conoscenze con una serie di tutorial su ' Introduzione ai test di automazione '. Questa serie di tutorial sull'automazione risponderà a tutte le domande di cui sopra in modo graduale con semplici esempi.

Diamo un'occhiata alla serie di tutorial sull'avvio dell'automazione nel tuo progetto !!

Processo end-to-end di automazione:

Tutorial n. 1 : La migliore guida per avviare l'automazione sul tuo progetto
Tutorial n. 2: Tipi di test automatici e alcune idee sbagliate
Tutorial n. 3: 10 passaggi per introdurre l'automazione nel tuo progetto
Tutorial n. 4: La guida dalla A alla Z sulla selezione del miglior strumento di automazione
Tutorial n. 5: Sviluppo di script e framework di automazione
Tutorial # 6: Esecuzione e reportistica dell'automazione
Tutorial # 7: Migliori pratiche e strategie di automazione del test

Suggerimenti per l'automazione:

Tutorial n. 8: 10 suggerimenti da leggere prima di automatizzare il lavoro di test
Tutorial n. 9: In che modo differisce la pianificazione dei test per i progetti manuali e di automazione
Tutorial n.10: Quando optare per l'automazione?
Tutorial n. 11: Sfide dei test di automazione
Tutorial n. 12: Guida all'implementazione del POC (Proof of Concept) nell'automazione
Tutorial n.13: Come selezionare i casi di test corretti per l'automazione
Tutorial n. 14: Come tradurre casi di test manuali in script di automazione

Carriera nell'automazione:

Tutorial # 15: Suggerimenti per diventare un tester di automazione migliore
Tutorial n. 16: Test Automation - È una carriera specializzata? I normali tester possono eseguire anche l'automazione?

Strumenti di automazione popolari:

Tutorial n. 17: Tutorial sul selenio 31+ I migliori tutorial gratuiti per la formazione sul selenio
Tutorial n. 18: Tutorial QTP
Tutorial n. 19: Strumento di test dei servizi Web SoapUI
Tutorial n. 20: HP LoadRunner per test delle prestazioni

Quadri di automazione:

Tutorial n. 21: Perché abbiamo bisogno di Framework per l'automazione
Tutorial n. 22: I framework di automazione più popolari

Automazione in Agile:

Tutorial n. 23: Come implementare un'automazione efficiente nel mondo Agile

Altri strumenti di automazione:

Tutorial n. 24: I migliori strumenti di test di automazione
Tutorial n.25: Sikuli GUI Automation Tool
Tutorial # 26: PowerShell: automazione dell'interfaccia utente dell'applicazione desktop con PowerShell
Tutorial # 27: Catalon Automation Recorder (alternativa IDE al selenio)
Tutorial n. 28: Strumento Geb: automazione del browser utilizzando lo strumento Geb
Tutorial n. 29: AutoIt: come gestire i popup di Windows utilizzando AutoIt
Tutorial # 30: Cetriolo: automazione utilizzando lo strumento di cetriolo e il selenio
Tutorial # 31: Strumento di test del goniometro per test end-to-end di applicazioni AngularJS

Test di automazione mobile:

Tutorial # 32: Tutorial pratico di Appium Studio
Tutorial # 33: Tutorial Appium per principianti
Tutorial # 34: Tutorial Selendroid: Android Mobile Automation Framework
Tutorial # 35: Tutorial Ranorex: un potente strumento di test per desktop, Web e dispositivi mobili

Esempi di automazione specifici del dominio:

Tutorial # 36: Automazione delle applicazioni JAVA / J2EE

Preparazione al colloquio per lavori di automazione:

Tutorial # 37: Domande di intervista sul test di automazione
Tutorial n. 38: Domande di intervista al selenio

Esploriamo il primo tutorial della serie 'The Ultimate Guide to Automation Testing' !!

Cosa imparerai:

Cos'è il test di automazione?

Se un software può fare qualsiasi cosa, perché un software non può testare un software?

Questa affermazione ti sembra logica?

Se sì, congratulazioni, ora stai pensando all'automazione del test, che è il punto centrale di cui parleremo in questa serie di tutorial informativi.

Immagina di essere il primo giorno di lavoro come SQA. Ti viene presentata un'applicazione da testare. È un'applicazione ERP che contiene centinaia di moduli e migliaia di rapporti. Inizi il tuo test esplorativo aprendo un modulo che contiene circa 50 campi diversi.

Si tenta di inserire dati casuali in questo modulo che hanno richiesto circa 20 minuti. Quindi premi invia. Wolla !! Viene visualizzato un messaggio di errore che sembra un'eccezione non gestita. Diventi molto felice. Annoti con orgoglio i passaggi e segnala il bug nel tuo sistema di gestione dei bug. Grande sforzo, ti senti davvero fiducioso ed energico. Continui il test fino alla fine della giornata e trovi altri bug. 'Fantastico primo giorno', hai pensato.

Ora arriva il giorno successivo, lo sviluppatore ha risolto il problema e rilascia una nuova versione della build. Provi lo stesso modulo con gli stessi passaggi e hai scoperto che il bug è stato risolto. Lo contrassegni come fisso. Grande sforzo. Hai contribuito alla qualità del prodotto identificando quel bug e poiché questo bug viene corretto, la qualità è migliorata.

Ora arriva il terzo giorno, uno sviluppatore ha rilasciato di nuovo una versione più recente. Ora devi nuovamente testare quel modulo per assicurarti che non venga trovato alcun problema di regressione. Stessi 20 minuti. Adesso ti senti un po 'annoiato.

Ora immagina 1 mese da ora in poi, le versioni più recenti vengono rilasciate costantemente e ad ogni rilascio, devi testare questo lungo modulo più 100 di altri moduli come questo, solo per assicurarti che non ci sia alcuna regressione.

unix shell scripting intervista domande e risposte per esperti

Adesso ti senti arrabbiato. Ti senti stanco . Inizi a saltare i passaggi. Riempi solo il 50% circa dei campi totali. La tua precisione non è la stessa, la tua energia non è la stessa e sicuramente i tuoi passi non sono gli stessi.

E un giorno, il client segnala lo stesso bug nella stessa forma. Ti senti patetico. Non ti senti sicuro adesso. Pensi di non essere abbastanza competente. I manager stanno mettendo in dubbio le tue capacità.

Ho una notizia per te; questa è la storia del 90% dei tester manuali là fuori. Non sei diverso.

I problemi di regressione sono i problemi più dolorosi. Siamo esseri umani. E non possiamo fare la stessa cosa con la stessa energia, velocità e precisione ogni giorno. Questo è ciò che fanno le macchine. A questo serve l'automazione, per ripetere gli stessi passaggi con la stessa velocità, precisione ed energia con cui sono stati ripetuti la prima volta.

Spero che tu colga la mia puntualizzazione!!

automazione testare un amico

Ogni volta che si verifica una situazione del genere, è necessario automatizzare lo scenario di test. L'automazione dei test è tua amica . Ti aiuterà a concentrarti su nuove funzionalità mentre ti prendi cura delle regressioni. Con l'automazione, puoi compilare quel modulo in meno di 3 minuti.

Lo script riempirà tutti i campi e ti dirà il risultato insieme agli screenshot. In caso di guasto, può individuare la posizione in cui il test case ha fallito, aiutandoti così a riprodurlo con facilità.

Automazione: un metodo conveniente per i test di regressione

I costi di automazione sono inizialmente molto più alti. Include il costo dello strumento, quindi il costo della risorsa di test dell'automazione e la sua formazione.

Ma quando gli script sono pronti, possono essere eseguiti centinaia di volte ripetutamente con la stessa precisione e piuttosto rapidamente. Ciò consentirà di risparmiare molte ore di test manuali. Quindi il costo diminuisce gradualmente e alla fine diventa un metodo conveniente per Test di regressione .

Scenari che richiedono l'automazione

Lo scenario di cui sopra non è l'unico caso in cui avrai bisogno di test di automazione. Esistono diverse situazioni che non possono essere verificate manualmente.

Per esempio ,

  1. Confronto di due immagini pixel per pixel.
  2. Confronto di due fogli di calcolo contenenti migliaia di righe e colonne.
  3. Test di un'applicazione sotto il carico di 100.000 utenti.
  4. Benchmark delle prestazioni.
  5. Testare l'applicazione su diversi browser e su diversi sistemi operativi in ​​parallelo.

Queste situazioni richiedono e dovrebbero essere testate da strumenti.

Quindi, quando automatizzare?

Questa è un'era di metodologia agile in SDLC, dove lo sviluppo e il test andranno quasi in parallelo ed è molto difficile decidere quando automatizzare.

Considerare le seguenti situazioni prima di passare all'automazione

  • Il prodotto può essere nelle sue fasi primitive, quando il prodotto non ha nemmeno un'interfaccia utente, in queste fasi dobbiamo avere un pensiero chiaro su ciò che vogliamo automatizzare. I seguenti punti dovrebbero essere ricordati.
    • I test non dovrebbero essere obsoleti.
    • Man mano che il prodotto si evolve, dovrebbe essere facile scegliere gli script e aggiungerli.
    • È molto importante non lasciarsi trasportare e assicurarsi che gli script siano facili da eseguire il debug.
  • Non tentare l'automazione dell'interfaccia utente nelle fasi iniziali poiché l'interfaccia utente è soggetta a frequenti modifiche, quindi gli script non funzioneranno. Per quanto possibile, optare per l'automazione a livello API / Non UI fino a quando il prodotto non si stabilizza. L'automazione delle API è facile da correggere ed eseguire il debug.

Come decidere i migliori casi di automazione:

L'automazione è parte integrante di un ciclo di test ed è molto importante decidere cosa vogliamo ottenere con l'automazione prima di decidere di automatizzare.

I vantaggi che l'automazione sembra fornire sono molto interessanti, ma allo stesso tempo una suite di automazione mal organizzata può rovinare l'intero gioco. I tester possono finire per eseguire il debug e correggere gli script il più delle volte con conseguente perdita di tempo per il test.

Efficiente automazione dei test

Questa serie spiega come una suite di automazione può essere resa abbastanza efficiente da raccogliere i casi di test giusti e produrre i risultati giusti con gli script di automazione che abbiamo.

Inoltre, ho coperto le risposte a domande come Quando automatizzare, Cosa automatizzare, Cosa non automatizzare e Come strategizzare l'automazione.

Test giusti per l'automazione

Il modo migliore per affrontare questo problema è trovare rapidamente una 'Strategia di automazione' adatta al nostro prodotto.

L'idea è di raggruppare i casi di test in modo che ogni gruppo ci dia un diverso tipo di risultato. L'illustrazione riportata di seguito mostra come possiamo raggruppare i nostri casi di test simili, a seconda del prodotto / soluzione che stiamo testando.

Raggruppamento di casi di test

Cerchiamo ora di approfondire e capire cosa ogni gruppo può aiutarci a ottenere:

# 1) Crea una suite di test di tutte le funzionalità di base Test positivi . Questa suite dovrebbe essere automatizzata e quando questa suite viene eseguita su qualsiasi build, i risultati vengono visualizzati immediatamente. Qualsiasi errore di script in questa suite porta a un difetto S1 o S2 e quella build specifica può essere squalificata. Quindi abbiamo risparmiato molto tempo qui.

Come passaggio aggiuntivo, possiamo aggiungere questa suite di test automatizzati come parte di BVT (Test di verifica della build) e controllare gli script di automazione del QA nel processo di creazione del prodotto. Quindi, quando la build è pronta, i tester possono verificare i risultati del test di automazione e decidere se la build è adatta o meno per l'installazione e l'ulteriore processo di test.

Ciò raggiunge chiaramente gli obiettivi dell'automazione che sono:

  • Riduci lo sforzo di test.
  • Trova bug nelle fasi iniziali.

#Due) Successivamente, abbiamo un gruppo di Test end to end .

In soluzioni di grandi dimensioni, la verifica di una funzionalità end-to-end è la chiave, soprattutto durante le fasi critiche del progetto. Dovremmo avere alcuni script di automazione che toccano anche i test della soluzione end-to-end. Quando viene eseguita questa suite, il risultato dovrebbe indicare se il prodotto nel suo insieme funziona come previsto o meno.

La suite di test di automazione dovrebbe essere indicata se uno qualsiasi dei pezzi di integrazione è rotto. Questa suite non deve coprire ogni piccola caratteristica / funzionalità della soluzione, ma dovrebbe coprire il funzionamento del prodotto nel suo insieme. Ogni volta che abbiamo una versione alpha o beta o qualsiasi altra versione intermedia, questi script tornano utili e danno un certo livello di fiducia al cliente.

Per capire meglio, supponiamo che stiamo testando un portale per lo shopping online , come parte dei test end-to-end, dovremmo coprire solo i passaggi chiave coinvolti.

Come indicato di seguito:

  • Login utente.
  • Sfoglia e seleziona gli elementi.
  • Opzione di pagamento: copre i test front-end.
  • Gestione degli ordini di backend (implica la comunicazione con più partner integrati, il controllo delle scorte, l'invio di e-mail all'utente, ecc.) - Questo aiuterà l'integrazione di test dei singoli pezzi e anche il punto cruciale del prodotto.

Quindi, quando viene eseguito uno di questi script, si ha la certezza che la soluzione nel suo insieme funzioni correttamente.!

# 3) Il terzo set è il Test basati su funzionalità / funzionalità .

Per esempio , Potremmo avere la funzionalità per sfogliare e selezionare un file, quindi quando lo automatizziamo possiamo automatizzare i casi per includere la selezione di diversi tipi di file, dimensioni dei file ecc., In modo che venga eseguito il test delle funzionalità. Quando ci sono modifiche / aggiunte a quella funzionalità, questa suite può fungere da suite di regressione.

# 4) Il prossimo sulla lista sarebbe Test basati sull'interfaccia utente. Possiamo avere un'altra suite che testerà funzionalità basate esclusivamente sull'interfaccia utente come l'impaginazione, la limitazione dei caratteri della casella di testo, il pulsante del calendario, i menu a discesa, i grafici, le immagini e molte di queste funzionalità incentrate esclusivamente sull'interfaccia utente. Il fallimento di questi script di solito non è molto critico a meno che l'interfaccia utente non sia completamente inattiva o alcune pagine non vengano visualizzate come previsto!

# 5) Possiamo avere ancora un'altra serie di test che sono semplici ma molto laboriosi da eseguire manualmente. I test noiosi ma semplici sono i candidati ideali per l'automazione, ad esempio l'immissione dei dettagli di 1000 clienti nel database ha una funzionalità semplice ma estremamente noiosa da eseguire manualmente, tali test dovrebbero essere automatizzati. In caso contrario, finiscono per essere ignorati e non testati.

Cosa NON automatizzare?

Di seguito sono riportati alcuni test che non dovrebbero essere automatizzati.

# 1) Test negativi / test di failover

Non dovremmo tentare di automatizzare test negativi o di failover , poiché per questi test i tester devono pensare in modo analitico e i test negativi non sono molto semplici per dare un risultato positivo o negativo che può aiutarci.

I test negativi richiederanno molti interventi manuali per simulare un tipo di scenario di ripristino di emergenza effettivo. Solo per esemplificare, stiamo testando funzionalità come l'affidabilità dei servizi web: per generalizzarla qui, l'obiettivo principale di tali test sarebbe causare guasti deliberati e vedere quanto bene il prodotto riesce ad essere affidabile.

La simulazione degli errori di cui sopra non è semplice, può comportare l'iniezione di alcuni stub o l'uso di alcuni strumenti intermedi e l'automazione non è il modo migliore per andare qui.

# 2) Test ad hoc

Questi test potrebbero non essere sempre rilevanti per un prodotto e questo potrebbe anche essere qualcosa a cui il tester potrebbe pensare in quella fase di avvio del progetto, e anche lo sforzo per automatizzare un test ad-hoc deve essere convalidato rispetto alla criticità della caratteristica toccata dai test.

Per esempio , Un tester che sta testando una funzionalità che si occupa della compressione / crittografia dei dati potrebbe aver eseguito intensi test ad hoc con la varietà di dati, tipi di file, dimensioni dei file, dati corrotti, una combinazione di dati, utilizzando algoritmi diversi, su diversi piattaforme ecc.

Quando pianifichiamo automazione potremmo voler dare la priorità e non fare un'automazione esaustiva di tutti i test ad hoc solo per quella funzione, e finire con un po 'di tempo per automatizzare le altre funzionalità chiave.

# 3) Test con una massiccia pre-configurazione

Ci sono test che richiedono enormi prerequisiti.

Per esempio, Potremmo avere un prodotto che si integra con un software di terze parti per alcune delle funzioni, poiché il prodotto si integra con qualsiasi sistema di code di messaggistica che richiede installazione su un sistema, impostazione di code, creazione di code ecc.

Il 3rdil software di terze parti potrebbe essere qualsiasi cosa e la configurazione potrebbe essere di natura complessa e se tali script sono automatizzati, questi dipenderanno per sempre dalla funzione / configurazione di quel software di terze parti.

I prerequisiti includono:

Al momento le cose possono sembrare semplici e pulite dato che entrambe le configurazioni laterali sono in corso e tutto va bene. Abbiamo visto in numerose occasioni che quando un progetto entra nella fase di manutenzione il progetto viene spostato in un altro team, e finiscono per eseguire il debug di tali script in cui il test effettivo è molto semplice ma lo script fallisce a causa di un 3rdproblema con il software del party.

Quanto sopra è solo un esempio, in generale, tieni d'occhio i test che hanno laboriosi pre setup per un semplice test che segue.

Semplice esempio di automazione del test

Quando provi un software (sul Web o sul desktop), normalmente utilizzi un mouse e una tastiera per eseguire i tuoi passaggi. Lo strumento di automazione imita gli stessi passaggi utilizzando script o un linguaggio di programmazione.

Per esempio , se stai testando una calcolatrice e il caso di test è che devi aggiungere due numeri e vedere il risultato. Lo script eseguirà gli stessi passaggi utilizzando il mouse e la tastiera.

download gratuito del firewall per Windows 10

L'esempio è mostrato di seguito.

Passaggi del caso di test manuale:

  1. Avvia Calcolatrice
  2. Premere 2
  3. Premi +
  4. Premere 3
  5. Premere =
  6. Lo schermo dovrebbe visualizzare 5.
  7. Chiudi calcolatrice.

Script di automazione:

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

Lo script sopra è solo una duplicazione dei passaggi manuali. Lo script è facile da creare e anche facile da capire.

Cosa sono le asserzioni?

La penultima riga dello script necessita di qualche spiegazione in più.

Assert.AreEqual ('5', txtResult.DisplayText, 'Calculator non mostra 5);

In ogni caso di test, abbiamo un risultato atteso o previsto alla fine. Nello script precedente, ci aspettiamo che sullo schermo venga visualizzato '5'. Il risultato effettivo è il risultato visualizzato sullo schermo. In ogni caso di test, confrontiamo il risultato atteso con il risultato effettivo.

Lo stesso vale anche per i test di automazione. L'unica differenza qui è che, quando facciamo questo confronto nell'automazione dei test, viene chiamato qualcos'altro in ogni strumento.

Alcuni strumenti lo chiamano ' Asserzione ', Alcuni lo chiamano' punto di controllo 'E alcuni lo chiamano' convalida '. Ma fondamentalmente, questo è solo un confronto. Se questo confronto fallisce, per Per esempio. una schermata mostra 15 invece di 5, quindi questa asserzione / checkpoint / convalida non riesce e il tuo caso di test viene contrassegnato come non riuscito.

Quando un test case fallisce a causa di un'asserzione, significa che hai rilevato un bug tramite l'automazione del test. Devi segnalarlo al tuo sistema di gestione dei bug proprio come fai normalmente nei test manuali.

Nello script precedente, abbiamo eseguito un'asserzione nella penultima riga. 5 è il risultato atteso, txtResult . DisplayText è il risultato effettivo e se non sono uguali, ci verrà mostrato un messaggio che 'La calcolatrice non mostra 5'.

Conclusione

Spesso i tester incontrano scadenze di progetto e mandati per automatizzare tutti i casi per migliorare le stime dei test.

Ci sono alcune percezioni 'sbagliate' comuni sull'automazione.

Sono:

  • Possiamo automatizzare ogni caso di test.
  • L'automazione dei test ridurrà enormemente i tempi di test.
  • Non vengono introdotti bug se gli script di automazione funzionano senza problemi.

Dovremmo essere chiari sul fatto che l'automazione può ridurre i tempi di test solo per determinati tipi di test. L'automazione di tutti i test senza alcun piano o sequenza porterà a script di grandi dimensioni che richiedono una manutenzione pesante, falliscono spesso e richiedono anche molti interventi manuali. Inoltre, in prodotti in continua evoluzione, gli script di automazione possono diventare obsoleti e richiedere controlli costanti.

Raggruppare e automatizzare i candidati giusti farà risparmiare molto tempo e offrirà tutti i vantaggi dell'automazione.

Questo eccellente tutorial può essere riassunto in soli 7 punti.

Test di automazione:

  • È il test che viene eseguito a livello di programmazione.
  • Utilizza lo strumento per controllare l'esecuzione dei test.
  • Confronta i risultati attesi con i risultati effettivi (asserzioni).
  • Può automatizzare alcune attività ripetitive ma necessarie ( Per esempio. I tuoi casi di test di regressione).
  • Può automatizzare alcune attività difficili da eseguire manualmente (Per esempio.Scenari di test di carico).
  • Gli script possono essere eseguiti rapidamente e ripetutamente.
  • È conveniente nel lungo periodo.

Qui, l'automazione è spiegata in termini semplici, ma ciò non significa che sia sempre semplice da fare. Ci sono sfide, rischi e molti altri ostacoli coinvolti. Esistono numerosi modi in cui l'automazione del test può andare storta, ma se tutto va bene, i vantaggi dell'automazione del test sono davvero enormi.

Prossimi in questa serie:

Nei nostri prossimi tutorial, discuteremo di diversi aspetti relativi all'automazione.

Questi includono:

  1. Tipi di test automatici e alcune idee sbagliate.
  2. Come introdurre l'automazione nella tua organizzazione ed evitare insidie ​​comuni quando si esegue l'automazione dei test.
  3. Il processo di selezione degli strumenti e il confronto di vari strumenti di automazione.
  4. Sviluppo di script e framework di automazione con esempi.
  5. Esecuzione e reporting di Test Automation.
  6. Migliori pratiche e strategie di automazione del test.

Sei ansioso di saperne di più su ogni concetto di test di automazione? Fai attenzione e resta sintonizzato sul nostro elenco dei prossimi tutorial di questa serie e sentiti libero di esprimere i tuoi pensieri nella sezione commenti qui sotto.

PROSSIMO Tutorial n. 2

Lettura consigliata

^