Test Automation Framework: Hva er, Architecture & Typer

Hva er rammeverk i automatiseringstesting?

A Test Automation Framework er et sett med retningslinjer som kodingsstandarder, håndtering av testdata, behandling av objektlager osv... som når de følges under automatisering av skripting gir gunstige resultater som økt gjenbruk av kode, høyere portabilitet, reduserte skriptvedlikeholdskostnader osv. Dette er bare retningslinjer og ikke regler; de er ikke obligatoriske, og du kan fortsatt skripte uten å følge retningslinjene. Men du vil gå glipp av fordelene ved å ha et rammeverk.

Hvorfor trenger du et rammeverk?

La oss vurdere et eksempel for å forstå hvorfor du trenger et rammeverk.

Jeg er sikker på at du har deltatt på et seminar/foredrag/konferanse hvor deltakerne ble bedt om å følge følgende retningslinjer –

• Deltakere bør besette plassene sine 5 minutter før starten av en forelesning.
• Ta med en notatbok og penn for å ta notater.
• Les abstraktet, så du har en idé om hva presentasjonen skal handle om.
• Mobiltelefoner bør settes til stille.
• Bruk utgangsportene i motsatt ende av foredragsholderen hvis du trenger å forlate det midt i forelesningen.
• Spørsmål vil bli tatt på slutten av økten.

Tror du kan gjennomføre et seminar UTEN følger disse retningslinjene👍

Svaret er stort JA! Absolutt, du kan gjennomføre et seminar/foredrag/konferanse/demonstrasjon uten de ovennevnte retningslinjene.. faktisk vil noen av oss ikke følge dem selv om det er lagt opp!

Men hvis retningslinjene følges, vil det resultere i et gunstig resultat som redusert publikumsdistraksjon under forelesninger, økt deltakeroppbevaring og forståelse av emnet.

Basert på ovenstående, a Rammeverk kan defineres som et sett med retningslinjer som, når de følges, gir gunstige resultater.

Typer testautomatiseringsrammer

Nedenfor er de forskjellige typene av automatiserte testrammer:

• 1) Lineær skripting
• 2) Testbiblioteket Architecture Framework.
• 3) Den datadrevne Testing Framework.
• 4) Det søkeorddrevne eller tabelldrevne testrammeverket.
• 5) The Hybrid Test Automation Framework.

La oss se på dem i detalj -

1) Lineær skripting – opptak og avspilling

Det er det enkleste av alle Testing Automation Frameworks og også kjent som "Ta opp og spille av". I denne Automatiseringstesting Framework, Tester registrerer manuelt hvert trinn (navigasjon og brukerinndata), setter inn sjekkpunkter (valideringstrinn) i første runde. Deretter spiller han det innspilte manuset i de påfølgende rundene.

Eksempel: Vurder å logge på Søknad om flyreservasjon og sjekke om applikasjonen har lastet inn ved vellykket pålogging. Her vil testeren ganske enkelt registrere trinnene og legge til valideringstrinn.

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")

Fordeler

• Raskeste måten å generere et skript på
• Automatiseringskompetanse ikke nødvendig
• Den enkleste måten å lære funksjonene til testverktøyet

Ulemper

• Lite gjenbruk av manus
• Testdata er hardkodet inn i skriptet
• Vedlikeholdsmareritt

2) Testbiblioteket Architecture Framework

Det er også kjent som "Strukturert skripting" or "Funksjonell dekomponering".

I dette rammeverket for automatiseringstesting blir testskript først registrert av "Record & Playback”Metoden. Later, blir vanlige oppgaver inne i skriptene identifisert og gruppert i funksjoner. Disse funksjonene kalles av hovedtestskriptet Driver på ulike måter for å lage testcases.

Eksempel: Ved å bruke samme eksempel som ovenfor, vil funksjonen for å logge inn på Flight Reservation se ut som .

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

Nå vil du kalle denne funksjonen i hovedskriptet som følger

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

Fordeler

• Høyere nivå av kodegjenbruk oppnås i Structured Scripting sammenlignet med "Record & Playback"
• Automatiseringsskriptene er mindre kostbare å utvikle på grunn av høyere gjenbruk av kode
• Enklere skriptvedlikehold

Ulemper

• Teknisk ekspertise er nødvendig for å skrive skript ved hjelp av Test Library Framework
• Mer tid er nødvendig for å planlegge og forberede testskript.
• Testdata er hardkodet i skriptene

3) Det datadrevne testrammeverket

I dette rammeverket, mens Testsak logikken ligger i testskriptene, testdataene er separert og holdt utenfor testskriptene. Testdata leses fra de eksterne filene (Excel-filer, tekstfiler, CSV-filer, ODBC-kilder, DAO-objekter, ADO-objekter) og lastes inn i variablene inne i testskriptet. Variabler brukes både for inngangsverdier og for verifikasjonsverdier. Testskriptene i seg selv er utarbeidet enten ved hjelp av Linear Scripting eller Test Library Framework.

Eksempel: Å utvikle flyreservasjonspåloggingsskriptet ved hjelp av denne metoden vil innebære to trinn.

Trinn 1) Lag en test – Datafil som kan være Excel, CSV eller en annen databasekilde.

Agentnavn	Passord
Jimmy	Mercury
Tina	MERCURY
Bill	Merkur

Trinn 2) Utvikle testskript og referanser til testdatakilden din.

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.

Fordeler

• Endringer i testskriptene påvirker ikke testdataene
• Testtilfeller kan utføres med flere sett med data
• En rekke testscenarier kan utføres ved å bare variere testdataene i den eksterne datafilen

Ulemper

• Mer tid er nødvendig for å planlegge og forberede både testskript og testdata

4) Det søkeorddrevne eller tabelldrevne testrammeverket

Utviklingen av nøkkelorddrevet eller tabelldrevet automatiseringsrammeverk krever datatabeller og nøkkelord, uavhengig av testautomatiseringsverktøy brukes til å henrette dem. Tester kan designes med eller uten applikasjonen. I en nøkkelorddrevet test dokumenteres funksjonaliteten til applikasjonen-under-testen i en tabell samt i trinnvise instruksjoner for hver test.

Det er 3 grunnleggende komponenter i et nøkkelorddrevet rammeverk, nemlig. Nøkkelord , applikasjonskart , komponentfunksjon.

Hva er et nøkkelord?

Nøkkelord er en handling som kan utføres på en GUI-komponent. Eks. For GUI-komponenttekstboks vil noen nøkkelord (handling) være InputText, VerifyValue, VerifyProperty og så videre.

Hva er applikasjonskartet?

Et applikasjonskart gir navngitte referanser for GUI-komponenter. Applikasjonskart er ingenting annet enn "Objektlager"

Hva er komponentfunksjon?

Komponentfunksjoner er de funksjonene som aktivt manipulerer eller avhører GUI-komponenten. Et eksempel på en funksjon vil være klikk på web-knappen med all feilhåndtering, skriv inn data i en webredigering med all feilhåndtering. Komponentfunksjoner kan være applikasjonsavhengige eller uavhengige.

Eksempel: For å forstå søkeordvisning kan vi ta det samme eksempelet. Det innebærer 2 trinn

Trinn 1: Opprette datatabell (forskjellig fra testdatatabell opprettet i datadrevet rammeverk). Denne datatabellen inneholder handling som skal utføres på GUI-objekter og tilsvarende argumenter hvis noen. Hver rad representerer ett testtrinn.

Objekt	Handling
(Søknadskart)	(SØKEORD)	Argument
WinEdit (agentnavn)	Sett	Guru99
WinEdit (passord)	Sett	Mercury
Win Button (OK)	Klikk
Vindu (flyreservasjon)	Bekreft	Eksisterer

Trinn 2: Skrive kode i form av komponentfunksjoner.

Når du har opprettet datatabellen(e), skriver du ganske enkelt et program eller et sett med skript som leser i hvert trinn, utfører trinnet basert på nøkkelordet som inneholder handlingsfeltet, utfører feilkontroll og logger all relevant informasjon. Dette programmet eller settet med skript vil 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 søkeorddrevet rammeverk.

Fordelen med søkeorddrevet rammeverk er at søkeordene kan gjenbrukes. For å forstå dette bør du vurdere at du ønsker å bekrefte påloggingsoperasjonen for et nettsted, si YAHOO MAIL. Tabellen vil se slik ut -

Objekt	Handling
(SØKNAKKART)	(SØKEORD)	Argument
WebEdit (brukernavn)	Sett	abc@yahoo.com
WebEdit (passord)	Sett	xxxxx
WebButton (OK)	Klikk
Vindu (Yahoo Mail)	Bekreft	Laster

Hvis du observerer i dette tilfellet at nøkkelordsett , klikk , bekreft forblir det samme som tilsvarende komponentfunksjoner allerede er utviklet for. Alt du trenger å gjøre er å endre Application Mapping (Object Repository) fra tidligere flyreservasjon til Yahoo Mail , med en endring i argumentverdier og det samme skriptet vil fungere!

Fordeler

• Gir høy kodegjenbrukbarhet
• Testverktøy uavhengig
• Uavhengig av applikasjon under test, fungerer det samme skriptet for AUT (med noen begrensninger)
• Tester kan designes med eller uten AUT

Ulemper

• Startinvesteringen er ganske høy, og fordelene med dette kan bare realiseres hvis applikasjonen er betydelig stor og testskriptene skal vedlikeholdes i ganske mange år.
• Høy automatiseringsekspertise kreves for å lage nøkkelorddrevet rammeverk.

MERK : Selv om Micro Focus UFT annonserer seg selv som nøkkelorddrevet rammeverk, kan du ikke oppnå fullstendig testverktøy og applikasjonsuavhengighet ved å bruke HP UFT.

5) The Hybrid Test Automation Framework

Som navnet antyder er dette rammeverket kombinasjonen av ett eller flere automatiseringsrammer diskutert ovenfor som trekker fra sine styrker og prøver å dempe svakhetene deres. Det hybride test-QA-automasjonsrammeverket er det de fleste testautomatiseringsrammeverk utvikler seg til over tid og flere prosjekter. Maksimal industri bruker Keyword Framework i en kombinasjon av funksjonsdekomponeringsmetode.

PS: Andre automatiseringsrammer som er verdt å nevne er

Test Modularity Framework

I dette rammeverket er en vanlig oppgave i testskript gruppert sammen som moduler.

Eksempel: Bruk av handlinger i QTP-bruk kan lage et modulært skript

Eksempelskript for pålogging

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

Nå kan du kalle denne handlingen i hovedskriptet som følger –

RunAction ("Login[Argument]", oneIteration)

Business Process Testing (BPT)

Disse automatiseringsrammene deler opp store forretningsprosesser i komponenter som kan gjenbrukes flere ganger i samme eller forskjellige testskript. For eksempel er forretningsprosessen for å bestille en flyreise delt inn i komponenter som pålogging , finne flyreiser , bestilling , betaling og utlogging som kan gjenbrukes i samme forretningsprosess eller forskjellige prosesser. BPT legger også til rette for tettere koordinering mellom SMB-er og automatiseringsingeniører.

Sammendrag

• Et rammeverk er et sett med retningslinjer som kodingsstandarder, håndtering av testdata, behandling av objektlager osv... som når de følges under automatiseringsskripting gir gunstige resultater som økt gjenbruk av kode, høyere portabilitet, reduserte vedlikeholdskostnader for skript osv.
• Lineær skripting er den enkleste av alle automatiseringsrammer og også kjent som "Record & Playback".
• Testbibliotek Architecture Framework er også kjent som "Structured Scripting" eller "Functional Decomposition".
• I Data-Driven Testing Framework ligger testcaselogikk i testskript, og testdataene er separert og holdt utenfor testskriptene.
• Det nøkkelorddrevne eller tabelldrevne rammeverket krever utvikling av datatabeller og nøkkelord, uavhengig av testautomatiseringsverktøyet som brukes til å utføre dem.
• Hybrid Automation Framework er det de fleste testautomatiseringsrammeverk utvikler seg til over tid og flere prosjekter.