Всем привет! Меня зовут Максим Брежнев, я инженер нагрузочного тестирования на проекте Сбера. В этой статье я расскажу вам об инструментах нагрузочного тестирования, применяемых в финансово-технической отрасли.

Как я попал в НТ, сам того не ожидая

Нагрузочное тестирование (НТ) — это один из видов тестирования, которое отвечает за тестирование производительности, сбор и анализ полученных данных, определение времени отклика программы или устройства в ответ на внешний запрос, а также за проверку масштабируемости, стрессо- и отказоустойчивости устройств или программ. Основная цель НТ — следить чтобы система или устройство соответствовало предъявляемым требованиям для полноценной работы.

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

В НТ, как и в тестировании в целом, я оказался случайно, в конце 2017г. На тот момент я пребывал в некой неопределённости, так как моя текущая деятельность системным администратором завела меня в опасную «зону комфорта», из которой настало время выбираться. Волею судеб, я оказался в кабинете руководителя отдела тестирования, где и состоялся следующий занятный разговор:

— Нам надо развернуть направление нагрузочного тестирования, слышал о таком? - спросил у меня руководитель.

— Нет.

— Готов этим заняться?

— Конечно!

После я покинул насиженное годами место с понижением оклада, но при этом с большим энтузиазмом и перспективами в будущем.

Да что говорить, новые цели всегда требуют мобилизации всех своих способностей. В моём случае, именно стремление к изучению нового дало мне терпение и усидчивость, напористость и уверенность в себе и своих силах. Кстати, об этих и других навыках, которые важно развивать, чтобы добиться успехов в тестировании, рассказал мой коллега Кирилл Шувалов, рекомендую статью к прочтению.

Спустя два года, я устроился в Smart IT и попал на проект Сбера, где и работаю до сих пор.

В нашей команде НТ мы тестируем разные сервисы и автоматизированные системы, инструментарий НТ-ешника довольно широкий. Давайте рассмотрим инструментарий подробнее.

HP PerformanceCenter

Корпоративным стандартом для нагрузки у нас является HP PerformanceCenter, в основном его используют крупные компании, готовые платить за лицензии.

Инструмент обладает  широким выбором протоколов взаимодействия, большим функционалом и возможностями. Соответственно, скрипты нашего проекта пишутся на С или Java. Затем их необходимо собрать в профиль нагрузки. Профиль нагрузки может состоять из нескольких десятков скриптов, нацеленные каждый на свою интенсивность/длительность/интервал активности. Без чтения документации или помощи опытных коллег поначалу не обойтись. Развёрнутая у нас версия 12.63, в целом, работает стабильно  и  предсказуемо, в сравнении с предыдущей. 

Apache JMeter

Для АС с REST-архитектурой используем старый-добрый Apache JMeter. Материалов по работе с этим инструментом очень много, что-то нового не добавлю. В работе с этим инструментом мы задействуем стандартные http-request sampler, jsr223 preprocessor. Логи транзакций откидываем в свою базу Influx c помощью Backend Listener. Для текущих задач этого достаточно.

Linux и клиенты

В повседневной работе тестировщика пригодится владение командной оболочкой Linux, т.е. bash. Это помогает самостоятельно работать с серверами твоей АС или с серверами с тестовой инфраструктурой: настраивать клиентов для сбора метрик, устанавливать и запускать необходимое ПО, устранять различные инфраструктурные проблемы.

SQLDeveloper - клиент для OracleDB. 

DBeaver - универсальный клиент, вытесняет предыдущий, т.к. работаем ещё и с БД Postgres.

Инструменты для мониторинга и сбора метрик

В тестировании никуда без мониторинга. Благодаря ему мы наблюдаем за поведением АС в целом и на отдельные её элементы при проведении НТ. Используем Grafana для визуализации и анализа данных. Например, в сочетании с базой Influx и клиентом Telegraf мы собираем инфраструктурные метрики(cpu, ram,heap и т д) с серверов на которых установлено приложение нашей АС. 

Связка Influx и Prometheus помогает нам собирать инфраструктурные метрики только для сервисов, использующих контейнеризацию.

Обязательно проводим сбор метрик(бизнес-метрики) из БД АС, либо средствами Grafana без посредников, либо самонаписанными утилитами с перечнем нужных «селектов» в связке с Influx. Мониторинг и анализ этих данных показывает, выполняет ли наша АС свои функциональные задачи.

Пример использования

Допустим, у нас стоит задача провести «Тест стабильности» (Тестирование надёжности) нашей АС, подготовить отчёт(протокол СНТ). Настроенный мониторинг позволяет  сличать визуализированные показатели по инфраструктурным и бизнес-метрикам на всём протяжении теста и по его завершении. Такой способ значительно упрощает и ускоряет процесс выявления мест отклонения поведения системы от ожидаемой картины (рост утилизации ресурсов серверов, ошибочные статусы операций и тд). Далее следует сделать вывод о критичности возникавших ошибок и приложить к отчёту.

Отчёты по результатам проведённых тестов прикладываются в баг-трекер Jira. Этот инструмент удобен для тестировщика тем, что после выявления багов и расставления приоритетов в бэклоге, разработчики ПО могут создать новые ветки в системе управления исходным кодом, такой как Bitbucket, и начать работу над устранением бага прямо из заявки Jira.

Жизненный опыт

Как не рассказать про рядовой, но наглядный случай выявленной после НТ проблеме на АС. После новогодних праздников, предстояло заняться тестированием нового релиза. Установили крайнюю сборку приложения нашей АС, которая прошла интеграционно-функциональное тестирование (ИФТ), на стенд НТ для регресса. Регресс подразумевает под собой проверку уже протестированного функционала. Ничего не предвещало беды, но спустя час «теста стабильности» приложение упало с ошибкой «OutOfMemoryErr:Java heap space». Т.е. утечка памяти java-процессом. Теперь наша задача выяснить причины.  

Наше java-приложение  развернуто на IBM WebSphere. В результате падения, был создан файл дамп javacore, который мы отыскали в недрах WebSphere.

Далее для анализа это файла нам понадобится запустить приложение IBM Heap Analyzer, разработанное специально для таких случаев. Ранее с этим приложением я не сталкивался, но существенных затруднений не возникло. Файл дампа был большой и никак не удавалось его открыть на своей машине, т.к. не хватало локального размера RAM. Потребовалось задействовать один из серверов, а при открытии дампа потребовалось около 22Gb. Так мы открыли файл и обнаружили класс, который занял более 50% всего размера heap.

В результате был заведён инцидент на команду разработки с описанием нашего профиля нагрузки и полученными в ходе тестов ошибками.

Выводы

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

В финтехе для нагрузки используется HP PerformanceCenter, для АС с REST-архитектурой используется  Apache JMeter. Также, в повседневной работе НТ-тестировщика пригодится владение командной оболочкой Linux, т.е. bash и парочкой клиентов: SQLDeveloper и DBeaver. Помимо всего прочего, важным моментом в работе является мониторинг метрик, сбор и анализ данных. В этом вам помогут такие инструменты как: Grafana, Influx, Telegraf и Prometheus.

Ну, а если вы это уже все знаете и умеете, и думаете о смене проекта, то welcome в нашу аутстафф-команду. Сейчас мы в поиске Middle и Senior НТ-специалистов по стеку: oracle, loadrunner, jenkins, influx+grafana, java для работы над проектом Банка Открытие. Для того чтобы подать заявку на вакансию, нажмите тут.