Yksi usean tuotteen ohjelmistotoimittajien usein kohtaamista ongelmista on insinöörien – kehittäjien, testaajien ja infrastruktuurin ylläpitäjien – pätevyyden päällekkäisyys lähes jokaisessa tiimissä. Tämä koskee myös kalliita insinöörejä - kuormitustestauksen asiantuntijoita.
Sen sijaan, että insinöörit suorittaisivat suoria tehtäviään ja käyttäisivät ainutlaatuista kokemustaan kuormitustestausprosessin rakentamiseen, metodologian, optimaaliset mittarit ja automaattisten testien kirjoittamisen kuormitusprofiilien mukaisesti, insinöörien on usein otettava testiinfrastruktuuri käyttöön alusta alkaen, määritettävä lataustyökalut ja upotettava ne. CI-järjestelmissä, perustaa seurantaa ja raporttien julkaisemista.
Voit löytää ratkaisuja joihinkin organisaatioongelmiin Positive Technologiesissa käyttämämme testauksen avulla . Ja tässä puhun mahdollisuudesta integroida kuormitustestit yhteiseen CI-putkilinjaan käyttämällä käsitettä "kuormitustestaus palveluna" (kuormitustestaus palveluna). Opit kuinka ja mitä kuormalähteiden Docker-kuvia voidaan käyttää CI-putkessa; kuinka liität latauslähteitä CI-projektiisi koontimallin avulla; miltä demoputki näyttää kuormitustestien suorittamista ja tulosten julkaisemista varten. Artikkeli voi olla hyödyllinen ohjelmistotestausinsinööreille ja CI:n automaatioinsinööreille, jotka miettivät kuormajärjestelmänsä arkkitehtuuria.
Konseptin ydin
Kuormitustestauksen käsite palveluna tarkoittaa kykyä integroida lataustyökalut Apache JMeter, Yandex.Tank ja omat puitteet mielivaltaiseksi jatkuvaksi integraatiojärjestelmäksi. Demo on GitLab CI:lle, mutta periaatteet ovat yhteiset kaikille CI-järjestelmille.
Kuormitustestaus palveluna on keskitetty kuormitustestauspalvelu. Kuormitustestit suoritetaan omistetuissa agenttipooleissa, tulokset julkaistaan automaattisesti GitLab Pagesissa, Influx DB:ssä ja Grafanassa tai testiraportointijärjestelmissä (TestRail, ReportPortal jne.). Automatisointi ja skaalaus toteutetaan mahdollisimman yksinkertaisesti - lisäämällä ja parametroimalla GitLab CI -projektissa tavallinen gitlab-ci.yml-malli.
Tämän lähestymistavan etuna on, että keskitetty automaatioosasto (DevOps-insinöörit) ylläpitää koko CI-infrastruktuuria, latausagentteja, latauslähteiden telakointikuvia, testausputkia ja raporttien julkaisemista, kun taas kuormitustestausinsinöörit voivat keskittyä testien kehittämiseen. ja niiden tulosten analysointi ilman infrastruktuurikysymyksiä.
Kuvauksen yksinkertaisuuden vuoksi oletetaan, että testattava kohdesovellus tai -palvelin on jo otettu käyttöön ja määritetty etukäteen (tähän voidaan käyttää automatisoituja skriptejä Pythonissa, SaltStackissa, Ansiblessa jne.). Sitten koko kuormitustestauksen konsepti palveluna sopii kolmeen vaiheeseen: raporttien valmistelu, testaus, julkaiseminen. Tarkemmat tiedot kaaviosta (kaikki kuvat ovat napsautettavissa):
Peruskäsitteet ja määritelmät kuormitustestauksessa
Kun suoritamme kuormitustestejä, pyrimme noudattamaan , käytä asianmukaista terminologiaa ja suositeltuja mittareita. Annan lyhyen luettelon kuormitustestauksen tärkeimmistä käsitteistä ja määritelmistä.
Lataa agentti - virtuaalikone, jolla sovellus käynnistetään - latauslähde (Apache JMeter, Yandex.Tank tai itse kirjoitettu latausmoduuli).
Testitavoite (tavoite) - palvelimelle asennettu palvelin tai sovellus, jota kuormitetaan.
Testiskenaario (testitapaus) - joukko parametroituja vaiheita: käyttäjän toimet ja odotetut reaktiot näihin toimiin, kiinteät verkkopyynnöt ja vastaukset määritetyistä parametreista riippuen.
Profiili tai kuormasuunnitelma (profiili) - klo (Osa 4.2.4, s. 43) kuormitusprofiilit määrittelevät mittareita, jotka ovat kriittisiä tietyssä testissä, ja vaihtoehdot kuormitusparametrien muuttamiseen testin aikana. Voit nähdä esimerkkejä profiileista kuvasta.
Testata — komentosarja, jossa on ennalta määrätty parametrijoukko.
Testisuunnitelma (testisuunnitelma) - testisarja ja kuormitusprofiili.
Testran (testrun) - yksi iteraatio, jossa suoritetaan yksi testi täysin suoritetulla latausskenaariolla ja vastaanotetulla raportilla.
Verkkopyyntö (pyyntö) — HTTP-pyyntö, jonka agentti lähettää kohteeseen.
Verkkovastaus (vastaus) — HTTP-vastaus, jonka kohde lähettää agentille.
HTTP-vastauskoodi (HTTP-vastausten tila) - standardi vastauskoodi sovelluspalvelimelta.
Tapahtuma on täydellinen pyyntö-vastausjakso. Tapahtuma lasketaan pyynnön (pyynnön) lähettämisen alusta vastauksen (vastauksen) vastaanottamisen loppuun.
Tapahtuman tila - oliko pyyntö-vastausjakso onnistuneesti suoritettu loppuun. Jos tässä jaksossa oli virhe, koko tapahtuma katsotaan epäonnistuneeksi.
Vasteaika (latenssi) - aika pyynnön (pyynnön) lähettämisen päättymisestä vastauksen (vastauksen) vastaanottamisen alkuun.
Lataa mittareita — kuormitetun palvelun ja kuormitusagentin ominaisuudet, jotka määritetään kuormitustestausprosessissa.
Perusmittarit kuormitusparametrien mittaamiseen
Jotkut menetelmässä yleisimmin käytetyistä ja suositelluista (s. 36, 52) mittarit näkyvät alla olevassa taulukossa. Samanlaiset tiedot agentille ja kohteelle on lueteltu samalla rivillä.
Latausagentin mittarit
Kohdejärjestelmän tai -sovelluksen mittarit, joita testataan kuormituksen alaisena
Määrä vCPU ja muisti RAM,
Levy - kuormitusaineen "rauta"-ominaisuudet
prosessori, Muisti, levyn käyttö - CPU:n, muistin ja levyn latausdynamiikka
testausprosessissa. Yleensä mitataan prosentteina
suurimmat käytettävissä olevat arvot
Verkon suorituskyky (kuormitusagentti) - läpijuoksu
verkkoliitäntä palvelimella,
mihin latausagentti on asennettu.
Yleensä mitataan tavuina sekunnissa (bps)
Verkon suorituskyky(kohteessa) - verkkoliitännän kaistanleveys
kohdepalvelimella. Yleensä mitataan tavuina sekunnissa (bps)
Virtuaaliset käyttäjät- virtuaalisten käyttäjien määrä,
kuormitusskenaarioiden toteuttaminen ja
jäljitellä todellisia käyttäjän toimia
Virtuaalikäyttäjien tila, Hyväksytty/Epäonnistunut/Yhteensä — onnistuneiden ja
virtuaalisten käyttäjien epäonnistuneet tilat
latausskenaarioihin sekä niiden kokonaismäärään.
Yleensä odotetaan, että kaikki käyttäjät pystyivät suorittamaan
kaikki kuormitusprofiilissa määritellyt tehtäväsi.
Mikä tahansa virhe tarkoittaa, että oikea käyttäjä ei pysty siihen
ratkaise ongelmasi työskennellessäsi järjestelmän kanssa
Pyyntöjä sekunnissa (minuutti)- verkkopyyntöjen määrä sekunnissa (tai minuutissa).
Tärkeä latausagentin ominaisuus on se, kuinka monta pyyntöä se voi luoda.
Itse asiassa tämä on jäljitelmä virtuaalisten käyttäjien pääsystä sovellukseen
Vastauksia sekunnissa (minuutti)
- verkon vastausten määrä sekunnissa (tai minuutissa).
Tärkeä kohdepalvelun ominaisuus: kuinka paljon
luoda ja lähettää vastauksia kyselyihin
lastausagentti
HTTP-vastauksen tila— eri vastauskoodien määrä
latausagentin vastaanottamalta sovelluspalvelimelta.
Esimerkiksi 200 OK tarkoittaa onnistunutta puhelua,
ja 404 - että resurssia ei löytynyt
Viive (vasteaika) - aika lopusta
pyynnön (pyynnön) lähettäminen ennen vastauksen (vastauksen) vastaanottamista.
Yleensä mitataan millisekunteina (ms)
Tapahtuman vasteaika— yhden täyden tapahtuman aika,
pyyntö-vastaussyklin loppuun.
Tämä on aika pyynnön (pyynnön) lähettämisen alusta
kunnes vastaus (vastaus) on saatu päätökseen.
Tapahtuma-aika voidaan mitata sekunneissa (tai minuutteissa)
useilla tavoilla: harkitse minimiä,
maksimi, keskiarvo ja esimerkiksi 90. prosenttipiste.
Pienin ja maksimi lukemat ovat äärimmäisiä
järjestelmän suorituskyvyn tila.
Yhdeksäskymmenes prosenttipiste on yleisimmin käytetty,
kuten useimmat käyttäjät osoittavat,
mukavasti järjestelmän suorituskyvyn kynnyksellä
Tapahtumat sekunnissa (minuutti) - kokonaisten lukumäärä
tapahtumat sekunnissa (minuutti),
eli kuinka paljon hakemus pystyi hyväksymään ja
käsitellä pyyntöjä ja antaa vastauksia.
Itse asiassa tämä on järjestelmän läpimenokyky
Tapahtuman tila , Hyväksytty / Epäonnistui / Yhteensä - numero
onnistuneet, epäonnistuneet ja tapahtumien kokonaismäärä.
Todellisille käyttäjille epäonnistunut
kauppa todella tarkoittaa
kyvyttömyys työskennellä kuormitetun järjestelmän kanssa
Kuormatestauksen kaavio
Kuormitustestauksen käsite on hyvin yksinkertainen ja koostuu kolmesta päävaiheesta, jotka olen jo maininnut: Valmistele-testi-raportti, eli testitavoitteiden valmistelu ja parametrien asettaminen latauslähteille, sitten kuormitustestien suorittaminen ja lopuksi testiraportin luominen ja julkaiseminen.
Kaavamaiset huomautukset:
- QA.Tester on kuormitustestauksen asiantuntija,
- Target on kohdesovellus, jonka toimintaa kuormitettaessa haluat tietää.
Kaavion entiteettien, vaiheiden ja vaiheiden luokitin
Vaiheet ja vaiheet
Mitä tapahtuu
Mitä on sisäänkäynnissä
Mikä on tulos
Valmistelu: valmisteluvaihe testausta varten
LoadParameters
Asetus ja alustus
käyttäjä
latausparametrit,
mittareiden valinta ja
testisuunnitelman valmistelu
(lataa profiili)
Mukautetut vaihtoehdot
latausagentin alustus
Testisuunnitelma
Testauksen tarkoitus
VM
Pilvien käyttöönotto
virtuaalikoneen kanssa
vaaditut ominaisuudet
VM-asetukset latausagentille
Automaatioskriptit for
VM:n luominen
VM määritetty sisään
pilvi
env
Käyttöjärjestelmän asennus ja valmistelu
ympäristöä varten
kuorma-agentin työ
Ympäristöasetukset kohteelle
kuorma-agentti
Automaatioskriptit for
ympäristöasetukset
Valmistettu ympäristö:
käyttöjärjestelmä, palvelut ja sovellukset,
työlle välttämätön
kuorma-agentti
LoadAgents
Asennus, konfigurointi ja parametrointi
lastausagentti.
Tai lataa docker-kuva osoitteesta
esikonfiguroitu latauslähde
Lataa lähdetelakkakuva
(YAT, JM tai itse kirjoitettu kehys)
asetukset
kuorma-agentti
Asetettu ja valmis
töihin kuorma-agentti
Testi: kuormitustestien suoritusvaihe. Lähteet ovat latausagentteja, jotka on otettu käyttöön GitLab CI:n erityisissä agenttipoolissa
Ladata
Load Agentin käynnistäminen
valitulla testisuunnitelmalla
ja latausparametreja
Käyttäjän asetukset
alustusta varten
kuorma-agentti
Testisuunnitelma
Testauksen tarkoitus
Toteutuslokit
kuormitustestit
Järjestelmälokit
Tavoitteen mittareiden ja kuormitusagentin muutosten dynamiikka
Suorita agentit
Agentin toteutus
paljon testiskriptejä
mukaisesti
kuormitusprofiili
Lataa agentin vuorovaikutus
testausta varten
Testisuunnitelma
Testauksen tarkoitus
Lokit
Kokoelma "raakoja" lokeja
kuormitustestauksen aikana:
latausagentin toimintatietueet,
testikohteen tila
ja agenttia pyörittävä VM
Toteutuslokit
kuormitustestit
Järjestelmälokit
Metrics
Kerää "raakoja" mittareita testauksen aikana
Tavoitteen mittareiden muutosten dynamiikka
ja kuorma-agentti
Raportti: testiraportin valmisteluvaihe
Generaattori
Käsittely kerätty
latausjärjestelmä ja
seurantajärjestelmä "raaka"
mittareita ja lokeja
Raportin muodostaminen sisään
ihmisen luettavassa muodossa
mahdollista elementeillä
analyytikot
Toteutuslokit
kuormitustestit
Järjestelmälokit
Mittareiden muutosten dynamiikka
kohde ja kuorma-agentti
Käsitellyt "raa'at" lokit
sopivassa muodossa
lataukset ulkoiseen tallennustilaan
Staattinen kuormitusraportti,
ihmisen luettavissa
julkaista
Raportin julkaiseminen
kuormasta
ulkoinen testaus
palvelu
Käsitelty "raaka"
lokit sopivassa muodossa
purkamiseen ulkopuolelta
arkistot
Tallennettu ulkoiseen
tallennusraportit päällä
kuorma, sopiva
ihmisen analyysiin
Kuormalähteiden yhdistäminen CI-mallissa
Siirrytään käytännön osaan. Haluan näyttää kuinka joissain projekteissa yrityksessä olemme ottaneet käyttöön kuormitustestauksen konseptin palveluna.
Ensin DevOps-insinööriemme avulla loimme GitLab CI:n agenttijoukon kuormitustestien suorittamista varten. Jotta niitä ei sekoitettaisi malleissa muihin, kuten kokoonpanopooliin, lisäsimme näihin agenteihin tunnisteita, : kuorma. Voit käyttää mitä tahansa muita ymmärrettäviä tunnisteita. He kysyvät GitLab CI Runners.
Kuinka selvittää tarvittava teho laitteiston avulla? Latausagenttien ominaisuudet - riittävä määrä vCPU:ta, RAM-muistia ja levyä - voidaan laskea sen perusteella, että Dockerin, Pythonin (Yandex.Tank), GitLab CI -agentin, Javan (Apache JMeterille) pitäisi olla käynnissä agentissa. . Javaa varten JMeterin alla on myös suositeltavaa käyttää vähintään 512 Mt RAM-muistia ja ylärajana .
Siksi suosittelemme kokemuksemme perusteella vähintään 4 vCPU:n, 4 Gt RAM:n ja 60 Gt SSD:n käyttöä latausagenteille. Verkkokortin suorituskyky määräytyy kuormitusprofiilin vaatimusten perusteella.
Käytämme pääasiassa kahta latauslähdettä - Apache JMeter ja Yandex.Tank Docker -kuvia.
on Yandexin avoimen lähdekoodin työkalu kuormitustestaukseen. Sen modulaarinen arkkitehtuuri perustuu Phantomin korkean suorituskyvyn asynkroniseen osumapohjaiseen HTTP-pyyntögeneraattoriin. Säiliössä on sisäänrakennettu testattavan palvelimen resurssien valvonta SSH-protokollan kautta, se voi pysäyttää testin automaattisesti tietyissä olosuhteissa, näyttää tulokset sekä konsolissa että kaavioiden muodossa, voit yhdistää moduulisi siihen toiminnallisuuden laajentamiseksi. Muuten, käytimme Tankia, kun se ei vielä ollut valtavirtaa. Artikkelissa "» voit lukea tarinan siitä, kuinka suoritimme kuormitustestauksen sillä vuonna 2013 on yksi yrityksemme tuotteista.
on Apachen avoimen lähdekoodin kuormitustestaustyökalu. Sitä voidaan käyttää yhtä hyvin sekä staattisten että dynaamisten verkkosovellusten testaamiseen. JMeter tukee valtavaa määrää protokollia ja tapoja olla vuorovaikutuksessa sovellusten kanssa: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET jne.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ja IMAP(S), tietokannat JDBC:n kautta, voivat suorittaa komentotulkkikomentoja ja työskennellä Java-objektien kanssa. JMeterillä on IDE testisuunnitelmien luomiseen, virheenkorjaukseen ja suorittamiseen. Siellä on myös CLI komentorivikäyttöä varten missä tahansa Java-yhteensopivassa käyttöjärjestelmässä (Linux, Windows, Mac OS X). Työkalu voi luoda dynaamisesti HTML-testiraportin.
Helpottaaksemme käyttöä yrityksessämme, jotta testaajat voisivat itse muuttaa ja lisätä ympäristöä, teimme GitLab CI:n latauslähteiden telakointikuvia, jotka julkaistaan sisäisessä . Tämä nopeuttaa ja helpottaa niiden liittämistä putkiin kuormitustestejä varten. Kuinka tehdä Docker push rekisteriin GitLab CI:n kautta - katso .
Otimme tämän perustelakkatiedoston Yandex.Tankille:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Ja Apache JMeterille tämä:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Voit lukea kuinka jatkuva integraatiojärjestelmämme toimii artikkelista "'.
Malli ja putki
Projektissa on esimerkki mallista kuormitustestien suorittamista varten . Sisään Voit lukea mallin käyttöohjeet. Itse mallissa (tiedosto ) on huomautuksia siitä, mistä kukin vaihe on vastuussa.
Malli on hyvin yksinkertainen ja näyttää kolme yllä olevassa kaaviossa kuvattua kuormitustestauksen vaihetta: raporttien valmistelu, testaus ja julkaiseminen. Tästä vastuussa : Valmista, testaa ja raportoi.
- vaihe tulee käyttää testikohteiden esikonfigurointiin tai niiden saatavuuden tarkistamiseen. Latauslähteiden ympäristöä ei tarvitse määrittää, ne on valmiiksi rakennettu telakointikuviksi ja lähetetty telakointiaseman rekisteriin: määritä vain haluamasi versio Testivaiheessa. Mutta voit rakentaa ne uudelleen ja tehdä omia muokattuja kuviasi.
- vaihe käytetään latauslähteen määrittämiseen, testien suorittamiseen ja testiartefaktien tallentamiseen. Voit valita minkä tahansa latauslähteen: Yandex.Tank, Apache JMeter, omasi tai kaikki yhdessä. Voit poistaa tarpeettomat lähteet käytöstä kommentoimalla tai poistamalla työtehtävän. Latauslähteiden sisääntulokohdat:
- Yandex.Tank-käynnistysparametrit on määritetty kohdassa .,
- Apache JMeterin käynnistysparametrit on määritetty tiedostossa .
Huomautus: Kokoonpanon konfigurointimallia käytetään vuorovaikutuksen määrittämiseen CI-järjestelmän kanssa, eikä se tarkoita testilogiikan sijoittamista siihen. Testejä varten määritetään aloituspiste, jossa ohjausbash-komentosarja sijaitsee. Testien suorittamisen, raporttien luomisen ja itse testikomentosarjat on otettava käyttöön laadunvarmistusinsinöörien toimesta. Demossa molemmissa latauslähteissä Yandex-pääsivupyyntöä käytetään yksinkertaisimpana testinä. Skriptit ja testiparametrit ovat hakemistossa .
- Lavalla sinun tulee kuvata, kuinka Testivaiheessa saadut testitulokset julkaistaan ulkoisille tallennusvälineille, esimerkiksi GitLab-sivuille tai erityisiin raportointijärjestelmiin. GitLab Pages edellyttää, että ./public-hakemisto ei ole tyhjä ja sisältää vähintään index.html-tiedoston testien jälkeen. Voit lukea GitLab Pages -palvelun vivahteista. .
Esimerkkejä tietojen viemisestä:
- JMeteristä kohteeseen ,
- Yandex.Tankista osoitteeseen .
Julkaisun asennusohjeet:
- HTML-statiikka sisään ,
- InfluxDB:hen ja sitten kohteeseen .
Demoesimerkissä putki, jossa on kuormitustestit ja kaksi kuormituslähdettä (voit poistaa tarpeettoman käytöstä), näyttää tältä:
Apache JMeter voi luoda HTML-raportin itse, joten se on kannattavampaa tallentaa GitLab-sivuille vakiotyökaluilla. Apache JMeter -raportti näyttää tältä:
Yandex.Tank-esittelyssä näet vain GitLab-sivujen osiossa. Testauksen aikana Tank voi tallentaa tulokset InfluxDB-tietokantaan ja sieltä ne voidaan näyttää esimerkiksi Grafanassa (asetukset tehdään tiedostossa ). Tältä Tankin raportti näyttää Grafanassa:
Yhteenveto
Artikkelissa puhuin käsitteestä "kuormitustestaus palveluna" (kuormitustestaus palveluna). Pääideana on käyttää infrastruktuuria valmiiksi määritettyjen latausagenttien poolien, latauslähteiden telakointikuvien, raportointijärjestelmien ja putkilinjan avulla, joka yhdistää ne GitLab CI:ssä yksinkertaisen .gitlab-ci.yml-mallin pohjalta (esimerkki ). Kaikkea tätä tukee pieni automaatioinsinöörien tiimi ja kopioidaan tuotetiimien pyynnöstä. Toivon, että tämä auttaa sinua valmistelemaan ja toteuttamaan vastaavanlainen suunnitelma yrityksessäsi. Kiitos huomiostasi!
PS Haluan sanoa suuret kiitokset kollegoilleni Sergey Kurbanov ja Nikolai Yusev teknisestä avusta kuormitustestauksen konseptin toteuttamisessa palveluna yrityksessämme.
Kirjoittaja: - Varajäsen Teknologia- ja kehitysprosessien (DevOps) johtaja, Positive Technologies
Lähde: will.com