Един от проблемите, с които често се сблъскват доставчиците на мултипродуктов софтуер, е дублирането на компетенциите на инженерите – разработчици, тестери и инфраструктурни администратори – в почти всеки екип. Това важи и за скъпите инженери - специалисти в областта на натоварването.
Вместо да изпълняват преките си задължения и да използват уникалния си опит, за да изградят процес на тестване на натоварване, да изберат методология, оптимални показатели и да напишат автоматични тестове в съответствие с профилите на натоварване, инженерите често трябва да внедряват тестова инфраструктура от нулата, да конфигурират инструменти за натоварване и да ги вграждат себе си в CI системи, настройват мониторинг и публикуване на отчети.
Можете да намерите решения на някои организационни проблеми в тестването, което използваме в Positive Technologies в . И в този ще говоря за възможността за интегриране на тестове за натоварване в общ CI тръбопровод, използвайки концепцията за „тестване на натоварване като услуга“ (тестване на натоварване като услуга). Ще научите как и кои докер изображения на източници на зареждане могат да се използват в конвейера на CI; как да свържете източници на зареждане към вашия CI проект с помощта на шаблон за изграждане; как изглежда демонстрационният тръбопровод за провеждане на тестове за натоварване и публикуване на резултатите. Статията може да бъде полезна за инженери по тестване на софтуер и инженери по автоматизация в CI, които мислят за архитектурата на своята система за зареждане.
Същността на концепцията
Концепцията за тестване на натоварване като услуга предполага възможност за интегриране на инструменти за зареждане Apache JMeter, Yandex.Tank и вашите собствени рамки в произволна система за непрекъсната интеграция. Демото ще бъде за GitLab CI, но принципите са общи за всички CI системи.
Load testing като услуга е централизирана услуга за тестване на натоварване. Тестовете за натоварване се изпълняват в специални пулове на агенти, резултатите се публикуват автоматично в GitLab Pages, Influx DB и Grafana или в системи за докладване на тестове (TestRail, ReportPortal и др.). Автоматизацията и мащабирането се изпълняват възможно най-просто - чрез добавяне и параметризиране на обичайния шаблон gitlab-ci.yml в проекта GitLab CI.
Предимството на този подход е, че цялата CI инфраструктура, агенти за зареждане, докер изображения на източници на зареждане, конвейери за тестване и публикуване на отчети се поддържат от централизиран отдел за автоматизация (инженери на DevOps), докато инженерите за тестване на натоварване могат да съсредоточат усилията си върху разработването на тестове и анализ на резултатите от тях, без да се занимават с инфраструктурни въпроси.
За простота на описанието ще приемем, че целевото приложение или сървър, които се тестват, вече са внедрени и конфигурирани предварително (за това могат да се използват автоматизирани скриптове в Python, SaltStack, Ansible и др.). Тогава цялата концепция за тестване на натоварването като услуга се вписва в три етапа: подготовка, изпитване, публикуване на доклади. Повече подробности на диаграмата (всички снимки могат да се кликват):
Основни понятия и определения в натоварващото тестване
Когато провеждаме тестове за натоварване, ние се опитваме да се придържаме към , използвайте подходящата терминология и препоръчани показатели. Ще дам кратък списък на основните понятия и дефиниции в тестването на натоварване.
Агент за зареждане - виртуална машина, на която ще се стартира приложението - източник на зареждане (Apache JMeter, Yandex.Tank или самостоятелно написан модул за зареждане).
Тестова цел (цел) - сървър или приложение, инсталирано на сървъра, което ще бъде обект на натоварване.
Тестов сценарий (тестов случай) - набор от параметризирани стъпки: потребителски действия и очаквани реакции към тези действия, с фиксирани мрежови заявки и отговори, в зависимост от зададените параметри.
Профил или план за натоварване (профил) - в (Раздел 4.2.4, стр. 43) профилите на натоварване дефинират показатели, които са критични за конкретен тест и опции за промяна на параметрите на натоварване по време на теста. Можете да видите примери за профили на фигурата.
Тест — скрипт с предварително определен набор от параметри.
План за тестване (план за тестване) - набор от тестове и профил на натоварване.
Тестран (теструн) - една итерация на изпълнение на един тест с напълно изпълнен сценарий на натоварване и получения отчет.
Мрежова заявка (заявка) — HTTP заявка, изпратена от агент до цел.
Мрежов отговор (отговор) — HTTP отговор, изпратен от целта към агента.
Код на HTTP отговор (статус на HTTP отговори) - стандартен код на отговор от сървъра на приложения.
Транзакцията е пълен цикъл заявка-отговор. Транзакцията се брои от началото на изпращане на заявка (заявка) до завършване на получаване на отговор (отговор).
Статус на транзакцията - дали е възможно да се завърши успешно цикълът заявка-отговор. Ако е имало някаква грешка в този цикъл, тогава цялата транзакция се счита за неуспешна.
Време за реакция (латентност) - времето от края на изпращане на заявка (заявка) до началото на получаване на отговор (отговор).
Заредете показатели — характеристиките на натоварената услуга и агента на натоварване, определени в процеса на изпитване на натоварване.
Основни метрики за измерване на параметрите на натоварването
Някои от най-често използваните и препоръчвани в методиката (стр. 36, 52) показателите са показани в таблицата по-долу. Подобни показатели за агент и цел са изброени на един и същи ред.
Метрики за агента за зареждане
Метрики на целевата система или приложение, които се тестват под натоварване
Брой vCPU и памет RAM,
Disk - "железни" характеристики на товара агент
процесор, Памет, използване на диска - динамика на натоварването на процесора, паметта и диска
в процес на тестване. Обикновено се измерва като процент от
максимални налични стойности
пропускателна способност на мрежата (on load agent) - пропускателна способност
мрежов интерфейс на сървъра,
където е инсталиран агентът за зареждане.
Обикновено се измерва в байтове в секунда (bps)
пропускателна способност на мрежата(on target) - честотна лента на мрежовия интерфейс
на целевия сървър. Обикновено се измерва в байтове в секунда (bps)
Виртуални потребители- броя на виртуалните потребители,
прилагане на сценарии за натоварване и
имитиране на реални потребителски действия
Състояние на виртуални потребители, Успешно/Неуспешно/Общо — брой успешни и
неуспешни статуси на виртуални потребители
за сценарии на натоварване, както и общият им брой.
Обикновено се очаква, че всички потребители са успели да завършат
всички ваши задачи, посочени в профила на натоварване.
Всяка грешка ще означава, че истинският потребител няма да може
разрешите проблема си при работа със системата
Заявки в секунда (минута)- броя на мрежовите заявки за секунда (или минута).
Важна характеристика на агента за зареждане е колко заявки може да генерира.
Всъщност това е имитация на достъп до приложението от виртуални потребители
Отговори в секунда (минута)
- броя на отговорите на мрежата за секунда (или минута).
Важна характеристика на целевата услуга: колко
генерирайте и изпращайте отговори на запитвания с
агент за зареждане
Статус на HTTP отговор— брой различни кодове за отговор
от сървъра на приложения, получен от агента за зареждане.
Например 200 OK означава успешно повикване,
и 404 - че ресурсът не е намерен
латентност (време за реакция) - време от края
изпращане на заявка (заявка) преди да започнете да получавате отговор (отговор).
Обикновено се измерва в милисекунди (ms)
Време за отговор на транзакцията— време на една пълна транзакция,
завършване на цикъла заявка-отговор.
Това е времето от началото на изпращане на заявката (заявката)
до приключване на получаване на отговор (отговор).
Времето за транзакция може да бъде измерено в секунди (или минути)
по няколко начина: разгледайте минимума,
максимум, среден и, например, 90-ия персентил.
Минималните и максималните показания са екстремни
състояние на производителност на системата.
Деветдесетият процентил е най-често използваният,
както показва повечето потребители,
удобно работещи на прага на производителността на системата
Транзакции в секунда (минута) - броят на пълните
транзакции в секунда (минута),
тоест колко е било в състояние да приеме приложението и
обработка на заявки и издаване на отговори.
Всъщност това е пропускателната способност на системата
Състояние на транзакцията , Успешно / Неуспешно / Общо - бр
успешни, неуспешни и общия брой транзакции.
За реални потребители неуспешно
транзакцията всъщност ще означава
невъзможност за работа със системата под натоварване
Схематична диаграма на тестване на натоварване
Концепцията за тестване на натоварване е много проста и се състои от три основни етапа, които вече споменах: Подгответе-тест-доклад, тоест подготовка на тестови цели и задаване на параметри за източници на натоварване, след това изпълнение на товарни тестове и накрая генериране и публикуване на тестов доклад.
Схематични бележки:
- QA.Tester е експерт в тестването на натоварване,
- Target е целевото приложение, за което искате да знаете поведението му при натоварване.
Класификатор на обекти, етапи и стъпки в диаграмата
Етапи и стъпки
Какво се случва
Какво има на входа
Какъв е изходът
Подгответе: етап на подготовка за тестване
Параметри на натоварване
Настройка и инициализация
потребител
параметри на натоварване,
избор на показатели и
подготовка на тест план
(зареди профил)
Персонализирани опции за
инициализация на зареждащ агент
План за тестване
Цел на тестването
VM
Внедряване в облак
виртуална машина с
изисквани характеристики
Настройки на VM за агент за зареждане
Скриптове за автоматизация за
Създаване на VM
VM, конфигуриран в
Облакът
пощенски плик
Настройка и подготовка на ОС
среда за
работа на агент за натоварване
Настройки на средата за
товар агент
Скриптове за автоматизация за
настройки на средата
Подготвена среда:
ОС, услуги и приложения,
необходими за работа
товар агент
LoadAgents
Инсталация, конфигурация и параметризация
агент за зареждане.
Или изтегляне на докер изображение от
предварително конфигуриран източник на натоварване
Заредете изображението на докер източника
(YAT, JM или самостоятелно написана рамка)
Настройки
товар агент
Настроен и готов
агент за натоварване на работа
Тест: етап на изпълнение на товарни тестове. Източниците са агенти за зареждане, внедрени в специални пулове агенти за GitLab CI
Натоварване
Стартиране на агента за зареждане
с избран тестов план
и параметри на натоварване
Потребителски опции
за инициализация
товар агент
План за тестване
Цел на тестването
Дневници за изпълнение
тестове за натоварване
Системни регистрационни файлове
Динамика на промените в показателите на целта и агента на натоварване
Стартирайте агенти
Изпълнение на агент
много тестови скриптове
според
профил на натоварване
Взаимодействие с агент за зареждане
с цел тестване
План за тестване
Цел на тестването
Дневник
Събиране на "сурови" трупи
по време на тестване на натоварване:
записи на дейността на агента за зареждане,
състояние на тестовата цел
и виртуалната машина, изпълняваща агента
Дневници за изпълнение
тестове за натоварване
Системни регистрационни файлове
Метрика
Събиране на "сурови" показатели по време на тестване
Динамика на промените в целевите показатели
и агент за натоварване
Доклад: етап на подготовка на протокола от изпитването
Генератор
Обработката е събрана
система за зареждане и
система за мониторинг "сурова"
метрики и регистрационни файлове
Оформяне на отчет в
четима от човека форма
възможно с елементи
анализатори
Дневници за изпълнение
тестове за натоварване
Системни регистрационни файлове
Динамика на промените в показателите
целеви и зареждащ агент
Обработени "сурови" трупи
в подходящ формат за
качвания във външна памет
Доклад за статично натоварване,
четими за хора
Публикувам
Публикуване на доклада
относно натоварването
тестване във външно
обслужване
Обработен "суров"
регистрационни файлове в подходящ формат
за разтоварване към външен
сводове
Запазено във външно
отчети за съхранение на
товар, подходящ
за човешки анализ
Свързване на източници на натоварване в CI шаблон
Да преминем към практическата част. Искам да покажа как по някои проекти в компанията внедрихме концепцията за тестване на натоварването като услуга.
Първо, с помощта на нашите инженери на DevOps създадохме специален набор от агенти в GitLab CI за провеждане на тестове за натоварване. За да не ги бъркаме в шаблони с други, като пулове за сглобяване, ние добавихме тагове към тези агенти, : натоварване. Можете да използвате всякакви други разбираеми тагове. Те питат 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 за агенти за зареждане. Пропускателната способност на мрежовата карта се определя въз основа на изискванията на профила на натоварване.
Използваме основно два източника на зареждане - Apache JMeter и Yandex.Tank докер изображения.
е инструмент с отворен код от Yandex за тестване на натоварване. Модулната му архитектура е базирана на високопроизводителния асинхронен генератор на HTTP заявки, базиран на попадения. Резервоарът има вградено наблюдение на ресурсите на тествания сървър чрез SSH протокола, може автоматично да спре теста при определени условия, може да показва резултатите както в конзолата, така и под формата на графики, можете да свържете вашите модули към него за разширяване на функционалността. Между другото, използвахме танка, когато все още не беше масов. В статията "» можете да прочетете историята за това как извършихме тестване на натоварване с него през 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 тестов отчет.
За лесна употреба в рамките на нашата компания, за способността на самите тестери да променят и добавят средата, ние направихме компилации на докер изображения на източници на зареждане на GitLab CI с публикуване във вътрешния . Това прави по-бързо и по-лесно свързването им в тръбопроводи за тестове на натоварване. Как да направите docker push към регистъра чрез GitLab CI - вижте .
Взехме този основен докер файл за Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]И за Apache JMeter този:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Можете да прочетете как работи нашата система за непрекъсната интеграция в статията "".
Шаблон и конвейер
Примерен шаблон за провеждане на тестове за натоварване е наличен в проекта . В Можете да прочетете инструкциите за използване на шаблона. В самия шаблон (файл ) има бележки за какво отговаря всяка стъпка.
Шаблонът е много прост и демонстрира трите етапа на тестване на натоварването, описани в диаграмата по-горе: подготовка, тестване и публикуване на отчети. Отговорен за това : Подгответе, тествайте и докладвайте.
- етап трябва да се използва за предварително конфигуриране на тестови цели или проверка на тяхната наличност. Средата за източници на зареждане не е необходимо да се конфигурира, те са предварително изградени като докер изображения и публикувани в регистъра на докерите: просто посочете желаната версия на етапа на тестване. Но можете да ги възстановите и да направите свои собствени модифицирани изображения.
- етап използва се за указване на източника на зареждане, изпълнение на тестове и съхраняване на тестови артефакти. Можете да изберете всеки източник на зареждане: Yandex.Tank, Apache JMeter, ваш собствен или всички заедно. За да деактивирате ненужните източници, просто коментирайте или изтрийте заданието. Входни точки за източници на натоварване:
- Параметрите за стартиране на Yandex.Tank са посочени в .,
- Параметрите за стартиране на Apache JMeter са посочени във файла .
Забележка: Шаблонът за конфигурация на асемблиране се използва за настройка на взаимодействие с CI системата и не предполага поставяне на тестова логика в него. За тестове е посочена входната точка, където се намира контролният bash скрипт. Методът за провеждане на тестове, генериране на отчети и самите тестови скриптове трябва да бъдат внедрени от QA инженери. В демонстрацията и за двата източника на зареждане заявката за главната страница на Yandex се използва като най-прост тест. Скриптовете и тестовите параметри са в директорията .
- На сцената трябва да опишете как да публикувате резултатите от теста, получени на етапа на теста, във външни хранилища, например в страници на GitLab или специални системи за отчитане. 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 (конфигурацията се извършва във файла ). Ето как изглежда репортажът на Танк в Графана:
Обобщение
В статията говорих за концепцията за „тестване на натоварване като услуга“ (тестване на натоварване като услуга). Основната идея е да се използва инфраструктурата от предварително конфигурирани пулове от агенти за зареждане, докер изображения на източници за зареждане, системи за отчитане и конвейер, който ги комбинира в GitLab CI въз основа на прост шаблон .gitlab-ci.yml (пример ). Всичко това се поддържа от малък екип от инженери по автоматизация и се копира по искане на продуктови екипи. Надявам се, че това ще ви помогне при подготовката и прилагането на подобна схема във вашата компания. Благодаря ви за вниманието!
PS Искам да изкажа голяма благодарност на моите колеги, Сергей Курбанов и Николай Юсев, за техническата помощ при внедряването на концепцията за тестване на натоварване като услуга в нашата компания.
Автор: - Депутат Ръководител на отдела за технологии и процеси за развитие (DevOps) в Positive Technologies
Източник: www.habr.com