Søgeordsdrevet testramme med eksempel

⚡ Smart opsummering

Søgeordsdrevet testning adskiller testlogik fra automatiseringskode via mappingping nøgleord i letforståelige sprog til genanvendelige funktioner, så testere designer, vedligeholder og skalerer automatiserede pakker via regneark i stedet for at skrive scripts til hver enkelt testcase.

  • 🔑 Grundlæggende om søgeord: Enhver handling som f.eks. openbrowser, klik eller Typtext bliver et selvbeskrivende søgeord, der understøttes af præcis én funktion.
  • 🧩 Fire byggesten: Excel-ark, et funktionsbibliotek, dataark og et objektlager holder trin, objekter, handlinger og data adskilt.
  • 📊 Borddrevet design: Testere skriver cases som nøgleordsrækker med parametre, så der kræves ingen kendskab til scriptsprog for at skrive en test.
  • 🇧🇷 Udførelse af driverscript: Et driverscript læser hvert nøgleord, kalder den tilknyttede funktion og skriver resultatet tilbage til arket.
  • 🧪 Valg af værktøj: HP QTP, Selenium, og Robot Framework fortolker alle nøgleordstabeller uden brugerdefineret parsing.
  • ⚖️ Rammetilpasning: Hybridopsætninger parrer søgeord med datadrevne input for at udvide dækningen uden at duplikere et eneste testtrin.
  • 🚧 Planlæg for overheadomkostninger: Det koster tid at designe søgeord og vedligeholde biblioteket på forhånd, så hold ordforrådet lille og gennemgå det ved hver udgivelse.

Hvad er søgeordsdrevet test?

Søgeordsdrevet test er en scriptteknik, der bruger datafiler til at indeholde nøgleord, der er relateret til den applikation, der testes. Disse nøgleord beskriver det sæt af handlinger, der kræves for at udføre et specifikt trin.

En søgeordsdrevet test består af nøgleord på højt og lavt niveau, herunder søgeordsargumenterne, som er sammensat til at beskrive handlingen af ​​en testcase. Det kaldes også tabeldrevet test eller handling ord baseret test.

Søgeordsdrevet rammeværk er det funktionelle automatiseringstestframework, der er bygget op omkring denne teknik. Det opdeler testcases i fire forskellige dele for at adskille kodning fra testcases og testtrin for bedre automatisering: selve testtrinnene, de objekter, som disse trin påvirker, de handlinger, der udføres på disse objekter, og de data, der leveres til dem.

I søgeordsdrevet test identificerer du først et sæt søgeord og tilknytter derefter en handling (eller funktion) relateret til disse søgeord. Her er enhver testhandling som åbning eller lukning af browser, museklik, tastetryk osv. beskrevet med et nøgleord som f.eks. openbrowser, klik, Typtext og så videre.

Diagrammet nedenfor viser to almindelige forretningshandlinger, der bliver til genbrugelige søgeord. For eksempel:

  1. logger på eller til "guru99"-webstedet - Nøgleordet "login" vil blive brugt i vores automatiseringsramme for at teste login-funktionen eller handlingen forbundet med den.
  2. logger ud til "guru99"-webstedet— Nøgleordet "logout" vil blive brugt i vores automatiseringsramme for at teste logout-funktionen eller handlingen forbundet med den.

Du vil se flere eksempler længere nede i artiklen. Mønsteret ændrer sig aldrig: én forretningshandling, ét søgeord, én funktion.

Eksempel på søgeord

Ordlisten nedenfor viser typiske nøgleord til en bankapplikation og den forretningshandling, som hvert enkelt udløser.

nøgleord Beskrivelse
Login Log ind på guru99 banks demoside
Emails Send e-mail
logger ud Log ud fra guru99 banks demoside
Notifikationer Find ulæste notifikationer

💡 Tip: Navngiv søgeord efter forretningshandlingen, ikke det tekniske trin. "Login" overlever et redesign af siden, mens "ClickBlueButton" ikke gør.

Komponenter i et søgeordsdrevet rammeværk

At vide, hvad et søgeord er, er kun halvvejs. For at oprette et søgeordsdrevet framework samler du et lille sæt filer, der hver især omhandler et emne.

  1. Excel-ark – Identificér nøgleordene og gem dem i et Excel-ark, én række pr. testtrin.
  2. Funktionsbibliotek – Består af funktionerne for forretningsflowene (login-knappen til ethvert websted). Når en test udføres, læser den nøgleordet fra Excel-arket og kalder funktionerne i overensstemmelse hermed.
  3. Datablade – Gem de testdata, der bruges i applikationen, så ét nøgleord kører mod mange input.
  4. Objektopbevaring – Indeholder lokaliseringspunkterne for hvert element, som nøgleordene berører, så en ændret lokaliseringspunkt redigeres ét sted.
  5. Test scripts – Du kan have test scripts for hver manual Test sag eller et enkelt driverscript.
  6. Driverscript – Gennemgår Excel-arket række for række, sammenligner hvert nøgleord med funktionsbiblioteket og registrerer resultatet.
  7. Automatiseringsværktøj – Udfører de løste kommandoer mod applikationen og leverer til rapporteringslaget.

Tilsammen danner disse syv dele et komplet testautomatiseringsrammeHvorfor vælge dette design?

Hvorfor udfører søgeordsdrevet test

I Software Engineering udføres søgeordsdrevet test af følgende årsag

  • Fælles komponenter håndteres af standardbibliotek
  • Ved at bruge denne tilgang kan tests skrives på en mere abstrakt mådetract-manér
  • Høj grad af genanvendelighed
  • Detaljerne i scriptet er skjult for brugerne
  • Brugere behøver ikke bruge scriptsprogene
  • Testen er kortfattet, vedligeholdelig og fleksibel

Fordi søgeordslaget absorberer ændringer i applikationen, vil en stor regressionstest Suiten forbliver grøn ved at redigere en håndfuld funktioner i stedet for hundredvis af scripts. Den argumentation former, hvordan tilgangen anvendes.

Sådan udfører du søgeordsdrevet test

Søgeordsdrevet testning kan udføres på begge måder, manuelt såvel som automatiseret. Men normalt bruges det sammen med automatiseret testning.

Formålet bag automatisering af søgeordsdrevet testning er

  • Det hjælper med at reducere vedligeholdelsesomkostningerne
  • Undgår duplikerede specifikationer
  • Større genbrug af funktionsscripting
  • Bedre testsupport og bærbarhed
  • Opnå flere test med mindre eller samme indsats

Med søgeordsdrevet testning kan du oprette simple funktionelle tests I de tidligere udviklingsfaser testes applikationen stykke for stykke. Den enkleste måde at sammensætte en søgeordsdrevet test på er at optage den. Efter optagelsen kan testen ændres og tilpasses efter behov.

Hvert nøgleord skal være knyttet til mindst én kommando, et testscript eller en funktion, der implementerer de handlinger, der er relateret til det pågældende nøgleord.

Når testcases udføres, fortolkes nøgleord af et testbibliotek, som kaldes af en testautomatiseringsramme.

De vigtigste aktiviteter involveret i søgeordsdrevet testning er

  • Trin 1) Identifikation af søgeord på lavt niveau såvel som på højt niveau
  • Trin 2) Implementering af søgeord som eksekverbare
  • Trin 3) Oprettelse af testcases
  • Trin 4) Oprettelse af driver-scripts
  • Trin 5) Udførelse af automatiseringstestscripts

Trin 1 og 2 er engangsdesignarbejde; trin 3 til 5 gentages ved hvert sprint, som eksemplerne nedenfor viser.

Eksempel på testcases

Disse tre scenarier genbruger de samme nøgleord, der er defineret tidligere.

  1. TC_01: Log ind på guru99 demo site, find ud af hvor mange transaktioner der udføres i dag
  2. TC_02: Log ind på guru99 demo site, send en e-mail til en af ​​dine kunder og log derefter ud
  3. TC_03: Log ind på guru99-demo-webstedet og tjek, om der er modtaget notifikationer

Skrevet som en nøgleordstabel bliver TC_02 til seks rækker, som enhver tester kan læse eller omarrangere uden at åbne koden:

Trin Søgeord Argument Forventet resultat
1 åben browser Chrome Browsersessionen starter
2 Login mngr123 / demopass Managerens hjemmeside vises
3 Emails kunde@eksempel.com Skrivevinduet åbnes
4 klik Send "Mail "sendt" vises
5 logger ud - Session lukket
6 lukbrowser - Browser udgivet

Swapping Argumentet i trin 3 omdanner de samme seks rækker til en anden test, hvilket er hvor testdata ledelse betaler sig.

Fordele ved søgeordsdrevet test

  • Det giver funktionelle testere mulighed for at planlægge testautomatisering, før applikationen er klar
  • Tests kan udvikles uden programmeringskendskab
  • Det er ikke afhængigt af et specifikt programmeringssprog eller værktøj
  • Kompatibel med alle automatiseringsværktøjer på markedet

Disse fordele forklarer, hvorfor søgeordsdrevet testning er velegnet til langtidsholdbare automatiseret test suiter. Priserne betyder også noget.

Begrænsninger ved søgeordsdrevet testning

MavemusklernetracEn funktion, der gør nøgleordsdrevne tests læsbare, gør dem også dyre at bygge. Før den første testkørsel skal nogen identificere nøgleordene, implementere hvert enkelt som en funktion, tilslutte objektarkivet og skrive driverscriptet. På et lille projekt koster den opsætning mere end at scripte testene direkte.

Vedligeholdelse er den anden omkostning. Biblioteket deles af hver test, så én uforsigtig redigering ødelægger hele pakken. Biblioteker spreder sig også: teams tilføjer næsten dubletter såsom "Login", "SignIn" og "DoLogin".

  • Høj initial investering – frameworkdesign og implementering af nøgleord går forud for enhver testkørsel.
  • Reduceret fleksibilitet – testere udtrykker kun, hvad eksisterende søgeord tillader, så usædvanlige scenarier skal udvikles.
  • Akavet for kompleks logik – forgrening og løkker modstår flade bordrækker.
  • Færdigheder er stadig nødvendige – nøgleordslaget er kodefrit, funktionsbiblioteket er ikke.

⚠️ Advarsel: RevSe nøgleordsbiblioteket ved hver udgivelse og slet ubrugte poster. Et ukontrolleret ordforråd er den mest almindelige årsag til, at nøgleordsdrevne frameworks opgives.

Disse afvejninger former sammenligningen nedenfor.

Søgeordsdrevet vs. datadrevet vs. hybrid framework

Søgeordsdrevet og datadrevet test løser forskellige problemer. Et datadrevet framework varierer inputtet fra et fast script; et nøgleordsdrevet framework varierer trinnene. Tabellen tilføjer den hybridmodel, som de fleste virksomhedsteams anvender.

Aspect Søgeordsdrevet rammeværk Datadrevet rammeværk Hybrid rammeværk
Hvad er eksternaliseret Testtrin og handlinger Kun testdata Både trin og data
Planlægningsindsats Omfattende og præcis Begrænset til data og scripts Højeste
Vedligeholdelse Lettere, mere mavemuskulaturtraction lag Hårdere mavemusklertractionen er tyndere Nemmest i stor skala
Kodningsfærdigheder nødvendige Kun for funktionsbiblioteket Påkrævet for hvert script Kræves til kernelaget
Kan starte før byggeriet Ja Ingen Ja

I praksis kombineres stilarterne. Et hybrid framework gemmer trin som nøgleord og input i dataark, ofte over en SideobjektmodelVælg søgeordsdrevet, når mange testere skriver tests, datadrevet, når ét flow kræver mange input, og hybrid, når begge dele gælder.

Værktøjer brugt til søgeordsdrevet test

Adskillige værktøjer bruges i vid udstrækning til søgeordsdrevet testning, og hver især fortolker søgeordstabellen forskelligt.

  • HP QTP – leveres med en indbygget nøgleordsvisning, så arket og den eksekverbare test er én artefakt.
  • Selenium – har intet native nøgleordslag, så teams bygger selv funktionsbiblioteket og driverscriptet.
  • Robotramme – en open source-motor designet omkring søgeord, med tabelformet syntaks og mange færdige søgeord.
  • TestNG – almindeligvis brugt sammen med Selenium at sekventere søgeordskortlagte metoder og generere rapporter.

Vores liste over automatiserede testværktøjer dækker licenser og platformsupport for hver mulighed.

Ofte Stillede Spørgsmål

AI-assistenter kan udarbejde søgeordsnavne fra brugerhistorier og strukturere matchningen Selenium metoder, hvilket fjerner det meste af opsætningstidenpingEt menneske skal stadig bekræfte forretningsvokabularet og validere hver genereret locator, før serien er betroet.

Den reducerer den i stedet for at fjerne den. Selvreparerende motorer genidentificerer et element fra omgivende attributter, når en locator går i stykker, hvilket fjerner rutinemæssige reparationer. Der er stadig behov for styring af arkivet, fordi en helbredt locator, der lydløst matcher det forkerte element, skjuler en reel defekt.

Nej. Begge skjuler kode bag læsbare trin, men BDD-værktøjer som f.eks. Cucumber Brug "Givet-Hvornår-Så"-sætninger, der er skrevet til samarbejde om krav. Nøgleordsbaserede tests bruger tabulære handlingsord, der er skrevet til genbrug i automatiseringspakken.

Hold ordforrådet så lille som applikationen tillader, typisk et par dusin lavniveauhandlinger plus et nøgleord på højt niveau pr. forretningsflow. Hvis to nøgleord beskriver den samme handling, skal du flette dem sammen med det samme; det er dubletter, der gør biblioteker uvedligeholdlige.

Ja. Overfør nøgleordsarkene til versionskontrol sammen med funktionsbiblioteket, og lad derefter byggeserveren kalde driverscriptet. Løbere som f.eks. TestNG håndtag grobping og rapportering, så fejl dukker op i den samme byggerapport som enhedstests.

Opsummer dette indlæg med: