Jak testovat Android notifikace a deep linky

Notifikace může mít správný text, a přesto přivést uživatele na nesprávnou obrazovku. Nebo backend vytvoří událost, ale Android nic nezobrazí, protože uživatel nepovolil upozornění. Spolehlivý test proto neověřuje pouze jednu bublinu v systémové liště, ale celý tok od události na serveru až po konkrétní obsah otevřený v aplikaci.

Jeden scénář prochází několika vrstvami

U zprávy „Objednávka byla odeslána“ spolupracují nejméně čtyři části systému:

Backend vytvoří událost. Objednávka změní stav a server připraví zprávu pro konkrétní instanci aplikace nebo uživatele.
Doručovací služba přijme zprávu. Může jít například o Firebase Cloud Messaging (FCM). Přijetí požadavku službou ještě nepotvrzuje, že se notifikace zobrazila na zařízení.
Android a aplikace zprávu zpracují. Výsledek závisí na typu zprávy, stavu aplikace, verzi systému, oprávnění k notifikacím a nastavení kanálu.
Klepnutí otevře cíl. Deep link neboli odkaz na konkrétní místo v aplikaci musí otevřít správnou objednávku a vytvořit smysluplnou navigační historii.

Pokud test začne až klepnutím na připravenou notifikaci, neověří backend ani doručení. Pokud skončí kontrolou textu v systémové liště, neověří deep link. Tyto dílčí testy jsou užitečné při diagnostice, ale alespoň jeden klíčový scénář potřebuje projít celý dohodnutý tok.

Sestavte matici podle stavu, ne podle počtu telefonů

Nejdůležitější kombinace vznikají ze stavu aplikace a účtu:

Aplikace je v popředí. Při FCM se zpráva v popředí předává aplikačnímu handleru; viditelnou notifikaci proto může vytvářet samotná aplikace.
Aplikace je na pozadí. U notifikační FCM zprávy může systém vložit upozornění do lišty a údaje pro navigaci zpřístupnit po klepnutí.
Cold start. Proces aplikace neběží a po klepnutí se musí vytvořit od začátku. Deep link se nesmí ztratit během inicializace.
Warm nebo hot start. Proces či obrazovka už existují. Nový odkaz musí aktualizovat navigaci bez otevření staré položky nebo vytvoření duplicitních obrazovek.
Uživatel je přihlášený nebo odhlášený. Chráněný cíl může vyžadovat přihlášení a po něm pokračování na původně požadovaný obsah.

Do matice přidejte povolené, zamítnuté a dosud nevyžádané notifikace. Od Androidu 13, tedy API úrovně 33, používají běžné notifikace runtime oprávnění POST_NOTIFICATIONS. Oficiální dokumentace Androidu uvádí také ADB příkazy pro přípravu jednotlivých stavů oprávnění, takže test nemusí záviset na tom, co na zařízení zůstalo po předchozím běhu.

Realistický příklad: změna stavu objednávky

Představte si testovací objednávku A-4821, která čeká na odeslání. Test se přihlásí vyhrazeným účtem, alespoň jednou otevře aplikaci, aby se zaregistrovala k přijímání zpráv, a uloží identifikátor zařízení k tomuto účtu. Přes bezpečné testovací API poté změní stav objednávky na „odeslaná“. Backend má vytvořit jednu událost s identifikátorem objednávky, uživatele a cílem deep linku.

Nejprve se ověří záznam na serveru: událost vznikla pouze jednou, patří správnému účtu a neobsahuje cíl jiné objednávky. Poté se aplikace přesune na pozadí a test čeká na upozornění. Úspěchem není jen text „Objednávka byla odeslána“. Po klepnutí se musí zobrazit objednávka A-4821, stav „odeslaná“ a odpovídající položky. Tlačítko Zpět má vést na seznam objednávek, ne znovu otevřít stejný detail.

Stejný obchodní případ je vhodné rozdělit na menší varianty. U cold startu test před klepnutím zastaví proces aplikace, ale ponechá její data a přihlášení. Ve warm stavu nechá aplikaci na detailu jiné objednávky a ověří, že nový deep link obsah nahradí. V odhlášeném stavu má aplikace přesměrovat na přihlášení a po úspěšném ověření pokračovat k A-4821; pokud to produkt záměrně nedělá, musí test místo toho potvrdit dohodnutý bezpečný cíl.

Nakonec přijde negativní varianta: oprávnění k notifikacím je zamítnuté. Backendová událost může vzniknout správně, ale systémové upozornění se nemá očekávat. Test potom ověří, zda aplikace po otevření zobrazuje nový stav objednávky a zda uživateli přiměřeně vysvětlí možnost upozornění zapnout. Tato varianta odděluje chybu produktu od platného rozhodnutí uživatele.

Postup od události po cílovou obrazovku

1. Připravte jednoznačná testovací data

Vytvořte například objednávku s jedinečným identifikátorem a známým počátečním stavem. Stejný identifikátor použijte v backendových logách, zprávě i očekávání testu. Při selhání pak dokážete spojit serverovou událost s tím, co zařízení přijalo a otevřelo.

2. Ověřte vznik události samostatně

Test na API nebo integrační vrstvě potvrdí, že správná obchodní událost vytvořila zprávu pro správného příjemce a obsahuje potřebný cíl. Samostatný test zde pomáhá odlišit chybu backendu od problému na zařízení. Produkční rozesílání není nutné používat, pokud existuje bezpečný testovací endpoint nebo izolované testovací prostředí.

3. Nastavte stav aplikace a oprávnění

Před během výslovně určete, zda má být aplikace spuštěná, na pozadí, nebo zastavená. Stejně nastavte stav přihlášení a oprávnění k notifikacím. Nástroje Appium a Maestro umějí ovládat aplikaci i systémové prvky; Maestro navíc umožňuje při spuštění nastavit vybraná oprávnění. Konkrétní podporu je však potřeba ověřit na použitém ovladači, verzi Androidu a typu zařízení.

4. Rozlište doručení od zobrazení

Kontrolujte, zda zpráva dorazila na určené zařízení, zda se zobrazil správný název, text a kanál a zda nevznikla duplicita. Při zamítnutém oprávnění je správným výsledkem spíše srozumitelné chování aplikace než viditelná systémová notifikace. Test nemá oprávnění potichu zapnout, a tím obejít reálnou cestu uživatele.

5. Klepněte a ověřte význam, nejen název obrazovky

Po klepnutí ověřte ID nebo obsah konkrétní objednávky, zprávy či úkolu. Samotný nadpis „Detail“ nestačí. Zkontrolujte také tlačítko Zpět: uživatel by se měl dostat na očekávané místo, ne na prázdnou obrazovku nebo ven z aplikace.

Deep link testujte také přímo, bez notifikace. Android podporuje spuštění URI přes ADB a obdobnou operaci nabízejí Appium (mobile: deepLink) i Maestro (openLink). Tím oddělíte chybu routingu od chyby doručení. U odkazů na vlastní webovou doménu ověřte také Android App Links, včetně manifestu a souboru assetlinks.json; obyčejný webový odkaz se může podle verze systému a uživatelských nastavení otevřít v prohlížeči.

6. Sbírejte důkazy z každé vrstvy

Jedinečný korelační identifikátor vložte do backendové události, testovacího záznamu o odeslání a podle možností také do datové části zprávy. Nemusí se zobrazovat uživateli. Při selhání podle něj propojíte serverový log, odpověď doručovací služby, log zařízení a konkrétní běh testu bez odhadování podle podobného času.

U každé vrstvy si předem určete důkaz úspěchu. Backend může potvrdit vytvoření jedné zprávy, doručovací služba přijetí požadavku, zařízení zobrazení správného kanálu a aplikace konkrétní obsah po klepnutí. Tyto signály nejsou zaměnitelné: přijetí zprávy službou nepotvrzuje zobrazení a otevřený detail nepotvrzuje, že uživatel přišel přes systémovou notifikaci.

Neověřujte přesnou dobu doručení jedním krátkým pevným čekáním. Síť, úsporné režimy a plánování systému mohou čas ovlivnit. Nastavte přiměřené časové okno podle účelu testu, zaznamenejte skutečný čas jednotlivých kroků a při jeho překročení uložte diagnostiku. Pro produkt s časově kritickými upozorněními je vhodné požadovaný limit definovat jako samostatný provozní požadavek a měřit jej ve vhodném prostředí, ne jej odvodit z jednoho automatizovaného běhu.

Hraniční stavy, které odhalí nejvíce problémů

Ověřte neexistující nebo již odstraněný cíl, expirovanou relaci, odhlášení na jiném zařízení a dvě notifikace otevřené v opačném pořadí. Aplikace má v těchto případech zobrazit bezpečný a srozumitelný náhradní stav, ne cizí obsah nebo nekonečné načítání.

Systémové dialogy a chování při doručení se mohou lišit mezi verzemi Androidu a úpravami výrobců. Rychlé scénáře proto lze vyvíjet na emulátoru, zatímco rozhodující tok je vhodné zařadit také do cíleného pokrytí na reálných zařízeních. Výběr zařízení popisujeme v článku Emulátor nebo reálné zařízení.

Co spouštět často a co ponechat na širší běh

Při každé relevantní změně může rychle běžet přímý test deep linku, navigace a přihlášeného či odhlášeného stavu. Nemusí čekat na externí doručení a přesněji ukáže chybu v routingu. Integrační test backendu může podobně ověřovat vytvoření správného payloadu bez systémového rozhraní Androidu.

Celý tok přes skutečnou doručovací službu a systémovou lištu je pomalejší a citlivější na prostředí. Zařaďte jej pro nejdůležitější typy upozornění do pravidelného běhu nebo kontroly před releasem a použijte omezený výběr verzí Androidu a zařízení podle rizika. Při automatizaci systémové lišty upřednostněte dostupné systémové identifikátory a význam prvků před souřadnicemi; přesný text systémového tlačítka se může měnit s jazykem nebo verzí systému.

Takové rozdělení nevytváří dva konkurenční testy. Rychlá vrstva chrání pravidla aplikace a navigaci, zatímco menší počet celých běhů ověřuje skutečné propojení vrstev. Když celý scénář selže, dílčí testy pomohou určit místo problému.

Co tím získáte

Rozdělení toku na vrstvy zkrátí diagnostiku. Když test selže, tým ví, zda událost nevznikla, zpráva se nedoručila, systém ji nezobrazil nebo aplikace nesprávně zpracovala odkaz. Matice stavů zároveň pokryje rozdíly, které jeden úspěšný klik na otevřené aplikaci neukáže.

Další krok

Vyberte jednu notifikaci s vysokým dopadem a zakreslete její cestu od backendové události po cílovou obrazovku. Připravte samostatný test události, samostatný test deep linku a jeden celý scénář pro přihlášený cold start. Potom přidávejte další kombinace podle rizika, ne mechanicky podle každé obrazovky.