Генерация тестов с помощью ИИ (AI test generation) - создание тест-кейсов, кода автотестов или тестовых данных генеративной моделью ИИ, обычно большой языковой моделью (LLM), на основе требований, пользовательского интерфейса, спецификаций API или существующих тестов и кода. Результат - черновик. Его проверяет человек, а сгенерированный код ещё и собирают и запускают, прежде чем черновик войдёт в набор тестов.
Эту практику описывает силлабус ISTQB Certified Tester Testing with Generative AI (CT-GenAI) - сертификация уровня Specialist, представленная в июле 2025 года. Версия 1.0 силлабуса датирована 25 июля 2025; версия 1.1, объявленная в апреле 2026 года, - небольшое обновление с той же структурой и теми же целями обучения. Исследования по теме сведены в обзоре «Software Testing with Large Language Models: Survey, Landscape, and Vision» (Wang и соавторы, IEEE Transactions on Software Engineering, 2024). Промышленный пример - TestGen-LLM, инструмент, который Meta описала в феврале 2024 года.
Какую задачу решает
Тест-дизайн превращает требования в условия тестирования, тест-кейсы и ожидаемые результаты. Автоматизация затем превращает тест-кейсы в код с локаторами, тестовыми данными и проверками. Оба шага - ручная работа, которая растёт вместе с продуктом, и оба отстают от изменений в требованиях и интерфейсе.
Языковая модель создаёт текст из текста. За минуты она может набросать шаги по юзер стори, тест по описанию API или новый модульный тест рядом с существующими. Силлабус CT-GenAI перечисляет такие задачи: генерацию тест-кейсов по функциональным и нефункциональным требованиям, синтетических тестовых данных и скриптов автоматизации по структурированным тест-кейсам. Силлабус также указывает, что сгенерированный результат нужно тщательно проверять в зависимости от связанного с ним риска.
Входные данные
Качество сгенерированного теста зависит от того, что получает модель. В таблице - обычные входные данные и то, что каждое даёт модели.
| Входные данные | Что получает модель | Ограничения |
|---|---|---|
| Требования, юзер стори, критерии приёмки | Ожидаемое поведение, правила, условия | Неоднозначности и пробелы копируются или заполняются догадками |
| Интерфейс и его дерево доступности | Элементы, роли, имена, текущие тексты | Показывает одно состояние страницы, а не правила за ним |
| Спецификация API, например OpenAPI | Операции, параметры, схемы, коды ответов | Описывает интерфейс, а не бизнес-логику |
| Существующие тесты и код | Стиль, фикстуры, вспомогательные функции, текущее поведение | Тесты по коду наследуют дефекты кода |
Силлабус CT-GenAI называет похожие входные данные: требования, юзер стори, критерии приёмки, технические спецификации, макеты интерфейса, снимки экрана, код и существующие тест-кейсы.
Дерево доступности (accessibility tree), по определению WAI-ARIA 1.2, - дерево доступных объектов, которое представляет структуру пользовательского интерфейса. У каждого узла есть роль и доступное имя - те же данные, на которые опираются локаторы по роли, описанные в статье Локаторы в UI-автотестах. Инструменты, через которые модель управляет браузером, используют это дерево вместо снимков экрана: например, MCP-сервер Playwright даёт модели структурированные снимки доступности страницы.
Документ OpenAPI описывает HTTP-операции в машиночитаемом виде; последняя опубликованная версия OpenAPI Specification - 3.2.1. Модель получает из него точные пути, параметры и схемы ответов, а не угадывает их. Ожидаемых значений, которые зависят от данных и бизнес-правил, в спецификации нет.
Результаты
Тест-кейсы
Сгенерированный тест-кейс устроен так же, как написанный вручную: заголовок, предусловия, шаги, ожидаемые результаты и ссылка на требование. Устройство описано в статье Тест-кейс. Пример показывает черновик в том виде, в каком его может вернуть модель; имена полей произвольные.
{
"title": "Expired password forces a password change after sign-in",
"requirement": "AUTH-112",
"preconditions": ["User expired@example.com exists", "The password expired 3 days ago"],
"steps": [
{ "action": "Open the sign-in page", "expected_result": "The sign-in form is shown" },
{ "action": "Sign in as expired@example.com", "expected_result": "The Change password page is shown" },
{ "action": "Open any other page", "expected_result": "The user is returned to Change password" }
],
"status": "ai_generated_draft",
"generated_by": { "model": "model-a", "prompt_version": "testcase-from-story@4" }
}Поле status помечает тест-кейс как непроверенный. Поле generated_by хранит модель и версию промпта, чтобы потом найти черновики, созданные изменённым промптом.
Код автотестов
Генерируют модульные тесты, тесты API и UI-тесты. Пример - UI-тест для того же требования на Playwright Test.
import { test, expect } from '@playwright/test';
test('expired password forces a password change', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('expired@example.com');
await page.getByLabel('Password').fill('Old-password-1');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('heading', { name: 'Change password' })).toBeVisible();
await expect(page.getByText('Your password expired 3 days ago')).toBeVisible();
});Пригодность теста решают два вопроса. Есть ли на странице поле «Email» и кнопка «Sign in»? Требует ли продукт текст из последней проверки или он только скопирован из текущего состояния? На первый вопрос отвечает запуск теста, на второй - только человек, который знает требование.
Тестовые данные
Силлабус CT-GenAI описывает генерацию представительных синтетических тестовых данных, сохраняющих конфиденциальность. Модель создаёт записи по схеме и с граничными случаями, названными в промпте. Значения проверяют как любой другой результат: по схеме, бизнес-правилам и границам, которые нужны тесту.
Данные практики и исследований
TestGen-LLM в Meta
Статья «Automated Unit Test Improvement using Large Language Models at Meta» (Alshahwan и соавторы, FSE 2024) описывает TestGen-LLM - инструмент, который добавляет тест-кейсы в существующие тестовые классы на Kotlin. Каждый кандидат проходит цепочку фильтров:
- Сборка. Тест должен собираться; код, который не собирается, отбрасывается.
- Прохождение. Тест должен проходить; непройденный тест отбрасывается, потому что инструмент не может отличить настоящий дефект от неверной проверки.
- Надёжность. Тест запускают пять раз, и он должен пройти каждый раз; иначе он считается нестабильным.
- Покрытие. Тест должен увеличить покрытие строк по сравнению с существующими тестами.
В оценке на Instagram Reels и Stories 75 процентов сгенерированных тест-кейсов собрались, 57 процентов стабильно прошли и 25 процентов увеличили покрытие. На тест-марафонах (test-a-thons) в Instagram и Facebook инструмент улучшил 11,5 процента классов, к которым его применили, а инженеры приняли в эксплуатацию 73 процента его предложений. Авторы называют подход гарантированной программной инженерией на основе LLM (assured LLM-based software engineering): модель предлагает, а детерминированные проверки гарантируют улучшение и отсутствие регресса.
Обзор исследований
Обзор Wang и соавторов анализирует 102 исследования. Самыми характерными применениями LLM в тестировании он называет подготовку тест-кейсов и исправление программ; среди рассмотренных задач - генерация модульных тест-кейсов, генерация тестовых оракулов и генерация входных данных для системных тестов. Обзор называет четыре открытые проблемы: высокое покрытие, проблему тестового оракула, строгую оценку и применение в реальных проектах.
Известные ограничения
Выдуманные API, пакеты и локаторы
Силлабус CT-GenAI определяет галлюцинации как результат, который выглядит фактически неверным или не относящимся к задаче, а ошибки рассуждения - как неверное понимание логических структур, например условий или причины и следствия. В сгенерированных тестах и то и другое проявляется как ссылки на несуществующее: методы библиотеки, эндпоинты API, поля ответа, элементы страницы.
Статья «We Have a Package for You!» (Spracklen и соавторы, USENIX Security 2025) измерила одну из форм этого. В 576 000 образцах кода от 16 моделей в среднем не меньше 5,2 процента пакетов, предложенных коммерческими моделями, и 21,7 процента пакетов, предложенных открытыми моделями, не существовали; уникальных выдуманных имён было 205 474. Авторы описывают галлюцинацию пакетов как новую форму атаки путаницы пакетов (package confusion) на цепочку поставки программного обеспечения, поэтому зависимости сгенерированных тестов проверяют как любые другие зависимости.
Локаторы выдумываются так же, если модель не видела страницу. Тест, написанный только по юзер стори, угадывает подписи и имена. Модель, которая работает с деревом доступности запущенного приложения, выбирает существующие имена; например, агент-генератор Playwright проверяет селекторы и проверки на живой странице, пока пишет тест.
Проблема оракула
Тестовый оракул (test oracle) - источник, который определяет, правильно ли наблюдаемое поведение для заданного входа. Обзор Barr и соавторов (2015) описывает проблему тестового оракула как задачу отличить желаемое, правильное поведение системы от потенциально неправильного.
Генерация не снимает эту проблему, а переносит её. Тест, созданный по коду, проверяет то, что код делает. TestGen-LLM оставляет только проходящие тесты, поэтому проверки оставленных тестов описывают текущее поведение, правильное оно или нет. Такие тесты защищают от будущего регресса, но не находят существующие дефекты. У теста, созданного по требованию, оракул независимый, но он не лучше самого требования и того, как его поняла модель.
Сгенерированный тест, который прошёл с первого запуска, показывает, что его проверки совпадают с текущим поведением. Он не показывает, что текущее поведение правильное.
Покрытие и смысл
Покрытие измеряет, какой код выполняет тест, а не что он проверяет. Тест, который вызывает функцию и ничего не проверяет, увеличивает покрытие строк. Статья о TestGen-LLM отмечает, что тест без проверок опирается на неявный оракул: код не должен выбрасывать исключение. Поэтому покрытие читают вместе с проверками, а сгенерированный тест рецензируют по тому, что он проверяет, а не только по тому, что он выполняет. Ограничения покрытия требований описаны в статье Трассируемость и покрытие требований.
Проверка человеком
Статусы рецензирования
Сгенерированные тест-кейсы проходят тот же жизненный цикл, что и написанные вручную, с одним дополнительным статусом в начале. Жизненный цикл описан в статье Тест-кейс; таблица показывает типичную последовательность для сгенерированных черновиков.
| Статус | Значение |
|---|---|
| Сгенерированный черновик | Создан моделью, человек его ещё не читал, в тестовые прогоны не входит |
| На рецензировании | Рецензент сверяет черновик с требованием |
| Активный | Одобрен и используется в тестовых прогонах |
| Отклонён | Не подходит; хранится или удаляется по правилам команды |
Отдельный статус не пускает непроверенные черновики в тестовые прогоны и отчёты. Он также делает видимой их долю: сколько черновиков одобрено, исправлено или отклонено для каждой версии промпта.
Что проверяет рецензент
- Трассируемость. Каждый тест-кейс ссылается на настоящее требование и проверяет то, что в нём сказано.
- Ожидаемые результаты. Каждый ожидаемый результат следует из требования, а не из текущего поведения.
- Полнота. Есть негативные случаи и границы; техники тест-дизайна показывают, каких не хватает.
- Дубликаты. Черновик не повторяет существующий тест-кейс.
- Данные. В тестовых данных нет настоящих персональных данных.
Проверка запуском
Сгенерированный код запускают до рецензирования, по образцу фильтров TestGen-LLM: он должен собираться, проходить и проходить повторно. Тест, который не прошёл с первого запуска, разбирают, потому что причиной может быть дефект продукта или теста. Прошедший тест рецензируют по его проверкам. Повторные запуски выявляют нестабильные тесты, описанные в статье Нестабильные тесты; запуск сгенерированных тестов в конвейере описан в статье Автотесты в CI.
Конфиденциальность данных
Требования, тест-кейсы и код, отправленные внешней модели, покидают организацию. Силлабус CT-GenAI называет риски: непреднамеренное раскрытие чувствительных данных, отсутствие контроля над их использованием и риски несоответствия нормам, например GDPR.
Условия задают правила поставщика модели. OpenAI, например, указывает, что данные, отправленные в её API, не используются для обучения моделей, если клиент сам не дал на это согласия, а журналы контроля злоупотреблений по умолчанию хранятся до 30 дней; нулевое хранение данных доступно после одобрения. Модель, запущенная на собственной инфраструктуре организации, оставляет данные внутри неё. В обоих случаях персональные данные удаляют из требований и заменяют синтетическими до отправки.
Доступ к тестовым данным через MCP
Модель создаёт черновики лучше, когда может читать существующие тест-кейсы, требования и результаты и записывать черновики прямо туда, где они хранятся. Это обеспечивает Model Context Protocol (MCP), описанный в статье Что такое MCP: система управления тестированием предоставляет MCP-сервер, инструменты которого ищут тест-кейсы, читают требования и создают черновики.
Такой доступ ограничивают как любой другой. Для генерации достаточно токена с правом чтения и правом создавать черновики. Смена статусов и удаление остаются за людьми. Инструкции, спрятанные в данных, которые читает модель, - известный риск, он описан в статьях Безопасность MCP и Prompt injection.
Генерация с помощью ИИ, техники тест-дизайна и запись с воспроизведением
Таблица сравнивает три способа получить тесты.
| Генерация с помощью ИИ | Техники тест-дизайна | Запись и воспроизведение | |
|---|---|---|---|
| Источник тестов | Требования, интерфейс, спецификации, код | Требования и модели поведения | Действия человека в интерфейсе |
| Кто выбирает случаи | Модель, затем рецензент | Тест-дизайнер по технике | Тот, кто записывает |
| Критерий покрытия | Собственного нет | Задан техникой | Нет |
| Ожидаемые результаты | Предлагает модель | Выводятся из требования | Сняты с текущего состояния |
| Повторяемость | При каждом запуске другой результат | Те же случаи по тем же требованиям | Точное воспроизведение записи |
Техники тест-дизайна, например классы эквивалентности и граничные значения, таблицы решений и переходы состояний, определяют, какие случаи нужны и когда набор полон. У генерации с помощью ИИ такого критерия нет. Их сочетают: техника задаёт случаи, а модель пишет для них шаги и код, или техника служит рецензенту проверкой полноты.
Инструменты записи и воспроизведения (record-and-playback), например Selenium IDE или Playwright codegen, записывают действия человека и превращают их в скрипт; codegen предпочитает локаторы по роли, тексту и test id. Запись фиксирует один путь и его текущие результаты, поэтому у неё та же проблема оракула, что у генерации по коду. Её место в наборе тестов разобрано в статье Уровни автоматизации и пирамида тестов.
Термины
| Термин | Значение |
|---|---|
| Генерация тестов с помощью ИИ (AI test generation) | Создание тест-кейсов, кода тестов или тестовых данных генеративной моделью ИИ |
| Галлюцинация (hallucination) | Результат модели, который выглядит фактически неверным или не относящимся к задаче |
| Дерево доступности (accessibility tree) | Дерево доступных объектов, которое представляет структуру пользовательского интерфейса |
| Тестовый оракул (test oracle) | Источник, который определяет, правильно ли наблюдаемое поведение для заданного входа |
| Проблема оракула (oracle problem) | Трудность отличить правильное поведение системы от неправильного |
| Сгенерированный черновик (AI-generated draft) | Статус тест-кейса, созданного моделью и ещё не проверенного человеком |
Источники
- Certified Tester Testing with Generative AI (CT-GenAI), ISTQB(откроется в новой вкладке) (на английском)
- CT-GenAI Syllabus v1.0, ISTQB, 2025, копия на сайте ATSQA(откроется в новой вкладке) (на английском)
- ISTQB announces minor update to CT-GenAI, ISTQB, апрель 2026(откроется в новой вкладке) (на английском)
- Automated Unit Test Improvement using Large Language Models at Meta, N. Alshahwan et al., arXiv:2402.09171(откроется в новой вкладке) (на английском)
- Software Testing with Large Language Models: Survey, Landscape, and Vision, J. Wang et al., arXiv:2307.07221(откроется в новой вкладке) (на английском)
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, J. Spracklen et al., arXiv:2406.10279(откроется в новой вкладке) (на английском)
- The Oracle Problem in Software Testing: A Survey, E. T. Barr et al., IEEE Transactions on Software Engineering, 2015(откроется в новой вкладке) (на английском)
- Accessible Rich Internet Applications (WAI-ARIA) 1.2, W3C(откроется в новой вкладке) (на английском)
- OpenAPI Specification, последняя версия(откроется в новой вкладке) (на английском)
- Playwright MCP, Microsoft, GitHub(откроется в новой вкладке) (на английском)
- Playwright Test Agents, документация Playwright(откроется в новой вкладке) (на английском)
- Test generator (codegen), документация Playwright(откроется в новой вкладке) (на английском)
- Selenium IDE, проект Selenium(откроется в новой вкладке) (на английском)
- Data controls in the OpenAI platform, документация OpenAI API(откроется в новой вкладке) (на английском)