В этой статье мы поговорим про автоматизированные тестирования в 1С. Я расскажу, как в нашей компании устроен этот процесс, какие инструменты, методы и подходы мы применяем.
Подразделения нашей компании поддерживают более 22 систем. Это абсолютно разные системы: от типовых топовых ERP УХ и ЗУП до конфигураций, разработанных с нуля.
Пирамида автоматизированных тестов и ее адаптация под 1С
Когда речь заходит про стратегию автоматизированного тестирования, нужно начинать с пирамиды автотестов. Так как именно пирамида нам показывает, каких тестов и сколько должно быть для того, чтобы эффективнее выстроить процесс и использовать ресурсы.
На рисунке представлена классическая пирамида автоматизированного тестирования, описанная Майком Коном. Чем выше уровень тестов в пирамиде, тем меньше должно быть тестов, при этом они сложнее и продолжительнее, их сложнее разрабатывать, они чаще ломаются и, соответственно, их тяжелее поддерживать.
Однако при попытке применить эту пирамиду к системам, разработанным на базе платформы 1С Предприятие, возникает ряд вопросов. И если с нижним уровнем (UNIT – тесты для проверки отдельных методов) и верхним уровнем (UI – тесты по взаимодействию с пользовательским интерфейсом) все просто и понятно – про них есть много статей и докладов – то при попытке интерпретации тестов среднего уровня возникает проблема. Это происходит потому, что пирамида разработана для приложений на микросервисной архитектуре, где есть бекэнд и фронтенд, собственная реализация взаимодействия с базой данных. А 1С – это монолитные системы. А некоторые функции, такие как взаимодействие с базой данных, вообще берет на себя сама платформа.
Поэтому мы построили свою пирамиду автотестов. В ее центр мы поставили понятие пользовательской операции. С одной стороны, пользовательская операция – это то, что объединяет под собой несколько методов (при нажатии пользователем на кнопку формы последовательно выполняется несколько процедур и функций). С другой стороны, пользовательская операция – это базовый элемент, на котором построены все сценарии более верхнего уровня – end-to-end тесты.
В статье я не буду говорить ни про юнит, ни про UI тесты. Как тестировщики, мы считаем, что слоем юнит тестов должны заниматься разработчики: так эффективнее с точки зрения трудозатрат. А что касается тестов верхнего слоя пирамиды, то здесь у нас в арсенале есть такие инструменты как 1С Сценарное тестирование или Vanessa. Мы изучаем эти инструменты и активно внедряем у себя.
В дальнейшем в статье я буду говорить именно о тестах среднего уровня нашей пирамиды.
Определение и принципы тестов среднего уровня
Под тестами среднего уровня нашей пирамиды мы понимает тесты, направленные на проверку одной пользовательской операции или единицы интеграции, без взаимодействия с пользовательским интерфейсом. Под единицей интеграции мы понимаем один вид сообщения в рамках конкретной интеграции.
Существует три основных принципа автотестов:
-
Атомарность тестов,
-
Независимость тестов друг от друга,
-
Отделение тестов от данных.
Но если про атомарность и независимость тестов говорят всегда, то про принцип отделения тестов часто забывают, хотя он крайне важен.
Его суть состоит в том, что входные данные и сам тест можно логически разделить. В результате тест превращается в аналог функции, на вход которой подаются параметры, а на выходе получается результат.
Чтобы не путаться в терминологии, мы ввели понятие шаблона теста. Шаблон теста – это заготовка, как говорилось выше, это аналог функции. А сам тест мы рассматриваем как совокупность набора входных параметров, шаблона теста и выходного результата.
Реализация тестов через внешние обработки
Чаще всего инструментами автоматизированного тестирования 1С выступают внешние обработки, и мы также не стали отказываться от этого подхода. Рассмотрим, как может выглядеть обработка для проверки пользовательской операции проведения документа.
Главным входным параметром для теста здесь выступает ссылка на документ в тестируемой информационной базе. В качестве результата теста выступает отчет о движениях документа. Когда мы выбираем другую ссылку на документ и нажимаем кнопку «Выполнить тест», у нас появляется другой отчет о движениях, другой результат. И по факту это уже новый тест.
В реальности у нас должны быть тысячи сочетаний входных параметров и результатов тестирования, поэтому возникает вопрос, где мы будем хранить эти данные. Для таких целей мы разработали собственную систему, которую назвали «1С Запуск тестов». Система предназначена для хранения информации о внешних обработках и входных параметрах для тестов, умеет запускать эти обработки с конкретными значениями этих параметров, ожидать завершения их выполнения и анализировать полученный результат. Всего в системе предусмотрено до пяти вариантов анализа результата.
Расширенные возможности системы запуска тестов
На самом деле функционал конфигурации шире, чем просто возможность запуска внешних обработок. Всего система поддерживает три вида команд: пакетные команды 1С, внешние обработки и произвольные исполняемые файлы (файлы с расширением exe и cmd). Этих видов команд достаточно, чтобы охватить любые типы операций.
Все операции в сценариях делятся на два типа: подготовительные и непосредственно сами проверки или тесты. Например, пакетные команды – это в основном подготовительные операции (выгрузить/загрузить конфигурацию или информационную базу, обновить конфигурацию из хранилища и т.д.), но среди них есть и проверочные: синтаксический контроль или проверка применимости расширения. С внешними обработками все с точностью наоборот. В основном это тесты и проверки, но бывают ситуации, когда мы с их помощью выполняем и подготовительные действия: например, запуск обработчиков фонового обновления БД после обновления на типовой релиз.
Если вернуться к внешним обработкам, то в любом языке программирования или фреймворке существуют определенные правила. У нас они тоже есть.
Для того, чтобы конфигурация «Запуск тестов» могла работать с внешними обработками, они должны быть написаны по определенным правилам:
-
Реквизиты обработки – это параметры теста.
-
Один из реквизитов обработки должен быть предназначен для вывода результата проверки.
-
Выходной результат может быть в двух форматах: txt или mxl.
-
Процедура, выполняющая тест внутри обработки, должна быть экспортной.
Формирование и использование тестовых наборов
Теперь давайте рассмотрим общий процесс по созданию тестов на примере обработки по тестированию проведения документов.
Для тестов мы используем наполненную данными тестовую базу. Это может быть выгрузка из рабочей базы, демо база или база, наполненная синтетическими данными. Наша цель – создать тестовый набор. Тестовый набор – это таблица в формате mxl, где названия колонок соответствуют названиям параметров нашей тестовой обработки, а в строках указаны конкретные значения этих параметров. Одна строка таблицы – это набор значений параметров для одного теста. Эту таблицу можно сформировать вручную, подбирая значения из тестовой базы, но лучше предусмотреть в тестовой обработке интерфейс для автоматического подбора тестовых примеров. Например, в нашей обработке по проверке документов есть четыре универсальных варианта формирования тестового набора (подбора тестовых документов).
После того, как мы сформировали тестовый набор, мы загружаем его в систему запуска тестов. В ней есть универсальный загрузчик, который преобразует табличный документ в формате .mxl в объекты конфигурации «Запуск тестов». На выходе мы получаем сценарий тестирования. В сценарии указано, в какой информационной базе запускается обработка и с какими параметрами.
Нужно обратить внимание на то, что в качестве дополнительного разреза в сценарии появляется «пользователь», который по факту является дополнительным параметром теста. Одна и та же обработка с одинаковым набором параметров, запущенная под разными пользователями, может давать разные результаты. Например, проведение документа может быть доступно одному пользователю и недоступно другому. Действие одно и то же, но результат будет различаться.
Последнее, что нужно сделать – выполнить первый прогон тестов и зафиксировать текущие результаты. В дальнейшем мы будем использовать их как эталонные. Сам результат теста – это отчет о движениях в формате mxl, а в качестве варианта анализа мы выберем простое сравнение текущего и предыдущего результатов средствами платформы 1С.
После выполнения всех этапов мы можем приступать непосредственно к самому тестированию: обновлять информационную базу на новые версии и запускать тесты повторно.
Примеры реализации тестов для разных типов операций
Чтобы лучше понять принцип, давайте рассмотрим еще несколько примеров подобных обработок.
Первый пример – тестирование формирования отчета, созданного на механизме общей формы отчета.
В качестве входных параметров здесь выступают: имя отчета, как оно указано в метаданных, и вариант настройки пользователя. Вариант настройки особенно удобен, если мы используем выгрузку рабочей базы, так как в этом случае нам просто нужно подобрать нужный готовый вариант.
Код обработки простой: открываем отчет, применяем вариант, компонуем и получаем результат из табличного документа отчета.
Второй пример – тестирование печатных форм. Здесь, помимо ссылки на объект, мы передаем еще и имя макета.
Такая обработка позволяет тестировать любую печатную форму, основанную на общем модуле «УправлениеПечатью».
Пример кода основной функции теста
Применение подхода к разным типам операций
Применение данного подхода не ограничивается тремя перечисленными пользовательскими операциями.
Что еще мы проверяем подобным образом? Естественно, это основные операции с документами: открытие, заполнение, печать, проведение.
Отчеты также тестируются аналогичным образом: приведенный выше пример – только один из вариантов. Если речь про УПП, можно написать обработку, которая тестирует любой отчет, построенный на механизме универсального отчета или механизме компоновки данных.
Взаимодействие с другими системами, тестирование интеграций, реализованных через HTTP-сервисы. Обычно такие интеграции реализованы универсально, в виде общих модулей. В них есть ключевая функция, отвечающая за вызов интеграции. Остается поместить вызов этой функции во внешнюю обработку, а параметры функции и передать через реквизиты обработки.
Обмены между базами 1С. Например обмен между нашими базами УПП и ERP. Здесь мы также используем принцип отделения тестов от данных: логика теста хранится во внешней обработке, а тестовые примеры наполняются без программирования. После каждого очередного релиза нам требуется добавить несколько тестовых примеров, и все это выполняется без изменения кода.
Ключевые пользовательские операции, по которым в рабочих базах собирается статистика по времени выполнения – это менее универсальные обработки, предназначенные для конкретной конфигурации. Но здесь мы также применили подход отделения тестов от данных. Тестовые примеры мы берем из регистра сведений «Замеры времени», так как в нем содержится вся необходимая для тестовых примеров информация.
Изменения в конфигурациях – это отдельный большой пласт проверок. С помощью внешних обработок мы можем проверять не только изменения в метаданных, элементах форм и свойствах тестируемых конфигураций, но и контролировать изменения в текстах модулей, проверяя их, например, на соответствия требования оптимальности.
Преимущества предложенного подхода
Первое преимущество данного подхода – универсальность. Обработки, основанные на механизмах платформы 1С, универсальны для любой конфигурации. Обработки, основанные на общих механизмах конфигурации, универсальны для всех конфигураций, в которые встроены эти механизмы.
Например, когда нам передали на поддержку конфигурацию ERP, мы смогли воспользоваться обработкой с помощью которой тестировали проведение документов в базе ЗУП. За сутки мы сгенерировали около десяти тысяч тестовых примеров для базы ERP и смогли начать проверять в ней аналогичные операции.
Второе преимущество – разделение труда. Разработчику выдается задание на реализацию внешней обработки для тестирования какой-либо пользовательской операции. После завершения работ он передает обратно уже готовый вариант обработки и в процессе тестирования более никак не участвует. Подбором тестовых примеров, расширением тестового покрытия, самим запуском тестов и актуализацией результатов занимаются уже непосредственно или аналитики, или тестировщики.
Третье – простота поддержки тестов. Подмена текущего результата на эталонный выполняется автоматически при установке соответствующего признака.
Автоматизация верхнего слоя пирамиды и сценарии обновления
Конечно же, мы не забываем про тесты верхнего уровня нашей пирамиды. В качестве инструмента для создания UI тестов для конфигураций на управляемых формах мы используем инструмент Vanessa Automation. Как я писал выше, конфигурация «Запуск тестов» это чуть больше, чем просто работа с внешними обработками 1С.
Далее разберем пример сценария для подготовки тестовых информационных баз и последующего параллельного запуска двух проектов тестов на Ванессе. На изображении представлен фрагмент нашей конфигурации. В сценарии участвуют три базы: одна подготовительная (ERP_VA_basic), а две другие (ERP_VA и ERP_VA_KlOp) предназначены для проведения самого тестирования.
В сценарии обновление подготовительной базы выполняется с учетом того, что в базе присутствует расширение, а вместе с изменениями основной конфигурации в новом релизе может прийти типовое обновление конфигурации ERP.
Сначала выполняется обновление основной конфигурации и расширения из хранилища, после этого обновляется информационная база, выполняется проверка применимости расширения и запускаются обработчики обновления. Фоновые обработчики обновления запускаются отдельно, так как без их выполнения часть пользовательских операций в базе может быть недоступна. После этого мы считаем, что наша база полностью готова к тестированию, и выгружаем ее в файл.
После обновления тестов до актуальной версии, мы параллельно восстанавливаем в две тестовые базы (ERP_VA и ERP_VA_KlOp), ранее подготовленную выгрузку и после этого также параллельно запускаем тесты.
В сценарии участвуют пакетные команды, скрипты и внешние обработки. Для наглядности приведу таблицу с комментариями по каждой строке сценария:
Архитектура и возможности системы тестирования
Выше был описан пример того, как в конфигурации «Запуск тестов» можно организовать параллельное выполнение действий в рамках одного сценария. Главным минусом такого подхода является то, что при возникновении проблемы на одном из предыдущих шагов (например, по загрузке информационных баз, очередность 10) действия следующих двух шагов по выполнению тестов не будут выполнены ни для одной из баз – то есть операции 11-ого шага не запустятся. Для того, чтобы этого избежать, в системе есть возможность разбить один сценарий на несколько (отдельные сценарии для каждой базы) и выстроить их в последовательно- параллельную цепочку. В конфигурации «Запуск тестов» это реализовано с помощью механизма «Последовательностей запуска сценариев».
На изображении приведен пример из нашей системы, показывающий, как организована параллельность:
Сценарий «Обновление базы ERP_VA_basic», включает в себя операции с базой ERP_VA_basic и выполняется первым. При успешном его выполнении запускаются сценарии «Запуск тестов ERP_VA» и «Запуск тестов ERP_VA_KlOp».
Более подробное описание представлено в таблице:
Схематически это можно представить вот так:
Мы разбиваем исходный сценарий на три отдельных, при выполнении которых операции загрузки информационной базы полностью отвязаны друг от друга. Операции внутри каждого сценария выполняются независимо от операций других сценариев.
Дополнительные возможности конфигурации 1С Запуск тестов
-
Переопределение параметров действий (шагов сценария) в рамках конкретного прогона. Иногда требуется, чтобы у каждого нового прогона сценария каждый раз были свои уникальные параметры. Например, в сценарии выгрузки очередного релиза у нас каждый раз будет его новый номер.
-
Динамическое определение состава действий конкретного прогона сценария с помощью тегов. Можно заполнять прогон только теми операциями сценария, которые соответствуют выбранным тегам. Например, у нас есть сценарий, который проверяет все печатные формы всех используемых документов какой-то информационной базы. Но в рамках нового прогона нам нужно перепроверить только тесты с тегом «ТОРГ12». Данный механизм позволит автоматически подобрать для прогона только нужные тесты.
-
Фиксация времени выполнения и контроль превышения времени операций сценария. Например, при превышении времени обновления информационной базы более одного часа мы обязаны предоставлять эту информацию вместе со своим релизом. Данный механизм помогает нам в решении этой задачи.
-
Параллельное выполнение операций и сценариев.
-
Конфигурация поддерживает тестирование версии хранилища: можно настроить мониторинг и автоматически запускать выбранный сценарий для каждой новой версии, помещенной в хранилище 1С.
По сути конфигурация «Запуск тестов» – это фреймворк автоматизированного тестирования с элементами CI системы. Возможность запускать пакетные команды, скрипты и внешние обработки позволяет конфигурировать практически любые сценарии.
Схема взаимодействия и практические результаты
На самом деле информационных баз со сценариями тестирования на конфигурации «Запуск тестов» у нас несколько. Их расположение зависит от того, как у нас организован тестовый ландшафт, и от того, как нам удобнее группировать наши сценарии: в одной базе или в нескольких. Центром у нас выступает наша TMS система 1С:Управление разработкой, которая по веб сервисам взаимодействует с базами со сценариями таким образом, что из самой TMS мы можем в нужное время запускать нужные сценарии и отслеживать ход их выполнения, а также, при необходимости, анализировать результаты выполнения конкретных операций.
Заключение
Мы сформировали свою пирамиду тестирования. Наша стратегия заключается в том, чтобы за одну итерацию проверить максимально возможное количество пользовательских операций независимо друг от друга, за один раз исправить все найденные ошибки, и только после этого запускать end-to-end-тесты, которые начинают вести себя более стабильно.
Подход отделения тестов от данных позволяет выполнять это с минимальными затратами на разработку и поддержку, а также привлекать к расширению тестовых наборов специалистов, компетентных в предметных областях. Это расширяет тестовый набор и повышает качество тестирования наших продуктов.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт