Testautomatiseringsramme: ArchiTekstur og typer

Hvad er Framework i automationstestning?

A Test Automation Framework er et sæt retningslinjer som kodningsstandarder, håndtering af testdata, behandling af objektlager osv... som, når de følges under automatisering af scripting, giver gavnlige resultater som øget genbrug af kode, højere portabilitet, reducerede omkostninger til scriptvedligeholdelse osv. Dette er kun retningslinjer og ikke regler; de er ikke obligatoriske, og du kan stadig skrive scripts uden at følge retningslinjerne. Men du vil gå glip af fordelene ved at have et Framework.

Hvorfor har du brug for et Framework?

Lad os overveje et eksempel for at forstå, hvorfor du har brug for et Framework.

Jeg er sikker på, at du har deltaget i et seminar/foredrag/konference, hvor deltagerne blev bedt om at overholde følgende retningslinjer –

• Deltagerne skal besætte deres pladser 5 minutter før starten af ​​en forelæsning.
• Medbring en notesbog og pen til note.
• Læs mavemusklernetracså du har en idé om, hvad præsentationen vil handle om.
• Mobiltelefoner skal indstilles til lydløs.
• Brug udgangsportene i den modsatte ende af højttaleren, hvis du har brug for at forlade det midt i foredraget.
• Spørgsmål vil blive taget i slutningen af ​​sessionen.

Tror du, du kan afholde et seminar UDEN overholdelse af disse retningslinjer?

Svaret er stort JA! Bestemt, du kan afholde et seminar/foredrag/konference/demonstration uden ovenstående retningslinjer.. faktisk vil nogle af os ikke følge dem, selvom der er fastlagt!

Men hvis retningslinjerne følges, vil det resultere i et gavnligt resultat, såsom reduceret publikumsforstyrrelsetraction under forelæsninger, øget deltagerfastholdelse og forståelse af emnet.

På baggrund af ovenstående, en Framework kan defineres som et sæt retningslinjer, der, når de følges, giver gavnlige resultater.

Test Automation Framework ArchiTekstur: Nøglekomponenter

Før man sammenligner typerne, er det en god idé at se, hvad hvert framework indeholder. ArchiTekstur beskriver, hvordan disse dele er lagdelt, så en ændring i ét lag ikke bryder de andre.

• Testscriptlag: Indeholder testtilfældene. Scripts forbliver korte, fordi de kalder genbrugelige funktioner i stedet for at gentage navigationstrin.
• Funktionsbibliotek: Gemmer delte handlinger såsom login, søgning og log ud, så en ændring af arbejdsgangen foretages én gang.
• Objektlager: Knytter brugervenlige navne til GUI-elementplaceringer. Når brugerfladen ændres, redigeres kun dette lag.
• Testdatalag: Bevarer input og forventede værdier i Excel, CSV eller databasekilder i stedet for inde i koden.
• Konfigurationslag: Indeholder miljø URLs, browservalg, timeouts og legitimationsoplysninger.
• Rapporteringslag: Producerer udførelsesrapporter, skærmbilleder af fejl og diagnosticeringslogfiler.
• Udførelseslag: Udløser suiter fra en byggeserver, der forbinder automatisering til kontinuerlig integration.

Framework-typerne nedenfor adskiller sig primært i, hvor strengt de adskiller disse lag.

Typer af testautomatiseringsrammer

Nedenfor er de forskellige typer af automatiserede testrammer:

1. Lineær scripting
2. Testbiblioteket Architecture Framework.
3. Den datadrevne Test Ramme.
4. Det søgeordsdrevne eller tabeldrevne testframework.
5. Hybrid testautomatiseringsrammeværk.

Lad os se på dem i detaljer -

1) Lineær scripting – Optag og afspilning

Det er det enkleste af alle Test Automation Frameworks og også kendt som "Optag og afspil". I denne Test af automatisering Framework, testeren registrerer manuelt hvert trin (navigation og brugerinput), indsætter kontrolpunkter (valideringstrin) i første runde. Han afspiller derefter det indspillede manuskript i de efterfølgende runder.

Eksempel: Overvej at logge ind Ansøgning om flyreservation og kontrollere, om applikationen er indlæst ved vellykket log-on. Her vil testeren blot registrere trinene og tilføje valideringstrin.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Fordele

• Hurtigste måde at generere et script på
• Automatiseringsekspertise er ikke påkrævet
• Den nemmeste måde at lære funktionerne i testværktøjet

Ulemper

• Lidt genbrug af scripts
• Testdata er hardkodet ind i scriptet
• Vedligeholdelse mareridt

2) Testbiblioteket Architecture Framework

Det er også kendt som "Struktureret scripting" or "Funktionel nedbrydning".

I dette Automation Testing Framework optages testscripts oprindeligt af "Optag & afspilning”Metode. Later, er almindelige opgaver inde i scripts identificeret og grupperet i funktioner. Disse funktioner kaldes af hovedtestscriptet Chauffør på forskellige måder at skabe testcases.

Eksempel: Ved at bruge samme eksempel som ovenfor, vil funktionen til at logge ind på Flight Reservation se ud.

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Nu vil du kalde denne funktion i hovedscriptet som følger

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Fordele

• Højere niveau af kodegenbrug opnås i Structured Scripting sammenlignet med "Record & Playback"
• Automatiseringsscripts er billigere at udvikle på grund af højere genbrug af kode
• Nemmere scriptvedligeholdelse

Ulemper

• Teknisk ekspertise er nødvendig for at skrive scripts ved hjælp af Test Library Framework
• Der kræves mere tid til at planlægge og forberede testscripts.
• Testdata er hårdkodet i scripts

3) Den datadrevne testramme

I denne ramme, mens Test sag Da logikken ligger i testscripts, adskilles testdataene og opbevares uden for testscriptsene. Testdata læses fra de eksterne filer (Excel-filer, tekstfiler, CSV-filer, ODBC-kilder, DAO-objekter, ADO-objekter) og indlæses i variablerne i testscriptet. Variabler bruges både til inputværdier og til verifikationsværdier. Selve testscripts udarbejdes enten ved hjælp af Linear Scripting eller Test Library Framework. Teknikken forklares yderligere i datadrevet test tutorial.

Eksempel: Udviklingping Login-scriptet til flyreservation ved hjælp af denne metode vil involvere to trin.

Trin 1) Opret en test – Datafil, som kunne være Excel, CSV eller enhver anden databasekilde.

Trin 2) Udvikl testscript og foretag referencer til din testdatakilde.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Fordele

• Ændringer i testscripts påvirker ikke testdata
• Testcases kan udføres med flere sæt data
• En række testscenarier kan udføres ved blot at variere testdataene i den eksterne datafil

Ulemper

• Der kræves mere tid til at planlægge og forberede både testscripts og testdata

4) Det nøgleordsdrevne eller tabeldrevne testrammeværk

Søgeordsdrevet eller udvikling af tabeldrevne automatiseringsframeworks kræver datatabeller og nøgleord, uafhængig af testautomatiseringsværktøj bruges til at udføre dem. Tests kan designes med eller uden applikationen. I en søgeordsdrevet test dokumenteres funktionaliteten af ​​applikationen-under-testen i en tabel samt i trin-for-trin instruktioner for hver test.

Der er 3 grundlæggende komponenter i et søgeordsdrevet rammeværk, dvs. Nøgleord , applikationskort , komponentfunktion.

Nøgleord er en handling, der kan udføres på en GUI-komponent. Eks. For GUI Component Textbox ville nogle søgeord (handling) være InputText, VerifyValue, VerifyProperty og så videre.

Hvad er applikationskortet?

Et applikationskort giver navngivne referencer til GUI-komponenter. Applikationskort er intet andet end "Objektopbevaring"

Hvad er komponentfunktion?

Komponentfunktioner er de funktioner, der aktivt manipulerer eller udspørger GUI-komponenten. Et eksempel på en funktion ville være klik på web-knappen med al fejlhåndtering, indtast data i en webredigering med al fejlhåndtering. Komponentfunktioner kan være applikationsafhængige eller uafhængige.

Eksempel: Lad os tage det samme eksempel for at forstå søgeordsvisning. Det involverer 2 trin

Trin 1: Oprettelse af datatabel (forskellig fra testdatatabel oprettet i datadrevet rammeværk). Denne datatabel indeholder handling, der skal udføres på GUI-objekter og tilsvarende argumenter, hvis nogen. Hver række repræsenterer et testtrin.

Trin 2: Skrivning Code i form af komponentfunktioner.

Når du har oprettet dine datatabeller, skriver du blot et program eller et sæt scripts, der læser i hvert trin, udfører trinnet baseret på nøgleordet, der indeholdt handlingsfeltet, udfører fejlkontrol og logger alle relevante oplysninger. Dette program eller sæt scripts ville ligne pseudokoden nedenfor:

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

Det er alt til Keyword Driven Framework.

Fordelen ved Keyword Driven Framework er, at søgeordene kan genbruges. For at forstå dette skal du overveje, at du vil bekræfte login-operationen for et websted, sig YAHOO MAIL. Bordet vil se sådan ud -

Hvis du i dette tilfælde observerer, at nøgleordene Angiv, Klik og Bekræft forbliver de samme, og for hvilke der allerede er udviklet tilsvarende komponentfunktioner. Alt du skal gøre er at ændre applikationskortet.ping (Objektarkiv) fra tidligere flyreservation til Yahoo Mail , med en ændring i argumentværdier og det samme script vil fungere!

Fordele

• Giver høj kodegenanvendelighed
• Testværktøj uafhængig
• Uafhængigt af applikation under test virker det samme script for AUT (med nogle begrænsninger)
• Tests kan designes med eller uden AUT

Ulemper

• Da den oprindelige investering er ret høj, kan fordelene ved dette kun realiseres, hvis applikationen er betydeligt stor, og testscripts skal vedligeholdes i en del år.
• Der kræves høj automatiseringsekspertise for at skabe det søgeordsdrevne rammeværk.

BEMÆRK : Selvom OpenText UFT En (tidligere Micro Focus UFT) reklamerer for at være et søgeordsdrevet framework, kan du ikke opnå fuldstændig uafhængighed af testværktøjer og applikationer ved at bruge det.

5) Hybrid Test Automation Framework

Som navnet antyder er denne ramme kombinationen af ​​et eller flere automatiseringsrammer diskuteret ovenfor, der trækker fra deres styrker og forsøger at afbøde deres svagheder. Den hybride test QA-automatiseringsramme er, hvad de fleste testautomatiseringsrammer udvikler sig til over tid og flere projekter. Maksimal industri bruger Keyword Framework i en kombination af funktionsnedbrydningsmetode.

PS: Andre Automation Frameworks, der er værd at nævne, er

Test Modularity Framework

I denne ramme er en fælles opgave i testscript grupperet sammen som moduler.

EksempelBrug af handlinger i QTP brug kan oprette modulære scripts

Eksempel script til login

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Nu kan du kalde denne handling i hovedscriptet som følger –

RunAction ("Login[Argument]", oneIteration)

Business Process Testing (BPT)

Disse automatiseringsrammer opdeler store forretningsprocesser i komponenter, som kan genbruges flere gange i samme eller forskellige testscripts. For eksempel er forretningsprocessen ved at bestille en flyrejse opdelt i komponenter som Login, Finding af fly, Booking, Betaling og Logout, som kan genbruges i den samme forretningsproces eller forskellige processer. BPT letter også tættere koordinering mellem SMV'er og automationsingeniører.

Sådan vælger du det rigtige testautomatiseringsframework

Ingen enkelt type vinder hver gang. Det rigtige valg afhænger af holdets færdigheder, applikationens størrelse og hvor længe serien skal overleve. Tabellen nedenfor sammenligner de fem typer ud fra de faktorer, der bestemmer resultatet.

Gennemgå disse spørgsmål, før du forpligter dig:

1. Hvor længe vil suiten leve? Årelang vedligeholdelse retfærdiggør den høje initiale investering i et søgeordsdrevet eller hybridt design. Et kort projekt gør det ikke.
2. Hvem skriver prøverne? Hvis manuelle testere bidrager med cases, lader en nøgleordstabel dem arbejde uden at lære scriptsproget.
3. Hvor ustabil er grænsefladen? Hyppig skærmskift gør et separat objektlager nødvendigt, ellers skal hvert script redigeres.
4. Hvor meget datavariation er nødvendig? Mange inputkombinationer peger direkte på et datadrevet design.
5. Hvilket værktøj er allerede i brug? Rammen skal passe til det valgte automatiseringsværktøj og et sprog teamet kender, såsom Selenium med Java or Cucumber.

De fleste teams starter med en biblioteks- eller datadrevet tilgang og udvikler sig derefter mod en hybridmodel, efterhånden som regression suiten udvides.

Fordele ved Test Automation Framework Architecture

Følgende er fordelene ved Test automation framework arkitektur:

• En testautomatiseringsramme hjælper med at reducere risikoen og omkostningerne
• Det forbedrer effektiviteten af ​​tests
• Det hjælper med at reducere vedligeholdelsesomkostningerne
• Tillader genbrug af kode
• Det giver mulighed for at opnå maksimal testdækning
• Det maksimerer applikationens funktionalitet
• Hjælper med at reducere duplikering af testsager
• Det hjælper med at forbedre testeffektiviteten og ydeevnen med testautomatisering

Ofte Stillede Spørgsmål