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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наш опыт

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

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

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

Приложение	Что сделали	Команда	Результат
Расчет размера налогового вычета.	Автоматизировали тесты UI, API, подключение к CI (Jenkins).	1 человек.	#1 Процент покрытия тестовой модели: 60%. #2 Время на полный регресс: <4 часов. #3 Кол-во обнаруженных критичных дефектов на проме сократилось в два раза.
Система распределения задач	Автоматизировали тесты UI, подключение к CI	3 человека.	#1 Процент покрытия тестовой модели: 50%. #2 Время на полный регресс снизилось до 2 дней с 7 дней. #3 Сократилось кол-во обнаруженных дефектов на ПСИ (приемо-сдаточных испытаниях) по данным, собранным за 3 месяца.
Система расчета ключевых показателей	Автоматизировали тесты UI, API.	1 человек.	#1 Процент покрытия тестовой модели: 80% #2 Время на полный регресс: 2 часа #3 Количество обнаруженных дефектов за время ОПЭ (опытно-промышленной эксплуатации) с высоким уровнем критичности - 1 (изначально попал в 20% непокрытых авто-тестами).
Система работы с обращениями клиентов	Автоматизировали тестирование UI, API.	2 человека.	#1 Процент покрытия тестовой модели: 70% #2 Время на полный регресс сократился до 1 дня вместо 7 дней. #3 Количество итераций тестирования в конце релиза сократилось с 5-6 до 1-2.
Система открытия счетов	Автоматизировали тестирование UI, API.	1 человек.	#1 Процент покрытия тестовой модели: 20% #2 Время на полный регресс: 7 дней. #3 Кол-во обнаруженных критичных дефектов на проме сократилось на 40%. На основе данных, собранных за 3 месяца.
Система выдачи кредитов	Автоматизировали тесты UI, подключение к CI.	3 человека.	#1 Процент покрытия тестовой модели: 50% #2 Время на полный регресс снизилось до 2 дней вместо 3 дней. #3 Кол-во обнаруженных критичных дефектов на проме сократилось на основе 3-месячного наблюдения.

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

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

Приложение	Что сделали	Команда	Результат
Система продаж	Автоматизировали тесты UI, API, подключение к DevOps.	5 человек.	#1 Процент покрытия тестовой модели: 50%. #2 Возможность реализации концепции DevOps.#3 Кол-во обнаруженных критичных дефектов на проме сократилось значительно, по результатам наблюдений за 3 месяца.
Система регистрации новых клиентов и открытия счетов (Postman)	Автоматизация API-тестов.	4 человека.	#1 Процент покрытия тестовой модели: 90%. #2 Возможность реализации концепции DevOps. #3 Время на полный регресс сократилось до 2 часов вместо 72 часов. #3 Кол-во обнаруженных критичных дефектов на проме за полгода: 1. #4 Частота поставок – 2 раза в неделю.

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

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

Приложение	Что сделали	Команда	Результат
Система работы с кредитными заявками	Автоматизировали тесты UI, API.	5 человек.	#1 Процент покрытия тестовой модели: 50%. #2 Возможность реализации концепции DevOps. #3 Время на полный регресс сократилось до 3 дней вместо 10. #4 Кол-во обнаруженных критичных дефектов на проме сократилось значительно, по результатам наблюдений за 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 в ближайшем будущем

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

Изменение	Описание
Дерево WEB-элементов	Своеобразный аналог Page object – формирование и последующее использование элементов приложения с их группировкой.
Рекордер	#1 Запись действий пользователя в браузере. #2 Автоматическое преобразование действий пользователя в шаги Робота и дерево WEB-элементов.
Формирование тестового сценария из отдельных действий	Поддержка формирования тестового сценария из отдельных шагов алгоритма в студии:- Общая информация. - Предусловие. - Отдельные шаги. - Постусловие.
Дерево тестов	#1 Множество сценариев в рамках одной студии. #2 Определение дополнительных признаков сценариев по аналогии с NUnit или xUnit.
Переиспользование тестов	Возможность переиспользования готовых тестов в других тестах.
Выбор режима запуска тестов	#1 На основе сформированных групп. #2 На основе сформированных признаков. #3 В параллельном и последовательном режимах. #4 С помощью Оркестратора.
Настройка отчетов	Возможность гибкой настройки отчетов по результатам исполнения тестов с использованием Allure.

Общие выводы