Една от проблемите, с които често се сблъскват многопродуктови доставчици на софтуер, е дублирането на компетенциите на инженерите – разработчици, тестировчици и администратори на инфраструктура – почти във всяка екип. Това важи и за скъпоструващите инженери – специалисти в областта на натоварващото тестване.
Вместо да се занимават с основните си задължения и да използват уникалния си опит за изграждане на процеса на натоварващо тестване, да избират методология, оптимални стойности на метрики и да пишат автотестове в съответствие с профилите на натоварване, инженерите често трябва да разгръщат тестовата инфраструктура от нулата, да настройват инструменти за натиск, сами да ги интегрират в 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) — сървър или приложение, инсталирано на сървъра, което ще бъде подложено на натоварване.
Тest сценарий (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,
Disk — «хардуерни» характеристики на натоварващия агент
CPU, Памет, използване на диск — динамиката на натоварването на процесора, паметта и диска
в процеса на тестване. Обикновено се измерва в проценти от
максимално налични стойности
Мрежов капацитет (на натоварващия агент) — капацитет на мрежовия интерфейс на сървъра,
където е инсталиран натоварващия агент.
Обикновено се измерва в байтове в секунда (bps)
(на целта) — капацитет на мрежовия интерфейс
Мрежов капацитетна целевия сървър. Обикновено се измерва в байтове в секунда (bps)
Виртуални потребители
— брой виртуални потребители,осъществяващи сценарии на натоварване и
имитиращи реални действия на потребителите
Статус на виртуалните потребители
, Успех/Неуспех/Общо — брой успешни инеуспешни статуси на работа на виртуалните потребители
за сценарии на натоварване, а също и тяхното общо количество.
Обикновено се очаква, че всички потребители ще могат да изпълнят
всички свои задачи, посочени в профила на натоварването.
Всяка грешка ще означава, че и реален потребител не може
да реши своята задача при работа със системата
Запитвания в секунда (минута)
— брой мрежови запитвания в секунда (или минута).Важно свойство на натоварващия агент: колко запитвания може да генерира.
Метрика, която описва количеството натоварване.
Това е имитация на взаимодействие с приложението от виртуални потребители.
Отговори в секунда (минута)
— брой мрежови отговори на секунда (или минута).
Важно свойство на целевата услуга: колко
успя да генерира и изпрати отговори на запитвания с
натоварващия агент.
HTTP статуси на отговори— брой различни кодове на отговори
от приложния сървър, получени от натоварващия агент.
Например, 200 OK означава успешно взаимодействие,
а 404 — че ресурсът не е намерен.
Забавяне (време за реакция) — времето от края
на изпращане на заявката (request) до началото на приемане на отговора (response).
Обикновено се измерва в милисекунди (ms).
Време за отговор на транзакцията— времето на една пълна транзакция,
завършване на цикъл "запитване — отговор".
Это время от начала на изпращане на заявката (request)
до завършване на приемане на отговора (response).
Времето на транзакцията може да се измерва в секунди (или минути)
по няколко начина: считат минималното,
максималното, средното и, например, 90-ия перцентил.
Минималните и максималните показания са крайни
състояния на производителността на системата.
Деветдесетият перцентил се използва най-често,
тъй като показва преобладаващото количество потребители,
работещи комфортно на границата на производителността на системата.
Транзакции на секунда (минута) — брой пълни
транзакции в секунда (минута),
т.е. колко приложение успя да приеме и
обработи запитвания и да предостави отговори.
Това на практика е пропускателната способност на системата.
Статус на транзакции , Успешни / Неуспешни / Общи — брой
успешни, неуспешни и общо количество транзакции.
За реални потребители неуспешна
транзакция всъщност ще означава
невъзможност за работа с системата под натоварване.
Основна схема на натоварващо тестване
Основната схема на натоварващо тестване е много проста и се състои от три основни етапа, за които вече споменах: Подготовка — Тестване — Доклад, т.е. подготовка на цели за тестване и задаване на параметри за източниците на натоварване, след това извършване на натоварващи тестове и, накрая, съставяне и публикуване на доклад за тестването.
Забележки към схемата:
- QA. Тестер — експерт по натоварващо тестване,
- Цел — целево приложение, за което трябва да се проучи поведението му под натоварване.
Класификатор на същности, етапи и стъпки в схемата.
Етапи и стъпки
Какво се случва
Какво има на входа
Какво има на изхода
Подготовка: етап на подготовка за тестване
LoadParameters
Задаване и инициализация
потребителя
параметри на натоварване,
избор на метрики и
подготовка на тестов план
(профил на натоварването)
Потребителски параметри за
инициализация на агента за натоварване
Тестов план
Цел на тестването
VM
Разгръщане в облака
виртуална машина с
необходими характеристики
Параметри на ВМ за агента за натоварване
Автоматизационни скриптове за
създаване на ВМ
Настроена ВМ в
облака
Env
Настройка на ОС и подготовка
на околната среда за
работа на агента за натоварване
Параметри на околната среда за
агента за натоварване
Автоматизационни скриптове за
настройки на околната среда
Подготвена околна среда:
ОС, услуги и приложения,
необходими за работа
агента за натоварване
LoadAgents
Инсталация, настройка и параметризиране
на агента за натоварване.
Или изтегляне на докер изображение с
преднастроен източник на натоварване
Докер изображение на източника на натоварване
(ЯТ, JM или самостоятелно написан фреймворк)
Параметри на настройката
агента за натоварване
Настроен и готов
за работа агент за натоварване
Test: етап на изпълнение на натоварващи тестове. Източниците са агенти за натоварване, разположени в специализирани пулове на агенти за GitLab CI
Натоварване
Стартиране на агента за натоварване
с избран тестов план
и параметри на натоварването
Потребителски параметри
за инициализация
агента за натоварване
Тестов план
Цел на тестването
Логове на изпълнението
на натоварващите тестове
Системни журнали
Динамика на промените в метриките на целите и агента за натоварване
RunAgents
Изпълнение от агента
за натоварване на тестови сценарии
в съответствие с
профил на натоварването
Взаимодействие на агента за натоварване
с целта за тестване
Тестов план
Цел на тестването
Логове
Събиране на „сурови“ логове
в процеса на натоварваща проверка:
записи за действията на агента за натоварване,
състояние на целта за тестване
и ВМ, на която е стартиран агентът
Логове на изпълнението
на натоварващите тестове
Системни журнали
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 MB RAM и, като горна граница, .
Така че, въз основа на нашия опит, препоръчваме за натоварените агенти да се използват поне: 4 vCPU, 4 GB RAM, 60 GB 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-a. Точки за вход за източниците на натоварване:
- параметрите за стартиране на Yandex.Tank се указват във файла.,
- параметрите за стартиране на Apache JMeter се указват във файла .
Забележка: шаблонът на конфигурацията за изграждане се използва за настройка на взаимодействието с CI системата и не предвижда логика на тестовете. За тестовете се указва точка на вход, където се намира управляващият bash скрипт. Начинът на стартиране на тестовете, генерирането на отчети и самите тестови сценарии трябва да бъдат реализирани от QA инженерите. В демонстрационния пример, за двата източника на натоварване, като най-прост тест се използва заявка към основната страница на Яндекс. Сценарии и параметри на тестовете се намират в каталога .
- На етапа трябва да се опишат начините за публикуване на резултатите от тестовете, получени на етапа Test, във външни хранилища, например в 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 образи на източници на натоварване, системи за отчет и свързващият ги пайплайн в GitLab CI, базиран на прост шаблон .gitlab-ci.yml (пример ). Всичко това се поддържа от малък екип инженери-автоматизатори и се копира по заявка на продуктови екипи. Надявам се, че това ще ви помогне в подготовката и реализацията на аналогична схема във вашата компания. Благодаря за вниманието!
P. S. Искам да благодаря на моите колеги, Сергей Курбанов и Николай Юсев, за техническата помощ с реализирането на концепцията load testing as a service в нашата компания.
Автор: — зам. ръководител на отдела за технологии и процеси на разработка (DevOps) на компания Positive Technologies
Източник: habr.com
