Free Press

Egy teljes útmutató a mobilalkalmazások teszteléséhez mélyreható oktatóanyagokkal:

A mobiltechnológia és az okoseszközök most a trend, és megváltoztatják a világ jövőjét, ahogyan mi ismerjük. Erről mindannyian kezeskedhetünk, nem igaz? Nos, amatőr lenne, ha felsorolnám, hogy mire használjuk ezeket a mobileszközöket. Mindannyian tudjátok – talán jobban, mint mi.

Lássunk rögtön ahhoz, amiről ez a bemutató fog szólni.

A több mint 30 mobil tesztelési tutorial teljes listája:

Mobil tesztelés bevezetése:

Tutorial #1: Bevezetés a mobil tesztelésbe
Tutorial #2: iOS alkalmazások tesztelése
Tutorial #3: Android alkalmazások tesztelése
Tutorial #4: Mobil tesztelési kihívások és megoldások
Tutorial #5: Miért nehéz a mobil tesztelés?

Mobil eszközök tesztelése:

Tutorial #6: Android verzió tesztelése, amikor kiveszik a piacról
Tutorial #7: Hogyan teszteljük a mobil alkalmazásokat alacsony árfekvésű készülékeken
Tutorial #8: Mobil alkalmazások terepi tesztelése
Tutorial #9: Phone Model Vs OS Version: Melyiket kell először tesztelni?

Mobil felhasználói felület tesztelése:

Tutorial #10: Mobil alkalmazások felhasználói felületének tesztelése
Tutorial #11: Mobile Responsive Test

Mobile Testing Services:

Tutorial #12: Cloud-Based Mobile Application Testing
Tutorial #13: Mobil alkalmazás tesztelési szolgáltatások
Tutorial #14: Mobil alkalmazás béta tesztelési szolgáltatások
Tutorial #15: Mobil alkalmazás fejlesztő cég
Tutorial #16: Felhő alapú mobil alkalmazás tesztelési szolgáltatók

Mobil alkalmazás teljesítmény és biztonsági tesztelés:

Tutorial #17: Mobil alkalmazások teljesítménytesztelése a BlazeMeter használatával
Tutorial #18: Mobil alkalmazások biztonsági tesztelési irányelvei

Mobil tesztelési eszközök:

Tutorial #19: Android App Testing Tools
Tutorial #20: Best Mobile App Security Testing Tools
Tutorial #21: 58 Best Mobile Testing Tools

Mobile Automation Testing:

Tutorial #22: Appium Mobile Automation Tool tutorial
Tutorial #23: Appium Studio tutorial
Tutorial #24: Android alkalmazások automatizálása a TestComplete eszközzel
Tutorial #25: Robotium tutorial – Android alkalmazások UI tesztelési eszköze
Tutorial #26: Selendroid Tutorial: Mobil automatizálási keretrendszer
Tutorial #27: pCloudy Tutorial: Mobile App Testing on Real Devices
Tutorial #28: Katalon Studio & Kobiton’s Cloud-Based Device Farm Tutorial

Mobile Testing Career:

Tutorial #29: How to Get a Mobile Testing Job Fast
Tutorial #30: Mobil tesztelési interjúkérdések és önéletrajz
Tutorial #31: Mobil tesztelési interjúkérdések 2. rész

*************************************************************

Kezdjük a sorozat 1. bemutatójával.

Tutorial #1: Bevezetés a mobilalkalmazások tesztelésébe

Múltak azok az idők, amikor a telefon egy olyan készülék volt, amely a sarokban ült, és csörögnie kellett, hogy felhívja magára a figyelmünket, vagy a számítógép egy olyan gép volt, amelyet csak néhány ember használt – ma már lényünk kiterjesztése – ablak a világra és virtuális szolgák, akik azt teszik, amit mondanak nekik.

A számítógépek tomboltak, és megváltoztatták az emberek gondolkodását, viselkedését, tanulását és létezését.

Mára a mobilitási megoldások átvették az uralmat a piacon. Az emberek nem akarják mindenre bekapcsolni a laptopjukat/PC-jüket, inkább azt akarják, hogy a kézi eszközeik mindent gyorsan elvégezzenek.

Ezért a mobil megoldásokat, amelyeket ügyfeleinknek szállítunk, nagyon jól kell tesztelni. Ez a bemutató azoknak szól, akik már foglalkoznak mobil teszteléssel, vagy akik az utóbbi időben váltottak rá. Mivel már számos oktatóanyagunk van a mobilteszteléssel kapcsolatos terminológiák definícióiról, közvetlenül ennek az oktatóanyagnak a tárgykörével fogunk foglalkozni.

Ez az oktatóanyag egyszerre lesz bevezetés és útmutató a mobilteszteléshez. Olvassa végig!

A mobil tesztelés típusai

A mobil eszközökön végzett tesztelésnek nagyjából 2 fajtája van:

#1. Hardveres tesztelés:

A készülék, beleértve a belső processzorokat, belső hardvert, képernyőméreteket, felbontást, helyet vagy memóriát, kamerát, rádiót, Bluetooth-t, WIFI-t stb. Ezt néha egyszerű “mobiltesztelésnek” is nevezik.

#2. Szoftver- vagy alkalmazástesztelés:

A mobileszközökön működő alkalmazásokat és azok működését tesztelik. A korábbi módszertől való megkülönböztetés érdekében “Mobilalkalmazás-tesztelésnek” nevezik. A mobil alkalmazásoknál is van néhány alapvető különbség, amelyek megértése fontos:

a) Natív alkalmazások: A natív alkalmazás olyan platformon való használatra készül, mint a mobil és a táblagépek.
b) A mobil webes alkalmazások szerveroldali alkalmazások, amelyekkel különböző böngészők, például Chrome, Firefox segítségével mobilhálózathoz vagy vezeték nélküli hálózathoz, például WIFI-hez csatlakozva mobilon lehet elérni a webhelyet/eket.
c) A hibrid alkalmazások a natív alkalmazás és a webes alkalmazás kombinációi. Eszközökön vagy offline futnak, és olyan webes technológiákkal íródnak, mint a HTML5 és a CSS.

Van néhány alapvető különbség, amely ezeket megkülönbözteti:

• A natív alkalmazások egyetlen platformhoz kötődnek, míg a mobil webes alkalmazások a platformok közötti kötődéssel rendelkeznek.
• A natív alkalmazások olyan platformokra íródnak, mint az SDK-k, míg a mobil webes alkalmazások olyan webes technológiákkal íródnak, mint a HTML, CSS, asp.net, Java, PHP.
• A natív alkalmazásokhoz telepítés szükséges, de a mobil webes alkalmazásokhoz nincs szükség telepítésre.
• A natív alkalmazás a play store-ból vagy az alkalmazásboltból frissíthető, míg a mobil webes alkalmazások központi frissítésűek.
• Nagyon sok natív alkalmazás nem igényel internetkapcsolatot, de a mobil webes alkalmazások esetében ez elengedhetetlen.
• A natív alkalmazás gyorsabban működik, mint a mobil webes alkalmazások.
• A natív alkalmazások olyan alkalmazásboltokból települnek, mint a Google play áruház vagy az alkalmazásbolt, ahol a mobil webes alkalmazások weboldalak, és csak az interneten keresztül érhetők el.

A cikk további részében a mobilalkalmazások teszteléséről lesz szó.

A mobilalkalmazások tesztelésének jelentősége

A mobileszközökön lévő alkalmazások tesztelése nagyobb kihívást jelent, mint a webes alkalmazások tesztelése az asztali számítógépen, mivel

• A mobileszközök különböző képernyőméretekkel és hardverkonfigurációkkal rendelkező különböző mobileszközök, például kemény billentyűzet, virtuális billentyűzet (érintőképernyő) és trackball stb. miatt.
• A mobileszközök széles választéka, például HTC, Samsung, Apple és Nokia.
• Különböző mobil operációs rendszerek, például Android, Symbian, Windows, Blackberry és IOS.
• Az operációs rendszer különböző verziói, mint iOS 5.x, iOS 6.x, BB5.x, BB6.x stb.
• Különböző mobilhálózat-üzemeltetők, mint GSM és CDMA.
• Gyakori frissítések – (mint Android- 4.2, 4.3, 4.4, iOS-5.x, 6.x) – minden egyes frissítéssel egy új tesztelési ciklus ajánlott, hogy megbizonyosodjunk arról, hogy az alkalmazás funkcionalitása nem sérül.

Mint minden alkalmazás esetében, a mobilalkalmazások tesztelése is nagyon fontos, mivel az ügyfélkör általában milliós nagyságrendben vásárol egy bizonyos terméket – és egy hibás terméket soha nem értékelnek. Ez gyakran pénzbeli veszteséget, jogi problémát és helyrehozhatatlan márkaimázs-károsodást eredményez.

A mobil és asztali alkalmazások tesztelése közötti alapvető különbség:

Néhány nyilvánvaló szempont, ami megkülönbözteti a mobilalkalmazások tesztelését az asztali teszteléstől

• Az asztali alkalmazás tesztelése központi feldolgozóegységen történik. A mobileszközön az alkalmazás tesztelése olyan készüléken történik, mint a Samsung, a Nokia, az Apple és a HTC.
• A mobileszközök képernyőjének mérete kisebb, mint az asztali gépeké.
• A mobileszközöknek kevesebb memóriájuk van, mint az asztali gépeknek.
• A mobileszközök olyan hálózati kapcsolatokat használnak, mint a 2G, 3G, 4G vagy WIFI, míg az asztali gépek szélessávú vagy betárcsázós kapcsolatokat használnak.
• Az asztali alkalmazások teszteléséhez használt automatizálási eszköz nem feltétlenül működik a mobil alkalmazásokon.

A mobil alkalmazások tesztelésének típusai:

A fenti technikai szempontok figyelembevétele érdekében a mobil alkalmazásokon a következő típusú teszteléseket végzik.

• Használhatósági tesztelés- Annak biztosítása, hogy a mobilalkalmazás könnyen használható legyen, és kielégítő felhasználói élményt nyújtson az ügyfelek számára
• Kompatibilitási tesztelés- Az alkalmazás tesztelése különböző mobileszközökön, böngészőkben, képernyőméretekben és operációs rendszer verziókban a követelményeknek megfelelően.
• Felületi tesztelés- Az alkalmazás menüpontjainak, gombjainak, könyvjelzőinek, előzményeinek, beállításainak és navigációs folyamatának tesztelése.
• Szolgáltatások tesztelése- Az alkalmazás szolgáltatásainak online és offline tesztelése.
• Alacsony szintű erőforrás-tesztelés: A memóriahasználat tesztelése, az ideiglenes fájlok automatikus törlése, a helyi adatbázis növekedésével kapcsolatos problémák, amelyeket alacsony szintű erőforrás-tesztelésnek nevezünk.
• Teljesítménytesztelés- Az alkalmazás teljesítményének tesztelése a kapcsolat 2G-ről, 3G-ről WIFI-re való váltásával, a dokumentumok megosztásával, az akkumulátor fogyasztásával stb.
• Üzemeltetési tesztelés- A biztonsági mentések és a helyreállítási terv tesztelése, ha az akkumulátor lemerül, vagy adatvesztés az alkalmazás tárolóból történő frissítése során.
• Telepítési tesztek- Az alkalmazás validálása az eszközökre történő telepítéssel/eltávolítással.
• Biztonsági tesztelés- Az alkalmazás tesztelése annak érvényesítésére, hogy az információs rendszer védi-e az adatokat vagy sem.

Mobilalkalmazás tesztelési stratégia

A tesztelési stratégiának biztosítania kell, hogy az összes minőségi és teljesítménybeli irányelv teljesüljön. Néhány támpont ezen a területen:

1) Az eszközök kiválasztása – Elemezze a piacot, és válassza ki a széles körben használt eszközöket. (Ez a döntés leginkább az ügyfeleken múlik. Az ügyfél vagy az alkalmazáskészítők figyelembe veszik az egyes készülékek népszerűségi tényezőjét, valamint az alkalmazás marketingigényét, hogy eldöntsék, milyen készülékeket használjanak a teszteléshez.)

2) Emulátorok – Ezek használata rendkívül hasznos a fejlesztés kezdeti szakaszában, mivel lehetővé teszik az alkalmazás gyors és hatékony ellenőrzését. Az emulátor egy olyan rendszer, amely a szoftvert egyik környezetből egy másik környezetbe futtatja anélkül, hogy magát a szoftvert megváltoztatná. Megkettőzi a valós rendszer funkcióit és működését.

Mobil emulátorok típusai

• Készülék emulátor- az eszközgyártók által biztosított
• Böngésző emulátor- a mobil böngészők környezetét szimulálja.
• Működő rendszerek emulátor- az Apple az iPhone-okhoz, a Microsoft a Windows telefonokhoz és a Google Android telefonokhoz biztosít emulátorokat

Javasolt eszköz

#1) Kobiton

A Kobiton egy megfizethető és rendkívül rugalmas felhőalapú mobil élmény platform, amely felgyorsítja a natív, webes és hibrid alkalmazások tesztelését és szállítását Androidon és iOS-en egyaránt valós eszközökkel. Új, szkript nélküli tesztautomatizálásuk segít a kódolási szakértelemmel nem rendelkező csapatoknak, hogy könnyedén létrehozzák a nyílt szabványú Appium szkripteket.

=> Látogasson el a Kobiton weboldalára

Listája néhány ingyenes és könnyen használható mobileszköz-emulátornak

i. Mobiltelefon emulátor – Olyan készülékek tesztelésére szolgál, mint az iPhone, Blackberry, HTC, Samsung stb.

ii. MobiReady – Ezzel nem csak a webes alkalmazást tesztelhetjük, hanem a kódot is ellenőrizhetjük.

iii. Responsivepx – A weboldalak válaszait, megjelenését és funkcionalitását ellenőrzi.

iv. Screenfly – Ez egy testreszabható eszköz, és különböző kategóriákba tartozó weboldalak tesztelésére szolgál.

3) Miután a mobilalkalmazás fejlesztésének kielégítő szintje befejeződött, áttérhet a fizikai eszközökön történő tesztelésre a valósabb forgatókönyveken alapuló teszteléshez.

4) Fontolja meg a felhőalapú tesztelést: A felhőalapú számítástechnika alapvetően eszközök futtatását jelenti több rendszeren vagy hálózaton keresztül az interneten keresztül, ahol az alkalmazások tesztelhetők, frissíthetők és kezelhetők. Tesztelési célokra létrehozza a webalapú mobil környezetet egy szimulátoron a mobilalkalmazás eléréséhez.

Pros:

• Backup és helyreállítás- A felhőalapú számítástechnika automatikusan biztonsági mentést készít az adatokról távoli helyről, így az adatok helyreállítása és visszaállítása könnyen elvégezhető. És a tárolási kapacitás is korlátlan.
• A felhő különböző eszközökről és bárhonnan elérhető.
• A felhőalapú számítástechnika költséghatékony, könnyen használható, karbantartható és frissíthető.
• Gyors és gyors telepítés.
• Webalapú felület.
• Egyazon szkriptet több eszközön is futtathatja párhuzamosan.

Hátrányok

• Kevesebb ellenőrzés- Mivel az alkalmazás távoli vagy harmadik féltől származó környezetben fut, a felhasználónak korlátozott ellenőrzése és hozzáférése van a funkciókhoz.
• Internetkapcsolati problémák- a beállítás az interneten történik. A hálózati problémák befolyásolják a rendelkezésre állást és a működést
• Biztonsági és adatvédelmi kérdések- A felhőalapú számítástechnika internetes számítástechnika, és az interneten semmi sem teljes mértékben biztonságos, így az adatok feltörésének esélye nagyobb.

5) Automatizálás vs. Kézi tesztelés

• Ha az alkalmazás új funkciókat tartalmaz, tesztelje azt kézzel.
• Ha az alkalmazás egyszer vagy kétszer igényel tesztelést, végezze azt kézzel.
• Automatizálja a regressziós tesztesetek szkriptjeit. Ha a regressziós tesztek ismétlődnek, az automatizált tesztelés tökéletes erre.
• Automatizálja a szkripteket az összetett forgatókönyvekhez, amelyek kézi végrehajtás esetén időigényesek.

A mobilalkalmazások tesztelésére kétféle automatizálási eszköz áll rendelkezésre:

Objekt-alapú mobil tesztelési eszközök- automatizálás az eszköz képernyőjén lévő elemek objektumokká való leképezésével. Ez a megközelítés független a képernyőmérettől, és főleg Android készülékeknél használatos.

• Eg:- Ranorex, jamo solution

Képalapú mobil tesztelési eszközök- automatizálási szkriptek létrehozása az elemek képernyőkoordinátái alapján.

• Eg:- Sikuli, Egg Plant, RoutineBot

6) A hálózati konfiguráció szintén a mobil tesztelés szükséges része. Fontos, hogy az alkalmazást különböző hálózatokon, például 2G, 3G, 4G vagy WIFI hálózaton validáljuk.

Tesztesetek a mobilalkalmazás teszteléséhez

A funkcionalitás alapú tesztesetek mellett a mobilalkalmazás tesztelése speciális teszteseteket igényel, amelyeknek a következő forgatókönyvekre kell kiterjedniük.

• Akkumulátorhasználat- Fontos nyomon követni az akkumulátor fogyasztását az alkalmazás mobileszközökön történő futtatása során.
• Az alkalmazás sebessége- a válaszidő különböző eszközökön, különböző memóriaparaméterekkel, különböző hálózati típusokkal stb.
• Adatigény – A telepítéshez, valamint annak ellenőrzéséhez, hogy a korlátozott adatcsomaggal rendelkező felhasználó képes lesz-e a letöltésre.
• Memóriaigény- ismét a letöltéshez, telepítéshez és futtatáshoz
• Az alkalmazás funkcionalitása- győződjön meg róla, hogy az alkalmazás nem omlik össze hálózati hiba vagy bármi más miatt.

Töltsön le néhány minta tesztesetet a mobil alkalmazások teszteléséhez:

=> Mobilalkalmazás minta tesztesetek letöltése

Típusos tevékenységek és eljárások a mobilalkalmazás tesztelése során

A tesztelés terjedelme az ellenőrizendő követelmények számától vagy az alkalmazáson végzett változtatások mértékétől függ. Ha kevés a változtatás, elegendő egy kör szanitástesztelés. Nagyobb és/vagy összetett változtatások esetén teljes regressziós tesztelés ajánlott.

Egy példa az alkalmazás tesztelési projektjére: Az ILL (International Learn Lab) egy olyan alkalmazás, amelyet arra terveztek, hogy segítse az adminisztrátorokat, kiadókat a weboldalak együttműködésben történő létrehozásában. Egy webböngésző segítségével az oktatók egy sor funkció közül választhatnak, hogy az igényeiknek megfelelő órát hozzanak létre.

Mobil tesztelési folyamat:

1. lépés. A tesztelés típusainak azonosítása: Mivel egy ILL alkalmazás böngészőkre alkalmazható, ezért kötelező tesztelni ezt az alkalmazást az összes támogatott böngészőn különböző mobileszközökkel. Használhatósági, funkcionális és kompatibilitási tesztelést kell végeznünk a különböző böngészőkön a manuális és automatizált tesztesetek kombinációjával.

2. lépés. Kézi és automatizált tesztelés: A projekt során követett módszertan az agilis, kéthetes iterációval. A fejlesztőcsapat kéthetente új buildet ad ki a tesztelőcsapat számára, a tesztelőcsapat pedig a QA-környezetben futtatja a teszteseteket. Az automatizálási csapat szkripteket készít az alapvető funkciók készletéhez, és lefuttatja a szkripteket, amelyek segítenek meghatározni, hogy az új build elég stabil-e a teszteléshez. A kézi tesztelő csapat teszteli az új funkcionalitást.

A JIRA-t az elfogadási kritériumok megírására; a tesztesetek karbantartására és a hibák naplózására / újraellenőrzésére használják. Amint az iteráció véget ér, iterációs tervezési megbeszélést tartanak, ahol a dev. A csapat, a terméktulajdonos, az üzleti elemző és a QA csapat megvitatja, hogy mi ment jól és mit kell javítani.

3. lépés. Béta tesztelés: Miután a QA csapat befejezte a regressziós tesztelést, a build átkerül az UAT-ba. A felhasználói átvételi tesztelést az ügyfél végzi. Újra ellenőrzik az összes hibát, hogy megbizonyosodjanak arról, hogy minden hibát kijavítottak, és az alkalmazás minden jóváhagyott böngészőn az elvárásoknak megfelelően működik.

4. lépés. Teljesítményteszt: A teljesítménytesztelő csapat a JMeter szkriptek segítségével és az alkalmazás különböző terheléseivel teszteli a webalkalmazás teljesítményét.

5. lépés. Böngészőtesztelés: A webalkalmazást több böngészőben tesztelik – mind különböző szimulációs eszközökkel, mind fizikailag, valódi mobileszközökkel.

Step #6. Indítási terv: Minden 4. hét után a tesztelés átkerül a stagingbe, ahol egy utolsó kör végponttól végpontig tartó tesztelést végeznek ezeken az eszközökön, hogy megbizonyosodjanak arról, hogy a termék készen áll a gyártásra. És ezután indul a Live!

*****************************************

How to Test Mobile Applications on Both Android and iOS Platforms

A tesztelők számára, akik iOS és Android platformon is tesztelik az alkalmazásukat, nagyon fontos, hogy ismerjék a kettő közötti különbséget. Az iOS és az Android rengeteg különbséggel rendelkezik a megjelenés, az alkalmazás nézete, a kódolási szabványok, a teljesítmény stb. tekintetében.

Az Android és az iOS tesztelése közötti alapvető különbség

Elképzelhető, hogy átnézted az összes oktatóanyagot, ide beírtam néhány fontosabb különbséget, ami viszont segíteni fog neked a tesztelés részeként:

#1) Mivel rengeteg Android eszköz áll rendelkezésre a piacon, és mindegyikük különböző képernyőfelbontással és mérettel rendelkezik, ezért ez az egyik legfontosabb különbség.

Például a Samsung S2 mérete túl kicsi a Nexus 6-hoz képest. Nagy a valószínűsége annak, hogy az alkalmazás elrendezése és dizájnja torzul az egyik eszközön. Az iOS esetében a valószínűség alacsony, mivel a piacon csak megszámlálható számú eszköz áll rendelkezésre, és ezek közül sok telefon hasonló felbontással rendelkezik.

Például, mielőtt az iPhone 6 és újabb készülékek megjelentek, az összes régebbi verzió csak hasonló méretű volt.

#2) Példa a fenti pont igazolására, hogy az Androidban a fejlesztőknek 1x,2x,3x,4x és 5x képeket kell használniuk, hogy minden eszköz képfelbontását támogassák, míg az iOS csak 1x,2x és 3x-ot használ. A tesztelő felelőssége lesz azonban annak biztosítása, hogy a képek és a többi UI-elem minden eszközön helyesen jelenjenek meg.

A képfelbontások fogalmának megértéséhez lásd az alábbi ábrát:

#3) Mivel a piacot elárasztották az Android-eszközök, a kódot úgy kell megírni, hogy a teljesítmény állandó maradjon. Így elég valószínű, hogy az alkalmazásod lassan viselkedhet az alacsonyabb kategóriájú készülékeken.

#4) Egy másik probléma az Androiddal kapcsolatban, hogy a szoftverfrissítések nem minden készülékre érhetőek el egyszerre. A készülékgyártók döntik el, hogy mikor frissítik a készülékeiket. Nagyon nehéz feladat lesz mindent tesztelni mind az új, mind a régi operációs rendszerrel.

A fejlesztők számára is nehézkessé válik a kódjuk módosítása, hogy mindkét verziót támogassák.

Például, amikor az Android 6.0 megjelent, jelentős változás történt, mivel ez az operációs rendszer elkezdte támogatni az alkalmazásszintű engedélyeket. A további pontosítás érdekében a felhasználó az engedélyeket (hely, kapcsolatok) az alkalmazás szintjén is módosíthatta.

Most a tesztelő csapat felelőssége, hogy az Android 6.0 és magasabb verziókon az alkalmazás indításakor megjelenjen az engedélyek képernyője, és ne jelenjen meg az engedélyek képernyője az alacsonyabb verziókon.

#5) A tesztelés szempontjából a pre-production build (azaz a béta verzió) tesztelése mindkét platformon eltérő. Androidon, ha egy felhasználó hozzá van adva a béta felhasználók listájához, akkor csak akkor láthatja a frissített béta buildet a Play Store-ban, ha ugyanazzal az e-mail azonosítóval van bejelentkezve a Play Store-ba, amellyel béta felhasználóként hozzá van adva.

Kulcstényezők a mobil tesztelésben

A mobil tesztelésben dolgoztam az elmúlt 2 évben mind az iOS, mind az Android platformon, és az összes alább említett kulcsfontosságú pont ebben a bemutatóban a személyes tapasztalatomból származik, és néhány a projektben felmerült problémákból származik.

Define your own scope of Testing

Mindenkinek megvan a saját tesztelési stílusa. Néhány tesztelő csak arra koncentrál, amit a szemével lát, a többiek pedig szenvedélyesen foglalkoznak mindennel, ami bármely mobilalkalmazás kulisszái mögött működik.

Ha iOS/Android tesztelő vagy, azt javaslom, hogy legalább ismerkedj meg az Android vagy iOS néhány közös korlátozásával/alapvető funkciójával, mivel ez mindig hozzáadott értéket jelent a tesztelési stílusunkhoz. Tudom, hogy példák említése nélkül nehéz megérteni a dolgokat.

Az alábbiakban néhány példa:

• A 6.0.1 verzió alatti Android eszközökön nem tudjuk megváltoztatni az engedélyeket, például a kamerát, a tárhelyet stb. az alkalmazás szintjén.
• A 10.0 verzió alatti iOS esetében a call kit nem volt ott. Csak röviden, egyszerű szavakkal, a call kitet egy hívó alkalmazás használja, és teljes képernyős nézetet jelenít meg, amikor a felhasználó hívást kap a hívó alkalmazásoktól, mint például a WhatsApp, Skype stb. Míg a 10.0 alatti iOS-verziók esetében ezeket a hívásokat egy értesítési banner formájában látjuk.
• Sokan találkozhattatok már olyan problémákkal a Paytm-ben, amikor az alkalmazás nem irányít át a bank fizetési oldalára, ha pénzt akartok hozzáadni a pénztárcátokhoz. Úgy gondoljuk, hogy a fenti probléma a bankunkkal vagy a Paytm szerverével kapcsolatos, de csak az AndroidSystemWebView nem frissült. A programozással kapcsolatos kis tudás mindig hasznos Önnek, és megoszthatja a csapatával.
• Egyszerű szavakkal, amikor egy alkalmazás megnyit benne bármilyen weboldalt, akkor az AndroidSystemWebView-t frissíteni kell.

Ne korlátozza a tesztelést

A tesztelésnek nem szabad csak a mobilalkalmazás feltárására és a hibák naplózására korlátozódnia. Nekünk, mint minőségbiztosítóknak tisztában kell lennünk az összes kéréssel, amit a szerverünkre küldünk, és a válaszokkal, amit kapunk belőle.

Konfiguráljuk a Putty-t a naplók megtekintésére vagy a sumo logikájának ellenőrzésére a naplókhoz, attól függően, hogy mit használunk a projektünkben. Ez nem csak abban segít, hogy megismerje az alkalmazás végponttól végpontig tartó áramlását, hanem jobb tesztelővé is teszi Önt, mivel most több ötletet és forgatókönyvet kap.

Érv: Semmi sem jön a világra ok nélkül. Minden állítás mögött érvényes oknak kell állnia. A naplók elemzése mögött az áll, hogy sok kivétel figyelhető meg a naplókban, de ezek nem mutatnak semmilyen hatást a felhasználói felületre, ezért nem vesszük észre.

Szóval, figyelmen kívül kellene hagynunk?

Nem, nem kellene. Nincs hatása a felhasználói felületre, de lehet, hogy futurisztikus aggodalomra ad okot. Lehetséges, hogy az alkalmazásunk összeomlik, ha az ilyen típusú kivételek tovább kúsznak. Mivel az App Crash-ről már beszéltünk az utolsó mondatban, ez ahhoz vezet, hogy a QA hozzáférjen a projekt crashlytics-éhez.

A crashlytics egy olyan eszköz, ahol az összeomlásokat az idővel és az eszközmodellel együtt naplózzák.

Most a kérdés itt az, hogy ha a tesztelő látta az alkalmazás összeomlását, akkor miért kell törődnie a crashlytics-szel?

A válasz erre elég érdekes. Vannak olyan összeomlások, amelyek lehet, hogy nem láthatóak a felhasználói felületen, de a crashlytics-on naplózva vannak. Ez lehet a memórián kívüli összeomlás vagy néhány végzetes kivétel, ami később hatással lehet a teljesítményre.

Platformok közötti tesztelés

A platformok közötti interakció tesztelése nagyon fontos.

Egy egyszerű példát idézve, mondjuk, hogy egy olyan csevegő alkalmazáson dolgozol, mint a WhatsApp, amely támogatja a képek és videók küldését, és az alkalmazás iOS és Android platformokra épül(A fejlesztés lehet, hogy szinkronban megy vagy nem)

Teszteld az Android és az iOS kommunikációját, ennek oka, hogy az iOS “Objective C”-t használ, míg az Android programozás Java alapú, és mivel mindkettő különböző platformokra épül, néha extra javításokat kell végezni az alkalmazás oldalán a különböző nyelvi platformokról érkező karakterláncok felismeréséhez.

Keep an eye on the size of your Mobile App

Egy másik fontos tanács a mobil tesztelők számára – Kérjük, minden egyes kiadás után ellenőrizze folyamatosan az alkalmazás méretét.

El kell érnünk, hogy az alkalmazás mérete ne érje el azt a pontot, amikor még mi, mint végfelhasználó sem szeretnénk letölteni ezt az alkalmazást a nagy mérete miatt.

Az alkalmazás frissítési forgatókönyvek tesztelése

A mobil tesztelők számára az alkalmazás frissítésének tesztelése nagyon fontos. Győződjön meg róla, hogy az alkalmazás nem zuhan össze frissítéskor, mivel a fejlesztőcsapat esetleg nem egyeztette a verziószámot.

Az adatok megőrzése ugyanilyen fontos, mivel bármilyen preferenciát is mentett a felhasználó az előző verzióban, annak meg kell maradnia, amikor frissíti az alkalmazást.

Egy felhasználó például elmenthette a bankkártya adatait olyan alkalmazásokban, mint a PayTm stb.

A készülék operációs rendszere nem támogatja az alkalmazást

Érdekesen hangzik?

Igen, előfordulhat, hogy sok készülék nem támogatja az alkalmazást. Sokan bizonyára tudják, hogy a gyártók saját wrappereket írnak az US tetejére, és lehetséges, hogy az alkalmazásod bármely SQL-lekérdezése nem kompatibilis az eszközzel, és ezért kivételt dob, és ez azt eredményezheti, hogy az alkalmazás nem is indul el az adott telefonon.

A lényeg itt az – Próbáld meg használni az alkalmazásodat a saját eszközeiden, kivéve azokat, amelyeket az irodában használsz. Könnyen előfordulhat, hogy problémákat tapasztalsz az alkalmazásoddal.

Az alkalmazás engedélyezési tesztelése

A következő a listán a mobilalkalmazások engedélyezési tesztelése. Majdnem minden második alkalmazás hozzáférést kér a felhasználóktól a telefon kapcsolataihoz, kamerájához, galériájához, helyéhez stb. Láttam néhány tesztelőt, akik hibát követnek el azzal, hogy nem tesztelik ezeknek az engedélyeknek a megfelelő kombinációit.

Emlékszem egy valós idejű példára, amikor egy olyan csevegőalkalmazást teszteltünk, amelynek minden funkciója a képek és hangfájlok megosztása volt. A Tárolás engedélye NEM-re volt beállítva.

Most, amikor a felhasználó a Kamera opcióra kattintott, az soha nem nyílt meg, amíg a Tárolás engedélye IGEN-re nem lett beállítva. A forgatókönyvet figyelmen kívül hagytuk, mivel az Android Marshmallow rendelkezett ezzel a funkcióval, hogy ha a tárolási engedély NEM-re van állítva, akkor a kamera nem használható az adott alkalmazáshoz.

A hatály tovább terjed, mint amit a fenti bekezdésben tárgyaltunk. Meg kell győződnünk arról, hogy az alkalmazás nem kér olyan engedélyeket, amelyeket nem használ.

A szoftveriparban jártas végfelhasználó nem tölthet le olyan alkalmazást, amelyben túl sok engedélyt kérnek. Ha eltávolítottál bármilyen funkciót az alkalmazásodból, akkor győződj meg róla, hogy eltávolítottad az engedélyek képernyőjét ugyanarra.

Vehetjük össze a hasonló és népszerű alkalmazásokkal a piacon

A történet erkölcse – Ha valaha is kétségek merülnek fel, akkor csak ne következtess magad. Az azonos platformon lévő más hasonló alkalmazásokkal való összehasonlítás megerősítheti az érveidet, hogy a tesztelt funkció működni fog-e vagy sem.

Történjen áttekintés az Apple Build elutasítási kritériumairól

Végezetül, a többséged talán már találkozott olyan helyzetekkel, amikor az Apple elutasította a buildjeidet. Tudom, hogy ez a téma az olvasók nagy részét nem fogja érdekelni, de mindig jó megismerni az Apple elutasítási irányelveit.

Tesztelőként nehézzé válik számunkra, hogy gondoskodjunk a technikai szempontokról, de mégis van néhány elutasítási kritérium, amelyre a tesztelők vigyázhatnak.

Az ezzel kapcsolatos további információkért kattints ide.

Mindig az első lábon kell állni

Tesztelőként ne hagyd, hogy a Dev Team/menedzserek átadják a dolgokat az udvarodnak. Ha szenvedélyesen szereted a tesztelést, akkor “Mindig légy a frontvonalban”. Próbálj meg részt venni olyan tevékenységekben, amelyek jóval azelőtt zajlanak, hogy a kód a te vödrödbe kerülne tesztelésre.

A legfontosabb, hogy folyamatosan nézd a JIRA-t, a QC-t, az MTM-et vagy bármelyiket is használják a projektedben az ügyfelektől és az üzleti elemzőtől érkező jegyekkel kapcsolatos legfrissebb frissítésekért. Továbbá álljon készen arra, hogy megossza a véleményét, ha módosításokra van szükség. Ez az összes tesztelőre vonatkozik, akik különböző területeken és platformokon dolgoznak.

Amíg és amíg nem érezzük a terméket sajátunknak, soha nem kellene javaslatokat tennünk új fejlesztésekre vagy a meglévő funkciók módosítására.

Hosszú ideig (12-24 óra)

Tudom, hogy furcsán hangzik, de sok logika van a háttérben, amit mindannyian nem értünk.

Ezt azért osztom meg, mert láttam, hogy az alkalmazás indítás után összeomlik, mondjuk kb. 14 óra után a háttérállapotból. Az ok bármi lehet, attól függően, hogy a fejlesztők hogyan kódolták.

Hadd osszam meg egy valós idejű példát:

Az én esetemben a token lejárata volt az oka. Az egyik csevegőalkalmazás, ha 12-14 óra után indult, megrekedt a csatlakozó banneren, és soha nem csatlakozott, amíg meg nem ölték és újra nem indították. Az ilyen dolgokat nagyon nehéz elkapni, és bizonyos értelemben ez teszi a mobil tesztelést nagyobb kihívássá és kreatívabbá.

Az alkalmazás teljesítménytesztelése

A mobil világában az alkalmazás teljesítménye befolyásolja, hogy az alkalmazást milyen mértékben ismerik el világszerte. Tesztelő csapatként túlságosan fontossá válik, hogy ellenőrizzük az alkalmazás reakcióját, és ami még fontosabb, hogy hogyan működik, amikor nagyszámú felhasználó használja azt együttesen.

Példa:

Beszéljünk a PayTm-ről.

Mindannyian biztosan rákattintottak a PayTm-alkalmazásban a PÉNZÜGYÍTÉS opcióra, amely ezután megjeleníti a pénztárcájában lévő egyenleget. Ha figyelembe vesszük, hogy mi történik a színfalak mögött, akkor ez egy kérés, amely a PayTm felhasználói azonosítóval megy tovább a szerver felé, és a szerver visszaküldi a választ a számláján lévő egyenleggel.

A fenti eset csak akkor áll fenn, ha egy felhasználó elérte a szervert. Biztosítanunk kell, hogy még akkor is, ha 1000 felhasználó éri el a szervert, időben visszakapja a választ, mert a végfelhasználói használhatóság az elsődleges célunk.

Következtetés

Azzal fejezném be ezt a bemutatót, hogy megismétlem, hogy a mobiltesztelés az elején nagyon egyszerűnek tűnik, de ahogy egyre jobban beleásod magad, meg fogod érteni, hogy nem könnyű biztosítani, hogy bármit is fejlesztettünk, zökkenőmentesen fusson több ezer eszközön szerte a világon.

A legtöbbször csak olyan alkalmazásokat fogsz látni, amelyek az OS legújabb és utolsó néhány verzióján támogatottak. Azonban a tesztelők feladata lesz, hogy biztosítsák, hogy ne hagyjanak ki egyetlen forgatókönyvet sem. Sok más pontot is figyelembe kell venni, de nem említettem azokat, amelyeket a többi oktatóanyagban már megemlítettem.

A mobil tesztelés során hasznosak az olyan forgatókönyvek, mint az akkumulátor fogyasztása, a megszakításos tesztelés, a különböző hálózatokon (3G, Wi-Fi) végzett tesztelés, a hálózatváltás közbeni tesztelés, a mobilalkalmazások majomtesztelése stb.

A tesztelők hozzáállása sokat számít, amikor a valós tesztelési környezetről van szó. Amíg és amíg nem szereted a munkádat, addig nem fogsz foglalkozni olyan dolgokkal, amelyeket az útmutatóban említettek.

Már körülbelül 6 éve dolgozom ezen a területen, és nagyon jól tudom, hogy a feladatok időnként monotonná válnak, de sok más dolog van, amit magunk is megtehetünk, hogy ezeket a monoton feladatokat némileg érdekessé tegyük.

A megfelelő tesztstratégia megtervezése, a megfelelő mobil szimulátorok, eszközök és mobil tesztelési eszközök kiválasztása biztosíthatja a 100%-os tesztlefedettséget, és segíthet a biztonsági, használhatósági, teljesítmény, funkcionalitás és kompatibilitás alapú tesztek beépítésében a tesztcsomagjainkba.

Nos, ez volt a törekvésünk, hogy teljesítsük olvasóink többszörös kérését egy mobilalkalmazás-tesztelési útmutatóval kapcsolatban.

Autors: Köszönjük Swapnának, Hasnetnek és sok más mobil tesztelési szakértőnek, hogy segítettek nekünk összeállítani ezt a sorozatot!

Következő cikkünkben többet fogunk beszélni az iOS alkalmazások teszteléséről.