Unu el la problemoj, kiujn ofte alfrontas multiproduktaj softvarvendistoj, estas la duobligo de la kompetentecoj de inĝenieroj - programistoj, testistoj kaj infrastrukturaj administrantoj - ĉe preskaŭ ĉiu teamo. Ĉi tio validas ankaŭ por multekostaj inĝenieroj - specialistoj en la kampo de ŝarĝtestado.
Anstataŭ plenumi siajn rektajn devojn kaj uzi sian unikan sperton por konstrui ŝarĝan testan procezon, elekti metodaron, optimumajn metrikojn kaj verki aŭtotestojn konforme al ŝarĝaj profiloj, inĝenieroj ofte devas deploji testan infrastrukturon de nulo, agordi ŝarĝajn ilojn kaj enkonstrui ilin. sin en CI-sistemoj, starigis monitoradon kaj publikigon de raportoj.
Vi povas trovi solvojn al iuj organizaj problemoj en testado, kiun ni uzas ĉe Positive Technologies en . Kaj en ĉi tiu, mi parolos pri la ebleco integri ŝarĝtestojn en komuna CI-dukto uzante la koncepton de "ŝarĝo-testado kiel servo" (ŝarĝo-testado kiel servo). Vi lernos kiel kaj kiuj docker-bildoj de ŝarĝfontoj povas esti uzataj en la CI-dukto; kiel konekti ŝarĝajn fontojn al via CI-projekto uzante konstruan ŝablonon; kiel aspektas la demo-dukto por ruli ŝarĝtestojn kaj publikigi la rezultojn. La artikolo povas esti utila por inĝenieroj pri testado de programaro kaj aŭtomatigaj inĝenieroj en CI, kiuj pensas pri la arkitekturo de sia ŝarĝsistemo.
La esenco de la koncepto
La koncepto de ŝarĝtestado kiel servo implicas la kapablon integri ŝarĝajn ilojn Apache JMeter, Yandex.Tank kaj viajn proprajn kadrojn en arbitran kontinuan integrigan sistemon. La demo estos por GitLab CI, sed la principoj estas komunaj al ĉiuj CI-sistemoj.
Ŝarĝtestado kiel servo estas centralizita servo por ŝarĝtestado. Ŝarĝtestoj estas aranĝitaj en dediĉitaj agentaj naĝejoj, la rezultoj estas publikigitaj aŭtomate en GitLab Pages, Influx DB kaj Grafana aŭ en testaj raportaj sistemoj (TestRail, ReportPortal, ktp.). Aŭtomatigo kaj skalo estas efektivigitaj kiel eble plej simple - per aldonado kaj parametrigado de la kutima gitlab-ci.yml ŝablono en la GitLab CI-projekto.
La avantaĝo de ĉi tiu aliro estas, ke la tuta CI-infrastrukturo, ŝarĝaj agentoj, docker-bildoj de ŝarĝfontoj, testaj duktoj kaj eldonaj raportoj estas konservitaj fare de centralizita aŭtomatiga fako (DevOps-inĝenieroj), dum ŝarĝtestantaj inĝenieroj povas koncentri siajn klopodojn sur testa disvolviĝo. kaj analizo de iliaj rezultoj, sen traktado de infrastrukturaj aferoj.
Por simpleco de priskribo, ni supozos, ke la cela aplikaĵo aŭ servilo sub testo jam estis deplojita kaj agordita anticipe (aŭtomatigitaj skriptoj en Python, SaltStack, Ansible, ktp. povas esti uzataj por tio). Tiam la tuta koncepto de ŝarĝtestado kiel servo konvenas en tri stadiojn: preparado, testado, publikigo de raportoj. Pliaj detaloj pri la diagramo (ĉiuj bildoj estas klakeblaj):
Bazaj konceptoj kaj difinoj en ŝarĝtestado
Farante ŝarĝtestojn, ni provas aliĝi al , uzu la taŭgan terminologion kaj rekomenditajn metrikojn. Mi donos mallongan liston de la ĉefaj konceptoj kaj difinoj en ŝarĝtestado.
Ŝarĝo agento - virtuala maŝino sur kiu la aplikaĵo estos lanĉita - la ŝarĝfonto (Apache JMeter, Yandex.Tank aŭ memskribita ŝarĝmodulo).
Testa celo (celo) - servilo aŭ aplikaĵo instalita sur la servilo, kiu estos ŝarĝebla.
Testa scenaro (testkazo) - aro de parametrigitaj paŝoj: uzant-agoj kaj atendataj reagoj al ĉi tiuj agoj, kun fiksaj retaj petoj kaj respondoj, depende de la specifitaj parametroj.
Profilo aŭ ŝarĝa plano (profilo) - en (Sekcio 4.2.4, p. 43) ŝarĝprofiloj difinas metrikojn kiuj estas kritikaj por speciala testo kaj opcioj por ŝanĝi ŝarĝajn parametrojn dum la testo. Vi povas vidi ekzemplojn de profiloj en la figuro.
Testo — skripto kun antaŭfiksita aro de parametroj.
Testplano (testplano) - aro da testoj kaj ŝarĝa profilo.
Testran (testrun) - unu ripeto de ekzekuto de unu testo kun plene efektivigita ŝarĝoscenaro kaj la ricevita raporto.
Reta peto (peto) — HTTP-peto sendita de agento al celo.
Reta respondo (respondo) — HTTP-respondo sendita de la celo al la agento.
HTTP responda kodo (HTTP responds status) - norma responda kodo de la aplika servilo.
Transakcio estas kompleta peto-responda ciklo. Transakcio estas kalkulita de la komenco de sendo de peto (peto) ĝis la kompletigo de ricevado de respondo (respondo).
Transakcia stato - ĉu eblis sukcese plenumi la peto-respondan ciklon. Se estis iu eraro en ĉi tiu ciklo, tiam la tuta transakcio estas konsiderata malsukcesa.
Responda tempo (latenteco) - la tempo de la fino de sendo de peto (peto) ĝis la komenco de ricevado de respondo (respondo).
Ŝarĝu metrikojn - la karakterizaĵoj de la ŝarĝita servo kaj la ŝarĝa agento determinitaj en la procezo de ŝarĝo-testado.
Bazaj metrikoj por mezuri ŝarĝajn parametrojn
Kelkaj el la plej ofte uzataj kaj rekomenditaj en la metodiko (p. 36, 52) la metrikoj estas montritaj en la suba tabelo. Similaj metrikoj por agento kaj celo estas listigitaj sur la sama linio.
Metriko por la ŝarĝagento
Metrikoj de la cela sistemo aŭ aplikaĵo estanta testitaj sub ŝarĝo
Nombro de vCPU kaj memoro RAM,
disko - "feraj" trajtoj de la ŝarĝa agento
CPU, Memoro, Diska uzado - dinamiko de CPU, memoro kaj disko-ŝarĝado
en la procezo de testado. Kutime mezurita kiel procento de
maksimumaj disponeblaj valoroj
reto trairo (sur ŝarĝa agento) - trafluo
reto interfaco sur la servilo,
kie la ŝarĝagento estas instalita.
Kutime mezurite en bajtoj je sekundo (bps)
reto trairo(sur celo) - retinterfaco bendolarĝo
sur la cela servilo. Kutime mezurite en bajtoj je sekundo (bps)
Virtualaj uzantoj- la nombro da virtualaj uzantoj,
efektivigante ŝarĝoscenarojn kaj
imitante realajn uzantajn agojn
Statuso de virtualaj uzantoj, Passed/Failed/Total — nombro de sukcesaj kaj
malsukcesaj statusoj de virtualaj uzantoj
por ŝarĝoscenaroj, same kiel ilia totala nombro.
Ĝenerale estas atendite, ke ĉiuj uzantoj povis kompletigi
ĉiuj viaj taskoj specifitaj en la ŝarĝa profilo.
Ajna eraro signifos, ke vera uzanto ne povos
solvu vian problemon kiam vi laboras kun la sistemo
Petoj je sekundo (minuto)- la nombro da retaj petoj por sekundo (aŭ minuto).
Grava karakterizaĵo de ŝarĝa agento estas kiom da petoj ĝi povas generi.
Fakte, ĉi tio estas imito de aliro al la aplikaĵo de virtualaj uzantoj
Respondoj je sekundo (minuto)
- la nombro da retaj respondoj je sekundo (aŭ minuto).
Grava karakterizaĵo de la cela servo: kiom
generi kaj sendi respondojn al demandoj kun
ŝarĝa agento
HTTP-responda stato— nombro da malsamaj respondkodoj
de la aplika servilo ricevita de la ŝarĝa agento.
Ekzemple, 200 OK signifas sukcesan vokon,
kaj 404 - ke la rimedo ne estis trovita
atendotempo (response time) - tempo de la fino
sendante peton (peton) antaŭ ol komenci ricevi respondon (respondon).
Kutime mezurite en milisekundoj (ms)
Tempo de respondo de transakcio- tempo de unu kompleta transakcio,
kompletigo de la peto-responda ciklo.
Ĉi tiu estas la tempo ekde la komenco de sendo de la peto (peto)
ĝis kompletigo de ricevado de respondo (respondo).
Transakcia tempo povas esti mezurita en sekundoj (aŭ minutoj)
en pluraj manieroj: konsideru la minimumon,
maksimumo, mezumo kaj, ekzemple, la 90-a percentilo.
La minimumaj kaj maksimumaj legaĵoj estas ekstremaj
sistema rendimento statuso.
La naŭdeka percentilo estas la plej ofte uzata,
kiel ĝi montras la plimulton de la uzantoj,
komforte funkcianta ĉe la sojlo de sistema rendimento
Transakcioj je sekundo (minuto) - la nombro de kompletaj
transakcioj je sekundo (minuto),
tio estas, kiom la aplikaĵo povis akcepti kaj
procesi petojn kaj eligi respondojn.
Fakte, ĉi tio estas la trairo de la sistemo
Transakcia stato , Pasita / Malsukcesa / Totala - nombro
sukcesa, malsukcesa kaj la tuta nombro de transakcioj.
Por realaj uzantoj malsukcesaj
la transakcio efektive signifos
nekapablo labori kun la sistemo sub ŝarĝo
Ŝarĝu Testa Skema Diagramo
La koncepto de ŝarĝtestado estas tre simpla kaj konsistas el tri ĉefaj etapoj, kiujn mi jam menciis: Preparu-Testo-Raporton, tio estas, prepari testcelojn kaj fiksi parametrojn por ŝarĝfontoj, poste ekzekuti ŝarĝtestojn kaj, fine, generi kaj publikigi testan raporton.
Skemaj notoj:
- QA.Tester estas fakulo pri ŝarĝtestado,
- Celo estas la cela aplikaĵo por kiu vi volas scii ĝian konduton sub ŝarĝo.
Klasigilo de estaĵoj, stadioj kaj paŝoj en la diagramo
Etapoj kaj paŝoj
Kio okazas
Kio estas ĉe la enirejo
Kio estas la eligo
Preparu: prepara stadio por testado
Ŝarĝi Parametrojn
Agordo kaj inicialigo
uzanto
ŝarĝi parametrojn,
elekto de metrikoj kaj
preparplano de provo
(ŝarĝi profilon)
Propraj elektoj por
ŝarĝa agento inicialigo
Testplano
Celo de testado
VM
Nuba deplojo
virtuala maŝino kun
postulataj trajtoj
VM-agordoj por ŝarĝa agento
Aŭtomatigaj skriptoj por
VM-kreado
VM agordita en
nubo
Sendu
OS-aranĝo kaj preparado
medio por
ŝarĝo agento laboro
Medio-agordoj por
ŝarĝo agento
Aŭtomatigaj skriptoj por
medio-agordoj
Preta medio:
OS, servoj kaj aplikoj,
necesa por laboro
ŝarĝo agento
Ŝarĝaj Agentoj
Instalado, agordo kaj parametrigo
ŝarĝa agento.
Aŭ elŝuti docker-bildon de
antaŭgordita ŝarĝofonto
Ŝargi fontan docker-bildon
(YAT, JM aŭ memskribita kadro)
Agordoj
ŝarĝo agento
Agordu kaj preta
al laborŝarĝo agento
Testo: etapo de ekzekuto de ŝarĝtestoj. Fontoj estas ŝarĝaj agentoj deplojitaj en dediĉitaj agentoj por GitLab CI
ŝarĝo
Lanĉante la Ŝarĝan Agenton
kun elektita testplano
kaj ŝarĝi parametrojn
Uzantaj Opcioj
por komencado
ŝarĝo agento
Testplano
Celo de testado
Ekzekutaj protokoloj
ŝarĝtestoj
Sistema protokoloj
Dinamiko de ŝanĝoj en celmetriko kaj ŝarĝagento
Kuru Agentojn
Agenta Ekzekuto
amasoj da testaj skriptoj
konforme
ŝarĝo profilon
Ŝarĝu Agentinterago
por la provoj
Testplano
Celo de testado
Registroj
Kolekto de "krudaj" ŝtipoj
dum ŝarĝtestado:
ŝarĝi agadregistrojn,
stato de la testcelo
kaj la VM kurante la agenton
Ekzekutaj protokoloj
ŝarĝtestoj
Sistema protokoloj
metrikoj
Kolektado de "krudaj" metrikoj dum testado
Dinamiko de ŝanĝoj en celmetriko
kaj ŝarĝo agento
Raporto: fazo de preparado de prova raporto
Generatoro
Prilaborado kolektita
ŝarĝsistemo kaj
monitora sistemo "kruda"
metrikoj kaj protokoloj
Formado de raporto en
homa legebla formo
ebla kun elementoj
analizistoj
Ekzekutaj protokoloj
ŝarĝtestoj
Sistema protokoloj
Dinamiko de ŝanĝoj en metriko
celo kaj ŝarĝo agento
Prilaboritaj "krudaj" ŝtipoj
en formato taŭga por
alŝutoj al ekstera stokado
Raporto pri senmova ŝarĝo,
homlegebla
publikigas
Publikigo de la raporto
pri ŝarĝo
testado en ekstera
servo
Prilaborita "kruda"
protokoloj en taŭga formato
por malŝarĝo al ekstera
deponejoj
Savita en ekstera
stokado raportas pri
ŝarĝo, taŭga
por homa analizo
Konekti Ŝarĝfontojn en CI-Ŝablono
Ni transiru al la praktika parto. Mi volas montri kiel en iuj projektoj en la kompanio ni efektivigis la koncepton de ŝarĝo-testado kiel servo.
Unue, kun la helpo de niaj DevOps-inĝenieroj, ni kreis dediĉitan aron da agentoj en GitLab CI por fari ŝarĝajn testojn. Por ne konfuzi ilin en ŝablonoj kun aliaj, kiel kunigejoj, ni aldonis etikedojn al ĉi tiuj agentoj, : ŝarĝo. Vi povas uzi aliajn kompreneblajn etikedojn. Ili demandas GitLab CI Kuristoj.
Kiel ekscii la postulatan potencon per aparataro? La karakterizaĵoj de ŝarĝaj agentoj - sufiĉa nombro da vCPU, RAM kaj Disko - povas esti kalkulitaj surbaze de tio, ke Docker, Python (por Yandex.Tank), GitLab CI-agento, Java (por Apache JMeter) devus funkcii per la agento. . Por Java sub JMeter, estas ankaŭ rekomendite uzi minimumon de 512 MB da RAM kaj, kiel supra limo, .
Tiel, laŭ nia sperto, ni rekomendas uzi almenaŭ 4 vCPU-ojn, 4 GB RAM, 60 GB SSD por ŝarĝaj agentoj. La trairo de la retkarto estas determinita surbaze de la postuloj de la ŝarĝa profilo.
Ni ĉefe uzas du ŝarĝfontojn - Apache JMeter kaj Yandex.Tank docker-bildoj.
estas malfermkoda ilo de Yandex por ŝarĝtestado. Ĝia modula arkitekturo estas bazita sur la alt-efikeca nesinkrona traf-bazita HTTP-petogeneratoro de Phantom. La tanko havas enkonstruitan monitoradon de la resursoj de la servilo sub testo per la SSH-protokolo, povas aŭtomate ĉesigi la teston sub specifitaj kondiĉoj, povas montri la rezultojn kaj en la konzolo kaj en formo de grafikaĵoj, vi povas konekti viajn modulojn. al ĝi por vastigi funkciecon. Cetere, ni uzis la Tankon kiam ĝi ankoraŭ ne estis ĉefa. En la artikolo "» Vi povas legi la rakonton pri kiel ni faris ŝarĝtestadon per ĝi en 2013 estas unu el la produktoj de nia kompanio.
estas malfermfonta ŝarĝa testa ilo de Apache. Ĝi povas esti uzata same bone por testi kaj statikajn kaj dinamikajn TTT-aplikaĵojn. JMeter subtenas grandegan nombron da protokoloj kaj manieroj interagi kun aplikaĵoj: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ktp.), SOAP / REST Retservoj, FTP, TCP, LDAP, SMTP(S), POP3( S) ) kaj IMAP(S), datumbazoj per JDBC, povas efektivigi ŝelkomandojn kaj labori kun Java objektoj. JMeter havas IDE por krei, sencimigi kaj efektivigi testajn planojn. Ekzistas ankaŭ CLI por komandlinia operacio en ajna Java kongrua operaciumo (Linukso, Vindozo, Mac OS X). La ilo povas dinamike generi HTML-testraporton.
Por facileco de uzo ene de nia kompanio, por la kapablo de la testantoj mem ŝanĝi kaj aldoni la medion, ni faris konstruojn de docker-bildoj de ŝarĝfontoj sur GitLab CI kun publikigo al la interna. . Ĉi tio plirapidigas kaj pli facile konekti ilin en duktoj por ŝarĝtestoj. Kiel fari docker push al registro per GitLab CI - vidu .
Ni prenis ĉi tiun bazan docker-dosieron por Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Kaj por Apache JMeter ĉi tiu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Vi povas legi kiel funkcias nia kontinua integriga sistemo en la artikolo "".
Ŝablono kaj dukto
Ekzemplo de ŝablono por fari ŝarĝtestojn estas havebla en la projekto . la Vi povas legi la instrukciojn por uzi la ŝablonon. En la ŝablono mem (dosiero ) estas notoj pri kio respondecas ĉiu paŝo.
La ŝablono estas tre simpla kaj montras la tri stadiojn de ŝarĝtestado priskribitaj en la supra diagramo: preparado, testado kaj publikigado de raportoj. Respondeca pri tio : Preparu, Testu kaj Raportu.
- Scenejo devus esti uzata por antaŭagordi testajn celojn aŭ kontroli ilian haveblecon. La medio por ŝarĝfontoj ne bezonas esti agordita, ili estas antaŭkonstruitaj kiel docker-bildoj kaj afiŝitaj en la docker-registro: nur specifu la deziratan version en la Teststadio. Sed vi povas rekonstrui ilin kaj fari viajn proprajn modifitajn bildojn.
- Scenejo uzata por specifi la ŝarĝfonton, ruli testojn kaj stoki testajn artefaktojn. Vi povas elekti ajnan ŝarĝfonton: Yandex.Tank, Apache JMeter, vian propran aŭ ĉiujn kune. Por malŝalti nenecesajn fontojn, simple komentu aŭ forigu la laboron. Enirpunktoj por ŝarĝfontoj:
- Lanĉaj parametroj por Yandex.Tank estas specifitaj en la .,
- La ekparametroj de Apache JMeter estas specifitaj en la dosiero .
Noto: La ŝablono agorda agordo estas uzata por agordi interagon kun la CI-sistemo kaj ne implicas lokigon de testa logiko en ĝi. Por testoj, la enirpunkto estas specifita, kie troviĝas la kontrolbash-skripto. La metodo de rulado de testoj, generado de raportoj kaj la testaj skriptoj mem devas esti efektivigitaj de QA-inĝenieroj. En la demo, por ambaŭ ŝarĝfontoj, la Yandex-ĉefpaĝa peto estas uzata kiel la plej simpla testo. Skriptoj kaj testaj parametroj estas en la dosierujo .
- Ĉe la scenejo vi devas priskribi kiel publikigi la testrezultojn akiritajn ĉe la Teststadio al eksteraj stokaĵoj, ekzemple, al GitLab-paĝoj aŭ specialaj raportaj sistemoj. GitLab Pages postulas, ke la ./publika dosierujo estu nemalplena kaj enhavu almenaŭ index.html dosieron post la finiĝo de la testoj. Vi povas legi pri la nuancoj de la servo GitLab Pages. .
Ekzemploj de kiel eksporti datumojn:
- de JMeter al ,
- de Yandex.Tanko al .
Afiŝado de agordaj instrukcioj:
- HTML-statiko en ,
- al InfluxDB kaj poste al .
En la demonstra ekzemplo, la dukto kun ŝarĝtestoj kaj du ŝarĝfontoj (vi povas malŝalti la nenecesan) aspektas jene:
Apache JMeter povas mem generi HTML-raporton, do estas pli profite konservi ĝin en GitLab Pages uzante normajn ilojn. Jen kiel aspektas la raporto de Apache JMeter:
En la demo ekzemplo por Yandex.Tank, vi nur vidos en la sekcio por GitLab Paĝoj. Dum testado, la Tanko povas konservi la rezultojn al la datumbazo InfluxDB, kaj de tie ili povas esti montritaj, ekzemple, en Grafana (agordo estas farita en la dosiero. ). Jen kiel aspektas la raporto de Tank en Grafana:
Resumo
En la artikolo, mi parolis pri la koncepto de "ŝarĝo-testado kiel servo" (ŝarĝo-testado kiel servo). La ĉefa ideo estas uzi la infrastrukturon de antaŭ-konfiguritaj grupoj de ŝarĝaj agentoj, docker bildoj de ŝarĝfontoj, raportsistemoj kaj dukto kiu kombinas ilin en GitLab CI bazita sur simpla .gitlab-ci.yml ŝablono (ekzemplo). ). Ĉio ĉi estas subtenata de malgranda teamo de aŭtomatigaj inĝenieroj kaj reproduktita laŭ peto de produktteamoj. Mi esperas, ke ĉi tio helpos vin prepari kaj efektivigi similan skemon en via kompanio. Dankon pro atento!
PS Mi volas diri grandan dankon al miaj kolegoj, Sergey Kurbanov kaj Nikolaj Yusev, pro teknika helpo kun la efektivigo de la koncepto de ŝarĝotestado kiel servo en nia kompanio.
aŭtoro: - Deputito Estro de Teknologio kaj Disvolvaj Procezoj (DevOps) ĉe Positive Technologies
fonto: www.habr.com