Søkeorddrevet testrammeverk med eksempel

Hva er søkeorddrevet testing?

Søkeorddrevet testing er en skriptteknikk som bruker datafiler til å inneholde nøkkelordene relatert til applikasjonen som testes. Disse nøkkelordene beskriver settet med handlinger som kreves for å utføre et spesifikt trinn.

En søkeorddrevet test består av søkeord på høyt og lavt nivå, inkludert søkeordargumentene, som er sammensatt for å beskrive handlingen til en testcase. Det kalles også tabelldrevet testing eller handlingsordbasert testing.

Ocuco Søkeorddrevet rammeverk er rammeverket for funksjonell automatiseringstesting som er bygget rundt denne teknikken. Det deler testtilfeller inn i fire forskjellige deler for å skille koding fra testtilfeller og testtrinn for bedre automatisering: selve testtrinnene, objektene disse trinnene påvirker, handlingene som utføres på disse objektene, og dataene som leveres til dem.

I søkeorddrevet testing identifiserer du først et sett med søkeord og knytter deretter en handling (eller funksjon) relatert til disse søkeordene. Her er hver testhandling som åpning eller lukking av nettleser, museklikk, tastetrykk osv. beskrevet med et nøkkelord som f.eks. åpne nettleseren, klikk, Typtext og så videre.

Diagrammet nedenfor viser to vanlige forretningshandlinger som blir til gjenbrukbare søkeord. For eksempel:

1. Logg inn til «guru99»-nettstedet – Nøkkelordet «pålogging» vil bli brukt i vårt automatiseringsrammeverk, for å teste påloggingsfunksjonen eller handlingen knyttet til den.
2. utlogging til «guru99»-nettstedet— Nøkkelordet «logg ut» vil bli brukt i vårt automatiseringsrammeverk, for å teste utloggingsfunksjonen eller handlingen knyttet til den.

Du vil se flere eksempler lenger ut i artikkelen. Mønsteret endres aldri: én forretningshandling, ett nøkkelord, én funksjon.

Eksempel på nøkkelord

Ordlisten nedenfor viser typiske nøkkelord for en bankapplikasjon og forretningshandlingen som hvert enkelt utløser.

nøkkelord	Tekniske beskrivelser
Login	Logg på guru99 bank demoside
E-post	Send e-post
logger ut	Logg ut fra guru99 banks demoside
Påminnelser	Finn uleste varsler

💡 Tips: Navngi nøkkelord etter forretningshandlingen, ikke det tekniske trinnet. «Logg inn» overlever en redesign av siden, mens «ClickBlueButton» ikke gjør det.

Komponenter i et søkeorddrevet rammeverk

Å vite hva et nøkkelord er, tar deg bare halvveis. For å lage et nøkkelorddrevet rammeverk setter du sammen et lite sett med filer, som hver eier ett problem.

1. Excel ark – Identifiser nøkkelordene og lagre dem i et Excel-ark, én rad per testtrinn.
2. Funksjonsbibliotek – Består av funksjonene for forretningsflytene (påloggingsknappen for ethvert nettsted). Når en test kjøres, leser den nøkkelordet fra Excel-arket og kaller funksjonene deretter.
3. Dataark – Lagre testdataene som brukes i applikasjonen, slik at ett nøkkelord kjører mot mange inndata.
4. Objektlager – Lagrer lokaliseringspunktene for hvert element nøkkelordene berører, slik at en endret lokaliseringspunkt redigeres på ett sted.
5. Test skript – Du kan ha testskript for hver manual Testsak eller et enkelt driverskript.
6. Driverskript – Går gjennom Excel-arket rad for rad, sammenligner hvert nøkkelord mot funksjonsbiblioteket og registrerer resultatet.
7. Automatiseringsverktøy – Utfører de løste kommandoene mot applikasjonen og leverer til rapporteringslaget.

Sammen danner disse sju delene en komplett rammeverk for testautomatiseringHvorfor velge dette designet?

Hvorfor gjøre søkeorddrevet testing

I programvareteknikk utføres nøkkelorddrevet testing av følgende grunn

• Vanlige komponenter håndteres av standard bibliotek
• Ved å bruke denne tilnærmingen kan tester skrives på en mer abstraksjonell måtetract-måte
• Høy grad av gjenbrukbarhet
• Detaljene i skriptet er skjult for brukerne
• Brukere trenger ikke å bruke skriptspråkene
• Testen er kortfattet, vedlikeholdbar og fleksibel

Fordi nøkkelordlaget absorberer endringer i applikasjonen, vil en stor Regresjonstesting Suiten holder seg grønn ved å redigere en håndfull funksjoner i stedet for hundrevis av skript. Den begrunnelsen former hvordan tilnærmingen brukes.

Hvordan utføre søkeorddrevet testing

Søkeorddrevet testing kan gjøres på begge måter, manuelt så vel som automatisert. Men vanligvis brukes det sammen med automatisert testing.

Målet bak automatisering av søkeorddrevet testing er

• Det bidrar til å redusere vedlikeholdskostnadene
• Unngår dupliserte spesifikasjoner
• Større gjenbruk av funksjonsskripting
• Bedre teststøtte og portabilitet
• Oppnå flere tester med mindre eller samme innsats

Med søkeorddrevet testing kan du lage enkle funksjonelle tester i de tidlige stadiene av utviklingen, testing av applikasjonen del for del. Den enkleste måten å lage en nøkkelorddrevet test på er å ta den opp. Etter opptaket kan testen modifiseres og tilpasses etter behov.

Hvert nøkkelord må være koblet til minst én kommando, et testskript eller en funksjon som implementerer handlingene relatert til det nøkkelordet.

Når testtilfeller utføres, tolkes nøkkelord av et testbibliotek, som kalles opp av et testautomatiseringsrammeverk.

De viktigste aktivitetene involvert i søkeorddrevet testing er

• Trinn 1) Identifisere søkeord på lavt nivå og høyt nivå
• Trinn 2) Implementering av nøkkelord som kjørbare
• Trinn 3) Opprette testcases
• Trinn 4) Opprette driverskriptene
• Trinn 5) Utføre testskriptene for automatisering

Trinn 1 og 2 er engangs designarbeid; trinn 3 til 5 gjentas hver sprint, som eksemplene nedenfor viser.

Eksempel på testtilfeller

Disse tre scenariene gjenbruker de samme nøkkelordene som er definert tidligere.

1. TC_01: Logg inn på guru99 demoside, finn ut hvor mange transaksjoner som utføres i dag
2. TC_02: Logg på guru99 demoside, send en e-post til en av kundene dine og logg ut
3. TC_03: Logg inn på guru99-demosiden og sjekk om det er mottatt varsel

TC_02, som er skrevet som en nøkkelordtabell, blir til seks rader som enhver tester kan lese eller endre rekkefølgen på uten å åpne koden:

Trinn	søkeord	Argument	Forventet resultat
1	åpen nettleser	Chrome	Nettleserøkten starter
2	Login	mngr123 / demopass	Hjemmesiden til lederen vises
3	E-post	kunde@eksempel.com	Skrivevinduet åpnes
4	klikk	sent	"Mail sendt» vises
5	logger ut	-	Sesjonen er avsluttet
6	lukk nettleseren	-	Nettleseren er lansert

Byttping argumentet i trinn 3 gjør de samme seks radene om til en annen test, som er der testdata ledelsen lønner seg.

Fordeler med søkeorddrevet testing

• Den lar funksjonelle testere planlegge testautomatisering før applikasjonen er klar
• Tester kan utvikles uten programmeringskunnskap
• Det er ikke avhengig av et bestemt programmeringsspråk eller verktøy
• Kompatibel med alle automatiseringsverktøy tilgjengelig på markedet

Disse fordelene forklarer hvorfor søkeorddrevet testing passer for langsiktige automatisert testing suiter. Kostnadene spiller også en rolle.

Begrensninger ved nøkkelorddrevet testing

MagemusklenetracEn situasjon som gjør nøkkelorddrevne tester lesbare, gjør dem også dyre å bygge. Før den første testen kjøres, må noen identifisere nøkkelordene, implementere hvert av dem som en funksjon, koble til objektarkivet og skrive driverskriptet. I et lite prosjekt koster oppsettet mer enn å skripte testene direkte.

Vedlikehold er den andre kostnaden. Biblioteket deles av hver test, så én uforsiktig redigering ødelegger hele pakken. Biblioteker sprer seg også: team legger til nesten duplikater som «Login», «SignIn» og «DoLogin».

• Høy startinvestering – rammeverksdesign og implementering av nøkkelord går forut for enhver testkjøring.
• Redusert fleksibilitet – testere uttrykker bare det eksisterende nøkkelord tillater, så uvanlige scenarier trenger utvikling.
• Kjipt for kompleks logikk – forgreninger og løkker motstår flate bordrader.
• Ferdigheter er fortsatt nødvendige – nøkkelordlaget er kodefritt, funksjonsbiblioteket er ikke.

⚠️ Advarsel: RevVis nøkkelordbiblioteket hver utgivelse og slett ubrukte oppføringer. Et ukontrollert vokabular er den vanligste grunnen til at nøkkelorddrevne rammeverk blir forlatt.

Disse avveiningene former sammenligningen nedenfor.

Søkeorddrevet vs. datadrevet vs. hybrid rammeverk

Søkeorddrevet og datadrevet testing løse forskjellige problemer. Et datadrevet rammeverk varierer inputene til et fast skript; et nøkkelorddrevet rammeverk varierer trinnene. Tabellen legger til hybridmodellen de fleste bedriftsteam bruker.

Aspekt	Søkeorddrevet rammeverk	Datadrevet rammeverk	Hybrid rammeverk
Hva er eksternalisert	Testtrinn og handlinger	Kun testdata	Både trinn og data
Planleggingsinnsats	Omfattende og presis	Begrenset til data og skript	Høyeste
Vedlikehold	Enklere, mer magemusklertracsjonslag	Hardere magemusklertracsjonen er tynnere	Enklest i stor skala
Kodeferdigheter kreves	Kun for funksjonsbiblioteket	Påkrevd for hvert skript	Nødvendig for kjernelaget
Kan starte før byggingen	Ja	Nei	Ja

I praksis kombineres stilene. Et hybridrammeverk lagrer trinn som nøkkelord og inndata i dataark, ofte over en SideobjektmodellVelg nøkkelorddrevet når mange testere skriver tester, datadrevet når én flyt trenger mange input, og hybrid når begge deler gjelder.

Verktøy som brukes for søkeorddrevet testing

Flere verktøy brukes mye for nøkkelorddrevet testing, og hvert verktøy tolker nøkkelordtabellen på en annen måte.

• HP QTP – leveres med en innebygd nøkkelordvisning, slik at arket og den kjørbare testen er én artefakt.
• Selenium – har ikke noe innebygd nøkkelordlag, så teamene bygger funksjonsbiblioteket og driverskriptet selv.
• Robotramme – en motor med åpen kildekode designet rundt nøkkelord, med tabellarisk syntaks og mange ferdige nøkkelord.
• TestNG – ofte brukt sammen med Selenium for å sekvensere nøkkelordtilordnede metoder og generere rapporter.

Vår liste over automatiserte testverktøy dekker lisenser og plattformstøtte for hvert alternativ.

Spørsmål og svar