Tänu veebisaitide ja rakenduste ülemaailmsele levikule on kasutajaliidese testimine tähtsam kui kunagi varem. Kui te võtate kasutusele uue tarkvara või veebilehe, on väga oluline, et kasutajaliides (UI) oleks õige, et tasakaalustada funktsionaalsust ja esteetikat.
Palju on vaja selleks, et luua veenev kasutajaliides, kusjuures kasutajaliidese testimine on lakmuspaberitest, mille abil saab kindlaks teha, kas kasutajaliides vastab kõigile nõuetele või mitte.
Selles artiklis käsitleme kõiki peamisi kasutajaliidese testimisega seotud valdkondi, alates kasutajaliidese määratlemisest kuni kasutajaliidese testimise parimate viisideni.
Kasutajaliides vs. graafiline kasutajaliides: Segaduse klaarimine
Alustuseks püüame klaarida mõistete UI ja GUI ümber tekkinud segadust. Allpool on esitatud nende kahe termini tähenduse ja nende erinevuste kirjeldus:
1. Mis on kasutajaliidese testimine?
Kasutajaliides ehk UI on platvorm, mida kasutate teatava tarkvaraga suhtlemiseks. Kasutajaliides on koht, kus võite sisestada juhiseid, sisestada andmeid või vaadata teavet ekraanilt või monitorilt.
On olemas palju erinevaid kasutajaliidese tüüpe, sealhulgas graafilised kasutajaliidesed (GUI) ja käsurea liidesed, mis lihtsalt näitavad koodi ja teksti.
2. Mis on graafiline kasutajaliides (GUI)?
Graafiline kasutajaliides (GUI) on kasutajaliidese tüüp, mida enamik inimesi tunneb. See on kasutajaliidese tüüp, mis kasutab visuaalseid elemente, et aidata meil süsteemi funktsioonidega suhelda.
Näiteks võite kasutada menüüsid või tööriistaribasid, mis sisaldavad ikooni, et aidata teil süsteemis navigeerida. Isegi tekst töötab graafilises kasutajaliideses hästi, et juhendada kasutajat mõne funktsiooni kaudu, näiteks klõpsates “fail”, kui soovite avada või salvestada dokumenti.
3. Kasutajaliides vs. graafiline kasutajaliides
Et aidata teil paremini mõista neid kahte arvutiga suhtlemise vormi, vaadake allpool toodud otsest võrdlust UI vs. GUI vahel:
UI:
– Kasutajaliidese lühend
– See on teatud tüüpi platvorm, mis võimaldab kasutajatel suhelda seadmetega
– See on inimese ja masina vahelise suhtluse vorm.
– Seda kasutavad kõik ja see töötab sageli taustal, nii et te ei tea, et te seda kasutate.
– Tavalised näited on MS-DOS või Unix
GUI:
– Graafilise kasutajaliidese lühend.
– See on platvormi tüüp, mis kasutab graafikat, et aidata kasutajatel seadme funktsioonides navigeerida.
– See on UI alamklass
– Seda kasutavad tavaliselt keskmised, igapäevased kasutajad, näiteks tarbijad.
– Tavalised näited on Windows 10, iOS ja Android
Mis on kasutajaliidese (UI) testimine?
Kasutajaliidese (UI) testimine, mida mõnikord nimetatakse sõltuvalt kontekstist ka GUI testimiseks, on rida tegevusi, mida kasutatakse rakenduse visuaalsete elementide jõudluse ja üldise funktsionaalsuse mõõtmiseks. Selle eesmärk on kontrollida ja valideerida kasutajaliidese erinevaid funktsioone ning tagada, et ei esineks ootamatuid tulemusi, defekte ega vigu.
Kasutajaliidese testimist selliste tööriistade abil nagu ZAPTEST kasutatakse peamiselt selliste asjade nagu kasutatavus, funktsionaalsus ja kasutajaliidese jõudlus kontrollimiseks, et veenduda, et see on eesmärgipärane.
Mõnel juhul kontrollitakse ka selliseid asju nagu vastavus või visuaalne ühtsus süsteemi üldisele disainikontseptsioonile.
Millal ja miks on vaja kasutajaliidese teste?
Kasutajaliidese testimine on tavaliselt kõige tõhusam enne rakenduse tootmisse laskmist. Selle eesmärk on tagada lõppkasutajale parim kogemus, võimalikult väheste vigade ja defektidega.
Lõppkasutajad ei ole parimad tarkvara testijad, seega on oluline lahendada kõik probleemid enne, kui see jõuab nende juurde.
Kasutajaliidese testimine on kasulik viis hinnata, kuidas rakendus käitub teatud toimingutega, näiteks klaviatuuri ja hiirega menüüdega suhtlemisel. See aitab kontrollida rakenduse visuaalseid elemente, et tagada nende korrektne kuvamine.
Kasutajaliidese testimine on ka suurepärane võimalus mõõta jõudlust ja veenduda, et rakenduse funktsionaalsuses ei ole vigu või probleeme.
Kasutajaliidese testide tüübid
Sõltuvalt testitavast rakendusest tuleb kaaluda erinevaid UI-teste.
Kasutajaliidese testidega on võimalik kontrollida paljusid funktsioone rakendustes, seega võib õige testitüübi valimine aidata tuvastada konkreetseid probleeme.
Teisisõnu, sõltuvalt sellest, mida te kavatsete testida, on olemas erinevad kasutajaliidese testimise meetodid ja tööriistad, nagu ZAPTESTi automatiseeritud kasutajaliidese testimise tööriistad.
Mõned kõige levinumad funktsionaalse ja mittefunktsionaalse testimise meetodid on järgmised:
1. Regressioonitestimine
Regressioonitestimine on kasutajaliidese testimise liik, mille käigus vaadeldakse kõiki muudatusi rakenduse või veebisaidi kodeerimises.
See tagab, et kogu rakenduse funktsionaalsus on pärast muudatuste tegemist koodi osades nii, nagu see on ette nähtud.
See ei pea tegema mingeid väljamõeldud teste, vaid lihtsalt käivitab koodi, et veenduda, et kõik sõltuvused ja funktsioonid töötavad samamoodi nagu enne muudatuste tegemist.
2. Funktsionaalne testimine
Funktsionaalsete testide eesmärk on kontrollida, kas rakendus vastab kõigile funktsionaalsetele nõuetele.
See testib kõiki rakenduse üksikuid funktsioone ja kontrollib seejärel tulemust, et veenduda, et see töötab ootuspäraselt.
Seda tüüpi kasutajaliidese testimine keskendub tavaliselt musta kasti testimisele, mis ei vaata ühtegi lähtekoodi. See kipub kontrollima selliseid asju nagu kasutajaliides, kõik seotud APId, kliendi ja serveri suhtlus või turvalisus.
3. Vastuvõtukatsetused
Vastuvõtutestimine, mida mõnikord nimetatakse ka kasutaja vastuvõtutestimiseks (User Acceptance Testing, UAT), on kasutajaliidese testimise vorm, mille viib läbi rakenduse lõppkasutaja, et kontrollida süsteemi enne tootmisesse üleminekut.
Seda tüüpi kasutajaliidese testimine toimub kõige sagedamini testimise lõppfaasis, kui muud valdkonnad on kontrollitud.
Vastuvõtutestimist kasutatakse rakenduse üldise voolu valideerimiseks algusest lõpuni. See ei uuri pinnapealseid probleeme, nagu õigekirjavead või esteetilised probleemid. See kasutab eraldi testimiskeskkonda, et jäljendada tootmiskeskkonda, tagades, et see on valmis järgmisele etapile üleminekuks.
4. Üksuse testimine
Ühiktestimise eesmärk on kontrollida rakenduse üksikuid komponente, et veenduda, et see töötab nii, nagu on ette nähtud.
Tavaliselt viiakse see läbi kodeerimisfaasis, nii et tavaliselt on seda tüüpi kasutajaliidese testi tegemine arendajate ülesanne.
Ühiktestimine toimib koodi eraldamise teel, et veenduda, et see töötab ootuspäraselt. See konkreetne kooditükk võib olla konkreetne moodul, funktsioon, objekt või mõni muu rakenduse osa.
5. Tulemuslikkuse testimine
Jõudlustestimise eesmärk on hinnata rakenduse optimeerimist, uurides selliseid asju nagu kiirus, stabiilsus, reageerimisvõime ja rakenduse skaleeritavus kasutamise ajal.
Seda tüüpi kasutajaliidese testimise eesmärk on leida rakenduses probleemseid kohti või kitsaskohti andmevoos. Kolm peamist valdkonda, mida see vaatab, on rakenduse kiirus, skaleeritavus ja stabiilsus.
6. GUI testimine
GUI-testimise vahendid kontrollivad rakenduse graafilist kasutajaliidest, et veenduda, et kõik funktsioonid toimivad ootuspäraselt.
See hõlmab ka rakenduse graafiliste vahendite ja juhtimisseadiste, näiteks nuppude, tööriistaribade ja ikoonide vaatamist. Kasutajaliides on see, millega lõppkasutaja rakenduse kasutamisel suhtleb ja mida ta näeb.
Millised on kasutajaliidese testimise eelised?
Kasutajaliidese testimine ja selliste tööriistade nagu ZAPTESTi kasutajaliidese testimise pakett on kasulik nii arendajale kui ka lõppkasutajale.
Allpool on toodud mõned peamised kasutajaliidese testimisega seotud eelised:
1. See parandab funktsionaalsust
Oluline on testida rakendusi, et tagada nende ootuspärane toimimine, nii et kui esineb tõrkeid, vigu või muid probleeme, saab need enne avaldamist kõrvaldada.
Kui rakendus jõuab lõppkasutajateni ja see on vigane, täis vigu või katki, siis ei tee see seda tööd, mida temalt oodatakse. See omakorda tekitab lõppkasutajatele liiga palju probleeme ja nad lõpetavad tõenäoliselt selle kasutamise.
2. See lihtsustab kasutamist
UI testimise automatiseerimisvahendid on samuti kasulikud rakenduse optimeerimiseks ja sujuvamaks muutmiseks.
Isegi kui kogu kodeerimine töötab nii, nagu peaks, võib halvasti kujundatud kasutajaliides lõppkasutajaid segadusse ajada ja nad kiiresti välja lülitada, vähendades rakenduse kasutuselevõtu määra. Kasutajaliidese testimine on suurepärane võimalus siluda mis tahes elemente või disainivalikuid, et seda oleks lihtsam kasutada.
3. See tugevdab rakenduste mainet
Kui võtate aega, et teostada korralikult kasutajaliidese testimist ja võtta kasutusele sellised vahendid nagu ZAPTESTi testimise automatiseerimise tarkvara, on see suurepärane võimalus rakenduse lihvimiseks ja selle võimalikult kasutajasõbralikuks muutmiseks.
Kui seda tehakse õigesti, teeb see rakendusest suurepärase brändi saadiku, mis suurendab selle üldist mainet. Kui rakendus töötab veavabalt ja teeb kõike, mida ta peaks tegema, siis kasutajad hindavad seda ja kasutavad seda rakendust.
Millised on kasutajaliidese testimise peamised väljakutsed?
Kuigi kasutajaliidese testimine on oluline osa rakenduse arendamisest, ei ole see tingimata lihtne osa protsessist.
Tasuta UI testide automatiseerimise tarkvaraga on seotud mitmeid probleeme ja väljakutseid, mis muudavad selle töö keeruliseks.
Allpool on toodud mõned peamised probleemid, mis on seotud kasutajaliidese testimisega, kui kasutatakse ebapiisavaid kasutajaliidese testimise vahendeid:
1. Kasutajaliidese uuendused
Rakenduse arendamine on tavaliselt iteratiivne protsess, mis toob uusi funktsioone ja funktsioone kogu arendustsükli jooksul ja ka pärast seda.
Kõik need sporaadilised muudatused võivad muuta kasutajaliidese testide tõhusa läbiviimise üsna keeruliseks, kuna muud sõltuvused ja koodi koostoimed muudavad testitavat.
2. Testimine, mis muutub üha keerulisemaks
Rakendused ja veebisaidid on nüüd palju keerulisemad kui isegi mõned aastad tagasi. Kogu selle lisafunktsionaalsuse tõttu peavad kasutajaliidese testimise tööriistad ja kasutajaliidese automatiseerimise tarkvara uurima rohkem elemente ja protsesse.
Selle tulemusena tuleb paljusid kasutajaliidese testimise vahendeid kohandada, et need kõik need keerulised täiendused ära mahutada.
3. Ajalised piirangud
Rakenduste keerukuse kasvades kasvavad ka testimiseks kasutatavad vahendid. Kasutajaliidese testimise skriptid muutuvad palju aeganõudvamaks, kuna testitava koodi maht on väga suur. See probleem süveneb veelgi, kui õiged kasutajaliidese testimise vahendid ei ole kättesaadavad.
4. Kasutajaliidese skriptide ajakohastamine
Kui kasutajaliides muutub ja lisandub uus funktsionaalsus, tuleb testiskripte kohandada, et testida uusi protsesse. See muutub iga uue lisandumisega keerulisemaks, sest testiskripte uuendatakse ja kohandatakse pidevalt, et need vastaksid uutele funktsioonidele.
Kas peaksite kasutajaliidese testimist automatiseerima?
Kui tuleb otsustada, milline on parim lähenemisviis rakenduse või veebi kasutajaliidese testimisele, on kaks erinevat teed, mida kaaluda – käsitsi testimine või automatiseeritud kasutajaliidese testimine automatiseeritud tööriistade abil. Nii manuaalsel testimisel kui ka kasutajaliidese automatiseerimisel on omad eelised ja puudused, seega on mõistlik kaaluda mõlemat, et näha, milline neist sobib rakendusele kõige paremini.
Mis on manuaalne kasutajaliidese testimine?
Käsitsi testimine, erinevalt kasutajaliidese automatiseerimisest, hõlmab testija kasutamist, et käsitsi suhelda ja kontrollida kõiki rakenduses või veebisaidil esinevaid funktsioone.
Nende esmane eesmärk on kontrollida, kas kogu taotluses esineb küsimusi, eeskirjade eiramisi või probleeme. See on eriti kasulik võimalus väiksemate, piiratud elementidega rakenduste puhul, nagu need, mida leidub rakenduste varajastel versioonidel.
1. Kasutajaliidese käsitsi testimise eelised
Sõltuvalt rakendusest ja selle ülesehitusest on UI käsitsi testimise valikul palju eeliseid.
Allpool on toodud mõned kasutusliidese käsitsi testimisega seotud eelised:
– Manuaalne kasutajaliidese testimine hõlmab inimintellekti, et otsida vigu või probleeme. On asju, mida automatiseeritud kasutajaliidese testimine lihtsalt ei suuda ning kõigi rakenduse puuduste leidmiseks on vaja inimlikku suhtlemist, kriitilist mõtlemist ja inimlikku elementi.
– Automatiseeritud testid võivad olla üsna aeganõudvad, kuna nad loovad uuesti mitu stsenaariumi erinevate funktsioonide jaoks, mida peab kontrollima inimtester. Manuaalne kasutajaliidese testimine võimaldab inimtestijatel keskenduda pigem vigade leidmisele kui emulatsioonide loomisele.
– Inimtesterid tunnevad rakendust tavaliselt väga hästi, kulutades sageli lugematuid tunde, et harjuda kasutajaliidesega. Tänu sellele saavad nad aru, mida tuleb vigade osas tähele panna, aidates neil samal ajal rakenduse hetkeseisuga kursis olla.
– On probleeme, mida automatiseeritud kasutajaliidese testimine ei pruugi märgata, kuna see ei mõjuta koodi. Sellised asjad nagu serveri reageerimisaeg võivad olla aeglustunud, kuid automatiseeritud test võib neid kergesti tähelepanuta jätta. Manuaalne kasutajaliidese testimine kõrvaldab selle probleemi, sest inimkasutaja märkab neid probleeme kohe.
– Manuaalne kasutajaliidese testimine on kõige täpsem kasutajakogemuse emulatsioon, kuna te loob olukorra, mis peegeldab seda, kuidas lõppkasutaja rakendusega suhtleb. See loob reaalse konteksti, et leida probleeme, mida lõppkasutajad tavaliselt leiavad, kuid mis võib-olla jäävad automatiseeritud kasutajaliidese testimisel tähelepanuta.
2. Manuaalse kasutajaliidese testimise piirangud
Manuaalsel kasutajaliidese testimisel on ka piiranguid, mida tuleks arvesse võtta enne otsuse tegemist, milline on teie rakenduse jaoks parim testimisviis.
Mõned manuaalsete kasutajaliidese testide piirangud on järgmised:
– Käsitsi testimine võtab palju kauem aega kui automatiseeritud kasutajaliidese testimine, eriti kui kasutatakse selliseid kaasaegseid vahendeid nagu hüperautomaatika. Automatiseeritud testimise skriptid võivad töötada palju kiiremini kui mis tahes tüüpi inimsisend, nii et käsitsi veebi kasutajaliidese testimise valimine lisab ajakavale lisatunde.
– Kuna tegemist on lõppkokkuvõttes inimliku protsessiga, on käsitsi teostatav veebi kasutajaliidese testimine altis inimlikele vigadele. Manuaalse kasutajaliidese testimise puhul võib juhtuda, et vigu jääb tähelepanuta, kuna ei ole piisavalt keskendutud või on tähelepanu hajutatud, mis võib põhjustada probleeme. Võrdluseks, automatiseeritud kasutajaliidese testimine eemaldab protsessi inimliku elemendi, muutes selle palju vähem vastuvõtlikuks sellistele probleemidele. See kehtib eelkõige uusimate kasutajaliidese automatiseeritud testimise liikide, näiteks robotiseeritud protsesside automatiseerimise kohta.
– Leitud vigade tegelik logimine võtab palju kauem aega, mis võib muuta muutuste jälgimise raskeks. Automaatne kasutajaliidese testimine on siinkohal parem lähenemisviis, sest see nõuab uuendamist ainult siis, kui uus funktsioon on rakendatud.
– Manuaalne kasutajaliidese testimine nõuab rakenduse põhjalikku tundmist, et testida probleeme kompetentselt. Selle tulemusel on inimtestijatel vaja teatavat teadmiste taset, enne kui nad saavad tõhusalt testida. Automatiseeritud testimine ei nõua sellist teadmiste taset.
3. Salvestamine ja korduvkatsetamine
Record & replay testimine on koodivaba UI testimise vorm, mis võimaldab teil teste käivitada ilma sügavate programmeerimisoskusteta. See kasutab funktsionaalsust, et salvestada rakenduses tehtud käsitsi tehtud toimingud enne nende salvestamist testimustrina.
See võimaldab UI-testi uuesti ja uuesti läbi viia ilma inimese osaluseta.
4. Manuaalne vs. salvestamine ja kordamine vs. automatiseeritud testimine
Nende kolme kasutajaliidese testimise tüübi vahel otsustamisel on oluline arvestada rakenduse ulatust ja ulatust ning olemasolevaid ressursse.
Manuaalset kasutajaliidese testimist on kõige lihtsam luua ja kasutada, kuid see eeldab palju nõudeid, näiteks testija häid teadmisi rakendusest. Samuti on raske jätkata käsitsi kasutajaliidese testimist, kui rakendust pidevalt uuendatakse.
Kasutajaliidese testimise automatiseerimise tööriistad, nagu Zaptest pakub, on suurepärane võimalus, kui kavatsete rakendust regulaarselt uuendada, ja aja jooksul tasub see end ära.
Record & replay on mõeldud selleks, et ületada lõhe kahe kasutajaliidese testimise tüübi vahel. See pakub põhitasandil kasutajaliidese automatiseerimist, kuid nõuab siiski inimese panust selle käivitamiseks.
Mida te testite kasutajaliidese testide läbiviimisel?
See, mida te testite, kui te kasutate selliseid vahendeid nagu ZAPTESTi kasutajaliidese testimise tarkvara, sõltub sellest, mida rakendus sisaldab.
See kipub siiski järgima rakenduse funktsionaalsust. Näiteks kui rakendusel on kassalehekülg, hõlmab kasutajaliidese testimine selliseid asju nagu “osta kohe” nupu testimine.
Kuigi tegelikud protsessid, mida testida, on rakenduste lõikes erinevad, on olemas mitmeid üldisi UI asju, mida testida, näiteks:
1. Vead andmetüüpides
See kasutajaliidese test tagab, et õiget tüüpi andmed töötavad asjakohastes väljades. Näiteks tekst nimede jaoks ilma numbrite kasutamise võimaluseta. Kui kasutajaliidese testija saab sisestada numbrilisi väärtusi nime väljale, siis on midagi valesti.
2. Välja laiuse küsimused
Seda kasutatakse teatavate väljade, näiteks postiindeksite tähemärkide arvu piiramiseks. Kui rakendus ei piira nende väljade tähemärkide arvu, võib see lõppkasutajalt kaasa tuua vigaseid sisendeid.
3. Nupud
Need kasutajaliidese testid tagavad, et nupud toimivad õigesti, nii et näiteks järgmise lehekülje nupp suunab lõppkasutaja järgmisele leheküljele. On palju erinevaid nuputüüpe, millel on erinevad eesmärgid, seega on oluline, et nad täidaksid oma ülesandeid, et luua toimiv rakendus.
4.Table kerimine
Kui rakenduses on andmeid sisaldavaid tabeleid, tagab tabelite kerimine, et saate andmeid kerida, säilitades samal ajal pealkirjad nähtavad.
Kui see ei toimi, muudab see andmed lõppkasutajale segaseks.
5. Vealogid
Rakenduse krahhi või vea korral on oluline testida vealogisid, et veenduda, et need annavad täpse tulemuse veateadete jaoks.
Ilma täpse veateate ja veaprotokollideta ei ole võimalik kindlaks teha, mis probleemi põhjustab või kuidas seda parandada.
Kuidas teostada UI (GUI) testi?
Et anda teile hea ettekujutus sellest, kuidas teostada UI- ehk GUI-testi, loome teile näite, mida vaadata.
Oletame, et testime rakenduse vormilehte konto registreerimiseks. Sellel lehel on mitu testitavat kasutajaliidese elementi, mis on märgistatud TC-X (kus TC tähistab testjuhtumit ja X tähistab elemendi numbrit).
Allpool on esitatud nimekiri olemasolevatest TC-dest:
TC-1: kaubamärgi logo ekraani ülaosas
– Seda tuleks testida, et kontrollida, kas see kuvab õiget asendit, kirjatüüpi ja lehekülje märgistust.
TC-2: Registreeri oma konto
– See peaks kontrollima, et lehekülje päis oleks täpne.
– Samuti peaks see kontrollima, et kuvatakse õiget kirjastiili.
TC-3: eesnime väli
– See peaks testima tekstikasti õiget joondust ja asendit.
– Samuti peaks see testima väljade sildid ja kontrollima, et see aktsepteerib kehtivaid ja keeldub kehtetutest kannetest.
TC-4: perekonnanime väli
– See peaks testima tekstikasti õiget joondust ja asendit.
– Samuti peaks see testima väljade sildid ja kontrollima, et see aktsepteerib kehtivaid ja keeldub kehtetutest kannetest.
TC-5: Kasutajanime väli
– See peaks testima, milline veateade kuvatakse piiratud tähemärkide sisestamisel.
– Samuti peaks ta kontrollima, et veateade oleks kehtiv ja täpne.
TC-6: Salasõna väli
– See peaks testima väljade sildid, et veenduda, et see aktsepteerib kehtivaid sümboleid ja lükkab tagasi kehtetud sümbolid.
– Samuti peaks see testima tekstikasti joondamist ja asendit.
TC-7: nupp järgmisele lehele
– See peaks testima, et vormi esitamine toimib nagu ette nähtud.
– Samuti peaks ta kontrollima nuppude paigutust ja veenduma, et see on kasutajale loetav.
UI testi plaan – mis see on?
Kasutajaliidese testimise kava on dokument, mis on osa rakenduste testimisprotsessist.
Kasutajaliidese testimise plaanis on jaotatud põhiteave rakenduse ja kõigi sellega seotud testimistegevuste kohta.
Testimisplaani koostamine on tavaliselt üks esimesi samme, mida rakenduste testimisel tehakse, sest see paneb aluse testimismeetoditele ja kavandatud tulemustele.
See on kasulik dokument, mis annab väljaspool testimismeeskonda asuvatele isikutele parema ettekujutuse sellest, mis protsessis toimub.
Kuidas kirjutada UI testimise kava
Kasutajaliidese testi plaanid pakuvad suurepäraseid juhiseid ja juhiseid kasutajaliidese testijatele, nii et nende õige koostamine aitab rakenduste testimisel ja kontrollimisel väga hästi kaasa.
Vaadake alljärgnevaid samme, et õppida, kuidas kirjutada kasutajaliidese testimise kava:
1. Sisaldab põhiteavet kasutajaliidese testimise kohta.
Kasutajaliidese testimise kava sisaldab kogu olulist teavet, mis on vajalik rakenduse testimise läbiviimiseks. Osa sellest teabest hõlmab järgmist:
– Testimiseks vajalikud spetsialistid, nende rollid ja oskused.
– Rakenduse testimiseks kuluv koguaeg.
– Testimisel kasutatavad katsemeetodid.
– Testimiseks vajalikud ressursid, näiteks spetsiifiline riistvara, dokumentatsioon või tööriistad.
– Sihtkatsekeskkondade, näiteks mobiilseadmete, konkreetse operatsioonisüsteemi või brauserite jaotus.
– Testimisprotsessi üldised eesmärgid.
2. Suitsukatsetused
Järgmisena saate kasutada suitsu testimist, et aidata luua kasutajaliidese testimise kava. Suitsutestimine on kasulik viis rakenduse põhiprobleemide ja vigade tuvastamiseks, kuid see ei otsi probleeme liiga põhjalikult.
See on tehnika, mis sobib kõige paremini rakenduse ülemise kihi kasutajaliidese testimiseks, nii et see võib üsna kergesti tabada silmatorkavaid probleeme.
3. Korrektsuse testimine
Et kaevuda sügavamale rakendusse, et leida vähem ilmseid vigu ja tõrkeid, on kasutajaliidese testimine suurepärane tehnika, mida saab kasutada kasutajaliidese testimiseks.
Korrektsuse testimise käigus kontrollitakse uut või muudetud kodeeringut, et veenduda selle vastavuses rakenduse nõuetega.
See erineb suitsutustestimisest selle poolest, et see on palju põhjalikum, kuna kasutajaliidese testimine võimaldab rakenduse funktsionaalsust sügavamalt uurida.
Pärast seda, kui rakendus on läbinud suitsukatse, lisab sanity test täiendava kontrollitaseme.
UI testimisstsenaariumid
Selleks, et tagada rakenduse eesmärgipärane toimimine mitmes valdkonnas ja interaktsioonis, on oluline viia läbi erinevaid kasutajaliidese testimisstsenaariume.
Järgnevalt on esitatud ülevaade UI testimisstsenaariumide kohta koos näitega.
1. Mis on UI testimisstsenaariumid?
Kasutajaliidese testimisstsenaarium on viis, kuidas luua dokumentatsiooni mitme kasutusjuhu kohta rakenduses.
Kasutajaliidese testi stsenaariumiga kirjeldatakse konkreetseid tegevusi, mida kasutaja võib rakenduse kasutamise ajal teha.
Mõnel juhul kirjeldab see ka stsenaariumi, mida kasutaja võib rakenduse kasutamise ajal kogeda.
Kasutajaliidese testimisstsenaariumid on kasulikud, sest nendega kontrollitakse, kas rakenduse funktsionaalsus toimib ootuspäraselt. Kasulike stsenaariumide loomiseks on vaja rakenduse põhjalikku tundmist ning klientide ja arendajate panust.
2. Näide kasutajaliidese testimisstsenaariumide kohta
Võtame näiteks rakenduse sisselogimislehe testimisstsenaariumi. Kasutajaliidese testistsenaariumiga püütakse vastata järgmistele küsimustele:
– Kas kasutajad saavad platvormile sisse logida, kasutades õigeid volitusi?
– Milline on vale sisselogimise tulemus, kui kasutate valesid volitusi?
– Mis juhtub, kui kasutate kehtivat kasutajanime, kuid kehtetut parooli?
– Mis juhtub, kui jätate väljad tühjaks ja proovite sisse logida?
– Kui on olemas nupp “unustasin salasõna”, mis juhtub, kui te sellele vajutate?
– Kas kõik lehel olevad lingid toimivad nii, nagu on ette nähtud?
Nendele küsimustele vastamine aitab kasutajaliidese testijatel tuvastada kõik rakenduse osad, mis ei tööta nii, nagu peaksid.
Samuti kontrollitakse, et kõik olemasolevad toimingud annavad oodatud tulemuse, näiteks sisselogimine õigete volituste abil.
UI testjuhtumid
Kasutajaliidese testimisstsenaariumi üksikute aspektide vaatlemiseks kasutatakse testjuhtumeid rakenduse funktsionaalsuse üksikute osade funktsioonide lahtiseletamiseks.
Allpool on esitatud kokkuvõte, mis on kasutajaliidese testjuhtumid koos näidetega.
1. Mis on kasutajaliidese testjuhtumid?
Kasutajaliidese testjuhtum on rida tegevusi, mis viiakse läbi konkreetse funktsiooni või funktsionaalsuse kontrollimiseks rakenduses.
Kasutajaliidese testjuhtumid jaotavad konkreetsete stsenaariumide jaoks testimise sammud, andmed, eeltingimused ja järeltingimused ning kontrollivad ka nõudeid.
Kasutajaliidese testjuhtum kipub sisaldama väga spetsiifilisi muutujaid, et võimaldada põhjalikku testimist üksikutel tasanditel. Kasutajaliidese testijad võrdlevad seejärel tegelikke tulemusi oodatud tulemustega, et tagada rakenduse nõuetele vastav toimimine.
2. Näited UI ja GUI testjuhtumite kohta
Et aidata teil paremini mõista UI ja GUI testjuhtumeid, vaadake allpool olevaid näiteid, mis on testjuhtumid testistsenaariumi jaoks, mis vaatleb sisselogimisekraani funktsionaalsust:
– Kontrollige süsteemi käitumist kehtivate volituste sisestamisel.
– Kontrollige süsteemi käitumist, kui kasutatakse kehtetut e-posti aadressi, kuid kehtivat salasõna.
– Kontrollige süsteemi käitumist, kui kasutatakse kehtivat e-posti aadressi, kuid kehtetut parooli.
– Kontrollige süsteemi käitumist, kui kasutatakse kehtetut e-posti aadressi ja salasõna.
– Kontrollige süsteemi käitumist, kui väljad jäetakse tühjaks.
– Kontrollige, kas link “unustasin parooli” käitub ootuspäraselt.
– Kontrollige süsteemi käitumist, kui nupp “hoida mind sisse logituna” on märgitud.
– Kontrollige süsteemi käitumist, kui sisestatakse vale telefoninumber.
Niisiis, kõik need näited on üksikud UI testjuhtumid.
Erinevalt testimisstsenaariumist, mis hõlmab kogu protsessi, vaatlevad testjuhtumid üksikuid funktsioone. Teisisõnu, iga ülaltoodud näide on kasutajaliidese testjuhtum, kusjuures kogu loetelu on liigitatud testimisstsenaariumiks.
UI testskriptid
Rakenduse testimise veelgi üksikasjalikumaks jaotamiseks luuakse UI-testi skriptid, et anda testijatele rohkem teavet testjuhtumite ja stsenaariumide kohta.
Allpool on kokkuvõte sellest, mis on kasutajaliidese testiskriptid ja kuidas neid kirjutada.
1. Mis on UI testskriptid?
Kasutajaliidese testiskriptid on väga üksikasjalikud kirjeldused rakenduses tehtavatest testidest, tavaliselt rida-realt.
Need on oma olemuselt väga spetsiifilised ja sisaldavad palju üksikasju kasutatud testjuhtumite, andmete ja rakenduse eeldatava funktsionaalsuse kohta.
Kõik testjuhtumite tulemused lisatakse ka testiskriptidesse, et suurendada teabe rikkalikkust.
2. Kuidas kirjutada UI testiskripte
Kasutajaliidese testiskriptid on lihtsad, sest need kirjeldavad lihtsalt testjuhtumeid.
Kui te lisate neisse järgmise teabe, peaksite saama oma UI-testi skriptidest palju kasu:
– Testskripti ID: See on testiskripti unikaalne identifikaator.
– Pealkiri: Testskripti pealkiri.
– Testjuhtumi ID: See on selle testjuhtumi ID, mille jaoks te loote skripti.
– Nõuded: Need on testjuhtumite käivitamiseks vajaliku riistvara rakenduse spetsifikatsioonid.
– Menetlus: Need on sammud, mis võetakse testimisega edasiliikumiseks.
– Tulemus: See on testimise väljund ja lõpptulemus.
– Staatus: See näitab testiskripti edukust – kas see õnnestus või ebaõnnestus?
– Veakood: Kui tekkis probleem, siis veakood täpsustab, milles probleem seisnes.
UI testide kontrollnimekiri
Nüüd, kui olete valmis alustama kasutajaliidese testimisega, kasutage oma testide loomiseks allpool toodud kontrollnimekirja:
1. Kontrollige põhifunktsioone
Funktsionaalne testimine on suurepärane võimalus leida selliseid asju nagu visuaalsed vead või tõrked platvormil.
Lisage selles etapis kindlasti sellised asjad nagu biomeetrilised andmed, mis tahes sõnumid ja andmed rakenduse mälu kohta.
2. Kontrollige platvormidevahelist ühilduvust
Et vältida selliseid probleeme nagu seadme killustatus, mis takistab teatavate kasutajate juurdepääsu rakendusele, on kasulik kontrollida platvormide vahelist ühilduvust.
See hõlmab rakenduse kontrollimist erinevate ekraanilahenduste puhul.
Hea mõte on uurida nii originaal- kui ka hübriidrakenduste ühilduvust mobiilseadmete, näiteks Androidi ja iOSi puhul.
3. Kontrollige ühilduvust erinevate ekraanisuuruste vahel
On palju erinevaid ekraanisuurusi, mida lõppkasutajad võivad üritada rakendusega kasutada, seega on oluline testida kasutajaliidest nende jaoks.
Kasutajaliidese reageerimisvõime testimist on kõige parem rakendada kõige uuemates seadmetes, et lahendada võimalikke probleeme. Samuti ärge unustage testida nii maastiku- kui ka portree režiimis.
4. Kontrollida jõudlust ja skaleeritavust
Kui rakendus on skaleeritav, suudab see pakkuda suurepärast jõudlust eri platvormidel.
Testige erinevaid koormustasemeid, liiklust ja muid lõppkasutaja stsenaariume, et hinnata rakenduse jõudlust ja skaleeritavust.
Seda saab teha paralleelse testimise abil, mille puhul kasutatakse automatiseeritud kasutajaliidese testimist nagu robotiseeritud protsesside automatiseerimine mitmes keskkonnas.
5. Kontrollida rakenduse ligipääsetavust
Kättesaadavuse testimine tagab, et lõppkasutajate abistamiseks mõeldud konkreetsed funktsioonid toimivad ootuspäraselt. Kontrollige siin selliseid asju nagu kirjasuurus, ekraanilugeja režiim ja suumimisvõimalused.
6. Kontrolli värvid ja tekst
Rakendused peaksid kuvama värve kindlal viisil, seega on oluline seda kontrollida, katsetades värviskeeme.
See hõlmab selliseid asju nagu hüperlingi värv või muud kirjatüübid. Samuti on kasulik kontrollida teksti õigekirja, kirjasuuruse ja joonduse osas.
7. Hinnake navigatsioonikiirust
Veenduge, et rakenduse kasutajaliides töötab sujuvalt ja ilma tõrgeteta. Sellised asjad nagu pealkirjade laadimisekraan on hea koht, kus otsida viivitust.
