Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании.
В прошлый раз мы остановились на том, что без README с описанием архитектуры фреймворка генерация автотестов на большом легаси-проекте превращается в бесконечный цикл ревью и правок. Поэтому, начать лучше с создания такого документа, а уже после него переходить к коду.
Сегодня я расскажу о том, как именно я генерировала автотесты и локаторы, сколько это заняло по времени и где модель всё равно ошибалась.
Что нужно для запуска генерации автотестов?
Минимальный список артефактов на входе:
README с архитектурой — источник правды о структуре, паттернах, локаторах и т.д.
Файлы с тест-кейсами — я выгружала уже готовые кейсы из Zephyr.
Исходный код проекта, в котором модель будет писать новые автотесты.
Тест-кейсы и описание архитектуры я положила в одну папку внутри тестового модуля, так модели не приходится каждый раз искать файлы по всему репозиторию.
В процессе своих исследований я пришла к тому, что будет нелишним создать "алгоритм генерации автотестов" — документ, в котором описан поэтапный процесс генерации автотеста: какие классы и методы проверить, какой код добавить, как написать тест и т.д. Также в этом документе содержатся чек-листы, по которым ИИ проверит себя после генерации, и примеры "правильно / неправильно".
Команда для создания документа максимально простая, алгоритм генерируется по уже готовому README с описанием вашего проекта:
Изучи файл README.md и на его основе составь алгоритм генерации автотестов для нейросети — пошаговый регламент с примерами из проекта.
Этот алгоритм потом встраивается в основной промпт генерации, и результаты генерации получаются лучше.
Вот примеры некоторых этапов из готового алгоритма:
Пошаговый процесс генерации
Шаг 1. Подготовьте промпт для генерации
Попросите ИИ собрать промпт под ваш стек и ваш проект.
В промпте явно зафиксируйте:
ссылку на README с архитектурой;
ссылку на алгоритм генерации;
ссылку на файлы со сценариями тестов;
минимальные технические требования, не учтенные в README
запреты и ограничения: использовать существующие классы и методы, не изобретать новую архитектуру и т.п.
Готовый промпт я выложила в своём репозитории.
Я запускаю генерацию ограниченного числа тестов. Не 30 штук за раз, а какая-то логическая группа из нескольких автотестов, например для одного экрана калькулятора страховой премии. Также я разделяю генерацию е2е тестов и компонентных тестов, чтобы модель погружалась в один контекст за раз.
В промпте я иногда явно указывала, в каком пакете и классе должен появиться тест и нужно ли создавать новые page objects или достаточно существующих. Но так было до того момента, как у меня появился алгоритм генерации автотестов. С ним уже не нужно было каждый раз указывать, какие классы использовать.
Шаг 2. Запустите генерацию и дождитесь результата
Шаг 3. Ревью кода
Это обязательный шаг. ИИ ускоряет написание, но не снимает ответственность за качество.
На что смотрю я:
Область | Что проверить |
|---|---|
Дубли | Нет ли новых методов там, где уже есть готовые шаги |
Page objects | Используются существующие классы, структура не ломается |
Ассерты | Проверки в нужном месте, без лишних дублей |
Нейминг | Соответствует конвенциям из README |
Локаторы | Нет захардкоженного текста, который уже есть в константах |
Мелкие недочеты правлю руками, более крупные и систематические — через уточнение промпта или алгоритма генерации.
Шаг 4. Запустите тесты
Шаги 3 и 4 можно поменять местами. Мне обычно удобнее сначала понять, работает ли тест в принципе, а потом уже ревьюить код. На пилотном проекте 9 из 10 тестов с первого раза запускались и отрабатывали корректно, даже если код выглядел избыточным и неоптимальным. Т.е. ИИ сразу писал рабочий код, нужно было только провести ревью и поправить недочеты.
Локаторы: отдельный подпроцесс
Я дико не люблю руками писать локаторы, поэтому искала способ делегировать эту часть ИИ. Самый простой способ "в лоб" выглядит так:
Сохранить HTML страницы (или нужного фрагмента) в файл в папку, где лежат все артефакты для ИИ.
Запустить генерацию с опорой на раздел про локаторы в README — приоритеты атрибутов, параметризация, интерфейсы элементов.
Команда:
Сгенерируй локаторы на основе файла data_page_locators.html в соответствии с принципами из README.md
Локаторы можно генерировать до автотестов или после, я пробовала оба варианта. А еще можно не выгружать html, а запускать агента на тестовом стенде с задачей "вытащить" все локаторы из UI. Про агента я более подробно напишу в отдельной статье. Главное, что вариантов может быть много и нужно выбирать тот, который больше подходит под ваши процессы или просто больше вам нравится.
Скажу честно: из всех подпроцессов тестирования, которые я пыталась оптимизировать с помощью ИИ, наименьшее ускорение у меня получился именно на локаторах — генерация локаторов с ИИ была быстрее всего в 1,5-2 раза, чем ручное написание локаторов. Но даже такой результат я считаю хорошим, учитывая, как сильно я не люблю писать локаторы самостоятельно)
Ну и не забываем делать ревью локаторов после генерации. При необходимости вносим правки в код или промпт.
Что получилось по цифрам
Итоговые цифры с моего пилота, полученные на нашем стеке, после запуска успешного, отработанного процесса. У вас все может быть иначе, если домен сложнее или фреймворк другой.
Генерация автотестов заняла примерно в 4 раза меньше времени, чем если писать всё с нуля в одиночку на том же объёме.
За две недели суммарно набралось порядка 100 автотестов и базовый каркас, который можно переиспользовать для других продуктов.
По локаторам — ускорение в 1,5–2 раза, не больше. Возможно, что это связано с тем, что в проекте использовалась довольно редкая библиотека Atlas со своими правилами составления локаторов.
Даже если вы не хотите использовать ИИ для автоматизации, то всегда имеет смысл проанализировать ваш фреймворк с нейронкой для написания максимально подробного README проекта. Это очень облегчит онбординг новых автоматизаторов и, возможно, подскажет вам неочевидные места, требующие рефакторинга.
Еще одна зависимость
Я уже не раз писала о том, что качество входных данных напрямую влияет на качество результата. А генерация автотестов с ИИ зависит не только от предварительного анализа фреймворка, но и от детализации тест-кейсов, которые переданы в автоматизацию. Если тест-кейсы написаны под ручных тестировщиков, в них не хватает каких-то деталей (очевидных для погруженного в проект тестировщика, но не для ИИ), пропущены шаги или даны перекрестные ссылки на другие сценарии — никакой ИИ не напишет с первого раза рабочие автотесты. Вам придется вносить много ручных правок либо уже в сам код, либо дописывать недостающие шаги в тест-кейсах.
Поэтому, прежде чем переходить к генерации кода, убедитесь в том, что ваши тест-кейсы будут понятны ИИ и содержат в себе все необходимые детали. А это приводит нас к тому, что для хороших результатов нужно внедрять сквозной процесс слева. Если ручные тестировщики будут использовать ИИ-инструменты для генерации тест-кейсов, сразу подходящих для последующей автоматизации, то профит получат все.
Что в итоге
Генерация автотестов с ИИ работает, если не забывать о качестве входных данных (детальные тест-кейсы) и предварительной подготовке (анализ фреймворка + алгоритм генерации автотестов), а также об обязательном ревью результатов. Ну а если у вас что-то не получается, спросите нейронку - зачастую она сможет подсказать вам нужное направление.
На этом мы закончили рассматривать стандартный shift-left с ИИ. В следующих статьях я расскажу про другие задачи, с которыми вам могут помочь ИИ-инструменты.
Напоминаю, что мы уже успели поговорить про:
ИИ в тестировании: зачем мы пошли в пилот и почему начали с чата, а не с агентов
Контекст для LLM в тестировании: от калькулятора страховой премии до ТЗ на сотню страниц
Тестирование требований с ИИ: что делать, когда контекст уже готов
Продолжение следует!
