Miks ei tohiks seleeni ja kurki koos kasutada

Selles postituses selgitan, miks on minu arvates halb mõte kirjutada kasutajaliidese automatiseeritud teste seleeni ja kurgiga.

Postituse pealkirjas mainitakse seleeni ja kurki, kuna need on vastavalt kõige populaarsemad brauseri automatiseerimise ja BDD tööriistad, kuid selle artikli kontekst puudutab kõiki kasutajaliidese automatiseerimisvahendeid koos mis tahes BDD tööriistadega.

Enne kui süvenen, vaatame üle mõne taustteabe.




Mis on seleen?

Seleen on brauseri automatiseerimise testimise tööriist, mis on võimeline kasutaja aktiivsuse simuleerimiseks suhtlema veebirakenduse HTML-elementidega.

Selenium WebDriveris saame kirjutada skripte mitmetesse programmeerimiskeeltesse ning see võib olla suurepärane eelis mitme operatsioonisüsteemi ja brauseriteülese testimise jaoks.




Mis on kurk?

Kurk loodi käitumispõhise arendamise (BDD) protsessi juhtimiseks, nii et klient saab kirjeldada oma nõudeid kui näiteid, mida nimetatakse stsenaariumiteks, lihttekstifailidena, kasutades Gherkini keelt vormingus Given When Then.

Kurkimaailmas nimetatakse neid faile funktsioonifailideks, mida Scrumi meeskond vaatab enne tegeliku arenduse alustamist nõuetest selgelt aru.

Kui arendus on käimas, kirjutavad arendajad ja / või kvaliteedikontrolli etappide definitsioonid, mis on sisuliselt koodijupid, mis seovad stsenaariumid funktsioonifailidest testkoodini, mis täidavad toiminguid testitava rakenduse vastu.



Seleen ja kurk

Nii seleen kui kurk on suurepärased tööriistad omaenda eesmärkidel, kuid koos kasutatuna ei abiellu asjad kenasti! Vaatame, miks.


Lood kirjutatakse tavaliselt kasutaja vaatenurgast, näiteks:

Tunnusjoon: Sisselogimise funktsioon

Veebisaidi abc.com kasutajana

Soovin, et kliendid saaksid saidile sisse logida


Et nad saaksid oma kontoteavet vaadata.

Omakorda on funktsioonifailide stsenaariumid kirjutatud viisil, mis kirjeldab funktsiooni käitumist, kui kasutaja suhtleb rakendus . Näiteks:

1. stsenaarium: Kehtiv sisselogimine

Arvestades, et olen abc.com sisselogimislehel


Kui sisestan kehtivad volitused

Seejärel suunatakse mind lehele Minu konto

Nii saate erinevate andmekombinatsioonide testimiseks lisada veel stsenaariume.

Kuna nii lugu kui ka funktsioonifail on kirjutatud kõrgetasemelisest vaatepunktist ja kuna me tahame stsenaariume automatiseerida, näib loomulik alustada kurkides sammude määratluste kirjutamist, mis kutsuvad rakendust juhtima Seleeni, tegema toiminguid ja kontrollige tulemust.


Kuid see on koht, kus probleem ilmneb; kui hakkame seleeni kombineerima kurgiga, et kirjutada automatiseeritud kasutajaliidese teste.

Ausalt öeldes sobivad lihtsatel juhtudel nagu ülaltoodud sisselogimisstsenaarium asjad kenasti kokku ja lähenemine tundub usutav ning tegelikult näib, et enamik näiteid, mida näete Internetis ja mis näitavad seleeni ja kurgi kasutamist, piirduvad kuulus sisselogimisnäide.

Selliste ajaveebide lugejad eeldavad, et nad saavad kasutada lihtsat sisselogimisstsenaariumi ja rakendada sama põhimõtet rakenduse laiemas kontekstis.

Ärge laske end siiski petta, sest reaalses suures veebipõhises rakenduses rakendades võivad asjad seleeni ja kurgiga väga hapuks minna.

Võtame näite tüüpilise e-kaubanduse rakenduse otsingutulemuste lehelt, mis müüb tooteid veebis. Tavaliselt on otsingutulemuste leht täis funktsioone, nagu filtrid, sortimised, toodete loend, otsingu muutmise võime, võime lehitseda või kerimisel automaatselt laadida jne, nagu on näha allolevast ekraanipildist:

Eeldan, et kõik otsingutulemuste lehe funktsioonid lisati saidile järk-järgult, kasutades kiiret arendust.

Rakendades sama lihtsa sisselogimisnäite põhimõtet, on iga funktsiooni väljatöötamisel vastava funktsioonifaili täis palju erinevaid stsenaariume. Näiteks:

Arenduse 1. iteratsioonis töötatakse välja „Filter hinna järgi”, nii et meil oleks selle jaoks funktsioonifail koos oma hinnafiltriga seotud stsenaariumidega.

Arenduse 2. iteratsioonis on välja töötatud „Filter tärnide järgi”, nii et meil oleks selle jaoks funktsioonifail koos oma tärnifiltriga seotud stsenaariumidega ja nii iga uue funktsiooni jaoks.

Oluline on märkida, et iga funktsioonifaili stsenaariumid on spetsiifilised ainult nende vastavate funktsioonide jaoks. Tegelikult kutsutakse neid seetõttu funktsioonifailid sest keskendutakse individuaalsed tunnused .

Nagu varem mainitud, saame rakenduse lihtsuse korral üle elada väljakutse automatiseerida kasutajaliidese stsenaariumid seleeni ja kurgiga. Kuid kui rakendus kasvab ja uusi funktsioone lisatakse, tekib keerukus, kuna erinevate funktsioonide vahel võib olla sõltuvusi.

Näiteks võisin kõigepealt filtreerida oma otsingutulemused hinna järgi ja seejärel rakendada tärnide jaoks teist filtrit. Ah ... meil on nüüd probleem!

Millist funktsioonifaili peaks see stsenaarium nüüd minema? Kas failis „Filtreerimine tärnide järgi” või „Filtreerimine hinna järgi”? Kuidas oleks, kui lisan nüüd stsenaariumi, et rakendada filtreeritud tulemustele sortimist, et sortida kõige rohkem hääli?

Milliseid funktsioonifaile ta peaks uurima, kui mõni huvirühm soovib teada saada, milline on meie testide katvus? Kas ta saab stsenaariumi kajastamise täieliku pildi, lugedes ainult ühte funktsioonifaili või peaks ta lugema kõiki funktsioonifaile?

Arendamise ajal, kui iga funktsiooni arendatakse ükshaaval igas iteratsioonis, oleksid funktsioonifailid keskendunud iseärasusele, nii et ühel hetkel, kui meil on mitu funktsiooni, peame hakkama mõtlema nende testimisele, mitte ainult eraldi, vaid ka loomingulised stsenaariumid, kus me ühendame erinevaid funktsioone.

Ja tegelikult teevad seda rakenduse tegelikud kasutajad. Esmalt sisestavad nad oma otsingukriteeriumid, kui nad on otsingutulemuste lehel, siis nad võivad lehitseda, seejärel filtreerida, siis sortida, siis tagasi minna ja nii edasi ning nad saavad neid toiminguid teha mis tahes järjekorras. Ettenähtud sündmuste järjekorda ei toimu. See on tõeline kasutaja teekond ja tõeline süsteemi test!

Suurem osa rakenduse vigadest on paljastatud, kui funktsioon ise on lollakas või kui kaks funktsiooni, mis töötavad täiesti eraldi, ei tööta koos. Sellel põhineb paarikaupa testimise mudel.

Niisiis, mis on seleeni ja kurgi koos kasutamisel suur probleem?

Kui vähegi võimalik, ei tohiks me funktsionaalseks kontrollimiseks kasutada veebi GUI-d. Funktsiooni funktsionaalsust tuleks testida API-kihil integreerimistestide abil.

Kasutajaliides peaks olema reserveeritud ainult kasutaja voogude kontrollimiseks rakenduse kaudu või lõpptestide jaoks ning veendumaks, et lehel on asjakohased oodatavad moodulid või vidinad, kui kasutaja liigub ühelt lehelt teisele.

Tüüpiline kasutajateekond tähendaks järgmist:

1 - liikuge abc.com veebisaidi avalehele

2 - toote otsimine kodulehelt

3 - sirvige otsingutulemite loendit

4 - Rakenda filter ja / või sorteeri

5 - Lugege toote üksikasju

6 - lisage toode ostukorvi

7 - jätkake maksmist…

Seleen on nende stsenaariumide automatiseerimisel ja igal lehel erinevate elementide kontrollimisel suurepärane. Nagu eespool mainisin, peaksime sellele keskenduma kasutajaliidese kihil testimisel ja erinevate olekute üleminekute testimisel.

Nagu näha, puudutab iga kasutaja teekond läbi rakenduse paljusid lehti ja võib-olla interakteerub igal lehel mitme funktsiooniga ning me kontrolliksime kogu reisi jooksul igal sammul erinevaid asju, nii et funktsioonifail nende stsenaariumide dokumenteerimiseks pole absoluutselt mingit mõtet, sest me ei testi funktsiooni, vaid integreeritud süsteemi.

Asjad lähevad tõesti pirnikujuliseks, kui proovime kirjutada otsast lõpuni stsenaariumid vormingus Arvestatud-millal-siis. Mitu Givensit meil on? Mitu kümmet meil on?

Võib väita, et otsast lõpuni testide jaoks võiksime seleeni lihtsalt kasutada ilma kurgita ja iga seleeni ja kurgi abil saaksime iga funktsiooni jaoks eraldi automatiseeritud testid. Jällegi, ma ei soovita seda lähenemist, kuna teil on tõenäoliselt duplikaatkatseid ja me teame, kui aeglased ja rabedad on kasutajaliidese testid, seega peaksime püüdma, et neid oleks vähem ja mitte rohkem! Pealegi peate ikkagi tegelema funktsioonisõltuvuse testidega.

Kokkuvõte

Kurk on suurepärane vahend funktsiooni käitumise kontrollimiseks API-kihil koos integreerimistestidega, kus iga funktsiooni saab põhjalikult testida. Seda tööriista tuleks kasutada lugude testimiseks.

Seleen on suurepärane tööriist kasutajaliidese kihtide kasutajate stsenaariumide automatiseerimiseks ja süsteemi kui terviku käitumise kontrollimiseks, hõlmates paljusid kasutajalugusid.

Kui jõuame süsteemiintegratsiooni testimise või kasutajaliidese testimise juurde, on kõige parem kasutada seleeni ilma selle aluseks oleva kurgi raamistikuta, sest proovides kirjutada kurgi funktsioonifaile kasutajate teekondade jaoks, võib see muutuda väga tülikaks ja ei teeniks tööriista ülesannet.

Minu artikkel põhineb faktide järeldamisel!

  • Kui kurgi kasutamisel on väärtust, on see funktsiooni tasemel.
  • Funktsiooni funktsionaalsuse kontrollimine on kõige parem väljaspool kasutajaliidest, nt. API testid.
  • Isegi API kihtide testides ebaõnnestub kurk tohutult.
  • Kasutajaliidese testid peaksid hõlmama kasutaja / ettevõtte stsenaariume ja mitte üksikuid funktsioone.

Kurk töötab suurepäraselt testide ja stsenaariumide lihtsustatud ja naiivse vaatega, näiteks kõigi lemmik sisselogimisfunktsioonidega.

Arvestades, et olen sisselogimislehel
Kui sisestan kehtivad volitused
Siis peaksin oma kontot nägema

Kuid kõik asjatundlikud testijad teavad, et isegi lihtsal sisselogimisfunktsioonil on palju kontrollimisi. Proovige need tšekid kurgis teisendada.

See on ainult sisselogimiseks; proovige kirjutada kurgiga otsast-lõpuni test!

Kasutajaliidese testid peaksid hõlmama kasutajate reise, mis on tavaliselt otsast lõpuni ja kasutavad rakenduse mitut funktsiooni.

Ühe kasutaja rännakul kogu rakenduses toimub palju.

Kurk EI OLE kindlasti õige vahend kasutaja / ettevõtte stsenaariumi testimiseks.