Cucumber Ramme: Hvad er Cucumber?

⚡ Smart opsummering

Cucumber er et testværktøj, der understøtter adfærdsdrevet udvikling, hvilket giver alle mulighed for at læse tests uanset teknisk viden. Denne ressource forklarer, hvordan adfærdsdrevet udvikling fungerer gennem Given-Når-Så-trin, fordelene ved Cucumber, og hvordan det sammenlignes med Selenium og HP ALM.

  • ???? Kernedefinition: Cucumber er et adfærdsdrevet udviklingsværktøj, der skriver tests i letforståelige sprog, som er forståelige for både tekniske og ikke-tekniske interessenter.
  • 🗣️ BDD Foundation: Forretningsanalytikere og produktejere beskriver systemadfærd, før udviklere skriver kode, hvilket forbedrer den fælles forståelse.
  • 📝 Givet-Når-Så: Hver Cucumber Scenariet følger en læsbar Givet-Hvornår-Så-struktur, der også fungerer som levende dokumentation.
  • ⚡ Vigtigste Fordele: Hurtig opsætning, genbrug af kode, fokus på slutbrugeren og nem involvering af ikke-kodende forretningsinteressenter.
  • ⚖️ Værktøjssammenligning: Cucumber er gratis og BDD-baseret, mens HP ALM er betalt og Selenium målretter sig mod funktionel og ydeevnetestning.

Cucumber Framework

Hvad er Cucumber?

Cucumber er et testværktøj, der understøtter adfærdsdrevet udvikling (BDD). Det tilbyder en måde at skrive tests, som alle kan forstå, uanset deres tekniske viden. I BDD skriver brugerne (forretningsanalytikere, produktejere) først scenarier eller accepttests, der beskriver systemets adfærd fra kundens perspektiv, til gennemgang og godkendelse af produktejerne, før udviklerne skriver deres kode. Cucumber rammeværket bruger Ruby programmeringssprog.

Cucumber Framework
Cucumber Framework

Sådan fungerer BDD i Cucumber Automatisering?

Forestil dig, at du har fået til opgave at oprette et pengeoverførselsmodul i en netbankapplikation.

Der er flere måder at teste det på i Cucumber Testramme:

  1. Pengeoverførsel bør finde sted, hvis der er tilstrækkelig saldo på kildekontoen.
  2. Pengeoverførsel bør finde sted, hvis destinationskontooplysningerne er korrekte.
  3. Pengeoverførslen skal finde sted, hvis den indtastede transaktionsadgangskode / RSA-kode / sikkerhedsgodkendelse for transaktionen er korrekt.
  4. Pengeoverførsel skal finde sted, selvom det er en helligdag.
  5. Pengeoverførslen skal finde sted på en fremtidig dato fastsat af kontohaveren.

Testscenarie bliver mere detaljeret og kompleks, efterhånden som vi tager højde for yderligere funktioner som overførselsbeløb X i et interval på Y dage/måneder, stop af den planlagte overførsel, når det samlede beløb når Z, og så videre.

Udvikleres generelle tendens er at udvikle funktioner og skrive testkode senere. Som det fremgår af ovenstående tilfælde, Test sag Udviklingen til dette scenarie er kompleks, og udvikleren vil udsætte Test indtil udgivelsen, hvor de vil udføre hurtig, men ineffektiv testning.

For at overvinde dette problem, Cucumber BDD (Behavior Driven Development) blev udtænkt. Det gør hele testprocessen nem for en udvikler.

In Cucumber BDD, hvad end du skriver skal gå ind Givet-Hvornår-Så trin. Lad os betragte det samme eksempel ovenfor i BDD:

Given that a fund transfer module in net banking application has been developed
And I am accessing it with proper authentication
When I shall transfer with enough balance in my source account
Or I shall transfer on a Bank Holiday
Or I shall transfer on a future date
And destination a/c details are correct
And transaction password/RSA code/security authentication for the transaction is correct
And press or click send button
Then amount must be transferred
And the event will be logged in log file

Er det ikke nemt at skrive, læse og forstå? Det dækker alle mulige testcases for pengeoverførselsmodulet og kan nemt ændres for at imødekomme flere. Det minder også mere om at skrive dokumentation til pengeoverførselsmodulet.

Fordele ved Cucumber Software

  1. Det er nyttigt at involvere forretningsinteressenter, der ikke nemt kan læse kode.
  2. Cucumber Testværktøj fokuserer på slutbrugeroplevelsen.
  3. Stilen i testenes skrivning gør det nemmere at genbruge kode i testene.
  4. Hurtig og nem opsætning og udførelse.
  5. Cucumber testværktøj er et effektivt værktøj til test.

Cucumber vs Selenium vs ALM

I dette afsnit vil vi studere forskellen mellem Cucumber, Seleniumog ALM.

Cucumber HP ALM (QTP) Selenium
Cucumber softwaren er gratis. QTP er dyrt. Det er gratis.
Cucumber Software er et adfærdsdrevet udviklingsværktøj. Det er et funktionelt automatiseringsværktøj. Det er en funktionel og ydeevne (Selenium Grid) testværktøj.
Plugin'et i Cucumber Testværktøjet virker hurtigere. Plugins er langsommere sammenlignet med Cucumber og Selenium. Plugins er langsommere end Cucumber.
Cucumber Framework understøtter også andre sprog ud over Ruby, som f.eks. Java, Scala, GroovyOsv QTP understøtter kun VB Script. Selenium understøtninger Java, .Net og mange andre sprog.
At skrive automatiseringstrin er et fælles arbejde mellem testere og udviklere. In QTP, kun testeren skriver automatiseringstrin. lignende Cucumber, at skrive automatiseringstrin er et fælles arbejde mellem testere og udviklere.
Cucumber Testværktøjet understøtter kun webmiljøet. Understøtter web, desktop og alle klient-server-applikationer. Understøtter kun webmiljøet.

Tjek også:- UFT vs Selenium: Forskel mellem Selenium og HP UFT

Ofte Stillede Spørgsmål

Ja. AI-værktøjer kan udarbejde Gherkin-scenarier og trindefinitioner direkte fra skriftlige krav. Testere bør dog gennemgå de genererede scenarier for nøjagtighed, kanttilfælde og fuldstændig dækning, før de bruges.

Nej. AI fremskynder scenarieskrivning og tringenerering, men menneskelige testere definerer stadig forventet adfærd, validerer forretningslogik og opretholder samarbejdet med interessenter, hvilket fortsat er centralt for adfærdsdrevet udvikling.

Gherkin er et almindeligt tekstsprog Cucumber bruger til at skrive testscenarier. Den følger "Givet-When-Then"-strukturen, hvilket gør tests læsbare for både forretningsinteressenter og udviklere, samtidig med at de stadig er eksekverbare.

Cucumber er et BDD-værktøj. Det fokuserer på systemadfærd beskrevet fra brugerens perspektiv, i modsætning til TDD, som fokuserer på at skrive kodetests på enhedsniveau, før hvert lille stykke funktionalitet implementeres.

Opsummer dette indlæg med: