Mida silmas pidada testide automatiseerimisel

Automatiseerimiseks sobivaimad testid on tavaliselt sellised, mis testivad suhteliselt lihtsaid ning sirgjoonelisi stsenaariumeid, kuid mis käsitsi jooksutades liigselt aega kulutavad. Automaattestid on väga head selliste ülesannete jaoks, mida inimene kas ei saa või lihtsalt ei taha käsitsi testida.

Automaatselt testitav funktsionaalsus ei tohiks olla habras ning liigselt sõltuv testi käivitamisele eelnevast olukorrast ning testi lõpptulemusest. Kui tarkvara mõne osa testimise automatiseerimine on liiga keeruline, nende testide haldamine aja- ning ressursimahukas, ning lõpptulemusena käsitsi testimisega võrreldes olulist võitu ei saavutata, siis enamustel juhtudel ei tasu selline automatiseerimine ära.

Mis siis oluline on

Testid ei tohiks olla monotoonsed, staatilised. Muuda testi sisendandmeid paindlikumaks, et leida vigu, mis muidu võivad peitu jääda.

Automaattest suudab leida vaid neid probleeme, mille olemasolu või puudumist ta kontrollib. Kui unustada testi sisse kirjutada mingi potentsiaalse veaolukorra kontrollimine, annab test positiivse tulemuse ja võib luua pildi näilisest kvaliteedist – mis aga ei pruugi tegelikkusega ühtida.

Analüüsi automaattestide tulemusi regulaarselt, kasuta saadud infot testide kvaliteedi parandamiseks.

Automaattestide korduv jooksutamine samal tarkvaraversioonil ei pruugi küll oluliselt suurendada testitava tarkvara kvaliteeti, kuid aitab tuvastada vigu ja probleeme testides endis.

Testide loomisel tuleb tavaliselt välja rohkem vigu, kui ainult olemasolevate testide jooksutamisel. Seega täienda olemasolevaid teste ja kirjuta regulaarselt juurde uusi – tarkvara kvaliteedile mõjub see ainult positiivselt.

Automaattestid peaksid olema sellised, et ka arendajad saaks neid lihtsalt jooksutada enne, kui nad oma koodi commitivad.

Testi sisu, omavahelised sõltuvused ja andmed

Reegel number üks – ära ürita testida ühe testiga liiga palju asju korraga! Kirjuta test esmalt ideaalse maailma tingimustele vastavalt, seejärel täienda testi nii, et see suudaks hakkama saada ka väiksemate kõrvalkalletega ideaalist.

Üks test ei tohiks sõltuda mõnest teisest, teste peaks saama käivitada isoleeritult ja ühekaupa. Iga test peaks looma endale vajalikud andmed ise või kasutama testandmeid, mis on loodud enne testide käivitamist arvestusega, et need oleks sobilikud kõigile testidele. Testandmed peaks olema võimalikult lähedased tegelikele andmetele.

Ära kirjuta testiandmeid otse testi sisse, kasuta väliseid andmeid – nii lihtsustad testandmete haldamist. Test peaks olema jooksutatav korduvalt ilma igakordse uute andmete tekitamisete.

Ühe testi ebaõnnestumine ei tohiks blokeerida teiste testide käivitamist. Kui mõnest testist jääb kas ebaõnnestumise või testi iseloomu tõttu maha andmeid, ei tohiks need nö. “jäänukid” mõjutada ülejäänud testide käivitumist.

Kaalu ka data-driven testing metoodika rakendamist.

Veebirakenduste testimisest

Veebirakenduste testimisel kasutatakse veebilehel erinevate elementide leidmiseks üldiselt lokaatoreid – CSS klassid, elementide identifikaatorid, XPath päringud. Lokaatorid peaksid olema võimalikult lühikesed ning määrama elemendi võimalikult üheselt. Eelista võimalusel CSS lokaatoreid, kuna neid on lihtsam lugeda, kui XPath päringuid. Väldi positsioonilisi päringuid (näiteks ‘//table/link[3]’), need on tavaliselt väga haprad.

Mingi tegevuse sooritamise järel peaks test alati ootama, kuni antud tegevus on lõppenud, eriti kui kasutatakse Ajax-päringuid. Määra ka limiit, kui kaua maksimaalselt tegevuse lõppemist ootama peaks. Kui rakendusel kulub tegevuse lõpetamiseks kauem, kui ettenähtud limiit, on tegu probleemiga.

Elementide olemasolu enne nende kasutamist ei ole vaja kontrollida. Näiteks andmete sisestamisel vormi ebaõnnestub test sisestamisel, kuna oodatud tekstivälja ei leitud. Kui selle tekstivälja olemasolu enne sisestamist kontrollida, ebaõnnestuks test lihtsalt samm varem. Lõpptulemusena ei muutu mitte midagi, kuid kontrolli ärajätmisega tuleb kirjutada vähem koodi.

Kontrolli aga tulemust alati peale mõne tegevuse sooritamist. Näiteks kui salvestasid mõne vormi sisu, kontrolli, et sisestatud andmed ka salvestati.

Lõpetuseks

Käivita iga testi mitu korda erinevates tingimustes enne, kui testi versioonikontrolli commitid. Nii uusi kui muudetud teste tuleks sel viisil testida.

Kui testi automatiseerimine on liiga keeruline, on tihti mõistlikum jätta see manuaalseks. Tõenäoliselt ei saa väga lihtsalt automatiseerida ka selliseid teste, mis peaksid pikalt ootama mõne taustaprotsessi või kolmanda osapoole tegevuse järel.

Kõiki automaatteste tõenäoliselt ei pea jooksutama igakordse buildimise käigus, mõned testid jälle pole vajalikud acceptance testimisel. Jaota testid üksteisest sõltumatult käivitatavateks kogumiteks.

Lõpetuseks tuleks meeles pidada, et automaattestid ei ole midagi muud kui tarkvara. Automaattestides, nagu igasuguses tarkvaras, võib olla vigu, need võivad olla valesti koostatud või puudulikud. Ka automaattestid vajavad testimist ja regulaarset ülevaatust, et püsida aktuaalsena ning täita oma eesmärki. Järgi ka testide automatiseerimisel tarkvaraarenduse häid tavasid, kommenteeri oma teste, tee need teistele arusaadavaks ja lihtsasti kasutatavaks.

Leave a Reply

Your email address will not be published. Required fields are marked *