Af hverju ætti ekki að nota selen og agúrku saman

Í þessari færslu mun ég útskýra hvers vegna ég tel að það sé slæm hugmynd að skrifa sjálfvirk próf HÍ með Selen og agúrku.

Í titli færslunnar er minnst á Selen og agúrku vegna þess að þeir eru vinsælustu sjálfvirkni vafra og BDD verkfæra í sömu röð, samt sem áður gildir samhengi þessarar greinar um öll sjálfvirkni tæki HÍ ásamt hvaða BDD tæki.

Áður en ég kafa dýpra skulum við fara yfir nokkrar bakgrunnsupplýsingar.

Hvað er selen?

Selen er sjálfvirkur prófunartæki vafra sem er fær um að hafa samskipti við HTML þætti vefforrits til að líkja eftir virkni notenda.

Í Selenium WebDriver getum við skrifað forskriftir á fjölda forritunarmála og geta verið frábær eign fyrir mörg OS og próf í gegnum vafra.

Hvað er agúrka?

Agúrka var búið til til að knýja fram atferlisstýrða þróun (BDD) ferli, þannig að viðskiptavinurinn geti lýst kröfum sínum sem röð af dæmum sem kallast atburðarás, í látlausum textaskrám með því að nota kúrkínsmálið í gefnu þegar síðan sniði.



Í agúrkaheiminum eru þessar skrár kallaðar eiginleikaskrár sem eru skoðaðar af Scrum teyminu til að fá skýran skilning á kröfunum áður en raunveruleg þróun er hafin.

Þegar þróun er hafin munu verktaki og / eða QA skrifa Skrefskilgreiningar sem eru í raun bútar af kóða sem binda atburðarásina frá eiginleikaskrám til prófkóða sem framkvæma aðgerðir gegn forritinu sem er til prófunar.

Selen og agúrka

Bæði selen og agúrka eru frábær verkfæri í eigin tilgangi en þegar þau eru notuð saman giftast hlutirnir ekki fallega! Við skulum sjá hvers vegna.

Sögur eru yfirleitt skrifaðar út frá sjónarhorni notanda, til dæmis:

Lögun: Innskráningarvirkni

Sem notandi vefsíðu abc.com

Ég vil að viðskiptavinir geti skráð sig inn á síðuna

Svo að þeir geti skoðað reikningsupplýsingar sínar.

Aftur á móti eru sviðsmyndir í eiginleikaskrám skrifaðar á þann hátt sem lýsir hegðun eiginleikans þegar notandi hefur samskipti við umsókn . Til dæmis:

Sviðsmynd 1: Gild innskráning

Í ljósi þess að ég er á abc.com innskráningarsíðu

Þegar ég fæ gilt skilríki

Þá er mér vísað á síðuna Reikningur minn

Og svo er hægt að bæta við fleiri sviðsmyndum til að prófa mismunandi samsetningar gagnanna.

Vegna þess að bæði sagan og eiginleikaskráin er skrifuð frá sjónarhóli háttsettra og vegna þess að við viljum gera sjálfsmyndirnar sjálfvirkar virðist eðlilegt að byrja að skrifa skrefaskilgreiningar í Gúrku sem kalla Selen til að keyra forritið, gerðu aðgerðirnar og sannreyna niðurstöðuna.

En, þetta er þar sem vandamálið kemur upp; þegar við byrjum að sameina selen og agúrku til að skrifa sjálfvirkar prófanir á HÍ.

Í sanngirni, í einföldum tilvikum eins og atburðarásinni hér að ofan, passa hlutirnir fallega saman og nálgunin virðist líkleg og í raun virðast flest dæmi sem þú sérð á internetinu, sem sýna fram á notkun á seleni og agúrku, takmarka sig við frægt Login dæmi.

Lesendur slíkra blogga ætla að þeir geti tekið einföldu atburðarás innskráningar og beitt sömu meginreglu í víðara samhengi forrits.

Ekki láta blekkjast þó, þar sem hlutirnir geta orðið mjög súrir með Selen og agúrku þegar það er borið á raunverulegt stórt vefforrit.

Við skulum taka dæmi af leitarniðurstöðusíðu dæmigerðs rafræns verslunarforrits sem selur vörur á netinu. Venjulega er leitarniðurstöðusíðan full af eiginleikum, svo sem síum, tegundum, vörulista, getu til að breyta leit, getu til að hlaða eða sjálfvirkt hlaða við að fletta, osfrv., Eins og sjá má á skjámyndinni hér að neðan:

Ég ætla að gera ráð fyrir að hver eiginleiki á leitarniðurstöðusíðunni hafi verið bætt við síðuna stigvaxandi með lipurri þróun.

Ef við notum sömu meginreglu í einföldum innskráningardæmum okkar, þar sem hver eiginleiki er þróaður, myndum við hafa hverja eiginleikaskrá fyllt með fullt af mismunandi atburðarás. Til dæmis:

Í endurtekningu 1 í þróuninni er „Sía eftir verði“ þróað, þannig að við myndum hafa eiginleikaskrá fyrir það með eigin sviðsmyndum sem tengjast verðsíunni.

Í endurgerð 2 í þróuninni er „Sía eftir stjörnugjöf“ þróað, þannig að við myndum hafa eiginleikaskrá fyrir hana með eigin sviðsmyndum sem tengjast stjörnugjöfarsíunni og svo framvegis fyrir hvern nýjan eiginleika.

Það er mikilvægt að hafa í huga að atburðarásin í hverri eiginleikaskrá er aðeins sértæk fyrir viðkomandi eiginleika. Reyndar er þetta ástæðan fyrir því að þeir eru kallaðir lögun skrár vegna þess að áherslan er á einstaka eiginleika .

Eins og fyrr segir, þegar forritið er einfalt, getum við lifað af áskorunina um að gera sjálfvirkar sviðsmyndir í HÍ með seleni og agúrku. En þegar forritið vex og nýjum eiginleikum er bætt við, þá myndast flækjustig þar sem það gæti verið háð milli mismunandi aðgerða.

Ég gæti til dæmis fyrst síað leitarniðurstöður mínar eftir verði og síðan notað aðra síu fyrir stjörnugjöfina. Ah ... við höfum nú vandamál!

Hvaða eiginleikaskrá ætti þessi atburðarás að fara núna? Í skránni „Sía eftir stjörnugjöf“ eða „Sía eftir verði“? Hvað með það ef ég bæti nú við atburðarás til að beita tegund í síaðar niðurstöður mínar til að raða eftir hæstu atkvæðum?

Ef hagsmunaaðili vill sjá hver prófumfjöllun okkar er, hvaða eiginleikaskrár ætti hann að skoða? Mun hann fá heildarmynd af umfjöllun um atburðarás með því að lesa aðeins eina af lögunaskrám eða þyrfti hann að lesa allar leikjaskrár?

Þegar þróunin er þróuð, hver og einn eiginleiki er þróaður einn í einu í hverri endurtekningu, myndu aðgerðarskrárnar beinast að eiginleikanum sjálfum, þannig að einhvern tíma, þegar við höfum marga eiginleika, verðum við að fara að hugsa um að prófa þetta, ekki aðeins í einangrun en einnig skapandi atburðarás þar sem við sameinum mismunandi eiginleika.

Og í raun er þetta það sem raunverulegir notendur forritsins munu gera. Þeir munu fyrst slá inn leitarskilyrðin, einu sinni á leitarniðurstöðusíðunni, þeir myndu mögulega blaðsíða, sía síðan, raða, fara síðan aftur og svo framvegis og þeir geta gert þessar aðgerðir í hvaða röð sem er. Það verður ekki mælt fyrir um röð atburða. Þetta er alvöru notendaferðalag og algjör prófun á kerfinu!

Meirihluti galla í forriti er afhjúpaður þegar annað hvort eiginleiki er buggy eða þegar tveir eiginleikar sem virka fullkomlega vel í einangrun, vinna ekki saman. Þetta er það sem Pairwise Testing Model byggir á.

Svo, hvað er málið með að nota selen og agúrku saman?

Þar sem það er mögulegt ættum við ekki að nota vefur GUI til að staðfesta virkni. Prófa skal virkni eiginleika í API laginu með samþættingarprófum.

HÍ ætti aðeins að vera frátekið til að kanna notendastreymi í gegnum forritið, eða end-to-end próf og ganga úr skugga um að viðeigandi búnar einingar eða búnaður séu til staðar á síðunni þegar notandinn flakkar frá einni síðu til annarrar.

Dæmigerð notendaferð myndi fela í sér:

1 - Flettu að heimasíðu abc.com vefsíðunnar

2 - Leitaðu að vöru frá heimasíðunni

3 - Flettu í gegnum lista yfir leitarniðurstöður

4 - Notaðu síu og / eða raðaðu

5 - Lestu upplýsingar um vörur

6 - Bættu vörunni í körfu

7 - Haltu áfram að skoða ...

Selen er frábært í því að gera sjálfvirkar þessar sviðsmyndir og athuga ýmsa þætti á hverri síðu og eins og ég nefndi hér að framan, þá ættum við að einbeita okkur að því þegar prófað er í UI lag og prófanir á mismunandi umbreytingum ríkja.

Eins og sjá má snertir hver notendaferð í gegnum forritið margar síður og hefur mögulega samskipti við marga eiginleika á hverri og einni síðu, og við myndum sannreyna ýmsa hluti í hverju skrefi á ferðinni, svo að nota lögun skrá að skjalfesta þessar sviðsmyndir hefur engan tilgang, því við erum ekki að prófa eiginleika, við erum að prófa samþætta kerfið.

Hlutirnir fara raunverulega perulaga þegar við reynum að skrifa sviðsmyndirnar frá lokum til enda á gefnu-þegar-þá sniði. Hvað ætlum við að hafa mörg Givens? Hvað ætlum við að eiga marga tugi?

Maður gæti haldið því fram að fyrir end-to-end próf gætum við bara notað Selen eitt og sér án agúrkunnar og haft aðskildar sjálfvirkar prófanir fyrir hverja eiginleika með Selen og agúrku. Aftur, ég mæli ekki með þessari aðferð þar sem þú munt mögulega hafa tvítekningarpróf og við vitum hversu hæg og brothætt próf HÍ eru, þannig að við ættum að stefna að því að hafa minna af þeim ekki meira! Þar að auki verður þú samt að takast á við eiginleikarannsóknir.

Yfirlit

Gúrka er frábært tæki til að kanna hegðun eiginleika í API laginu með samþættingarprófum þar sem hægt er að prófa hvern og einn eiginleika. Þetta tæki ætti að nota við sögupróf.

Selen er frábært tæki til að gera sjálfvirkar atburðarás notenda við HÍ lagið og athuga hegðun kerfisins í heild og nær yfir margar notendasögur.

Þegar við komum að kerfisaðlögunarprófun eða UI-prófun er best að nota selen án undirliggjandi agúrkuramma þar sem reynt er að skrifa gúrkufaraskrá fyrir notendaferðir, getur orðið mjög fyrirferðarmikill og myndi ekki þjóna þeim tilgangi sem tólið er smíðað fyrir.

Grein mín er byggð á ályktun staðreynda!

  • Ef það er einhver gildi í því að nota agúrku, þá er það á eiginleikastiginu.
  • Að kanna virkni eiginleika er best gert utan HÍ, t.d. API próf.
  • Jafnvel við API lag prófanir, agúrka mistakast hörmulega.
  • HÍ-próf ​​ættu að ná til atburðarásar notenda / fyrirtækja en ekki stakra eiginleika.

Gúrka vinnur fallega með einfaldri og barnalegri sýn á prófanir og sviðsmyndir, svo sem uppáhalds innskráningaraðgerðir allra.

Í ljósi þess að ég er á innskráningarsíðunni
Þegar ég fæ gilt skilríki
Þá ætti ég að sjá reikninginn minn

En allir klókir prófanir vita að jafnvel einföld innskráningarvirkni hefur mörg mörg eftirlit. Prófaðu að breyta þessum ávísunum í agúrku.

Þetta er bara til innskráningar; prófaðu að skrifa end-to-end próf í agúrku!

HÍ prófanir ættu að ná yfir notendaferðir sem eru venjulega endir til enda og æfa marga eiginleika forrits.

Það er margt sem gerist í einni notendaferð yfir forritið.

Agúrka er örugglega EKKI rétta tækið til að prófa atburðarás notenda / viðskipta.