Перейти к содержимому

Мониторинг по сценарию

Тест на Playwright по расписанию: вход, корзина, оплата и запросы к API


Сценарий проверяет сайт так, как им пользуется человек: открывает страницы в настоящем браузере, входит в личный кабинет, кладёт товар в корзину и смотрит, что на экране то, что должно быть. Обычная HTTP-проверка увидит, что сайт ответил 200, но не заметит, что кнопка входа перестала работать, а каталог открывается пустым.

Сценарий — это тест на Playwright. Statuser запускает его по расписанию в браузере на своей стороне и открывает инцидент, если тест упал.

Как включить

При добавлении сервера выберите тип мониторинга Сценарий и заполните:

  • Название — оно показывается в списке серверов, на страницах статуса и в уведомлениях. Например, «Вход в личный кабинет».
  • Сценарий — код теста. В новом сервере уже лежит пример, с которого удобно начать.
  • Переменные окружения — логины, пароли и токены, которые нужны тесту. Подробнее — в разделе Пароли и токены.
  • Откуда проверять — город, из которого откроется сайт.
  • Таймаут сценария — сколько может длиться весь прогон.
  • Интервал проверки — как часто запускать сценарий.

Перед сохранением нажмите Запустить в блоке Проверить сценарий: Statuser прогонит тест так же, как по расписанию, и покажет результат со скриншотом, видео и трейсом.

Как написать сценарий

Сценарий можно записать в Codegen, поручить ИИ или написать по примерам ниже.

Записать в Codegen

Проще всего не писать тест руками, а записать. Установите Node.js и запустите запись:

npx playwright codegen https://example.com

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

Попросить ИИ

Тест можно поручить ИИ-ассистенту — Statuser AI в панели или любому другому. Опишите путь по шагам и что считать успехом и попросите тест на @playwright/test одним файлом. Чтобы черновик заработал с первого раза, добавьте в запрос несколько условий:

  • искать элементы по роли и подписи (getByRole, getByLabel), а не по CSS-классам — такие тесты переживают редизайн;
  • после каждого важного шага ставить проверку expect;
  • логин и пароль брать из process.env, а не вписывать в код;
  • обойтись без playwright.config и своих таймаутов — их задаёт Statuser.

Например:

Напиши тест на @playwright/test одним файлом: открыть https://example.com/login,
войти с логином из process.env.LOGIN и паролем из process.env.PASSWORD
и проверить, что появилась надпись «Мой профиль».
Элементы ищи через getByRole и getByLabel, конфиг не нужен.

ИИ не видит ваш сайт и может ошибиться в подписях кнопок и полей — сверьте их со страницей или запишите проблемный шаг в Codegen. Настоящие пароли в чат ассистента не вставляйте: в тест они придут из переменных окружения. Готовый черновик проверьте кнопкой Запустить.

Вход в личный кабинет

import { test, expect } from '@playwright/test';
 
test('вход в личный кабинет', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.getByLabel('Email').fill(process.env.LOGIN!);
  await page.getByLabel('Пароль').fill(process.env.PASSWORD!);
  await page.getByRole('button', { name: 'Войти' }).click();
  await expect(page.getByText('Мой профиль')).toBeVisible();
});

Проверки (expect) — главное в сценарии. Без них тест пройдёт, даже если после входа открылась страница с ошибкой: сам по себе Playwright следит только за тем, что элементы, с которыми вы работаете, нашлись на странице.

Цепочка запросов к API

Сценарий не обязан открывать браузер. Через request можно проверить API, в котором один запрос зависит от другого, — например, получить токен и сходить с ним в защищённый метод:

import { test, expect } from '@playwright/test';
 
test('API: вход и профиль', async ({ request }) => {
  const login = await request.post('https://api.example.com/auth', {
    data: { login: process.env.LOGIN, password: process.env.PASSWORD },
  });
  expect(login.ok()).toBeTruthy();
  const { token } = await login.json();
 
  const profile = await request.get('https://api.example.com/me', {
    headers: { Authorization: `Bearer ${token}` },
  });
  expect(profile.status()).toBe(200);
});

Куки, которые вернул один запрос, request подставляет в следующие сам — сессионную куку передавать руками не нужно.

Несколько проверок в одном сценарии

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

Пароли и токены

Не вписывайте секреты в код. Добавьте их кнопкой Добавить переменную окружения и читайте в тесте через process.env, как в примерах выше.

  • Имя — латинские буквы в верхнем регистре, цифры и _, например PASSWORD.
  • До 20 переменных. Значение одной — до 4 КБ, это около 4000 символов латиницей: хватит на пароль, токен или ключ.
  • Некоторые имена задать нельзя — они нужны Statuser, чтобы запустить тест. Это имена с префиксами PLAYWRIGHT_, PW_, PWTEST_, PWDEBUG, DEBUG, NODE_, LD_ и STATUSER_, а также PATH, HOME, TMPDIR, CI, FORCE_COLOR, HTTP_PROXY, HTTPS_PROXY, NO_PROXY и ALL_PROXY.

Значения хранятся в зашифрованном виде и после сохранения не показываются: поле остаётся пустым с подсказкой Сохранено — оставьте пустым. Чтобы сменить значение, введите новое.

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

Откуда идёт проверка

Сценарий открывает сайт из выбранного города: Москвы, Санкт-Петербурга, Амстердама, Алматы или Нью-Йорка. Город один, и запасного нет: от адреса зависит то, что сценарий часто и проверяет, — геоблоки, белые списки, язык и цены. Выберите город, из которого сайтом пользуются ваши клиенты.

Запросы идут с тех же IP-адресов, что остальные проверки Statuser, а User-Agent у сценария — как у настольного Chrome, с меткой Statuser Bot. Если Statuser уже пропущен в файрволе, добавлять ничего не нужно, а как настроить правило — в статье User-Agent и IP-адреса Statuser.

Как проходит прогон

  • Таймаут — на весь сценарий, а не на один шаг, как в Playwright по умолчанию. Не уложился — прогон считается упавшим. Варианты: 15, 30, 45 секунд, 1 и 2 минуты.
  • Интервал — от 10 минут до суток.
  • Повторов нет: каждый прогон — одна попытка. Если сайт иногда отвечает медленно и тест из-за этого падает, добавьте повтор в сам сценарий строкой test.describe.configure({ retries: 1 }); — он уложится в тот же таймаут.
  • Каждый прогон начинается с чистого листа: новый браузер без кук и кеша. Между прогонами ничего не сохраняется — если тесту нужна авторизация, он входит сам.

Когда открывается инцидент

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

В карточке инцидента — шаг, на котором упал тест, текст ошибки, консоль браузера, скриншот, видео прогона и трейс. Трейс открывается во встроенном просмотрщике Playwright: в нём можно пройти сценарий по шагам, посмотреть страницу до и после каждого действия, сетевые запросы и консоль.

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

Сами файлы хранятся, пока существует инцидент, а файлы пробных прогонов — сутки.

Как запустить вручную

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

Ручных запусков — не больше 30 за 10 минут и по одному одновременно на аккаунт.

Что важно учитывать

  • Только публичные адреса. Сценарий открывает сайты и API, доступные из интернета.
  • Порты — 80, 443 и от 1024: этого хватает сайтам и API, в том числе на нестандартных портах вроде 8443 или 3000.
  • Скачивание файлов в браузере выключено.
  • Память — около 1,2 ГБ на прогон. Сценарий, которому нужно больше, останавливается с ошибкой о превышении памяти.
  • Код — до 64 КБ, это больше тысячи строк. Тест входа из примера выше занимает меньше половины килобайта.
  • Сценарий входит в лимит серверов тарифа. Сколько сценариев можно завести, как часто их проверять и какой таймаут поставить на каждом тарифе — на странице Тарифы.