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

A legtöbb tesztstratégia már a projekt elején elbukik

Amikor egy projekt a végén minőségi gondokkal küzd, a reflex szinte mindig ugyanaz: a tesztelést okoljuk. „Nem teszteltek eleget”, „átcsúszott egy hiba”, „a QA nem fogta meg”. Kényelmes magyarázat, mert a folyamat legvégére mutat, oda, ahol a baj láthatóvá vált. Pedig a valódi ok gyakran nem a tesztelésben rejlik. Maga a tesztstratégia dönti el jó

AI rendszerek tesztelése: miért teljesen más, mint egy hagyományos szoftveré?

Egyre több cég épít AI funkciót a termékébe: chatbotot az ügyfélszolgálatra, ajánlórendszert a webshopba, dokumentumfeldolgozót a háttérfolyamatokba, döntéstámogatót a szakértői munkába. A vezetők jó része ilyenkor ugyanúgy áll a teszteléshez, mint bármely más szoftvernél: „írjuk meg a teszteseteket, nézzük meg, átmegy-e”. Csakhogy egy AI rendszer másképp működik, és ami fontosabb: másképp is hibázik. Ezért másképp

AI által generált kód = új QA kihívások

Az AI asszisztensek (a GitHub Copilottól a különféle nagy nyelvi modellekig) néhány év alatt a szoftverfejlesztés mindennapi eszközévé váltak. Egy funkció, amelynek megírása korábban órákba telt, ma percek alatt elkészül. A fejlesztői produktivitás növekedése valós és mérhető. Csakhogy a sebesség önmagában megtévesztő mutató. A kód gyorsabb megírása ugyanis nem jelenti azt, hogy a kód jobb

Scroll to Top

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.