Један од проблема са којима се добављачи софтвера за више производа често суочавају је дуплирање компетенција инжењера - програмера, тестера и администратора инфраструктуре - у скоро сваком тиму. Ово важи и за скупе инжењере - специјалисте у области испитивања оптерећења.
Уместо да обављају своје директне дужности и користе своје јединствено искуство за изградњу процеса тестирања оптерећења, бирају методологију, оптималне метрике и пишу аутотестове у складу са профилима оптерећења, инжењери често морају да имплементирају инфраструктуру за тестирање од нуле, конфигуришу алате за оптерећење и уграде их себе у ЦИ системима, успоставили праћење и објављивање извештаја.
Решења за неке организационе проблеме можете пронаћи у тестирању које користимо у Поситиве Тецхнологиес у . А у овом ћу говорити о могућности интеграције тестова оптерећења у заједнички ЦИ цевовод користећи концепт „тестирања оптерећења као услуге“ (тестирање оптерећења као услуге). Научићете како и које доцкер слике извора оптерећења могу да се користе у ЦИ цевоводу; како да повежете изворе оптерећења са вашим ЦИ пројектом користећи шаблон за прављење; како изгледа демо цевовод за покретање тестова оптерећења и објављивање резултата. Чланак може бити користан за инжењере за тестирање софтвера и инжењере аутоматизације у ЦИ који размишљају о архитектури свог система оптерећења.
Суштина концепта
Концепт тестирања оптерећења као услуге подразумева могућност интеграције алата за оптерећење Апацхе ЈМетер, Иандек.Танк и сопствених оквира у произвољан систем континуиране интеграције. Демо ће бити за ГитЛаб ЦИ, али принципи су заједнички за све ЦИ системе.
Тестирање оптерећења као услуга је централизована услуга за тестирање оптерећења. Тестови оптерећења се покрећу у наменским групама агената, резултати се аутоматски објављују у ГитЛаб Пагес, Инфлук ДБ и Графана или у системима за извештавање о тестовима (ТестРаил, РепортПортал, итд.). Аутоматизација и скалирање се имплементирају што једноставније – додавањем и параметрирањем уобичајеног гитлаб-ци.имл шаблона у ГитЛаб ЦИ пројекту.
Предност овог приступа је у томе што целокупну ЦИ инфраструктуру, агенте за оптерећење, доцкер слике извора оптерећења, цевоводе за тестирање и извештаје за објављивање одржава централизовано одељење за аутоматизацију (ДевОпс инжењери), док инжењери за тестирање оптерећења могу да усмере своје напоре на развој теста и анализу њихових резултата, не бавећи се питањима инфраструктуре.
Ради једноставности описа, претпоставићемо да је циљна апликација или сервер који се тестира већ постављен и конфигурисан унапред (за ово се могу користити аутоматске скрипте у Питхон, СалтСтацк, Ансибле итд.). Тада се цео концепт тестирања оптерећења као услуге уклапа у три фазе: припрема, тестирање, објављивање извештаја. Више детаља на дијаграму (све слике се могу кликнути):
Основни концепти и дефиниције у тестирању оптерећења
Када вршимо тестове оптерећења, трудимо се да се придржавамо , користите одговарајућу терминологију и препоручене метрике. Даћу кратку листу главних концепата и дефиниција у тестирању оптерећења.
Учитај агента - виртуелна машина на којој ће се апликација покренути - извор учитавања (Апацхе ЈМетер, Иандек.Танк или самописани модул за учитавање).
Циљ теста (циљ) - сервер или апликација инсталирана на серверу који ће бити подложан учитавању.
Тест сценарио (тестни случај) - скуп параметризованих корака: радње корисника и очекиване реакције на ове акције, са фиксним мрежним захтевима и одговорима, у зависности од наведених параметара.
Профил или план учитавања (профил) - у (Одељак 4.2.4, стр. 43) профили оптерећења дефинишу метрике које су критичне за одређени тест и опције за промену параметара оптерећења током теста. Примере профила можете видети на слици.
Тест — скрипта са унапред одређеним скупом параметара.
Тест план (тест-план) - скуп тестова и профил оптерећења.
Тестран (теструн) - једна итерација покретања једног теста са потпуно извршеним сценаријем оптерећења и примљеним извештајем.
Мрежни захтев (захтев) — ХТТП захтев послан од агента до циља.
Мрежни одговор (одговор) — ХТТП одговор послат од циља до агента.
ХТТП код одговора (статус ХТТП одговора) - стандардни код одговора са сервера апликација.
Трансакција је комплетан циклус захтев-одговор. Трансакција се рачуна од почетка слања захтева (захтева) до завршетка пријема одговора (одговора).
Статус трансакције - да ли је било могуће успешно завршити циклус захтев-одговор. Ако је било грешке у овом циклусу, онда се цела трансакција сматра неуспешном.
Време одговора (латенција) - време од завршетка слања захтева (захтева) до почетка пријема одговора (одговора).
Учитај метрику — карактеристике оптерећене услуге и агента оптерећења утврђених у процесу испитивања оптерећења.
Основне метрике за мерење параметара оптерећења
Неки од најчешће коришћених и препоручених у методологији (стр. 36, 52) метрике су приказане у табели испод. Слични показатељи за агента и циља су наведени у истом реду.
Метрике за агента оптерећења
Метрике циљног система или апликације која се тестира под оптерећењем
број вЦПУ и памћење РАМ-,
Диск - "гвоздене" карактеристике средства за оптерећење
Процесор, Меморија, употреба диска - динамика оптерећења процесора, меморије и диска
у процесу тестирања. Обично се мери као проценат од
максималне расположиве вредности
пропусност мреже (он лоад агент) - пропусност
мрежни интерфејс на серверу,
где је инсталиран агент за учитавање.
Обично се мери у бајтовима у секунди (бпс)
пропусност мреже(на циљу) - пропусни опсег мрежног интерфејса
на циљном серверу. Обично се мери у бајтовима у секунди (бпс)
Виртуелни корисници- број виртуелних корисника,
спровођење сценарија оптерећења и
имитирајући стварне радње корисника
Статус виртуелних корисника, Пассед/Фаилед/Тотал — број успешних и
неуспешни статуси виртуелних корисника
за сценарије оптерећења, као и њихов укупан број.
Уопштено се очекује да су сви корисници могли да заврше
сви ваши задаци наведени у профилу учитавања.
Свака грешка значи да прави корисник неће моћи
решите свој проблем када радите са системом
Захтеви у секунди (минута)- број мрежних захтева у секунди (или минути).
Важна карактеристика агента за учитавање је колико захтева може да генерише.
У ствари, ово је имитација приступа апликацији виртуелних корисника
Одговори у секунди (минути)
- број мрежних одговора у секунди (или минути).
Важна карактеристика циљне службе: колико
генерише и шаље одговоре на упите са
агент за утовар
Статус ХТТП одговора— број различитих кодова одговора
са сервера апликација које је примио агент за учитавање.
На пример, 200 ОК значи успешан позив,
и 404 – да извор није пронађен
Латентност (време одговора) - време од краја
слање захтева (захтева) пре почетка добијања одговора (одговора).
Обично се мери у милисекундама (мс)
Време одговора на трансакцију— време једне комплетне трансакције,
завршетак циклуса захтев-одговор.
Ово је време од почетка слања захтева (захтева)
до завршетка пријема одговора (одговора).
Време трансакције се може мерити у секундама (или минутима)
на неколико начина: размотрите минимум,
максимум, просек и, на пример, 90. перцентил.
Минимална и максимална очитавања су екстремна
статус перформанси система.
Деведесети перцентил је најчешће коришћен,
као што показује већина корисника,
удобно функционисање на прагу перформанси система
Трансакције у секунди (минута) - број комплетних
трансакције у секунди (минута),
односно колико је апликација била у стању да прихвати и
обрађују захтеве и одговоре на питања.
У ствари, ово је пропусност система
Статус трансакције , Положено / Неуспешно / Укупно - број
успешно, неуспешно и укупан број трансакција.
За праве кориснике неуспешно
трансакција ће заправо значити
немогућност рада са системом под оптерећењем
Шематски дијаграм тестирања оптерећења
Концепт тестирања оптерећења је веома једноставан и састоји се од три главне фазе, које сам већ поменуо: Припреми-Тест-Извештај, односно припрема циљева тестирања и постављање параметара за изворе оптерећења, затим извођење тестова оптерећења и, на крају, генерисање и објављивање извештаја о тестирању.
Шематске напомене:
- КА.Тестер је стручњак за тестирање оптерећења,
- Циљ је циљна апликација за коју желите да сазнате њено понашање под оптерећењем.
Класификатор ентитета, фаза и корака у дијаграму
Фазе и кораци
Шта се дешава
Шта је на улазу
Шта је излаз
Припремите се: фаза припреме за тестирање
ЛоадПараметерс
Подешавање и иницијализација
корисника
параметри оптерећења,
избор метрике и
припрема плана тестирања
(учитај профил)
Прилагођене опције за
иницијализација агента учитавања
План тестирања
Сврха тестирања
VM
Примена у облаку
виртуелна машина са
потребне карактеристике
ВМ подешавања за агента за учитавање
Скрипте за аутоматизацију за
Креирање ВМ
ВМ конфигурисан у
облак
Енв
Подешавање и припрема ОС-а
окружење за
рад агента оптерећења
Подешавања окружења за
агент за оптерећење
Скрипте за аутоматизацију за
подешавања окружења
Припремљено окружење:
ОС, услуге и апликације,
неопходна за рад
агент за оптерећење
ЛоадАгентс
Инсталација, конфигурација и параметрирање
агент за утовар.
Или преузимање доцкер слике са
унапред конфигурисани извор оптерећења
Учитај изворну доцкер слику
(ИАТ, ЈМ или самостално писани оквир)
Подешавања
агент за оптерећење
Постављено и спремно
да агент за радно оптерећење
Тест: фаза извођења тестова оптерећења. Извори су агенти за учитавање распоређени у наменске групе агената за ГитЛаб ЦИ
Оптерећење
Покретање агента за учитавање
са изабраним планом тестирања
и параметрима оптерећења
Корисничке опције
за иницијализацију
агент за оптерећење
План тестирања
Сврха тестирања
Дневници извршења
тестови оптерећења
Системски дневники
Динамика промена метрике циљева и агента оптерећења
Покрени агенте
Агент Екецутион
гомилу тестних скрипти
в складу с
профил оптерећења
Интеракција учитавања агента
у сврху испитивања
План тестирања
Сврха тестирања
Дрва
Збирка "сирових" трупаца
током тестирања оптерећења:
учитавање записа активности агента,
стање испитне мете
и ВМ који покреће агента
Дневници извршења
тестови оптерећења
Системски дневники
Метрицс
Прикупљање „сирових“ метрика током тестирања
Динамика промена метрике циљева
и агент за пуњење
Извештај: фаза припреме извештаја о испитивању
Генератор
Обрада прикупљена
систем утовара и
систем за праћење "сиров"
метрике и евиденције
Формирање извештаја у
човеку читљив облик
могуће са елементима
аналитичари
Дневници извршења
тестови оптерећења
Системски дневники
Динамика промена метрике
циљ и агент за оптерећење
Обрађени "сирови" трупци
у формату погодном за
отпремања на спољну меморију
Извештај о статичком оптерећењу,
човеку читљив
Објавити
Објављивање извештаја
о оптерећењу
тестирање у екстерном
услуга
Обрађено "сирово"
евиденције у одговарајућем формату
за истовар на спољну
репозиторијуми
Сачувано у екстерном
извештаји о складиштењу на
оптерећење, погодно
за анализу људи
Повезивање извора оптерећења у ЦИ шаблону
Пређимо на практични део. Желим да покажем како на неким пројектима у компанији имплементирали смо концепт тестирања оптерећења као услуге.
Прво, уз помоћ наших ДевОпс инжењера, направили смо наменски скуп агената у ГитЛаб ЦИ за покретање тестова оптерећења. Да их не бисмо помешали у шаблонима са другима, као што су скупови склопова, додали смо ознаке овим агентима, : оптерећење. Можете користити било које друге разумљиве ознаке. Они питају ГитЛаб ЦИ Руннерс.
Како сазнати потребну снагу помоћу хардвера? Карактеристике агената за учитавање – довољан број вЦПУ-а, РАМ-а и диска – могу се израчунати на основу чињенице да на агенту треба да раде Доцкер, Питхон (за Иандек.Танк), ГитЛаб ЦИ агент, Јава (за Апацхе ЈМетер). . За Јаву под ЈМетер-ом, такође се препоручује да користите најмање 512 МБ РАМ-а и, као горњу границу, .
Стога, на основу нашег искуства, препоручујемо коришћење најмање 4 вЦПУ-а, 4 ГБ РАМ-а, 60 ГБ ССД-а за агенте за учитавање. Пропусност мрежне картице се одређује на основу захтева профила оптерећења.
Углавном користимо два извора учитавања - Апацхе ЈМетер и Иандек.Танк доцкер слике.
је Иандеков алат отвореног кода за тестирање оптерећења. Његова модуларна архитектура је заснована на Пхантомовом асинхроном генератору ХТТП захтева високих перформанси заснованом на хитовима. Резервоар има уграђено праћење ресурса сервера који се тестира преко ССХ протокола, може аутоматски зауставити тест под одређеним условима, може приказати резултате како у конзоли тако и у облику графикона, можете повезати своје модуле да прошири функционалност. Иначе, користили смо Танк када још није био мејнстрим. У чланку "» можете прочитати причу о томе како смо са њим извршили тестирање оптерећења 2013. године је један од производа наше компаније.
је алатка за тестирање оптерећења отвореног кода из Апацхе-а. Може се подједнако добро користити за тестирање и статичких и динамичких веб апликација. ЈМетер подржава огроман број протокола и начина за интеракцију са апликацијама: ХТТП, ХТТПС (Јава, НодеЈС, ПХП, АСП.НЕТ, итд.), СОАП / РЕСТ Веб услуге, ФТП, ТЦП, ЛДАП, СМТП(С), ПОП3( С) ) и ИМАП(С), базе података преко ЈДБЦ-а, могу да извршавају команде љуске и раде са Јава објектима. ЈМетер има ИДЕ за креирање, отклањање грешака и извршавање планова тестирања. Такође постоји ЦЛИ за рад на командној линији на било ком оперативном систему компатибилном са Јавом (Линук, Виндовс, Мац ОС Кс). Алат може динамички да генерише ХТМЛ извештај о тестирању.
Ради лакшег коришћења унутар наше компаније, ради могућности самих тестера да мењају и додају окружење, направили смо буилд доцкер слике извора учитавања на ГитЛаб ЦИ са објављивањем у интерном . Ово чини бржим и лакшим њихово повезивање у цевоводе за тестове оптерећења. Како да урадите доцкер пусх до регистра преко ГитЛаб ЦИ - погледајте .
Узели смо ову основну доцкер датотеку за Иандек.Танк:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]А за Апацхе ЈМетер ово:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Како функционише наш систем континуиране интеграције можете прочитати у чланку "'.
Шаблон и цевовод
Пример шаблона за спровођење тестова оптерећења доступан је у пројекту . У Можете прочитати упутства за коришћење шаблона. У самом шаблону (датотека ) постоје белешке о томе за шта је одговоран сваки корак.
Шаблон је веома једноставан и показује три фазе тестирања оптерећења описане у дијаграму изнад: припрема, тестирање и објављивање извештаја. Одговоран за ово : Припремите, тестирајте и пријавите.
- Сцена треба да се користи за унапред конфигурисање тестних циљева или проверу њихове доступности. Окружење за изворе учитавања не треба да се конфигурише, они су унапред направљени као доцкер слике и постављени у доцкер регистар: само наведите жељену верзију у фази тестирања. Али можете их поново изградити и направити своје модификоване слике.
- Сцена користи се за одређивање извора учитавања, покретање тестова и складиштење артефаката теста. Можете да изаберете било који извор учитавања: Иандек.Танк, Апацхе ЈМетер, сопствени или све заједно. Да бисте онемогућили непотребне изворе, само коментаришите или избришите посао. Улазне тачке за изворе оптерећења:
- Параметри покретања за Иандек.Танк су наведени у .,
- Параметри покретања Апацхе ЈМетер-а су наведени у датотеци .
Напомена: Шаблон конфигурације склопа се користи за подешавање интеракције са ЦИ системом и не подразумева постављање тестне логике у њега. За тестове је наведена улазна тачка, где се налази контролна басх скрипта. Метод извођења тестова, генерисање извештаја и саме тест скрипте морају да имплементирају КА инжењери. У демонстрацији, за оба извора учитавања, захтев главне странице Иандек-а се користи као најједноставнији тест. Скрипте и параметри теста су у директоријуму .
- На позорници потребно је да опишете како да објавите резултате теста добијене у фази тестирања на спољним складиштима, на пример, на ГитЛаб страницама или посебним системима за извештавање. ГитЛаб Пагес захтева да директоријум ./публиц не буде празан и да садржи најмање индек.хтмл датотеку након завршетка тестова. Можете прочитати о нијансама услуге ГитЛаб Пагес. .
Примери како да извезете податке:
- од ЈМетера до ,
- од Иандек.Танк до .
Објављивање упутства за подешавање:
- ХТМЛ статика у ,
- на ИнфлукДБ, а затим на .
У демо примеру, цевовод са тестовима оптерећења и два извора оптерећења (можете да онемогућите непотребан) изгледа овако:
Апацхе ЈМетер може сам да генерише ХТМЛ извештај, тако да је исплативије да га сачувате у ГитЛаб Пагес користећи стандардне алате. Овако изгледа извештај Апацхе ЈМетер:
У демо примеру за Иандек.Танк, видећете само у одељку за ГитЛаб странице. Током тестирања, Танк може да сачува резултате у бази података ИнфлукДБ, а одатле се могу приказати, на пример, у Графани (конфигурација се врши у датотеци ). Овако изгледа Танков извештај у Графани:
Резиме
У чланку сам говорио о концепту „тестирања оптерећења као услуге“ (тестирање оптерећења као услуге). Основна идеја је да се користи инфраструктура унапред конфигурисаних скупова агената учитавања, доцкер слика извора учитавања, система за извештавање и цевовода који их комбинује у ГитЛаб ЦИ на основу једноставног .гитлаб-ци.имл шаблона (пример ). Све ово подржава мали тим инжењера за аутоматизацију и реплицира на захтев производних тимова. Надам се да ће вам ово помоћи у припреми и имплементацији сличне шеме у вашој компанији. Хвала на пажњи!
ПС Желим да кажем велико хвала мојим колегама, Сергеју Курбанову и Николају Јусеву, на техничкој помоћи око имплементације концепта тестирања оптерећења као услуге у нашој компанији.
Аутор: - Заменик Шеф технологије и развојних процеса (ДевОпс) у компанији Поситиве Тецхнологиес
Извор: ввв.хабр.цом