Az egyik probléma, amellyel a többtermékes szoftvergyártók gyakran szembesülnek, a mérnökök – fejlesztők, tesztelők és infrastruktúra-adminisztrátorok – kompetenciáinak megkettőződése szinte minden csapatban. Ez vonatkozik a drága mérnökökre is - a terhelési tesztelés szakértőire.
Ahelyett, hogy közvetlen feladataikat látnák el, és egyedi tapasztalataikat felhasználnák a terhelési tesztelési folyamat felépítésére, módszertan kiválasztására, optimális mérőszámok kiválasztására és a terhelési profiloknak megfelelő automatikus tesztek megírására, a mérnököknek gyakran a nulláról kell üzembe helyezniük a tesztinfrastruktúrát, be kell állítaniuk a betöltési eszközöket és beágyazni azokat. magukat a CI-rendszerekben, létrehozzák a monitoringot és a jelentések közzétételét.
Néhány szervezeti problémára megoldást találhat a Positive Technologies által használt tesztelés során . Ebben pedig arról fogok beszélni, hogy a terhelési teszteket egy közös CI-folyamatba integrálhatjuk a „terheléses tesztelés mint szolgáltatás” (terheléses tesztelés mint szolgáltatás) fogalmával. Megtudhatja, hogyan és mely betöltési források docker-képei használhatók a CI-folyamatban; hogyan lehet betöltési forrásokat csatlakoztatni a CI-projekthez egy összeállítási sablon segítségével; hogyan néz ki a bemutató folyamat a terhelési tesztek futtatásához és az eredmények közzétételéhez. A cikk hasznos lehet azoknak a szoftvertesztelő mérnököknek és automatizálási mérnököknek a CI-ben, akik a betöltési rendszerük architektúráján gondolkodnak.
A koncepció lényege
A terhelési tesztelés szolgáltatásként való koncepciója magában foglalja az Apache JMeter, a Yandex.Tank és a saját keretrendszerek betöltési eszközeinek egy tetszőleges folyamatos integrációs rendszerbe történő integrálásának képességét. A demó a GitLab CI-hez fog szólni, de az alapelvek minden CI-rendszerben közösek.
A terheléstesztelés mint szolgáltatás a terheléstesztelés központosított szolgáltatása. A terhelési tesztek dedikált ügynökkészletekben futnak, az eredményeket automatikusan közzéteszik a GitLab Pages, az Influx DB és a Grafana vagy a tesztjelentési rendszerekben (TestRail, ReportPortal stb.). Az automatizálás és a méretezés a lehető legegyszerűbben valósul meg – a GitLab CI projektben szokásos gitlab-ci.yml sablon hozzáadásával és paraméterezésével.
Ennek a megközelítésnek az az előnye, hogy a teljes CI-infrastruktúrát, a betöltési ügynököket, a betöltési források docker-képeit, a tesztelési folyamatokat és a jelentések közzétételét egy központosított automatizálási osztály (DevOps mérnökök) karbantartja, míg a terheléstesztelő mérnökök a tesztfejlesztésre összpontosíthatják erőfeszítéseiket. és eredményeik elemzése, az infrastrukturális kérdésekkel való foglalkozás nélkül.
A leírás egyszerűsége érdekében feltételezzük, hogy a tesztelés alatt álló célalkalmazás vagy -kiszolgáló már előre telepítve és konfigurálva van (ehhez a Python, SaltStack, Ansible stb. automatizált szkriptjei használhatók). Ezután a terhelési tesztelés, mint szolgáltatás teljes koncepciója három szakaszra oszlik: jelentések elkészítése, tesztelése, közzététele. További részletek a diagramon (minden kép kattintható):
A terheléses tesztelés alapfogalmai és definíciói
A terhelési vizsgálatok elvégzésekor igyekszünk betartani , használja a megfelelő terminológiát és ajánlott mérőszámokat. Röviden felsorolom a terheléses tesztelés főbb fogalmait és definícióit.
Ügynök betöltése - egy virtuális gép, amelyen az alkalmazás elindul - a betöltési forrás (Apache JMeter, Yandex.Tank vagy egy saját maga írt betöltési modul).
Teszt cél (cél) - a kiszolgálóra telepített szerver vagy alkalmazás, amely betöltésre kerül.
Tesztforgatókönyv (teszteset) - paraméterezett lépések halmaza: felhasználói műveletek és ezekre a műveletekre várható reakciók, rögzített hálózati kérésekkel és válaszokkal, a megadott paraméterektől függően.
Profil vagy terhelési terv (profil) - ban ben (4.2.4. szakasz, 43. oldal) a terhelési profilok meghatározzák az adott teszthez kritikus mérőszámokat, valamint a terhelési paraméterek vizsgálat közbeni megváltoztatásának lehetőségeit. Az ábrán láthat példákat a profilokra.
Teszt — egy parancsfájl előre meghatározott paraméterkészlettel.
Tesztterv (teszt-terv) - tesztsorozat és terhelési profil.
Testran (testrun) - egy teszt futtatásának egy iterációja egy teljesen végrehajtott betöltési forgatókönyvvel és a kapott jelentéssel.
Hálózati kérés (kérés) — Egy ügynöktől a célnak küldött HTTP-kérés.
Hálózati válasz (válasz) — HTTP-válasz, amelyet a cél küldött az ügynöknek.
HTTP válaszkód (HTTP válaszok állapota) – szabványos válaszkód az alkalmazáskiszolgálótól.
A tranzakció egy teljes kérés-válasz ciklus. A tranzakció a kérés (kérés) elküldésének kezdetétől a válasz (válasz) beérkezéséig számít.
Tranzakció állapota - sikerült-e sikeresen befejezni a kérés-válasz ciklust. Ha ebben a ciklusban hiba történt, akkor a teljes tranzakció sikertelennek minősül.
Válaszidő (latencia) - a kérés (kérés) elküldésének végétől a válasz (válasz) beérkezésének kezdetéig eltelt idő.
Betöltési mutatók — a terhelt szolgáltatás és a terhelési vizsgálat során meghatározott terhelési tényező jellemzői.
Alapvető mérőszámok a terhelési paraméterek mérésére
Néhány a módszertanban leggyakrabban használt és ajánlott (36., 52. o.) a mutatókat az alábbi táblázat mutatja. Az ügynökre és a célpontra vonatkozó hasonló mutatók ugyanabban a sorban vannak felsorolva.
A betöltési ügynök mérőszámai
A terhelés alatt tesztelt célrendszer vagy alkalmazás mérőszámai
Szám vCPU és a memória RAM,
Korong - a töltőanyag "vas" jellemzői
CPU, Memória, lemezhasználat - CPU, memória és lemezbetöltés dinamikája
a tesztelés folyamatában. Általában százalékában mérik
maximális elérhető értékek
Hálózati áteresztőképesség (on load agent) - áteresztőképesség
hálózati interfész a szerveren,
ahol a betöltési ügynök telepítve van.
Általában bájt per másodpercben (bps) mérik
Hálózati áteresztőképesség(célponton) - hálózati interfész sávszélessége
a célszerveren. Általában bájt per másodpercben (bps) mérik
Virtuális felhasználók- a virtuális felhasználók száma,
terhelési forgatókönyvek megvalósítása és
valódi felhasználói műveletek utánzása
Virtuális felhasználók állapota, Sikeres/Sikertelen/Összesen — sikeres és
a virtuális felhasználók sikertelen állapotai
betöltési forgatókönyvekhez, valamint azok teljes számához.
Általában várható, hogy minden felhasználó képes volt befejezni
a terhelési profilban megadott összes feladatát.
Bármilyen hiba azt jelenti, hogy egy valódi felhasználó nem lesz képes rá
megoldja a problémát, amikor a rendszerrel dolgozik
Kérések másodpercenként (perc)- a hálózati kérések száma másodpercenként (vagy percenként).
A betöltési ügynök fontos jellemzője, hogy hány kérést tud generálni.
Valójában ez az alkalmazáshoz való virtuális felhasználók hozzáférésének utánzata
Válaszok másodpercenként (perc)
- a hálózati válaszok száma másodpercenként (vagy percenként).
A célszolgáltatás fontos jellemzője: mennyi
segítségével generálhat és küldhet válaszokat a lekérdezésekre
rakodószer
HTTP válasz állapota— különböző válaszkódok száma
a betöltési ügynök által kapott alkalmazáskiszolgálóról.
Például a 200 OK sikeres hívást jelent,
és 404 -, hogy az erőforrás nem található
Késleltetés (válaszidő) - a végétől számított idő
kérés (request) küldése a válasz (válasz) fogadásának megkezdése előtt.
Általában milliszekundumban (ms) mérik
Tranzakció válaszidő— egy teljes tranzakció ideje,
a kérés-válasz ciklus befejezése.
Ez az idő a kérés (kérés) elküldésének kezdetétől számítva
a válasz (válasz) beérkezéséig.
A tranzakciós idő másodpercben (vagy percben) mérhető
többféleképpen: vegye figyelembe a minimumot,
maximum, átlag és például a 90. percentilis.
A minimális és maximális értékek szélsőségesek
a rendszer teljesítményének állapota.
A kilencvenes százalékos a leggyakrabban használt,
amint azt a legtöbb felhasználó mutatja,
kényelmesen működik a rendszer teljesítményének küszöbén
Tranzakciók másodpercenként (perc) - a készek száma
tranzakciók másodpercenként (perc),
vagyis mennyit tudott elfogadni a pályázat és
kéréseket feldolgozni és válaszokat kiadni.
Valójában ez a rendszer áteresztőképessége
Tranzakció állapota , Sikerült / Sikertelen / Összesen - szám
sikeres, sikertelen és a tranzakciók teljes száma.
Valódi felhasználóknak sikertelen
a tranzakció valójában azt fogja jelenteni
képtelenség a terhelés alatti rendszerrel dolgozni
Terhelésvizsgálati sematikus diagram
A terheléses tesztelés koncepciója nagyon egyszerű, és három fő szakaszból áll, amelyeket már említettem: Készíts-Teszt-Jelentés, azaz a tesztcélok elkészítése és a betöltési források paramétereinek beállítása, majd a terhelési tesztek végrehajtása, és a végén tesztjelentés generálása és közzététele.
Sematikus megjegyzések:
- A QA.Tester a terheléses tesztelés szakértője,
- A Target az a célalkalmazás, amelynek terhelés alatti viselkedését szeretné tudni.
Entitások, szakaszok és lépések osztályozója a diagramban
Szakaszok és lépések
Mi történik
Mi van a bejáratnál
Mi a kimenet
Felkészülés: felkészülési szakasz a tesztelésre
LoadParameters
Beállítás és inicializálás
felhasználó
terhelési paraméterek,
a mérőszámok megválasztása és
tesztterv elkészítése
(profil betöltése)
Egyéni opciók a
betöltési ügynök inicializálása
Teszt terv
A tesztelés célja
VM
Felhő telepítése
virtuális géppel
szükséges jellemzőket
Virtuálisgép-beállítások betöltési ügynökhöz
Automatizálási szkriptek a
VM létrehozása
A virtuális gép be van állítva
felhő
env
OS beállítása és előkészítése
környezet számára
rakományügynöki munka
Környezeti beállítások a következőhöz:
rakodó ügynök
Automatizálási szkriptek a
környezeti beállításokat
Előkészített környezet:
OS, szolgáltatások és alkalmazások,
munkához szükséges
rakodó ügynök
LoadAgents
Telepítés, konfiguráció és paraméterezés
rakodószer.
Vagy tölts le egy docker képet innen
előre konfigurált betöltési forrás
Forrás docker kép betöltése
(YAT, JM vagy saját maga írt keretrendszer)
Beállítások
rakodó ügynök
Beállítás és kész
terhelési ügynöknek dolgozni
Teszt: a terhelési tesztek végrehajtásának szakasza. A források a GitLab CI dedikált ügynökkészleteiben telepített betöltési ügynökök
Terhelés
A Load Agent indítása
kiválasztott teszttervvel
és a terhelési paramétereket
Felhasználói beállítások
inicializáláshoz
rakodó ügynök
Teszt terv
A tesztelés célja
Végrehajtási naplók
terhelési tesztek
Rendszernaplók
A célmetrikák és a terhelési ügynök változásainak dinamikája
Fuss ügynökök
Ügynökvégrehajtás
rengeteg tesztszkript
vminek megfelelően
terhelési profil
Az ügynök interakció betöltése
tesztelés céljából
Teszt terv
A tesztelés célja
Naplók
"Nyers" naplók gyűjteménye
terhelési vizsgálat során:
betöltési ügynök tevékenységi rekordok,
a tesztcél állapota
és az ügynököt futtató virtuális gép
Végrehajtási naplók
terhelési tesztek
Rendszernaplók
Metrics
"Nyers" mutatók gyűjtése a tesztelés során
A célmutatók változásának dinamikája
és rakodóügynök
Jelentés: tesztjelentés elkészítési szakasza
Generátor
Feldolgozás összegyűjtve
rakodórendszer és
felügyeleti rendszer "nyers"
mérőszámok és naplók
Jelentés készítése ben
ember által olvasható formában
elemekkel lehetséges
elemzők
Végrehajtási naplók
terhelési tesztek
Rendszernaplók
A mérőszámok változásának dinamikája
cél- és betöltési ügynök
Feldolgozott "nyers" naplók
megfelelő formátumban
feltölt a külső tárhelyre
Statikus terhelés jelentés,
ember által olvasható
Közzétesz
A jelentés közzététele
a terhelésről
külső tesztelés
szolgáltatás
Feldolgozott "nyers"
megfelelő formátumban naplózza
külsőre történő kirakodáshoz
adattárak
Külsőben mentve
tárolási jelentések
teher, alkalmas
emberi elemzéshez
Terhelési források csatlakoztatása CI-sablonban
Térjünk át a gyakorlati részre. Meg akarom mutatni, hogyan kell a cég egyes projektjeiben a terheléses tesztelés, mint szolgáltatás koncepcióját valósítottuk meg.
Először is, DevOps mérnökeink segítségével létrehoztunk egy dedikált ügynökkészletet a GitLab CI-ben a terhelési tesztek futtatásához. Annak érdekében, hogy ne keverjük össze őket a sablonokban másokkal, például az összeállítási készletekben, címkéket adtunk ezekhez az ügynökökhöz, : Betöltés. Bármilyen más érthető címkét használhat. Kérdeznek GitLab CI futók.
Hogyan lehet megtudni a szükséges teljesítményt hardverrel? A betöltési ügynökök jellemzői - kellő számú vCPU, RAM és lemez - kiszámítható az alapján, hogy az ügynökön futnia kell a Dockernek, a Pythonnak (Yandex.Tank), a GitLab CI agentnek, a Java-nak (Apache JMeterhez). . Java alatt JMeter alatt is javasolt minimum 512 MB RAM használata, és felső határként .
Így tapasztalataink alapján legalább 4 vCPU, 4 GB RAM, 60 GB SSD használatát javasoljuk betöltési ügynökökhöz. A hálózati kártya áteresztőképességét a terhelési profil követelményei alapján határozzák meg.
Főleg két betöltési forrást használunk - Apache JMeter és Yandex.Tank docker képeket.
a Yandex nyílt forráskódú eszköze terhelési teszteléshez. Moduláris architektúrája a Phantom nagy teljesítményű aszinkron találat-alapú HTTP-kérésgenerátorán alapul. A tank beépített monitorozással rendelkezik a tesztelt szerver erőforrásairól SSH protokollon keresztül, meghatározott körülmények között automatikusan le tudja állítani a tesztet, képes megjeleníteni az eredményeket konzolon és grafikonok formájában is, csatlakoztathatja moduljait a funkcionalitás bővítése érdekében. Egyébként a Tankot akkor használtuk, amikor még nem volt mainstream. A cikkben "» elolvashatja a történetet, hogyan végeztünk vele terhelési tesztet 2013-ban cégünk egyik terméke.
egy nyílt forráskódú terhelési tesztelő eszköz az Apache-tól. Egyformán jól használható statikus és dinamikus webalkalmazások tesztelésére is. A JMeter számos protokollt és módot támogat az alkalmazásokkal való interakcióhoz: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET stb.), SOAP / REST webszolgáltatások, FTP, TCP, LDAP, SMTP(S), POP3( Az S) ) és az IMAP(S), a JDBC-n keresztüli adatbázisok shell-parancsokat hajthatnak végre, és dolgozhatnak Java objektumokkal. A JMeter rendelkezik egy IDE-vel a teszttervek létrehozásához, hibakereséséhez és végrehajtásához. Minden Java-kompatibilis operációs rendszeren (Linux, Windows, Mac OS X) van egy CLI is a parancssori műveletekhez. Az eszköz dinamikusan tud létrehozni egy HTML tesztjelentést.
A vállalatunkon belüli egyszerűbb használat érdekében, hogy maguk a tesztelők módosíthassák és hozzáadhassák a környezetet, a GitLab CI-n lévő betöltési források docker képeiből készítettünk buildeket, amelyeket a belső oldalon tettünk közzé. . Ez gyorsabbá és egyszerűbbé teszi a csővezetékekbe történő csatlakoztatását a terhelési tesztekhez. Hogyan lehet a docker push-t a regisztrációs adatbázisba küldeni GitLab CI-n keresztül - lásd .
Ezt az alapvető docker fájlt vettük a Yandex.Tank számára:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Az Apache JMeterhez pedig ez:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]A folyamatos integrációs rendszerünk működéséről a cikkben olvashat.".
Sablon és csővezeték
A projektben található egy példa a terhelési tesztek végrehajtására szolgáló sablonra . -Ban Elolvashatja a sablon használati utasítását. Magában a sablonban (fájl ) megjegyzések találhatók arról, hogy az egyes lépések miért felelősek.
A sablon nagyon egyszerű, és a terhelési tesztelés három szakaszát mutatja be, amelyeket a fenti diagram ismertet: a jelentések elkészítését, tesztelését és közzétételét. Felelős ezért : Felkészülés, tesztelés és jelentés.
- Színpad a tesztcélok előre konfigurálására vagy elérhetőségük ellenőrzésére kell használni. A betöltési források környezetét nem kell konfigurálni, ezek előre be vannak építve docker képként, és felkerülnek a docker registry-be: csak adja meg a kívánt verziót a teszt szakaszban. De újraépítheti őket, és elkészítheti saját módosított képeit.
- Színpad a betöltési forrás megadására, a tesztek futtatására és a tesztműtermékek tárolására szolgál. Bármilyen betöltési forrást választhat: Yandex.Tank, Apache JMeter, saját vagy együtt. A szükségtelen források letiltásához írja be megjegyzéseit vagy törölje a munkát. Belépési pontok a terhelési forrásokhoz:
- A Yandex.Tank indítási paramétereit a .,
- Az Apache JMeter indítási paraméterei a fájlban vannak megadva .
Megjegyzés: Az összeállítás konfigurációs sablonja a CI rendszerrel való interakció beállítására szolgál, és nem jelenti azt, hogy tesztlogikát kell elhelyezni benne. A teszteknél meg van adva a belépési pont, ahol a vezérlő bash szkript található. A tesztek futtatásának, a jelentések készítésének módszerét és magukat a tesztszkripteket a minőségbiztosítási mérnököknek kell megvalósítaniuk. A demóban mindkét betöltési forrás esetében a Yandex főoldali kérése a legegyszerűbb teszt. A szkriptek és a tesztparaméterek a könyvtárban vannak .
- A színpadon le kell írnia, hogyan lehet a Teszt szakaszban kapott teszteredményeket közzétenni külső tárolókon, például GitLab oldalakon vagy speciális jelentési rendszereken. A GitLab Pages megköveteli, hogy a ./public könyvtár ne legyen üres, és a tesztek befejezése után tartalmazzon legalább egy index.html fájlt. A GitLab Pages szolgáltatás árnyalatairól olvashat. .
Példák az adatok exportálására:
- JMetertől ig ,
- a Yandex.Tanktól a .
A közzététel beállítási útmutatója:
- HTML statika be ,
- az InfluxDB-be, majd a .
A demópéldában a terhelési tesztekkel és két terhelési forrással (a szükségtelent letilthatja) a folyamat így néz ki:
Az Apache JMeter maga is tud HTML jelentést generálni, így kifizetődőbb, ha szabványos eszközökkel GitLab Pagesbe menti. Így néz ki az Apache JMeter jelentés:
A Yandex.Tank bemutató példájában csak azt fogja látni a GitLab oldalak szakaszában. A tesztelés során a Tank el tudja menteni az eredményeket az InfluxDB adatbázisba, és onnan például a Grafanában megjeleníthető (a beállítás a fájlban történik ). Így néz ki Tank jelentése a Grafanában:
Összegzés
A cikkben beszéltem a "terhelési tesztelés mint szolgáltatás" (terheléses tesztelés mint szolgáltatás) fogalmáról. A fő ötlet az, hogy a betöltési ügynökök előre konfigurált készletei, a betöltési források docker képei, a jelentési rendszerek és egy olyan folyamat, amely ezeket a GitLab CI-ben kombinálja egy egyszerű .gitlab-ci.yml sablon alapján (példa ). Mindezt automatizálási mérnökök kis csapata támogatja, és a termékcsapatok kérésére megismétlik. Remélem, ez segít Önnek egy hasonló rendszer előkészítésében és bevezetésében az Ön cégében. Köszönöm a figyelmet!
PS Szeretnék köszönetet mondani kollégáimnak, Szergej Kurbanovnak és Nyikolaj Jusevnek, hogy technikai segítséget nyújtottak a terheléses tesztelés koncepciójának, mint szolgáltatásnak cégünkben történő megvalósításához.
Szerző: - Helyettes A Positive Technologies technológiák és fejlesztési folyamatok (DevOps) vezetője
Forrás: will.com