Процессы и инструменты тестирования

Замер: почему на тестовой среде зелено

Продолжу тот замер, он показателен. Поиск строки по адресу почты без индекса: на тысяче строк 0,074 мс, на миллионе - 75,9 мс. С индексом: 0,004 мс и 0,008 мс соответственно. То есть на маленькой базе индекс ускоряет в 19 раз, но обе цифры настолько малы, что разницы не видно глазами. На большой - ускорение примерно в десять тысяч раз, и вот его уже видно как разницу между «мгновенно» и «страница висит».

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

// Отсюда лестница сред: dev (где разработчики ломают всё подряд), test (стенд тестировщика), staging - предпрод, максимально похожий на боевую среду по конфигурации, данным и железу, - и прод. Staging «примерно как прод», но с другими настройками, выключенными интеграциями и тысячей строк вместо миллиона, даёт ровно ту ложную зелень, что в замере выше.

индекс

структура, по которой база находит строку без перебора всей таблицы

staging

предпрод-среда, повторяющая боевую по настройкам и объёму данных

Локализация до слоя

«Сломался фронт» - самый бесполезный репорт. Фронтом называют то, что работает в браузере у пользователя: страница, кнопки, скрипты. Бэкенд - сервер, который считает и хранит данные. Показываю, как отличить одно от другого. Нажимаю «оплатить», открываю в браузере панель разработчика, вкладку Network - там видны все запросы, которые страница отправила на сервер, с их ответами. Вижу: запрос на оформление вернул код 500 и тело с текстом ошибки сервера. Коды делятся просто: 4xx - клиент прислал что-то не то (400 - кривые данные, 401 и 403 - нет прав, 404 - адреса не существует), 5xx - сервер сломался сам. Значит, фронт ни при чём, это бэкенд.

Дальше по порядку. Вкладка Console показывает ошибки скриптов самой страницы: если запросы отработали нормально, а Console красная - вот теперь это фронт. В ответе сервера обычно есть заголовок с идентификатором запроса, в моём замере это был X-Request-Id со значением req-a1b2c3: по нему в логах сервиса находится ровно этот запрос, а не все подряд. Потом при необходимости - проверка состояния в базе запросом и повтор вызова мимо интерфейса через Postman или curl (инструменты, которые отправляют запросы к серверу напрямую, без страницы).

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

Network / Console

вкладки панели разработчика: запросы к серверу / ошибки скриптов страницы

фиче-флаг

переключатель функции без выкладки новой версии

Данные, учёт и метрики процесса

Тестовые данные - такой же актив, как код. Три источника: сгенерированные, фикстуры (заранее подготовленный набор с известным состоянием, который заливается перед прогоном) и обезличенные слепки прода - последние удобнее всех и опаснее всех, потому что персональные данные надо вычистить до, а не после. Общая изменяемая база на всю команду даёт мигающие прогоны по определению: мой тест ждёт трёх заказов, а сосед в этот момент создал четвёртый.

Учёт держат два инструмента. TMS (test management system) - система, где живут кейсы, прогоны и их связь с требованиями и дефектами; результат прогона в ней и есть аргумент в решении о релизе. Баг-трекер ведёт дефект по стадиям: заведён, взят в работу, починен, проверен, закрыт. Дисциплина полей (среда, версия, компонент) превращает его в пригодную статистику, а без неё это свалка текстов.

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

фикстуры

подготовленный набор данных с известным состоянием под прогон

TMS

test management system: хранилище кейсов, прогонов и их связей

Как отвечать: «Что первым делом смотришь, когда «сломался фронт»?»

Первым делом я не пишу репорт, а локализую проблему до слоя, потому что половина таких случаев - это бэкенд, данные или среда. Открываю панель разработчика, вкладку Network, и смотрю на запрос, который стоит за сломанной кнопкой. Если он вернул 500 - сломался сервер, и репорт пойдёт другой команде, с телом ответа. Если 400 или 403 - фронт отправил не то или не хватает прав. Если запрос вообще не ушёл или ушёл, но страница на ответ не среагировала, - смотрю Console: там видны ошибки скриптов самой страницы, и вот тогда это действительно фронт. Дальше беру идентификатор запроса из заголовка ответа и по нему нахожу в логах ровно этот вызов, а не все подряд. Если нужно - проверяю состояние в базе запросом и повторяю вызов мимо интерфейса, чтобы понять, воспроизводится ли он без страницы. И проверяю банальное: та ли среда, не выключен ли фиче-флаг. В итоге в репорте у меня не «сломался фронт», а «такой-то запрос вернул 500, вот тело ответа и идентификатор запроса» - и разбор занимает минуты вместо дней.

Почему это сильный ответ: показан порядок действий (Network, коды ответа, Console, идентификатор запроса, база, вызов мимо интерфейса, среда и флаги) и объяснено, что даёт точная локализация.

На чём валят

• −Тестовая база в тысячу строк против прода в миллион: тот же запрос ускоряется индексом в 10 000 раз, и без него релиз ложится.
• −Репортить «сломался фронт», не заглянув в Network, где лежит 500 от сервера.
• −Общая изменяемая база на всю команду - прогоны ломают состояние друг другу.
• −Staging с другими настройками и выключенными интеграциями - зелено на стенде, красно в проде.
• −Собирать метрики, по которым не принимается ни одно решение.