Разработка
Ivan Melnikov

Применение RPA в автоматизации тестирования

Привет! Меня зовут Иван Мельников и я директор по развитию продуктов компании ROBIN. Перед вами рассказ о том, как тестировщики искали инструменты для автоматизации тестирования.

Про автоматизацию тестирования

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

Разрушая мифы

Автоматизация подходит не всем и вся. Разберем популярные тезисы:

#1 Автоматизация экономит время и ресурсы

Реальность: Автоматизация экономит время при многократном выполнении сценариев тестирования. Зачем автоматизировать процесс, если сценарий пройдет один раз?

#2 Автоматизация быстрее, чем ручной труд

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

#3 Более широкий тестовый охват функций приложения

Реальность: Тезис верен, только если система автоматизации позволяет автоматизацию этой функции.

#4 Автоматизация позволяет тестировать часто и тщательно

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

Автоматизация — фу. А, не — показалось

У автоматизации есть и свои плюсы:

  • Построение и внедрение полноценного процесса DevOps.
  • Быстрая подготовка большого объема тестовых данных.
  • Возможность оперативно протестировать ПО до публикации кода.
  • Быстрая проверка исправлений багов тестировщиками.
  • Сокращение времени полной проверки продукта с нескольких недель до нескольких часов (зависит от продукта).

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

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

Наш опыт

В ROBIN мы пересмотрели и перепробовали разные подходы к автоматизации тестирования интерфейса (UI) и интеграций (API):

Собственный фреймфорк

Мы пытались создать собственное решение, которое подойдет под нужды отдела и компании: мы создали солянку из Selenium, C#, и Jenkins. Что вышло для тестирования разных приложений:

1. Расчет размера налогового вычета

Что сделали: Автоматизировали тесты UI, API; подключение к CI (Jenkins)

Команда: 1 человек

Результаты:

  • Процент покрытия тестовой модели: 60%
  • Время на полный регресс: <4 часов
  • Кол-во обнаруженных критичных дефектов на проме сократилось в два раза

2. Система распределения задач

Что сделали: Автоматизировали тесты UI, подключение к CI

Команда: 3 человека

Результаты:

  • Процент покрытия тестовой модели: 50%
  • Время на полный регресс снизилось до 2 дней с 7 дней
  • Сократилось кол-во обнаруженных дефектов на ПСИ (приемо-сдаточных испытаниях) по данным, собранным за 3 месяца

3. Система расчета ключевых показателей

Что сделали: Автоматизировали тесты UI, API

Команда: 1 человек

Результаты:

  • Процент покрытия тестовой модели: 80%
  • Время на полный регресс: 2 часа
  • Количество обнаруженных дефектов за время ОПЭ (опытно-промышленной эксплуатации) с высоким уровнем критичности — 1 (изначально попал в 20% непокрытых авто-тестами)

4. Система работы с обращениями клиентов

Что делали: Автоматизировали тестирование UI, API

Команда: 2 человека

Результаты:

  • Процент покрытия тестовой модели: 70%

  • Время на полный регресс сократился до 1 дня вместо 7 дней

  • Количество итераций тестирования в конце релиза сократилось с 5-6 до 1-2

5. Система открытия счетов

Что делали: Автоматизировали тестирование UI, API

Команда: 1 человек

Результаты:

  • Время на полный регресс: 7 дней
  • Кол-во обнаруженных критичных дефектов на проме сократилось на 40% На основе данных, собранных за 3 месяца
  • Процент покрытия тестовой модели: 20%

6. Система выдачи кредитов

Что делали: Автоматизировали тесты UI, подключение к CI

Команда: 3 человека

Результаты:

  • Процент покрытия тестовой модели: 50%
  • Время на полный регресс снизилось до 2 дней вместо 3 дней
  • Кол-во обнаруженных критичных дефектов на проме сократилось на основе 3-месячного наблюдения

Готовые бесплатные фреймворки

Мы использовали готовые фреймворки для автоматизации тестирования: Selenide, JDI, Cucumber. Также в список включили автоматизацию через условно-бесплатный инструмент Postman.

1. Система продаж

Что сделали: Автоматизировали тесты UI, API, подключение к DevOps.

Команда: 5 человек.

Результат:

  • Процент покрытия тестовой модели: 50%
  • Возможность реализации концепции DevOps
  • Кол-во обнаруженных критичных дефектов на проме сократилось значительно, по результатам наблюдений за 3 месяца

2. Система регистрации новых клиентов и открытия счетов (Postman)

Что сделали: Автоматизация API-тестов.

Команда: 4 человека.

Результат:

  • Процент покрытия тестовой модели: 90%
  • Возможность реализации концепции DevOps
  • Время на полный регресс сократилось до 2 часов вместо 72 часов
  • Кол-во обнаруженных критичных дефектов на проме за полгода: 1
  • Частота поставок – 2 раза в неделю

Готовые платные системы

Пробовали и платные системы: HP UFT, Katalon. Что из этого вышло:

1. Система работы с кредитными заявками

Что сделали: Автоматизировали тесты UI, API.

Команда: 5 человек.

Результаты:

  • Процент покрытия тестовой модели: 50%
  • Возможность реализации концепции DevOps
  • Время на полный регресс сократилось до 3 дней вместо 10
  • Кол-во обнаруженных критичных дефектов на проме сократилось значительно, по результатам наблюдений за 3 месяца

Что поняли из поисков

Каждый из инструментов имеет свои плюсы и минусы: в сети тонна материалов и сравнений на каждый из них.

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

  • Нужно иметь хороший скилл программирования.
  • Ресурсоемкие поддержка и доработка используемых инструментов.
  • Конфигурация DevOps происходит самостоятельно и без поддержки -> Внедрение решения по автоматизации в DevOps происходит самостоятельно и без поддержки.
  • Большие ресурсы на поддержку документации и подготовку обучающих материалов.

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

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

Что осознали про автоматизацию тестирования:

  • Если правильно определить цели, продукт автоматизации, и сформировать ограничения – в итоге получится рабочая система для автоматизированной проверки поставок изменений в ПО.
  • Намного проще автоматизировать тесты API, чем UI.

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

Переход на нашу RPA

В итоге, мы переходим на нашу собственную систему ROBIN RPA (Robotic Process Automation).

И у такого перехода видим свои плюсы:

Плюс 1: Визуализация автоматизирования

Использование платформы предполагает либо полное отсутствие, либо минимальное знание языков программирования, которые используем (Java, C#, Python) => Спасибо визуальному интерфейсу. Если и надо добавить код, то на уровне простых функций.

Плюс 2: No English

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

Плюс 3: Легкий онбординг

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

Плюс 4: Минимальные затраты на поддержку

Мы не тратим финансовые ресурсы на развитие платформу. Совсем.

Плюс 5: Поддержка DevOps

Разворачивание и поддержка DevOps либо не требует времени, либо отнимает на 80% меньше времени, чем обычно => Спасибо встроенному решению Оркестратор + возможность его вызова из другой CI системы.

Плюс 6: Легко перебрасывать сотрудников на проекты

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

Плюс 7: Возможность работы с гос. учреждениями

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

RPA Robin как инструмент нагрузочного тестирования

Платформа RPA Robin 2.0 может использоваться для нагрузочного тестирования, ибо функционал позволяет исполнять сценарии параллельно. Однако, на момент написания статьи есть и ограничения, поэтому не стоит сравнивать его с теми же Jmeter или LoadRunner:

  • Каждый робот (алгоритм) – это отдельный процесс, и будет потреблять больше ресурсов, чем выделенный поток.
  • Один робот = один сценарий нагрузки.
  • Отчетность есть, но не больно детальная.
  • Нет встроенного инструмента анализа потребления системных ресурсов.
  • Нет инструмента перехватывания HTTP запросов => сложность при эмуляции работы пользователей в Web-приложении

Держим пункты, описанные выше, в голове и рассмотрим реализацию нагрузочного тестирования с помощью Robin:

API

С определенными ограничениями: предусмотрены готовые действия (шаги в алгоритме в визуальном интерфейсе) для эмуляции SOAP и REST запросов.

Web:

Большое количество требуемых ресурсов железа, потому что Robin воспроизводит сценарий через экземпляр браузера. Исполнение происходит тяжелее, чем эмуляция HTTP-потока через специализированные инструменты.

Получается:

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

  • Под каждый сценарий написать отдельного Робота.

  • Получить отчет о работе Роботов.

  • Написать Робота, запускающего другие Роботы.

  • Получить анализ утилизации ресурсов через внешние инструменты вроде Zabbix.

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

Развитие ROBIN в ближайшем будущем

В списке грядущих изменений:

1. Дерево WEB-элементов

Своеобразный аналог Page object – формирование и последующее использование элементов приложения с их группировкой.

2. Рекордер

  • Запись последовательности действий пользователя в браузере
  • Автоматическое преобразование действий пользователя в шаги Робота и дерево WEB-элементов.

3. Формирование тестового сценария из отдельных действий

Поддержка формирования тестового сценария из отдельных шагов алгоритма в студии:

- Общая информация.

- Предусловие.

- Отдельные шаги.

- Постусловие.

4. Дерево тестов

  • Множество сценариев в рамках одной студии
  • Определение дополнительных признаков сценариев по аналогии с NUnit или xUnit

5. Переиспользование тестов

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

6. Выбор режима запуска тестов

  • На основе сформированных групп
  • На основе сформированных признаков
  • В параллельном и последовательном режимах
  • С помощью Оркестратора

7. Настройка отчетов

Возможность гибкой настройки отчетов по результатам исполнения тестов с использованием Allure.

Общие выводы

Получается:

  • Автоматизация нужна не в каждом случае
  • А если автоматизация нужна – можно попробовать RPA

Сколько чашек чая с печеньками вы можете выпить, пока робот делает за вас работу?: )

0
Комментарии
Читать все 0 комментариев
null