Cjelovit vodič za ispitivanje izvedbe s primjerima

complete performance testing guide with examples

Što je ispitivanje performansi?

Testiranje performansi poznato je i pod nazivom „Perf testiranje“, vrsta je ispitivanja koja se provodi kako bi se provjerilo kako aplikacija ili softver radi pod opterećenjem u smislu odziva i stabilnosti. Cilj ispitivanja izvedbe je identificirati i ukloniti uska grla u izvedbi iz aplikacije.

Ovaj se test uglavnom provodi kako bi se provjerilo ispunjava li softver očekivane zahtjeve za brzinu, skalabilnost i stabilnost aplikacije.

funkcionalno ispitivanje i nefunkcionalno ispitivanje

U ovom ćemo poglavlju obraditi iscrpne detalje kao što su - Vrste testiranja, proces i pisanje strategije ispitivanja izvedbe od nule.

Ovo je detaljna serija tutorijala koju biste možda željeli označiti!

Istražimo!

Popis SVIH vodiča za ispitivanje izvedbe u ovoj seriji:

Vodič br. 1: Kompletan vodič za ispitivanje performansi (Ovaj vodič)
Vodič br. 2: Razlika između ispitivanja performansi, opterećenja i naprezanja
Vodič br. 3: Funkcionalno ispitivanje vs ispitivanje performansi
Vodič br. 4: Plan ispitivanja i strategija ispitivanja
Vodič br. 5: Načini za nadopunjavanje vašeg testiranja izvedbe
Vodič br. 6: Vodič za testiranje performansi u oblaku
Vodič br. 7: Vodič za testiranje izvedbe mobilne aplikacije
Vodič br. 8: Kako izvršiti ručno ispitivanje performansi
Vodič br. 9: Vodič za testiranje izvedbe web stranica
Vodič br. 10: Tvrtke za ispitivanje performansi
Vodič br. 11: Ispitivanje performansi pomoću LoadRunnera (Niz)

Alati:

Vodič br. 12: Alati za testiranje vrhunskih performansi
Vodič br. 13: Vodič za ispitivanje performansi Neoload
Vodič br. 14: Vodič za ispitivanje performansi za mobilne uređaje BlazeMeter
Vodič br. 15: Vodič za testiranje opterećenja, stresa i performansi WAPT-a
Vodič br. 16: Vodič za testiranje izvedbe web mjesta SmartMeter.io

Što ćete naučiti:

• Vrste ispitivanja performansi
  • Ispitivanje opterećenja
  • Ispitivanje naprezanja
  • Ispitivanje glasnoće
  • Ispitivanje kapaciteta
  • Ispitivanje pouzdanosti / oporavka
• Postupak ispitivanja izvedbe
• Kako napisati dokument o strategiji ispitivanja izvedbe?
  • Uzorak Predložak strategije ispitivanja izvedbe
  • #1. Uvod
    • Cilj
    • Arhitektura
  • # 2) Opseg
    • U opsegu
    • Izvan dosega
  • # 3) Pristup
    • Scenariji ispitivanja izvedbe
    • Vrste ispitivanja performansi
    • Metrika izvedbe
    • Aktivnosti i rezultati ispitivanja izvedbe
  • # 4) Podaci o ispitivanju
  • # 5) Kriteriji za ulazak i izlazak
  • # 6) Upravljanje nedostacima
    • Definicija ozbiljnosti nedostataka
  • # 7) Alati i tehnike ispitivanja
  • # 8) Kriteriji suspenzije i ponovnog pokretanja
  • # 9) Ispitni rezultati
  • # 10) Uloge i odgovornosti
  • # 11) Potencijalni rizici i plan ublažavanja
  • # 12) Pretpostavke
  • # 13) Ovisnosti
  • # 14) Kratice
• Najbolji primjeri za realistično testiranje izvedbe
  • # 1) Planiranje
  • # 2) Razvoj
  • # 3) Izvršenje
  • # 4) Analiza
  • Zaključak
  • Preporučena literatura

Vrste ispitivanja performansi

Ispitivanje opterećenja

Ispitivanje opterećenja vrsta je ispitivanja performansi u kojem se aplikacija testira radi svojih performansi u normalnoj i vršnoj upotrebi. Izvedba aplikacije provjerava se s obzirom na njezin odgovor na zahtjev korisnika i njezinu sposobnost da dosljedno odgovori u okviru prihvaćene tolerancije na različita opterećenja korisnika.

Ključna razmatranja su:

1. Koje je maksimalno opterećenje aplikacija u stanju prije nego što se aplikacija počne ponašati neočekivano?
2. Koliko podataka baza podataka može obraditi prije nego što sustav uspori ili se primijeti pad?
3. Postoje li problemi povezani s mrežom koje treba riješiti?

Ispitivanje naprezanja

Testiranje naprezanja koristi se za pronalaženje načina za razbijanje sustava. Test također pruža raspon maksimalnog opterećenja koje sustav može podnijeti.

Općenito, testiranje naprezanja ima inkrementalni pristup gdje se opterećenje postupno povećava. Test započinje opterećenjem za koje je aplikacija već testirana. Zatim se polako dodaje više tereta kako bi se stres naglasio. Točka u kojoj počnemo vidjeti da poslužitelji ne reagiraju na zahtjeve smatra se prijelomnom točkom.

Treba odgovoriti na sljedeća pitanja:

• Koje je maksimalno opterećenje koji sustav može podnijeti prije nego što se pokvari?
• Kako se sustav kvari?
• Može li se sustav oporaviti nakon pada?
• Na koliko se načina sustav može slomiti i koji su slabi čvor pri rukovanju neočekivanim opterećenjem?

Ispitivanje glasnoće

Volumensko ispitivanje je provjera da količinu podataka kojima aplikacija obrađuje ne utječe na izvedbu aplikacije. Da bi se izvršilo ispitivanje volumena, u bazu podataka unosi se ogroman volumen podataka. Ovaj test može biti inkrementalni ili stalni test. U inkrementalnom testu, količina podataka povećava se postupno.

Općenito, s upotrebom aplikacije, veličina baze podataka raste i potrebno je testirati aplikaciju na teškoj bazi podataka. Dobar primjer za to može biti web mjesto nove škole ili fakulteta s malim količinama podataka koje je potrebno pohraniti u početku, ali nakon 5-10 godina podataka u bazi podataka web mjesta je mnogo više.

Ispitivanje kapaciteta

=> Je li aplikacija sposobna ispuniti količinu posla i pod normalnim i uz vršnim uvjetima opterećenja?

Ispitivanje kapaciteta obično se provodi za buduće izglede. Ispitivanje kapaciteta odnosi se na sljedeće:

1. Hoće li aplikacija moći podržati buduće opterećenje?
2. Je li okruženje sposobno izdržati nadolazeće povećano opterećenje?
3. Koji su dodatni resursi potrebni da bi okoliš bio dovoljno sposoban?

Ispitivanje kapaciteta koristi se za određivanje broja korisnika i / ili transakcija koje će određena web aplikacija podržati i još uvijek ispunjavati izvedbu. Tijekom ovog testiranja, resursi poput kapaciteta procesora, propusnosti mreže, upotrebe memorije, kapaciteta diska itd. Uzimaju se u obzir i mijenjaju kako bi se postigao cilj.

Internetsko bankarstvo savršen je primjer gdje bi testiranje kapaciteta moglo igrati glavnu ulogu.

Pouzdanost / oporavak Testiranje

Ispitivanje pouzdanosti ili ispitivanje oporavka - je provjera je li aplikacija sposobna vratiti se u normalno stanje nakon kvara ili abnormalnog ponašanja i koliko vremena treba za to (drugim riječima, procjena vremena).

Ako internetska stranica za trgovanje doživi neuspjeh u kojem korisnici ne mogu kupiti / prodati dionice u određeno doba dana (vršni sati), ali to mogu učiniti nakon sat ili dva, možemo reći da je aplikacija pouzdana ili oporavio od nenormalnog ponašanja.

Postupak ispitivanja izvedbe

Evo svih aktivnosti izvedenih u ovom testiranju:

# 1) Analiza zahtjeva / prikupljanje

Tim za izvedbu komunicira s klijentom radi identifikacije i prikupljanja zahtjeva - tehničkih i poslovnih. To uključuje dobivanje informacija o arhitekturi aplikacije, tehnologijama i korištenoj bazi podataka, namijenjenim korisnicima, funkcionalnosti, upotrebi aplikacije, zahtjev za ispitivanje , hardverski i softverski zahtjevi itd.

# 2) Odabir POC / alata

Jednom kada se utvrdi ključna funkcionalnost, POC (Proof Of Concept - što je svojevrsna demonstracija aktivnosti u stvarnom vremenu, ali u ograničenom smislu) vrši se pomoću dostupnih alata.

Popis dostupnih alata ovisi o cijeni alata, protokolu koji aplikacija koristi, tehnologijama koje se koriste za izgradnju aplikacije, broju korisnika koje simuliramo za test itd. Tijekom POC-a kreiraju se skripte za identificirani ključ funkcionalnost i izvršava se s 10-15 virtualnih korisnika.

# 3) Plan i dizajn ispitivanja performansi

Ovisno o informacijama prikupljenim u prethodnim fazama, provodi se planiranje i projektiranje ispitivanja.

Planiranje testa uključuje informacije o tome kako će se odvijati test izvedbe - testno okruženje, radno opterećenje, hardver itd.

Više o dokumentu Strategije testiranja u nastavku.

# 4) Razvoj testova performansi

• Stvoreni su slučajevi upotrebe za funkcionalnost identificiranu u planu ispitivanja kao opseg PT-a.
• Ti se slučajevi upotrebe dijele s klijentom na odobrenje. Ovo je kako bi se osiguralo da će skripta biti snimljena ispravnim koracima.
• Jednom odobren, razvoj skripti započinje snimanjem koraka u slučajevima korištenja s alatom za ispitivanje izvedbe odabranim tijekom POC-a (Proof of Concepts) i poboljšanim izvođenjem Korelacije (za rukovanje dinamičkom vrijednošću), Parametrizacijom (zamjena vrijednosti) i prilagođenim funkcijama kao po situaciji ili potrebi. Više o tim tehnikama u našim video tutorialima.
• Skripte se zatim provjeravaju prema različitim korisnicima.
• Paralelno sa stvaranjem skripti, tim za izvedbu također nastavlja raditi na postavljanju testnog okruženja (softver i hardver).
• Tim za izvedbu također će se brinuti za metapodatke (back-end) putem skripti ako klijent ne poduzme ovu aktivnost.

# 5) Modeliranje testova performansi

Model izvedbe opterećenja stvoren je za izvršavanje testa. Glavni cilj ovog koraka je provjeriti postižu li se zadani mjerni podaci izvedbe (koje pružaju klijenti) tijekom testa ili ne. Postoje različiti pristupi za stvaranje modela opterećenja. “ Mali zakon ”Koristi se u većini slučajeva.

# 6) Izvršenje testa

Scenarij je dizajniran prema Load modelu u Controlleru ili Performance Centeru, ali početni testovi se ne izvršavaju s maksimalnim brojem korisnika koji su u Load modelu.

Izvršenje testa vrši se postupno. Na primjer, Ako je maksimalan broj korisnika 100, scenariji se prvo pokreću s 10, 25, 50 korisnika i tako dalje, na kraju prelazeći na 100 korisnika.

# 7) Analiza rezultata ispitivanja

Rezultati ispitivanja najvažniji su rezultat ispitivača performansi. Tu možemo dokazati povrat ulaganja (ROI) i produktivnost koju napori za testiranje performansi mogu pružiti.

Neke od najboljih praksi koje pomažu procesu analize rezultata:

1. Jedinstven i značajan naziv za svaki rezultat testa - ovo pomaže u razumijevanju svrhe testa.
2. U sažetak rezultata testa uključite sljedeće podatke:

• Razlog neuspjeha
• Promjena performansi aplikacije u usporedbi s prethodnim probnim radom
• Promjene napravljene u testu s točke gradnje aplikacije ili testnog okruženja.
• Dobra je praksa sačiniti sažetak rezultata nakon svake probne vožnje, tako da se rezultati analize ne sastavljaju svaki put kada se navode rezultati ispitivanja.
• PT općenito zahtijeva mnogo probnih vožnji da bi donio točan zaključak.
• U sažetku rezultata dobro je imati sljedeće točke:
  • Svrha testa
  • Broj virtualnih korisnika
  • Sažetak scenarija
  • Trajanje testa
  • Propusnost
  • Grafovi
  • Usporedba grafova
  • Vrijeme odziva
  • Došlo je do pogreške
  • Preporuke

# 8) Izvještaj

Rezultati ispitivanja trebaju biti pojednostavljeni kako bi zaključak bio jasniji i ne bi trebali biti izvedeni. Razvojnom timu treba više informacija o analizi, usporedbi rezultata i pojedinostima kako su rezultati dobiveni.

Izvještaj o ispitivanju smatra se dobrim ako je kratak, opisan i precizan.

Kako napisati dokument o strategiji ispitivanja izvedbe?

Ovaj će vam vodič objasniti kako napisati uzorak strategije ispitivanja izvedbe za aplikaciju za razmjenu poruka.

Imajte na umu da je ovo samo primjer i da će se zahtjevi razlikovati od klijenta do klijenta. U ovom ćemo uputstvu upoznati i najbolje prakse za testiranje performansi.

kako napisati učinkovite test slučajeve

Uzorak Predložak strategije ispitivanja izvedbe

O aplikaciji ABC chat - Pretpostavimo da je ovo radni stol za chat koji u tvrtki koristi njihov agent za korisničku podršku, ovaj program za chat koristi XMPP protokol, tj. Proširivi protokol za razmjenu poruka i prisutnosti te poslužitelj Open fire za slanje i primanje trenutnih poruka.

Na ovom postojećem klijentu za chat napravljena su neka poboljšanja poput daljinskog upravljanja računalom, dijagnoze računala, alata za popravak, internetskog chata itd., Tako da je ova strategija testiranja izvedbe primjer takvih aplikacija.

Za ovu aplikaciju pretpostavimo da se projektni tim odlučio koristiti JMeter za ispitivanje performansi i JIRA za praćenje kvara.

Prva stranica dokumenta Strategije ispitivanja uspješnosti trebala bi sadržavati naslov dokumenta i autorska prava tvrtke.

Druga stranica treba sadržavati kontrolu dokumenata koja uključuje, povijest verzija dokumenta, popis recenzenata i odobravatelja i popis suradnika.

Treća stranica trebala bi sadržavati sadržaj, a zatim slijede teme u nastavku.

#1. Uvod

Svrha ovog dokumenta je definirati / objasniti kako će se ispitivanje performansi izvoditi na ABC chat aplikaciji za trenutno i buduće stanje.

ABC aplikacija za chat interni je radni sto Agent za daljinsku podršku. Ovaj radni stol služit će za ispunjavanje zahtjeva kupaca. Ovaj Workbench ima mogućnosti kao što su internetski chat, identifikacija kupca, daljinsko upravljanje računalom, dijagnostika računala i alati za popravak.

Cilj

Ključni ciljevi ispitivanja izvedbe su sljedeći:

• Da biste stekli uvjerenje da su promjene postojeće aplikacije za chat u skladu s definiranim Ugovorom o razini usluge.
• Kako bi se osiguralo da rezultat novih poboljšanja ne utječe na izvedbu aplikacije, dostupnost usluge i stabilnost aplikacije.
• Vremena odgovora na transakcije ostaju unutar prihvatljive tolerancije za sve veći profil opterećenja.
• JVM-ovi pokazuju stabilnu upotrebu memorije u sve većim profilima opterećenja.

Slika dolje jasno objašnjava postupak ispitivanja i optimizacije performansi:

Arhitektura

U ovu sesiju morate uključiti dijagram arhitekture svog projekta.

# 2) Opseg

U opsegu

Ispod je opseg ispitivanja performansi za ABC chat radni stol:

• Stjecanje znanja o ključnim poslovnim transakcijama i raspodjela opterećenja nakon detaljnog proučavanja sustava.
• Utvrdite kritične scenarije za ispitivanje izvedbe uz pomoć različitih projektnih staza.
• Koristite rezultate prethodnih izdanja kao polaznu osnovu za buduća izdanja.
• Provjerite i potvrdite okruženje za testiranje performansi i infrastrukturu alata za ispitivanje performansi / opterećenja za sve dodatne Agent strojeve.
• Priprema skripti za ispitivanje performansi pomoću JMetera za identificirane scenarije koji oponašaju identificirano vršno opterećenje.
• Postavite nadzor performansi na poslužiteljima za praćenje testa kako biste identificirali uska grla tijekom faze izvođenja testa.
• Objavite rezultate ispitivanja izvedbe.
• Koordinirajte s raznim dionicima kako biste riješili identificirane probleme izvedbe.
• Osnovna razina izvedbe za buduća izdanja.

Izvan dosega

• Ispitivanje funkcionalnosti , UAT, Testiranje sustava i Testiranje sigurnosti.
• Ispitivanje performansi / nadzor bilo kojeg sučelja treće strane.
• Ugađanje performansi. (Uglavnom podešavanje vrši drugi tim, ako u slučaju da imate inženjere performansi za podešavanje sustava, to možete dodati u Inscope).
• Profiliranje koda / Veličina hardvera / Planiranje kapaciteta.
• Sigurnost / Ispitivanje ranjivosti / UAT / Ispitivanje bijele kutije .
• Izrada podataka za ispitivanje performansi.
• Nefunkcionalni testovi ( Na primjer, preusmjeravanje, oporavak od katastrofe, izrada sigurnosnih kopija, upotrebljivost) osim testova performansi.
• Testiranje bilo kojeg mobilnog rješenja.
• Testiranje i podešavanje izvedbe aplikacija treće strane.
• Ostvarivanje preporuka za izvedbu, promjena aplikacijskog koda i promjena konfiguracije proizvoda / poslužitelja koje podržava dobavljač bit će izvan opsega iz perspektive tima za izvedbu.
• Infrastrukturna podrška / Implementacija gradnje / Spremnost okoline / Vraćanje baze podataka / Mrežna podrška itd.

# 3) Pristup

Testiranje izvedbe za ABC chat provest će se pomoću Jmetra pisanjem prilagođenih XMPP dodataka koji koriste smack knjižnicu za XMPP veze. Te se knjižnice koriste za postavljanje veza, prijavu i slanje chat poruka na XMPP poslužitelj.

Te se knjižnice spajaju u jar datoteku koja je raspoređena u Jmeter i dizajnirana je na temelju scenarija koji će se testirati. Jmeter Work Bench instaliran je na lokalnom stroju koji se spaja na JMeter poslužitelj koji ima generatore učitavanja za generiranje potrebnog opterećenja na sustavu chat poslužitelja za praćenje ponašanja sustava.

Scenarij testa bit će napisan pomoću alata JMeter. Skripte bi se prilagodile prema potrebi. Raspored će se stvoriti s potrebnim ubrzanjem kako bi se simulirali scenariji iz stvarnog svijeta.

Testni scenarij bio bi podijeljen i mjeren u sljedećim aspektima:

a) Osnovni test: Da biste pokrenuli svaki scenarij s 1 vuserom i višestrukim iteracijama kako bi se utvrdilo ispunjava li izvedba aplikacije ugovor o poslovnoj razini usluge ili ne.

b) Ispitivanje osnovnog opterećenja: Kako bi udovoljio Business Benchmarku pod testom opterećenja, tim za ispitivanje performansi izvest će test osnovnog opterećenja koji će pomoći identificirati probleme s performansama sustava s povećanim opterećenjem i stvoriti osnovnu liniju za sljedeću razinu ispitivanja performansi.

c) Vršno opterećenje / test skalabilnosti: Tim za testiranje performansi izvest će više testova sa sve većim brojem korisnika kako bi se zadovoljilo očekivano opterećenje, a također će se izmjeriti performanse aplikacije kako bi se uspostavila krivulja izvedbe i utvrdilo može li implementacija podržati ugovore o razini usluge pod vršnim opterećenjem korisnika.

Pomaže u podešavanju ili planiranju kapaciteta pojedinačnih Java virtualnih strojeva (JVM), ukupnog broja potrebnih JVM-ova i procesora. To će se postići povećanjem broja Vusera na 50%, 75%, 100% i 125% vršnog kapaciteta.

d) Test izdržljivosti: Tim za testiranje performansi izvodit će ovaj test tijekom 8 sati / 16 sati / 24 sata kako bi identificirao curenje memorije, probleme s performansama tijekom vremena i ukupnu stabilnost sustava. Tijekom testova izdržljivosti, tim za testiranje performansi nadgleda ključne pokazatelje izvedbe, poput vremena odziva transakcije i stabilnosti upotrebe memorije.

Resurse sustava poput CPU-a, memorije i IO-a potrebno je nadzirati uz pomoć projektnog tima.

Pretpostavlja se da je okruženje za testiranje izvedbe replika proizvodnog okruženja. Testovi će se izvoditi s dodatnim opterećenjem kako bi se utvrdilo gdje aplikacija zakazuje.

Scenariji ispitivanja izvedbe

Uključite excel u skup scenarija.

Na primjer,

Scenarij 1: Da bi potvrdili chat agenta i kupca za X br. istodobnih sesija.

Vrste ispitivanja performansi

Tablica navedena u nastavku objašnjava različite vrste testova izvedbe zajedno s njihovim ciljevima.

Metrika izvedbe

• Metrika na strani klijenta

• Metrika performansi sustava i mreže

Aktivnosti i rezultati ispitivanja izvedbe

# 4) Podaci o ispitivanju

Pretpostavlja se da će podaci o izvedbenom okruženju biti kopija proizvodnih podataka, a potrebne podatke o ispitivanju pružit će projektni tim.

# 5) Kriteriji za ulazak i izlazak

• Pristup svim aplikacijama u okruženju.
• Spremnost okoline završena.
• Spremnost podataka o ispitivanju performansi.

# 6) Upravljanje nedostacima

• Modul za upravljanje nedostacima u JIRA-i koristit će se u projektu za bilježenje kvara i za praćenje do zatvaranja.
• Identifikacija nedostataka koji se pronađu tijekom faze izvođenja testa zabilježit će se u JIRA-i, a razvojni će tim te nedostatke riješiti prema težini dolje.
• Sastanci za pregled nedostataka održavali bi se svakodnevno uz sudjelovanje testa za ispitivanje, razvoj, analitičara kvalitete i poslovnih timova.
• Kriteriji za otklanjanje nedostataka postajali bi stroži kako se projekt približava datumu Go Live. Smjernice za kriterije otklanjanja nedostataka koje će se objaviti na sastancima za pregled nedostataka.

Definicija ozbiljnosti nedostataka

Definicije kodova ozbiljnosti su kako slijedi:

# 7) Alati i tehnike ispitivanja

# 8) Kriteriji suspenzije i ponovnog pokretanja

Dolje su navedeni kritični kriteriji suspenzije i ponovnog pokretanja koji će utjecati na aktivnosti ispitivanja:

# 9) Ispitni rezultati

Isporučeni rezultati ispitivanja uključuju:

besplatni softver za sigurnosnu kopiju za Windows 8.1

• Strategija ispitivanja izvedbe
• Dokument o zahtjevima za izvedbu
• Dokument o scenariju ispitivanja izvedbe
• Skripte za provjeru izvedbe
• Rezultati ispitivanja izvedbe

# 10) Uloge i odgovornosti

Uloge i odgovornosti jasno su objašnjene u donjoj tablici.

# 11) Potencijalni rizici i plan ublažavanja

# 12) Pretpostavke

• Okolina za testiranje izvedbe bit će preslika arhitekture proizvoda. (tj. ispravan hardver, softver, sučelja, integracijski slojevi itd.).
• Skripte za izvedbu bit će dizajnirane na temelju kritičnih tokova za koje je upotreba velika.
• Sva pitanja u vezi s infrastrukturom trebala bi se riješiti prije početka ispitivanja performansi. Sve kasnije izvršene promjene konfiguracije poništit će rezultate testa.
• Aplikacija je stabilna i spremna za upotrebu u testnom okruženju izvedbe.
• Na raspolaganju su vam potrebni hardverski i softverski resursi (poput strojeva / softvera za generiranje opterećenja, strojeva za upravljanje / agent).
• Sve promjene opsega proći će kroz postupak kontrole promjena, a tim za ispitivanje učinka procijenit će utjecaj vremenskih rokova i resursa.
• Očekuje se da će odgovarajući poslužitelji podnijeti opterećenje.
• Dnevnici praćenja aplikacija moraju biti omogućeni za prateće sustave u svrhu praćenja.

# 13) Ovisnosti

• Dostupnost testnog okruženja izvedbe koje je preslika arhitekture proizvoda.
• Podrška potrebna od različitih timova za funkcionalne, razvojne, baze podataka i infrastrukturu tijekom faza pripreme i izvršenja testa.
• Tijekom cijele faze testiranja performansi ne primjenjuju se promjene koda, jer je vrijeme vrlo ograničeno.
• U slučaju nepredviđenih problema koji dovode do ograničenja unutar vremenskih rokova, ako vremenski rokovi ne dopuštaju da se svi opsezi ispitivanja ispune u okviru originalnih datuma prekretnice, od Upravitelja izdanja dostupna je podrška za pružanje odluke o opsegu i određivanju prioriteta.
• Poslovni korisnici aplikacija / stručnjaci za predmet bit će dostupni za funkcionalna pojašnjenja i odjavu poslovnih transakcija.
• Upravitelj programa ABC chat pregledat će i odjaviti se.

# 14) Kratice

Do sada ste već morali jasno razumjeti kako napisati učinkovitu strategiju ispitivanja performansi za aplikaciju za razmjenu poruka.

Najbolji primjeri za realistično testiranje izvedbe

Da bismo uspješno završili projekt provjere performansi, moramo osigurati da to radimo na pravi način iz faze planiranja, tj. Planiranja, razvoja, izvršenja i analize.

Pogledajmo detaljno svaku fazu kako bismo učinkovito proveli testiranje izvedbe.

# 1) Planiranje

• Pokušajte identificirati najčešće tijekove rada, tj. Poslovne scenarije koji se moraju testirati. Ako je aplikacija već postojeća, provjerite zapisnike poslužitelja da biste razumjeli najčešće korištene scenarije. Ako je aplikacija nova, razgovarajte s timom za upravljanje projektom kako biste razumjeli glavni tijek poslovanja.
• Planirajte test opterećenja na takav način da pokrivate širok raspon radnih tokova, poput lagane potrošnje, srednje upotrebe i vršnih opterećenja.
• Morate izvesti mnoge cikluse testa učitavanja, pa pokušajte stvoriti okvir tako da možete uvijek iznova koristiti iste skripte. Također, pokušajte imati sigurnosnu kopiju skripti.
• Pokušajte analizirati koliko dugo test mora trajati, je li to jedan sat? 8 sati? Dan ili tjedan? Obično će dugotrajni testovi otkriti mnoge glavne nedostatke poput OS grešaka, curenja memorije itd.
• Ako vaša organizacija koristi bilo koji APM (Alat za nadzor aplikacija), tada ga možete uključiti tijekom probnih pokretanja kako biste lakše prepoznali probleme s izvedbom i lakše identificirali osnovni uzrok.

# 2) Razvoj

• Tijekom razvijanja skripti, tj. Snimanja, pokušajte dati smislenije ime transakcije na temelju imena poslovnih tokova koja su spomenuta u planu.
• Nemojte snimati nijednu aplikaciju treće strane, a ako se zabilježi, pokušajte je filtrirati dok poboljšavate skripte.
• Ne mogu se sve dinamičke vrijednosti povezati pomoću značajke automatske korelacije u alatu, pa pokušajte napraviti ručnu korelaciju kako biste izbjegli pogreške.
• Pokušajte dizajnirati testove izvedbe na takav način da pogađate pozadinu aplikacije, a ne samo poslužitelj predmemorije.

# 3) Izvršenje

• Obavezno pokrenite testove u proizvodnom okruženju, uključujući čimbenike poput SSL-a, Load Balancera i Firewall-a. To je neophodno kako bi se simuliralo realno opterećenje sustava.
• Pokušajte stvoriti radno opterećenje koje je vrlo realno, to možete dobiti provjerom dnevnika poslužitelja ako je riječ o postojećem programu, a ako je novi program te podatke trebate dobiti od poslovnog tima. Imajte na umu da je radno opterećenje vrlo važno za provođenje uspješnih testova izvedbe.
• Nikada ne dođite do zaključka provođenjem testova s ​​okolinom veličine polovine proizvodnje, uvijek se savjetuje provođenje testova u okruženju koje je jednako kao i proizvodnja.
• Tijekom izvođenja dugotrajnih testova pokušajte gledati trčanje u čestim intervalima kako biste bili sigurni da test radi glatko.

# 4) Analiza

• Pokušajte analizirati aplikaciju tako da prvo dodate nekoliko važnih brojača, kada se pronađe usko grlo, a zatim pokušajte dodati dodatne brojače s obzirom na usko grlo. To će, pak, pomoći da se problem lakše pronađe.
• Aplikacija može propasti iz mnogih razloga, poput toga što ne može odgovoriti na zahtjev, odgovoriti kodom pogreške, zatajiti logiku provjere valjanosti ili presporo reagirati. Zato pokušajte sve to ispitati prije nego što donesete zaključak.

Zaključak

Siguran sam da bi vam ovaj vodič dao neizmjerno znanje o testovima izvedbe i kako napisati dokument o strategiji ispitivanja izvedbe s detaljnim primjerima.

U našem nadolazećem vodiču detaljno ćemo naučiti razlike između ispitivanja performansi, opterećenja i naprezanja.

Također, provjeri => Besplatna serija dubinskih treninga LoadRunner

SLJEDEĆA Vodič

Preporučena literatura

• Ispitivanje performansi vs ispitivanje opterećenja vs testiranje naprezanja (razlika)
• Ispitivanje opterećenja pomoću HP LoadRunner vodiča
• Testiranje performansi u oblaku: davatelji usluga za testiranje opterećenja u oblaku
• Ispitivanje opterećenja, stresa i performansi web aplikacija pomoću WAPT-a
• Alati i usluge za testiranje izvedbe web stranica
• Kako izvršiti ručno ispitivanje performansi?
• Testiranje performansi mobilnih aplikacija pomoću BlazeMetera
• Testiranje izvedbe web usluga pomoću LoadRunner VuGen skriptiranja