Som utviklere innen automatisering føler vi vel en viss tilfredsstillelse når vi hører fra det manuelle testteamet eller kunden om hvordan de har hatt nytte av automatiseringen vi har bygget? Derfor går vi inn for en testautomatiseringspakke av høy kvalitet som ikke bare er robust, men også enkelt kan tilpasses oppdateringer som kreves i henhold til endringer i forretningsmessige eller tekniske krav. Vedlikeholdet bør være enkelt – det er noe vi stadig minner oss selv på. Hva er måtene å sikre dette på?
Blant de mange måtene vi kan sikre høy kvalitet på i en testautomatiseringspakke, er én måte å sørge for gjenbruk – ikke bare ved å gjenbruke ofte brukte testtrinn, men også ved å gjenbruke ofte brukte UI-objekter. I denne artikkelen forklarer jeg hvordan vi kan bruke objektlagre til å forbedre gjenbrukbarheten ved å gjenbruke objekter i et prosjekt for UI-testautomatisering.
- Hva er et objektlager i testautomatisering?
- Hvorfor er det viktig?
- Beste praksis ved bruk av objektlagre
- Slik oppretter du objektlagre (eksempler)
Hva er et objektlager i testautomatisering?
Når du først begynner å utforme testautomatiseringspakken, sørger de fleste av oss for at vi ikke skriver om kodeblokker. Derfor bygger vi gjenbrukbare funksjoner og gjør de gjenbrukbare kodeblokkene tilgjengelige i kodebiblioteker. Men har du gjenbrukt ofte brukte UI-objekter? Hvis ikke, skal jeg forklare hvordan du kan gjøre dette ved å ha et objektlager som grunnlag.
Et objektlager er en samling UI-objekter som ofte hører sammen. Dette forbedrer ikke bare gjenbrukbarheten, men sikrer også pålitelighet og administrasjon av UI-elementene i testautomatiseringspakken.
Når du bygger testautomatiseringsskriptene, har du knyttet testskripttrinn til hvert av disse UI-objektene. For eksempel –
- Skrive inn tekst i et tekstboks-UI-objekt
- Hente teksten fra et etikett-UI-objekt
- Klikke på hyperkoblingsobjektet … og så videre.
Hvordan kan du så forbedre gjenbrukbarheten ved å gjenbruke UI-objektene som skriptene dine arbeider med?
Hvis testautomatiseringsverktøyet du bruker, har et «objektlager», er det enkelt. Ved hjelp av et objektlager kan du samle UI-objektene og legge til, slette, administrere eller oppdatere UI-objektene fra dette lageret på en organisert måte. Du kan til slutt gjenbruke objektene ved å referere til dem.
La oss analysere en situasjon der du ikke har brukt et OR i testautomatiseringspakken. I et slikt tilfelle ville du, for separate testautomatiseringsskript som bruker den samme UI-komponenten, lagt til flere kopier av det samme UI-objektet i hvert av testskriptene for å utføre aktiviteter på det.
La oss nå se på en situasjon der vi bruker et OR. I et slikt tilfelle ville du hatt ett enkelt sted/objektlager der du lagrer UI-objektene. Dermed ville hvert testskript som trenger å utføre handlinger på det samme UI-objektet eller den samme UI-komponenten, være knyttet til det samme UI-objektet som er lagret i OR-et. Det finnes bare én kopi av UI-objektet i testpakken, mens flere testskript refererer til eller kaller det samme UI-objektet. Og det er her gjenbrukbarheten kommer inn!
Have an account? Log In
Hvorfor er det viktig?
Første gang jeg brukte et OR, var da jeg brukte det i verktøyet IBM Rational Functional Test Automation. Siden den gang har jeg, hver gang jeg lærer meg et nytt verktøy, sett frem til å sjekke om verktøyet har OR-funksjonen eller ikke.
Første gang jeg brukte et OR, automatiserte teamet vårt en omfattende administrativ nettbasert UI-konsoll med flere sider. Vi hadde over 100 testtilfeller som skulle automatiseres. Hvis vi ikke hadde brukt OR-et, ville det ha vært en enorm utfordring å automatisere. Vi analyserte situasjonen og konkluderte med at testautomatiseringspakken vi ønsket å bygge, var et ideelt tilfelle for bruk av et OR.
Grunnene?
1. Hvert av testtilfellene vi automatiserte, hadde flere underflyter til felles og hadde derfor tilknyttede UI-komponenter til felles.
Siden det fantes felles underflyter, fantes det også åpenbare felles UI-objekter i scenariene. Vi ønsket ikke å legge til kopier av de samme UI-objektene om og om igjen, så vi bestemte oss for å gjenbruke UI-objektene.
For eksempel måtte et sett med testtilfeller navigere gjennom de samme koblingene i navigasjonsmenyen før et sett med trinn ble utført. Derfor planla vi å ha et lager som bare skulle lagre og administrere alle navigasjonskoblingene. Deretter kunne vi gjenbruke navigasjonskoblingene i en OR-fil.
2. Vi ble informert om at det i fremtiden kunne oppstå situasjoner med UI-oppdateringer – når det gjaldt hyperkoblinger, etiketter og så videre.
Derfor ønsket vi å sikre at testautomatiseringspakken enkelt kunne tilpasses når en slik UI-oppdatering fant sted, og at alt vedlikeholdsarbeid skulle gå raskt og enkelt.
Det var her OR-et kom oss til unnsetning: Vi trengte ikke å gjøre endringer i UI-objektlagrene i hver kopi av det samme UI-objektet. Når det oppstod en endring, måtte vi bare oppdatere det ene tilknyttede objektet i OR-et, så ville testskriptene kjøre i henhold til det oppdaterte UI-objektet.
3. Vi måtte bygge en testautomatiseringspakke med over 100 skript i løpet av én måned!
Her kom en annen fordel ved å bruke et OR inn: Ved å velge en tilnærming der vi bygget et OR, og ved at ingen av oss måtte legge til de samme brukergrensesnittelementene på nytt, sparte vi tid. Vi bygget et godt organisert OR, og alt vi måtte gjøre, var å bygge koden vår rundt objektene vi hadde organisert i OR-et.
Vi fokuserte på testtilfellets mål og forretningslogikken i testtilfellene i stedet for å kaste bort tid på å finne opp hjulet på nytt ved å legge til objekter for hvert testskript. Vi sparte tid og leverte til slutt testautomatiseringspakken innen den planlagte tiden på én måned!
Beste praksiser ved bruk av objektlagre
Nå som du vet i hvilke situasjoner et objektlager for brukergrensesnittet kan være nyttig, vil du vel ikke vite hva som får det til å fungere?
1. Bygg som et team et felles mål om gjenbruk. Forstå sammen hvorfor dette kan hjelpe testautomatiseringsteamet, teamet for manuell testing og til slutt kunden.
2. Mens dere utvikler testautomatiseringspakken, må dere som team alltid være samkjørte og informert om objektene dere bygger. Ha et sett med grupperingsregler og navnekonvensjoner som dere alle følger. Når dere begynner, kan dere lage en plan for hvordan dere vil organisere og lagre hver av OR-filene. For eksempel navigasjonsmenyobjekter i én OR-fil, brukergrensesnittobjekter for en innloggingsside i en annen OR-fil osv. Dere kan også bestemme navnekonvensjoner for objektene, slik at de blir enkle å finne.
3. Sørg for å navngi brukergrensesnittobjektene på en måte som gjør dem lesbare og enkle å finne og forstå. Navngi brukergrensesnittobjektene slik at alle andre som går gjennom brukergrensesnittlageret med hensikt å oppdatere det, enkelt skal kunne finne brukergrensesnittobjektet. I eksempelet nedenfor viser jeg en slik situasjon.
Slik oppretter du objektlagre (eksempler)
La oss nå se nærmere på hvordan du raskt kan komme i gang med objektlagre. Verktøy som UFT, IBM RFT, UiPath Test Automation Suite og Power Automate har objektlagre. Så hvorfor vente? Tro meg, det er svært enkelt!
Her er et eksempel der jeg har opprettet et OR for QAL-nettstedet:
Se på brukergrensesnittet ovenfor – jeg grupperte alle elementene som er knyttet til handlinger i innloggingsgrensesnittet, sammen, siden de ville være felles for flere testtilfeller. Deretter grupperte jeg navigasjonslenkene sammen. Hvis vi registrerer disse objektene i en gruppe, og alle testskriptene dermed bruker denne gruppen med lenkeobjekter i begynnelsen av hvert testtilfelle, kan objektene gjenbrukes i stedet for å legges til i lageret på nytt
Eksempel på bruk av objektlageret i UiPath
Slik ser objektlageret ut i UiPath-verktøyet:
I dette eksempelet på objektlageret har jeg organisert objektene for «innloggingssiden» i ett sett og «hovednavigasjonslenkene» i et annet sett. Hvis jeg med dette skulle bygge flere testskript for å – la oss si – teste innloggingssiden, ville alle testskriptene «kalle» de samme objektene som jeg hadde plassert på «innloggingssiden».
More Articles
Eksempel på bruk av objektlageret i PowerAutomate
Slik ser objektlageret ut i PowerAutomate-verktøyet:
Som jeg nevnte tidligere, er nøkkelen til gjenbruk også å sørge for at du navngir objektene slik at du enkelt kan finne dem igjen senere. Se på brukergrensesnittobjektet «meprmath_quiz». I motsetning til de andre feltene kan vi ikke enkelt identifisere hvilket brukergrensesnittobjekt det viser til. I et tilfelle som det ovenfor viste feltnavnet «meprmath_quiz» da jeg la til brukergrensesnittobjektet for tekstboksen «quiz». Vi kunne derfor kanskje kalt det «login_add» eller noe lignende for å gjøre objektet enkelt å finne under automatisering og vedlikehold av OR-et.
Avslutning
Så hvordan bruker du OR i ditt favorittverktøy for testautomatisering? Vi vil gjerne høre om det.
Jeg håper denne artikkelen hjelper deg med å forstå hvordan OR hjelper teamet på lang sikt. Vi er heldige som lever i en tid der de fleste verktøy for testautomatisering har OR-funksjonalitet. Alt du trenger å gjøre, er derfor å utforske hvordan det fungerer i favorittverktøyet ditt!
Lærte du noe nytt i denne artikkelen? Hvis du gjerne vil lese flere artikler som denne, må du ikke glemme å abonnere på nyhetsbrevet til The QA Lead!
Relaterte artikler:
Relatert verktøyliste: PROGRAMVARE FOR YTELSESTESTING FOR QA-TEAMER
Også verdt å sjekke ut:
