Пожалуй, сейчас уже нет ни одного специалиста по тестированию, который бы не задумывался над вопросом автоматизации тестирования. Великое множество фреймворков, языков, специальных инструментов автоматизации — выбирай самый подходящий, на твой взгляд, и автоматизируй. Но не всегда всё так просто.
Попытки использования общепринятых фреймворков автоматизации тестирования для 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С.
Начнём с взаимодействия «клик по кнопке» для открытия списка справочников:
Следующий вид взаимодействия — это клик в поле ввода текста:
Уникальные свойства такие же, как с кнопкой открытия справочников (это тип и имя):
И третий вид взаимодействия — клик по чекбоксу:
Уникальными свойствами будут имя и текст при наведении (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, за помощь с подготовкой этого поста.
Попытки использования общепринятых фреймворков автоматизации тестирования для 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С выбираем кнопку «Справочник…»:
- Выбираем уникальные свойства элемента, такие, как тип и имя:
- Клик готов!
Следующий вид взаимодействия — это клик в поле ввода текста:
Уникальные свойства такие же, как с кнопкой открытия справочников (это тип и имя):
И третий вид взаимодействия — клик по чекбоксу:
Уникальными свойствами будут имя и текст при наведении (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, за помощь с подготовкой этого поста.
SaintMortum
Вот и ответ чем плохо легаси. В 1С у вас старый интерфейс, который уже не развивается лет 5, не меньше. И для тестов приходится городить костыли типа RPA. А могли бы разрабатывать на управляемых формах, которым лет 10, не меньше :) и там писать нормальные тесты используя возможности платформы.
capitannemo
Вспоминается...
На автосервисную точку для "Мерседесов" подъезжает "Запорожец".Оттуда вылезает мужик:
- Ребята, поставьте мне какую-нибудь деталь от "Мерседеса" на машину.
- Да ты чего, мужик?!
- Ну очень хочется, вот, деньги всю жизнь копил...
- Ну ладно, приходи завтра...Мужик приходит, садится в машину, заводит. Заводится так сразу, легко.Мужик в восторге, никогда так еще не было... Потом так мягко трогается, едеттихо, ну просто в кайф... Метров сто отъехал, вдруг машина почему-то назадпоехала. Обратно доехал, вылезает.
- Ну, мужики! Что такое? Сначала так здорово все было, а потом...
- Эээ, мужик, мы тебе двигатель от дворников поставили...
Если вы присмотритесь, то статью пишет системный интегратор. К нему с чем клиент пришел, с тем он и работает, это раз
А два, переходить с обычных форм на управляемые только для тестов, это не только контрпродуктивно, но и раза в 2 тормознет систему в целом.