Så aktiverar du återanvändning med objektförråd i testautomatisering
Som automationsutvecklare känner vi väl en känsla av tillfredsställelse när vi hör från teamet för manuell testning eller kunden hur de har dragit nytta av den automation vi byggt? Därför förespråkar vi en testautomatiseringssvit av hög kvalitet som inte bara är robust, utan också lätt kan anpassas till uppdateringar som krävs till följd av förändringar i verksamhetens eller teknikens krav. Underhåll ska vara enkelt – det är vad vi hela tiden påminner oss själva om. Vilka sätt finns det att säkerställa detta?
Bland de många sätt som vi kan använda för att säkerställa hög kvalitet i en testautomatiseringssvit är ett sätt att säkerställa återanvändbarhet – inte bara genom att återanvända vanligt förekommande teststeg, utan också genom att återanvända vanligt förekommande användargränssnittsobjekt. I den här artikeln förklarar jag hur vi kan använda objektarkiv för att förbättra återanvändbarheten genom att återanvända objekt i ett projekt för automatiserad testning av användargränssnitt.
- Vad är ett objektarkiv inom testautomation?
- Varför är det viktigt?
- Bästa praxis vid användning av objektarkiv
- Så skapar du objektarkiv (exempel)
Vad är ett objektarkiv inom testautomation?
När du börjar utforma testautomatiseringssviten ser de flesta av oss till att vi inte skriver om kodblock. Därför skapar vi återanvändbara funktioner och gör återanvändbara kodblock tillgängliga i kodbibliotek. Men har du återanvänt vanligt förekommande användargränssnittsobjekt? Om inte, låt mig förklara hur du kan göra det genom att ha ett objektarkiv som grund.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Ett objektarkiv är en samling användargränssnittsobjekt som vanligtvis hör samman. Detta förbättrar inte bara återanvändbarheten, utan säkerställer också tillförlitlighet och hantering av användargränssnittselementen i automationssviten.
När du bygger testautomatiseringsskripten har du kopplat testskriptsteg till vart och ett av dessa användargränssnittsobjekt. Till exempel genom att –
- Skriva i ett textfält som är ett användargränssnittsobjekt
- Hämta texten från ett etikettobjekt
- Klicka på hyperlänksobjektet … och så vidare.
Hur kan du då förbättra återanvändbarheten genom att återanvända de användargränssnittsobjekt som dina skript arbetar med?
Om testautomatiseringsverktyget du använder har ett ”objektarkiv” är det enkelt. Med hjälp av ett objektarkiv kan du samla användargränssnittsobjekten och lägga till, ta bort, hantera eller uppdatera dem från arkivet på ett organiserat sätt. Du kan sedan återanvända objekten genom att referera till dem.
Låt oss analysera en situation där du inte har använt ett OR i din testautomatiseringssvit. I ett sådant fall skulle du, för separata testautomatiseringsskript som använder samma användargränssnittskomponent, lägga till flera kopior av samma användargränssnittsobjekt i vart och ett av testskripten för att utföra aktiviteter på det.
Låt oss nu ta en situation där vi faktiskt använder ett OR. I ett sådant fall skulle du ha en enda plats eller ett enda arkiv där du lagrar användargränssnittsobjekten. Därmed skulle varje testskript som behöver agera på samma användargränssnittsobjekt eller komponent kopplas till samma användargränssnittsobjekt som lagras i OR. Det finns bara en kopia av användargränssnittsobjektet i testsviten, medan flera testskript refererar till eller anropar samma användargränssnittsobjekt. Och det är här återanvändbarheten kommer in i bilden!
Varför är det viktigt?
Första gången jag använde ett OR var i verktyget IBM Rational Functional Test Automation. Sedan dess har jag, varje gång jag lär mig ett nytt verktyg, velat kontrollera om verktyget har OR-funktionen eller inte.
Första gången jag använde ett OR var när vårt team automatiserade en omfattande administrativ webbkonsol med flera sidor. Vi hade över 100 testfall att automatisera. Om vi inte hade använt OR skulle det ha varit en enorm utmaning att automatisera. Vi analyserade situationen och kom fram till att den testautomatiseringssvit vi ville bygga var ett idealiskt fall för att använda ett OR.
Anledningarna?
1. Vart och ett av testfallen som vi automatiserade hade flera gemensamma delflöden och hade därför gemensamma användargränssnittskomponenter.
Eftersom det fanns gemensamma delflöden fanns det uppenbara gemensamma användargränssnittsobjekt i scenarierna. Vi ville inte lägga till kopior av samma användargränssnittsobjekt om och om igen, så vi beslutade att återanvända objekten.
Exempelvis behövde en uppsättning testfall navigera genom samma länkar i navigeringsmenyn innan en uppsättning steg utfördes. Därför planerade vi att skapa ett arkiv som endast skulle lagra och hantera alla navigeringslänkar. Sedan kunde vi återanvända navigeringsmenylänkarna i en OR-fil.
2. Vi fick information om att det i framtiden kunde uppstå situationer med uppdateringar av användargränssnittet – exempelvis hyperlänkar, etiketter och så vidare.
Därför ville vi säkerställa att testautomatiseringssviten enkelt kunde anpassas till förändringar när en sådan uppdatering av användargränssnittet inträffade, och att eventuellt underhållsarbete skulle gå snabbt och enkelt.
Det var här OR kom till vår räddning: vi behövde inte göra ändringar i objektarkiven för användargränssnittet i varje kopia av samma användargränssnittsobjekt. När en ändring inträffade behövde vi bara uppdatera det enda tillhörande objektet i OR, så kördes testskripten enligt det uppdaterade användargränssnittsobjektet.
3. Vi var tvungna att bygga en testautomatiseringssvit med över 100 skript inom en månad!
Här kom ytterligare en fördel med att använda ett OR in i bilden: genom att välja metoden att bygga ett OR och genom att ingen av oss behövde lägga till samma UI-objekt igen sparade vi tid. Vi byggde ett välorganiserat OR, och allt vi behövde göra var att bygga vår kod kring de objekt som vi hade organiserat i OR:et.
Vi fokuserade på testfallets mål och testfallens affärslogik i stället för att slösa tid på att uppfinna hjulet på nytt genom att lägga till objekt för varje testskript. Vi sparade tid och levererade till slut testautomatiseringssviten inom den planerade tiden på en månad!
Bästa praxis att följa vid användning av objektarkiv
Nu när du känner till situationer där ett UI-objektarkiv kan vara till hjälp, vill du inte veta vad som får det att fungera?
1. Bygg som team upp ett gemensamt mål kring återanvändning. Förstå tillsammans varför det kan hjälpa ditt automatiseringsteam, teamet för manuell testning och till slut även kunden.
2. Se under utvecklingen av testautomatiseringssviten till att ni som team alltid är samspelta och informerade om de objekt ni bygger. Ha en uppsättning grupperingsregler och namnkonventioner som ni alla följer. När ni börjar kan ni ta fram en plan för hur ni ska organisera och lagra varje OR-fil. Till exempel navigeringsmenyobjekt i en OR-fil och UI-objekt för en inloggningssida i en annan OR-fil. Ni kan också bestämma namnkonventioner för objekten så att de blir enkla att hitta.
3. Se till att namnge UI-objekten på ett sådant sätt att de är läsbara och enkla att hitta och förstå. Namnge UI-objekten på ett sådant sätt att någon annan som går igenom UI-arkivet i syfte att uppdatera det enkelt ska kunna hitta UI-objektet. I exemplet nedan visar jag en sådan situation.
Så skapar du objektarkiv (exempel)
Låt oss nu se praktiskt på hur du snabbt kan komma igång med objektarkiv. Verktyg som UFT, IBM RFT, UiPath Test Automation Suite och Power Automate har objektarkiv inbyggda. Så varför vänta? Tro mig, det är väldigt enkelt!
Här är ett exempel där jag har skapat ett OR för QAL-webbplatsen:
Observera ovanstående UI – jag grupperade alla widgetar som hör samman med åtgärder på inloggningssidans UI-widgetar, eftersom de skulle vara gemensamma för flera testfall. Därefter grupperade jag navigeringslänkarna tillsammans. Om vi registrerar dessa objekt i en grupp kommer alla testskript definitivt att använda denna grupp av UI-länkobjekt i början av varje testfall, och då kan objekten återanvändas i stället för att läggas till i arkivet igen
Exempel på användning av objektarkivet i UiPath
Så här ser objektarkivet ut i UiPath-verktyget:
I det här exemplet på objektarkivet har jag organiserat objekten för ”Inloggningssida” i en uppsättning och ”Huvudnavigeringslänkar” i en annan uppsättning. Om jag skulle bygga flera testskript för att – låt oss säga – testa inloggningssidan skulle alla testskript ”anropa” samma objekt som jag hade placerat i ”Inloggningssida”.
Exempel på användning av objektarkivet i PowerAutomate
Så här ser objektarkivet ut i PowerAutomate-verktyget:
Som jag nämnde tidigare handlar nyckeln till återanvändning också om att se till att du namnger objekten så att du enkelt kan hitta dem senare. Observera UI-objektet ”meprmath_quiz”. Till skillnad från de andra fälten kan vi inte enkelt identifiera vilket UI-objekt det hänvisar till. I ett fall som ovan visade fältnamnet ”meprmath_quiz” visserligen när jag lade till UI-objektet för textrutan ”quiz”, men vi skulle kanske kunna kalla det ”login_add” eller något liknande för att göra objektet lätt att hitta när vi automatiserar och underhåller OR:et.
Sammanfattning
Så hur använder du OR i ditt favoritverktyg för testautomatisering? Vi vill gärna veta.
Jag hoppas att den här artikeln hjälper dig att förstå hur OR hjälper teamet på lång sikt. Vi har tur som lever i en tid där de flesta verktyg för testautomatisering har OR-funktionen tillgänglig. Därför behöver du bara utforska hur den fungerar i ditt favoritverktyg!
Lärde du dig något nytt i den här artikeln? Om du gärna vill läsa fler artiklar som denna får du inte glömma att prenumerera på nyhetsbrevet från The QA Lead!
Relaterad läsning:
Relaterad lista över verktyg: PRESTANATESTNINGSPROGRAMVARA FÖR QA-TEAM
Också värt att kolla in:
