Применение 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
Сколько чашек чая с печеньками вы можете выпить, пока робот делает за вас работу?: )