Un script înregistrat poate simula un utilizator virtual; cu toate acestea, o simplă înregistrare poate să nu fie suficientă pentru a reproduce „comportamentul real al utilizatorului”.
Când un script este înregistrat, acesta acoperă fluxul unic și direct al aplicației subiect. Întrucât, un utilizator real poate efectua mai multe iterații ale oricărui proces înainte de a se deconecta. Întârzierea între apăsarea butoanelor (timpul de gândire) va varia de la o persoană la alta. Sunt șanse ca unii utilizatori reali să acceseze aplicația dvs. prin DSL, iar unii să o acceseze printr-un dial-up. Deci, pentru a obține senzația reală de utilizator final, trebuie să ne îmbunătățim scripturile pentru a se potrivi exact sau, cel puțin, pentru a avea un comportament foarte apropiat de utilizatorii reali.
Cele de mai sus reprezintă considerentul cel mai semnificativ atunci când se efectuează „Testarea performanței”, dar există mai mult într-un script VU. Cum veți măsura cantitatea exactă de timp luată de un utilizator atunci când SUL este supus unui test de performanță? Cum ați ști dacă utilizatorul VU a trecut sau a eșuat la un moment dat? Care este cauza din spatele eșecului, dacă un proces backend a eșuat sau resursele serverului au fost limitate?
Trebuie să ne îmbunătățim scriptul pentru a răspunde la toate întrebările de mai sus.
- Utilizarea tranzacțiilor
- Înțelegerea timpului de gândire, a punctelor de întâlnire și a comentariilor
- Inserarea funcțiilor prin meniu
- Ce este Parametrizarea?
- Setările timpului de rulare și impactul acestora asupra simulării VU
- Rulați Logic
- Ritm
- Buturuga
- Think Times
- Simulare viteză
- Emulare browser
- Proxy
Utilizarea tranzacțiilor
Tranzacțiile sunt mecanici care măsoară timpul de răspuns al serverului pentru orice operațiune. În cuvinte simple, utilizarea „Tranzacției” ajută la măsurarea timpului luat de sistem pentru o anumită solicitare. Poate fi la fel de mic ca un clic de buton sau un apel AJAX după pierderea focalizării din caseta de text.
Aplicarea tranzacțiilor este simplă. Trebuie doar să scrieți o linie de cod înainte ca cererea să fie făcută către server și să închideți tranzacția la sfârșitul cererii. LoadRunner necesită doar un șir ca nume de tranzacție.
Pentru a deschide o tranzacție, utilizați această linie de cod:
lr_start_transaction („Numele tranzacției”);
Pentru a închide tranzacția, utilizați această linie de cod:
lr_end_transaction („Nume tranzacție”,);
- LR_AUTO
- LR_PASS
- LR_FAIL
Exemplu:
lr_end_transaction („My_Login”, LR_AUTO);
lr_end_transaction („Business_Workflow_Transaction Name”, LR_FAIL);
Puncte de reținut:
- Nu uitați, lucrați cu „C” și acesta este un limbaj sensibil la majuscule.
- Caracterul perioadei (.) Nu este permis în numele tranzacției, deși puteți utiliza spații și subliniere.
- Dacă v-ați ramificat bine codul și ați adăugat puncte de control pentru a verifica răspunsul de la server, puteți utiliza gestionarea erorilor personalizate, cum ar fi, LR_PASS sau LR_FAIL. În caz contrar, puteți utiliza LR_AUTO și LoadRunner va gestiona automat erorile serverului (HTTP 500, 400 etc.)
- Atunci când aplicați tranzacții, asigurați-vă că nu există nicio declarație de tip think_time sau altfel tranzacția dvs. va include întotdeauna perioada respectivă.
- Deoarece LoadRunner necesită un șir constant ca nume de tranzacție, o problemă obișnuită la aplicarea tranzacției este nepotrivirea șirului. Dacă dați un nume diferit la deschiderea și închiderea unei tranzacții, veți avea cel puțin 2 erori. Deoarece tranzacția pe care ați deschis-o nu a fost niciodată închisă, LoadRunner va genera o eroare. În plus, tranzacția pe care încercați să o închideți nu a fost niciodată deschisă, rezultând astfel o eroare.
- Puteți să vă folosiți inteligența și să vă răspundeți singur care dintre erorile de mai sus va fi raportată mai întâi? Pentru a vă valida răspunsul, de ce să nu vă faceți propria greșeală? Dacă ai fi răspuns corect, ești pe drumul cel bun. Dacă ai răspuns greșit, trebuie să te concentrezi.
- Deoarece LoadRunner se ocupă automat de sincronizarea solicitărilor și a răspunsului, nu va trebui să vă faceți griji cu privire la răspuns atunci când aplicați tranzacții.
Înțelegerea timpului de gândire, a punctelor de întâlnire și a comentariilor
Puncte de întâlnire
Puncte de întâlnire înseamnă „puncte de întâlnire”. Este doar o linie de declarație care îi spune lui LoadRunner să introducă concurența. Inserați puncte de întâlnire în scripturile VUser pentru a emula încărcarea grea a utilizatorului pe server.
Punctele de întâlnire îi instruiesc pe VUser să aștepte în timpul execuției testului pentru ca mai multe VUser să ajungă la un anumit punct, astfel încât să poată efectua simultan o sarcină. De exemplu, pentru a imita sarcina maximă pe serverul băncii, puteți introduce un punct de întâlnire prin care să instruiți 100 VUser să depună numerar în conturile lor în același timp. Acest lucru poate fi realizat cu ușurință folosind întâlnirea.
Dacă punctele de întâlnire nu sunt locuri corect, VUser va accesa diferite părți ale aplicației - chiar și pentru același script. Acest lucru se datorează faptului că fiecare VUser obține un timp de răspuns diferit și, prin urmare, puțini utilizatori rămân în urmă.
Sintaxă: lr_rendesvous („Numele logic”);
Cele mai bune practici:
- Prefixați un punct de întâlnire cu „rdv_” pentru o mai bună lizibilitate a codului; de exemplu, „rdv_Login”
- Eliminați orice declarații imediate despre timpul de gândire
- Aplicarea punctelor de întâlnire într-o vizualizare script (după înregistrare)
Comentarii
Adăugați comentarii pentru a descrie o activitate, o bucată de cod sau o linie de cod. Comentariile ajută la înțelegerea codului pentru oricine se referă la acesta în viitor. Acestea oferă informații despre operațiuni specifice și separă două secțiuni pentru distincție.
Puteți adăuga comentarii
- În timpul înregistrării (folosind instrumentul)
- După înregistrare (scriere directă în cod)
Cele mai bune practici: marcați orice comentariu în partea de sus a fiecărui fișier script
Inserarea funcțiilor prin meniu
Deși puteți scrie direct linii simple de cod, este posibil să aveți nevoie de un indiciu pentru a reaminti o funcție. De asemenea, puteți utiliza Steps Toolbox (cunoscută sub numele de Insert Function înainte de versiunea 12) pentru a găsi și a insera orice funcție direct în scriptul dvs.
Puteți găsi Bara de instrumente Pași în Afișați caseta de instrumente Pași.
Se va deschide o fereastră laterală, se va uita la instantaneu:
Ce este Parametrizarea?
Un parametru în VUGen este un container care conține o valoare înregistrată care este înlocuită pentru diferiți utilizatori.
În timpul executării scriptului (în VUGen sau Controller), valoarea dintr-o sursă externă (cum ar fi .txt, XML sau baza de date) substituie valoarea anterioară a parametrului.
Parametrizarea este utilă în trimiterea valorilor dinamice (sau unice) către server, de exemplu; se dorește un proces de afaceri pentru a rula 10 iterații, dar alegând de fiecare dată un nume de utilizator unic.
De asemenea, ajută la stimularea comportamentului real al sistemului subiect. Aruncați o privire la exemplul de mai jos:
Exemple de probleme:
Procesul de afaceri funcționează numai pentru data curentă care vine de la server, prin urmare nu poate fi transmisă ca o cerere codificată.
Uneori, aplicația client trece un ID unic serverului (de exemplu, session_id) pentru ca procesul să continue (chiar și pentru un singur utilizator) - Într-un astfel de caz, parametrizarea ajută.
Adesea, aplicația client păstrează o memorie cache de date trimise către și de la server. Ca urmare, serverul nu primește un comportament real al utilizatorului (în cazul în care serverul rulează algoritm diferit în funcție de criteriile de căutare). În timp ce scriptul VUser se va executa cu succes, statisticile de performanță trase nu vor fi semnificative. Utilizarea datelor diferite prin parametrizare ajută la emularea activității serverului (proceduri etc.) și la exercitarea sistemului.
Este posibil ca o dată care este codificată în VUser în timpul înregistrării să nu mai fie valabilă după trecerea acelei date. Parametrizarea datei permite ca executarea VUser să aibă succes prin înlocuirea datei hard-codate. Astfel de câmpuri sau cereri sunt candidații potriviți pentru parametrizare.
Faceți clic aici dacă videoclipul nu este accesibil
Setările timpului de rulare și impactul acestora asupra simulării VU
Setările pentru timpul de rulare sunt la fel de semnificative ca și scriptul VUGen. Cu configurații diferite, puteți obține diferite modele de testare. Acesta este motivul pentru care puteți ajunge la rezultate care nu pot fi repetate dacă setările pentru timpul de rulare nu sunt coerente. Să discutăm fiecare atribut unul câte unul.
Rulați Logic
Run Logic definește de câte ori vor fi executate toate acțiunile, cu excepția vuser_init și vuser_end.
Probabil acest lucru face mai clar de ce LoadRunner sugerează păstrarea întregului cod de autentificare în vuser_init și a părții Deconectare în vuser_end, ambele exclusiv.
Dacă ați creat mai multe acțiuni, să spunem, conectați-vă, deschideți ecranul, calculați închirierea, trimiteți fonduri, verificați soldul și deconectați-vă, apoi, scenariul de mai jos va avea loc pentru fiecare utilizator utilizator:
Toți utilizatorii VU se vor autentifica, vor executa ecran deschis, vor calcula închirierea, vor trimite fonduri, vor verifica soldul - apoi - vor deschide din nou ecranul, vor calcula închirierile ... și așa mai departe - iterând de 10 ori - urmat de deconectare (o dată).
Aceasta este o setare puternică care permite să acționeze mai mult ca un utilizator real. Amintiți-vă, un utilizator real nu se conectează și se deconectează de fiecare dată - el, de obicei, repetă aceiași pași.
De câte ori faceți clic pe „Mesaje primite” când vă verificați e-mailul înainte de a vă deconecta?
Ritm
Asta e important. În general, oamenii nu sunt în măsură să înțeleagă diferența dintre ritm și timp de gândire. Singura diferență este că „stimularea se referă la întârzierea dintre iterații”, în timp ce timpul de gândire este întârzierea dintre oricare 2 pași.
Setarea recomandată depinde de proiectarea testului. Cu toate acestea, dacă doriți să aveți o încărcare agresivă, vă recomandăm să alegeți „De îndată ce iterația anterioară se încheie”
Buturuga
Un jurnal (așa cum se înțelege în general) este o contabilitate a tuturor evenimentelor în timp ce rulați LoadRunner. Puteți activa jurnalul pentru a afla ce se întâmplă între aplicația dvs. și serverul dvs.
LoadRunner oferă un mecanism puternic de înregistrare, care este robust și scalabil de la sine. Vă permite să păstrați doar „Jurnal standard” sau un jurnal extins detaliat și configurabil sau să îl dezactivați complet.
Un jurnal standard este informativ și ușor de înțeles. Acesta conține doar cantitatea potrivită de cunoștințe pe care, în general, le veți avea nevoie pentru a depana scripturile VUser.
În cazul jurnalului extins, toate informațiile jurnalului standard sunt un subset. În plus, puteți avea înlocuirea parametrilor. Aceasta îi spune componentei LoadRunner să includă informații complete despre toți parametrii (de la parametrizare), inclusiv cereri, precum și date de răspuns.
Dacă includeți „Date returnate de server”, atunci jurnalul dvs. va continua. Aceasta va include toate informațiile HTML, etichete, resurse, informații despre resurse incluse chiar în jurnal. Opțiunea este bună numai dacă aveți nevoie de depanare serioasă. De obicei, acest lucru face ca fișierul jurnal să fie foarte mare ca dimensiune și să nu fie ușor de înțeles.
După cum ați fi putut ghici până acum, dacă optați pentru „Advance Trace”, fișierul jurnal va fi masiv. Trebuie să încercați. Veți observa că și timpul de VUGen a crescut semnificativ, deși acest lucru nu va avea niciun impact asupra timpului de răspuns la tranzacție raportat de VUGen. Cu toate acestea, acestea sunt informații foarte avansate și poate utile dacă înțelegeți subiectul aplicației, comunicarea client-server între aplicația dvs. și hardware, precum și detalii la nivel de protocol. De obicei, aceste informații sunt esențiale, deoarece necesită eforturi extreme de înțelegere și depanare.
Sfaturi:
- Indiferent de cât timp VUGen durează când jurnalul este activat, acesta nu are niciun impact asupra timpului de răspuns la tranzacție. HP numește acest fenomen drept „tehnologie de ultimă generație”.
- Dezactivați jurnalul dacă nu este necesar.
- Dezactivați jurnalul când ați terminat cu scripturile. Includerea scripturilor cu înregistrarea activată va face ca controlerul să ruleze mai lent și să raporteze mesajele deranjante.
- Dezactivarea jurnalului va crește capacitatea numărului maxim de utilizatori pe care îi puteți simula din LoadRunner.
- Luați în considerare utilizarea „Trimiteți mesaj numai atunci când apare o eroare” - aceasta va dezactiva mesajele de informații inutile și va raporta numai mesajele legate de eroare.
Think Times
Think Time este pur și simplu întârzierea dintre doi pași.
Think Time ajută la replicarea comportamentului utilizatorului, deoarece niciun utilizator real nu poate folosi nicio aplicație ca o mașină (VUGen). VUGen generează automat timpul de gândire. Aveți în continuare control complet pentru a elimina, înmulți sau fluctua durata duratei de gândire.
Pentru a înțelege mai multe, de exemplu, un utilizator poate deschide un ecran (adică un răspuns urmat de o cerere) și apoi să îi furnizeze numele de utilizator și parola înainte de a accesa Enter. Următoarea interacțiune a aplicației cu serverul va avea loc atunci când face clic pe „Conectare”. Timpul pe care l-a luat un utilizator pentru a-și introduce numele de utilizator și parola este Think Time în LoadRunner.
Dacă doriți să simulați o încărcare agresivă pe aplicație, luați în considerare dezactivarea completă a timpului de gândire.
Cu toate acestea, pentru a simula un comportament asemănător real, puteți „User Random Think Time” și setați procentele după cum doriți.
Luați în considerare utilizarea Limit Think Time la o perioadă legitimă. De obicei, 30 de secunde sunt destul de bune.
Simulare viteză
Simularea vitezei se referă pur și simplu la capacitatea lățimii de bandă pentru fiecare echipament client.
Din moment ce simulăm mii de VUser prin LoadRunner, este uimitor cât de simplu a făcut LoadRunner pentru a controla lățimea de bandă / simularea vitezei de rețea.
Dacă sunteți clienți, accesați aplicația dvs. de peste 128 Kbps, o puteți controla de aici. Veți putea simula „comportament asemănător real”, care ar trebui să vă ajute să obțineți statistici corecte de performanță.
Cea mai bună recomandare este să setați Utilizarea lățimii de bandă maxime. Acest lucru vă va ajuta să ignorați orice blocaje de performanță legate de rețea și să vă concentrați mai întâi pe eventualele probleme din aplicație. Puteți oricând rula testul de mai multe ori pentru a vedea comportamentul diferit în circumstanțe diferite.
Emulare browser
Experiența utilizatorului nu depinde de browserul pe care îl folosește un utilizator final. În mod clar, acest lucru depășește sfera măsurilor de performanță. Cu toate acestea, puteți alege ce browser doriți să emulați.
Puteți să vă răspundeți când va conta cu adevărat să selectați browserul potrivit în această configurație?
Veți utiliza această configurație dacă faceți obiectul aplicației este o aplicație web, returnând răspunsuri diferite pentru diferite browsere. De exemplu, puteți vedea diferite imagini și conținut pentru IE și Firefox etc.
O altă setare importantă este Simularea cache-ului browserului. Dacă doriți să evaluați timpul de răspuns când cache-ul este activat, bifați această casetă. Dacă sunteți în căutarea celei mai nefavorabile situații, acest lucru nu este evident o considerație.
Descărcarea resurselor non-HTML va permite LoadRunner să descarce orice CSS, JS și alte conținut media îmbogățit. Acest lucru ar trebui să rămână verificat. Cu toate acestea, dacă doriți să eliminați acest lucru din proiectarea testului de performanță, puteți debifa acest lucru.
Proxy
Cel mai bine este să eliminați complet proxy-ul din mediul de testare - acest lucru va face rezultatele testului nesigure. Cu toate acestea, s-ar putea să vă confruntați cu situații în care este inevitabil. Într-o astfel de situație, LoadRunner vă facilitează setările proxy.
Veți lucra (sau ar trebui să lucrați) fără setarea proxy. O puteți obține din browserul dvs. implicit. Cu toate acestea, nu uitați să verificați ce browser este setat implicit și ce configurație proxy este pentru browserul implicit.
Dacă utilizați un proxy și necesită autentificare (sau un script), puteți face clic pe butonul Autentificare care duce la o nouă fereastră. Consultați imaginea de mai jos.
Utilizați acest ecran pentru a furniza numele de utilizator și parola pentru a vă autentifica pe serverul proxy. Faceți clic pe OK pentru a închide ecranul.
Felicitări. Ați terminat cu configurarea scriptului VUGen. Nu uitați să-l configurați pentru toate scripturile VUser.