1с сценарное тестирование 3.0 10 начало работы. Инструменты тестирования для тех, кому жалко тратить свое время на рутину

Здравствуйте, друзья!

Предлагаю вашему вниманию небольшую конфигурацию для сценарного тестирования решений на базе 1С:Предприятие 8.3, управляемые формы.

Конфигурация называется Тестер. Тестер является средой разработки и запуска сценарных тестов. Тестер не является продуктом BDD в чистом виде и не предназначен для описания поведения системы, до того, как она была разработана.

Главные цели Тестера:

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

Используя тестер, вы можете рассчитывать на решение следующих задач:

1. Высокая степень покрытия функционала. Тестер хорошо сфокусирован на процесс разработки тестов, что положительно сказывается на количестве и качестве создаваемых тестов
2. Тесты пишутся на языке программирования 1С, что является не только знакомым инструментом, но также позволяет использовать в тестировании весь набор функций платформы, а главное – позволяет управлять ходом тестирования программно, не опираясь на заложенную модель в инструменте тестирования
3. Из тестов можно делать библиотеки, например, можно создавать тесты, которые по переданным параметрам открывают окно поиска в динамическом списке, или формируют некий отчет. Если вам нужно для своего теста иметь остаток на складе, можно реализовать библиотечный тест, в который вы передадите состав требуемого остатка, и этот остаток будет оприходован
4. Простая проверка бизнес логики, без сравнения с данными других баз, без прямых запросов к тестируемому приложению, без макетов с сериализованными «в другом месте» данными. Вся информация может быть сохранена в самом тесте, в макете, при необходимости – доработана.
5. Кроме того, что все тесты хранятся в базе, и любой пользователь Тестера может использовать написанный другим программистом тест, Тестер имеет возможность инкрементальной выгрузки/загрузки тестов в файловую систему. Это может быть полезно для дальнейшей синхронизации тестов с системами контроля версий, например, Git.

В демонстрационной базе разработана небольшая инфраструктура взаимосвязанных тестов, которая может быть взята на вооружение при разработке ваших собственных тестов. Также, в базе есть пример создания документа Заказ поставщику для ERP2 (демо).

Для конфигурации ERP2 (демо), был создан репозиторий https://github.com/grumagargler/ERP2
Туда я выгрузил демонстрационные тесты. Надеюсь, это начинание не останется без внимания энтузиастов, и тесты будут пополняться.

Наиболее исчерпывающую информацию по Тестеру вы найдете в справке, она будет на рабочем столе, при запуске системы. В справке есть раздел Быстрый старт, я рекомендую с ним ознакомиться.

Тестер бесплатный. Разрабатывается и поддерживается для собственных нужд, без какой-либо коммерческой подоплеки.

Спасибо за проявленный интерес к системе и удачных вам тестов друзья!

Обновление 1.3.2.7

Добавлена процедура LogError (ЗаписатьОшибку), используется для программного добавления сообщений в журнал ошибок из кода сценария без остановки выполнения сценария

Все функции по работе с полями теперь умеют производить навигацию по табличной части, например, так можно проверить в пятой строке сумму начисления: Проверить ("#Начисления / Результат [ 5 ]", 1000);

Функция Check (Проверить) пытается проверять числовые значения без учета разделителя триад и дробной части

Добавлен Журнал запуска, где регистрируются события выполнения сценариев

Добавлен переход из сценария в Журнал запуска и Журнал ошибок

Добавлен помощник в дерево выбора полей

В помощник добавлена онлайн-справка по встроенным методам тестера

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

Добавлены отчеты: Протокол, Сводка (отчеты будут работать только для вновь запущенных сценариев данного релиза). Существует возможность настройки расписания отсылки отчетов по почте (при формировании отчетов учитываются RLS пользователей)

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

Оптимизирована выгрузка сценариев в файлы. Выгружаемые файлы формируются в формате bsl

Порядок перехода:

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

Внимание! Конфигурация выложена на базе версии 8.3.10, но работа ранних версий также поддерживается. Для этого, необходимо под версией 8.3.10 установить необходимый конфигурации режим совместимости, сохранить конфигурацию в файл и использовать его в качестве обновления.

В статье рассмотрен новый механизм автоматизированного тестирования, который впервые появился в платформе в редакции 8.3. Изучив материал статьи, вы узнаете:

• Что представляет из себя автоматизированное тестирование в платформе?
• Как и когда им пользоваться?
• Что и где нужно настроить, чтобы его запустить?
• Как написать сценарий автоматизированного тестирования?

Применимость

В статье рассматривается платформа «1С:Предприятие» редакции 8.3.4.465. В актуальной версии платформы возможности механизма автоматического тестирования существенным образом расширены, однако на актуальность материала статьи это не повлияло. Он по прежнему актуален.

Автоматизированное тестирование в «1С:Предприятие 8.3»

В платформе «1С:Предприятие 8.3» появился новый механизм, предназначенный для имитации интерактивных действий пользователей системы – автоматизированное тестирование.

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

При тестировании используются два вида клиентских приложений – менеджер тестирования и клиент тестирования. Менеджер тестирования устанавливает связь с клиентом тестирования и выполняет сценарий тестирования.

Сценарий тестирования – это код на встроенном языке, в котором описывается последовательность выполняемых интерактивных действий.

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

Менеджер тестирования может быть толстым или тонким клиентом. Клиент тестирования – толстым, тонким клиентом или веб-клиентом.

Менеджер тестирования может быть подключен к нескольким клиентам тестирования, а клиент тестирования может быть подключен только к одному менеджеру.

Для управления клиентом менеджер устанавливает с ним TCP-соединение. Важно, что для проведения автоматизированного тестирования не требуется вносить изменений в структуру конфигурации.

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

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

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

Запуск менеджера может быть выполнен из командной строки с ключом /TESTMANAGER:

“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\test” /N Администратор /TESTMANAGER

Также менеджер тестирования можно запустить из конфигуратора.

Для этого через меню Сервис – Параметры открываем диалог “Параметры”, в котором на закладке Запуск 1С:Предприятия – Дополнительные отмечаем пункт “Запускать как менеджер тестирования”:

Еще один способ запуска менеджера тестирования – из встроенного языка, при помощи метода ЗапуститьСистему(), в котором следует указать командную строку:

ЗапуститьСистему(“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F X:\test /N Администратор /TESTMANAGER”)

Клиента тестирования также можно запустить из командной строки. Для этого следует воспользоваться ключом параметра командной строки /TESTCLIENT.

При помощи параметра TPort указывается номер порта, через который будет вестись взаимодействие менеджера и клиента тестирования. Если этот параметр не указан в командной строке, то будет использован порт 1538.

“c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\Platform8Demo” /N Администратор /TESTCLIENT -TPort 1539

Клиент тестирования можно запустить из конфигуратора. Для этого через меню Сервис – Параметры открываем диалог “Параметры”, в котором на закладке Запуск 1С:Предприятия – Дополнительные отмечаем пункт “Запускать как клиент тестирования”. При этом надо будет указать номер используемого порта.

Обратите внимание, что для подключения к клиенту тестирования необходимо знать два параметра: IP-адрес (или имя) компьютера, на котором запущен клиент тестирования, и номер TCP-порта, с помощью которого будет выполняться взаимодействие.

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

Для выполнения автоматизированного тестирования необходимо проделать следующие шаги:

1. Разработать сценарий тестирования – написать внешнюю или встроенную в конфигурацию обработку, в которой будут последовательно описаны выполняемые шаги.
2. Запустить менеджер тестирования.
3. Запустить клиент тестирования (один или несколько).
4. В менеджере тестирования запустить на исполнение созданную обработку, убедиться в выполнении запрограммированных действий на клиенте.

Тестируемое приложение описывается набором объектов встроенного языка, которые используются для написания сценария:

• ТестируемоеПриложение;
• ТестируемоеОкноКлиентскогоПриложения;
• ТестируемыйКомандныйИнтерфейсОкна;
• ТестируемаяГруппаКомандногоИнтерфейса;
• ТестируемаяКнопкаКомандногоИнтерфейса;
• ТестируемаяФорма;
• ТестируемоеПолеФормы;
• ТестируемаяГруппаФормы;
• ТестируемаяКнопкаФормы;
• ТестируемаяТаблицаФормы;
• ТестируемаяДекорацияФормы.

В качестве тестируемой конфигурации будем использовать демонстрационную конфигурацию “Управляемое приложение”.

Создадим внешнюю обработку, добавим новую форму, в которой определим обработчик для новой команды “ЗапуститьТестирование”.

В тесте выполняем следующие действия: создаем новый элемент справочника “Склады”, в поле Наименование вводим строку “Склад тест”, затем нажимаем кнопку “Записать и закрыть”.

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

&НаКлиенте
Процедура ЗапуститьТестирование (Команда )
// Подключимся к тестируемому приложению
ТестируемоеПриложение = Новый ТестируемоеПриложение (“localhost” );
// Пытаемся подключаться не более одной минуты
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл Попытка
ТестируемоеПриложение.УстановитьСоединение ();
Подключен = Истина ;
Прервать ;
Исключение
КонецПопытки ; КонецЦикла ; Если Не Подключен Тогда
// Завершаем работу теста
ТестируемоеПриложение = Неопределено ;
Сообщить (“Не удалось установить соединение!” );
Возврат ;
КонецЕсли ;
// Найдем главное окно
ГлавноеОкноТестируемого
= (Тип ());
ГлавноеОкноТестируемого.Активизировать ();
// Выполним команду создания элемента справочника товаров
ГлавноеОкноТестируемого.ВыполнитьКоманду (“e1cib/command/Справочник.Склады.Создать” );
ТестируемоеПриложение.ОжидатьОтображениеОбъекта (Тип (“ТестируемаяФорма” ), “Склад*” );
ТестируемаяФорма = ТестируемоеПриложение.НайтиОбъект (Тип (“ТестируемаяФорма” ),
“Склад*” );
ТестируемаяФорма.Активизировать ();
// Зададим наименование для нового товара
ЭлементФормы = ТестируемаяФорма.НайтиОбъект (Тип (“ТестируемоеПолеФормы” ),
“Наименование” );
ЭлементФормы.Активизировать ();
ЭлементФормы.ВвестиТекст (“Склад тест” );
// Запишем элемент
ЭлементФормы = ТестируемаяФорма.НайтиОбъект (Тип (“ТестируемаяКнопкаФормы” ),
“Записать и закрыть” );
ЭлементФормы.Нажать ();
КонецПроцедуры

В диалоге параметров запуска сначала выбиралось значение “Запустить как менеджер тестирования”, при помощи сочетания клавиш Ctrl+F5 запускался пользовательский сеанс.

Потом в диалоге выбиралось значение “Запустить как клиент тестирования”, при помощи сочетания клавиш Ctrl+F5 запускался второй пользовательский сеанс.

Таким образом мы избежали необходимости вручную указывать требуемые параметры командной строки.

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

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

Для этого необходимо запустить приложение в специальном режиме:

Для увеличения нажмите на изображение.

В заголовке программы появляется несколько кнопок:

Кнопки предназначены для:

• начала/приостановки записи;
• прекращения записи;
• завершения записи.

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

Для увеличения нажмите на изображение.

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

Для этого предназначена обработка “Преобразование журнала действий пользователя” (UILogToScript.epf), которую можно получить с сайта ИТС .

Для увеличения нажмите на изображение.

В результате работы обработки мы получаем сгенерированный код на встроенном языке. Этот код следует вставить в модуль формы обработки тестирования.

Обратите внимание, что в сгенерированном коде числа, большие 999 или меньшие –999, будут выводиться с использованием неразрывного пробела в качестве разделителя групп (например, «1 234» вместо «1234»).

Этот символ необходимо удалить из полученного кода вручную.

Участок кода с подключением к клиенту обработка сформировала автоматически.

В нашем примере получился следующий код:

&НаКлиенте
Процедура ЗапуститьТестирование (Команда )
ТестовыйСценарий_23_03_2014 ();
КонецПроцедуры &НаКлиенте
Процедура ТестовыйСценарий_23_03_2014 () ТестовоеПриложение = Новый ТестируемоеПриложение ();
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь ;
ОписаниеОшибкиСоединения = “” ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение.УстановитьСоединение ();
Подключен = Истина ;
Прервать ;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки ;
КонецЦикла ;
Если Не Подключен Тогда
ТестовоеПриложение = Неопределено ;
Сообщить (+ Символы.ПС + ОписаниеОшибкиСоединения );
Возврат ;
КонецЕсли ; (ТестовоеПриложение );
(ТестовоеПриложение ); КонецПроцедуры &НаКлиенте
Процедура ОкноПриложенияКонтрагентыКнопкаСоздатьНажать (ТестовоеПриложение )
ОкноПриложенияКонтрагенты = (Тип (
“ТестируемоеОкноКлиентскогоПриложения” ), “Контрагенты” , , 30 );
ОкноПриложенияКонтрагентыФормаКонтрагенты = ОкноПриложенияКонтрагенты.НайтиОбъект (Тип (
“ТестируемаяФорма” ), “Контрагенты” );
КнопкаСоздать = ОкноПриложенияКонтрагентыФормаКонтрагенты.НайтиОбъект (Тип (
“ТестируемаяКнопкаФормы” ), “Создать” );
КнопкаСоздать.Нажать (); КонецПроцедуры &НаКлиенте
Процедура ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать (ТестовоеПриложение ) ОкноПриложенияКонтрагентСоздание = ТестовоеПриложение.НайтиОбъект (Тип (
“ТестируемоеОкноКлиентскогоПриложения” ), “Контрагент (создание)” , , 30 );
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание =
ОкноПриложенияКонтрагентСоздание.НайтиОбъект (Тип (“ТестируемаяФорма” ),
“Контрагент (создание)” );
ПолеНаименование =
(Тип (
“ТестируемоеПолеФормы” ), “Наименование” );
ПолеНаименование.ВвестиТекст (“Новый” ); ПолеВидЦен = ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект (Тип (
“ТестируемоеПолеФормы” ), “Вид цен” );
ПолеВидЦен.Активизировать (); ПолеВидЦен.Выбрать (); ПолеВидЦен.ОжидатьФормированияВыпадающегоСписка (); ПолеВидЦен.ВыполнитьВыборИзСпискаВыбора (“Закупочная” ); КнопкаЗаписатьИЗакрыть =
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект (Тип (
“ТестируемаяКнопкаФормы” ), “Записать и закрыть” );
КнопкаЗаписатьИЗакрыть.Нажать (); КонецПроцедуры

В полученном сценарии устанавливается подключение к клиенту тестирования, нажимается кнопка создания нового элемента справочника “Контрагенты”, в поле Наименование вводится текст “Новый”, а в выпадающем списке “Вид цен” выбираем значение “Закупочная”, затем нажимается кнопка “Записать и закрыть”.

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

Менеджер тестирования будет использоваться один, а к нему подключены два клиента на разных портах.

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

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

Процедура ТестовыйСценарий_23_03_2014_ДваКлиента () //первый клиент
ТестовоеПриложение1 = Новый ТестируемоеПриложение ();
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
Подключен = Ложь ;
ОписаниеОшибкиСоединения = “” ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение1.УстановитьСоединение ();
Подключен = Истина ;
Прервать ;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки ;
КонецЦикла ; //второй клиент
ТестовоеПриложение2 = Новый ТестируемоеПриложение ();
ВремяОкончанияОжидания = ТекущаяДата () + 60 ;
ОписаниеОшибкиСоединения = “” ;
Пока Не ТекущаяДата () >= ВремяОкончанияОжидания Цикл
Попытка
ТестовоеПриложение2.УстановитьСоединение ();
Подключен = Истина ;
Прервать ;
Исключение
ОписаниеОшибкиСоединения = ОписаниеОшибки ();
КонецПопытки ;
КонецЦикла ;
Если Не Подключен Тогда
ТестовоеПриложение1 = Неопределено ;
ТестовоеПриложение2 = Неопределено ;
Сообщить (“Не смогли установить соединение!” + Символы.ПС + ОписаниеОшибкиСоединения );
Возврат ;
КонецЕсли ; //процедуры отдельные для каждого клиента тестирования
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать1 (ТестовоеПриложение1 );
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать2 (ТестовоеПриложение2 );
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать1 (ТестовоеПриложение1 );
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать2 (ТестовоеПриложение2 ); КонецПроцедуры

Паузы между выполняемыми действиями тоже нужно запрограммировать отдельно. Сценарий для большого количества клиентов становится трудночитаемым.

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

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

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

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

Также автоматизированное тестирование может применяться для выявления в конфигурации избыточных блокировок и взаимоблокировок.

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

Основные возможности

С помощью «1С:Сценарное тестирование 8» можно написать и выполнить тесты для проверки работоспособности любой конфигурации системы «1С:Предприятие 8». Инструмент состоит из двух внешних обработок. Одна обработка предназначена для записи теста, вторая обработка для прогона теста. Записанный тест можно выполнить либо в ручном, либо в автоматическом режиме.

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

Тест представляет собой набор действий, которые пользователь должен выполнить в программе. Это могут быть действия, например, по созданию новых элементов справочников, документов, заполнению данных на форме, нажатию кнопок. При автоматическом прогоне такого теста происходит имитация работы пользователя по вводу информации. Важно, что выполнение команд теста по интерактивному созданию объектов и заполнению форм отрабатываются платформой «1С:Предприятия 8» так же, как если бы эти данные вводил пользователь с клавиатуры.

Подобный принцип тестирования есть и в других программах, но, в отличие от них, в данном инструменте реализованы возможности разработки теста, отражающие специфику тестирования конфигураций «1С:Предприятия 8». К таким возможностям можно отнести:

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

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

Использование 1С:Сценарное тестирование 8

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

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

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

«1С:Сценарное тестирование 8» могут использовать:

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

Для разработки и отладки сценария в СТ существует специальная обработка. Обработку можно выгрузить из СТ по команде в разделе Администрирование - «Сохранить обработку в файл».

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

Для записи и отладки сценариев нужно запустить две сессии базы: «Менеджер тестирования» (далее МТ) и «Клиент тестирования» (далее КТ).

МТ управляет КТ, записывает действия пользователя и позволяет дорабатывать сценарий. КТ нужен для воспроизведения самого сценария и исполнения действий пользователя.

При запуске КТ нужно указать параметры запуска (вид соединения 1С, пользователь и т.д.):

После того как запустился КТ, можно приступать к записи действий пользователя. Для этого в МТ в обработке включаем запись.

Можно воспроизводить действия в КТ.

После завершения действий в КТ, нажимаем остановку записи в МТ:

По команде «Записать и закрыть» записанные действия переносятся в сценарий:

Итог: Конфигурация «Сценарное тестирование 3.0» при правильном и умелом подходе позволяет быстро и эффективно записывать интерактивные действия пользователя, достаточно просто дорабатывать и отлаживать сценарии. Для разработки интерактивных шагов сценария не обязательна квалификация программиста. Достаточно знать и понимать, как воспользоваться уже готовым решением.

P.S.: Сценарии лучше не запускать под интерфейсом «Такси», так как бывает некорректно отрабатывает сценарий.

Многие специалисты и просто пользователи продуктов на базе 1С Предприятие 8 должно быть уже наслышаны о выпуске нового программного продукта для проведения тестирования любых (согласно официальным заявлениям) конфигураций, и имя ему - 1С Сценарное тестирование 8. Сразу уточню, что данный инструмент является разработкой непосредственно компании 1С, а не сторонних активистов. Информацию по этому продукту (помимо бесконечных перепечаток с сайта 1С) найти мне не удалось, из чего я могу сделать вывод, что ее просто нет. Да и сам продукт обзора найти нелегко, по крайней мере тем, кто не хочет платить 30к за лицензию или уже ей не обладает вкупе с поставкой КИП8. Так или иначе, но после некоторых мытарств мне таки удалось заполучить этот инструмент в свои руки. И вот с этого момента начну поподробней.

Установка.

На данный момент мне известны следующие официальные способы раздобыть данный инструмент:

а) Он входит в поставку "1С:Корпоративный инструментальный пакет 8".

б) Можно скачать на сайте пользовательской поддержки 1С.

в) Ранняя версия присутствовала на диске ИТС, кажется за октябрь.

Само приложение весит порядка 2Мб, но радоваться рано - чтобы его инсталлировать, необходимо указать путь к папке с шаблонами. Как я понимаю, данный каталог есть в базовых конфигурациях, или же в тестовой, которая прилагается к программе. Ее и следует установить в первую очередь (~90Мб), далее благополучно инсталлируем утилиту и удаляем более ненужную конфигурацию .

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

Уточню, с чем мне пришлось работать. Мне досталась версия 1.2.2.1, очевидно не первичная. В качестве тестовой конфигурации я использовал конфигурацию на базе 1С Предприятие 8.1.

Разбор полетов.

Итак, как я уже упоминал, 1С Сценарное тестирование состоит из двух внешних обработок: ЗаписьТестов и ПрогонТестов.

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

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

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

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

Рис. 1 Обработка ЗаписьТестов.

Идеология данного инструмента основана на сравнении объектов эталонной базы с объектами в тестируемой базе. Это хорошо видно по главному окну обработки ЗаписиТестов, в левой части данные из эталонной базы, справа тесты, основанные на данных из левой части. Эталонной, считается та база, в которой создан тест.

Помимо основной функции инструмента, описанной выше, существует ряд других, более примитивных, но иногда не менее полезных. Например, инструмент можно использовать только для автозаполнения форм, нажатия кнопок, заполнения табличных частей и так далее, данные шаги имитируют работу пользователя в интерактивном режиме. А так как роль пользователя играет тестировщик, то получается своего рода ad hoc тестирование в автоматическом режиме.

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

Каждый шаг можно выполнить непосредственно в этой обработке, нажав F12. Этот функционал ставит под сомнение надобность второй обработки ПрогонТестов, думаю, в будущем логично было бы их объединить.

Рис. 2 Обработка ПрогонТестов.

Готовый тест записывается в xml документ, который мы открываем в тестируемой базе через обработку ПрогонТестов и наблюдаем, как у нас все замечательно выполняется.

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

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

Теперь рассмотрим плюсы и минусы использования этой системы в полевых условиях.

Особенности использования.

По официальным заявлениям, 1С Сценарное тестирование должно быть универсальным средством в плане совместимости с различными конфигурациями. Думаю, моя конфигурация является отличным стендом для проверки этого утверждения.

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

Вот часть того, с чем мне пришлось столкнуться:

1. Почему-то при всем многообразии вариантов шагов теста нет шага для удаления обрабатываемого объекта. На первых порах приходилось использовать шаг «Обработка» и писать вручную код для удаления объектов. В конце концов я решил пока обойтись без этого и работать с существующими данными.
2. Одним из самых полезных, на мой взгляд, является шаг «Сравнение движения с эталоном». Вот оно, то чего так не хватало. Теперь есть возможность отслеживать все изменения в проводках, которые не были запланированы.
   Данный шаг нуждается в очень тонкой настройке. Например, нам нужно отслеживать движение документа по четырем регистрам, и у каждого из них свой набор полей и аналитик. Есть значения, которые будут изменяться при изменении объекта, и это не будет ошибкой. Например, поле вроде TimeStamp, в которое записывается время проведения документа, или номер документа, если он присваивается автоматически. Все такие моменты будут вызывать ошибку при выполнении теста. Хорошо, что разработчики предусмотрели это и дали возможность отключать проверку непостоянного поля. Нам остается только найти такие поля.
   Однако и тут без подводных камней не обошлось. Например, у меня отчего-то в форме настройки шага, если отображено больше одного регистра, то движения по ним не показываются, приходится отключать лишние и настраивать каждый регистр персонально.
   И что мне уж совсем не понравилось. Как мне удалось понять, по регистрам проверяются только те движения, которые есть в эталоне. Например, если в эталоне одна проводка, а в тестируемой базе три, то ошибки при сравнении НЕ будет. Т.к. по всему регистру производится поиск проводки с параметрами эталонной, если все OK, то присутствие в регистре остальных, относящихся к этому же объекту, не отслеживается.
3. Далеко не всегда корректно работают шаги по авто-заполнению форм, основанные на скрипте. Ошибки часто возникают в ссылочных полях и датах. Это скорее не ошибка инструмента, а особенность полей, но тем не менее придется повозиться с их настройкой.
4. Возможные варианты шагов ассоциированы с конкретными объектами конфигурации. То, что доступно для справочников, может быть недоступно для регистров и т.д. Точнее было бы сказать, что привязка скорее не к объектам, а к их особенностям, скажем, если у регистра нет формы, то и шага заполнить ее не будет.
   Но встречаются и баги, например, у меня часто недоступен шаг «Нажать кнопку», точнее, сам выбор сделать можно, только ничего не произойдет.
5. Остается просто уйма вопросов по автоматизации тестирования в некоторых особо запутанных случаях. Особенно это касается документов, работающих с остатками, где важную роль играют практически все моменты, часть из которых обыграть в текущей реализации инструмента очень проблематично. Есть ряд ограничений в конфигурации по созданию документов в одну дату, с одним номером и т.д. пока я остановился на использовании существующих объектов без создания новых.

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

Варианты применения.

Я для себя на данный момент выбрал следующую концепцию внедрения рассматриваемого инструмента в процесс тестирования.

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

Итак, у нас есть эталонная база, по которой мы сделали себе сценарии на все случаи жизни. В каком-либо документе в разработческой конфигурации внесены исправления, которые нужно протестировать. Как правило - вручную. После чего конфигурация с изменениями загружается в тестовую базу, и прогоняются сценарии для всех либо только смежных объектов с целью выяснить, оказало ли изменение в документе влияние на остальные объекты. После чего конфигурация считается жизнеспособной и устанавливается в рабочую базу. После этого сценарий тестирования измененного документа меняется на новый эталон из рабочей базы.

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

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

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

Вывод.

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