Автоматизированное тестирование 1с это
Автоматизированное тестирование помогает улучшить качество продукта, и поэтому оно достаточно широко используется при разработке/тестировании самых разных проектов. Платформа «1С:Предприятие» также позволяет выполнять автоматизированное тестирование и имеет для этого все необходимые инструменты. Эта статья рассказывает о том, что это за инструменты и как ими пользоваться.
Общая информация
Итак, автоматизированное тестирование прикладных решений — это часть процесса тестирования, которая представляет собой имитацию действий пользователя, а также получение и оценку результатов этих действий.
Автоматизированное тестирование выполняется при помощи двух клиентских приложений и сценария тестирования.
Сценарий тестирования — это программа на встроенном языке «1С». Сценарий описывает последовательность выполняемых действий и, если нужно, проверяет результаты выполнения этих действий. Для этого во встроенном языке имеются специальные объекты.
Менеджер тестирования — это клиентское приложение (толстый или тонкий клиент) запущенное в соответствующем режиме. В этом приложении исполняется сценарий тестирования и производится оценка результатов (если нужно).
Клиент тестирования — это клиентское приложение (толстый, тонкий или веб-клиент). Это приложение получает от менеджера команды, воспроизводит их и возвращает результат.
Все вышеописанное отлично иллюстрирует изображение с сайта «1С»:
Схема автоматизированного тестирования в «1С»
Запись действий пользователя
Написание более или менее серьезного теста представляется очень трудоемкой задачей — нужно в коде описать все необходимые действия: нажатия на кнопки, выборы из списков, заполнения полей ввода и тд.
К счастью имеется способ серьезно упростить работу — записать журнал действия пользователя. Запуск этого режима производится из конфигуратора:
Запуск записи действий пользователя из конфигуратора
Или из командной строки:
C:\Program Files\1cv8\common>1cestart.exe ENTERPRISE /IBName "Тестовая база" /UILogRecorder
После запуска в правом верхнем углу основного окна приложения появятся кнопки для управления записью действий пользователя:
Управление записью действий пользователя
С помощью этих кнопок запись можно:
- начать/приостановить/продолжить;
- прекратить;
- завершить.
Начав запись, сделав какие-либо действия и завершить запись, мы увидим некий XML-документ, например такой:
Пример записи действий пользователя
Выглядит все это вот так:
Преобразование XML в код на встроенном языке
Обработке можно скормит текст или имя файла, попросить сгенерировать код подключения к клиенту и указать некоторые другие настройки.
Запуск системы тестирования
Запустить клиентское приложение в режиме менеджера тестирования или клиента тестирования можно из конфигуратора или при помощи командной строки.
В конфигураторе нужно пройти в меню «Сервис»-«Параметры», затем открыть вкладку «Запуск 1С:Предприятия»-«Дополнительные» и выбрать требуемый режим запуска:
Настройка запуска «1С:Предприятия»
Запуск из командной строки в режиме менеджера тестирования выглядит примерно так:
C:\Program Files\1cv8\common>1cestart.exe ENTERPRISE /IBName "Тестовая база" /TestManager
А в режиме клиента тестирования так:
C:\Program Files\1cv8\common>1cestart.exe ENTERPRISE /IBName "Тестовая база" /TestClient -TPort 2000
При запуске в режиме клиента можно указать номер порта (по умолчанию 1538), это нужно в том случае, если запущено несколько клиентов тестирования.
Текущий режим будет указан в заголовке главного окна:
Заголовок главного окна в режиме менеджера
Заголовок главного окна в режиме клиента
Создание и область применения тестов
Для создания полноценного теста, как правило, недостаточно преобразовать запись действий пользователя в код на встроенном языке. Но подобный инструмент позволяет избежать неинтересной механической работы и помогает понять принцип написания тестов.
В написании текста также может помочь схема объектов для имитации интерактивных действий:
Схема объектов для имитации интерактивных действий
А также синтаксис-помощник в котором имеется подробная информация о каждом из этих объектов.
Самым простым вариантом запуска теста будет создать обработку (можно внешнюю) и просто засунуть в нее имеющийся код теста и запустить из менеджера тестирования.
Основной областью применения автоматизированного тестирования мне представляется (возможно я неправ) проверка работоспособности существующего функционала при добавлении нового (часто бывает, что при добавлении нового ломается старое).
На этом все, надеюсь, что данная статья была Вам полезна.
Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
(оценок: 2, средняя оценка: 3,50 из 5)
В данной статье будет рассмотрен новый механизм системы "1С:Предприятие 8" поддерживаемый начиная с платформы версии 8.3.
Механизм позволяет легко и быстро создавать различные сценарии тестирования, без необходимости написания сложных процедур и функций для имитации действий пользователя.
Начиная с версии 8.3 платформа позволяет записать действия пользователя (переход по интерфейсу, нажатие кнопок, ввод текста в поля ввода и т.п.) и сохранить все действия в XML файл для дальнейшего использования при тестировании. Основное назначение данного механизма - сценарное тестирование, но думаю, что при большом желании можно устроить нагрузочное тестирование или использовать механизм при оптимизации системы (анализ ожидания на блокировках, поиск дедлоков и т.п.). Ниже я более подробно опишу настройку тестов.
Я не буду переписывать информацию с сайта 1С, а сразу перейду к описанию настройки теста. Перед созданием теста необходимо записать действия пользователя, для чего необходимо з апустить предприятие в режиме записи действий пользователя из конфигуратора:
После чего в клиентском приложении станут доступны команды управления записью журнала.
При помощи данных команд можно начать/приостановить запись журнала, прервать запись (без сохранения) или прекратить запись с отображением XML текста содержащим информацию о пользовательских действиях, который потребуется для дальнейшей настройки.
В работе с обработкой сложностей не должно возникнуть, рекомендую установить флаг для генерирования кода подключения к клиенту и установить значение переключателя "Преобразовывать" в "Текст". Далее копируем XML текст в поле "Журнал действий пользователя", выполняем команду "Преобразовать" и в текстовом поле "Сценарий" появится программный код для запуска тестирования, который в дальнейшем нам понадобится. Ниже рассмотрю основную процедуру выполняющую подключение к клиенту и запуск теста, в моем случае процедура называется "ТестовыйСценарий_06_03_2014".
&НаКлиенте
Процедура ТестовыйСценарий_06_03_2014 ()
//Создание объекта "ТестовоеПриложение" при помощи которого будет выполняться
//подключение к клиенту тестирования.
//Параметры:
// ИмяКомпьютера - Имя или IP адрес компьютера на отором запущено приложение клиента тестирования.
// Порт - Порт по которому будет выполняться подключение к клиенту тестирования. По умолчанию 1538,
// если необходимо на одном компьютере запускать несколько клиентов, их нужно разнести по разным портам.
// ИдентификаторКлиента - Идентификатор веб-клиента.
ТестовоеПриложение = Новый ТестируемоеПриложение ();
//Далее выполняется попытка подключения к клиенту тестирования.
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь;
ОписаниеОшибкиСоединения = "" ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение . УстановитьСоединение ();
Подключен = Истина;
Прервать;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки;
КонецЦикла;
Если Не Подключен Тогда
ТестовоеПриложение = Неопределено;
Сообщить ( "Не смогли установить соединение! " + Символы . ПС + ОписаниеОшибкиСоединения );
Возврат;
КонецЕсли;
//Если подключение к клиенту тестирования прошло успешно, запускаются управляющие процедуры
//имитирующие пользовательские действия.
ОкноПриложенияОсновноеКнопкаКомандногоИнтерфейсаПриходнаяНакладнаяНажать ( ТестовоеПриложение );
ОкноПриложенияПриходнаяНакладнаяКнопкаСоздатьНажать ( ТестовоеПриложение );
ОкноПриложенияПриходнаяНакладнаяСозданиеПолеНоменклатураВыбрать ( ТестовоеПриложение );
ОкноПриложенияНоменклатураТаблицаСписокВыбрать ( ТестовоеПриложение );
ОкноПриложенияПриходнаяНакладнаяСозданиеКнопкаПровестиИЗакрытьНажать ( ТестовоеПриложение );
Далее, в самом простом варианте, необходимо создать новую обработку (не важно, внешняя или встроенная), добавить управляемую форму на которой разместить команду выполняющую процедуру подключения к клиенту и запуска тестового сценария.
&НаКлиенте
Процедура ТестовыйСценарий_06_03_2014 ()
//.
КонецПроцедуры
Обращаю внимание, что если во время теста вводились числа больше 999 (количество, суммы и т.п.) при преобразовании в XML платформа автоматически не удаляет разделитель групп (по умолчанию неразрывный пробел) и его необходимо удалить в самих процедурах!
Для выполнения тестового сценария, необходимо как минимум два клиентских приложения, запущенных в режиме менеджера тестирования и в режиме клиента тестирования соответственно . Есть два варианта запуска приложений:
1. В параметрах конфигуратора (Сервис - Параметры) перейти на закладку "Запуск 1С:Предприятия", раскрыть вкладку "Дополнительно", в группе "Автоматизированное тестирование" выбрать необходимы режим запуска. Т.е. вручную запустить менеджер тестирования и необходимо количество клиентов, перед каждым запуском нужно выбрать необходимый режим и для клиентов указать различные порты (если клиент один, оставить порт по умолчанию).
2. Автоматически запускать менеджера и клиентов тестирования используя ключи "/TESTMANAGER" и "/TESTCLIENT" соответственно . Ниже приведен пример программного кода 1С для файлового варианта (необходимо изменить версию платформы, путь до информационной базы и если запускается более одного клиента тестирования указать порт).
ЗапуститьСистему ( "C:\Program Files (x86)\1cv8\\bin\1cv8.exe ENTERPRISE /F /N Администратор / TESTMANAGER " );
ЗапуститьСистему ( "C:\Program Files (x86)\1cv8\\bin\1cv8.exe ENTERPRISE /F /N Администратор /TESTCLIENT [-TPort] " );
Все действия по настройке теста закончены, осталось на менеджере тестирования запустить выполнение обработки. После подключения к клиенту тестирования менеджер передаст на выполнение команды и в окне клиентского приложения будут эмулироваться все действия пользователя, записанные при создании журнала действий пользователя.
Ниже, привожу пример простого программного кода по работе с двумя клиентами тестирования:
&НаКлиенте
Процедура ТестовыйСценарий_06_03_2014 ()
ТестовоеПриложение1 = Новый ТестируемоеПриложение (); //Порт по умолчанию 1538
ТестовоеПриложение2 = Новый ТестируемоеПриложение (, 1539 );
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь;
ОписаниеОшибкиСоединения = "" ;
//Подключение к первому клиенту тестирования
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение1 . УстановитьСоединение ();
Подключен = Истина;
Прервать;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки;
КонецЦикла;
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
//Подключение ко второму клиенту тестирования
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение2 . УстановитьСоединение ();
Подключен = Истина;
Прервать;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки;
КонецЦикла;
Если Не Подключен Тогда
ТестовоеПриложение1 = Неопределено;
ТестовоеПриложение2 = Неопределено;
Сообщить ( "Не смогли установить соединение! " + Символы . ПС + ОписаниеОшибкиСоединения );
Возврат;
КонецЕсли;
//Для каждого клиента скопируем процедуры тестирования.
ОкноПриложенияОсновноеКнопкаКомандногоИнтерфейсаПриходнаяНакладнаяНажать1 ( ТестовоеПриложение1 );
ОкноПриложенияОсновноеКнопкаКомандногоИнтерфейсаПриходнаяНакладнаяНажать2 ( ТестовоеПриложение2 );
ОкноПриложенияПриходнаяНакладнаяКнопкаСоздатьНажать1 ( ТестовоеПриложение1 );
ОкноПриложенияПриходнаяНакладнаяКнопкаСоздатьНажать2 ( ТестовоеПриложение2 );
ОкноПриложенияПриходнаяНакладнаяСозданиеПолеНоменклатураВыбрать1 ( ТестовоеПриложение1 );
ОкноПриложенияПриходнаяНакладнаяСозданиеПолеНоменклатураВыбрать2 ( ТестовоеПриложение2 );
ОкноПриложенияНоменклатураТаблицаСписокВыбрать1 ( ТестовоеПриложение1 );
ОкноПриложенияНоменклатураТаблицаСписокВыбрать2 ( ТестовоеПриложение2 );
ОкноПриложенияПриходнаяНакладнаяСозданиеКнопкаПровестиИЗакрытьНажать1 ( ТестовоеПриложение1 );
ОкноПриложенияПриходнаяНакладнаяСозданиеКнопкаПровестиИЗакрытьНажать2 ( ТестовоеПриложение2 );
В результате выполнения данной процедуры менеджер тестирования подключается ко всем инициализированным клиентам тестирования и параллельно запускает на них выполнение теста.
Я вижу следующие варианты использования данного механизма:
1. Вы сотрудник службы технической поддержки и при появлении у пользователя сложной проблемы Вы хотите посмотреть, что именно пользователь выполняет в системе.
Для решения подобной задачи, можно создать bat-файл для запуска системы в режиме клиента тестирования и использовать методы тестового приложения "НачатьЗаписьЖурналаДействийПользователя" и "ЗавершитьЗаписьЖурналаДействийПользователя" для получения журнала. Ниже привожу пример программного кода:
&НаКлиенте
Процедура Запустить ( Команда )
ТестовоеПриложение = Новый ТестируемоеПриложение ();
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь;
ОписаниеОшибкиСоединения = "" ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение . УстановитьСоединение ();
Подключен = Истина;
Прервать;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки;
КонецЦикла;
Если Не Подключен Тогда
ТестовоеПриложение = Неопределено;
Сообщить ( "Не смогли установить соединение! " + Символы . ПС + ОписаниеОшибкиСоединения );
Возврат;
КонецЕсли;
В результате получится XML текст, который в дальнейшем может быть преобразован в обработку для повторения ошибки пользователя. После исправления ошибки данную обработку можно использовать для тестирования.
2. Не для кого не секрет, что при разработке новых возможностей системы зачастую появляются ошибки в ранее разработанном функционале. Для полноценного тестирования можно заранее создавать тестовые сценарии исправного функционала и выполнять их перед выпуском новых релизов.
3. Для разрешения проблем ожиданий на блокировках или дедлоков. Можно создать несколько тестов, которые явно приведут к проблеме производительности для дальнейшего расследования.
4. Проведение нагрузочного тестирования. Фирма 1С позиционирует функционал как механизм сценарного тестирования, но по большому счету не запрещает запускать большое количество клиентов тестирования. В обработчики можно вставить генераторы случайных чисел для разнородности вводимой информации. На момент написания статьи, мне не известны примеры подобного нагрузочного тестирования, при получении новой информации я обновлю публикацию.
Рассмотренный в статье механизм может существенно облегчить процесс разработки и тестирования бизнес приложений на базе платформы "1С:Предприятие 8", но на момент написания статьи я рекомендую использовать его в ознакомительных целях, т.к. механизм довольно новый и возможно, еще не до конца отлажен разработчиками.
Все комментарии и дополнения по тексту статьи я с радостью жду в комментариях!
Мобильные приложения на 1С становятся сложнее – и усложняется задача по их тестированию.
С другой стороны, современные технологии Git + 1C:EDT и автотестирование, которое появилось в новой мобильной платформе 8.3.20, могут значительно облегчить процесс разработки на мобильной платформе. Причем 1C:EDT идеально подходит для мобильных решений, так как с конфигурациями такого размера справляется мгновенно.
Однако есть проблема – и она не техническая. Есть банальный дефицит понимания и сумма мифов:
- 1C:EDT плохо работает с мобильной платформой, так как 1C:EDT до сих пор не может ее установить через adb
- В 1C:EDT есть проблемы с отладкой мобильных приложений
- В 1C:EDT нет представления мобильных форм
А в части автотестов:
- Накликивать на устройстве тесты неудобно
- Нет инструмента тестирования с поддержкой мобильной платформы
- Не получится тестировать интерактивный функционал, например, проверить, что фото делается/сделалось, или проверить отмену фото.
И дальше будут в основном производные от этих «истин».
А что, если это не совсем так? :)
В этих двух видео мы разберем эти утверждения и попробуем расставить все точки над «Ё» :)
Видео № 1
Как сделать УДОБНОЙ разработку на базе мобильной платформы в 1C:EDT
В этом видео Дмитрий (IRP Team) расскажет, как:
- Подключить мобильное устройство в режиме отладки по Wi-Fi
- Отображается экран устройства внутри 1C:EDT
- Решить проблемы, связанные с отладкой
- Сэкономить место, «убедив» 1C:EDT, что установлена полноценная Android SDK (EDT по умолчанию требует SDK, которое весит 3 Gb – покажем, что это не обязательно).
Тайминг ключевых моментов видео
01:09 – импорт конфигурации и влияние параметра области применения на доступные опции в 1C:EDT
02:05 – добавление мобильной платформы в 1C:EDT и подстановка adb без SDK
05:10 – подключение мобильного устройства в режиме дебаг через WiFi
10:10 – создание конфигурации отладки мобильного приложения
12:54 – установка приложения через adb
15:53 – отображение нашего реального устройства внутри 1C:EDT
16:39 – решение проблем, связанных с отладкой мобильных устройств в 1C:EDT
21:10 – выводы.
Видео № 2
Как протестировать приложение на мобильной платформе 1С
В этом видео Наталья из команды (IRP Team) покажет, как:
- Подключить Android эмулятор как тест клиент
- Настроить VA для работы с мобильными устройствами
- Выполнить запись сценария, накликивая его в эмуляторе мышкой
- Воспроизвести сценарий при помощи VA на мобильном клиенте
- Воспроизвести сценарий на мобильной платформе
- Написать тест создания фотографии камерой устройства (интерактивное взаимодействие с камерой).
Тайминг ключевых моментов видео
00:09 – почему важно тестировать мобильные приложения в режиме автотестов
02:45 – цикл тестов для мобильных устройств
03:49 – особенности окружения
05:38 – создание и запуск тестового сценария
07:45 – решение проблемы интерактивного взаимодействия
10:15 – отчет о выполнении тестов.
Необходимые настройки
Сейчас в платформе есть ошибки фичи, поэтому надо придерживаться следующих настроек:
- В базе менеджера тестирования не должно быть пользователей. Вообще никаких, даже без пароля. Как следствие, чтобы работала VA, надо прописать в файле C:\Program Files\1cv8\conf\conf.cfg строку DisableUnsafeActionProtection=.*
- Порт тестирования должен быть 1538, на другом работать не будет.
Полезные инструменты, упомянутые в видео
Выводы
Если вы работаете с мобильной платформой – это прямо удобный шанс перейти на современные технологий.
В случае стационарной 1С покрыть код тестами и поддерживать их актуальными или сразу всем отделом перепрыгнуть на 1C:EDT – задача нетривиальная, а покрыть тестами мобильный функционал, вести в 1C:EDT разработку небольшой конфигурации и потихоньку писать маленькие скрипты сборки (или брать готовые) на oscript – это значительно проще.
И «выхлоп» будет чуть ли не через пару дней, после первого же пойманного автотестами бага :)
Сегодня будем решать две однотипные проблемы, которые появились у слушателей курса по тестированию:
- Я начинаю учиться на курсе по 1С – где ее взять?
- Я хочу запустить автоматическое тестирование – где взять отдельную лицензию?
С обучением это еще более-менее решается – можно использовать учебную версию платформы, но для многих задач она не подходит, поскольку имеет свои ограничения.
Для тестирования и вовсе отпадает в силу главного ограничения: Количество одновременно запущенных сеансов информационной базы ограничено одним сеансом.
А для тестов нужно как минимум 2 сеанса: 1-й – для менеджера тестирования и 2-й – для клиента тестирования. В некоторых ситуациях даже больше двух.
И далее мы смотрим на ситуацию глазам QA-инженера, которому не нужно что-то кодировать, но нужно как-то запускать свои 2 сессии для тестировани.
При этом будущий QA-инженер понимает, что
- ему вряд ли дадут доступ к серверу с нужными базами для проведения тестирования
- возможно никто не выделит ему отдельную лицензию для установки на свой локальный компьютер, так как компании используется многопользовательская лицензия на сервере
Хотя есть еще вариант – поставить эту учебную версию платформы, обучиться, через пару месяцев сдать экзамен, и тогда купить лицензию со скидкой 90% для разработчика 1С, как это описано здесь. Но это, как бы сказать… Не быстро как-то…
А что, если можно установить обычную версию 1С, которой будет достаточно для обучения и экспериментов с тестированием, не нарушая политики лицензирования 1С?
Что потребуется для установки
Рассмотрим ситуацию, когда Вы работаете в компании, где уже используется конфигурация 1С, и Вы хотите начать писать тесты.
Вам потребуются только две вещи:
- Платформа 8.3.20 (не ниже)
- База данных (не выгрузка базы в dt, а именно файловая база)
Платформу можно взять у IT-отдела или скачать с сайта ИТС. А в качестве базы данных можно взять демо-базу конфигурации, которая используется у Вас в компании.
Если у вас недостаточно мощный компьютер, то развернуть на нем конфигурацию типа 1С:ERP УП будет довольно сложно. Но для этих целей можно попросить у IT-отдела демо конфигурацию «Управляемое приложение», которая доступна для скачивания на сайте ИТС рядом со ссылками на платформу.
Установка платформы
Давайте теперь разберемся с тем, как устанавливать платформу. Обязательное требование – версия платформы не ниже 8.3.20, это важно, иначе может отличаться синтаксис.
Платформу Вы получите в виде архива, который надо распаковать и запустить файл setup.exe.
И нажимаем Далее:
Тут надо выбрать только две опции 1С:Предприятие – Тонкий клиент и Сервер 1С:Предприятие 8, и жмем Далее.
И снимаем флажок с установки сервера:
Потом нажимаем Далее, и затем будет еще одно окно с настройкой лицензий – там снимаем верхний флажок, так как нам не нужно устанавливать драйвер защиты.
Автономный сервер
Что именно нам нужно от платформы – так это автономный сервер. Это технология сейчас находится в бета версии, но нам для обучения ее будет вполне достаточно, так как автономный сервер позволяет запускать до трех клиентских сеансов без лицензии.
А этого нам, будущим QA-инженерам, будет достаточно, так как для написания тестов нам достаточно и двух сессий – одна в режиме TestManager, другая – TestClient.
Чтобы убедиться в том, что автономный сервер установился, зайдем в папку найдем вот такой файл:
Обратите внимание – в вашем случае путь может отличаться.
Подключение базы данных
Следующий этап – это подключение базы.
Где взять базу для тестирования – решать вам (я писал об этом выше), я же буду показывать на примере конфигурации IRP (которую без проблем можно использовать для обучения):
Распаковываем желательно по короткому пути, чтобы не было пробелов, кириллицы, спецсимволов и прочего (в теории – это не должно влиять, но опыт подсказывает другое):
Обратите внимание на то, что это не файл выгрузки базы данных с расширением .dt, а это именно файловая база 1Cv8.1CD.
Запускаем автономный сервер
Для этого идем в папку, где установлена 1С, и находим файл ibsrv. Кликаем по нему правой кнопкой мыши и отправляем ярлык на рабочий стол:
Далее идем на рабочий стол и кликаем по ярлыку правой кнопкой мыши, выбираем Свойства и прописываем путь к базе:
То есть в конце строки ставим пробел и дописываем:
Если в пути есть пробелы, то путь базы нужно взять в кавычки.
Сохраняем изменения и запускаем этот ярлык. После этого должно появиться вот такое черное окно:
Его закрывать нельзя: если закроете, то не сможете попасть в базу – тогда нужно будет его снова запустить.
И мы сможем попасть в базу:
В базе уже есть данные, с которыми можно писать простые тесты и обучаться.
Подключаем базу в список баз
И последний этап – это подключить базу в режиме тест менеджера и проверить, что все работает. Запускаем ярлык 1С, нажимаем Добавить, выбираем опцию Добавить существующую базу, и указываем путь к базе:
Нажимаем Далее и не забываем указать ключ /TestManager:
Теперь давайте запустим базу и убедимся, что она открылась в режиме менеджера тестирования:
Спасибо компании 1С за интересный инструмент!
Подведем итог
Может показаться, что в статье мы просто рассказали, как скачать конфигурацию и установить платформу, прописав некоторые параметры в ярлыке. Но для организации процесса тестирования этого будет достаточно.
Да, конфигуратор запустить не получится, и если Вы хотите открывать любую конфигурацию и не испытывать ограничений в работе, то придется приобрести лицензию.
Используя учебную платформу, Вы сможете зайти в конфигуратор или запустить толстый клиент, но сама учебная платформа ограничит Вас в количестве сеансов, которые необходимы для процесса тестирования.
Поэтому не упускайте шанс запустить 1С официально без лицензий, а то вдруг 1С уберет эту функциональность (хотя, вряд ли).
До релиза новой версии фреймворка по тестированию “xUnitFor1C” осталось совсем немного, а значит пришло время рассказать о проделанной работе и о том, что ожидает пользователей.
Релиз получится действительно мажорным, изменений очень много, и они носят глобальный характер. Но обо всем по порядку.
Зачем все перепиливать?
Насколько я понимаю, на момент, когда проект только рождался, основной целью было понять, насколько модульное тестирование может быть востребовано в среде 1С. Понятное дело, что продумывать и выделять уровни абстракций на этапе прототипирования — дело не особо перспективное. Прототип не обладает эластичностью настоящего кода. Прототип — это эксперимент, результаты которого нужно выбрасывать.
Далее флаг разработки переходил от одного энтузиаста к другому, при этом базовая архитектура оставалась прежней. С ростом популярности продукта и осознания того, что хотелось бы получить, стало все сложнее вносить изменения.
Мне нравится метафора Алана Купера:
Создание большой программы можно сравнить с постройкой столба из кирпича. Этот столб состоит из тысячи кирпичей, положенных один на другой. Столб может быть выстроен, только если класть кирпичи с большой точностью. Любое отклонение приведет к падению кирпичей. Если кирпич с номером 998 сможет отклонить на пять миллиметров, столб, вероятно, сможет выдержать тысячу кирпичей, но если отклонение на 5-ом кирпиче, столб никогда не станет выше трех десятков.
Архитектура, существовавшая с прототипа, была тем самым отклонением на 5-ом кирпиче, которая не позволяла добавить новый функционал, который нам так хотелось — тестирование в стиле BDD, в частности, использование Gherkin. Есть мнение, что нужно выбирать что-то одно. Либо TDD либо BDD. Поработав по принципам гибкого тестирования, я понял, что модульные и сценарные тесты ни в коем случае не должны противопоставляться, они прекрасное дополнение друг к другу!
Вот так выглядит матрица гибкого тестирования:
Модульные тесты относятся к квадранту 1 — низкоуровневые тесты. Предназначены для проектирования слабо-связанной, эластичной, тестируемой архитектуры. Они выполняют для разработчика ту же роль, что и страховочный трос для скалолаза. При этом они достаточно дешевые в разработке и содержании.
Сценарные тесты относятся к квадранту 2 — тесты более высокого уровня. Нужны, чтобы убедится, что мы правильно понимаем то, что нужно сделать. Это мостик между бизнесом и разработкой, возможность говорить на одном языке. Прекрасная документация, которая никогда не устареет. При этом они дороже в создании и более хрупкие.
По мне так прекрасная синергия. Я считаю, что для создания высококачественного ПО нужно использовать оба подхода вместе! Совмещенные тесты обоих видов создают отличную защиту от регрессии.
Немного забегу вперед и скажу, что на новом движке еще не реализовано тестирование в стиле BDD, но фундамент полностью подготовлен. Сценарное тестирование — это следующий шаг.
Архитектура
Она полностью переработана. Инструмент стал намного гибче и проще в разработке. Теперь это не обработка с 8,5к строк кода, теперь это ядро с системой плагинов. Да-да, тут нет ошибки, в 1С можно сделать фреймворк, который будет расширяться плагинами.
В качестве плагинов выступают внешние обработки, располагающиеся в папке “Plugins” и реализующие следующий базовый интерфейс:
Обращение к плагину происходит по идентификатору, например:
Работу ядра теперь можно грубо выразить в виде единственной функции:
КаноническийРезультатТестирования = ВыполнитьТесты(КаноническоеДеревоТестов);
Возникает резонный вопрос: “Что за канонические дерево тестов и результат тестирования?”.
Откуда берутся канонические деревья с тестами и как это способствует универсализации?
- Пользователь выбирает Загрузчик, которым хочет воспользоваться;
- Далее определяется путь для поиска тестовых сценариев (возможно интерактивно). При этом путь — это просто некая строка, которую умеет верно интерпретировать выбранный загрузчик. Например, это может быть путь в файловой системе или путь в дереве метаданных конфигурации или … все что угодно;
- По выбранному пути производится поиск тестовых сценариев;
- По найденным сценариям формируется дерево тестов для ядра, при этом в путях у листьев дерева указываются некие строки (аналогично п.2), которые умеет верно интерпретировать выбранный загрузчик;
- Когда идет выполнение тестов, ядро для разрешения путей у листьев дерева обращается к соответствующему загрузчику.
Функция ВыбратьПутьИнтерактивно(ТекущийПуть = "") — клиентский метод для интерактивного выбора пути для загрузки тестов;
Функция Загрузить(КонтекстЯдра, Путь) — поиск тестовых сценариев и построение канонического дерева тестов;
Функция ПолучитьКонтекстПоПути(КонтекстЯдра, Путь) — получение тестового контекста по переданному пути.
- ЗагрузчикФайлов — загрузчик модульных тестов из epf файлов. В качестве путей использует пути к файлам файловой системы;
- ЗагрузчикКаталогов — построен поверх загрузчика файлов. В качестве пути для поиска принимает путь к каталогу файловой системы. В остальном полностью полагается на загрузчика файлов;
- ЗагрузчикИзПодсистемКонфигурации — в качестве путей использует дерево метаданных конфигурации в строковом представлении. Например, “Метаданные.Обработки.Тест_Обработка”. API тестовых обработок заимствует загрузчика файлов.
А что делать с каноническими результатами тестирования?
После того как ядро переработало дерево тестов в результат тестирования, оно его передает еще одному специальному типу плагина “ГенераторОтчета”.
- ГенераторОтчетаMXL — moxel-формат отчета, который сейчас используется при интерактивной работе с инструментом;
- ГенераторОтчетаJUnitXML — junit.xml отчет, который используется в непрерывной интеграции (CI).
Функция СоздатьОтчет(КонтекстЯдра, РезультатыТестирования) — формирование отчета в формате предлагаемом плагином. Результаты тестирования передаются плагину в каноническом для ядра формате;
Процедура Показать(Отчет) — клиентский метод для интерактивного показа сформированного отчета. Плагин сам определяет, как именно нужно оформить для пользователя сформированный им отчет;
Процедура Экспортировать(Отчет, ПолныйПутьФайла) — сохраняет отчет по указанному пути, в основном используется для целей CI.
Полезняшки
Всякие “полезняшки” имеют тип плагина “Утилита”. Как правило, выполняют библиотечную или сервисную функцию. Например, библиотека утверждений в стиле BDD — плагин “УтвержденияBDD”, о котором я писал в своей прошлой статье. “СериализаторMXL” — сервисный плагин, который занимается сериализацией данных базы в moxel-формат и обратно.
Послесловие
До влития в основной ствол разработки, исходники доступны по ссылке.
Теперь можно утверждать, что фреймворк вырос из “просто инструмент для модульного тестирования” в “инструмент позволяющий покрыть почти все возможные виды автоматического тестирования”. Он модульный, четко разделен по слоям, легко может дорабатываться и расширяться. Кажется, текущее название перестало передавать назначение продукта. Может, пришло время изменить название? Если у вас есть хорошая идея для названия, не стесняйтесь поделиться.
Читайте также: