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

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

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

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

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

Согласованность и защита приватности

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

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

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

Связанные семейства поведения

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

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

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

Выбор представительного набора

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

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

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

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

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

Проверка на телефоне

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

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

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

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

Проверка на планшете

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

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

Подготовьте отдельные ожидаемые снимки и заметки. Если поддерживается внешняя клавиатура или указатель, создайте другое условие и не смешивайте способы ввода в одном запуске.

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

Проверка на компьютере

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

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

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

Формы и экранная клавиатура

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

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

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

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

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

Касание, указатель и клавиатура

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

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

Ориентация и адаптивный макет

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

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

Медиа и разрешения

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

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

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

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

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

Язык и сетевой контекст

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

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

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

Полезные доказательства

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

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

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

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

Поддерживаемая матрица

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

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

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

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

CI и управляемая инфраструктура

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

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

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

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

Когда требуется физическое устройство

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

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

Проверка обновлений

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

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

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

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

Решение о развертывании

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

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

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

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

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

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

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

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

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

Частые вопросы

Может ли один профиль покрыть все телефоны?

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

Должно ли средство автоматизации задавать экран?

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

Могут ли телефон, планшет и компьютер использовать один сеанс?

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

Как проверять касания?

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

Как часто пересматривать профили?

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

Заменяет ли это проверку доступности?

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

Что хранить после запуска?

Минимальные доказательства с профилем, версиями, путем, языком, ориентацией и состоянием. Удалите персональные данные и примените срок хранения.

Документированная базовая среда

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

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