Wednesday, April 28, 2010

Seminar: testimise automatiseerimine Seleniumiga


27. aprillil toimus Testijate Päeva järelseminar teemal "Testimise automatiseerimine kasutades Seleniumi". Temaatilised ettekanded olid Aqriselt ning Conformiq'lt ning vahepalaks vesteldi vabas vormis osalejaid huvitavatel teemadel. Järgnevalt lühike kokkuvõte sellest, mida räägiti ehk kokkuvõte arutletud teemadest:

Kuidas salvestada ja hallata ekraanipilte? (2 häält)
Seleniumil endal on täiesti standardsed vahendid ekraanipildi loomiseks. Üks variant on lehe source htmli maha salvestamine ja publitseerimine.
Kuid seleniumil on ka meetodid nagu captureEntirePageScreenshot (lehe põhine, töötab ainult Firefoxis) ja captureScreenshot (Operatsioonisüsteemi põhine).

Who write selenium tests? If developer writes Selenium tests, what tester does?
(2 häält)
RIK arvab, et arendajad ei tohiks Seleniumi teste kirjutada, kuna nad on oma koodis kinni ja vigu tuvastavaid teste nad ei leia.
Aqris: kui testcase-d on ette kirjutatud siis võiks arendajad neid kirjutada ja testijad saaksid neid teste täiendada või leida programmis olulisemaid vigu.
Conformiq: testid tuleks disainida mudeli põhiselt. Mudeli peaksid tegema arendajad ja testijad koos.

Kuidas otsustada, mida ja kui palju tasub automatiseerida? (2 häält)
Agiilses arenduses: kõrge prioriteediga acceptance testid (prioriteedi ütleb klient, äripool)

Tavaline arendus, jätkuprojekt: salvestada staatilised testid ja need taaskäivitada. Stabiilsed võtta testidena sisse.


Kuidas paremini organiseerida/üles ehitada testide struktuuri? (3 häält)
Testide loomisel tuleb kasutada helperklasse, tegelikud testide väljakutsed on lühikesed, kogu töö tehakse helperklassides. Koodi haldamine on siin oluline.
Testide loomisel on variant kasutada ka PageObjects metoodikat (http://code.google.com/p/selenium/wiki/PageObjects).
Testide struktureerimiseks võib kasutada ka raporteerimise vahendeid. Näiteks kasutada Java-s koodi annoteerimist ja selle läbi ette anda nii testi andmeid kui ka defineerida testi eel- ja järeltegevusi. TestNG võimaldab sellist lähenemist.


Millises agiilse arenduse etapis tasuks hakata teste automatiseerima? (4 häält)
Sõltub projektist ressurssidest. Kui klient nõuab siis muidugi tuleb igal juhul kirjutada.

Kui järgida test-driven developmenti siis tuleks testid kirjutada juba prototüüpimise faasi (kui see faas on olemas). Kui prototüüpimist ei toimu, siis tuleb ikkagi oodata kuni on valmis vähegi stabiilsem keskkond.

Kui prototüüpimist ei ole siis võiks eesmärk olla: ASAP (as soon as possible), reaalsuses tuleb aga kuskil sprintide vahepeal, kui keskkond on natuke stabiliseerunud.
Andres: kui sprintide käigus tehakse kräppi koodi siis ei ole mõtet teste kirjutada.

Toodi välja probleem: kui automatiseerida teste sprintide lõikes siis läheb asi käest, ei jõua enam. Testide arendamise tuleb ka aega varuda ja planeerida sprindi sees.
Probleemiks: on ka testide muutmine, võib minna aina aja kulukamaks. (Tuleks üle vaadata testide disain?)

Idee: testijad võiksid arendajatega koos paika panna elementide id-d. Nii saaks testija juba varakult kokkulepitud id-dega hakata teste kirjutama.


Testi raportid (11 häält)
How to create human-readable test report? (5 häält)
Milliseid vahendeid paremini kasutada Seleniumi testraportite loomiseks? (3 häält)
Testide astmelisus (testcase, test, testsuite) (3 häält)

Vahendid, mida kasutatakse raporteerimiseks:
EMT - kostümeeritud testng, mis võimaldab luua veebipõhiseid raporteid. Lisaks võimaldab vahend komplekteerida test suite ja testide järjestusi. TestNG-ga saab realiseerida ka data-driven testimist ehk kui testis assert ebaõnnestub siis võetakse testi andmete failist uus test koos testandmetega.

RIK
kasutab isetehtud framework, mis töötab anti peal. Ant võtab sisse testsuite-i ja genereerib custom xslt template alusel vajaliku arusaadava raporti.
Mõned mõtted siia frameworki juurde:
  • testsuite, testcase (1 class file per testcase), tests - selline peaks olema tegelik struktuur, testide astmelisus
  • Vaikimisi on nii: testsuite, tests, testcases
  • Tuleks hallata ainult testide struktuuri (testid ise on viidud helper klassidesse) – nii oleksid testide koostamine justkui legomäng, kus vajalikud tegevused pannakse kokku eri klotsidega ja edaspidiselt on vaja mitme või mitmekümne testi haldamiseks muuta vaid üht/mõnd klotsi - kui miski testitavas süsteemis peaks muutuma.
  • Kui testimiseks on kasutatav vaid IE siis peab kahjuks iga testija oma valgete kätega kõikide elementide ID´d ise sisestama (kas siis otse testi või helper klassidesse - olenevalt testija testsüsteemi keerukusest)
  • Iga test loob oma algandmed käivitamata eeltingimuste täitmisel kontrolle - igal klotsil on vastav väli, mis ütleb kas on tarvis selle klotsi puhul teha ka kõik kontrollid või tuleb eeltingimustena selle klotsi tegevused teha ilma põhjalike kontrollideta, lisaks toimub testi jooksmisel kontrolltingimuste ja eestikeelsete veateadete kogumine, kontrollid viiakse läbi alles testi lõpus, siis kui kõik tegevused on tehtud, testide kontrolltingimused on seotud ID´dega (mitte elementide ID´d vaid kontrollidel on oma ID´d mida saab testdokumentatsiooni lihtsalt nummerdada))
Ruby ja Rspec:
Rspec suudab genereerida vaikimisi juba väga häid raporteid. Raportites on vaikimisi vea korral olemas lehe html source, screenshot, diff ja kui testi käigus salvestati mingi fail siis ka see on testi juures kätte saadav.

Lauda jäänud küsimused/probleemid
  • Selenium ja threadid
  • Kiiruse probleemid
  • IE salvestaja (nagu on Firefoxil)?
  • Seleniumi crashi mure (ei lasta sessiooni kinni)
  • Paroolide salvestus faili ning nende lugemine
  • Mingid characterid on sisestamatud/trükitamatud
  • Selenium startup akna mõõdustamine (FIXED-SIZE)
  • Millised on levinumad probleemid, mis on ette tulnud? Kuidas neid lahendati? Kas on teadaolevaid lahendamata probleeme seotud Seleniumiga?
  • Kas Seleniumiga saab mõõta CPU ja mälu kasutust? Kas saab ette kirjutada veebilehel navigeerimise stsenaariumi?
  • Kuidas võiks olla testimise protsess üles ehitatud automatiseeritud testimise korral? Millest võiks alustada?
  • Kuidas kõige paremini disainida testide kogum (testsuite)? (töömaht ja selgus loomisel ning muutmised oleksid minimaalsed)
  • Millised võivad olla põhjused, et test kord jookseb läbi ja siis jälle annab vea?
  • Mis vahe on FFPluginil (IDE) ja RC vahel? (funktsionaalsus, näiteks kui ma tahan testida ainult FF browseris)
  • Faster test runs
  • Kuidas on äripool (klient) rahul automaatsete testide koostamise kohustusega ning kuidas nad hakkama saavad (Kui tihti satuvad probleemide otsa)?

No comments: