Как создать тестовые данные с ИИ и не копировать реальные анкеты

Зачем нужен новый набор, если есть выгрузка

Реальные анкеты удобны только на первый взгляд: в них уже встречаются нужные форматы и крайние случаи. Но удаление имени не делает строку безопасной. Дата записи, редкая услуга и адрес могут вместе указывать на человека. Для тестовой среды лучше создать записи с нуля по схеме, сохранив не личность клиента, а структуру данных. ИИ здесь помогает придумать разнообразные варианты ввода; он не проверяет законность обработки и не решает, какие данные разрешено переносить. Начните с перечня полей и цели каждого теста. Если конкретное поле не влияет на сценарий, его можно вовсе не добавлять.

Опишите правила до генерации

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

Создайте записи, которые остаются вымышленными

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

Проверьте набор вне чата

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

Что считать готовым результатом

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

Частые вопросы