Cодержание:
Введение
Как войти? Быстрый старт
0. Первые шаги
1. Аналитика и анализ
2. Рядовые кейсы для облегчения жизни
3. Настраиваем свой тестовый фреймворк
4. Тестирование API
5. Тестирование UI
Заключение
Введение
AI, LLM, нейросети, искусственный интеллект. Каждый день мы слышим о них из каждого утюга, как это круто, полезно, супер, всем рекомендую, что скоро потеряем работу и прочее. При всем многообразии информации, публикации и статей, это всё ещё остается игрушкой техно энтузиастов.
Многие ещё не проснулись и не понимают, куда движется развитие нейросетей. А рядовой пользователь может даже не представлять, что это такое («слышал я про ваш этот биткоин»), не говоря уже о том, чтобы применять это на практике.
Как и технологии распределены неравномерно, так и знание о технологиях распределено неравномерно. Когда одни люди запускают мультиагентные системы, заменяют подразделения сотрудников нейроагентами или полностью автоматизируют свою жизнь, попутно доверяясь нейро‑психологам, диетологам, докторам, коучам, ассистентам, другие в этот момент сталкиваются со сложностями уровня «как написать промпт».
Давай погрузимся на более прикладной уровень: как применять в работе это чудо? А конкретно — как это может быть полезно, если ты рядовой QA‑automation‑инженер.
Статья носит информационно‑прикладной характер и предназначена для ознакомления с кейсами применения LLM‑консультантов и агентов для сотрудников QA/automation‑инженерии. Важно отметить, что в статье не рассматриваются расширенные возможности, наподобие мультиагентности, и предполагается, что у пользователя есть базовая подписка.
Как войти? Быстрый старт
Часть посвящена новичкам, которые пытаются понять, что такое LLM и как это применять в работе.
Если вы не купили целый пиар отдел для написания курсов по LLM, то можно найти открытые бесплатные курсы про введение в нейросети и как ими пользоваться.
Быстрое и безболезненное погружение можно осуществить через эти ресурсы:
открытый курс Как упростить жизнь с помощью нейросетей — https://t‑j.ru/pro/ai‑text/ — универсальный вводный курс для всех.
документация по клоду, для использованию агентов cloude code — https://code.claude.com/docs/ru/quickstart — больше полезно для automation.
курс по возможностям агентной IDE Cursor — https://cursor.com/en‑US/learn — больше полезно для automation.
После этого вы ощутите что‑то на подобии:
«я получил власть, которая и не снилась моему отцу »
Какая разница между ИИ-ассистентом и ИИ-агентом?
Важно дать определение какие нейросети есть. Остановимся на двух основных понятиях: ассистенты и агенты. Поймем, в чем их разница.
Языковая модель* — это база, алгоритм, обученный на огромных массивах текста.
🫡 ИИ‑ассистент
Ассистент — это обёртка или приложение, использующее языковую модель. (Например: ChatGPT, Gemini, Copilot, Perplexity, jaycopilot).
У него нет долгосрочной памяти — при каждом новом вопросе ему подгружают краткий контекст, о чем говорили до этого и он отвечает(угадывает) дальше.
Отвечает на один запрос за раз. Хорош в решение конкретных, простых задач в один шаг: перевести текст, ответить на вопрос, написать письмо, проанализировать ошибку, исправить тест, предложить 10 вариантов проверок, проанализировать кусок документации и написать тест кейсы по нему.
🤖 ИИ‑агент
Это как множество ассистентов, объединённых в одном суперагенте. Он имеет память и помнит весь контекст задачи. Может ссылаться на правила, видеть весь ваш репозиторий кода, интегрироваться с другими приложениями и управлять ими. Например, подключаться к базе данных и полностью управлять ею через текстовые команды. Или — подключаться к вашему репозиторию и по команде пушить код. Кроме того, он способен общаться с другими агентами, выстраивая сеть из взаимосвязанных агентов.
Помнит всё про задачу, знает куда двигается, т.е способна к автономному планированию и выполнению задач.
Может выполнять задачи в несколько шагов без постоянных подсказок, использует память, чтобы помнить, что было сделано или, о чем шла речь.
Ассистент = умный исполнитель, который делает одно задание хорошо, но без продолжения (не помнит истории). Агент = целая команда или компания, которая работает над проектами, координирует процессы и обучается по ходу дела.
Ассистент — дизайнер, который рисует одну иконку. Агент — рекламное агентство, где работают дизайнеры, копирайтеры, менеджеры, аналитики, и они ведут десятки проектов одновременно.
Когда что использовать?
Когда что использовать?
Для быстрых одноразовых задач — ассистенты в виде чатов (jaycopilot, ChatGPT, Gemini, Copilot, Harvey AI — юриспруденция, Runway Gen-2, Pika Labs — видео, Suno, Aiva — музыка).
Для сложных задач с несколькими шагами — агенты, которые специально заточены для решения конкретных задач (пример сетей который поддерживают функции агентов: Yandex Code Assistant, Claude Code, Cursor) Важно понимать, что развитие сетей происходит стремительно, и каждый день появляются новые возможности. Но общее правило остается — под вашу задачу нужно использовать ту сеть, которая создана или наиболее подходит под решение вашей задачи. Согласитесь, странно ожидать от LLM, предназначенной для написания музыки, хорошего кода для приложений — она просто не для этого создана.
Списки о доступных сетях и что они могут делать легко найти в интернете, не будем на этом останавливаться. И вот мы уже научились печатать слова, возвращаемся к нашему проекту. Что же нам делать дальше?
0. Первые шаги
Дальнейший обзор будет происходит на примере моего собственного проекта автотестов. Написан много лет назад, настоящими руками, где ещё надо было самому думать. Думать? Не, бред какой‑то.
Что имеем? Старый проект авто тестов на java. Стек всё ещё актуален как никогда и надежен как швейцарские часы.
Наш стек
1. Язык: Java 17+ 2. UI Testing: Selenide, Selenoid 3. API Testing: REST Assured 4. Test Framework: JUnit 5 5. Build Tool: Maven 6. Reporting: Allure/TestOps 7. CI/CD: GitLab 8. Data: PostgreSQL
Техника безопасности
Что важно отметить:
Убедитесь, что политика безопасности вашей компании разрешает загрузку кодовой базы в облачные LLM. Для сенситив проектов, используйте локальные модели или Enterprise‑решения, предоставляемые компанией. Обязательно и всегда чистим код от кредов и других чувствительных данных.
При планировании изменений, обязательно используйте Planning Mode, в Claude Code это активируется комбинацией Shift+Tab дважды, в Cursor — через Agent Mode с планированием. И только после полного понимания того, что мы хотим изменить, даём разрешение приступить к работе — желательно с ручным подтверждением последующих изменений. Если полностью отдавать контроль агенту, возможно получить непредсказуемый, избыточный или попросту бесполезный результат... При масштабном рефакторинге, очень просто упустить что вообще происходит, поэтому желательно отслеживать каждый шаг, чтобы не пришлось откатывать изменения при массовой поломке.
1. Аналитика и анализ
Кейс: Комплексный аудит Фреймворка авто тестирования
Проблема: Для начала попробуем понять, а «норм или не норм» наш проект? Конечно же мы пилили наше детище годами, лелеяли, рефакторили. Проект обрастал мхом новыми фичами и тестами. Становился аж целым фреймворком, конечно же мы уже и не понимаем, как он работает и зачем мы это всё написали. Для понимания «зачем и как» проведем подробный аудит проекта.
Вар 1: Комплексный аудит фреймворка автотестирования
Что используем: Claude Code, Cursor или любой агентный LLM с возможностью анализа кода
Пример промпта:
Я хочу, чтобы ты провёл аудит всего моего проекта с точки зрения профессионального автотестировщика:
ЗАДАЧИ АУДИТА:
1. Проанализируй модули и структуру построения фреймворка
2. Оцени подключение к базе данных и работу с данными
3. Изучи структуру тестов и их организацию
4. Дай оценку по скорости работоспособности
5. Проверь актуальность bestpractices подходов
6. Составь подробный отчёт с рекомендациями
КРИТЕРИИ ОЦЕНКИ:
- Архитектура и модульность
- Производительность и стабильность
- Поддерживаемость кода
- Соответствие современным стандартам
- Инфраструктура и CI/CD
- Управление тестовыми данными
ФОРМАТ ОТЧЕТА:
1. Executive Summary
2. Критичные проблемы (High Priority)
3. Важные улучшения (Medium Priority)
4. Мелкие доработки (LowPriority)
5. План действий с оценкой трудозатрат
6. Бенчмарки и метрики
ФОКУС: Меня больше волнует глобальное построение фреймворка и инфраструктуры,
чем отдельные маленькие тесты.
Если будут вопросы -- задавай. Сохрани файл с аудитом в корень проекта.
Вар 2: Аудит API тестов
Проанализируй структуру моих API тестов:
- Соответствие REST API best practices
- Покрытие HTTP методов и статус кодов
- Валидация схем JSON
- Управление аутентификацией
- Производительность запросов
Дай рекомендации по улучшению архитектуры API тестов.
Вар 3: Аудит безопасности
Проведи security аудит моего фреймворка автотестирования:
- Хранение credentials и sensitive data
- Логирование конфиденциальной информации
- Доступы к тестовым окружениям
- Уязвимости в зависимостях
- Соответствие OWASP рекомендациям
Составь план устранения security issues.
Вар 4: Аудит производительности
Проанализируй производительность моих тестов:
- Время выполнения test suites
- Узкие места в коде
- Возможности оптимизации
- Метрики и мониторинг
Предложи конкретные способы ускорения тестов.
Результат: На выходе получаем солидное полотно текста с подробным анализом модулей проекта. Что плохо и как сделать лучше, список рекомендаций к исправлению с приоритетом по критичности по всем модулям (бд, утечки памяти, логи, отчеты, многопоточность, стабильность) — В общем, солидный список важных доработок, которые сделают ваш проект лучше.
Экономия времени на анализ проекта огромна. LLM становится вашим виртуальным аудитором, который может за час проанализировать то, на что у человека ушли бы недели! Применение: обязательно.
Особенно ценно: Когда вы единственный тестировщик на проекте и нужен независимый экспертный взгляд со стороны.
Кейс: Выявление повторяющихся и дублирующих тестов
Проблема: Бывает, что со временем проект разрастается, и мы уже не помним, какие тесты были написаны. Тестов много, проверок много, и никто уже не помнит, что и зачем проверяет. Из этого часто возникает проблема дублей. Что с этим можно сделать:
Вар 1: Анализ директории на дубли
Что используем: Claude Code, Cursor или любой агентный LLM с возможностью анализа кода
Я хочу, чтобы ты проверил на наличие дублирующих проверок в:
{src/test/java/tests/user/наш проект}
Проанализируй:
— Повторяющиеся тестовые сценарии
— Одинаковые проверки в разных тестах
— Похожие и повторяющиеся методы
— Дублирующие утилитные методы
После этого выведи сравнительный анализ в виде таблицы на наличие дублей и рекомендациями по устранению.
Вар 2: Сравнение конкретных тестов
Я хочу, чтобы ты сравнил:
{UserRegistrationTest.java} с {UserCreationTest.java}
Выведи сравнительный анализ на:
— Различие тестовых сценариев
— Наличие дублей в проверках
— Целесообразность существования обоих тестов
— Возможности объединения или рефакторинга
Дай рекомендации что делать с этими тестами.
Результат: В результате мы значительно экономим время на анализ наших тестов и можем в удобном формате получить текущее состояние тестов. Получаем удобную статистику по проценту дублирования: какие тесты можно удалить и какие — объединить. Если проводить анализ всего проекта на дубли, экономия времени будет колоссальной. В целом можно проводить любые аналитические вопросы подобным способом.
2. Рядовые кейсы для облег��ения жизни
Кейс: Как LLM упрощает написание SQL запросов
Проблема: Проблема: Сложные SQL запросы отнимают время. Обычно в работе хватает простых SELECT * FROM table WHERE condition, но вдруг понадобился сложный запрос с несколькими JOIN'ами, подзапросами и агрегацией. И тут начинается: «А как правильно джоинить эту таблицу?», «Какой синтаксис?», «Почему GROUP BY ругается?»
Как было раньше: Садимся и начинаем собирать запрос по кусочкам, проверяем каждый JOIN отдельно, вспоминаем синтаксис, гуглим примеры, отлаживаем общий запрос…
Что используем: Любой LLM‑ассистент (ChatGPT, Gemini, Claude, GitHub Copilot)
Как стало с LLM: Прописываем задачу сразу в чат:
Вар 1: Составляем сложный запрос
Пишем что хотим получить:
У меня есть таблицы:
users (id, name, email, department_id)
departments (id, name, manager_id)
orders (id, user_id, amount, created_at)
Нужен запрос: показать всех пользователей с их отделами и суммой заказов за последние 30 дней. Включить пользователей без заказов.
Вар 2: Генерация тестовых данных
Пишем примерно следующее: Создай SQL скрипт для заполнения тестовыми данными таблиц users, departments, orders. Нужно 100 пользователей, 5 отделов, 1000 заказов. Данные должны быть реалистичными.
Вар 3: Отладка нерабочих запросов
Пишем что‑то такое:
Скидываем целиком наш SQL запрос. И просим: Этот SQL запрос выдает ошибку. Объясни проблему и исправь. Также объясни, что делает каждая часть запроса.
Результат: Раньше: Изучение документации, написание запроса, отладка, оптимизация — в зависимости от сложности может занимать часы, у разработчиков или аналитиков с огромными простынями запросов — может быть и больше.
Теперь: Промпт/Запрос/Описание для LLM — 5 мин, проверка результата — 2 мин, адаптация/отладка — 10 мин. Итого: ~20 минут на то что могло занимать часы.
Вывод: LLM превращает написание SQL из мучительного процесса в быстрое прикладное решение. Главное правильно формулировать что вы хотите.
Кейс: когда нам нужно написать проверку по regexp
Проблема: умения писать regexp уравнения — это отдельный вид искусства. Чтобы учесть всё что нужно и собрать шаблон, требуется довольно много времени. С приходом LLM можно забыть про самостоятельное написание регулярных выражений.
Нам нужно регулярное выражение для валидации email адресов в автотестах.
Вар 1: regexp на email
Что используем: Любой LLM‑ассистент (ChatGPT, Gemini, Claude, GitHub Copilot)
Нам нужно регулярное выражение для валидации email адресов в автотестах.
Пишем следующее сразу в чат: Создай регулярное выражение для валидации email адресов в автотестах. Нужно поддерживать стандартные форматы, включая поддомены.
Или, если нам нужно написать шаблон на проверку конкретного типа email, то можем скинуть пример посты, например: Создай регулярное выражение на проверку почты формата: test@test.name.ru
Вар 2: проверки на имя пользователя
Пишем запрос с углубленными требованиями, если необходимо. Помни, что добавлять требования можно бесконечно, нас же интересует быстрый подход и результат.
Пишем следующее: Создай регекс для генерации валидных и невалидных тестовых данных для поля «Имя пользователя»: Длина: 3–20 символов. Разрешены: буквы, цифры, подчеркивание. Не может начинаться с цифры.
Результат: Получаем в ответе что‑то типа этого: ^[a‑zA‑Z0-9._%+‑]+@[a‑zA‑Z0-9.‑]+\.[a‑zA‑Z]{2,}$, и навсегда забываем про ужасы формирования regexp в ручную.
Вывод: После чего используем данный шаблон для своих проверок в тестах. Быстро и легко, экономия времени значительная.
Кейс: когда кажется, что можно сделать проще
Проблема: Написали автотест, он работает, но кажется можно сделать красивее, быстрее и лучше. Но как именно улучшить — не понятно. Что можно сделать:
Вар 1: свежий взгляд на код
Что используем: Любой LLM‑ассистент (ChatGPT, Gemini, Claude, GitHub Copilot)
Пишем максимально просто:
Проанализируй мой автотест, мне кажется что его можно сделать лучше. Предложи варианты что с ним можно сделать? Важно чтобы было понятно и быстро. Поищи варианты бест практис написания автотестов. Не перегружай и не мудри лишнего.
Вар 2: упрощение и оптимизация
Упрости этот тест, убери дублирование и сделай более читаемым. Простота и понятность важнее чем красота кода.
Поищи решения как можно ускорить работу теста.
Подумай как убрать дублирование и переделай тесты в один параметризированный.
Результат: Получаем новые свежие идеи, варианты по оптимизации и упрощению. Полезно для поиска новых идей, выход за рамки привычных сценариев. Особенно ценно, когда замыливается глаз от долгой работы с одним и тем же кодом.
Кейс: Когда нужно написать проверки на ответ API
Проблема: Написали заготовку теста на REST Assured (Авторизация, Тело запроса или параметры, отправили запрос). Стандартный тест, где проверяем валидацию на обязательность полей, отправляя пустые поля в запросе. Отправили. Получили JSON с 30+ полями ошибок.
И каждое поле «кричит» в стиле:«errors»: { «firstName»: «ФИО обязательно», «lastName»: «Фамилия обязательна», //... и ещё 23+ поля },
Раньше: Мы говорили окей, садились и начинали по очереди писать ассерты на каждое поле. При изменении схемы API переделывали всё заново. Простая и нудная работа.
Что можно делать сейчас:
Копируем весь наш тест в ассистента
Копируем ответ из консоли/логов
Без усложнений просим: Возьми мой тест и напиши проверки на его ответ в формате.body() / assertThat()
Или можно скопировать пример проверок которые мы написали ранее и просить: возьми пример этих проверок за основу и делай также.
Экспериментируй! Спрашивай, уточняй, узнавай что добавить ещё. Вариантов очень много.
Результат: Получаем готовый результат за секунды. Процесс написания проверок из долгой рутины превращается в операцию копирования‑вставки. Экономия времени в разы на долгой дистанции.
3. Настраиваем свой тестовый фреймворк
Кейс: Настройка системы логирования
Проблема: Я вижу, что в моем проекте мне недостаточно логирования или оно работает нестабильно или недостаточно информативно. Разбираться с логами, писать систему логирования долго и не хочется. Поэтому я сразу пишу о проблеме в чат:
Вар 1: Решаем проблемы с отображением логов в Allure
Что используем: Claude Code, Cursor или любой агентный LLM с возможностью анализа кода
У меня проблема с логированием в автотестах: Когда я запускаю автотесты локально, то вижу логи в отчете. Но когда я запускаю тесты удаленно через гитлаб раннер, то в моем Allure отчете, я их не вижу.
ТЕКУЩАЯ СИТУАЦИЯ:
— Локально: логи видны в консоли
— Библиотека: {Logback/Log4j2/SLF4J}
— CI/CD: GitLab Runner
— Проблема: в Allure отчете логи не отображаются
ТРЕБОВАНИЯ:
— Настроить отображение логов в Allure отчетах
— Логировать цепочку запросов/ответов API
— Подробное логирование для отладки
— Работа в локальной и удаленной среде
Проанализируй мою текущую конфигурацию и настрой систему логирования. Я хочу чтобы ты настроил систему логирования так, чтобы в Аллюр отчете, было видно всю цепочку запросов ответов, чтобы было подробно настроено логгирование при локальном и удаленном запуске тестов.
Вар 2: Настройка с нуля
Нужно настроить систему логирования для фреймворка автотестов: (указываем адрес проекта)
АРХИТЕКТУРА:
— Язык: Java
— Тестовый фреймворк: {JUnit5}
— Отчетность: Allure / AllureTestOps
— Типы тестов: API + UI
ЗАДАЧИ:
— Логирование HTTP запросов/ответов
— Скриншоты при падении UI тестов
— Структурированные логи для анализа
— Разные уровни детализации (DEBUG, INFO, ERROR)
— Ротация и архивирование логов
Создай полноценную систему логирования с примерами использования.Добавь комментарии, для лучшего понимания и поддержки. Используй бест практис автотестирования для настройки логирования.
Результат: По итогу получаем полноценную систему логирования в проекте. Подробное отображение, красивое оформление. Даже смайлики есть, что конечно лишнее, но скучные логи становятся повеселее. Экономия времени на настройку и рефакторинг системы логирования или её расширение в проекте значительная. Не забывайте использовать planning mode для масштабных изменений конфигурации логирования.
Кейс: Оптимизация многопоточности
Проблема: На основании аудита выявлено, что у нас проблема с многопоточностью. А может, у вас на проекте она вообще не настроена? Обязательно используем Planning Mode: Shift+Tab дважды (Claude Code) или Agent Planning (Cursor)
Вар 1: Оптимизация существующей многопоточности
На основании проведенного аудита и выявленных проблем с многопоточностью, результаты которого сохранены в файле {адрес файла с отчетом.md}
ПРОБЛЕМЫ ИЗ АУДИТА:
— Race conditions при работе с общими ресурсами
— Нестабильные падения в многопоточном режиме
— Конфликты при работе с БД/файлами
— Неоптимальное использование ресурсов
ЦЕЛИ ОПТИМИЗАЦИИ:
— Повысить стабильность параллельного выполнения
— Ускорить общее время выполнения тестов
— Устранить конфликты ресурсов
— Сохранить читаемость и поддерживаемость кода
Спланируй работы по оптимизации многопоточности при запуске автотестов, с детальным анализом
каждой проблемы. Дай подробный анализ проблемы, и результаты которые ожидается достигнуть после внесения исправлений.
Вар 2: Внедрение многопоточности с нуля
Мне нужно внедрить многопоточный запуск тестов на проекте: дай мне подробный план как можно внедрить многопоточный запуск тестов на проекте. Какие библиотеки нужны, что нужно дополнительно настраивать, как это сделать?
ТЕКУЩАЯ АРХИТЕКТУРА:
{описание фреймворка/прикрепление ключевых файлов}
ТРЕБОВАНИЯ:
— Фреймворк: {JUnit5}
— Типы тестов: {API/UI/интеграционные}
— Ресурсы: БД, файлы, внешние API
— Целевое количество потоков: {4–8} с возможностью переключения
ЗАДАЧИ:
1. Анализ текущего кода
2. Выбор оптимальной стратегии параллелизации
3. Настройка изоляции данных между потоками
4. Конфигурация тестового фреймворка
Составь подробный план внедрения с пошаговой инструкцией на основании анализа проекта.
Вар 3: Диагностика проблем многопоточности
Мои тесты нестабильно работают в многопоточном режиме:
СИМПТОМЫ:
— Локально в одном потоке: работает
— В CI с параллелизмом: случайные падения
— Ошибки: {примеры ошибок из логов}
ПОДОЗРЕНИЯ:
— Конфликты при работе с тестовыми данными
— Проблемы с WebDriver в UI тестах
— Состояние гонки при работе с БД
— Неправильная изоляция между тестами
ТЕКУЩАЯ КОНФИГУРАЦИЯ:
{прикрепить конфигурационные файлы}
Проанализируй проблемы, текущую конфигурацию и предложи решения для стабилизации.
Результат: Получаем настроенную многопоточность на проекте с подробной инструкцией. Повышение стабильности и скорости работы автотестов при анализе проблем, на ~50% в моем случае. Ну и, конечно же экономия времени на анализ проблемы и эксперименты по оптимизации. Красота!
Кейс: Настройка JDBС на проекте
Проблема: Мы создали свежий Java проект, и нам нужно написать автотест где требуется подключиться к базе данных и вытянуть или записать какие‑то данные. Казалось бы, что сложного? Добавил драйвер, прописал connection.. Но на практике оказывается, что и подключение у нас не закрывается и пулл переполняется, и вообще мы забыли как это всё это написать. Вместо того чтобы копаться и гуглить best practice что и как собрать, используем LLM для быстрой и настройки JDBC.
Вар 1: Настройка JDBC с нуля
Что используем: Claude, ChatGPT, Cursor или любой агентный LLM с возможностью анализа кода
Мне нужно настроить JDBC подключение для Java проекта:
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ:
— Java 17, никакого спринга, чистая JDBC, я не хочу грузить свой проект автотестов спрингом.
— База данных: PostgreSQL, Oracle — учитывай возможность подключения к разным базам.фф
— Проект: веб‑приложение с REST API
ЗАДАЧИ:
1. Настрой JDBC драйвер и connection
2. Создай оптимальную конфигурацию пула соединений
3. Добавь обработку исключений и retry логику
4. Настрой мониторинг соединений
5. Создай тестовый класс для проверки подключения
6. Добавь побольше комментариев, чтобы любому человеку было понятно что происходит.
7. Создай необходимые сервисные классы и методы, которые я буду использовать в автотестах.
8. Я хочу иметь сервисные методы которые мне позволять выполнять CRUD операции.
ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ:
— Максимально просто и быстро. У меня всё же проект автотестов.
— Проверяй закрытие соединений, учитывай если запрос завис, ставь таймауты.
Вар 2: Оптимизация существующего JDBC модуля
Проанализируй мою текущую JDBC конфигурацию на производительность:
{прикладываешь свои файлы конфигурации или указываешь путь}
ПРОБЛЕМЫ которые я заметил:
— Запросы выполняются 5–10 секунд — слишком долго.
— Много ошибок «Connection pool exhausted»
ЦЕЛИ ОПТИМИЗАЦИИ:
— Ускорить запросы в 2–3 раза
— Снизить потребление ресурсов
— Устранить connection pool issues
Проанализируй и дай конкретные рекомендации по оптимизации с примерами кода.
Результат: Получаем готовую рабочую конфигурацию по взаимодействию в БД за 10 минут. Всё оптимизированно и перепроверенно на утечки. Огромная экономия времени на настройке и оптимизации. А главное, мы не зависли на этапе настройки и можем приступать к написанию автотестов.
Кейс: Глаза агентов. MCP для управления БД.
Проблема: Нам нужно получить данные из нескольких таблиц в бд, проанализировать данные или заполнить тестовые данные. Но мы устали описывать структуру таблиц для ассистента, копируя отдельные куски базы и подробно описывать какие таблицы и поля есть. Что делать?
Решение есть:
MCP (Model Context Protocol) — это протокол, который позволяет AI‑агентам взаимодействовать с внешними системами и инструментами (в нашем случае с БД). Например, если мы хотим управлять базой PostgreSQL напрямую прямо через чат агента. Для этого существует PostgreSQL MCP Server протокол, который позволяют агенту видеть приложение и управлять им. Это примерно, как глаза для агента, которыми он может заглядывать в БД без вашего участия.
Подключили MCP на базу и это дает нам возможность: прямо в агенте задавать вопросы что там происходит в нашей бд, позволяет агенту просматривать таблицы, поля, связи, выполнять CRUD операции (многие MCP серверы для БД работают в READ‑ONLY режиме для безопасности), создавать запросы на основе ваших требований.
Информацию по доступным MCP и как их подключать вы при желании легко найдете в интернете. Например, есть MCP для Gitlab, Chrome, MCP для БД и многие другие. MCP это мощный инструмент который ещё больше развязывает руки агентам и ускоряет работу. Что очень круто и удобно. Пробуем. Официальный репозиторий MCP серверов: github.com/modelcontextprotocol/servers
Результат: AI‑агент сам ходит в бд, может исследовать структуру таблиц, посмотреть какие поля есть в таблице, по запросу может сгенерировать сложные запросы и помогать в подготовке тестовых сценариев заполняя нужные таблицы по запросу. Экономия времени на работу с бд — значительная.
Помните: Вы должны быть уверенными пользователями пк чтобы случайно не разрешить агенту почистить пару ненужных таблиц. Пробуем только на тестовых базах с обезличенными данными.
Кейс: генерация Swagger документации
Проблема: Если предположить, что команда маленькая и некому писать Swagger документацию, то без актуальной Swagger документации авто тестировщику приходится изучать код или гадать по названиям эндпоинтов. При большом желании, мы можем делегировать создание документации агенту, при условии, если у вас есть доступ к проекту. Сомнительно, но всё же.
Обязательно используем Planning Mode: для анализа всей кодовой базы и планирования структуры документации.
Вар 1: Полная генерация Swagger с нуля
Что используем: Claude Code — Sonnet 4.5, Cursor Agent Mode или любой LLM‑ассистент с возможностью анализа кода
Проанализируй весь API проект и создай полную Swagger/OpenAPI документацию:
ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ:
— Покрытие всех эндпоинтов с подробными описаниями
— Примеры запросов и ответов для каждого метода
— Валидация схем данных (required поля, типы, ограничения)
— Описание статус‑кодов и возможных ошибок
— Группировка эндпоинтов по функциональности
— Аутентификация и авторизация
СТАНДАРТЫ:
— OpenAPI спецификация (поищи актуальную версию)
— Лучшие практики REST API документирования
— Понятные описания для разработчиков и тестировщиков
— Примеры для быстрого старта
— Добавляем ссылки на документацию, или прикладываем файл с документацией.
Создай профессиональную документацию. (Если нет развернутого сервиса, спрашиваем что нужно и как развернуть Ui для swagger с нуля)
Вар 2: Чистый Manual кейс
Проанализируй Swagger и напиши мне чек‑лист проверок для ручного тестирования, включая граничные значения и (расширять по потребностям)
Результат: Имеем на выходе готовую подробную и актуализированную документацию на основании кодовой базы, и уже в легкую можем писать автотесты. Не забываем перепроверять на реальных данных работу и тестируем документацию на соответствие требованиям документации. Но это вы и так знаете.
Кейс: GitLab CI/CD или как настроить .gitlab-ci.yml самому
Проблема: Есть рабочий.gitlab‑ci.yml который запускает все тесты после пуша кода в репозиторий. Я хочу чтобы у меня появилась возможность при запуске job автотестов в гитлабе выбрать запуск конкретного теста или класса. Проблема в том, что мы не девопсы и не понимаем, как писать yml файлы. Поэтому обращаемся к агенту:
Вар 1: Изменение yml и настройка GitLab
Задача: настроить.gitlab‑ci.yml для выборочного запуска автотестов.
Я хочу чтобы у меня появилась возможность при запуске автотестов в гитлабе, выбирать запуск конкретного теста, конкретного класса или конкретного пекеджа. Сейчас в гитлабе у меня настроен только запуск всех тестов
после пуша кода в ветку. Я хочу отдельный ручной способ запуска в интерфейсе гитлаба. Как это сделать, я не знаю, мне нужны инструкции. Проанализируй проект, если что‑то нужно уточнить спрашивай, подумай как можно это сделать. Потом сформируй документацию мануал в отдельном.md файле, как запустить тесты вручную.
Нужны варианты ручного запуска для:
— конкретного теста
— конкретного класса
— конкретного пакета
Сейчас есть только автозапуск всех тестов после пуша.
Проанализируй проект и предложи решение. Также проанализируй текущий.gitlab‑ci.yml, проверь его и предложи как можно улучшить.
Результат: Итого получено, полностью переписанный и усовершенствованный.gitlab‑ci.yml с картинками. Подробное руководство по ручному запуску автотестов в GitLab CI. Добавлены 5 новых manual job'ов. Проверен и сформирован рабочий.gitlab‑ci.yml.
По итогу погружение в настройки CI/CD инфраструктуры (что по сути работа девопсов, но всё же) из многодневного процесса гугления, превращается в быстрое получение рабочего решения.
Тайные знания: Как управлять другими приложениями через агентов
Что используем: Claude Code — Sonnet 4.5, Cursor Agent Mode или любой LLM‑ассистент с возможностью анализа кода
Если у какого‑то приложения нет готового MCP, но есть документация с api, то можно использовать агента, чтобы попробовать управлять этим приложением. Агенту можно передать персональный токен авторизации от приложения и, с помощью той же LLM, совместно составить промпт‑инструкцию, включающую запрос на написание скриптов по управлению приложением, описывая, что нужно сделать, и ссылаясь на документацию приложения. Агент сам найдёт документацию API и выполнит необходимое в рамках предоставленного API, если он это позволяет.
Для чего это тестировщику? Например, можно пробовать анализировать документацию в confluence или попробовать через агента создавать тест кейсы сразу в TMS. Тут сложность именно в создании самой инструкции и правильной настройки. Не всегда возможно получить те или иные данные или изменять что‑то удаленно. С некоторыми приложениями работает, с некоторыми нет. Пробуйте.
4. Тестирование API
Кейс: Авто генерация API тестов по Swagger документации
Проблема: Как быстро написать тесты если у вас красивый и подробный swagger? Писать каждый тест вручную — долго и нудно, попробуем упростить работу используя агента!
Напомню, что: Swagger(openApi) — это автоматически генерируемая документация на Api, ещё и с красивым UI, что очень удобно и функционально. Часто при тестировании Api мы руководствуемся именно ей. Когда документации не написано, за документацию принимается Swagger. Это де‑факто стандарт для проектирования, документирования и тестирования RESTful API
Шаг 1: Получаем Swagger JSON
Открываем UI вашего Swagger
Жмем ссылку на версию в шапке (обычно ведет на /swagger.json)
Копируем весь JSON код
Шаг 2: Готовим промпт
Возьми этот Swagger JSON: [вставляем код / файл] Напиши API тесты
Стек: Java + RestAssured + Junit5 + Allure
Требования:
Следуй best practices тестирования API
Добавь тесты безопасности (401, 403, валидация)
Используй параметризированные тесты где уместно
Проверяй структуру ответов и обязательные поля
Приоритет: читаемость и скорость выполнения
Структура как в примере:
@Test
public void testGetUser() {
given()
.header(«Authorization», «Bearer » + token)
.pathParam(«id», 123)
.when()
.get(«/users/{id}»)
.then()
.statusCode(200)
.body(«id», equalTo(123))
.body(«name», notNullValue());
}
Добавь тесты на:
— Позитивные сценарии (200)
— Негативные сценарии (400, 404)
— Авторизацию (401, 403)
— Валидацию полей ответа
— Граничные значения параметров
Группируй тесты по эндпоинтам в отдельные классы и для каждого контроллера создай отдельный пеккедж.
Начинай с эндпоинтов: /users, /auth, /products, сроко сначала пишем тесты на один эндпоинт, тест за тестом, по одному, с подтверждением от пользователя после каждого написанного теста. Я не хочу чтобы всё превратилось в кашу из тестов, поэтому мы будем двигаться по шагам, помни об этом.
Результат: зависит от качества и достоверности оформленной документации swagger. Если всё описано достаточно подробно, вы буквально получаете пачку готовых тестов на все описанные эндпоинты требующие минимальных переделок.
В реальности же, если описано плохо и скудно, вы как минимум получаете пачку заготовок, которые удобно переделывать просто, следуя по порядку.
В любом случае цикл из Подготовка — Генерация — Доработка требует значительно меньше времени чем раньше.
Важно: Хорошо работает для маленьких контрактов. Лучше вообще не просить сделать всю сразу, а четко выделять: сейчас пишем только на этот эндпоинт. Очень легко потерять контроль и получить огромное месиво из тестов, которое проще удалить чем разбираться в них. Начните с небольшого API, чтобы оценить качество генерации, затем масштабируйте на весь проект.
Кейс: Тестирование сложных API контрактов с большим количеством полей
Проблема: Рядовая задача тестировщика: нужно протестировать новый эндпоинт, POST запрос с пейлоадом на 50+ полей, (вложенные объекты, массивы). Если для позитивной проверки достаточно проверить отправку рабочего контракта, получить тело ответа и написать на ответ ассерты, то для проверки валидации и негативных сценариев это настоящий вызов.
Как было раньше: Изучаем документацию → создаем POJO модели → вручную пишем Builder'ы → вручную покрываем каждое поле тестами → проверяем валидацию → тестируем вложенные объекты. На всё уходит дни. И потом тоже самое повторяем для ответа. Что делаем теперь:
Вар 0: Неэффективный подход (НЕ делайте так)
Плохой промпт:
«У меня есть документация по полям, входная модель, пример ответа. Вот тексты/файлы/ссылки. Напиши автотесты на этот эндпоинт согласно best practices.»
Результат: Хаотичный неконтролируемый ад из тестов, дублирование проверок, нерабочий код, трата токенов. Нам такое не надо.
Вар 1: Нормальный подход - пошаговая декомпозиция
Начинаем с малых шагов от общего к частному. Делим задачу на маленькие контролируемые шаги. Модель делим на однотипные части. Делаем Generate POJO from JSON. Создаем базовую структуру пекеджей. При большом количестве вложенных полей рекомендуется создавать отдельные классы для каждого верхнеуровневого объекта, для большего контроля, так как после написания проверок на каждый вложенный объект, может получится бесконечный список, в котором мы никогда не разберемся по итогу.
Переключаемся в планирующий режим и просим:
Привет! Изучи API документацию: Вот моя документация: [ссылка/файл] Вот моя POJO модель: [адрес где лежит проект] Сделай простой анализ: 1. Какие поля обязательные, какие нет? 2. Раздели поля на группы (например: пользователь, контакты, настройки) 3. Покажи основные типы данных (строка, число, дата) 4. Если что-то непонятно - спрашивай Отвечай простым списком, без сложных терминов. После этого я дам новые инструкции что нужно сделать.
Результат: агент понял наш проект, прочитал документацию и требования на модель, держит в контексте что уже сделано и готов работать с текущими данными.
Начинаем двигаться от общего к частному:
Теперь напиши простые тесты на обязательные поля. Я использую: Java + RestAssured + Junit5 для API тестов Пиши код под этот стек. Задача: проверить, что API возвращает ошибку, когда мы не отправляем нужные поля. Объекты для проверки: - userInfo (обязательный) - contactDetails (обязательный) - preferences (необязательный) Пример как я хочу чтобы выглядел тест: [вставляете свой пример] Правила: - Один тест = одна проверка - Понятные названия тестов - Отдельный класс для каждого объекта - Пиши по 3-5 тестов, потом остановись и спроси "продолжать?" Начинай с userInfo.
Результат: у нас есть классы для каждого верхнеуровневого объекта контракта. У нас есть начальные тесты на проверку обязательности полей.
Если результат нас устраивает, то продолжаем расширять покрытие необходимыми проверками.
Спускаемся в рамках одного объекта на уровень ниже и просим писать тесты на вложенные поля.
Теперь напиши детальные тесты на поля внутри userInfo. Поля и их правила: (ориентируйся на документацию) - firstName: обязательное, строка, от 1 до 50 символов - lastName: обязательное, строка, от 1 до 50 символов - birthDate: необязательное, дата в формате YYYY-MM-DD Какие тесты нужны на каждое поле: 1. Отправляем пустое поле → должна быть ошибка 2. Отправляем слишком длинное значение → ошибка 3. Отправляем правильное значение → успех 4. Для даты: неправильный формат → ошибка 5. Расшить список проверок согласно бест практис и согласуй со мной. Пример ожидаемой ошибки: (сверяйся с документацией) [вставляете пример ответа с ошибкой] Пиши тесты по одному полю за раз: - Сначала все тесты на firstName - Потом все тесты на lastName - Потом все тесты на birthDate Формируй тесты блоками по 10 с подтверждение на продолжения от пользователя после каждого блока.
Результат: Если не следим за потоком тестов и дать подтверждение в формате “ я тебе доверяю, начинай работу“ — есть большая вероятность, что всё превратиться в месиво. При нормальном исходе мы получаем множественные заготовки, на тесты, которые нуждаются в минимальных правках. Лучший исход, это объемное покрытие рабочими тестами. Не забываем проверять написанные тесты!
Таким образом мы контролируемо можем точечно покрывать участки контракта тестами при помощи LLM, сразу проверяя работу, дополняя проверками на ожидаемый результат. В случае если LLM начнет неконтролируемо строчить кучу псевдотестов, мы всегда сможем её затормозить. Пока это лучший подход, который работает на больших моделях у меня.
Вывод: В данном кейсе экономия 20–30% времени на создании заготовок. На больших моделях очень много вариаций кейсов и ответов, которые зачастую нигде не описаны и нуждаются анализе и доработках. Поэтому приходится вручную дописывать проверки на различные кейсы. Но при правильной декомпозиции проверяемой модели, мы можем эффективно делить проверки на блоки и делать множество заготовок кейсов, которые уже можно легко дорабатывать. Но всё же часть ручной рутины это снимает, а это уже хорошо. Вся точность упирается в подробность и точность документации, а мы знаем, что и документацию нужно тестировать.
LLM не заменяет экспертизу тестировщика, но значительно ускоряет создание базового покрытия сложных контрактов. Путь к успеху — правильная декомпозиция и пошаговый контроль процесса.
5. Тестирование UI
Кейс: Завернуть UI тест в Page Object
Проблема: Часто бывает, что мы быстро набрасываем автотест, не думая про крастоту или паттерны, главное запустить, отладить до стабильного состояния, а потом уже можно наводить красоту. Вот у нас огромное полотно из смешанных вызовов, селекторов, всё копируется по многу раз. Мы хотим в проекте UI автотестов, отрефакторить тест согласно паттерну Page Object? скрыв всё лишнее в соответствующем Page. Руками это делать довольно долго и нудно, поэтому мы используем llm.
Завернуть UI тест в Page Object
Если тест большой (например длинный E2E), где множество страниц и переходов, то в лоб просить сетку красиво отрефакторить, приведет к неконтролируемому написанию множества кусочков методов по непонятной логике со сложными группировками и неймингом. Это плохой путь.
Лучше делить задачу на блоки, например по тем же Page которые мы проходим. Если у нас есть страница ввода карты, авторизации, то стоит ограничить запросы на рефакторинг одним блоком. Потом регистрация и уже ввод карты и так далее Так и контролировать процесс легче, и нейросеть легче направлять.
Переключаемся в режим планирования Shift + Tab
Проблема: У меня есть степы UI теста, она не оптимизированные, просто простыня селекторов и проверок. я хочу отрефакторить это всё в красивый педж обжект. Проанализируй мой код, и предложи варианты как ты можешь завернуть всё в этот паттерн. Учитывай уже созданные мной пейджы. Не перегружай текущий функционал. Работай только в рамках этого пакета {пекедж нейм} Задача: возьми мой UI автотест {адрес теста}, и проведи рефакторинг, скрыв лишние элементы согласно паттерну Page Object. В качестве примера можешь взять уже готовый описанный как мне нужно тест: {адрес примера теста} Создай все необходимые классы нужного Page, если они не созданы. Заворачивай однотипные блоки в Step для подробного отображения в Allure отчетах. Вынеси все селекторы в отдельные переменные.Сформируй компактные блоки для повторяющегося функционала. Если необходимо объединяй малые блоки в большие. Везде добавляй логирование достаточное для понимания что происходит. Если ты видишь как еще можно оптимизировать тест расскажи мне. Если есть вопросы спрашивай. Спланируй план работ и делай только после моего подтверждения. Если мы рефакторим в рамках класса, то можно добавить общие рекомендации: Подсвети моменты где мы можем переиспользовать блок в других тестах и проверяй на дубли. {тут можно сужать работы до контролируемых в рамках небольших кусков кода и указать: Я хочу чтобы сначала ты отрефакторил вот эту часть кода {вставить нужную часть кода} (где например блок ввода карты)), а после, после моего согласия, приступал к другим частям.}
Что ещё хорошо рефакторить: какие‑то отдельные селекторы, на которых не было обертки. {Проанализируй код на наличие селекторов без обертки и оберни их в метод, согласно бест практис написания UI автотестов под паттерн Page Object.
Результат: При правильном подходе, мы значительно экономим время на рефакторинге UI автотестов, и точечно подгоняем тесты под единый паттерн. Польза значительная. Мой пример: До: 12 блоков × 5 строк = 60 строк дублированного кода. После: 12 блоков × 1 строка = 12 строк + 2 метода в Page Object. Сокращение кода: ~80% в тестовых методах.
Кейс: Простой способ написать селектор
Проблема: Что самое главное в написании UI‑тестов? Выбор стабильного селектора. Наверное, это главный геморрой всех UI‑тестов — выбор селекторов. Как же сделать это быстро с помощью LLM, если test‑id вы видели только в статьях по тестированию, а учить и вспоминать, как писать скобки и точки в DevTools, чтобы найти заветный путь к элементу, вам уже порядком надоело?
Что можно делать?
Открываем девтулс — находим нужный элемент и в дом дереве поднимаясь на несколько уровней вложенности выше, прямо из девтулса правой кнопкой — Copy — Copy elements. Так мы копируем кусок html с нужным элементом. Просим LLM искать устойчивые атрибуты (data‑testid, id, уникальные тексты) и избегать привязки к иерархии div> div > span по возможности.
Вставляем скопированный элемент в чат и пишем: напиши мне селектор на элемент. Добавь проверки текста. Я использую библиотеку selenide. Выведи мне нужный код.
Результат: Да, это может быть странно и нестабильно. Как же так, нужно же написать оптимальный селектор… да, если у тебя есть на это время. Таким же способом, можно накидать достаточно объемный e2e тест за короткое время. Главное он будет работать и проверять! А отладкой можно заняться, когда будет на это время.
Кейс: технологии будущего или как писать UI тесты через агента
А что если я хочу заставить агента писать e2e UI автотесты? На это есть последняя и современная библиотека Playwright (это современный фреймворк с открытым исходным кодом от Microsoft, предназначенный для автоматизации тестирования и взаимодействия с веб‑приложениями.)
Так вот у него уже есть Playwright MCP server. А как мы знаем MCP — это как глаза у агента. И вот мы даем агенту глаза и руль для управления браузером и просим проанализировать страницу и написать на неё e2e тест.
Подробнее об этом я расскажу в следующей статье. Просто знайте, что это возможно уже сейчас.
Заключение
Не стоит ожидать, что пока ты пьешь кофе, то нейросети сами сделают всю работу (пока что) Это не решатель всех проблем, а всего лишь инструмент.
Если вы не понимать принципы и подходы области тестирования где мы применяем агентов, то нейросеть наспамит неподдерживаемую простыню кода в которой вы сами потом и утонете. Но если вы знаете базу и понимаете, чего хотите, то агенты (Claude, Cursor и ко) становятся по настоящему полезным помощником, который заберет на себя часть рутины.
Не бойтесь делегировать рутинную работу нейросетям. На текущем этапе развития сетей не забывайте внимательно проверять их работу. Доверяйте, но проверяйте. Пробуйте, ищите новые кейсы, делитесь с коллегами, помогайте развивать индустрию. (может это зачтется, когда ASI будет составлять список кого оставить наградить)
Удачи в экспериментах!
