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

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

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

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

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

Автоматизация подходит не всем и вся. Разберем популярные тезисы:
1
Автоматизация экономит время и ресурсы
Реальность: Автоматизация экономит время при многократном выполнении сценариев тестирования. Зачем автоматизировать процесс, если сценарий пройдет один раз?
2
Автоматизация экономит время и ресурсы
Реальность: Тезис действителен только для исполнения сценариев на стабильной системе. Иногда отладить сценарий автоматизации и добиться его стабильного выполнения отнимет больше времени, чем «поработать руками».
3
Более широкий тестовый охват функций приложения
Реальность: Тезис верен, только если система автоматизации позволяет автоматизацию этой функции.
4
Автоматизация позволяет тестировать часто и тщательно
Реальность: Тезис верен, но с одним нюансом: сценарии исполняются одинаково, что приводит к эффекту пестицида (при регулярном прогоне тестовых сценариев ошибки перестают находиться).

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

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

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

Наш опыт

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

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

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

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

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

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

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

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

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

  • Нужно иметь хороший скилл программирования.
  • Ресурсоемкие поддержка и доработка используемых инструментов.
  • Конфигурация 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 могёт:

  1. Под каждый сценарий написать отдельного Робота.
  2. Написать Робота, запускающего другие Роботы.
  3. Получить отчет о работе Роботов.
  4. Получить анализ утилизации ресурсов через внешние инструменты вроде Zabbix.

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

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

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

Общие выводы

Получается:
  • Автоматизация нужна не в каждом случае.
  • А если автоматизация нужна – можно попробовать RPA.
  • Сколько чашек чая с печеньками вы можете выпить, пока робот делает за вас работу?