Тестирование мобильных и web-клиентов
Тестирование мобильных и браузерных клиентов — типы приложений, устройства против эмуляторов, тестирование прерываний и локалей, разбор трафика и DOM браузера.
19 вопросов
JuniorТеорияОчень частоЧто даёт тестированию доступности каждый из WCAG, axe и Lighthouse?
Что даёт тестированию доступности каждый из WCAG, axe и Lighthouse?
WCAG — это стандарт: критерии успеха по четырём принципам на уровнях A/AA/AAA. axe — автоматический движок, сканирующий отрисованный DOM на нарушения вроде отсутствующих меток или низкого контраста. Lighthouse аудирует страницу и оценивает доступность. Автотулы ловят лишь часть; контраст, метки и структура всё ещё требуют ручных проверок и проверки вспомогательными технологиями.
Типичные ошибки
- ✗Думать, что автоматический проход означает полную доступность
- ✗Путать WCAG (стандарт) с axe и Lighthouse (инструментами)
- ✗Пропускать ручные проверки и проверку скринридером после автосканов
Уточняющие вопросы
- →Какие проблемы доступности автоскан не может надёжно поймать?
- →Что означают уровни соответствия WCAG — A, AA и AAA?
JuniorТеорияОчень частоЧем отличаются реальные устройства, эмуляторы и симуляторы и что предпочесть?
Чем отличаются реальные устройства, эмуляторы и симуляторы и что предпочесть?
Реальное устройство даёт самые точные результаты — настоящие датчики, производительность и сеть — но дорого. Эмулятор (Android) моделирует железо и ОС, а симулятор (iOS) лишь имитирует окружение без настоящей эмуляции железа. Предпочитайте эмуляторы/симуляторы для раннего, дешёвого и широкого покрытия, а реальные устройства — для финальных и регрессионных прогонов.
Типичные ошибки
- ✗Менять местами определения эмулятора и симулятора
- ✗Думать, что эмулятор заменяет реальное устройство для финальных проверок
- ✗Считать, что симуляторы точно воспроизводят реальную производительность
Уточняющие вопросы
- →Какие дефекты воспроизводимы только на реальном устройстве?
- →Почему симулятор iOS не является настоящим эмулятором железа?
JuniorТеорияЧастоКакие бывают типы мобильных приложений — нативные, веб и гибридные?
Какие бывают типы мобильных приложений — нативные, веб и гибридные?
Нативное приложение собирается под платформу её SDK, имеет полный доступ к устройству и лучшую производительность. Веб-приложение работает в браузере, не зависит от платформы, но ограничено в доступе к устройству. Гибридное — это веб-код в нативной оболочке (WebView), которое жертвует частью производительности ради одной общей кодовой базы.
Типичные ошибки
- ✗Путать гибридное приложение с чисто веб-приложением
- ✗Думать, что нативное приложение работает на обеих платформах из одного бинарника
- ✗Считать, что веб-приложение имеет полный доступ к железу устройства
Уточняющие вопросы
- →Какие различия в тестировании возникают между нативным и гибридным приложением?
- →Почему команда может выбрать гибрид вместо нативного несмотря на потерю производительности?
JuniorТеорияЧастоЧто умеют браузерные DevTools для тестирования и чем отличаются снифферы?
Что умеют браузерные DevTools для тестирования и чем отличаются снифферы?
DevTools (вкладки Network, Console, Elements, Application) изучают страницу, которую отрисовал браузер, и его собственные запросы и ответы. Прокси для разбора трафика (сниффер вроде Charles или Fiddler) стоит между клиентом и сервером и может перехватывать и менять трафик любого приложения, а не только браузера, с map local/remote, точками останова и throttling.
Типичные ошибки
- ✗Думать, что DevTools перехватывают трафик других приложений
- ✗Считать, что сниффер ограничен браузером
- ✗Путать вкладку Network с возможностями полноценного прокси
Уточняющие вопросы
- →Как с помощью прокси навязать ошибку 500 одному запросу?
- →Какая вкладка DevTools показывает заголовки запроса и ответа?
MiddleТеорияЧастоЧто такое тестирование прерываний на мобайле и какие сценарии оно покрывает?
Что такое тестирование прерываний на мобайле и какие сценарии оно покрывает?
Тестирование прерываний проверяет, что приложение корректно ведёт себя, когда что-то прерывает его во время работы, а затем возобновляется. Сценарии: входящий звонок или SMS, push-уведомление, будильник, низкий заряд, сворачивание и повторное открытие, потеря сети и блокировка экрана. Приложение должно сохранять состояние и корректно восстанавливаться после каждого прерывания.
Типичные ошибки
- ✗Сводить его только к входящим звонкам
- ✗Забывать, что приложение должно сохранять и восстанавливать состояние
- ✗Путать его с нагрузочным или стресс-тестированием
Уточняющие вопросы
- →Как проверить, что состояние сохранено после прерывания сворачиванием?
- →Какие прерывания труднее всего воспроизвести на эмуляторе?
MiddleТеорияЧастоКакие ключевые различия iOS и Android должен учитывать тестировщик?
Какие ключевые различия iOS и Android должен учитывать тестировщик?
iOS — закрытая, единообразная экосистема с малым числом моделей и строгими гайдлайнами App Store. Android — open-source с огромной фрагментацией: много вендоров, кастомные оболочки, версии ОС и форм-факторы. Важная ловушка: на устройствах Huawei нет сервисов Google, поэтому push через FCM и вход Google там не работают. У каждой платформы свои языки, сторы и правила ревью.
Типичные ошибки
- ✗Путать, какая платформа открытая, а какая закрытая
- ✗Забывать, что у Huawei нет сервисов Google (push через FCM не работает)
- ✗Недооценивать фрагментацию устройств и версий Android
Уточняющие вопросы
- →Почему push-уведомления могут не работать именно на устройстве Huawei?
- →Как фрагментация Android расширяет матрицу тестовых устройств?
MiddleТеорияЧастоКак читать логи iOS, Android и бэкенда при расследовании дефекта?
Как читать логи iOS, Android и бэкенда при расследовании дефекта?
Android: logcat (через adb logcat или Android Studio). iOS: консоль Xcode или приложение Console на macOS. Бэкенд: централизованная система логов вроде Kibana/ELK или Grafana. Краши идут в Crashlytics или Firebase. Логи дают тестировщику увидеть реальную ошибку, стек-трейс и поток запросов за симптомом, превращая смутное «не сработало» в точную причину для отчёта.
Типичные ошибки
- ✗Менять местами инструменты логов Android и iOS
- ✗Думать, что сообщение на экране — полная причина
- ✗Забывать логи бэкенда и крэш-репортеры
Уточняющие вопросы
- →Где искать нативный краш на Android против iOS?
- →Как лог бэкенда помогает понять, отказал клиент или сервер?
MiddleТеорияЧастоЧем тестирование адаптивного веб-приложения отличается от тестирования нативного приложения?
Чем тестирование адаптивного веб-приложения отличается от тестирования нативного приложения?
Адаптивное веб-приложение варьируется по вьюпорту: брейкпойнты, ширины, ориентация, зум браузера и масштаб текста, через эмуляцию устройств в DevTools. Нативное приложение варьируется по устройству: версии ОС, плотности, вендоры, UI-конвенции платформы, жесты, железо, разрешения и ревью в сторе. Тест адаптива гонится за перестроением вёрстки в браузере; нативный — за фрагментацией устройств и ОС.
Типичные ошибки
- ✗Считать веб- и нативный тест одной и той же работой
- ✗Менять местами ось вьюпорта (веб) с осью устройства (нативное)
- ✗Забывать, что ревью в сторе, жесты и разрешения — только для нативного
Уточняющие вопросы
- →Какая функция DevTools помогает быстро проверить адаптивные брейкпойнты?
- →Почему нативному приложению нужна более широкая матрица устройств, чем веб-приложению?
MiddleТеорияИногдаЧто такое браузерный движок и какие есть основные?
Что такое браузерный движок и какие есть основные?
Браузерный движок — это компонент, который парсит HTML/CSS и отрисовывает страницу. Три основных: Blink (Chromium → Chrome, Edge, Opera), WebKit (Safari) и Gecko (Firefox). Главное для тестировщика: Chrome и Edge делят движок, а Safari и Firefox — нет, поэтому кросс-браузерные баги кучкуются на не-Blink движках.
Типичные ошибки
- ✗Называть браузеры (Chrome) вместо движков (Blink)
- ✗Считать, что Safari или Firefox работают на Chromium/Blink
- ✗Думать, что тест одного браузера покрывает все движки
Уточняющие вопросы
- →Почему Safari часто вскрывает баги, которых нет в Chrome?
- →Как составить матрицу кросс-браузерного теста по движкам?
MiddleТеорияИногдаЧто такое DOM и как тестировщики его используют?
Что такое DOM и как тестировщики его используют?
DOM (Document Object Model) — это дерево объектов, которое браузер строит из HTML страницы, представляя каждый элемент и его состояние. Тестировщики используют его, чтобы находить элементы селекторами (CSS/XPath) для ручных проверок и автоматизации, изучать или менять текущее состояние элемента и проверять, что отрисованная структура соответствует ожидаемой.
Типичные ошибки
- ✗Путать DOM со статическим HTML-исходником
- ✗Думать, что DOM не меняется после загрузки
- ✗Считать, что селекторы не работают по DOM
Уточняющие вопросы
- →Как динамическое изменение DOM делает локатор нестабильным?
- →Какой селектор вы выберете для стабильной ссылки на элемент?
MiddleТеорияИногдаКак просматривать и менять сетевые запросы с мобильного устройства?
Как просматривать и менять сетевые запросы с мобильного устройства?
Пропустите устройство через прокси — Charles, Fiddler, Proxyman или mitmproxy — и установите его доверенный корневой сертификат, чтобы он читал HTTPS. После этого можно изучать запросы и ответы, менять их, делать map local/remote, переписывать значения, замедлять сеть и инжектировать сбои (например навязать 500 одному эндпоинту), чтобы проверить, как приложение обрабатывает ошибки.
Типичные ошибки
- ✗Забывать про доверенный корневой сертификат для HTTPS
- ✗Думать, что прокси не может менять, а только наблюдать
- ✗Считать, что браузерные DevTools захватывают трафик нативного приложения
Уточняющие вопросы
- →Почему для чтения HTTPS-трафика нужен доверенный корневой сертификат?
- →Как сымитировать медленную сеть только для одного эндпоинта?
MiddleДебаггингИногдаОдно из двух одинаковых устройств не получает push — определите причину
Одно из двух одинаковых устройств не получает push — определите причину
Раз бэкенд и сеть исключены, причина на стороне устройства или аккаунта. Проверьте: отключённое разрешение на уведомления, выключенные системные или приложенческие уведомления, battery saver / Doze, убивающий фоновый процесс, устаревший или отсутствующий push-токен, отсутствие сервисов Google (Huawei → FCM-токен не выдан), другой залогиненный аккаунт, режим «Не беспокоить» или различие push по версии ОС.
Открыть задачу →Типичные ошибки
- ✗Винить общий код приложения, когда различие на стороне устройства
- ✗Забывать, что разрешения, battery saver и Doze блокируют push
- ✗Упускать причину отсутствия сервисов Google (Huawei/FCM)
Уточняющие вопросы
- →Как проверить, есть ли у устройства B валидный push-токен?
- →Почему устройство Huawei никогда не получит FCM-push?
MiddleТеорияИногдаЧто специфично для мобильного тестирования и какие дефекты бывают только там?
Что специфично для мобильного тестирования и какие дефекты бывают только там?
Мобайл добавляет проблемы, которых нет на десктопе: переходы сети (Wi-Fi↔мобильный, потеря), прерывания (звонки, SMS, push), огромную фрагментацию устройств и экранов, жизненный цикл (фон/передний план, выгрузка системой), разрешения и батарею. Дефекты только мобайла кучкуются вокруг этого — потеря состояния при сворачивании, поломка на нестабильной связи или вёрстка на необычном экране.
Типичные ошибки
- ✗Считать, что десктопный набор полностью покрывает мобайл
- ✗Забывать про жизненный цикл (фон/передний план/выгрузка)
- ✗Игнорировать переходы сети и фрагментацию устройств
Уточняющие вопросы
- →Что такое тестирование прерываний и приведите два примера?
- →Как приоритизировать дефект только мобайла против функционального?
SeniorДизайнИногдаВаше мобильное приложение выходит в 14 странах. Спроектируйте стратегию тестирования и регресса: что проверять по локалям (переводы, RTL, форматы даты/чисел/валюты, локаль устройства против локали в приложении), как учитывать региональных платёжных эквайеров и любые юридические или регуляторные различия, как масштабировать матрицу устройств по рынкам и как вы бы приоритизировали по рискам и ограничили по времени полный регресс, чтобы он оставался выполнимым. Объясните, как решаете, что перетестировать везде, а что только в затронутых регионах.
Ваше мобильное приложение выходит в 14 странах. Спроектируйте стратегию тестирования и регресса: что проверять по локалям (переводы, RTL, форматы даты/чисел/валюты, локаль устройства против локали в приложении), как учитывать региональных платёжных эквайеров и любые юридические или регуляторные различия, как масштабировать матрицу устройств по рынкам и как вы бы приоритизировали по рискам и ограничили по времени полный регресс, чтобы он оставался выполнимым. Объясните, как решаете, что перетестировать везде, а что только в затронутых регионах.
Покройте локализацию насквозь: переводы и обрезание текста, RTL-вёрстку, локале-специфичные форматы даты/чисел/валюты и разделение локали устройства против локали в приложении. Проверьте эквайера и юридические/регуляторные правила каждого региона и постройте матрицу устройств по доле рынка. Объём регресса — по рискам: общий core перетестировать везде, а локале- и платёже-специфичные потоки только в затронутых регионах, с тайм-боксом плюс буфер на риск.
Типичные ошибки
- ✗Сводить локализацию к одному переводу текста
- ✗Игнорировать расхождение локали устройства и локали в приложении
- ✗Гонять полный регресс везде вместо риск-скоупинга по регионам
Уточняющие вопросы
- →Как протестировать RTL-вёрстку, не зная языка?
- →Как региональные платёжные эквайеры меняют подготовку тестовых данных?
SeniorДизайнИногдаМобильное приложение подтормаживает на части устройств. Спроектируйте, как вы проверите плавность и локализуете причину: какой целевой кадр и бюджет времени на кадр вы держите, как воспроизводите и измеряете подтормаживания (на каких устройствах, какими инструментами), какие метрики смотрите помимо кадров и как оформите дефект производительности, чтобы разработчик мог по нему действовать. Объясните, почему тест только на флагмане вводит в заблуждение.
Мобильное приложение подтормаживает на части устройств. Спроектируйте, как вы проверите плавность и локализуете причину: какой целевой кадр и бюджет времени на кадр вы держите, как воспроизводите и измеряете подтормаживания (на каких устройствах, какими инструментами), какие метрики смотрите помимо кадров и как оформите дефект производительности, чтобы разработчик мог по нему действовать. Объясните, почему тест только на флагмане вводит в заблуждение.
Цель — 60 fps, бюджет ~16,6 мс на кадр; кадры дольше отбрасываются и читаются как подтормаживание. Воспроизводите на слабых и старых устройствах, а не только на флагмане, и измеряйте профайлером — отброшенные кадры, нагрузку CPU/GPU, память и время старта. Оформляйте дефект с устройством, ОС, шагами, трассой метрики и видео, чтобы разработчик действовал по конкретной измеренной регрессии, а не по смутному ощущению.
Типичные ошибки
- ✗Тестировать только на флагманском устройстве
- ✗Сообщать о тормозах по ощущению без метрик и трассы
- ✗Игнорировать CPU/GPU, память и старт помимо кадров
Уточняющие вопросы
- →Почему бюджет на кадр около 16,6 мс для 60 fps?
- →Что вы зафиксируете, чтобы разработчик воспроизвёл подтормаживание?
SeniorДизайнИногдаВам нужно протестировать доступность для скринридера на single-page-приложении, где навигация меняет вид, переписывая DOM на клиенте, без полной перезагрузки страницы. Тест для зрячих проходит, но незрячие пользователи сообщают, что после нажатия ссылки ничего не озвучивается, фокус остаётся на старом элементе, а динамически загруженный контент молчит. Спроектируйте подход к тесту со скринридером: какие вспомогательные технологии и платформы охватите (VoiceOver, TalkBack, NVDA), как проверите, что смены маршрута озвучиваются и фокус переносится верно, как должны вести себя ARIA live-регионы и роли для динамического контента и почему одни автоматические сканы доступности не поймают эти специфичные для SPA проблемы.
Вам нужно протестировать доступность для скринридера на single-page-приложении, где навигация меняет вид, переписывая DOM на клиенте, без полной перезагрузки страницы. Тест для зрячих проходит, но незрячие пользователи сообщают, что после нажатия ссылки ничего не озвучивается, фокус остаётся на старом элементе, а динамически загруженный контент молчит. Спроектируйте подход к тесту со скринридером: какие вспомогательные технологии и платформы охватите (VoiceOver, TalkBack, NVDA), как проверите, что смены маршрута озвучиваются и фокус переносится верно, как должны вести себя ARIA live-регионы и роли для динамического контента и почему одни автоматические сканы доступности не поймают эти специфичные для SPA проблемы.
Тестируйте вспомогательными технологиями на каждой платформе — VoiceOver на iOS, TalkBack на Android, NVDA на десктоп-вебе — а не одними автосканами. Убедитесь, что каждая клиентская смена маршрута озвучивается и фокус переходит на новый вид, а не остаётся на старом. Подтвердите, что динамический контент раскрывается через ARIA live-регионы и верные роли, так что читается вслух. Автотулы проверяют статичную разметку и упускают эти сбои SPA.
Типичные ошибки
- ✗Доверять автосканам покрытие поведения скринридера на SPA
- ✗Не озвучивать клиентские смены маршрута и не переносить фокус
- ✗Оставлять динамический контент вне ARIA live-регионов, из-за чего он молчит
Уточняющие вопросы
- →Как перенести фокус скринридера после клиентской смены маршрута?
- →Какие сбои SPA упускает автоматический скан доступности?
JuniorТеорияРедкоЧто означают цифры в номере версии приложения вроде 4.21.3?
Что означают цифры в номере версии приложения вроде 4.21.3?
Это семантическое версионирование, MAJOR.MINOR.PATCH. MAJOR (4) растёт при ломающих, несовместимых изменениях; MINOR (21) — при новых обратно совместимых функциях; PATCH (3) — при обратно совместимых исправлениях багов. Схема позволяет тестировщику или пользователю оценить риск обновления по одним лишь цифрам.
Типичные ошибки
- ✗Менять порядок major, minor и patch
- ✗Думать, что патч-релиз может вносить ломающие изменения
- ✗Считать, что цифры не несут смысла о совместимости
Уточняющие вопросы
- →Какой сегмент должен меняться при обратно совместимой новой функции?
- →Как номер версии помогает определить объём регресса?
SeniorДизайнРедкоУ вашего мобильного приложения пользователи на сотнях моделей устройств Android и iOS, версий ОС, размеров и плотностей экранов, и протестировать все невозможно. Спроектируйте, как вы построите и будете поддерживать матрицу тестовых устройств при такой фрагментации: какие данные используете для выбора значимых устройств (доля рынка, ваша аналитика, крэш-репорты, бизнес-критичные сегменты), как сбалансируете реальные устройства против эмуляторов и облачной фермы устройств, как разобьёте матрицу по уровням, чтобы smoke-набор гонялся на каждой сборке, а более широкий — перед релизом, и как удержите матрицу актуальной по мере появления новых устройств, версий ОС и вендорских причуд (например, отсутствие сервисов Google у Huawei). Объясните, чем обоснуете то, что намеренно оставляете непокрытым.
У вашего мобильного приложения пользователи на сотнях моделей устройств Android и iOS, версий ОС, размеров и плотностей экранов, и протестировать все невозможно. Спроектируйте, как вы построите и будете поддерживать матрицу тестовых устройств при такой фрагментации: какие данные используете для выбора значимых устройств (доля рынка, ваша аналитика, крэш-репорты, бизнес-критичные сегменты), как сбалансируете реальные устройства против эмуляторов и облачной фермы устройств, как разобьёте матрицу по уровням, чтобы smoke-набор гонялся на каждой сборке, а более широкий — перед релизом, и как удержите матрицу актуальной по мере появления новых устройств, версий ОС и вендорских причуд (например, отсутствие сервисов Google у Huawei). Объясните, чем обоснуете то, что намеренно оставляете непокрытым.
Выбирайте устройства по данным: доля рынка, ваша аналитика использования, очаги крэш-репортов и бизнес-критичные сегменты. Балансируйте реальные устройства для ценных случаев против эмуляторов и облачной фермы для широты. Разбейте на уровни: smoke-набор на сборку, более широкий взвешенный по риску перед релизом. Обновляйте по мере новых моделей, версий ОС и вендорских причуд, обосновывая каждое непокрытое устройство малой долей и риском.
Типичные ошибки
- ✗Выбирать устройства на глаз вместо доли, аналитики и крэш-данных
- ✗Тестировать только флагман, игнорируя фрагментацию слабых устройств
- ✗Позволять матрице устаревать по мере выхода новых моделей и версий ОС
Уточняющие вопросы
- →Какой источник данных лучше всего показывает устройства ваших реальных пользователей?
- →Как бы вы решили, что устройство безопасно оставить непокрытым?
SeniorДизайнРедкоМобильное приложение используют в поездах и внутри зданий, где связь не чисто «включена или выключена», а прерывистая — высокая задержка, потеря пакетов, запросы, отваливающиеся по таймауту на полпути, и постоянное перескакивание между Wi-Fi и сотовой. Пользователи сообщают о дублях заказов после повтора, о вечно крутящемся спиннере и о правках, которые молча пропадают после возврата в онлайн. Спроектируйте подход к тесту этой деградированной нестабильной связи: как вы воспроизведёте её детерминированно, какое поведение проверите (офлайн-очередь и синхронизация при переподключении, повтор с backoff, идемпотентность повторных записей, разрешение конфликтов, рендер частичных данных, таймауты и обратная связь пользователю) и чем это отличается от теста одного чистого обрыва сети.
Мобильное приложение используют в поездах и внутри зданий, где связь не чисто «включена или выключена», а прерывистая — высокая задержка, потеря пакетов, запросы, отваливающиеся по таймауту на полпути, и постоянное перескакивание между Wi-Fi и сотовой. Пользователи сообщают о дублях заказов после повтора, о вечно крутящемся спиннере и о правках, которые молча пропадают после возврата в онлайн. Спроектируйте подход к тесту этой деградированной нестабильной связи: как вы воспроизведёте её детерминированно, какое поведение проверите (офлайн-очередь и синхронизация при переподключении, повтор с backoff, идемпотентность повторных записей, разрешение конфликтов, рендер частичных данных, таймауты и обратная связь пользователю) и чем это отличается от теста одного чистого обрыва сети.
Воспроизводите через прокси или link conditioner: задержка, потеря пакетов, перескоки Wi-Fi/сотовая — не только режим полёта. Проверьте офлайн-очередь и синхронизацию при переподключении, повтор с backoff и идемпотентность повторных записей, чтобы переотправленный заказ не задвоился. Проверьте разрешение конфликтов, рендер частичных данных, таймауты и обратную связь. Фокус — целостность данных, а не восстановление после обрыва.
Типичные ошибки
- ✗Тестировать только чистый обрыв вкл/выкл, а не деградированную нестабильную связь
- ✗Игнорировать идемпотентность, из-за чего повторная запись дублирует действие
- ✗Пропускать разрешение конфликтов для правок, сделанных офлайн
Уточняющие вопросы
- →Как бы вы сделали повторный платёжный запрос безопасно идемпотентным?
- →Какой инструмент впрыскивает задержку и потерю пакетов для детерминированного повтора?
