От экспертов «1С-Рарус»: Подходы к сценарному тестированию на примере 1С:Общепит и 1С:Сценарное тестирование

Важность тестирования программ

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

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

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

И главный вопрос, который возникает в данной ситуации: “Как?” Как ускорить процесс тестирования без ущерба качеству? Как не попасть в ловушку человеческого фактора и банально не забыть протестировать смежные блоки?

Одним из вариантов решения данной проблемы является автоматизация процессов тестирования. 

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

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

Автоматизация тестирования в 1С

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

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

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

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

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

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

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

• 1С:Сценарное тестирование, ред. 3.0 — конфигурация от фирмы «1С».
• Vanessa ADD (Automation Driven Development) — open-source проект, являющийся результатом объединения фреймворков xUnitFor1C (дымовое и юнит-тестирование) и Vanessa-Behavior (сценарное тестирование и BDD). Может применяться в связке с 1С:СППР.

В рамках данной статьи будет рассмотрен вариант работы с решением «1С:Сценарное тестирование» по нескольким причинам:

• Решение разрабатывается и находится на постоянной поддержке со стороны фирмы «1С».
• Включает в себя обширный функционал для организации автоматического тестирования.

1C-RarusTechDay 2020



Все записи докладов

Использование конфигурации «1С:Сценарное тестирование» для автоматизации процессов тестирования

Основные принципы работы решения

Конфигурация устанавливается обычным способом для всех решений фирмы «1С»: установка шаблонов и развертывание информационной базы из них. Далее в конфигурации необходимо завести пользователей и произвести первоначальные настройки. Целью данной статьи не является полное описание настроек конфигурации для дальнейшей работы, потому не будем останавливаться на данном моменте. Узнать более подробно об первоначальной настройке конфигурации можно в документации на ИТС (https://its.1c.ru/db/kip#content:66:hdoc) и в обучающих видео (https://www.youtube.com/channel/UCbdRui0PGMp9lqhvnVJcRzA) от разработчиков данной конфигурации.

Итак, где же можно создавать сценарии тестирования

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

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

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

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

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

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

Сохраняется два вида обработок: «старая» с именем STest_<номер_версии_СцТ>.epf и интерактивная iSTest_<номер_версии_СцТ>.epf с префиксом «i» в начале имени файла.

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

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

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

При написании сценариев непосредственно в базе «1С:Сценарное тестирование» они сразу создаются и хранятся в ней.

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

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

Способы написания сценариев тестирования: «накликивание», предопределенные шаги или универсальные макрошаги?

Для ответа на вопрос: «Как писать сценарии тестирования?», необходимо предварительно разобраться с понятиями: сценарий тестирования, шаг сценария и типов шагов.

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

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

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

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

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

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

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

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

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

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

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

Главным достоинством данного способа является именно скорость и простота создания сценариев тестирования: пользователь просто записывает выполнение своих действий на клиенте тестирования, а обработка преобразовывает их в шаги сценария тестирования.

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

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

Второй способ — использование предопределенных шагов

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

Необходимые шаги добавляются в сценарий тестирования вручную.

Как уже было сказано, количество шагов в «старой» и интерактивной обработках отличается, но в основных шагах они схожи. Ниже рассмотрены типы шагов «старой» обработки.

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

• интерактивные шаги для работы с формой;
• интерактивные шаги для работы с таблицей;
• интерактивные шаги для работы с табличным документом;
• общие шаги проверки бизнес-логики;
• общие интерактивные шаги;
• общие шаги.

Каждый шаг имеет собственную форму настройки, а ее внешний вид зависит от типа настраиваемого шага.

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

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

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

Третий способ — использование универсальных макрошагов

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

Каждый универсальный макрошаг содержит перечень предопределенных параметров, которые условно делятся на два типа:

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

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

• Переход в подсистемы и открытие формы списка объектов.
• Изменение реквизитов на формах объектов.
• Поиск в динамическом списке.
• Закрытие всех или конкретного активного окна формы.
• Нажатие любой кнопки на форме, в том числе декораций и гиперссылок командного интерфейса.
• Сравнение табличных документов.

Какие плюсы универсальных макрошагов можно отметить?

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

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

Организация тестирования 1С:Общепит

Организации тестирования типового отраслевого решения состоит из трех этапов:

• Документирование, то есть создание описания плана тестирования и ведение реестра созданных сценариев тестирования.
• Написание и отладка сценариев тестирования в обработке.
• Создание пакетов тестирования и запуск их вручную или по расписанию.

Пройдемся подробнее по каждому из этапов.

Документирование — реестр и описание созданных сценариев тестирования

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

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

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

• предусловие,
• сценарий тестирования,
• результат.

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

После того, как сценарий был внесен в реестр и описан, начинается его создание.

Написание сценария тестирования с использованием универсальных макрошагов

Наши сценарии тестирования обязательно включают в себя два важных блока:

• Ряд последовательных шагов, которые приводят к открытию или созданию объекта.
• Групповой шаг проверки бизнес-логики, который является следствием и венцом правильности проверки объекта.

Для написания сценариев тестирования нами используется «старая» обработка.

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

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

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

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

После установки соединения приступаем к написанию сценария тестирования.

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

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

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

И текста процедуры исполняемого на стороне менеджера тестирования.

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

• КоличествоДобавляемыхСтрок — количество добавляемых строк в табличную часть объекта. Относится к элементу управления табличные части. Заполняется, если необходимо работать с табличной частью объекта.
• Области — области объекта, в которых расположены элементы управления по названию из конфигуратора. Областью являются Шапка объекта, Вкладки. Есть возможность указать несколько областей через точку с запятой. Если область не указывается, то она игнорируется.
• ПроверятьОткрытиеСервисныхОкон — для закрытия типовых сервисных окон, принимает значение Да или Нет. В значении Нет проверка на открытие сервисных окон не происходит. В значении Да закрывает служебные сервисные сообщения нажатием на кнопку ДА в окне сообщения.

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный универсальный макрошаг может выполняться в двух режимах:

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

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

Загрузка, хранение и пакетный запуск сценариев тестирования

Сценарии тестирования пишутся нами во внешней обработке и сохраняются в файлы формата xml или zip. Для дальнейшего использования их необходимо загрузить в базу «1С:Сценарное тестирование».

Для чего это надо?

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

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

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

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

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

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

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

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

В своих пакетах мы используем следующие шаги:

• Группа подключения к базе, развернутой на сервере «1С» — в ней указывается расположение и параметры подключения к заранее вручную развернутой серверной базе.
• Загрузка в нее эталонной ИБ — загрузка файла dt, расположенного по указанному пути. Эталонная база — это база, в которой уже предопределены необходимые настройки и есть минимальные данные для отработки сценариев тестирования.
• Обновление ИБ файлом cf — обновление эталонной базы заранее сохраненным файлом cf с актуальными изменениями конфигурации.
• Запуск тестируемого приложения — запуск эталонной базы с параметром клиента тестирования.
• Выполнение интерактивных шагов сценариев тестирования — перечень интерактивных сценариев для выполнения.
• Закрытие тестируемого приложения — закрытие эталонной базы.

Пакет можно запускать двумя способами:

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

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

Командную строку можно взять из самого пакета по кнопке Еще, команда Получить командную строку для запуска.

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

• Запуск bat-файла для создания актуального cf, который далее будет загружаться шагом пакета Обновление ИБ файлом cf.
• Запуск пакета.

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

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

При запуске пакета возможна рассылка оповещений о результатах тестирования. Мы сделали рассылку через отдельный электронный почтовый ящик. Настройку его можно осуществить в подсистеме Администрирование, Органайзер, Учетные записи электронной почты.

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

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

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

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

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

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

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

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

Гид по форме

Первой доработкой стала функциональность, позволяющая динамически отрисовывать дерево элементов активной тестируемой формы в отдельном окне на стороне менеджера тестирования. Она получила название Гид по форме. Первоначальная идея была заимствована с open-source проекта Vanessa ADD, который там называется Исследователь формы.

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

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

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

Однако это не всегда действенно, когда речь заходит о большом количестве элементов на одной форме.

Было принято решение сделать двустороннее позиционирование. При нажатии на любую из строк дерева на стороне «Гида по форме» происходит позиционирование на элементе формы на стороне клиента тестирования. И наоборот, при нажатии на элемент формы на стороне клиента тестирования происходит позиционирование на строке дерева «Гида по форме» с его синонимом и именем.

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

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

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

И последняя доработка, которая была на данный момент произведена — возможность автоматического создания универсального макрошага по двойному клику на любом из элементов «Гида по форме». Тип универсального макрошага будет зависеть от того, какой тип у элемента. Необходим универсальный макрошаг, который работает с табличной частью объекта — нажимаем на элемент табличной части. Необходимо работать с кнопкой — нажимаем на имя кнопки.

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

Замена синонимов в сценарии тестирования

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

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

Обусловлено это тем, что некоторые элементы формы выстраивают свои наименования/имена динамически, в момент работы «1С:Предприятия» или же напрямую зависят от имени/синонима другого объекта конфигурации.

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

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

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

Решение проблемы оказалось достаточно тривиальным. За основу автозамены старого синонима в сценариях на новый был выбран подход мэппинг, позволяющий в отдельном файле хранить связку ИмяОбъекта — СинонимСтарый — СинонимНовый.

Решение задачи разделили на три этапа:

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

Рассмотрим более подробно каждый из этапов:

На основную форму обработки были добавлены и вынесены два новых реквизита:

• Кнопка Синонимы метаданных, открывающая форму отбора метаданных.
• Реквизит Синонимы, куда подтягивается соответствующий файл, с которым нам предстоит работать.

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

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

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

В случае ответа Да происходит ровно тоже самое за исключением того, что ранее установленные связи СтарыйСиноним‑НовыйСиноним исчезают, оставляя актуальным только последний существующий синоним.

Полномасштабное автоматическое тестирование — This Is the Way

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

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

Конечно можно еще предложить и вовсе не тестировать или тестировать частично, но это забег в пропасть. Мы выбираем путь профессионалов.

Если вам интересна разработка на платформе «1С:Предприятие», вы можете почитать другие статьи от экспертов «1С-Рарус»:

• Jenkins в разработке конфигураций «1С»
• Производительность нового RLS в 1С БСП 3. Переходить или нет?
• Оптимизация перезапуска рабочих процессов на платформе «1С» 8.3.15 и выше

И подписывайтесь на рассылку с новостями компании «1С-Рарус». Рассылка выходит один раз в 2 недели и содержит список актуальных мероприятий, которые мы проводим, и свежих публикаций на сайте.