Една от проблема, с които често се сблъскват многопродуктови доставчици на софтуер, е дублирането на компетенциите на инженерите — разработчици, тестери и администратори на инфраструктура — почти във всеки екип. Това важи и за скъпоструващите инженери — специалисти в областта на натоварващото тестване.
Вместо да изпълняват преки задължения и да използват уникалния си опит за изграждане на процеса на натоварващо тестване, избор на методология, оптимални стойности на метрики и писане на автоматизирани тестове в съответствие с профилите на натоварване, инженерите често трябва да изграждат тестовата инфраструктура от нулата, да конфигурират инструментите за натоварване, сами да ги интегрират в CI системите, да настройват мониторинга и публикуването на отчети.
Решения на някои организационни проблеми в тестването, които прилагаме в Positive Technologies, можете да намерите в . А в тази ще разкажа за възможността за интеграция на натоварващи тестове в общия CI конвейер с помощта на концепцията „натоварващо тестване като услуга“ (load testing as a service). Ще научите как и какви Docker образи на източници на натоварване можете да използвате в CI конвейера; как да свържете източниците на натоварване в CI проекта си с помощта на шаблон за изграждане; как изглежда демопайплайн за стартиране на натоварващи тестове и публикуване на резултатите. Статията може да бъде полезна на инженери по тестване на софтуер и инженери автоматизатори в CI, които се замислят за архитектурата на системата си за натоварване.
Същността на концепцията
Концепцията load testing as a service предвижда възможността да интегрирате инструменти за натоварване Apache JMeter, Yandex.Tank и собствени рамки в произволна система за непрекъсната интеграция. Демонстрационният пример ще бъде за GitLab CI, но принципите са общи за всички CI системи.
Load testing as a service — това е централизирана услуга за провеждане на натоварващо тестване. Натоварващите тестове се стартират в отделни пулове от агенти, публикуването на резултатите става автоматично в GitLab Pages, Influx DB и Grafana или в системи за отчитане на тестовете (TestRail, ReportPortal и т.н.). Автоматизацията и мащабирането се реализират максимално лесно — чрез добавяне и параметризиране в проекта GitLab CI на обикновения шаблон gitlab-ci.yml.
Предимството на подхода е в това, че всяка CI инфраструктура, натоварващи агенти, Docker образи на източници на натоварване, тестови пайплайни и публикуване на отчети — се поддържат от силите на централизирания отдел за автоматизация (DevOps инженери), а инженерите по натоварващо тестване могат да се фокусират върху разработката на тестове и анализа на техните резултати, без да се занимават с инфраструктурни въпроси.
За простота на описанието ще предположим, че целевото тествано приложение или сървър вече е разположен и настроен предварително (за това могат да се използват автоматизирани скриптове на Python, SaltStack, Ansible и др.). Тогава цялата концепция за натоварващо тестване като услуга се вписва в три етапа: подготовка, тестване, публикуване на отчети. Повече информация на схемата (всички картинки са кликаеми):
Основни понятия и определения в натоварващото тестване
При провеждане на натоварващи изпитания се стараем да се придържаме , използваме съответната терминология и препоръчителни метрики. Представям кратък списък на основните понятия и определения в натоварващото тестване.
Натоварващ агент (load agent) — виртуална машина, на която ще бъде стартирано приложението — източник на натоварване (Apache JMeter, Yandex.Tank или самописен натоварващ модул).
Цел на тестването (target) — сървър или приложение, инсталирано на сървъра, което ще бъде подложено на натоварване.
Тестов сценарий (test case) — набор от параметризирани стъпки: действия на потребителите и очакваните реакции на тези действия, с фиксирани мрежови заявки и отговори, в зависимост от зададените параметри.
Профил или план на натоварването (profile) — в (п. 4.2.4, стр. 43) профили на натоварване определят критично важните за конкретния тест метрики и вариантите за промяна на параметрите на натоварването по време на теста. Примери за профили можете да видите на изображението.
Тест (test) — сценарий с предварително определен набор от параметри.
Тестов план (test-plan) — набор от тестове и профил на натоварване.
Тестран (testrun) — една итерация на стартиране на един тест с напълно изпълнен сценарий на натоварването и получен отчет.
Мрежова заявка (request) — HTTP заявка, изпратена от агента до целта.
Мрежов отговор (response) — HTTP отговор, изпратен от целта до агента.
HTTP код на отговора (HTTP responses status) — стандартен код на отговора от приложенския сървър.
Транзакция (transaction) — пълният цикъл "запитване — отговор". Транзакцията се счита от момента на изпращане на запитването (request) до завършване на приемането на отговора (response).
Статус на транзакцията (transactions status) — дали е успешно завършен цикъла "запитване – отговор". Ако в този цикъл е имало някаква грешка, цялата транзакция се счита за неуспешна.
Време за отговор (latency) — времето от края на изпращането на запитването (request) до началото на приемането на отговора (response).
Метрики на натоварване (metrics) — характеристики на натоварвания сервиз и натоварващия агент, определени в процеса на тестове за натоварване.
Основни метрики за измерване на параметрите на натоварване
Някои от най-обичайните и препоръчвани в методологията (стр. 36, 52) метриките са посочени в таблицата по-долу. Подобни метрики за агента и целта са посочени в един ред.
Метрики за натоварващия агент
Метрики на целевата система или приложение, тествани под натоварване
Брой vCPU и памет RAM,
Диск — "железни" характеристики на натоварващия агент
CPU, Памет, Диск използване — динамика на натоварването на процесора, паметта и диска
в процеса на тестване. Обикновено се измерва в проценти от
максимално достъпните стойности
Мрежова пропускливост (on load agent) — пропускливостта
на мрежовия интерфейс на сървера,
където е инсталиран натоварващият агент.
Обикновено се измерва в байтове в секунда (bps)
Мрежова пропускливост(on target) — пропускливостта на мрежовия интерфейс
на целевия сървър. Обикновено се измерва в байтове в секунда (bps)
Виртуални потребители— брой виртуални потребители,
които реализират сценарии на натоварване и
имитират реални действия на потребителите
Статус на виртуалните потребители, Успешни/Неуспешни/Общо — брой на успешните и
неуспешни статути на работа на виртуалните потребители
за сценарии на натоварване, както и общото им количество.
Обикновено се очаква, че всички потребители ще могат да изпълнят
всички свои задачи, посочени в профила на натоварването.
Всяка грешка означава, че и реалният потребител не може
да реши своята задача при работа с системата.
Запитвания на секунда (минута)— брой мрежови запитвания в секунда (или минута).
Важна характеристика на натоварващия агент: колко запитвания може да генерира.
В действителност, това е имитация на взаимодействие с приложението от виртуални потребители.
Отговори на секунда (минута)
— брой мрежови отговори в секунда (или минута).
Важна характеристика на целевата услуга: колко
беше генерирано и изпратено отговори на запитвания от
нагрузъчния агент.
HTTP статус на отговорите— брой различни кодове на отговор
от приложния сървър, получени от нагрузъчния агент.
Например, 200 OK означава успешно взаимодействие,
а 404 — че ресурсът не е намерен.
Забавяне (време за отговор) — времето от края
на изпращането на запитването (request) до началото на получаването на отговора (response).
Обикновено се измерва в милисекунди (ms).
Време за отговор на транзакция— времето на една цяла транзакция,
завършване на цикъла "запитване — отговор".
Това е времето от началото на изпращането на запитването (request)
до края на получаването на отговора (response).
Времето на транзакцията може да се измерва по няколко начина: считат се минималните,
максималните, средни и, например, 90-тия перцентил.
Минималните и максималните измервания — това са крайни
състояния на производителността на системата.
Деветдесетият перцентил се използва най-често,
тъй като показва как работят повечето потребители,
удобно функциониращи на прага на производителността на системата.
Транзакции на секунда (минута)
— брой завършени транзакции в секунда (минута),
тоест колко приложението успя да приеме и
обработи запитвания и да издаде отговори.
В действителност, това е пропускателната способност на системата.
Статус на транзакциите
, Преминали / Неуспешни / Общо — брой успешни, неуспешни и общ брой на транзакциите.
За реалните потребители, неуспешната
транзакция всъщност ще означава
невъзможност за работа със системата под натоварване.
Принципна схема на нагрузъчното тестване
Принципната схема на нагрузъчното тестване е много проста и се състои от три основни етапа, за които вече споменах:
Подготовка — Тест — Доклад , тоест подготовка на целите на тестването и задаване на параметри за източниците на натоварване, след това изпълнение на нагрузъчните тестове и накрая изготвяне и публикуване на отчет за тестването.Забележки към схемата:
QA.Тестър — експерт по нагрузъчно тестване,
- Цел — целевото приложение, за което трябва да се установи неговото поведение под натоварване.
- Класификатор на обекти, етапи и стъпки в схемата.
Етапи и стъпки
Какво се случва.
Какво става
Какво на входа
Какво на изхода
Подготовка: етап на подготовка за тестване
LoadParameters
Задаване и инициализация
от потребителя
параметри на натоварването,
избор на метрики и
подготовка на тестовия план
(профил на натоварването)
Потребителски параметри за
инициализация на натоварващия агент
Тестов план
Цел на тестването
VM
Разгръщане в облака
на виртуална машина с
необходими характеристики
Параметри на ВМ за натоварващия агент
Скриптове за автоматизация за
създаване на ВМ
Настроена ВМ в
облака
Env
Настройка на ОС и подготовка
окружение за
работа на натоварващия агент
Параметри на околната среда за
натоварващия агент
Скриптове за автоматизация за
настройки на околната среда
Подготвена околна среда:
ОС, услуги и приложения,
необходими за работа
натоварващия агент
LoadAgents
Инсталиране, настройка и параметризиране
на натоварващия агент.
Или изтегляне на Docker образ с
преднастроен източник на натоварване
Docker образ на източника на натоварване
(ЯТ, JM или самостоятелно написан фреймворк)
Параметри на настройка
натоварващия агент
Настроен и готов
за работа натоварващ агент
Test: етап на изпълнение на натоварващи тестове. Източниците са натоварващи агенти, развернати в специализирани пулове агенти за GitLab CI
Load
Стартиране на натоварващия агент
с избрания тестов план
и параметри на натоварването
Потребителски параметри
за инициализация
натоварващия агент
Тестов план
Цел на тестването
Логове от изпълнението
на натоварващите тестове
Системни журнали
Динамика на промените на метриките на целта и натоварващия агент
RunAgents
Изпълнение от агента
на натоварването на тестовите сценарии
в съответствие с
с профил на натоварването
Взаимодействие на натоварващия агент
с целта на тестването
Тестов план
Цел на тестването
Logs
Събиране на "сурови" логове
по време на натоварващото тестване:
записи за действията на натоварващия агент,
състоянието на целта на тестването
и ВМ, на която е стартиран агентът
Логове от изпълнението
на натоварващите тестове
Системни журнали
Metrics
Събиране на "сурови" метрики по време на тестването
Динамика на промените на метриките на целта
и натоварващия агент
Report: етап на подготовка на отчета за тестване
Generator
Обработка на събраните
от натоварващата система и
системата за мониторинг "сурови"
метрики и логове
Формиране на отчет в
човекочитаем вид,
възможно с елементи
на анализ
Логове от изпълнението
на натоварващите тестове
Системни журнали
Динамика на промените на метриките
на целта и натоварващия агент
Обработени "сурови" логове
в формат, подходящ за
извеждане във външни хранилища
Статически отчет за натоварването,
подходящ за анализ от човек
Publish
Публикация на отчета
за натоварване
тестове във външен
сервис
Обработените «сурови»
логове в формат, подходящ за
експорт във външни
хранилища
Запазените във външното
хранилище отчети за
натоварване, подходящи
за анализ от човек
Свързване на източници на натоварване в CI шаблон
Да преминем към практическата част. Искам да покажа как в някои проекти на компанията реализирахме концепцията за натоварвателно тестване като услуга.
Първоначално с усилията на нашите DevOps инженери създадохме в GitLab CI специален пул от агенти за изпълнение на натоварващи тестове. За да не ги объркваме в шаблоните с други, например сборни, пулове, добавихме тагове на тези агенти, : load. Могат да се използват всякакви други разбираеми тагове. Те се задават на GitLab CI Runners.
Как да определим необходимата мощност на «желязото»? Характеристиките на натоварващите агенти — достатъчно количество vCPU, RAM и диск — могат да бъдат изчислени въз основа на това, че на агента трябва да са инсталирани Docker, Python (за Yandex.Tank), агент GitLab CI, Java (за Apache JMeter). За Java под JMeter също се препоръчва да се използва минимум 512 МБ RAM и, като горна граница, .
Така, на базата на нашия опит, препоръчваме да се използват поне: 4 vCPU, 4 ГБ RAM, 60 ГБ SSD за натоварващите агенти. Пропускната способност на мрежовата карта се определя на базата на изискванията на профила на натоварването.
Въз основа на нашите нужди използваме основно два източника на натоварване — Docker образи Apache JMeter и Yandex.Tank.
— това е инструмент с отворен код на компания Yandex за провеждане на натоварващо тестване. Основата на неговата модулна архитектура е високопроизводителният асинхронен hit-based генератор на HTTP заявки Phantom. Tank разполага с вграден мониторинг на ресурсите на тествания сървър по протокол SSH, може автоматично да спре теста при зададени условия, може да изведе резултати както в конзолата, така и под формата на графики, можете да свържете свои модули за разширяване на функционалността. Между другото, ние използвахме Tank, когато това все още не беше мейнстрийм. В статията «» можете да прочетете историята за това как през 2013 година провеждахме натоварващо тестване — един от продуктите на нашата компания.
— това е опенсорсен инструмент за провеждане на натоварващо тестване от компанията Apache. Той може да се използва еднакво добре както за тестване на статични, така и на динамични уеб приложения. JMeter поддържа огромно количество протоколи и методи за взаимодействие с приложения: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET и т.н.), SOAP / REST уеб услуги, FTP, TCP, LDAP, SMTP(S), POP3(S) и IMAP(S), бази данни чрез JDBC, може да изпълнява shell команди и да работи с Java обекти. JMeter разполага с IDE за създаване, дебъгване и изпълнение на тестови планове. Има и CLI за работа в команден ред на всяка операционна система, съвместима с Java (Linux, Windows, Mac OS X). Инструментът може динамично да генерира HTML отчет за тестването.
За удобство при използването в нашата компания, за да позволим на самите тестери да изменят и добавят среди, направихме билдове на Docker образи за натоварващи източници на GitLab CI с публикация во вътрешния . По този начин е по-бързо и лесно да ги свързвате в пайплайни за натоварващи тестове. Как да направите docker push в регистъра чрез GitLab CI — вижте в .
Основният Docker файл за Yandex.Tank взехме оттук:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]А за Apache JMeter този:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Как е организирана нашата система за непрекъсната интеграция, можете да прочетете в статията «».
Шаблон и пайплайн
Пример за шаблон за провеждане на натоварващи тестове е наличен в проекта . В можете да прочетете инструкциите за използване на шаблона. В самия шаблон (файл ) има бележки относно отговорността на всяка стъпка.
Шаблонът е много прост и демонстрира трите етапа на натоварващото тестване, описани по-горе в схемата: подготовка, тестване и публикуване на отчети. За това отговарят : Prepare, Test и Report.
- Етап трябва да се използва за предварителна настройка на целите за тестване или проверка на тяхната наличност. Средата за натоварващи източници не се нуждае от настройка, те предварително са събрани като Docker образи и предоставени в Docker регистър: достатъчно е да посочите необходимата версия на етапа Test. Но можете да ги преобновите и да направите свои модифицирани образи.
- Етап използва се за посочване на източника на натоварване, за стартиране на тестове и за запазване на артефакти от тестовете. Можете да изберете всякакъв източник на натоварване: Yandex.Tank, Apache JMeter, свой собствен или всичките заедно. За да деактивирате ненужните източници, е достатъчно да коментирате или изтриете job-ата. Точки на вход за източниците на натоварване:
- параметрите за стартиране на Yandex.Tank се посочват в файла.,
- параметрите за стартиране на Apache JMeter се посочват в файла .
Забележка: шаблонът на конфигурацията за изграждане се използва за настройка на взаимодействието с CI системата и не предвижда разполагане на логиката на тестовете в него. За тестовете се посочва точката на вход, където се намира управляващият bash скрипт. Начинът на стартиране на тестовете, генерирането на отчети и самите тестови сценарии трябва да се реализират от QA инженери. В демо примера за двата източника на натоварване се използва като най-прост тест заявка към основната страница на Яндекс. Сценариите и параметрите на тестовете се намират в директорията .
- На етапа т debe бъде описан начините за публикуване на резултатите от тестовете, получени на етапа Тест, в външни схранилища, например в GitLab Pages или специализирани системи за отчитане. За GitLab Pages е нужно каталогът .\/public да бъде непразен и да съдържа поне файл index.html след завършване на тестовете. Можете да прочетете за нюансите на работата на услугата GitLab Pages .
Примери как да експортирате данни:
- от JMeter в ,
- от Yandex.Tank в .
Инструкции за настройка на публикуване:
- HTML статиката в ,
- в InfluxDB и след това в .
В демо примера, пайплайнът с натоварващи тестове и два източника на натоварване (може да деактивирате ненужния) изглежда така:
Apache JMeter може сам да генерира HTML отчет, затова е по-добре да се запазва в GitLab Pages с вградените средства. Ето как изглежда отчетът на Apache JMeter:
В демо примера за Yandex.Tank ще видите само в раздела за GitLab Pages. По време на тестовия процес Tank може да запазва резултатите в база данни InfluxDB, а оттам те могат да бъдат визуализирани, например, в Grafana (настройката се извършва в файла ). Ето как изглежда отчетът на Tank в Grafana:
Резюме
В статията обсъждам концепцията за „тестиране на натоварване като услуга“ (load testing as a service). Основната идея е да се използва инфраструктура от предварително настроени пулове с натоварващи агенти, Docker изображения на източници на натоварване, системи за отчети и обединяващия ги pipeline в GitLab CI, базиран на прост шаблон .gitlab-ci.yml (пример ). Всичко това се поддържа от малък екип инженери-автоматизатори и се тиражира по искане на продуктови екипи. Надявам се, че това ще ви помогне в подготовката и реализирането на подобна схема във вашата компания. Благодаря за вниманието!
P. S. Искам да благодаря на моите колеги, Сергей Курбанов и Николай Юсев, за техническата помощ при реализирането на концепцията load testing as a service в нашата компания.
Автор: — зам. ръководител на отдела за технологии и процеси на разработка (DevOps) в компанията Positive Technologies
Източник: habr.com
