Testování Androidu: AWS Device Farm vs Firebase TestLab

Uplynul celý rok, co jsem začal pracovat na řešení pro testování automatizace Android na projektu pro velkou společnost. Projekt je nyní předán jinému týmu a je čas podělit se o cenné zkušenosti.

Naší úlohou bylo automatizovat pouze testy E2E. Jedním z prvních rozhodnutí, které jsme museli učinit, je vybrat dostatečně vážnou společnost, která poskytuje služby „pronájmu“ všech druhů fyzických zařízení pro účely testování. Nejprve jsme mysleli na řešení s vlastním hostingem, které by bylo možné zapojit do potrubí Cl, ale nikdy jsme nemohli poskytnout dostatečně rozmanitou rozmanitost zařízení. Proto jsme začali hledat cloudová řešení.

Protože jsme potřebovali řešení podporující platformy Android i iOS s velkým počtem různých zařízení, společnost AWS DeviceFarm si vybrala jako řešení, kterému bychom mohli věřit, že bude dostatečně stabilní, s pohotovou podporou a snadnou obsluhou.

AWS DeviceFarm

Při prvním použití pravděpodobně službu vyzkoušíte prostřednictvím webového uživatelského rozhraní. Pro zahájení zkušebního běhu je třeba provést pouze několik povinných kroků:

  • Vyberte typ testu: Instrumentace
  • Nahrajte testovací apk
  • Nahrajte aplikaci apk
  • Vyberte zařízení (vytvořte tzv. Pool zařízení)
  • Pokud nepotřebujete žádný další datový balíček, klikněte na tlačítko Spustit.

A v podstatě je to. Testy budou probíhat na vybraných zařízeních a pokud bude vše v pořádku, zobrazí se souhrnná statistika úspěšnosti / neúspěchu na zařízení a podrobný seznam úspěšných a neúspěšných testů.

Pro každý test budete mít ve výchozím nastavení k dispozici protokol přístrojů, logcat a video.

Webové uživatelské rozhraní se však při použití kanálu CI příliš nepoužívá, takže pro sestavovací server musíme použít buď AWS CLI nebo nějaký plugin. Používali jsme Jenkins, který má podporu pro komunikaci AWS DeviceFarm (samozřejmě prostřednictvím pluginu).

Fungovalo to velmi dobře, alespoň pokud jde o provádění testů. První obrovský problém, na který jsme narazili, byl nedostatek hlášení. Neexistuje žádná možnost přidat e-mail nebo e-maily, které by měly obdržet zprávu o testování. Ve skutečnosti neexistuje žádná zpráva, dokonce ani přehledná, která by mohla být předána klientovi. Zůstali jsme s možností umožnit přístup do našeho projektu AWS, aby bylo možné výsledky testování zkontrolovat prostřednictvím webu Ul.

Podpora JUnit4 - Deal breaker

Na straně Android byl testovací proces dost komplikovaný a museli jsme udělat několik kompromisů. Jedním z nich bylo vynutit přísné pořadí provedení testu z důvodu složitého a dlouhého postupu přihlašování v aplikaci.

Za tímto účelem jsme jako první krok vytvořili přesné testovací sady. Praktické chování definice sady testů v Androidu spočívá v tom, že testovací třídy budou prováděny v pořadí, v jakém jsou definovány v anotaci @SuiteClasses.

Jako druhou část jsme museli objednat testy také uvnitř testovacích tříd, což jsme provedli s jedinou dostupnou možností: anotace @ FixMethodOrder.

A to byl konec cesty pro nás s AWS DeviceFarm, protože implementují JUnit4 pouze částečně, bez podpory definice testovacích sad ani FixMethodOrder! Protože jsme byli vynecháni z možností, museli jsme opustit službu, protože jsme nemohli provést testy, jak jsme chtěli.

Firebase TestLab

Než jsme opustili AWS, museli jsme se ujistit, že najdeme službu, stále dostatečně vážnou as dobrou podporou, která nemá tato omezení JUnit4. Zkusili jsme Firebase a fungovalo to.

Prostřednictvím webového uživatelského rozhraní jsou kroky nastavení téměř identické s AWS:

  • Vyberte typ testu: (také instrumentace)
  • Nahrajte oba APK
  • Vyberte zařízení
  • Běh.
  • Sledujte výsledky testu na zařízení a na test s přístupem k záznamu videa a protokolům.

Webové uživatelské rozhraní samozřejmě nemůžeme použít, takže nakonec používáme řešení CLI pro Firebase: gcloud.

S gcloud jsme schopni definovat typ testu, cesty k apk souborům, adresář výsledků a kbelík v Google Cloud Storage a test-target, který kromě všech standardních možností, jako je testovací balíček nebo individuální test, akceptuje také testovací sada jako cíl při respektování pořadí provedení.

Přestože Firebase TestLab funguje podobným způsobem jako AWS DeviceFarm, spoléhá se na zásobník Google, a proto ukládá všechny výsledky testů do kbelíku v Google Cloud Storage, což je úžasné, protože můžeme k souborům přistupovat přímo.

Malá poznámka zde: Pro definování vlastního segmentu a cesty pro provedení testu je vyžadován placený přístup k Google Cloud Storage. V případě využití volného úložiště budou výsledky testu uloženy do adresáře testlab / random-hash a po 90 dnech budou odstraněny.

Protože jsme měli přístup k výsledkům testů přímo, mohli jsme sestavit testovací zprávu tak, jak jsme chtěli, což se našim klientům opravdu líbilo. Přesto bych rád zmínil, že Firebase také neposkytuje řešení pro hlášení systému, kde bychom mohli vytvořit pouze seznam adres, abychom dosáhli výsledků. Ve výstupu konzoly má výsledky na zařízení.

Časové limity:

Ačkoli nám Firebase dává možnost testovacích souprav běžet, nepřijde to zdarma. Maximální časový limit pro provedení testu je 30 minut. To je více než dost pro 90% případů použití, ale v našem případě se jedna testovací sada obsahující všechny testovací třídy ukázala jako problematické řešení, protože naše testy E2E provádějí 60 a více minut.

Důvodem tohoto 30minutového limitu je podle diskusí na fórech Google a Slack stabilita systému, takže kompromis našli 30minut. Provádění čehokoli jiného, ​​než co by bylo přerušeno bez jakýchkoli výsledků.

Tento problém jsme vyřešili vytvořením mnoha malých testovacích souprav, které jsou prováděny jeden po druhém, se samostatnými voláními gcloud. V důsledku toho bylo generování zpráv ještě složitější, ale přinejmenším možné, což nám nakonec poskytlo pracovní řešení.

Srovnání:

Zde se pokusíme shrnout výhody a nevýhody obou služeb:

  1. Jednoduchost CLI: Firebase
  2. Dostupnost pluginů: AWS
  3. Systémové zprávy (seznam adresátů): Žádné
  4. Dostupnost zpráv: Firebase
  5. Přehled zprávy: Firebase
  6. Výběr zařízení: AWS (Firebase má 15-20 různých zařízení)
  7. Aktuální kompatibilita: Firebase
  8. Dostupnost podpory: Firebase (téměř okamžitě přes Slack)
  9. Dálkové ovládání zařízení: AWS
  10. Stabilita systému: AWS (Na Firebase jsme měli na některých zařízeních hodně „selhání infrastruktury“)
  11. Integrace IDE: Firebase
  12. Podpora pro iOS: Obě (s malou výhodou pro AWS, protože podpora Firebase XCUITest je v době psaní v uzavřené beta verzi)

Tento seznam by mohl pokračovat a dále, ale jeho cílem není říci „Nikdy byste neměli používat službu X“. Chtěl jsem poukázat na problémy a výhody z příkladu skutečného světa.

Závěr

Jako uživatel těchto služeb mám všeobecný pocit, že neexistuje velká svoboda volby. Protože naše požadavky a očekávání jsou vyšší, stěny, na které narazíme, jsou také vyšší a stává se to často. Nejhorší na tom je, že si nemůžete být vědomi všech těchto drobných problémů při rozhodování. Kdo by přemýšlel o problémech JUnit4 na AWS ... ale stává se to.

Poznámka: Tyto služby se používají na neomezené placené plány, včetně provozu generovaného na Google Cloud Storage. V důsledku bezplatného nebo zkušebního použití neexistovala žádná omezení služeb.

Buďte opatrní!