Побудуйте матрицю свого браузера на основі ризику, а не прапорця

Ваш тестовий пакет має спадне меню браузера. Хтось відбирає все. КІ стає повільнішим, збої множаться, і ніхто не може пояснити, які конфігурації захищають бізнес. Велика матриця виглядає акуратно, але все одно може пропустити той мобільний потік, який клієнти використовують для завершення реєстрації.

Почніть із ризику, а потім виберіть конфігурації, які його піддають. У цьому посібнику використовуються проекти 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 матриця, орієнтована на ризик, запобігає використанню обмеженого часу перегляду через незрозуміле дублювання. Для більшої команди це дає власникам продуктових зон загальний словниковий запас. Корисним результатом є набір конфігурацій, які ви можете захистити, з відомими обмеженнями та видимими подальшими діями, а не найдовший список, який дозволяє екран налаштувань.