Som automatiseringsudviklere føler vi så ikke en tilfredshed, når vi hører fra teamet for manuel test eller kunden om, hvordan de har haft gavn af at bruge den automatisering, vi har bygget? Derfor går vi efter en automatiseringspakke af høj kvalitet, som ikke kun er robust, men også nemt kan tilpasses de opdateringer, der kræves i henhold til ændringer i forretningsmæssige eller tekniske krav. Vedligeholdelse skal være nemt – det er, hvad vi hele tiden minder os selv om. Hvilke måder findes der til at sikre dette?
Blandt de mange måder, hvorpå vi kan sikre høj kvalitet i en testautomatiseringspakke, er én måde at sikre genanvendelighed på – ikke kun ved at genbruge almindeligt anvendte testtrin, men også ved at genbruge almindeligt anvendte UI-objekter. I denne artikel vil jeg forklare, hvordan vi kan bruge objektlagre til at forbedre genanvendeligheden ved at genbruge objekter i et UI-testautomatiseringsprojekt.
- Hvad er et objektlager i testautomatisering?
- Hvorfor er det vigtigt?
- Bedste praksisser ved brug af objektlagre
- Sådan opretter du objektlagre (eksempler)
Hvad er et objektlager i testautomatisering?
Når du først begynder at designe testautomatiseringspakken, sørger de fleste af os for, at vi ikke skriver kodeblokke igen. Derfor opbygger vi genanvendelige funktioner og gør de genanvendelige kodeblokke tilgængelige i kodebiblioteker. Men har du genbrugt almindeligt anvendte UI-objekter? Hvis ikke, så lad mig forklare, hvordan du kan gøre det ved at have et objektlager som grundlag.
Et objektlager er en samling af UI-objekter, der almindeligvis er knyttet til hinanden. Det forbedrer ikke kun genanvendeligheden, men sikrer også pålidelighed og håndtering af UI-elementerne i automatiseringspakken.
Mens du opbygger testautomatiseringsscripts, ville du have knyttet testscripttrin til hvert af disse UI-objekter. Eksempelvis ved at –
- Skrive i et tekstfelt-UI-objekt
- Hente teksten fra et etiket-UI-objekt
- Klikke på hyperlinkobjektet .. og så videre.
Hvordan kan du så forbedre genanvendeligheden ved at genbruge de UI-objekter, som dine scripts arbejder med?
Hvis det testautomatiseringsværktøj, du bruger, har et “objektlager”, er det nemt. Ved hjælp af et objektlager kan du samle UI-objekterne og tilføje, slette, administrere eller opdatere UI-objekterne fra dette lager på en organiseret måde. Du kan til sidst genbruge objekterne ved at referere til dem.
Lad os analysere en situation, hvor du ikke har brugt et OR i din testautomatiseringspakke. I et sådant tilfælde ville du for separate testautomatiseringsscripts, der bruger den samme UI-widget, tilføje flere kopier af det samme UI-objekt til hvert af testscriptne for at udføre aktiviteter på det.
Lad os nu se på en situation, hvor vi bruger et OR. I et sådant tilfælde ville du have én placering/ét lager, hvor du gemmer UI-objekterne. Dermed ville hvert testscript, der skal arbejde med det samme UI-objekt eller den samme UI-widget, være knyttet til det samme UI-objekt, der er gemt i OR'et. Der er kun én kopi af UI-objektet i testpakken, mens flere testscript refererer til eller kalder det samme UI-objekt. Og det er her, genanvendeligheden kommer i spil!
Have an account? Log In
Hvorfor er det vigtigt?
Min første erfaring med at bruge et OR var, da jeg brugte det i værktøjet IBM Rational Functional Test Automation. Siden da har jeg, hver gang jeg lærer et nyt værktøj, set frem til at kontrollere, om værktøjet har OR-funktionen eller ej.
Første gang jeg brugte et OR, var da vores team automatiserede en omfattende administrativ web-UI-konsol med flere sider. Vi havde mere end 100 testcases, der skulle automatiseres. Hvis vi ikke havde brugt OR'et, ville det have været en enorm udfordring at automatisere. Vi analyserede situationen og konkluderede, at den testautomatiseringspakke, vi ønskede at opbygge, var det ideelle tilfælde til at bruge et OR.
Årsagerne?
1. Hver af de testcases, vi automatiserede, havde flere underforløb til fælles og havde derfor tilknyttede UI-komponenter til fælles.
Da der var fælles underforløb, var der naturligvis også fælles UI-objekter i scenarierne. Vi ønskede ikke at tilføje kopier af de samme UI-objekter igen og igen, så vi besluttede at genbruge UI-objekterne.
For eksempel skulle et sæt testcases navigere gennem de samme links i navigationsmenuen, før de udførte en række trin. Derfor planlagde vi at have et lager, der kun skulle gemme og administrere alle navigationslinks. Derefter kunne vi genbruge navigationsmenuens links i en OR-fil.
2. Vi blev informeret om, at der i fremtiden kunne opstå situationer med UI-opdateringer – for eksempel hyperlinks, etiketter osv.
Derfor ville vi sikre, at testautomatiseringspakken nemt kunne tilpasses, når en sådan UI-opdatering fandt sted, og at enhver vedligeholdelsesindsats skulle være hurtig og nem.
Det var her, OR'et kom os til undsætning: Vi behøvede ikke at foretage ændringer i UI-objektlagrene i hver kopi af det samme UI-objekt. Når der var en ændring, skulle vi blot opdatere det ene tilknyttede objekt i OR'et, hvorefter testscriptne ville køre i henhold til det opdaterede UI-objekt.
3. Vi var nødt til at opbygge en testautomatiseringspakke med over 100 scripts inden for en måned!
Her kom endnu en fordel ved at bruge et OR i spil: Ved at vælge tilgangen med at opbygge et OR, så ingen af os behøvede at tilføje de samme UI-objekter igen, sparede vi tid. Vi opbyggede et velorganiseret OR, og det eneste, vi skulle gøre, var at skrive vores kode omkring de objekter, som vi havde organiseret i OR'et.
Vi fokuserede på testcasens mål og testcasenes forretningslogik i stedet for at spilde tid på at opfinde den dybe tallerken igen ved at tilføje objekter til hvert enkelt testscript. Vi sparede tid og leverede til sidst testautomatiseringspakken inden for den planlagte tidsramme på en måned!
Bedste praksisser ved brug af objektlagre
Nu hvor du kender de situationer, hvor et UI-objektlager kan være nyttigt, vil du så ikke gerne vide, hvad der får det til at fungere?
1. Opbyg som team et fælles mål om genbrug. Forstå i fællesskab, hvorfor det i sidste ende kan hjælpe dit automatiseringsteam, det manuelle testteam og klienten.
2. Mens I udvikler testautomatiseringspakken, skal I som team altid være afstemt og informeret om de objekter, I opbygger. Hav et sæt grupperingsregler og navngivningskonventioner, som I alle følger. Når I går i gang, kan I udarbejde en plan for, hvordan I vil organisere og gemme hver af OR-filerne. Eksempelvis navigationsmenuobjekter i én OR-fil, UI-objekter til en login-side i en anden OR-fil osv. I kan også beslutte navngivningskonventioner for objekterne, så de er nemme at finde.
3. Sørg for at navngive UI-objekterne på en måde, så navnene er læsbare og nemme at finde og relatere til. Navngiv UI-objekterne på en sådan måde, at alle andre, der gennemgår UI-lageret med henblik på at opdatere det, nemt kan finde UI-objektet. I eksemplet nedenfor viser jeg en sådan situation.
Sådan opretter du objektlagre (eksempler)
Lad os nu se nærmere på, hvordan du hurtigt kan komme i gang med objektlagre. Værktøjer som UFT, IBM RFT, UiPath Test Automation Suite og Power Automate har objektlagre indbygget. Så hvorfor vente? Tro mig, det er supernemt!
Her er et eksempel, hvor jeg har oprettet et OR med udgangspunkt i QAL-webstedet:
Læg mærke til brugerfladen ovenfor – jeg grupperede alle de widgets, der er forbundet med handlinger på loginbrugerfladens widgets, sammen, da de ville være fælles på tværs af flere testcases. Derefter grupperede jeg navigationslinkene sammen. Hvis vi registrerer disse objekter i en gruppe, vil alle testscripts helt sikkert bruge denne gruppe af UI-linkobjekter i begyndelsen af hver testcase, og disse objekter kan derfor genbruges i stedet for at blive tilføjet til lageret igen
Eksempel på brug af objektlageret i UiPath
Sådan ser objektlageret ud i UiPath-værktøjet:
I dette eksempel på objektlageret har jeg organiseret objekterne på “Login-siden” i ét sæt og “Hovednavigationslinkene” i et andet sæt. Hvis jeg med dette skulle opbygge flere testscripts for eksempelvis at teste login-siden, ville alle testscripts “kalde” de samme objekter, som jeg havde placeret på “Login-siden”.
More Articles
Eksempel på brug af objektlageret i PowerAutomate
Sådan ser objektlageret ud i PowerAutomate-værktøjet:
Som jeg nævnte tidligere, er nøglen til genanvendelighed også at sikre, at du navngiver objekterne, så du nemt kan finde dem senere. Læg mærke til UI-objektet “meprmath_quiz”. I modsætning til de andre felter kan vi ikke umiddelbart identificere, hvilket UI-objekt det henviser til. I et tilfælde som ovenstående kunne vi derfor, selv om feltet blev vist som “meprmath_quiz”, da jeg tilføjede UI-objektet til tekstfeltet “quiz”, måske kalde det “login_add” eller noget lignende for at gøre objektet nemt at finde under automatisering og vedligeholdelse af OR'et.
Afslutning
Så hvordan bruger du OR'et i dit foretrukne testautomatiseringsværktøj? Det vil vi meget gerne vide.
Jeg håber, at denne artikel hjælper dig med at forstå, hvordan OR hjælper teamet på lang sigt. Vi er heldige, at vi befinder os i en tid, hvor de fleste testautomatiseringsværktøjer har OR-funktionen tilgængelig. Derfor skal du blot undersøge, hvordan den fungerer i dit foretrukne værktøj!
Lærte du noget nyt i denne artikel? Hvis du gerne vil have flere artikler som denne, så glem ikke at abonnere på The QA Lead-nyhedsbrevet!
Relateret læsning:
Relateret liste over værktøjer: SOFTWARE TIL YDEEVNESTEST TIL QA-TEAM
Også værd at tjekke:
