Представьте себе страшный сон тестировщика и в целом вашей команды – пользователи пишут в поддержку, что пуши не приходят, сообщения не доходят, а вы никак не можете воспроизвести проблему и у вас даже нет понимания: а как это воспроизводить, от чего вообще зависит доставка пушей?
Посмотрев русскоязычные и англоязычные ресурсы про тестирование, я так и не смог найти полноценного материала, который бы гарантировал достаточные знания для того, чтобы понимать как пуши и уведомления работают, как их тестировать и что не маловажно как искать и разбираться с проблемами, когда пуши не доходят до пользователей.
Я Арман, и сегодня я хочу вам рассказать про пуши ?
Тестирование пушей и уведомлений в приложениях, где они играют ключевую роль, таких как социальные сети, мессенджеры, банковские приложения, интернет-магазины и даже игры становится важной частью процесса обеспечения качества.
Быстрая и точная доставка уведомлений имеет критическое значение для эффективной передачи важных сообщений и способствует регулярному возвращению пользователей в приложение. Также стоит отметить, что пуш-уведомления могут заменить дорогостоящие SMS, использоваться для вывода акций и промо-сообщений, а также передавать невидимые конфигурационные сообщения для приложения.
Тестирование позволяет выявить проблемы в доставке, отображении и взаимодействии с уведомлениями, обеспечивая безупречный пользовательский опыт.
Что же нужно знать и понимать, чтобы тестировать пуши и уведомления успешно? Попробую сегодня ответить на этот вопрос, раскрыв в этой статье следующие темы:
Что такое пуш, а что уведомление и почему их нужно различать.
Какие виды пушей и уведомлений могут быть в вашем приложении.
Почему доставка пуша не означает, что уведомление было показано.
❗️Прошу обратить внимание, что некоторая часть материала будет рассказывать только про пуши в Android, однако общая тема статьи должна быть полезна при тестировании и разработке любой из платформ. Некоторые разделы в том числе должны быть полезны разработчикам, которые находятся в поиске решений связанных с пушами.
Что такое пуш, а что уведомление и почему их нужно различать.
Чтобы писать правильные тестовые сценарии и разбираться в причинах проблем с пушами и уведомлениями, надо разобраться в терминологии и понимать, что такое пуш, а что такое уведомление. Многие ошибочно считают что это одно и тоже, но на самом деле пуши и уведомления хоть и имеют связь, но могут обходиться друг без друга.
Тут важно понимать, что я не докапываюсь до слов, если кто-то называет всё это пушами, но разницу понимает, то всё ок, совершенно не важно как вы это называете.
Уведомление – это всплывающая плашка, звук, значок – элемент интерфейса призванный обратить на себя внимание пользователя. Чтобы показать уведомление, приложению не нужно ничего, оно может показать информацию без подключения к интернету, напомнить вам о каком-либо событии и всё в этом духе. Триггером для показа уведомления может быть что угодно, внутренняя логика приложения, таймер, или же push-сообщение!
Push – пуш это сообщение! Сообщение в специальном формате , которое должно быть обработано на телефоне. Оно приходит через специального посредника – сервиса пуш-сообщений через интернет. Обычно им выступает сервис от производителя операционной системы (APNS - Apple, FCM - Google, HMS - Huawei) но также могут использоваться альтернативные поставщики пушей. Как правило пуши нацелены на то, чтобы показать вам уведомление, однако это совсем не обязательное условие, и пуши могут быть неотображаемые и нужны приложению для обновления какой-нибудь внутренней информации.
Иными словами пуш может быть уведомлением, а может не быть, а уведомление может быть пуш-уведомлением, а может локальным (или внутренним, реализуемый по внутренней логике приложения в обход пуш сервера).
Уведомление - то что видим на экране, а пуш – это сообщение в виде json, которое отправляется с push-сервера на устройство пользователя.
Важно понимать это различие, так как оно позволяет нам правильно диагностировать причины почему какое-либо уведомление не отображается на смартфоне. А также, зная особенности и различия, мы сможем покрыть кейсами как уведомления так и пуши и их совместную работу, чётко понимая в каком месте что проверяется.
Например, если мы знаем что какой-то тип уведомлений в приложении не использует пуш, а показывается только при открытии приложения напрямую работая с нашим API, мы не будем, проверять подписки на пуши и другие параметры.
Точно также наоборот, если какая-то фича у нас использует механизм пушей, но не для показа уведомлений, а, например, для обновления данных, мы будем сразу знать куда смотреть.
Как пуши работают
Понимание того, как пуши работают, это уже 80% успеха при их тестировании, написании тестовых сценариев или выявлении проблем с ними.
Как я уже упоминал ранее у пушей есть посредник, это некий пуш-сервис – обычно предоставляется производителем устройства или системы (Apple Push Notification Service (APNS) – Apple, Firebase Cloud Messaging (FCM) – Google, huawei mobile services (HMS) –Huawei), но также может предоставляться какой-либо сторонней службой, например, как сервис пушей от RuStore. Многие из них могут работать как посредники для других, например fcm и hms также могут отправлять пуши через APNS, а RuStore со всеми ними, такое решение можно использовать для единой точки входа на бэкенде.
Ранее также был Mi Push services – Xiaomi, однако по последним заявлениям компании они больше не работают вне Китая. А также существуют такие альтернативы как pushy, я не стал глубоко копаться в логике работы, но судя по всему они являются прослойкой между клиентом и firebase, либо самостоятельно сохраняют соединение со своим сервером, что будет делать ваше приложение прожорливым в плане батареи.
Сервис пушей представляется собой систему облако-устройство, на устройстве служба имеет постоянное подключение к собственному облаку и имеет право разбудить приложение или показать пуш от его имени. Разработчики могут использовать этот сервис для быстрой и более стабильной доставки сообщений, так как она имеет высокий приоритет в системе.
Как это работает?
При запуске приложения или при логине приложение регистрируется в системе пуш сообщений и получает от него токен, который привязан к устройству пользователя.
Токен отправляется на ваш сервер, где хранится в базе и ассоциируется с этим пользователем.
Как только возникает необходимость отправки сообщения этому пользователю, например, пользователю отправили сообщение, сервер берёт токен пользователя и само сообщение и отправляет его в облако пуш-сервиса.
Облако уже в свою очередь по токену отправляет пуш на девайс, где служба сервиса принимает его и решает как поступить (показать, отложить или разбудить ваше приложение для обработки пуша).
Кроме точечных сообщений существуют также массовые, в этом случае приложение подписывается на конкретный тип пушей (топик) из которого сообщения будут отправляться на конкретный девайс автоматически, а наш бэкенд только отправляет сообщения в конкретный топик. Подробнее документация для fcm (android) и документация для APNS (работает начиная с 18 iOS).
Какие виды пушей и уведомлений могут быть в вашем приложении
После того как поняли как отличать пуши от уведомлений и как пуши работают, нужно разобраться, какие пуши бывают, в чём их отличие, а главное как от этого меняется поведение вашего приложения и уведомлений, которые она показывает.
❗️ Разбирать пуши буду в контексте FCM – как самый популярный сервис по отправке пуш-сообщений, который поддерживает в том числе отправку пушей на iOS через APNS. Основная логика примерно одинакова во всех пуш-сервисах, однако перед тестированием рекомендуется изучить подробнее документацию сервиса, который вы используете.
Пуши бывают нескольких видов:
Базовый (notification messages) – такое пуш-уведомление, содержит поле - notification, в котором можно указать только title, body, image . Оно показывается автоматически, когда приложение в фоне или выключено, если же приложение открыто, то ничего не будет показано.
{
"message": {
"token": "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvv...",
"notification": {
"title": "Breaking News",
"body": "Something exciting just happened!",
"image": "https://example.com/news-image.jpg"
}
}
}Data - пуши с полем data, в которое вы можете добавить собственные данные в формате ключ-значение, без поля notification. При получении такого сообщения система разбудит ваше приложение, чтобы оно его обработало. Ничего автоматически не показывается. Пуш доставляется до приложения в любом случае, приложение уже само реагирует на него, может показать уведомление, а может не показать.
Особенность, о которой многие не знают – такой пуш придёт и разбудит приложение даже, если пользователь не дал разрешение на показ уведомлений (потому что как уже писал пуш – это вам не уведомление).
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCI...",
"data":{
"name" : "Арман",
"body" : "Этот пуш никогда не покажется",
"silent" : "true",
"anything" : "Что угодно",
...
}
}
}-
Гибридные пуш-сообщения, Базовый + Data – содержат оба поля и notification и data, логика работы здесь зависит от состояния приложения в момент получения пуша.
Приложение в фоне или выключено - уведомление отрисовывается автоматически, используя только данные из поля notification, а данные из data будут переданы приложению, только, если пользователь нажмёт на уведомление.
Приложение на переднем плане - fcm передаст приложению весь пайлоад сразу и не будет ничего автоматически показывать.
Уведомления:
Дальше буду говорить про пуши, но будет неправильным не упомянуть какие бывают уведомления и какая логика может быть в них заложена.
Пуш-уведомления – собственно, то о чём говорили выше.
Локальное-уведомление – приложение само инициирует показ уведомления по своей внутренней логике, не обращаясь к бэкенду.
-
Собственная логика показа уведомлений – можно назвать подтипом для локальной логики, ниже приведу примеры. Здесь приложение может как обращаться к бэкенду, так и нет:
моментальный показ уведомлений, когда приложение включено
показ уведомлений в периоды, когда система будит приложения в сервисных целях, тут в том числе приложение может обратиться к бэкенду
некая запланированная активность по показу уведомлений используя сервисы системы, например для андроид WorkManager или AlarmManager
Постоянно висящее уведомление, позволяющее сохранять постоянное соединение с вашим бэкендом или информирующее о другой активности приложения.
Если у вас нет уверенности используется ли та или иная технология, вид уведомления или пуша в вашем приложение, то стоит уточнить это у разработчиков и задокументировать в базе знаний.
Понимание логики работы приложения, не только в контексте пушей - ключ к составлению правильных проверок при тестировании, и нахождению причин проблем.
Что влияет на доставку пушей
Если система настолько крутая и продуманная, то откуда возникают проблемы, что вообще влияет на пуши и почему ваши пуши могут не доходить до устройства?
Первое и главное пуш-сервисы не гарантируют, что ваш пуш будет доставлен! А уж тем более они не гарантируют, что пуш будет доставлен вовремя (даже если устройство пользователя включено и в сети).
Есть несколько основных причин из-за которых пуш может не доходить до устройства:
-
Приоритет пуша в FCM – его вы выставляете сами, однако, fcm оставляет за собой право его понизить, есть два приоритета:
нормальный – сообщения, которые можно отложить.
высокий – сообщения, которые должны быть доставлены максимально быстро.
-
TTL пуша – параметр времени жизни пуша, т.е. время, за которое пуш считается актуальным и есть смысл его доставить. Может быть от 0 до 2419200 сек. – 28 дней.
Если оно слишком маленькое, то пуш по просту может не успевать дойти до пользователя, по каким-либо причинам (снижен приоритет, пользователь не в сети, экономия заряда и др).
Значение 0 означает, что пуш актуален только сейчас, например, его можно использовать для пуша звонка. В этом случае fcm будет стараться доставить его немедленно, но если доставить не получается, то он уже никогда не дойдёт
-
Несворачиваемые пуши –
ℹ️ Сворачиваемыми называют уведомления, которые могут заменить предыдущее. Означает, что если предыдущее не дошло, то можно его отбросить и отправить только последнее.
Если несворачиваемых пуш-сообщений больше 100, то они удаляются, а на приложение отправляется специальный коллбэк об этом, который можно обработать (тут важно не забыть об этом, особенно, если такая ситуация реальна для вашего приоложения).
VPN – По официальной документации FCM, VPN сильно усложняет работу сервисов, может разрывать постоянное соединение с сервером и скрывать информацию, которую fcm использует для настройки соединения.
Правила FCM – Следуя собственным алгоритмам и правилам FCM может снизить приоритет самостоятельно, когда считает, что ваши пуши не нужны пользователю – концепция FCM такая, что пуши с высоким приоритетом должны показывать уведомления, если ваши пуши не приводили к показу уведомлений (например, очень большое количество тихих (silent) пушей), то приоритет будет снижен. И тогда действительно важные пуши также не дойдут. Также приоритет снижается, если вы отправляете пуши с высоким приоритетом, когда уведомления выключены.
Проблемы связанные с вашим бэкендом и приложением, например, неправильный запрос к сервису пуш-сообщений, использование уже протухшего токена, или бэкенд вовсе не смог получить токен от приложения пользователя.
Если у ваших пользователей возникают проблемы с приходом пуш уведомлений от пуш-сервиса, то эти параметры одни из первых, на которые нужно обратить внимание. О том как понять, что пуши не доходят будет раздел ниже, а пока:
Почему доставка пуша не означает, что уведомление было показано
После того, как ваш пуш дошёл до телефона пользователя, в игру вступает новый игрок – система устройства. Она также как и пуш-сервис хочет максимально сберечь батарею устройства, а значит будет всячески стараться отложить запуск приложения для обработки пуша и показ уведомлений.
Отдельно разберём причины, по которым пуш, дошедший до устройства пользователя, всё равно не показывается. ❗️Данная часть посвящена Android, хоть и многие принципы у разных платформ похожи, рекомендую дополнительно изучить документацию платформы, проблемы на которой вы исследуйте.
-
Здесь также есть своя система приоритетов, но уже для уведомлений. Приоритет задаётся вами для категорий (каналов) уведомлений, нужен для того, чтобы система понимала какой тип уведомления на каком уровне должен беспокоить пользователя.
Конкретное поведение также не гарантируется и система ориентируясь на приоритеты, поведение пользователя и другие параметры само решает, когда показать уведомление.
Ошибки при инициализации каналов уведомлений или же вручную отключенные пользователем каналы также могут быть причиной не показа пуш-уведомления.
-
App Standby и DOZE MODE – используются системой для экономии заряда батаре. Только пуши с высоким приоритетом могут разбудить приложение в этих режимах, а как мы помним FCM может снизить вам приоритет. Если это произошло у приложения, которое закрыто будут лишь короткие промежутки времени для выполнения действий в фоне, в том числе для показа уведомлений.
Некоторые производители смартфонов также имеют дополнительные инструменты оптимизации батареи, которые ограничивают время работы в фоне и показ уведомлений.
Заблокированные порты по которым fcm общается с телефоном также влияют на показ уведомлений. Обычно fcm использует 5228-5230 порты, но также может стандартный 443.
Приложение может быть полностью остановлено пользователем или приложением для оптимизации. Если приложение остановлено вручную из настроек о приложении, то система считает, что пользователь не даёт права ему вообще запускаться и показывать какие-либо уведомления.
Система также может автоматически отобрать разрешение на показ уведомлений. Могут произойти краши и анр при обработке пуша вашим приложением, например, если тело пуша, которое отправил ваш бэкенд будет содержать невалидные для приложения данные.
Перед тем как копать глубоко в вопросы почему пуш не доходит до пользователя, обязательно убедитесь, что пользователь не выключил уведомления или каналы уведомлений и что оптимизации системы, которые могут влиять на доставку пушей в фоне выключены и приложение добавлено в исключения.
Есть такой сайт – Don't kill my app, в нём содержатся инструкции как выключать разные оптимизации, у разных производителей устройств и оболочках.
Как узнать, что пуши не доходят
Для того чтобы разобраться в проблеме, нужно узнать о проблеме, да можно подождать пока пользователи сами массово начнут до вас приходить, но гораздо эффективнее сработать на опережение и заметить проблему в зачатке. А с этим нам поможет статистика и вотчдоги.
Наличие систем наблюдения и статистики позволит вам быстрее реагировать на новые проблемы, а также анализировать эффективность доставки пушей, тем самым улучшая пользовательский опыт.
Есть два решения из которого можно взять статистику:
Статистика самого Firebase – имеет как преимущества так и недостатки. Имеет удобный агрегированный формат, где можно увидеть проблему на графике. А также возможность экспорта статистики в BigQuery для детального анализа. Однако, они не могут предоставить информацию об открытиях пушей, не все события будут записаны (например, если пользователь запретил сбор статистики), а также есть сложности в анализе конкретных проблем.
-
Второй вариант это собственная система аналитики, когда ваше приложение само сообщает информацию на ваш бэк с информацией о том, что пуш был доставлен.
Такое решение позволяет получить подробную статистику о пушах, провести детальную трассировку от сервера до устройства, возможность реализовать больше бизнес-требований. Например, можно отслеживать не только пуши, но и в целом все виды уведомлений, которые у вас показываются, считая общую эффективность доставки сообщений, не зависимо от источника.
Проблемы будут только с пушами без data параметра, если они не были открыты приложение не узнает о них, а также мы не будем знать был ли показан пуш так как система могла не показать его.
Решать какое решение вам подходит надо исходя из требований и возможностей. Например, если вы не используете data пуши и нет никаких уведомлений которые генерирует само приложение, то возможно будет достаточно статистики из Firebase, чтобы видеть общую картину.
Что можно сделать, чтобы спасти пуши
Мы разобрались с проблемами, которые могут возникать при доставке пушей, некоторые из них можно решить, следуя рекомендациям сервисов:
не злоупотреблять с приоритетами
увеличить ttl если он маленький
использовать сворачиваемые пуш сообщения
Другие можно решить глубоким анализом вашего приложения и логики работы бекенда, ориентируясь на детальную статистику по доставке пушей и логи.
Однако, всё ещё остаётся множество не зависящих от нас аспектов, которые могут всё сломать, например, что делать если гугл или эппл внезапно решит отключить ваше приложение от пушей?
Тут на помощь нам приходят какие решения как:
использовать некий fallback, который в периоды активности приложения будет напрямую ходить в апи забирать сообщения и показывать их.
использовать альтернативные провайдеры пуш уведомлений (например, hms для устройств huawei и/или RuStore)
также для увеличения процента доставки уведомлений приложению при получении нового пуша можно сходить на бэк и восстановить уведомления, которые были пропущены и не отображались ранее.
Заключение
На этом увлекательное приключение в мир пушей заканчивается. Какие выводы нужно сделать и к каким решениям прийти, если вам важны пуши.
Не путайте пуши и уведомления и правильно выбираете тесты в зависимости от того что тестируете
Изучите правила работы пушей и сервисов, чтобы быстрее и легче искать причины проблем, а также оптимизировать увеличить эффективность доставки
На эффективность доставки пушей сильно влияют правильно настроенные параметры пуш-сообщений такие как ttl и приоритеты, проведите как минимум ревизию, какие параметры выбраны у вас и насколько они обоснованы
Подготовьтесь к сюрпризам судьбы используйте fallback и несколько путей доставки уведомлений
А наличие статистики и вотчдогов позволит вам быстро заметить такие ситуации и среагировать на них
Надеюсь что-то из того, что я рассказал, было полезным для вас, и пуши стали для вас чем-то более понятным и прозрачным, несмотря на то, что мутных штук в них и так полно. Если есть вопросы пишите в комменты, если нашли ошибки и фейлы тоже. Если хотите поддержать меня или вам интересно, то о чём я пишу подписывайтесь на канал в телеграмме, где я рассказываю больше полезного про тестирование и QA – LilBugHunters.