В прошлом уроке — чек-лист по прерываниям, разрешениям, сети, ориентации и жестам. Но за самим внешним видом мобильной вёрстки прячутся дефекты, которые вы ещё не ловили. Даже если элементы не наезжают друг на друга и помещаются на экране (это мы уже проверяли в главе 7 на трёх ширинах), картинка может быть нечёткой на одном телефоне и чёткой на другом, часть контента может прятаться под вырезом камеры, а кнопка может визуально помещаться, но быть слишком маленькой, чтобы в неё точно попасть пальцем. В этом уроке — что проверять глубже вёрстки, обзорно про мобильные сборки, и как правильно собирать доказательства мобильного дефекта для баг-репорта.
Чему научишься за этот урок:
— объяснять, что такое плотность пикселей (DPR) и почему она влияет на чёткость вёрстки отдельно от её ширины;
— проверять зону безопасности (safe area) вокруг выреза камеры и системных элементов экрана;
— находить дефекты размера touch-таргетов — отдельный от наложения элементов класс проблем;
— понимать, что тестировщик обычно не собирает мобильные сборки сам, а получает готовые от разработчиков;
— собирать доказательства мобильного дефекта: экран-запись, логи устройства, точные данные об устройстве.
Плотность пикселей: почему одна вёрстка выглядит по-разному чётко
В главе 7 мы проверяли вёрстку на трёх типичных ШИРИНАХ экрана — десктоп, планшет, мобильный. Но у двух телефонов с одинаковой шириной экрана в пикселях CSS вёрстка может выглядеть по-разному чётко. Дело в плотности пикселей (device pixel ratio, DPR) — количестве физических пикселей экрана, приходящихся на один логический пиксель CSS. У экрана с DPR 1 один логический пиксель соответствует одному физическому; у экрана с DPR 3 — уже девяти физическим пикселям (3×3), и изображение или иконка, подготовленные без учёта высокой плотности, будут выглядеть размытыми, хотя ширина и расположение элементов останутся прежними. Это не тот же дефект, что «поломка вёрстки при другой ширине» из главы 7 — там страдает расположение, здесь страдает чёткость картинки при абсолютно правильном расположении.
Зона безопасности и вырез камеры (notch)
У части современных телефонов часть экрана физически занята вырезом камеры (notch), скруглёнными углами или системной полосой снизу для жестов возврата. Область экрана, которая гарантированно не перекрыта этими элементами, называется зоной безопасности (safe area). Если вёрстка не учитывает это ограничение, важный элемент — например, кнопка или текст в шапке страницы — может частично уехать под вырез камеры или системную полосу и оказаться нечитаемым или ненажимаемым, хотя по ширине экрана всё выглядело нормально. Проверить это можно в DevTools: в панели устройств есть модели с вырезом камеры (например, iPhone с notch), и режим адаптивного дизайна показывает, как вёрстка ведёт себя вокруг этой зоны.
Размер touch-таргетов
На десктопе пользователь кликает мышью — точным устройством ввода, способным попасть даже в маленький элемент. На мобильном пользователь нажимает пальцем — менее точным «инструментом», которому нужна область побольше. Touch-таргет — это кликабельная область элемента (кнопки, ссылки, иконки), рассчитанная на нажатие пальцем. Дефект размера touch-таргета — это отдельный от «наложения элементов» из главы 7 класс проблемы: кнопка может визуально не наезжать на соседний элемент и полностью помещаться на экране, но быть слишком маленькой или расположенной слишком близко к другой кликабельной области — так, что палец пользователя случайно попадает не туда или не попадает вовсе. Такой дефект не всегда заметен на скриншоте — иногда его нужно буквально попробовать нажать пальцем на реальном устройстве или через эмуляцию touch в DevTools.
Сборки: обзорно
Мобильное native-приложение распространяется не в виде страницы по ссылке, а в виде сборки — файла APK для Android или сборки, публикуемой через App Store для iOS (IPA). Тестировщик обычно не собирает эти файлы сам: сборку готовит разработчик или система автоматической сборки (CI), а тестировщик получает уже готовый файл или ссылку на тестовую версию для установки. На этом курсе мы сборки не создаём — это, как и весь native, честное ограничение курса mobile web-платформы, о котором говорилось в первом уроке главы.
Сбор доказательств для мобильного баг-репорта
В главе 6 мы разобрали структуру баг-репорта: заголовок, шаги, факт, ожидание, окружение, доказательства. Для мобильного дефекта поля «Доказательства» и «Окружение» становятся особенно важны и приобретают специфику. Кроме обычного скриншота полезна экран-запись (screen recording) — она показывает баг в процессе, например неправильную анимацию при повороте экрана или момент, когда touch-таргет не срабатывает с первого нажатия. Ещё один источник — логи устройства (device logs), доступные через инструменты разработчика на реальном устройстве или эмуляторе. И главное: в поле «Окружение» мобильного баг-репорта обязательно указывать не только браузер и ОС, а модель устройства, разрешение экрана и его плотность пикселей (DPR) — без этого разработчик не сможет понять, воспроизводится ли дефект именно на этой плотности или ширине, и баг-репорт остаётся неполным.
Глубже вёрстки главы 7: - Плотность пикселей (DPR) -> чёткость картинки, не расположение - Зона безопасности (safe area) -> контент под вырезом камеры/полосой - Touch-таргет -> размер кликабельной области под палец Доказательства мобильного бага: - Скриншот - момент времени - Экран-запись - процесс (анимация, срабатывание нажатия) - Логи устройства - техническая причина - Окружение: модель + разрешение + DPR - обязательно
Совет: если баг воспроизводится на одном телефоне и не воспроизводится на другом с той же шириной экрана — первое подозрение не «баг нестабилен», а разная плотность пикселей или другая зона безопасности у этих двух моделей. Проверьте DPR и notch, прежде чем списывать дефект на случайность.
Итог:
— плотность пикселей (DPR) влияет на чёткость вёрстки отдельно от её ширины — это дефект чёткости, а не расположения;
— зона безопасности (safe area) — область экрана, гарантированно свободная от выреза камеры и системных элементов, её нужно проверять отдельно;
— touch-таргет — размер кликабельной области под палец, отдельный от наложения элементов класс дефекта из главы 7;
— сборки (APK/IPA) тестировщик обычно не создаёт сам — получает готовые от разработчиков или CI, на этом курсе сборки не создаём;
— доказательства мобильного бага: скриншот, экран-запись, логи устройства, и обязательно — модель, разрешение и DPR устройства в поле «Окружение» баг-репорта.
Контрольный вопрос. Что такое плотность пикселей (DPR) и на что она влияет?
Подсказка: Речь не про ширину экрана и не про частоту обновления — а про то, из скольких физических точек состоит один логический пиксель.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что называют зоной безопасности (safe area) на мобильном экране?
Подсказка: Ключевое слово здесь про физическое перекрытие экрана устройством, а не про правила размещения контента.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Чем дефект размера touch-таргета отличается от дефекта «наложение элементов» из главы 7?
Подсказка: Подумай, может ли элемент выглядеть на скриншоте абсолютно нормально и всё равно быть проблемой для пальца.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Кто на практике обычно собирает мобильную сборку (APK/IPA) для тестирования?
Подсказка: Вспомни, кто в команде отвечает за компиляцию кода в готовый файл приложения.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие данные обязательно должны быть в поле «Окружение» мобильного баг-репорта (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Три из четырёх пунктов — технические характеристики устройства, ещё один — не факт, а мнение, ему в этом поле не место.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется инструмент доказательства мобильного бага, который показывает дефект В ПРОЦЕССЕ — например, неправильную анимацию при повороте экрана, а не только один момент времени? Ответь термином из урока по-русски (через дефис).
Подсказка: Это не скриншот — скриншот фиксирует только один момент времени.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Кнопка «Записаться на курс» на карточке курса визуально полностью помещается на экране и не наезжает на соседние элементы, но пользователи жалуются, что часто промахиваются пальцем и попадают на соседнюю ссылку «Подробнее». Ответь термином из урока (как он записан в тексте), к какому классу дефекта это относится.
Подсказка: Речь не про наложение элементов на скриншоте, а про размер кликабельной области под палец.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Один и тот же баг воспроизводится на iPhone 14 Pro, но не воспроизводится на iPhone SE, хотя оба телефона показывают вёрстку на очень похожей ширине экрана в DevTools. Какую техническую характеристику экрана тестировщику стоит сравнить в первую очередь, чтобы объяснить разницу? Ответь одним термином — аббревиатурой из трёх букв.
Подсказка: Речь не про ширину экрана — вспомни характеристику, которая отвечает за чёткость картинки при одинаковой ширине.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик нашёл дефект: в шапке мобильной страницы каталога курсов текст заголовка частично уезжает под вырез камеры на iPhone с notch, хотя на других моделях без выреза заголовок виден полностью. Объясни в 2-3 предложениях, как называется эта проблема, почему она не является дефектом «наложение элементов» из главы 7, и как её можно проверить в DevTools.
Критерий приёмки: назван термин «зона безопасности» (safe area) или «вырез камеры» (notch); объяснено, что это отдельный класс дефекта от наложения элементов, потому что связан с физическим перекрытием экрана конкретной моделью устройства, а не с расположением элементов друг относительно друга; указано, что в DevTools нужно выбрать конкретную модель устройства с вырезом камеры (notch) в панели устройств, чтобы это увидеть.
Подсказка: Вспомни термин про область экрана, гарантированно свободную от выреза камеры, и какую модель устройства нужно выбрать в DevTools, чтобы вырез вообще появился.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Вы нашли дефект: на карточке курса на странице каталога кнопка «Записаться на курс» слишком маленькая и расположена слишком близко к ссылке «Подробнее» — палец промахивается примерно в трети попыток. Оформи для этого дефекта поля «Доказательства» и «Окружение» баг-репорта (структура — из главы 6), с учётом мобильной специфики этого урока: какие именно доказательства приложишь и что укажешь в окружении.
Критерий приёмки: в доказательствах названы минимум два разных типа (например, аннотированный скриншот с указанием размера/расстояния между кнопками плюс экран-запись процесса промахивания пальцем); в окружении указаны все три обязательных мобильных параметра — модель устройства, разрешение экрана, плотность пикселей (DPR); отсутствие любого из трёх параметров окружения или единственный тип доказательства — критерий не выполнен.
Подсказка: Пройдись по двум полям баг-репорта из главы 6 отдельно: сначала перечисли типы доказательств для ЭТОГО конкретного дефекта, потом — три обязательных параметра именно мобильного окружения из этого урока.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Это был последний урок главы «Мобильное тестирование». Дальше в курсе — глава «Безопасность и производительность»: что должен замечать manual QA в вопросах безопасности, границы ответственности тестировщика, и как читать отчёт нагрузочного теста.
