Mis on ahvi ja gorilla testimine? Näited, erinevus
Thomas Hamilton
⚡ Nutikas kokkuvõte
Ahvitestimine annab töötavale rakendusele juhuslikku ja planeerimata sisendit ning jälgib, kas see jääb ellu, seega paljastatakse krahhid, hangumised ja käsitlemata olekud juba ammu enne ühegi eelnevalt määratletud testi kirjutamist.
Mis on ahvide testimine?
Ahvide testimine on tarkvara testimise tehnika, mille puhul testija sisestab rakendusse juhuslikke sisendeid ilma eelnevalt määratletud testijuhtumiteta ja kontrollib rakenduse käitumist, eriti seda, kas see jookseb kokku. Ahvitestimise eesmärk on leida vigu ja vigu eksperimentaalse, skriptimata interaktsiooni kaudu.
Nimi tuleb lihtsast pildist, mis on illustreeritud allpool.
- Ahvitestimisel koheldakse testijat (ja mõnikord ka arendajat) kui "ahvi".
- Kui ahv kasutaks arvutit, täidaks ta ülesandeid juhuslikult, süsteemist aru saamata.
- Samamoodi rakendab testija testitavale süsteemile juhuslikke sisendeid vigade leidmiseks ilma ühtegi testijuhtumit eelnevalt defineerimata.
- Mõnel juhul on ahvide testimise eesmärk üksuse testimine or GUI-testimine.
Mis on Gorilla testimine?
Gorilla testimine on tarkvara testimise tehnika, mille puhul testitakse programmi ühte moodulit korduvalt, et kinnitada selle korrektset toimimist ja vigade puudumist.
Ühte moodulit võib täpselt samal viisil harjutada sada või enam korda, mistõttu gorillatestimist tuntakse ka kui „pettust tekitavat testimist“. Ahvitestimine levib rakenduses juhuslikult; gorillatestimine süveneb ühte kohta, kuni see puruneb või osutub usaldusväärseks.
Ahvide testimise tüübid
Ahvidega testimine jaguneb kategooriatesse vastavalt sellele, kui palju testija süsteemi kohta teab. Allolev diagramm võtab need kolm tüüpi kokku.
- Rumal ahv: Testijal pole süsteemist ega selle funktsionaalsusest aimugi ning puudub igasugune garantii, et ükski sisend on kehtiv.
- Nutikas ahv: Testijal on süsteemist, selle eesmärgist ja funktsionaalsusest täpne ettekujutus, ta navigeerib selles ja annab kehtivaid sisendeid.
- Särav ahv: Testija töötab reaalse kasutajakäitumise põhjal ja oskab öelda, kus defektid tõenäoliselt ilmnevad.
Ahvide testimine vs gorillade testimine vs ad-hoc testimine
Ahvide testimine, gorillade testimine ja ad-hoc testimine neil on ebamäärane maitse, mistõttu neid sageli segamini aetakse. Neid eraldavad kaks allolevat tabelit.
Ahvide testimine vs gorillade testimine
| Ahvi testimine | Gorilla testimine |
|---|---|
| Teostatakse juhuslikult, ilma konkreetselt eelnevalt määratletud testjuhtumiteta. | Ei ole ettemääratud ega juhuslikud – samu kontrolle lihtsalt korratakse. |
| Teostatakse kogu süsteemil ja võib hõlmata paljusid testijuhtumeid. | Teostatud väheste valitud moodulite ja väheste testjuhtumitega. |
| Eesmärk on kontrollida süsteemi krahhi. | Eesmärk on kontrollida, kas moodul töötab korralikult. |
Ahvide testimine vs ad-hoc testimine
| Ahvi testimine | Ad-hoc testimine |
|---|---|
| Teostatakse juhuslikult, ilma konkreetselt eelnevalt määratletud testjuhtumiteta. | Teostatakse ilma planeerimise või dokumentatsioonita, seega ei valmistata ette testjuhtumeid ega SRS-i. |
| Testijad ei pruugi teada, mis süsteem see on või milleks seda kasutatakse. | Enne testimise alustamist peab testija süsteemist hästi aru saama. |
| Eesmärk on kontrollida süsteemi krahhi. | Eesmärk on jagada süsteem juhuslikeks alamosadeks ja kontrollida nende funktsionaalsust. |
Ahvide testimise eelised ja puudused
Kuna see tehnika vahetab planeerimise kiiruse kasuks, tulenevad selle eelised ja nõrkused samast omadusest.
Ahvide testimise eelised
- Uut tüüpi vead: Testija saab vabalt töötada väljaspool eelnevalt määratletud stsenaariume, mis toob esile vead, mille skriptimise peale keegi ei tulnud.
- Lihtne teostada: Juhuslike andmete põhjal juhuslike toimingute korraldamine on kiire viis süsteemi harjutamiseks.
- Less oskuslikud inimesed: Ahvidega testimist saab sageli teha ilma väga kogenud testijateta.
- Less kulukas: selle seadistamine ja käitamine nõuab oluliselt vähem kulutusi kui skriptitud tarkvarapakett.
Ahvide testimise puudused
- Vigu võib olla raske paljundada: Kuna sisendid on juhuslikud, ei pruugi tõrke taasloomine olla võimalik ilma salvestatud algväärtuseta.
- Less täpsus: Testija ei saa täpset stsenaariumi määratleda ega garanteerida käsitletu täpsust.
- Tehniline oskusteave on endiselt abiks: Selleks, et tulemused oleksid tähendusrikkad, peavad testijad valdkonda hästi tundma.
- Saagikuse suhtes aeglane: Töötlemised võivad kesta pikka aega ja ikkagi tagastada vähe defekte, jättes süsteemi lünki.
Kuidas ahvidel testida
Ahvidel testimine muutub palju tõhusamaks, kui seda juhib tööriist ja seda saab käivitada selle vastu Android nii ehitusversioone kui ka töölaua- ja veebirakendusi. Üldine protsess on järgmine:
- Registreerige testitav rakendus tööriista või spetsiaalse serveriga, mis seda haldab.
- Valmista ette viited ja konfiguratsioon, mida tööriist vajab testimiskomplekti loomiseks.
- Käivitage loodud testimiskomplekt.
- Laske tööriistal oma logi kirjutada – „ahvitesti” logifail salvestab iga genereeritud sündmuse ja tulemused.
- Laske käivitusel jätkuda, kuni süsteem jõuab krahhipunktini, kus rikkuv toiming jäädvustatakse logisse.
- Jaga aruannet vastutava meeskonnaga ja säilita testiandmeid edaspidiseks kasutamiseks.
Säilita iga logi. Juhuslik käivitamine on hiljem kasulik ainult siis, kui sündmuste jada ja selle genereerinud algväärtus salvestati, seega defektide haldamine saab krahhi siduda reprodutseeritava sisendiga.
Ahvide testimise tööriistad
Ahvidel testimine on tavaliselt automatiseeritud, sest masin suudab genereerida tuhandeid sündmusi ajaga, mille inimene genereerib paar tosinat. Levinumad valikud on:
- Kasutajaliides/rakendus Exerciser Monkey: sisseehitatud käsurea tööriist Android mis jookseb ADB shell ja saadab seadmesse või emulaatorisse pseudojuhuslikke kasutajasündmuste vooge, näiteks puudutused, žestid ja klahvivajutused, ning süsteemitaseme sündmusi.
- MonkeyRunner: eraldi Python API mis juhib seadmeid ja emulaatoreid tööjaamast, saates spetsiifilisi käske ja jäädvustades ekraanipilte. Vaatamata nimele ei ole see sama tööriist kui treeningahv.
- Kasutajaliidese automatiseerija ja Appium: üldine mobiilne testimine raamistikud, millele saab skriptida pooljuhuslike sündmuste järjestuste käivitamiseks ehituse ajal.
- Hägusustööriistad, näiteks AFL: sama juhusliku sisendi ideed rakendati andmetele, mitte žestidele, mida käsitletakse jaotises hägustestimine.
Ahvitestimise tööriistade tugi on õhem kui skriptitud testide puhul automaatika testimine, seega enamik meeskondi kombineerib üldise sündmuste generaatori oma olemasoleva raamistikuga, selle asemel et osta spetsiaalset toodet.
Millal ahvitestimist kasutada
Ahvidel testimine teenib oma koha pigem konkreetsetes olukordades kui planeeritud testimise üldise asendajana.
Kasutage seda, kui:
- Varajane versioon vajab enne ametlike testjuhtumite olemasolu odavat stabiilsuskontrolli.
- Liides on väga interaktiivne – mängud, joonistusvahendid, meediapleierid – ja tegeliku kasutaja käitumist on raske ennustada.
- Sa tahad leotada või stress käivitamine, mis otsib paljude tundide jooksul krahhe, mälulekkeid ja käsitlemata olekuid.
- Väljalase on läbinud skriptikontrolli ja sa tahad sõltumatut kontrolli kõigele, mida skript pole puudutanud.
Vältige seda, kui:
- Teil on vaja korduvaid tõendeid nõude täitmise kohta – see on kirjaliku dokumendi ülesanne. testjuhtum.
- Ehitus on piisavalt ebastabiilne, et iga käivitamine jookseb kohe kokku, mis peidab kõik esimese tõrke taha.
- Aeg on lühike, kuna juhuslik jooks ei garanteeri millegi leidmist.
Praktikas annavad tugevaimad tulemused segameetodite abil: skriptitud testid hõlmavad teadaolevaid vooge, uurimuslik testimine uurib tundmatut tahtlikult ja ahvid testivad rünnakuid selle üle, mida mõlemad eeldasid, et kunagi ei juhtu.
