AI для генерации тест-кейсов из требований: покрытие и граничные случаи

August 31, 2026

8 min read

ai ии тест-кейсы требования llm тестирование системный-анализ граничные-случаи покрытие промпты

AI для генерации тест-кейсов из требований: покрытие и граничные случаи

Если вам когда-нибудь приходилось расписывать 50 тест-кейсов к пятнице, а в понедельник Product Owner добавлял «ещё одну маленькую фичу», вы знаете, какая это рутина. Причём рутина коварная: когда выписываешь двадцатый кейс подряд, мозг отключается и пропускает очевидное — например, что никто не проверил поведение системы при отрицательной сумме заказа. Языковая модель в этом смысле ровно противоположна уставшему аналитику: она не скучает, не утомляется и методично обходит все ветки условий, включая те, про которые вы подсознательно решили «ну такого точно не случится». Этот пост — о том, как заставить LLM генерировать тест-кейсы, а не фантазии, и при этом не выкинуть потом половину в корзину.

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

Почему генерация тест-кейсов — кандидат номер один на AI-автоматизацию

Три причины, по которым эта задача ложится на LLM почти идеально.

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

Вторая: хороший набор тест-кейсов — это комбинаторный перебор входных данных и условий. А комбинаторика — ровно то, в чём человек стабильно ошибается, а машина нет.

Третья: требования, из которых генерируются кейсы, написаны на естественном языке. LLM обучена этот язык понимать и извлекать из него логические условия («если сумма > 5000, то скидка 10%») не хуже, чем парсер — из кода.

Пайплайн: от требования к набору тест-кейсов

Рабочий процесс состоит из пяти шагов. На вход подаётся функциональное требование, на выходе — структурированная таблица тест-кейсов с разбивкой по категориям.

graph TD
  A["Функциональное требование"] --> B["LLM: анализ и декомпозиция"]
  B --> C["Позитивные сценарии"]
  B --> D["Негативные сценарии"]
  B --> E["Граничные значения"]
  B --> F["Анализ покрытия"]
  C --> G["Структурированные тест-кейсы"]
  D --> G
  E --> G
  F --> G
  G --> H["Экспорт: Excel / TMS"]
  
  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#fff
  style C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#7b68ee,stroke:#5a4db2,color:#fff
  style G fill:#50c878,stroke:#3a9a5c,color:#fff
  style H fill:#50c878,stroke:#3a9a5c,color:#fff

Схема выше — общая картина. Модель берёт требование, декомпозирует его на логические условия и строит три категории тестов. Четвёртый блок — анализ покрытия — проверяет, все ли ветки условий затронуты. Дальше посмотрим на конкретный пример.

Что модель делает с текстом требования

Допустим, в спецификации написано:

При сумме заказа свыше 5000 руб. применяется скидка 10%. Скидка не суммируется с промокодами. Для товаров категории «Уценка» скидка не применяется.

Человек видит здесь одно правило. LLM видит:

Основное условие: сумма > 5000 → скидка 10%.
Исключение: промокод → скидка не применяется.
Исключение: категория = "Уценка" → скидка не применяется.
Неявный вопрос: что делать, если сумма > 5000, применён промокод И товар уценён — приоритет какого правила выше?

Пункт 4 — как раз то, за что мы платим модели. Человек, выписывающий тест-кейсы на автомате, это пересечение правил пропустит.

graph LR
  A["Требование: скидка 10% при сумме > 5000"] --> B["LLM: анализ условий"]
  B --> C["TC-01: сумма 6000, скидка 10%"]
  B --> D["TC-02: сумма 5000, без скидки"]
  B --> E["TC-03: сумма 4999.99, без скидки"]
  B --> F["TC-04: сумма 0, ошибка"]
  B --> G["TC-05: сумма -100, ошибка валидации"]
  B --> H["TC-06: сумма не число, ошибка типа"]
  
  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#fff
  style C fill:#50c878,stroke:#3a9a5c,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#e0e0e0,stroke:#999,color:#333
  style G fill:#e0e0e0,stroke:#999,color:#333
  style H fill:#e0e0e0,stroke:#999,color:#333

Здесь зелёным выделен позитивный сценарий, фиолетовым — граничные значения (ровно 5000 и 4999.99), серым — негативные. Настоящая ценность модели — не в TC-01, который любой студент напишет, а в TC-04, TC-05 и TC-06, которые часто выпадают из поля зрения.

Промпты: как просить модель о тест-кейсах и получать полезный результат

Формулировка промпта решает всё. Дайте модели абстрактное «сгенерируй тест-кейсы» — получите абстрактный мусор. Дайте чёткий формат и критерии — получите таблицу, которую можно копировать в TestRail. Ниже три рабочих шаблона.

Базовый промпт: позитивные и негативные сценарии

1
Ты — QA-инженер с опытом тестирования enterprise-систем. Сгенерируй тест-кейсы для приведённого ниже требования.
2

3
Формат каждого тест-кейса:
4
- ID: TC-XXX
5
- Тип: Позитивный / Негативный / Граничный
6
- Предусловие:
7
- Шаги:
8
- Ожидаемый результат:
9

10
Покрой следующие категории:
11
1. Стандартный успешный сценарий (минимум 1).
12
2. Альтернативные успешные сценарии.
13
3. Граничные значения (ровно на границе, на единицу меньше, на единицу больше).
14
4. Негативные сценарии (невалидные входные данные, ошибки системы).
15
5. Пустые / нулевые значения.
16
6. Конфликт правил (если требование содержит несколько условий).
17

18
Требование:
19
---
20
[текст требования]
21
---

Промпт: фокус на граничных значениях

Граничные значения — ахиллесова пята ручного тестирования. При росте числа полей комбинаций границ становится слишком много для перебора человеком. LLM с этим справляется:

1
Проанализируй требование и построй матрицу граничных значений для каждого числового параметра.
2

3
Для каждого параметра приведи:
4
- Минимальное допустимое значение (MIN).
5
- MIN + 1.
6
- MIN - 1 (ожидаем ошибку валидации).
7
- Максимальное допустимое значение (MAX).
8
- MAX + 1 (ожидаем ошибку).
9
- MAX - 1.
10
- Ноль (если применимо).
11
- Отрицательное значение (если применимо).
12

13
Выведи результат в виде таблицы: Параметр | Значение | Ожидаемый результат | Тип кейса.

Промпт: комплексная генерация с матрицей покрытия

Наиболее полный вариант — просим модель оценить покрытие и указать, что осталось непротестированным:

1
Ты — ведущий QA. Сгенерируй тест-кейсы для требования и оцени покрытие.
2

3
Шаг 1: Декомпозируй требование на атомарные условия (каждое «если — то»).
4
Шаг 2: Построй матрицу комбинаций условий (condition coverage).
5
Шаг 3: Для каждой комбинации напиши тест-кейс в формате ID / Тип / Предусловие / Шаги / Результат.
6
Шаг 4: Укажи, какие комбинации условий не покрыты тест-кейсами и почему (противоречат бизнес-логике, физически невозможны, etc.)
7
Шаг 5: Выдели те кейсы, которые отсутствовали бы в ручном наборе — то, что человек скорее всего пропустил бы.

Примечательно, что последний шаг — «что человек пропустил бы» — даёт на удивление точные результаты. Модель действительно находит слепые зоны, характерные для ручного анализа.

Типичные ошибки AI-генерации и как их фильтровать

Это не серебряная пуля. LLM генерирует и откровенно бесполезные кейсы. Категории мусора:

1. Очевидные кейсы без ценности. «TC-042: открыть страницу → страница открылась». Да, модель перестраховывается. Правило: если кейс не проверяет логику, а проверяет факт существования элемента, вычёркивайте без жалости.

2. Кейсы, противоречащие бизнес-логике. Модель не знает, что «возврат средств через 365 дней после покупки» запрещён политикой компании. Она предложит такой кейс. Всё, что касается доменных ограничений, остаётся на аналитике.

3. Кейсы на несуществующие поля. Иногда LLM додумывает атрибуты, которых нет в требовании: «проверить скидку для VIP-пользователя», хотя в спецификации роли не упоминаются вообще. Каждый сгенерированный кейс сверяйте с текстом исходного требования.

4. Дубли под разными ID. Одна и та же проверка, сформулированная разными словами. Модель не считает это дублем. Вычитывайте набор целиком, а не построчно.

Хорошая практика: первым делом просите модель сгенерировать кейсы, а вторым — провести самокритику. Промпт: «Проверь сгенерированный набор тест-кейсов на дубли, нерелевантные кейсы и противоречия с исходным требованием. Укажи, какие кейсы предлагаешь удалить и почему». Двухпроходный подход отсекает примерно 15-20% мусора без участия человека.

Куда встроить AI-генерацию тест-кейсов в реальном процессе

Три сценария внедрения, от простого к сложному.

Сценарий 1: Помощник аналитика. Вы написали требования в Confluence. Перед отправкой на ревью разработчику копируете текст требования в интерфейс Claude/ChatGPT, применяете базовый промпт, получаете 20-40 тест-кейсов. Просматриваете, удаляете мусор, дописываете пропущенное — и кладёте таблицу рядом с требованием. Разработчик видит, как будет проверяться его код. Time-to-quality сокращается на один цикл «ой, я не так понял».

Сценарий 2: AI-ассистент в pipeline. Вы интегрируете LLM через API: вебхук из Confluence/Jira при изменении требования → LLM перегенерирует тест-кейсы → результат сохраняется в TestRail/Zephyr. Тест-кейсы всегда актуальны актуальной версии требований.

Сценарий 3: AI-агент. Полноценный агент, который не только генерирует кейсы, но и анализирует результаты прогонов: какие кейсы упали, какие требования затронуты, что надо дотестировать. Это уже ближе к тому, что разбиралось в посте про AI-агентов для системного аналитика.

Какой бы сценарий вы ни выбрали, начинайте с первого. Скопируйте одно нефункциональное требование, примените промпт и посмотрите на результат. Скорее всего, вы найдёте минимум два кейса, которые не пришли бы в голову при ручном выписывании — это и есть ROI.

Почему LLM-генерация меняет отношение к требованиям

Есть занятный побочный эффект, который я наблюдал в двух проектах: когда команда начинает генерировать тест-кейсы через LLM, требования пишутся иначе. Зная, что модель споткнётся о «система должна быстро обрабатывать», аналитик формулирует точнее. Зная, что пропуск граничного условия будет подсвечен, автор спецификации заполняет пробелы заранее.

Другими словами, AI-генерация работает как обратная связь: требование → тест-кейсы → требование корректируется → тест-кейсы уточняются. Петля, которая поднимает качество и того и другого одновременно.

Заключение

LLM — не замена аналитику и не замена QA. Это генератор первого черновика тест-кейсов, который работает быстрее, методичнее и без творческих пропусков. Ваша задача — не писать кейсы с нуля, а фильтровать, дополнять и принимать решения о том, что тестировать в первую очередь.

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

Более глубокие разборы по смежным темам — AI-ревью требований: как LLM находит противоречия и пропуски и функциональные требования: шаблоны, примеры и типичные ошибки. Первое — про проверку качества требований перед генерацией кейсов, второе — про то, как писать требования так, чтобы модели было из чего генерировать.

PS. Один тимлид на моей памяти сказал: «Тест-кейсы — это единственное, что стоит между красивой презентацией фичи и звонком заказчика в два часа ночи». LLM, пожалуй, поможет развести эти два события подальше друг от друга.