ИИ пишет тест-кейсы и автотесты за тебя: как их генерировать и не получить ложное покрытие

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

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

Разберём, какую часть работы LLM действительно снимает с QA, где создаёт видимость покрытия и почему сгенерированный набор всё равно приходится проектировать и проверять человеку.

Помог с написанием статьи:

Александр Мужев

Ведущий QA-инженер полного цикла в «Альфа-Деньгах», эксперт на курсах «Инженер по тестированию» и «Фулстек-разработчик на Python» в Нетологии

Два режима генерации тест-кейсов: из требований и из кода

У автогенерации тест-кейсов есть два основных режима. В первом модель получает требования — например, пользовательскую историю, или user story. Во втором читает готовый код и пишет тесты под текущую реализацию.

Разница принципиальная: требования описывают, как система должна работать, а код — как она работает сейчас.

Генерация из требований

Допустим, модель получила такую пользовательскую историю:

Пользователь может изменить email в настройках профиля. На новый адрес отправляется ссылка, которая действует 24 часа. До подтверждения в профиле остаётся старый email. Новый адрес должен быть уникальным.

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

Тем же способом получают чек-листы, тестовые данные или сценарии Given–When–Then: исходное условие, действие, ожидаемый результат. Это ещё не проверка продукта. Модель просто разворачивает короткое требование в более подробное описание.

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

Например, из этой постановки она вполне может вывести такой кейс:

Сценарий: пользователь повторно запрашивает смену email.

Ожидаемый результат: предыдущая ссылка становится недействительной, на новый адрес приходит новое письмо.

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

Генерация из кода

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

GitHub Copilot, например, умеет генерировать тесты для открытого файла и учитывать соседние тестовые классы. В официальной документации GitHub отдельно предупреждает: полученный набор может охватывать не все сценарии, поэтому его нужно проверять и дополнять вручную.

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

Поэтому режимы нельзя считать взаимозаменяемыми. Генерация из требований отвечает на вопрос «соответствует ли продукт договорённостям», генерация из кода — «не изменилось ли текущее поведение». Если не различать эти задачи, регрессионный тест легко принять за проверку бизнес-логики.

Где ИИ действительно экономит время

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

Подготовка первого черновика

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

Лучше всего она справляется с явно описанным позитивным путём. Заполнить форму, оплатить заказ, получить подтверждение — такую последовательность модель без труда разобьёт на отдельные проверки.

Ценность здесь не в том, чтобы сохранить весь ответ. Тестировщик выкидывает повторы, объединяет близкие проверки и оставляет только применимое. Но начинает уже не с пустой страницы.

Чек-листы и оформление

Оформление тестовой документации — отдельный слой рутины: перенести проверки в шаблон, добавить предусловия, унифицировать названия, превратить заметки в таблицу.

Эту работу модель делает предсказуемо именно потому, что не принимает содержательных решений. Что проверять, уже определил человек, а ИИ приводит материал к нужной форме.

Тестовые данные

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

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

Обновление существующих кейсов

Полезно давать модели не пустую постановку, а изменение. Допустим, срок действия ссылки сократился с 24 часов до двух. ИИ может найти старое значение в регрессе и собрать список кейсов, которые нужно пересмотреть.

Такой ответ обычно сильнее генерации с нуля, потому что у модели уже есть принятая терминология, формат и часть продуктовой логики. Но влияние изменения на соседние функции она только предполагает. Финальный список всё равно утверждает тестировщик.

Где ИИ создаёт ложное чувство покрытия

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

Тест подтверждает ошибку в коде

Возьмём простое правило: премиум-пользователь получает скидку 10% на заказы от 1 000 рублей включительно. В коде ошиблись дважды — оставили скидку 5% и исключили из условия ровно 1 000 рублей.

def calculate_price(total: float, is_premium: bool) -> float:

    if is_premium and total > 1000:

        return total * 0.95

    return total

Передаём модели только код:

Напиши unit-тесты для функции calculate_price на pytest.

Проверь обычного и премиум-пользователя, граничное значение

и сумму выше границы.

Модель может вернуть такой набор:

def test_regular_user():

    assert calculate_price(2000, False) == 2000

def test_premium_user_above_limit():

    assert calculate_price(2000, True) == 1900

def test_premium_user_on_boundary():

    assert calculate_price(1000, True) == 1000

Все три теста зелёные. При этом второй закрепляет скидку 5% вместо 10%, а третий — неверную обработку границы. Модель протестировала фактическое поведение функции, но ничего не сказала о том, соответствует ли оно требованиям.

Эту проблему разбирают авторы исследования Do LLMs generate test oracles that capture the actual or the expected program behaviour? Они проверили генерацию ожидаемых результатов на тестах из 24 Java-проектов и пришли к выводу, что LLM склонны фиксировать текущее поведение программы вместо задуманного.

Ожидаемый результат, с которым тест сравнивает поведение системы, называют тестовым оракулом. В эксперименте модель выбирала правильный вариант менее чем в половине случаев. Поэтому такие результаты нужно проверять вручную.

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

Пропущенные негативные и краевые сценарии

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

В примере со сменой email очевидны занятый адрес и просроченная ссылка. Гораздо менее очевидны два запроса подряд, попытка двух аккаунтов одновременно занять один адрес, корпоративный вход через SSO и сброс пароля в момент неподтверждённой смены.

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

Галлюцинации в шагах и ожидаемых результатах

Галлюцинация в тест-кейсе редко выглядит как явная бессмыслица. Модель может добавить правдоподобную деталь, которой нет в продукте: например, шаг «Нажать кнопку „Отменить“» или вызов метода cancelEmailChange(), отсутствующего в API. Если ревьюер плохо знает функцию, выдумку легко принять за техническую деталь.

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

Много кейсов про одно и то же

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

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

Покрытие кода показывает, какие строки и условия выполнились во время теста. Но оно не оценивает качество самой проверки. Тест может выполнить всю функцию и проверить только то, что она что-то вернула. Ошибка в расчёте при этом останется незамеченной.

Понять, действительно ли набор тестов ловит ошибки, помогает мутационное тестирование, или mutation testing. Инструмент намеренно вносит в код небольшие изменения: инвертирует условие, заменяет оператор или удаляет часть логики. Если после этого тесты продолжают проходить, значит, они не заметили поломку. Так работает, например, Stryker.

Флаки- и ложноположительные тесты

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

LLM часто копирует нестабильность из примеров, которые получает на вход. Если в исходных тестах используются фиксированные паузы, общие тестовые данные или зависимость от порядка запуска, модель воспроизведёт тот же подход в новом коде.

В исследовании 2026 года авторы сравнили созданные LLM тесты для SAP HANA, DuckDB, MySQL и SQLite с существующими наборами. Сгенерированные тесты немного чаще оказывались нестабильными. В 63% вручную разобранных случаев причиной стала зависимость от порядка элементов, который система не гарантировала. Модели также переносили нестабильность из тестов, переданных им в качестве примера.

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

Кто отвечает за качество: тест-дизайн никуда не делся

Перебрать значения несложно. Проблема в том, как понять, какие значения система должна обрабатывать одинаково и в каких точках меняется бизнес-поведение.

Для поля с диапазоном от 1 до 100 достаточно проверить 0, 1, 100 и 101. В продукте граница часто зависит ещё и от тарифа, валюты, роли или даты подключения. Эти условия не лежат на поверхности и редко помещаются в одном фрагменте требований.

Здесь и нужен тест-дизайн. Классы эквивалентности объединяют значения с одинаковой логикой обработки: суммы ниже 1 000 рублей — один класс, от 1 000 — другой. Анализ граничных значений проверяет точки смены поведения: 999, 1 000 и 1 001 рубль.

Для комбинаций параметров используют попарное тестирование (Pairwise). Например, для фильтров каталога ИИ может сгенерировать сотню тестов на все сочетания, а Pairwise сократит набор до 10–15 кейсов: каждая пара значений встретится хотя бы в одном сценарии. Это помогает не принимать большое количество однотипных тестов за хорошее покрытие.

Если результат зависит сразу от нескольких условий, их сводят в таблицу решений. Переходы состояний, поиск вероятных ошибок из опыта и исследовательское тестирование нужны там, где простого перебора уже недостаточно. Эти техники входят в актуальную программу ISTQB CTFL.

Для скидки из примера недостаточно взять суммы 1 000 и 2 000. Сначала нужно разложить само правило на условия:

• премиум-статус есть или нет;

• сумма ниже, равна или выше 1 000 рублей;

• скидка не превышает возможный лимит;

• итоговая цена корректно округляется;

• изменение статуса во время оформления заказа не меняет уже рассчитанный результат.

Только после этого становится понятно, какие сценарии нужны и какого результата ждать в каждом из них. ИИ может оформить их и перевести в код, но структуру проверки определил не он: она появилась в момент разбора бизнес-правила.

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

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

Поэтому ревью генерации — не вычитка формулировок. Нужно подтвердить ожидаемый результат, найти пропущенные классы, убрать дубли и сопоставить набор с реальными рисками продукта. Это и есть основная работа QA, даже если сами строки написал ИИ.

Как встроить ИИ без потери качества

Начинать с запроса «напиши весь регресс» бессмысленно. На сотне сгенерированных кейсов уже трудно отделить экономию от нового объёма работы, который команда получила на ревью.

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

Передавайте не только задачу

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

Но контекст нельзя измерять килобайтами. Весь репозиторий не поможет, если среди файлов нет ответа на проверяемый вопрос. Нужны документы и код, которые задают конкретное поведение, а не просто максимальный объём входных данных.

Для смены email рабочий запрос может выглядеть так:

Составь черновик тест-кейсов для смены email в B2B-сервисе.

Правила:
— новый email должен быть уникальным;
— сравнение выполняется без учёта регистра;
— ссылка подтверждения действует 24 часа;
— после повторного запроса предыдущая ссылка становится недействительной;
— до подтверждения вход и восстановление пароля работают со старым email;
— пользователи с SSO не могут менять email самостоятельно;
— новый адрес закрепляется за аккаунтом только после подтверждения.

Для каждого кейса укажи:
— проверяемое правило или риск;
— предусловия;
— шаги;
— ожидаемый результат.

Отдельно перечисли вопросы, на которые не хватает данных.

Не придумывай интерфейс, сообщения и правила, которых нет в описании.

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

Генерируйте небольшими частями

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

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

Разделите техническую и смысловую проверку

У сгенерированного автотеста сначала проверяют техническую состоятельность:

• собирается ли код;

• стабильно ли проходит тест;

• корректно ли настроены заглушки внешних зависимостей;

• очищаются ли данные;

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

И только потом — содержание:

• откуда взят ожидаемый результат;

• какое требование или риск закрывает тест;

• не повторяет ли он существующую проверку;

• какие классы и границы пропущены;

• действительно ли падение теста будет означать дефект продукта.

В промышленном TestGen-LLM от Meta Platforms Inc.* применялся похожий принцип: инженерам показывали не всю генерацию, а только тесты, которые прошли технические фильтры и давали измеримый прирост покрытия.

В оценке на Reels и Stories 75% сгенерированных тестов успешно собирались, 57% стабильно проходили и только 25% увеличивали покрытие. Во время внутренних тестовых сессий разработчики приняли для использования в продакшене 73% прошедших фильтрацию рекомендаций. Решение всё равно оставалось за инженерами, а не за самой системой.

_{* Meta Platforms Inc. признана экстремистской организацией, её деятельность в России запрещена.}

Доверить ИИ или оставить человеку

Таблица показывает границу ответственности: модель может подготовить вариант, но решение о качестве и достаточности набора остаётся у команды.

Заменит ли ИИ тестировщика

По данным World Quality Report 2025 — ежегодного исследования Capgemini, OpenText и Sogeti — 89% опрошенных организаций пилотируют или используют генеративный ИИ в обеспечении качества: 37% работают с ним в проде, ещё 52% остаются на стадии пилотов.

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

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

Сгенерировать текст тест-кейса стало дешевле. Определить его ценность, подтвердить ожидаемый результат и заметить пропущенный риск — нет.

У тестировщика при этом становится меньше механической работы и больше анализа: разбирать требования, строить модель рисков, проводить исследовательские проверки и ревьюить сгенерированное. Сокращать QA-команду только потому, что LLM написала сто кейсов, — примерно то же самое, что сокращать разработчиков после тысячи строк, сгенерированных Copilot.

Чек-лист: что проверить перед тем, как принять сгенерированный тест-кейс

1. Откуда взят ожидаемый результат? Он должен следовать из требования, спецификации или согласованного правила, а не только из текущего кода.

2. Какое требование или риск закрывает кейс? Если ответ не сформулирован, тест, возможно, только увеличивает объём набора.

3. Есть ли негативные сценарии помимо стандартной валидации? Модель часто ограничивается основным позитивным путём и очевидными ошибками ввода.

4. Верно ли выбраны классы эквивалентности и границы? Перебор чисел не гарантирует, что модель увидела точку, в которой меняется бизнес-правило.

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

6. Не придумала ли модель часть продукта? Сверьте методы, элементы интерфейса, сообщения, зависимости и правила с реальной системой.

7. Не дублирует ли кейс уже существующую проверку? Другие данные и формулировка ещё не делают сценарий новым.

8. Контролирует ли тест существенный результат? Проверки «ответ не пустой» недостаточно, если ошибка может быть внутри самого значения.

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

10. Падает ли тест, если намеренно сломать проверяемое условие? Если код изменился, а тест остался зелёным, его ценность сомнительна.

Что почитать дальше

• ISTQB CTFL 4.0: техники тест-анализа и тест-дизайна — программа даёт системную основу для проектирования проверок: классы эквивалентности, граничные значения, таблицы решений и переходы состояний. Пригодится, чтобы оценивать не количество сгенерированных кейсов, а полноту тестового набора.

• GitHub Docs: генерация тестов с помощью Copilot — практические примеры генерации модульных и интеграционных тестов. GitHub показывает, какой контекст передавать модели, как уточнять запрос и почему сгенерированный код нужно запускать, проверять и дополнять вручную.

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

• Stryker: как mutation testing проверяет сами тесты — понятное введение в мутационное тестирование. На примерах показано, как инструмент намеренно меняет условия и операторы в коде, а затем проверяет, заметит ли тестовый набор эту поломку.

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

• демодоступа к лекциям и практике курса «Инженер по тестированию» с целым набором бонусов для участников;

• бесплатного практического курса «ИИ в деле: ускорьте свою работу», если хотите внедрить ИИ-инструменты под разные потребности бизнеса;

• демодоступа к двум занятиям курса «Специалист по искусственному интеллекту», где увидите полный цикл работы с моделью;

• бесплатного курса «ИТ в действии: как создаются и живут цифровые продукты», на котором можно примерить на себя 6 разных ролей и попрактиковаться на реальных задачах разработчиков и инженеров.

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

• на расширенном курсе «Инженер по тестированию» с практикой от партнёров и поддержкой от тестировщиков из VK, Т-Банка и других компаний;

• на программе «Фулстек-разработчик на Python», где оформите до 43 проектов в портфолио;

• на практическом курсе «Нейросети для разработчиков» — для тех, кому надо внедрить AI в повседневную практику;

• на совместной с МФТИ программе «Разработчик на Python», чтобы сразу получить навыки построения IT-бизнеса — от генерации идей до привлечения инвестиций.