Тестовые данные: где брать, как готовить и почему это половина работы

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

Почему это важнее, чем кажется

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

Умножьте на количество сценариев, и станет понятно, куда уходит время. Тестировщик, который умеет быстро получать нужное состояние, успевает вдвое больше при той же внимательности.

Пять способов получить данные

Способ	Когда подходит	Минус
Через интерфейс	Одиночная проверка, простое состояние	Долго, не масштабируется
Через API	Нужно много однотипных записей	Надо знать методы и авторизацию
Запросами к базе	Нужно редкое или невозможное состояние	Легко нарушить целостность
Скрипт-генератор	Регулярно нужен один и тот же набор	Надо написать и поддерживать
Копия боевых данных	Нужен реалистичный объём	Обязательно обезличивание

На практике комбинируют: базовый набор наливают скриптом при развёртывании стенда, частные случаи добирают через API, а совсем экзотические состояния правят запросом.

Каким должен быть хороший набор

• Покрывает классы, а не количество. Не «сто пользователей», а «пользователь без заказов, с одним, с сотней, заблокированный, с незаполненным профилем».
• Содержит крайние случаи. Имя из одного символа и из максимальной длины, нулевая сумма, пустой список.
• Реалистичен. Тестовые имена вида «ааа» и «тест123» скрывают дефекты вёрстки: настоящие фамилии длиннее и с дефисами.
• Восстанавливается. Должен быть способ вернуть стенд в исходное состояние одной командой, а не руками.
• Не зависит от даты. Набор, где заказ создан «вчера» жёстко прописанной датой, через месяц начнёт врать.

Боевые данные на тестовом стенде

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

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

• Имена, телефоны, адреса и почты заменяются на сгенерированные.
• Платёжные данные не переносятся вовсе.
• Идентификаторы сохраняются, чтобы связи между таблицами не разъехались.
• Распределение данных сохраняется: если у 3% пользователей больше ста заказов, так должно остаться.

Ошибки, из-за которых проверки врут

1. Проверять на своём давнем аккаунте. У вас там особое состояние, накопленное за полгода. У нового пользователя всё иначе — и половина дефектов живёт именно там.
2. Использовать один аккаунт на всех. Коллега меняет данные параллельно, и вы получаете необъяснимое поведение.
3. Править базу напрямую там, где есть бизнес-логика. Поменяли статус заказа запросом — и обошли расчёты, уведомления и историю. Результат проверки бессмысленный.
4. Не чистить за собой. Через месяц на стенде тысячи мусорных записей, и поиск нужного превращается в отдельную задачу.
5. Забывать про справочники. Проверили на трёх категориях товаров, а в проде их триста — и на трёхсотой вёрстка ломается.

Отдельная тема: даты и время

Самый коварный вид тестовых данных. Набор, где заказ создан «вчера», через месяц превращается в набор, где заказ создан месяц назад, — и проверки, завязанные на срок, начинают падать без всякой причины.

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

Если в продукте есть что-то, зависящее от времени — подписки, сроки доставки, отчётные периоды, — попросите у разработчиков способ подменить дату на стенде. Это экономит недели ожидания «когда наступит нужный день».

Как автоматизировать подготовку

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

Коллекция в Postman. Соберите последовательность запросов: создать пользователя → авторизоваться → создать заказ → оплатить. Запуск через Runner создаёт нужное состояние за секунды. Как это устроено — в разборе Postman для тестировщика.

Набор SQL-запросов. Файл с готовыми выборками: найти пользователя без заказов, найти заказ в нужном статусе, посмотреть, что записалось. Пополняйте его каждый раз, когда пишете новый запрос, — см. шпаргалку по SQL.