Vad är Monkey & Gorilla Testing? Exempel, skillnad
Redaktionellt team
⚡ Smart sammanfattning
Monkey-testning matar slumpmässig, oplanerad inmatning till en körande applikation och övervakar om den överlever, så kraschar, frysningar och ohanterade tillstånd exponeras långt innan något fördefinierat testfall har skrivits.
Vad är apatestning?
Aptestning är en mjukvarutestningsteknik där testaren matar in slumpmässiga indata i en applikation utan fördefinierade testfall och kontrollerar hur applikationen beter sig, särskilt om den kraschar. Syftet med apatestning är att hitta buggar och fel genom experimentell, oskriptad interaktion.
Namnet kommer från en enkel bild, illustrerad nedan.
- Vid aptestning behandlas testaren (och ibland utvecklaren) som "apa".
- Om en apa använde en dator skulle den utföra uppgifter slumpmässigt, utan att förstå systemet.
- På samma sätt tillämpar testaren slumpmässiga indata på systemet som testas för att hitta buggar utan att fördefiniera något testfall.
- I vissa fall syftar apaförsök till att enhetstestning or GUI-testning.
Vad är Gorilla Testing?
Gorillatestning är en mjukvarutestningsteknik där en modul i programmet testas upprepade gånger för att bekräfta att den fungerar korrekt och inte innehåller några defekter.
En enda modul kan utföras hundra gånger eller mer på exakt samma sätt, vilket är anledningen till att gorillatestning också kallas "frustrerande testning". Aptestning sprider sig slumpmässigt över applikationen, medan gorillatestning borrar sig in på ett ställe tills det går sönder eller visar sig vara fast.
Typer av apatestning
Aptestning är indelat i kategorier beroende på hur mycket testaren vet om systemet. Diagrammet nedan sammanfattar de tre typerna.
- Dum apa: Testaren har ingen aning om systemet eller dess funktionalitet, och det finns ingen garanti för att någon inmatning är giltig.
- Smart apa: Testaren har en exakt uppfattning om systemet, dess syfte och dess funktionalitet, navigerar genom det och ger giltiga indata.
- Lysande apa: Testaren utgår från verkligt användarbeteende och kan ange var fel sannolikt kommer att uppstå.
Aptestning kontra Gorillatestning kontra Ad hoc-testning
Aptestning, gorillatestning och ad hoc-testning delar en oskriptad prägel, vilket är anledningen till att de ofta förväxlas. De två tabellerna nedan skiljer dem åt.
Aptestning kontra gorillatestning
| Aptestning | Gorillatestning |
|---|---|
| Utförs slumpmässigt, utan specifikt fördefinierade testfall. | Varken fördefinierade eller slumpmässiga — samma kontroller upprepas helt enkelt. |
| Utförs på hela systemet och kan involvera många testfall. | Utfördes på ett fåtal utvalda moduler med få testfall. |
| Målet är att kontrollera om det finns en systemkrasch. | Målet är att kontrollera om modulen fungerar korrekt. |
Aptestning kontra ad hoc-testning
| Aptestning | Ad hoc-testning |
|---|---|
| Utförs slumpmässigt, utan specifikt fördefinierade testfall. | Utförs utan planering eller dokumentation, så inga testfall eller SRS förbereds. |
| Testare kanske inte vet vad systemet är eller vad det är till för. | Testaren måste förstå systemet väl innan testningen påbörjas. |
| Målet är att kontrollera om det finns en systemkrasch. | Målet är att dela upp systemet i slumpmässigt gjorda deldelar och kontrollera deras funktionalitet. |
Fördelar och nackdelar med apatestning
Eftersom tekniken handlar om planering för snabbhet, kommer dess fördelar och svagheter från samma egenskap.
Fördelar med apatestning
- Nya typer av buggar: Testaren kan arbeta fritt utanför tidigare angivna scenarier, vilket uppdagar fel som ingen tänkte på att skripta.
- Lätt att utföra: Att arrangera slumpmässiga handlingar mot slumpmässig data är ett snabbt sätt att träna systemet.
- Less skickliga personer: Aptester kan ofta utföras utan mycket erfarna testare.
- Less kostsam: Det kräver betydligt mindre utgifter för att installera och köra än en skriptbaserad svit.
Nackdelar med apatestning
- Buggar kan vara svåra att reproducera: Eftersom indata är slumpmässiga är det kanske inte möjligt att återskapa ett fel utan ett inspelat frö.
- Less noggrannhet: Testaren kan inte definiera ett exakt scenario och kan inte garantera riktigheten av det som täcktes.
- Teknisk expertis hjälper fortfarande: För att resultaten ska vara meningsfulla behöver testare god kunskap inom området.
- Långsam i förhållande till avkastning: Körningar kan pågå under lång tid och ändå returnera få defekter, vilket lämnar luckor i systemet.
Hur man utför apatestning
Aptestning blir mycket effektivare när ett verktyg styr den, och den kan köras mot Android byggen samt skrivbords- och webbapplikationer. Den allmänna processen är:
- Registrera applikationen som testas med verktyget eller den dedikerade servern som ska driva den.
- Förbered de referenser och den konfiguration som verktyget behöver för att bygga en testsvit.
- Kör den inbyggda testsviten.
- Låt verktyget skriva sin logg – loggfilen för "monkey test" registrerar varje genererad händelse och resultaten.
- Låt körningen fortsätta tills systemet når en kraschpunkt, där den felaktiga åtgärden registreras i loggen.
- Dela rapporten med det ansvariga teamet och spara testdata för framtida referens.
Spara varje logg. En slumpmässig körning är bara användbar senare om händelsesekvensen och fröet som producerade den sparades, så felhantering kan koppla kraschen tillbaka till en reproducerbar indata.
Verktyg för apatestning
Aptestning är vanligtvis automatiserad, eftersom en maskin kan generera tusentals händelser på den tid en person producerar några dussin. De vanligaste alternativen är:
- UI/Application Exerciser Monkey: ett kommandoradsverktyg inbyggt i Android som löper i aDB skal och skickar pseudoslumpmässiga strömmar av användarhändelser, såsom tryckningar, gester och tangenttryckningar, plus händelser på systemnivå, till en enhet eller emulator.
- MonkeyRunner: en separat Python API som driver enheter och emulatorer från en arbetsstation, skickar specifika kommandon och tar skärmdumpar. Trots namnet är det inte samma verktyg som motionsapan.
- UI Automator och Appium: allmänna mobil testning ramverk som kan skriptas för att utlösa semi-slumpmässiga händelsesekvenser vid en build.
- Fuzzingverktyg som AFL: samma idé med slumpmässig inmatning tillämpad på data snarare än gester, vilket behandlas i fuzz testning.
Verktygsstödet för apatestning är tunnare än för skripttestning automatiseringstestning, så de flesta team kombinerar en generisk händelsegenerator med sitt befintliga ramverk snarare än att köpa en dedikerad produkt.
När man ska använda apatestning
Aptestning förtjänar sin plats i specifika situationer snarare än som en generell ersättning för planerad testning.
Använd den när:
- En tidig version behöver en billig stabilitetskontroll innan formella testfall finns.
- Gränssnittet är mycket interaktivt – spel, ritverktyg, mediaspelare – och verkligt användarbeteende är svårt att förutsäga.
- Vill du ha ett bad eller påkänning körning som jagar efter krascher, minnesläckor och ohanterade tillstånd under många timmar.
- En utgåva har klarat skriptkontroller och du vill ha en oberoende granskning av allt som skriptet aldrig har berört.
Undvik det när:
- Du behöver upprepbara bevis på att ett krav är uppfyllt – det är en skriftligs uppgift. testfall.
- Byggnaden är tillräckligt instabil för att varje körning kraschar omedelbart, vilket döljer allt bakom det första felet.
- Tiden är knapp, eftersom en slumpmässig sökning inte ger någon garanti för att hitta något.
I praktiken kommer de starkaste resultaten från blandade metoder: skriptade tester täcker de kända flödena, utforskande testning undersöker det okända medvetet, och apor testar attacker vad de båda antog aldrig skulle hända.
