Каждому проекту – сценарные тесты! Быстрый старт в тестирование с помощью СППР

Меня зовут Анатолий Ненашев, я с 1С уже больше 15 лет.

Выступал в ролях разработчика, архитектора, релиз-инженера, тестировщика и разработчика тестов. И уже больше 5 лет активно занимаюсь вопросами обеспечения качества решений на 1С.

Представляю компанию «Эдит Про» – это разработчик и интегратор решений на 1С. У нас в компании отдельно выделено направление, которое занимается вопросами DevOps, мониторинга и оптимизации.

Расскажу о том:

• как начать писать сценарные тесты с помощью СППР;

• в чем преимущество СППР;

• какие минимальные настройки для ее работы потребуются;

• все это разберем на примере боевого теста по созданию и проведению приходного кассового ордера в ERP 2.5.

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

Что есть в СППР для тестирования

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

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

• подсистема по моделированию конфигурации;

• трекер-задач;

• подсистема учета ошибок;

• и в 2019 году была выпущена СППР 2.0, в которой появилась подсистема тестирования.

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

Фреймворк активно развивается, разрабатывается сообществом. Основной мейнтейнер – Леонид Паутов, который также является сотрудником фирмы «1С».

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

Какие, помимо этого, можно получить плюшки?

• Если вы уже используете СППР для моделирования или проектирования, но по какой-то причине не используете ее подсистему тестирования, вы сможете связать ваши тесты с функциями вашей системы.

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

• Ну и еще одно преимущество заключается в том, что СППР – это конфигурация на 1С с БСП под капотом. Если что-то хочется доработать, у нас как у разработчиков 1С есть все компетенции, чтобы это сделать.

Какое окружение нам потребуется?

• Во-первых, нам потребуется сама СППР – ее, как и любую конфигурацию, можно просто купить. По состоянию на октябрь 2021 года ее розничная цена – 7200 рублей. Достаточно демократично, я считаю. Это не какой-нибудь там ЦКК, ЦУП и так далее, которые стоят гораздо дороже.

• Помимо этого, нам потребуется установить Vanessa Automation – есть очень много способов установки этого фреймворка, но мы воспользуемся самым простым. Скачаем zip-архив со страницы релизов проекта на GitHub и развернем его в какой-нибудь каталог, который нам удобен. Здесь тоже нет никакой магии.

• Ну и, естественно, раз мы будем тестировать ERP, в качестве тестовой базы возьмем демобазу ERP.

Минимальные настройки для старта разработки тестов

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

• В СППР заведем пользователя – поскольку в конфигурации используется стандартная подсистема по управлению пользователями БСП, в этом нет ничего сложного.

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

• И еще для работы механизма тестирования мы должны запускать СППР в режиме менеджера тестирования. Удобнее всего сразу настроить этот режим запуска через список информационных баз, добавив параметр /TESTMANAGER в дополнительные параметры запуска.

Для самой СППР в общих настройках раздела «Администрирование» нужно в разделе «Тестирование» поставить галочку «Использовать механизмы тестирования», которая включает всю эту подсистему.

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

• Каталог для данных тестирования – туда будут выгружаться из СППР данные для прогона в Vanessa Automation.

• И фреймворк для запуска тестов – здесь нужно указать путь к инструменту тестирования Vanessa Automation, который мы скачали до этого. Основной его обработкой является обычная 1С-обработка, здесь нужно указать путь к ней.

Это – общие настройки.

Для запуска тестирования в СППР нужно создать проект. Это можно сделать в меню «Главное» в разделе «Проекты».

Создадим новый проект и назовем его «ERP» – почему бы и нет.

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

И для этого проекта мы еще создадим раздел – так как мы будем тестировать ПКО, назовем раздел «Кассовые операции».

В разделе «Моделирование» нам нужно добавить два профиля пользователя.

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

Мы создадим два профиля – «Кассир» и «Администратор». Почему два? Если мы в ERP создадим и проведем документ «Приходный кассовый ордер», то при попытке проверить его движения через соответствующий отчет мы обнаружим, что под пользователем с правами кассира это сделать невозможно – у кассира нет прав на «Отчет о движениях документов».

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

Поэтому мы разбиваем наш тестовый сценарий на две части:

• сам ввод документа и его проведение мы будем выполнять под «Кассиром»;

• а проверку движений будем выполнять под «Администратором».

Далее в разделе «Тестирование» нам нужно добавить такую сущность, как «Эталонная база тестирования». Это – база, в которой наши фичи потом будут проверяться.

Здесь тоже достаточно указать:

• Наименование.

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

Создание теста на основе типичного сценария

В разделе «Тестирование» создадим новый сценарий работы пользователя.

На закладке «Описание» нам нужно указать:

• Наименование.

• Проект.

• Раздел проекта.

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

• И есть обязательное поле «Функция» – оно служит для связи сценария и функции нашей моделируемой системы. Если мы не используем СППР для проектирования, нам необязательно постоянно создавать разные функции, мы можем использовать одну функцию на все сценарии. И просто подставлять ее – в связи с тем, что поле обязательное.

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

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

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

• «Текущий сеанс СППР» – можно запускать менеджер тестирования на стороне СППР;

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

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

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

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

Так как мы еще ничего не писали, текст сценария внутри Vanessa Automation будет содержать:

• заголовок фичи;

• автоматически сформированную секцию контекста для запуска клиента тестирования и закрытия в нем всех окон,

• автоматически сформированный заголовок нашего сценария;

• а сам текст сценария будет пустой, потому что мы еще ничего не делали.

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

• На странице «Основные» закладки «Сервис» нужно указать «Каталог проекта» – такой же, как мы до этого указывали в поле «Каталог для данных тестирования» в персональных настройках.

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

Теперь мы готовы записать поведение для нашего первого сценария.

В командной панели нажимаем «Начать запись поведения» – будет автоматически запущен сеанс ERP под тем пользователем, профиль которого мы указали, с учетом того, что ранее мы сопоставили профиль пользователя с профилем эталонной базы.

В системе мы повторим те же действия, которые бы делал пользователь:

• заходим в нужный раздел;

• переходим в список документов;

• создаем документ;

• заполняем в нем все нужные поля;

• проводим его;

• закрываем.

После этого переключаемся обратно в СППР и останавливаем запись поведения через команду «Закончить запись поведения».

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

Он пока сыроват, и с ним нужно еще немного поработать.

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

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

В этом случае мы можем использовать символ подстановки «*» (звездочка), который будет означать, что после слова «ордер» у нас может идти любой текст. Если мы в шаге «Открылось окно Приходный кассовый ордер» поставим в качестве параметра «Приходный кассовый ордер *», то как бы ни менялся в дальнейшем номер этого документа, шаг у нас падать не будет, тест будет проходить.

Второй момент, с которым мы можем столкнуться – это асинхронные события.

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

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

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

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

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

Как нам найти подходящий шаг? Для этого есть ряд способов.

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

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

К библиотеке известных шагов можно перейти:

• по сочетанию клавиш Ctrl+I;

• через пункт контекстного меню;

• или по кнопке «Добавить известный шаг» на закладке «Работа с UI».

Открывается отдельная форма, в которой есть:

• поле поиска;

• поле шагов, которые мы в результате этого поиска нашли;

• и дополнительное описание справа.

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

Например, есть шаг: «И я жду, что поле «Заголовок поля» перестанет быть пустым в течение 30 секунд». Нам этот шаг отлично подходит. Единственное, что вместо параметра «Заголовок поля» мы подставляем «Номер», потому что мы ждем, что заполнится номер.

Запуск и сохранение данных тестирования сценария СППР

После того как мы внесли изменение в сценарий, мы можем из Vanessa запустить его на выполнение: по команде «Выполнить» или по хоткею F5.

Если мы уже закрыли клиент тестирования с сеансом ERP, он опять у нас заново откроется, и в нем прогонятся наши шаги: документ создастся и проведется. Но мы уже не будем ничего вводить руками – все уже будет выполняться автоматически.

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

Сверка данных с эталоном. Использование макетов и переменных. Исследователь формы

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

Запишем действия:

• открыть нужный раздел;

• открыть список документов;

• перейти к определенному документу;

• открыть его;

• сформировать отчет о движениях.

Завершаем запись поведения, но пока ничего дополнительно не делаем – сразу возьмем наш сформированный текст сценария и запишем его в справочник сценариев СППР.

Что нам не хватает на данном этапе?

• Во-первых, мы сформировали отчет о движениях, но пока еще его не проверяем.

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

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

Займемся этим.

Начнем с создания процесса.

В СППР в разделе «Тестирование» создадим новый процесс.

Нам нужно указать:

• наименование;

• проект;

• раздел проекта;

• и дальше нам нужно задать шаги процесса.

Так как у нас есть два сценария, у нас будет два шага:

• Один по вводу и проведению ПКО. В нем мы указываем:

  • наименование этого шага;

  • тип этого шага – оставляем «Шаг процесса»;

  • указываем исполнителя – какой профиль пользователя у нас будет исполнять этот шаг;

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

• Аналогично добавляем второй шаг с проверкой движений.

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

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

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

• «Я сохраняю навигационную ссылку текущего окна в переменную».

• «Я открываю навигационную ссылку».

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

• В первом сценарии мы добавим шаг «Я сохраняю навигационную ссылку текущего окна в переменную» после проведения документа – когда у нас документ уже записался, но мы его еще не закрыли.

• А во втором сценарии нам нужно вставить шаг «Я открываю навигационную ссылку» вместо шагов открытия списка документов, перехода к нужной строке и открытия документа из списка. Все эти шаги мы заменяем одним шагом и подставляем туда переменную, которую мы придумали.

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

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

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

Как бы это делал пользователь? Наверное, он бы брал фактический результат и сверял с каким-нибудь эталоном.

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

После чего откроем в карточке процесса «Присоединенные файлы», и добавим туда этот макет.

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

• Заголовок отчета – потому что номер документа меняется, заголовок меняется; дата документа меняется, заголовок меняется.

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

• Дальше есть ряд реквизитов с уникальными идентификаторами – там формируется GUID, и в новых документах он тоже будет каждый раз новый.

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

Что мы будем со всем этим делать?

• С идентификаторами мы решим, что нам их проверять не нужно, и заменим их символом подстановки «*» (звездочка). Точно так же, как мы это делали в сценариях.

• Для проверки периода мы будем запоминать дату документа после его записи в переменную с помощью шага «Я запоминаю значение поля с именем таким-то как ИмяПеременной». А потом будем подставлять значение этой переменной в наш макет. Например, мы можем точно так же в самом табличном документе через доллары указать имя переменной, и при проверке туда будет автоматически подставляться значение этой переменной.

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

После того как мы скорректировали наш макет, нам нужен еще один шаг, который будет этот макет проверять. Мы используем шаг «Тогда табличный документ РеквизитТабличныйДокумент равен макету ИмяМакета по шаблону»

Параметр ИмяМакета мы заменяем на наименование того присоединенного файла с эталоном, который мы прикрепили к процессу.

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

«Исследователь формы» можно запустить:

• с закладки «Работа с UI»;

• по комбинации клавиш Alt+E;

• или с панели команд.

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

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

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

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

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

Запуск тестирования процесса СППР

После этого мы можем запустить выполнение тестов уже из формы процесса – там есть аналогичная команда «Запуск тестов».

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

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

Начните заниматься качеством ваших продуктов – это не так уж и сложно, как кажется

В итоге:

• Мы научились использовать СППР для того, чтобы просто начать уже писать какие-нибудь сценарные тесты, а не думать об этом.

• Познакомились с темами,

  • как работать с переменными в Ванессе;

  • как использовать символы подстановки в шагах и макетах;

  • как проверять табличные документы;

  • как их хранить внутри СППР;

  • что делать с асинхронными событиями;

  • как искать известные шаги;

  • что такое «Исследователь форм», и как он нам помогает.

Ну и лучшее, конечно, впереди. Дальше еще очень много всего:

• вы продолжите изучать стандартную библиотеку шагов;

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

• будете использовать вложенные сценарии;

• будете использовать параметры в сценариях и процессах;

• научитесь писать свои шаги;

• узнаете, как наладить автоматический запуск тестов.

Возможно, в процессе вы забьете вообще на СППР, но продолжите заниматься сценарными тестами.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.