Ramverk för testautomation: ArchiStruktur och typer

Vad är ramverk i automationstestning?

A Testa Automation Framework är en uppsättning riktlinjer som kodningsstandarder, hantering av testdata, behandling av objektlager etc... som när de följs under automatisering av skript ger fördelaktiga resultat som ökad kodåteranvändning, högre portabilitet, minskad skriptunderhållskostnad etc. Dessa är bara riktlinjer och inte regler; de är inte obligatoriska och du kan fortfarande skripta utan att följa riktlinjerna. Men du kommer att gå miste om fördelarna med att ha ett ramverk.

Varför behöver du ett ramverk?

Låt oss överväga ett exempel för att förstå varför du behöver ett ramverk.

Jag är säker på att du har deltagit i ett seminarium/föreläsning/konferens där deltagarna ombads följa följande riktlinjer –

• Deltagarna bör sitta på sina platser 5 minuter innan föreläsningen börjar.
• Ta med en anteckningsbok och penna för anteckningar.
• Läs magmusklernatracså att du har en uppfattning om vad presentationen kommer att handla om.
• Mobiltelefoner ska vara inställda på tyst.
• Använd utgångsgrindarna i den motsatta änden av talaren om du skulle behöva lämna mitt under föreläsningen.
• Frågor kommer att ställas i slutet av sessionen.

Tror du att du kan genomföra ett seminarium UTAN följa dessa riktlinjer?

Svaret är stort JA! Visst, du kan genomföra ett seminarium/föreläsning/konferens/demonstration utan ovanstående riktlinjer.. faktiskt, vissa av oss kommer inte att följa dem även om det finns upplagt!

Men om riktlinjerna följs kommer det att resultera i ett positivt resultat, som minskad publikbristtraction under föreläsningar, ökad deltagarlojalitet och förståelse för ämnet.

Baserat på ovanstående, a Ramverk kan definieras som en uppsättning riktlinjer som, när de följs, ger fördelaktiga resultat.

Testa Automation Framework ArchiStruktur: Viktiga komponenter

Innan man jämför typerna är det bra att se vad varje ramverk innehåller. ArchiTektur beskriver hur dessa delar är skiktade så att en förändring i ett lager inte bryter bryter de andra.

• Testskriptlager: Håller testfallen. Skript förblir korta eftersom de anropar återanvändbara funktioner istället för att upprepa navigeringssteg.
• Funktionsbibliotek: Lagrar delade åtgärder som inloggning, sökning och utloggning, så att en arbetsflödesändring görs en gång.
• Objektförråd: Mappar vänliga namn till GUI-elementlokaliserare. När gränssnittet ändras redigeras endast detta lager.
• Testdatalager: Behåller indata och förväntade värden i Excel, CSV eller databaskällor istället för inuti koden.
• Konfigurationslager: Innehåller miljö URLs, webbläsarval, timeouts och inloggningsuppgifter.
• Rapporteringslager: Skapar körningsrapporter, skärmdumpar av fel och diagnostikloggar.
• Exekveringslager: Utlöser sviter från en byggserver, länkar automatisering till kontinuerlig integration.

Ramverkstyperna nedan skiljer sig huvudsakligen åt i hur strikt de separerar dessa lager.

Typer av ramverk för testautomatisering

Nedan finns de olika typerna av ramverk för automatisk testning:

1. Linjär skriptning
2. Testbiblioteket Architecture Framework.
3. Den datadrivna Testning Ramverk.
4. Det nyckelordsdrivna eller tabelldrivna testramverket.
5. Hybrid testautomatiseringsramverket.

Låt oss titta på dem i detalj -

1) Linjärt skript – Spela in och spela upp

Det är det enklaste av alla Testing Automation Frameworks och även känt som "Spela in och spela upp". I detta Automationstestning Framework, Tester registrerar manuellt varje steg (navigering och användarinmatningar), infogar kontrollpunkter (valideringssteg) i den första omgången. Han spelar sedan upp det inspelade manuset i de efterföljande omgångarna.

Exempel: Överväg att logga in Ansökan om flygbokning och kontrollera om applikationen har laddats vid lyckad inloggning. Här kommer testaren helt enkelt att registrera stegen och lägga till valideringssteg.

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

Fördelar

• Snabbaste sättet att skapa ett skript
• Automationsexpertis krävs inte
• Det enklaste sättet att lära sig funktionerna i testverktyget

Nackdelar

• Lite återanvändning av skript
• Testdata hårdkodas in i skriptet
• Underhåll mardröm

2) Testbiblioteket Architecture Framework

Det är också känt som "Structured Scripting" or "Funktionell nedbrytning".

I detta ramverk för automatiseringstestning registreras testskript initialt av "Spela in och spela upp”Metod. Later, identifieras vanliga uppgifter i skripten och grupperas i funktioner. Dessa funktioner anropas av huvudtestskriptet Chaufför på olika sätt för att skapa testfall.

Exempel: Med samma exempel som ovan kommer funktionen för att logga in 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

Nu kommer du att anropa denna funktion i huvudskriptet enligt följande

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

Fördelar

• Högre nivå av återanvändning av kod uppnås i Structured Scripting jämfört med "Record & Playback"
• Automatiseringsskripten är mindre kostsamma att utveckla på grund av högre återanvändning av kod
• Enklare skriptunderhåll

Nackdelar

• Teknisk expertis är nödvändig för att skriva skript med Test Library Framework
• Mer tid behövs för att planera och förbereda testskript.
• Testdata är hårdkodade i skripten

3) Det datadrivna testramverket

I detta ramverk, medan Testfall Logiken finns i testskript, testdata separeras och hålls utanför testskripten. Testdata läses från externa filer (Excel-filer, textfiler, CSV-filer, ODBC-källor, DAO-objekt, ADO-objekt) och laddas in i variablerna i testskriptet. Variabler används både för indatavärden och för verifieringsvärden. Testskripten själva förbereds antingen med hjälp av linjära skript eller Test Library Framework. Tekniken förklaras vidare i datadrivna tester handledning.

Exempel: Utvecklaping Skriptet för inloggning för flygbokning med den här metoden kommer att involvera två steg.

Steg 1) Skapa ett test – Datafil som kan vara Excel, CSV eller någon annan databaskälla.

Steg 2) Utveckla testskript och gör referenser till din testdatakälla.

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.

Fördelar

• Ändringar av testskripten påverkar inte testdata
• Testfall kan utföras med flera uppsättningar data
• En mängd testscenarier kan utföras genom att bara variera testdata i den externa datafilen

Nackdelar

• Mer tid behövs för att planera och förbereda både testskript och testdata

4) Det nyckelordsdrivna eller tabelldrivna testramverket

Ocuco-landskapet Nyckelordsdriven eller utveckling av tabelldriven automatiseringsramverk kräver datatabeller och nyckelord, oberoende av testautomatiseringsverktyg används för att avrätta dem. Tester kan utformas med eller utan applikationen. I ett nyckelordsdrivet test dokumenteras funktionaliteten av applikationen-under-test i en tabell samt i steg-för-steg-instruktioner för varje test.

Det finns tre grundläggande komponenter i ett nyckelordsdrivet ramverk, dvs. Nyckelord , Applikationskarta , Komponentfunktion.

Nyckelord är en åtgärd som kan utföras på en GUI-komponent. Ex. För GUI Component Textbox skulle vissa nyckelord ( Action) vara InputText, VerifyValue, VerifyProperty och så vidare.

Vad är applikationskartan?

En applikationskarta ger namngivna referenser för GUI-komponenter. Applikationskartor är inget annat än "Objektförråd"

Vad är komponentfunktion?

Komponentfunktioner är de funktioner som aktivt manipulerar eller förhör GUI-komponenten. Ett exempel på en funktion skulle vara klicka på webbknappen med all felhantering , ange data i en webbredigering med all felhantering. Komponentfunktioner kan vara applikationsberoende eller oberoende.

Exempelvis: För att förstå nyckelordsvyn tar vi samma exempel. Det innebär 2 steg

steg 1: Skapar datatabell (Skillnad från testdatatabell skapad i datadrivet ramverk). Denna datatabell innehåller åtgärder som ska utföras på GUI-objekt och motsvarande argument om några. Varje rad representerar ett teststeg.

steg 2: Skrift Code i form av komponentfunktioner.

När du har skapat dina datatabeller, skriver du helt enkelt ett program eller en uppsättning skript som läser i varje steg, kör steget baserat på nyckelordet i fältet Åtgärd, utför felkontroll och loggar all relevant information. Detta program eller uppsättning skript skulle se ut som pseudokoden nedan:

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 är allt till nyckelordsdrivet ramverk.

Fördelen med Keyword Driven Framework är att sökorden är återanvändbara. För att förstå detta, tänk på att du vill verifiera inloggningsfunktionen för en webbplats, säg YAHOO MAIL. Tabellen kommer att se ut så här -

Om du i det här fallet observerar att nyckelorden Set, Click och Verify förblir desamma, för vilka motsvarande komponentfunktioner redan är utvecklade. Allt du behöver göra är att ändra applikationskartan.ping (Objektarkiv) från tidigare flygbokning till Yahoo Mail , med en förändring i argumentvärden och samma skript kommer att fungera!

Fördelar

• Ger hög kodåteranvändbarhet
• Testverktyg oberoende
• Oberoende av Application Under Test, fungerar samma skript för AUT (med vissa begränsningar)
• Tester kan utformas med eller utan AUT

Nackdelar

• Eftersom den initiala investeringen är ganska hög, kan fördelarna med detta bara realiseras om applikationen är avsevärt stor och testskripten ska underhållas under ganska många år.
• Hög automationsexpertis krävs för att skapa det nyckelordsdrivna ramverket.

NOTERA : Även om OpenText UFT En (tidigare Micro Focus UFT) marknadsför sig som ett sökordsdrivet ramverk, kan du inte uppnå fullständigt oberoende av testverktyg och applikationer med hjälp av det.

5) Hybrid Test Automation Framework

Som namnet antyder är detta ramverk kombinationen av ett eller flera Automation Frameworks som diskuterats ovan som drar ur sina styrkor och försöker mildra sina svagheter. Hybridtest-QA-automationsramverket är vad de flesta testautomationsramverk utvecklas till över tid och flera projekt. Maximum industri använder Keyword Framework i en kombination av funktionsnedbrytningsmetod.

PS: Andra Automation Frameworks värda att nämna är

Testa Modularity Framework

I detta ramverk grupperas en vanlig uppgift i testskript som moduler.

ExempelvisAnvända åtgärder i QTP användning kan skapa modulära skript

Exempelskript för inloggning

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 kalla denna Action i huvudskriptet enligt följande –

RunAction ("Login[Argument]", oneIteration)

Business Process Testing (BPT)

Dessa Automation Frameworks delar upp stora affärsprocesser i komponenter som kan återanvändas flera gånger i samma eller olika testskript. Till exempel är affärsprocessen för att boka en flygresa uppdelad i komponenter som inloggning , Hitta flyg , bokning , betalning och utloggning som kan återanvändas i samma affärsprocess eller olika processer. Dessutom underlättar BPT närmare samordning mellan små och medelstora företag och automationsingenjörer.

Hur man väljer rätt ramverk för testautomation

Ingen enskild typ vinner varje gång. Rätt val beror på lagets skicklighet, applikationens storlek och hur länge sviten måste överleva. Tabellen nedan jämför de fem typerna baserat på de faktorer som avgör resultatet.

Gå igenom dessa frågor innan du bestämmer dig:

1. Hur länge kommer sviten att leva? Åratal av underhåll rättfärdigar den höga initiala investeringen i en sökordsdriven eller hybriddesign. Ett kort projekt gör det inte.
2. Vem skriver proven? Om manuella testare bidrar med fall kan de arbeta med hjälp av en nyckelordstabell utan att behöva lära sig skriptspråket.
3. Hur volatilt är gränssnittet? Frekventa skärmbyten gör ett separat objektarkiv nödvändigt, annars behöver varje skript redigeras.
4. Hur mycket datavariation behövs? Många inmatningskombinationer pekar direkt mot en datadriven design.
5. Vilket verktyg används redan? Ramverket måste passa det valda automatiseringsverktyg och ett språk som teamet kan, till exempel Selenium med Java or Cucumber.

De flesta team börjar med en biblioteks- eller datadriven metod och växer sedan mot en hybridmodell allt eftersom regression sviten expanderar.

Fördelar med Test Automation Framework Architecture

Följande är fördelarna med Test automation framework-arkitektur:

• Ett ramverk för testautomatisering hjälper till att minska riskerna och kostnadskostnaderna
• Det förbättrar effektiviteten i testerna
• Det hjälper till att minska underhållskostnaderna
• Tillåter återanvändning av kod
• Det gör det möjligt att uppnå maximal testtäckning
• Det maximerar applikationens funktionalitet
• Hjälper till att minska testfallsdubblering
• Det hjälper till att förbättra testeffektiviteten och prestandan med testautomatisering

Vanliga frågor