Produktu anitzeko software saltzaileek askotan izaten duten arazoetako bat ia talde guztietan ingeniarien konpetentzien bikoizpena da - garatzaileak, probatzaileak eta azpiegitura-administratzaileak. Hau ingeniari garestiei ere aplikatzen zaie - karga proben arloan espezialistak.
Zuzeneko eginkizunak egin beharrean eta esperientzia paregabea erabili karga probatzeko prozesu bat eraikitzeko, metodologia bat aukeratu, metrika optimoak eta autotestak idatzi karga-profilen arabera, ingeniariek sarritan proba-azpiegitura hutsetik zabaldu behar dute, karga tresnak konfiguratu eta txertatu behar dituzte. beraiek CI sistemetan, txostenen jarraipena eta argitalpena ezarri.
Positive Technologies-en erabiltzen ditugun probetan antolakuntza-arazo batzuetarako irtenbideak aurki ditzakezu . Eta honetan, karga-probak CI kanalizazio komun batean integratzeko aukerari buruz hitz egingo dut "karga-probak zerbitzu gisa" kontzeptua erabiliz (karga-probak zerbitzu gisa). CI kanalizazioan nola eta zein docker-irudi erabil daitezkeen ikasiko duzu; nola konektatu karga-iturriak zure CI proiektura eraikitze txantiloi bat erabiliz; karga-probak egiteko eta emaitzak argitaratzeko demo kanalizazioa nolakoa den. Artikulua erabilgarria izan daiteke beren karga-sistemaren arkitekturan pentsatzen ari diren software probak egiteko ingeniarientzat eta automatizazioko ingeniarientzat.
Kontzeptuaren funtsa
Karga-probak zerbitzu gisa kontzeptuak Apache JMeter, Yandex.Tank eta zure esparru propioak etengabeko integrazio sistema arbitrario batean kargatzeko tresnak integratzeko gaitasuna dakar. Demoa GitLab CIrentzat izango da, baina printzipioak komunak dira CI sistema guztietan.
Karga-probak zerbitzu gisa karga-probak egiteko zerbitzu zentralizatua da. Karga-probak agente-multzo dedikatuetan egiten dira, emaitzak GitLab Pages, Influx DB eta Grafana-n edo probak emateko sistemetan argitaratzen dira automatikoki (TestRail, ReportPortal, etab.). Automatizazioa eta eskalatzea ahalik eta errazen inplementatzen dira - GitLab CI proiektuan ohiko gitlab-ci.yml txantiloia gehituz eta parametrizatuz.
Ikuspegi honen abantaila da CI azpiegitura osoa, karga-agenteak, karga-iturrien docker-irudiak, saiakuntza-hodiak eta argitalpen-txostenak automatizazio-sail zentralizatu batek (DevOps ingeniariak) mantentzen dituela, karga-probak egiteko ingeniariek proba-garapenera bideratu ditzaketen bitartean. eta haien emaitzen analisia, azpiegituren gaiak landu gabe.
Deskribapena errazteko, proban dagoen xede-aplikazioa edo zerbitzaria aldez aurretik zabaldu eta konfiguratuta dagoela onartuko dugu (Python, SaltStack, Ansible, etab.-en script automatizatuak erabil daitezke horretarako). Ondoren, zerbitzu gisa karga-probaren kontzeptu osoa hiru fasetan sartzen da: txostenak prestatzea, probatzea, argitaratzea. Diagramari buruzko xehetasun gehiago (argazki guztiak klika daitezke):
Karga-probetan oinarrizko kontzeptuak eta definizioak
Karga-probak egiterakoan, betetzen saiatzen gara , erabili terminologia egokia eta gomendatutako metrika. Karga probetan kontzeptu eta definizio nagusien zerrenda labur bat emango dut.
Karga-agentea - Aplikazioa abiaraziko den makina birtual bat - karga-iturria (Apache JMeter, Yandex.Tank edo norberak idatzitako karga-modulu bat).
Test helburua (helburua) - kargatuko den zerbitzarian instalatutako zerbitzaria edo aplikazioa.
Test eszenatoki (proba kasua) - Parametrotutako urratsen multzoa: erabiltzaileen ekintzak eta ekintza horien aurrean espero diren erreakzioak, sareko eskaera eta erantzun finkoekin, zehaztutako parametroen arabera.
Profila edo karga-plana (profila) - urtean (4.2.4. atala, 43. or.) karga-profilek proba jakin baterako funtsezkoak diren metrika eta proban zehar karga-parametroak aldatzeko aukerak definitzen dituzte. Irudian profilen adibideak ikus ditzakezu.
Proba β aldez aurretik zehaztutako parametro multzoa duen script bat.
Proba-plana (proba-plana) - Proba multzo bat eta karga-profila.
Testran (testrun) - Proba bat exekutatzeko iterazio bat guztiz exekutatutako karga-eszenatokiarekin eta jasotako txostenarekin.
Sare eskaera (eskaera) β Agente batetik helburu batera bidalitako HTTP eskaera.
Sareko erantzuna (erantzuna) β Helburutik agenteari bidalitako HTTP erantzuna.
HTTP erantzun-kodea (HTTP erantzunen egoera) - aplikazio-zerbitzariaren erantzun-kode estandarra.
Transakzio bat eskaera-erantzun ziklo osoa da. Transakzio bat eskaera (eskaera) bidaltzen hasten denetik erantzuna (erantzuna) jasotzen amaitzen den arte zenbatzen da.
Transakzioaren egoera - eskaera-erantzun zikloa arrakastaz burutzea posible den. Ziklo honetan akatsik egon bada, transakzio osoa arrakastatsutzat jotzen da.
Erantzun denbora (latentzia) - eskaera (eskaera) bidaltzen amaitzen denetik erantzuna (erantzuna) jasotzen hasten den denbora.
Kargatu metrikak β karga-zerbitzuaren eta karga-agentearen ezaugarriak karga-probaren prozesuan zehaztutakoak.
Karga-parametroak neurtzeko oinarrizko neurketak
Metodologian erabili eta gomendagarrienetako batzuk (36., 52. or.) neurketak beheko taulan agertzen dira. Agentearen eta xedearen antzeko neurketak lerro berean agertzen dira.
Karga-agentearen neurketak
Kargapean probatzen ari den xede-sistemaren edo aplikazioaren neurketak
Zenbakia vCPU eta memoria RAM,
Disko - Karga-agentearen "burdina" ezaugarriak
CPU, Memoria, Diskoaren erabilera - PUZaren, memoriaren eta diskoen kargaren dinamika
probak egiteko prozesuan. Normalean, ehuneko gisa neurtzen da
erabilgarri dauden gehienezko balioak
sarearen transmisioa (karga-agentean) - errendimendua
zerbitzarian sareko interfazea,
non karga-agentea instalatuta dagoen.
Normalean segundoko bytetan neurtzen da (bps)
sarearen transmisioa(helburuan) - sareko interfazearen banda zabalera
xede zerbitzarian. Normalean segundoko bytetan neurtzen da (bps)
Erabiltzaile birtualak- erabiltzaile birtualen kopurua,
karga-eszenatokiak ezartzea eta
erabiltzailearen benetako ekintzak imitatuz
Erabiltzaile birtualen egoera, Gainditua/Huts egin/Guztira β arrakastaren kopurua eta
erabiltzaile birtualen arrakastarik gabeko egoerak
karga agertokietarako, baita haien kopuru osoa ere.
Oro har, erabiltzaile guztiek osatu ahal izan dutela espero da
karga-profilean zehaztutako zeregin guztiak.
Edozein errore esan nahi du benetako erabiltzaile batek ezin izango duela
konpondu zure arazoa sistemarekin lan egiten duzunean
Eskaerak segundoko (minutu)- segundoko (edo minutuko) sareko eskaera kopurua.
Karga-agente baten ezaugarri garrantzitsu bat zenbat eskaera sor ditzakeen da.
Izan ere, erabiltzaile birtualek aplikaziorako sarbidearen imitazioa da
Erantzunak segundoko (minutu)
- segundoko (edo minutuko) sareko erantzunen kopurua.
Xede-zerbitzuaren ezaugarri garrantzitsu bat: zenbat
Sortu eta bidali galderei erantzunak
kargatzeko agente
HTTP erantzunaren egoeraβ erantzun-kode ezberdinen kopurua
karga-agenteak jasotako aplikazio-zerbitzaritik.
Adibidez, 200 OK dei arrakastatsua esan nahi du,
eta 404 - baliabidea ez zela aurkitu
latentzia (erantzun denbora) - amaieratik denbora
erantzuna (erantzuna) jasotzen hasi aurretik eskaera (eskaera) bidaltzea.
Normalean milisegundotan (ms) neurtzen da
Transakzio erantzuteko denbora- transakzio oso baten denbora,
eskaera-erantzun zikloa amaitzea.
Hau da eskaera (eskaera) bidaltzen hasten den denbora.
erantzuna (erantzuna) jasotzen amaitu arte.
Transakzio-denbora segundotan (edo minututan) neur daiteke
hainbat modutan: kontuan hartu minimoa,
maximoa, batez bestekoa eta, adibidez, 90. pertzentilea.
Irakurketa minimoak eta maximoak muturrekoak dira
sistemaren errendimendu egoera.
Laurogeita hamargarren pertzentilea da gehien erabiltzen dena,
erabiltzaile gehienak erakusten dituenez,
sistemaren errendimenduaren atarian eroso jardutea
Transakzioak segundoko (minutu) - osoa kopurua
segundoko transakzioak (minutu),
hau da, eskaerak zenbat onartu ahal izan zuen eta
eskaerak prozesatu eta erantzunak eman.
Izan ere, hau da sistemaren errendimendua
Transakzioaren egoera , Gainditua / Huts egin / Guztira - zenbakia
arrakastatsuak, arrakastatsuak eta transakzio kopuru osoa.
Benetako erabiltzaileentzat arrakastarik ez dutenentzat
transakzioak benetan esan nahi du
sistema kargapean lan egiteko ezintasuna
Karga-probaren diagrama eskematikoa
Karga-probaren kontzeptua oso erraza da eta hiru fase nagusi ditu, dagoeneko aipatu ditudanak: Prestatu-Test-Txostena, hau da, proba-helburuak prestatzea eta karga-iturrien parametroak ezartzea, ondoren karga-probak gauzatzea eta, amaieran, proba-txostena sortu eta argitaratzea.
Oharrak eskematikoak:
- QA.Tester karga probetan aditua da,
- Target kargapean duen portaera jakin nahi duzun xede aplikazioa da.
Diagramako entitateen, faseen eta urratsen sailkatzailea
Etapak eta urratsak
Zer ari da gertatzen
Zer dago sarreran
Zein da irteera
Prestatu: probak egiteko prestatzeko fasea
LoadParameters
Ezarpena eta hasieratzea
erabiltzailea
kargatzeko parametroak,
metrik aukeraketa eta
proba-plana prestatzea
(kargatu profila)
Aukera pertsonalizatuak
karga-agentearen hasieratzea
Proba plana
Probak egiteko helburua
VM
Hodeiaren hedapena
makina birtualarekin
eskatutako ezaugarriak
Karga-agentearen VM ezarpenak
Automatizaziorako scriptak
VM sortzea
VM-n konfiguratuta dago
Hodei
Bid
OS konfiguratzea eta prestatzea
ingurunerako
karga agente lana
Ingurunearen ezarpenak
karga-agente
Automatizaziorako scriptak
ingurunearen ezarpenak
Prestatutako ingurunea:
OS, zerbitzuak eta aplikazioak,
lanerako beharrezkoak
karga-agente
LoadAgents
Instalazioa, konfigurazioa eta parametrizazioa
kargatzeko agente.
Edo docker irudi bat deskargatuz
aurrez konfiguratutako karga-iturria
Kargatu iturburuko docker irudia
(YAT, JM edo norberak idatzitako markoa)
Ezarpenak
karga-agente
Konfiguratu eta prest
lan karga agentea
Proba: karga-probak egiteko etapa. Iturburuak GitLab CI-rako agente multzo dedikatuetan inplementatutako karga-agenteak dira
Karga
Karga-agentea abiarazten
hautatutako proba-planarekin
eta karga-parametroak
Erabiltzailearen Aukerak
hasieratzeko
karga-agente
Proba plana
Probak egiteko helburua
Exekuzio erregistroak
karga-probak
Sistemaren erregistroak
Helburuen metriketan eta karga-agentean aldaketen dinamika
Exekutatu Agenteak
Agentearen Exekuzioa
probako script asko
arabera
karga-profila
Kargatu agenteen interakzioa
probak egiteko
Proba plana
Probak egiteko helburua
Erregistroak
Log "gordinak" biltzea
karga proban:
kargatu agentearen jarduera-erregistroak,
proba-helburuaren egoera
eta agentea exekutatzen duen VM
Exekuzio erregistroak
karga-probak
Sistemaren erregistroak
Metrics
Probetan zehar neurketa "gordinak" biltzea
Helburuen metriketan aldaketen dinamika
eta karga-agentea
Txostena: proba-txostena prestatzeko fasea
Generator
Bildutako prozesamendua
kargatzeko sistema eta
monitorizazio sistema "gordina"
metrikak eta erregistroak
Txosten baten eraketa urtean
gizakiak irakur daitekeen forma
elementuekin posible
analistak
Exekuzio erregistroak
karga-probak
Sistemaren erregistroak
Metrikoen aldaketen dinamika
helburua eta karga-agentea
Erregistro "gordinak" prozesatu
horretarako egokia den formatuan
kanpoko biltegiratze kargak
Karga estatikoko txostena,
gizakiak irakurtzeko modukoa
Argitaratu
Txostenaren argitalpena
zamari buruz
kanpoko proban
zerbitzua
"Gordina" prozesatua
erregistroak formatu egoki batean
kanpoko aldera deskargatzeko
biltegiak
Kanpoan gordeta
biltegiratzeko txostenak
karga, egokia
giza analisirako
Karga-iturriak CI txantiloian konektatzen
Goazen zati praktikora. Enpresako zenbait proiektutan nolakoa den erakutsi nahi dut karga-probaren kontzeptua zerbitzu gisa ezarri dugu.
Lehenik eta behin, gure DevOps ingeniarien laguntzarekin, GitLab CIn agente multzo bat sortu genuen karga-probak egiteko. Txantiloietan beste batzuekin nahasteko, esate baterako, muntaketa-igerilekuak, etiketak gehitu dizkiegu agente horiei, : zama. Beste edozein etiketa ulergarri erabil ditzakezu. galdetzen dute GitLab CI Runners.
Nola jakin behar den potentzia hardwarearen arabera? Karga-agenteen ezaugarriak - vCPU, RAM eta Disko kopuru nahikoa - Docker, Python (Yandex.Tank-erako), GitLab CI agentea, Java (Apache JMeter-erako) agentean exekutatu behar direla kontuan hartuta kalkula daitezke. . JMeter-en Javarako, gutxienez 512 MB RAM erabiltzea gomendatzen da eta, goiko muga gisa, .
Horrela, gure esperientzian oinarrituta, gutxienez 4 vCPU, 4 GB RAM, 60 GB SSD erabiltzea gomendatzen dugu karga-agenteetarako. Sareko txartelaren errendimendua karga-profilaren eskakizunen arabera zehazten da.
Bi karga iturri erabiltzen ditugu batez ere: Apache JMeter eta Yandex.Tank docker irudiak.
Yandex-en kode irekiko tresna da karga probak egiteko. Bere arkitektura modularra Phantom-en errendimendu handiko hitetan oinarritutako HTTP eskaera-sorgailu asinkronoan oinarritzen da. Deposituak proban dagoen zerbitzariaren baliabideen jarraipena du SSH protokoloaren bidez, proba automatikoki geldi dezake baldintza zehatzetan, emaitzak bistaratu ditzake kontsolan eta grafiko moduan, zure moduluak konektatu ditzakezu. horri funtzionaltasuna zabaltzeko. Bide batez, tankea oraindik ohikoa ez zenean erabili genuen. artikuluan "Β» 2013an harekin karga-probak nola egin genituen azaltzen duen istorioa irakur dezakezu gure konpainiaren produktuetako bat da.
Apache-ren kode irekiko karga probatzeko tresna da. Berdin erabil daiteke web aplikazio estatikoak zein dinamikoak probatzeko. JMeterrek aplikazioekin elkarreragiteko protokolo eta modu ugari onartzen ditu: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etab.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) eta IMAP(S), datu-baseek JDBC bidez, shell komandoak exekutatu ditzakete eta Java objektuekin lan egin dezakete. JMeterrek IDE bat du proba-planak sortzeko, arazketa eta exekutatzeko. Komando-lerroko funtzionamendurako CLI bat ere badago Java bateragarria den edozein sistema eragiletan (Linux, Windows, Mac OS X). Tresnak HTML proba-txosten bat sor dezake dinamikoki.
Gure enpresan erabiltzeko erraztasunagatik, probalariek beraiek ingurunea aldatzeko eta gehitzeko duten gaitasunagatik, GitLab CI-n karga-iturrien docker-irudien eraikuntzak egin ditugu barnean argitaratuz. . Horri esker, karga probak egiteko kanalizazioetan konektatzea azkarrago eta errazagoa da. Nola egin docker push erregistrora GitLab CI bidez - ikusi .
Yandex.Tank-erako oinarrizko docker fitxategi hau hartu dugu:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Eta Apache JMeter-erako hau:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Gure etengabeko integrazio sistemak nola funtzionatzen duen irakur dezakezu " artikuluan'.
Txantiloia eta kanalizazioa
Karga-probak egiteko txantiloi baten adibide bat dago eskuragarri proiektuan . Urtean Txantiloia erabiltzeko argibideak irakur ditzakezu. Txantiloian bertan (fitxategia ) urrats bakoitzari buruzko oharrak daude.
Txantiloia oso erraza da eta goiko diagraman deskribatutako karga-probaren hiru faseak erakusten ditu: txostenak prestatzea, probatzea eta argitaratzea. Honen arduraduna : Prestatu, probatu eta jakinarazi.
- Etapa proba-helburuak aldez aurretik konfiguratzeko edo haien erabilgarritasuna egiaztatzeko erabili behar da. Karga-iturburuen ingurunea ez da konfiguratu beharrik, docker irudi gisa aldez aurretik eraikita daude eta docker erregistroan argitaratzen dira: zehaztu nahi den bertsioa Proba fasean. Baina horiek berreraiki ditzakezu eta zure irudi aldatuak egin ditzakezu.
- Etapa karga-iturria zehazteko, probak exekutatzeko eta proba-artefaktuak gordetzeko erabiltzen da. Edozein karga-iturri aukeratu dezakezu: Yandex.Tank, Apache JMeter, zurea edo denak batera. Behar ez diren iturriak desgaitzeko, besterik gabe iruzkin ezazu edo ezabatu lana. Karga iturrietarako sarrera-puntuak:
- Yandex.Tank-en abiarazteko parametroak .,
- Apache JMeter abiarazteko parametroak fitxategian zehazten dira .
Oharra: muntaia konfiguratzeko txantiloia CI sistemarekin elkarrekintza konfiguratzeko erabiltzen da eta ez du esan nahi proba-logika bertan jartzea. Probetarako, sarrera-puntua zehazten da, non dagoen kontrol bash script-a. Probak egiteko metodoa, txostenak sortzeko eta probaren script-ak berak inplementatu behar dituzte QA ingeniariek. Demoan, karga-iturburu bietarako, Yandex orri nagusiaren eskaera proba errazena bezala erabiltzen da. Scriptak eta proba-parametroak direktorioa daude .
- Agertokian Proba fasean lortutako proben emaitzak kanpoko biltegietara nola argitaratu deskribatu behar duzu, adibidez, GitLab orrietara edo txosten berezietarako sistema berezietara. GitLab Pages-ek ./public direktorioa hutsik ez egotea eta gutxienez index.html fitxategi bat edukitzea eskatzen du probak amaitu ondoren. GitLab Pages zerbitzuaren Γ±abardurak irakur ditzakezu. .
Datuak esportatzeko moduaren adibideak:
- JMeter-etik ,
- Yandex-etik.Tank to .
Konfiguratzeko argibideak argitaratzea:
- HTML estatikoak barne ,
- InfluxDBra eta gero .
Demo adibidean, karga-probak eta bi karga-iturri dituen kanalizazioak (alferrikakoa desgaitu dezakezu) itxura hau du:
Apache JMeter-ek HTML txosten bat sor dezake bera, beraz, errentagarriagoa da GitLab Pages-en gordetzea tresna estandarrak erabiliz. Hau da Apache JMeter txostenaren itxura:
Yandex.Tank-en demoaren adibidean, bakarrik ikusiko duzu GitLab orrialdeen atalean. Probetan zehar, Tank-ek emaitzak InfluxDB datu-basean gorde ditzake, eta hortik bistaratu daitezke, adibidez, Grafanan (konfigurazioa fitxategian egiten da. ). Honela ikusten da Tank-en txostenak Grafanan:
Laburpena
Artikuluan, "load testing as a service" kontzeptuari buruz hitz egin nuen (load testing as a service). Ideia nagusia karga-agenteen aurrez konfiguratutako multzoen azpiegitura, karga-iturrien docker-irudiak, txosten-sistemak eta GitLab CI-n konbinatzen dituen kanalizazio bat erabiltzea da .gitlab-ci.yml txantiloi sinple batean oinarrituta (adibidea). ). Hori guztia automatizazio-ingeniari talde txiki batek onartzen du eta produktu-taldeek hala eskatuta errepikatzen dute. Espero dut honek zure enpresan antzeko eskema bat prestatzen eta ezartzen lagunduko dizula. Eskerrik asko arretagatik!
PS Eskerrik asko nire lankideei, Sergey Kurbanov eta Nikolai Yusev, gure enpresan karga-probaren kontzeptua zerbitzu gisa ezartzeko laguntza teknikoagatik.
Egilea: - Diputatua Positive Technologies-ko Teknologia eta Garapen Prozesuen (DevOps) arduraduna
Iturria: www.habr.com