При сопровождении крупных, давно разрабатываемых проектов на платформе «1С:Предприятие 8.3» (таких как УПП, УСО или сильно кастомизированные самописные конфигурации) рано или поздно возникает необходимость обновления версии платформы и повышения режима совместимости. Например, когда разработчикам требуется использовать новые возможности, такие как современный HTML5-поле, появившийся в платформе версии 8.3.14, приходится уходить со старых режимов совместимости (например, 8.3.5).
Перевод огромной базы на новую платформу — это всегда риск парализовать работу предприятия из-за множества мелких runtime-ошибок в коде обычных форм, которые перестают поддерживаться новыми релизами. Тестировать базу вручную силами программистов или пользователей слишком долго и неэффективно. В этой статье мы подробно рассмотрим, как автоматизировать процесс тестирования конфигураций на обычных формах, проанализируем доступные инструменты и разберем создание собственного легкого инструмента для быстрого «дымового» тестирования.
Перед тем как выбирать стратегию тестирования, нам необходимо разобраться в технологических ограничениях платформы 1С. Большинство современных конфигураций используют управляемые формы, для которых фирма 1С разработала мощный встроенный механизм автоматизированного тестирования. Запуск клиентского приложения с ключами /TESTMANAGER (менеджер тестирования) и /TESTCLIENT (тестируемый клиент) позволяет эмулировать любые действия пользователя.
Популярные современные фреймворки, такие как Vanessa Automation (VA), работают именно на базе этого платформенного механизма. Однако здесь нас подстерегает главное ограничение: инструмент автоматизированного тестирования платформы работает исключительно с управляемым интерфейсом. Он физически не умеет взаимодействовать с элементами управления обычных форм (в толстом клиенте).
Попытка написать полноценные сценарии поведения пользователя (UI-тесты) в Vanessa Automation для обычных форм не принесет желаемого результата «из коробки». Вам придется либо использовать внешние кликеры операционной системы (например, AutoIt), либо писать громоздкий код эмуляции без графического интерфейса, что для разовой задачи обновления не имеет коммерческого смысла. Поэтому нам нужны специализированные инструменты.
Проанализируем одно из самых мощных бесплатных решений для тестирования обычных форм — подсистему «Инструменты разработчика». В этой библиотеке реализован уникальный механизм технического тестирования интерфейса и метаданных обычного приложения.
Выделим основные возможности этого инструмента для нашей задачи:
Использование подсистемы «Инструменты разработчика» позволяет выявить до 80% критических ошибок инициализации кода обычных форм без написания сложных тестовых сценариев.
Если бюджет проекта позволяет использовать коммерческие инструменты, рассмотрим специализированные системы, созданные для автоматизации обновлений измененных конфигураций:
А. «1С:Автоматическое тестирование конфигураций» (разработка компании «1С-ИжТиСи»)
Этот продукт незаменим при обновлении сильно переписанных баз. Он ориентирован именно на технический контроль качества после обновления платформы или релиза:
Б. «1С:Сценарное тестирование 8» (входит в состав Корпоративного инструментального пакета — КИП)
Исторический инструмент от фирмы 1С. В отличие от современных библиотек, он полноценно поддерживает запись действий пользователя в толстом клиенте на обычных формах. Мы можем запустить запись сценария, выполнить ключевые цепочки документов вручную, а затем воспроизводить этот сценарий в автоматическом режиме на новых версиях платформы.
Выясним, как поступить, если нам нужно решить задачу быстро, без разворачивания сложных систем тестирования и без покупки коммерческого софта. В таких случаях опытные архитекторы 1С пишут простую внешнюю обработку для так называемого «дымового» (Smoke) тестирования.
Суть метода заключается в автоматическом программном открытии всех форм конфигурации под учетной записью администратора в блоке безопасности Попытка ... Исключение. Если код формы содержит устаревшие функции, которые не поддерживаются новой платформой или новым режимом совместимости, система выдаст ошибку. Мы перехватим эту ошибку, закроем форму и запишем проблему в лог.
Разберем по шагам реализацию такого алгоритма. Создадим простую процедуру для тестирования справочников и документов:
Процедура ВыполнитьДымовоеТестирование() Экспорт
ТаблицаОшибок = Новый ТаблицаЗначений;
ТаблицаОшибок.Колонки.Добавить("ТипОбъекта");
ТаблицаОшибок.Колонки.Добавить("ИмяОбъекта");
ТаблицаОшибок.Колонки.Добавить("ИмяФормы");
ТаблицаОшибок.Колонки.Добавить("ТекстОшибки");
// Тестируем справочники
Для Каждого Метаданное Из Метаданные.Справочники Цикл
ИмяСправочника = Метаданное.Имя;
// Проверяем основную форму объекта
ИмяФормы = "ФормаОбъекта";
Попытка
// Пытаемся получить форму нового (пустого) элемента
НовыйЭлемент = Справочники[ИмяСправочника].СоздатьЭлемент();
Форма = НовыйЭлемент.ПолучитьФорму();
// Если форма получена, пробуем ее открыть и сразу закрыть
Если Форма <> Неопределено Тогда
Форма.Открыть();
Форма.Закрыть();
КонецЕсли;
Исключение
НоваяСтрока = ТаблицаОшибок.Добавить();
НоваяСтрока.ТипОбъекта = "Справочник";
НоваяСтрока.ИмяОбъекта = ИмяСправочника;
НоваяСтрока.ИмяФормы = ИмяФормы;
НоваяСтрока.ТекстОшибки = ОписаниеОшибки();
КонецПопытки;
КонецЦикла;
// Тестируем документы
Для Каждого Метаданное Из Метаданные.Документы Цикл
ИмяДокумента = Метаданное.Имя;
ИмяФормы = "ФормаДокумента";
Попытка
НовыйДокумент = Документы[ИмяДокумента].СоздатьДокумент();
Форма = НовыйДокумент.ПолучитьФорму();
Если Форма <> Неопределено Тогда
Форма.Открыть();
Форма.Закрыть();
КонецЕсли;
Исключение
НоваяСтрока = ТаблицаОшибок.Добавить();
НоваяСтрока.ТипОбъекта = "Документ";
НоваяСтрока.ИмяОбъекта = ИмяДокумента;
НоваяСтрока.ИмяФормы = ИмяФормы;
НоваяСтрока.ТекстОшибки = ОписаниеОшибки();
КонецПопытки;
КонецЦикла;
// Выводим результаты в отчет или таблицу
ПоказатьРезультатыТестирования(ТаблицаОшибок);
КонецПроцедуры
Рассмотрим подробнее, почему этот подход эффективен:
Записать() не вызывается), транзакционная целостность данных не нарушается. Мы проверяем исключительно визуально-интерфейсную часть и код инициализации (события ПередОткрытием, ПриОткрытии и обработчики ожидания).Для более глубокого анализа мы можем усложнить этот скрипт: вместо создания новых (пустых) элементов находить в базе данных по одному существующему заполненному элементу каждого справочника или документа и пытаться открыть его форму. Это позволит протестировать процедуры чтения данных и заполнения реквизитов на форме, которые часто содержат логику, зависящую от переданного контекста владельца или родителя.
При планировании перевода устаревшей системы на обычных формах на новые релизы платформы 1С рекомендуем придерживаться следующего плана действий: