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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники:

● Тестирование push-уведомлений в мобильных приложениях

● Механизм пуш-уведомлений для iOS и Android

Покрытие девайсов

Большинство багов обнаруживается на покрытии около 30% девайсов - разрешение, мощность, версия ос+нижняя граница для данной аппы. Варианты: физическая ферма устройств, эмулятор и симулятор (BrowserStack (облачный), родной в Android Studio, BlueStack, Genymotion и т.п.). Вообще физический устройств желательно иметь хотя бы штук 6 - два отличающихся айфона, по планшету на iOS и Android, 2 разных андроида. Хуавей сейчас тестится отдельно из-за гугл сервисов.

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

● Выбор мобильных устройств: пошаговая инструкция для начинающих QA. Часть II

● Облачные платформы для мобильного тестирования

● Android phone and tablet market shares

● The most popular iPhones - 2020

● Mobile Vendor Market Share Worldwide

● Яндекс.Радар Мобильные ОС

● https://mobile-review.com/all/articles/android/genoczid-android-flagmanov/

Middleware

Связу́ющее програ́ммное обеспе́чение (англ. middleware; также переводится как промежу́точное программное обеспечение, программное обеспечение среднего слоя, подпрогра́ммное обеспечение, межплатфо́рменное программное обеспечение) — широко используемый термин, означающий слой или комплекс технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами. (с) Вики. В данном разделе нас интересует применение в мобильной разработке.

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

● API не дописано — разработчики заказчика загружены текущей работой и не мотивированы сдать его в срок, при том, что у маркетинга планы и сроки запуска мобильного приложения горят;

● API сильно не совпадает со структурой мобильного приложения (данные для экранов приходится дергать с 3-4 методов и обрабатывать локально);

● Нет документации, либо она сильно разрознена и не актуальна;

● Несколько точек входа (разросшаяся инфраструктура находится на нескольких серверах с разными адресами);

● Уже существующее API меняется после апдейтов основного сайта;Отсутствие тестовых серверов;

● Баги (много багов).

И добавим сюда понимание, что со всем этим придется бороться сразу на двух платформах, которые хоть и являются мобильными, часто используют разные архитектурные подходы и, как следствие, разные сроки старта и готовности этапов. Все это приводит к увеличению сроков разработки и, соответственно, стоимости разработки.

Для минимизации всех этих проблем предлагается использовать промежуточный сервер — шину данных.

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

Бонусом мы имеем возможность разрабатывать приложения со своими наработками по авторизации, обработкам ошибок и прочим мелочам, протестированными и проверенными.

Плюсы такого подхода:

● Отсутствуют простои из-за неготовности API заказчика — в худшем случае на шине отдаются тестовые данные;

● Упрощается реализация мобильного приложения практически до тонкого клиента;

● Единственная точка входа позволяет упростить архитектуру работы с сетью в МП;

● Возможность выкладывать обновления для сервера шины (меняющую взаимодействие с сервером заказчиком) без обновления МП, в кратчайшие сроки, без модерации со стороны третьих фирм;

● Простота и отсутствие полноценной БД позволяет легко разворачивать любое количество тестовых серверов;

● Удобное логирование всех сетевых ошибок и оповещение о них;

● Изменения в работе API заказчика необходимо вносить только в одном месте — на сервере шины;

● Документация ведется принятым и привычным в компании способом;

● Использование наработок снижает сроки и стоимость разработки.

Все это позволяет снизить сроки и стоимость, напрямую и косвенно, за счет снижения рисков простоя, сложности реализации серверной части и тестирования. Шикарный бонус разработчику — возможность предложить более низкую цену и выиграть конкурс, а заказчику - сэкономить и уменьшить сроки внедрения МП.

Источник: Middleware: необходимость в мире разработки мобильных приложений