Rammeverk for testautomatisering: ArchiTekstur og 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 magemusklenetracså har du en idé om hva presentasjonen vil 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 overholde 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 publikumsforstyrrelsetracsjon under forelesninger, økt deltakerlojalitet og forståelse av faget.

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

Test Automation Framework ArchiTekstur: Nøkkelkomponenter

Før man sammenligner typene, er det nyttig å se hva hvert rammeverk inneholder. ArchiTekstur beskriver hvordan disse delene er lagdelt, slik at en endring i ett lag ikke ødelegger de andre.

• Testskriptlag: Holder testtilfellene. Skriptene forblir korte fordi de kaller gjenbrukbare funksjoner i stedet for å gjenta navigasjonstrinn.
• Funksjonsbibliotek: Lagrer delte handlinger som pålogging, søk og utlogging, slik at en endring i arbeidsflyten gjøres én gang.
• Objektarkiv: Tilordner brukervennlige navn til GUI-elementlokaliseringsverktøy. Når grensesnittet endres, redigeres bare dette laget.
• Testdatalag: Beholder inndata og forventede verdier i Excel, CSV eller databasekilder i stedet for inne i koden.
• Konfigurasjonslag: Inneholder miljø URLs, nettleservalg, tidsavbrudd og påloggingsinformasjon.
• Rapporteringslag: Produserer utførelsesrapporter, skjermbilder av feil og diagnostiske logger.
• Utførelseslag: Utløser pakker fra en byggeserver, og kobler automatisering til kontinuerlig integrering.

Rammeverkstypene nedenfor skiller seg hovedsakelig ut i hvor strengt de skiller disse lagene.

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. Hybrid testautomatiseringsrammeverk.

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 testskript, testdataene skilles og holdes utenfor testskriptene. Testdata leses fra de eksterne filene (Excel-filer, tekstfiler, CSV-filer, ODBC-kilder, DAO-objekter, ADO-objekter) og lastes inn i variablene i testskriptet. Variabler brukes både for inngangsverdier og for verifiseringsverdier. Selve testskriptene utarbeides enten ved hjelp av lineær skripting eller Test Library Framework. Teknikken forklares videre i datadrevet testing opplæringen.

Eksempel: Utviklingping Skriptet for pålogging av flyreservasjon som bruker denne metoden vil innebære to trinn.

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

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

Ocuco Søkeorddrevet eller utvikling av 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.

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.

Trinn 2: Skrive Code 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 -

Hvis du i dette tilfellet observerer at nøkkelordene Angitt, Klikk og Bekreft forblir de samme, og tilsvarende komponentfunksjoner er allerede utviklet for dem. Alt du trenger å gjøre er å endre applikasjonskartet.ping (Objektarkiv) 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 OpenText UFT En (tidligere Micro Focus UFT) annonserer seg selv som et søkeorddrevet rammeverk, kan du ikke oppnå fullstendig uavhengighet av testverktøy og applikasjoner ved å bruke det.

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.

EksempelBruk av handlinger i QTP bruk kan opprette modulære 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.

Hvordan velge riktig rammeverk for testautomatisering

Ingen enkelt type vinner hver gang. Det riktige valget avhenger av lagets ferdigheter, applikasjonsstørrelsen og hvor lenge serien må overleve. Tabellen nedenfor sammenligner de fem typene basert på faktorene som avgjør utfallet.

Gå gjennom disse spørsmålene før du bestemmer deg:

1. Hvor lenge vil suiten leve? Årelang vedlikehold rettferdiggjør den høye initiale investeringen i et søkeorddrevet eller hybrid design. Et kort prosjekt gjør ikke det.
2. Hvem skriver testene? Hvis manuelle testere bidrar med saker, lar en nøkkelordtabell dem jobbe uten å lære skriptspråket.
3. Hvor volatilt er grensesnittet? Hyppig skjermbytte gjør et separat objektlager essensielt, ellers må hvert skript redigeres.
4. Hvor mye datavariasjon er nødvendig? Mange inputkombinasjoner peker direkte mot et datadrevet design.
5. Hvilket verktøy er allerede i bruk? Rammeverket må passe til det valgte automatiseringsverktøy og et språk teamet kan, for eksempel Selenium med Java or Cucumber.

De fleste team starter med en bibliotek- eller datadrevet tilnærming, og vokser deretter mot en hybridmodell etter hvert som regresjon suiten utvides.

Fordeler med Test Automation Framework Architecture

Følgende er fordelene med Test automatiseringsrammearkitektur:

• Et rammeverk for testautomatisering bidrar til å redusere risiko og kostnadsutgifter
• Det forbedrer effektiviteten av tester
• Det bidrar til å redusere vedlikeholdskostnadene
• Tillater gjenbruk av kode
• Det gjør det mulig å oppnå maksimal testdekning
• Det maksimerer applikasjonsfunksjonaliteten
• Bidrar til å redusere duplisering av testtilfeller
• Det bidrar til å forbedre testeffektiviteten og ytelsen med testautomatisering

Spørsmål og svar