Генерация тестовых данных в LLM. Больше вреда или пользы?

До широкого применения LLM тестовые данные генерировали через Faker, встроенные инструменты фреймворков, Excel или системные подходы, например, property-based testing. С появлением чат-ботов наподобие ChatGPT генерировать тестовые данные стало проще и удобнее.
Теперь достаточно написать: "Сгенерируй тестовые данные для формы регистрации". И через несколько секунд получить аккуратную таблицу с именами, email, паролями, телефонами и ожидаемыми результатами.

Но можно ли доверять таким данным? LLM склонны к галлюцинациям и додумыванию контекста. А тестовые данные должны не только выглядеть разнообразно. Они должны проверять реальные риски, границы и ошибки системы.

Создаёт ли LLM настоящее покрытие или иногда только его иллюзию? Проверим на примере формы регистрации (имя, email, пароль, телефон и стандартные правила валидации).

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

А после разберём, почему LLM может генерировать “условно полезные” данные и как можно от этого защититься.

Еще больше материала про AI QA и тестирование AI-приложений в Telegram-канале ModernQA

Подход 1. Наивный промпт

Запрос: "Сгенерируй тестовые данные для формы регистрации. Укажи ожидаемый результат"

Пример типичного ответа от модели:

На первый взгляд выглядит нормально. Есть позитивные и негативные сценарии. Но если посмотреть глазами QA, покрытие недостаточное:

Это и есть иллюзия покрытия. Cписок выглядит как тестовое покрытие, но проверяет в основном happy path и самые очевидные ошибки.

Подход 2. Управляемый промпт

Запрос, в котором описаны категории и структура:

"Сгенерируй 6 тестовых наборов для формы регистрации. Обязательно покрой следующие категории: валидные данные, пустое обязательное поле, некорректный email, дубликат, граничные значения, потенциально опасный или “грязный” ввод. Для каждого укажи: category, данные, expected_result и what_we_check"

Пример ответа (модель обычно выдает все 6; листинг сокращен):

Остальные кейсы (пустые поля, граничные значения и т.д.) строятся по тому же принципу.

Разницу в степени контроля. В наивном подходе модели отдается право самой определять данные. В управляемом подходе QA самостоятельно задает параметры, а модель помогает их реализовать в конкретные примеры.

Модель не занимается тест-дизайном. Она генерирует наиболее правдоподобный и аккуратный ответ на запрос. В итоге получаются данные, которые выглядят качественно, но плохо ловят реальные баги.

Основные причины:

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

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

#тестирование #qa #qaengineer #ai