QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page
  • Принцип работы push-уведомлений
  • Разница между push-уведомлениями в iOS и Android
  • Тестирование push-уведомлений
  • Как узнать, что push-сообщения не доходят до устройств пользователей

Was this helpful?

Edit on GitHub
  1. Мобильное тестирование

Тестирование push-уведомлений

PreviousТестирование требований к мобильным приложениямNextТестирование дип линков (mobile deep links)

Last updated 3 months ago

Was this helpful?

Push-уведомления — это сообщения, отправляемые на мобильное устройство клиента. Они обычно используются для доставки обновлений продуктов, напоминаний, персонализированных предложений, последних новостей и любой информации, которая является неотъемлемой частью функциональности приложения и требует особого внимания или быстрых действий.

Важно! Не путайте уведомления и push.

Уведомление – это всплывающая плашка, звук, значок – элемент интерфейса призванный обратить на себя внимание пользователя. Чтобы показать уведомление, приложению не нужно ничего, оно может показать информацию без подключения к интернету, напомнить вам о каком-либо событии и всё в этом духе. Триггером для показа уведомления может быть что угодно, внутренняя логика приложения, таймер, или же push-сообщение.

Push – пуш это сообщение! Сообщение в специальном формате , которое должно быть обработано на телефоне. Оно приходит через специального посредника – сервиса пуш-сообщений через интернет. Обычно им выступает сервис от производителя операционной системы (APNS - Apple, FCM - Google, HMS - Huawei) но также могут использоваться альтернативные поставщики пушей. Как правило пуши нацелены на то, чтобы показать вам уведомление, однако это совсем не обязательное условие, и пуши могут быть неотображаемые и нужны приложению для обновления какой-нибудь внутренней информации.

Иными словами пуш может быть уведомлением, а может не быть, а уведомление может быть пуш-уведомлением, а может локальным (или внутренним, реализуемый по внутренней логике приложения в обход пуш-сервера).

Принцип работы push-уведомлений

  • Пользователь устанавливает ваше приложение на устройство и запускает его;

  • 1 – приложение регистрируется в службе push-уведомлений и получает у него токен — уникальный идентификатор устройства;

  • 2 – приложение передает полученный токен на ваш сервер;

  • 3 – сервер шлет уведомления в службу push-уведомлений при наступлении определенного события, вместе с полученным токеном;

  • 4 – служба push-уведомлений по токену находит ваше устройство и отправляет push на него, , где служба сервиса принимает его и решает как поступить (показать, отложить или разбудить ваше приложение для обработки пуша).

Массовые push-сообщения

Доставка push-сообщений даже, когда ваше приложение выключено, осуществляется за счёт того, что службы push-уведомлений постоянно подключены к своим серверам, не убиваются системой и имеют право "разбудить" ваше приложение.

В случае iOS уведомления работают через облачную платформу APNS (Apple Push Notification Service).

Если говорить о решении пуш-уведомлений от Android, то есть несколько вариантов. Самый простой способ действовать — использовать Firebase Cloud Messaging (FCM) для устройств Android с Google Apps. Если у ваших пользователей есть устройства Huawei (а именно, без Google Apps), то для работы пушей на таких устройствах необходимо будет также поддержать работу с HMS (Huawei Push Kit), используя Huawei Push Kit.

Конечно, вы также можете создать собственного провайдера push-уведомлений или использовать готовые проекты, поскольку платформа имеет открытый исходный код.

Стоит отметить тот факт, что решения для Android (как Firebase Cloud Messaging, так и Huawei Push Kit) можно использовать как прокси к пушам на iOS, позволяя работать с пушами из одной точки входа с единым API.

Разница между push-уведомлениями в iOS и Android

iOS основана на модели push Opt-In, которая не позволяет брендам отправлять мобильные push-уведомления пользователям своих приложений до тех пор, пока эти пользователи не согласятся их получать.

Начиная с 13 версии Android также добавил необходимость приложениям получать разрешения на показ уведомлений. До 13 версии Android по умолчанию разрешает пользователям получать push-уведомления с возможностью отказаться от них вручную. Что давало более широкую аудиторию пользователей с поддержкой push. Однако, когда у пользователей нет возможности легко отказаться от их получения, нерелевантные или слишком частые уведомления могут подтолкнуть клиентов отключить сообщения или удалить приложение.

Тут нужно отметить тот факт, что речь касается именно показа уведомлений, но так называемые тихие (silent) push-сообщения всё ещё будут приходить на устройство и "будить" ваше приложения для обработки сообщения, несмотря на запрет уведомлений.

Виды push-сообщений на примере FCM

Как отмечалось выше FCM позволяет отправлять пуши как на Android так и на iOS.

Пуши бывают нескольких видов:

  • Базовый (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 передаст приложению весь пайлоад сразу и не будет ничего автоматически показывать.

Виды уведомлений
  • Пуш-уведомления – собственно, то о чём говорили выше.

  • Локальное-уведомление – приложение само инициирует показ уведомления по своей внутренней логике, не обращаясь к бэкенду.

  • Собственная логика показа уведомлений – можно назвать подтипом для локальной логики, ниже примеры. Здесь приложение может как обращаться к бэкенду, так и нет:

    • моментальный показ уведомлений, когда приложение включено

    • показ уведомлений в периоды, когда система будит приложения в сервисных целях, тут в том числе приложение может обратиться к бэкенду

  • Постоянно висящее уведомление, позволяющее сохранять постоянное соединение с вашим бэкендом или информирующее о другой активности приложения.

Если у вас нет уверенности используется ли та или иная технология, вид уведомления или пуша в вашем приложение, то стоит уточнить это у разработчиков и задокументировать в базе знаний.

Понимание логики работы приложения, не только в контексте пушей - ключ к составлению правильных проверок при тестировании, и нахождению причин проблем.

Тестирование push-уведомлений

Если у вас на проекте только вводят push-уведомления или вы обнаруживаете много проблем с их доставкой в первую очередь обратитесь к официальной документации провайдеров push-сообщений. Так как у них есть множество ограничений и условий (такие как время жизни пуша, приоритет и т.д.), неправильная настройка какого-либо параметра может сделать так, что почти все push не будут доходить или будут приходить с запозданием.

Ссылки на документацию сервисов

Не приходят push-уведомления: Чтобы разобраться в причине, для начала проверьте, чтобы в меню устройства была активирована соответствующая функция (разрешены уведомления для конкретного приложения). Затем убедитесь, что не включен режим «Не беспокоить». Если всё настроено правильно, но уведомления не приходят, попробуйте перезагрузить устройство и заново авторизоваться в приложении. Токен push-сервиса мог протухнуть и приложению необходимо получить его вновь. Или на вашем сервере не происходит регистрация или удаляется полученный токен. Совместно с backend вашего сервиса проверьте, корректность регистрации устройства, а также ответ API службы push-уведомлений (FCM, APNS или др.). Проверьте также, какой стиль уведомления используется (необходим «Баннер» либо «Предупреждение»). Если не помогло всё перечисленное, попробуйте перезайти в свою учетную запись магазина приложений, либо откройте саму программу, в том случае, если на другие приложения тоже не приходят push-уведомления (стоит также проверить наличие интернета на устройстве).

Переходы по push-уведомлению: При тестировании необходимо проверить такие сценарии (с учётом того, что пользователь может быть авторизован или неавторизован):

  • переход по push-уведомлению с заблокированного экрана;

  • переход по push-уведомлению из «шторки»;

  • пользователь находится в приложении;

  • переход по push-уведомлению при свёрнутом приложении;

  • пользователь разлогинился после получения push;

  • переход по push-уведомлению с включенным «Don't keep Activities» (характерно для Android-приложений).

Существуют push-уведомления, которые ведут на определенный экран с выбором определенных фильтров. В таком случае необходимо проверить, что переход осуществляется на правильный экран. Если это был поисковой запрос, то проверьте, что текст поискового запроса отображается в строке поиска и выдача товаров соответствует поиску. Также могут передаваться определенные фильтры, в таком случае необходимо проверить, что выбраны все «зашитые» фильтры.

Если push-уведомление ведет на WebView, то проверьте, что WebView открывается корректно на обеих платформах. И что в push зашит корректный URL.

Устаревший push-токен: У устройства изменился push-токен, когда восстановили приложение из резервной копии системы и не передался новый push-токен.

Ограничения со стороны службы push-уведомлений: Google и Apple не гарантируют доставку push, есть множество параметров, которые могут повлиять на скорость доставки пуша. Например, Google может уменьшить приоритет push-сообщений, если большая часть push-сообщений не отображается в виде уведомлений. Также на скорость доставки push может повлиять большая очередь на доставку со стороны служб.

Проверка максимального и минимального количества отображаемых символов: В iOS и Android имеется лимит отображаемых символов. Он разный. Максимальное значение количества символов для платформы iOS - ограничение в 4 строки (178 символов), а для Android — не более 13 строк (663 символа). Не забудьте также проверить push-уведомление, содержащее минимальное количество символов, для обоих платформ можно задать 1 символ.

Кастомный звук для push-уведомления: При тестировании push-уведомлений важно учитывать тот факт, что звук push-уведомления может быть задан кастомный. В таком случае необходимо проверять и звуковое сопровождение нотификации.

Изображения в push-уведомлениях: Push-уведомление может содержать изображение, при отправке пуша — клиент получает ссылку на изображение и перед показом загружает его, далее происходит процесс обогащения пуша картинкой - она устанавливается. Уведомление отображается после загрузки картинки. Если push-уведомление содержит картинку, необходимо проверить, что она отображается.

Локальные уведомления: Локальные уведомления планируются самим приложением и служат для своевременного и актуального информирования пользователей, пока приложение не работает на переднем плане. Чтобы уведомление отобразилось, его необходимо запланировать самому пользователю. В таких случаях проверяем кейсы, связанные с таймингом отправки сообщения.

Проблемы на серверной стороне: В другие приложения приходят push-уведомления, но не приходит на наше, хотя push-токен отправлен на сервер. Стоит проверить корректность отправки push на другие аккаунты сервиса и другие устройства. При отсутствии push-уведомлений сообщите команде серверной разработки.

Мультиаккаунт: Если в вашем приложние реализована возможность входа в несколько аккаунтов, крайне важно тщательно изучить какое должно быть поведение push при входе в несколько аккаунтов. Должны ли приходить push со всех или только с активного аккаунта. Если да нужно проверить коректность переключения аккаунтов при открытии push, а также, что пользователю понятно для какого аккаунта пришёл push. Если push не должны приходить для не активных аккаунтов, то следует проверить корректность перерегистрации аккаунта на сервере и/или push-токена (в зависимости от выбранной логики) при переключении аккаунтов.

Как узнать, что push-сообщения не доходят до устройств пользователей

Наличие систем наблюдения и статистики позволит вам быстрее реагировать на новые проблемы, а также анализировать эффективность доставки пушей, тем самым улучшая пользовательский опыт.

Есть два решения из которого можно взять статистику:

  • Второй вариант это собственная система аналитики (либо интеграция сторонних решений), когда ваше приложение само сообщает информацию на ваш бэк с информацией о том, что пуш был доставлен.

    • Такое решение позволяет получить подробную статистику о пушах, провести детальную трассировку от сервера до устройства, возможность реализовать больше бизнес-требований. Например, можно отслеживать не только пуши, но и в целом все виды уведомлений, которые у вас показываются, считая общую эффективность доставки сообщений, не зависимо от источника.

Источники:

Доп. материал:

Кроме точечных сообщений существуют также массовые, в этом случае приложение подписывается на конкретный тип пушей (топик) из которого сообщения будут отправляться на конкретный девайс автоматически, а наш бэкенд только отправляет сообщения в конкретный топик. Подробнее и (работает начиная с 18 iOS).

некая запланированная активность по показу уведомлений используя сервисы системы, например для андроид или

Статистика от push-провайдера – имеет как преимущества так и недостатки. Например, и от FCM или для iOS девайсов . Однако, они не могут предоставить информацию об открытиях пушей, не все события будут записаны (например, если пользователь запретил сбор статистики), а также есть сложности в анализе конкретных проблем.

документация для fcm (android)
документация для APNS
WorkManager
AlarmManager
FCM
APNS
HMS
агрегированный формат
BigQuery для детального анализа
статистика от APNS
Руководство по тестированию push-уведомлений
Тестирование push-уведомлений в мобильных приложениях
Механизм пуш-уведомлений для iOS и Android
Отправка push-уведомлений с помощью Firebase Cloud Messaging
Отправка push-уведомлений в приложение для iOS с помощью облачных сообщений Firebase