Testimisautomaatika näpunäited ja parimad tavad

Automatiseeritud testimine on tarkvaraarenduse elutsükli jooksul oluline testimistegevus, kuna see võib meeskonnale anda kiiret tagasisidet, kui uus funktsioon on välja töötatud.

Samuti eemaldatakse see kvaliteedikontrolli kohustusest regressioonikatsete korduv käivitamine, mis säästab QA-d teistele testimistegevustele keskendumiseks.

Kui testimisautomaatika on õigesti tehtud, võib see meeskonnale väga kasulik olla. Allpool olevad näpunäited aitavad teil oma automatiseeritud testimisprotsessist ja tegevusest kõige rohkem kasu saada ning toovad esile lõkse, mida testide automatiseerimisel alustada tuleb.




Käsitsi vs automatiseeritud - testimine vs kontrollimine

Vältige käsitsi ja automatiseeritud testimise võrdlemist. Mõlemat on vaja, kuna kumbki täidab erinevat eesmärki. Automatiseeritud testid on juhiste kogum, mille inimene on kirjutanud konkreetse ülesande täitmiseks. Iga kord, kui automatiseeritud test käivitatakse, järgib see täpselt samu juhiseid, nagu juhendatud, ja kontrollib ainult neid asju, mida palutakse kontrollida.

Seevastu käsitsi testimise ajal on testija aju haaratud ja võib süsteemis tuvastada muid tõrkeid. Testi etapid ei pruugi olla iga kord ühesugused, kuna testija saab testimise käigus vooge muuta; see kehtib eriti uurimiskatsete korral.




Automatiseerida regressioonitestid

Peamine põhjus, miks soovite testi automatiseerida on see, et soovite testi testida korduvalt igal uuel versioonil. Kui test tuleb läbi viia ainult üks kord, võib katse automatiseerimine ületada kasu.

Regressioonitestid tuleb testitava tarkvara arenedes läbi viia korduvalt. See võib olla QA jaoks väga aeganõudev ja igav ülesanne, kuna ta peab iga päev regressioonikatseid tegema. Regressioonitestid sobivad testide automatiseerimiseks.



Kujunduskatsed enne nende automatiseerimist

Alati on hea tava koostada testijuhud ja stsenaariumid enne testide automatiseerimise alustamist. Defektide tuvastamisel võib abi olla hea testkonstruktsioonist, automatiseeritud testid viivad läbi ainult testi ülesehituse.

Otse automatiseerimisele hüppamise oht on see, et olete huvitatud ainult skripti toimimisest ja tavaliselt ainult positiivsete ja õnnelike voogude stsenaariumide automatiseerimisest, selle asemel et mõelda teistele võimalikele katsetatavatele stsenaariumidele.


Samuti ärge vähendage testimise ulatust ainult selleks, et test toimiks või õnnestuks.



Eemaldage automatiseeritud testide määramatus

Automatiseeritud testimise üks põhipunkte on võime anda järjepidevaid tulemusi, et oleksime kindlad, et testi ebaõnnestumisel on midagi tegelikult valesti läinud.

Kui automatiseeritud test läbib ühe katse ja ebaõnnestub järgmises proovis ilma testitava tarkvara muudatusteta, ei saa me olla kindlad, kas rike on tingitud rakendusest või muudest teguritest, näiteks testkeskkonna probleemidest või probleemidest testikood ise.

Ebaõnnestumiste korral peame tulemusi analüüsima, et näha, mis on valesti läinud, ja kui meil on palju vastuolulisi või valepositiivseid tulemusi, pikendab see analüüsi aega.


Ärge kartke ebastabiilsete testide eemaldamist regressioonipakettidest; selle asemel püüdke saavutada järjepidevad puhtad tulemused, millele saate tugineda.



Vaadake üle automaatsed kehtivuse testid

Teid ärevab automatiseeritud testide arv, mis on aegunud, lihtsalt ärge kontrollige midagi või ei kontrolli kõige olulisemaid kontrollimisi!

See võib olla sümptom hüpata otse automatiseerimise juurde, kulutamata eelnevalt piisavalt aega, mida teha vaja, ja kavandades häid teststsenaariume.

Alati leidke mõni kolleeg, kes kontrolliks kehtivuse ja mõistlikkuse automatiseeritud testid. Veenduge, et testid oleksid ajakohased.




Ärge automatiseerige ebastabiilset funktsionaalsust

Uue funktsiooni või funktsionaalsuse väljatöötamisel võivad paljud asjad valesti minna ja isegi see funktsioon ei pruugi enam olla rakendatav, kuna ettevõte on oma meelt muutnud.

Kui alustasite testide automatiseerimist funktsiooni väljatöötamise ajal, tuleb teste funktsiooni arenedes mitu korda värskendada ja kõigi muudatustega kaasas käimine võib olla üsna hirmutav. Ja kui see funktsioon pole enam rakendatav, raisatakse kogu see katse automatiseerimise vaev.

Seetõttu on alati parim funktsioon automatiseerida, kui see on stabiliseerunud ja seda ei saa enam muuta.



Ärge oodake testautomaatikast võlujõudu

Testi automatiseerimise peamine põhjus on QA-aja vabastamine huvitavateks uurimuslikeks katsetusteks ja meeskonnale kindlustunne, et rakendus on uute muudatuste edastamisel endiselt heas korras.


Ärge oodake, et automaatika leiab palju vigu . Tegelikult on automaatika abil leitud vigade arv alati palju väiksem kui käsitsi ja uurimuslikul testimisel.



Ärge lootke ainult automatiseerimisele - hoiduge testide läbimisest

Automaatsed regressioonitestid võivad meeskonnale usalduse tekitada, sest regressioonitestid peaksid uue funktsionaalsuse pakkumisel siiski läbima. Meeskond hakkab testidele lootma ja hea regressioonikatsete komplekt võib toimida turvavõrguna.

Pange tähele, et kõik testid ei ole automatiseeritud ega saa olla automatiseeritud, seepärast tuleb automatiseeritud testidega alati kaasata ka uurimuslikke teste.

Mõnikord peaks tarkvara muutmine testis ebaõnnestuma; kui aga kõik katsed on läbitud, tähendab see, et defekt on vahele jäänud ja kuna üleskutset ei olnud, jäi defekt märkamata.



Eesmärk on kiire tagasiside

Kiire tagasiside on üks automatiseeritud testide eesmärkidest, sest arendajad soovivad teada, kas nende väljatöötatud töötab ja pole praegust funktsionaalsust rikkunud.

Selle kiire tagasiside tsükli saamiseks tuleb testid komponendi või API kihil automatiseerida, ilma et kasutajaliidese lootust saaks.

Kasutajaliidese kaudu tehtavad testid on palju aeglasemad ja GUI muudatuste tõttu altid vigadele. Teisisõnu, funktsionaalsus töötab endiselt ootuspäraselt, kuid testid nurjuvad kasutajaliidese muudatuste tõttu. Seetõttu võivad testid muutuda ebausaldusväärseteks.



Mõistke konteksti

Katseid saab automatiseerida igas kihis, üksuses, API-s, teenuses, graafilises liideses. Igal kihil on testimiseks erinev eesmärk.
Üksuste testid tagavad, et kood töötab klassi tasandil, selle koostab ja loogika on ootuspärane. Selle kihi testid on pigem kontrollimine kui valideerimine.

API-testid või integreerimistestid tagavad, et funktsioonide ja klasside komplekt saaks töötada koos ning andmeid saaks ühest klassist teise edastada.

GUI testid seevastu testivad kasutaja voogusid ja rännakuid. Üldiselt ei testiks me kasutajaliidese funktsionaalsust. Seda tuleks teha madalamatel kihtidel.

Kasutajaliidese testide põhieesmärk on tagada, et kogu süsteem toimiks vastavalt mõnele tavalisele kasutaja stsenaariumile ja kasutusjuhtumile. Selle kihi testimine on pigem valideerimine kui kontrollimine

Kasutajaliidese tasemel automatiseerime pigem stsenaariumid kui lood.



Ärge automatiseerige iga testi

100% testkatvus pole võimalik, kuna kombinatsioone võib olla miljoneid. Teostame alati võimalike testide alamhulga. Sama põhimõte kehtib ka automatiseeritud testimise kohta.

Automatiseeritud skripti loomiseks on vaja aega ja vaeva ning „Iga testi automatiseerimine“ seadmine nõuab palju ressursse ja aega, mis paljudel juhtudel pole võimalik.

Selle asemel kasutage riskipõhist lähenemisviisi, et teha kindlaks, millised testid peaksid olema automatiseeritud. Automatiseerimise maksimaalse väärtuse saamiseks automatiseerige ainult kõige olulisemad ärijuhtumid ja stsenaariumid.

Samuti lisab suur arv automatiseeritud teste hoolduskulusid ja neid on raske hooldada.

Veel tuleb meeles pidada, et kõiki teste ei saa automatiseerida. Mõned testid on oma olemuselt väga keerukad ja vajavad palju järgneva süsteemi kontrollimist ning võivad olla vastuolulised. Sellistel juhtudel on kõige parem jätta need kontrollid käsitsi testimiseks.



Kasutage testimisvõtteid testimisautomaatikas

ISTQB-s õpitud testitehnikad pole mõeldud ainult käsitsi testimiseks. Neid saab rakendada ka automatiseeritud testimisel. Sellised tehnikad nagu piirväärtuse analüüs, samaväärsuse jagamine, ülemineku oleku testimine, paarikaupa testimine võivad automatiseeritud testimisel pakkuda palju eeliseid.



Ärge automatiseerige kaost

Automaatse testimise maksimaalseks kasutamiseks peaks olema hea kvaliteedikontrolli protsess. Kui kvaliteedikontrolli protsess on kaootiline ja lisame sellele kaosele automaatse testimise, on meil ainult kiirem kaos.

Proovige vastata järgmistele küsimustele: mida automatiseerida, Millal automatiseerida , Millal tuleb automatiseeritud testid läbi viia, kes automatiseerib testid, milliseid tööriistu tuleks testide automatiseerimiseks kasutada jne.

Need näpunäited on kogutud peamiselt automatiseerimistestija kogemustest ja mõnedest headest tavadest, mida teised järgivad.

Kas teil on sellesse loendisse lisatavaid testimisautomaatika näpunäiteid?