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

Hogyan épül fel egy jól működő tesztelési stratégia? – A szoftverminőség tervrajza

Tegyük fel, hogy egy hatalmas felhőkarcolót kell építeni egy forgalmas belváros közepén és megvannak hozzá a szakképzett munkások, a legmodernebb munkagépek és a prémium alapanyagok. Azonban van egy apró, de annál kritikusabb bökkenő: nincs részletes tervrajz. Mindenki tudja nagyjából, mi a dolga – a kőműves falat húz, az asztalos ablakot épít be, a villanyszerelő pedig

Mi az a regressziós tesztelés, és miért ez a szoftverminőség záloga?

Ismerős a helyzet? A fejlesztőcsapat éppen csak élesített egy ragyogó új funkciót, amitől mindenki a felhasználószám robbanásszerű növekedését várja. Az öröm azonban rövid ideig tart: alig egy órával a kiadás után érkeznek az első dühös hibajegyek. Az új funkció ugyan remekül működik, de valamilyen rejtélyes módon a bejelentkezés gomb megszűnt létezni, vagy a fizetési folyamat

Hogyan gyorsítja a tesztelés a release ciklust? A sebesség és a minőség szimbiózisa

„A tesztelés lassít.” Ez az egyik leggyakoribb tévhit a szoftverfejlesztési projektekben, ami gyakran vezet oda, hogy a release határidők közeledtével a minőségbiztosítás az első, amit feláldoznak a gyorsaság oltárán. A szemléletmód alapja a hagyományos, lineáris fejlesztési modell, ahol a tesztelés egyfajta „végellenőrzésként” funkcionál, ami megakasztja a folyamatot. A valóság azonban az agilis és DevOps környezetben

Scroll to Top