Тестирование разработки на совместимость с конфигурацией

Программирование - Инструментарий

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

СОДЕРЖАНИЕ

ЗАЧЕМ ЭТО НУЖНО

СОСТАВ ПУБЛИКАЦИИ

ОГРАНИЧЕНИЯ ОБРАБОТОК

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ОБРАБОТОК

КАК ИСПОЛЬЗОВАТЬ ОБРАБОТКИ

ПОВТОРНОЕ ИCПОЛЬЗОВАНИЕ ФУНКЦИОНАЛА ПРОВЕРОК ДЛЯ РАЗНЫХ РЕШЕНИЙ

 

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

Обработки этой публикации тестировались на платформе 8.3.12.1685, но совместимы с более ранними версиями платформы.

 

ЗАЧЕМ ЭТО НУЖНО

Допустим, вы разработали решение для УТ 11 и выложили его на Инфостарте.

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

Своё решение вы тестировали на некотором наборе версий конфигурации УТ 11. В других версиях или в других видах конфигураций структура метаданных может отличаться.

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

Для этого вы подготавливаете некие правила проверки конфигурации, прикрепляете их и обработку тестирования к своей публикации (в виде бесплатных файлов).

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

Настоящая публикация включает обработки для создания правил проверки и тестирования конфигурации по этим правилам.

 

СОСТАВ ПУБЛИКАЦИИ

Публикация включает архив, состоящий из следующих файлов:

1. Обработка «Редактор правил проверки»

2. Обработка «Тестирование конфигурации»

3. Файлы функций проверки

4. Руководство пользователя обработок

 

ОГРАНИЧЕНИЯ ОБРАБОТОК

1. Обработки предназначены для управляемых форм.

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

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

 

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ОБРАБОТОК

Подробно функционал обработок описан в прикреплённом к публикации руководстве пользователя.

 
GIF - ПРИМЕР РАБОТЫ ОБРАБОТОК

Обработка «Редактор правил проверки» предназначена для создания правил тестирования конфигурации на совместимость с прикладным решением.

Функциональные возможности редактора правил:

  • Создание правил проверки структуры конфигурации – проверки существования объектов метаданных разных уровней (справочники, реквизиты, общие модули и т.д.)
  • Автоматическое построение правил по исходному коду модулей, xml-файлам форм и макетов СКД
  • Добавление программных проверок (произвольный код) для метаданных разных уровней
  • Загрузка функций для программных проверок из файлов
  • Добавление условий выполнения проверок
  • Группировка правил проверок
  • Установка разных уровней важности для проверок (ошибка/предупреждение/информация)
  • Выгрузка /загрузка правил проверок в файл/из файла.

 

 

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

Функциональные возможности обработки тестирования:

  • загрузка файла проверок
  • формирование отчёта о результатах проверок
  • выгрузка отчёта в файл Excel

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

 

КАК ИСПОЛЬЗОВАТЬ ОБРАБОТКИ

Процесс создания/тестирования по правилам проверки может выглядеть так:

 

1. Разработчик создаёт правила проверки:

  • Выгружает тестируемое решение в файлы через конфигуратор. Например, внешнюю обработку можно выгрузить в файлы .xml (файлы обработки и её форм) и .bsl (файлы модулей)
  • Загружает файлы в редактор проверок
  • Редактор автоматически извлекает структуру метаданных, используемых в текстах модулей и xml-файлах решения.
  • Редактор автоматически строит структуру проверки метаданных
  • При необходимости разработчик дополняет структуру теми метаданными, которые не были извлечены автоматически
  • При необходимости добавляет для некоторых метаданных программные проверки – пишет произвольный код или использует предопределённые функции проверки, загруженные из файлов
  • При необходимости указывает для проверок их уровни важности: ошибка/предупреждение/информация.
  • Сохраняет правила проверки в файл.

 

2. Разработчик передаёт правила проверки и обработку тестирования клиенту

Клиент запускает обработку тестирования, загружает в неё правила, запускает тестирование.

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

 

3. Разработчик анализирует обнаруженные проблемы и дорабатывает своё решение для совместимости с другой версией или другим видом конфигурации.

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

 

4. Например, рассмотрим простейший случай

В конфигурациях УТ 11.4 и УНФ 1.6 есть справочник Номенклатура.

В УТ у номенклатуры  есть реквизит «ВидНоменклатуры», в УНФ – «КатегорияНоменклатуры».

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

Клиент протестировал его на УНФ и получил ошибку «Отсутствует реквизит ВидНоменклатуры».

Разработчик внёс изменение в решение. Теперь оно в зависимости от конфигурации использует тот или иной реквизит.

Разработчик также внёс изменение в правила проверки, теперь:

  • существование справочника Номенклатура проверяется всегда
  • существование реквизита КатегорияНоменклатуры проверяется только при условии, что тестирование выполняется в конфигурации УНФ
  • существование реквизита ВидНоменклатуры проверяется только при условии, что тестирование выполняется в конфигурации, отличной от УНФ – в это условие попадает УТ, оно же применяется и для остальных конфигураций в предположении, что реквизит в этих конфигурациях тоже будет называться ВидНоменклатуры (например, Розница 2.2)

 

ПОВТОРНОЕ ИCПОЛЬЗОВАНИЕ ФУНКЦИОНАЛА ПРОВЕРОК ДЛЯ РАЗНЫХ РЕШЕНИЙ

1) ГРУППЫ ПРОВЕРОК

Редактор правил позволяет создавать, загружать и сохранять группы проверок.

 

Например, вы разработали «Решение 1», которое использует функционал:

  • дополнительных реквизитов номенклатуры
  • характеристик номенклатуры
  • присоединённых файлов номенклатуры

 

И разработали «Решение 2», которое использует функционал:

  • заказов клиентов
  • дополнительных реквизитов номенклатуры

 

Оба решения используют функционал дополнительных реквизитов номенклатуры.

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

При разработке правил проверки для «Решения 2» вы можете добавить в список правил эту группу правил.

Формат файла группы проверок аналогичен формату файла правил, поэтому его можно использовать и как самостоятельные правила.

 

2) ФУНКЦИИ ПРОВЕРКИ

Редактор правил позволяет  задавать собственные проверки в виде произвольного программного кода.

Также с помощью программного кода задаются условия выполнения некоторой ветки дерева проверок (например, «Выполнять для конфигурации УТ» или «Выполнять для платформы версии ниже 8.3.9»).

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

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

Эту функцию затем он может использовать в разных правилах проверки.

 

Файл исходного кода функции – текстовый файл, содержащий:

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

 

Пример статичного кода – код условия «Выполнять для конфигурации УТ», например:

Результат = Найти(Метаданные.КраткаяИнформация, "Управление торговлей") <> 0;

Этот код не зависит от контекста, неважно, в каком именно условии он применяется.

 

Пример кода, генерирующего код проверки – это функция проверки типа реквизита.

В зависимости от реквизита код будет разным.

Например, для реквизита «Наименование» - этот код будет проверять, является ли тип реквизита строковым.

Для реквизита «Номенклатура» - проверять, является ли тип реквизита ссылкой на справочник Номенклатура.

 

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

8

Скачать файлы

Наименование Файл Версия Размер
Тестирование разработки на совместимость с конфигурацией
.rar 556,14Kb
15.10.18
2
.rar 1.0.0 556,14Kb 2 Скачать

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. sytkosa 116 15.10.18 17:48 Сейчас в теме
(0) Добрый день, есть несколько вопросов
1. Есть ли групповой режим или режим командной строки;
2. Возможно ли обработку адаптировать чтобы она стала как библиотека в onescript;
3. Какие условия распространения в дальнейшем планируются по данному инструментарию, если свободно возможно ли проект выложить в git для доработки сообществом;
2. maxim_1c 60 15.10.18 19:33 Сейчас в теме
(1)
Добрый день,

1. «Есть ли групповой режим или режим командной строки» - я так понимаю, речь только про обработку тестирования, а не про редактор правил? Нет, таких режимов нет. Можете пояснить, как вы видите работу обработки в этих режимах?

2. «Возможно ли обработку адаптировать чтобы она стала как библиотека в onescript»
С onescript не знаком. Опять же, можете пояснить, как вы это видите в общих чертах?

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

Обработка «Редактор правил проверки» распространяется через эту публикацию за стартмани.

Обработка «Тестирование конфигурации» и функции проверки свободны для распространения (планировал их выложить бесплатно, но правила инфостарта не позволяют). Если нужно, могу выслать. Обработку «Тестирование конфигурации» разработчики могут прикреплять к своим публикациям.

Про git пока не думал, но вообще да, идея интересная. По крайней мере, можно выложить обработку тестирования и функции проверки для совместной доработки.
3. Darklight 15 16.10.18 09:48 Сейчас в теме
Интересная разработка, всё, бы "ничего", НО

1. Всё равно над знать структуру метаданных другой конфигурации

4. Например, рассмотрим простейший случай

В конфигурациях УТ 11.4 и УНФ 1.6 есть справочник Номенклатура.

В УТ у номенклатуры есть реквизит «ВидНоменклатуры», в УНФ – «КатегорияНоменклатуры».

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

Клиент протестировал его на УНФ и получил ошибку «Отсутствует реквизит ВидНоменклатуры».

Разработчик внёс изменение в решение. Теперь оно в зависимости от конфигурации использует тот или иной реквизит.
Показать


Разработчик, не зная (не имея) структуру метаданных (причём, порой, достаточно подробно углубляясь в особенности работы) никак не узнает, что вместо реквизита "ВидНоменклатуры" нужно использовать реквизит "КатегорияНоменклатуры" в этотм же справочнике. А ведь он хранение в иной версии конфигурации может быть и в другом месте организовано (например в регистре сведений). При этом в конфигурациях может быть и так, что актуальное хранение переместится в другое место с какой-то версии (в т.ч. в результате персональных доработок у пользователя), но старое место ещё останется (не которое время) в составе конфигурации - тогда проверка найдёт реквизит, который уже не используется - конечно тут всё можно понять при детальном изучении даже успешного отчета (самим пользователем, если он продвинутый). Но разработчик порой не сможет понят, что ему нужно и как доработать. Это касается не только реквизитов и элементов хранения данных, это касается любых метаданных.

2. Отсутствие различных элементов метаданных
Так же частенько какие-то элементы метаданных могут присутствовать не во всех поставках конфигураций даже одной версии (я про поставки разного уровня наполнения: проф, корп...) или же попросту быть включены/исключены с разных версий. Зачастую в этих случаях эти метаданные могут быть просто не использованы и в самом устанавливаемом решении. Но опять таки, анализировать как это всё должно быть учтено - по таким отчетам почти не реально. Нужно всю конфигурацию иметь и на ней тестировать.
4. maxim_1c 60 16.10.18 10:26 Сейчас в теме
(3)

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

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

Вообще идея обработок родилась в результате опыта, полученного при адаптации одного решения под конфигурации УТ 11.1-11.4, УНФ 1.6, Розница 2.2. Оглядываясь назад, могу сказать, что мне бы эти обработки тестирования помогли бы в своё время.

Я вижу такие возможные случаи использования обработок:
- конечный клиент может самостоятельно протестировать некоторое решение перед покупкой. Я часто вижу комментарии пользователей инфостарта типа «а ваша обработка будет работать под моей конфигурацией?»
- при выходе новой версии конфигурации разработчик может сам протестировать, будет ли его решение совместимо с ней. Например, если разработчик в своей публикации заявляет о совместимости с УТ, то при выходе УТ 11.4 он может увидеть, что в новой версии поменялся механизм хранения присоединённых файлов
- можно применять этот метод и для случая, когда вы, например, сопровождаете какого-то клиента, дорабатываете его конфигурацию, обновляете её. При очередном обновлении вы можете заранее протестировать, будут ли конфликты у ваших доработок с обновлённой конфигурацией.
5. zeegin 30 17.10.18 10:30 Сейчас в теме
Поздравляю!

Вы изобрели механизм заимствования и проверки расширений (ровно то, что делает платформа при проверке применимости расширения, только нативно).
6. maxim_1c 60 17.10.18 11:45 Сейчас в теме
(5)

Да, есть некоторые пересечения, только тут речь не только про расширения, плюс можно создавать собственные программные проверки.
7. zeegin 30 17.10.18 12:22 Сейчас в теме
(6) Ну так а в чем мотивация писать правила в сторонке от решения для УТ, например, если можно все решение и проверки сделать в расширении и использовать механику проверки платформы?
9. maxim_1c 60 17.10.18 12:40 Сейчас в теме
(7)

Как минимум:

- есть отдельная обработка тестирования, которую можно скинуть клиенту (вместе с правилами проверки), не скидывая свою разработку. Смысл в том, чтобы не предоставляя клиенту решение позволить ему проверить совместимость.

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

- речь не только про расширения, но и про обработки, отчёты и т.д.
10. zeegin 30 17.10.18 12:59 Сейчас в теме
(9) Сценарий с проверкой совместимости без передачи решения интересный.

Но я не очень понимаю какой процесс общения с клиентом надо для этого использовать. Это только для аутсорсинга?

На отчеты и обработки не рекомендую сильно вкладываться, т.к. сейчас рекомендуется все делать расширениями.
11. maxim_1c 60 17.10.18 13:10 Сейчас в теме
(10)

По поводу этого:
"Но я не очень понимаю какой процесс общения с клиентом надо для этого использовать"

Если речь про Инфостарт, то я вижу это так:

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

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

Клиент выполняет тестирование по правилам, если результаты содержат ошибки, скидывает результаты разработчику.
8. maxim_1c 60 17.10.18 12:39 Сейчас в теме
Оставьте свое сообщение