Битва с призраками прошлого: ищем "битые" запросы после обновления релиза

06.02.25

База данных - Обновление 1С

+35 –1

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
Анализ конфигурации: Поиск ошибок в текстах запросов .epf 17,37Kb ver:1.0 8	8	Скачать (2 SM)	Купить за 2 150 руб.

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

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

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

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

Понятное дело, это безобразие нужно исправлять. Но какие методы обнаружения «битых» запросов сейчас существуют?

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

Автоматизированное тестирование – это вещь, безусловно, очень крутая и полезная, но далеко не все могут себе позволить разработку тестов, покрывающих весь доработанный функционал.

Проверка релиза тестировщиками / аналитиками / консультантами – безусловно, действенный метод, но занимает много времени, и почти всегда в ходе этих тестирований что-то пропускается и остаётся незамеченным.

А вот конечные пользователи такие ошибки находят махом! Но согласитесь, заливать в продуктив недотестированный релиз с «битыми» запросами в коде – сложно назвать лучшим управленческим решением.

Теперь к делу… Я разработал решение, которое позволяет в автоматическом режиме найти большинство «битых» запросов, которые появились в результате перехода на новый релиз.

Суть решения довольно простая. Мы выгружаем в файлы три конфигурации:

Наша доработанная конфигурация до обновления
Конфигурация с типовым релизом, на который осуществляется переход
Наша обновлённая на новый релиз конфигурация с перенесёнными доработками

Моя обработка сканирует все файлы модулей конфигурации и вытаскивает из них все тексты запросов, которые получается вытащить. Да, получается вытащить далеко не все, часть запросов у нас формируется динамически, из нескольких частей и т.д. Такие мы пропускаем.

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

Затем программа сканирует полученные ошибки и оставляет только те, в которых «Поле не обнаружено» или «Таблица не обнаружена». Вот они, «битые» запросы!

Но, к сожалению, всё не так просто. Типовые конфигурации, увы, кишат подобными запросами. При попытке открыть их в конструкторе, мы видим ошибку. Но дальше по коду идёт волшебная замена одной подстроки на другую (или другая подобная магия) и на выполнение попадает уже правильный запрос, который отлично работает.

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

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

Предполагается, что ошибки, которые программа находит в новом типовом релизе – это тоже шум. ~~Ведь не могут же 1С-ники наделать ерунды.~~ А даже если нет, к нашему обновлению это не относится.

Таким образом, просканировав две эти конфигурации, мы собираем базу «шума».

Затем приступаем к сканированию нашей обновлённой конфигурации с доработками, при этом указываем два файла с «шумами». Программа исключит идентичные ошибки из этих 2 файлов и оставит только «битые» запросы, которые возникли при переносе доработок в новый типовой релиз. Их будет не много, и их можно будет уже легко отсмотреть и проверить руками.

Условно данный метод можно представить в виде классической схемы пересечения трёх множеств.

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

Да, данный инструмент не гарантирует нахождение всех проблем в запросах (хотя бы потому, что не может анализировать динамически формируемые запросы в коде), но совершенно точно помогает находить большинство «призраков прошлого» в запросах.

Скорость работы радует. Даже тяжелейшие конфигурации вроде ERPУХ последней версии сканируются примерно за 10 минут. Как минимум, рекомендую всем попробовать данный инструмент, а если понравится – взять на вооружение))

Пошаговая инструкция по применению инструмента «Анализ конфигурации: Поиск ошибок в текстах запросов»

Шаг 1. Нужно подготовить 3 базы. С конфигурацией до обновления, с конфигурацией после обновления и с типовым релизом, на который вы обновились. Заходим в каждую базу в режиме конфигуратора и выгружаем конфигурацию в файлы:

Далее указываем, в какую папку выгружаем конфигурацию. Каждую конфигурацию нужно выгрузить в отдельную папку.

Шаг 2. Запускаем базу с конфигурацией до обновления в режиме «1С Предприятия». Открываем нашу обработку.

Указываем путь к папке, в которую мы выгрузили конфигурацию. Нажимаем «Выполнить поиск ошибок». Ждём.

Шаг 3. Дожидаемся результатов.

Выбираем в меню «Действия» - «Сохранить файл со всеми ошибками (для исключений)»

Сохраняем ошибки в файл, назовём его, например, ШумДоОбновления.mxl.

Шаг 4. Открываем базу с типовой конфигурацией нового релиза в режиме «1С Предприятия». Повторяет шаги, аналогичные шагам 2 и 3. В результате получаем файл ШумНовогоРелиза.mxl.

Шаг 5. Запускаем базу, обновлённую на новый релиз с перенесёнными доработками в режиме «1С Предприятия». Запускаем обработку. Указываем путь к папке с выгруженной конфигурацией. Но в этот раз нажимаем на выключатель «Скрывать ошибки».

Появляются варианты, отмечаем выключатели «Конфигурации до обновления» и «Типового релиза».

Выбираем подготовленные ранее файлы с шумами. Нажимаем «Выполнить поиск ошибок». В итоге на последнем шаге программа исключит все ошибки «шумов» из итогового результата.

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

Также есть возможность формировать собственный файл со списком ошибок-исключений. Для этого можно отмечать ошибки, которые вы не считаете ошибками, чекбоксами в списке.

Далее выбираем меню «Действия»:

Сначала нажимаем «Добавить в исключения отмеченные». После нажатия данные строки скроются из списка. Далее выбираем пункт «Выгрузить все скрытые исключения в файл».

Данным файлом также можно в дальнейшем пользоваться, включив данный флажок:

Ну и на этом у меня всё! Всем удачи и берегите своё время) Надеюсь, данная обработка вам в этом поможет)

Другие мои публикации на Инфостарте:

Проверено на следующих конфигурациях и релизах:

1С:ERP Управление предприятием 2, релизы 2.5.20.93

обработка инструмент поиск ошибок в конфигурации анализ конфигурации поиск ошибок в запросах обновление конфигурации

+35 –1

См. также

Infostart Toolkit — Инструменты разработчика 1С 8.3

Инструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Платные (руб)

Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

15500 руб.

02.09.2020 174971 973 403

931

Обновление конфигураций Бухгалтерия 2, КА 1.1, ЗУП 2.5

Зарплата Регламентированный учет и отчетность Кадровый учет Обновление 1С Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Зарплата и Управление Персоналом 2.5 Бухгалтерский учет Налоговый учет Управленческий учет Акцизы ЕНВД ЕСН Земельный налог ИП, ПБОЮЛ, КФХ Налог на имущество Налог на прибыль НДС НДФЛ ФОМС, ЕФС Транспортный налог УСН ПСН (патентная система налогообложения) Платные (руб)

Пакет обновлений для старых конфигураций 1С:КА 1.1, ЗУП 2.5 и БУХ 2.0 - УСН, НДС 5%, 7%, НДФЛ новая шкала 2025, ЕФС-1, Расчет страховых взносов, Статистика, СЗВ-ТД, 2-НДФЛ, Регламентированная отчетность, Кадровый учет, Прослеживаемость импортных товаров

27900 руб.

01.04.2020 152095 546 392

252

Шпаргалка по запросам

Запросы Программист Бесплатно (free)

Увидел cheatsheet по SQL и захотелось нарисовать подобное, но про запросы.

18.10.2024 12105 sergey279 18

Ловушка функции запроса АВТОНОМЕРЗАПИСИ()

Запросы Программист Платформа 1С v8.3 Запросы 1C:Бухгалтерия Бесплатно (free)

Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть.

11.10.2024 7073 XilDen 36

Итоговый запрос в отчете СКД

Запросы СКД Программист Стажер Система компоновки данных Россия Бесплатно (free)

Часто при разработке отчетов в СКД возникает ситуация, когда не совсем понятно, почему отчет выводит не те данные, которые нужны, либо не выводит вовсе. Возникает потребность увидеть конечный запрос, который формирует СКД. Как это сделать, рассмотрим в этой статье.

15.05.2024 11312 implecs 6

Пропорциональное распределение в запросе с использованием АвтоНомерЗаписи()

Запросы Программист Стажер Платформа 1С v8.3 1C:Бухгалтерия Бесплатно (free)

Часто поступают задачи по произвольному распределению общих сумм. После распределения иногда пропадают копейки. Суть решения добавить АвтоНомерЗаписи() в ВТ распределения, и далее используя функции МАКСИМУМ или МИНИМУМ можем положить разницу копеек в первую или последнюю строку знаменателя распределения.

11.04.2024 3737 andrey_sag 10

Генератор текстов запросов 1С из естественного языка LLM GPT

Инструментарий разработчика Запросы Программист Стажер Платформа 1С v8.3 Управляемые формы 1C:Бухгалтерия Бесплатно (free)

Пишем на человеческом языке, что нам надо, и получаем текст запроса на языке 1С. Используются большие языковые модели (LLM GPT) от OpenAI или Яндекс на выбор.

15.01.2024 11806 214 mkalimulin 32

Объектная модель запроса "Схема запроса" 2

Запросы Программист Платформа 1С v8.3 Запросы 1C:Бухгалтерия Бесплатно (free)

Далеко уже не новый тип данных "Схема запроса". Статья о том, как использовать его "попроще". Примеры создания текста запроса с нуля и изменение имеющегося запроса.

06.12.2023 7184 user1923546 29

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. dsdred 3786 06.02.25 11:29 Сейчас в теме

Выглядит неплохо.

2. SlavaKron 06.02.25 11:38 Сейчас в теме

Скажите, это "битый" запрос?

ВЫБРАТЬ
	ТЗ.Поле1 КАК Поле1,
	ТЗ.Поле2 КАК Поле2
ПОМЕСТИТЬ ВТ
ИЗ
	&ТЗ КАК ТЗ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	ВЫБОР 
		КОГДА ВТ.Поле1.Реквизит1 = 0 ТОГДА ВТ.Поле2
		ИНАЧЕ ВТ.Поле1
	КОНЕЦ
ИЗ
	ВТ КАК ВТ

Показать

3. XilDen 559 06.02.25 11:45 Сейчас в теме

(2) Это запрос, создающий "шум". Если всё сделать по инструкции, такие запросы будут исключены из финального списка ошибок.

4. user2122906 88 06.02.25 12:20 Сейчас в теме

Однозначно плюс! Годная идея, мне кажется. В финальный список ошибок будут попадать только те ошибки, которые вызваны изменением метаданных, потому что все остальные ошибки попадут в список исключений. Скачал, протестирую)

5. PerlAmutor 157 06.02.25 18:29 Сейчас в теме

EDT вроде тоже умеет проверять запросы. Основная головная боль у меня с запросами формирования движений, когда куски запросов разбросаны по общим модулям и собираются в зависимости от функциональных опций и кучи других условий. А на выходе все это склеивается через "ОБЪЕДИНИТЬ ВСЕ" и внезапно обнаруживается, что в запросах разное количество полей или поля не на своих позициях (а это еще страшнее, т.к. запрос может компилироваться без ошибок).

6. XilDen 559 06.02.25 19:49 Сейчас в теме

(5) Есть такая проблема, да) но тут только руками отлаживать, увы)

7. ivanov660 4673 06.02.25 19:51 Сейчас в теме

(10)
1. Правильно ли я понял что две конфигурации нам нужны чтобы исключить повторяемые ошибки?
2. А не правильнее ли найти фалы с изменениями, а потом их проверять. Т.е. сначала например находим те файлы между новой и доработанной, в которых есть отличия. И их прогоняем. Так мне кажется будет значительно эффективнее.
3. Позже посмотрю код, как у вас там этот функционал реализован.

8. XilDen 559 06.02.25 20:27 Сейчас в теме

(7) 1 - да, правильно. В конфигурациях есть много запросов, которые выдают ошибку при открытии в конструкторе, но при этом работают без ошибок по факту. Цель - убрать эти ошибки из общего списка. Как тут правильно писали выше, алгоритм состоит в том, чтобы все ошибки нового типового релиза и все ошибки конфигурации до обновления не считать ошибками. В таком случае останутся только ошибки в запросах, которые в старой конфигурации открывались без проблем, а в новой перестали открываться. А такое возможно только из-за изменения метаданных. Их нам и нужно найти.
2 - ну если с этой точки зрения рассматривать оптимизацию алгоритма, то безусловно можно найти более эффективные решения увеличения производительности поиска. Но в сущности, в этом нет особого смысла. Ну будет занимать процесс поиска не 30, а 15 минут, что это особо поменяет? Не так часто приходится обновлять базы на новый релиз, чтобы сэкономленное время превысило время, которое мы потратим на оптимизацию алгоритма. Обновление на новый релиз занимает как минимум несколько дней, а то и недель. Потратить лишние пол часа и попить чаёк, пока программка поищет косяки в конфигурации - совсем не сложно) даже приятно)

11. ivanov660 4673 07.02.25 00:38 Сейчас в теме

(8) 2 пункт. Тут вопрос больше в том, что мы будем анализировать именно части связанные с изменениями, а не все. Т.е. влияние именуемого вами "шума" будет как раз меньше. На сколько я понял цель вашей обработки проверять именно внесенные изменения, а это именно и поможет нам сконцентрироваться на этом.

12. XilDen 559 07.02.25 06:25 Сейчас в теме

(11) да, но у данного подхода есть 4 существенных минуса.
1 - для того, чтобы нам вычислить только файлы, в которых у нас были доработки, нам нужно сравнивать конфигурацию до обновления не с новым типовым релизом (это бессмысленно, изменения будут везде и мы никак не сможем отделить мух от котлет - изменения это нового релиза или изменения из за наших доработок), нам придётся сравнивать её с текущим типовым релизом. Т.е. вместо 3 баз для анализа их будет 4. Слишком усложняется всё. Дополнительное время на развёртывание базы, выгрузку её в файлы - это как минимум +40 минут времени.

2 - а какой мы будем использовать алгоритм поиска различий в файлах? Самое быстрое - это по размеру файлов. Но можем ли мы гарантировать, что два файла, весящих одинаковое количество байт - идентичны? По правилам, конечно, кусок типового кода должен комментироваться в случае доработок, но по факту может быть ситуация, что пользователь удалил 20 символов типового кода и дописал 20 символов своего. Значит у нас остаётся либо посимвольное сравнение файлов, либо сравнение через хэш-сумму файлов. И то и другое, я полагаю, займёт значительное время. Окупится ли это время на последующих шагах за счёт значительно меньшего объёма обрабатываемых файлов, содержащих доработки? Спорно, тут думаю покажет только тестирование с замером.

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

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

13. ivanov660 4673 07.02.25 08:42 Сейчас в теме

(12)
1. Мы будем сравнивать изменённую новую конфигурацию с новой типовой конфигурацией. К тому же вы выше сказали, какая разница если будет на 15 минут больше.
2. Хотя бы хэш MD5. Очень быстро и из коробки.
3. Ваше понятие шума достаточно спорно. Зачем нам унификация? Вы хотите поставить на поток? Опять же нет необходимости увеличивать количество баз.
4. Если мы сравним новую типовую базу с новой доработанной, то изменения будут там куда они переехали.

P.S. Я вас не заставляю дорабатывать, а предложил идею. Что-то подобное мы используем при автоматическом переносе изменений из старой доработанной конфигурации в новую. К сведению, поиск построчных отличий по модифицированному алгоритму diff у меня занимает порядка 20 минут в конфигурации ERP (достаточно хорошо доработана). У себя я не реализовывал проверку запросов, но думал над этим. Вот по этому и обратил внимание на вашу статью.

15. XilDen 559 07.02.25 09:23 Сейчас в теме

(13)
1. Хм, в таком варианте это действительно уже интересней, не подумал сразу об этом)
2. Не доводилось тестировать производительность этого механизма, к сожалению, но поверю вам на слово)
3. Честно - не знаю, наверное это имело бы смысл, если бы на данный инструмент был высокий спрос. Пока что его нет, от слова, совсем, всего 3 скачивания) При таком спросе конечно нет никакого смысла в потоке)
4. Да, при таком подходе согласен)
Но в чём принципиальное преимущество данного подхода? Мы вроде сошлись, что разница в 15 минут не принципиальна, итоговый результат со списком найденных ошибок в обоих случаях будет один и тот же. Для чего тогда?

17. ivanov660 4673 07.02.25 10:09 Сейчас в теме

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

18. XilDen 559 07.02.25 10:26 Сейчас в теме

(17) Спасибо за пищу для размышлений, возможно вы правы) Если будет свободное время, пожалуй, поэкспериментирую с применением вашего подхода, отпишусь о результатах)

19. nemec 27 09.02.25 13:14 Сейчас в теме

(12) Хеш работает быстро, я использовал его именно для такой же цели - сверки кода в двух текстовых файлах, в этой обработке https://infostart.ru/1c/tools/1373139/ , можете не переживать и смело использовать

9. gybson 06.02.25 21:49 Сейчас в теме

Это будет совсем хорошо выглядеть с гитом и заранее сохраненным списком "шумов". Чего их каждый раз то собирать?

10. XilDen 559 06.02.25 22:37 Сейчас в теме

(9) Да, хорошая идея, думал об этом, можно создать библиотеку шумов на все версии типовых релизов. Как дальнейшее развитие инструмента - вполне себе вариант) будет спрос - сделаю)

14. yukoz 65 07.02.25 08:55 Сейчас в теме

1. Если внимательно переносить доработки в дважды изменённых модулях, то там проблемы минимальны, а чаще вообще их нет.
2. Часто проблема в запросах возникает, либо в динамических (собираются из разных мест), либо, где по коду вставляются плюсики с переменными (конкатенация), либо после запроса указано СтрЗаменить и меняется текст запроса... но такое эта обработка "не увидит".
3. Еще часто проблема возникает в дополнительных внешних обработках\отчетах... но такое эта обработка "не увидит".
4. Есть еще много всяких расширение, там обработка сможет искать проблемные места?
5. Есть свои запросы в ролях, там обработка сможет искать проблемные места?

P.S. Я часто обновляю сильно доработанные конфигурации и не уверен, что обработка мне чем-то сильно поможет.. наоборот на нее время уйдет.
Для более важных конфигураций написал авто-тесты на Ванессе, с помощью этого как раз и находятся проблемные места. Именно с точки зрения пользователя с неполными правами.

16. XilDen 559 07.02.25 09:57 Сейчас в теме

(14)
1. Это может быть даже не типовой общий модуль, а созданный в результате доработки. В модуле может быть куча прекрасных запросов к типовым регистрам, документам, справочникам. Если в одном из этих типовых регистров/документов/справочников в новом релизе поменяется реквизитный состав, то эти прекрасные запросы перестанут работать. Таких нетиповых модулей может быть очень много. Как бы аккуратно мы не переносили код в процессе обновления, такие нетиповые модули переедут в новую конфигурацию "как есть". И их нужно будет досконально проверять.
2. Тут полностью согласен, данные запросы обработка не увидит, и у меня нет никаких идей, как можно это исправить.
3. Ну проблему с внешними отчётами и обработками можно в принципе решить, встроив их в основную конфигурацию на время проверки.
4. По поводу расширений: да, мы можем точно также выгрузить расширения в файлы и обработка выполнит по ним поиск запросов. За одним исключением: там где используется &ИзменениеИКонтроль обработка не сможет проанализировать области #Вставка#... #КонецВставки# и #Удаление#...#КонецУдаления#. Но это можно легко доработать.
5. Нет, к сожалению ,на данный момент роли не анализируются, анализируются только файлы с модулями конфигурации, имеющие формат *.bsl. Роли же выгружаются в формат xml и хранятся в совершенно другом формате. Но всё это конечно тоже можно доработать, если у пользователей будет спрос)

Автотесты - это круто) У всех свой подход, я не настаиваю) Просто поделился своим инструментом, может кому то и пригодится)

20. DmitriyV 2 10.02.25 15:59 Сейчас в теме

Но вы же не проверяете все ошибки при определении "шума". Допустим типовая и доработанная. В обоих запросах ошибка "поле не найдено Фамилия". Но это же первая попавшаяся ошибка. Вы исключите этот запрос? А вдруг в доработанной помимо поля Фамилия, нет еще и поля "Отчество". А в типовой поле есть.

21. XilDen 559 11.02.25 08:14 Сейчас в теме

(20) Да, всё верно. Проверка запроса строится в любом случае так, что обнаруживается самая первая ошибка в запросе. Если в запрос, который попадает в "шум", влезли с доработкой, то с большой долей вероятности, такая ошибка не будет обнаружена обработкой. А у вас есть идея, как обнаруживать сразу все ошибки в запросе, а не только первую?

22. DmitriyV 2 11.02.25 09:42 Сейчас в теме

(21) сомневаюсь что это возможно. Просто в статье про такой нюанс не рассказали. А только про динамически формирующиеся запросы. Кто-нибудь скачает как панацею

23. artbear 1566 17.02.25 11:59 Сейчас в теме

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

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

авторское решение в виде полу-автоматического способа анализ очень интересно.

ps напомню, что в Vanessa-ADD также есть несколько дымовых тестов, выполняющих роль статического анализа
- проверка макетов СКД
- проверка ролей
- проверка типов общих модулей
- и т.д.

24. artbear 1566 17.02.25 12:01 Сейчас в теме

(23) дополню, что при использовании bsl ls также есть проблемы
- могут не проверятся внешние отчеты, обработки, т.к. может не быть связки с конфигурацией
- расширения также часто проверяются без связки с корневой конфигурацией
- и т.п.