Viena iš problemų, su kuria dažnai susiduria kelių produktų programinės įrangos pardavėjai, yra beveik kiekvienos komandos inžinierių – kūrėjų, testuotojų ir infrastruktūros administratorių – kompetencijų dubliavimas. Tai galioja ir brangiems inžinieriams – apkrovos testavimo srities specialistams.
Užuot atlikę savo tiesiogines pareigas ir naudodami savo unikalią patirtį kurdami apkrovos testavimo procesą, pasirinkę metodiką, optimalias metrikas ir rašydami automatinius testus pagal apkrovos profilius, inžinieriai dažnai turi įdiegti bandymų infrastruktūrą nuo nulio, konfigūruoti apkrovos įrankius ir juos įterpti. KI sistemose, nustato stebėjimą ir ataskaitų skelbimą.
Kai kurių organizacinių problemų sprendimus galite rasti testuodami, kuriuos naudojame „Positive Technologies“. . O šiame kalbėsiu apie galimybę integruoti apkrovos testus į bendrą CI vamzdyną naudojant „apkrovos testavimo kaip paslaugos“ sąvoką (apkrovos testavimas kaip paslauga). Sužinosite, kaip ir kokius apkrovos šaltinių docker vaizdus galima naudoti CI konvejeryje; kaip prijungti apkrovos šaltinius prie CI projekto naudojant kūrimo šabloną; kaip atrodo demonstracinis dujotiekis, skirtas atlikti apkrovos testus ir paskelbti rezultatus. Straipsnis gali būti naudingas programinės įrangos testavimo inžinieriams ir automatikos inžinieriams CI, kurie galvoja apie savo apkrovos sistemos architektūrą.
Koncepcijos esmė
Apkrovos testavimo kaip paslaugos koncepcija reiškia galimybę integruoti apkrovos įrankius „Apache JMeter“, „Yandex.Tank“ ir savo sistemas į savavališką nuolatinio integravimo sistemą. Demonstracinė versija bus skirta „GitLab CI“, tačiau principai yra bendri visoms CI sistemoms.
Apkrovos testavimas kaip paslauga yra centralizuota apkrovos testavimo paslauga. Apkrovos testai vykdomi tam skirtuose agentų telkiniuose, rezultatai automatiškai skelbiami „GitLab Pages“, „Influx DB“ ir „Grafana“ arba bandymų ataskaitų sistemose („TestRail“, „ReportPortal“ ir kt.). Automatizavimas ir mastelio keitimas įgyvendinami kuo paprasčiau – pridedant ir parametruojant įprastą gitlab-ci.yml šabloną GitLab CI projekte.
Šio metodo pranašumas yra tas, kad visą CI infrastruktūrą, įkėlimo agentus, įkrovos šaltinių doko vaizdus, testavimo vamzdynus ir ataskaitas tvarko centralizuotas automatikos skyrius (DevOps inžinieriai), o apkrovos testavimo inžinieriai gali sutelkti savo pastangas į bandymų kūrimą. ir jų rezultatų analizę, nenagrinėjant infrastruktūros problemų.
Aprašymo paprastumo dėlei darysime prielaidą, kad bandoma tikslinė programa arba serveris jau buvo įdiegtas ir sukonfigūruotas iš anksto (tam galima naudoti automatinius Python, SaltStack, Ansible ir kt. scenarijus). Tada visa apkrovos testavimo kaip paslaugos koncepcija suskirstyta į tris etapus: ataskaitų rengimas, testavimas, publikavimas. Daugiau informacijos diagramoje (visas nuotraukas galima spustelėti):
Pagrindinės apkrovos testavimo sąvokos ir apibrėžimai
Atlikdami apkrovos bandymus stengiamės jų laikytis , naudokite atitinkamą terminiją ir rekomenduojamą metriką. Pateiksiu trumpą pagrindinių apkrovos testavimo sąvokų ir apibrėžimų sąrašą.
Pakrovimo agentas - virtuali mašina, kurioje bus paleista programa - įkėlimo šaltinis (Apache JMeter, Yandex.Tank arba savarankiškai parašytas apkrovos modulis).
Bandymo tikslas (tikslas) - serveris arba jame įdiegta programa, kuri bus įkeliama.
Bandymo scenarijus (bandomasis atvejis) - parametrizuotų žingsnių rinkinys: vartotojo veiksmai ir laukiamos reakcijos į šiuos veiksmus su fiksuotomis tinklo užklausomis ir atsakymais, priklausomai nuo nurodytų parametrų.
Profilis arba apkrovos planas (profilis) - į (4.2.4 skyrius, 43 p.) apkrovos profiliai apibrėžia metriką, kuri yra labai svarbi konkrečiam bandymui, ir apkrovos parametrų keitimo bandymo metu galimybes. Profilių pavyzdžius galite pamatyti paveikslėlyje.
Testas — scenarijus su iš anksto nustatytu parametrų rinkiniu.
Bandymo planas (bandymo planas) - bandymų rinkinys ir apkrovos profilis.
Testran (testrun) - viena iteracija, kai vykdomas vienas bandymas su visiškai įvykdytu apkrovos scenarijumi ir gauta ataskaita.
Tinklo užklausa (užklausa) – HTTP užklausa, siunčiama iš agento į tikslą.
Tinklo atsakas (atsakymas) — HTTP atsakymas, siunčiamas iš tikslo agentui.
HTTP atsako kodas (HTTP atsakymo būsena) – standartinis atsako kodas iš taikomųjų programų serverio.
Sandoris yra pilnas užklausos-atsakymo ciklas. Operacija skaičiuojama nuo užklausos (užklausos) išsiuntimo pradžios iki atsakymo (atsakymo) gavimo pabaigos.
Sandorio būsena - ar pavyko sėkmingai užbaigti užklausos-atsakymo ciklą. Jei šiame cikle įvyko klaida, visa operacija laikoma nesėkminga.
Reakcijos laikas (delsa) - laikas nuo užklausos (užklausos) išsiuntimo pabaigos iki atsakymo (atsakymo) gavimo pradžios.
Apkrovos metrika — apkrovos eksploatacijos ir apkrovos agento charakteristikos, nustatytos atliekant apkrovos bandymą.
Pagrindinės apkrovos parametrų matavimo metrikos
Vieni dažniausiai naudojamų ir rekomenduojamų metodikoje (p. 36, 52) metrika parodyta žemiau esančioje lentelėje. Panaši agento ir tikslo metrika pateikiama toje pačioje eilutėje.
Apkrovos agento metrika
Tikslinės sistemos arba taikomosios programos, kuri bandoma veikiant apkrovai, metrika
Skaičius vCPU ir atmintis RAM,
Diskas - apkrovos agento "geležinės" charakteristikos
CPU, Atmintis, disko naudojimas - CPU, atminties ir disko įkrovimo dinamika
testavimo procese. Paprastai matuojamas procentais
didžiausios galimos vertės
Tinklo pralaidumas (ant apkrovos agentas) – pralaidumas
tinklo sąsaja serveryje,
kur įdiegta apkrovos priemonė.
Paprastai matuojama baitais per sekundę (bps)
Tinklo pralaidumas(taikinyje) – tinklo sąsajos pralaidumas
tiksliniame serveryje. Paprastai matuojama baitais per sekundę (bps)
Virtualūs vartotojai- virtualių vartotojų skaičius,
įgyvendinant apkrovos scenarijus ir
imituojant tikrus vartotojo veiksmus
Virtualių vartotojų būsena, Įskaityta/Nepavyko/Iš viso — sėkmingų ir
nesėkmingos virtualių vartotojų būsenos
apkrovos scenarijus, taip pat bendrą jų skaičių.
Paprastai tikimasi, kad visi vartotojai galėjo užbaigti
visas jūsų užduotis, nurodytas apkrovos profilyje.
Bet kokia klaida reikš, kad tikras vartotojas to negalės
išspręskite savo problemą dirbdami su sistema
Užklausos per sekundę (min.)- tinklo užklausų skaičius per sekundę (arba minutę).
Svarbi apkrovos agento charakteristika yra tai, kiek užklausų jis gali sugeneruoti.
Tiesą sakant, tai yra virtualių vartotojų prieigos prie programos imitacija
Atsakymai per sekundę (min.)
- tinklo atsakymų skaičius per sekundę (arba minutę).
Svarbi tikslinės paslaugos charakteristika: kiek
generuoti ir siųsti atsakymus į užklausas su
pakrovimo agentas
HTTP atsakymo būsena— skirtingų atsakymo kodų skaičius
iš programų serverio, kurį gavo įkėlimo agentas.
Pavyzdžiui, 200 OK reiškia sėkmingą skambutį,
ir 404 – kad išteklius nerastas
Uždelsimas (atsakymo laikas) – laikas nuo pabaigos
užklausos (užklausos) siuntimas prieš pradedant gauti atsakymą (atsakymą).
Paprastai matuojama milisekundėmis (ms)
Sandorio reakcijos laikas— vienos užbaigtos operacijos laikas,
užklausos-atsakymo ciklo pabaiga.
Tai laikas nuo užklausos (užklausos) išsiuntimo pradžios
iki atsakymo (atsakymo) gavimo pabaigos.
Operacijos laikas gali būti matuojamas sekundėmis (arba minutėmis)
keliais būdais: apsvarstykite minimumą,
maksimalus, vidutinis ir, pavyzdžiui, 90 procentilių.
Minimalūs ir didžiausi rodmenys yra ekstremalūs
sistemos veikimo būsena.
Devyniasdešimtasis procentilis yra dažniausiai naudojamas
kaip rodo dauguma vartotojų,
patogiai veikia prie sistemos veikimo slenksčio
Operacijos per sekundę (min.) - užbaigtų skaičių
operacijų per sekundę (min.),
tai yra, kiek paraiška galėjo priimti ir
apdoroti užklausas ir pateikti atsakymus.
Tiesą sakant, tai yra sistemos pralaidumas
Sandorio būsena , Išlaikyta / Nepavyko / Iš viso - skaičius
sėkmingų, nesėkmingų ir bendrą operacijų skaičių.
Tikriems vartotojams nepasisekė
sandoris iš tikrųjų reikš
nesugebėjimas dirbti su apkrauta sistema
Apkrovos testavimo schema
Apkrovos testavimo koncepcija yra labai paprasta ir susideda iš trijų pagrindinių etapų, kuriuos jau minėjau: Parengti-testas-ataskaitaty paruošti bandymo tikslus ir nustatyti apkrovos šaltinių parametrus, tada atlikti apkrovos testus ir pabaigoje sugeneruoti bei paskelbti bandymo ataskaitą.
Scheminės pastabos:
- QA.Tester yra apkrovos testavimo ekspertas,
- Target yra tikslinė programa, kurios elgseną apkrovus norite sužinoti.
Esybių, etapų ir žingsnių klasifikatorius diagramoje
Etapai ir žingsniai
Kas atsitiks
Kas yra prie įėjimo
Kas yra išvestis
Pasiruošimas: pasiruošimo bandymui etapas
Apkrovos parametrai
Nustatymas ir inicijavimas
Vartotojas
apkrovos parametrai,
metrikų pasirinkimas ir
testo plano rengimas
(įkelti profilį)
Pasirinktinės parinktys
įkėlimo agento inicijavimas
Bandymo planas
Testavimo tikslas
VM
Debesų diegimas
virtuali mašina su
reikalingos savybės
Įkėlimo agento VM nustatymai
Automatizavimo scenarijai
VM kūrimas
VM sukonfigūruotas
debesis
Env
OS nustatymas ir paruošimas
aplinka
krovinio agento darbas
Aplinkos nustatymai, skirti
krovinio agentas
Automatizavimo scenarijai
aplinkos parametrus
Paruošta aplinka:
OS, paslaugos ir programos,
reikalingos darbui
krovinio agentas
LoadAgents
Montavimas, konfigūravimas ir parametrų nustatymas
pakrovimo agentas.
Arba atsisiųskite „Docker“ vaizdą iš
iš anksto sukonfigūruotas apkrovos šaltinis
Įkelti šaltinio doko vaizdą
(YAT, JM arba savarankiškai parašyta sistema)
Nustatymai
krovinio agentas
Nustatykite ir paruoškite
dirbti krovinio agentą
Testas: apkrovos testų vykdymo etapas. Šaltiniai yra įkėlimo agentai, diegiami specialiuose GitLab CI agentų telkiniuose
Įkelti
Įkėlimo agento paleidimas
su pasirinktu testavimo planu
ir apkrovos parametrai
Vartotojo parinktys
inicijavimui
krovinio agentas
Bandymo planas
Testavimo tikslas
Vykdymo žurnalai
apkrovos bandymai
Sistemos žurnalai
Tikslų metrikos ir apkrovos agento pokyčių dinamika
Vykdykite agentus
Agento vykdymas
daugybė bandomųjų scenarijų
pagal
apkrovos profilis
Įkelti agento sąveiką
bandymo tikslu
Bandymo planas
Testavimo tikslas
Naujienos
„Žaliavų“ rąstų kolekcija
apkrovos bandymo metu:
apkrovos agento veiklos įrašai,
bandomojo tikslo būsena
ir agentą valdanti VM
Vykdymo žurnalai
apkrovos bandymai
Sistemos žurnalai
Metrika
„Neapdorotos“ metrikos rinkimas testavimo metu
Tikslų metrikos pokyčių dinamika
ir krovinio agentas
Ataskaita: bandymo ataskaitos rengimo etapas
Generatorius
Apdorojimas surinktas
pakrovimo sistema ir
stebėjimo sistema "neapdorota"
metrikos ir žurnalai
Ataskaitos sudarymas
žmogui skaitoma forma
galima su elementais
analitikai
Vykdymo žurnalai
apkrovos bandymai
Sistemos žurnalai
Metrikos pokyčių dinamika
taikinys ir apkrovos agentas
Apdoroti „žaliaviniai“ rąstai
tinkamu formatu
įkeliama į išorinę saugyklą
Statinės apkrovos ataskaita,
skaitomas žmogui
Skelbti
Ataskaitos paskelbimas
apie apkrovą
bandymai išorėje
tarnyba
Perdirbtas "neapdorotas"
tinkamo formato žurnalus
iškrovimui į išorę
saugyklos
Išsaugota išorinėje
saugojimo ataskaitos apie
apkrova, tinkama
žmonių analizei
Apkrovos šaltinių prijungimas CI šablone
Pereikime prie praktinės dalies. Noriu parodyti, kaip kai kuriuose įmonės projektuose įdiegėme apkrovos testavimo kaip paslaugos koncepciją.
Pirmiausia, padedami „DevOps“ inžinierių, sukūrėme specialią agentų grupę „GitLab CI“, kad galėtume atlikti apkrovos testus. Kad nepainiotume jų šablonuose su kitais, pvz., surinkimo telkiniais, prie šių agentų pridėjome žymų, : apkrova. Galite naudoti bet kokias kitas suprantamas žymas. Jie klausia GitLab CI bėgikai.
Kaip pagal aparatinę įrangą sužinoti reikiamą galią? Įkėlimo agentų charakteristikas – pakankamą vCPU, RAM ir disko skaičių – galima apskaičiuoti remiantis tuo, kad agente turėtų veikti Docker, Python (skirta Yandex.Tank), GitLab CI agentas, Java (skirta Apache JMeter). . Java pagal JMeter, taip pat rekomenduojama naudoti mažiausiai 512 MB RAM ir, kaip viršutinę ribą, .
Taigi, remdamiesi savo patirtimi, apkrovos agentams rekomenduojame naudoti bent 4 vCPU, 4 GB RAM, 60 GB SSD. Tinklo plokštės pralaidumas nustatomas pagal apkrovos profilio reikalavimus.
Daugiausia naudojame du įkėlimo šaltinius – „Apache JMeter“ ir „Yandex.Tank docker“ vaizdus.
yra atvirojo kodo „Yandex“ įrankis, skirtas apkrovos testavimui. Jo modulinė architektūra pagrįsta Phantom didelio našumo asinchroniniu hitu pagrįstu HTTP užklausų generatoriumi. Bake yra įmontuotas bandomojo serverio resursų stebėjimas per SSH protokolą, gali automatiškai sustabdyti testą nurodytomis sąlygomis, gali rodyti rezultatus tiek konsolėje, tiek grafikų pavidalu, galite prijungti savo modulius Norėdami išplėsti funkcionalumą. Beje, mes naudojome Tanką, kai jis dar nebuvo įprastas. Straipsnyje "» galite perskaityti istoriją, kaip su juo atlikome apkrovos testavimą 2013 m yra vienas iš mūsų įmonės produktų.
yra „Apache“ atvirojo kodo apkrovos testavimo įrankis. Jis vienodai gerai gali būti naudojamas tiek statinėms, tiek dinaminėms žiniatinklio programoms išbandyti. JMeter palaiko daugybę protokolų ir būdų, kaip bendrauti su programomis: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET ir kt.), SOAP / REST žiniatinklio paslaugos, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ir IMAP(S), duomenų bazės per JDBC, gali vykdyti apvalkalo komandas ir dirbti su Java objektais. JMeter turi IDE, skirtą kurti, derinti ir vykdyti bandymų planus. Taip pat yra CLI komandų eilutės veikimui bet kurioje su Java suderinamoje operacinėje sistemoje (Linux, Windows, Mac OS X). Įrankis gali dinamiškai generuoti HTML testo ataskaitą.
Kad būtų lengviau naudoti mūsų įmonėje, kad patys bandytojai galėtų keisti ir pridėti aplinką, sukūrėme „GitLab CI“ įkrovos šaltinių „Docker“ vaizdų versijas su publikavimu vidinėje . Tai leidžia greičiau ir lengviau sujungti juos į vamzdynus apkrovos bandymams. Kaip „Docker“ stumti į registrą per „GitLab CI“ – žr .
Mes paėmėme šį pagrindinį „Yandex.Tank“ docker failą:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Ir „Apache JMeter“ šis:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Kaip veikia mūsų nuolatinės integracijos sistema, galite perskaityti straipsnyje "".
Šablonas ir vamzdynas
Apkrovos bandymų šablono pavyzdys pateiktas projekte . Į Galite perskaityti šablono naudojimo instrukcijas. Pačiame šablone (failas ) yra pastabų apie tai, už ką atsakingas kiekvienas žingsnis.
Šablonas yra labai paprastas ir parodo tris apkrovos testavimo etapus, aprašytus aukščiau esančioje diagramoje: ataskaitų rengimą, testavimą ir publikavimą. Už tai atsakingas : Paruoškite, išbandykite ir praneškite.
- Etapas turėtų būti naudojami norint iš anksto sukonfigūruoti bandymo tikslus arba patikrinti jų prieinamumą. Apkrovos šaltinių aplinkos nereikia konfigūruoti, jie yra iš anksto sukurti kaip docker vaizdai ir paskelbti docker registre: tiesiog nurodykite norimą versiją testavimo etape. Bet jūs galite juos atkurti ir pasidaryti modifikuotus vaizdus.
- Etapas naudojamas norint nurodyti įkėlimo šaltinį, vykdyti testus ir saugoti bandomuosius artefaktus. Galite pasirinkti bet kurį įkėlimo šaltinį: „Yandex.Tank“, „Apache JMeter“, savo arba visus kartu. Norėdami išjungti nereikalingus šaltinius, tiesiog pakomentuokite arba ištrinkite užduotį. Apkrovos šaltinių įėjimo taškai:
- Yandex.Tank paleidimo parametrai nurodyti .,
- Apache JMeter paleidimo parametrai nurodyti faile .
Pastaba: surinkimo konfigūracijos šablonas naudojamas sąveikai su CI sistema nustatyti ir nereiškia, kad joje turi būti bandymo logika. Testams nurodomas įėjimo taškas, kuriame yra valdymo bash scenarijus. Testų vykdymo, ataskaitų generavimo ir pačių testavimo scenarijų metodą turi įdiegti kokybės užtikrinimo inžinieriai. Demonstracinėje versijoje abiem įkėlimo šaltiniams „Yandex“ pagrindinio puslapio užklausa naudojama kaip paprasčiausias testas. Skriptai ir bandymo parametrai yra kataloge .
- Scenoje Turite aprašyti, kaip paskelbti testavimo etape gautus testo rezultatus išorinėse saugyklose, pavyzdžiui, GitLab puslapiuose ar specialiose ataskaitų teikimo sistemose. „GitLab“ puslapiuose reikalaujama, kad ./viešasis katalogas nebūtų tuščias ir jame būtų bent index.html failas, kai bus baigti bandymai. Galite pasiskaityti apie „GitLab Pages“ paslaugos niuansus. .
Duomenų eksportavimo pavyzdžiai:
- nuo JMeter iki ,
- iš Yandex.Tank į .
Skelbimo nustatymo instrukcijos:
- HTML statika ,
- į InfluxDB ir tada į .
Demonstraciniame pavyzdyje dujotiekis su apkrovos bandymais ir dviem apkrovos šaltiniais (galite išjungti nereikalingą) atrodo taip:
„Apache JMeter“ gali pats sugeneruoti HTML ataskaitą, todėl naudingiau ją išsaugoti „GitLab“ puslapiuose naudojant standartinius įrankius. Štai kaip atrodo Apache JMeter ataskaita:
„Yandex.Tank“ demonstraciniame pavyzdyje matysite tik „GitLab“ puslapių skiltyje. Bandymo metu bakas gali įrašyti rezultatus į InfluxDB duomenų bazę, o iš ten jie gali būti rodomi, pavyzdžiui, Grafana (konfigūracija atliekama faile ). Taip atrodo Tanko ataskaita Grafana:
Santrauka
Straipsnyje kalbėjau apie sąvoką „apkrovos testavimas kaip paslauga“ (apkrovos testavimas kaip paslauga). Pagrindinė idėja yra naudoti iš anksto sukonfigūruotų įkėlimo agentų telkinių infrastruktūrą, įkėlimo šaltinių doko vaizdus, ataskaitų sistemas ir dujotiekį, kuris juos sujungia GitLab CI remiantis paprastu .gitlab-ci.yml šablonu (pavyzdys ). Visa tai palaiko nedidelė automatikos inžinierių komanda ir atkartoja produktų komandų prašymu. Tikiuosi, kad tai padės jums parengti ir įgyvendinti panašią schemą jūsų įmonėje. Ačiū, už dėmesį!
PS Noriu pasakyti didelį ačiū savo kolegoms Sergejui Kurbanovui ir Nikolajui Jusevui už techninę pagalbą įgyvendinant apkrovos testavimo kaip paslaugos koncepciją mūsų įmonėje.
autorius: – pavaduotojas „Positive Technologies“ technologijų ir plėtros procesų (DevOps) vadovas
Šaltinis: www.habr.com