Et af de problemer, som softwareleverandører med flere produkter ofte står over for, er duplikerede kompetencer blandt ingeniører – udviklere, testere og infrastrukturadministratorer – næsten i hvert team. Dette gælder også dyre ingeniører, der er specialister inden for belastningstest.
I stedet for at fokusere på deres direkte opgaver og bruge deres unikke erfaring til at opbygge belastningstestprocessen, vælge metoder, optimale metrikværdier og skrive automatiserede tests i overensstemmelse med belastningsprofiler, bliver ingeniører ofte nødt til fra bunden at opbygge testinfrastruktur, konfigurere belastningsværktøjer, integrere dem i CI-systemer, samt opsætte overvågning og publicering af rapporter.
Løsninger på nogle organisatoriske problemer inden for test, som vi anvender hos Positive Technologies, kan findes i . I denne artikel vil jeg beskrive muligheden for at integrere belastningstest i det samlede CI-pipeline ved hjælp af konceptet "belastningstest som en service" (load testing as a service). Du vil lære, hvilke containerbilleder til belastningskilder der kan bruges i CI-pipelinen; hvordan du tilslutter belastningskilder til dit CI-projekt ved hjælp af en bygge-skabelon; hvordan en demopipeline til kørsel af belastningstest og offentliggørelse af resultater ser ud. Artiklen kan være nyttig for softwaretestere og CI-automatiseringsingeniører, der overvejer arkitekturen for deres belastningssystem.
Essensen af konceptet
Konceptet load testing as a service indebærer muligheden for at integrere belastningsværktøjer som Apache JMeter, Yandex.Tank og egne rammeværk i et vilkårligt system for kontinuerlig integration. Eksemplet vil være til GitLab CI, men principperne er generelle for alle CI-systemer.
Load testing as a service er en centraliseret service til udførelse af belastningstest. Belastningstest startes i dedikerede agentpuljer, og resultaterne offentliggøres automatisk i GitLab Pages, Influx DB og Grafana eller i testrapporteringssystemer (TestRail, ReportPortal osv.). Automation og skalerbarhed realiseres så enkelt som muligt – ved at tilføje og parametrere en almindelig gitlab-ci.yml-skabelon i GitLab CI-projektet.
Fordelen ved tilgangen ligger i, at hele CI-infrastrukturen, belastningsagenter, Docker-billeder af belastningskilder, testpipeline og offentliggørelse af rapporter — understøttes af centrale automatiseringsafdelinger (DevOps-ingeniører), så belastningstestingeniører kan fokusere deres indsats på udvikling af tests og analyse af deres resultater uden at bekymre sig om infrastrukturen.
For enkelhedens skyld vil vi antage, at den applikation eller server, der skal testes, allerede er implementeret og konfigureret på forhånd (dette kan gøres ved hjælp af automatiserede scripts i Python, SaltStack, Ansible osv.). Derefter kan hele konceptet om belastningstest som en service opdeles i tre faser: forberedelse, test, offentliggørelse af rapporter. Se mere på diagrammet (alle billeder er klikbare):
Grundlæggende begreber og definitioner i belastningstestning
Når vi udfører belastningstest, forsøger vi at overholde , og bruger relevant terminologi og anbefalede målinger. Her er en kort liste over de vigtigste begreber og definitioner inden for belastningstestning.
Belastningsagent (load agent) — en virtuel maskine, hvor applikationen — belastningskilden (Apache JMeter, Yandex.Tank eller en skræddersyet belastningsmodul) vil køre.
Testmål (target) — serveren eller applikationen, der er installeret på serveren, som vil blive underkastet belastning.
Testcase (test case) — et sæt parametrede trin: brugerhandlinger og forventede reaktioner på disse handlinger, med dokumenterede netværksanmodninger og svar afhængigt af de angivne parametre.
Profil eller belastningsplan (profile) — i (punkt 4.2.4, side 43) belastningsprofiler definerer kritisk vigtige målinger for den specifikke test og variationer i ændring af belastningsparametre under testen. Eksempler på profiler kan ses i diagrammet.
Test (test) — et scenarie med et forud defineret sæt parametre.
Testplan (test-plan) — et sæt tests og en belastningsprofil.
Testkørsel (testrun) — én iteration af kørsel af en test med et fuldt udført belastningsscenarie og en genereret rapport.
Netværksanmodning (request) — en HTTP-anmodning sendt fra agenten til målet.
Netværkssvar (response) — HTTP-svar, der sendes fra målet til agenten.
HTTP-statuskode (HTTP responses status) — standardstatuskode fra applikationsserveren.
Transaktion (transaction) — den fulde cyklus "forespørgsel — svar". Transaktionen betragtes fra begyndelsen af forespørgslen (request) til afslutningen af modtagelsen af svaret (response).
Transaktionsstatus (transactions status) — om cyklussen "forespørgsel – svar" lykkedes. Hvis der opstod en fejl i denne cyklus, betragtes hele transaktionen som mislykket.
Svarevne (latency) — tiden fra afslutningen af sendingen af forespørgslen (request) til begyndelsen af modtagelsen af svaret (response).
Belastningsmetrikker (metrics) — karakteristika for den under belastning udsatte tjeneste og belastningsagenten, der defineres under belastningstestningen.
Primære metrikker til måling af belastningsparametre
Nogle af de mest almindeligt anvendte og anbefalede i metodologien (s. 36, 52) metrikker er angivet i tabellen nedenfor. Lignende metrikker for agenten og målet er angivet i én linje.
Metrikker for belastningsagenten
Metrikker for det målrettede system eller applikationen, der testes under belastning
Antal vCPU og hukommelse RAM,
Disk — de "hardware"-specifikationer for belastningsagenten
CPU, Memory, Disk usage — dynamikken af CPU-, hukommelses- og diskbelastning
under testningen. Normalt måles det i procent af
maksimalt tilgængelige værdier
Netværksgennemstrømning (on load agent) — båndbredden
af netværksgrænsefladen på serveren,
hvor belastningsagenten er installeret.
Normalt måles det i bytes per sekund (bps)
Netværksgennemstrømning(on target) — båndbredden for netværksgrænsefladen
på den målrettede server. Normalt måles det i bytes per sekund (bps)
Virtuelle brugere— antallet af virtuelle brugere,
der implementerer belastningsscenarier og
imiterer reale brugerhandlinger.
Status for virtuelle brugere, Bestået/Fejlet/Total — antallet af succesfulde og
mislykkedes status for virtuelle brugers arbejde
til belastningsscenarier samt deres samlede antal.
Det forventes normalt, at alle brugere har kunnet udføre
alle deres opgaver som angivet i belastningsprofilen.
Enhver fejl vil betyde, at den reelle bruger heller ikke kan
løse sin opgave, når de interagerer med systemet.
Anmodninger per sekund (mindst)— antallet af netværksanmodninger pr. sekund (eller pr. minut).
En vigtig egenskab ved belastningsagenten: hvor mange anmodninger den kan generere.
Faktisk er dette en simulation af anmodninger til applikationen fra virtuelle brugere
Svar pr. sekund (minut)
— antal netværks svar pr. sekund (eller minut).
En vigtig egenskab ved den målrettede tjeneste: hvor mange
svar på anmodninger der er lykkedes
fra belastningsagenten
HTTP svare status— antal forskellige svarkoder
fra applikationsserveren, modtaget af belastningsagenten.
For eksempel betyder 200 OK, at henvendelsen var succesfuld,
mens 404 — at ressourcen ikke blev fundet
Forsinkelse （respons tid） — tiden fra afslutning af
sending af anmodning (request) til begyndelsen af modtagelse af svaret (response).
Måles normalt i millisekunder (ms)
Transaktions responstid— tiden for én komplet transaktion,
afslutning af cyklussen "anmodning — svar".
Denne tid går fra begyndelsen af sendingen af anmodningen (request)
til afslutningen af modtagelsen af svaret (response).
Transaktionstid kan måles på flere måder:
beregner minimums-
maximum, gennemsnit og for eksempel 90. percentil.
Minimums- og maksimumsværdier er de ekstreme
tilstande for systemets ydeevne.
Den 90. percentil bruges oftest,
da den viser størstedelen af brugerne,
som komfortabelt arbejder ved ydeevnegrænsen for systemet
Transaktioner pr. sekund (minut) — antal komplette
transaktioner pr. sekund (minut),
det vil sige hvor mange anmodninger applikationen kunne modtage og
behandle og give svar.
Faktisk er dette systemets gennemløb.
Transaktionsstatus , Bestået / Fejlet / Total — antal
succesfulde, mislykkede og det samlede antal transaktioner.
For rigtige brugere vil en mislykket
transaktion faktisk betyde
en umulighed for at arbejde med systemet under belastning.
Den grundlæggende skitse for belastningstest
Den grundlæggende skitse for belastningstest er meget enkel og består af tre hovedfaser, som jeg allerede har nævnt: Forbered — Test — Rapport, det vil sige forberedelse af testmål og fastlæggelse af parametre for belastningskilder, derefter udførelse af belastningstest og til sidst formular og offentliggørelse af testrapporten.
Bemærkninger til skitsen:
- QA.Tester — ekspert i belastningstestning,
- Mål — målapplikationen, hvor man ønsker at finde ud af dens adfærd under belastning.
Klassificeringssystem for enheder, faser og trin i diagrammet
Faser og trin
Hvad sker der
Hvad der er på indgangen
Hvad der er på udgangen
Forberedelse: forberedelsesfasen til testning
LoadParameters
Opgave og initialisering
brugeren
af belastningsparametre,
valg af metrikker og
forberedelse af testplanen
(belastningsprofil)
Brugerdefinerede parametre til
initialisering af belastningsagenten
Testplan
Formålet med testningen
VM
Udrulning i skyen
af en virtuel maskine med
de krævede egenskaber
VM-parametre til belastningsagenten
Automatiseringsscripts til
oprettelse af VM
Konfigureret VM i
skyen
Miljø
Konfiguration af OS og forberedelse
af miljøet til
drift af belastningsagenten
Miljøparametre til
belastningsagenten
Automatiseringsscripts til
miljøindstillinger
Forberedt miljø:
OS, tjenester og applikationer,
nødvendige for drift
belastningsagenten
LoadAgents
Installation, konfiguration og parameterisering
af belastningsagenten.
Eller download af Docker-billedet med
forudkonfigureret belastningskilde
Docker-billede af belastningskilden
(JMeter, JM eller skræddersyet framework)
Konfigurationsparametre
belastningsagenten
Konfigureret og klar
til drift belastningsagent
Test: afviklingsfasen af belastningstest. Kilderne er belastningsagenter, der er udrullet i dedikerede puljer af agenter til GitLab CI
Belastning
Start af belastningsagenten
med den valgte testplan
og belastningsparametre
Brugerdefinerede parametre
til initialisering
belastningsagenten
Testplan
Formålet med testningen
Udførelseslogs
af belastningstest
Systemlogger
Dynamik i ændringen af målemetrikkerne og belastningsagenten
RunAgents
Udførelse af agenten
af belastnings testscenarier
ombygges i henhold til
belastningsprofil
Interaktion mellem belastningsagenten
og testformålet
Testplan
Formålet med testningen
Logs
Indsamling af "rå" logs
under belastningstestning:
optegnelser af belastningsagentens handlinger,
tilstand af testmålet
og VM, hvor agenten kører
Udførelseslogs
af belastningstest
Systemlogger
Metrikker
Indsamling af "rå" metrikker under testning
Dynamik i ændringen af målemetrikkerne
og belastningsagenten
Rapport: forberedelsesfasen til testningsrapporten
Generator
Behandling af indsamlede
af belastningssystemet og
overvågningssystemet af "rå"
metrikker og logs
Generering af rapporten i
læsevenligt format,
muligvis med elementer
af analyse
Udførelseslogs
af belastningstest
Systemlogger
Dynamik i ændringen af målemetrikkerne
af målet og belastningsagenten
Behandlede "rå" logs
i et format, der er egnet til
eksport til eksterne lagre
Statisk rapport om belastningen,
egnet til menneskelig analyse
Publish
Offentliggørelse af rapporten
om belastningstesten
i en ekstern
tjeneste
Behandlede "rå"
logs i et eksportvenligt format
til eksterne systemer
lager
Gemte rapporter om
belastningen i et eksternt
lager, der er brugbare
til menneskelig analyse
Forbindelse af belastningskilder i CI-skabelonen
Lad os gå videre til den praktiske del. Jeg vil vise, hvordan vi i nogle projekter hos har implementeret konceptet med belastningstest som en service.
Først oprettede vores DevOps-ingeniører en dedikeret pool af agenter til at køre belastningstest i GitLab CI. For at undgå forvirring med andre pooler, såsom byggepooler, tilføjede vi tags til disse agenter, : load. Du kan bruge enhver anden forståelig tag. De angives af GitLab CI Runners.
Hvordan finder man den nødvendige kraft på "maskinvara"? Karakteristika for belastningsagenterne - tilstrækkeligt antal vCPU, RAM og disk - kan beregnes ud fra, at Docker, Python (til Yandex.Tank), GitLab CI-agenten og Java (til Apache JMeter) skal være kørende på agenten. For Java under JMeter anbefales det også at bruge mindst 512 MB RAM og som øvre grænse, .
Derfor anbefaler vi baseret på vores erfaring at bruge mindst: 4 vCPU, 4 GB RAM, 60 GB SSD til belastningsagenterne. Bandbredde for netværkskortet bestemmes ud fra kravene til belastningsprofilen.
Vi bruger hovedsageligt to belastningskilder - Docker-billeder af Apache JMeter og Yandex.Tank.
er et open source-værktøj fra Yandex til belastningstest. Dets modulære arkitektur er baseret på en højtydende, asynkron hit-baseret generator af HTTP-anmodninger kaldet Phantom. Tanken har indbygget overvågning af ressourcerne på den testede server via SSH-protokollen, kan automatisk stoppe testen under bestemte betingelser, kan vise resultater både i konsollen og som grafer, og du kan tilføje dine egne moduler for at udvide funktionaliteten. Forresten brugte vi Tank, da det ikke endnu var mainstream. I artiklen "" kan man læse historien om, hvordan vi i 2013 udførte belastningstest ved hjælp af det - et af vores produkters produkter.
— et open source værktøj til belastningstest udviklet af Apache. Det kan anvendes til både statiske og dynamiske webapplikationer. JMeter understøtter et væld af protokoller og metoder til interaktion med applikationer: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET osv.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S) og IMAP(S), databaser via JDBC, kan udføre shell-kommandoer og arbejde med Java-objekter. JMeter har et IDE til oprettelse, fejlsøgning og udførelse af testplaner. Der er også en CLI til brug i kommandolinjen i ethvert Java-kompatibelt operativsystem (Linux, Windows, Mac OS X). Værktøjet kan dynamisk generere en HTML-rapport om testen.
For at lette brugen internt i vores virksomhed, og for at give testerne mulighed for selv at ændre og tilføje miljøer, har vi lavet Docker-images til belastningskilder på GitLab CI med publicering til vores interne . Det gør det hurtigere og enklere at integrere dem i pipelines til belastningstest. Hvordan man udfører docker push til registry via GitLab CI — se i .
Den grundlæggende Docker-fil til Yandex.Tank vi tog er denne:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Og til Apache JMeter er denne:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Hvordan vores system til kontinuerlig integration fungerer, kan du læse i artiklen «».
Skabelon og pipeline
Et eksempel på en skabelon til udførelse af belastningstest er tilgængeligt i projektet . I kan du læse vejledningen til brug af skabelonen. I selve skabelonen (fil ) er der bemærkninger om, hvad hvert trin i processen ansvarer for.
Skabelonen er meget simpel og demonstrerer de tre faser af belastningstest, som beskrevet ovenfor i diagrammet: forberedelse, test og publicering af rapporter. Dette styres af : Prepare, Test og Report.
- Trin bør bruges til forberedende opsætning af testmålene eller til at kontrollere deres tilgængelighed. Miljøet for belastningskilderne behøver ikke konfigureres, da de er forudbyggede som Docker-images og tilgængelige i docker registry: det er tilstrækkeligt at angive den ønskede version i testfasen. Men det er muligt at ombygge dem og lave sine egne tilpassede billeder.
- Trin bruges til at angive kilden til belastningen, starte tests og gemme testartefakter. Du kan vælge enhver kilde til belastningen: Yandex.Tank, Apache JMeter, din egen eller alle sammen. For at deaktivere unødvendige kilder er det tilstrækkeligt at kommentere eller slette jobbet. Indgangspunkter for belastningskilderne:
- startparametre for Yandex.Tank angives i filen.,
- startparametre for Apache JMeter angives i filen .
Bemærk: Skabelon til samlingskonfiguration bruges til at konfigurere interaktionen med CI-systemet og er ikke beregnet til at indeholde testlogik. For tests angives et indgangspunkt, hvor den kontrollerende bash-script befinder sig. Måden tests startes, rapporter genereres og selve testscripts skal implementeres af QA-ingeneørerne. I demoeksemplet for begge belastningskilder anvendes en simpel test, der kalder hovedsiden af Yandex. Scenarier og testparametre ligger i kataloget .
- På trin skal du beskrive måderne at offentliggøre testresultater, der opnås i trinnet Test, til eksterne lagringssteder, f.eks. GitLab Pages eller specialrapporteringssystemer. For GitLab Pages kræves det, at kataloget .\/public skal være ikke-tom og indeholde mindst filen index.html. Du kan læse om nuancerne ved at arbejde med GitLab Pages .
Eksempler på, hvordan man eksporterer data:
- fra JMeter til ,
- fra Yandex.Tank til .
Instruktioner til opsætning af offentliggørelse:
- HTML-statisk i ,
- i InfluxDB og derefter i .
I demoeksemplet ser pipelinen med belastningstest og to kilder til belastning (kan deaktivere den unødvendige) sådan ud:
Apache JMeter kan selv generere en HTML-rapport, så det er fordelagtigt at gemme den i GitLab Pages med de indbyggede værktøjer. Sådan ser Apache JMeter's rapport ud:
I demoeksemplet for Yandex.Tank vil du kun se i sektionen for GitLab Pages. Under testning kan Tank gemme resultaterne i InfluxDB, som derefter kan vises f.eks. i Grafana (opsætningen udføres i filen ). Sådan ser Tankens rapport ud i Grafana:
CV
I artiklen har jeg beskrevet konceptet "load testing as a service". Hovedideen ligger i at bruge infrastrukturen af forudkonfigurerede puljer af belastningsagenter, Docker-billeder af belastningskilder, rapporteringssystemer og en pipeline, der samler dem i GitLab CI baseret på en simpel skabelon .gitlab-ci.yml (eksempel ). Alt dette understøttes af en lille gruppe af ingeniører inden for automatisering og implementeres efter anmodning fra produktteams. Jeg håber, dette vil hjælpe dig med at forberede og implementere en lignende ordning i din virksomhed. Tak for opmærksomheden!
P. S. Jeg vil gerne sige stort tak til mine kolleger, Sergey Kurbanov og Nikolay Yusev, for den tekniske hjælp til implementeringen af konceptet load testing as a service i vores virksomhed.
Forfatter: — stedfortræder for lederen af teknologier og udviklingsprocesser (DevOps) i Positive Technologies
Kilde: habr.com
