Een van die probleme waarmee verskaffers van multiproduksagteware dikwels te kampe het, is die duplisering van die bevoegdhede van ingenieurs – ontwikkelaars, toetsers en infrastruktuuradministrateurs – in byna elke span. Dit geld ook vir duur ingenieurs – spesialiste op die gebied van lastoetsing.
In plaas daarvan om hul direkte pligte uit te voer en hul unieke ervaring te gebruik om 'n lastoetsproses te bou, 'n metodologie, optimale statistieke te kies en outotoetse in ooreenstemming met lasprofiele te skryf, moet ingenieurs dikwels toetsinfrastruktuur van nuuts af ontplooi, laaigereedskap opstel en dit insluit hulself in CI-stelsels, monitering en publikasie van verslae opstel.
U kan oplossings vind vir sommige organisatoriese probleme in toetse wat ons by Positive Technologies in gebruik . En in hierdie een sal ek praat oor die moontlikheid om lastoetse in 'n algemene CI-pyplyn te integreer deur die konsep van "vragtoetsing as 'n diens" (vragtoets as 'n diens) te gebruik. Jy sal leer hoe en watter docker-beelde van laaibronne in die CI-pyplyn gebruik kan word; hoe om vragbronne aan jou CI-projek te koppel deur 'n bousjabloon te gebruik; hoe die demo-pyplyn lyk om vragtoetse uit te voer en die resultate te publiseer. Die artikel kan nuttig wees vir sagteware-toetsingenieurs en outomatiseringsingenieurs in CI wat oor die argitektuur van hul vragstelsel dink.
Die essensie van die konsep
Die konsep van lastoetsing as 'n diens impliseer die vermoë om lasgereedskap Apache JMeter, Yandex.Tank en jou eie raamwerke te integreer in 'n arbitrêre deurlopende integrasiestelsel. Die demonstrasie sal vir GitLab CI wees, maar die beginsels is algemeen vir alle CI-stelsels.
Lastoetsing as 'n diens is 'n gesentraliseerde diens vir vragtoetsing. Beladingstoetse word in toegewyde agentpoele uitgevoer, die resultate word outomaties gepubliseer in GitLab Pages, Influx DB en Grafana of in toetsverslagdoeningstelsels (TestRail, ReportPortal, ens.). Outomatisering en skaal word so eenvoudig as moontlik geïmplementeer - deur die gewone gitlab-ci.yml-sjabloon in die GitLab CI-projek by te voeg en te parameteriseer.
Die voordeel van hierdie benadering is dat die hele CI-infrastruktuur, vragagente, dokbeelde van vragbronne, toetspyplyne en publiseringsverslae deur 'n gesentraliseerde outomatiseringsafdeling (DevOps-ingenieurs) onderhou word, terwyl lastoetsingenieurs hul pogings op toetsontwikkeling kan fokus en ontleding van hul resultate, sonder om met infrastruktuurkwessies te handel.
Vir die eenvoud van beskrywing, sal ons aanvaar dat die teikentoepassing of bediener wat getoets word reeds ontplooi en vooraf gekonfigureer is (outomatiese skrifte in Python, SaltStack, Ansible, ens. kan hiervoor gebruik word). Dan pas die hele konsep van vragtoetsing as 'n diens in drie fases: voorbereiding, toetsing, publikasie van verslae. Meer besonderhede oor die diagram (alle prente is klikbaar):
Basiese konsepte en definisies in lastoetsing
Wanneer ons vragtoetse uitvoer, probeer ons om te voldoen aan , gebruik die toepaslike terminologie en aanbevole maatstawwe. Ek sal 'n kort lys gee van die hoofbegrippe en definisies in lastoetsing.
Laai agent - 'n virtuele masjien waarop die toepassing geloods sal word - die laaibron (Apache JMeter, Yandex.Tank of 'n selfgeskrewe laaimodule).
Toetsdoelwit (teiken) - bediener of toepassing geïnstalleer op die bediener wat onderhewig sal wees aan laai.
Toetsscenario (toetsgeval) - 'n stel geparameteriseerde stappe: gebruikeraksies en verwagte reaksies op hierdie aksies, met vaste netwerkversoeke en -antwoorde, afhangende van die gespesifiseerde parameters.
Profiel of laaiplan (profiel) - in (Afdeling 4.2.4, p. 43) lasprofiele definieer maatstawwe wat krities is vir 'n bepaalde toets en opsies om lasparameters tydens die toets te verander. U kan voorbeelde van profiele in die figuur sien.
Toets - 'n skrip met 'n voorafbepaalde stel parameters.
Toetsplan (toetsplan) - 'n stel toetse en 'n lasprofiel.
Testran (toetsrun) - een herhaling van die uitvoer van een toets met 'n volledig uitgevoer las scenario en die ontvang verslag.
Netwerkversoek (versoek) — 'n HTTP-versoek wat van 'n agent na 'n teiken gestuur is.
Netwerkreaksie (reaksie) — 'n HTTP-reaksie wat vanaf die teiken na die agent gestuur is.
HTTP-reaksiekode (HTTP-reaksiestatus) - standaardresponskode vanaf die toepassingbediener.
'n Transaksie is 'n volledige versoek-reaksie-siklus. 'n Transaksie word getel vanaf die begin van die stuur van 'n versoek (versoek) tot die voltooiing van die ontvangs van 'n antwoord (antwoord).
Transaksie status - of dit moontlik was om die versoek-reaksie-siklus suksesvol te voltooi. As daar enige fout in hierdie siklus was, word die hele transaksie as onsuksesvol beskou.
Reaksietyd (latency) - die tyd vanaf die einde van die stuur van 'n versoek (versoek) tot die begin van die ontvangs van 'n antwoord (antwoord).
Laai maatstawwe — die kenmerke van die gelaaide diens en die vragmiddel wat in die proses van vragtoetsing bepaal is.
Basiese statistieke vir die meting van lasparameters
Sommige van die mees algemeen gebruik en aanbeveel in die metodologie (p. 36, 52) die metrieke word in die tabel hieronder getoon. Soortgelyke maatstawwe vir agent en teiken word op dieselfde lyn gelys.
Metrieke vir die vragmiddel
Metrieke van die teikenstelsel of toepassing wat onder las getoets word
Number vCPU en geheue RAM,
Skyf - "yster" eienskappe van die vragmiddel
CPU, Geheue, skyfgebruik - dinamika van SVE, geheue en skyflaai
in die proses van toetsing. Gewoonlik gemeet as 'n persentasie van
maksimum beskikbare waardes
netwerk deurvoer (op vragmiddel) - deurset
netwerkkoppelvlak op die bediener,
waar die vragmiddel geïnstalleer is.
Gewoonlik gemeet in grepe per sekonde (bps)
netwerk deurvoer(op teiken) - netwerk koppelvlak bandwydte
op die teikenbediener. Gewoonlik gemeet in grepe per sekonde (bps)
Virtuele gebruikers- die aantal virtuele gebruikers,
implementering van las scenario's en
ware gebruikershandelinge na te boots
Virtuele gebruikers status, Slaag/Misluk/Totaal — aantal suksesvolle en
onsuksesvolle statusse van virtuele gebruikers
vir vrag scenario's, sowel as hul totale aantal.
Daar word oor die algemeen verwag dat alle gebruikers in staat was om te voltooi
al jou take gespesifiseer in die laai profiel.
Enige fout sal beteken dat 'n regte gebruiker dit nie sal kan doen nie
los jou probleem op wanneer jy met die stelsel werk
Versoeke per sekonde (minuut)- die aantal netwerkversoeke per sekonde (of minuut).
'n Belangrike kenmerk van 'n vragagent is hoeveel versoeke dit kan genereer.
Trouens, dit is 'n nabootsing van toegang tot die toepassing deur virtuele gebruikers
Antwoorde per sekonde (minuut)
- die aantal netwerkreaksies per sekonde (of minuut).
'n Belangrike kenmerk van die teikendiens: hoeveel
genereer en stuur antwoorde op navrae met
laai agent
HTTP-reaksiestatus— aantal verskillende reaksiekodes
vanaf die toepassingsbediener wat deur die vragagent ontvang is.
Byvoorbeeld, 200 OK beteken 'n suksesvolle oproep,
en 404 - dat die hulpbron nie gevind is nie
latency (reaksietyd) - tyd vanaf die einde
die stuur van 'n versoek (versoek) voordat 'n antwoord (reaksie) begin ontvang word.
Gewoonlik gemeet in millisekondes (ms)
Transaksie reaksie tyd- tyd van een volledige transaksie,
voltooiing van die versoek-reaksie-siklus.
Dit is die tyd vanaf die begin van die stuur van die versoek (versoek)
tot voltooiing van die ontvangs van 'n antwoord (respons).
Transaksietyd kan in sekondes (of minute) gemeet word
op verskeie maniere: oorweeg die minimum,
maksimum, gemiddeld en byvoorbeeld die 90ste persentiel.
Die minimum en maksimum lesings is uiters
stelsel prestasie status.
Die negentigste persentiel is die algemeenste gebruik,
soos dit die meeste van die gebruikers wys,
werk gemaklik op die drumpel van stelselwerkverrigting
Transaksies per sekonde (minuut) - die aantal voltooi
transaksies per sekonde (minuut),
dit wil sê hoeveel die aansoek kon aanvaar en
verwerk versoeke en reik antwoorde uit.
Trouens, dit is die deurset van die stelsel
Transaksie status , Slaag / Misluk / Totaal - getal
suksesvol, onsuksesvol en die totale aantal transaksies.
Vir regte gebruikers onsuksesvol
die transaksie sal eintlik beteken
onvermoë om met die stelsel onder las te werk
Laai toets skematiese diagram
Die konsep van lastoetsing is baie eenvoudig en bestaan uit drie hooffases, wat ek reeds genoem het: Berei-Toets-Verslag voor, dit wil sê om toetsdoelwitte voor te berei en parameters vir lasbronne op te stel, dan lastoetse uit te voer en aan die einde 'n toetsverslag te genereer en te publiseer.
Skematiese notas:
- QA.Tester is 'n kenner in vragtoetsing,
- Target is die teikentoepassing waarvoor u sy gedrag onder lading wil weet.
Klassifiseerder van entiteite, stadiums en stappe in die diagram
Stadiums en stappe
Wat is besig om te gebeur
Wat is by die ingang
Wat is die uitset
Berei voor: voorbereiding stadium vir toetsing
Laai Parameters
Opstelling en inisialisering
gebruiker
laai parameters,
keuse van maatstawwe en
toetsplan voorbereiding
(laai profiel)
Pasgemaakte opsies vir
laai agent inisialisering
Toets plan
Doel van toetsing
VM
Wolk-ontplooiing
virtuele masjien met
vereiste eienskappe
VM instellings vir laai agent
Outomatisering skrifte vir
VM skepping
VM gekonfigureer in
wolk
Stuur
OS opstelling en voorbereiding
omgewing vir
laai agent werk
Omgewing instellings vir
laai agent
Outomatisering skrifte vir
omgewing instellings
Voorbereide omgewing:
OS, dienste en toepassings,
nodig vir werk
laai agent
LoadAgents
Installasie, konfigurasie en parameterisering
laai agent.
Of die aflaai van 'n docker-prent vanaf
vooraf gekonfigureerde laaibron
Laai brondoker-beeld
(YAT, JM of selfgeskrewe raamwerk)
Instellings
laai agent
Opgestel en gereed
vrag agent te werk
Toets: stadium van uitvoering van lastoetse. Bronne is vragagente wat in toegewyde agentpoele vir GitLab CI ontplooi word
vrag
Begin die Load Agent
met geselekteerde toetsplan
en laai parameters
Gebruikersopsies
vir inisialisering
laai agent
Toets plan
Doel van toetsing
Uitvoering logs
lastoetse
Stelsel logs
Dinamika van veranderinge in doelwitmaatstawwe en vragagent
Begin Agente
Agent Uitvoering
hope toetsskrifte
in ooreenstemming met
laai profiel
Laai Agent Interaksie
vir die doel van toetsing
Toets plan
Doel van toetsing
Logs
Versameling van "rou" logs
tydens lastoetsing:
laai agent aktiwiteit rekords,
toestand van die toetsteiken
en die VM wat die agent bestuur
Uitvoering logs
lastoetse
Stelsel logs
Statistieke
Versamel "rou" statistieke tydens toetsing
Dinamika van veranderinge in doelwitmaatstawwe
en laai agent
Verslag: toetsverslag voorbereiding stadium
Generator
Verwerking ingesamel
laai stelsel en
moniteringstelsel "rou"
metrieke en logs
Vorming van 'n verslag in
mens leesbare vorm
moontlik met elemente
ontleders
Uitvoering logs
lastoetse
Stelsel logs
Dinamika van veranderinge in metrieke
teiken en laai agent
Verwerkte "rou" logs
in 'n formaat wat geskik is vir
oplaai na eksterne berging
Statiese las verslag,
mens-leesbaar
Publiseer
Publikasie van die verslag
oor vrag
toets in eksterne
diens
"rou" verwerk
logs in 'n geskikte formaat
vir aflaai na buite
bewaarplekke
Gestoor in ekstern
stoor verslae oor
laai, geskik
vir menslike analise
Koppel lasbronne in 'n CI-sjabloon
Kom ons gaan aan na die praktiese deel. Ek wil wys hoe op sommige projekte in die maatskappy ons het die konsep van lastoetsing as 'n diens geïmplementeer.
Eerstens, met die hulp van ons DevOps-ingenieurs, het ons 'n toegewyde poel agente in GitLab CI geskep om lastoetse uit te voer. Om hulle nie in sjablone met ander te verwar nie, soos samestellingpoele, het ons etikette by hierdie agente gevoeg, :laai. Jy kan enige ander verstaanbare etikette gebruik. Hulle vra GitLab CI Hardlopers.
Hoe om die vereiste krag deur hardeware uit te vind? Die eienskappe van laai agente - 'n voldoende aantal vCPU, RAM en skyf - kan bereken word gebaseer op die feit dat Docker, Python (vir Yandex.Tank), GitLab CI-agent, Java (vir Apache JMeter) op die agent moet loop . Vir Java onder JMeter word dit ook aanbeveel om 'n minimum van 512 MB RAM te gebruik en, as 'n boonste limiet, .
Dus, gebaseer op ons ervaring, beveel ons aan om ten minste 4 vCPU's, 4 GB RAM, 60 GB SSD vir laai agente te gebruik. Die deurset van die netwerkkaart word bepaal op grond van die vereistes van die lasprofiel.
Ons gebruik hoofsaaklik twee laaibronne - Apache JMeter en Yandex.Tank docker beelde.
is 'n oopbronhulpmiddel van Yandex vir vragtoetsing. Sy modulêre argitektuur is gebaseer op Phantom se hoëprestasie asinchrone treffergebaseerde HTTP-versoekgenerator. Die tenk het 'n ingeboude monitering van die hulpbronne van die bediener wat getoets word via die SSH-protokol, kan die toets outomaties onder bepaalde omstandighede stop, kan die resultate beide in die konsole en in die vorm van grafieke vertoon, u kan u modules koppel daaraan om funksionaliteit uit te brei. Terloops, ons het die Tank gebruik toe dit nog nie hoofstroom was nie. In die artikel "» jy kan die storie lees van hoe ons lastoetsing daarmee in 2013 uitgevoer het is een van ons maatskappy se produkte.
is 'n oopbron-ladingstoetsinstrument van Apache. Dit kan ewe goed gebruik word vir die toets van beide statiese en dinamiese webtoepassings. JMeter ondersteun 'n groot aantal protokolle en maniere om met toepassings te kommunikeer: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ens.), SOAP / REST Webdienste, FTP, TCP, LDAP, SMTP(S), POP3( S) ) en IMAP(S), databasisse via JDBC, kan dopopdragte uitvoer en met Java-voorwerpe werk. JMeter het 'n IDE vir die skep, ontfouting en uitvoering van toetsplanne. Daar is ook 'n CLI vir opdragreëlwerking op enige Java-versoenbare bedryfstelsel (Linux, Windows, Mac OS X). Die instrument kan dinamies 'n HTML-toetsverslag genereer.
Vir gemak van gebruik binne ons maatskappy, vir die vermoë van die toetsers self om die omgewing te verander en by te voeg, het ons bouwerk gemaak van koppelbeelde van laaibronne op GitLab CI met publikasie aan die interne . Dit maak dit vinniger en makliker om hulle in pypleidings vir lastoetse te verbind. Hoe om docker push na register te doen via GitLab CI - sien .
Ons het hierdie basiese docker-lêer vir Yandex.Tank geneem:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]En vir Apache JMeter hierdie een:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]U kan lees hoe ons deurlopende integrasiestelsel werk in die artikel "".
Sjabloon en pyplyn
'n Voorbeeld van 'n sjabloon vir die uitvoer van lastoetse is in die projek beskikbaar . In U kan die instruksies vir die gebruik van die sjabloon lees. In die sjabloon self (lêer ) daar is notas oor waarvoor elke stap verantwoordelik is.
Die sjabloon is baie eenvoudig en demonstreer die drie stadiums van lastoetsing wat in die diagram hierbo beskryf word: voorbereiding, toetsing en publisering van verslae. Verantwoordelik hiervoor : Berei voor, toets en rapporteer.
- Verhoog moet gebruik word om toetsteikens vooraf op te stel of om hul beskikbaarheid na te gaan. Die omgewing vir laaibronne hoef nie gekonfigureer te word nie, hulle is vooraf gebou as koppelbeelde en geplaas in die koppelaarregister: spesifiseer net die verlangde weergawe in die toetsstadium. Maar jy kan hulle herbou en jou eie gewysigde beelde maak.
- Verhoog gebruik om die vragbron te spesifiseer, toetse uit te voer en toetsartefakte te stoor. Jy kan enige laaibron kies: Yandex.Tank, Apache JMeter, jou eie, of almal saam. Om onnodige bronne te deaktiveer, maak net kommentaar of vee die taak uit. Toegangspunte vir vragbronne:
- Beginparameters vir Yandex.Tank word in die .,
- Apache JMeter-opstartparameters word in die lêer gespesifiseer .
Let wel: Die samestelling konfigurasie sjabloon word gebruik om interaksie met die CI stelsel op te stel en impliseer nie plasing van toetslogika daarin nie. Vir toetse word die toegangspunt gespesifiseer, waar die kontrole bash script geleë is. Die metode om toetse uit te voer, verslae te genereer en die toetsskrifte self moet deur QA-ingenieurs geïmplementeer word. In die demonstrasie, vir beide laaibronne, word die Yandex-hoofbladversoek as die eenvoudigste toets gebruik. Skripte en toetsparameters is in die gids .
- Op die stadium jy moet beskryf hoe om die toetsresultate wat in die toetsstadium verkry is, na eksterne bergings te publiseer, byvoorbeeld na GitLab Pages of spesiale verslagdoeningstelsels. GitLab Pages vereis dat die ./public-gids nie-leeg is nie en ten minste 'n index.html-lêer bevat nadat die toetse voltooi is. U kan lees oor die nuanses van die GitLab Pages-diens. .
Voorbeelde van hoe om data uit te voer:
- van JMeter na ,
- van Yandex.Tank aan .
Plaas opstelling instruksies:
- HTML-statistieke in ,
- na InfluxDB en dan na .
In die demo-voorbeeld lyk die pyplyn met lastoetse en twee lasbronne (jy kan die onnodige een deaktiveer) so:
Apache JMeter kan self 'n HTML-verslag genereer, so dit is meer winsgewend om dit in GitLab-bladsye te stoor met behulp van standaardnutsgoed. Dit is hoe die Apache JMeter-verslag lyk:
In die demo-voorbeeld vir Yandex.Tank, sal jy net sien in die afdeling vir GitLab-bladsye. Tydens toetsing kan die tenk die resultate in die InfluxDB-databasis stoor, en van daar af kan dit byvoorbeeld in Grafana vertoon word (konfigurasie word in die lêer gedoen ). Só lyk Tank se verslag in Grafana:
Opsomming
In die artikel het ek gepraat oor die konsep van "load testing as a service" (load testing as a service). Die hoofgedagte is om die infrastruktuur van vooraf gekonfigureerde poele vragagente, koppelaarbeelde van vragbronne, verslagdoeningstelsels en 'n pyplyn wat hulle in GitLab CI kombineer, te gebruik, gebaseer op 'n eenvoudige .gitlab-ci.yml-sjabloon (voorbeeld) ). Dit alles word ondersteun deur 'n klein span outomatiseringsingenieurs en herhaal op versoek van produkspanne. Ek hoop dit sal jou help met die voorbereiding en implementering van 'n soortgelyke skema in jou maatskappy. Dankie vir jou aandag!
NS Ek wil baie dankie sê aan my kollegas, Sergey Kurbanov en Nikolai Yusev, vir tegniese bystand met die implementering van die konsep van lastoetsing as 'n diens in ons maatskappy.
Skrywer: - Adjunk Hoof van Tegnologieë en Ontwikkelingsprosesse (DevOps) by Positive Technologies
Bron: will.com