Проверка профилей устройств: телефон, планшет и компьютер

Нужно подтвердить работу мобильной оплаты или панели для планшета, не бронируя лабораторию устройств для каждой проверки? BotBrowser повторяет заданное утвержденным профилем условие отображения, ввода, медиа и платформы внутри браузера, но не доказывает работу реальных датчиков, диалогов операционной системы или производительность устройства; для таких критериев приемки используйте физическое оборудование.

Кратко

Используйте один утвержденный профиль для названного сценария, фиксируйте профиль и наблюдаемый результат и переходите к физическому устройству, когда приемка зависит от оборудования или поведения ОС вне браузера.

Содержание

• Начать с сценария
• Выбрать семейства устройств
• Проверить формы и сенсорный ввод
• Контролировать ориентацию и разрешения
• Сохранить выпускные доказательства
• Перейти к физическому устройству
• Практический вывод

Начинайте с пользовательского сценария, а не с ширины экрана

Страница на телефоне - это не просто суженная страница для компьютера. Сенсорный ввод меняет реакцию элементов управления. Экранная клавиатура меняет доступную область вокруг форм. Ориентация влияет на навигацию и медиа. Особенности платформы определяют меню, загрузку файлов, разрешения и способ, которым браузер передает задачу другому приложению. Полезная проверка устройства рассматривает все эти виды поведения вместе.

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

Практическая отправная точка - путь клиента: выберите профиль телефона для оплаты с мобильного, профиль планшета для сенсорной панели управления и профиль компьютера для сценария на рабочей станции. Запишите этот выбор вместе с тестовым случаем, чтобы проверяющие могли воспроизвести те же условия и понять, что именно отражают результаты.

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

Согласованность профиля не заменяет управление процессом. Командам следует использовать утвержденные тестовые учетные записи, разрешенные адреса, контролируемые данные и политику хранения скриншотов и журналов. Охват устройств должен следовать письменно зафиксированной цели QA, потому что длинный список профилей менее полезен, чем небольшой набор, связанный с реальными требованиями продукта.

Профиль устройства полезнее всего тогда, когда проверяющие рассматривают его как полное тестовое условие. К соответствующим семействам поведения относятся:

• Дисплей: доступная область страницы, плотность отображения, ориентация, полноэкранный режим и адаптивная раскладка.
• Ввод: касание, указатель, клавиатура, фокус, выделение, перетаскивание и жестовые элементы управления.
• Формы: влияние экранной клавиатуры, сообщения проверки, раскладка автозаполнения, элементы выбора даты и времени, выбор файлов.
• Медиа: адаптивные изображения, элементы управления воспроизведением, запросы разрешения на захват и подходящее для устройства представление.
• Идентичность платформы: контекст семейства браузера и операционной системы, представленный как единое семейство устройств.
• Графика и текст: поведение отрисовки, подходящее выбранному профилю и проверяемому содержимому.
• Региональный контекст: язык, часовой пояс и сетевое расположение, выбранные по разрешенному плану тестирования.

Используйте эти категории, чтобы наблюдать за приложением: остается ли элемент управления видимым, можно ли завершить форму, соблюдается ли согласие и дает ли один и тот же профиль стабильный результат.

Храните device-profile, journey-id, expected-result и evidence-id вместе с записью случая. Для геометрического контракта клавиатуры используйте VirtualKeyboard: границы viewport и inset, где политика профиля отделена от данных visual viewport.

Выбор профилей и проверка каждого семейства устройств

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

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

Записывайте, почему каждый профиль входит в набор. Короткая заметка вроде «покрывает оформление заказа на узком экране» или «представляет панель управления с приоритетом касания» помогает позднее решить, оправдывает ли профиль свое место. Если два профиля всегда дают одни и те же находки, оставьте тот, который соответствует более реальному использованию, а другой уберите.

Телефон. Проверка на телефоне должна идти по законченным задачам. Снимок главной страницы мало говорит о том, сможет ли клиент войти, сделать выбор по согласию, восстановить учетную запись, загрузить документ или завершить покупку. Пройдите путь от входа до завершения с одним и тем же профилем и уделите особое внимание элементам у нижнего края экрана, закрепленной навигации, диалогам и многошаговым формам. Проверяйте портретную и альбомную ориентацию только если продукт поддерживает обе.

Областям касания нужны достаточные промежутки, но проверка должна также подтверждать доступ с клавиатуры там, где его обещает продукт. Профиль телефона не повод пренебрегать порядком фокуса, подписями, восстановлением после ошибок и настройками уменьшения анимации. Проверки приватности и доступности на мобильных устройствах часто выявляют одни и те же проблемы проектирования: скрытые варианты выбора, неясное состояние или элементы, зависящие от единственного способа ввода.

Планшет. Раскладки для планшетов часто находятся между допущениями для мобильных устройств и для компьютеров. Сайт может перейти к многоколоночной раскладке, пока ввод остается преимущественно сенсорным, а компактное меню может стать постоянной боковой панелью. Используйте профили планшетов для панелей управления, инструментов учета, приложений выездного обслуживания, образовательных продуктов и медиа-сервисов. Проверьте разделенные экраны, большие диалоги, перетаскивание, виртуальные клавиатуры и поворот и убедитесь, что увеличенная ширина не открывает элементы, предназначенные только для компьютера и неудобные при касании. Проверка планшета - это не растянутая проверка телефона, поэтому подготовьте для нее собственные ожидаемые снимки экрана и заметки о взаимодействии.

Компьютер. Профили компьютеров остаются важными, даже если мобильного трафика больше. Сценарии на рабочей станции часто включают длинные формы, задачи в нескольких окнах, скачивание, загрузку файлов, сочетания клавиш и плотную информацию. Сохраняйте задокументированную базу для сравнения, потому что случайный размер окна при каждом запуске затрудняет понимание изменений на снимках. Проверка на компьютере также служит контролем для мобильных находок: если диалог согласия не работает только в профиле телефона, у команды более узкая область поиска, а если он не работает во всех семействах устройств, проблема может быть в общей логике приложения.

Записывайте profile-rationale, coverage-family, review-date и retire-decision для каждого выбранного профиля.

Формы, экранная клавиатура и сенсорный ввод

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

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

Различие между областью просмотра раскладки и визуальной областью просмотра объясняет, почему поведение клавиатуры требует отдельной проверки. MDN описывает визуальную область просмотра как видимую часть страницы без экранных клавиатур и других элементов, которые не масштабируются вместе со страницей. Когда клавиатура открывается, видимая область может уменьшиться, а раскладка, на которую опираются CSS и фиксированное позиционирование, остается прежней. Поэтому закрепленный нижний блок, рассчитанный по раскладке, может оставить главное действие под клавиатурой, а страница, реагирующая на изменения видимой области, способна сохранить это действие доступным. Более полную модель проверки, охватывающую состояния области просмотра и сценарии с клавиатурой и касанием, см. в статье Проверка качества мобильного профиля браузера.

Формулируйте ожидаемый результат проверки клавиатуры в наблюдаемых терминах. Для формы входа: поле с фокусом остается в видимой области, сообщение проверки появляется рядом с полем и не скрыто клавиатурой, кнопку отправки можно достичь, не покидая страницу, а потеря фокуса возвращает страницу в разумную позицию. Храните эти результаты как короткий список внутри тестового случая и выполняйте их с профилем, выбранным для этого случая, чтобы другой проверяющий мог повторить последовательность и сравнить результат.

Для мобильного поведения с учетом клавиатуры используйте задокументированную настройку продукта, а не накладывайте на профиль область просмотра из фреймворка. Профиль должен оставаться владельцем условия устройства на протяжении всей проверки, а средство автоматизации должно только проходить утвержденный сценарий.

Проверка ввода должна опираться на результаты для пользователя. Убедитесь, что касания запускают нужный элемент, прокрутка не вызывает соседнее действие, маркеры перетаскивания остаются удобными, а меню можно закрыть. Если сценарий поддерживает указатель или физическую клавиатуру, проверяйте это условие отдельно и сохраняйте для него собственные результаты. О том, как ведут себя события мыши, касания и пера и как сохранить доступность каждого пути, см. в статье События указателя и доступный ввод: мышь, сенсорный экран и перо.

Ручная проверка по-прежнему ценна. Автоматические проверки могут подтвердить, что элемент существует и задача выполняется, а проверяющий может заметить, что меню выглядит перегруженным, объяснение разрешения неясно, а выбор по приватности становится трудно найти после поворота. Профили устройств не заменяют проверку доступности, для которой по-прежнему нужны семантические проверки, охват клавиатурой и программой экранного доступа, проверка контрастности, управление фокусом и квалифицированные тестировщики.

Фиксируйте focus-target, visualViewport.height, validation-state и return-position для последовательности формы.

Ориентация, медиа, разрешения и региональный контекст

Проверяйте смену ориентации только там, где пользователи действительно поворачивают устройство. Медиа, просмотр документов, карты, диаграммы и некоторые инструменты для планшетов часто требуют обеих ориентаций, тогда как оформление заказа, официально рассчитанное только на портретный режим, может в этом не нуждаться. Если ориентация входит в область проверки, убедитесь в непрерывности: страница должна сохранять значимое состояние, держать активную задачу на виду, не открывать повторно закрытые диалоги и не терять введенные в форму данные. О том, как работает поворот как состояние раскладки и как сохранить задачу целой при повороте, см. в статье Screen Orientation API и адаптивные интерфейсы.

Фиксируйте результаты до и после изменения с одним и тем же профилем. Не совмещайте проверку ориентации с не связанным изменением языка, сетевого региона или состояния учетной записи. Одно контролируемое изменение делает результат понятнее.

Камера, микрофон, геолокация, уведомления и доступ к файлам затрагивают и представление в браузере, и согласие внутри приложения. Проверяйте эти пути только с разрешенными учетными записями и утвержденными тестовыми данными. Приложение должно объяснять, зачем запрашивается доступ, обрабатывать отказ, не загоняя пользователя в тупик, и позволять позже изменить выбор там, где продукт это поддерживает. Для медиа убедитесь, что предпросмотр, отключение звука, отмена и восстановление после ошибки работают как ожидается.

Результаты разрешений могут сохраняться в каталоге данных браузера, поэтому применяйте осознанную политику тестового состояния. Чистое состояние подходит для согласия при первом запуске, а сохраненное - для повторных визитов. Помечайте результаты, чтобы другой проверяющий знал, какое условие проверялось.

Семейство устройств - лишь часть мобильного опыта. Язык, часовой пояс и сетевой регион могут менять содержимое, форматирование, обязательства по согласию и каналы поддержки. Выбирайте эти значения по разрешенному плану тестирования и сохраняйте их согласованными со сценарием. Профиль телефона не требует определенного типа сети, но маршрут должен быть утвержден, задокументирован и достаточно стабилен, чтобы результат можно было проверить. Не допускайте попадания учетных данных на снимки экрана и в общие журналы.

Запускайте региональные варианты как отдельные случаи. Не смешивайте небрежно смену языка с другой учетной записью, другим профилем и другим сетевым маршрутом. Четкие границы случаев упрощают воспроизведение сбоев и сокращают лишний сбор пользовательских данных.

Называйте контролируемые входы orientation-change, permission-state, locale и network-route.

Результаты проверки, матрицы выпуска и CI

Полезные результаты связывают условие устройства с наблюдаемым поведением приложения. Записывайте семейство профиля, сборку браузера, сборку приложения, класс тестовой учетной записи, региональные параметры, ориентацию и попытанный сценарий. Сохраняйте самый небольшой снимок или запись, которые объясняют результат, и удаляйте персональные данные перед передачей.

Журналы требуют той же сдержанности. Вывод консоли приложения, сетевые трассировки и диагностика браузера могут содержать идентификаторы или сведения об учетных записях. Собирайте только то, что нужно для расследования, храните это по политике хранения команды и ограничивайте доступ. Четко называйте ожидаемые базовые состояния, чтобы проверяющие могли понять, относится ли снимок к оплате на телефоне, панели управления на планшете или сценарию поддержки на компьютере, не открывая отдельную таблицу.

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

Большие матрицы часто становятся медленными, и их начинают игнорировать. Отделите небольшой выпускной барьер от более широкого планового охвата: барьер включает семейства устройств и сценарии, сбой которых заблокирует поставку, а плановые запуски охватывают дополнительные раскладки, языки и более редкие процессы. Назначьте владельца каждому случаю и держите карантин временным и заметным. Если случай для устройства нестабилен, запишите причину, сохраните более небольшой диагностический случай и назначьте дату пересмотра вместо того, чтобы молча принимать меняющиеся снимки или повторные попытки.

CI-раннерам нужны тот же профиль, та же сборка браузера, те же шрифты и вспомогательные ресурсы и то же состояние приложения, что и в утвержденной базе. Передавайте эти входные данные через обычные средства организации для секретов и артефактов и не загружайте другой профиль при каждом запуске, если проверка явно не охватывает ротацию профилей. Не позволяйте настройкам отображения фреймворка переопределять условие устройства, заданное профилем, и используйте отдельные экземпляры браузера для разных идентичностей устройств, чтобы состояние хранилища и сбои можно было отнести к предполагаемому профилю.

Планирование мощности должно опираться на измерения на ваших страницах. У панели управления с большим объемом медиа и простой формы разная стоимость по памяти, графике и сети. Начните с небольшого числа одновременных запусков, понаблюдайте за временем завершения и запасом ресурсов, а затем выберите предел для этой нагрузки.

Обновления браузера, профиля, средства автоматизации и приложения могут по-разному влиять на проверку устройства. По возможности меняйте один слой за раз, запускайте выпускной барьер до расширения до плановой матрицы и сравнивайте с базой, созданной тем же семейством профиля. После обновления перепроверьте согласие, разрешения, восстановление учетной записи, загрузку файлов и оплату и храните старые результаты только пока это оправдано политикой и инженерной пользой.

Каждая строка матрицы содержит browser-build, profile-revision, app-build и matrix-case.

Когда физическое устройство все же необходимо

Настольная проверка на основе профилей не отменяет потребность в физических устройствах. Используйте оборудование, когда критерии приемки зависят от настоящей камеры, радиомодуля, биометрического датчика, диалога операционной системы, передачи в другое приложение, поведения оборудования конкретного производителя или производительности при реальных условиях заряда батареи и нагрева. Оборудование также уместно для итоговой сертификации, если ее требует договор или политика платформы.

Полезное правило эскалации простое: если ожидаемый результат зависит от физического оборудования или службы операционной системы вне браузера, подтвердите его на целевом устройстве. Если он относится к отображению в браузере и поддерживаемому сценарию на основе профиля, выполнение на компьютере или сервере может дать повторяемые результаты, нужные команде, а ограниченное время лаборатории устройств будет потрачено на условия, которым действительно нужно оборудование.

BotBrowser может запускать соответствующие мобильные профили Android или семейства WebKit с поддержкой касания, определяемой профилем. С задокументированной опцией --bot-mobile-keyboard доверенный фокус на редактируемом поле уменьшает visualViewport.height, не меняя область просмотра раскладки, поэтому команда может повторять мобильную проверку форм и клавиатуры из одного задокументированного условия профиля. Профили компьютеров эту опцию игнорируют. BotBrowser не может заменить физические устройства, настоящие клавиатуры операционной системы, системные диалоги или поведение оборудования и не гарантирует, что каждое устройство или раскладка приложения будут вести себя одинаково.

Выбирайте проверку устройств на основе профилей, когда команде нужна повторяемая QA для браузера в семействах телефона, планшета и компьютера, особенно в CI или на управляемой инфраструктуре. Выбирайте сервис физических устройств, когда приемка зависит от настоящего оборудования, а стандартную адаптивную эмуляцию - когда задача сводится к раннему наброску раскладки и идентичность устройства вне области проверки. Перед расширением развертывания подтвердите владельца каждого профиля, разрешенное использование, обращение с тестовыми данными, хранение результатов, мощность раннеров и путь эскалации. Эти решения важнее числа названий устройств в каталоге.

Скачайте BotBrowser, чтобы запускать утвержденные профили устройств, или изучите функции согласованности платформы перед планированием развертывания. Для мобильного планирования см. проверку профилей браузера Android. Согласованность экрана и окна описывает проверку адаптивного отображения, а кроссплатформенные профили браузера - выбор вариантов развертывания на хосте.

Итог

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

Источники

• Документация BotBrowser по эмуляции устройств
• MDN: VisualViewport