Et av problemene som programvareleverandører av flere produkter ofte står overfor, er duplisering av kompetansen til ingeniører – utviklere, testere og infrastrukturadministratorer – på nesten alle lag. Dette gjelder også for dyre ingeniører - spesialister innen lasttesting.
I stedet for å gjøre sine direkte plikter og bruke sin unike erfaring til å bygge en lasttestingsprosess, velge en metodikk, optimale beregninger og skrive autotester i samsvar med lastprofiler, må ingeniører ofte distribuere testinfrastruktur fra bunnen av, konfigurere lasteverktøy og bygge dem inn. seg i CI-systemer, sette opp overvåking og publisering av rapporter.
Du kan finne løsninger på noen organisatoriske problemer i testing som vi bruker hos Positive Technologies i . Og i denne vil jeg snakke om muligheten for å integrere lasttester i en felles CI-rørledning ved å bruke konseptet "lasttesting som en tjeneste" (lasttesting som en tjeneste). Du vil lære hvordan og hvilke docker-bilder av lastkilder som kan brukes i CI-pipeline; hvordan koble belastningskilder til CI-prosjektet ditt ved hjelp av en byggemal; hvordan demo-pipelinen ser ut for å kjøre belastningstester og publisere resultatene. Artikkelen kan være nyttig for programvaretestende ingeniører og automasjonsingeniører i CI som tenker på arkitekturen til lastsystemet sitt.
Essensen av konseptet
Konseptet med lasttesting som en tjeneste innebærer muligheten til å integrere lastverktøy Apache JMeter, Yandex.Tank og dine egne rammeverk i et vilkårlig kontinuerlig integreringssystem. Demoen vil være for GitLab CI, men prinsippene er felles for alle CI-systemer.
Lasttesting som en tjeneste er en sentralisert tjeneste for lasttesting. Lastetester kjøres i dedikerte agentpooler, resultatene publiseres automatisk i GitLab Pages, Influx DB og Grafana eller i testrapporteringssystemer (TestRail, ReportPortal, etc.). Automatisering og skalering implementeres så enkelt som mulig - ved å legge til og parameterisere den vanlige gitlab-ci.yml-malen i GitLab CI-prosjektet.
Fordelen med denne tilnærmingen er at hele CI-infrastrukturen, lastagenter, docker-bilder av lastkilder, testrørledninger og publiseringsrapporter vedlikeholdes av en sentralisert automasjonsavdeling (DevOps-ingeniører), mens lasttestingsingeniører kan fokusere innsatsen på testutvikling og analyse av resultatene deres, uten å forholde seg til infrastrukturspørsmål.
For enkelhets skyld vil vi anta at målapplikasjonen eller serveren som testes allerede er distribuert og konfigurert på forhånd (automatiserte skript i Python, SaltStack, Ansible, etc. kan brukes til dette). Da passer hele konseptet med lasttesting som en tjeneste inn i tre stadier: utarbeidelse, testing, publisering av rapporter. Flere detaljer på diagrammet (alle bilder er klikkbare):
Grunnleggende begreper og definisjoner i lasttesting
Ved gjennomføring av belastningstester prøver vi å forholde oss til , bruk riktig terminologi og anbefalte beregninger. Jeg vil gi en kort liste over hovedbegrepene og definisjonene i lasttesting.
Lastemiddel - en virtuell maskin som applikasjonen vil bli lansert på - lastekilden (Apache JMeter, Yandex.Tank eller en selvskrevet lastemodul).
Testmål (mål) - server eller applikasjon installert på serveren som vil bli utsatt for belastning.
Testscenario (testcase) - et sett med parametriserte trinn: brukerhandlinger og forventede reaksjoner på disse handlingene, med faste nettverksforespørsler og svar, avhengig av de angitte parameterne.
Profil eller lasteplan (profil) - inn (Avsnitt 4.2.4, s. 43) lastprofiler definerer beregninger som er kritiske for en bestemt test og alternativer for å endre lastparametere under testen. Du kan se eksempler på profiler i figuren.
Test — et skript med et forhåndsbestemt sett med parametere.
Testplan (testplan) - et sett med tester og en lastprofil.
Testran (testrun) - én iterasjon av å kjøre en test med et fullstendig utført belastningsscenario og den mottatte rapporten.
Nettverksforespørsel (forespørsel) — En HTTP-forespørsel sendt fra en agent til et mål.
Nettverksrespons (respons) — Et HTTP-svar sendt fra målet til agenten.
HTTP-svarkode (HTTP-svarstatus) - standard svarkode fra applikasjonsserveren.
En transaksjon er en fullstendig forespørsel-svar-syklus. En transaksjon telles fra starten av å sende en forespørsel (forespørsel) til fullføringen av mottak av et svar (svar).
Transaksjonsstatus - om det var mulig å fullføre forespørsel-svar-syklusen. Hvis det var noen feil i denne syklusen, anses hele transaksjonen som mislykket.
Responstid (latens) - tiden fra slutten av å sende en forespørsel (forespørsel) til begynnelsen av å motta et svar (svar).
Last inn beregninger – egenskapene til den lastede tjenesten og lastemiddelet som er bestemt i prosessen med lasttesting.
Grunnleggende beregninger for måling av lastparametere
Noen av de mest brukte og anbefalte i metodikken (s. 36, 52) metrikkene er vist i tabellen nedenfor. Lignende beregninger for agent og mål er oppført på samme linje.
Beregninger for lastagenten
Beregninger for målsystemet eller applikasjonen som testes under belastning
Nummer vCPU og minne RAM,
Disk - "jern"-karakteristikker til lastemiddelet
prosessor, Minne, diskbruk - dynamikk av CPU, minne og disklasting
i ferd med å teste. Vanligvis målt i prosent av
maksimale tilgjengelige verdier
Nettverksgjennomstrømning (på lastemiddel) - gjennomstrømning
nettverksgrensesnitt på serveren,
hvor load agenten er installert.
Vanligvis målt i byte per sekund (bps)
Nettverksgjennomstrømning(på mål) - båndbredde for nettverksgrensesnitt
på målserveren. Vanligvis målt i byte per sekund (bps)
Virtuelle brukere- antall virtuelle brukere,
implementere belastningsscenarier og
imitere ekte brukerhandlinger
Status for virtuelle brukere, Bestått/Ikke bestått/Totalt — antall vellykkede og
mislykkede statuser for virtuelle brukere
for lastscenarier, samt deres totale antall.
Det forventes generelt at alle brukere var i stand til å fullføre
alle oppgavene dine spesifisert i lasteprofilen.
Enhver feil vil bety at en ekte bruker ikke vil være i stand til det
løse problemet når du arbeider med systemet
Forespørsler per sekund (minutt)- antall nettverksforespørsler per sekund (eller minutt).
En viktig egenskap ved en lastagent er hvor mange forespørsler den kan generere.
Faktisk er dette en etterligning av tilgang til applikasjonen for virtuelle brukere
Svar per sekund (minutt)
- antall nettverkssvar per sekund (eller minutt).
En viktig egenskap ved måltjenesten: hvor mye
generere og sende svar på forespørsler med
lastemiddel
HTTP-svarstatus— antall ulike svarkoder
fra applikasjonsserveren mottatt av lasteagenten.
For eksempel betyr 200 OK en vellykket samtale,
og 404 - at ressursen ikke ble funnet
Ventetid (responstid) - tid fra slutten
sende en forespørsel (forespørsel) før du begynner å motta et svar (svar).
Vanligvis målt i millisekunder (ms)
Transaksjonens responstid– tidspunktet for en full transaksjon,
fullføring av forespørsel-svar-syklusen.
Dette er tiden fra starten av sendingen av forespørselen (forespørselen)
til ferdigstillelse av mottak av svar (svar).
Transaksjonstiden kan måles i sekunder (eller minutter)
på flere måter: tenk på minimum,
maksimum, gjennomsnitt og for eksempel 90. persentilen.
Minimums- og maksimumsavlesningene er ekstreme
systemytelsesstatus.
Den nittiende persentilen er den mest brukte,
som det viser de fleste av brukerne,
fungerer komfortabelt på terskelen for systemytelse
Transaksjoner per sekund (minutt) - antall komplette
transaksjoner per sekund (minutt),
det vil si hvor mye søknaden var i stand til å godta og
behandle forespørsler og utstede svar.
Faktisk er dette gjennomstrømningen til systemet
Transaksjonsstatus , Bestått / Ikke bestått / Totalt - antall
vellykket, mislykket og totalt antall transaksjoner.
For ekte brukere mislykket
transaksjonen faktisk vil bety
manglende evne til å jobbe med systemet under belastning
Skjematisk diagram for lasttesting
Konseptet med lasttesting er veldig enkelt og består av tre hovedtrinn, som jeg allerede har nevnt: Forbered-Test-Rapport, det vil si å utarbeide testmål og sette parametere for belastningskilder, deretter utføre belastningstester og på slutten generere og publisere en testrapport.
Skjematiske merknader:
- QA.Tester er en ekspert på belastningstesting,
- Target er målapplikasjonen du vil vite atferden til under belastning.
Klassifisering av enheter, stadier og trinn i diagrammet
Etapper og trinn
Hva skjer
Hva er ved inngangen
Hva er utgangen
Forbered: forberedelsesstadiet for testing
Lasteparametere
Innstilling og initialisering
bruker
laste parametere,
valg av beregninger og
utarbeidelse av testplan
(last profil)
Egendefinerte alternativer for
load agent initialisering
Testplan
Formål med testing
VM
Skydistribusjon
virtuell maskin med
nødvendige egenskaper
VM-innstillinger for load agent
Automatiseringsskript for
VM opprettelse
VM konfigurert i
Sky
env
OS-oppsett og klargjøring
miljø for
lasteagent arbeid
Miljøinnstillinger for
lastemiddel
Automatiseringsskript for
miljøinnstillinger
Forberedt miljø:
OS, tjenester og applikasjoner,
nødvendig for arbeid
lastemiddel
LoadAgents
Installasjon, konfigurering og parameterisering
lastemiddel.
Eller laste ned et docker-bilde fra
forhåndskonfigurert lastekilde
Last inn kildedokkerbilde
(YAT, JM eller selvskrevet rammeverk)
Innstillinger
lastemiddel
Sett opp og klar
til arbeidsbelastningsagent
Test: stadiet for utførelse av belastningstester. Kilder er belastningsagenter som er distribuert i dedikerte agentpooler for GitLab CI
Laste
Starte Load Agent
med valgt testplan
og belastningsparametere
Brukeralternativer
for initialisering
lastemiddel
Testplan
Formål med testing
Utførelseslogger
belastningstester
Systemlogger
Dynamikk av endringer i målberegninger og belastningsagent
Kjør agenter
Agent henrettelse
masse testskript
i samsvar med
lastprofil
Last agentinteraksjon
med det formål å teste
Testplan
Formål med testing
Logger
Samling av "rå" logger
under lasttesting:
lasteagentaktivitetsposter,
tilstanden til testmålet
og VM som kjører agenten
Utførelseslogger
belastningstester
Systemlogger
Metrics
Innsamling av "rå" beregninger under testing
Dynamikk ved endringer i målberegninger
og lastemiddel
Rapport: forberedelsesstadiet for testrapporten
Generator
Behandling samlet
lastesystem og
overvåkingssystem "rå"
metrikk og logger
Utarbeidelse av en rapport i
menneskelig lesbar form
mulig med elementer
analytikere
Utførelseslogger
belastningstester
Systemlogger
Dynamikk ved endringer i beregninger
mål og lastemiddel
Behandlet "rå" logger
i et format som passer for
laster opp til ekstern lagring
Statisk belastningsrapport,
lesbar for mennesker
Publiser
Offentliggjøring av rapporten
om belastning
testing i ekstern
service
Bearbeidet "rå"
logger i et passende format
for lossing til ekstern
depoter
Lagret i ekstern
lagringsrapporter om
belastning, passende
for menneskelig analyse
Koble til lastkilder i CI-mal
La oss gå videre til den praktiske delen. Jeg ønsker å vise hvordan på noen prosjekter i selskapet vi har implementert konseptet lasttesting som en tjeneste.
Først, ved hjelp av våre DevOps-ingeniører, opprettet vi en dedikert pool av agenter i GitLab CI for å kjøre belastningstester. For ikke å forveksle dem i maler med andre, for eksempel samlingspooler, la vi til tagger til disse agentene, : last. Du kan bruke alle andre forståelige tagger. De spør GitLab CI-løpere.
Hvordan finne ut nødvendig kraft etter maskinvare? Egenskapene til lastagenter - et tilstrekkelig antall vCPU, RAM og disk - kan beregnes basert på det faktum at Docker, Python (for Yandex.Tank), GitLab CI-agent, Java (for Apache JMeter) skal kjøres på agenten . For Java under JMeter anbefales det også å bruke minimum 512 MB RAM og, som en øvre grense, .
Derfor, basert på vår erfaring, anbefaler vi å bruke minst 4 vCPUer, 4 GB RAM, 60 GB SSD for load agents. Gjennomstrømningen til nettverkskortet bestemmes basert på kravene til lastprofilen.
Vi bruker hovedsakelig to belastningskilder - Apache JMeter og Yandex.Tank docker-bilder.
er et åpen kildekodeverktøy fra Yandex for lasttesting. Dens modulære arkitektur er basert på Phantoms høyytelses asynkrone treffbaserte HTTP-forespørselsgenerator. Tanken har en innebygd overvåking av ressursene til serveren som testes via SSH-protokollen, kan automatisk stoppe testen under spesifiserte forhold, kan vise resultatene både i konsollen og i form av grafer, du kan koble til modulene dine til det for å utvide funksjonaliteten. Forresten, vi brukte Tanken da den ennå ikke var mainstream. I artikkelen "» du kan lese historien om hvordan vi utførte lasttesting med den i 2013 er et av vårt firmas produkter.
er et åpen kildekode-lasttestverktøy fra Apache. Den kan brukes like godt til å teste både statiske og dynamiske webapplikasjoner. JMeter støtter et stort antall protokoller og måter å samhandle med applikasjoner på: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) og IMAP(S), databaser via JDBC, kan utføre skallkommandoer og arbeide med Java-objekter. JMeter har en IDE for å lage, feilsøke og utføre testplaner. Det er også en CLI for kommandolinjedrift på alle Java-kompatible operativsystemer (Linux, Windows, Mac OS X). Verktøyet kan dynamisk generere en HTML-testrapport.
For enkel bruk i selskapet vårt, for testerne selv til å endre og legge til miljøet, laget vi bygg av docker-bilder av lastekilder på GitLab CI med publisering til intern . Dette gjør det raskere og enklere å koble dem i rørledninger for belastningstester. Hvordan gjøre docker-push til register via GitLab CI - se .
Vi tok denne grunnleggende docker-filen for Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Og for Apache JMeter denne:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Du kan lese hvordan vårt kontinuerlige integreringssystem fungerer i artikkelen "'.
Mal og rørledning
Et eksempel på mal for gjennomføring av lasttester er tilgjengelig i prosjektet . I Du kan lese instruksjonene for bruk av malen. I selve malen (fil ) er det merknader om hva hvert trinn er ansvarlig for.
Malen er veldig enkel og demonstrerer de tre stadiene av lasttesting beskrevet i diagrammet ovenfor: forberedelse, testing og publisering av rapporter. Ansvarlig for dette : Forbered, test og rapporter.
- Scene skal brukes til å forhåndskonfigurere testmål eller sjekke tilgjengeligheten. Miljøet for lastkilder trenger ikke å konfigureres, de er forhåndsbygd som docker-bilder og lagt ut i docker-registeret: bare spesifiser ønsket versjon på teststadiet. Men du kan gjenoppbygge dem og lage dine egne modifiserte bilder.
- Scene brukes til å spesifisere belastningskilden, kjøre tester og lagre testartefakter. Du kan velge hvilken som helst lastekilde: Yandex.Tank, Apache JMeter, din egen eller alle sammen. For å deaktivere unødvendige kilder, bare kommentere eller slette jobben. Inngangspunkter for lastkilder:
- Startparametere for Yandex.Tank er spesifisert i .,
- Apache JMeter-oppstartsparametere er spesifisert i filen .
Merk: Sammenstillingskonfigurasjonsmalen brukes til å sette opp interaksjon med CI-systemet og innebærer ikke plassering av testlogikk i det. For tester er inngangspunktet spesifisert, hvor kontrollbash-skriptet er plassert. Metoden for å kjøre tester, generere rapporter og selve testskriptene må implementeres av QA-ingeniører. I demoen, for begge belastningskildene, brukes Yandex-hovedsideforespørselen som den enkleste testen. Skript og testparametere er i katalogen .
- På scenen du må beskrive hvordan du publiserer testresultatene oppnådd på teststadiet til eksterne lagringer, for eksempel til GitLab-sider eller spesielle rapporteringssystemer. GitLab Pages krever at ./public-katalogen ikke er tom og inneholder minst en index.html-fil etter at testene er fullført. Du kan lese om nyansene til GitLab Pages-tjenesten. .
Eksempler på hvordan du eksporterer data:
- fra JMeter til ,
- fra Yandex.Tank til .
Instruksjoner for å legge ut oppsett:
- HTML-statikk i ,
- til InfluxDB og deretter til .
I demoeksemplet ser rørledningen med lasttester og to lastkilder (du kan deaktivere den unødvendige) slik ut:
Apache JMeter kan generere en HTML-rapport selv, så det er mer lønnsomt å lagre den i GitLab-sider ved å bruke standardverktøy. Slik ser Apache JMeter-rapporten ut:
I demoeksemplet for Yandex.Tank vil du bare se i delen for GitLab-sider. Under testing kan tanken lagre resultatene til InfluxDB-databasen, og derfra kan de vises for eksempel i Grafana (konfigurasjon gjøres i filen ). Slik ser Tanks rapport ut i Grafana:
Oppsummering
I artikkelen snakket jeg om begrepet «load testing as a service» (load testing as a service). Hovedideen er å bruke infrastrukturen til forhåndskonfigurerte pooler av lastagenter, docker-bilder av lastkilder, rapporteringssystemer og en pipeline som kombinerer dem i GitLab CI basert på en enkel .gitlab-ci.yml-mal (eksempel ). Alt dette støttes av et lite team av automasjonsingeniører og replikeres på forespørsel fra produktteam. Jeg håper dette vil hjelpe deg med å utarbeide og implementere en lignende ordning i din bedrift. Takk for din oppmerksomhet!
PS Jeg vil si en stor takk til mine kolleger, Sergey Kurbanov og Nikolai Yusev, for teknisk assistanse med implementeringen av konseptet lasttesting som en tjeneste i vårt selskap.
Forfatter: - Stedfortreder Leder for teknologi og utviklingsprosesser (DevOps) i Positive Technologies
Kilde: www.habr.com