Генерация тестовых данных с ИИ: руководство для ручного тестировщика. ai.. ai. Postman.. ai. Postman. бд.. ai. Postman. бд. Блог компании Росгосстрах.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ. искусственный интеллект.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ. искусственный интеллект. тестирование.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ. искусственный интеллект. тестирование. Тестирование IT-систем.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ. искусственный интеллект. тестирование. Тестирование IT-систем. Тестирование веб-сервисов.. ai. Postman. бд. Блог компании Росгосстрах. Будущее здесь. ИИ. искусственный интеллект. тестирование. Тестирование IT-систем. Тестирование веб-сервисов. тестовые данные.

Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже разобрали shift-left: контекст, тестирование требований, генерацию тестовой документации, автотесты и оптимизацию тестовой модели. Но даже когда кейсы написаны, а автотесты готовы, остаётся задача, на которую может уходить довольно много времени — это подготовка тестовых данных для ручного тестирования.

Есть масса различных видов тестовых данных, которые могут понадобиться QA-инженеру:

  • наполнить тестовую БД клиентами с валидными реквизитами и связями между таблицами,

  • собрать коллекцию Postman по Swagger,

  • подготовить файл с десятками записей под конкретный сценарий, и т.п.

Я не буду разбирать досконально все возможные варианты, но покажу на паре примеров, как подойти к такой задаче с помощью ИИ-инструментов.

Что нужно для старта?

Минимальный набор на входе зависит от вашей задачи, но общая логика одна:

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

  2. Опорные артефакты — схема БД, OpenAPI/Swagger, пример логов, список полей с типами и правилами и т.п.

  3. Ограничения — не предлагать реальные персональные данные, не добавлять в скрипты команды для удаления таблиц и т.п.

  4. Формат результата – четкий формат того артефакта, который вы хотите получить на выходе.

  5. Эталонный пример итогового документа, чтобы модель меньше фантазировала.

Чем точнее входные данные, тем меньше итераций вам придется сделать для получения нужного результата.

Универсальный процесс: семь шагов

Шаг 1. Сформулируйте задачу

Кратко опишите агенту, что нужно сделать. В описании укажите:

  • что генерируем (клиенты, договоры, события, запросы API);

  • куда попадут данные (PostgreSQL, CSV, Postman, мок-сервер);

  • сколько записей или сценариев вам нужно;

  • какие ограничения важны (валидность по правилам, явно тестовый вид, без реальных email).

Пример формулировки: «Нужно наполнить тестовую БД клиентами: данные валидные, но ФИО — из вымышленных персонажей.»

Шаг 2. Попросите агента уточнить входные данные

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

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

Обычно агент запросит схему, объём, правила валидности, примеры, ограничения по безопасности и т.п.

Шаг 3. Передайте запрошенные материалы

Ответьте на вопросы агента и приложите файлы. Чем точнее вход — тем меньше правок после генерации.

Шаг 4. Попросите подготовить промпт-шаблон

Если задача регулярная и вы хотите повторять генерацию таких данных — попросите ИИ написать универсальный промпт с плейсхолдерами.

Собери универсальный промпт-шаблон с плейсхолдерами, который я смогу переиспользовать.
Укажи, что куда подставлять.

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

Шаг 5. Согласуйте формат результата

До генерации зафиксируйте, что именно вам нужно получить на выходе:

  • формат: SQL-файл, JSON, CSV, curl, коллекция Postman;

  • один файл или несколько;

  • нужны ли комментарии, пкраткая инструкция «как запустить» и т.п.

Шаг 6. Сгенерируйте и проверьте

Запустите генерацию по согласованному промпту. Провалидируйте результат, прогоните его на тестовой среде.

Если что-то не так — опишите ошибку и попросите исправить точечно, и внести правки в промпт, если это необходимо.

Шаг 7. Сохраните и переиспользуйте

Сохраните в папке проекта:

  • финальный промпт;

  • сгенерированный артефакт (SQL, .json.http).

В следующий раз не начинайте с нуля — берите шаблон и подставляйте новые вводные.

Пример стартового сообщения для агента:

Задача: [что генерируем]
Для чего: [БД / API / файл / Postman]
Объём: [сколько записей/запросов]
Какие данные: [чёткое описание]
Ограничения: [что нельзя]
Формат результата: [csv, json, коллекция Postman]

Сначала: перечисли, что тебе нужно от меня, и подготовь промпт-шаблон.
Потом: сгенерируй результат в формате [SQL / curl / JSON / ...].
В конце: кратко опиши, как проверить результат.

Генерация данных для БД

Одним из самых распространенных кейсов по подготовке тестовых данных является наполнение тестовых БД клиентами, товарами или другими сущностями. Если у вас есть API для создания таких сущностей, то задача не должна быть сложной. Но если вам приходится готовить такие данные вручную, да еще и задействовать несколько связанных таблиц сразу, то такая задача – потенциальный кандидат для применения ИИ.

ИИ-агент может сгенерировать нужное количество данных и подготовить SQL-скрипт для инсерта в нужную таблицу.

Шаг 1. Пишем задание и запускаем промпт

В промпте перечисляем таблицы, столбцы, типы данных и бизнес-правила. Пример:

Сгенерируй 50 записей для тестовой БД + ТОЛЬКО SQL скрипт для их вставки в таблицу. БД PostgreSQL

Название таблицы test_table

Названия столбцов и формат данных:

id - формат guid
number - формат integer
name - текстовый формат, строка должна начинаться со слов "Договор №" + любой номер от 1 до 100000
start_date - формат timestamp, в интервале от текущей даты до текущая дата минус 2 года
end_date - формат timestamp, не позднее текущей даты + 5 лет
object - массив объектов (от 1 до 5 объектов в массиве):
[
{"code": формат guid
"name": строка,
"address": любой адрес в России,
"isActive": true/false}
]
description - любая строка, не больше 64 символов
created - NOW()
updated - NOW()

Шаг 2. Ревьюим результат

На что смотрю я:

Область

Что проверить

Структура

В INSERT INTO test_table (...) есть все ожидаемые колонки, порядок совпадает со схемой

Форматы

id/code выглядят как UUID, даты — timestamp, JSON-массивы валидны

Ограничения из промпта

start_date в пределах последних 2 лет, end_date не позже NOW() + 5 yearsdescription ≤ 64 символов

Безопасность

Нет DROP/TRUNCATE/DELETE без явного запроса; скрипт только на INSERT

Шаг 3. Пробный INSERT

После проверки делаю пробный INSERT в таблицу на тестовом стенде. Если падает — возвращаюсь к агенту с текстом ошибки.

Шаг 4. Вставляем все данные

Пробный INSERT прошёл — запускаем полный скрипт. На всю задачу обычно уходит 5-10 минут.

Генерация коллекций для Postman

С Postman еще проще, чем с БД. Для этой задачи промпт вообще не обязателен — достаточно простого объяснения в чате с агентом.

Вариант 1: по ссылке на Swagger

Сгенерируй мне коллекцию для постмана по этому сваггеру https://petstore.swagger.io/
и сохрани в текущей папке. Также сгенерируй файл с окружением со всеми необходимыми переменными.

На выходе получаете json файлы с коллекцией запросов и окружением. Импортируете в Postman — получаете работоспособные запросы с переменными окружения. Можно сразу попросить ИИ сгенерировать pre-request и post-request скрипты, если вам нужно сохранять какие-то атрибуты из ответов и передавать в другой запрос.

Вариант 2: по локальному файлу OpenAPI

Если Swagger недоступен по URL (внутренний стенд, VPN, авторизация):

  1. Переходите по ссылке со страницы Swagger на JSON-описание методов.

  2. Сохраняете файл локально.

  3. Даёте агенту задачу:

Сгенерируй мне коллекцию для постмана по этому файлу @openapi.json
и сохрани в текущей папке. Также сгенерируй файл с окружением со всеми 
необходимыми переменными.

Результат аналогичный — файлы готовы к импорту.

Для Postman я обычно проверяю: все ли эндпоинты из спецификации попали в коллекцию, корректны ли пути и методы, заполнены ли переменные в environment (baseUrl, токены, если нужны). Один-два запроса прогоняю руками сразу.

На что обращать внимание при проверке (сводная таблица)

Критерий

Что проверить

Задача

Понятно, что генерируем, куда и сколько

Входные данные

Схема, правила и ограничения переданы агенту

Формат вывода

Согласован до генерации (SQL, curl, JSON и т.д.)

Валидность

Поля и связи соответствуют DDL или контракту API

Безопасность

Нет нежелательных DROP/TRUNCATE/DELETE; среда — test

Сохранение

Промпт и артефакт лежат в папке проекта для повторного использования

Что в итоге

Генерация тестовых данных с ИИ работает, если:

  • чётко описать задачу и согласовать формат вывода до генерации;

  • передать схему и ограничения;

  • проверить результат на тестовой среде, начиная с одной записи;

  • сохранить промпт и артефакты для переиспользования.

В следующих статьях я расскажу про другие задачи, с которыми вам могут помочь ИИ-инструменты.

Продолжение следует!

Автор: alenameteneva

Источник