Тестирование мобильных и web-клиентов
Мобильный клиент — это не «сайт на маленьком экране». Он работает в среде, которая непрерывно вмешивается в его жизнь — входящий звонок обрывает сценарий, сеть переключается с Wi-Fi на мобильную, система выгружает процесс ради памяти, а сам зоопарк устройств и версий ОС растягивает матрицу проверок в десятки строк. Половина мобильных дефектов вообще не воспроизводится на десктопе.
Этот блок собирает то, что тестировщику приходится знать про клиентскую часть: какие бывают приложения и платформы, где их гонять — на реальном устройстве, эмуляторе или симуляторе, — как ведёт себя браузер (движок, DOM, DevTools) и как разобрать трафик и логи, когда что-то сломалось. Ловушки здесь въедливые — путают эмулятор с симулятором, называют браузер вместо движка, забывают про Huawei без сервисов Google. Полная карта — в слоях ниже.
Карта темы
- Типы мобильных приложений — нативные, веб и гибридные (WebView) и что это меняет в тестировании.
- Различия iOS и Android — закрытая единообразная платформа против открытой фрагментированной и ловушка Huawei.
- Устройства, эмуляторы и симуляторы — чем отличаются и что выбрать для раннего покрытия и финала.
- Специфика мобильного тестирования — сеть, жизненный цикл, разрешения и батарея — класс дефектов только мобайла.
- Тестирование прерываний — звонок, push, блокировка экрана и требование сохранить состояние.
- Семантическое версионирование — как читать
MAJOR.MINOR.PATCHи оценивать риск обновления. - Браузерные движки — Blink, WebKit, Gecko и почему кросс-браузерные баги кучкуются не на Blink.
- DOM для тестировщика — дерево объектов страницы, селекторы CSS/XPath и проверка отрисованной структуры.
- DevTools и снифферы — что видят DevTools браузера и чем их превосходит прокси для разбора трафика.
- Прокси трафика устройства — как перехватить и подменить HTTPS-запросы телефона через корневой сертификат.
- Чтение логов —
logcat, консоль Xcode, Kibana и краш-репортеры как источник настоящей причины. - Диагностика пропажи push — порядок проверок, когда одно из двух одинаковых устройств не получает уведомления.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Путать гибридное приложение с чисто веб | Неверные выводы о доступе к железу и о том, что тестировать |
| Менять местами эмулятор и симулятор | На собеседовании это сразу выдаёт незнание платформ |
| Считать, что эмулятор заменяет реальное устройство | Пропущены дефекты датчиков, производительности и сети |
| Называть браузер (Chrome) вместо движка (Blink) | Матрица кросс-браузерных проверок построена по браузерам, а не по движкам |
| Забывать про Huawei без сервисов Google | push через FCM и вход Google молча не работают, а причину ищут в коде |
| Думать, что DevTools перехватывают трафик других приложений | Для нативного трафика нужен прокси, а не вкладка Network |
| Забывать доверенный корневой сертификат для HTTPS | Прокси видит только зашифрованный поток и ничего полезного |
| Считать, что сообщение на экране — полная причина дефекта | Настоящая ошибка и стек-трейс остаются в логах непрочитанными |
Значение для собеседований
Мобильный блок проверяют, чтобы понять, работали ли вы с настоящими устройствами или знаете тему по статьям. Вопросы почти всегда практические — «дано два одинаковых телефона, на одном нет push, что проверите» или «спроектируйте матрицу кросс-браузерного теста». Ценится не пересказ определений, а порядок действий и знание ловушек.
Что обычно проверяют:
- Разницу нативного, веб и гибридного приложения и что она меняет в тестировании.
- Эмулятор против симулятора и когда нужно именно реальное устройство.
- Класс дефектов, который есть только на мобайле, и тестирование прерываний.
- Как разобрать трафик телефона и где искать логи iOS, Android и бэкенда.
Типичный неверный ответ: «мобильное тестирование — это то же самое, только экран меньше». На деле мобайл добавляет целый пласт среды — прерывания, переходы сети, жизненный цикл процесса, фрагментацию и разрешения, — и именно вокруг него собираются баги, которых десктопный набор никогда не найдёт.