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.

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:
- 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.
- 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.
- Excel-ark – Identificér nøgleordene og gem dem i et Excel-ark, én række pr. testtrin.
- 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.
- Datablade – Gem de testdata, der bruges i applikationen, så ét nøgleord kører mod mange input.
- Objektopbevaring – Indeholder lokaliseringspunkterne for hvert element, som nøgleordene berører, så en ændret lokaliseringspunkt redigeres ét sted.
- Test scripts – Du kan have test scripts for hver manual Test sag eller et enkelt driverscript.
- Driverscript – Gennemgår Excel-arket række for række, sammenligner hvert nøgleord med funktionsbiblioteket og registrerer resultatet.
- 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.
- TC_01: Log ind på guru99 demo site, find ud af hvor mange transaktioner der udføres i dag
- TC_02: Log ind på guru99 demo site, send en e-mail til en af dine kunder og log derefter ud
- 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.

