عرضت Sber كيف يحوّل RAG وLLM داخل IDE السيناريوهات اليدوية إلى اختبارات آلية

Сбер показал, как можно сократить одну из самых рутинных задач в QA: превращать ручные сценарии в автотесты прямо в IDE. В основе — связка LLM и RAG, которая не просто пишет код, а сначала ищет релевантные примеры в самом проекте, чтобы сохранить его стиль, соглашения и архитектуру.

Почему прямой промпт не работает

Идея «просто отправить ручной тест в модель и получить готовый код» на практике ломается о детали. LLM действительно может собрать рабочий Java-тест, но почти наверняка сделает это не так, как принято в конкретной команде: забудет про Allure, нарушит схему именования, положит URL и тело запроса не туда, добавит лишние проверки или не использует внутренние утилиты вроде общего метода проверки статуса. Для тестовой автоматизации это не косметика, а реальная потеря совместимости с проектом.

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

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

Как работает RAG

Вместо статичного few-shot с вручную подобранными примерами команда Сбера сделала плагин для JetBrains IDE. Он сканирует проект через PSI-структуру, а не как сырой текст, поэтому видит классы, методы, аннотации и вызовы. На этой базе система собирает Allure-шаги, существующие автотесты, их TMS-ключи, код и краткие текстовые описания.

Дальше эти описания превращаются в эмбеддинги и сохраняются вместе с метаданными в локальную базу знаний или векторное хранилище. Когда в работу приходит новый ручной сценарий, система проходит несколько этапов: выделяет действие и ожидаемый результат для каждого шага; строит несколько смысловых вариантов запроса для поиска похожих шагов; просит LLM кратко описать весь тест, чтобы найти близкий автотест по смыслу; автоматически подставляет найденные примеры в промпт вместо ручного few-shot; * проверяет результат повторным запросом к модели и через PSI внутри IDE. Такой подход позволяет получать код, который выглядит так, будто его писал человек из этой команды, а не внешняя модель без контекста.

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

RAG — это few-shot, который сам находит нужные примеры.

Результаты прототипа По данным команды, внутренний прототип уже дал измеримый эффект.

Около 68% сгенерированных тестов оказались на приемлемом уровне и требовали лишь минимальных правок, а общая удовлетворённость пользователей составила примерно 80%. Лучше всего инструмент показал себя на простых и похожих API-сценариях, где особенно важно быстро воспроизводить устоявшийся шаблон кода без ручного копирования из соседних тестов. Автоматизаторы также отметили снижение когнитивной нагрузки: меньше времени уходит на рутину, больше — на сложные сценарии и архитектурные решения.

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

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

Что это значит

Для AI-инструментов в разработке начинается более интересный этап: ценность смещается от «сгенерировать любой код» к «сгенерировать код, который сразу встраивается в живой проект». История со Сбером показывает, что в QA выиграют не те команды, которые просто подключат LLM к IDE, а те, кто обернёт модель вокруг собственной базы знаний, проверок и инженерных правил.