Создавайте матрицу вашего браузера, основанную на рисках, а не на флажках

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

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

Отдельные три решения

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

Playwright документирует поддержку Chromium, Firefox и WebKit, а также фирменных каналов Chromium, таких как Chrome и Edge. Его сборка WebKit не имеет торговой марки Safari. Поэтому зеленый результат WebKit следует рассматривать как свидетельство WebKit, а не как утверждение, что каждая версия Safari на каждом iPhone прошла проверку.

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

Составьте карту пути к риску, который он несет

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

Узнайте у своей команды требования к поддерживаемым браузерам и текущие данные об аудитории. Если такового не существует, запишите предварительный выбор и дату его рассмотрения вместо того, чтобы придумывать проценты клиентов. Инженер QA может вести этот разговор с продуктом и поддержкой; выбор не должен быть скрыт в файле-бегуне, который никто не читает.

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

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

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

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium-desktop', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox-desktop', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit-phone-emulation', use: { ...devices['iPhone 13'] } }
  ]
});

Установите соответствующие двоичные файлы браузера в тестовой среде. Запустите именованный проект с помощью npx playwright test --project=webkit-phone-emulation. Эти имена описывают конфигурацию, а не гарантию на продукт. Код - это отправная точка для вашей собственной политики поддержки, а не универсальная рекомендуемая матрица.

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

Диагностика различий вместо удаления конфигурации

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

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

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

Где подходит созданное исследование

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

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