Mobilalkalmazások 04: Eszközfarmok 01

Bevezető

Mobiltesztelés sorozatunkban már bemutattuk, hogy a különféle mobilalkalmazás típusok esetében, milyen szempontokat kell figyelembe venni tesztelés esetén. Webkalmazások, Native alkalmazások, Progresszív web alkalmazások voltak.

Mi a csoda az az eszközfarm (device farm)?

Kezdjük egy kis történelemmel: a Nokia elkezdte kínálni fejlesztőinek okostelefon-bérbeadási szolgáltatását, így lehetőség volt az alkalmazást a desktopra helyezni, és remote-ban végigmenni a legfontosabb forgatókönyveken. Bár ingyenes volt, de hosszú várakozási idővel kellett elérni az eszközöket. Mégis, ez a teszt reményt adott a fejlesztőknek, hogy a szoftver megfelelően fog működni a különböző okostelefonokon, és így nem jelentkeznek felhasználói problémák.

Ezen kezdetleges emulátorok evolúciója arra a pontra jutott, hogy fejlesztői módban futó, mobiltelefonokon is futtatható szkripteket is lehetett már írni, melyek könnyen utánozták a felhasználói műveleteket az eszközökön – ezt követően létrehoztak olyan DevOps-eszközöket, amelyek ezeket a szkripteket több ezer mobileszközön automatikusan képesek létrehozni és futtatni. Ezeken az eszközökön vannak telepítve a célalkalmazások, melyek fejlesztői módban futnak.

Mire használhatjuk az eszközfarmot:

  • Alkalmazások automatizált tesztelésére különféle tesztelési keretrendszerek segítségével
  • Távoli hozzáférést nyújt eszközökhöz, amelyeken valós időben töltheti be az applikációt, futtathatja és kommunikálhat velük

Milyen előnyei vannak az eszközfarmnak?

  • Lehetővé teszi a tesztelés során felmerülő munkaerőköltségek jelentős csökkentését, valamint az eszközök lefedettségének növelését
  • Több ezer különböző konfigurációjú eszközhöz férhetünk hozzá
  • Emulátorokat és szimulátorokat is használhatunk
  • A felhőalapú tesztelés lehetővé teszi a teljesítményproblémák rögzítését is
  • Rengeteg eszközzel rendelkezik úgymint: különböző operációs rendszer-platformokkal, képernyőtájolásokkal, kijelzőméretekkel, memóriával, hálózattal stb.
  • Csökkenti az általános karbantartási és infrastrukturális költségeket
    • párhuzamos tesztelést végezhetünk, amellyel rengeteg időt takaríthatunk meg
    • biztonságos, és bárhonnan elérhető
  • A tesztelés során részletes riportokat nyerhetünk ki, ezáltal könnyebbé válik a hibák észlelése és javítása is
  • Könnyen integrálható a CI/CD-folyamatba, megkönnyítve az együttműködést más csapatokkal

Többféle mobileszközfarmok léteznek, no de miben különböznek egymástól?

Az összes eszközfarm valamilyen speciális szkriptet használ, amit az operációs rendszer indít el olyan műveletek szimulálására, mint a gombnyomások, érintések stb.

A fő különbség az, hogy az eszközfarmok milyen alrendszereket használnak a parancsfájlok futtatására – a népszerűek közül csak néhányat említsünk: Espresso, Appium, Calabash, UI Automator, Robotium, XCTest.

Vége

Még nincs vége!

A következő részben bemutatjuk a legismertebb eszközfarmokat.

Jó tesztet!

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

Miért nem szabad a fejlesztőnek a saját kódját tesztelnie?

A fejlesztő megírja a funkciót. Megírja hozzá a teszteket is – alaposan, lelkiismeretesen. Minden teszt zöld. A kód átmegy a pipeline-on, kimegy élesbe. Két héttel később a rendszer elhasal egy olyan eseten, amire senki nem gondolt. A tesztek nem hazudtak. Egyszerűen nem a jó kérdést tették fel. Ez a cikk nem arról szól, hogy a

Mennyi pénzbe kerül egy későn megtalált hiba?

Képzeljünk el egy egyetlen félreérthető mondatot egy több száz oldalas követelményspecifikációban. A mondat egy kerekítési szabályról szól, és kétféleképpen is értelmezhető. A fejlesztő az egyik értelmezés szerint kódolja le – teljesen logikusan, jóhiszeműen, a saját olvasata alapján. Ha ezt a mondatot valaki a specifikáció átolvasásakor megkérdőjelezi, a „javítás” költsége nagyjából tíz perc: egy tisztázó kérdés

A tesztelés nem költség, hanem bevételvédelem

Képzeljünk el egy hétfő reggeli vezetői értekezletet, ahol a pénzügyi igazgató (CFO) a negyedéves költségvetést vizsgálva megáll a „Minőségbiztosítás (QA) és Szoftvertesztelés” sornál. „Miért költünk ennyit arra, hogy hibákat keressünk a kódunkban? Nem lenne egyszerűbb, ha a fejlesztőink eleve jobban figyelnének, és hibátlan kódot adnának ki?” – hangzik el a klasszikus kérdés. Ez a felvetés

Scroll to Top