Всем привет! Я Вера, инженер по обеспечению качества в Т-Банке. Работала в разных командах и направлениях. Стараюсь всегда расширять свои знания и узнавать что-то новое.
В какой-то момент познакомилась с нагрузочным тестированием и решила выяснить, как небольшой команде удается справляться с такой большой компанией :-) Ребята не смогли бы поддерживать более 750 проектов, если бы просто был один большой отдел нагрузочного тестирования, куда под все нужды нанимали бы специалистов.
Перед командой стояла задача создать схему действий для внедрения и настройки нагрузочного тестирования в проектах. Схема должна подходить для всех проектов и быть удобной для использования. Это статья об истории создания и развития автоматизированной системы Cosmos.
Зарождение тестирования производительности
Нагрузочник, или специалист НТ, — это человек, который внедряет процесс нагрузочного тестирования в компании. В сам процесс входит многое: от анализа приложения до написания тестов и анализа результатов.
Давным-давно, в 2017 году, отдел НТ решил провести нагрузочное тестирование. Команда и основной стек были на Scala, поэтому в качестве инструмента был выбран Gatling (ядро Gatling тоже написано на Scala). Gatling был понятен разработчикам и автотестерам, решившим попробовать провести нагрузочное тестирование. Тестировщики могли разрабатывать скрипты на понятном им DSL, и такие скрипты напоминали unit’ы или автотесты. Попробовали — и результаты понравились.
Решили масштабировать идею на другие отделы и проекты. Так зародилось небольшое направление — тестирование производительности.
Поначалу возникало много проблем, так как первые тесты запускались с личного компьютера. Поэтому был выделен сервер, с которого запускали нагрузку. Отчеты складывали в Confluence, потому что там можно:
— оптимизировать ресурсы;
— стандартизировать запуски;
— хранить и использовать результаты нагрузочного тестирования;
— управлять запусками;
— работать совместно с другими запущенными тестами. Например, выключить сломанный тест.
У Confluence были свои минусы из-за большого количества рутинной работы: выгружать результаты, потом руками переформатировать в отчеты и прочее. Но первое время жили с ним.
Нагрузочник — хранитель знаний
Выросло количество проектов, которые хотели внедрить себе нагрузочное тестирование. Команда НТ расширялась, но сами инженеры были привязаны к конкретным проектам и направлениям. Часто нагрузочники решали одну и ту же задачу, но на разных языках программирования. В одном направлении нагрузочник мог не знать, что делает нагрузочник другого направления. По сути, инженер по НТ был хранителем всех знаний по своему направлению. Если он уходил в отпуск, проекты вставали.
При этом сами проекты не хотели участвовать в нагрузочном тестировании: они считали, что достаточно нагрузочника.
Земля — это колыбель разума, но нельзя же вечно быть в колыбели.
К. Э. Циолковский
В итоге решили разработать общие инструменты: и для нагрузочников и для проектов. План был такой:
Создать общий контекст. Сама команда НТ должна шарить знания, шарить задачи, помогать друг другу.
Описать и стандартизировать требования. Выявить то, что повторяется, и прийти через стандартизацию к тому, чтобы это автоматизировать.
Разработать понятный и удобный инструментарий для разработчиков. В идеале он должен работать по принципу кода.
Автоматизировать, чтобы система работала из коробки. Нужно было настроить автоматизацию и пользоваться ею, уменьшая рутинную работу. Так освобождалось время для исследований и более приоритетных задач.
Первые шаги и выбор инструментов
Команда НТ начала встречаться на общих митингах, которые переросли в ежедневные встречи. На встречах рассказывали о проблемах и задачах. Постепенно определили общий стек и сформулировали цели.
Для постановки целей выбрали фреймворк OKR. Он хорош тем, что можно оттолкнуться от действительной надобности и поставить задачи снизу: что необходимо решить прямо сейчас. Ребята поставили цели, обозначили критерии их достижения. Начали пилить и формировать бэклог.
Для процессов и workflow выбрали Kanban, потому что он позволяет точно оценивать сроки и предоставлять результаты вовремя, равномерно распределять нагрузку по задачам. К Kanban пришли через подход, называемый S.T.A.T.I.K.
Начали внедрять CI/CD. Увеличилось количество запусков, появилась обратная связь и от проектов. Возникло понимание, что им нужно, что полезнее сейчас. Например, увидеть процесс выполнения, сформировать результат в отчет и так далее. А еще появилась обратная связь от самой команды НТ и совместный доступ к запускам и артефактам.
Появились пайплайны: удобный инструмент кастомизации и добавления модулей. Начали разрабатывать общие модули: нотификации, некая подготовка проекта, работа с результатами, управление доступами и прочее.
Так как появился общий пайплайн и более-менее понятный запуск, не составило труда сделать шаблон, который называется Gatling Getter8 Template. Шаблон позволяет в пару кликов развернуть весь проект нагрузочного тестирования под ключ — останется только написать скрипты, то есть саму логику сценариев.
Со стандартизированным запуском и шаблоном появился переиспользуемый код. Ребята постоянно одинаково готовили данные — и решили все это оформить в виде библиотек. Так возник Gatling Picatinny. В нем много разных функций, помогающих подготовить данные, пробросить секреты, сделать шаблоны.
Когда библиотек и зависимостей стало много, чтобы все ускорить, сделали docker-файл и назвали Docker Gun. В нем уже все было прогрето, скачаны нужные кэши и нужные библиотеки. Оставалось только развернуть его — и можно запускать тест.
В пайплайн добавили обработку результатов, которая помогла автоматизировать подготовку данных для отчета. Сначала это был parser, он просто трансформировал данные в более удобные, которые потом вставлялись в Confluence. В самом Confluence разработали небольшой каталог — иерархию, чтобы понимать, как вообще распределять проекты. С ним можно было быстро их найти, исторически взглянуть на какой-то релиз и так далее.
Как погрузить разработчиков в тестирование
Команда НТ сделала много инструментов и показала их проектам. Но они никак не хотели вникать в нагрузочное тестирование. Было важно подготовить другие команды к внедрению нагрузочного тестирования, чтобы каждый мог настраивать его самостоятельно, не ожидая нагрузочника.
Единственный способ добиться самостоятельности — погрузить проекты в разработанные инструменты, в теорию. И главное, начать с ними общаться. А еще — обозначить ответственность конкретных команд за то, как будет подготовлено нагрузочное тестирование.
Ответственность прорабатывали так: проект не брали, если не был выделен разработчик, который расскажет про его окружение и развертывание. Должен быть кто-то, кто поможет подготовить и собрать знания о проекте.
Необходимым условием стало то, что разработчик помогал составить архитектурную схему и разобраться в ней. Потому что кто, как не разработчик, знает про свой сервис. И вместо того чтобы быть сломанным телефоном, смотреть старую документацию, ребята из НТ сразу пилили архитектурную схему, хранили ее рядом с кодом и потом собирали. К примеру, собирали методику нагрузочного тестирования с помощью статических генераторов файлов. Можно было сразу из скриптов смотреть, как выглядит эта методика.
Еще одно важное условие — разработчиков заставили писать нефункциональные требования в файл. К примеру, в конфигурации в YML было прописано:
— какие response time ожидаются;
— какой должен быть throughput, threshold, percentile.
Команда проекта вовлекалась на всех стадиях подготовки к внедрению нагрузочного тестирования. Потому что только так можно было узнать общие цели друг друга и получить нужный результат — тот, которого ожидали. И при этом не разойтись во взглядах и мнениях, как правильно тестировать.
Со своей стороны, ребята из НТ предоставляли общий workflow через мессенджер. Если какая-либо команда хотела настроить нагрузочное тестирование на своем проекте, она запускала workflow и ребята проводили их по всем стадиям подготовки.
На каждой стадии была система ревью — ответственные смотрели, что конкретно и на каком этапе находится. Сами проекты тоже знали, как все это будет тестироваться.
Задачей команды НТ стало не только написание скриптов и поиск актуальной документации. Как сервис нагрузочного тестирования, ребята прорабатывали стратегию тестирования вместе с командой проекта — чтобы все знали, как это работает и что получим в результате. И во время проработки этой стратегии команда проекта обучалась.
Для сотрудников компании создали школу по тестированию производительности. В нее приглашали разработчиков, ручных тестировщиков, автотестировщиков. Впоследствии переформатировали школу в хороший внутренний курс о том, как пользоваться разработанным инструментом, как читать результаты и как их анализировать.
По сути, команда НТ соединила разработку и тестирование. Обучили проекты теории, научили пользоваться инструментом и очень сильно приблизились к тому, чтобы можно было запускать много-много тестов и повышать интеграцию.
Все больше проектов хотели внедрять к себе нагрузку и при этом использовать стабильные и актуальные инструменты. Опыт по внедрению нагрузки на различные проекты был получен, поэтому команда НТ передала этап Workflow & Review самим проектам. Они теперь сами инициализируют у себя тестирование. Для этого оформили документы и инструкции.
По необходимости можно подключить ребят из НТ в помощь. Сама команда сконцентрировалась на разработке утилит, системы отчетности, поддержании работоспособности текущего сервиса. А еще — на улучшении и расширении общих правил, требований, подходов.
Анализ результатов
Уметь запускать тесты и пользоваться инструментами недостаточно. Нужно понимать, как анализировать результаты. Перед командой стояла задача создать удобный инструмент отчетов, который будет понятным и показательным.
Первым делом переписали parser, который трансформировал результаты в формат для отчетов в Confluence. Вместо просто парсинга результатов стали брать сырые результаты, анализировать их и складывать агрегированные метрики в базу данных. Но этого было недостаточно.
Не хватало понимания, как раскладывать данные. К примеру, часто приходилось искать список направлений, бизнес-линий, держать его актуальным и заполнять в базе руками. Это была проблема.
На помощь пришла внутренняя платформа, которая помогает разработчикам на всем пути разработки бизнес-продуктов. Разработчики сами знали, как им удобно хранить код, как разделять на группы и на репозитории.
Платформа построена на стеке GitLab, и оказалось, что достаточно взять с runner'a всю необходимую информацию о структуре расположения проекта, чтобы разложить получаемые данные.
В итоге была сформирована более простая и плоская иерархия: есть проект, у него есть симуляция и какой-то запуск. Все правильно раскладывалось в базу, и эти результаты лежали достаточно близко к репозиторию с кодом.
Не составило труда написать API и Web-интерфейс, чтобы показывать эти данные из базы. Также интегрировали UI, и разработчики проектов увидели все прогоны и результаты тестов прямо у себя в репозитории, на вкладке «Симуляции».
Система берет NFR-файл, анализирует сырые результаты, смотрит нефункциональные требования и выгружает данные в систему, используя Quality Gate. Это помогает разработчикам принять решение в релизе: посмотреть функциональные и нефункциональные требования, проверки на coverage и так далее.
Ну и конечно, главный профит всей системы — в долгом хранении данных. Пока у команды нет retention-policy, можно построить тренды и увидеть, что было именно в исторической перспективе. Это ценно в самом нагрузочном тестировании: сравнить то, что было сколько-то релизов назад, или посмотреть, как вело себя приложение и что могло повлиять — какой запуск, какой коммит.
Что можно увидеть в отчете
В общих сведениях отчета видно, где что лежит, кто когда запускал тесты, к какой задаче они привязаны. Есть ссылки на GitLab, Grafana, систему с логами. И главное — кроме метрик Percentile или APDEX есть метрика «Оценка качества»: это специальный светофор, опирающийся на установленный уровень Quality Gate. Он сигнализирует об уровне качества прошедшего теста: красный, желтый или зеленый.
Во вкладке анализируется NFR-файл, выполняются assert’ы и отображается результат по каждой проверке. К примеру, видно, что в текущем отчете не попали в RPS в throughput.
Есть система оценок. Они менее кастомизируемые, их нельзя задать через NFR-файл, кроме throughput. Было установлено общее правило: нельзя, чтобы ошибок было больше 5%, иначе эта оценка провалится.
Реализовали возможность сравнивать два произвольных запуска в рамках одного профиля/симуляции. В сравнительном отчете можно посмотреть разность percentile’й.
А в итоге
Человек вырастает по мере того, как растут его цели.
Фридрих Шиллер
Это был длинный и нелегкий путь. Ребята из НТ поняли, что главное — это общение с командами проектов. Необходимо общаться, взаимодействовать и обучать их. Проекты более активно и охотно включаются, если им предоставить необходимые и понятные инструменты.
Нужно развивать инструменты и отчетность. Они должны быть удобными, понятными, и если они для проектов с разработчиками, то делайте все как код.
Нельзя забывать об автоматизации — чтобы заниматься интересной исследовательской работой, а не перекладыванием результатов из файла в файл.
И конечно же, путь не закончился, ребята не останавливаются. Команда продолжает наращивать опыт и знания, трансформирует/упрощает инструменты, совершенствует подходы.
Спасибо! Приходите в наш телеграм-чат.