Shërbimi i testimit të ngarkesës. Shërbimi i testimit të ngarkesës loadme
Ekipi ynë u përball me mangësitë e mjeteve të testimit të ngarkesës dhe, në fund, u vendos që të zhvillojmë shërbimin tonë. Vështirësitë kryesore:
- Nëse ky është një shërbim, çmimi është shumë i lartë për një ngarkesë serioze
- Nëse ky është një mjet i dobishëm, rezultati varet nga shpejtësia e kanalit të kompjuterit/serverit nga i cili është kryer testi
- Pyetjet e përsëritura nuk pasqyrojnë shpejtësinë reale, pasi memoria e fshehtë ndodh në nivele të ndryshme nga CPU në bazën e të dhënave
Çfarë është bërë tashmë?
- Ju mund të testoni detyra nga lista e url-ve, deri në 20 copë
- Çdo url mund të përmbajë një ose më shumë parametra të rastësishëm të specifikuar duke përdorur funksionin $RND
- Testi kryhet nga shumë serverë, secili ka vetëm 8 thread
- Testimi mund të kryhet nga 5 rajone AWS - Dublin, Frankfurt, SHBA Lindje/Perëndim, Tokio
- Ne jemi gati të ofrojmë teste për deri në 200 tema falas
*** PËRDITËSIM ***
Unë shoh shumë banorë të guximshëm Khabra që vendosin një detyrë për 200 fije. Nëse supozojmë se 1 faqe jepet në 1 sekondë, atëherë kjo korrespondon me trafikun prej > 100 mijë vizitorë në orë. Projektet e zakonshme, përfshirë edhe tonat, vdesin nga teste të tilla.
Brenda një minutë, rezultati juaj do të jetë gati (për shembull, shihni rezultatin e shkëlqyer - testimi shembull.net). Siç mund ta shihni, 200 threads ju lejon të gjeneroni më shumë se 1000 kërkesa në sekondë - gjithçka varet nga shpejtësia e komunikimit me shërbimin që testohet, etj. në fakt, shpejtësia e përgjigjes.
Nëse jeni gati të tregoni rezultatin tuaj në faqen tonë të internetit, mund të klikoni butonin e rezultateve publike. Për t'ua treguar kolegëve tuaj, thjesht dërgoni një lidhje.
Çfarë të testoni?
Burimet statike, imazhet, skriptet duhet të shërbehen nga një CDN. Nuk ka kuptim të testoni shpejtësinë e ngarkimit të tyre IMHO, ju duhet vetëm të provoni shpejtësinë e përgjithshme të ngarkimit të faqes, për shembull duke përdorur http://tools.pingdom.com/fpt/ të mirën e vjetër;
Loadme fokusohet në testimin e metodave të kodit të faqes / api, etj... Sigurisht, është e mundur të testoni nginx që shërben 1x1.gif duke përdorur këtë mjet, por nuk ka asnjë përfitim praktik dhe nginx as nuk do të ngrohet nga kjo.
Për të përcaktuar se cilat faqe janë pengesa, është më mirë të përdorni newrelic. Ndryshe nga analitika e njohur e Google, ajo gjithashtu ju lejon të gjurmoni statistikat e kërkesave për bot dhe të krijoni pyetje bazuar në numrin e operacioneve për faqe, si dhe se cila faqe e ka prishur më shumë përvojën e përdoruesit sipas indeksit apdex.
Siç e dini, një mizë në vaj prish një fuçi me mjaltë dhe nëse aplikimi juaj ngadalësohet në disa veprime edhe relativisht të rralla, kjo mund të ndikojë mirë në operacionet popullore me peshë të lehtë.
Si funksionojnë ridrejtimet?
Ridrejtimet janë ekzekutuar; Ne i përdorim ato në mënyrë aktive për të testuar një nga faqet tona, wikiart.org, duke zbatuar funksionin "shko te një foto e rastësishme" në të.
Pse është e rëndësishme të testoni URL të shumta?
Për të testuar ndikimin e ndërsjellë të faqeve të njohura të shpejta dhe atyre të ngadalta (për shembull, kërkimi)
Pse nevojitet $RND?
Sintaksa është $RND (nga, në).
Për shembull, http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) do të gjenerojë pyetje arbitrare për të kërkuar produkte me çmime që variojnë nga 0 në 1000 dhe mbarojnë nga 1000 në 10000. Kjo bën të mundur vlerësimin e fuqisë reale të kërkimit.
Për shembull, dyqani i njohur ukrainas Rozetka shpenzon mesatarisht 5 sekonda duke kërkuar telefona inteligjentë me një çmim të rastësishëm:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d, që është shumë larg rezultatit ideal.
Amazon e përballon këtë detyrë thelbësisht më mirë - një numër i konsiderueshëm gabimesh si rezultat ka të ngjarë të ketë mbrojtje nga ddos
Planet e së ardhmes
Postoni, vendosni, fshini kërkesat
Gjëja e nevojshme është padyshim në plane.
Autorizimi
A do të jetë e mjaftueshme mbështetja e cookie-ve në mënyrë që kërkesa e parë të regjistrojë testin nën një përdorues të rastësishëm (i cili do të kërkojë mbështetje nga serveri) dhe puna e mëtejshme të bëhet në emër të këtij përdoruesi?
Testet e hapave
Le të themi, kryeni një seri testesh: 25%, 50%, 75% dhe 100%, dhe shikoni ndryshimin në shpejtësi.
Në vend të numrit të thread-ve, lejojeni përdoruesin të zgjedhë sa operacione në sekondë dëshiron të fillojë.
Testi i rregullt i planifikuar
Përsëriteni testin çdo ditë/javë dhe dërgoni një raport me email.
Ju gjithashtu mund të siguroni një lloj uebhook për të aktivizuar një test ekzistues nga kodi (për shembull, pas një përditësimi)
Vizualizimi i përmirësuar i xhiros
Serveri mund të jetë sjellë në mënyrë të çrregullt. Ne planifikojmë të shtojmë vizualizimin e xhiros së serverit me sekonda.
Konfirmimi i pronësisë së domenit
Kufiri i jo më shumë se 200 agjentëve për domen ekziston pikërisht për të siguruar që askush të mos e hedhë uebsajtin e dikujt tjetër në ddos. Mund të krijoni një nëndomain tjetër për faqen tuaj dhe ta provoni përsëri.
Në të ardhmen, megjithatë, do të jetë e nevojshme të verifikohen domenet duke përdorur një rekord CNAME ose një skedar me një emër specifik.
Konkurrentët ekzistues
Loadimpact.com - për një test normal ngarkimi, do të kërkohen të paktën 100 kërkesa në sekondë, 1500 të ashtuquajtur "përdorues virtualë" - secili prej tyre ngarkon faqen një herë në 15 sekonda. Kjo paketë kushton aktualisht 299 dollarë në muaj.Loader.io është një shërbim i shkëlqyer, paketa e paguar është vetëm 99 dollarë në muaj. Cilësimet shumë fleksibël të URL-së - mund të vendosni metoda, kuki, tituj, por ne nuk kishim randomizim të mjaftueshëm provë.
Ne vazhdojmë serinë e artikujve për testuesit fillestarë. Herën e fundit ju tregova se si kam studiuar. Këtë herë do të doja të flisja për ngarkesën. Testimi i stresit Ky është një lloj testimi mjaft kompleks dhe interesant, por kërkon më shumë kohë dhe nuk toleron gabime.
Testimi i stresit
Ky lloj testimi kryhet për të vlerësuar se sa të qëndrueshme janë kodi i produktit dhe platforma e tij. Kjo zakonisht verifikohet duke pasur një sasi të madhe të dhënash dhe përdoruesish. Ndryshe nga testimi funksional, testimi i ngarkesës rrallë jep përgjigje të qarta, por vetëm tregon se në cilin drejtim të përmirësohet produkti. Meqenëse ngarkesa mund të rritet pafundësisht, asnjë kod ose server nuk do të jetë në gjendje t'i rezistojë një presioni të tillë, por është e rëndësishme që ju të zbuloni se nën çfarë presioni është në gjendje të funksionojë plotësisht.
Nëse e shikoni, mund të shihni se ky lloj testimi i referohet testeve të orientuara nga klienti. Kjo do të thotë që testet e ngarkesës zakonisht kryhen në produktin e përfunduar dhe në një mjedis të ngjeshur ose të ngjashëm me shtyllën, pa u zhytur në vetë kodin. Më shpesh në praktikën time, me ndihmën e testeve të ngarkesës, më duhej të përcaktoja se sa kërkonte kodi i shkruar për performancën e serverit.
Jmeter
Ashtu si me testimin e automatizuar, testimi i ngarkesës duhej të mësohej drejtpërdrejt në praktikë. E vetmja e dhënë ishte Jmeter, pasi më vonë doli të ishte një nga mjetet më të famshme për testet e ngarkesës. Përparësitë e mëdha të Jmeter janë se ai ka një komunitet të madh, është me kod të hapur dhe përditësohet mjaft shpesh. Programi gjithashtu ka një GUI shumë miqësore për përdoruesit dhe aftësinë për të nisur përmes tastierës.
Kërko: jmeter, testimi i ngarkesës me jmetër
Ka disa mësime të shkëlqyera për Habré për krijimin e testeve të ngarkesës, nga të cilat jam udhëhequr gjatë studimit të këtij mjeti.
Deri më tani, nuk kam qenë në gjendje të zotëroj plotësisht të gjitha tiparet e Jmeter, pasi ai ka shumë funksionalitet. Por unë zotërova detyrat themelore të krijimit të skenarëve të provës për ngarkesën. Gjatë punës me jmeter, njerëzit që nuk janë të njohur me testimin e ngarkesës do të kenë shumë pyetje në lidhje me termat e rinj. Kjo lehtësohet edhe nga ndërfaqja në gjuhën angleze, shkruani emra të paqartë dhe sigurohuni që t'i studioni ato ndërsa shkoni; Për shembull, për mua ishte thread and swap.
Kërko: fije, ndërroj
Një variant i një detyre interesante për testimin e ngarkesës. Ju duhet të kontrolloni që aplikacioni në internet mund të trajtojë 200 qindra përdorues në internet të cilët do të angazhohen në korrespondencë në bisedën e integruar. Ka shumë opsione të mundshme për detyra të tilla që mund të vendosni t'i shkruani vetë. Vendosini vetes një detyrë për disa nga projektet tuaja (në mënyrë që të mos prishni dikë tjetër) dhe filloni ta zgjidhni atë duke përdorur jmeter.
Pasi studiova tiparet standarde të Jmeter, një herë u djega keq. Kam vlerësuar plotësisht matjet e mbledhura dhe kam marrë një qortim nga një koleg i vjetër. Nga kjo arrita në përfundimin se për të testuar ngarkesën nuk mjafton të njohësh vetëm mjetin. Është shumë e rëndësishme të vlerësohen saktë metrikat e mbledhura pas testeve të ngarkesës dhe të nxirret përfundimi i duhur bazuar në to.
Përsëri, Jmeter është një mjet shumë i fuqishëm dhe popullor për ngarkim. Unë do t'i kushtoja një rëndësi të madhe kur studioj këtë lloj testimi.
Ka disa mjete të tjera që kam hasur kohët e fundit për të shkruar testet e ngarkesës që më duken interesante.
Tank Yandex
Nuk mund të them me siguri, por duket se ky është një mjet mjaft i njohur për testimin e ngarkesës. E përdora disa herë për të imituar një fluks të madh përdoruesish, dhe Yandex Tank bëri një punë të shkëlqyer me këtë detyrë. Ndoshta për disa do të jetë një alternativë për Jmeter, pasi është më e lehtë për t'u përdorur.
Kërko: testet e ngarkesës së rezervuarit Yandex
Qasje e lezetshme për testet e ngarkesës. Në vend që të ruani skriptet nga regjistrat, ju i krijoni ato vetë në kodin Python. Ndërfaqja e integruar në internet ju lejon të konfiguroni shpejt ngarkesën dhe të filloni monitorimin. Një zgjidhje shumë interesante, dhe mund të shkallëzohet mirë falë Python.
Kërko: karkalec, karkalec testimi i ngarkesës
UPD. Ka disa shërbime interesante në internet për testimin e ngarkesës. Për shembull loadimpact.com. Sigurisht, testimi i ngarkesës në shkallë të gjerë atje paguhet, por në çdo rast mund të provoni mënyrën e provës.
Gjithashtu, në varësi të teknologjive të përdorura në zhvillim, mund të përdoren mjete të tjera për ngarkim. Për shembull, SOAP UI do t'ju lejojë ta ngarkoni atë me kërkesa. SOAP UI në përgjithësi bën shumë gjëra të dobishme, unë rekomandoj ta lexoni ose ta provoni në kohën e lirë.
Ky lloj testimi është paksa i ndryshëm, por ka një qëllim të ngjashëm - të përmirësojë cilësinë dhe stabilitetin e produktit dhe platformës suaj.
Shpesh testet e performancës kryhen kur një problem i performancës është shfaqur tashmë. Ky ishte rasti në rastin tim.
Situata të përsëritura shpesh
- Një funksion fatkeq ha shumicën e burimeve dhe ngadalëson të gjithë produktin.
- Përdorimi shumë i kujdesshëm i burimeve të disponueshme, megjithëse kodi mund të ekzekutohet disa herë më shpejt.
Për të gjetur probleme të tilla duhet të keni akses në kodin, bazat e të dhënave, konsolën e serverit dhe të kuptoni qartë se çfarë po ndodh saktësisht. Aftësia për të punuar me linjën e komandës në përgjithësi është shumë e përshtatshme këtu.
Shumë i përshtatshëm për të kontrolluar situatat e mësipërme profiluesit e kodeve. Duke përdorur profiluesit, mund të përcaktoni se sa kohë merr çdo pjesë e kodit. Më shpesh janë zhvilluesit ata që e bëjnë këtë, por mendoj se nuk do të dëmtojë as testuesit. Mund të gjeni gabime të dukshme dhe të bëni ndryshimet e duhura.
Kërko: profiluesit e kodeve
Sistemet e monitorimit janë gjithashtu shumë të dobishme këtu. Për shembull, Zabbix, Ansible dhe të tjerët. Me ndihmën e tyre, ju mund të gjurmoni burimet e konsumuara nga skriptet e caktuara dhe të krijoni raporte afatgjata. Këto sisteme përdoren kryesisht nga ekipet e zhvilluesve, por gjithashtu do të ndihmojnë shumë në testim.
Kjo eshte e gjitha. Shpresoj se kam treguar se në cilën mënyrë të gërmoj dhe çfarë të praktikoj. Do të jem i lumtur të dëgjoj pyetjet tuaja në komente.
Testimi i stresit
Testimi i stresit(anglisht) Testimi i ngarkesës) - përcaktimi ose grumbullimi i treguesve të performancës dhe koha e përgjigjes së një sistemi ose pajisjeje softuerike dhe harduerike në përgjigje të një kërkese të jashtme, me qëllim që të përcaktohet pajtueshmëria me kërkesat për një sistem (pajisje) të caktuar.
Për të studiuar kohën e reagimit të sistemit në ngarkesa të larta ose të pikut, kryhet testimi i stresit, në të cilin ngarkesa e krijuar në sistem tejkalon skenarët normalë të përdorimit të tij. Nuk ka kufi të qartë ndërmjet testimit të ngarkesës dhe stresit, por këto koncepte nuk duhet të ngatërrohen, pasi këto lloj testimesh u përgjigjen pyetjeve të ndryshme të biznesit dhe përdorin metodologji të ndryshme.
Testimi i ngarkimit të softuerit
Afati Testimi i stresit mund të përdoret në kuptime të ndryshme në një mjedis të testimit profesional të softuerit. Në përgjithësi, i referohet praktikës së simulimit të përdorimit të pritshëm të një aplikacioni duke emuluar shumë përdorues në të njëjtën kohë. Kështu, një testim i tillë është më i përshtatshëm për sistemet me shumë përdorues, më së shpeshti duke përdorur arkitekturën klient-server (për shembull, serverët në internet). Megjithatë, llojet e tjera të sistemeve softuerike mund të testohen në mënyrë të ngjashme. Për shembull, një redaktues teksti ose grafik mund të bëhet për të lexuar një dokument shumë të madh; dhe paketa financiare - gjeneroni një raport të bazuar në të dhënat për disa vite. Testi i ngarkesës i projektuar në mënyrë më adekuate do të prodhojë rezultate më të sakta.
Qëllimi kryesor i testimit të ngarkesës është krijimi i një ngarkese të caktuar të pritur në sistem (për shembull, përmes përdoruesve virtualë) dhe, zakonisht, duke përdorur softuer dhe pajisje identike, për të vëzhguar performancën e sistemit.
| Shembulli 1:
Një shërbim në internet me funksionalitetin e karrocave është krijuar për 100 përdorues të njëkohshëm që ndjekin një skenar të caktuar (veprime të specifikuara në përmasa të specifikuara):
Në këtë rast, testimi i ngarkesës duhet të imitojë skenarin tipik të punës me një shërbim ueb të përshkruar më sipër në mënyrë që të sigurohet që sistemi është gati për të hyrë në prodhim. Në këtë rast, treguesit e performancës së sistemit në tërësi ose çdo nyje të sistemit në veçanti mund të merren për analizë. |
Në mënyrë ideale, kriteret për suksesin e testimit të ngarkesës janë kërkesat e performancës së sistemit, të cilat formulohen dhe dokumentohen në fazën e zhvillimit të kërkesave funksionale për sistemin përpara programimit të zgjidhjeve kryesore arkitekturore. Megjithatë, shpesh ndodh që kërkesa të tilla të mos jenë formuluar qartë ose të mos jenë formuluar fare. Në këtë rast, do të jetë testimi i parë i ngarkesës gjyq (testimi i ngarkesës eksploruese) dhe të bazohen në supozime të arsyeshme në lidhje me ngarkesën e pritshme dhe konsumin e burimeve të harduerit.
Një nga qasjet optimale për përdorimin e testimit të ngarkesës për të matur performancën e sistemit është testimi në fazën e hershme të zhvillimit. Testimi i ngarkesës në fazat e para të gatishmërisë së një zgjidhjeje arkitekturore për të përcaktuar qëndrueshmërinë e saj quhet testimi "Proof-of-Concept".
Parimet themelore të testimit të ngarkesës
Më poshtë janë disa fakte eksperimentale, të përmbledhura në parimet e përdorura në testimin e performancës në përgjithësi dhe të zbatueshme për çdo lloj testimi të performancës (veçanërisht testimin e ngarkesës).
1. Unike e kerkesaveEdhe pasi të keni krijuar një skenar realist për të punuar me sistemin bazuar në statistikat e përdorimit të tij, duhet të kuptoni se gjithmonë do të ketë përjashtime nga ky skenar.
Ilustrimi i shpërndarjeve të ndryshme të dispersionit për kohën e ekzekutimit të pyetjeve X dhe Y.
Kur Shembulli 1 ky mund të jetë një përdorues që hyn në faqet unike të një shërbimi ueb që janë të ndryshëm nga të gjithë të tjerët.
2. Koha e përgjigjes së sistemitNë përgjithësi, koha e përgjigjes së një sistemi ndjek një funksion normal të shpërndarjes.
Në veçanti, kjo do të thotë se duke pasur një numër të mjaftueshëm matjesh, është e mundur të përcaktohet probabiliteti me të cilin përgjigja e sistemit ndaj një kërkese do të bjerë brenda një intervali të caktuar kohor.
3. Varësia e kohës së përgjigjes së sistemit nga shkalla e shpërndarjes së këtij sistemi.Varianca e shpërndarjes normale të kohës së përgjigjes së sistemit ndaj një kërkese është proporcionale me raportin e numrit të nyjeve të sistemit që përpunojnë kërkesa të tilla paralelisht dhe numrin e kërkesave për nyje.
Kjo do të thotë, përhapja e kohës së përgjigjes së sistemit ndikohet njëkohësisht nga numri i kërkesave për nyje të sistemit dhe numri i vetë nyjeve, secila prej të cilave shton një sasi të caktuar të rastësishme vonese gjatë përpunimit të kërkesave.
4. Ndryshimi në kohën e përgjigjes së sistemitNga pohimet 1, 2 dhe 3, mund të konkludojmë gjithashtu se me një numër mjaft të madh të matjeve të kohës së përpunimit të kërkesës, në çdo sistem do të ketë gjithmonë kërkesa, koha e përpunimit të të cilave i kalon maksimumet e përcaktuara në kërkesa; Për më tepër, sa më e gjatë të jetë koha totale e eksperimentit, aq më të larta do të jenë maksimalet e reja.
Ky fakt duhet të merret parasysh gjatë formimit të kërkesave të performancës së sistemit, si dhe gjatë kryerjes së testimit të rregullt të ngarkesës.
5. Saktësia e riprodhimit të profilit të ngarkesësSaktësia e kërkuar e riprodhimit të profileve të ngarkesës bëhet më e shtrenjtë sa më shumë komponentë të përmbajë sistemi.
Shpesh është e pamundur të merren parasysh të gjitha aspektet e profilit të ngarkesës për sistemet komplekse, pasi sa më kompleks të jetë sistemi, aq më shumë kohë do të shpenzohet për projektimin, programimin dhe mbajtjen e një profili adekuat të ngarkesës për të, gjë që nuk është gjithmonë e nevojshme. Qasja optimale në këtë rast është balancimi midis kostos së zhvillimit të testit dhe mbulimit të funksionalitetit të sistemit, gjë që rezulton në supozime për ndikimin në performancën e përgjithshme të një pjese të caktuar të sistemit nën testim.
Paketa e mjeteve të testimit të performancës
Duhet të theksohet se shumica e llojeve të testimit të performancës përdorin të njëjtat mjete që mund të kryejnë detyra tipike.
Ekziston një keqkuptim i zakonshëm që mjetet e testimit të ngarkesës së sistemit janë mjete regjistrimi dhe riprodhimi si mjetet e automatizimit të testimit të regresionit. Mjetet e testimit të ngarkesës funksionojnë në nivelin e protokollit, ndërsa mjetet e automatizimit të testimit të regresionit funksionojnë në nivelin e objektit GUI.
Ekzistojnë mjete të ndryshme për zbulimin dhe hetimin e problemeve në pjesë të ndryshme të sistemit. Të gjitha nyjet e sistemit mund të klasifikohen si më poshtë:
- Aplikacion,
- Baza e të dhënave,
- Neto,
- Përpunimi nga ana e klientit
- Balancimi i ngarkesës.
Vlen të përmendet gjithashtu shfaqja e aplikacioneve të rrjetit Business-to-business (B2B) që përdorin një marrëveshje të nivelit të shërbimit (ose SLA, Marrëveshja e Nivelit të Shërbimit). Popullariteti në rritje i aplikacioneve B2B ka bërë që gjithnjë e më shumë aplikacione të kalojnë në arkitekturën e orientuar drejt shërbimit, në të cilën informacioni shkëmbehet pa pjesëmarrjen e shfletuesve të internetit. Një shembull i një ndërveprimi të tillë do të ishte një agjenci udhëtimesh që kërkon informacion për një fluturim specifik midis Shën Petersburg dhe Omsk, ndërsa linja ajrore kërkohet të japë një përgjigje brenda 5 sekondave. Shkelja e një marrëveshjeje SLA shpesh rezulton në një gjobë të madhe.
Mjetet më të njohura të testimit të ngarkesës janë paraqitur më poshtë.
| NGA | Emri i prodhuesit | Komentet |
|---|---|---|
| OpenSTA | "Arkitektura e testimit të sistemit të hapur" | Softuer falas për testimin e ngarkesës/stresit, i licencuar sipas GNU GPL. Përdor një arkitekturë aplikacioni të shpërndarë bazuar në CORBA. Një version i Windows është i disponueshëm, megjithëse ka probleme me pajtueshmërinë me Windows Vista. Mbështetja përfundoi në 2007. |
| Testues i Performancës Racionale të IBM | IBM | Softuer i bazuar në mjedisin e zhvillimit të Eclipse që ju lejon të krijoni ngarkesa të mëdha dhe të matni kohën e përgjigjes për aplikacionet me arkitekturë klient-server. Kërkon licencim. |
| JMeter | Projekti Apache Jakarta me burim të hapur | Paketa e veglave ndër-platformë e bazuar në Java që ju lejon të kryeni teste ngarkimi duke përdorur lidhjet JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Bën të mundur krijimin e një numri të madh kërkesash nga kompjuterë të ndryshëm dhe kontrollin e procesit nga njëri prej tyre. |
| HP LoadRunner | HP | Një mjet testimi i ngarkesës i krijuar fillimisht për të imituar punën e një numri të madh përdoruesish të njëkohshëm. Mund të përdoret gjithashtu për testimin e njësisë ose integrimit. |
| SilkPerformer | Mikro fokus | |
| Testi i ngarkimit të Visual Studio | Microsoft | Visual Studio ofron mjete për testimin e performancës duke përfshirë testimin e ngarkesës/njësisë |
| Ngarkimi i plotësuar | SmartBear |
Treguesit kryesorë të performancës (metrika)
Një nga rezultatet e marra gjatë testimit të ngarkesës dhe i përdorur për analiza të mëtejshme janë treguesit e performancës së aplikimit. Ato kryesore diskutohen më poshtë.
1. Konsumi i burimit të CPU (CPU, %)Një metrikë që tregon se sa kohë nga një interval specifik i caktuar është shpenzuar nga procesori në llogaritjet për procesin e zgjedhur. Në sistemet moderne, një faktor i rëndësishëm është aftësia e një procesi për të ekzekutuar në fije të shumta në mënyrë që procesori të mund të kryejë llogaritjet paralelisht. Analiza e historisë së konsumit të burimeve të procesorit mund të shpjegojë ndikimin në performancën e përgjithshme të sistemit të rrjedhave të të dhënave të përpunuara, konfigurimeve të aplikacioneve dhe sistemit operativ, llogaritjes me shumë fije dhe faktorëve të tjerë.
2. Konsumi i RAM-it (Përdorimi i memories, Mb)Një metrikë që tregon sasinë e memories së përdorur nga një aplikacion. Kujtesa e përdorur mund të ndahet në tre kategori:
- Virtual - sasia e hapësirës së adresave virtuale që përdor procesori. Ky vëllim nuk nënkupton domosdoshmërisht përdorimin e hapësirës së duhur të diskut ose RAM-it. Hapësira virtuale është e kufizuar dhe procesi mund të jetë i kufizuar në aftësinë e tij për të ngarkuar bibliotekat e kërkuara.
- Private - sasia e hapësirës së adresave të zënë nga procesori dhe që nuk ndahet me proceset e tjera.
- Working Set - një grup faqesh memorie të përdorura së fundmi nga procesi. Kur ka mjaftueshëm memorie të lirë, faqet mbeten në grup edhe nëse nuk janë në përdorim. Nëse ka mbetur pak memorie e lirë, faqet e përdorura fshihen.
Kur një aplikacion është duke u ekzekutuar, memoria mbushet me referenca për objektet, të cilat, nëse nuk përdoren, mund të pastrohen nga një proces i veçantë automatik i quajtur mbledhës i mbeturinave. Mbledhësi i mbeturinave). Koha që i duhet procesorit për të pastruar kujtesën në këtë mënyrë mund të jetë e rëndësishme kur një proces ka zënë të gjithë memorien e disponueshme (në Java, i ashtuquajturi "GC e vazhdueshme e plotë") ose kur një proces ka sasi të mëdha memorie të alokuara që duhet të të pastrohet. Gjatë kohës që duhet për të pastruar kujtesën, qasja e një procesi në faqet e memories së caktuar mund të bllokohet, gjë që mund të ndikojë në kohën përfundimtare të përpunimit për atë proces.
3. Konsumi i burimeve të rrjetitKjo metrikë nuk lidhet drejtpërdrejt me performancën e aplikacionit, por mund të tregojë kufijtë e performancës së sistemit në tërësi.
| Shembulli 3:
Aplikacioni i serverit, duke përpunuar kërkesën e përdoruesit, i kthen atij transmetimin e videos duke përdorur një kanal rrjeti 2 megabit. Kërkesa thotë që serveri duhet të përpunojë 5 kërkesa përdoruesi njëkohësisht. Testimi i ngarkesës tregoi se serveri mund të sigurojë në mënyrë efektive të dhëna vetëm për 4 përdorues në të njëjtën kohë, pasi transmetimi multimedial ka një shpejtësi bit prej 500 kilobit. Natyrisht, ofrimi i këtij transmetimi për 5 përdorues në të njëjtën kohë është i pamundur për shkak të tejkalimit të kapacitetit të kanalit të rrjetit, që do të thotë se sistemi nuk i plotëson kërkesat e specifikuara të performancës, megjithëse konsumi i tij i burimeve të procesorit dhe memorjes mund të jetë i ulët. |
Puna me nënsistemin e diskut mund të ndikojë ndjeshëm në performancën e sistemit, kështu që mbledhja e statistikave mbi punën e diskut mund të ndihmojë në identifikimin e pengesave në këtë fushë. Një numër i madh leximesh ose shkrimesh mund të rezultojë që procesori të jetë i papunë duke pritur që të dhënat të përpunohen nga disku, duke rezultuar në rritjen e konsumit të CPU-së dhe kohën më të ngadaltë të përgjigjes.
5. Koha e përgjigjes së kërkesës, msKoha e ekzekutimit të pyetjes së aplikacionit mbetet një nga treguesit më të rëndësishëm të performancës së sistemit ose aplikacionit. Kjo kohë mund të matet në anën e serverit si masë e kohës që i duhet fundit për të përpunuar kërkesën; dhe nga ana e klientit, si tregues i kohës totale të nevojshme për serializimin/deserializimin, përcjelljen dhe përpunimin e kërkesës. Duhet të theksohet se jo çdo aplikacion i testimit të performancës mund të matë të dyja këto kohë.
Shiko gjithashtu
Lidhjet
- Platforma për shërbimet e testimit të uebsajteve dhe softuerit (rusisht)
- Portali i specialistëve të testimit të softuerit dhe sigurimit të cilësisë (rusisht) - Projekti i kushtohet çështjeve të testimit dhe përmirësimit të cilësisë së softuerit.
- Baza e njohurive të testuesit (rusisht) - Gjurmuesit e gabimeve, testimi i automatizuar, testimi i ngarkesës, testimi i përdorshmërisë, komunitetet, botimet e shtypura, librat
- Automatizimi i testimit të ngarkesës (rusisht)
- Shënime mbi testimin e ngarkesës (rusisht)
Letërsia
- Lisa Crispin, Janet Gregory Testimi i shkathët: Një udhëzues praktik për testuesit dhe ekipet e shkathëta. - M.: “Williams”, 2010. - 464 f. - (Seria e nënshkrimit të Addison-Wesley). - 1000 kopje. - ISBN 978-5-8459-1625-9
Fondacioni Wikimedia. 2010.
> Testimi i ngarkesës
Testimi i ngarkesës ose testimi i performancës
Testimi i stresit ose testimi i performancës- ky është testim i automatizuar që simulon punën e një numri të caktuar përdoruesish biznesi në një burim të përbashkët (të ndarë prej tyre).
Llojet kryesore të testimit të performancës
Le të shqyrtojmë llojet kryesore të testimit të ngarkesës, si dhe detyrat me të cilat përballen.
Testimi i performancës (Testimi i performancës)Qëllimi i testimit të performancës është të përcaktojë shkallëzueshmërinë e aplikacionit nën ngarkesë dhe ndodh si më poshtë:
- përcaktimi i numrit të përdoruesve që punojnë njëkohësisht me aplikacionin
- përcaktimi i kufijve të performancës së pranueshme ndërsa ngarkesa rritet (me një rritje të intensitetit të këtyre operacioneve)
- studim i performancës në ngarkesa të larta, ekstreme, stresi
Testimi i stresit ju lejon të kontrolloni se sa efikas është aplikacioni dhe sistemi në tërësi nën stres dhe gjithashtu të vlerësoni aftësinë e sistemit për të rigjeneruar, d.m.th. të kthehen në normalitet pas ndërprerjes së stresit. Stresi në këtë kontekst mund të jetë një rritje e intensitetit të operacioneve në vlera shumë të larta ose një ndryshim urgjent në konfigurimin e serverit. Gjithashtu, një nga detyrat e testimit të stresit mund të jetë vlerësimi i degradimit të performancës, kështu që qëllimet e testimit të stresit mund të mbivendosen me qëllimet e testimit të performancës.
Testimi i volumit (Testimi i vëllimit)Qëllimi i testimit të vëllimit është të merret një vlerësim i performancës ndërsa vëllimi i të dhënave në bazën e të dhënave të aplikacionit rritet, dhe ndodh sa vijon:
- matjen e kohës së ekzekutimit të operacioneve të përzgjedhura në intensitete të caktuara të këtyre operacioneve
- mund të përcaktohet numri i përdoruesve që punojnë njëkohësisht me aplikacionin
Detyra e testimit të stabilitetit (besueshmërisë) është të kontrollojë funksionalitetin e aplikacionit gjatë testimit afatgjatë (shumë orë) me një nivel mesatar ngarkese. Koha e ekzekutimit të operacionit mund të luajë një rol dytësor në këtë lloj testimi. Në të njëjtën kohë, vendi i parë vjen te mungesa e rrjedhjeve të kujtesës, rinisja e serverit nën ngarkesë dhe aspekte të tjera që ndikojnë në mënyrë specifike në stabilitetin e funksionimit.
Ngarkesa vs Testimi i Performancës
Në terminologjinë angleze mund të gjeni gjithashtu një lloj tjetër testimi - Testimi i ngarkesës- testimi i përgjigjes së sistemit ndaj ndryshimeve të ngarkesës (brenda kufirit të lejuar). Na u duk kështu Ngarkesa dhe Performanca Ata ende ndjekin të njëjtin qëllim: testimin e performancës (kohën e përgjigjes) nën ngarkesa të ndryshme. Kjo është arsyeja pse ne nuk i ndamë. Në të njëjtën kohë, dikush mund të ndajë. Gjëja kryesore është të kuptoni qëllimet e këtij ose atij lloji të testimit dhe të përpiqeni t'i arrini ato.
Kur vendosni një server në internet në përdorim të përditshëm, duhet të jeni të sigurt se ai
do të përballojë ngarkesën e planifikuar. Vetëm duke krijuar kushte afër luftimit,
ju mund të vlerësoni nëse fuqia e sistemit është e mjaftueshme dhe nëse
aplikacionet e përfshira në krijimin e përmbajtjes në ueb dhe faktorë të tjerë që ndikojnë
funksionimi i ueb serverit. Në këtë situatë ata do të vijnë në shpëtim mjete speciale,
të cilat do të ndihmojnë për të dhënë një vlerësim cilësor dhe sasior të punës Si
faqen e internetit në tërësi dhe komponentët e saj individualë.
Gjithçka shkon sipas planit
Para se të nxitojmë në betejë, së pari duhet të kuptojmë se çfarë duam
të marra si rezultat i testimit. Në fund të fundit, kontrolli, si çdo punë tjetër,
kërkon përgatitje paraprake. Nëse problemi është formuluar gabim
mund të arrihen rezultate që nuk pasqyrojnë plotësisht realitetin
statusi. Bazuar në ngarkesën e pritur të ueb serverit, është e nevojshme
përcaktoni kriteret e testimit. Vendosni atë që do të konsiderohet një sukses
po në lidhje me performancën e papranueshme të shërbimit (për shembull, koha e përgjigjes, ngarkimi
server). Ekzistojnë tre opsione testimi:
- Testimi i ngarkesës– Përcaktohet performanca e sistemit
me një ngarkesë të paracaktuar rreptësisht (të planifikuar, të punës). - Rezistenca (Stresi)– përdoret për të kontrolluar parametrat e sistemit
në kushte jonormale dhe ekstreme, detyra kryesore gjatë këtij testi është
përpiquni të prishni sistemin. Ju lejon të përcaktoni minimumin
sasia e nevojshme e burimeve të sistemit që aplikacioni të funksionojë, vlerësohet
aftësitë maksimale të sistemit dhe faktorët që kufizojnë këto aftësi.
Ai gjithashtu përcakton aftësinë e sistemit për të ruajtur integritetin e të dhënave kur
shfaqjen e situatave emergjente. - Performanca– kontroll gjithëpërfshirës, duke përfshirë
dy testet e mëparshme janë krijuar për të vlerësuar të gjithë treguesit e sistemit.
Rezultati i testit - numri maksimal i përdoruesve, e cila mund
qasje në të njëjtën kohë në faqen e internetit, numrin e kërkesave të përpunuara
aplikacioni ose koha e përgjigjes së serverit. Në bazë të rezultatit të marrë,
webmaster dhe administratori i rrjetit (të tjerët gjithashtu marrin pjesë në funksionimin e serverit
komponentët e rrjetit, ruterat, muri i zjarrit, serveri i memories dhe proxy, baza e të dhënave
të dhëna, etj.) do të jetë në gjendje të identifikojë paraprakisht pengesat që lindin për shkak të
funksionimin e pabalancuar të komponentëve dhe korrigjoni situatën më parë
përfshijnë sistemin në punë reale.
Gjatë testimit simulon funksionimin e njëkohshëm të disa qindra
ose mijëra vizitorë. Për vërtetësi më të madhe, secila prej virtualeve
përdoruesit mund të "shëtisin" rreth faqes sipas një skenari individual dhe të kenë personal
opsione. Ju gjithashtu mund të simuloni majat afatshkurtra gjatë testimit
ngarkoni kur numri i vizitorëve rritet papritur, gjë që është shumë
relevante për faqet me një audiencë të pabarabartë. Pra, për të kryer plotësisht
testimi, duhet të dini:
- sa vizitorë janë planifikuar të priten mesatarisht, në ngarkesën maksimale,
koha e ngarkesës së pikut; - a mund të kenë shumë përdorues të njëjtën adresë IP dhe/ose
Hyrja: Fjalëkalimi; - numri mesatar i faqeve të shikuara nga një përdorues, është atje
dallimet në sjellje midis përdoruesve të regjistruar dhe anonimë,
marrëdhëniet sasiore midis përdoruesve të tillë, faqeve të vizituara dhe
koha e shpenzuar nga përdoruesi në nyje; - prania e faqeve dinamike dhe faqeve që ndryshojnë gjatë një periudhe kohore
periudha dhe sa shpesh ndodh; - A përdoret emaili, për shembull, për të verifikuar kredencialet?
përdorues; - çfarë informacioni tjetër shtesë përdoret për të kontrolluar statusin
përdorues (cookies); - a kërkohet konfirmimi i autoritetit të përdoruesit nga një palë e tretë?
ose një server në distancë (për shembull, një numër karte krediti), dhe nëse
jepet informacion për testim; - Kapaciteti i disponueshëm i kanalit, gjerësia mesatare e tij për një
përdorues; - nëse puna e disa përdoruesve mund të shkaktojë një përplasje;
- nëse përdoret një lidhje e sigurt HTTPS;
- A po përdorni aplikacione Java, media streaming, shtojca speciale, çfarë
kërkohet nga ana e klientit për t'i mbështetur ata; - nëse përdoret memoria e faqes;
- ngjarje teknike të planifikuara që mund të ndikojnë në funksionimin
serverët, dhe koha e zbatimit të tyre (sinkronizimi, arkivimi, etj.).
Secili prej këtyre parametrave mund të ndikojë në rezultatin përfundimtar. Jo e nevojshme
Për të përfshirë të gjitha kontrollet në një test, fillimisht mund ta ndani detyrën në nën-detyra.
Për shembull, kontrollimi i sistemit themelor (serverët: ueb, aplikacionet, bazat e të dhënave) dhe
kontrollimi i moduleve individuale (servlets, skriptet, etj., për shembull, kontrolli
vërtetimi për një numër të madh përdoruesish). Si rezultat, kur
testimi, prodhohen tre lloje grafikësh: linear, jolinear dhe ngopje. NË
Në rastin e parë, kur ngarkesa rritet, koha e përgjigjes (d.m.th. përpunimi) mbetet
të përhershme. Ndërsa ngarkesa rritet më tej, rritet edhe koha e përgjigjes
(pothuajse në mënyrë lineare), dhe më në fund ndodh një situatë e ngjashme me një sulm DOS, kur koha
reagimi rritet pafundësisht. Tani që plani i veprimit është gati, le të kalojmë
një përmbledhje e shkurtër e shërbimeve që do të ndihmojnë në zbatimin e tij. Le të fillojmë me ato të lira.
Arkitektura e testimit të sistemeve të hapura
OpenSTA(www.opensta.org)
- më shumë se një aplikacion testimi, është një arkitekturë e hapur, e projektuar
rreth standardeve të hapura. Projekti u krijua në vitin 2001 nga një grup kompanish CYRANO,
i cili mbështeti versionin komercial të produktit, por CYRANO u shpërbë dhe tani
OpenSTA shpërndahet si një aplikacion me burim të hapur sipas një licence
GNU GPL, funksionon në Windows NT 4.0SP5/2000/XP. Kërkon të dhënat e Microsoft për të punuar
Access Components (MDAC), të cilat mund të shkarkohen nga faqja e internetit e korporatës.
Vegla aktuale lejon testimin e ngarkesës HTTP/HTTPS
shërbime, megjithëse arkitektura e saj është e aftë për më shumë. OpenSTA lejon
krijoni skripta testimi në një gjuhë të specializuar SCL (Script Control
Gjuhe). Për të thjeshtuar krijimin dhe redaktimin e skripteve, përdorni
vegël speciale Script Modeler. Zgjidhni Mjetet - Kanonizoni URL-në,
Shfletuesi i internetit do të hapet. Ne thjesht ecim nëpër faqe, duke mbledhur lidhje që do
ruajtur në skript. Të gjithë parametrat e kërkesës mund të modifikohen, është e mundur
zëvendësimi i ndryshueshëm. Struktura e testit dhe titujt do të shfaqen në skeda
në panelin e majtë. Është i përshtatshëm për të kombinuar testet në grupe. Cilësimet e përfaqësuesit janë të specifikuara në
vetë skriptin, kështu që ju mund të specifikoni shumë serverë. Mundësia e zbatuar
organizimi i testimit të shpërndarë që rrit realizmin, ose kur
Nuk është e mundur të ngarkoni një server të fuqishëm nga një kompjuter. Secila prej makinave është si kjo
sistemi mund të ekzekutojë grupin e vet të detyrave, dhe hosti i depove mbledh
dhe ruajtjen e rezultateve. Pas instalimit në çdo sistem testimi
është nisur serveri i emrave, funksionimi i të cilit është i detyrueshëm. Mbështetur
vërtetimi i përdoruesve në një burim ueb dhe vendosja e lidhjeve nëpërmjet
Protokolli SSL. Parametrat e funksionimit të sistemit të ngarkuar mund të kontrollohen nga
duke përdorur mjetet SNMP dhe Windows NT. Rezultatet e testit duke përfshirë kohën
përgjigjet, numri i bajteve të transferuara për sekondë, kodet e përgjigjeve për secilën kërkesë
dhe numri i gabimeve paraqitet në formën e tabelave dhe grafikëve. Duke përdorur një të madhe
numri i filtrave ju lejon të zgjidhni rezultatet e nevojshme. Rezultati mund të jetë
eksportoni në skedarin CSV. Aftësitë e daljes së raportit janë disi të kufizuara,
por duke ndjekur lidhjet në faqe mund të gjeni skriptet dhe shtojcat që thjeshtojnë, ndër të tjera,
analiza e informacionit të marrë.
Apache JMeter
Apache JMeter(jakarta.apache.org/jmeter)
është një aplikacion Java me burim të hapur i krijuar për ngarkim
duke testuar jo vetëm aplikacionet në internet dhe komponentët e tyre individualë (skriptet,
servlet, objekte Java, etj.), por edhe serverë FTP, baza të të dhënave (me
duke përdorur JDBC) dhe rrjetin. Funksionaliteti zgjerohet duke përdorur shtojca.
Mbështetur SSL (përmes Java Secure Sockets Extension). E mundshme
teston si duke përdorur një ndërfaqe grafike ashtu edhe nga linja e komandës.
Përdorimi i Java do të thotë ndër-platformë, pra JMeter
punon me siguri në sisteme të ndryshme *nix, në Windows nga 98 dhe disa të tjerë
OS. Shpërndarë nën licencën Apache.
NË JMeter mekanizmat për autorizimin e virtual
përdoruesit, sesionet e përdoruesve, shabllonet, caching dhe
analiza e mëvonshme offline e rezultateve të testit, funksionet ju lejojnë të gjeneroni
kërkesën tjetër bazuar në përgjigjen e serverit ndaj asaj të mëparshme. Unë kam një mundësi
kryejnë teste të shpërndara. Në këtë rast, një nga kompjuterët është
server (bin/jmeter-server.bat), i cili menaxhon klientët dhe mbledh
informacion përmbledhës.
Për të punuar, thjesht ekzekutoni ApacheJMeter.jar ose jmeter.bat në tastierë
(Windows) ose jmeter.sh (*nix).
JMeter ka një server proxy të integruar që është krijuar për të regjistruar
seanca, por mund të përdorni edhe një të jashtme. Para se të filloni testimin, duhet
krijoni një plan testimi që përshkruan një sërë detyrash që duhen përfunduar
JMeter. Ai duhet të përmbajë një ose më shumë grupe thread (Thread
Grupet) dhe elementë të tjerë:
- Kontrollues logjik;
- Kontrollorët e gjenerimit të mostrave;
- Dëgjuesit;
- Timers;
- Pohimet;
- Elementet e konfigurimit.
Para së gjithash, shtoni një grup thread (Edit - Add - Thread Group). Brenda saj
në cilësimet ne tregojmë emrin, numrin e fijeve që do të hapen, d.m.th
përdoruesit virtualë (Numri i temave), koha e vonesës ndërmjet nisjeve
threads (Ramp-Up Period), numri i cikleve të ekzekutimit të detyrave (Loop Count),
Këtu mund të përcaktoni edhe ekzekutimin e një detyre sipas një plani (Sheduler). Me tutje,
Duke klikuar në grupin e krijuar, duhet të shtoni një kërkesë mostër (Sampler) duke zgjedhur
atë nga lista. Për testimin e ngarkesës ose testimin e performancës
server, thjesht zgjidhni kërkesën HTTP (Shto -Sampler - Kërkesë HTTP). Këtu
tregoni emrin, adresën IP dhe portin e serverit në internet, protokollin, metodën e transferimit të të dhënave
(GET, POST), parametrat e ridrejtimit, transferimi i skedarëve në server. Ne konfigurojmë dhe
klikoni në Run. Prodhimi i rezultatit kryhet duke përdorur Listeners, secili
tregon rezultatin në mënyrën e vet. Për shembull, Grafiku Agregate shfaq totalin
rezultatet e testit në formën e tabelave dhe grafikëve.
Produktet falas, mjerisht, kanë mbaruar, tani ka disa zgjidhje tregtare.
WAPT – Testimi i aplikacionit në ueb
WAPT(www.loadtestingtool.com)
ju lejon të testoni qëndrueshmërinë e një faqe interneti dhe aplikacione të tjera duke përdorur
ndërfaqe në internet, në ngarkesa reale. Zhvilluar nga një kompani Novosibirsk
SoftLogica LLC. Ky është një nga programet e rishikimit më të lehtë për t'u përdorur. Për
për të kryer një test të thjeshtë, nuk keni nevojë as të shikoni dokumentacionin, ndërfaqen
e thjeshtë, por jo e lokalizuar. Drejton Windows 98 e tutje, i mbështetur
dhe Vista. Për kontroll WAPT mund të krijojë shumë virtuale
përdoruesit, secili me parametra individualë. Mbështetur shumëfish
llojet e vërtetimit dhe cookies. Skenari ju lejon të ndryshoni vonesat ndërmjet
pyet dhe gjeneron në mënyrë dinamike disa parametra testimi,
duke imituar kështu sa më shumë sjelljen e përdoruesve realë. Për të kërkuar
Opsione të ndryshme për kokën HTTP mund të zëvendësohen në cilësimet që mundeni
specifikoni kodimin e faqes. Parametrat User-Agent, X-Forwarded-For, IP janë specifikuar
në cilësimet e skenarit. Vlerat e parametrave të pyetjes mund të llogariten
në disa mënyra, duke përfshirë të përcaktuar nga përgjigja e serverit ndaj të mëparshmes
pyetja duke përdorur variabla dhe funksione. Puna e mbështetur nëpërmjet të sigurt
Protokolli HTTPS (dhe të gjitha llojet e serverëve proxy). Skriptet e krijuara të ruajtura në
Skedari XML, mund të ripërdoret. Përveç standardit Performance dhe
Stresi, ka disa teste të tjera në listë që ju lejojnë të përcaktoni
numri maksimal i përdoruesve dhe testoni serverin nën ngarkesë
gjatë një periudhe të gjatë.
Për të kryer testin, si rezultat duhet të zgjidhni New – Scenario
Magjistari i krijimit të testit do të hapet. Në hapin e parë tregohet lloji i testit dhe më pas
Çdo dritare është e mbushur me parametrat e testit të ardhshëm. Këtu mund të specifikoni
numri fiks i përdoruesve virtualë, ose rritje graduale
duke treguar numrin minimal dhe maksimal dhe intervalin kohor, të vendosur
kohëmatës testimi. Hapi tjetër është të vendosni kohën midis klikimeve (mendoni
koha), shpejtësia e lidhjes, tregon gamën e adresave IP që do të jenë
përdoret nga përdoruesit virtualë. Klikimi në Listën e Adresave IP do të lejojë
bëni një listë të adresave të tilla. Parametri HTTP User-Agent dhe
Emulimi i përfaqësuesit është aktivizuar. Nëse dëshironi që përdoruesit virtualë të kenë
cilësimet individuale, në hapin tjetër të magjistarit për secilën prej tyre
Ju duhet të krijoni profilin tuaj duke klikuar i ri ose duke ngarkuar një të ruajtur. Në tjetrën
Në dritaren e programit, duhet të vendosni parametrat e profilit.
Pasi të klikoni butonin Finish, skripti ruhet. Tani për të vënë në dukje
objekt testimi, krijoni një profil New – Profile dhe plotësoni të gjithë parametrat në
skedat. Këtu mund të modifikoni edhe disa parametra të specifikuar
më parë me ndihmën e një mjeshtri. Tregohet gjithashtu ngarkimi i vizatimeve nga virtuali.
përdoruesi, parametrat e vërtetimit, përdorimi i Cookies dhe të tjera.
Në skedën Regjistruesi, tregoni adresën e faqes, disponueshmëria e së cilës mund të jetë menjëherë
kontrolloni duke klikuar Shko. Në të njëjtën kohë, do të pasojë një kërkesë për të nisur Recorder, e cila
do të gjurmojë faqet e vizituara dhe do të regjistrojë URI-të (ato do të shfaqen në
panelet në të majtë). Kur të jenë mbledhur të gjitha informacionet, klikoni Run Test. Raporte të detajuara
në formë grafiku shfaqen gjatë testimit, pas përfundimit do të ketë
Faqja HTML është krijuar. Si rezultat, ju mund të merrni informacion për kohën
përgjigja e serverit me ngarkesë në rritje, sipas numrit të gabimeve të transmetuara dhe
bajtet e marra etj.
NeoLoad
NeoLoad(www.neotys.com)
- një sistem tjetër që ju lejon të kryeni testimin e ngarkesës
aplikacionet në ueb. Shkruar në Java, funksionon në kompjuterë që funksionojnë
duke përdorur Windows NT/2000/XP, Linux dhe Solaris. Në raport mund të merrni
informacion të detajuar për çdo skedar të shkarkuar. NeoLoad është shumë i përshtatshëm për
vlerësimi i performancës së komponentëve individualë (AJAX, PHP, ASP, CGI, Flash, applets dhe
etj). Është e mundur të vendoset koha e vonesës ndërmjet kërkesave (koha e mendimit) globalisht
dhe individualisht për çdo faqe. Testimi kryhet si me
duke përdorur një guaskë grafike shumë të përshtatshme dhe duke përdorur komandën
vargjet (duke përdorur një skedar XML të parapërgatitur). Mbështet punën me
Protokolli HTTPS, me përfaqësues HTTP dhe HTTPS, vërtetim bazë të uebit dhe kuki,
zbulimin automatik të të dhënave gjatë regjistrimit të një skripti dhe më pas riprodhimin e tij
koha e testimit. Për të punuar me profile të ndryshme për regjistrimin e përdoruesve
mund të përdoren variablat. Kur kryeni një provë, mund të përdorni
monitorë shtesë (SNMP, WebLogic, WebSphere, RSTAT dhe Windows, Linux,
Solaris), duke ju lejuar të kontrolloni parametrat e sistemit në të cilin funksionon
ueb server.
Me ndihmë NeoLoad Ju gjithashtu mund të kryeni teste të shpërndara. Nje nga
kompjuterët janë kontrollues, gjeneratorët janë instaluar në pjesën tjetër
load (loadGenerator). Kontrolluesi shpërndan ngarkesën midis loadGenerator dhe
mbledh statistika.
Puna me përdoruesit virtualë është shumë e përshtatshme. Përdoruesit
kanë cilësime individuale, pastaj ato kombinohen në Popullata (duhet
duhet të krijohet të paktën një Popullsi), te Popullsitë mund të vendosni gjeneralin
sjellje (për shembull, 40% e përdoruesve të popullsisë vizitojnë burimet dinamike,
20% lexojnë lajme). Përdoruesit virtualë mund të kenë individuale
Adresa IP, gjerësia e brezit dhe skripti juaj i testimit.
Është shumë e lehtë të krijosh një skenar për një test të ardhshëm. Hapni aplikacionin (nëse
lëshimi i parë do t'ju duhet të futni një çelës regjistrimi, versioni 30-ditor pas
regjistrimi do të dërgohet me postë), zgjidhni Projektin e Ri, shkruani emrin
projekti. Pas kësaj, do të shfaqet një sugjerim i vogël në lidhje me më tej
veprimet, duke klikuar Start Recording do të nisë shfletuesi i internetit, të gjitha lëvizjet do të jenë
regjistruar. Kur të përfundoni, klikoni Stop Recording ose mbyllni shfletuesin.
Do të nisë një magjistar që do t'ju ndihmojë të krijoni përdorues virtualë dhe
do të kërkojë automatikisht parametrat dinamikë në faqet e regjistruara,
do të vendosë vlerën mesatare të kohës së mendimit. Komponentët e faqes (HTML, imazhe, CSS)
ruhen veçmas. Për të marrë rezultatin, duhet të kaloni tre hapa:
- Dizajni - cilësimet e projektit, ka tre skeda. Depoja tregon
faqet e internetit dhe parametrat e pyetjeve, në Virtual User virtual
përdoruesit, specifikoni URL-të që duhet të "vizitojnë" dhe shtesë
kushtet nga skeda e majtë e fushës Veprimet. Në Popullsitë – detyra për secilin grup
përdoruesit. Veprimet e mëposhtme mund të zgjidhen në Veprimet: Vonesa
(vendosja e vendosjes), Loop (kërkesa e përsëritur), Ndërsa (cikli), If...Then...Else
(kusht), Enë dhe Enë e rastësishme (veprimet në grup), Provoni...Kape
(trajtimi i gabimeve), Ndalimi i përdoruesit virtual (ndalimi i virtuales
përdorues). - Runtime – specifikohen parametrat e testimit, testi kryhet. Këtu brenda
Statistikat shfaqen në skeda të veçanta ndërsa testi përparon. - Rezultatet – është përgjegjës për paraqitjen e statistikave të ndryshme në formën e tabelave dhe grafikëve.
Për më tepër, përveç vlerave të përgjithshme, duke përdorur sistemin e filtrit mund të zgjidhni
informacion për çdo parametër. Nëse dëshironi, projekti mund të ruhet për ripërdorim.
përdorni. Ndër produktet e paraqitura, aftësia për të krahasuar rezultatet
vetëm testi ka NeoLoad.
Duke përdorur shërbimet e testimit të ngarkesës, mund të merrni informacion rreth
funksionimin e shërbimit të internetit, të marrë masat e nevojshme për eliminimin e të identifikuarve
mangësitë dhe garantojnë performancën e kërkuar.
Produkte nga Microsoft
Microsoft Corporation ofron dy produkte që lejojnë
testoni ueb serverin nën ngarkesë. Kjo Stresi i aplikacionit të Microsoft
Mjet Dhe Mjeti i Analizës së Kapacitetit të Uebit. E para shpërndahet si
një produkt i veçantë dhe ka një ndërfaqe grafike. E dyta është përfshirë në
komplet mjetesh Shërbimet e Informacionit në Internet 6.0 Mjetet e Kompleteve të Burimeve,
punon nga linja e komandës. MAST më vizuale në krijimin e një testi
një magjistar i thjeshtë për krijimin e testeve do të ndihmojë, është e mundur të punoni me cookie, të rregulloni
ngarkon në URL të ndryshme. Skripti i testit mund të krijohet me dorë ose
regjistrohet duke përdorur një shfletues uebi dhe redaktohet nëse është e nevojshme. NË MBETJE
niveli i stresit rregullohet duke vendosur numrin e fijeve,
duke bërë kërkesa në server, dhe numrin e përdoruesve virtualë
llogaritet si prodhim i numrit të fijeve dhe numrit të prizave të hapura nga secila
fijet Në fund të testit, marrim një raport të thjeshtë në formë teksti, në të cilin
jepet informacion mbi numrin e kërkesave të përpunuara për njësi kohore, mesatarja
koha e vonesës, shpejtësia e transferimit të të dhënave drejt dhe nga serveri, numri
gabime etj. Raporti mund të eksportohet në një skedar CSV. Nuk ka opsione për
përpunimi statistikor nuk ofrohet, domethënë, vetëm me ndihmën e tij mundeni
vlerësoni performancën në kushte të caktuara.
