how develop test scripts using top 5 most popular test automation frameworks
Quando inizi a conoscere l'automazione dei test, devi imbatterti nel termine 'framework di automazione dei test'. Forse alcuni di voi si sentono a disagio con questo termine e iniziano a sentire che è qualcosa di difficile da capire e ancora più difficile da implementare.
Questo tutorial è stato scritto con l'obiettivo di aiutarti a comprendere i framework di automazione dei test nel modo più semplice possibile. Leggi tutti i tutorial in questo ' Serie di tutorial sui test di automazione qui .
Framework di automazione dei test (in un linguaggio molto semplice) è 'insieme di regole'. Le regole ci aiutano a scrivere script in modo tale da comportare una 'minore manutenzione'.
Per comprendere completamente il concetto di framework, dobbiamo prima imparare come scriviamo semplici script e poi come implementare un framework su di essi.
Nell'automazione dei test, scriviamo script. Lo scripting si basa fondamentalmente su tre 'A':
cos'è il sistema operativo Linux e Unix
- PREPARATIVI
- AZIONE
- ASSERZIONE
Di seguito sono riportati i dettagli di ciascuna A, con esempi:
# 1.PREPARATIVIo Identificazione di oggetti
Identifichiamo gli oggetti (pulsanti, menu a discesa, ecc.) In base ai loro ID, nomi o ai titoli delle finestre, ecc.
In caso di applicazione web, identifichiamo per ID utente, o Per XPath o Per CSS o Per nome della classe ecc. Se non funziona, identifichiamo gli oggetti utilizzando le coordinate del mouse (ma non è un metodo affidabile di identificazione dell'oggetto)
Prendi questo esempio di Selenium WebDriver (con C #) in cui identifichiamo gli oggetti usando l'id. (Applicazione web)
IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));
Un altro esempio da MS Coded UI (applicazione desktop)
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add';
Dopo l'identificazione, disponiamo o archiviamo questi oggetti in UIMaps o Object Repository per riutilizzarli nei nostri script. Ecco perché questo passaggio si chiama ARRANGEMENT.
#Due.AZIONEsull'oggetto identificato
Quando gli oggetti vengono identificati, eseguiamo alcuni tipi di azioni su di esso tramite mouse o tastiera.Per esempio, o clicchiamo, o facciamo doppio clic, o passiamo il mouse sopra di esso o talvolta trasciniamo. A volte scriviamo su caselle di testo. Quindi qualsiasi tipo di azione che eseguiamo su questi oggetti viene trattato in questo secondo passaggio.
Esempio 1 : (Selenium WebDriver con C #)
txtServer.Clear(); txtServer.SendKeys(“Some sample text”);
Esempio 2 : (Interfaccia utente codificata MS con C #)
Mouse.Click(buttonAdd);
# 3.ASSERZIONE
L'asserzione sta fondamentalmente controllando l'oggetto con un risultato atteso. Ad esempio, se premiamo 2 + 3 sulla calcolatrice, lo schermo dovrebbe mostrare 5. In questo caso, il nostro risultato atteso è 5. Questo concetto è già spiegato nel nostro primo tutorial.
Qui diamo un esempio di asserzione:
Assert.AreEqual('5', txtResult.DisplayText);
Quasi ogni script scritto nell'automazione del test contiene queste tre cose: Arrangement, Action e Assertion.
Ora dai un'occhiata a uno script completo che contiene tutti questi passaggi. Lo script aprirà una calcolatrice, premere 1 + 6 e quindi verificare se lo schermo mostra 7 o meno.
Esempio A:
[TestMethod] [TestMethod] public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties[WinWindow.PropertyNames.Name] = 'Calculator'; calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties[WinButton.PropertyNames.Name] = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties[WinButton.PropertyNames.Name] = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties[WinButton.PropertyNames.Name] = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties[WinText.PropertyNames.Name] = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }
Cosa imparerai:
- Cosa c'è di sbagliato in quella sceneggiatura?
- Esistono cinque framework popolari nell'automazione dei test:
- # 1. Struttura lineare:
- # 2. Quadro di modularità:
- # 3. Framework basato sui dati:
- # 4. Framework basato sulle parole chiave:
- # 5. Framework ibrido per l'automazione dei test:
- Conclusione
- Lettura consigliata
Cosa c'è di sbagliato in quella sceneggiatura?
La sceneggiatura è facile da capire e spero che tu abbia il concetto di tre 'A' nell'esempio sopra. Ma non va tutto bene con quella sceneggiatura.
Questo script non consente una facile manutenzione. Prendiamo di nuovo l'esempio della calcolatrice, se dobbiamo scrivere casi di test di ciascuna funzione della calcolatrice, ci saranno molti casi di test. Se ci sono 10 casi di test e in ogni test, dobbiamo definire lo stesso oggetto, quindi se si verifica un cambiamento nel nome o nell'ID dell'oggetto, dobbiamo cambiare la parte di identificazione dell'oggetto in 10 casi di test.
Per esempio, prendi l'esempio del pulsante AGGIUNGI nello script.
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add';
Supponiamo che questa linea venga utilizzata in 10 casi di test. Ora nella prossima versione della calcolatrice, lo sviluppatore ha cambiato il nome del pulsante da 'Aggiungi' a 'Plus'. Ora, quando eseguiamo i nostri casi di test, non saranno riusciti e dobbiamo modificare la riga sopra in questo caso in 10 casi di test.
btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Plus';
Quindi dobbiamo migliorare questo caso di prova. Dovremmo seguire il famoso principio DRY nella nostra codifica. DRY sta per 'Do not Repeat Yourself'. Dovremmo scrivere la parte di identificazione dell'oggetto in modo tale che l'oggetto dovrebbe essere identificato solo in un posto e dovrebbe essere chiamato ovunque.
Dai un'occhiata allo script migliorato.
Esempio B:
//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties[WinWindow.PropertyNames.Name] = 'Calculator'; _calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties[WinText.PropertyNames.Name] = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties[WinButton.PropertyNames.Name] = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. [TestMethod] public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }
Nell'esempio sopra, abbiamo separato il file calWindow e txtResult oggetti e spostarli in alto in modo che possano essere utilizzati con diversi metodi di test. Li abbiamo definiti una sola volta e possiamo usarli in tutti i casi di test che vogliamo.
convertitore gratuito da youtube a mp4 per mac
Abbiamo anche creato due funzioni. ClickButton () che accetta il nome di un pulsante e fare clic su di esso e AddTwoNumbers () che prende due numeri qualsiasi e li somma usando il fare clic sul pulsante funzione al suo interno.
Nel momento in cui iniziamo a 'migliorare' il nostro codice rendendolo riutilizzabile e manutenibile, significa che stiamo facendo uso di qualsiasi framework di automazione. Adesso diventa interessante.
Guarda anche=> Perché abbiamo bisogno del framework per l'automazione dei test?
Ci sono cinque framework popolari nell'automazione dei test :
- Lineare
- Modularità
- Basato sui dati
- Basato sulle parole chiave
- Ibrido
Spiegheremo ora ogni framework con l'aiuto delle sue caratteristiche.
# 1. Struttura lineare:
Caratteristiche
- Tutto ciò che riguarda uno script è definito all'interno degli script.
- Non si preoccupa dell'astrazione e della duplicazione del codice
- La registrazione e la riproduzione normalmente generano codice lineare
- Facile iniziare
- Incubo di manutenzione.
Leggendo le 5 caratteristiche di cui sopra di Linear Framework, possiamo facilmente collegare il nostro Esempio A ad esse. Questo esempio utilizza fondamentalmente il framework lineare, ogni cosa relativa a uno script è definita all'interno dello script. Il finestra di chiamata e TxtResult sono definiti all'interno dello script. Lo script non si preoccupa dell'astrazione e della duplicazione del codice. È anche un incubo di manutenzione come ho spiegato in precedenza.
Allora perché dovremmo usare questo framework?
Questo framework può essere utilizzato in progetti su piccola scala in cui non sono presenti molte schermate dell'interfaccia utente. Inoltre, quando utilizziamo uno strumento di automazione per la prima volta, normalmente genera codice in forma lineare. Quindi possiamo conoscere quale codice viene generato dallo strumento di automazione per azioni specifiche. Oltre a questi motivi, questo framework dovrebbe essere evitato nello scripting.
=> Vedi qui l'esempio di Linear e Keyword Framework con esempio QTP.
# 2. Quadro di modularità:
Caratteristiche
- Gli oggetti sono definiti una volta e riutilizzabili in tutti i metodi di test.
- Vengono creati metodi piccoli e mirati per funzionalità individuali
- Il test case è la raccolta di questi piccoli metodi e oggetti riutilizzabili
- Questo ci consente di scrivere codice gestibile.
Leggendo le caratteristiche di cui sopra, possiamo mettere in relazione il nostro esempio B a queste caratteristiche. In quell'esempio, abbiamo creato un'astrazione spostando il file calWindow in alto e definirlo all'interno di una proprietà utilizzabile ovunque. Abbiamo creato due piccole e indipendenti funzioni chiamate ClickButton () e AddTwoNumbers () . Combiniamo queste due piccole funzioni per creare il nostro script finale che verifica la funzionalità 'Aggiungi' della calcolatrice.
Ciò si traduce in una più facile manutenzione. Se si verifica una modifica nell'interfaccia utente della calcolatrice, è necessario modificare solo le funzioni. I nostri script rimarranno intatti. Questo framework è molto utilizzato nell'automazione. Il famoso Page Object Framework (che viene utilizzato con Selenium) è anche una sorta di framework di modularità. Distribuiamo l'intera applicazione web in pagine separate. I pulsanti, i menu a discesa e le caselle di controllo di ciascuna pagina sono definiti all'interno della classe di quella pagina. Se si verifica un cambiamento sul sito web, dobbiamo cambiare solo in quella classe di pagina e le altre pagine rimangono intatte. Ciò si traduce in una migliore manutenzione e una più facile leggibilità degli script.
L'unico svantaggio di questo framework è che richiede buoni concetti orientati agli oggetti e forti capacità di sviluppo. Se li hai, questo framework è altamente raccomandato.
# 3. Framework basato sui dati:
Caratteristiche:
- I dati di test (valori di input e output) vengono separati dallo script e archiviati in file esterni. Potrebbe essere un file CSV, un foglio di calcolo Excel o un database.
- Quando lo script viene eseguito, questi valori vengono prelevati da file esterni, memorizzati in variabili e sostituiscono i valori hardcoded se presenti.
- Veramente utile in luoghi in cui lo stesso test case deve essere eseguito con input diversi.
Esempio C:
Vogliamo eseguire l'add test case con tre diversi input.
I dati sono
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5
Abbiamo archiviato questi dati (sia in ingresso che in uscita) in un file CSV esterno.
[DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod] public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }
Nello script sopra, definiamo la nostra origine dati nella parte superiore dello script, che è un file .csv.
Abbiamo fornito il percorso di quel file.CSV e abbiamo detto allo script di analizzarlo 'in sequenza'. Ciò significa che lo script verrà eseguito tante volte quante sono le righe presenti nel file CSV. Nel nostro caso, lo script verrà eseguito 3 volte. In ogni esecuzione, aggiungerà i due numeri definiti nelle prime due colonne e verificherà che la somma di questi due numeri corrisponda al numero presente nella terza colonna.
Ci sono vari vantaggi di questo framework. Tutti i valori sono memorizzati al di fuori dello script, quindi se si verificheranno modifiche nella prossima build, non ci resta che modificare i dati nel file esterno e lo script rimarrà intatto.
Il secondo vantaggio è che lo stesso script può essere eseguito per input diversi. Prendi l'esempio di un ERP in cui devi testare la registrazione di 100 dipendenti. È possibile scrivere uno script e memorizzare i nomi e altri dati relativi ai dipendenti in un file esterno. Eseguirai uno script e verrà eseguito 100 volte. Ogni volta con dati di dipendenti diversi. È possibile rilevare facilmente su quali dati lo script non riesce a registrare il dipendente. Sarà un ulteriore vantaggio quando esegui test negativi.
=> Vedi qui l'esempio di framework basato sui dati e ibrido con esempio QTP.
# 4. Framework basato sulle parole chiave:
Caratteristiche:
- Sia i dati che le azioni sono definiti all'esterno dello script.
- Ha richiesto lo sviluppo di parole chiave per diversi tipi di azioni.
- La funzionalità che dobbiamo testare è scritta passo dopo passo in forma tabellare utilizzando le parole chiave che sviluppiamo ei dati di test. Memorizziamo questa tabella in file esterni proprio come il framework basato sui dati.
- Lo script analizzerà questa tabella ed eseguirà le azioni corrispondenti.
- Consente ai tester manuali che non conoscono la codifica di far parte dell'automazione in una certa misura.
Esempio D:
Abbiamo definito i dati (es. 1 + 3 = 4) e le azioni (es. Clic, Cancella ecc.) In un file excel in forma tabulare.
domande e risposte dell'intervista a sql server 2012
Lo script diventerà qualcosa di simile (il codice seguente è stato scritto solo per scopi di comprensione)
[TestMethod] public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells[“Window”]; WinCell Control = row.Cells[“Control”]; WinCell Action = row.Cells[“Action”]; WinCell Arguments = row.Cells[“Arguments”]; UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }
Lo script sopra è solo un parser del file excel. Analizza il file excel riga per riga e cerca le parole chiave per eseguire le rispettive azioni. Se trova la parola chiave 'Clic', farà clic sull'oggetto definito. Se trova 'Verifica risultato', eseguirà l'asserzione.
Ci sono vari vantaggi nell'usare il framework basato su parole chiave.
Il primo vantaggio è che questo framework è molto utile in quegli scenari in cui ci sono grandi possibilità di modifiche nei casi di test. Se qualche passaggio cambia in uno scenario di test, non è necessario toccare il codice. Dobbiamo solo aggiornare il file excel e lo script verrà aggiornato.
Puoi definire tutti i tuoi script in un file excel e consegnare questo file excel ai tester manuali per aggiungere nuovi script o aggiornare quelli esistenti. In questo modo, i tester manuali possono anche diventare parte dell'automazione del test perché non hanno bisogno di codificare nulla. Aggiorneranno semplicemente questo file Excel quando ce n'è bisogno e gli script verranno aggiornati automaticamente.
Il secondo vantaggio è che lo script diventa indipendente dallo strumento. Puoi mantenere i tuoi script in un file excel e se hai bisogno di cambiare il tuo strumento di automazione ad un certo punto, puoi cambiarlo facilmente scrivendo un parser excel in un altro strumento.
Lo svantaggio di questo framework è che devi inventare parole chiave per vari tipi di azioni. In progetti su larga scala, ci saranno così tante parole chiave che devi ricordare e organizzare i tuoi script e parole chiave. Questo a un certo punto diventa un compito ingombrante.
In alcuni scenari complessi, in cui gli oggetti non possono essere facilmente identificati e dobbiamo usare le coordinate del mouse e altre tecniche, questo framework non è molto utile.
Keyword driven è ancora uno dei framework preferiti da molti tester di automazione. Quadro robot di Google è un popolare framework basato su parole chiave supportato da una comunità attiva.
# 5. Framework ibrido per l'automazione dei test:
Caratteristiche:
- La combinazione di due o più delle tecniche di cui sopra, prendendo dai loro punti di forza e minimizzando i loro punti deboli.
- Il framework può utilizzare l'approccio modulare insieme al framework basato sui dati o basato su parole chiave.
- Il framework può utilizzare script per eseguire alcune attività che potrebbero essere troppo difficili da implementare con un approccio basato su parole chiave puro.
In parole semplici, framework ibrido, utilizza la combinazione delle tecniche sopra menzionate. Possiamo utilizzare un framework basato sui dati che è anche di natura modulare. Per alcuni casi di test, possiamo utilizzare un approccio basato su parole chiave e per il resto possiamo utilizzare modulare. Pertanto, ogni volta che uniamo due o più tecniche menzionate in questo articolo, utilizziamo effettivamente un approccio ibrido.
Conclusione
Spero che il framework di automazione dei test non sia più un termine spaventoso per te ora. Ho cercato di spiegare i framework più popolari nel modo più semplice possibile.
I framework sono qui per semplificarti la vita. Ti aiutano a scrivere script manutenibili e affidabili. Senza l'utilizzo di framework, il campo dell'automazione dei test è un incubo. Per ogni piccola modifica nell'applicazione, devi cambiare il tuo codice in centinaia di posti.
Quindi la comprensione di questi framework è un must per ogni tester che desidera un assaggio dell'automazione dei test.
Nel nostro prossimo tutorial in questa serie impareremo 'Esecuzione e reporting di Test Automation'.
Se mi sono perso qualcosa in questo articolo o hai bisogno di fare qualsiasi domanda, non esitare a chiedere nella sezione commenti.
Tutorial PREV n. 4 | PROSSIMO Tutorial # 6
Lettura consigliata
- Framework QTP - Framework di automazione del test - Esempi di framework lineari e guidati da parole chiave - Tutorial QTP # 17
- Comandi di automazione SeeTest: una spiegazione dettagliata con esempi
- 10 strumenti RPA di automazione dei processi robotici più popolari nel 2021
- In che modo la pianificazione dei test differisce per i progetti manuali e di automazione?
- I framework di automazione dei test più popolari con vantaggi e svantaggi di ciascuno - Selenium Tutorial # 20
- Scriptless Test Automation Framework: strumenti ed esempi
- Test Automation - È una carriera specializzata? I normali tester possono eseguire anche l'automazione?
- 25 migliori framework e strumenti di test Java per test di automazione (parte 3)