Mi az a majom- és gorillateszt? Példák, különbség
Thomas Hamilton
⚡ Okos összefoglaló
A majomtesztelés véletlenszerű, nem tervezett bemenetet adagol egy futó alkalmazásnak, és figyeli, hogy az túléli-e, így az összeomlások, lefagyások és kezeletlen állapotok jóval azelőtt megjelennek, hogy bármilyen előre definiált teszteset megíródna.
Mi a majmolás tesztelés?
Majomtesztelés egy szoftvertesztelési technika, amelyben a tesztelő véletlenszerű bemeneteket ad meg egy alkalmazásnak előre meghatározott tesztesetek nélkül, és ellenőrzi az alkalmazás viselkedését, különösen azt, hogy összeomlik-e. A majomtesztelés célja hibák és hibák felkutatása kísérleti, szkript nélküli interakció révén.
A név egy egyszerű képről származik, amelyet az alábbi ábra szemléltet.
- A majomtesztelés során a tesztelőt (és néha a fejlesztőt) „majomként” kezelik.
- Ha egy majom számítógépet használna, véletlenszerűen végezne feladatokat anélkül, hogy megértené a rendszert.
- Ugyanígy a tesztelő véletlenszerű bemeneteket alkalmaz a tesztelt rendszeren hibák felkutatására anélkül, hogy előre definiálna bármilyen tesztesetet.
- Bizonyos esetekben a majmokkal végzett tesztek célja egység tesztelés or Grafikus felhasználói felület tesztelése.
Mi az a Gorilla tesztelés?
Gorilla tesztelés egy olyan szoftvertesztelési technika, amelynek során a program egy modulját ismételten tesztelik annak megerősítésére, hogy megfelelően működik és nem tartalmaz hibákat.
Egyetlen modul akár százszor vagy többször is ugyanúgy tesztelhető, ezért a gorilla tesztelést „frusztráló tesztelésnek” is nevezik. A majom tesztelés véletlenszerűen terjed az alkalmazásban; a gorilla tesztelés egy helyre koncentrál, amíg az el nem romlik, vagy szilárdnak bizonyul.
A majomtesztelés típusai
A majomtesztelést kategóriákba sorolják aszerint, hogy a tesztelő mennyit tud a rendszerről. Az alábbi ábra összefoglalja a három típust.
- Hülye majom: A tesztelőnek fogalma sincs a rendszerről vagy annak működéséről, és nincs garancia arra, hogy bármely bemenet érvényes.
- Okos majom: A tesztelő pontos elképzeléssel rendelkezik a rendszerről, annak céljáról és működéséről, eligazodni tud benne, és érvényes bemeneteket szolgáltat.
- Zseniális majom: A tesztelő valós felhasználói viselkedésből indul ki, és meg tudja állapítani, hogy hol valószínűsíthető a hibák megjelenése.
Majomtesztelés vs. gorillatesztelés vs. eseti tesztelés
Majomtesztelés, gorillatesztelés és eseti tesztelés egy meghatározatlan ízük van, ezért gyakran összekeverik őket. Az alábbi két táblázat elválasztja őket.
Majomtesztelés vs. gorillatesztelés
| Majomtesztelés | Gorilla tesztelés |
|---|---|
| Véletlenszerűen végrehajtva, nincsenek konkrétan előre meghatározott tesztesetek. | Sem előre meghatározott, sem véletlenszerű – ugyanazokat az ellenőrzéseket egyszerűen megismétlik. |
| A teljes rendszeren végrehajtható, és számos tesztesetet foglalhat magában. | Néhány kiválasztott modulon, kevés tesztesettel végrehajtva. |
| A cél a rendszerösszeomlás ellenőrzése. | A cél annak ellenőrzése, hogy a modul megfelelően működik-e. |
Majomtesztelés vs. eseti tesztelés
| Majomtesztelés | Ad-hoc tesztelés |
|---|---|
| Véletlenszerűen végrehajtva, nincsenek konkrétan előre meghatározott tesztesetek. | Tervezés vagy dokumentáció nélkül hajtják végre, így nem készülnek tesztesetek vagy SRS. |
| A tesztelők talán nem tudják, mi a rendszer, vagy mire való. | A tesztelőnek a tesztelés megkezdése előtt jól meg kell értenie a rendszert. |
| A cél a rendszerösszeomlás ellenőrzése. | A cél az, hogy a rendszert véletlenszerűen részekre osszuk, és ellenőrizzük azok működését. |
A majmokkal végzett tesztelés előnyei és hátrányai
Mivel a technika a tervezést a sebességért cserébe használja, előnyei és gyengeségei ugyanabból a tulajdonságból fakadnak.
A majmokkal végzett tesztelés előnyei
- Új típusú hibák: A tesztelő szabadon dolgozhat a korábban meghatározott forgatókönyveken kívül is, ami olyan hibákat tár fel, amelyekre senki sem gondolt a szkriptelés során.
- Könnyen végrehajtható: A véletlenszerű adatokon alapuló véletlenszerű műveletek gyors módja a rendszer gyakorlásának.
- Less képzett emberek: A majmokkal végzett tesztek gyakran elvégezhetők nagy tapasztalattal rendelkező tesztelők nélkül.
- Less drága: Jelentősen kevesebb kiadást igényel a beállítása és futtatása, mint egy szkriptelt csomagé.
A majmokkal végzett tesztelés hátrányai
- A hibákat nehéz reprodukálni: Mivel a bemenetek véletlenszerűek, a hibák reprodukálása rögzített kezdőérték nélkül nem biztos, hogy lehetséges.
- Less pontosság: a tesztelő nem tud pontos forgatókönyvet meghatározni, és nem tudja garantálni a lefedett dolgok pontosságát.
- A műszaki szakértelem továbbra is hasznos: Ahhoz, hogy az eredmények értelmesek maradjanak, a tesztelőknek jól kell ismerniük a területet.
- Lassú a hozamhoz képest: A futtatások hosszú ideig is eltarthatnak, és továbbra is kevés hibát visszaadhatnak, réseket hagyva a rendszerben.
Hogyan végezzünk majomtesztelést
A majmokkal végzett tesztelés sokkal hatékonyabbá válik, ha egy eszköz vezérli, és ellene is futtatható. Android buildek, valamint asztali és webes alkalmazások. Az általános folyamat a következő:
- Regisztrálja a tesztelt alkalmazást az eszközzel vagy a dedikált szerverrel, amely futtatni fogja.
- Készítse elő a referenciákat és a konfigurációt, amelyre az eszköznek szüksége van egy tesztkészlet felépítéséhez.
- Futtassa a létrehozott tesztcsomagot.
- Hagyd, hogy az eszköz naplózza a naplóját – a „majomteszt” naplófájl minden generált eseményt és az eredményeket rögzíti.
- Hagyja a futtatást folytatódni, amíg a rendszer el nem éri az összeomlási pontot, ahol a szabálytalan művelet rögzítésre kerül a naplóban.
- Ossza meg a jelentést a felelős csapattal, és őrizze meg a tesztadatokat későbbi felhasználás céljából.
Őrizzen meg minden naplót. Egy véletlenszerű futtatás csak akkor hasznos később, ha az eseménysorozat és az azt létrehozó seed mentésre került, így hibakezelés vissza tudja kötni az összeomlást egy reprodukálható bemenethez.
Majomtesztelő eszközök
A majmokkal végzett tesztelés általában automatizált, mivel egy gép több ezer eseményt képes generálni annyi idő alatt, mint egy ember néhány tucatot. A leggyakrabban használt lehetőségek a következők:
- Felhasználói felület/alkalmazás Exerciser Monkey: egy beépített parancssori eszköz Android ami a aDB shell és pszeudo-véletlenszerű felhasználói eseményfolyamokat küld, például koppintásokat, gesztusokat és billentyűleütéseket, valamint rendszerszintű eseményeket egy eszközre vagy emulátorra.
- MonkeyRunner: egy külön Python API amely egy munkaállomásról vezérli az eszközöket és emulátorokat, specifikus parancsokat küld és képernyőképeket készít. A neve ellenére nem ugyanaz az eszköz, mint a gyakorlómajom.
- UI Automator és Appium: általános mobil tesztelés olyan keretrendszerek, amelyek szkriptelhetők félig véletlenszerű eseménysorozatok elindítására egy build során.
- Fuzzing eszközök, mint például az AFL: ugyanaz a véletlenszerű beviteli elv vonatkozik az adatokra a gesztusok helyett, amelyet a fuzz tesztelés.
A majomteszteléshez használt eszköztámogatás gyengébb, mint a szkriptelt teszteléshez. automatizálási tesztelés, így a legtöbb csapat egy általános eseménygenerátort kombinál a meglévő keretrendszerével, ahelyett, hogy egy dedikált terméket vásárolna.
Mikor kell majomtesztet használni?
A majmokkal végzett tesztelés inkább konkrét helyzetekben vívja ki a helyét, mintsem a tervezett tesztelés általános helyettesítőjeként.
Akkor használja, ha:
- Egy korai buildhez egy olcsó stabilitási ellenőrzésre van szükség, mielőtt hivatalos tesztesetek léteznének.
- A felület rendkívül interaktív – játékok, rajzeszközök, médialejátszók –, és a valós felhasználói viselkedést nehéz megjósolni.
- Áztatni szeretnél, vagy feszültség olyan futtatás, amely órákon át keresi az összeomlásokat, memóriaszivárgásokat és kezeletlen állapotokat.
- Egy kiadás átment a szkriptellenőrzéseken, és független ellenőrzést szeretnél végezni minden olyan területen, amelyhez a szkript még nem nyúlt hozzá.
Kerülje el, amikor:
- Ismételhető bizonyítékra van szükséged arra vonatkozóan, hogy egy követelmény teljesül – ez egy írásos dokumentum feladata. próbaper.
- A build elég instabil ahhoz, hogy minden futtatás azonnal összeomoljon, ami mindent az első hiba mögé rejt.
- Kevés az idő, mivel egy véletlenszerű keresés nem garantálja, hogy bármit is találunk.
A gyakorlatban a legerősebb eredményeket a kevert megközelítések adják: a szkriptelt tesztek lefedik az ismert folyamatokat, feltáró tesztelés Szándékosan vizsgálja az ismeretlent, és majomként teszteli a támadásokat, amiről mindketten azt feltételezték, hogy soha nem fog megtörténni.
