Meny

Hur man utvecklar testskript med de fem mest populära ramarna för testautomatisering (exempel)

  • Huvud
  • Automationstestning
  • Hur man utvecklar testskript med de fem mest populära ramarna för testautomatisering (exempel)

how develop test scripts using top 5 most popular test automation frameworks

Prova Vårt Instrument För Att Eliminera Problem

När du börjar lära dig mer om testautomatisering måste du stöta på termen ”ramverk för testautomatisering”. Kanske blir några av er obekväma med den här termen och börjar känna att det är något som är svårt att förstå och ännu svårare att genomföra.

Denna handledning är skriven i syfte att hjälpa dig att förstå testautomatiseringsramar så enkelt som möjligt. Läs alla handledning i detta '' Automation Testing Tutorials-serien här .

Testa automatiseringsramen (på mycket enkelt språk) är 'uppsättning regler'. Regler hjälper oss att skriva manus på ett sådant sätt som resulterar i ”lägre underhåll”.

För att helt förstå begreppet ramverk måste vi först lära oss hur vi skriver enkla manus och sedan hur man implementerar ett ramverk på dem.

testskript med hjälp av automatiseringsramar

I testautomatisering skriver vi skript. Skript handlar i grunden om tre 'A:

  1. ARRANGEMANG
  2. HANDLING
  3. PÅSTÅENDE

Nedan följer detaljerna för varje A, med exempel:

# 1.ARRANGEMANGeller objektidentifiering

Vi identifierar objekt (knappar, rullgardiner etc.) antingen genom deras id, namn eller genom deras fönstertitlar etc.

Vid webbapplikation identifierar vi oss efter användar-ID eller XPath eller CSS eller efter klassnamn etc. Om inget fungerar identifierar vi objekt med muskoordinater (men det är inte en tillförlitlig metod för objektidentifiering)

hur man öppnar datfiler i Windows

Ta detta exempel på Selen WebDriver (med C #) där vi identifierar objekt som använder id. (Webbapplikation)

IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));

Ett annat exempel från MS Coded UI (desktop-applikation)

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Efter identifiering ordnar eller lagrar vi dessa objekt i UIMaps eller Object Repository för att återanvända dem i våra skript. Det är därför detta steg kallas ARRANGEMENT.

#två.HANDLINGpå det identifierade objektet

När objekten identifieras utför vi någon form av åtgärder på den antingen med musen eller med tangentbordet.Till exempel, antingen klickar vi, eller dubbelklickar vi, eller muspekaren över det eller ibland drar och släpper vi. Ibland skriver vi på textrutor. Så alla typer av åtgärder vi utför på dessa objekt tas upp i det andra steget.

Exempel 1 : (Selen WebDriver med C #)

txtServer.Clear(); txtServer.SendKeys(“Some sample text”);

Exempel 2 : (MS-kodat användargränssnitt med C #)

Mouse.Click(buttonAdd);

# 3.PÅSTÅENDE

Påståendet är i princip att kontrollera objektet med något förväntat resultat. Om vi ​​till exempel trycker på 2 + 3 på miniräknaren ska skärmen visa 5. I det här fallet är vårt förväntade resultat 5. Detta koncept har redan förklarats i vår första handledning.

Här ger vi ett exempel på påståenden:

Assert.AreEqual('5', txtResult.DisplayText);

Nästan varje manus som skrivs i testautomatisering innehåller dessa tre saker: Arrangemang, Åtgärd och Påstående.

Titta nu på ett komplett skript som innehåller alla dessa steg. Manuset öppnar en miniräknare, tryck på 1 + 6 och kontrollera sedan om skärmen visar 7 eller inte.

testskript för automatiseringsramverk

Exempel 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(); }

Vad du kommer att lära dig:

Vad är fel med det manuset?

Manuset är lätt att förstå och jag hoppas att du får begreppet tre 'A i exemplet ovan. Men allt är inte bra med det manuset.

Det här skriptet tillåter inte enkelt underhåll. Ta exemplet med miniräknare igen. Om vi ​​måste skriva testfall för varje funktion i räknaren kommer det att finnas många testfall. Om det finns tio testfall och i varje test måste vi definiera samma objekt, och om någon ändring inträffar i objektets namn eller id måste vi ändra objektidentifieringsdelen i 10 testfall.

Till exempel, ta exemplet på knappen ADD i skriptet.

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Låt oss säga att den här linjen används i tio testfall. Nu i nästa version av miniräknaren har utvecklaren bytt namn på knappen från 'Lägg till' till 'Plus'. Nu när vi kör våra testfall kommer de att misslyckas och vi måste ändra ovanstående rad till detta i tio testfall.

btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Plus';

Så vi måste förbättra detta testfall. Vi bör följa den berömda DRY-principen i vår kodning. DRY står för ”Repetera inte dig själv”. Vi bör skriva objektidentifieringsdelen på ett sådant sätt att objektet ska identifieras bara på ett ställe och bör kallas överallt.

Ta en titt på det förbättrade skriptet.

Exempel 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(); }

I exemplet ovan har vi separerat calWindow och txtResult och flytta dem till toppen så att de kan användas över olika testmetoder. Vi har definierat dem bara en gång och vi kan använda dem i så många testfall som vi vill.

Vi har också skapat två funktioner. ClickButton () som accepterar ett knappnamn och klickar på det och AddTwoNumbers () som tar två nummer och lägg till dem med hjälp av klicka på knappen fungerar inuti den.

I det ögonblick vi börjar 'förbättra' vår kod och göra den återanvändbar och underhållbar, betyder det att vi använder alla automatiseringsramar. Nu blir det intressant.

Se även=> Varför behöver vi ramarna för testautomatisering?

Det finns fem populära ramar inom testautomatisering :

  1. Linjär
  2. Modularitet
  3. Data driven
  4. Nyckelord Driven
  5. Hybrid

Vi kommer nu att förklara varje ram med hjälp av dess egenskaper.

# 1. Linjär ram:

Egenskaper

  • Allt relaterat till ett skript definieras i skripten.
  • Bryr sig inte om abstraktion och kod duplicering
  • Inspelning och uppspelning genererar normalt linjär kod
  • Lätt att komma igång
  • Underhåll mardröm.

Genom att läsa ovanstående 5 egenskaper hos Linear Framework kan vi enkelt relatera vårt exempel A till dem. Det här exemplet använder i princip Linjär ram, någonting som är relaterat till ett skript definieras i skriptet. De samtalsfönster och TxtResult definieras i skriptet. Skriptet bryr sig inte om abstraktion och koddubblering. Det är också en underhålls mardröm som jag har förklarat tidigare.

Så varför ska vi använda detta ramverk?

Denna ram kan användas i småskaliga projekt där det inte finns många UI-skärmar. När vi använder något automatiseringsverktyg för första gången genererar det normalt kod i linjär form. Så vi kan lära oss om vilken kod som genereras av Automationsverktyget för specifika åtgärder. Utöver dessa skäl bör detta ramverk undvikas i ditt skript.

=> Se här exemplet med Linear och Keyword Framework med QTP-exempel.

# 2. Modularity Framework:

Egenskaper

  • Objekten definieras en gång och kan återanvändas i alla testmetoder.
  • Små och noggranna metoder skapas för individuella funktioner
  • Testfallet är samlingen av dessa små metoder och återanvändbara objekt
  • Detta gör att vi kan skriva underhållskod.

Genom att läsa ovanstående egenskaper kan vi relatera vårt exempel B till dessa egenskaper. I det exemplet har vi skapat en abstraktion genom att flytta calWindow till toppen och definiera den i en egendom som kan användas överallt. Vi har skapat två små och oberoende funktioner som kallas ClickButton () och AddTwoNumbers () . Vi kombinerar dessa två små funktioner för att skapa vårt slutliga skript som testar räknarens 'Lägg till' -funktionalitet.

Detta resulterar i enklare underhåll. Om någon ändring inträffar i räknargränssnittet måste vi bara ändra funktionerna. Våra skript kommer att förbli intakta. Detta ramverk används mycket i automatisering. Det berömda Page Object Framework (som används med Selen) är också ett slags modularitetsramverk. Vi distribuerar hela webbapplikationen på separata sidor. Knapparna, rullgardinsmenyn och kryssrutorna för varje sida definieras i klassen på den sidan. Om någon ändring inträffar på webbplatsen måste vi bara ändra den sidklassen och andra sidor förblir intakta. Detta resulterar i bättre underhåll och enklare läsbarhet för skript.

Den enda nackdelen med denna ram är att den kräver goda objektorienterade koncept och starka utvecklingsfärdigheter. Om du har sådana rekommenderas detta ramverk starkt.

# 3. Datadriven ram:

Egenskaper:

  • Testdata (in- och utgångsvärden) separeras från skriptet och lagras i externa filer. Detta kan vara en.CSV-fil, ett Excel-kalkylark eller en databas.
  • När skriptet körs väljs dessa värden från externa filer, lagras i variabler och ersätter de hårdkodade värdena om de finns.
  • Verkligen användbart på platser där samma testfall måste köras med olika ingångar.

Exempel C:

varför är c ​​++ bättre än java

Vi vill köra add testfallet med tre olika ingångar.

Uppgifterna är
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

Vi lagrade dessa data (både input och output) i en extern CSV-fil.

Datadrivet ramexempel

(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(); }

I ovanstående skript definierar vi vår datakälla längst upp i skriptet, som är en .csv-fil.

Vi har angett sökvägen till that.CSV-filen och ber skriptet att analysera det 'Sekventiellt'. Det betyder att skriptet kommer att köras så många gånger som det finns rader i CSV-filen. I vårt fall kommer manuset att köras tre gånger. I varje körning lägger den till de två siffrorna som definierats i de första två kolumnerna och verifierar att summan av dessa två nummer matchar numret som finns i den tredje kolumnen.

Det finns olika fördelar med detta ramverk. Alla värden lagras utanför skriptet, så om någon förändring kommer att inträffa i nästa version måste vi bara ändra data i den externa filen och skriptet förblir intakt.

Den andra fördelen är att samma skript kan köras för olika ingångar. Ta exemplet med en ERP där du måste testa registreringen av 100 anställda. Du kan skriva ett skript och lagra namnen och andra data relaterade till anställda i en extern fil. Du kommer att köra ett skript och det kommer att köras 100 gånger. Varje gång med olika anställdas uppgifter. Du kan enkelt upptäcka vilka data skriptet inte registrerar medarbetaren. Det kommer att vara en extra fördel när du gör negativa tester.

=> Se här exemplet med datadrivet och hybrid ramverk med QTP-exempel.

# 4. Nyckelordstyrd ramverk:

Egenskaper:

  • Både data och åtgärder definieras utanför skriptet.
  • Det krävde utveckling av nyckelord för olika typer av åtgärder.
  • Funktionaliteten som vi måste testa skrivs steg för steg i tabellform med de nyckelord som vi utvecklar och testdata. Vi lagrar denna tabell i externa filer precis som datadrivet ramverk.
  • Skriptet analyserar denna tabell och utför motsvarande åtgärder.
  • Tillåter att manuell testare som inte känner till kodning till någon del ingår i automatisering.

Exempel D:

Vi definierade data (t.ex. 1 + 3 = 4) samt åtgärder (t.ex. klicka, rensa etc.) i en excel-fil i tabellform.

Sökordsdrivet ramexempel

Skriptet blir något liknande detta (koden nedan är bara skriven för att förstå syftet)

(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 } }

Ovanstående skript är bara en tolkning av excel-filen. Den analyserar excel-filen rad för rad och letar efter nyckelord för att utföra respektive åtgärder. Om det hittar nyckelordet 'Klicka' klickar det på det definierade objektet. Om den hittar 'Verifiera resultat' kommer den att utföra påståendet.

Det finns olika fördelar med att använda det nyckelordsdrivna ramverket.

Den första fördelen är att detta ramverk är till stor hjälp i de scenarier där det finns stora chanser för förändringar i testfall. Om något steg ändras i ett testfall behöver vi inte röra koden. Vi måste bara uppdatera excel-filen och skriptet kommer att uppdateras.

Du kan definiera alla dina skript i en excel-fil och överlämna denna excel-fil till manuella testare för att lägga till nya skript eller uppdatera befintliga. På detta sätt kan manuella testare också bli en del av testautomatiseringen eftersom de inte behöver koda någonting. De uppdaterar bara den här excel-filen när det finns ett behov och skript uppdateras automatiskt.

Den andra fördelen är att ditt skript blir verktygsoberoende. Du kan behålla dina skript i en excel-fil och om du behöver ändra ditt automatiseringsverktyg någon gång kan du enkelt ändra det genom att skriva en excel-parser i ett annat verktyg.

Nackdelen med detta ramverk är att du behöver uppfinna nyckelord för olika typer av åtgärder. I storskaliga projekt kommer det att finnas så många nyckelord som du behöver komma ihåg och organisera dina skript och nyckelord. Detta i sig blir en besvärlig uppgift vid en tidpunkt.

I vissa komplexa scenarier, där objekt inte lätt kan identifieras och vi behöver använda muskoordinater och andra tekniker, är detta ramverk inte särskilt användbart.

Nyckelordsstyrd är fortfarande ett favoritramverk för många automatiseringstestare. Robotramverk av Google är ett populärt sökordsdrivet ramverk som stöds av en aktiv gemenskap.

# 5. Hybrid Test Automation Framework:

Egenskaper:

  • Kombinationen av två eller flera av ovanstående tekniker, som tar från deras styrkor och minimerar deras svagheter.
  • Ramverket kan använda det modulära tillvägagångssättet tillsammans med antingen datadrivet eller nyckelorddrivet ramverk.
  • Ramverket kan använda skript för att utföra vissa uppgifter som kan vara för svåra att implementera i en ren sökordsdriven strategi.

Med enkla ord, Hybrid framework, använd kombinationen av ovan nämnda tekniker. Vi kan använda ett datadrivet ramverk som också är modulärt. I vissa testfall kan vi använda nyckelorddriven metod och för att återstå kan vi använda modulära. Så när vi blandar två eller flera tekniker som nämns i den här artikeln använder vi faktiskt en hybridstrategi.

Slutsats

Jag hoppas att testautomatiseringsramen inte längre är en läskig term för dig nu. Jag försökte förklara de mest populära ramarna så enkelt som möjligt.

Ramar är här för att göra ditt liv enklare. De hjälper dig att skriva underhållbara och pålitliga manus. Utan att använda ramar är testautomationsfältet en mardröm. För varje liten förändring i applikationen måste du ändra din kod på hundratals platser.

Så en förståelse för dessa ramar är ett måste för varje testare som vill ha en smak av testautomation.

I vår nästa handledning i den här serien lär vi oss 'Exekvering och rapportering av testautomatisering'.

användning av grep-kommandot i unix

Om jag har missat något i den här artikeln eller om du behöver ställa några frågor är du välkommen att ställa i kommentarfältet.

PREV Handledning nr 4 | NÄSTA självstudie # 6

Rekommenderad läsning

^