Megszakítási tesztelés mobilalkalmazásban
Thomas Hamilton
⚡ Okos összefoglaló
A megszakítástesztelés azt vizsgálja, hogy egy mobilalkalmazás hogyan viselkedik hívás, riasztás, értesítés vagy hálózati kiesés esetén, és hogy az alkalmazás visszatér-e a korábbi állapotába a megszakítás megszűnése után.
Mi az a megszakításteszt?
Megszakítási tesztelés a mobilalkalmazás-tesztelés egy ága, amely azzal foglalkozik, hogy egy alkalmazás hogyan reagál egy megszakításra, és hogyan tér vissza az előző állapotába. A megszakítás az alkalmazáson kívülről – az operációs rendszerről, a hardverről vagy egy másik alkalmazásról – származik, és a teszt ellenőrzi, hogy az irányítás visszatérésekor nem vész-e el adat, képernyőállapot vagy folyamatban lévő tranzakció.
A megszakításos tesztelés bármilyen alkalmazástípusra alkalmazható – webes, mobil, önálló stb. Az eszközök, hálózatok és konfigurációk sokfélesége sokkal kiemelkedőbbé teszi. Mozgó alkalmazásoknál, mint a többinél.
Miért van szüksége megszakítási tesztelésre?
Mi az az egy dolog, ami szinte mindig történik egy megbeszélésen? Félreszakítanak, ugye? Amikor ez megtörténik, vannak, akik még csak pislogni sem mernek, vannak, akik egy percre is várnak, hogy visszakapják a fonalat, és vannak, akik teljesen elvesztik a gondolatmenetüket. Egyszerűen fogalmazva, a megszakítástesztelés megpróbálja kideríteni, hogy az alkalmazásod milyen viselkedést mutat.
Egy pillanatra tegyük félre a szófordulatokat, és nézzünk egy másik valós helyzetet. Tegyük fel, hogy van egy zseblámpád, és BEkapcsolod. Az elem lemerül, ami megszakítja a jelenlegi aktív állapotát. Cseréld ki az elemeket, és állítsd vissza. A zseblámpának a szokásos módon újra be kell kapcsolnia. Ez a használati eset. A tesztelés egy olyan ága, amely arra összpontosít, hogy ez megtörténik-e vagy sem, a megszakításos tesztelés.
Az üzleti terv egyszerű. A megszakítás a lehető legrosszabb pillanatban érkezik – fizetés, feltöltés vagy űrlap közben –, és egy felhasználó, aki elveszíti ezt a munkát, ritkán próbálkozik újra. Az önéletrajz összeomlása, az üres képernyők, a duplikált tranzakciók és az elveszett űrlapbevitel mind olyan hibák, amelyeket csak egy megszakítás fed fel, ezért élik túl a soha semmit sem megszakító funkcionális átfutást.
Megszakítások típusa a mobilalkalmazásban
A megszakítások egy maroknyi ismerős csoportba sorolhatók, amelyeket az alábbi ábra foglal össze.
Mindannyian ismerjük a gyakori megszakításokat, amelyek általában előfordulnak. Íme néhány közülük:
- Lemerült elem
- Akkumulátor feltöltve – töltés közben
- Bejövő telefonhívás
- Bejövő SMS
- Bejövő riasztás egy másik mobilalkalmazásból
- Töltéshez csatlakoztatva
- Kikapcsolva a töltésből
- A készülék kikapcsolva
- Alkalmazásfrissítési emlékeztetők
- Riasztó és kamerák üzemeltetésére, biztonsági szolgálat igénybe vételére
- A hálózati kapcsolat megszakadása
- Hálózati kapcsolat helyreállítása
Ez a lista nem teljes, de a leggyakoribb forgatókönyveket tartalmazza. A lista praktikusan rendszerezhető eredet szerint: eszközfüggő események, például akkumulátor és töltés, felhasználó által kezdeményezett események, például hívás fogadása vagy alkalmazásváltás, valamint külső események, például jelvesztés liftben vagy alagútban.
Megoldás megszakítás esetén
Ezen megszakítások esetén a várható viselkedés a következő négy közül az egyik:
- A háttérben fut: A megszakítás átveszi az irányítást, miközben az alkalmazás háttérbe szorul. A megszakítás megszűnése után átveszi az irányítást. Például egy telefonhívás vagy FaceTime-hívás, amelyen részt vesz, miközben egy digitális könyvet olvas az iBooksban (vagy hasonló alkalmazásban). Amikor a felhasználó felveszi a telefont, az iBooks megvárja, amíg a hívás véget ér, majd a hívás befejeztével folytatja.
- Figyelmeztetés megjelenítése: A riasztás eltűnik, és a felhasználó a szokásos módon dolgozhat. A fejlécben megjelenik egy „SMS érkezett” üzenet. A felhasználó nem törődik ezzel, és a szokásos módon folytatja az alkalmazás használatát. Más mobilalkalmazás-értesítések, például egy új ismerősként való megkeresés a Facebookon vagy egy WhatsApp-üzenet, szintén ebbe a kategóriába tartoznak. De ha a felhasználó úgy dönt, hogy elolvassa az üzenetet, az 1. pontban leírtak szerint viselkedik. Ha a riasztást figyelmen kívül hagyja, az alkalmazás állapota változatlan marad.
- Felhívás cselekvésre: A munka folytatása előtt ki kell kapcsolni vagy el kell halasztani az ébresztőket. Ugyanez vonatkozik az alkalmazásfrissítési üzenetekre is. A folytatás előtt vagy vissza kell vonni, vagy el kell fogadni a módosításokat. Egy másik példa az alacsony akkumulátortöltöttségre figyelmeztető jelzés – választhat, hogy a szokásos módon folytatja a munkát, vagy alacsony energiafogyasztású módba vált, ha az eszköz ezt lehetővé teszi.
- Nincs hatása: Példa erre, ha a hálózati kapcsolat elérhetővé válik, és az eszköz csatlakozik hozzá. Továbbá, amikor töltés céljából csatlakoztatja az eszközt, nincs szükség riasztásra vagy cselekvésre ösztönzésre. Valószínűleg elvégzi a feladatát, miközben Ön továbbra is használja az alkalmazást.
Tehát a tesztelt megszakítástól függően értse meg a viselkedést, és nézze meg, hogy az alkalmazás megfelel-e annak. A fent leírt viselkedésnek nem kell minden alkalmazás és eszköz esetében azonosnak lennie. Feltétlenül tájékozódjon a mobilalkalmazására vonatkozó konkrét részletekről.
Megszakított tesztelés tesztesetei várt eredményekkel
Miután a várható megoldásban megállapodtak, minden megszakítás egy szokásos tesztesetté válik, amelyhez tartozik egy kiváltó ok, egy művelet és egy ellenőrizhető eredmény. Az alábbi táblázat bemutatja, hogyan fordítható le a fenti négy megoldás konkrét forgatókönyvekké.
| Félbeszakítás | Teszt forgatókönyv | Várható eredmény |
| Bejövő telefonhívás | Hívás indítása félig kitöltött űrlap mellett, fogadás, majd hívás befejezése | Az alkalmazás a háttérbe ugrik, majd ugyanazon a képernyőn folytatódik a beírt adatokkal. |
| Bejövő SMS vagy push értesítés | Üzenet küldése videó vagy feltöltés közben, és a banner figyelmen kívül hagyása | A banner megjelenik és eltűnik; az alkalmazás állapota változatlan |
| Riasztó és kamerák üzemeltetésére, biztonsági szolgálat igénybe vételére | Ütemezett riasztás aktiválása aktív munkamenet közben, majd annak elvetése | A riasztás először cselekvésre ösztönzést kér, majd az alkalmazás ott folytatódik, ahol leállt. |
| Alacsony akkumulátor figyelmeztetés | Tranzakció közben a figyelmeztetési küszöbértékig merítse le az eszközt | Figyelmeztetés jelenik meg, a tranzakció nem törlődik, és az alacsony energiafogyasztású mód nem töri meg a képernyőt. |
| A hálózati kapcsolat megszakadása | Kapcsolódás letiltása kérés közben, majd visszaállítása | Egyértelmű üzenet jelenik meg, nem történik összeomlás, és a kérés befejeződik, vagy biztonságosan meghiúsul a visszaállítás során. |
| Töltés csatlakoztatva vagy levéve | A töltő csatlakoztatása és leválasztása aktív munkamenet közben | Nincs hatás – az alkalmazás látható változás nélkül folytatódik |
| Alkalmazásfrissítési emlékeztető | Frissítési kérés megjelenítése az alkalmazás használata közben | A felhasználó megszakíthatja vagy elfogadhatja a műveletet, és az alapul szolgáló képernyő mindkét választás esetén érvényben marad. |
Megszakításonként és kritikus képernyőnként egy sort használjon a teljes alkalmazás megszakításonkénti egy sora helyett. A fizetési képernyő, a bejelentkezési képernyő és a hosszú űrlapok mindegyike másképp hibásodik meg, és egyetlen általános eset ezt elrejti.
Most, hogy megértettük, mi az a megszakítási tesztelés, és mit kell érvényesíteni a végrehajtás során, itt az ideje, hogy beszéljünk ennek módjáról.
Hogyan kell elvégezni a megszakítási tesztelést
Nézze meg ezt az állítást: az iBooksnak a háttérben kell futnia, amikor a felhasználó bejövő telefonhívást kap.
Nem neveznéd ezt az iBooks alkalmazás funkcionális követelményének? Én igen.
Tehát a megszakításteszt egy részhalmaza Funkcionális tesztelés egy mobilalkalmazáshoz. A megszakításos tesztelés elvégzéséhez ugyanazokat a mobilalkalmazás-tesztelési keretrendszereket és eszközöket kell követni. A tesztelők képessége, hogy ezeket a forgatókönyveket kitalálják. Ha ez megtörtént, megtervezik a teszteseteket, és pontosan ugyanúgy hajtják végre őket, mint bármely más tesztet.
A gyakorlatban a sorozat rövid és ismételhető:
- Sorold fel a kritikus felhasználói folyamatokat – bejelentkezés, fizetés, feltöltés, hosszú űrlapok, médialejátszás.
- Jelöld rá az összes lehetséges megszakítást a fenti listából az egyes utakra.
- Egyeztesse a termék tulajdonosával az egyes párosítások várható megoldását, mivel nincs univerzális alapértelmezett megoldás.
- A megszakítást a legkockázatosabb pillanatban hajtsd végre, ne egy tétlen pillanatban, majd folytasd.
- Az alkalmazás állapotának, adatainak, munkamenetének és memóriájának ellenőrzése a folytatás után, ne csak azt, hogy az alkalmazás még mindig nyitva van.
A tágabb tudományágról bővebben a következő címen olvashat: Mobil tesztelés oktatóanyag és a példaesetek Mobilalkalmazások tesztelése.
Eszközök és technikák a megszakítások szimulálására
A fenti forgatókönyveket igény szerint kell előállítani, nem pedig várni rájuk, és minden platform biztosít erre módot.
- Android Emulátor kibővített vezérlőelemei: Az emulátor oldalsó panelje szimulálja a bejövő hívást, az SMS-t, az akkumulátor töltöttségi szintjét és a töltő állapotát, valamint a mobil térerőt, így a megszakítási lista nagy része második kézibeszélő nélkül is feloldható.
- iOS szimulátor és Xcode: A csatlakozási és hardverállapotok a szimulátorból és az eszközbeállításokból is módosíthatók, míg egy párosított fizikai eszköz lefedi azokat a hívási forgatókönyveket, amelyeket a szimulátor nem tud felidézni.
- Második fizikai eszköz: A tesztelt eszköz egy másik készülékről történő felhívása vagy üzenetküldése továbbra is a legmegbízhatóbb módja a valódi megszakítás reprodukálásának, különösen az időérzékeny esetekben.
- Eszköz beállítások: A repülőgép üzemmód, a Wi-Fi kapcsolók, a Ne zavarjanak mód, az akkumulátorkímélő mód és az ütemezett riasztások a valódi hardverek csatlakozási és áramkimaradásait is lefedik.
- Automatizálási keretrendszerek: Ugyanaz az automatizálási rendszer vezérelheti az alkalmazást a megszakítás előtt és után is, mint a funkcionális csomag többi része, így a folytatás ellenőrzése a folyamat előrehaladtával történik, nem pedig csak előre meghatározott időn belül.
- Valós eszközalapú felhők: Egy hosztolt eszközpark szélesebb lefedettséget biztosít a gyártók és operációsrendszer-verziók között, ami azért fontos, mert a megszakítások kezelése az egyik olyan terület, ahol a szállítók testreszabásai a leginkább eltérnek.
Bármi legyen is a mechanizmus, rögzítse a megszakítás pontos pillanatát a tesztesetben. A „Megszakítás feltöltés közben” és a „Megszakítás feltöltés után” különböző tesztek, eltérő hibamódokkal.
A megszakított tesztelés legjobb gyakorlatai
Néhány szokás különbözteti meg a hasznos megszakításgyűjteményt a pipálgatásos gyakorlattól.
- A legrosszabb pillanatban szakíts félbe: Target abban a pillanatban, amikor egy tranzakció véglegesítésre kerül, vagy egy fájl írása folyamatban van, mert ez az a pont, ahol az állapot a legsebezhetőbb.
- A folytatást teszteld, ne a megszakítást: A hiba szinte mindig a vezérlés visszatérése után jelenik meg, így az állításoknak a visszaállított képernyőre kell kerülniük.
- A hálózati változás mindkét irányát lefedjük: A kapcsolat elvesztése és visszaállítása külön eset, és a másodikat gyakrabban kihagyjuk.
- Változtasd meg az időtartamot: Egy két másodperces riasztás és egy tízperces hívás különböző életciklus-utakon keresztül vezeti végig az alkalmazást, beleértve a memóriából való kizárást is.
- Elterjedve az operációs rendszer verziói és az alsó kategóriás hardverek között: A háttérkizárás sokkal agresszívabb a korlátozott eszközökön, ami olyan hibákat is felszínre hoz, amelyeket egy csúcskészülék elrejt.
- Automatizáld az ismételhetőeket: A csatlakozási és akkumulátor-megszakítások tisztán automatizálódnak, így nincs szükség manuális erőfeszítésre a hívásokhoz és riasztásokhoz.
- Figyelje az erőforrás-felhasználást, valamint az alábbiakat: A memóriaszivárgást vagy az akkumulátor lemerítését okozó megszakítás folytatáskor hibának minősül, még akkor is, ha a képernyő megfelelően néz ki, ami összekapcsolja ezt a munkát a mobilalkalmazások teljesítményének tesztelése.
A megszakítási tesztelés nem ugyanaz, mint a helyreállítási tesztelés?
Nem, ez nem. Helyreállítási tesztelés érvényesíti a hiba utáni helyreállítást. A megszakítás nem feltétlenül hiba – csupán egy hibatracCIÓ.
Ez olyan, mint a vessző és a pont közötti különbség az angolban. A különbség csak technikai, de a kép világos. A helyreállító tesztelés azt kérdezi, hogy az alkalmazás vissza tud-e térni, ha valami elromlott; a megszakításos tesztelés pedig azt kérdezi, hogy egyáltalán elromlik-e valami, ha valami más kerül előtérbe.
Ez az, amit tudnunk kell ahhoz, hogy elkezdhessük a megszakításos tesztelést – a mobilalkalmazás-tesztelés egy fontos és intuitív ágát.
