Mest populære testautomatiseringsrammer med fordele og ulemper ved hver - Selen-tutorial # 20

most popular test automation frameworks with pros

I de sidste par Selen-tutorials diskuterede vi forskellige almindeligt anvendte og populære kommandoer i WebDriver , håndtering af webelementer som webtabeller, rammer og håndtering af undtagelser i Selen-scripts.

Vi diskuterede hver af disse kommandoer med eksempelkodestykker og eksempler for at gøre dig i stand til at bruge disse kommandoer effektivt, når du oplever lignende situationer. Blandt de kommandoer, vi diskuterede i den foregående vejledning, er det kun få af dem, der skylder den største betydning.

Når vi bevæger os fremad i Selenium-serien, vil vi koncentrere vores fokus mod Automation Framework oprettelse i de næste par kommende tutorials. Vi vil også kaste lys over forskellige aspekter af en automatiseringsramme, typer af automatiseringsrammer, fordelene ved at bruge en ramme og de grundlæggende komponenter, der udgør en automatiseringsramme.

Hvad du lærer:

• Hvad er Framework?
• Test automatiseringsrammen
• Typer af testautomatiseringsrammer
• # 1) Modulbaseret testramme
• # 2) Biblioteksarkitektur Testing Framework
• # 3) Datadrevet testramme
• # 4) Søgeordsdrevet testramme
• # 5) Hybrid Testing Framework
• # 6) Behavior Driven Development Framework
• Konklusion
• Anbefalet læsning

Hvad er Framework?

En ramme betragtes som en kombination af faste protokoller, regler, standarder og retningslinjer, der kan indarbejdes eller følges som en helhed for at udnytte fordelene ved stilladset, der leveres af rammen.

Lad os overveje et virkeligt scenarie.

Vi bruger meget ofte elevatorer eller elevatorer. Der er et par retningslinjer, de er nævnt i elevatoren, der skal følges og fjernes for at udnytte den maksimale fordel og langvarige service fra systemet.

Således har brugerne måske bemærket følgende retningslinjer:

• Kontroller elevatorens maksimale kapacitet og gå ikke op i en elevator, hvis den maksimale kapacitet er nået.
• Tryk på alarmknappen i tilfælde af en nødsituation eller problemer.
• Lad passageren komme ud af elevatoren, inden der er gået ind i elevatoren, og stå fri af dørene.
• I tilfælde af brand i bygningen, eller hvis der er en tilfældig situation, skal du undgå at bruge elevatoren.
• Du må ikke lege eller springe ind i elevatoren.
• Ryg ikke inde i elevatoren.
• Ring for hjælp / hjælp, hvis døren ikke åbner, eller hvis elevatoren slet ikke fungerer. Forsøg ikke at åbne dørene kraftigt.

Der kan være mange flere regler eller sæt retningslinjer. Således gør disse retningslinjer, hvis de følges, systemet mere fordelagtigt, tilgængeligt, skalerbart og mindre uroligt for brugerne.

Når vi nu taler om 'Test Automation Frameworks', lad os flytte vores fokus mod dem.

Test automatiseringsrammen

En “Test Automation Framework” er stilladser, der er lagt for at give et eksekveringsmiljø for automatiseringstest-scripts. Rammen giver brugeren forskellige fordele, der hjælper dem med at udvikle, udføre og rapportere automatiseringstest-scripts effektivt. Det ligner mere et system, der er oprettet specifikt for at automatisere vores tests.

På et meget simpelt sprog kan vi sige, at en ramme er en konstruktiv blanding af forskellige retningslinjer, kodningsstandarder, koncepter, processer, praksis, projekthierarkier, modularitet, rapporteringsmekanisme, testdataindsprøjtninger osv. Til søjleautomatiseringstest. Således kan brugeren følge disse retningslinjer, mens applikationen automatiseres for at drage fordel af forskellige produktive resultater.

Fordelene kan være i forskellige former som f.eks. Let scripting, skalerbarhed, modularitet, forståelighed, procesdefinition, genanvendelighed, omkostninger, vedligeholdelse osv. For at kunne få fat i disse fordele rådes udviklere til at bruge en eller flere af Test Automation Framework.

Desuden opstår behovet for en enkelt og standard Test Automation Framework, når du har en masse udviklere, der arbejder på de forskellige moduler i den samme applikation, og når vi ønsker at undgå situationer, hvor hver af udviklerne implementerer sin tilgang til automatisering.

Bemærk : Vær opmærksom på, at en testramme altid er applikationsuafhængig, dvs. at den kan bruges med enhver applikation uanset komplikationerne (som Technology stack, arkitektur osv.) Af applikationen, der testes. Rammen skal være skalerbar og vedligeholdelig.

Fordel ved rammen om testautomatisering

1. Genanvendelighed af kode
2. Maksimal dækning
3. Gendannelsesscenarie
4. Lav vedligeholdelse
5. Minimal manuel indgriben
6. Nem rapportering

Typer af testautomatiseringsrammer

Nu hvor vi har en grundlæggende idé om, hvad der er en automatiseringsramme, vil vi i dette afsnit forkynde dig med de forskellige typer testautomatiseringsrammer, der er tilgængelige på markedet. Vi vil også prøve at kaste lys over deres fordele og ulemper og anvendelighedsanbefalinger.

Der er et divergerende udvalg af automatiseringsrammer tilgængelige i dag. Disse rammer kan variere fra hinanden baseret på deres støtte til forskellige nøglefaktorer til automatisering som genanvendelighed, let vedligeholdelse osv.

forskel mellem alfatest og betatest

Lad os diskutere de få mest populære brugte testautomatiseringsrammer:

1. Modulbaseret testramme
2. Biblioteksarkitektur Testing Framework
3. Datadrevet testramme
4. Keyword Driven Testing Framework
5. Hybrid Testing Framework
6. Behavior Driven Development Framework

(klik på billedet for at se forstørret)

Lad os diskutere hver af dem i detaljer.

Men før det vil jeg også nævne, at brugeren til trods for at have denne ramme altid er gearet til at opbygge og designe sin egen ramme, der passer bedst til hans / hendes projektbehov.

# 1) Modulbaseret testramme

Modulbaseret testramme er baseret på et af det populært kendte OOP-koncept - Abstraktion. Rammen deler hele 'Application Under Test' i et antal logiske og isolerede moduler. For hvert modul opretter vi et separat og uafhængigt testscript. Således, når disse testskripter samlet bygger et større test script, der repræsenterer mere end et modul.

Disse moduler er adskilt af et abstraktionslag på en sådan måde, at de ændringer, der er foretaget i sektionerne i applikationen, ikke påvirker dette modul.

Fordele:

1. Rammen introducerer det høje niveau af modulering, hvilket fører til lettere og omkostningseffektiv vedligeholdelse.
2. Rammen er stort set skalerbar
3. Hvis ændringerne implementeres i en del af applikationen, er det kun testscriptet, der repræsenterer den del af applikationen, der skal løses for at lade alle de andre dele være uberørt.

Ulemper:

1. Mens vi implementerer testskripter for hvert modul separat, integrerer vi testdataene (data, som vi skal udføre test med) i testskripterne. Således, når vi formodes at teste med et andet sæt testdata, kræver det, at manipulationerne foretages i testskripterne.

# 2) Biblioteksarkitektur Testing Framework

Library Architecture Testing Framework er grundlæggende og grundlæggende bygget på modulbaseret testramme med nogle yderligere fordele. I stedet for at opdele applikationen under test i testskripter, adskiller vi applikationen i funktioner, ellers kan almindelige funktioner også bruges af de andre dele af applikationen. Således opretter vi et fælles bibliotek, der udgør fælles funktioner for den applikation, der testes. Derfor kan disse biblioteker kaldes fra testskripterne, når det er nødvendigt.

Det grundlæggende fundament bag rammen er at bestemme de fælles trin og gruppere dem i funktioner under et bibliotek og kalde disse funktioner i testskripterne, når det er nødvendigt.

Eksempel : Login-trinene kan kombineres til en funktion og gemmes i et bibliotek. Således kan alle testskripterne, der kræves for at logge ind, kalde den funktion i stedet for at skrive koden igen.

Fordele:

1. Ligesom modulbaseret ramme introducerer denne ramme også det høje niveau af modularisering, hvilket også fører til lettere og omkostningseffektiv vedligeholdelse og skalerbarhed.
2. Når vi opretter fælles funktioner, der effektivt kan bruges af de forskellige testskripter på tværs af rammen. Således introducerer rammen en stor grad af genanvendelighed.

Ulemper:

1. Ligesom modulbaseret ramme indlæses testdataene i testskripterne, og enhver ændring i testdataene vil også kræve ændringer i testscriptet.
2. Med introduktionen af ​​biblioteker bliver rammen lidt kompliceret.

# 3) Datadrevet testramme

Mens du automatiserer eller tester enhver applikation, kan det til tider være nødvendigt at teste den samme funktionalitet flere gange med det forskellige sæt inputdata. I sådanne tilfælde kan vi således ikke lade testdataene være integreret i testscriptet. Derfor tilrådes det at gemme testdata i en ekstern database uden for testskripterne.

Data Driven Testing Framework hjælper brugeren med at adskille testscriptlogikken og testdataene fra hinanden. Det lader brugeren gemme testdataene i en ekstern database. De eksterne databaser kan være ejendomsfiler, xml-filer, excel-filer, tekstfiler, CSV-filer, ODBC-arkiver osv. Dataene gemmes traditionelt i 'Key-Value' -par. Således kan nøglen bruges til at få adgang til og udfylde dataene i testskripterne.

Bemærk : Testdataene, der er gemt i en ekstern fil, kan høre til matrixen med den forventede værdi såvel som matrixen med inputværdier.

ved fejl genoptages næste i qtp

Eksempel:

Lad os forstå ovenstående mekanisme ved hjælp af et eksempel.

Lad os overveje funktionerne 'Gmail - Login'.

Trin 1: Første og første trin er at oprette en ekstern fil, der gemmer testdataene (inputdata og forventede data). Lad os f.eks. Overveje et excel-ark.

Trin 2: Det næste trin er at udfylde testdataene i Automation test Script. Til dette formål kan flere API'er bruges til at læse testdataene.

Ovenstående metode hjælper med at læse testdataene, og nedenstående teststrin hjælper brugeren med at indtaste testdataene på GUI'en.

element.sendKeys (obj_value.get (obj_index));

Fordele:

1. Det vigtigste ved denne ramme er, at den reducerer det samlede antal scripts, der kræves for at dække alle mulige kombinationer af testscenarier, betydeligt. Således kræves mindre mængde kode for at teste et komplet sæt scenarier.
2. Enhver ændring i testdatamatrixen hæmmer ikke testscriptkoden.
3. Øger fleksibilitet og vedligeholdelse
4. Et enkelt testscenarie kan udføres, hvorved testdataværdierne ændres.

Ulemper:

1. Processen er kompleks og kræver en ekstra indsats for at komme med testdatakilderne og læsemekanismerne.
2. Kræver færdigheder i et programmeringssprog, der bruges til at udvikle testskripter.

# 4) Søgeordsdrevet testramme

Den nøgleordsdrevne testramme er en udvidelse til Data driven Testing Framework på en måde, at den ikke kun adskiller testdataene fra scriptsne, men holder også det bestemte sæt kode, der hører til testscriptet, i en ekstern datafil.

Disse sæt kode kaldes nøgleord, og derfor er rammen så navngivet. Nøgleord er selvstyrende for, hvilke handlinger der skal udføres på applikationen.

Nøgleordene og testdataene er gemt i en strukturel struktur, og derfor betragtes det også populært som en tabeldrevet ramme. Vær opmærksom på, at nøgleord og testdata er enheder, der er uafhængige af det anvendte automatiseringsværktøj.

EksempelTest tilfælde af Keyword Driven Test Framework

I ovenstående eksempel er nøgleord som login, klik og bekræft link defineret i koden.
Afhængig af karakteren af ​​applikationen kan nøgleord udledes. Og alle nøgleordene kan genbruges flere gange i en enkelt testsag. Finderkolonne indeholder lokaliseringsværdien, der bruges til at identificere webelementerne på skærmen eller de testdata, der skal leveres.

Alle de krævede nøgleord er designet og placeret i rammens grundkode.

Fordele:

1. Ud over fordele, der leveres af datadrevet test, kræver søgeordsdrevet ramme ikke brugeren at have scripting-viden, i modsætning til datadrevet test.
2. Et enkelt nøgleord kan bruges på tværs af flere testskripter.

Ulemper:

1. Brugeren skal være velbevandret med mekanismen til oprettelse af nøgleord for effektivt at kunne udnytte fordelene ved rammen.
2. Rammen kompliceres gradvist, efterhånden som den vokser, og et antal nye nøgleord introduceres.

# 5) Hybrid Testing Framework

Som navnet antyder, er Hybrid Testing Framework en kombination af mere end en af ​​ovennævnte rammer. Det bedste ved en sådan opsætning er, at den udnytter fordelene ved alle mulige tilknyttede rammer.

Eksempelaf Hybrid Framework

Testark ville indeholde både nøgleordene og dataene.

I ovenstående eksempel indeholder nøgleordskolonnen alle de krævede nøgleord, der bruges i den bestemte testtilfælde, og datakolonnen driver alle de krævede data i testscenariet. Hvis et trin ikke har brug for input, kan det stå tomt.

# 6) Behavior Driven Development Framework

Behavior Driven Development framework tillader automatisering af funktionelle valideringer i letlæseligt og forståeligt format til forretningsanalytikere, udviklere, testere osv. Sådanne rammer kræver ikke nødvendigvis, at brugeren er bekendt med programmeringssprog. Der er forskellige værktøjer til rådighed til BDD som agurk, Jbehave osv. Detaljer om BDD-rammer diskuteres senere i Agurk-tutorial. Vi har også diskuteret detaljer om agurkisprog for at skrive testsager i agurk.

Komponenter i Automation Testing Framework

Selvom ovenstående billedlige gengivelse af en ramme er selvforklarende, vil vi stadig fremhæve et par punkter.

1. Objektlager : Objektregister akronym som OR er sammensat af det sæt lokaliseringstyper, der er knyttet til webelementer.
2. Testdata: De inputdata, som scenariet ville blive testet med, og det kan være de forventede værdier, som de faktiske resultater vil blive sammenlignet med.
3. Konfigurationsfil / konstanter / miljøindstillinger : Filen gemmer oplysningerne om applikations-URL'en, browserspecifik information osv. Det er generelt de oplysninger, der forbliver statiske gennem hele rammen.
4. Generik / programlogik / læsere : Dette er de klasser, der gemmer de funktioner, der ofte kan bruges i hele rammen.
5. Byg værktøjer og kontinuerlig integration : Dette er de værktøjer, der hjælper rammens evner til at generere testrapporter, e-mail-underretninger og loggeoplysninger.

Konklusion

De rammer, der er illustreret ovenfor, er de mest populære rammer, der bruges af testbrødrene. Der er forskellige andre rammer også på stedet. For alle de yderligere tutorials vil vi basere på Datadrevet testramme .

I denne vejledning diskuterede vi det grundlæggende i en automatiseringsramme. Vi diskuterede også de typer rammer, der er tilgængelige på markedet.

Næste tutorial # 21 : I den næste vejledning ville vi kort introducere dig til prøve rammen, MS Excel, som vil gemme testdata, excel manipulationer osv.

Indtil da er du velkommen til at stille dine spørgsmål om automatiseringsrammer.

Anbefalet læsning

• 7 faktorer, der påvirker testestimering af selen-automatiseringsprojekt - Selen-tutorial # 32
• Introduktion til Selen WebDriver - Selen Tutorial # 8
• Effektiv Selen Scripting og fejlfinding af scenarier - Selen Tutorial # 27
• Fejlfinding af selen-scripts med logfiler (Log4j-vejledning) - Selen-tutorial # 26
• 30+ bedste selen-tutorials: Lær selen med rigtige eksempler
• Dybdegående formørkelsesvejledninger til begyndere
• Sådan finder du elementer i Chrome og IE-browsere til opbygning af selen-scripts - Selen Tutorial # 7
• Agurk Selen Tutorial: Agurk Java Selen WebDriver Integration