как осуществляется тестирование мобильного приложения
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Процесс тестирования мобильных приложений
Тестирование – очень важный этап разработки мобильных приложений.
Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.
Мобильное тестирование сложный процесс: десятки различных разрешений экрана, аппаратные отличия, несколько версий операционных систем, разные типы подключения к интернету, внезапные обрывы связи.
Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.
Под катом я расскажу как мы тестируем мобильные приложения.
Тестирование требований
Тестирование начинается до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются нашими дизайнерами.
Тестировщик анализирует требования на полноту и противоречивость. В каждом проекте исходные требования содержат противоречивую информацию. Мы их решаем еще до начала разработки. Так же в каждом проекте требования неполны: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок, кнопки никуда не ведут. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях.
Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.
В основном на этом этапе используется basecamp.
Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.
Например, для проекта Trava на этом этапе было написано 1856 тестов.
Первый шаг тестирования закончен. Проект уходит в разработку.
Билд-сервер
Все наши проекты собираются на TeamCity билд-сервере.
Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые.
Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.
Тестирование билдов бывает быстрое и полное.
Быстрое тестирование
Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.
Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.
Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.
Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.
После этого выполняются функциональные тесты этой итерации. Если были найдены баги не покрытые тест-кейсами, создается новый тест-кейс.
Для андроид приложений запускаются monkey тесты.
По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).
Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).
Критичность бага определяется по таблице.
После завершения тестирования PM получает подробное письмо-отчет.
Полное тестирование
Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.
Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.
Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.
Разработчики часто забывают о миграции данных со старых версий и тестирование обновлений позволило нам выявить множество критических ошибок с падениями, удалением пользовательских данных о покупках. Это спасло не одно приложение от гневных отзывов и потери аудитории.
Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.
В конце полного тестирования, кроме письма, вручную составляется подробный отчет.
Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.
Тестирование внешних сервисов
Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.
Поэтому в обязательно порядке для внешних сервисов создается тестовый аккаунт и он проверяется при полном тестировании. Кроме того отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется боевым.
Учет времени
Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.
UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика
Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
5 принципов тестирования мобильных приложений
Сразу оговорюсь, всё нижеописанное почерпнуто мною исключительно из своего небольшого по объёму затраченного времени (но большого по количеству авралов, злоключений и прочих баттхёртов) опыта. Оговорка номер до: эти принципы применимы только к мобильному ПО. Как там у других — я не знаю и гадать не хочу. И последнее, пожалуй, самое важное. Данные принципы лишь задают направление, а потому будут полезны в основном новичкам (хотя вы, конечно, можете написать о бесполезности сей статьи в комментариях).
Итак, когда я только начинал заниматься тестированием, прочитал доступную теорию, начальник начал второе собеседование с простого вопроса – в чём особенность мобильного тестирования по отношению к другим видам тестирования? Тогда я лишь приблизительно смог ответить на этот вопрос. Сейчас я выделяю для себя следующие принципы:
Принцип 1: Постоянная мобильность
Главное отличие мобильного от десктопного ПО заключается в том, что с айфоном вы передвигаетесь, тщетно ловите вайфай в столовых ваших вузов (совершая характерные движения руками), бегаете и вообще по максимуму загружаете все возможные сенсоры движений, что китайские умельцы встроили в него. Забывать об этом смерти подобно. Кто-то может сказать, что глупо бегать по офису, меняя ориентации экрана и теряя-восстанавливая коннект. На это у меня есть 2 контр-примера из жизни:
Принцип 2: Ловля вай-фая на живца
Большая часть современных приложений, так или иначе, использует сеть. Далеко не всегда это “полный коннект”. Поэтому обязательно необходимо тестировать приложение как минимум 4-мя способами:
Принцип 3: Прерывания
По-хорошему, этот принцип должен стоять во главе всего списка. Ведь прерывания наносят самый существенный вред приложению, при этом являясь одним из основополагающих принципов самих мобильных систем. Во время использования вашего приложения, пользователь может
Принцип 4: Особенности операционных систем и железа
Данный принцип находится тут с явной натяжкой, но всё же, я считаю, что ОС и железо, установленное в мобильных устройствах, сказывается на производительности ПО намного сильнее, чем в десктопах. Почему?
Принцип 5: Человеческий фактор
Если приложение рассчитано на широкую аудиторию, будьте готовы к тому, что куча людей, бесконечно далёких от разработки ПО, будет вести себя совершенно по-разному с вашим приложением. Тут важно понимать, что мы не можем просчитать все возможные случаи использования приложения всеми криворукими пользователями. Но проверить, что приложение корректно выполняет весь свой функционал на основных юз-кейсах мы обязаны. Неплохо также обезопасить себя, пробежавшись по приложению в качестве пользователя-дурачка, тыкая во всё подряд, открывая и закрывая активности, не дожидаясь загрузки данных и т.д. Проблема с “замыленным глазом” решается путём привлечения в процесс ваших девушек, друзей и родственников. Просто дайте им приложение в руки и посмотрите, как они будут им пользоваться. Это даст вам примерную (насколько примерную зависит, конечно, от величины выборки) картину того, что следует тестировать в первую очередь и на что обратить внимание.
Вместо заключения
Конечно, в определённой степени эта подборка принципов субъективна и спорна и, возможно данная статья покажется надуманной или некорректной (как мне, так и вам). С другой стороны, я надеюсь, что статья всё же окажется полезной и поможет вам конкретизировать и не забывать вещи, наиболее важные при тестировании мобильных приложений. Ну и напоследок хотелось бы обменяться опытом:
Какие принципы мобильного тестирования вы используете?
Системный подход к тестированию Android-приложений, или О чем молчали разработчики
У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).
Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.
Конечно, можно перечитать всю доступную документацию для разработчиков, но вряд ли это время заложено в сроки проекта. Есть путь проще и продуктивнее: узнать у разработчика, что представляет из себя та функциональность, в которой возникает баг.
Понимая, из каких компонентов состоит приложение, вы сможете:
Предлагаю разобрать некоторые компоненты Андроид-системы и со стороны тестирования рассмотреть кейсы, которые надо проверять для них.
Давайте сразу оговорим, что определения в статье давались тестировщиком. Они не претендуют на истину в последней инстанции и могут содержать неточности. Комментарии и аргументированные замечания приветствуются.
В Андроиде все основано на работе процессов. Операционная система может завершить процесс, если он завис или появился новый с более высоким приоритетом. Когда пользователь видит результаты деятельности процесса, система воспринимает этот процесс как самый приоритетный. И при необходимости она будет закрывать его в последнюю очередь.
В процессах выполняется работа компонентов. Давайте начнем разбираться с таких компонентов, как активити и фрагменты, и рассмотрим кейсы, когда система может прекратить их работу.
Активити и фрагменты (activities and fragments)
С точки зрения тестировщика, активити можно воспринимать как экран, на котором отображаются элементы. Приложение состоит, как минимум, из одной активити. По сути, активити — это контейнер для UI-компонентов.
Если активити – это контейнер, то фрагменты – это UI-компоненты активити. Фрагмент тоже, в свою очередь, является контейнером для UI-компонентов.
Есть классная аналогия с браузером (спасибо разработчикам!) для более наглядного представления о том, как между собой связаны активити и фрагменты. Представим, что у нас открыто несколько окон одного браузера. Это несколько активити внутри одного приложения.
Внутри окна может быть открыто несколько вкладок. Это фрагменты внутри активити.
Фрагменты работают чуть быстрее, чем активити. Но на современных устройствах разница практически неощутима. В зависимости от того, каким образом решается задача, разработчик может написать приложение только на активити или на активити с использованием фрагментов.
Операционная система при управлении жизненным циклом приложения работает именно с активити приложения. Поэтому пока нас больше всего интересует жизненный цикл активити.
Пользователи запускают большое количество приложений, а значит, создается много процессов с активити. Каждый запущенный процесс съедает оперативную память устройства, и ее становится все меньше. Но Андроид тщательно следит за процессами и в случае нехватки ресурсов для выполнения более приоритетной работы закрывает те, которые менее приоритетны.
Давайте разберемся, в какой момент приложение «уязвимо» к таким решениям системы и как это может повлиять на его работоспособность.
Жизненный цикл активити
Для тех, кто не знал или знал, но забыл.
Жизненный цикл активити представлен следующими состояниями:
Теперь приведу примеры. Они покрывают основные кейсы, с которыми мы чаще всего сталкиваемся при тестировании.
Первый запуск приложения
При первом запуске приложения создается и загружается главная активити в приложении.
При переходе в состояние «Resumed» активити доступна для взаимодействия с пользователем. Все замечательно, проблем нет.
Переход с первого экрана на второй
Шаг 1: При переходе с первого экрана на второй активити первого экрана сначала встает на паузу. В этот момент могут выполняться такие действия, как сохранение введенных данных и остановка ресурсоемких операций (например, проигрывание анимаций). Это происходит довольно быстро и неощутимо для пользователя.
Шаг 2, 3, 4: Запускается активити второго экрана.
Шаг 5: Останавливается активити первого экрана. Также в случае, если Андроид в этот момент пытается освободить память, активити первого экрана дополнительно может перейти в состояние «Destroyed» (то есть уничтожиться).
Чтобы лучше понять, что из себя представляет состояние «Paused» давайте представим такую ситуацию: экран, поверх которого появился алерт. Мы не можем с ним взаимодействовать, но в то же время мы его видим.
Возврат со второго экрана на первый
При возврате со второго экрана на первый происходит почти то же самое, только первая активити не создается заново. Она подгружается из памяти (если, конечно, не была уничтожена системой). Вторая активити уничтожается после того, как была остановлена, так как она убирается из стека переходов.
Сворачивание и выход из приложения
При сворачивании приложения (например, по кнопке Home) активити останавливается.
Важно, чтобы при разворачивании приложения активити корректно восстановилась и данные сохранились.
На всех экранах стараемся проверять сворачивание-разворачивание приложения. Этот кейс особенно актуален на формах ввода. Согласитесь, будет обидно, если текст письма, который вы так старательно набирали, сотрется при банальном сворачивании приложения. Или форма, состоящая из множества полей, снова станет пустой.
При выходе из приложения (по аппаратной кнопке назад) помимо шага 1 и шага 2, выполняется шаг 3. Активити уничтожается и при следующем запуске приложения создается заново.
Поворот экрана
Один из значимых случаев, который плодит баги — это поворот экрана. Оказывается, при повороте экрана активити проходит полный жизненный цикл. А именно уничтожается и снова создается. И так при каждом повороте. Поэтому, опять же, проверяем поворот на каждом экране.
Поддержка горизонтальной ориентации экрана, с одной стороны, позволяет проверить корректность работы всех этапов активити, с другой стороны, значительно увеличивает количество тест-кейсов.
Многооконный режим
Начиная с Андроида 7 (с Андроида 6 как экспериментальная фича) стал доступен многооконный режим. Пользователи получили возможность видеть сразу несколько приложений на экране одновременно. При этом только то приложение, с которым пользователь сейчас взаимодействует, находится в состоянии «Resumed». Остальные устанавливаются в состояние «Paused».
Don’t keep activities (Не сохранять действия)
Надо ли проверять полный жизненный цикл активити, если приложение не поддерживает поворот экрана? Конечно, надо.
Если оперативная память давно не чистилась, ее не очень много, и в параллели с вашим приложением было запущено какое-нибудь ресурсоемкое приложение (например, PokemonGo), то шанс, что Андроид решит «прибить» процесс с вашей активити при переключении на другое приложение, возрастает.
Как проверить корректность работы приложения вручную, если оно не поддерживает поворот экрана? Довольно просто: установить галку «don’t keep activities» в настройках разработчика и перезапустить приложение.
В этом случае эмулируется ситуация, когда памяти не хватает и Андроид уничтожает все активити, с которыми пользователь сейчас не взаимодействует, оставляя только ту, что сейчас активна.
Это не значит, что галка должна всегда быть включенной при тестировании, но периодически смотреть приложение с опцией «don’t keep activities» полезно, чтобы пользователи со слабыми устройствами не сильно страдали и не ругали нас.
Broadcast receiver (широковещательный приемник)
Для обработки внешних событий используется компонент Broadcast receiver. Приложение может подписываться на события системы и других приложений. Андроид доставляет событие приложению-подписчику, даже если оно не запущено, и таким образом, может «мотивировать» его запуск.
При тестировании нам важно понимать, какие ожидаются события и как они обрабатываются.
Например, в коде заранее было прописано, что приложение ждет сообщение от конкретного номера и имеет доступ к смс. Когда пользователю придет секретный код, то Broadcast receiver получит уведомление и в поле подтверждения операции будет введен смс-код.
Сервисы (Services)
Еще одна очень важная вещь в Андроиде — это сервисы. Они нужны для выполнения фоновых задач. При этом приложение не обязательно должно быть открыто пользователем в этот момент.
У сервисов есть несколько режимов работы. Пользователь может видеть, что сервис запущен, а может и совершенно не замечать его.
Если вы услышали волшебное слово «сервис» от разработчика, не поленитесь, выясните, какую логику работы заложили в него:
Тут основной совет при проектировании тестовых сценариев — это обдумать пользовательские кейсы, когда работа сервиса может прерваться или начать конфликтовать с работой другого сервиса. Самые коварные ситуации: когда работа сервиса начинается, а пользователь этого не ждал. В этом случае полезно выяснить, что может спровоцировать запуск сервиса.
Самые простые и безобидные — это сервисы без дополнительных параметров. При ручном тестировании мы чаще всего не замечаем их работу. Например, если нужно отправить данные в систему аналитики, то для этой задачи нередко используют именно такие сервисы.
Еще один тип сервисов это sticky-сервисы. Если работа такого сервиса внезапно завершится, то спустя какое-то время sticky-сервис «возродится». Примечательно, что с каждым разом период до «возрождения» увеличивается, чтобы он меньше мешал работе системы. В некоторых приложениях примером sticky-сервиса может быть скачивание файлов на устройство. Возможно, вы замечали, если в «шторке» сбросить закачку, то спустя какое-то время она может восстановиться и продолжить скачивать файлы.
Самые важные сервисы — те, работу которых пользователь «ощущает» на себе и она для него важна. Они называются foreground-сервисы, и у них обязательно есть нотификация в «шторке», которую пользователь не может закрыть. Система их будет уничтожать в последнюю очередь, так как приоритет у таких сервисов самый высокий.
Например, музыкальный плеер. Если свернуть приложение и даже закрыть его, то плеер продолжает играть, пока пользователь не поставит его на паузу или не закроет. Или пока другое приложение или система не приостановит его работу. В частности, для музыкального плеера вариантов может быть много: входящий звонок, другое музыкальное приложение, звуковая нотификация.
Раз речь зашла о музыкальных плеерах, то стоит отметить такое понятие, как аудиофокус.
Аудиофокус
Представим, что при запуске нескольких аудиоплееров, они все будут играть одновременно. Вряд ли это кому-то понравится. Тут на помощь приходит аудиофокус, который запрашивается приложением у системы. В случае обычного запроса аудиофокуса система как бы оповещает все запущенные приложения: «Сейчас другое приложение будет говорить, помолчите, пожалуйста». Забавно, но это происходит именно в формате просьбы.
Если ваше приложение не очень вежливое, то оно спокойно может проигнорировать запрос. Наша задача – проверять эти ситуации.
Компромиссный режим запроса аудиофокуса называется «временным перехватом аудиофокуса». Это значит, что вашему приложению вернется аудиофокус, когда прервавшее его подаст системе сигнал, что аудиофокус освобожден.
Еще один вид запроса аудиофокуса — это «duck». Он просит остальные приложения не молчать, а уменьшить громкость наполовину пока воспроизводится звук запросившего фокус приложения. Например, такой запрос используется при проигрывании звука нотификации о новом сообщении в мессенджере.
Тестирование аудиофокуса очень важно, т.к. здесь все завязано на совести разработчиков и система не принимает особого участия в разрешении конфликтов. Ну а если баг все-таки вылезет к пользователям, то не сомневайтесь, они быстро вам об этом сообщат.
На этом, пожалуй, пока можно закончить. Конечно, есть еще много деталей и нет необходимости учитывать абсолютно все при тестировании. По моему опыту, тестировщику необходимо понимать из чего состоит приложение и как оно работает. Это дает возможность анализировать непростые баги, которые возникают на пересечении бизнес-логики приложения и особенностей работы операционной системы. Особенно если дело касается Андроида.