Parametriranje, funkcije, transakcije v LoadRunnerju

Kazalo:

Anonim

Posneti skript lahko simulira navideznega uporabnika; vendar zgolj posnetek morda ne bo dovolj za ponovitev "resničnega vedenja uporabnika".

Ko je scenarij posnet, zajema posamezen in neposreden tok predmetne aplikacije. Pravi uporabnik lahko izvede več ponovitev katerega koli postopka, preden se odjavi. Zamuda med klikanjem gumbov (čas razmišljanja) se razlikuje od osebe do osebe. Obstaja velika verjetnost, da nekateri resnični uporabniki dostopajo do vaše aplikacije prek DSL, nekateri pa prek klicne povezave. Da bi resnično občutili končnega uporabnika, moramo izboljšati skripte tako, da se natančno ujemajo ali vsaj zelo obnašajo resnične uporabnike.

Zgoraj omenjeno je najpomembnejše, kar je treba upoštevati pri izvajanju »preizkušanja učinkovitosti«, vendar VU skript vsebuje več. Kako boste natančno ocenili, koliko časa je uporabnik uporabil, ko je SUL na preizkusu učinkovitosti? Kako bi vedeli, ali je uporabnik VUser v določenem trenutku šel skozi ali je odpovedal? Kaj je vzrok za okvaro, ali je kakšen zaledni postopek odpovedal ali so bili strežniški viri omejeni?

Izboljšati moramo svoj skript, da bomo lažje odgovorili na vsa zgornja vprašanja.

  • Uporaba transakcij
  • Razumevanje časa razmišljanja, točk srečanja in komentarjev
  • Vstavljanje funkcij skozi meni
  • Kaj je parametrizacija?
  • Nastavitve časa izvajanja in njihov vpliv na simulacijo VU
    • Zaženi logiko
    • Hodanje
    • Dnevnik
  • Think Times
  • Simulacija hitrosti
  • Emulacija brskalnika
  • Zastopnik

Uporaba transakcij

Transakcije so mehanika za merjenje odzivnega časa strežnika za katero koli operacijo. Z enostavnimi besedami uporaba "Transakcije" pomaga izmeriti čas, ki ga sistem potrebuje za določeno zahtevo. Lahko je majhen kot klik gumba ali klic AJAX ob izgubi fokusa iz besedilnega polja.

Uporaba transakcij je enostavna. Preprosto napišite eno vrstico kode, preden je zahteva poslana strežniku, in zaprite transakcijo, ko se zahteva konča. LoadRunner zahteva samo niz kot ime transakcije.

Če želite odpreti transakcijo, uporabite to vrstico kode:

lr_start_transaction (“Ime transakcije”);

Če želite zapreti transakcijo, uporabite to vrstico kode:

lr_end_transaction (“Ime transakcije”, );

sporoča LoadRunnerju, ali je bila ta transakcija uspešna ali neuspešna. Možni parametri so lahko:

  • LR_AUTO
  • LR_PASS
  • LR_FAIL

Primer:

lr_end_transaction (“My_Login”, LR_AUTO);

lr_end_transaction (“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);

Opombe:

  • Ne pozabite, delate s “C” in to je jezik, ki razlikuje med velikimi in malimi črkami.
  • Znak za obdobje (.) V imenu transakcije ni dovoljen, čeprav lahko uporabite presledke in podčrtaje.
  • Če ste dobro razvejali kodo in dodali kontrolne točke za preverjanje odziva strežnika, lahko uporabite obdelavo napak po meri, na primer LR_PASS ali LR_FAIL. V nasprotnem primeru lahko uporabite LR_AUTO in LoadRunner bo samodejno obdelal napake strežnika (HTTP 500, 400 itd.)
  • Pri uveljavljanju transakcij se prepričajte, da ni vstavljen izpis think_time, sicer bo vaša transakcija vedno vključevala to obdobje.
  • Ker LoadRunner kot ime transakcije zahteva stalen niz, je pogosta težava pri uporabi transakcije neusklajenost niza. Če pri odpiranju in zapiranju transakcije navedete drugo ime, boste imeli vsaj 2 napaki. Ker transakcija, ki ste jo odprli, ni bila nikoli zaprta, bo LoadRunner povzročil napako. Poleg tega transakcija, ki jo želite zapreti, ni bila nikoli odprta, zato je prišlo do napake.
  • Ali lahko uporabite svojo inteligenco in si odgovorite, katera od zgornjih napak bo prva prijavljena? Za potrditev svojega odgovora, zakaj ne bi naredili lastne napake? Če ste pravilno odgovorili, ste na pravi poti. Če ste odgovorili napačno, se morate osredotočiti.
  • Ker LoadRunner samodejno skrbi za sinhronizacijo zahtev in odziva, vam pri uporabi transakcij ne bo treba skrbeti za odziv.

Razumevanje časa razmišljanja, točk srečanja in komentarjev

Točke srečanja

Točke srečanja pomenijo "točke srečanja". To je samo ena vrstica izjave, ki LoadRunnerju pove, naj uvede sočasnost. Točke srečanja vstavite v skripte VUser, da posnemate veliko obremenitev uporabnika na strežniku.

Točke srečevanja naročijo VUserju, naj med izvajanjem preizkusa počaka, da več VUser prispe na določeno točko, da lahko hkrati opravi nalogo. Če želite na primer posnemati največjo obremenitev na bančnem strežniku, lahko vstavite točko srečanja z navodili 100 VUserju, naj hkrati položi gotovino na svoje račune. To je mogoče enostavno doseči z randevujem.

Če mesta srečanja niso pravilno postavljena, bo uporabnik dostopal do različnih delov aplikacije - tudi za isti skript. To je zato, ker dobi vsak uporabnik različen odzivni čas in zato malo uporabnikov zaostaja.

Sintaksa: lr_rendesvous (»Logično ime«);

Najboljše prakse:

  • Za boljšo berljivost kode predpono točke odpojdi dodajte z “rdv_”; npr. “rdv_Login”
  • Odstranite vse takojšnje izjave o času razmišljanja
  • Uporaba točk srečanja v pogledu skripta (po snemanju)

Komentarji

Dodajte komentarje, da opišete dejavnost, del kode ali vrstico kode. Komentarji pomagajo, da je koda v prihodnje razumljiva vsem, ki se sklicujejo nanjo. Priskrbijo informacije o določenem delovanju in ločijo dva razdelka za razlikovanje.

Dodate lahko komentarje

  • Med snemanjem (z orodjem)
  • Po snemanju (neposredno pisanje v kodi)

Najboljša praksa: Označite kakršne koli komentarje na vrhu vsake datoteke skripta

Vstavljanje funkcij skozi meni

Čeprav lahko neposredno pišete preproste vrstice kode, boste morda potrebovali namig za priklic funkcije. Za iskanje in vstavljanje katere koli funkcije neposredno v skript lahko uporabite tudi orodje Steps Toolbox (znano kot Vstavi funkcijo pred različico 12).

Orodno vrstico Steps najdete pod View àSteps Toolbox.

To bo odprlo stransko okno, poglejte posnetek:

Kaj je parametrizacija?

Parameter v VUGen je vsebnik, ki vsebuje posneto vrednost, ki je zamenjan za različne uporabnike.

Med izvajanjem skripta (v VUGenu ali Controllerju) vrednost iz zunanjega vira (na primer .txt, XML ali baze podatkov) nadomesti prejšnjo vrednost parametra.

Parametriranje je koristno pri pošiljanju dinamičnih (ali enoličnih) vrednosti strežniku, na primer; v poslovnem procesu je zaželen 10 ponovitev, vendar vsakič izberejo enolično uporabniško ime.

Pomaga tudi pri spodbujanju resničnega vedenja do predmetnega sistema. Oglejte si spodnji primer:

Primeri težav:

Poslovni proces deluje samo za trenutni datum, ki prihaja s strežnika, zato ga ni mogoče posredovati kot trdno kodirano zahtevo.

Včasih odjemalska aplikacija strežniku posreduje enolični ID (na primer session_id), da se postopek nadaljuje (tudi za enega uporabnika) - v takem primeru pomaga parametrizacija.

Odjemalska aplikacija pogosto vzdržuje predpomnilnik podatkov, ki se pošiljajo na strežnik in iz njega. Posledično strežnik ne prejema dejanskega vedenja uporabnika (v primeru, da strežnik izvaja drugačen algoritem, odvisno od iskalnih kriterijev). Medtem ko se bo skript VUser uspešno izvedel, narisana statistika uspešnosti ne bo pomembna. Uporaba različnih podatkov s parametrizacijo pomaga pri posnemanju dejavnosti na strani strežnika (postopki itd.) In izvaja sistem.

Datum, ki je med snemanjem trdo kodiran v VUserju, po preteku tega datuma morda ne bo več veljaven. Parametriranje datuma omogoča izvedbo VUserja z zamenjavo trdno kodiranega datuma. Takšna polja ali zahteve so pravi kandidati za parametrizacijo.

Kliknite tukaj, če video ni dostopen

Nastavitve časa izvajanja in njihov vpliv na simulacijo VU

Nastavitve časa izvajanja so enako pomembne kot vaš VUGen Script. Z različnimi konfiguracijami lahko dobite različne preskusne zasnove. Zato lahko dobite neponovljive rezultate, če nastavitve časa izvajanja niso dosledne. Pogovorimo se o vsakem atributu enega za drugim.

Zaženi logiko

Run Logic določa, kolikokrat bodo izvedena vsa dejanja, razen vuser_init in vuser_end.

Verjetno je to bolj jasno, zakaj LoadRunner predlaga, da ostane vsa prijavna koda znotraj vuser_init, odjavni del pa izključno vuser_end.

Če ste ustvarili več dejanj, recimo, vpišite se, odprite zaslon, izračunajte najem, oddajte sredstva, preverite stanje in se odjavite, potem bo za vsakega uporabnika potekal spodnji scenarij:

Vsi uporabniki se bodo prijavili, izvedli odprti zaslon, izračunali najemnino, oddali sredstva, preverili stanje - nato - spet odprti zaslon, izračunali najemnine ... in tako naprej - 10-krat ponovitev - čemur sledi odjava (enkrat).

To je zmogljiva nastavitev, ki omogoča boljše delovanje resničnega uporabnika. Ne pozabite, da se pravi uporabnik ne prijavi in ​​odjavi vsakič - običajno ponovi iste korake.

Kolikokrat pri preverjanju e-pošte pred odjavo kliknete »Prejeto«?

Hodanje

To je pomembno. Ljudje večinoma ne morejo razumeti razlike med tempom in časom razmišljanja. Edina razlika je v tem, da se »hitrost gibanja nanaša na zakasnitev med ponovitvami«, medtem ko je čas razmišljanja zamuda med katerima koli 2 korakoma.

Priporočena nastavitev je odvisna od zasnove testa. Če pa želite agresivno obremenitev, razmislite o izbiri "Takoj, ko se prejšnja ponovitev konča"

Dnevnik

Dnevnik (kot je splošno razumljeno) je vodenje vseh dogodkov med zagonom LoadRunner. V dnevniku lahko omogočite, da veste, kaj se dogaja med vašo aplikacijo in strežnikom.

LoadRunner ponuja zmogljiv mehanizem beleženja, ki je robusten in prilagodljiv sam po sebi. Omogoča vam, da shranite samo »Standardni dnevnik« ali podroben, nastavljiv razširjeni dnevnik ali ga popolnoma onemogočite.

Standardni dnevnik je informativen in lahko razumljiv. Vsebuje ravno pravo količino znanja, ki vam bo običajno treba za odpravljanje težav s skripti VUser.

V primeru razširjenega dnevnika so vse standardne informacije dnevnika podnabor. Poleg tega lahko nadomestite parameter. To pove komponenti LoadRunner, da vključuje popolne informacije o vseh parametrih (od parametrizacije), vključno z zahtevami, pa tudi podatke o odzivih.

Če vključite »Podatke, ki jih vrne strežnik«, bo vaš dnevnik dolg. To bo vključevalo vse HTML-je, oznake, vire in informacije o ne-virih, vključene neposredno v dnevnik. Možnost je dobra le, če potrebujete resno odpravljanje težav. Običajno je zaradi tega datoteka dnevnika zelo velika in ga ni lahko razumeti.

Kot ste že lahko slutili, če se odločite za »Advance Trace«, bo vaša dnevniška datoteka ogromna. Morate poskusiti. Opazili boste, da se je tudi čas, ki ga je vzel VUGen, znatno povečal, čeprav to ne bo vplivalo na odzivni čas transakcije, o katerem poroča VUGen. Vendar so to zelo vnaprejšnje informacije in morda koristne, če razumete zadevno aplikacijo, komunikacijo med odjemalcem in strežnikom med vašo aplikacijo in strojno opremo ter podrobnosti na ravni protokola. Običajno so te informacije v bistvu mrtve, saj zahtevajo izjemna prizadevanja za razumevanje in odpravljanje težav.

Nasveti:

  • Ne glede na to, koliko časa traja VUGen, ko je dnevnik omogočen, to ne vpliva na odzivni čas transakcije. HP ta pojav imenuje "najsodobnejša tehnologija".
  • Onemogoči dnevnik, če ni potreben.
  • Ko končate s svojimi skripti, onemogočite dnevnik. Če vključite skripte z omogočenim beleženjem, bo krmilnik deloval počasneje in poročal o motečih sporočilih.
  • Če onemogočite dnevnik, se bo povečala zmogljivost največjega števila uporabnikov, ki jih lahko simulirate iz LoadRunnerja.
  • Razmislite o uporabi možnosti »Pošlji sporočilo samo, če pride do napake« - to bo izključilo nepotrebna informativna sporočila in sporočilo samo sporočila, povezana z napakami.

Think Times

Think Time je preprosto zakasnitev med dvema korakoma.

Think Time pomaga ponoviti vedenje uporabnikov, saj noben dejanski uporabnik ne more uporabljati nobene aplikacije, kot je stroj (VUGen). VUGen samodejno ustvari čas za razmišljanje. Še vedno imate popoln nadzor nad odstranjevanjem, množenjem ali nihanjem trajanja časa razmišljanja.

Če želite razumeti več, lahko uporabnik na primer odpre zaslon (to je odgovor, ki mu sledi zahteva) in nato pred pritiskom na tipko Enter navede uporabniško ime in geslo. Naslednja interakcija aplikacije s strežnikom se bo zgodila, ko bo kliknil »Prijava«. Čas, ki si ga je uporabnik vpisal, je Think Time v LoadRunnerju.

Če želite simulirati agresivno obremenitev aplikacije, razmislite o popolnem onemogočanju časa razmišljanja.

Vendar pa lahko za simulacijo resničnega podobnega vedenja »Uporabniški naključni čas razmišljanja« nastavite odstotke po želji.

Razmislite o uporabi omejitve časa razmišljanja na legitimno obdobje. Običajno je 30 sekund dovolj dobro.

Simulacija hitrosti

Simulacija hitrosti se preprosto nanaša na pasovno širino za vsak odjemalski stroj.

Ker skozi LoadRunner simuliramo na tisoče uporabnikov, je neverjetno, kako preprosto je LoadRunner naredil nadzor nad simulacijo pasovne širine / hitrosti omrežja.

Če ste stranka, ki svojo aplikacijo dostopa preko 128 Kbps, jo lahko nadzirate od tukaj. Simulirali boste "resnično podobno vedenje", kar bi moralo pomagati pri pridobivanju pravih statistik uspešnosti.

Najboljše priporočilo je, da nastavite na Uporabi največjo pasovno širino. To bo pomagalo prezreti vsa ozka grla v zvezi z zmogljivostjo in se najprej osredotočiti na morebitne težave v aplikaciji. Test lahko vedno izvedete večkrat, da vidite različno vedenje v različnih okoliščinah.

Emulacija brskalnika

Uporabniška izkušnja ni odvisna od brskalnika, ki ga uporablja končni uporabnik. Jasno je, da to presega obseg meril uspešnosti. Lahko pa izberete, kateri brskalnik želite posnemati.

Ali si lahko sami odgovorite, kdaj natančno bo za vas pomembno, da izberete pravi brskalnik v tej konfiguraciji?

To konfiguracijo boste uporabili, če ste predmet prijave spletna aplikacija, ki za različne brskalnike vrne različne odgovore. Ogledate si lahko na primer različne slike in vsebine za IE in Firefox itd.

Druga pomembna nastavitev je Simuliranje predpomnilnika brskalnika. Če želite izmeriti odzivni čas, ko je predpomnilnik omogočen, potrdite to polje. Če iščete najslabše možne primere, to očitno ni premislek.

Prenos virov, ki niso HTML, bo LoadRunnerju omogočil prenos vseh CSS, JS in drugih obogatenih predstavnosti. To je treba še naprej preverjati. Če pa želite to odstraniti iz zasnove preizkusa učinkovitosti, lahko to počistite.

Zastopnik

Najbolje je, da proxy popolnoma odstranite iz testnega okolja - tako bodo rezultati testa nezanesljivi. Vendar se lahko soočite s situacijami, ko je to neizogibno. V takem primeru vam LoadRunner olajša nastavitve proxyja.

Delali boste (ali bi morali delati) brez nastavitve proxy. Lahko ga dobite v privzetem brskalniku. Vendar ne pozabite preveriti, kateri brskalnik je nastavljen na privzeti in kakšna je konfiguracija proxy za privzeti brskalnik.

Če uporabljate strežnik proxy in potrebuje preverjanje pristnosti (ali skript), lahko kliknete gumb Preverjanje pristnosti, ki vodi v novo okno. Glejte spodnji posnetek zaslona.

Na tem zaslonu navedite uporabniško ime in geslo za preverjanje pristnosti na strežniku proxy. Kliknite V redu, da zaprete zaslon.

Vse čestitke. Končali ste s konfiguracijo skripte VUGen. Ne pozabite ga konfigurirati za vse skripte VUser.