сценарное тестирование 1с обычные формы

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

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

«1С:Сценарное тестирование» позволяет автоматизировать все потребности специалистов по тестированию, включая планирование работ, проектирование тестов, выполнение тестирования и анализ полученных результатов.

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

Создание и модификация тестов

Выполнение тестов и обработка их результатов

Ключевые преимущества «1С:Сценарного тестирования»

Для работы «1С:Сценарного тестирования» не требуется дополнительных программ и/или утилит.

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

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

Источник

Автоматизированное тестирование в «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.

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

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

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

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

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

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

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

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

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

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

Попытка
ТестируемоеПриложение.УстановитьСоединение ();
Подключен = Истина ;
Прервать ;
Исключение
КонецПопытки ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

&НаКлиенте
Процедура ТестовыйСценарий_23_03_2014 ()

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

ОкноПриложенияКонтрагентыКнопкаСоздатьНажать ( ТестовоеПриложение );
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать ( ТестовоеПриложение );

&НаКлиенте
Процедура ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать ( ТестовоеПриложение )

ПолеВидЦен = ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект ( Тип (
“ТестируемоеПолеФормы” ), “Вид цен” );
ПолеВидЦен.Активизировать ();

КнопкаЗаписатьИЗакрыть =
ОкноПриложенияКонтрагентСозданиеФормаКонтрагентСоздание.НайтиОбъект ( Тип (
“ТестируемаяКнопкаФормы” ), “Записать и закрыть” );
КнопкаЗаписатьИЗакрыть.Нажать ();

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

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

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

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

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

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

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

//процедуры отдельные для каждого клиента тестирования
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать1 ( ТестовоеПриложение1 );
ОкноПриложенияКонтрагентыКнопкаСоздатьНажать2 ( ТестовоеПриложение2 );
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать1 ( ТестовоеПриложение1 );
ОкноПриложенияКонтрагентСозданиеКнопкаЗаписатьИЗакрытьНажать2 ( ТестовоеПриложение2 );

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

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

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

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

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

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

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

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)

Источник

Интеграция сценарного тестирования в процесс разработки решений на базе платформы 1С

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

Вступление

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

Во многом, эти вопросы решаются внедрением специальных методик, например, TDD, BDD, организацией дополнительных процессов по тестированию. Однако, везде есть свои нюансы.

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

BDD, за счет человеческого языка сценариев Gherkin, идеологически сшивает в одном месте специалистов прикладной и технической областей, а используемая конструкция описания сценариев Given-When-Then универсальна. Однако, BDD больше о процессе создания продукта, а не только о его тестировании. BDD основывается на ролевом взаимодействии сотрудников компании, что делает её требовательной (и в какой-то мере хрупкой) ко всем звеньям цепи разработки. Другой важной проблемой является не высокая эффективность языка Gherkin при разработке сложных (с точки зрения BDD) сценариев. К автоматическому документированию, как бонусу BDD, также, немало вопросов. Руководства пользователя к продуктам известных вендоров, не строятся по принципу Given – When – Then, а с техническим документированием, многие выбирают подход “Лучше устаревшая, но понятная, чем актуальная, но непонятная (или понятная только автору сценариев) документация.

Исторически, TDD, BDD и другие, пришли из мира, где системы 1С нет как класса, где идет очень четкая специализация, и разрыв между понимаем задачи техническим специалистом и бизнесом, как правило, велик. Например, в типовой 1С-франчайзи, очень часто задачи идут конвейером, могут приниматься по телефону, скайпу или электронной почте. Организация заседаний на каждую доработку в формате трех друзей (Three Amigos), выглядит несерьёзно, а значит почти вся методика BDD искажается или даже ломается.

В тоже время, на крупных проектах, эти переговоры необходимы. В идеале там будет аналитик, тестировщик и разработчик (BA+QA+Developer), но там не будет всего отдела программистов. А им, в конечном итоге, писать код, проводить тестирование, зачастую, намного более глубокое, с пограничными значениями, отклонениями, и другими особенностями реализации, возникновение которых рождается в коде и не может быть описано в приемочном тесте или постановке задачи. И это будет не TDD, а реальные сценарные тесты, которые программисты как правило не автоматизируют, а выполняют вручную в рамках процесса кодирования.

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

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

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

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

О конфигурации Тестер

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

Возможности:

Особенности:

Другое применение:

Базовые определения

Процесс тестирования приложений при помощи Тестера основывается на взаимодействии Тестера с запущенной конфигурацией 1С в режиме 1С: Предприятие.

При этом считается, что Тестер выступает в роли Менеджера тестирования, а тестируемая конфигурация – в роли Клиент тестирования.

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

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

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

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

Тестер не является системой TDD, и строго говоря, не является идеологически чистым BDD. Тестер старается не привязываться к религии в разработке, он решает те проблемы, с которыми сталкиваются абсолютно все разработчики программного обеспечения. Тестер старается решать эти задачи максимально эффективно.

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

Предполагаемые пользователи Тестера, это:

Концепция

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

Имея на входе информацию по задаче, мы мысленно разбиваем весь процесс кодирования на небольшие транзакции, рывки. Это является для нас неким краткосрочным планом работ (даже если на входе BDD-сценарий). Затем, мы начинаем методично работать по схеме “написание кода – запуск приложения – проверка ожидаемого поведения – возврат к доработке кода”. Количество таких транзакций и степень их завершенности — очень хрупкие сущности, потому что опираются на способность и возможность программиста быть в сосредоточении.

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

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

Интегрирование в работу инструмента тестирования, потребует от программиста выработки навыка трансляции мысленно составленного плана работ в программный код сценария. Это дает ему возможность “разгружаться” сериализуясь в код теста. Накапливаемые сценарии, всегда можно воспроизвести, что позволяет сосредоточится на качестве выполняемых работ. Рост количества тестов дает свободу действий не только для рефакторинга, но и других существенных изменениях функциональности разрабатываемого приложения, что является одной из важных концепций инструмента.

Быстрый старт

Первый сценарий

Второй сценарий

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

После выполнения теста, в базе БСП должен быть новый партнер.
После выполнения теста, в окне сообщений Тестера, будет такое предупреждающее сообщение:

Сообщение говорит о том, что в 14 строке кода, метод Нажать нашел несколько мест, где можно нажать Создать.
Для того, чтобы задавать однозначно объекты, с которыми требуется взаимодействие, можно использовать идентификаторы, или полный путь.
Например, в 14 строке можно написать так:

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

Интерфейс

Интерфейс Тестера организован с позиций удобного написания и запуска тестов. При первом запуске, на домашнюю страницу выводится справка по системе (выкачивается из интернета) и открывается основной сценарий, если он задан. В левой части системы находится текстовый редактор для ввода кода сценария, справа – дерево сценариев.
К сожалению, на момент подготовки этой документации, система еще не поддерживает синтаксическое цветовое оформление программных модулей. Лишь поначалу это может показаться серьёзной проблемой, но спустя непродолжительное время, вы перестанете обращать на это внимание, потому что изначально, код сценария существенно проще, чем стандартный программный код конфигураций.
Некоторые специалисты ненадолго предпочли использование Visual Studio Code с расширением Language 1C (BSL) или обычный конфигуратор 1С для набора текста сценария, с последующим копированием или загрузкой в Тестер. Однако, практика показала, что ценность цветового оформления существенно ниже возможности взаимодействия программиста с полями и структурой тестируемого приложения, деревом сценариев, помощником и другими функциями, доступными только из Тестера.

Дерево сценариев

Тестер поставляется с демонстрационной базой. В демо-базе содержится небольшой набор универсальных тестов, а также специальные тесты для конфигурации ERP2. Я предлагаю использовать демо-базу в качестве начальной базы для создания вашей собственной инфраструктуры тестов.
Когда вы запускаете Тестер, в правой части экрана находится дерево сценариев. Это дерево позволяет организовать сценарии в виде иерархии. Каждый узел дерева имеет тип. Тип задает смысловое значение сценариев внутри узла, сортировку и пиктограмму. В терминологии 1С, это дерево – обычный иерархический справочник.
На картинке ниже показан пример дерева тестов из демонстрационной базы, и далее дано описание каждого маркера:

Типы сценариев, Маркер 1

Левее маркера, в зеленом цвете и специальной пиктограмме, находятся такие узлы как Корзина, Общее, Таблица и другие.
Такое оформление означает, что это библиотеки тестов. Признак, что узел является библиотекой, задается при создании/редактировании теста:

На картинке видно, что кроме библиотеки, тест может быть папкой, сценарием или методом.
Строгой технической привязки и контроля типа сценария в Тестере нет. Главное предназначение типов – это организация визуальной логики взаимосвязи сценариев.
В случае, если это библиотека, подразумевается, что внутри данной папки будут храниться только библиотечные сценарии-методы. Метод – это сценарий, который не должен привязываться к конкретной тестируемой логике приложения. Методы обычно могут принимать параметры, они работают как процедуры/функции. Методы не должны запускаться как отдельные, самостоятельные сценарии (запуск сценариев см. здесь).
Пример метода: ПроверитьОшибкуЗаписи.
Пример использования в коде сценария:

Группы сценариев, Маркер 2

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

Обычный сценарий, Маркер 3

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

Сценарий-метод, Маркер 4

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

Основной сценарий, Маркер 5

Этим маркером отмечен обычный сценарий. Подчеркивание снизу указывает на то, что данный сценарий в настоящий момент текущий (основной). Основной сценарий, это тот сценарий, над которым сейчас работает программист. Любой сценарий может быть установлен основным (правый клик в дереве / Основной). У каждого пользователя системы Тестер может быть свой основной сценарий. Основной сценарий отличается от остальных тем, что его легко найти в дереве (правый клик в дереве / Найти основной сценарий) и легко запустить на выполнение (см. Запуск тестов). Также, основной сценарий автоматически открывается при запуске новой сессии Тестера.

Приложения, Маркер 6

Хранилище, Маркер 7

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

Запуск тестов

При запуске теста по кнопке F5 (или командe Запустить) Тестер всегда запускает сценарий, установленный как основной. Таким образом, вне зависимости от кого, какой сценарий вы в данный момент редактируете, запускаться будет только основной.

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

Вкладка Поля

Перед внедрением

Установка

125мс всё еще можно комфортно работать через интернет, разработка Тестера велась с учетом удаленности программистов. Если по каким-то причинам, облачное решение организовать не получается, можно установить программу локально на каждый компьютер специалиста, файловый вариант. Для организации общего хранилища тестов, можно использовать Git. У Тестера есть возможность инкрементальной выгрузки/загрузки тестов в файловую систему.

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

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

Базы данных

Тестирование при помощи Тестера предполагает наличие двух баз данных: рабочей и начальной.

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

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

Создание и обновление начальной базы

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

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

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

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

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

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

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

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

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

Эталонная база

Данные для тестирования

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

Структура сценария

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

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

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

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

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

Яснее на примере. Давайте представим, что вы занимаетесь доработкой документа Списание ТМЗ, который нужно дополнить особыми движениями по регистрам. Для тестирования (неважно как, вручную или нет) вам понадобится материал на складе, себестоимость которого вы знаете, установленные параметры учетной политики, на которые вы полагаетесь, и другие настройки системы, например, вариант контроля остатков. Таким образом, вам нужно будет вручную, как минимум один раз проверить, что настройки системы в порядке. Затем, нужно будет создать несколько материалов, возможно отдельный склад и как минимум одно поступление ТМЗ, и вы не забудете дату поступления сделать днем ранее. Таким образом – вы определяете и создаете окружение, чтобы затем выполнить целевую часть – провести списание и проверить, что особые движения появились и они правильные. Другими словами – выполняются все три описанных выше структурных действия для разработки автоматизированного сценария.

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

Пример. Добавим в описанную задачу необходимость проверки сообщения об ошибке при списании количества материала, большего, чем есть на складе. Я сильно не ошибусь, если предскажу работу смекалки программиста: он просто откроет уже проведенное списание (предварительно добавив его в избранное для максимальной “скорости”), отменит его проведение, в колонку с количеством введет 999999, запишет документ, а потом проведет его и проанализирует сообщение об ошибке. Если сообщения не будет, программист вернется в код, сделает необходимые доработки и будет повторять итерацию до тех пор, пока сообщение об ошибке не появится.

И тут начинаются проблемы. Во-первых, проверить нормальное поведение списания уже так просто не получится. Нужно будет привести данные в порядок, убрать 999999 и вернуть то количество, которое было на момент, когда мы проверяли правильность доработанных движений. И нам уже вряд удастся быстро вспомнить, каким именно было то первоначальное количество. Во-вторых, даже если программист предварительно скопирует документ, перед тем как менять данные – максимум он потом сможет проверить отсутствие ошибок проведения, но расчетные показатели, результат проведения, он проверить уже не сможет.

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

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

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

Практика

Перейдем к практической части: поработаем с Тестером в режиме создания нового функционала для конфигурации УТ11 на базе постановки задачи от бизнес-аналитика.

Постановка задачи

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

Документ Реализация

Необходимо в документ Реализация, в табличную часть, добавить поле для ввода даты согласования (без времени).
Поле не обязательно для заполнения. Если поле задано – тогда данная позиция считается отмеченной для согласования. По таким позициям необходимо предусмотреть обособленный учет на базе регистра сведений Согласование. Записи в данный регистр производить при проведении документа. При повторном проведении документа, существующие записи регистра сведений не обновлять, только добавлять новые.

Регистр сведений Согласование

Тесты

Разработка

По этой задаче мы можем прикинуть ход разработки и тесты, которые нам понадобятся. Условимся, что начальная база у нас уже есть, в ней проведены нужные настройки, отключены окна-подсказки, проверки контрагентов и так далее (о начальной базе см. здесь). В моем случае, начальной базой будет демо-база УТ11.

Можно выделить как минимум четыре этапа:

Этап 1: добавить реквизит Дата согласования в табличную часть, в процедуре ОбработкаПроверкиЗаполнения реализовать проверку, чтобы дата согласования была больше даты документа

Этап 2: доработать процедуру ОбработкаПроведения, добавить туда логику формирования записей по регистру сведений

Этап 3: реализовать форму списка с фильтрами, как требует бизнес-аналитик

Этап 4: реализовать форму редактирования записи регистра для ввода данных по согласованным позициям.

Этап 1

Запускаем приложения на выполнение, переключаемся в Тестер и жмем там F5. В результате чего, тест должен завершиться без ошибок.

Этап 2

Метод для создания поставщика

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

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

Справку по всем функциям Тестера см. в разделе API Тестера.
Для создания сценариев-методов, в форме элемента сценария, на вкладке Свойства, нужно назначить соответствующий тип:

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

Затем, откроем редактор сценария Справочники.Поставщики.Создать и введем:

Параметризированный метод создания нового поставщика готов. Перейдем к созданию остальных методов.

Метод для создания покупателя

Проделаем в дереве сценариев практически те же действия для разработки сценария создания покупателя:

Затем введем код сценариев, Справочники.Покупатели.Создать.Параметры:

Метод для создания товаров

Справочники.Номенклатура.Создать.Параметры

Метод для создания складов

Справочники.Склады.Создать.Параметры

Источник