Тестирование производительности UI: время загрузки — это лёгкая половина

Что обычно измеряет тестирование производительности UI

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

Что на самом деле замечают пользователи

Чаще всего в продакшн просачивается именно третье: тестовые окружения маленькие, а аккаунты клиентов — нет.

Измерение, которое важно и которого обычно нет

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

Почему и здесь корректность идёт первой

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

Наполненный данными аккаунт, который никто не поддерживает

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

Наполнить такой аккаунт данными легко. Сохранять его реалистичным — нет: схема меняется, скрипт наполнения устаревает, и через два квартала он создаёт аккаунт, который уже ни на что не похож. В этот момент ему перестают доверять и возвращаются к тестам на десяти строках.

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

Регрессии важнее абсолютных значений

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

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

Если пайплайн принадлежит другой команде, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, с этим справится шаг GitHub Actions .

Что TestSprite проверяет в первую очередь

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

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

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