Menu

Sådan udvikles testskripter ved hjælp af Top 5 mest populære testautomatiseringsrammer (eksempler)

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

Prøv Vores Instrument Til At Fjerne Problemer

Når du begynder at lære om testautomatisering, skal du støde på udtrykket 'testautomatiseringsramme'. Måske bliver nogle af jer ubehagelige med dette udtryk og begynder at føle, at det er noget, der er svært at forstå og endnu sværere at gennemføre.

Denne tutorial er skrevet med det formål at hjælpe dig med at forstå testautomatiseringsrammer så enkelt som muligt. Læs alle vejledninger i dette '' Automatiseringstest-tutorials-serien her .

Test automatiseringsrammen (på meget simpelt sprog) er 'regelsæt.' Regler hjælper os med at skrive scripts på en sådan måde, der resulterer i 'lavere vedligeholdelse'.

For fuldstændigt at forstå konceptet med rammen skal vi først lære, hvordan vi skriver enkle scripts, og derefter hvordan vi implementerer en ramme om dem.

bedste systemvedligeholdelsessoftware til Windows 10

test scripts ved hjælp af automatiseringsrammer

I testautomatisering skriver vi scripts. Scripting handler grundlæggende om tre 'A'er:

  1. ARRANGEMENT
  2. HANDLING
  3. PÅSTAND

Nedenfor er detaljerne for hver A med eksempler:

# 1.ARRANGEMENTeller genstandsidentifikation

Vi identificerer objekter (knapper, dropdowns osv.) Enten efter deres id'er, navne eller ved deres vinduetitler osv.

I tilfælde af webapplikation identificerer vi os efter bruger-ID eller ved XPath eller efter CSS eller efter klassenavn osv. Hvis intet fungerer, identificerer vi derefter objekter ved hjælp af musekoordinater (men det er ikke en pålidelig metode til objektidentifikation)

Tag dette eksempel på Selen WebDriver (med C #), hvor vi identificerer objekter ved hjælp af id'et. (Webapplikation)

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

Et andet eksempel fra MS Coded UI (desktop-applikation)

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

Efter identifikation arrangerer eller gemmer vi disse objekter i UIMaps eller Object Repository for at genbruge dem i vores scripts. Derfor kaldes dette trin ARRANGEMENT.

#to.HANDLINGpå det identificerede objekt

Når objekterne identificeres, udfører vi en slags handlinger på den enten med mus eller tastatur.For eksempel, enten klikker vi, eller vi dobbeltklikker, eller vi holder musen over det, eller nogle gange trækker vi slip. Nogle gange skriver vi på tekstfelter. Så enhver form for handling, vi udfører på disse objekter, dækkes i dette andet trin.

Eksempel 1 : (Selen WebDriver med C #)

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

Eksempel 2 : (MS-kodet brugergrænseflade med C #)

Mouse.Click(buttonAdd);

# 3.PÅSTAND

Påstanden er grundlæggende at kontrollere objektet med et forventet resultat. For eksempel, hvis vi trykker på 2 + 3 på regnemaskinen, skal skærmen vise 5. I dette tilfælde er vores forventede resultat 5. Dette koncept er allerede forklaret i vores første tutorial.

Her giver vi et eksempel på påstand:

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

Næsten hvert script skrevet i testautomatisering indeholder disse tre ting: Arrangement, Action og Assertion.

Se nu på et komplet script, der indeholder alle disse trin. Scriptet åbner en lommeregner, tryk på 1 + 6 og kontroller derefter, om skærmen viser 7 eller ej.

test script til automatiseringsramme

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

Hvad du lærer:

Hvad er der galt med dette script?

Manuskriptet er let at forstå, og jeg håber, du får begrebet tre 'A'er i ovenstående eksempel. Men alt er ikke godt med dette script.

Dette script tillader ikke let vedligeholdelse. Tag eksemplet med lommeregner igen. Hvis vi skal skrive testtilfælde for hver funktion af lommeregneren, vil der være mange testtilfælde. Hvis der er 10 testtilfælde, og i hver test, er vi nødt til at definere det samme objekt, så hvis der sker ændringer i objektets navn eller id, skal vi ændre objektidentifikationsdelen i 10 testtilfælde.

For eksempel, tag eksemplet på knappen ADD i scriptet.

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

Lad os sige, denne linje bruges i 10 testsager. Nu i den næste version af lommeregneren har udvikleren ændret navnet på knappen fra “Tilføj” til “Plus”. Nu når vi kører vores testsager, mislykkes de, og vi er nødt til at ændre ovenstående linje til dette i 10 testsager.

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

Så vi er nødt til at forbedre denne testsag. Vi skal følge det berømte DRY-princip i vores kodning. DRY står for 'Gentag ikke dig selv'. Vi skal skrive objektidentifikationsdelen på en sådan måde, at objektet skal kun identificeres ét sted og skal kaldes overalt.

Se på det forbedrede script.

Eksempel B:

enhedstest integrations test system test
//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 eksemplet ovenfor har vi adskilt calWindow og txtResult objekter og flytte dem til toppen, så de kan bruges på tværs af forskellige testmetoder. Vi har kun defineret dem en gang, og vi kan bruge dem i så mange testsager, som vi vil.

Vi har også oprettet to funktioner. Klik på knappen () som accepterer et knapnavn og klik på det og AddTwoNumbers () som tager et hvilket som helst to tal og tilføjer dem ved hjælp af klik på knappen funktion inde i den.

I det øjeblik vi begynder at 'forbedre' vores kode og gøre den genanvendelig og vedligeholdelig, betyder det, at vi bruger enhver automatiseringsramme. Nu bliver det interessant.

Se også=> Hvorfor har vi brug for rammen for testautomatisering?

Der er fem populære rammer inden for testautomatisering :

  1. Lineær
  2. Modularitet
  3. Datadrevet
  4. Søgeordsdrevet
  5. Hybrid

Vi vil nu forklare hver ramme ved hjælp af dens egenskaber.

# 1. Lineær ramme:

Egenskaber

  • Alt relateret til et script er defineret inde i scripts.
  • Er ligeglad med abstraktion og kodekopiering
  • Optagelse og afspilning genererer normalt lineær kode
  • Let at komme i gang
  • Vedligeholdelses mareridt.

Ved at læse de ovennævnte 5 egenskaber ved Linear Framework, kan vi let relatere vores eksempel A til dem. Dette eksempel bruger dybest set Lineær ramme. Noget der er relateret til et script er defineret inde i scriptet. Det opkaldsvindue og TxtResult er defineret inde i scriptet. Scriptet er ligeglad med abstraktion og duplikering af kode. Det er også et vedligeholdelses-mareridt, som jeg har forklaret tidligere.

Så hvorfor skal vi bruge denne ramme?

Denne ramme kan bruges i mindre projekter, hvor der ikke er mange UI-skærme. Når vi bruger et hvilket som helst automatiseringsværktøj for første gang, genererer det normalt kode i lineær form. Så vi kan lære om, hvilken kode der genereres af automatiseringsværktøjet til specifikke handlinger. Bortset fra disse grunde, bør denne ramme undgås i dit scripting.

=> Se eksemplet på Linear og Keyword Framework med QTP-eksempel.

# 2. Modularitetsramme:

Egenskaber

  • Objekterne er defineret én gang og kan genbruges i alle testmetoder.
  • Små og aktuelle metoder oprettes til individuelle funktionaliteter
  • Test tilfælde er indsamling af disse små metoder og genanvendelige objekter
  • Dette giver os mulighed for at skrive kode, der kan vedligeholdes.

Ved at læse ovenstående egenskaber kan vi relatere vores eksempel B til disse egenskaber. I dette eksempel har vi skabt en abstraktion ved at flytte calWindow til toppen og definer det i en ejendom, der kan bruges overalt. Vi har oprettet to små og uafhængige funktioner kaldet Klik på knappen () og AddTwoNumbers () . Vi kombinerer disse to små funktioner for at oprette vores endelige script, der tester 'Tilføj' -funktionaliteten i lommeregneren.

Dette resulterer i lettere vedligeholdelse. Hvis der sker ændringer i lommeregnerens brugergrænseflade, skal vi kun ændre funktionerne. Vores scripts forbliver intakte. Denne ramme bruges meget i automatisering. Den berømte Page Object Framework (som bruges sammen med selen) er også en slags modularitetsramme. Vi distribuerer hele webapplikationen på separate sider. Knapperne, rullelisterne og afkrydsningsfelterne for hver side er defineret inden for klassen på den side. Hvis der sker ændringer på webstedet, skal vi kun ændre i den sideklasse, og andre sider forbliver intakte. Dette resulterer i bedre vedligeholdelse og lettere læsbarhed af scripts.

Den eneste ulempe ved denne ramme er, at den kræver gode objektorienterede koncepter og stærke udviklingsevner. Hvis du har dem, anbefales denne ramme stærkt.

# 3. Datadrevet ramme:

Egenskaber:

  • Testdata (input- og outputværdier) adskilles fra scriptet og gemmes i eksterne filer. Dette kan være en.CSV-fil, et Excel-regneark eller en database.
  • Når scriptet udføres, vælges disse værdier fra eksterne filer, gemmes i variabler og erstatter de hårdkodede værdier, hvis de er til stede.
  • Virkelig nyttigt på steder, hvor den samme test case skal køres med forskellige input.

Eksempel C:

Vi ønsker at køre add test case med tre forskellige input.

Dataene er
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

Vi lagrede disse data (både input og output) i en ekstern CSV-fil.

Datadrevet rammeeksempel

(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 ovenstående script definerer vi vores datakilde øverst på scriptet, som er en .csv-fil.

Vi har givet stien til that.CSV-filen og beder scriptet om at parsere det 'Sekventielt'. Det betyder, at scriptet kører så mange gange, som der er rækker til stede i CSV-filen. I vores tilfælde kører scriptet 3 gange. I hver kørsel tilføjer den de to numre, der er defineret i de første to kolonner, og verificerer, at summen af ​​disse to tal matcher antallet, der findes i den tredje kolonne.

Der er forskellige fordele ved denne ramme. Alle værdier er gemt uden for scriptet, så hvis der sker ændringer i den næste build, skal vi bare ændre dataene i den eksterne fil, og scriptet forbliver intakt.

Den anden fordel er, at det samme script kan køres for forskellige input. Tag eksemplet på en ERP, hvor du skal teste registreringen af ​​100 ansatte. Du kan skrive et script og gemme navne og andre data relateret til medarbejdere i en ekstern fil. Du udfører et script, og det kører 100 gange. Hver gang med forskellige medarbejderdata. Du kan let registrere, på hvilke data scriptet ikke registrerer medarbejderen. Det vil være en ekstra fordel, når du laver negativ test.

=> Se her eksemplet med datadrevet og hybrid ramme med QTP-eksempel.

# 4. Søgeordsdrevet ramme:

Egenskaber:

  • Både data og handlinger er defineret uden for scriptet.
  • Det krævede udvikling af nøgleord til forskellige typer handlinger.
  • Funktionaliteten, som vi skal teste, skrives trin for trin i tabelform ved hjælp af de nøgleord, vi udvikler, og testdataene. Vi gemmer denne tabel i eksterne filer ligesom datadrevet ramme.
  • Scriptet analyserer denne tabel og udfører de tilsvarende handlinger.
  • Tillader, at manuel tester, der ikke ved noget om kodning, er en del af automatisering i nogen grad.

Eksempel D:

Vi definerede dataene (f.eks. 1 + 3 = 4) samt handlinger (f.eks. Klik, ryd osv.) I en excel-fil i tabelform.

youtube til mp3-konverter med billede

Søgeordsdrevet rammeeksempel

Scriptet bliver noget som dette (nedenstående kode er bare skrevet for at forstå formålet)

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

Ovenstående script er kun en parser af excel-filen. Det parser excel-filen linje for linje og ser efter nøgleord til at udføre respektive handlinger. Hvis det finder nøgleordet 'Klik', klikker det på det definerede objekt. Hvis den finder 'Bekræft resultat', udfører den påstanden.

Der er forskellige fordele ved at bruge den nøgleordsdrevne ramme.

Den første fordel er, at denne ramme er meget nyttig i de scenarier, hvor der er store chancer for ændringer i testsager. Hvis et trin ændres i en testsag, behøver vi ikke røre ved koden. Vi skal bare opdatere excel-filen, og scriptet opdateres.

Du kan definere alle dine scripts i en excel-fil og aflevere denne excel-fil til manuelle testere for at tilføje nye scripts eller opdatere de eksisterende. På denne måde kan manuelle testere også blive en del af testautomatisering, fordi de ikke behøver at kode noget. De opdaterer bare denne excel-fil, når der er behov, og scripts opdateres automatisk.

Den anden fordel er, at dit script bliver værktøjsuafhængigt. Du kan vedligeholde dine scripts i en excel-fil, og hvis du har brug for at ændre dit automatiseringsværktøj på et eller andet tidspunkt, kan du nemt ændre det ved at skrive en excel-parser i et andet værktøj.

Ulempen ved denne ramme er, at du har brug for at opfinde nøgleord til forskellige typer handlinger. I store projekter vil der være så mange nøgleord, at du har brug for at huske og organisere dine scripts og nøgleord. Dette bliver i sig selv en besværlig opgave på et tidspunkt.

I nogle komplekse scenarier, hvor objekter ikke let kan identificeres, og vi har brug for musekoordinater og andre teknikker, er denne ramme ikke særlig nyttig.

Søgeordsdrevet er stadig en favoritramme for mange automatiseringstestere. Robotramme af Google er en populær søgeordsdrevet ramme, der understøttes af et aktivt samfund.

# 5. Hybrid Test Automation Framework:

Egenskaber:

  • Kombinationen af ​​to eller flere af ovennævnte teknikker, der tager deres styrker og minimerer deres svagheder.
  • Rammen kan bruge den modulære tilgang sammen med enten datadrevet eller søgeordsdrevet ramme.
  • Rammen kan bruge scripts til at udføre nogle opgaver, der kan være for vanskelige at implementere i en ren søgeordsdrevet tilgang.

I enkle ord, Hybrid framework, skal du bruge kombinationen af ​​de ovennævnte teknikker. Vi kan bruge en datadrevet ramme, som også er modulær. I nogle testtilfælde kan vi bruge nøgleordsdrevet tilgang, og for at forblive modulære. Så når vi blander to eller flere teknikker, der er nævnt i denne artikel, bruger vi faktisk en hybrid tilgang.

Konklusion

Jeg håber, at testautomatiseringsrammen ikke længere er en skræmmende betegnelse for dig nu. Jeg forsøgte at forklare de mest populære rammer så simpelt som muligt.

Rammer er her for at gøre dit liv lettere. De hjælper dig med at skrive vedligeholdelige og pålidelige scripts. Uden at bruge rammer er testautomatiseringsfeltet et mareridt. For hver lille ændring i applikationen skal du ændre din kode hundreder af steder.

Så en forståelse af disse rammer er et must for hver tester, der ønsker en smag af testautomatisering.

I vores næste tutorial i denne serie lærer vi 'Udførelse og rapportering af testautomatisering'.

Hvis jeg har gået glip af noget i denne artikel, eller hvis du har brug for at stille spørgsmål, er du velkommen til at stille i kommentarfeltet.

PREV Tutorial # 4 | NÆSTE vejledning # 6

Anbefalet læsning

^