ИИ-тестирование в 1С: как проверить код, который написала нейросеть

ИИ-тестирование в 1С: как проверить код, который написала нейросеть

Нейросеть уже умеет быстро писать код на встроенном языке 1С: процедуры, запросы, обработчики форм, HTTP-сервисы, черновики автотестов и даже пояснения к доработке. Для разработчика это выглядит как резкий прирост скорости. Задача сформулирована, через несколько секунд на экране уже аккуратный модуль с понятными именами переменных, комментариями и обработкой ошибок.

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

Именно поэтому ИИ-тестирование в 1С стоит понимать не как "нейросеть сама себя проверила", а как инженерный контур вокруг ИИ-кода. Модель может помогать, но принимать результат нужно только после проверки.

Почему 1С - особый случай

В обычной разработке ошибка нейросети часто сводится к неверному API, неправильной сигнатуре функции или устаревшему способу вызова. В 1С добавляется более опасный слой: код почти всегда связан с конкретной прикладной моделью.

Даже небольшой фрагмент может зависеть от документов, справочников, регистров, табличных частей, ролей, РЛС, расширений, функциональных опций, клиент-серверного контекста и версии типовой конфигурации. Когда модель пишет строку кода, она одновременно делает набор скрытых утверждений:

• такой объект метаданных существует;
• у него есть нужный реквизит;
• реквизит имеет подходящий тип;
• общий модуль доступен в нужном контексте;
• запрос обращается к правильному регистру;
• бизнес-правило понято корректно;
• пользователь имеет право выполнить операцию.

Если модель не знает реальную конфигурацию, она начинает достраивать недостающие факты по вероятности. Так появляются правдоподобные, но несуществующие регистры вроде ТоварыНаСкладах, реквизиты вроде ДоговорКонтрагента там, где в базе используется Соглашение, или код запроса в клиентском обработчике формы.

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

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

Синтаксис не равен качеству

Бенчмарки по 1С-коду хорошо отрезвляют. В материалах вебинара приводится 1C Code Bench: специализированный набор задач для оценки языковых моделей на 1С-разработке. Проверка там разделяется на два слоя: проходит ли решение базовый технический фильтр и корректно ли оно решает задачу.

По приведенным данным сильные модели проходят синтаксическую проверку примерно на уровне 74-77%, а корректность находится примерно в диапазоне 47-52%. Конкретные места в лидерборде будут меняться, но сам разрыв важен: модель уже умеет писать текст, похожий на 1С-код, но это не означает, что она правильно решила задачу.

Для команды это означает простую вещь: проверка ИИ-кода не может заканчиваться на "код запускается". Синтаксис - только первый барьер. После него остаются метаданные, бизнес-логика, права, производительность, транзакции, сопровождение и регрессия.

Что именно нужно проверять

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

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

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

Особенно важен тестовый оракул: источник, который говорит, какой результат считается правильным. В 1С оракул часто неочевиден. Что значит "правильно проверить остатки"? Нужно ли учитывать резерв, характеристику, серию, склад, организацию, дату документа, старые движения при перепроведении, настройки учетной политики и права пользователя?

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

Типовые ловушки ИИ-кода в 1С

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

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

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

Четвертая - регистры и движения. Здесь ошибка особенно опасна: неправильная аналитика, неочищенные старые движения, задвоение при перепроведении, неверная дата движения или отсутствие контроля транзакции могут испортить учетные данные.

Пятая - права и РЛС. Часто код проверяют под полными правами, а потом он падает у обычного пользователя или показывает данные, которые пользователь видеть не должен.

Шестая - производительность. Модель легко пишет запрос в цикле, выборку без отбора или загрузку большого объема данных в память. На демобазе это незаметно, в рабочей базе превращается в тормоза и блокировки.

Хороший пример разрыва между синтаксисом и смыслом - скидка. Требование: VIP-скидка 10% при сумме строго больше 100 000, максимум 15 000. Модель пишет условие Сумма >= 100000 и считает Сумма * 0.1 без ограничения сверху. Компилятор молчит. Ошибку ловят только тесты на границу и лимит.

Проверка должна зависеть от риска

Не все изменения одинаково опасны. Исправление текста подсказки на форме и изменение проведения документа не должны проходить один и тот же процесс. Для ИИ-кода особенно полезна риск-ориентированная модель:

Риск = вероятность дефекта * ущерб от проявления

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

Самые чувствительные зоны для ИИ-кода в 1С:

• движения регистров;
• массовая запись данных;
• привилегированный режим;
• обмены с внешними системами;
• права и РЛС;
• зарплата, кадры, налоги;
• закрытие периода;
• персональные данные.

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

Пирамида проверки ИИ-кода

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

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

Второй слой - предположения. Хорошая практика: просить модель перед кодом перечислить, что она считает истинным о конфигурации. Например: "документ называется ЗаказКлиента, табличная часть Товары, остатки берем из регистра СвободныеОстатки, проверка выполняется при проведении". Эти утверждения нужно подтвердить фактами.

Третий слой - метаданные и синтаксис. Здесь нужны автоматические проверки: существуют ли объекты, реквизиты и табличные части, доступен ли модуль в нужном контексте, проходит ли код синтаксический контроль.

Четвертый слой - тесты. Модульные тесты хорошо подходят для изолированной логики: расчет скидки, валидация данных, преобразование структур. Интеграционные тесты нужны для документов, регистров, движений, обменов и работы с реальными объектами конфигурации. Сценарные тесты проверяют путь пользователя: открыть форму, заполнить поля, нажать команду, получить результат.

Пятый слой - ревью и приемка. Здесь человек проверяет смысл, архитектуру, риски и готовность к выпуску.

Как ИИ может помогать тестированию

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

Например, перед написанием кода можно попросить модель не сразу генерировать процедуру, а сначала предложить сценарии проверки:

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

Такой список помогает увидеть, что задача шире одного фрагмента кода.

Но есть граница. Нельзя полностью отдавать ИИ финальный оракул, приемку риска, бизнес-смысл и production-решение. Если модель неверно поняла правило, она может написать и код, и тесты под одну и ту же неверную гипотезу. Внешне все будет красиво: тесты зеленые, логика согласована, но проверяется не то поведение.

Инструменты: факты вместо догадок

Чтобы агент был полезен в 1С-разработке, ему мало уметь писать текст. Ему нужны факты: структура конфигурации, результаты синтаксической проверки, ошибки тестов, логи, данные о метаданных и отчет о регрессии.

Здесь появляется роль MCP и тестовых контуров вроде METR. MCP дает агенту контролируемый доступ к инструментам: получить метаданные, запустить синтаксическую проверку, выполнить тесты, прочитать результат. METR в такой схеме выступает как тест-раннер для 1С:Enterprise, который может запускать проверки без ручных шагов.

При этом важно не переоценивать инструмент. MCP не делает модель правой. Он дает ей доступ к фактам. Качество результата зависит от того, какие вопросы агент задает и кто интерпретирует ответ.

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

• 1C:EDT или конфигуратор - синтаксис, сборка, проверка проекта;
• статический анализ - стандарты, сложность, подозрительные места, клиент-серверные нарушения;
• проверка метаданных - существование объектов, реквизитов, табличных частей и типов;
• YaXUnit - быстрые модульные тесты;
• Vanessa Automation - сценарные и UI-проверки;
• CI/CD - воспроизводимый запуск проверок и регрессии.

Хороший отчет проверки должен показывать не только "успешно" или "ошибка", а границы доверия. Например: "Синтаксис пройден, модульные тесты 38 из 38, интеграционные 12 из 12, UI-сценарии не запускались, производительность не проверялась". Такой отчет честнее, чем общее "все хорошо".

Роль человека

Автоматизация не убирает человека из процесса. Она убирает часть рутины, но не снимает ответственность за смысл. Человек утверждает критерии приемки, проверяет тестовый оракул, оценивает архитектурное место изменения, принимает остаточный риск и решает, можно ли выпускать код.

Ревью ИИ-кода отличается от обычного ревью. Помимо качества кода нужно спрашивать: какие предположения модель сделала без доказательств?

Например, модель добавила расчет скидки в модуль формы, потому что задача звучала "при изменении суммы пересчитать скидку". Код работает, тест формы проходит. Но архитектор видит, что это бизнес-правило должно жить в общем серверном модуле, потому что используется не только в форме, но и в загрузке заказов, мобильном рабочем месте и внешнем API.

Автотест может не знать архитектурную стратегию проекта. Человек обязан ее удерживать.

Еще одна обязанность человека - проверять тесты, написанные ИИ. Тесты не становятся правильными только потому, что они тесты. Если модель неправильно поняла бизнес-правило, она легко сгенерирует аккуратный тест под неправильное ожидание.

Что можно сделать уже завтра

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

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

Второе: просить тест-кейсы до кода. Сначала позитивные, негативные и граничные сценарии, потом реализация.

Третье: проверять метаданные до дорогих тестов. Если объект или реквизит не существует, нет смысла обсуждать архитектуру большого фрагмента.

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

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

Самое простое правило можно сформулировать так: ни один фрагмент ИИ-кода не попадает в рабочую ветку без проверки. Дальше процесс можно наращивать слоями: метаданные, тест-кейсы, синтаксис, модульные тесты, интеграционные сценарии, CI/CD и ревью по матрице риска.

Вывод

ИИ в 1С-разработке - это усилитель. Он ускоряет подготовку вариантов, помогает писать черновики тестов, подсвечивает граничные случаи и снимает часть рутины. Но он так же быстро усиливает хаос, если в команде нет понятных требований, тестов, архитектурных правил и ответственности за приемку.

Качество ИИ-кода определяется не только моделью. Оно определяется постановкой задачи, контекстом, инструментами, тестами, ревью и инженерной ответственностью команды.

Нейросеть генерирует гипотезы. Тестирование превращает их в инженерные изменения. В этом и есть здоровый подход к ИИ-коду в 1С: использовать скорость модели, но выпускать в production только проверенный результат.