Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании.

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

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

Что нужно для запуска генерации автотестов?

Минимальный список артефактов на входе:

1. README с архитектурой — источник правды о структуре, паттернах, локаторах и т.д.

2. Файлы с тест-кейсами — я выгружала уже готовые кейсы из Zephyr.

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

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

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

Команда для создания документа максимально простая, алгоритм генерируется по уже готовому README с описанием вашего проекта:

Изучи файл README.md и на его основе составь алгоритм генерации автотестов для нейросети — пошаговый регламент с примерами из проекта.

Этот алгоритм потом встраивается в основной промпт генерации, и результаты генерации получаются лучше.

Вот примеры некоторых этапов из готового алгоритма:

Пошаговый процесс генерации

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

Попросите ИИ собрать промпт под ваш стек и ваш проект.

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

• ссылку на README с архитектурой;

• ссылку на алгоритм генерации;

• ссылку на файлы со сценариями тестов;

• минимальные технические требования, не учтенные в README

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

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

Я запускаю генерацию ограниченного числа тестов. Не 30 штук за раз, а какая-то логическая группа из нескольких автотестов, например для одного экрана калькулятора страховой премии. Также я разделяю генерацию е2е тестов и компонентных тестов, чтобы модель погружалась в один контекст за раз.

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

Шаг 2. Запустите генерацию и дождитесь результата

Шаг 3. Ревью кода

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

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

Мелкие недочеты правлю руками, более крупные и систематические — через уточнение промпта или алгоритма генерации.

Шаг 4. Запустите тесты

Шаги 3 и 4 можно поменять местами. Мне обычно удобнее сначала понять, работает ли тест в принципе, а потом уже ревьюить код. На пилотном проекте 9 из 10 тестов с первого раза запускались и отрабатывали корректно, даже если код выглядел избыточным и неоптимальным. Т.е. ИИ сразу писал рабочий код, нужно было только провести ревью и поправить недочеты.

Локаторы: отдельный подпроцесс

Я дико не люблю руками писать локаторы, поэтому искала способ делегировать эту часть ИИ. Самый простой способ "в лоб" выглядит так:

1. Сохранить HTML страницы (или нужного фрагмента) в файл в папку, где лежат все артефакты для ИИ.

2. Запустить генерацию с опорой на раздел про локаторы в README — приоритеты атрибутов, параметризация, интерфейсы элементов.

Команда:

Сгенерируй локаторы на основе файла data_page_locators.html в соответствии с принципами из README.md

Локаторы можно генерировать до автотестов или после, я пробовала оба варианта. А еще можно не выгружать html, а запускать агента на тестовом стенде с задачей "вытащить" все локаторы из UI. Про агента я более подробно напишу в отдельной статье. Главное, что вариантов может быть много и нужно выбирать тот, который больше подходит под ваши процессы или просто больше вам нравится.

Скажу честно: из всех подпроцессов тестирования, которые я пыталась оптимизировать с помощью ИИ, наименьшее ускорение у меня получился именно на локаторах — генерация локаторов с ИИ была быстрее всего в 1,5-2 раза, чем ручное написание локаторов. Но даже такой результат я считаю хорошим, учитывая, как сильно я не люблю писать локаторы самостоятельно)

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

Что получилось по цифрам

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

• Генерация автотестов заняла примерно в 4 раза меньше времени, чем если писать всё с нуля в одиночку на том же объёме.

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

• По локаторам — ускорение в 1,5–2 раза, не больше. Возможно, что это связано с тем, что в проекте использовалась довольно редкая библиотека Atlas со своими правилами составления локаторов.

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

Еще одна зависимость

Я уже не раз писала о том, что качество входных данных напрямую влияет на качество результата. А генерация автотестов с ИИ зависит не только от предварительного анализа фреймворка, но и от детализации тест-кейсов, которые переданы в автоматизацию. Если тест-кейсы написаны под ручных тестировщиков, в них не хватает каких-то деталей (очевидных для погруженного в проект тестировщика, но не для ИИ), пропущены шаги или даны перекрестные ссылки на другие сценарии — никакой ИИ не напишет с первого раза рабочие автотесты. Вам придется вносить много ручных правок либо уже в сам код, либо дописывать недостающие шаги в тест-кейсах.

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

Что в итоге

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

На этом мы закончили рассматривать стандартный shift-left с ИИ. В следующих статьях я расскажу про другие задачи, с которыми вам могут помочь ИИ-инструменты.

Напоминаю, что мы уже успели поговорить про:

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

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

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

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

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

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