Тестирование iOS и Android

Введение в тестирование мобильных платформ #

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

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

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

Обзор архитектуры платформ #

Архитектура iOS #

Apple контролирует всю экосистему iOS — hardware, операционную систему, App Store и инструменты разработки. Эта вертикальная интеграция имеет прямые последствия для тестирования:

Архитектура Android #

Google предоставляет операционную систему Android, но производители оборудования значительно её кастомизируют:

Фактор фрагментации #

Крупнейшее различие между тестированием iOS и Android — это фрагментация устройств.

Фрагментация Android в цифрах #

Фрагментация Android проявляется в нескольких измерениях:

• Версии ОС: Android 10 — Android 14+ одновременно имеют значительную долю рынка
• Оболочки производителей: Samsung One UI, Xiaomi MIUI, Huawei EMUI, OnePlus OxygenOS — каждая модифицирует поведение стандартного Android
• Вариации hardware: Размеры экранов от 4" до 7.6" (складные), разные процессоры (Qualcomm, MediaTek, Samsung Exynos), различный объём RAM (2ГБ — 16ГБ)
• Различия в поведении API: API камеры, обработка уведомлений и фоновая обработка могут вести себя по-разному у разных производителей

Для тестировщиков это означает, что баг может появиться только на устройствах Samsung с Android 12 и One UI 4.1 — и больше нигде.

Консистентность iOS #

Контролируемая экосистема Apple означает гораздо меньшую фрагментацию:

• Обычно 2-3 мажорных версии iOS для поддержки
• ~15 конфигураций устройств (текущие модели iPhone + недавние iPad)
• Консистентное поведение API на всех устройствах
• Предсказуемый цикл обновлений (ежегодный мажорный релиз в сентябре)

Это не означает, что тестирование iOS проще — это означает, что тип сложности другой. Баги iOS чаще связаны с edge case-ами в строгих гайдлайнах Apple, чем с проблемами рендеринга на конкретных устройствах.

Сравнение инструментов тестирования #

У каждой платформы свой набор инструментов:

Симуляторы vs Эмуляторы #

Это различие чрезвычайно важно для тестировщиков:

iOS-симулятор: Запускает скомпилированную версию приложения на процессоре Mac. Быстрый, но не эмулирует реальное оборудование. Камера, GPS, акселерометр и другие сенсоры симулируются или недоступны. Push-уведомления на симуляторе тестировать нельзя.

Android-эмулятор: Полностью эмулирует устройство Android, включая процессор ARM (или использует аппаратное ускорение с x86-образами). Медленнее iOS-симулятора, но точнее. Поддерживает симуляцию камеры, GPS и других сенсоров.

Ключевое следствие для тестирования: Если приложение использует аппаратные функции (камера, Bluetooth, NFC, биометрия), необходимо тестировать на физических устройствах обеих платформ.

Платформо-специфичные аспекты тестирования #

Специфика iOS #

1. Соответствие гайдлайнам App Store: Apple отклоняет приложения за нарушения. Проверяйте соответствие перед отправкой.
2. Управление памятью: iOS агрессивно завершает фоновые приложения. Тестируйте восстановление состояния после давления на память.
3. Запросы разрешений: iOS показывает системные диалоги разрешений (камера, геолокация, уведомления), которые нельзя кастомизировать. Тестируйте флоу с выданными и отклонёнными разрешениями.
4. Dark Mode: С iOS 13 все приложения должны поддерживать тёмную тему. Тестируйте все экраны в обоих режимах.
5. Dynamic Type: Пользователи iOS могут менять размер системного шрифта. Тестируйте приложение с максимальным и минимальным размерами шрифта.

Специфика Android #

1. Поведение кнопки «Назад»: Android имеет системную кнопку возврата (аппаратную или жестовую). Проверяйте, что каждый экран корректно обрабатывает навигацию назад.
2. Разделённый экран и складные устройства: Android поддерживает многооконный режим и складные устройства. Тестируйте приложение в режиме разделённого экрана и при складывании/раскладывании.
3. Оптимизация батареи: Производители реализуют агрессивное энергосбережение, которое может убивать фоновые процессы. Тестируйте на устройствах Samsung, Xiaomi и Huawei.
4. Разрешения хранилища: Модель разрешений хранилища Android значительно изменилась между версиями (scoped storage в Android 10+).
5. Каналы уведомлений: С Android 8.0 уведомления должны использовать каналы. Тестируйте категоризацию уведомлений и пользовательский контроль.

Построение стратегии тестирования с приоритизацией платформ #

Когда ресурсы ограничены (а они всегда ограничены), нужна стратегия приоритизации тестирования по платформам.

Шаг 1: Проанализируйте пользовательскую базу #

Проверьте аналитику на предмет реального распределения платформ:

Пример распределения:
- iOS: 55% пользователей
- Android: 45% пользователей
  - Samsung: 40% пользователей Android
  - Xiaomi: 15%
  - Google Pixel: 12%
  - Остальные: 33%

Эти данные определяют выбор устройств. Если 55% пользователей на iOS — iOS получает приоритет.

Шаг 2: Определите матрицу устройств #

Создайте матрицу тестовых устройств, покрывающую максимум пользовательской базы минимумом устройств:

Цель: покрыть 80% пользовательской базы 6-8 устройствами.

Шаг 3: Проектирование платформо-специфичных тест-кейсов #

Некоторые тест-кейсы применимы к обеим платформам. Другие — специфичны:

Универсальные тест-кейсы:

• Основная бизнес-логика (логин, навигация, отображение данных)
• Коммуникация с API (эндпоинты, обработка ошибок)
• Валидация ввода
• Базовая доступность

Специфичные для iOS:

• Навигация с VoiceOver (screen reader)
• Масштабирование Dynamic Type (все 12 размеров)
• Диалог App Tracking Transparency
• Функции Handoff и Continuity
• Тестирование виджетов (WidgetKit)

Специфичные для Android:

• Кнопка «Назад» и жестовая навигация
• App links и обработка intent-ов
• Тестирование виджетов (App Widgets)
• Разделённый экран и picture-in-picture
• Специфика производителей (оптимизация батареи Samsung, Xiaomi)

Упражнение: Создайте свою матрицу устройств #

Сценарий: Вы — QA lead приложения доставки еды, работающего в Мексике и Бразилии. Ваша аналитика:

• 60% Android, 40% iOS
• Топ Android-устройства: Samsung Galaxy серия A (30%), Motorola серия G (20%), Xiaomi Redmi (15%)
• iOS: iPhone 12-15 покрывает 85% iOS-пользователей
• Android OS: 35% Android 13, 30% Android 12, 20% Android 14, 15% Android 11

Создайте матрицу из 8 устройств, максимизирующую покрытие.

Советы из продакшен-опыта #

Совет 1: Всегда тестируйте на реальных устройствах для release candidate. Симуляторы и эмуляторы пропускают аппаратно-специфичные баги. Как минимум, тестируйте финальную сборку на одном физическом iOS-устройстве и одном Android-устройстве перед каждым релизом.

Совет 2: Следите за багами, специфичными для производителей Android. В Waze мы обнаружили, что устройства Samsung с One UI 3.1 имели специфичный баг с сервисами геолокации в фоне, который не проявлялся ни у одного другого производителя.

Совет 3: Мониторьте отчёты о крашах по устройствам. Инструменты вроде Crashlytics и Sentry показывают распределение крашей по модели устройства и версии ОС. Просматривайте эти данные еженедельно.

Ключевые выводы #

• iOS и Android имеют фундаментально разные вызовы тестирования: iOS — строгие гайдлайны Apple и ограниченные конфигурации; Android — массовая фрагментация устройств
• Симуляторы (iOS) и эмуляторы (Android) служат разным целям и имеют разный уровень точности
• Матрица тестовых устройств должна основываться на реальной аналитике пользователей, а не на предположениях
• Некоторые тест-кейсы универсальны; другие должны быть платформо-специфичными
• Всегда включайте тестирование на физических устройствах для release candidate