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

1С Тест-центр 8 — специализированный программный продукт фирмы 1С, который позволяет оценить производительность системы и изучить узкие места информационной системы.

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

Сценарий тестирования в 1С Тест-центр пишется внутри специально созданной обработки. Шаблон такой находится внутри конфигурации, он имеет название «ТЦШаблонТестовойОбработки». Для создания собственного сценария теста необходимо скопировать данный шаблон и на основании него создать свой, новый, назовём его «Перепроведение поступления товаров»:

Добавим в обработку новый реквизит и выведем его на форму — «ДокументДляКопирования», это тот документ, который мы будем копировать.

Рассмотрим подробнее модуль формы. В нем можно использовать три процедуры — ТЦИнициализировать(), ТЦВыполнить(), Удалить().

ТЦИнициализировать — используется для начального заполнения настроек информационной базы, например, заполнение учетной политики.
ТЦВыполнить — основной модуль, в котором прописывается непосредственно сценарий тестирования.
ТЦУдалитьДанные — модуль, в котором описывается удаление объектов, созданных в процессе тестирования.

Напишем в процедуру ТЦВыполнить() простейший код, который будет 5 раз подряд копировать выбранный документ и замерять копирование и проведение каждого документа:

Для й=1 По 5 Цикл

Инструменты = КипВнешнийКомпонент.ПолучитьИнструменты();
ВремяНачала = КипВнешнийКомпонент.ЗначениеТаймера(Инструменты);

Получите 267 видеоуроков по 1С бесплатно:

СоздатьДокументы();

ВремяОкончания = КипВнешнийКомпонент.ЗначениеТаймера(Инструменты);
ДлительностьВыполнения = (ВремяОкончания — ВремяНачала) / 1000;

ТЦЗаписатьПоказатель(«ВремяВыполнения», ДлительностьВыполнения);

КонецЦикла;

Возврат ТЦРезультатВыполненияУспешно();

Процедура СоздатьДокументы() будет выполнятся на сервере:

Процедура СоздатьДокументы()

НовыйДокумент = ТЦОбъект.ДокументДляКопирования.Скопировать();
НовыйДокумент.Дата = ТекущаяДата();
НовыйДокумент.Записать(РежимЗаписиДокумента.Проведение);

КонецПроцедуры

На этом подготовка сценария закончена, перейдем к Тест-центра для проведения нагрузочного тестирования.

Настройка 1С Тест-центр 8.3

После написания тестирования приступим к настройке самого Тест-центра. Для настройки необходимо заполнить ряд справочников:

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

Сценарии тестирования

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

Также на вкладке «Параметры» есть возможность настройки сценария тестирования технического характера:

После настройки сценария осталось только произвести его запуск.

Запуск тестирования в 1С: Тест-центр

Когда всё готово, останется только запустить работу тестирования.

Для этого необходим запуск минимум двух сеансов программы: первый — в роли т.н. «агента», а второй в роли инициатора запуска сценария.

Запуск агента:

Запуск сценария:

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

В статье рассмотрен новый механизм автоматизированного тестирования, который впервые появился в платформе в редакции 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-порта, с помощью которого будет выполняться взаимодействие.

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

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

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

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

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

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

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

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

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

&НаКлиенте
Процедура ЗапуститьТестирование (Команда )
// Подключимся к тестируемому приложению
ТестируемоеПриложение = Новый ТестируемоеПриложение (“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

4601546061393

42 000

Лицензирование 1С:Сценарное тестирование 8

Продукт "1С:Сценарное тестирование 8" предназначен для использования с клиентскими лицензиями "1С:Предприятия 8" , увеличивающими количество рабочих мест.В комплект поставки продукта входит дистрибутив, книга "1С:Сценарное тестирование 8. Руководство по использованию" и лицензионное соглашение.

Для использования продукта необходимо наличие любой основной поставки (версии ПРОФ) системы 1С:Предприятие 8. Продукт не предназначен для использования с базовыми версиями 1С:Предприятия 8. 1С:Сценарное тестирование 8 правомерно использовать на рабочих местах локальной сети организации, обеспеченных клиентской лицензией 1С:Предприятия 8. 1С:Сценарное тестирование 8 включено в поставку 1С:Корпоративный инструментальный пакет 8

Поддержка и обновление 1С:Сценарное тестирование 8

Поддержка и сервисное обслуживание зарегистрированных пользователей осуществляется в рамках Информационно-технологического сопровождения (1С:ИТС ) - 1С:ИТС Техно или 1С:ИТС Проф. Период бесплатной подписки при покупке программы составляет 3 месяца. По истечении срока бесплатной подписки для получения услуг по поддержке продукта необходимо оформить платную подписку на любую основную поставку системы "1С:Предприятие 8"

Скачать обновления зарегистрированные пользователи могут с сайта users.v8.1c.ru и с диска ИТС.

Функциональные возможности 1С:Сценарное тестирование 8

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

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

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

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

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

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

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

Инструментарий 1С:Сценарное тестирование 8 состоит из двух внешних обработок (одна обработка предназначена для записи теста, вторая - для его выполнения), а также набора тестов (файлов в формате xml) для типовых конфигураций 1С:Предприятия 8.

Могут использовать:

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

Многие специалисты и просто пользователи продуктов на базе 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С Сценарное тестирование должно быть универсальным средством в плане совместимости с различными конфигурациями. Думаю, моя конфигурация является отличным стендом для проверки этого утверждения.

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

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

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

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

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

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

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

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

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

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

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

Вывод.

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

Установка.

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

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

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

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

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

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

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

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

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

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

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