Android Alkalmazástesztelési oktatóanyag automatizálási keretrendszerrel
Thomas Hamilton
⚡ Okos összefoglaló
Android Az alkalmazástesztelés egy felépítést ellenőrz egy széttagolt eszközkörnyezetben, az egység-, integrációs, működési és rendszerellenőrzéseket automatizálási keretrendszerekkel kombinálva, amelyek vagy egy eszközön, vagy közvetlenül a JVM-en futnak.
Miért Android Tesztelés?
Android a világ legnagyobb operációs rendszere. Egy időben, Android széttagolt: rengeteg eszköz van, és Android verziók, amelyekkel az alkalmazásnak kompatibilisnek kell lennie.
Nem számít, mennyi időt fektetsz a tervezésbe és a megvalósításba, a hibák elkerülhetetlenek, és hibák fognak megjelenni.
Android Tesztelési stratégia
Egy helyes Android a tesztelési stratégiának a következőket kell tartalmaznia
- Egységvizsgálat
- Integrációs teszt
- Operanemzeti teszt
- Rendszer teszt
Mértékegységek
Az egységtesztek olyan programkészletek, amelyek célja a forráskód egy atomi egységének, például egy metódusnak vagy egy osztálynak az ellenőrzése.
Az Android platform előre integrálva van a JUnit 3.0 keretrendszer. Ez egy nyílt forráskódú keretrendszer az automatizáláshoz Egység tesztelése, és lehetővé teszi a fejlesztők számára, hogy hatékony egységtesztelési programokat írjanak.
Az egységtesztelés kiegészítéseként a felhasználói felület (UI) teszteket is elvégezhetjük. Ezek a célalkalmazás felhasználói felületének komponenseit vizsgálják, és biztosítják, hogy az eszközön végrehajtott felhasználói műveletek sorozata esetén a helyes kimenetet adja vissza.
Az eszközön végzett felhasználói felület tesztelésének leggyakoribb módja a következő: Android Hangszerelés. De ennek teljesítményproblémái vannak. Az egyik legjobb eszköz a felhasználói felület tesztelésére Android is Robotium.
⚠️ Verzió megjegyzés: JUnit 3 osztály, mint például InstrumentationTestCase elavultak az API 24-nél; a jelenlegi projektek használják AndroidX teszt, Espresso és a UI Automator. Robotium 2016 óta nem jelent meg.
Integrációs tesztek
In Integrációs tesztelés, az összes egységtesztelt modult egyesítik és ellenőrzik. Android Ez gyakran azt jelenti, hogy ellenőrizni kell az olyan komponensekkel való integrációt, mint a Szolgáltatás, Tevékenység és Tartalomszolgáltató tesztelése.
Számos tesztelési keretrendszert használnak integrációs tesztek elvégzésére Android, mint például a Troyd, a Robolectric és Robotium.
Operanemzeti tesztek
OperaA funkcionális vagy elfogadási tesztek, más néven az interaktív tesztek, olyan magas szintű tesztek, amelyek az alkalmazás teljességét és helyességét ellenőrzik.
In Android, FitNesse egy nyílt forráskódú keretrendszer, amely megkönnyíti a működési tesztek futtatását a célalkalmazáson.
Rendszertesztek
In Rendszer tesztelés a rendszer egészét tesztelik, és ellenőrzik az összetevők, a szoftver és a hardver közötti interakciót.
In Android, A rendszertesztelés általában tartalmazza
- GUI tesztek
- Használhatósági tesztek
- Teljesítményvizsgálatok
- Stresszteszt
A fenti listában Teljesítményfelmérés nagyobb hangsúlyt kap. Használhat olyan eszközöket, mint pl Tracszemle teljesítménytesztek elvégzésére AndroidEz az eszköz segíthet az alkalmazás hibakeresésében és a teljesítményének profiljának felépítésében. Traca felülvizsgálatot most elavultnak tekintik, a javára a CPU Profiler.
Automatizált Android Tesztelés
As Android széttöredezett, sok eszközön kell tesztelni, és ez pénzbe kerül. Automatizált Android A tesztelés segít csökkenteni ezeket a költségeket.
Az automatizált előnyök Android tesztelés
- Csökkentse a tesztesetek végrehajtásának idejét
- Növelje fejlesztési folyamatának termelékenységét
- Korai hibafelismerés, megtakaríthatja a szoftver karbantartási költségeit
- Gyorsan megtalálta és kijavította a megvalósítás során fellépő hibákat
- Biztosítsa a szoftver minőségét
A következő 2 keretrendszert vizsgáljuk meg
- Android Tesztelési keretrendszer
- Robolectric tesztelési keretrendszer
Android tesztelési keretrendszer
Az egyik szabványos tesztelési keretrendszer a Android az alkalmazások a Android tesztelési keretrendszer. Jól integrált a Android SDK eszközök, és architektúrája három részből áll.
- Az alkalmazáscsomag a célalkalmazás, amelyet tesztelni kell.
- Az InstrumentationTestRunner a Teszt eset futtatóprogram, amely teszteseteket hajt végre a célalkalmazáson. A következőket tartalmazza:
- Teszteszközök: SDK eszközök tesztek készítéséhez. Ezek integrálva vannak az IDE-be, vagy parancssorból futtathatók.
- MonkeyRunner: Egy eszköz, amely API-kat biztosít olyan programok írásához, amelyek egy Android eszköz vagy emulátor kívül Android kód.
- A tesztcsomag tesztprojektekbe van szervezve, és elnevezési konvenciót követ. Ha a tesztelt alkalmazás csomagneve „com.mydomain.myapp”, akkor a tesztcsomag neve „com.mydomain.myapp.test” kell legyen. A tesztcsomag 2 objektumot tartalmaz:
- Teszteset osztályok: tartalmazzák a célalkalmazáson végrehajtandó tesztmetódusokat.
- Mintatárgyak: tartalmazzon mock adatokat, amelyeket tesztesetek minta bemeneteként fognak használni.
Android Tesztesetek osztályai
- A TestCase tartalmazza JUnit futtatási módszerek JUnit teszt
- A TestSuite-et tesztesetek futtatására használják
- Az InstrumentationTestSuite egy olyan TestSuite, amely Instrumentation elemeket injektál az InstrumentationTestCase-be a futtatásuk előtt.
- Az InstrumentationTestRunner teszteseteket futtat a célalkalmazáson.
- AndroidTestCase kiterjesztések JUnit TestCase metódusokkal olyan erőforrások eléréséhez, mint az Activity Context.
- Az ApplicationTestCase ellenőrzi az Application osztályokat egy ellenőrzött környezetben.
- Az InstrumentationTestCase egy adott funkciót vagy viselkedést ellenőrz, például az alkalmazás felhasználói felületének kimenetét.
- Az ActivityTestCase egy alap osztály, amely támogatja az alkalmazástevékenységek tesztelését.
- A ProviderTestCase egy osztály egyetlen ContentProvider tesztelésére.
- A ServiceTestCase szolgáltatásosztályokat tesztel tesztkörnyezetben, és támogatja a szolgáltatás életciklusát.
- A SingleLaunchActivityTestCase egyetlen tevékenység InstrumentationTestCase segítségével történő tesztelésére szolgál.
- AktivitásEgységTeszteset egyetlen izolált aktivitás tesztelésére szolgál.
- AktivitásMűszerezésTeszteset2 kiterjeszti a JUnit TestCase osztály, és instrumentációval összekapcsolja Önt a célalkalmazással, így hozzáférhet grafikus felhasználói felület komponenseihez, és felhasználói felület eseményeket, például billentyűleütéseket vagy érintéseket küldhet.
Az alábbiakban az ActivityInstrumentationTestCase metódus egy példája látható. Ez a metódus egy Számológép alkalmazás felhasználói felületének működését, valamint a felhasználói felület kimeneteinek helyességét ellenőrzi.
Roboelektromos tesztelési keretrendszer
Tesztelés a következővel: Android A tesztelési keretrendszer egy eszközzel vagy emulátorral nehézkes. A tesztek felépítése és futtatása lassú és sok fejlesztési erőfeszítést igényel. A probléma megoldására van egy másik lehetőség: a Robolectric tesztelési keretrendszer.
A Robolectric lehetővé teszi a futást Android közvetlenül a JVM-en tesztel, eszköz vagy emulátor nélkül.
Robolectric teszteset osztályok
A Robolectric a következő műveleteket tudja végrehajtani:
- Regisztráljon és hozzon létre egy Shadow osztályt
- Elfogja a betöltését Android osztály
- Felhasználás Javaassist a metódus törzseinek felülbírálásához Android osztály
- Árnyék objektum hozzárendelése Android osztály
Ez lehetővé teszi a tesztelt kód végrehajtását anélkül, hogy Android környezetben.
Egyéb tesztelési keretrendszerek
A fent említett tesztelési keretrendszereken kívül számos más is létezik, például:
- Android Junit jelentés, egy egyedi műszerezési tesztfutó számára Android amely XML-jelentéseket készít más eszközökkel való integrációhoz.
- Espresso
- Appium
Mítoszok a Android Tesztelés
Sok vállalkozás fejlődik Android Tesztelés olyan stratégiák, amelyek általános tévhiteken alapulnak. Ez a rész néhány népszerű mítoszt és valóságot vizsgál meg Android tesztelés.
1. mítosz: Minden Android az eszközök ugyanazok, tehát az emulátorokon való tesztelés elegendő
Egy alkalmazás tökéletesen működhet emulátorokon, mégis összeomolhat végrehajtás közben néhány valódi eszközön.
Az emulátorok nem elegendőek a mobilos teszteléshez. Az alkalmazásodat valódi eszközökön kell tesztelned.
2. mítosz: Elég néhány gyakori eszközön tesztelni
Az alkalmazásod másképp néz ki a különböző eszközökön, mivel a hardver, a képernyőméret és a memória eltérő. Teszteld különböző eszközökön, operációs rendszer verziókon, szolgáltatói hálózatokon és helyszíneken.
3. mítosz: Elegendő a közvetlenül a bevezetés előtti feltáró tesztelés
- A legtöbb tesztelés során először teszteseteket tervezünk, majd végrehajtjuk azokat; a feltáró tesztelés során a tervezés és a végrehajtás együtt történik.
- Nincs terv vagy előkészület, így a tesztelő bármilyen tesztet lefuttat, amit csak akar. Egyes függvényeket ismételten tesztelnek, míg másokat soha.
4. mítosz: Ha vannak hibák az alkalmazásban, a felhasználók meg fogják érteni
- Ha az alkalmazás nem működik és hibákat tartalmaz, a felhasználók eltávolítják az alkalmazást.
- A minőségi problémák a rossz értékelések elsődleges okai Google Játssz, rontva a hírnevedet és elveszítve az ügyfelek bizalmát.
Ezért elengedhetetlen a megfelelő Android tesztelési stratégia van érvényben.
A legjobb gyakorlatok itt Android Tesztelés
- Az alkalmazásfejlesztőknek a kódírással egyidejűleg kell létrehozniuk a teszteseteket
- Minden tesztesetet verziókövetésben kell tárolni, a forráskóddal együtt.
- Használjon folyamatos integrációt, és futtasson teszteket minden alkalommal, amikor a kódot módosítja
- Kerüld az emulátorokra és a rootolt eszközökre való kizárólagos támaszkodást; ellenőrizd az eredményeket valódi hardvereken egy ellenőrrel, például uiautomatorviewer
