Kodėl seleno ir agurkų negalima vartoti kartu

Šiame įraše paaiškinsiu, kodėl manau, kad bloga mintis yra rašyti vartotojo sąsajos automatinius testus su selenu ir agurkais.

Įrašo pavadinime minimi Selenas ir Agurkas, nes jie yra populiariausi naršyklės automatizavimo ir BDD įrankiai, tačiau šio straipsnio kontekstas taikomas bet kuriam vartotojo sąsajos automatikos įrankiui kartu su bet kuriuo BDD įrankiu.

Prieš pradėdamas gilintis, apžvelkime šiek tiek pagrindinės informacijos.




Kas yra selenas?

Selenas yra naršyklės automatikos testavimo įrankis, galintis sąveikauti su žiniatinklio programos HTML elementais, siekiant imituoti vartotojo veiklą.

„Selenium WebDriver“ mes galime rašyti scenarijus daugeliu programavimo kalbų ir tai gali būti puikus turtas atliekant kelių OS ir kelių naršyklių bandymus.




Kas yra agurkas?

Agurkas buvo sukurtas siekiant paskatinti elgesio varomą vystymąsi (BDD), kad klientas galėtų apibūdinti savo reikalavimus kaip pavyzdžių, vadinamų scenarijais, seriją paprastuose tekstiniuose failuose, naudodamas „Gherkin“ kalbą formatu „Given When Then“.

Agurkų pasaulyje šie failai vadinami funkciniais failais, kuriuos „Scrum“ komanda peržiūri, kad prieš pradėdami tikrąjį kūrimą aiškiai suprastų reikalavimus.

Vykdant kūrimą, kūrėjai ir (arba) QA parašys žingsnio apibrėžimus, kurie iš esmės yra kodo fragmentai, susiejantys scenarijus iš funkcijų failų su bandomuoju kodu, kuris vykdo veiksmus prieš bandomą programą.



Selenas ir agurkas

Tiek selenas, tiek agurkas yra puikūs įrankiai savo tikslams, tačiau kai jie naudojami kartu, viskas gražiai nesituokia! Pažiūrėkime, kodėl.


Istorijos paprastai rašomos iš vartotojo perspektyvos, pavyzdžiui:

Funkcija: Prisijungimo funkcija

Kaip svetainės abc.com vartotojas

Noriu, kad klientai galėtų prisijungti prie svetainės


Kad jie galėtų peržiūrėti savo sąskaitos informaciją.

Savo ruožtu scenarijai funkcijų failuose yra parašyti taip, kad apibūdintų funkcijos elgesį, kai vartotojas sąveikauja su taikymas . Pavyzdžiui:

1 scenarijus: Tinkamas prisijungimas

Atsižvelgdamas į tai, kad esu abc.com prisijungimo puslapyje


Kai įvesiu galiojančius kredencialus

Tada mane nukreipia į puslapį „Mano paskyra“

Taigi galite pridėti daugiau scenarijų, kad išbandytumėte skirtingus duomenų derinius.

Kadangi ir istorija, ir ypatybių failas yra parašyti aukšto lygio požiūriu ir kadangi mes norime automatizuoti scenarijus, atrodo natūralu, kad „Agurke“ pradėti rašyti žingsnių apibrėžimus, kurie paskambina „Selenium“, kad valdytų programą, atlikite veiksmus ir patikrinti rezultatą.


Bet čia kyla problema; kai mes pradedame derinti seleną su agurku ir rašome automatizuotus vartotojo sąsajos testus.

Tiesą sakant, tokiais paprastais atvejais, kaip aukščiau pateiktas „Login“ scenarijus, viskas puikiai dera ir požiūris atrodo patikimas. Tiesą sakant, dauguma internete matomų pavyzdžių, demonstruojančių seleno ir agurkų naudojimą, atrodo, apsiriboja vien tik žinomas „Login“ pavyzdys.

Tokių tinklaraščių skaitytojai mano, kad jie gali pasirinkti paprastą prisijungimo scenarijų ir tą patį principą taikyti platesniam programos kontekstui.

Tačiau neapsigaukite, nes naudojant Seleną ir Agurką viskas gali labai sugesti, kai jie pritaikomi realaus pasaulio didelėje internetinėje programoje.

Paimkime tipiškos el. Prekybos programos, parduodančios produktus internete, paieškos rezultatų puslapio pavyzdį. Paprastai paieškos rezultatų puslapyje yra daugybė funkcijų, tokių kaip filtrai, rūšiavimas, produktų sąrašas, galimybė pakeisti paiešką, galimybė puslapius paguldyti arba automatiškai įkelti slinkiant ir pan., Kaip matyti toliau pateiktoje ekrano kopijoje:

Darau prielaidą, kad kiekviena paieškos rezultatų puslapio funkcija buvo įtraukta į svetainę palaipsniui, naudojant judrią plėtrą.

Taikydami tą patį mūsų paprasto prisijungimo pavyzdžio principą, kai kiekviena funkcija yra sukurta, mes turėtume atitinkamą funkcijų failą, užpildytą daugybe skirtingų scenarijų. Pavyzdžiui:

1 kūrimo iteracijoje yra sukurtas „Filtruoti pagal kainą“, todėl mes turėtume jai failą su savo scenarijais, susijusiais su kainų filtru.

2 kūrimo iteracijoje yra sukurtas „Filtruoti pagal žvaigždžių įvertinimą“, todėl mes turėtume jam skirtą funkcijų failą su savo scenarijais, susijusiais su žvaigždžių įvertinimo filtru, ir taip toliau kiekvienai naujai funkcijai.

Svarbu atkreipti dėmesį į tai, kad kiekvieno ypatybės failo scenarijai būdingi tik jų atitinkamai funkcijai. Tiesą sakant, todėl jie ir vadinami funkciniai failai nes dėmesys skiriamas individualūs bruožai .

Kaip minėta anksčiau, kai programa yra paprasta, mes galime išgyventi iššūkį automatizuoti vartotojo sąsajos scenarijus naudojant seleną ir agurką. Tačiau augant programai ir pridedant naujų funkcijų, atsiranda sudėtingumas, nes tarp skirtingų funkcijų gali būti priklausomybių.

Pavyzdžiui, pirmiausia galėčiau filtruoti paieškos rezultatus pagal kainą, tada taikyti kitą filtrą žvaigždutėms. Ak ... mes dabar turime problemą!

Kurį funkcinį failą dabar turėtų naudoti šis scenarijus? Faile „Filtruoti pagal žvaigždžių įvertinimą“ arba „Filtruoti pagal kainą“? Kaip būtų, jei dabar pridėčiau scenarijų, kad pritaikyčiau rūšiavimą savo filtruojamiems rezultatams ir surūšiuoti pagal daugiausiai balsų?

Jei suinteresuotoji šalis nori sužinoti, kokia yra mūsų bandomoji aprėptis, į kuriuos iš funkcijų failų jis turėtų atkreipti dėmesį? Ar jis gaus visą scenarijaus aprėptį perskaitęs tik vieną iš funkcijų failų, ar jam reikės perskaityti visus funkcijų failus?

Kūrimo metu, kai kiekviena funkcija yra kuriama po vieną kiekvienoje iteracijoje, funkcijų failai bus sutelkti į pačią funkciją, todėl tam tikru momentu, kai turime keletą funkcijų, turime pradėti galvoti apie jų išbandymą, o ne tik atskirai, bet ir kūrybinius scenarijus, kai deriname skirtingas savybes.

Tiesą sakant, tai padarys tikrieji programos vartotojai. Pirmiausia jie įves savo paieškos kriterijus, kai tik bus paieškos rezultatų puslapyje, jie galbūt puslapiuos, tada filtruos, tada rūšiuos, tada grįš ir t. T., Ir jie galės atlikti šiuos veiksmus bet kokia tvarka. Nustatyta įvykių tvarka nebus. Tai yra tikroji vartotojo kelionė ir tikras sistemos išbandymas!

Dauguma programos klaidų yra matomos, kai pati funkcija yra klaidinga, arba kai dvi funkcijos, kurios puikiai veikia atskirai, neveikia kartu. Tuo remiasi porų testavimo modelis.

Taigi, kokia didelė problema naudojant Seleną ir Agurką kartu?

Jei įmanoma, neturėtume naudoti žiniatinklio GUI funkcijoms tikrinti. Funkcijos funkcionalumas turėtų būti išbandytas API lygmenyje atliekant integravimo testus.

Vartotojo sąsaja turėtų būti rezervuota tik norint patikrinti vartotojo srautus per programą arba „end-to-end“ bandymus ir įsitikinti, kad puslapyje yra atitinkamų numatomų modulių ar valdiklių, kai vartotojas naršo iš vieno puslapio į kitą.

Tipinė vartotojo kelionė reikštų:

1 - eikite į abc.com svetainės pagrindinį puslapį

2 - ieškokite produkto pagrindiniame puslapyje

3 - Naršykite per paieškos rezultatų sąrašą

4 - pritaikykite filtrą ir (arba) rūšiuokite

5 - perskaitykite išsamią informaciją apie gaminį

6 - Įdėkite produktą į krepšelį

7 - toliau tikrinkite…

Selenas puikiai automatizuoja šiuos scenarijus ir tikrina, ar kiekviename puslapyje nėra įvairių elementų, ir, kaip jau minėjau aukščiau, į tai turėtume sutelkti dėmesį testuodami vartotojo sąsajos sluoksnyje ir testuodami skirtingų būsenų perėjimus.

Kaip matyti, kiekviena vartotojo kelionė per programą paliečia daugybę puslapių ir potencialiai sąveikauja su keliomis funkcijomis kiekviename puslapyje, ir mes patikrintume įvairius dalykus kiekviename kelionės etape, todėl naudodamiesi funkcijų failas dokumentuoti šiuos scenarijus nėra jokios prasmės, nes mes netestuojame funkcijos, mes bandome integruotą sistemą.

Viskas iš tikrųjų vyksta kriaušės pavidalu, kai bandome parašyti „galas iki galo“ scenarijus formatu „Duota-kada-tada“. Kiek turėsime „Givens“? Kiek mes turėsime dešimčių?

Galima teigti, kad bandymams nuo galo iki pabaigos galėtume tiesiog naudoti Seleną be agurkų ir turėti atskirus automatinius kiekvienos funkcijos bandymus naudojant seleną ir agurką. Vėlgi, aš nerekomenduoju šio požiūrio, nes galbūt turėsite pasikartojančius testus ir mes žinome, kokie yra lėti ir trapūs vartotojo sąsajos testai, todėl turėtume siekti, kad jų būtų mažiau, o ne daugiau! Be to, vis tiek turėsite atlikti priklausomybės nuo funkcijų testus.

Santrauka

Agurkas yra puikus įrankis tikrinant funkcijos veikimą API sluoksnyje atliekant integracijos testus, kur kiekvieną funkciją galima kruopščiai išbandyti. Šis įrankis turėtų būti naudojamas istorijų testavimui.

Selenas yra puiki priemonė automatizuoti vartotojo scenarijus vartotojo sąsajos lygmenyje ir patikrinti visos sistemos elgesį, apimančią daugybę vartotojų istorijų.

Kai mes einame į sistemos integracijos testavimą arba vartotojo sąsajos testavimą, geriausia naudoti „Selenium“ be pagrindinės „Agurkų“ sistemos, nes bandymas rašyti „Agurkų“ funkcijų failus vartotojo kelionėms gali būti labai sudėtingas ir neatitiktų to tikslo, kuriam sukurtas įrankis.

Mano straipsnis paremtas faktų išskaičiavimu!

  • Jei yra kokia nors vertė naudoti agurką, tai yra funkcijų lygyje.
  • Funkcijos funkcionalumą patikrinti geriausia ne vartotojo sąsajoje, pvz. API testai.
  • Net atliekant API sluoksnio bandymus, agurkas žlunga.
  • Vartotojo sąsajos testai turėtų apimti vartotojo / verslo scenarijus, o ne atskiras funkcijas.

Agurkas puikiai veikia su paprastu ir naiviu bandymų ir scenarijų vaizdu, pavyzdžiui, visų mėgstamiausia prisijungimo funkcija.

Atsižvelgdamas į tai, kad esu prisijungimo puslapyje
Kai įvesiu galiojančius kredencialus
Tada turėčiau pamatyti savo sąskaitą

Bet kuris išmanantis testuotojas žino, kad net ir paprastą prisijungimo funkciją galima patikrinti daugeliu atvejų. Pabandykite konvertuoti tuos čekius agurkuose.

Tai tik prisijungimui; pabandykite parašyti agurkų testą nuo galo iki galo!

Vartotojo sąsajos testai turėtų apimti naudotojo keliones, kurios paprastai yra visos pabaigos ir naudojasi keliomis programos funkcijomis.

Vieno vartotojo kelionėje visoje programoje vyksta daug.

Agurkas tikrai NETINKAMA priemonė vartotojo / verslo scenarijų testavimui.