Ett av problemen som programvaruleverantörer av flera produkter ofta möter är dubbelarbetet av kompetensen hos ingenjörer - utvecklare, testare och infrastrukturadministratörer - i nästan alla team. Detta gäller även dyra ingenjörer - specialister inom området lastprovning.
Istället för att utföra sina direkta uppgifter och använda sin unika erfarenhet för att bygga en lasttestprocess, välja en metodik, optimala mätvärden och skriva autotester i enlighet med lastprofiler, måste ingenjörer ofta distribuera testinfrastruktur från grunden, konfigurera lastverktyg och bädda in dem själva i CI-system, sätta upp övervakning och publicering av rapporter.
Du kan hitta lösningar på vissa organisatoriska problem i testning som vi använder på Positive Technologies i . Och i den här kommer jag att prata om möjligheten att integrera lasttester i en gemensam CI-pipeline med hjälp av konceptet "lasttestning som en tjänst" (lasttestning som en tjänst). Du kommer att lära dig hur och vilka docker-bilder av lastkällor som kan användas i CI-pipeline; hur du ansluter laddningskällor till ditt CI-projekt med hjälp av en byggmall; hur demopipelinen ser ut för att köra belastningstester och publicera resultaten. Artikeln kan vara användbar för mjukvarutestningsingenjörer och automationsingenjörer inom CI som funderar på arkitekturen för sitt lastsystem.
Kärnan i konceptet
Konceptet med lasttestning som en tjänst innebär möjligheten att integrera lastverktyg Apache JMeter, Yandex.Tank och dina egna ramverk i ett godtyckligt kontinuerligt integrationssystem. Demon kommer att vara för GitLab CI, men principerna är gemensamma för alla CI-system.
Lasttestning som en tjänst är en centraliserad tjänst för lasttestning. Belastningstester körs i dedikerade agentpooler, resultaten publiceras automatiskt i GitLab Pages, Influx DB och Grafana eller i testrapporteringssystem (TestRail, ReportPortal, etc.). Automatisering och skalning implementeras så enkelt som möjligt - genom att lägga till och parametrera den vanliga gitlab-ci.yml-mallen i GitLab CI-projektet.
Fördelen med detta tillvägagångssätt är att hela CI-infrastrukturen, lastagenter, docker-bilder av lastkällor, testpipelines och publiceringsrapporter underhålls av en centraliserad automationsavdelning (DevOps-ingenjörer), medan lasttestingenjörer kan fokusera sina ansträngningar på testutveckling och analys av deras resultat, utan att ta itu med infrastrukturfrågor.
För att förenkla beskrivningen kommer vi att anta att målapplikationen eller servern som testas redan har distribuerats och konfigurerats i förväg (automatiska skript i Python, SaltStack, Ansible, etc. kan användas för detta). Då ryms hela konceptet med lasttestning som en tjänst i tre steg: förberedelse, testning, publicering av rapporter. Mer information om diagrammet (alla bilder är klickbara):
Grundläggande begrepp och definitioner inom lastprovning
Vid utförande av belastningstester försöker vi följa , använd lämplig terminologi och rekommenderade mätvärden. Jag kommer att ge en kort lista över huvudbegreppen och definitioner inom lasttestning.
Lastagent - en virtuell maskin på vilken applikationen kommer att startas - laddningskällan (Apache JMeter, Yandex.Tank eller en självskriven laddningsmodul).
Testmål (mål) - Server eller applikation installerad på servern som kommer att laddas.
Testscenario (testfall) - en uppsättning parametriserade steg: användaråtgärder och förväntade reaktioner på dessa åtgärder, med fasta nätverksbegäranden och svar, beroende på de angivna parametrarna.
Profil eller lastplan (profil) - kl (Avsnitt 4.2.4, s. 43) belastningsprofiler definierar mått som är kritiska för ett visst test och alternativ för att ändra belastningsparametrar under testet. Du kan se exempel på profiler i figuren.
Testa — ett skript med en förutbestämd uppsättning parametrar.
Testplan (testplan) - en uppsättning tester och en lastprofil.
Testran (testrun) - en iteration av att köra ett test med ett fullständigt kört laddningsscenario och den mottagna rapporten.
Nätverksbegäran (begäran) — En HTTP-begäran som skickas från en agent till ett mål.
Nätverkssvar (svar) — Ett HTTP-svar som skickas från målet till agenten.
HTTP-svarskod (HTTP-svarsstatus) - standardsvarskod från applikationsservern.
En transaktion är en fullständig begäran-svarscykel. En transaktion räknas från början av sändningen av en förfrågan (förfrågan) till slutförandet av mottagandet av ett svar (svar).
Transaktionsstatus - om det var möjligt att framgångsrikt slutföra begäran-svar-cykeln. Om det fanns något fel i denna cykel anses hela transaktionen vara misslyckad.
Svarstid (latens) - tiden från slutet av att skicka en förfrågan (förfrågan) tills början av mottagandet av ett svar (svar).
Ladda mätvärden — Egenskaperna för den lastade tjänsten och lastmedlet som fastställts under lastprovningen.
Grundläggande mätvärden för att mäta belastningsparametrar
Några av de mest använda och rekommenderade i metodiken (sid. 36, 52) mätvärdena visas i tabellen nedan. Liknande mätvärden för agent och mål listas på samma rad.
Mätvärden för lastagenten
Mätvärden för målsystemet eller applikationen som testas under belastning
Nummer vCPU och minne RAM,
Disk - "järn" egenskaper hos lastmedlet
CPU, Minne, diskanvändning - dynamik för CPU, minne och diskladdning
håller på att testa. Vanligtvis mätt i procent av
maximala tillgängliga värden
Nätverksgenomströmning (på lastmedel) - genomströmning
nätverksgränssnitt på servern,
där lastagenten är installerad.
Mäts vanligtvis i byte per sekund (bps)
Nätverksgenomströmning(på mål) - nätverksgränssnittets bandbredd
på målservern. Mäts vanligtvis i byte per sekund (bps)
Virtuella användare- antalet virtuella användare,
implementera belastningsscenarier och
efterlikna verkliga användarhandlingar
Virtuella användares status, Godkänd/Underkänd/Totalt — antal framgångsrika och
misslyckade statusar för virtuella användare
för belastningsscenarier, såväl som deras totala antal.
Det förväntas i allmänhet att alla användare kunde slutföra
alla dina uppgifter som anges i belastningsprofilen.
Alla fel kommer att innebära att en riktig användare inte kommer att kunna
lösa ditt problem när du arbetar med systemet
Förfrågningar per sekund (minut)- antalet nätverksbegäranden per sekund (eller minut).
En viktig egenskap hos en lastagent är hur många förfrågningar den kan generera.
I själva verket är detta en imitation av åtkomst till applikationen för virtuella användare
Svar per sekund (minut)
- antalet nätverkssvar per sekund (eller minut).
En viktig egenskap hos måltjänsten: hur mycket
generera och skicka svar på frågor med
lastningsmedel
HTTP-svarsstatus— Antal olika svarskoder
från applikationsservern som tas emot av lastagenten.
Till exempel betyder 200 OK ett lyckat samtal,
och 404 - att resursen inte hittades
Latens (svarstid) - tid från slutet
skicka en begäran (request) innan du börjar få ett svar (response).
Mäts vanligtvis i millisekunder (ms)
Transaktionens svarstid— tidpunkten för en fullständig transaktion,
slutförandet av begäran-svar-cykeln.
Detta är tiden från början av att skicka förfrågan (förfrågan)
tills mottagandet av ett svar (svar).
Transaktionstiden kan mätas i sekunder (eller minuter)
på flera sätt: överväg minimum,
maximum, genomsnitt och till exempel 90:e percentilen.
Minsta och maximala värden är extrema
systemets prestandastatus.
Den nittionde percentilen är den vanligaste,
som det visar de flesta av användarna,
fungerar bekvämt på tröskeln för systemets prestanda
Transaktioner per sekund (minut) - antalet kompletta
transaktioner per sekund (minut),
det vill säga hur mycket ansökan kunde acceptera och
behandla förfrågningar och utfärda svar.
I själva verket är detta genomströmningen av systemet
Transaktionsstatus , Godkänd / Underkänd / Totalt - antal
framgångsrika, misslyckade och det totala antalet transaktioner.
För riktiga användare misslyckas
transaktionen faktiskt kommer att innebära
oförmåga att arbeta med systemet under belastning
Schematiskt diagram för lasttestning
Konceptet med lasttestning är mycket enkelt och består av tre huvudsteg, som jag redan har nämnt: Förbered-Test-Rapport, det vill säga förbereda testmål och ställa in parametrar för belastningskällor, sedan utföra belastningstester och, i slutet, generera och publicera en testrapport.
Schematiska anteckningar:
- QA.Tester är expert på belastningstestning,
- Target är målapplikationen för vilken du vill veta dess beteende under belastning.
Klassificerare av enheter, stadier och steg i diagrammet
Etapper och steg
Vad händer
Vad finns vid ingången
Vad är utgången
Förbered: förberedelsestadiet för testning
Ladda parametrar
Inställning och initialisering
användare
ladda parametrar,
val av mått och
utarbetande av testplan
(ladda profil)
Anpassade alternativ för
laddningsagentinitiering
Testplan
Syftet med testningen
VM
Molndistribution
virtuell maskin med
erforderliga egenskaper
VM-inställningar för load agent
Automatiseringsskript för
VM skapande
VM konfigurerad i
moln
env
OS-installation och förberedelse
miljö för
lastagentarbete
Miljöinställningar för
lastmedel
Automatiseringsskript för
miljöinställningar
Förberedd miljö:
OS, tjänster och applikationer,
nödvändigt för arbetet
lastmedel
LoadAgents
Installation, konfiguration och parametrering
lastningsmedel.
Eller ladda ner en docker-bild från
förkonfigurerad laddningskälla
Ladda källdockningsbild
(YAT, JM eller självskrivet ramverk)
inställningar
lastmedel
Ställ in och klar
till arbetsbelastningsagent
Test: stadiet för utförande av belastningstester. Källor är belastningsagenter som distribueras i dedikerade agentpooler för GitLab CI
Ladda
Starta lastagenten
med vald testplan
och belastningsparametrar
Användaralternativ
för initiering
lastmedel
Testplan
Syftet med testningen
Utförandeloggar
belastningstester
Systemloggar
Dynamik för förändringar i målmått och lastagent
Kör agenter
Agent avrättning
massor av testskript
i enlighet med
ladda profil
Ladda agentinteraktion
i syfte att testa
Testplan
Syftet med testningen
Loggar
Samling av "rå" stockar
under belastningstestning:
belastningsagentaktivitetsregister,
testmålets tillstånd
och den virtuella datorn som kör agenten
Utförandeloggar
belastningstester
Systemloggar
Metrics
Samla in "rå" mätvärden under testning
Dynamik för förändringar i målmått
och lastmedel
Rapport: förberedelsestadiet för testrapporten
Generator
Bearbetning insamlad
lastningssystem och
övervakningssystem "rå"
mätvärden och loggar
Bildande av en rapport i
mänsklig läsbar form
möjligt med element
analytiker
Utförandeloggar
belastningstester
Systemloggar
Dynamik för förändringar i mått
mål och lastmedel
Bearbetade "rå" loggar
i ett format som lämpar sig för
laddar upp till extern lagring
Statisk belastningsrapport,
läsbar för människor
Publicera
Publicering av rapporten
om belastning
testning i extern
service
Bearbetad "rå"
loggar i lämpligt format
för avlastning till extern
förråd
Sparad i extern
lagring rapporterar om
belastning, lämplig
för mänsklig analys
Ansluter belastningskällor i CI-mall
Låt oss gå vidare till den praktiska delen. Jag vill visa hur på några projekt i företaget vi har implementerat konceptet lasttestning som en tjänst.
Först skapade vi med hjälp av våra DevOps-ingenjörer en dedikerad pool av agenter i GitLab CI för att köra belastningstester. För att inte blanda ihop dem i mallar med andra, till exempel sammansättningspooler, lade vi till taggar till dessa agenter, : ladda. Du kan använda alla andra förståeliga taggar. De frågar GitLab CI Runners.
Hur tar man reda på den kraft som krävs av hårdvara? Lastagenternas egenskaper - ett tillräckligt antal vCPU, RAM och disk - kan beräknas baserat på det faktum att Docker, Python (för Yandex.Tank), GitLab CI-agent, Java (för Apache JMeter) bör köras på agenten . För Java under JMeter rekommenderas också att använda minst 512 MB RAM och, som en övre gräns, .
Därför rekommenderar vi, baserat på vår erfarenhet, att du använder minst 4 vCPU:er, 4 GB RAM, 60 GB SSD för belastningsagenter. Nätverkskortets genomströmning bestäms utifrån kraven för belastningsprofilen.
Vi använder huvudsakligen två laddningskällor - Apache JMeter och Yandex.Tank docker-bilder.
är ett verktyg med öppen källkod från Yandex för belastningstestning. Dess modulära arkitektur är baserad på Phantoms högpresterande asynkrona träffbaserade HTTP-förfrågningsgenerator. Tanken har en inbyggd övervakning av resurserna på servern som testas via SSH-protokollet, kan automatiskt stoppa testet under specificerade förhållanden, kan visa resultaten både i konsolen och i form av grafer, du kan ansluta dina moduler till det för att utöka funktionaliteten. Förresten, vi använde Tanken när den ännu inte var mainstream. I artikeln "» du kan läsa historien om hur vi utförde belastningstester med den 2013 är en av vårt företags produkter.
är ett belastningstestverktyg med öppen källkod från Apache. Den 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 Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) och IMAP(S), databaser via JDBC, kan köra skalkommandon och arbeta med Java-objekt. JMeter har en IDE för att skapa, felsöka och köra testplaner. Det finns också en CLI för kommandoradsdrift på alla Java-kompatibla operativsystem (Linux, Windows, Mac OS X). Verktyget kan dynamiskt generera en HTML-testrapport.
För att underlätta användningen inom vårt företag, för testarnas förmåga att själva förändra och lägga till miljön, gjorde vi byggen av docker-bilder av laddningskällor på GitLab CI med publicering till den interna . Detta gör det snabbare och enklare att ansluta dem i rörledningar för belastningstester. Hur man gör docker-push till registret via GitLab CI - se .
Vi tog den här grundläggande docker-filen för Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Och för Apache JMeter den här:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Du kan läsa hur vårt kontinuerliga integrationssystem fungerar i artikeln "".
Mall och pipeline
Ett exempel på en mall för att genomföra belastningstester finns i projektet . I Du kan läsa instruktionerna för att använda mallen. I själva mallen (fil ) finns anteckningar om vad varje steg ansvarar för.
Mallen är mycket enkel och visar de tre stegen av belastningstestning som beskrivs i diagrammet ovan: förbereda, testa och publicera rapporter. Ansvarig för detta : Förbered, testa och rapportera.
- stadium bör användas för att förkonfigurera testmål eller kontrollera deras tillgänglighet. Miljön för laddningskällor behöver inte konfigureras, de är förbyggda som docker-bilder och läggs upp i docker-registret: ange bara önskad version i teststadiet. Men du kan bygga om dem och göra dina egna modifierade bilder.
- stadium används för att specificera belastningskällan, köra tester och lagra testartefakter. Du kan välja vilken laddningskälla som helst: Yandex.Tank, Apache JMeter, din egen eller alla tillsammans. För att inaktivera onödiga källor, kommentera bara eller ta bort jobbet. Ingångspunkter för belastningskällor:
- Startparametrar för Yandex.Tank anges i .,
- Apache JMeter-startparametrar anges i filen .
Obs: Monteringskonfigurationsmallen används för att ställa in interaktion med CI-systemet och innebär inte placering av testlogik i det. För tester anges ingångspunkten, där kontrollbash-skriptet finns. Metoden för att köra tester, generera rapporter och själva testskripten måste implementeras av QA-ingenjörer. I demon, för båda laddningskällorna, används Yandex huvudsidesbegäran som det enklaste testet. Skript och testparametrar finns i katalogen .
- På scenen du behöver beskriva hur du publicerar testresultaten som erhållits i teststadiet till externa lagringar, till exempel till GitLab-sidor eller speciella rapporteringssystem. GitLab Pages kräver att ./public-katalogen inte är tom och innehåller minst en index.html-fil efter att testerna är klara. Du kan läsa om nyanserna i tjänsten GitLab Pages. .
Exempel på hur man exporterar data:
- från JMeter till ,
- från Yandex.Tank till .
Lägga upp installationsinstruktioner:
- HTML-statik in ,
- till InfluxDB och sedan till .
I demoexemplet ser pipelinen med belastningstester och två belastningskällor (du kan inaktivera den onödiga) så här:
Apache JMeter kan generera en HTML-rapport själv, så det är mer lönsamt att spara den i GitLab-sidor med standardverktyg. Så här ser Apache JMeter-rapporten ut:
I demoexemplet för Yandex.Tank kommer du bara att se i avsnittet för GitLab-sidor. Under testning kan Tanken spara resultaten till InfluxDB-databasen och därifrån kan de visas till exempel i Grafana (konfigurering görs i filen ). Så här ser Tanks rapport ut i Grafana:
Sammanfattning
I artikeln pratade jag om begreppet "load testing as a service" (load testing as a service). Huvudidén är att använda infrastrukturen för förkonfigurerade pooler av lastagenter, docker-bilder av lastkällor, rapporteringssystem och en pipeline som kombinerar dem i GitLab CI baserat på en enkel .gitlab-ci.yml-mall (exempel: ). Allt detta stöds av ett litet team av automationsingenjörer och replikeras på begäran av produktteam. Jag hoppas att detta kommer att hjälpa dig att förbereda och implementera ett liknande system i ditt företag. Tack för uppmärksamheten!
PS Jag vill säga ett stort tack till mina kollegor, Sergey Kurbanov och Nikolai Yusev, för teknisk assistans med implementeringen av konceptet lasttestning som en tjänst i vårt företag.
Författare: - Ställföreträdare Head of Technologies and Development Processes (DevOps) på Positive Technologies
Källa: will.com