most popular test automation frameworks with pros
I de siste par Selen-opplæringene diskuterte vi forskjellige vanlige og populære kommandoer i WebDriver , håndtering av webelementer som nettabeller, rammer og håndtering av unntak i selen-skript.
Vi diskuterte hver av disse kommandoene med eksempler på kodebiter og eksempler for å gjøre deg i stand til å bruke disse kommandoene effektivt når du opplever lignende situasjoner. Blant kommandoene vi diskuterte i forrige opplæring, er det få av dem som er av største betydning.
Når vi går videre i Selenium-serien, vil vi konsentrere vårt fokus mot Opprettelse av Automation Framework i de neste kommende opplæringene. Vi vil også belyse ulike aspekter av et automatiseringsrammeverk, typer automatiseringsrammer, fordelene ved å bruke et rammeverk og de grunnleggende komponentene som utgjør et automatiseringsrammeverk.
Hva du vil lære:
- Hva er Framework?
- Test automatiseringsrammer
- Typer av rammen for testautomatisering
- # 1) Modulbasert testramme
- # 2) Framework for testing av biblioteksarkitektur
- # 3) Datadrevet testrammeverk
- # 4) Søkeorddrevet testramme
- # 5) Hybrid Testing Framework
- # 6) Behavior Driven Development Framework
- Konklusjon
- Anbefalt lesing
Hva er Framework?
Et rammeverk anses å være en kombinasjon av faste protokoller, regler, standarder og retningslinjer som kan innlemmes eller følges som en helhet for å utnytte fordelene med stillaset som tilbys av Framework.
La oss se på et virkelig scenario.
Vi bruker veldig ofte heiser eller heiser. Det er noen få retningslinjer som er nevnt i heisen som skal følges og tas vare på for å utnytte maksimal nytte og langvarig service fra systemet.
Dermed kan brukerne ha lagt merke til følgende retningslinjer:
- Kontroller heisens maksimale kapasitet og ikke gå opp i heisen hvis den maksimale kapasiteten har nådd.
- Trykk på alarmknappen i nødstilfeller eller problemer.
- La passasjeren gå av heisen hvis noen før han går inn i heisen og stå utenfor dørene.
- I tilfelle brann i bygningen eller hvis det er en tilfeldig situasjon, må du ikke bruke heisen.
- Ikke spill eller hopp inn i heisen.
- Ikke røyk inne i heisen.
- Ring for hjelp / assistanse hvis døren ikke åpnes eller hvis heisen ikke fungerer i det hele tatt. Ikke prøv å åpne dørene kraftig.
Det kan være mange flere regler eller sett med retningslinjer. Derfor blir disse retningslinjene, hvis de følges, systemet mer fordelaktig, tilgjengelig, skalerbart og mindre urolig for brukerne.
Nå som vi snakker om “Test Automation Frameworks”, la oss flytte fokus mot dem.
Test automatiseringsrammer
Et 'Test Automation Framework' er stillas som er lagt for å gi et utførelsesmiljø for automatiseringstestskriptene. Rammeverket gir brukeren forskjellige fordeler som hjelper dem med å utvikle, utføre og rapportere automatiseringstestskriptene effektivt. Det er mer som et system som er laget spesielt for å automatisere testene våre.
På et veldig enkelt språk kan vi si at et rammeverk er en konstruktiv blanding av ulike retningslinjer, kodingsstandarder, konsepter, prosesser, praksis, prosjekthierarkier, modularitet, rapporteringsmekanisme, testdatainjeksjoner etc. til søyleautomatiseringstesting. Dermed kan brukeren følge disse retningslinjene mens den automatiserer applikasjonen for å dra fordeler av forskjellige produktive resultater.
Fordelene kan være i forskjellige former, som for eksempel enkel skripting, skalerbarhet, modularitet, forståelighet, prosessdefinisjon, gjenbrukbarhet, kostnad, vedlikehold osv. For å være i stand til å få tak i disse fordelene, anbefales utviklere å bruke en eller flere av Test Automation Framework.
Videre oppstår behovet for en enkelt og standard Test Automation Framework når du har en rekke utviklere som jobber med de forskjellige modulene i samme applikasjon, og når vi vil unngå situasjoner der hver av utviklerne implementerer sin tilnærming til automatisering.
Merk : Legg merke til at et testrammeverk alltid er applikasjonsuavhengig, det vil si at det kan brukes med alle applikasjoner uavhengig av komplikasjonene (som Technology stack, arkitektur osv.) Av applikasjonen som testes. Rammeverket skal være skalerbart og vedlikeholdbart.
Fordelen med rammen for testautomatisering
- Gjenbrukbarhet av kode
- Maksimal dekning
- Gjenopprettingsscenario
- Lavpris vedlikehold
- Minimal manuell inngrep
- Enkel rapportering
Typer av rammen for testautomatisering
Nå som vi har en grunnleggende ide om hva som er et automatiseringsrammer, vil vi i denne delen forespeile deg med de forskjellige typene av testautomatiseringsrammer som er tilgjengelige på markedet. Vi vil også prøve å kaste lys over fordeler og ulemper og bruksanbefalinger.
Det er et divergerende utvalg av automatiseringsrammer tilgjengelig i dag. Disse rammene kan variere fra hverandre basert på deres støtte til forskjellige nøkkelfaktorer for å gjøre automatisering som gjenbrukbarhet, enkelt vedlikehold etc.
hva er brukertestetesting i programvaretesting
La oss diskutere de få mest brukte rammene for testautomatisering:
- Modulbasert testramme
- Biblioteksarkitektur Testing Framework
- Data Driven Testing Framework
- Keyword Driven Testing Framework
- Hybrid Testing Framework
- Behavior Driven Development Framework
(klikk på bildet for å se forstørret)
La oss diskutere hver av dem i detalj.
Men før det vil jeg også nevne at til tross for at han har dette rammeverket, er brukeren alltid utnyttet til å bygge og designe sitt eget rammeverk som passer best til hans / hennes prosjektbehov.
# 1) Modulbasert testramme
Modulbasert Testing Framework er basert på et av det populære OOP-konseptet - Abstraction. Rammeverket deler hele “Application Under Test” i et antall logiske og isolerte moduler. For hver modul lager vi et eget og uavhengig testskript. Dermed bygger disse testskriptene sammen et større testskript som representerer mer enn én modul.
Disse modulene er atskilt med et abstraksjonslag på en slik måte at endringene som er gjort i delene av applikasjonen ikke gir innvirkning på denne modulen.
Fordeler:
- Rammeverket introduserer det høye nivået av modularisering som fører til enklere og kostnadseffektivt vedlikehold.
- Rammeverket er ganske skalerbart
- Hvis endringene er implementert i en del av applikasjonen, er det bare testskriptet som representerer den delen av applikasjonen som må fikses for å la alle de andre delene være uberørt.
Ulemper:
- Mens vi implementerer testskript for hver modul separat, legger vi inn testdataene (data som vi skal utføre testing med) i testskriptene. Således, når vi skal teste med et annet sett med testdata, krever det at manipulasjonene gjøres i testskriptene.
# 2) Framework for testing av biblioteksarkitektur
Library Architecture Testing Framework er fundamentalt og grunnleggende bygget på modulbasert testing Framework med noen ekstra fordeler. I stedet for å dele applikasjonen under test i testskript, adskiller vi applikasjonen i funksjoner, eller heller kan vanlige funksjoner brukes av de andre delene av applikasjonen også. Dermed lager vi et felles bibliotek som består av vanlige funksjoner for applikasjonen som testes. Derfor kan disse bibliotekene kalles fra testskriptene når det er nødvendig.
Det grunnleggende fundamentet bak rammeverket er å bestemme de vanlige trinnene og gruppere dem i funksjoner under et bibliotek og kalle disse funksjonene i testskriptene når det er nødvendig.
Eksempel : Innloggingstrinnene kan kombineres til en funksjon og holdes i et bibliotek. Dermed kan alle testskriptene som kreves for å logge inn, ringe den funksjonen i stedet for å skrive koden på nytt.
Fordeler:
- I likhet med modulbasert rammeverk introduserer dette rammeverket også det høye nivået av modulering som fører til enklere og kostnadseffektivt vedlikehold og skalerbarhet.
- Når vi lager vanlige funksjoner som effektivt kan brukes av de forskjellige testskriptene over hele rammeverket. Dermed introduserer rammeverket en stor grad av gjenbrukbarhet.
Ulemper:
- I likhet med modulbasert rammeverk blir testdataene lagt inn i testskriptene, og enhver endring i testdataene vil også kreve endringer i testskriptet.
- Med innføringen av biblioteker blir rammeverket litt komplisert.
# 3) Datadrevet testrammeverk
Mens du automatiserer eller tester et hvilket som helst program, kan det til tider være nødvendig å teste den samme funksjonaliteten flere ganger med det forskjellige settet med inndata. I slike tilfeller kan vi ikke la testdataene være innebygd i testskriptet. Derfor anbefales det å oppbevare testdata i en ekstern database utenfor testskriptene.
Data Driven Testing Framework hjelper brukeren å adskille testskriptlogikken og testdataene fra hverandre. Den lar brukeren lagre testdataene i en ekstern database. De eksterne databasene kan være eiendomsfiler, xml-filer, excel-filer, tekstfiler, CSV-filer, ODBC-arkiver etc. Dataene lagres konvensjonelt i 'Key-Value' -par. Dermed kan nøkkelen brukes til å få tilgang til og fylle ut dataene i testskriptene.
Merk : Testdataene som er lagret i en ekstern fil, kan høre til matrisen med forventet verdi så vel som matrisen til inngangsverdiene.
kvalitetssikringsanalytiker intervju spørsmål og svar
Eksempel:
La oss forstå mekanismen ovenfor ved hjelp av et eksempel.
La oss se på funksjonen 'Gmail - Pålogging'.
Trinn 1: Første og fremste trinn er å lage en ekstern fil som lagrer testdataene (Input data and Expected Data). La oss for eksempel vurdere et excel-ark.
Steg 2: Neste trinn er å fylle ut testdataene i Automation test Script. For dette formålet kan flere API-er brukes til å lese testdataene.
public void readTD(String TestData, String testcase) throws Exception { TestData=readConfigData(configFileName,'TestData',driver); testcase=readConfigData(configFileName,'testcase',driver); FileInputStream td_filepath = new FileInputStream(TestData); Workbook td_work =Workbook.getWorkbook(td_filepath); Sheet td_sheet = td_work.getSheet(0); if(counter==0) { for (int i = 1,j = 1; i <= td_sheet.getRows()-1; i++){ if(td_sheet.getCell(0,i).getContents().equalsIgnoreCase(testcase)){ startrow = i; arrayList.add(td_sheet.getCell(j,i).getContents()); testdata_value.add(td_sheet.getCell(j+1,i).getContents());}} for (int j = 0, k = startrow +1; k <= td_sheet.getRows()-1; k++){ if (td_sheet.getCell(j,k).getContents()==''){ arrayList.add(td_sheet.getCell(j+1,k).getContents()); testdata_value.add(td_sheet.getCell(j+2,k).getContents());}} } counter++; }
Ovennevnte metode hjelper deg å lese testdataene, og testtrinnet nedenfor hjelper brukeren til å skrive inn testdataene på GUI.
element.sendKeys (obj_value.get (obj_index));
Fordeler:
- Det viktigste ved dette rammeverket er at det reduserer det totale antallet skript som kreves for å dekke alle mulige kombinasjoner av testscenarier betydelig. Dermed kreves mindre mengde kode for å teste et komplett sett med scenarier.
- Enhver endring i testdatamatrisen vil ikke hindre testskriptkoden.
- Øker fleksibilitet og vedlikehold
- Et enkelt testscenario kan utføres for å endre testdataverdiene.
Ulemper:
- Prosessen er kompleks og krever en ekstra innsats for å komme med testdatakildene og lesemekanismene.
- Krever ferdigheter i et programmeringsspråk som brukes til å utvikle testmanus.
# 4) Søkeorddrevet testramme
Søkeorddrevet testrammeverk er en utvidelse til Data driven Testing Framework i en forstand at det ikke bare adskiller testdataene fra skriptene, det holder også det bestemte settet med kode som tilhører testskriptet, i en ekstern datafil.
Dette settet med kode er kjent som nøkkelord, og derfor er rammeverket så navngitt. Nøkkelord er selvstyrende for hvilke handlinger som må utføres på applikasjonen.
Nøkkelordene og testdataene er lagret i en tabellaktig struktur, og det blir derfor også populært sett på som Table driven Framework. Legg merke til at nøkkelord og testdata er enheter uavhengig av automatiseringsverktøyet som brukes.
EksempelTest case of Keyword Driven Test Framework
I eksemplet ovenfor er nøkkelord som pålogging, klikk og verifisering Link definert i koden.
Avhengig av innholdet i applikasjonen kan nøkkelord utledes. Og alle nøkkelordene kan brukes flere ganger i en enkelt testtilfelle. Locator-kolonnen inneholder lokaliseringsverdien som brukes til å identifisere webelementene på skjermen eller testdataene som må leveres.
Alle nødvendige søkeord er designet og plassert i grunnkoden til rammeverket.
Fordeler:
- I tillegg til fordelene som tilbys ved datadrevet testing, krever ikke søkeorddrevet rammeverk brukeren å ha skriptekunnskap, i motsetning til datadrevet testing.
- Et enkelt nøkkelord kan brukes på flere testskripter.
Ulemper:
- Brukeren bør være godt kjent med søkeordskapningsmekanismen for å effektivt kunne utnytte fordelene som rammeverket gir.
- Rammeverket blir gradvis komplisert etter hvert som det vokser og en rekke nye nøkkelord blir introdusert.
# 5) Hybrid Testing Framework
Som navnet antyder, er Hybrid Testing Framework en kombinasjon av mer enn ett ovenfor nevnte rammeverk. Det beste med et slikt oppsett er at det utnytter fordelene med alle slags tilknyttede rammer.
Eksempelav Hybrid Framework
Testarket vil inneholde både nøkkelordene og dataene.
I eksemplet ovenfor inneholder nøkkelordkolonnen alle de nødvendige nøkkelordene som brukes i den aktuelle testtilfellet, og datakolonnen driver alle dataene som kreves i testscenariet. Hvis et trinn ikke trenger innspill, kan det stå tomt.
# 6) Behavior Driven Development Framework
Behavior Driven Development framework tillater automatisering av funksjonelle valideringer i lett lesbart og forståelig format til forretningsanalytikere, utviklere, testere osv. Slike rammer krever ikke nødvendigvis at brukeren er kjent med programmeringsspråket. Det er forskjellige verktøy tilgjengelig for BDD som agurk, Jbehave osv. Detaljer om BDD-rammeverk blir diskutert senere i Cucumber tutorial. Vi har også diskutert detaljer om agurkespråk for å skrive testsaker i agurk.
Komponenter av Automation Testing Framework
Selv om den ovennevnte billedlige fremstillingen av et rammeverk er selvforklarende, vil vi fremdeles trekke frem noen få punkter.
- Objektregister : Objektregister akronym som OR består av settet med lokaliseringstyper assosiert med webelementer.
- Testdata: Inndataene som scenariet vil bli testet med, og det kan være de forventede verdiene som de faktiske resultatene vil bli sammenlignet med.
- Konfigurasjonsfil / konstanter / miljøinnstillinger : Filen lagrer informasjonen om applikasjons-URL, nettleserspesifikk informasjon osv. Det er vanligvis informasjonen som forblir statisk gjennom hele rammeverket.
- Generikk / Programlogikk / Lesere : Dette er klassene som lagrer funksjonene som ofte kan brukes over hele rammeverket.
- Bygg verktøy og kontinuerlig integrasjon : Dette er verktøyene som hjelper til med rammeverket å generere testrapporter, e-postvarsler og logginformasjon.
Konklusjon
Rammene illustrert ovenfor er de mest populære rammene som brukes av testbrorskapet. Det er forskjellige andre rammer også på stedet. For alle de videre opplæringene vil vi basere på Data Driven Testing Framework .
I denne opplæringen diskuterte vi det grunnleggende i et automatiseringsrammer. Vi diskuterte også hvilke typer rammer som er tilgjengelige i markedet.
Neste opplæring # 21 : I neste opplæring, ville vi kort introdusere deg til eksempelrammeverket, MS Excel som vil lagre testdata, utmerke manipulasjoner etc.
Inntil da er du velkommen til å spørre om automatiseringsrammer.
Anbefalt lesing
- 7 faktorer som påvirker testestimering av selen automatiseringsprosjekt - selen opplæring # 32
- Introduksjon til Selenium WebDriver - Selenium Tutorial # 8
- Effektiv Selen Scripting og feilsøking av scenarier - Selenium Tutorial # 27
- Feilsøking av selen-skript med logger (Log4j-opplæring) - Selen-opplæring # 26
- 30+ beste selenopplæringsprogrammer: Lær selen med virkelige eksempler
- In-Depth Eclipse Tutorials For Beginners
- Hvordan finne elementer i Chrome- og IE-nettlesere for å bygge selen-skript - Veiledning nr. 7
- Agurk Selen Tutorial: Agurk Java Selen WebDriver Integration