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

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

В поисках такой платформы мы сравнили известные инструменты автоматизации:



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

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

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

С чего начать? В первую очередь, как и в любом процессе автоматизации, необходимо выбрать сценарии, которые целесообразно автоматизировать. Primo позволяет реализовывать целостные end to end-сценарии, захватывающие несколько систем, что существенно расширяет охват и полноценность автоматизации. Таким образом, этот инструмент применим для создания полноценного набора Sanity-тестов или регресса. В этом ещё один большой плюс RPA и выбранной нами платформы и отличие от других инструментов автоматизации.

В качестве примеров реализации рассмотрим выдержки как раз из такого сценария — end to end-сценария взаимодействия 1С и MS CRM.

Сценарий выбран, приступаем к автоматизации, а точнее — к роботизации. Запускаем Studio Primo (дружественный интерфейс, кстати, тоже повлиял на наш выбор платформы).



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

Для простоты начнём с последовательности. Этот тип процесса реализуется перетаскиванием необходимых элементов.



Далее идёт процесс настройки свойств и атрибутов каждого элемента.



Вот здесь и начинается самое интересное. Ключевой принцип автоматизации UI заключается в определении и однозначной идентификации различных элементов интерфейса.



Разберём три примера взаимодействия с элементами интерфейса 1С.

Начнём с взаимодействия «клик по кнопке» для открытия списка справочников:

  1. Добавляется элемент «Клик мышью» из палитры действий и нажимаем кнопку «Выбрать компонент»:

  2. В 1С выбираем кнопку «Справочник…»:

  3. Выбираем уникальные свойства элемента, такие, как тип и имя:

  4. Клик готов!

Следующий вид взаимодействия — это клик в поле ввода текста:



Уникальные свойства такие же, как с кнопкой открытия справочников (это тип и имя):



И третий вид взаимодействия — клик по чекбоксу:



Уникальными свойствами будут имя и текст при наведении (HelpText):




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



Теперь перейдём к следующей системе сценария и рассмотрим работу с всплывающим окном в MS CRM с помощью элемента «Клик по картинке» в качестве примера применения тайм-аутов взаимодействия.



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



Дальше давайте попробуем реализовать end to end-сценарий, содержащий взаимодействие двух систем.

Допустим, нам нужно получить значения из CRM и заполнить ими форму в 1С.

На примере кода 1С в CRM:



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



Из уникальных свойств выбираем идентификатор и имя атрибута:



Всё готово: действие «Получить текст» сохранит значение в выбранную переменную.

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



Поле заполнено:



Взаимодействие систем налажено, а дальше действуем по аналогии.

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

Если при отладке какое-либо из действий не выполнится, то в консоли на панели инструментов появится ошибка:



Двойным кликом можно перейти к расположению действия в проекте.

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

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

Ещё одна технически интересная возможность Primo — взаимодействие с iFrame, которую поддерживают далеко не все платформы. Взаимодействие со встроенными iFrame позволяет реализовывать сценарии MS CRM, которые в других случаях проверяются только вручную.

Рассмотрим несколько примеров с MS Dynamic CRM, открытой в MS Edge.

Сложность в том, что MS Dynamic CRM свёрстана с использование фреймов, и нужно заполнить форму сведений.



На примере поля «дата», используем элемент «Клик мышью», указываем на поле ввода из студии и получаем такой результат:



Есть свойство AutomationID — уникальное для элемента на странице. Его можно оставить для идентификации поля. Далее, элементом «Симуляция ввода» заполняем значение, и поле заполнено.

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



В свойствах действия заполняем свойство «Новое состояние» значением «true» (установить флажок).



Элемент на странице, как в примере с кликом, выбираем по AutomationID и получаем результат.



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



Когда RPA-проект готов, встаёт вопрос автоматизации его запусков. Для этого необходим Primo Оркестратор. Для его работы нужны выделенные аппаратные мощности.
Сначала готовый проект (в нашем случае — автотест) выгружается в Оркестратор и появляется на вкладке «RPA-проекты»:



Переходим на вкладку «Роботы»:



Робот нужен для выполнения проекта, их может быть больше одного. Можно добиться параллельного выполнения проектов, если задачи проектов не будут пересекать друг друга (например, авторизация в 1С одинаковой УЗ в одно время) и для каждого робота будет создана своя учётная запись.

На вкладке «Роботы» нажимаем кнопку «Запустить робота с проектом» — появляется всплывающее окно с выпадающим списком, в котором выбираем нужный для запуска проект.



На машине роботов появилось окно с консолью — значит, команда на запуск прошла успешно и проект начал своё выполнение.



Автотест успешно запущен! Оркестратор позволяет не только запускать наши автотесты вручную, но и настроить их запуск по расписанию и в случае необходимости параллельно.

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

Следующая стандартная задача любого инструмента автоматизации — это отчётность. Primo позволяет настроить в качестве отчётности любой привычный для автотестера инструмент, например, Grafana или Allure.

Рассмотрим в качестве примера реализацию визуальной отчётности выполнения RPA-проектов в Grafana.

На общем графике всех успешных выполнений виден провал в середине, который означает, что в промежутке 16:45 — 17:15 успешно выполнилось только 80 % всех запущенных проектов.

Полученные данные показывают сбои в работе тестируемых систем в этот период.



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



Также для наглядности есть графики выполнения по каждому проекту. Проект А:



Проект Б:



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

Спасибо Александру Степанову, разработчику RPA, за помощь с подготовкой этого поста.

Комментарии (2)


  1. SaintMortum
    20.10.2022 10:51
    +3

    Вот и ответ чем плохо легаси. В 1С у вас старый интерфейс, который уже не развивается лет 5, не меньше. И для тестов приходится городить костыли типа RPA. А могли бы разрабатывать на управляемых формах, которым лет 10, не меньше :) и там писать нормальные тесты используя возможности платформы.


    1. capitannemo
      20.10.2022 21:38

      Вспоминается...
      На автосервисную точку для "Мерседесов" подъезжает "Запорожец".Оттуда вылезает мужик:
      - Ребята, поставьте мне какую-нибудь деталь от "Мерседеса" на машину.
      - Да ты чего, мужик?!
      - Ну очень хочется, вот, деньги всю жизнь копил...
      - Ну ладно, приходи завтра...Мужик приходит, садится в машину, заводит. Заводится так сразу, легко.Мужик в восторге, никогда так еще не было... Потом так мягко трогается, едеттихо, ну просто в кайф... Метров сто отъехал, вдруг машина почему-то назадпоехала. Обратно доехал, вылезает.
      - Ну, мужики! Что такое? Сначала так здорово все было, а потом...
      - Эээ, мужик, мы тебе двигатель от дворников поставили...

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