BlazeMeter Jõudlustestimisest kaugemale: pideva testimise selgitus

Kui meeskonnad otsivad esimest korda testimislahendust, on neil sageli konkreetne probleem, millega nad peavad tegelema. Võib-olla kukkus veebisait musta reede soodusmüügi ajal kokku või kurdavad kasutajad aeglase kassasse mineku aegade üle. Sellistel hetkedel on jõudlustestimine prioriteet. Paljud organisatsioonid pöörduvad selle poole. BlazeMeter sest see on tuntud avatud lähtekoodiga skriptide massilise käitamise poolest.

Siiski, vaadates BlazeMeter Rangelt koormustestimise tööriistana ei näe see suuremat pilti. Minu arvates, omades üle kahe aastakümne kogemust, ütleksin, et jõudlustestimine on sageli küpsuse värav, mis tähendab, et see on alles esimene samm. Kaasaegne tarkvaraarendus vajab strateegiat, mis hõlmab kõiki arendusetappe. eluring, mitte ainult lõpp.

Tarkvara kiireks ja tõrgeteta avaldamiseks soovitan meeskondadel liikuda aeg-ajalt tehtavate jõudlustestide asemel ühtse ja pideva testimisplatvormi loomisele. Selles artiklis uurime, kuidas liikuda lihtsast koormuse genereerimisest kaugemale. Saate teada, kuidas luua terviklik kvaliteedistrateegia, mis hõlmab funktsionaalset testimist, API jälgimist, testandmeid ja teenuste virtualiseerimist – kõik ühes keskkonnas.

Miks on jõudlustestimine loomulik sisenemispunkt

Jõudlustestimine on kõige levinum alguspunkt sel lihtsal põhjusel: jõudlusvea on avalik tõrge. Kui ilmneb funktsionaalne viga, võib see mõjutada ühte kasutajat, kes üritab kasutada konkreetset funktsiooni. Seega, kui ilmneb jõudlusprobleem, aeglustub kogu rakendus või jookseb kokku kõigi jaoks.

Kuna need probleemid on ärikriitilised, pööratakse neile kohest tähelepanu. Kui meeskonnad alustavad koormustestimist, avastavad nad minu tähelepanekute kohaselt sageli enamat kui lihtsalt serveri piirangud. Suur koormustest toimib nagu stressitest kogu teie operatiivtorustikule. See paljastab sageli:

• Testiandmete lüngad: Sa mõistad, et sul pole piisavalt unikaalseid kasutajakirjeid, et simuleerida reaalset liiklust.
• API ebastabiilsus: Sa avastad, et taustteenused lakkavad töötamast ammu enne, kui esiotsa teenused lakkavad töötamast.
• Keskkonna sõltuvused: Te ei saa testida, kuna kolmanda osapoole maksevärav pole võrgus.
• Manuaalsed kitsaskohad: Sa veedad päevi logide käsitsi analüüsimisega, et leida rikke algpõhjus.

See avastusprotsess sunnib muutma mõtteviisi. Jõudlustestimist ei saa käsitleda isoleeritud sündmusena, mis toimub vahetult enne juurutamist. Nende probleemide lahendamiseks tuleb vasakule nihutada, nihutades testimise tsükli varasemasse etappi. Siin osutub vajalikuks terviklik platvorm.

Võtme tagasivõtmine

• Jõudlusprobleemid on väga nähtavad ja sageli peamine põhjus, miks meeskonnad hakkavad testimistööriista otsima.
• Koormustestimine paljastab sügavamaid struktuurilisi probleeme andmetes, keskkondades ja API-des.
• Jõudlustestide eraldamine ülejäänud arendusprotsessist tekitab kitsaskohti.

BlazeMeter kui peamine jõudlustestimise platvorm

Enne teistele valdkondadele laienemist on oluline mõista, miks meeskonnad valivad BlazeMeter jõudlustestimiseks esiteks. Platvorm võimaldas mul käivitada avatud lähtekoodiga skripte, näiteks JMeter, Gatling ja Seleniumilma keeruka infrastruktuurita.

Suuremahuliste testide hõlbus läbiviimine

Minu meeskonna peamine eelis oli koormus-, pinge-, piigi-, leotus- ja vastupidavustestide ulatuslik läbiviimine. Samuti saate pilvest simuleerida miljoneid virtuaalseid kasutajaid, et oma rakenduse piire koormustestida.

Platvorm pakub paindlikkust organisatsioonidele, kellel on ranged turvavajadused. Sain avalikust pilvest teste käivitada, et simuleerida välist liiklust, ja isegi kasutada privaatseid asukohti, et käivitada teste meie tulemüüri taga. See hübriidlähenemine võimaldab teil testida sisemisi rakendusi ilma neid avalikkusele paljastamata.

Loodud kaasaegsete DevOps-torustike jaoks

ma märkasin, et BlazeMeter integreerub otse pideva integratsiooni (CI) tööriistadega nagu Jenkins, GitHub ja Azure DevOps. Parim osa on see, et testi käsitsi käivitamise asemel sain oma torujuhtme konfigureerida nii, et see käivitaks jõudlustesti iga kord, kui arendaja koodi lisab.

See lähenemisviis käsitleb jõudlustestimist koodina. Salvestate oma testikonfiguratsioonid versioonikontrollisüsteemis koos rakenduskoodiga. See tagab, et teie testid arenevad samas tempos kui teie rakendus, vältides "testi triivi", mis sageli juhtub vanemate patenteeritud tööriistadega.

Toimivusest funktsionaalsuseni: ulatuse laiendamine

Kui olete toimivuskontrolli rutiini loonud, on järgmine loogiline samm tegeleda funktsionaalne testimineVarem kasutasid meeskonnad selleks eraldi tööriistu: ühte funktsioonide toimivuse (funktsionaalsus) ja teist kiiruse (jõudlus) kontrollimiseks. See tööriistade laialivalgumine toob kaasa suured kulud ja killustatud aruandluse.

Ühendatud funktsionaalne testimine veebis ja API-des

BlazeMeter lubas mu meeskonnal meie jõudlustestide ressursse funktsionaalseks valideerimiseks taaskasutada. Näiteks kui olete juba kirjutanud JMeter skripti, mis simuleerib kasutaja sisselogimist ja toote ostmist koormustesti jaoks, saate sama loogikat kasutada ka funktsionaalse testi käivitamiseks.

See võimalus vähendab hoolduskoormust märkimisväärselt. Seetõttu ei pidanud ma samade kasutajavoogude jaoks haldama kahte eraldi skriptide teeki. Nende funktsionaalsete testide sagedase käivitamisega (isegi iga versiooni puhul) saate aru regressioon vead varakult.

Järjepidev aruandlus eri testitüüpide vahel

Erinevate tööriistade kasutamisel on tulemuste korreleerimine keeruline. Kui ühes tööriistas funktsionaaltest ebaõnnestub ja teises jõudlustesti tulemused langevad, võtab aega, et teha kindlaks, kas neil on ühine algpõhjus.

Koondades need testid ühele platvormile, leidsin ühe tõeallika. Nägin oma funktsionaalsete testide läbimise/läbikukkumise määrasid koos jõudlustrendidega. See ühtne vaade aitab teil kindlaks teha, kas hiljutine koodimuudatus põhjustas funktsiooni rikke või lihtsalt aeglustas seda. Lisaks kiirendab see tõrkeotsingu protsessi.

Testiandmete haldus: varjatud kitsaskohtade lahendamine

Üks suurimaid takistusi kehtiva testimise sooritamisel on andmedRealistliku testi läbiviimiseks on vaja realistlikke andmeid. Te ei saa testida 10 000 kasutaja sisselogimisvoogu, kui teie andmebaasis on ainult 50 kasutajakontot.

Traditsiooniliselt kopeerivad meeskonnad andmeid tootmiskeskkonnast madalamatesse keskkondadesse. See protsess on aeglane, riskantne ja rikub sageli privaatsuseeskirju, näiteks isikuandmete kaitse üldmäärust (GDPR) või HIPAA-d.

Andmete kohene loomine

BlazeMeter lahendab selle integreeritud testandmete haldusega. Tootmisandmete kopeerimise asemel saate genereerida sünteetilisi andmeid, mis näevad välja ja käituvad nagu päris andmed, kuid ei sisalda tundlikku teavet.

See võimaldab teil:

• Skaleerige vaevata: Genereerige koheselt tuhandeid unikaalseid kirjeid koormustesti jaoks.
• Jää nõuetele vastavaks: Veenduge, et teie turvalisest tootmiskeskkonnast ei lahkuks kunagi isikut tuvastavaid andmeid.
• Loo konkreetsed stsenaariumid: Genereerige andmeid äärmuslike juhtumite jaoks, näiteks aegunud krediitkaartidega kasutajate või kindlate geograafiliste asukohtade jaoks, mida võib olla tootmisandmetest raske leida.

Kuna mul olid nõudmisel kehtivad andmed, sain kõrvaldada "andmete ootamise", mis sageli lükkab testimistsükleid päevade või nädalate võrra edasi.

Teenuse virtualiseerimine: testige varem, isegi kui sõltuvused pole veel valmis

Kaasaegsed rakendused tuginevad sõltuvuste võrgustikule, nagu sisemised mikroteenused, kolmandate osapoolte API-d, suurarvutid ja välised makseväravad. Kui üks neist pole saadaval, siis testimine peatub.

See on jõudlustestimise klassikaline probleem. Soovite oma kassaprotsessi testida, aga pangandus-API võtab iga tehingu eest tasu või on testikeskkond hoolduse tõttu maas.

Teenuste pilkamine meeskondade blokeeringu tühistamiseks

BlazeMeter Teenuse virtualiseerimine võimaldab teil luua nende sõltuvuste virtuaalseid „makette“. Need maketid simuleerivad tegeliku teenuse käitumist, andmeid ja jõudlusomadusi.

Näiteks saaksin virtuaalse maksevärava konfigureerida nii, et see vastaks 200 millisekundi jooksul teatega „edu“ või 5 sekundi jooksul veateatega „ajalõpp“. See võimaldab teil:

• Testi paralleelselt: Arendajad saavad oma koodi virtuaalse API suhtes testida enne, kui päris API on isegi loodud.
• Kontrolli kaost: Simuleeri aeglaseid võrke või veareaktsioone, et näha, kuidas sinu rakendus tõrgetega toime tuleb.
• Vähendage kulusid: Vältige suuremahuliste koormustestide ajal kolmandate osapoolte teenuste tehingutasusid.

See võimekus on hajutatud arhitektuuride jaoks kriitilise tähtsusega, kuna see tagab, et üks puuduv tükk ei blokeeri kogu teie väljalasketorustikku.

Võtme tagasivõtmine

• Sõltuvused, nagu API-d ja suurarvutid, blokeerivad sageli testimise edenemist.
• Virtualiseerimine võimaldab teil neid teenuseid simuleerida, et testimine sujuks.
• Saate simuleerida negatiivseid stsenaariume (latentsus, vead), mida on reaalsetes süsteemides raske käivitada.

API testimine ja jälgimine: teadmiste laiendamine tootmiskeskkonda

Tänapäevases tarkvaraarhitektuuris on API-d teie rakenduse selgroog. Kui teie API-d ebaõnnestuvad, ebaõnnestub ka teie kasutajaliides. Kuigi jõudlustestid kontrollivad API-d koormuse all, peate ka veenduma, et API toimib õigesti ja järgib oma lepingut.

Pidev API kontrollimine

BlazeMeter Laiendab teie haaret API kihis. Selle tööriista abil saaksin käivitada funktsionaalseid API teste, et valideerida vastuste struktuure, päiseid ja andmete täpsust. Kuna API-del puudub kasutajaliides, töötavad need testid äärmiselt kiiresti, mistõttu on need ideaalsed kiirete tagasisideahelate jaoks teie CI-torustikus.

Tootmisseisundi jälgimine

Testimine ei tohiks juurutamise ajal lõppeda. BlazeMeter võimaldab teil oma testimisskripte ümber kujundada jälgimisskriptideks. Saate oma tootmiskeskkonna API-de vastu regulaarselt kergeid teste käivitada erinevatest asukohtadest üle maailma.

See annab pidevat tagasisidet tööaja ja latentsuse kohta. Kui API hakkab aeglaselt reageerima või tagastab vigu, saate kohe teate. See ühendab lünga eeltootmise testimise ja tootmise jälgitavuse vahel, nii et saate probleeme märgata enne, kui teie kliendid seda teevad.

Tehisintellekti abil teostatav aruandlus ja analüüs: tulemuste muutmine otsusteks

Pidev testimine genereerib tohutu hulga andmeid. Kui päevas tehakse sadu teste, muutub läbimise/läbimise aruannete käsitsi ülevaatamine võimatuks. Siinkohal muudab tehisintellekt (AI) toorandmed tegutsemist võimaldavateks otsusteks.

Leida Signal Müras

BlazeMeter rakendab tehisintellekti teie testitulemustele, et aidata teil tuvastada kõrvalekaldeid. Ainult graafiku kuvamise asemel saab platvorm esile tõsta kõrvalekaldeid tavapärasest käitumisest.

Näiteks kui teie sisselogimistoiming võtab tavaliselt aega 200 ms, kuid pärast konkreetset commit'i hüppab see ootamatult 500 ms-ni, siis süsteem annab sellest halvenemisest märku. See seob erinevat tüüpi testide ebaõnnestumisi, et aidata teil aru saada, kas jõudluse hüpe on seotud konkreetse funktsionaalse veaga.

See intelligentsus vähendab oluliselt keskmist lahendusaega (MTTR). Arendajad kulutavad vähem aega logide läbitöötamisele ja rohkem aega tegeliku koodiprobleemi lahendamisele.

Jõudlustestimine kui sisse-Ramp küpsuseni

Täieliku pideva testimise strateegia omaksvõtmine ei toimu üleöö. Tavaliselt on see pikk teekond.

1. Alusta jõudlusest: Enamik meeskondi alustab siit, et tegeleda otsese stabiilsusriskiga. Nad kasutavad BlazeMeter avatud lähtekoodiga skriptide suures mahus käitamiseks.
2. Lisa funktsionaalsus ja API: Meeskonnad mõistavad, et saavad neid skripte taaskasutada funktsionaalseks kontrollimiseks ja API kontrollimiseks, koondades tööriistu.
3. Testiandmete ja virtualiseerimise integreerimine: Testide kiiremaks ja varasemaks käivitamiseks võtavad meeskonnad blokeerijate eemaldamiseks kasutusele sünteetilisi andmeid ja virtuaalseid teenuseid.
4. Skaleerimine tehisintellekti abil: Testide mahu kasvades kasutavad meeskonnad müra haldamiseks ja kiiruse säilitamiseks tehisintellektil põhinevaid teadmisi.

Kasutamise eelis BlazeMeter on see, et see toetab kogu seda teekonda. Ma ei pidanud ostma uusi tööriistu ega migreerima skripte, kui minu vajadused keerukamaks muutusid. Sa lihtsalt avad uued võimalused sama platvormi sees.

Miks BlazeMeter Beats Pointi lahendused

Võite mõelda: „Miks mitte kasutada iga sammu jaoks tasuta eraldi tööriistu?“ Kuigi avatud lähtekoodiga tööriistad on suurepärased, on nende kokkuviimine ühtseks ettevõtte töövooguks keeruline ja kulukas.

Isetehtud tööriistaketi hooldamine hõlmab järgmist:

• Ehitusserverite ja koormusgeneraatorite haldamine.
• Tööriistade ühendamiseks kohandatud liimikoodi kirjutamine.
• Andmete käsitsi korreleerimine erinevate aruannete vahel.
• Turvalisuse ja vastavusega tegelemine mitme tarnija juures.

BlazeMeter pakub ühtset platvormi, mis haldab teie eest infrastruktuuri, turvalisust ja integratsiooni. Selle tulemuseks on madalamad kogukulud (TCO), kuna teie insenerid keskenduvad rakenduse testimisele, mitte testimistööriistade hooldamisele. Saate avatud lähtekoodiga tarkvara vabaduse (kuna saate endiselt kasutada JMeter, Seleniumjne) ettevõtte platvormi usaldusväärsuse ja ulatusega.

Hankige enamat kui jõudlustestimine