A jégkorszaktól a bosszúállóig az Appium segítségével

Tanulságok a Kite's Robot megközelítésből

Hadd kezdjem itt egy unalmas horoggal: az alkalmazás kézi tesztelésével kapcsolatos személyes tapasztalataim. Mivel a termékfejlesztés magában foglalja a bitek és darabokat is, a mondatbiztosítási csapat tagjai számára monoton lesz ugyanazokat a műveleteket újra és újra elvégezni. Minden alkalommal, amikor tesztelnem kellett valamit, friss felhasználóra volt szükségem, és így új felhasználót kellett manuálisan regisztrálnom. Unalmasabb, mint amilyennek hangzik.

Itt jön a kép az automatizálás. Mi lenne, ha időt írnánk egy olyan kód írására, amely mindezt unalmas munkát elvégzi nekünk? Mi lenne, ha ez is pontosan működne?

A Kite QA csapata meglehetősen sok kutatást és fejlesztést végzett a megfelelő eszközök megtalálása érdekében. Az Appium mellett döntöttünk, mivel:

  1. Nyílt forráskódú
  2. Nem szükséges a forráskód
  3. Nincs szüksége műszerezésre
  4. Rengeteg támogató anyagot kínál könnyen

Az Appium függetlenül attól, hogy a legtöbbünk rakéta tudományának érezze magát. Ha azonban megfelelő megközelítést követ, akkor lehetőségeit teljes mértékben kihasználhatja.

Ebben a bejegyzésben kiemelem az Appium klasszikus megközelítésének hátrányait, és azt, hogy a Kite-i robot-megközelítés miként teszi az Appiumot viszonylag gondtalan élménnyé. A Robot megközelítést a Kite első alkalmazásában, a Kite Cash-ben használtuk. Kísérleti célokra indították, és szervesen ballonba helyezte a több mint 100 000 felhasználóval rendelkező hálózatba, több mint 1100 városban.

Klasszikus megközelítés

Általánosságban elmondható, hogy a klasszikus megközelítés szorosan kapcsolt kódot tesz lehetővé, amely nem fenntartható, növeli az redundanciákat, megnehezíti a refaktorozást és nem méretezhető.

Tekintettel ezekre a korlátozásokra, közelítsünk az Appium-hoz mint történethez.

Klasszikus forgatókönyv

Fontolja meg a bejelentkezési képernyőt felhasználónévvel, jelszóval és bejelentkezési gombbal. Ha helyesen írom be a hitelesítő adatokat, és rákattintom a „Bejelentkezés” elemre, akkor képesnek lennék arra, hogy bejelentkezzek és megtekintsem a következő képernyőt.

A tesztre gondolva az alábbi kérdéseket tesszük fel: mit akarunk elérni? és hogyan érjük el? Korábbi megközelítésünk szorosan összekapcsolta ezt a Mit és Hogyan. Ha azonban ezt a párot együtt tartják, akkor a QA megnehezíti a szkriptek fenntartását és méretezését. A probléma elkerülhetetlenül az, hogy az üzleti igények megváltoznak, és ennek az összekapcsolásnak köszönhetően változtatnunk kell a teszten. Íme egy példa:

Mit kell elérni: a helyes felhasználónév / jelszó megadásával a felhasználót a műszerfal képernyőjére kell vinni.

  • Írja be a „hulk@spiderman.com” felhasználónevet
  • Írja be a „HS @ 1235” jelszót
  • Nyomja meg a „Bejelentkezés” gombot
  • Ellenőrizze, hogy megjelenik-e az irányítópult képernyő

Vegye figyelembe a kódot:

Lássuk, milyen problémák vannak ebben a megközelítésben:

  1. Magas szintű kód-másolat van, ami tovább rontja az automatizálás teljesítményét.
  2. A fenti kód nem olvasható. Az olyan gyorsan növekvő vállalatoknál, mint a Kite (és még sokan mások), az új tagok folyamatosan egyesülnek az egyes csapatokkal. Egy új tag nem fogja megérteni ezt a kódot és céljait, ha a kód megírása után csatlakoztak.
  3. A közeljövőben nem leszünk kényelmesek kezelni ezt a fajta kódot, amikor növekszik az alkalmazások munkafolyamata.
  4. Az új felhasználói felület beépített változásait nehéz belefoglalni az ilyen típusú kódba, mert a refaktálásnak - több ponton - sok mindent meg kell történnie ahhoz, hogy újra működjön.

Nyilvánvaló, hogy a klasszikus megközelítés könnyűnek tűnhet, de amint egy alkalmazás jellemzői növekednek, a kód kezelése fejfájást okoz.

Robot megközelítés

Mi lenne, ha olyan megközelítést követnénk, ahol csak arra koncentrálunk, mit akarunk elérni? és nem Hogyan akarjuk elérni? Ezután különféle osztályokat hozunk létre a Hogyan és Miért. Így a Hogyan és a Milyen kategóriák függetlenek egymástól.

A Robot tesztelési mintázata hasonló a széles körben használt Page Object Model-hez, amely egy olyan tervezési minta, amely webes platformok felhasználói felületének objektumtárának létrehozására szolgál.

Jelenleg a manuális felhasználóra támaszkodunk a műveletek végrehajtására. Mi lenne, ha a robotok mindezt nekünk tennék? A Robot megközelítésben tudjuk, hogy a képernyő lehetővé teszi a felhasználónév / jelszó bevitelét anélkül, hogy magunkkal meg kellene győződnünk arról, hogy hova kerülnek ezek az értékek.

Robot forgatókönyv

Egy robot létezik a UsernamePasswordScreenBot oldalon, amely átadja az értékeket a felhasználónév / jelszó mezőkben, és rákattint a „Bejelentkezés” gombra. Most, a képernyő megváltozik, és ez a robot csak a LoginPasswordScreenBot osztály felett tudja irányítani. Innentől egy másik bot veszi át, mondjuk, egy ResultScreenBotot, hogy a következő képernyőn további műveleteket hajtson végre.

Más szavakkal, képernyőnként hozzon létre egy robotot, amely elvégzi a szükséges műveleteket.

Dőljön hátra, pihenjen, és hagyja, hogy a robotok az Ön számára dolgozzanak.

Ez a kód megmagyarázza, hogy mit akarunk, vagyis hogy megadhatunk egy felhasználónevet és jelszót, amelyből be kell jelentkezni a felhasználóba.

Összehasonlítás

Hasonlítsuk össze a mutatókat és a teljesítmény változásait a klasszikus megközelítésben és a Robot megközelítésben:

  1. A kód sokszorosítása minimálisra csökken, mivel az elem azonosítókat egy osztályba helyezzük, és minden alkalommal ugyanazt az osztályt használjuk.
  2. A kód olvashatóság javult, mivel egy új tag, aki csatlakozik a csapathoz, megérti, mit csinál ez a kód intuitívabban.
  3. Az ilyen kód kezelése és az felhasználói felület változásaihoz való alkalmazkodás most már egyszerûbb. Cserélje ki a kódot egy helyen, és ez a változás mindenütt visszatükröződik. Vegyünk egy példát: a bejelentkezési folyamatban megváltozik egy elem azonosítója vagy új mező kerül hozzáadásra. A klasszikus megközelítés során változtatásokat kell végrehajtanunk minden olyan ponton, ahol bejelentkezünk. A Robot megközelítésben csak hozzáadjuk vagy szerkesztjük az LoginPasswordScreenBot osztály elemeit, és közvetlenül innen hívjuk.

Robot tesztelési köre

Először azt gondolhatjuk, hogy a botok nem elég okosak ahhoz, hogy elvégezzék a Sanity-tesztet vagy lefedjék a negatív áramlásokat. A robotjainak azonban negatív hatása van, a józanság és a regressziós tesztelés az alábbi kódon keresztül történik - ezáltal néhány extra áhított percet tölt be ebédszünetére. Ehhez különféle módszereket kell létrehoznunk és átadnunk a tartalmat.

A fenti kód bemutatja, hogyan lehet módszereket létrehozni minden olyan adathoz, amelyet egyetlen osztályban továbbítani kíván. A klasszikus megközelítés arra összpontosított, hogy mit kell elérni és hogyan lehet elérni. Meg kell szabadulnunk a „Hogyan” alkotóelemtől, hogy egyszerűbbé tegyük a dolgokat.

Időmegtakarítás és kapacitásépítés

Figyelemre méltó időt takarítottunk meg és megnöveltük képességeinket, ha a Robot megközelítésre váltottunk.

  1. Tesztelési lefedettségünk nőtt a kézi teszteléshez képest.
  2. Egy egész napról 5-10 percre csökkentettük a Sanity befejezéséhez szükséges időt.
  3. 50% -kal csökkent a szkriptek létrehozásának ideje, és megoldottuk a skálázhatóság kérdését.
  4. A szkript megközelítés segítségével létrehozhatunk egy regressziós csomagot, amely egyszerűbbé és pontosabbá teszi a tesztelést.

Következtetés

A Kite-hez hasonló induló vállalkozásként rugalmasan próbáltam ki új dolgokat kipróbálni és időt fektettem a kutatásba - emiatt új módszert kaptam az Appium használatához. A Kite-nél dolgozó rendkívül támogató csapatnak köszönhetően minden nap jobb gyakorlatokkal találkozom. Nyílt csere útján képesek voltunk olyan innovációra, amely hatékonyabbá, eredményesebbé és szórakoztatóbbá tette munkánkat. Ha az Ön munkahelye támogatja, arra ösztönzem Önt, hogy szervezzen tudásmegosztó üléseket, és hetente külön órákat állítson össze új technikák kísérletezésére; ez a leghatékonyabb módja annak, hogy hosszú távú stratégiákat dolgozzon ki annak érdekében, hogy csapata szoros és folyamatos innovációt tartson fenn.