Генерация автотестов с ИИ: почему первый PR растянулся на две недели и что изменилось после анализа фреймворка

Всем привет! Я продолжаю свой цикл статей про применение ИИ в тестировании. Мы уже успели поговорить про:

• ИИ в тестировании: зачем мы пошли в пилот и почему начали с чата, а не с агентов ^[1]

• Контекст для LLM в тестировании: от калькулятора страховой премии до ТЗ на сотню страниц ^[2]

• Тестирование требований с ИИ: что делать, когда контекст уже готов ^[3]

• Генерация тестовой документации с ИИ ^[4]

Следующий этап в shift-left подходе — это автоматизация. А в нашем случае — генерация автотестов с помощью ИИ.

На пилоте к этому моменту у нас уже были готовые артефакты с предыдущих этапов:

• структурированный контекст продукта;

• оттестированные требования;

• детальные тест-кейсы и чек-листы в Zephyr.

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

Основные причины, по которым это имеет смысл:

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

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

Важный момент, который хочу подсветить: автотесты генерируются не для замены ручного ручного тестирования. Автотесты — это помощь с рутинным регрессом, а не отказ от экспертизы QA.

Как я начинала: оптимизм и один большой промпт

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

На пилоте мы автоматизировали UI калькулятора страховой премии Тест-кейсы уже лежали в Zephyr, контекст по продукту был готов. Казалось, что нужно просто превратить текстовые сценарии в код.

Я взяла за основу уже существующий крупный проект с автотестами — тот, на котором в компании уже писали UI-тесты. Промпт был подробным. Тест-кейсы — тоже. Проект полностью в доступе ИИ-агента. Что же могло пойти не так?

Первые UI-автотесты получились быстро, но даже близко не того качества, которое нам требовалось. Замечания по первому pull request я разгребала почти две недели, параллельно переосмысливая свои ошибки ^[5].

Почему не получилось с первого раза

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

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

Я не знала библиотеку, на которой строился фреймворк, и нейросеть тоже. Проект был построен на библиотеке Atlas ^[6], с которой я вообще ни разу не работала, а у ИИ не оказалось знаний по ней, т.к. в интернете в принципе мало информации по Atlas.

Я смешала два разных процесса в один запрос. «Проанализируй архитектуру» и «напиши тесты по этим кейсам» — задачи разного масштаба. Когда их склеиваешь, модель уделяет внимание ^[7] тому, что ближе к финальному результату, а архитектурные договорённости пролетают мимо.

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

Шаг, который всё переломил

Я разделила процесс на два этапа.

Этап 1. Попросила ИИ подробно описать архитектуру тестового проекта: структуру, паттерны, page objects, принципы построения локаторов, организацию классов и т.п.

По времени анализ занял около сорока минут. На выходе получился большой README, в моём случае порядка 19 страниц текста с реальными примерами кода из проекта. Вручную я бы писала такой документ…. Да, честно говоря, так вообще и не написала бы)

Этап 2. Только после этого я запустила генерацию автотестов по тест-кейсам, с предварительным изучением получившегося README.

Что изменилось после появления документа с описанием архитектуры:

• ИИ перестал каждый раз сканировать весь репозиторий с нуля, и получал необходимые знания, считывая за несколько секунд один текстовый документ;

• результаты генерации стали стабильнее;

• ИИ начал с первой попытки следовать всем необходимым паттернам и code style проекта, перестал придумывать свое.

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

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

Что должно быть в анализе фреймворка

Хороший README — это не пересказ дерева папок. Это подробная инструкция по проекту с автотестами, на которую может опираться как ИИ, так и человек.

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

1. Общая информация — язык, фреймворк тестирования, UI-библиотека, система отчётности, сборщик.

2. Структура проекта — модули, пакеты, назначение каждой ключевой папки.

3. Паттерны — Page Object, Steps, базовые компоненты и всё, что реально используется в коде (с примерами, не абстракциями).

4. Локаторы — приоритеты атрибутов, параметризация, константы для текстов.

5. Принципы написания тестов — структура класса, аннотации, naming convention, Arrange–Act–Assert.

6. Работа с данными — DTO, enum, генераторы.

7. Конфигурация — профили, переменные окружения.

8. Чек-листы — что проверить при создании нового page object, локатора, теста.

9. Антипаттерны — примеры «так у нас не делают» с объяснением, почему.

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

Пошаговая инструкция: анализ фреймворка перед генерацией

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

Шаг 1. Подготовьте промпт для анализа

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

В промпте явно зафиксируйте:

• задачу на детальный анализ архитектуры;

• список аспектов (структура, паттерны, локаторы, тесты, данные, конфигурация);

• формат вывода — README.md ^[8] с примерами кода, чек-листами и блоками «правильно / неправильно»;

• запрет на выдумывание: только то, что есть в репозитории.

Готовый промпт я выложила в своем репозитории.

Шаг 2. Подготовьте проект в Cursor

• Откройте весь проект автотестов в Cursor: модели нужен доступ к коду, а не только к промпту.

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

• Положите в неё промпт для анализа.

Шаг 3. Запустите анализ

Команда простая:

Выполни задание, описанное в файле [путь к промпту для анализа архитектуры]

Дождитесь завершения. На большом проекте это может занять от 30 до 60 минут — это нормально. Зато вы тратите это время один раз, а не при каждой генерации теста. Ну и никто не отменяет кофе-брейка, пока ИИ изучает ваши автотесты)

Если анализ идёт слишком долго:

• ограничьте область, например, только тестовый модуль без сгенерированных файлов и зависимостей;

• разбейте на части: сначала структура и паттерны, потом локаторы и тесты.

Шаг 4. Проверьте README

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

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

Если что-то не так — не перезапускайте анализ целиком. Укажите ИИ конкретные файлы или классы и попросите поправить раздел.

Шаг 5. Сохраните и подключите к процессу генерации

• Сохраните README в репозитории , например, в папку cursorData внутри тестового модуля.

• При каждой генерации автотестов сначала ссылайтесь на этот файл:

Изучи архитектуру проекта в файле README.md, затем напиши тест для [описание задачи]

• Добавьте README в code review: если архитектура проекта меняется, документ тоже должен обновляться.

Шаг 6. Регулярно обновляйте

README устаревает. Планово пересматривайте его:

• при добавлении новых page objects или крупных рефакторингах;

• при смене архитектуры;

• просто так раз в 1–2 месяца, чтобы примеры кода не отставали от реальности.

Что дальше: от README к рабочим тестам

Когда README готов и отревьюен, можно переходить к генерации, о чем я расскажу в следующей статье.

Что в итоге

Генерация автотестов с ИИ возможна, но не начинается с промпта «напиши тест по этому кейсу». Она начинается с вопроса: понимает ли модель (и вы сами) архитектуру проекта, в котором этот тест должен быть написан.

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

Напоминаю про выложенные в моем репозитории материалы ^[9] по этому и другим этапам тестирования с ИИ.

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

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