CheckMateDB в РСХБ: как мы автоматизируем автотесты на Java (и почему это не заменяет автоматизаторов)

Меня зовут Михаил Герасимов, я главный инженер команды автоматизации тестирования в РСХБ.Цифра. Наш основной фокус — регрессионные автотесты на Java.

Эта публикация — первая в серии статей про CheckMateDB. Здесь мы сделаем быстрый, но технически предметный обзор продукта: что уже работает, какие задачи он закрывает и как мы его развиваем. В следующих статьях разберем отдельные части подробнее: архитектуру модулей, ML‑контур генерации кода, практику внедрения и метрики качества

Если коротко, то наша ежедневная реальность выглядит так: ручные тестировщики пишут сценарии в TestIT, а автоматизаторы превращают их в код. Звучит просто, но на масштабе регресса очень быстро проявляется bottleneck: между тест‑кейсом и готовым автотестом лежит большой слой однотипной инженерной рутины. Где‑то нужно аккуратно собрать тестовые данные, где‑то написать Criteria, где‑то выстроить PageHelper‑цепочку, где‑то допилить проверки и стабилизировать прогон. Иногда кажется, что половина автотеста уже написана… просто в 17 разных местах и в разное время.

Расскажу, как мы в команде закрываем этот разрыв с помощью CheckMateDB и почему развиваем его как единую точку входа для автоматизированного тестирования: от данных и SQL‑аналитики до AI‑генерации кода и управляемого применения изменений.

Рис. 1. CheckMateDB как единая точка входа для автоматизированного тестирования

Откуда проблема?

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

Типовой поток выглядит так:

1. Ручной тестировщик формулирует сценарий в TestIT (предусловия, шаги, ожидаемый результат);

2. Автоматизатор декомпозирует сценарий на технические операции;

3. Подбирает тестовые данные через Criteria‑слой (часто с несколькими ограничениями по статусам, филиалам, ролям, датам и связями с другими таблицами);(Можно почитать тут)

4. Собирает UI/бизнес‑цепочку через PageHelper и операции формы;

5. Добавляет проверочный слой (Assertions, верификация записи в БД/модели)(Можно почитать тут);

6. Оформляет тест под TestNG и TestIT‑интеграцию;

7. Стабилизирует прогон под конкретное окружение (данные, роли, конкуренция с параллельными тестами).

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

Иногда это выглядит так: сначала 20 минут пишем полезную логику, потом 2 часа убеждаем стенд, что мы с ним друзья.

Как это выглядит в коде:

1. Поиск тестовых данных(упрощенный пример):

   @Step("Подготовка тестовых данных")
   private DtoR2Loan prepareTestData() {
       return new CriteriaR2Loan()
               .withKindCredEqual(R2KindCred.$CRED_09_A)
               .withStatusEqual(ComStatusPrd.$WAIT_CONF)
               .withBranchIn(DepartUtils.getBranchArrayByDefault())
               .getRandomObjectWithError(7);
   }
   

2. Воздействие на тестовые данные:

   loan = editLoanHelper
           .execute()
           .goTabCoBorrower()
           .setCoBorrower(coBorrower)
           .clickButtonAdd()
           .returnOnMainTab()
           .clickOk()
           .getObject();
   

3. Проверки:

AssertionsUtil.assertThat(loan)
                .goToR2CodebtorInfoAssert()
                .containsEntryInArray(coBorrower);

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

Рис. 2 Ручной пайплайн от TestIT до регрессионного прогона

Что такое CheckMateDB?

CheckMateDB — это модульная инженерная платформа с явным разделением ответственности между слоями:

• слой подключения и сессионного контекста;

• слой работы с данными и метаданными;

• слой генерации кода (классический и AI‑driven);

• слой валидации и контролируемого применения изменений.

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

1) Reference + Connection Layer

Технически это входной инфраструктурный слой, который решает 3 важные задачи:

a) Управление профилями подключений

• CRUD профилей БД пользователя;

• валидация параметров (host, port, db, username, databaseType);

• проверка доступности перед сохранением;

• ownership‑модель доступа (пользователь работает только со своими конфигами).

b) Активация профиля БД в HTTP‑сессии

После активации профиля формируется session‑scoped connection context, который используют:

• SQL‑консоль;

• Table View/metadata;

• CodeGen/Agent пайплайн.

Это важно, потому что генерация тестового кода без «живого» контекста БД почти всегда приводит к рассинхрону между кодом и реальными данными.

c) Безопасная точка входа для остальных модулей

Reference‑layer фактически играет роль «control plane»:

• проверяет, что есть валидное активное подключение;

• отдает нормализованный bootstrap‑контекст в UI;

• снижает риск «плавающих» ошибок в downstream‑модулях.

Проще говоря: пока connection layer не в порядке, остальная платформа работает в режиме «не лечим симптомы, лечим причину».

Почему это важно для регресса

В регрессионном контуре нестабильные подключения и «кривой» контекст — это одна из причин каскадных проблем:

• тесты начинают падать «не по бизнесу»;

• генерация кода получает неверные метаданные;

• команда тратит время на ложные дефекты.

Поэтому у нас правило простое:

Сначала валидный connection context, потом генерация и прогоны.

Да, звучит не так романтично, как «AI написал все сам», зато намного ближе к production.

Скрытый текст

Платформа в целом умная, но если дать ей неправильный host— даже самая сильная LLM не пробросит кабель до сервера.

Рис. 3. Reference‑модуль и активное подключение (Скрин из /reference: список профилей, активный профиль, статус подключения, кнопки управления)

2) SQL Console

SQL‑консоль в CheckMateDB — прикладной инструмент для работы с данными в регрессе.

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

• запуск: POST /api/sql-console/execute;

• опрос статуса: GET /api/sql-console/status/{executionId};

• получение результата порциями: GET /api/sql-console/result/{executionId}?offset=&limit=;

• принудительная остановка: POST /api/sql-console/cancel/{executionId}.

Такой подход нужен, чтобы длинные запросы не блокировали UI и не «клали» пользовательскую сессию. Отдельно поддерживаются диагностические и инженерные сценарии:

• EXPLAIN для анализа плана запроса;

• получение DDL и metadata (schemas/tables/views/columns);

• экспорт результатов в CSV/JSON/XLSX;

• история запросов (с фильтрацией и очисткой по периодам);

• избранное и snippets (CRUD для повторного использования SQL);

Почему это важно для регрессионных автотестов: генерация кода без надежного data‑access слоя почти всегда превращается в угадывание.
SQL Console дает проверяемый источник истины по данным, схеме и реальному поведению запросов — а это значит, что снижает количество ложных проблем в автотестах.

Иногда лучший bugfix начинается не с «поправим PageHelper», а с честного EXPLAIN.

Рис. 4. SQL Console: выполнение и результат запроса
(Скрин из /sql-console)

3) Table View + Query API

Table View + Query API — это слой быстрой работы с данными без ручного написания сложного SQL.

Ключевые возможности:

• фильтрация с подгрузкой данных порциями (lazy loading);

• работа со связями через join‑деревья;

• preview SQL перед выполнением;

• сохранение и восстановление состояния запроса.

Для регресса это важно, потому что ускоряет проверку данных и диагностику падений.

Отдельно отмечу: этот функционал мы развиваем в сторону нетехнических пользователей, чтобы с данными можно было работать через понятный интерфейс, без глубокого знания SQL и внутренней структуры БД.

Рис. 5. Table View: фильтры

4) Classic CodeGen

Classic CodeGen — это детерминированный генератор базовых артефактов автотестов, без «магии» и с предсказуемым результатом. Такой подход стал возможным благодаря нашей библиотеки query-criteria-builder(о ней вы могли читать ранее), которая унифицировала стиль работы с запросами и подготовкой данных.

Что генерируем:

• Entity/DTO;

• Table;

• Assert и AssertList.

• Criteria

Технически пайплайн выглядит так:

1. берем активное подключение из сессии;

2. загружаем dbMetadata по таблице (колонки, типы, ключи);

3. нормализуем входные параметры (schema/table/package);

4. маппим SQL‑типы в Java‑типы с учетом диалекта;

5. генерируем код через профильный генератор;

6. возвращаем результат в UI для проверки и применения.

Поддерживается основной контур, на котором у нас идет регресс PostgreSQL.

Почему этот модуль важен:
он дает «надежный фундамент» для дальнейшей AI‑генерации — сначала стабильный каркас, потом интеллектуальная доработка.

Иногда самый полезный AI — это тот, который пока не нужен, потому что детерминированный генератор уже сделал все как надо.

Рис. 6. Генерация Entity

Рис. 7. Генерация Assert

5) Tools AI (ai_module)

Tools AI — это прикладной AI‑control plane внутри CheckMateDB.

Что делает модуль технически:

• управляет модельными конфигурациями (CRUD) с привязкой к пользователю;

• хранит и использует активное подключение к модели в контексте HTTP‑сессии;

• поддерживает стриминг ответов через SSE (token/error/done);

• дает принудительную остановку генерации (cancel) для долгих/неудачных запросов;

• отдает диагностику активной модели и подключения;

• предоставляет единый AI Gateway для остальных модулей (workspace, codegen, дальнейшие интеграции).

Ключевые инженерные моменты:

1. Provider abstraction
   Есть единый интерфейс вызова модели и маршрутизация к провайдеру (локальные и OpenAI‑compatible сценарии).

2. Session‑scoped connection state
   Пользователь выбирает модель один раз, дальше модули платформы работают через единый активный контекст в сессии.

3. Безопасность конфигураций
   Модельные настройки разделены по владельцу, API‑ключи хранятся в шифрованном виде.

4. Управляемая конкуренция и стабильность стрима
   SSE‑ответы идут в отдельном execution‑контуре, есть ограничения на параллелизм и корректный cleanup при timeout/disconnect.

5. Единая точка интеграции
   Вместо «каждый модуль напрямую ходит в свою модель» — один gateway и единые правила валидации/обработки ошибок.

   Это важно, потому что Tools AI превращает LLM из «внешнего сервиса по вызову» в управляемый инфраструктурный слой платформы.

Раньше модель была «гостем в системе», теперь — «сотрудником по пропуску».

Рис. 8. Tools AI: конфиги и диагностика

6) Codegen Workspace Agent (codegen_workspace_module)

Codegen Workspace Agent — это центральный runtime‑контур генерации кода в CheckMateDB: здесь AI работает не «в вакууме», а в контексте реального проекта и архитектурных ограничений.

Что есть на уровне модуля:

• работа с локальным проектом (выбор, чтение, редактирование файлов);

• обычный AI‑chat и mode‑driven запуск агента;

• управляемый pipeline: INIT -> CONTEXT -> GENERATE -> VALIDATE -> APPLY;

• preview изменений с ручным подтверждением apply;

• история запусков, загрузка прошлого запуска и rerun.

Рис. 9. Codegen Workspace Agent: pipeline выполнения и этап ручного Apply

Технически это реализовано через набор endpoint‑ов:

• /codegen/workspace/session-state — сохранение/восстановление состояния workspace;

• /codegen/workspace/ai/connection и /codegen/workspace/ai/generate — chat‑режим;

• /codegen/workspace/agent/v1/run — запуск оркестратора;

• /codegen/workspace/agent/v1/history — история запусков;

• /codegen/workspace/agent/v1/db-metadata — автозагрузка dbMetadata из активной SQL‑сессии.

Внутри оркестратора работают отдельные технические компоненты:

1. Prompt Profile Registry — выбор профиля под режим генерации.

2. Context Tooling — сбор project hints, target paths, class context.

3. Response Parser — разбор structured output модели.

4. Guardrails Validator — валидация пути, action, package/path consistency, размеров и синтаксиса.

5. Repair Loop — повтор генерации при невалидном ответе.

6. Merge Service — аккуратный update существующих классов, если target уже есть.

Отдельно важно: apply остается human‑in‑the‑loop, то есть даже при успешной генерации изменения сначала попадают в preview и только потом применяются.

Агент у нас умный, но в прод все равно заходит через «покажи diff».

Рис. 9. Codegen Workspace

Как планируем внедрять fine‑tuning

На текущем этапе мы не дообучаем базовые LLM. В проде работает связка:

• RAG по проектному и доменному контексту;

• prompt orchestration по режимам/профилям;

• guardrails validation на структурированный результат;

• repair‑loop при невалидном ответе;

• human‑in‑the‑loop перед apply.

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

Fine‑tuning для нас — следующий этап зрелости, но по инженерным правилам.

1. Capability taxonomy
   Разделяем задачи на четкие capability:
   GenerateEntity, GenerateTable, GenerateAssert, GenerateFullAutoTestFromTestIT, RefactorExistingAutoTest.

2. Data пайплайн
   Тренировочный корпус формируем из:

   • подтвержденных инженером патчей,

   • неуспешных кейсов (валидационные сбои/откаты),

   • доменных шаблонов библиотеки.

3. Data governance
   Маскирование чувствительных данных, versioning датасетов, traceability источников, строгий split train/val/test.

4. Обучение на контракт
   Цель — воспроизводимый формат:
   task + context -> plan + files[] + checks.

5. PEFT‑first стратегия
   Старт через LoRA/QLoRA: быстрее, дешевле, проще rollout/rollback.

6. Eval до выката
   Метрики инженерного качества: compile‑pass, guardrail violations, post‑edit distance, success rate по capability, latency/cost per success.

7. Shadow + Canary rollout
   Сначала shadow, затем поэтапный rollout с автокатом при деградации.

8. Continuous learning loop
   Feedback от автоматизаторов → обновление датасета → повторный eval → controlled release.

Fine‑tuning у нас должен усилить существующую архитектуру.

7) Отдельная библиотека автотестов

Отдельно от web‑приложения у нас есть бибилиотека для построения фреймворка для написания авто тестов вокруг нее.(Можно почитать тут: https://habr.com/ru/companies/rshb/articles/779150/ )

Библиотека включает:

• Criteria‑слой для параметризованного отбора тестовых данных;

• Dto / Table‑модели как унифицированное представление данных;

• Assert‑слой для проверок и постусловий;

• интеграцию с TestNG, Allure, TestIT.

Технически это важно по двум причинам:

1. Единый контракт исполнения
   Генерация кода в платформе ориентируется на стабильный API библиотеки, поэтому результат предсказуемо встраивается в существующий тестовый контур.

2. Снижение вариативности в регрессе
   За счет унифицированных паттернов (Criteria -> PageHelper -> Assert) уменьшается «разнобой» реализации между тестами и упрощается сопровождение.

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

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

8) Интеграция с TestIT и Jenkins

Важный контур в CheckMateDB — интеграция с TestIT и CI, чтобы автоматизатор видел не только код, но и полный жизненный цикл автотеста после запуска.

Что дает этот блок на практике:

• просмотр результатов выполнения автотеста (pass/fail/skip);

  

  Рис. 10. Результаты выполнения авто тестов в прогоне

• отображение статуса прогона в Jenkins (running/complete/failed/aborted);

  

  Рис. 11. Запуски наборов тестов

• быстрые переходы в TestIT:

  • тест‑кейс,

    

    Рис. 12. Тест кейс из TestIT

  • автотест,

  • тест‑ран,

  • связанные артефакты;

  

  Рис. 13. Функционал

• переходы в Jenkins/Allure по deep‑link;

• служебные операции: синхронизация атрибутов, фильтрация по autoTestId/@externalId, групповые действия по прогонам.

Технически это работает как корреляционный слой между несколькими системами.
Мы связываем сущности по ключам:

• autoTestId,

• autoTestExternalId,

• testRunId,

• buildNumber,

• branch/commitSha.

За счет этого в одном интерфейсе видно: какой тест запущен, где именно упал, и куда идти разбираться — в TestIT, Jenkins или отчетный артефакт.

Минимальный flow:

1. Jenkins запускает регрессионный набор.

2. Результаты отправляются/синхронизируются с TestIT.

3. CheckMateDB подтягивает статусы и метаданные прогона.

4. Пользователь в одном месте получает статус, ссылки и действия.

Куда идем дальше с CheckMateDB?

Планируем построить capability‑платформу с явным контуром:

• capability layer (генерация/рефакторинг/самовосстановление);

• model router + policy engine (quality/latency/cost);

• safety layer (guardrails + apply gate);

• eval/ops layer (benchmark + telemetry + canary).

Рис. 14. Целевая архитектура развития CheckMateDB

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

В начале года Дарио Амодеи (CEO Anthropic) озвучил тезис:

Сначала исчезнет написание кода, а затем и вся разработка

И тут начинается самое интересное. В чем же парадокс?

По открытым данным у той же Anthropic — сотни вакансий для инженеров

Скрытый текст

В нашем черновом расчете: около 454 позиций с высокими компенсациями

То есть «ручного кода» становится меньше, а спрос на сильных инженеров — не падает.

Роль инженера сдвигается:

• меньше «исполнителя»;

• больше архитектора пайплайна;

• больше редактора и валидатора результата ИИ;

• больше владельца качества и рисков.

В нашем контексте в команде мы видим ровно это же:
автогенерация ускоряет выпуск регресса, но ответственность за корректность остается у автоматизатора.

Когда разработка дешевеет, растет количество задач, которые становится выгодно автоматизировать.

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

Такое уже было:

• компиляторы после ассемблера;

• фреймворки после boilerplate;

• облака после ручного управления серверами.

Каждый раз звучал прогноз:

Программисты больше не понадобятся

И каждый раз в итоге рос и рынок, и роль инженера.

Цифры, которые поддерживают тренд

• 2010: ~5 млн разработчиков в мире

• 2025: ~28,7 млн

• 2030 (прогноз): ~45 млн

• BLS: +17% до 2033 года (около 304k новых рабочих мест)

Практический вывод простой:
CheckMateDB — про рост инженерной мощности автоматизаторов.