Meny

Slik utvikler du testskript ved hjelp av de fem mest populære rammene for testautomatisering (eksempler)

  • Hoved
  • Automatiseringstesting
  • Slik utvikler du testskript ved hjelp av de fem mest populære rammene for testautomatisering (eksempler)

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

Prøv Instrumentet Vårt For Å Eliminere Problemer

Når du begynner å lære om testautomatisering, må du komme over begrepet 'rammeverk for testautomatisering'. Kanskje noen av dere blir ukomfortable med dette begrepet og begynner å føle at det er noe som er vanskelig å forstå og enda vanskeligere å implementere.

Denne opplæringen er skrevet med det formål å hjelpe deg med å forstå rammer for testautomatisering så enkelt som mulig. Les alle veiledningene i dette ' Automatiseringstestopplæringsserier her .

Test automatiseringsrammeverk (på veldig enkelt språk) er 'regelsett.' Regler hjelper oss med å skrive manus på en slik måte som resulterer i 'mindre vedlikehold'.

For å forstå konseptet med rammeverket helt, må vi først lære hvordan vi skriver enkle skript og deretter hvordan vi implementerer et rammeverk på dem.

sql tekniske intervju spørsmål og svar for nybegynnere

test skript ved hjelp av automatiseringsrammer

I testautomatisering skriver vi skript. Scripting handler i utgangspunktet om tre ‘A’er:

  1. ORDNING
  2. HANDLING
  3. PÅSTAND

Nedenfor er detaljene for hver A, med eksempler:

#1.ORDNINGeller objektidentifikasjon

Vi identifiserer objekter (knapper, rullegardiner osv.) Enten etter ID-er, navn eller vindustitler osv.

I tilfelle nettapplikasjon identifiserer vi oss etter bruker-ID, eller ved XPath eller etter CSS eller etter klassenavn osv. Hvis ingenting fungerer, identifiserer vi objekter ved hjelp av musekoordinater (men det er ikke en pålitelig metode for objektidentifikasjon)

Ta dette eksemplet på Selen WebDriver (med C #) der vi identifiserer objekter ved hjelp av id. (Webapplikasjon)

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

Et annet eksempel fra MS Coded UI (desktop-applikasjon)

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

Etter identifikasjon ordner eller lagrer vi disse objektene i UIMaps eller Object Repository for å gjenbruke dem i skriptene våre. Derfor kalles dette trinnet ARRANGEMENT.

#to.HANDLINGpå det identifiserte objektet

Når objektene blir identifisert, utfører vi noen form for handlinger på den enten med mus eller tastatur.For eksempel, enten vi klikker, eller vi dobbeltklikker, eller vi holder musen over det, eller noen ganger drar og slipper vi. Noen ganger skriver vi på tekstbokser. Så enhver form for handling vi utfører på disse objektene blir dekket i dette andre trinnet.

Eksempel 1 : (Selen WebDriver med C #)

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

Eksempel 2 : (MS-kodet brukergrensesnitt med C #)

Mouse.Click(buttonAdd);

# 3.PÅSTAND

Påstanden er i utgangspunktet å sjekke objektet med noe forventet resultat. Hvis vi for eksempel trykker på 2 + 3 på kalkulatoren, skal skjermen vise 5. I dette tilfellet er vårt forventede resultat 5. Dette konseptet er allerede forklart i vår første opplæring.

Her gir vi et eksempel på påstand:

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

Nesten hvert skript skrevet i testautomatisering inneholder disse tre tingene: Arrangement, Action og Assertion.

Ta en titt på et komplett skript som inneholder alle disse trinnene. Skriptet åpner en kalkulator, trykk på 1 + 6 og sjekk deretter om skjermen viser 7 eller ikke.

testskript for automatiseringsrammeverk

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

Hva du vil lære:

Hva er galt med det manuset?

Manuset er enkelt å forstå, og jeg håper du får begrepet tre ‘A’er i eksemplet ovenfor. Men alt er ikke bra med det manuset.

Dette skriptet tillater ikke enkelt vedlikehold. Ta eksemplet med kalkulator igjen. Hvis vi må skrive testtilfeller for hver funksjon av kalkulatoren, vil det være mange testtilfeller. Hvis det er 10 testtilfeller, og i hver test, må vi definere det samme objektet. Hvis det forekommer endringer i navnet eller ID-en til objektet, må vi endre objektidentifikasjonsdelen i 10 testtilfeller.

For eksempel, ta eksemplet på knappen ADD i skriptet.

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

La oss si at denne linjen brukes i 10 testtilfeller. Nå i neste versjon av kalkulatoren, har utvikleren endret navnet på knappen fra “Legg til” til “Pluss”. Nå når vi kjører testsakene våre, vil de mislykkes, og vi må endre linjen ovenfor til dette i 10 testsaker.

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

Så vi må forbedre denne testsaken. Vi bør følge det berømte DRY-prinsippet i kodingen vår. DRY står for “Don't Repeat Yourself”. Vi bør skrive objektidentifikasjonsdelen på en slik måte at objektet skal bare identifiseres på ett sted og skal kalles overalt.

Ta en titt på det forbedrede skriptet.

Eksempel 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 eksemplet ovenfor har vi skilt mellom calWindow og txtResult objekter og flytte dem til toppen slik at de kan brukes på tvers av forskjellige testmetoder. Vi har definert dem bare én gang, og vi kan bruke dem i så mange testtilfeller som vi vil.

Vi har også laget to funksjoner. ClickButton () som godtar et knappnavn og klikker på det og AddTwoNumbers () som tar et hvilket som helst to tall og legger dem til ved hjelp av klikk på knappen funksjon inni den.

I det øyeblikket vi begynner å 'forbedre' koden vår og gjøre den gjenbrukbar og vedlikeholdbar, betyr det at vi bruker ethvert automatiseringsrammeverk. Nå blir det interessant.

Se også=> Hvorfor trenger vi rammeverket for testautomatisering?

Det er fem populære rammer innen testautomatisering :

  1. Lineær
  2. Modularitet
  3. Data drevet
  4. Søkeorddrevet
  5. Hybrid

Vi vil nå forklare hvert rammeverk ved hjelp av egenskapene.

#1. Lineær ramme:

Kjennetegn

  • Alt relatert til et skript er definert i skriptene.
  • Bryr seg ikke om abstraksjon og duplisering av kode
  • Opptak og avspilling genererer normalt lineær kode
  • Lett å komme i gang
  • Vedlikehold Mareritt.

Ved å lese de ovennevnte 5 egenskapene til Linear Framework, kan vi enkelt relatere eksempel A til dem. Dette eksemplet bruker i utgangspunktet Linear framework, Ever ting relatert til et skript er definert inne i skriptet. De samtalevindu og TxtResult er definert inne i skriptet. Skriptet bryr seg ikke om abstraksjon og duplisering av kode. Det er også et vedlikeholds-mareritt som jeg har forklart tidligere.

Så hvorfor skal vi bruke dette rammeverket?

Dette rammeverket kan brukes i småskalaprosjekter der det ikke er mange UI-skjermer. Når vi bruker automatiseringsverktøy for første gang, genererer det vanligvis kode i lineær form. Så vi kan lære om hvilken kode som genereres av automatiseringsverktøyet for spesifikke handlinger. Annet enn disse grunnene, bør dette rammeverket unngås i skriptene dine.

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

# 2. Modularity Framework:

Kjennetegn

  • Objektene er definert en gang og kan brukes på nytt i alle testmetoder.
  • Små og aktuelle metoder er laget for individuelle funksjoner
  • Test tilfellet er samlingen av disse små metodene og gjenbrukbare gjenstander
  • Dette lar oss skrive vedlikeholdbar kode.

Ved å lese de ovennevnte egenskapene, kan vi relatere eksempel B til disse karakteristikkene. I det eksemplet har vi skapt en abstraksjon ved å flytte calWindow til toppen og definer den i en eiendom som kan brukes overalt. Vi har laget to små og uavhengige funksjoner kalt ClickButton () og AddTwoNumbers () . Vi kombinerer disse to små funksjonene for å lage vårt endelige skript som tester 'Legg til' funksjonaliteten til kalkulatoren.

Dette gir enklere vedlikehold. Hvis det skjer noen endring i kalkulatorgrensesnittet, må vi bare endre funksjonene. Skriptene våre forblir intakte. Dette rammeverket er sterkt brukt i automatisering. Det berømte Page Object Framework (som brukes med selen) er også et slags rammeverk for modularitet. Vi distribuerer hele webapplikasjonen på separate sider. Knappene, rullegardinene og avmerkingsboksene på hver side er definert i klassen på den siden. Hvis det forekommer endringer på nettstedet, må vi bare endre det i den sideklassen, og andre sider forblir intakte. Dette resulterer i bedre vedlikehold og lettere lesbarhet for skript.

c ++ konverter char * til int

Den eneste ulempen med dette rammeverket er at det krever gode objektorienterte konsepter og sterke utviklingsevner. Hvis du har disse, anbefales dette rammeverket.

# 3. Datadrevet rammeverk:

Kjennetegn:

  • Testdata (inngangs- og utgangsverdier) skilles fra skriptet og lagres i eksterne filer. Dette kan være en.CSV-fil, et Excel-regneark eller en database.
  • Når skriptet kjøres, plukkes disse verdiene fra eksterne filer, lagres i variabler og erstatter de hardkodede verdiene hvis de er til stede.
  • Virkelig nyttig på steder der samme testtilfelle må kjøres med forskjellige innganger.

Eksempel C:

Vi ønsker å kjøre add test case med tre forskjellige innganger.

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

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

Datadrevet rammeverkeksempel

(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 skriptet ovenfor definerer vi datakilden vår øverst i skriptet, som er en .csv-fil.

Vi har gitt banen til den.CSV-filen og ba skriptet analysere den 'Sekvensielt'. Det betyr at skriptet vil kjøre så mange ganger som det er rader til stede i CSV-filen. I vårt tilfelle vil manuset kjøre 3 ganger. I hvert løp vil det legge til de to tallene som er definert i de to første kolonnene, og verifisere at summen av disse to tallene samsvarer med tallet som er tilstede i den tredje kolonnen.

Det er forskjellige fordeler med dette rammeverket. Alle verdiene er lagret utenfor skriptet, så hvis noen endringer vil skje i neste bygg, må vi bare endre dataene i den eksterne filen, og skriptet forblir intakt.

Den andre fordelen er at det samme skriptet kan kjøres for forskjellige innganger. Ta eksemplet med en ERP der du må teste registreringen av 100 ansatte. Du kan skrive ett skript og lagre navnene og andre data relatert til ansatte i en ekstern fil. Du vil utføre ett skript, og det vil kjøre 100 ganger. Hver gang med forskjellige ansattes data. Du kan enkelt oppdage hvilke data skriptet ikke registrerer den ansatte. Det vil være en ekstra fordel når du utfører negativ testing.

=> Se eksemplet på datadrevet og hybrid rammeverk med QTP-eksempel.

# 4. Søkeorddrevet rammeverk:

Kjennetegn:

  • Både data og handlinger er definert utenfor skriptet.
  • Det krevde utvikling av nøkkelord for forskjellige typer handlinger.
  • Funksjonaliteten som vi må teste, skrives trinnvis i tabellform ved hjelp av nøkkelordene vi utvikler og testdataene. Vi lagrer denne tabellen i eksterne filer akkurat som datadrevet rammeverk.
  • Skriptet analyserer denne tabellen og utfører de tilsvarende handlingene.
  • Tillater manuell tester som ikke vet om koding å være en del av automatisering til en viss grad.

Eksempel D:

Vi definerte dataene (f.eks. 1 + 3 = 4) samt handlinger (f.eks. Klikk, Fjern osv.) I en Excel-fil i tabellform.

Søkeorddrevet rammeverkeksempel

Skriptet blir noe slikt (koden nedenfor er bare skrevet for å 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 skript er bare en parser av Excel-filen. Den analyserer excel-filen linje for linje og ser etter nøkkelord for å utføre respektive handlinger. Hvis det finner nøkkelordet 'Klikk', vil det klikke på det definerte objektet. Hvis den finner 'Bekreft resultat', vil den utføre påstanden.

Det er forskjellige fordeler med å bruke søkeorddrevet rammeverk.

Den første fordelen er at dette rammeverket er veldig nyttig i de scenariene der det er store sjanser for endringer i testsaker. Hvis noen trinn endres i en testsak, trenger vi ikke å berøre koden. Vi må bare oppdatere Excel-filen, og skriptet blir oppdatert.

Du kan definere alle skriptene dine i en excel-fil og overlevere denne excel-filen til manuelle testere for å legge til nye skript eller oppdatere de eksisterende. På denne måten kan manuelle testere også bli en del av testautomatisering fordi de ikke trenger å kode noe. De vil bare oppdatere denne excel-filen når det er behov og skript vil automatisk bli oppdatert.

Den andre fordelen er at skriptet ditt blir verktøyuavhengig. Du kan vedlikeholde skriptene dine i en excel-fil, og hvis du trenger å endre automatiseringsverktøyet ditt på et eller annet tidspunkt, kan du enkelt endre det ved å skrive en excel-parser i et annet verktøy.

Ulempen med dette rammeverket er at du trenger å finne opp søkeord for forskjellige typer handlinger. I store prosjekter vil det være så mange søkeord at du trenger å huske og organisere skriptene og søkeordene dine. Dette blir i seg selv en tungvint oppgave på et tidspunkt.

I noen komplekse scenarier, hvor objekter ikke lett kan identifiseres og vi trenger å bruke musekoordinater og andre teknikker, er dette rammeverket ikke veldig nyttig.

Søkeorddrevet er fortsatt et favorittrammeverk for mange automatiseringstestere. Roboteramme av Google er et populært søkeorddrevet rammeverk som støttes av et aktivt fellesskap.

# 5. Hybrid Test Automation Framework:

Kjennetegn:

  • Kombinasjonen av to eller flere av de ovennevnte teknikkene, som tar ut av styrken og minimerer svakhetene.
  • Rammeverket kan bruke den modulære tilnærmingen sammen med enten datadrevet eller søkeorddrevet rammeverk.
  • Rammeverket kan bruke skript for å utføre noen oppgaver som kan være for vanskelige å implementere i en ren søkeorddrevet tilnærming.

I enkle ord, Hybrid framework, bruk kombinasjonen av de ovennevnte teknikkene. Vi kan bruke et datadrevet rammeverk som også er modulært. I noen testtilfeller kan vi bruke søkeorddrevet tilnærming, og for å være igjen kan vi bruke modulær. Så når vi blander to eller flere teknikker som er nevnt i denne artikkelen, bruker vi faktisk en hybrid tilnærming.

Konklusjon

Jeg håper at rammen for testautomatisering ikke lenger er et skummelt begrep for deg nå. Jeg prøvde å forklare de mest populære rammene så enkelt som mulig.

topp 10 gratis nedlastingssider for mp3

Rammeverk er her for å gjøre livet ditt lettere. De hjelper deg med å skrive vedlikeholdbare og pålitelige skript. Uten å bruke rammer er testautomatiseringsfeltet et mareritt. For hver liten endring i applikasjonen, må du endre koden hundrevis av steder.

Så en forståelse av disse rammene er et must for alle tester som ønsker en smak av testautomatisering.

I vår neste opplæring i denne serien vil vi lære 'Utførelse og rapportering av testautomatisering'.

Hvis jeg har savnet noe i denne artikkelen, eller du trenger å stille spørsmål, er du velkommen til å spørre i kommentarfeltet.

PREV Opplæring # 4 | NESTE opplæring # 6

Anbefalt lesing

^