codename: Taurus

В статье рассматривается инструмент для простого доступа к различным средствам автоматизированного нагрузочного тестирования WEB-ресурсов.

Введение в нагрузочное тестирование

Нередко можно встретить снисходительное отношение к тестированию со стороны программистов, поэтому мы позволим себе объяснить важность предметной области и заодно провести маленький ликбез.

Вообразите себя владельцем интернет-магазина. Через месяц грядут большие распродажи и вы не знаете – ожидает вас рост объёмов или падение сервера и язвительные шутки конкурентов (впрочем, если вы известный монополист авиаперевозок – дальше можете не читать). Вот если бы эти пользователи набежали прямо сейчас, то, оценив нагрузку, вы бы добавили нужных ресурсов. Но каких именно? Памяти или процессоров? Или дискового кэша? А может всё и так хорошо?
Определенность в данной ситуации – большое конкурентное преимущество для бизнеса и он ставит задачу: создать виртуальную нагрузку. Пусть два бота кладут товары в корзину, один пытается оплатить ещё один отменяет заказ и три в это время регистрируются, итого – семь. Или семь миллионов – как пожелает тот, кто создает нагрузку.

Здесь пора обозначить два понятия: генератор нагрузки (приложение, возможно много копий одного приложения в облаке, эмулирующие пользователей) и тест-план – сценарий поведения бота.

Существующие инструменты

Люди, имеющие отношение к обсуждаемой области, обязательно слышали про JMeter, Gatling, Selenium, более опытные могут упомянуть ещё с полдюжины средств генерации нагрузки. Итак, первая проблема – этих средств просто много и они совершенно разные. ctoНекоторые, как JMeter, для описания тест-плана требуют использования графического интерфейса, другие, как Gatling, опираются внутри на классические языки программирования (Scala, Java, Python). У них отличаются умолчания, способности распределенного выполнения и даже наличие такого базового функционала, как возможность поддерживать нагрузку определенное время. Эти инструменты имеют разную способность к автоматизации – некоторые, о ужас, возвращают успешный код завершения когда тест провалился. Люди, отвечающие за работу CI, понимают, что проверять систему подобными инструментами становится крайне неудобно. Впрочем, есть одна область, в которой традиционные инструменты нагрузочного тестирования достаточно близки: результаты их работы сложно увидеть, а увидев – почти невозможно понять.

Наш подход

Я прошу прощения если вы эксперт в данной области и описанные сложности кажутся вам надуманными. Вы, не просыпаясь, в уме разбираете километровые csv-файлы с timestamp’ами в UTC и ваш мощный скрипт рисует рисует графики, от которых в восхищении весь совет директоров. У меня для вас плохие новости: мы решили снизить планку входа в нагрузочное тестирование. Это не обязательно означает помочь вчерашним студентам начать карьеру в IT – нередко в нагрузочное тестирование приходят и опытные разработчики, с одной стороны, предпочитающие аскетичный внешний вид и ясные конфигурационные файлы а с другой, – активно использующие автоматизацию и нуждающиеся в свежих наработках индустрии. Мы в BlazeMeter проанализировали существующие инструменты и решили, что знаем, как упростить жизнь и новичкам, и экспертам.

Чтобы попробовать Taurus, нам понадобится:

1. установить инструмент (проще всего – из репозитория пакетов Python утилитой pip, но есть и нативные установщики для различных OS и даже образ для Docker’a)
2. создать конфигурационный файл для описания тест-плана:
   

   ---
   
   execution:
   
   - concurrency: 100
   
     ramp-up: 1m
   
     hold-for: 5m
   
     scenario: quick-test
   
   scenarios:
   
     quick-test:
   
       requests:
   
       - http://blazedemo.com

3. запустить инструмент, передав ему параметром конфигурационный файл
   $ bzt <test_file>

Открывающийся после этого при настройках по умолчанию псевдографический мониторинг не только вызывает вау-эффект у настоящих гиков, но и неплохо позволяет анализировать тест в динамике:

Как это готовить правильно?

Конфигурационный файл может быть написан на YAML либо JSON. На вышеприведенном примере рассмотрим синтаксис первого из них. Файл должен начинаться с трех дефисов, отступы задают иерархию, основные строительные элементы – списки и словари, один элемент структуры на строку. Этих знаний достаточно, чтобы понимать и модифицировать образцы (например, с сайта gettaurus.org).

Приложение консольное, вопросов не задает и сходу встраивается в любую автоматизацию. На это хотелось бы обратить особое внимание: не просто совместимость, но удобство применения, скажем, для Continuous Integration – едва ли не основной принцип проекта. Добавлением нескольких строчек возможно:

• запустить одновременно несколько генераторов нагрузки;
• отложить тест на определенное время;
• настроить критерии успешности теста в том числе и на основании полученных http-пакетов;
• менять исполнителя – например, потребление ресурсов JMeter’ом вас не устраивает или нужны возможности Selenium’а;
• использовать разные типы http-запросов, добавлять заголовки и т.д.;
• получить web-отчет, ссылку на который можно отправить коллеге;
• перенести тест в облако и выполнить на десятках виртуальных машин (осторожно, это может быть платно, о чем я расскажу ниже).

Сейчас мы поддерживаем девять генераторов нагрузки – JMeter, Selenium, Gatling, Grinder, Locust, PBench, Siege, Apache Benchmark и Tsung.

Taurus преобразовывает конфигурационные параметры в опции, понятные конкретному генератору. Для JMeter генерируется XML (JMX), для Gatling – код на Scala (разумеется, выполнение уже готовых нативных тестовых скриптов также возможно). При необходимости Taurus скачивает инструмент из сети, запускает, следит за работой показывая промежуточные результаты (более или менее в реальном времени) и в конце теста выдает финальный отчет.

Отдельно нужно коснуться некоторых принципов выдачи результатов.
Данные агрегируются по временным интервалам и выделяются настраиваемыми перцентилями – так, например, инженеру будет интересно, уложились ли 98% запросов в лимит времени. При этом результаты различных инструментов выглядят одинаково и могут сравниваться по основным метрикам.

Ещё пользователь может:

• выполнять мониторинг ресурсов как генерующей нагрузку системы, так и нагружаемой – очевидно, истощение ресурсов любой из них тестировщику следует знать;
• производить быструю настройку переопределяя элементы конфигурации из командной строки;
• структурировать тест-план используя включаемые файлы;
• определять команды операционной системы для выполнения на разных этапах теста.

Для специалистов замечу, что основным поддерживаемым инструментом является JMeter, так уж сложился спрос в индустрии.

Работа изнутри, перспективы

В данный момент разработка идет силами трех человек программистов. Исходный код публично на Github, поддержка пользователей идет посредством Google Groups. Для контроля качества кода изменения оформляются pullrequest’ами, проходящими обязательное review. Выделенных тестировщиков нету, их роль играет армия пользователей, на сообщения которых мы стараемся реагировать безотлагательно.
Код основательно покрыт юнит-тестами (на данный момент покрытие составляет 92%).

Сборку и деплой пакета и сайта Taurus’a осуществляет Jenkins, выполняя перед этим функциональное и unit-тестирование. Для проверки commit’ов используются также Travis и Appveyor. JIR’ы у нас нету, и github’овский issue tracker отключен по вышеупомянутым соображениям – основная идея поддержки заключается в том, чтобы исправлять выявленные баги немедленно.

Можно уверенно говорить что мы уже стали полезны – в этом году нас почтил вниманием devops.com. Развитие идет достаточно активно, по крайней мере, новый функционал добавляется в планы быстрее, чем реализовывается.

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

Основная задача, которую ставит перед нами BlazeMeter – делать удобный продукт, который привлечет ощутимую часть сообщества, поэтому многие новые направления вырастают из хотелок пользователей. Из подобных глобальных вещей могу отметить скорый приход поддержки функционального тестирования, валидацию конфигурационных файлов, скоростную фотосъемку загрузки web-страницы, поддержку Selenium-тестов на .Net и JS.

Как мы дошли до такой жизни

Компания BlazeMeter, зарегистрированная в США и имеющая команду разработки в Израиле, уже около пяти лет предлагает средства для тестирования формата “поставь галочки на сайте а мы за тебя создадим нагрузку и покажем отчет”.

В поисках новых ниш компания обратила внимание на инженеров. Даже не принося деньги напрямую довольные технически грамотные люди создают очень полезный с точки зрения IT-бизнеса фон, недостижимый, например, рекламой или скидками. Этим клиентам не лень читать документацию, но им нужны очень мощные и гибкие инструменты, а ещё лучше – поддержка тех инструментов, которые они уже используют (много ли среди нас желающих переучиваться?). А то, что они используют, оставляет желать лучшего – значит, есть где приложить силы и получить хорошую репутацию.

Языком для проекта был выбран Python, отлично подходящий для работы со сторонними инструментами в командной строке на различных архитектурах, лицензией – Apache 2.0. Архитектура модульная, многие компоненты вполне могут быть переписаны программистом средней руки (поддержка новых генераторов нагрузки или специфический репортер, скажем, отправляющий SMS-сообщения).

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