Ena od težav, s katerimi se pogosto srečujejo prodajalci programske opreme z več izdelki, je podvajanje kompetenc inženirjev – razvijalcev, preizkuševalcev in skrbnikov infrastrukture – v skoraj vsaki ekipi. To velja tudi za drage inženirje - specialiste na področju obremenitvenih testiranj.
Namesto da bi opravili svoje neposredne naloge in uporabili svoje edinstvene izkušnje za izgradnjo procesa testiranja obremenitve, izbiro metodologije, optimalnih meritev in pisanje samodejnih testov v skladu s profili obremenitve, morajo inženirji pogosto uvesti testno infrastrukturo iz nič, konfigurirati orodja za nalaganje, jih sami vdelati v sisteme CI, nastaviti spremljanje in objavljanje poročil.
Rešitve nekaterih organizacijskih težav lahko najdete v testiranju, ki ga uporabljamo v Positive Technologies v . In v tem bom govoril o možnosti integracije obremenitvenih testov v skupni cevovod CI z uporabo koncepta »obremenitvenega testiranja kot storitve« (obremenitveno testiranje kot storitev). Naučili se boste, kako in katere slike vira nalaganja dockerja je mogoče uporabiti v cevovodu CI; kako povezati vire nalaganja z vašim projektom CI z uporabo gradbene predloge; kako izgleda predstavitveni cevovod za izvajanje obremenitvenih testov in objavo rezultatov. Članek je lahko koristen za inženirje za preizkušanje programske opreme in inženirje za avtomatizacijo v CI, ki razmišljajo o arhitekturi svojega nalagalnega sistema.
Bistvo koncepta
Koncept obremenitvenega testiranja kot storitve pomeni zmožnost integracije nalagalnih orodij Apache JMeter, Yandex.Tank in vaših lastnih ogrodij v poljuben neprekinjen integracijski sistem. Demo bo za GitLab CI, vendar so načela skupna vsem sistemom CI.
Obremenitveno testiranje kot storitev je centralizirana storitev za obremenitveno testiranje. Obremenitveni testi se izvajajo v namenskih skupinah agentov, rezultati so samodejno objavljeni v GitLab Pages, Influx DB in Grafana ali v sistemih za poročanje o testih (TestRail, ReportPortal itd.). Avtomatizacija in skaliranje sta implementirana kar se da enostavno – z dodajanjem in parametriranjem običajne predloge gitlab-ci.yml v projektu GitLab CI.
Prednost pristopa je, da celotno infrastrukturo CI, obremenitvene agente, priklopne slike virov obremenitve, preskusne cevovode in objavo poročil vzdržuje centraliziran oddelek za avtomatizacijo (inženirji DevOps), in inženirji obremenitvenega testiranja lahko svoja prizadevanja osredotočijo na razvoj testov in analizo njihovih rezultatov, ne da bi se ukvarjali z infrastrukturnimi težavami.
Zaradi poenostavitve opisa bomo predvidevali, da je ciljna aplikacija ali strežnik, ki ga testiramo, že nameščen in konfiguriran vnaprej (za to je mogoče uporabiti avtomatizirane skripte v Python, SaltStack, Ansible itd.). Potem se celoten koncept obremenitvenega testiranja kot storitve ujema s tremi stopnjami: priprava, testiranje, objava poročil. Več podrobnosti na diagramu (vse slike so klikljive):
Osnovni pojmi in definicije v obremenitvenem testiranju
Pri izvajanju obremenitvenih preizkusov se skušamo držati , uporabite ustrezno terminologijo in priporočene meritve. Podal bom kratek seznam glavnih pojmov in definicij v obremenitvenem testiranju.
Agent za obremenitev - virtualni stroj, na katerem se bo aplikacija zagnala - vir nalaganja (Apache JMeter, Yandex.Tank ali samonapisani modul za nalaganje).
Testni cilj (cilj) - strežnik ali aplikacija, nameščena na strežniku, ki bo predmet obremenitve.
Testni scenarij (testni primer) - nabor parametriziranih korakov: uporabniška dejanja in pričakovane reakcije na ta dejanja, s fiksnimi omrežnimi zahtevami in odgovori, odvisno od podanih parametrov.
Profil ali načrt obremenitve (profil) - v (Razdelek 4.2.4, str. 43) profili obremenitve definirajo metrike, ki so kritične za določen preskus, in možnosti za spreminjanje parametrov obremenitve med preskusom. Primere profilov si lahko ogledate na sliki.
Test — skript z vnaprej določenim naborom parametrov.
Testni načrt (testni načrt) - sklop testov in profil obremenitve.
Testran (testrun) - ena ponovitev izvajanja enega testa s popolnoma izvedenim obremenitvenim scenarijem in prejetim poročilom.
Omrežna zahteva (zahteva) — Zahteva HTTP, poslana od agenta do cilja.
Odziv omrežja (odziv) — Odgovor HTTP, poslan s cilja agentu.
HTTP odzivna koda (status HTTP odzivov) - standardna odzivna koda aplikacijskega strežnika.
Transakcija je celoten cikel zahteva-odgovor. Transakcija se šteje od začetka pošiljanja zahteve (povpraševanja) do zaključka prejema odgovora (odgovora).
Stanje transakcije - ali je bilo mogoče uspešno zaključiti cikel zahteva-odgovor. Če je v tem ciklu prišlo do kakršne koli napake, se celotna transakcija šteje za neuspešno.
Odzivni čas (latenca) - čas od konca pošiljanja zahteve (povpraševanja) do začetka prejema odgovora (odgovora).
Naloži meritve — značilnosti obremenjenega prevoza in povzročitelja obremenitve, določene v procesu preskušanja obremenitve.
Osnovne metrike za merjenje parametrov obremenitve
Nekaj najpogosteje uporabljenih in priporočenih v metodologiji (str. 36, 52) so metrike prikazane v spodnji tabeli. Podobne metrike za agenta in cilja so navedene v isti vrstici.
Meritve za agenta obremenitve
Meritve ciljnega sistema ali aplikacije, ki se preskuša pod obremenitvijo
Število vCPE in spomin RAM,
Disk - "železne" lastnosti obremenitve
CPU, Pomnilnik, uporaba diska - dinamika nalaganja procesorja, pomnilnika in diska
v procesu testiranja. Običajno se meri kot odstotek
največje razpoložljive vrednosti
prepustnost omrežja (on load agent) - prepustnost
omrežni vmesnik na strežniku,
kjer je nameščen agent za nalaganje.
Običajno merjeno v bajtih na sekundo (bps)
prepustnost omrežja(on target) - pasovna širina omrežnega vmesnika
na ciljnem strežniku. Običajno merjeno v bajtih na sekundo (bps)
Virtualni uporabniki- število virtualnih uporabnikov,
izvajanje scenarijev obremenitve in
posnemanje resničnih uporabniških dejanj
Status virtualnih uporabnikov, Uspešno/Neuspešno/Skupno — število uspešnih in
neuspešni statusi virtualnih uporabnikov
za scenarije obremenitve, kot tudi njihovo skupno število.
Na splošno se pričakuje, da so vsi uporabniki lahko dokončali
vse vaše naloge, določene v profilu obremenitve.
Vsaka napaka bo pomenila, da pravi uporabnik ne bo mogel
rešite svojo težavo pri delu s sistemom
Zahtevki na sekundo (minuta)- število omrežnih zahtev na sekundo (ali minuto).
Pomembna značilnost agenta za nalaganje je, koliko zahtev lahko ustvari.
Pravzaprav gre za imitacijo dostopa do aplikacije s strani virtualnih uporabnikov
Odzivi na sekundo (minuta)
- število odzivov omrežja na sekundo (ali minuto).
Pomembna značilnost ciljne storitve: koliko
ustvarjanje in pošiljanje odgovorov na poizvedbe z
nakladalno sredstvo
Stanje odziva HTTP— število različnih odzivnih kod
iz aplikacijskega strežnika, ki ga je prejel agent za nalaganje.
Na primer, 200 OK pomeni uspešen klic,
in 404 - da vir ni bil najden
Latenca (odzivni čas) - čas od konca
pošiljanje zahteve (povpraševanja) preden začnete prejemati odgovor (odgovor).
Običajno merjeno v milisekundah (ms)
Odzivni čas transakcije— čas ene celotne transakcije,
zaključek cikla zahteva-odgovor.
To je čas od začetka pošiljanja povpraševanja (povpraševanja)
do zaključka prejema odgovora (odgovora).
Čas transakcije se lahko meri v sekundah (ali minutah)
na več načinov: upoštevajte minimum,
maksimum, povprečje in na primer 90. percentil.
Najmanjši in največji odčitki so ekstremni
stanje delovanja sistema.
Devetdeseti percentil je najpogosteje uporabljen,
kot kaže večina uporabnikov,
udobno delovanje na pragu zmogljivosti sistema
Transakcije na sekundo (minuta) - število popolnih
transakcij na sekundo (minuta),
torej koliko je aplikacija lahko sprejela in
obdelati zahteve in izdati odgovore.
Pravzaprav je to prepustnost sistema
Stanje transakcije , Uspešno / Neuspešno / Skupaj - število
uspešnih, neuspešnih in skupno število transakcij.
Za prave uporabnike neuspešno
bo transakcija dejansko pomenila
nezmožnost dela s sistemom pod obremenitvijo
Shematski diagram testiranja obremenitve
Koncept obremenitvenega testiranja je zelo preprost in je sestavljen iz treh glavnih stopenj, ki sem jih že omenil: Pripravi poročilo o preizkusu, to je priprava testnih ciljev in nastavitev parametrov za vire obremenitve, nato izvedba obremenitvenih testov in na koncu generiranje in objava testnega poročila.
Shematične opombe:
- QA.Tester je strokovnjak za testiranje obremenitve,
- Target je ciljna aplikacija, za katero želite izvedeti njeno obnašanje pod obremenitvijo.
Klasifikator entitet, stopenj in korakov v diagramu
Stopnje in koraki
Kaj se dogaja
Kaj je na vhodu
Kakšen je rezultat
Pripravite se: pripravljalna faza za testiranje
LoadParameters
Nastavitev in inicializacija
uporabnik
parametri obremenitve,
izbira meritev in
priprava testnega načrta
(naloži profil)
Možnosti po meri za
inicializacija agenta za nalaganje
Testni načrt
Namen testiranja
VM
Namestitev v oblaku
virtualni stroj z
zahtevane lastnosti
Nastavitve VM za agenta nalaganja
Skripte za avtomatizacijo
Ustvarjanje VM
VM konfiguriran v
oblak
Pošlji
Namestitev in priprava OS
okolje za
delo agenta za obremenitev
Nastavitve okolja za
obremenitveni agent
Skripte za avtomatizacijo
nastavitve okolja
Pripravljeno okolje:
OS, storitve in aplikacije,
potrebno za delo
obremenitveni agent
LoadAgents
Namestitev, konfiguracija in parametriranje
nakladalno sredstvo.
Ali prenos slike dockerja iz
vnaprej konfiguriran vir nalaganja
Naloži izvorno sliko dockerja
(YAT, JM ali ogrodje, ki ga sami napišemo)
Možnosti nastavitve
obremenitveni agent
Nastavljeno in pripravljeno
agent za delovno obremenitev
Test: stopnja izvedbe obremenitvenih testov. Viri so agenti za nalaganje, razporejeni v namenskih skupinah agentov za GitLab CI
Obremenitev
Zagon agenta za nalaganje
z izbranim testnim načrtom
in parametri obremenitve
Uporabniške možnosti
za inicializacijo
obremenitveni agent
Testni načrt
Namen testiranja
Dnevniki izvajanja
obremenitveni testi
Sistemski dnevniki
Dinamika sprememb ciljne metrike in agenta obremenitve
Zaženi agente
Agentska izvedba
ogromno testnih skriptov
v skladu s
profil obremenitve
Interakcija posrednika za nalaganje
za namen testiranja
Testni načrt
Namen testiranja
Dnevniki
Zbiranje "surovih" dnevnikov
med obremenitvenim testiranjem:
zapisi dejavnosti agenta za nalaganje,
stanje testnega cilja
in VM, ki izvaja agenta
Dnevniki izvajanja
obremenitveni testi
Sistemski dnevniki
Meritve
Zbiranje "surovih" meritev med testiranjem
Dinamika sprememb ciljnih metrik
in agent za obremenitev
Poročilo: faza priprave poročila o preskusu
Generator
Obdelava zbrana
nakladalni sistem in
nadzorni sistem "surov"
metrike in dnevniki
Oblikovanje poročila v
človeku berljivi obliki
možno z elementi
analitiki
Dnevniki izvajanja
obremenitveni testi
Sistemski dnevniki
Dinamika sprememb metrike
ciljni in obremenitveni agent
Obdelana "surova" polena
v obliki, primerni za
naloži v zunanji pomnilnik
poročilo o statičnih obremenitvah,
človeku berljiv
objavi
Objava poročila
o obremenitvi
testiranje v zunanjih
storitev
Predelano "surovo"
dnevnike v primerni obliki
za razkladanje na zunanjo
repozitoriji
Shranjeno v zunanjem
poročila o skladiščenju
obremenitev, primeren
za analizo ljudi
Povezovanje virov obremenitve v predlogi CI
Preidimo na praktični del. Želim pokazati, kako na nekaterih projektih v podjetju implementirali smo koncept obremenitvenega testiranja kot storitve.
Najprej smo s pomočjo naših inženirjev DevOps ustvarili namensko skupino agentov v GitLab CI za izvajanje obremenitvenih testov. Da jih v predlogah ne bi zamenjali z drugimi, kot so zbirni bazeni, smo tem agentom dodali oznake, : obremenitev. Uporabite lahko katere koli druge razumljive oznake. Sprašujejo GitLab CI Runners.
Kako ugotoviti potrebno moč po strojni opremi? Značilnosti agentov za nalaganje - zadostno število vCPU, RAM-a in diska - je mogoče izračunati na podlagi dejstva, da naj bi se na agentu izvajali Docker, Python (za Yandex.Tank), GitLab CI agent, Java (za Apache JMeter). Za Javo pod JMeter je priporočljivo uporabiti tudi najmanj 512 MB RAM-a in kot zgornjo mejo .
Zato na podlagi naših izkušenj priporočamo uporabo vsaj 4 vCPU-jev, 4 GB RAM-a, 60 GB SSD za nalagalne agente. Prepustnost omrežne kartice se določi glede na zahteve obremenitvenega profila.
Uporabljamo predvsem dva vira nalaganja - Apache JMeter in Yandex.Tank docker slike.
je odprtokodno orodje podjetja Yandex za testiranje obremenitve. Njegova modularna arhitektura temelji na Phantomovem visoko zmogljivem asinhronem generatorju zahtev HTTP, ki temelji na zadetkih. Rezervoar ima vgrajeno spremljanje virov testiranega strežnika prek protokola SSH, lahko samodejno ustavi test pod določenimi pogoji, lahko prikaže rezultate tako v konzoli kot v obliki grafov, nanj lahko povežete svoje module, da razširite funkcionalnost. Mimogrede, Tank smo uporabljali, ko še ni bil mainstream. V članku "» lahko preberete zgodbo o tem, kako smo leta 2013 z njim izvajali obremenitveno testiranje je eden od izdelkov našega podjetja.
je odprtokodno orodje za testiranje obremenitve podjetja Apache. Enako dobro se lahko uporablja za testiranje statičnih in dinamičnih spletnih aplikacij. JMeter podpira ogromno število protokolov in načinov interakcije z aplikacijami: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET itd.), SOAP / REST spletne storitve, FTP, TCP, LDAP, SMTP(S), POP3(S) in IMAP(S), podatkovne baze prek JDBC, lahko izvaja ukaze lupine in dela z objekti Java. JMeter ima IDE za ustvarjanje, odpravljanje napak in izvajanje testnih načrtov. Obstaja tudi CLI za delovanje ukazne vrstice v katerem koli operacijskem sistemu, združljivem z Javo (Linux, Windows, Mac OS X). Orodje lahko dinamično ustvari testno poročilo HTML.
Za lažjo uporabo znotraj našega podjetja, za možnost samih preizkuševalcev, da spreminjajo in dodajajo okolje, smo izdelali gradnje slik dockerjev virov nalaganja na GitLab CI z objavo v internem . Tako jih je hitreje in lažje povezati v cevovode za obremenitvene teste. Kako narediti docker push v register prek GitLab CI - glejte .
Vzeli smo to osnovno datoteko docker za Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]In za Apache JMeter to:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Kako deluje naš sistem kontinuirane integracije, si lahko preberete v članku "".
Predloga in cevovod
Primer predloge za izvajanje obremenitvenih testov je na voljo v projektu . V Preberete lahko navodila za uporabo predloge. V sami predlogi (datoteka ) obstajajo opombe o tem, za kaj je odgovoren vsak korak.
Predloga je zelo preprosta in prikazuje tri stopnje testiranja obremenitve, opisane v zgornjem diagramu: priprava, testiranje in objava poročil. Odgovoren za to : Pripravite, testirajte in poročajte.
- Faza je treba uporabiti za vnaprejšnjo konfiguracijo testnih ciljev ali preverjanje njihove razpoložljivosti. Okolja za vire nalaganja ni treba konfigurirati, ti so vnaprej zgrajeni kot slike dockerjev in objavljeni v registru dockerjev: samo določite želeno različico na stopnji Test. Lahko pa jih obnovite in naredite svoje spremenjene slike.
- Faza uporablja se za določanje vira nalaganja, izvajanje testov in shranjevanje testnih artefaktov. Izberete lahko poljuben vir nalaganja: Yandex.Tank, Apache JMeter, svoj ali vse skupaj. Če želite onemogočiti nepotrebne vire, samo komentirajte ali izbrišite opravilo. Vstopne točke za vire obremenitve:
- Parametri zagona za Yandex.Tank so določeni v .,
- Zagonski parametri Apache JMeter so navedeni v datoteki .
Opomba: Konfiguracijska predloga sklopa se uporablja za nastavitev interakcije s sistemom CI in ne pomeni umestitve preskusne logike vanj. Za teste je podana vstopna točka, kjer se nahaja kontrolni bash skript. Metodo izvajanja testov, generiranje poročil in same testne skripte morajo izvajati inženirji za zagotavljanje kakovosti. V predstavitvi je za oba vira nalaganja kot najpreprostejši test uporabljena zahteva glavne strani Yandex. Skripte in testni parametri so v imeniku .
- Na odru opisati morate, kako objaviti rezultate testa, pridobljene na stopnji Test, v zunanjih pomnilnikih, na primer na straneh GitLab ali v posebnih sistemih za poročanje. GitLab Pages zahteva, da imenik ./public ni prazen in vsebuje vsaj datoteko index.html po zaključku preizkusov. Preberete lahko o niansah storitve GitLab Pages. .
Primeri izvoza podatkov:
- od JMeter do ,
- od Yandex.Tank do .
Navodila za nastavitev objave:
- Statika HTML v ,
- v InfluxDB in nato v .
V predstavitvenem primeru je cevovod z obremenitvenimi testi in dvema viroma obremenitve (lahko onemogočite nepotrebnega) videti takole:
Apache JMeter lahko sam ustvari poročilo HTML, zato ga je bolj donosno shraniti v GitLab Pages s standardnimi orodji. Tako izgleda poročilo Apache JMeter:
V predstavitvenem primeru za Yandex.Tank boste videli samo v razdelku za strani GitLab. Med testiranjem lahko Tank shrani rezultate v bazo InfluxDB, od tam pa jih lahko prikaže na primer v Grafani (konfiguracija se izvede v datoteki ). Tako je videti Tankovo poročilo v Grafanu:
Povzetek
V članku sem govoril o pojmu "obremenitveno testiranje kot storitev" (obremenitveno testiranje kot storitev). Glavna ideja je uporaba infrastrukture vnaprej konfiguriranih skupin nalagalnih agentov, slik dockerjev virov nalaganja, sistemov poročanja in cevovoda, ki jih združuje v GitLab CI na podlagi preproste predloge .gitlab-ci.yml (primer ). Vse to podpira majhna ekipa inženirjev za avtomatizacijo in replicirano na zahtevo proizvodnih skupin. Upam, da vam bo to pomagalo pri pripravi in izvajanju podobne sheme v vašem podjetju. Hvala za pozornost!
PS Rad bi se zahvalil kolegoma, Sergeju Kurbanovu in Nikolaju Jusevu, za tehnično pomoč pri implementaciji koncepta testiranja obremenitve kot storitve v našem podjetju.
Avtor: - Namestnik Vodja tehnologije in razvojnih procesov (DevOps) pri Positive Technologies
Vir: www.habr.com