Система состоит из внешней обработки и отдельной информационной базы, работающей в качестве бэк-енд хранилища тестов и среды автоматического выполнения тестов по расписанию.
Система была предназначена и используется в платформе версии 8.1 и неуправляемых конфигурациях платформы 8.2. Для использования в управляемых конфигурациях в режиме внешней обработки необходимо переписать весь интерфейс или менять параметры конфигурации.
В связи с тем, что в бэк-енде воедино слиты два проекта, то, при желании запуска автоматических тестов, версия платформы для бэк-енда должна быть такой же, как и версия платформы тестируемой конфигурации.
Очень много картинок.
Определившись с версией платформы, и, при необходимости, настроив тестируемую конфигурацию (ТК) для запуска неуправляемой внешней обработки, создаём информационную базу бэк-енда (БЕ) из конфигурации на той же версии платформы, что и ТК.
Перед началом ввода тестов надо настроить информационную базу БЕ. Для этого надо завести нужных пользователей конфигурации:
И дать одному из них права Администратора:
После чего запускаем базу в режиме Предприятия, заходим под администратором и запускаем встроенную обработку Настройка:
Для хранения тестов различных конфигураций используется понятие Проект. Не связанные между собой конфигурации должны тестироваться в разных проектах. Если же конфигурация совершает качественный скачок в развитии, но при этом бОльшая часть тестов от предыдущей версии запускается без ошибок, то это уже новая Версия конфигурации данного Проекта.
Добавляем свой проект:
Поля Соединение с ИБ с тестами и Путь к обработке тестирования используются для выполнения автоматического тестирования. Сейчас мы их не будем заполнять, для ввода и ручного запуска тестов достаточно существования проекта в базе БЕ.
Ниже можно перечислить версии ТК, эти данные используются при запуске теста, если в этом списке не указана версия ТК, то тест не будет запущен. Поэтому заведём текущую версию вашей ТК. Версия берётся из свойств конфигурации:
Добавляем версию:
Для каждой версии ТК можно задать параметры соединения с хранилищем, где разрабатывается эта версия, тогда перед запуском автоматических тестов система попытается взять текущую версию конфигурации из указанного хранилища, накатить эту конфигурацию на тестируемую базу и только потом запустить выбранные тесты. Так же можно выполнить шелл-скрипты до запуска тестов и после. Оставляем все дополнительные поля пустыми, сохраняем созданную версию и записываем проект.
Жмём кнопку Далее:
Здесь мы видим созданные нами настройки проекта, можем добавить/удалить версии/проекты.
Ещё раз жмём Далее:
В этом окне перечислены пользователи конфигурации, тут можно задать ФИО текущего пользователя, добавить других пользователей.
Заполним текущему пользователю ФИО и выберем ему проект по-умолчанию:
Так же можно установить флажок для того, чтобы пользователь принудительно сменил свой пароль при первом входе в систему тестирования.
Сохраняем пользователя и жмём кнопку Далее:
Добавляем текущему пользователю контактную информацию:
На все указанные и включенные e-mail будут приходить отчёты по каждому результату автоматического тестирования.
Жмём кнопку Далее, перед нами форма заполнения констант:
Здесь указываются параметры для отправки генерируемых писем с результатами автоматического тестирования.
Пропускаем этот шаг и снова жмём Далее:
Перед нами окно где можно создать задания на автоматическое тестирование конфигураций.
Пока оставляем без изменений, жмём Готово.
На данный момент у нас создан один проект, у него создана одна версия текущей ТК, всё готово для добавления и выполнения тестов.
Запускаем ТК в режиме Предприятия и открываем внешнюю обработку (ВО) (ВО находится в вышеупомянутой конфигурации БЕ, называется Тестирование, её необходимо выгрузить из конфигурации в виде внешней обработки):
Заполняем форму авторизации и соединяемся с базой тестов.
В результате появится основная форма для работы с тестами:
Слева расположен список групп на которые разбиты тесты. Добавим новую группу в которой будем создавать наши новые тесты:
В выбранной группе создадим новый тест. Для примера я создал общий модуль с именем Тесты и добавил туда экспортную функцию:
Функция Сложение(Знач Аргумент1, Знач Аргумент2) Экспорт
Возврат Аргумент1 + Аргумент2;
КонецФункции
В наименовании теста я указал что я буду тестировать. В поле Модуль я указываю расположение тестируемого метода — общий модуль Тесты:
Если бы я тестировал метод, расположенный в модуле объекта справочника или документа, то дополнительно необходимо указать ссылку на конкретный объект информационной базы, т.к. метод выполняется в определённом контексте определённого объекта. В данном случае контекстом является глобальный контекст и указывать ссылку на объект контекста нет необходимости.
Далее копируем сигнатуру метода и вставляем в поле Заголовок метода:
После чего нажимаем первую кнопку в тулбаре над этим полем — Разобрать метод:
в результате заполняются поля Параметры и Результаты.
Заполняем входящие значения для аргументов:
Готово.
Теперь можно запустить тест для вычисления результатов, нажав на вторую кнопку (зелёная стрелочка) Вычисление результатов и полюбоваться на полученный результат:
Тест отработал верно — запоминаем результат как эталон, нажав третью кнопку Запомнить результаты как эталон:
Далее сохраняем нашу работу в базу тестов:
В принципе это — всё.
В тулбаре над тестами есть кнопка запуска всех тест в данной группе, в тулбаре над заголовком метода есть кнопки запуска теста и просмотр сохранённого эталонного значения.
Куча полей Перед и после выполнения, выполняемый код и т.п. были описаны в предыдущей статье.
Можете экспериментировать.
Бинарники пока что выложены на GitHub. Если у кого-то возникнет желание доработать, исправить ошибки, то, пожалуйста, поделитесь вашими наработками с сообществом. Пока что я не представляю как правильно коллективно разрабатывать конфигурации 1С синхронизируясь через интернет. 1С-ный сервер хранилища — бесполезная надстройка надо файловым доступом и я не вижу смысла его разворачивать. Выгрузка/загрузка конфигурации в xml реализована только в 8.3, возможно это единственный нормальный путь, но существуют конфигурации и под 8.1 и 8.2, которые тоже нужно тестировать. Так что пока пусть будет GitHub, если будет реальная потребность — будем думать.
Код распространяется под лицензией GPLv2, т.е. — публикуйте свои изменения в коде, если вы его используете.
Нереализованные мечты:
— Это, конечно, смешно, но тестов на конфигурацию тестирования нет. Было бы неплохо начать их писать.
— Рефакторинг кода. Код не идеальный, где-то и костыли и прочие плохо-пахнующие конструкции используются. В проект добавлялся код других разработчиков, этот код пристально не ревьювился, могут быть удивительные места.
— Разграничить права доступа по проектам. Сейчас любой пользователь имеет доступ к любому проекту, по-хорошему надо бы сделать так, чтобы каждому пользователю назначались только нужные ему проекты. В идеале было бы сделать полноценную систему ролей — права на добавление теста, на запуск группы тестов и т.п.
— Переделать формы на управляемые. Даст возможность тестирования управляемых конфигураций без изменения настроек этих конфигураций в режим совместимости или включения внешней обработки как встроенной. По большому счёту вся модель работы с тестами вынесена в модуль внешней обработки, а в модулях форм остался лишь связующий код контроллеров.
— Разделить хранилище тестов и среду автоматического тестирования на две конфигурации, это даст возможность использовать для хранилища тестов любую версии платформы, и вынести автоматическое тестирование на другой компьютер. В принципе внутренняя архитектура этих частей уже разделена, осталось произвести это разделение и заменить прямое обращение от среды выполнения тестов к информационной базе хранилища тестов на подключение к хранилищу и вызов уже существующих методов через это подключение.
— Доработка функционала и улучшение интерфейса.
ссылка на оригинал статьи http://habrahabr.ru/post/215409/
Добавить комментарий