A gyakran előforduló probléma, amivel a többtermékes szoftvergyártók szembesülnek, az a mérnökök — fejlesztők, tesztelők és infrastruktúra-adminisztrátorok — kompetenciáinak duplikálása majdnem minden csapatban. Ez a költséges mérnökökre, a terheléses tesztelés szakterületének specialistáira is vonatkozik.
Ahelyett, hogy közvetlen feladataikkal foglalkozna, és egyedi tapasztalatukat felhasználva felépítenék a terheléses tesztelési folyamatot, kiválasztanák a módszert, az optimális metrikák értékeit és megírnák az automatizált teszteket a terhelési profilokhoz, a mérnököknek gyakran nulláról kell felépíteniük a tesztinfrastruktúrát, beállítaniuk a terhelési eszközöket, beintegrálniuk azokat a CI-rendszerekbe, valamint konfigurálniuk a megfigyelést és a jelentések publikálását.
Néhány, a tesztelés során felmerülő szervezeti probléma megoldása, amelyeket a Positive Technologies alkalmaz, megtalálható a . Ebben a cikkben az „terheléses tesztelés mint szolgáltatás” (load testing as a service) koncepció segítségével a terheléses tesztek integrálásának lehetőségeit mutatom be a CI-pipeline-ba. Megtudhatja, hogyan és milyen terhelési forrás Docker image-ek használhatók a CI-pipeline-ban; hogyan csatlakoztathatók a terhelési források a saját CI-projektjéhez a build sablon segítségével; hogyan néz ki egy demopipeline a terheléses tesztek futtatására és az eredmények publikálására. A cikk hasznos lehet a szoftvertesztelők és a CI automatizálók számára, akik elgondolkodtak terhelési rendszerük architektúráján.
A koncepció lényege
A terheléses tesztelés mint szolgáltatás koncepciója lehetővé teszi az Apache JMeter, Yandex.Tank és saját keretrendszereink terhelési eszközeinek integrálását bármilyen folyamatos integrációs rendszerbe. A bemutató példa a GitLab CI-re vonatkozik, de az elvek általánosan alkalmazhatók minden CI-rendszerre.
A terheléses tesztelés mint szolgáltatás egy központosított szolgáltatás a terheléses tesztelés lebonyolítására. A terheléses teszteket dedikált ügynöki pultokban indítják, az eredmények publikálása automatikusan történik a GitLab Pages, Influx DB és Grafana vagy tesztjelentési rendszerekbe (TestRail, ReportPortal stb.). Az automatizálás és a skálázás a lehető legegyszerűbben valósul meg — a GitLab CI projektbe egy egyszerű gitlab-ci.yml sablon hozzáadásával és paraméterezésével.
A megközelítés előnye abban rejlik, hogy az összes CI-infrastruktúra, a terhelési ügynökök, a terhelési forrást képező Docker-képek, a tesztelési folyamatok és a jelentések publikálása egy központosított automatizálási részleg (DevOps mérnökök) által van támogatva, így a terheléses tesztelési mérnökök az értékelések kidolgozására és az eredmények elemzésére tudják összpontosítani erőfeszítéseiket, anélkül hogy az infrastruktúra kérdéseivel foglalkoznának.
Az egyszerűség kedvéért tekintsük úgy, hogy a célzott tesztelendő alkalmazás vagy szerver előre telepítve és konfigurálva van (ehhez automatizált szkriptek használhatók, mint például Python, SaltStack, Ansible stb.). Ekkor a terheléses tesztelés mint szolgáltatás koncepciója három lépésre bontható: előkészítés, tesztelés, jelentések közzététele. További részletek a diagramon (minden kép kattintható):
Alapvető fogalmak és definíciók a terheléses tesztelésben
A terheléses tesztelési vizsgálatok során igyekszünk betartani , megfelelő terminológiát és ajánlott metrikákat használva. Röviden összefoglalom a terheléses tesztelés alapvető fogalmait és definícióit.
Terhelési ügynök (load agent) — egy virtuális gép, amelyen futtatni fogják az alkalmazást, amely a terhelést képezi (Apache JMeter, Yandex.Tank vagy egy egyedi terhelési modul).
Tesztelési cél (target) — a szerveren található szerver vagy alkalmazás, amely terhelésnek lesz kitéve.
Tesztelő szcenárió (test case) — egy paraméterezett lépésekből álló halmaz: felhasználói műveletek és a várt reakciók ezen műveletekre, a rögzített hálózati kérésekkel és válaszokkal, a megadott paraméterek függvényében.
Terhelési profil vagy terv (profile) — ehhez tízszer kevesebb hardver szükséges. (4.2.4. pont, 43. oldal) a terhelési profilok meghatározzák a konkrét teszthez kritikus fontosságú metrikákat és a terhelési paraméterek változásának lehetőségeit a teszt folyamán. A profilok példáit a képen láthatja.
Teszt (test) — egy előre meghatározott paraméterkészletű szcenárió.
Teszt terv (test-plan) — tesztek és terhelési profilok együttesen.
Tesztfutás (testrun) — egy teszt egy iterációja egy teljesen megvalósított terhelési szcenárióval és a kapott jelentéssel.
Hálózati kérés (request) — egy HTTP-kérés, amely az ügynöktől a célhoz kerül elküldésre.
Hálózati válasz (response) — HTTP-válasz, amelyet a célküldözőnek küldenek.
HTTP válaszkód (HTTP responses status) — az alkalmazás kiszolgálótól származó szabványos válaszkód.
Tranzakció (transaction) — a "lekérdezés — válasz" teljes ciklusa. A tranzakció akkor kezdődik, amikor a lekérdezés (request) elküldése megtörténik, és akkor ér véget, amikor a válasz (response) fogadása befejeződik.
A tranzakció állapota (transactions status) — a "lekérdezés – válasz" ciklus sikeresen befejeződött-e. Ha a ciklus során bármilyen hiba történt, akkor az egész tranzakció sikertelennek számít.
Válaszidő (latency) — az idő, amely a lekérdezés (request) elküldésének befejezése és a válasz (response) fogadásának megkezdése között eltelt.
Teljesítmény metrikák (metrics) — a terhelési tesztelés során meghatározott jellemzők a terhelt szolgáltatás és a terhelési ügynök vonatkozásában.
Fő metrikák a terhelési paraméterek mérésére
Néhány leggyakrabban használt és ajánlott a módszertanban (34. és 52. old.) a metrikák az alábbi táblázatban találhatók. Hasonló metrikák az ügynök és a cél esetében egy sorban szerepelnek.
Metrikák a terhelési ügynöknél
A tesztelést igénylő célrendszer vagy alkalmazás metrikái
Mennyiség vCPU és memória RAM,
Lemez — a terhelési ügynök "hardveres" jellemzői
CPU, Memória, lemezhasználat — a processzor, memória és lemez terhelésdinamikája
a tesztelés során. Általában százalékban van mérve a
maximálisan elérhető értékek
Hálózati áteresztőképesség (Network throughput) (terhelési ügynöknél) — a hálózati interfész áteresztőképessége
a szerveren,
ahol a terhelési ügynök telepítve van.
Általában bájt per másodperc (bps) értékben van mérve
Hálózati áteresztőképesség (Network throughput)(célon) — a cél szerveren lévő hálózati interfész áteresztőképessége. Általában bájt per másodperc (bps) értékben van mérve
Virtuális felhasználók
— a terhelési forgatókönyveket megvalósító virtuális felhasználók számaés
leutánozzák a valós felhasználók cselekedeteit
Virtuális felhasználók állapota
, Megfelelt/Nem felelt meg/Összes — a virtuális felhasználók sikeres éssikertelen státuszainak száma a terhelési forgatókönyvek során, valamint azok összes száma.
Általában elvárható, hogy minden felhasználó sikeresen el tudja végezni
minden feladatát, amelyet a terhelésprofilban megadtak.
Bármilyen hiba azt jelenti, hogy a valós felhasználó sem tudja
megoldani a feladatát a rendszer használata során.
Kérések másodpercenként (perce)
— a hálózati kérések száma másodpercenként (vagy percenként).
Fontos jellemzője a terhelési ügynöknek: mennyi kérést tud generálni.— количество сетевых запросов в секунду (или минуту).
Важная характеристика нагрузочного агента: сколько он может генерировать запросов.
Valójában ez a virtuális felhasználók általi alkalmazáslekérés szimulálása.
Felelős másodpercenként (percenként)
— a hálózati válaszok száma másodpercenként (vagy percenként).
Fontos jellemzője a célzott szolgáltatásnak: mennyit sikerült
generálni és küldeni a kérdésekre adott válaszokból,
terhelési ügynök
HTTP válaszok állapota— a különböző válaszkódok száma
az alkalmazás szerverétől, amelyeket a terhelési ügynök kapott.
Például a 200 OK sikeres lekérést jelent,
míg a 404 — hogy az erőforrás nem található
Késleltetés (válaszidő) — az az időtartam,
amely a kérés befejezése és a válasz fogadása között telik el.
Általában milliszekundumban (ms) mérik.
Tranzakciós válaszidő— egy teljes tranzakció időtartama,
a "kérés — válasz" ciklus befejezése.
Ez az idő a kérés (request) elküldésének kezdetétől,
a válasz (response) fogadásának befejezéséig tart.
A tranzakció időtartamát más módokon is mérhetjük: a minimumot,
maximumot, átlagot és például a 90. percentilis értéket számítják.
A minimum és maximum értékek a rendszer teljesítményének szélsőséges
állapotait mutatják.
A kilencvenedik percentilis a leggyakrabban használt,
mivel a legtöbb felhasználót jelzi,
akik kényelmesen dolgoznak a rendszer teljesítményének határán.
Tranzakciók másodpercenként (percenként)
— a teljes tranzakciók száma másodpercenként (percenként),
azaz hány kérdést volt képes a rendszer fogadni és
feldolgozni, és hány választ adott.
Valójában ez a rendszer áteresztő képessége.
Tranzakciók állapota
, Sikerült / Nem sikerült / Összesen — a szám sikeres, sikertelen és az összes tranzakció esetében.
Valós felhasználók számára a sikertelen
tranzakció valójában azt jelentheti,
hogy a rendszer terhelés alatt nem működik.
A terheléses tesztelés alapelvei
A terheléses tesztelés alapelvei nagyon egyszerűek és három fő szakaszból állnak, amelyeket már említettem:
Előkészítés — Teszt — Jelentés , vagyis a tesztelési célok és a terhelési források paramétereinek meghatározása, majd a terhelési tesztek végrehajtása, végül pedig a tesztelésről szóló jelentés elkészítése és közzététele.Megjegyzések a sémához:
QA.Egység — szakértő a terheléses tesztelés terén,
- Cél — a célalkalmazás, amelynek teljesítményét terhelés alatt szeretnénk megtudni.
- Entitások, szakaszok és lépések klasszifikátora a sémában
Szakaszok és lépések
Mi történik
Что происходит
Mi van a bemenet alatt
Mi van a kimenet alatt
Prepare: készítési fázis a teszteléshez
LoadParameters
Feladat és inicializálás
felhasználó által
terhelési paraméterek,
mérők kiválasztása és
tesztterv előkészítése
(terhelési profil)
Felhasználói paraméterek az
terhelés-ügynök inicializálásához
Tesztterv
A tesztelés célja
VM
Virtuális gép felhőben történő telepítése
a kívánt jellemzőkkel
VM paraméterek a terhelés-ügynök számára
Automatizálási szkriptek
VM létrehozásához
Beállított VM
Env
felhőben
OS beállítása és
környezet előkészítése
a terhelés-ügynök működéséhez
Környezet paraméterei a
terhelés-ügynök számára
környezetbeállítások
VM létrehozásához
Előkészített környezet:
OS, szolgáltatások és alkalmazások,
amelyek szükségesek a működéshez
LoadAgents
környezetbeállítások
A terhelés-ügynök telepítése, beállítása és paraméterezése.
Vagy a Docker-kép letöltése
előre beállított terhelésforrással
Terhelésforrás Docker-kép
(JMeter, JM vagy saját keretrendszer)
Beállítási paraméterek
Kész és működésre kész terhelés-ügynök
Test: a terhelési tesztek végrehajtásának szakasza. A források terhelés-ügynökök, amelyek a GitLab CI dedikált ügynökvölgyeiben kerültek telepítésre
környezetbeállítások
A terhelés-ügynök indítása
a kiválasztott teszttervvel
és terhelési paraméterekkel
Betöltés
Felhasználói paraméterek
az inicializáláshoz
Futtatási naplók
terhelési tesztekhez
Rendszernaplók
környezetbeállítások
Tesztterv
A tesztelés célja
A cél és a terhelés-ügynök mutatóinak dinamikája
RunAgents
A terhelés-ügynök által végrehajtott
tesztforgatókönyvek
a terhelési profillal
A terhelés-ügynök interakciója
a tesztelési céllal
a következő szerint
A 'nyers' naplók gyűjtése
a terhelési tesztelés során:
a terhelés-ügynök tevékenységéről készült feljegyzések,
Tesztterv
A tesztelés célja
Naplófájlok
a tesztelési cél állapotáról
és a VM-ről, amelyen fut a ügynök
A nyers mutatók gyűjtése a tesztelés során
A cél mutatóinak dinamikája
és a terhelés-ügynök
A cél és a terhelés-ügynök mutatóinak dinamikája
RunAgents
A terhelés-ügynök által végrehajtott
Metrikák
Report: a tesztelési jelentés készítési szakasza
Generator
A begyűjtött
terhelési rendszer és
monitoring rendszer nyers
mutatóinak és naplóinak feldolgozása
Jelentés készítése
emberi olvasásra alkalmas formátumban,
lehetőséggel
elemzések elemeivel
A mutatók dinamikája
a cél és a terhelés-ügynök
Feldolgozott 'nyers' naplók
A cél és a terhelés-ügynök mutatóinak dinamikája
RunAgents
A terhelés-ügynök által végrehajtott
olyan formátumban, amely alkalmas
külső tárolókba történő kiadásra
Statikus jelentés a terhelésről,
mely alkalmas az emberi elemzésre
A jelentés közzététele
a terhelési
tesztelésről külső
Publish
szolgáltatásban
Feldolgozott 'nyers'
тестировании во внешнем
сервисе
Обработанные «сырые»
napló formátumban, amely alkalmas
külső
tárhelyekre
A külső
tárhelyen tárolt jelentések a
terhelésről, amelyek alkalmasak
emberi elemzésre
Terhelési források csatlakoztatása a CI sablonban
Lépjünk a gyakorlati részre. Szeretném bemutatni, hogyan valósítottuk meg a terheléses tesztelés szolgáltatásként néhány projektünkben a cégünknél.
Először DevOps mérnökeink létrehoztak a GitLab CI-ben egy külön ügynökpultot a terhelési tesztek futtatásához. Annak érdekében, hogy ne keverjük össze őket más sablonokban, például a build ügynökökkel, címkéket adtunk ezeknek az ügynököknek, : load. Bármilyen más érthető címke is használható. Ezeket a regisztráció során állítjuk be Hogyan tudhatjuk meg a szükséges hardvererőforrást? A terhelési ügynökök jellemzőit - elegendő számú vCPU, RAM és lemez - az alapján lehet kiszámítani, hogy az ügynökön futnia kell Dockernek, Python-nak (a Yandex.Tank számára), a GitLab CI ügynöknek, Javának (az Apache JMeter számára). A JMeter-hez ajánlott legalább 512 MB RAM-ot használni Java alatt, és a felső határként
a rendelkezésre álló memória 80%-a .
Nálunk főként két terhelési forrást használunk – az Apache JMeter és a Yandex.Tank Docker képeit.
Yandex.Tank
Yandex.Tank és a terheléses tesztelés automatizálásaPT Appllication Firewall Apache JMeter
— ez egy nyílt forráskódú eszköz terheléses teszteléshez, amelyet az Apache fejlesztett. Egyaránt jól használható statikus és dinamikus webalkalmazások tesztelésére. A JMeter hatalmas mennyiségű protokollt és interakciós módot támogat az alkalmazásokkal: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET stb.), SOAP / REST Webszolgáltatások, FTP, TCP, LDAP, SMTP(S), POP3(S) és IMAP(S), adatbázisok JDBC-n keresztül, képes shell parancsokat végrehajtani és Java objektumokkal dolgozni. A JMeter rendelkezik IDE-vel a teszttervek létrehozásához, hibakereséséhez és végrehajtásához. CLI is rendelkezésre áll bármilyen Java-kompatibilis operációs rendszer parancssorában (Linux, Windows, Mac OS X). Az eszköz képes dinamikusan HTML-jelentést generálni a tesztelésről.
A vállalatunkon belüli használhatóság érdekében, hogy a tesztelők maguk is módosíthassák és hozzáadhassák a környezetet, Docker képek terhelési forrásokhoz készítünk GitLab CI alatt, amelyek a belső Így gyorsabban és egyszerűbben csatlakoztathatók a terheléses teszteléseket lebonyolító pipeline-okhoz. Hogyan végezheti el a docker push-t a registry-be a GitLab CI segítségével — nézze meg a .
A Yandex.Tank alap Docker fájlja ez volt:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Az Apache JMeter számára pedig ez:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]A folyamatos integrációs rendszerünk felépítéséről a "».
Template és pipeline
A terheléses teszteléshez készült sablon példája elérhető a . A olvasható el a sablon használati utasítása. Magában a sablonban (fájl ) megjegyzések vannak arról, hogy egyes lépések milyen feladatokért felelnek.
A sablon nagyon egyszerű, és bemutat három lépést a terheléses tesztelés során, amelyek fentebb a diagramon láthatók: előkészítés, tesztelés és jelentés publikálása. Ezt a : Prepare, Test és Report.
- Fázis kell használni a tesztelési célok előzetes beállítására vagy elérhetőségük ellenőrzésére. A terhelési források környezetét nem szükséges beállítani, ezek előre elkészítve docker képekként vannak, és elérhetők a docker registry-ben: elegendő, ha megadja a szükséges verziót a Test lépésnél. De lehetőség van az újragyártására is, hogy saját módosított képeket készítsen.
- Fázis A terhelési források meghatározására, tesztek futtatására és a tesztelési artefaktumok megőrzésére használható. Bármilyen terhelési forrás választható: Yandex.Tank, Apache JMeter, saját vagy mind együttesen. A nem kívánt források egyszerűen kikapcsolhatók a job megjegyzésbe tétele vagy törlése által. Belépési pontok a terhelési források számára:
- A Yandex.Tank indítási paraméterei a fájlban találhatók.,
- Az Apache JMeter indítási paraméterei a fájlban találhatók .
Megjegyzés: Az építési konfigurációs sablon a CI-rendszerrel való interakció beállítására szolgál, és nem tartalmazza a tesztek logikáját. A tesztekhez meg kell adni a belépési pontot, ahol a vezérlő bash-script található. A tesztek indításának módját, a jelentések létrehozását és a tesztforgatókönyveket a QA mérnököknek kell megvalósítaniuk. A bemutató példában mindkét terhelési forrás esetén a Yandex főoldalának alapvető tesztje található. A forgatókönyvek és a tesztek paraméterei a könyvtárban találhatók .
- A szakaszban le kell írni a tesztelési eredmények külső tárolókba, például GitLab Pages-be történő közzétételének módjait, amelyeket a Teszt szakaszban kaptunk. A GitLab Pages számára szükséges, hogy a tesztelés befejezése után a ./public könyvtár nem legyen üres, és legalább egy index.html fájlt tartalmazzon. A GitLab Pages szolgáltatás működésének sajátosságairól itt olvashat .
Példák, hogyan exportálhat adatokat:
- JMeter-ból a ,
- Yandex.Tank-ból az .
A közzététel beállításához szükséges utasítások:
- HTML statikus fájlok az ,
- InfluxDB-be, majd pedig a .
A bemutató példában a terheléses tesztek és két terhelési forrás (a nem kívánt letiltható) csővezeték így néz ki:
Az Apache JMeter képes önállóan létrehozni HTML-jelentést, ezért érdemes ezt GitLab Pages-en keresztül a beépített eszközökkel megőrizni. Itt látható az Apache JMeter jelentése:
A bemutató példában a Yandex.Tank esetében csak a látható a GitLab Pages részben. A tesztelés során a Tank képes az eredményeket InfluxDB-be menteni, ahonnan például Grafanába is ki lehet őket ábrázolni (a beállítás a fájlban található ). Itt látható, hogyan néz ki a Tank jelentése Grafanában:
Összefoglaló
A cikkben a "terhelés tesztelés mint szolgáltatás" (load testing as a service) koncepcióját ismertem. A fő gondolat az előre beállított terhelési ügynökök, a terhelési források Docker-képeinek, a jelentési rendszerek és a GitLab CI-ben egy egyszerű .gitlab-ci.yml sablon alapján összegyűjtött pipeline használatában rejlik. (példa ). Mindezt egy kis automatizálási mérnöki csapat támogatja, és a termékcsapatok igényeire alapján másolható. Remélem, ez segíteni fog Önnek hasonló megoldás előkészítésében és megvalósításában a vállalatában. Köszönöm a figyelmét!
P. S. Szeretnék köszönetet mondani kollégáimnak, Sergey Kurbanovnak és Nikolai Yusevnek, a load testing as a service koncepció megvalósításához nyújtott technikai segítségükért cégünknél.
Szerző:: — a Positive Technologies fejlesztési technológiai és folyamatvezető helyettese
Forrás: habr.com
