Et af de problemer, som leverandører af multi-produktsoftware ofte står over for, er overlapningen af kompetencerne hos ingeniører - udviklere, testere og infrastrukturadministratorer - på næsten alle teams. Det gælder også for dyre ingeniører - specialister inden for belastningsprøvning.
I stedet for at udføre deres direkte opgaver og bruge deres unikke erfaring til at opbygge en belastningstestproces, vælge en metode, optimale målinger og skrive autotest i overensstemmelse med belastningsprofiler, skal ingeniører ofte implementere testinfrastruktur fra bunden, konfigurere belastningsværktøjer og integrere dem sig i CI-systemer, opsætte overvågning og offentliggørelse af rapporter.
Du kan finde løsninger på nogle organisatoriske problemer i test, som vi bruger hos Positive Technologies i . Og i denne vil jeg tale om muligheden for at integrere belastningstests i en fælles CI-pipeline ved hjælp af konceptet "load testing as a service" (load testing as a service). Du vil lære, hvordan og hvilke docker-billeder af belastningskilder, der kan bruges i CI-pipelinen; hvordan man forbinder belastningskilder til dit CI-projekt ved hjælp af en byggeskabelon; hvordan demo-pipelinen ser ud til at køre belastningstest og offentliggøre resultaterne. Artiklen kan være nyttig for softwaretestingeniører og automationsingeniører i CI, der tænker på arkitekturen af deres belastningssystem.
Essensen af konceptet
Konceptet med belastningstest som en service indebærer muligheden for at integrere belastningsværktøjer Apache JMeter, Yandex.Tank og dine egne rammer i et vilkårligt kontinuerligt integrationssystem. Demoen vil være til GitLab CI, men principperne er fælles for alle CI-systemer.
Load test as a service er en centraliseret service til load test. Belastningstest køres i dedikerede agentpuljer, resultaterne publiceres automatisk i GitLab Pages, Influx DB og Grafana eller i testrapporteringssystemer (TestRail, ReportPortal, etc.). Automatisering og skalering implementeres så enkelt som muligt - ved at tilføje og parametrere den sædvanlige gitlab-ci.yml skabelon i GitLab CI-projektet.
Fordelen ved denne tilgang er, at hele CI-infrastrukturen, lastagenter, docker-billeder af lastkilder, testpipelines og publiceringsrapporter vedligeholdes af en centraliseret automationsafdeling (DevOps-ingeniører), mens lasttestingeniører kan fokusere deres indsats på testudvikling og analyse af deres resultater uden at beskæftige sig med infrastrukturproblemer.
For nemheds skyld antager vi, at målapplikationen eller serveren, der testes, allerede er installeret og konfigureret på forhånd (automatiserede scripts i Python, SaltStack, Ansible osv. kan bruges til dette). Så passer hele konceptet med belastningstest som en service ind i tre faser: udarbejdelse, test, offentliggørelse af rapporter. Flere detaljer på diagrammet (alle billeder er klikbare):
Grundlæggende begreber og definitioner i belastningstest
Ved udførelse af belastningstest forsøger vi at overholde , brug den passende terminologi og anbefalede metrics. Jeg vil give en kort liste over de vigtigste begreber og definitioner i belastningstest.
Load agent - en virtuel maskine, hvorpå applikationen vil blive lanceret - belastningskilden (Apache JMeter, Yandex.Tank eller et selvskrevet belastningsmodul).
Testmål (mål) - server eller applikation installeret på serveren, der vil blive indlæst.
Testscenarie (testcase) - et sæt parametriserede trin: brugerhandlinger og forventede reaktioner på disse handlinger, med faste netværksanmodninger og -svar, afhængigt af de specificerede parametre.
Profil eller belastningsplan (profil) - ind (Afsnit 4.2.4, s. 43) belastningsprofiler definerer metrikker, der er kritiske for en bestemt test og muligheder for at ændre belastningsparametre under testen. Du kan se eksempler på profiler på figuren.
Prøve — et script med et forudbestemt sæt parametre.
Testplan (testplan) - et sæt test og en belastningsprofil.
Testran (testrun) - en iteration af at køre en test med et fuldt udført belastningsscenarie og den modtagne rapport.
Netværksanmodning (anmodning) — En HTTP-anmodning sendt fra en agent til et mål.
Netværkssvar (svar) — Et HTTP-svar sendt fra målet til agenten.
HTTP-svarkode (HTTP-svarstatus) - standardsvarkode fra applikationsserveren.
En transaktion er en komplet anmodning-svar-cyklus. En transaktion tælles fra starten af afsendelse af en anmodning (anmodning) til afslutningen af modtagelse af et svar (svar).
Transaktionsstatus - om det var muligt at gennemføre anmodning-svar-cyklussen. Hvis der var nogen fejl i denne cyklus, betragtes hele transaktionen som mislykket.
Svartid (latency) - tiden fra slutningen af afsendelse af en anmodning (anmodning) til begyndelsen af modtagelse af et svar (svar).
Indlæs metrics — egenskaberne for den lastede tjeneste og det lastmiddel, der er bestemt under lastprøvningen.
Grundlæggende metrik til måling af belastningsparametre
Nogle af de mest brugte og anbefalede i metoden (s. 36, 52) metrikken er vist i tabellen nedenfor. Lignende metrics for agent og mål er angivet på samme linje.
Metrikker for belastningsagenten
Metrikker for målsystemet eller applikationen, der testes under belastning
Nummer vCPU og hukommelse RAM,
Disk - "jern"-karakteristika for lastmidlet
CPU, Hukommelse, Diskbrug - dynamik af CPU, hukommelse og diskbelastning
i gang med at teste. Normalt målt i procent af
maksimale tilgængelige værdier
Netværksgennemstrømning (på load agent) - gennemløb
netværksgrænseflade på serveren,
hvor load agenten er installeret.
Normalt målt i bytes per sekund (bps)
Netværksgennemstrømning(på målet) - netværksgrænsefladebåndbredde
på målserveren. Normalt målt i bytes per sekund (bps)
Virtuelle brugere- antallet af virtuelle brugere,
implementering af belastningsscenarier og
efterligning af rigtige brugerhandlinger
Status for virtuelle brugere, Bestået/Ikke bestået/Total — antal beståede og
mislykkede statusser for virtuelle brugere
for belastningsscenarier, samt deres samlede antal.
Det forventes generelt, at alle brugere var i stand til at gennemføre
alle dine opgaver angivet i belastningsprofilen.
Enhver fejl vil betyde, at en rigtig bruger ikke vil være i stand til det
løse dit problem, når du arbejder med systemet
Forespørgsler pr. sekund (minut)- antallet af netværksanmodninger pr. sekund (eller minut).
En vigtig egenskab ved en lastagent er, hvor mange anmodninger den kan generere.
Faktisk er dette en efterligning af virtuelle brugeres adgang til applikationen
Svar pr. sekund (minut)
- antallet af netværkssvar pr. sekund (eller minut).
En vigtig egenskab ved måltjenesten: hvor meget
generere og sende svar på forespørgsler med
læssemiddel
HTTP-svarstatus— antal forskellige svarkoder
fra applikationsserveren modtaget af indlæsningsagenten.
For eksempel betyder 200 OK et vellykket opkald,
og 404 - at ressourcen ikke blev fundet
Latency (svartid) - tid fra slutningen
sende en anmodning (anmodning), før du begynder at modtage et svar (svar).
Normalt målt i millisekunder (ms)
Transaktionens responstid— tidspunktet for en fuldstændig transaktion
afslutning af anmodning-svar-cyklussen.
Dette er tidspunktet fra starten af afsendelsen af anmodningen (anmodningen)
indtil afslutningen af modtagelsen af et svar (svar).
Transaktionstiden kan måles i sekunder (eller minutter)
på flere måder: overvej minimum,
maksimum, gennemsnit og for eksempel 90. percentilen.
Minimum og maksimum aflæsninger er ekstreme
status for systemets ydeevne.
Den halvfemsindstyvende percentil er den mest brugte,
som det viser de fleste af brugerne,
komfortabelt at arbejde på tærsklen af systemets ydeevne
Transaktioner pr. sekund (minut) - antallet af komplette
transaktioner pr. sekund (minut),
det vil sige hvor meget ansøgningen var i stand til at acceptere og
behandle anmodninger og udstede svar.
Faktisk er dette systemets gennemstrømning
Transaktionsstatus , Bestået / Ikke bestået / I alt - antal
vellykket, mislykket og det samlede antal transaktioner.
For rigtige brugere mislykkedes
transaktionen faktisk vil betyde
manglende evne til at arbejde med systemet under belastning
Skematisk diagram af belastningstest
Konceptet med belastningstest er meget enkelt og består af tre hovedfaser, som jeg allerede har nævnt: Forbered-Test-Rapport, det vil sige udarbejdelse af testmål og indstilling af parametre for belastningskilder, derefter udførelse af belastningstest og til sidst generering og udgivelse af en testrapport.
Skematiske noter:
- QA.Tester er ekspert i belastningstest,
- Target er den målapplikation, som du ønsker at kende dens adfærd under belastning.
Klassificering af enheder, stadier og trin i diagrammet
Etaper og trin
Hvad sker der
Hvad er der ved indgangen
Hvad er output
Forbered: forberedelsesstadiet til test
Belastningsparametre
Indstilling og initialisering
bruger
belastningsparametre,
valg af metrikker og
udarbejdelse af testplan
(indlæs profil)
Brugerdefinerede muligheder for
load agent initialisering
Testplan
Formål med test
VM
Cloud-implementering
virtuel maskine med
nødvendige egenskaber
VM-indstillinger for load agent
Automatisering scripts til
VM oprettelse
VM konfigureret i
Sky
konvolut
OS opsætning og forberedelse
miljø for
lastagent arbejde
Miljøindstillinger for
belastningsmiddel
Automatisering scripts til
miljøindstillinger
Forberedt miljø:
OS, tjenester og applikationer,
nødvendigt for arbejdet
belastningsmiddel
LoadAgents
Installation, konfiguration og parametrering
læssemiddel.
Eller download af et docker-billede fra
forudkonfigureret indlæsningskilde
Indlæs kildedocker-billede
(YAT, JM eller selvskrevet ramme)
Indstillinger
belastningsmiddel
Opsat og klar
til arbejdsbelastningsagent
Test: fase af udførelse af belastningstest. Kilder er indlæsningsagenter, der er implementeret i dedikerede agentpuljer til GitLab CI
Load
Start af Load Agent
med valgt testplan
og belastningsparametre
Brugerindstillinger
til initialisering
belastningsmiddel
Testplan
Formål med test
Udførelseslogs
belastningstest
System logs
Dynamik af ændringer i målmålinger og belastningsagent
Kør agenter
Agent henrettelse
masser af test scripts
i overensstemmelse med
belastningsprofil
Indlæs agentinteraktion
med henblik på test
Testplan
Formål med test
Logs
Indsamling af "rå" logs
under belastningstest:
load agent aktivitetsregistreringer,
testmålets tilstand
og den VM, der kører agenten
Udførelseslogs
belastningstest
System logs
Metrics
Indsamling af "rå" metrics under test
Dynamik af ændringer i målmålinger
og load agent
Rapport: forberedelsesstadiet for testrapporten
Generator
Behandling indsamlet
læssesystem og
overvågningssystem "rå"
metrikker og logs
Udarbejdelse af en rapport i
menneskelig læsbar form
muligt med elementer
analytikere
Udførelseslogs
belastningstest
System logs
Dynamik af ændringer i metrics
mål og belastningsmiddel
Bearbejdede "rå" logs
i et format, der passer til
uploads til eksternt lager
Statisk belastningsrapport,
menneskelig læsbar
Udgiv
Udgivelse af rapporten
om belastning
test i ekstern
service
Forarbejdet "rå"
logs i et passende format
til aflæsning til ekstern
depoter
Gemt eksternt
lagerrapporter vedr
belastning, passende
til menneskelig analyse
Tilslutning af belastningskilder i CI-skabelon
Lad os gå videre til den praktiske del. Jeg vil gerne vise hvordan på nogle projekter i virksomheden vi har implementeret konceptet belastningstest som en service.
For det første skabte vi med hjælp fra vores DevOps-ingeniører en dedikeret pulje af agenter i GitLab CI til at køre belastningstest. For ikke at forveksle dem i skabeloner med andre, såsom samlingspuljer, tilføjede vi tags til disse agenter, : belastning. Du kan bruge alle andre forståelige tags. De spørger GitLab CI Runners.
Hvordan finder man ud af den nødvendige strøm af hardware? Karakteristika for load-agenter - et tilstrækkeligt antal vCPU, RAM og Disk - kan beregnes ud fra det faktum, at Docker, Python (for Yandex.Tank), GitLab CI-agent, Java (for Apache JMeter) skal køre på agenten . For Java under JMeter anbefales det også at bruge minimum 512 MB RAM og som en øvre grænse, .
Baseret på vores erfaring anbefaler vi derfor at bruge mindst 4 vCPU'er, 4 GB RAM, 60 GB SSD til load agents. Netværkskortets gennemløb bestemmes ud fra kravene til belastningsprofilen.
Vi bruger hovedsageligt to indlæsningskilder - Apache JMeter og Yandex.Tank docker-billeder.
er et open source-værktøj fra Yandex til belastningstest. Dens modulære arkitektur er baseret på Phantoms højtydende asynkrone hit-baserede HTTP-anmodningsgenerator. Tanken har en indbygget overvågning af ressourcerne på serveren under test via SSH-protokollen, kan automatisk stoppe testen under specificerede forhold, kan vise resultaterne både i konsollen og i form af grafer, du kan tilslutte dine moduler til det for at udvide funktionaliteten. Forresten brugte vi Tanken, da den endnu ikke var mainstream. I artiklen "» du kan læse historien om, hvordan vi udførte belastningstest med den i 2013 er et af vores virksomheds produkter.
er et open source-belastningstestværktøj fra Apache. Det kan bruges lige så godt til at teste både statiske og dynamiske webapplikationer. JMeter understøtter et stort antal protokoller og måder at interagere med applikationer på: 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 en IDE til oprettelse, fejlretning og udførelse af testplaner. Der er også en CLI til kommandolinjebetjening på ethvert Java-kompatibelt operativsystem (Linux, Windows, Mac OS X). Værktøjet kan dynamisk generere en HTML-testrapport.
For at lette brugen inden for vores virksomhed, for testernes egen evne til at ændre og tilføje miljøet, lavede vi builds af docker-billeder af indlæsningskilder på GitLab CI med publicering til den interne . Dette gør det hurtigere og nemmere at forbinde dem i rørledninger til belastningstest. Sådan laver du docker-push til registreringsdatabasen via GitLab CI - se .
Vi tog denne grundlæggende docker-fil til Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Og til Apache JMeter denne:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Du kan læse hvordan vores kontinuerlige integrationssystem fungerer i artiklen "'.
Skabelon og pipeline
Et eksempel på en skabelon til udførelse af belastningstest findes i projektet . I Du kan læse instruktionerne til brug af skabelonen. I selve skabelonen (fil ) der er noter om, hvad hvert trin er ansvarligt for.
Skabelonen er meget enkel og demonstrerer de tre stadier af belastningstestning, der er beskrevet i diagrammet ovenfor: forberedelse, testning og udgivelse af rapporter. Ansvarlig for dette : Forbered, test og rapporter.
- etape skal bruges til at forudkonfigurere testmål eller kontrollere deres tilgængelighed. Miljøet for indlæsningskilder behøver ikke at være konfigureret, de er præbygget som docker-billeder og lagt op i docker-registret: Angiv blot den ønskede version på teststadiet. Men du kan genopbygge dem og lave dine egne ændrede billeder.
- etape bruges til at angive belastningskilden, køre test og gemme testartefakter. Du kan vælge enhver belastningskilde: Yandex.Tank, Apache JMeter, din egen eller alle sammen. For at deaktivere unødvendige kilder skal du bare kommentere eller slette jobbet. Indgangspunkter for belastningskilder:
- Startparametre for Yandex.Tank er angivet i .,
- Apache JMeter-startparametre er angivet i filen .
Bemærk: Monteringskonfigurationsskabelonen bruges til at opsætte interaktion med CI-systemet og indebærer ikke placering af testlogik i det. For test er indgangspunktet angivet, hvor kontrolbash-scriptet er placeret. Metoden til at køre test, generere rapporter og selve testscripts skal implementeres af QA-ingeniører. I demoen, for begge indlæsningskilder, bruges Yandex-hovedsideanmodningen som den enkleste test. Scripts og testparametre er i mappen .
- På scenen du skal beskrive, hvordan du publicerer testresultaterne opnået på teststadiet til eksterne lagre, for eksempel til GitLab-sider eller specielle rapporteringssystemer. GitLab Pages kræver, at ./public-mappen ikke er tom og indeholder mindst en index.html-fil, efter at testene er afsluttet. Du kan læse om nuancerne i GitLab Pages-tjenesten. .
Eksempler på, hvordan du eksporterer data:
- fra JMeter til ,
- fra Yandex.Tank til .
Opsætningsinstruktioner til opslag:
- HTML-statik i ,
- til InfluxDB og derefter til .
I demoeksemplet ser pipelinen med belastningstests og to belastningskilder (du kan deaktivere den unødvendige) sådan her:
Apache JMeter kan selv generere en HTML-rapport, så det er mere rentabelt at gemme den i GitLab Pages ved hjælp af standardværktøjer. Sådan ser Apache JMeter-rapporten ud:
I demoeksemplet til Yandex.Tank vil du kun se i sektionen for GitLab-sider. Under test kan Tanken gemme resultaterne i InfluxDB-databasen, og derfra kan de f.eks. vises i Grafana (konfigurationen foretages i filen ). Sådan ser Tanks rapport ud i Grafana:
Resumé
I artiklen talte jeg om begrebet "load testing as a service" (load testing as a service). Hovedidéen er at bruge infrastrukturen af prækonfigurerede puljer af belastningsagenter, docker-billeder af belastningskilder, rapporteringssystemer og en pipeline, der kombinerer dem i GitLab CI baseret på en simpel .gitlab-ci.yml-skabelon (eksempel ). Alt dette understøttes af et lille team af automationsingeniører og replikeres efter anmodning fra produktteams. Jeg håber, at dette vil hjælpe dig med at udarbejde og implementere en lignende ordning i din virksomhed. Tak for din opmærksomhed!
PS Jeg vil gerne sige en stor tak til mine kolleger, Sergey Kurbanov og Nikolai Yusev, for teknisk assistance med implementeringen af konceptet med belastningstest som en service i vores virksomhed.
Forfatter: - Stedfortræder Head of Technology and Development Processes (DevOps) hos Positive Technologies
Kilde: www.habr.com