Ett av de vanligaste problemen för flerproduktföretag som utvecklar programvara är duplicering av kompetenser bland ingenjörerna - utvecklare, testare och infrastrukturadministratörer - nästan i varje team. Detta gäller även kostsamma ingenjörer - specialister inom belastningstestning.
Istället för att fokusera på sina grundläggande uppgifter och använda sin unika erfarenhet för att bygga upp processen för belastningstestning, välja metodik, optimala värden för metrik och skriva automatiska tester i enlighet med belastningsprofiler, tvingas ingenjörerna ofta bygga upp testinfrastrukturen från grunden, konfigurera belastningstestverktygen, själva integrera dem i CI-system, samt ställa in övervakning och publicering av rapporter.
Lösningar på vissa organisatoriska problem inom testning, som vi tillämpar hos Positive Technologies, kan du hitta i . I denna artikel kommer jag att berätta om möjligheten att integrera belastningstester i den övergripande CI-pipelinen med hjälp av konceptet "belastningstestning som en tjänst". Du kommer att lära dig hur och vilka Docker-avbildningar av belastningskällor som kan användas i CI-pipelinen; hur man ansluter belastningskällor i ditt CI-projekt med hjälp av en byggmall; hur en demopipeline ser ut för att köra belastningstester och publicera resultat. Artikeln kan vara nyttig för programvarutestare och automatiseringsingenjörer i CI som funderar över arkitekturen för sina belastningssystem.
Kärnan i konceptet
Konceptet belastningstestning som en tjänst innebär möjligheten att integrera belastningsverktyg som Apache JMeter, Yandex.Tank och egna ramverk i valfritt system för kontinuerlig integration. Exemplet kommer att vara för GitLab CI, men principerna som presenteras gäller för alla CI-system.
Belastningstestning som en tjänst är en centraliserad tjänst för att utföra belastningstestning. Belastningstester körs i dedikerade pooler av agenter, och publicering av resultat sker automatiskt i GitLab Pages, Influx DB och Grafana, eller i testrapportssystem (TestRail, ReportPortal och liknande). Automatisering och skalning realiseras på ett så enkelt sätt som möjligt - genom att lägga till och parameterisera en vanlig mall gitlab-ci.yml i GitLab CI-projektet.
Fördelen med detta tillvägagångssätt är att hela CI-infrastrukturen, belastningsagenter, Docker-bilder av belastningskällor, testpipelines och publicering av rapporter — stöds av ett centralt automatiseringskontor (DevOps-ingenjörer), vilket gör att belastningstestingenjörer kan fokusera sina insatser på att utveckla tester och analysera resultaten utan att behöva ta itu med infrastrukturella frågor.
För enkelhetens skull kommer vi att anta att det målapplicering eller server redan är utplacerad och konfigurerad i förväg (automatiserade skript på Python, SaltStack, Ansible m.fl. kan användas för detta). Då kan hela konceptet med belastningstestning som en tjänst sammanfattas i tre steg: förberedelse, testning, publicering av rapporter. Mer information finns i diagrammet (alla bilder är klickbara):
Grundläggande begrepp och definitioner inom belastningstestning
Vid belastningstester försöker vi följa , använda lämplig terminologi och rekommenderade mätvärden. Här är en kort lista över grundläggande begrepp och definitioner inom belastningstestning.
Belastningsagent (load agent) — en virtuell maskin där applikationen – belastningskällan – (Apache JMeter, Yandex.Tank eller en egen skriven belastningsmodul) kommer att köras.
Testmålet (target) — servern eller applikationen installerad på servern som kommer att utsättas för belastning.
Testfall (test case) — en uppsättning parametiserade steg: användaråtgärder och förväntade reaktioner på dessa åtgärder, med registrerade nätverksanrop och svar, beroende på angivna parametrar.
Profil eller belastningsplan (profile) — i (p. 4.2.4, s. 43) belastningsprofiler definierar kritiska mätvärden och alternativ för att ändra belastningsparametrarna under testet. Exempel på profiler kan ses i bilden.
Test (test) — ett scenario med en förutbestämd uppsättning parametrar.
Testplan (test-plan) — en uppsättning tester och belastningsprofil.
Testkörning (testrun) — en iteration av körningen av ett test med ett helt genomfört belastningsscenario och en erhållen rapport.
Nätverksanrop (request) — en HTTP-förfrågan som skickas från agenten till målet.
Nätverksrespons (response) — HTTP-svaret som skickas från målet till agenten.
HTTP-statuskod (HTTP responses status) — en standardstatuskod som ges av applikationsservern.
Transaktion (transaction) — en fullständig cykel av "förfrågan — svar". En transaktion anses ske från början av förfrågan (request) tills svaret (response) tas emot.
Transaktionsstatus (transactions status) — huruvida cykeln "förfrågan – svar" lyckades eller inte. Om det fanns något fel under denna cykel anses hela transaktionen misslyckad.
Svarstid (latency) — tiden från slutet av förfrågan (request) till början av svaret (response).
Belastningsmetrik (metrics) — egenskaper hos den belastade tjänsten och belastningsagenten som definieras under belastningstestning.
Grundläggande metriker för att mäta belastningsparametrar
Några av de mest vanligt förekommande och rekommenderade metrics i metoden (s. 36, 52) anges i tabellen nedan. Liknande metrics för agenten och målet anges i samma rad.
Metriker för belastningsagenten
Metriker för det målsystem eller den applikation som testas under belastning
Antalet vCPU och minne RAM,
Disk — de "hårda" egenskaperna hos belastningsagenten
CPU, Memory, Disk usage — dynamiken i CPU-, minnes- och diskbelastningen
under testningen. Vanligtvis mätt i procent av
de maximalt tillgängliga värdena
Nätverksgenomströmning (on load agent) — nätverksgränssnittets kapacitet
på servern där belastningsagenten är installerad.
Vanligtvis mätt i byte per sekund (bps)
(on target) — nätverksgränssnittets kapacitet
Nätverksgenomströmningpå måservern. Vanligtvis mätt i byte per sekund (bps)
Virtuella användare
— antal virtuella användare som utför belastningsscenarier ochimiterar faktiska användares handlingar
Virtuella användarstatus
, Passed/Failed/Total — antalet framgångsrika och
misslyckade statusar för de virtuella användarnaför belastningsscenarier samt deras totala antal.
Det förväntas vanligtvis att alla användare har kunnat utföra
alla sina uppgifter som anges i belastningsprofilen.
Eventuella fel kommer att innebära att även en verklig användare inte kan
lösa sitt problem när den arbetar med systemet.
Begärningar per sekund (minut)
— antalet nätverksförfrågningar per sekund (eller minut).
En viktig egenskap hos belastningsagenten: hur många förfrågningar den kan generera.Viktig egenskap hos belastningsagenten: hur många förfrågningar den kan generera.
En viktig egenskap hos belastningsagenten: hur många förfrågningar den kan generera.
Det här är i praktiken en simulering av hur virtuella användare interagerar med applikationen
Svar per sekund (minut)
— antalet nätverks-svar per sekund (eller minut).
En viktig egenskap hos den avsedda tjänsten: hur många
svar har lyckats generera och skicka på begärningar från
belastningsagenten
HTTP-svarstatus— antalet olika svarskoder
från applikationsservern som mottagits av belastningsagenten.
Till exempel, 200 OK betyder ett framgångsrikt anrop,
medan 404 betyder att resursen inte hittades
Fördröjning (svarstid) — tiden från att begäran (request) har skickats
till dess att svaret (response) börjar tas emot.
Vanligtvis mäts det i millisekunder (ms)
Transaktionssvarstid— tiden för en fullständig transaktion,
avslutningen av cykeln "begäran — svar".
Detta är tiden från att begäran (request) skickas
tills svaret (response) tas emot.
Transaktionstiden kan mätas på flera sätt: man kan räkna
minimi,
maximi, genomsnitt och till exempel 90:e percentilen.
Minimi- och maximivärdena är de yttersta
prestandatillstånden i systemet.
Den nittioende percentilen används oftast,
eftersom den visar hur de flesta användare
har en bekväm upplevelse nära systemets prestationsgräns
Transaktioner per sekund (minut) — antalet fullständiga
transaktioner per sekund (minut),
det vill säga hur många begärningar applikationen kunnat ta emot och
bearbeta och ge svar på.
Detta är i praktiken systemets kapacitet
Transaktionsstatus , Godkända / Misslyckade / Totalt — antalet
lyckade, misslyckade och det totala antalet transaktioner.
För verkliga användare innebär en misslyckad
transaktion i praktiken
att det är omöjligt att arbeta med systemet under belastning.
Den grundläggande schemat för belastningstestning
Den grundläggande schemat för belastningstestning är mycket enkel och består av tre huvudsteg, som jag redan har nämnt: Förbered - Testa - Rapportera, dvs. förbereda testmålen och ange parametrar för belastningskällorna, sedan utföra belastningstester och till slut, skapa och publicera en testrapport.
Anmärkningar till schemat:
- QA.Tester — expert på belastningstestning,
- Mål — den applikation som ska analyseras under belastning.
Klassificerare av enheter, steg och steg i schemat
Steg och steg
Vad händer
Что на входе
Что на выходе
Prepare: этап подготовки к тестированию
LoadParameters
Задание и инициализация
användaren
параметров нагрузки,
выбор метрик и
подготовка тест-плана
(профиля нагрузки)
Пользовательские параметры для
инициализации агента нагрузки
Тест-план
Цель тестирования
VM
Развертывание в облаке
виртуальной машины с
требуемыми характеристиками
Параметры ВМ для агента нагрузки
Скрипты автоматизации для
создания ВМ
Настроенная ВМ в
molnet
Env
Настройка ОС и подготовка
окружения для
работы нагрузочного агента
Параметры окружения для
агента нагрузки
Скрипты автоматизации для
настройки окружения
Подготовленное окружение:
ОС, сервисы и приложения,
необходимые для работы
агента нагрузки
LoadAgents
Установка, настройка и параметризация
нагрузочного агента.
Или скачивание докер-образа с
преднастроенным источником нагрузки
Докер-образ источника нагрузки
(ЯТ, JM или самописный фреймворк)
Параметры настройки
агента нагрузки
Настроенный и готовый
к работе агент нагрузки
Test: этап выполнения нагрузочных тестов. Источниками являются агенты нагрузки, развернутые в выделенных пулах агентов для GitLab CI
Ladda
Запуск агента нагрузки
с выбранным тест-планом
и параметрами нагрузки
Пользовательские параметры
для инициализации
агента нагрузки
Тест-план
Цель тестирования
Логи выполнения
нагрузочных тестов
Системные журналы
Динамика изменения метрик цели и нагрузочного агента
RunAgents
Исполнение агентом
нагрузки тестовых сценариев
i enlighet med
профилем нагрузки
Взаимодействие агента нагрузки
с целью тестирования
Тест-план
Цель тестирования
Loggar
Сбор «сырых» логов
в процессе нагрузочного тестирования:
записи о действиях агента нагрузки,
состоянии цели тестирования
и ВМ, на которой запущен агент
Логи выполнения
нагрузочных тестов
Системные журналы
Metrik
Сбор «сырых» метрик в процессе тестирования
Динамика изменения метрик цели
и нагрузочного агента
Report: этап подготовки отчета о тестировании
Generator
Обработка собранных
нагрузочной системой и
системой мониторинга «сырых»
метрик и логов
Формирование отчета в
человекочитаемом виде,
возможно с элементами
аналитики
Логи выполнения
нагрузочных тестов
Системные журналы
Динамика изменения метрик
цели и нагрузочного агента
Обработанные «сырые» логи
в формате, пригодном для
выгрузки во внешние хранилища
Статический отчет о нагрузке,
пригодный для анализа человеком
Publish
Публикация отчета
о нагрузочном
тестировании во внешнем
сервисе
Обработанные «сырые»
loggar i ett användbart format
för export till externa
lagring
Sparade i extern
lagring rapporter om
belastning, användbara
för mänsklig analys
Anslutning av belastningskällor i CI-mallen
Låt oss gå till den praktiska delen. Jag vill visa hur vi på vissa projekt inom företaget har implementerat konceptet belastningstestning som en tjänst.
Först skapade våra DevOps-ingenjörer i GitLab CI en dedikerad pool av agenter för att köra belastningstester. För att inte blanda dem med andra pooler, som byggpooler, lade vi till taggar på dessa agenter, : load. Du kan använda andra förståeliga taggar. De anges GitLab CI Runners.
Hur vet man vilken hårdvarukraft som krävs? Specifikationerna för belastningsagenterna – tillräckligt antal vCPU, RAM och Disk – kan beräknas utifrån att Docker, Python (för Yandex.Tank), GitLab CI-agenten och Java (för Apache JMeter) måste köras på agenten. För Java under JMeter rekommenderar man också att använda minst 512 MB RAM och, som övre gräns, .
Därför, utifrån vår erfarenhet, rekommenderar vi att använda minst: 4 vCPU, 4 GB RAM, 60 GB SSD för belastningsagenter. Bandbredden för nätverkskortet bestäms baserat på kraven för belastningsprofilen.
Vi använder huvudsakligen två belastningskällor – Docker-bilder av Apache JMeter och Yandex.Tank.
är ett öppen källkodsverktyg från Yandex för belastningstestning. I grunden för dess modulära arkitektur ligger en högpresterande asynkron hit-baserad HTTP-förfrågan generator, Phantom. Tank har inbyggd resursövervakning av den testade servern via SSH-protokollet, kan automatiskt stoppa testet vid givna villkor, kan visa resultat både i konsolen och i grafisk form, och man kan ansluta sina egna moduler för att utöka funktionaliteten. För övrigt använde vi Tank när det fortfarande var en nischlösning. I artikeln "" kan man läsa historien om hur vi 2013 genomförde belastningstestning med hjälp av den – en av våra produkters.
— är ett öppet verktyg för belastningstestning utvecklat av Apache. Det kan användas lika bra för att testa både statiska och dynamiska webbapplikationer. JMeter stöder ett stort antal protokoll och sätt att interagera med applikationer: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET etc.), SOAP / REST-webbtjänster, FTP, TCP, LDAP, SMTP(S), POP3(S) och IMAP(S), databaser via JDBC, kan exekvera shell-kommandon och arbeta med Java-objekt. JMeter har en IDE för att skapa, debugga och köra testplaner. Dessutom finns en CLI för att arbeta i kommandoraden på valfri Java-kompatibel OS (Linux, Windows, Mac OS X). Verktyget kan dynamiskt generera en HTML-rapport om testningen.
För att underlätta användningen inom vårt företag, för att möjliggöra för testarna att själva ändra och lägga till omgivningen har vi gjort Docker-avbildningar av belastningskällor i GitLab CI med publicering till vårt interna . Det blir snabbare och enklare att ansluta dem i pipelines för belastningstester. Hur man gör en docker push till registry via GitLab CI — se i .
Den grundläggande Docker-filen för Yandex.Tank tog vi denna:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Och för Apache JMeter denna:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Hur vårt system för kontinuerlig integration är uppbyggt kan du läsa i artikeln "».
Mall och pipeline
Ett exempel på en mall för att genomföra belastningstester finns tillgänglig i projektet . I kan du läsa instruktionerna för att använda mallen. I själva mallen (fil ) finns kommentarer om vad varje steg ansvarar för.
Mallen är mycket enkel och demonstrerar tre steg i belastningstestningen som beskrivs ovan i schemat: förberedelse, testning och publicering av rapporter. Det ansvarar för : Prepare, Test och Report.
- Steg ska användas för förberedande inställning av testmål eller för att kontrollera deras tillgänglighet. Omgivningen för belastningskällor behöver inte konfigureras, de är redan byggda som Docker-avbildningar och publicerade i docker registry: det räcker att ange den önskade versionen i steget Test. Men de kan återbyggas och skapa egna modifierade bilder.
- Steg används för att ange lastkällan, köra tester och spara testartefakter. Du kan välja vilken lastkälla som helst: Yandex.Tank, Apache JMeter, din egen eller alla tillsammans. För att stänga av oönskade källor räcker det att kommentera eller ta bort jobb. Ingångspunkterna för lastkällor:
- startparameters för Yandex.Tank anges i filen.,
- startparameters för Apache JMeter anges i filen .
Observera: mallen för byggkonfiguration används för att ställa in interaktionen med CI-systemet och förutsätter inte att testlogik ingår. För tester anges en ingångspunkt där den styrande bash-skriptet finns. Hur testen körs, rapporter genereras och själva testspecifikationerna måste implementeras av QA-ingenjörerna. I demonstrationsprovet används en grundläggande förfrågan av Yandex:s startsida som det enklaste testet för båda lastkällorna. Scenarier och testparametrar ligger i katalogen .
- I fasen måste sätten att publicera testresultaten, som erhållits i Test-fasen, till externa lagringsutrymmen beskrivas, till exempel i GitLab Pages eller specialiserade rapporteringssystem. För GitLab Pages krävs att katalogen . /public efter testerna är icke-tom och innehåller minst filen index.html. Om nyanserna i GitLab Pages tjänsten kan du läsa .
Exempel på hur man exporterar data:
- från JMeter till ,
- från Yandex.Tank till .
Instruktioner för konfiguration av publicering:
- HTML-statiska i ,
- till InfluxDB och sedan till .
I demonstrationsprovet ser pipeline med lasttester och två lastkällor (som kan stängas av om så önskas) ut så här:
Apache JMeter kan själv generera HTML-rapporter, därför är det fördelaktigt att spara dem i GitLab Pages med de inbyggda verktygen. Så här ser en Apache JMeter-rapport ut:
I demonstrationsprovet för Yandex.Tank kommer du endast att se i avsnittet för GitLab Pages. Under testerna kan Tank spara resultat i InfluxDB, och därifrån kan de visas, till exempel i Grafana (konfigurationen utförs i filen ). Så här ser rapporten från Tank ut i Grafana:
Sammanfattning
I artikeln diskuterar jag konceptet "load testing as a service". Huvididén är att använda infrastrukturen av förkonfigurerade pooler av lastagent, Docker-avbilder för lastgenerering, rapporteringssystem och en sammanvävande pipeline i GitLab CI baserat på en enkel mall .gitlab-ci.yml (exempel ). Allt detta stödjs av en liten grupp automationsingenjörer och sprids på begäran av produktteam. Jag hoppas att detta kan hjälpa er att förbereda och genomföra ett liknande system i ert företag. Tack för er uppmärksamhet!
P. S. Jag vill ge ett stort tack till mina kollegor, Sergey Kurbanov och Nikolay Yusev, för tekniskt stöd vid implementeringen av konceptet load testing as a service i vårt företag.
Författare: — vice chef för avdelningen för teknik och utvecklingsprocesser (DevOps) på Positive Technologies
Källa: habr.com
