Parametrizare, Funcții, Tranzacții în LoadRunner

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ă un flux unic și direct prin aplicația în cauză. Un utilizator real poate efectua mai multe iterații ale unui proces înainte de a se deconecta. Întârzierea dintre clicurile pe butoane (timpul de gândire) variază de la o persoană la alta, iar unii utilizatori ajung la aplicația dvs. printr-o conexiune rapidă, în timp ce alții nu. Așadar, pentru a obține o imagine reală a unui utilizator final, trebuie să îmbunătățim scripturile noastre pentru a se comporta foarte aproape de utilizatorii reali.

Aceasta este cea mai importantă considerație atunci când se efectuează „Test de performanta„”, dar un script VUser implică mai mult. Cum veți măsura timpul necesar unui VUser în timp ce sistemul sub sarcină (SUL) este testat? Cum veți ști dacă VUser a reușit sau a eșuat la un anumit moment și dacă un proces backend a eșuat sau resursele serverului au fost insuficiente?

Trebuie să îmbunătățim scenariul nostru pentru a ne ajuta să răspundem la toate întrebările de mai sus.

Notă despre marcă: VuGen a fost livrat ca HP, apoi Micro Focus și acum face parte din OpenText Inginerie profesională a performanțeiFuncțiile și setările de mai jos sunt neschimbate.

Utilizarea Tranzacțiilor

Tranzacțiile măsoară timpul de răspuns al serverului pentru orice operațiune. În cuvinte simple, o „tranzacție” măsoară timpul necesar sistemului pentru o anumită solicitare. Poate fi la fel de mic ca un clic pe un buton sau un apel AJAX declanșat atunci când o casetă de text își pierde focalizarea.

Aplicarea tranzacțiilor este simplă. Scrieți o linie de cod înainte de a fi făcută solicitarea și închideți tranzacția când solicitarea se termină. LoadRunner necesită doar un șir de caractere ca nume de tranzacție.

Pentru a deschide o tranzacție, utilizați această linie de cod:

lr_start_transaction(“Transaction Name”);

Pentru a închide tranzacția, utilizați această linie de cod:

lr_end_transaction(“Transaction Name”, <status>);

The spune LoadRunner dacă această anumită tranzacție a avut succes sau nu. Parametrii posibili ar putea fi:

• LR_AUTO
• LR_PASS
• LR_FAIL

Exemplu:

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);

Code Note: Fragmentele sunt reproduse exact așa cum au fost publicate, inclusiv citatele tipografice. Un script VuGen real are nevoie de ghilimele duble ASCII directe, așa că reintroduceți-le dacă copiați acest cod.

Puncte de reținut:

• Nu uitați că lucrați cu „C” și acesta este un limbaj sensibil la majuscule și minuscule.
• Punctul (.) nu este permis într-un nume de tranzacție, deși puteți utiliza spații și sublinieri.
• Dacă 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 personalizată a erorilor, cum ar fi LR_PASS sau LR_FAIL. În caz contrar, puteți utiliza LR_AUTO, iar LoadRunner va gestiona automat erorile serverului (HTTP 500, 400 etc.).
• Când aplicați tranzacții, asigurați-vă că nu există nicio declarație de timp de gândire inclusă în interior, altfel tranzacția va include întotdeauna acea perioadă.
• Întrucât LoadRunner necesită un șir constant ca nume de tranzacție, o problemă frecventă la aplicarea tranzacțiilor este o nepotrivire a șirurilor. Dacă dați un nume diferit la deschiderea și închiderea unei tranzacții, veți primi cel puțin 2 erori. Tranzacția pe care ați deschis-o nu a fost niciodată închisă, deci LoadRunner generează o eroare; iar tranzacția pe care încercați să o închideți nu a fost niciodată deschisă, ceea ce generează o a doua eroare.
• Ambele erori apar în jurnalul de reluare, așa că ori de câte ori este raportată una dintre ele, verificați mai întâi numele tranzacției din instrucțiunile de deschidere și închidere.
• Întrucât LoadRunner se ocupă automat de sincronizarea cererilor și răspunsurilor, nu va trebui să vă faceți griji cu privire la răspuns atunci când aplicați tranzacții.

Puncte de întâlnire, comentarii și funcții de script

Trei îmbunătățiri minore fac ca un script să se comporte și să se citească ca un cod de producție: punctele de întâlnire, comentariile și browserul de funcții încorporat în VuGen.

Puncte de întâlnire

Un punct de întâlnire este un „punct de întâlnire”. Este o singură instrucțiune care îi spune lui LoadRunner să introducă concurența. Punctele de întâlnire se introduc în scripturile VUser pentru a emula încărcarea mare a utilizatorilor pe server.

Punctele de întâlnire instruiesc un utilizator virtual (VUser) să aștepte în timpul execuției până când mai mulți utilizatori virtuali (VUsers) ajung la un anumit punct, astfel încât aceștia să poată efectua o sarcină simultan. De exemplu, pentru a emula sarcina maximă pe serverul unei bănci, introduceți un punct de întâlnire care instruiește 100 de utilizatori virtuali să depună numerar în același timp.

Dacă punctele de întâlnire nu sunt plasate corect, utilizatorii virtuali vor accesa părți diferite ale aplicației chiar și pentru același script. Acest lucru se datorează faptului că fiecare utilizator virtual are un timp de răspuns diferit și, prin urmare, câțiva utilizatori rămân în urmă.

Sintaxă:

lr_rendezvous(“Logical Name”);

Notă de corecție: pagina publicată scrie asta lr_rendesvousNumele corect al funcției este lr_rendezvous; forma greșită nu se va compila.

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 instrucțiuni de timp de gândire imediat adiacente
• Aplicarea punctelor de întâlnire în vizualizarea Script, după înregistrare

Vizualizarea Script de mai jos prezintă o declarație de întâlnire inserată într-o acțiune înregistrată:

Comentarii

Adăugați comentarii pentru a descrie o activitate, o porțiune de cod sau o linie de cod. Comentariile ajută la înțelegerea codului pentru oricine îl va consulta în viitor. Acestea oferă informații despre o operațiune specifică și separă două secțiuni pentru a le distinge.

Puteți adăuga comentarii

• În timpul înregistrării (folosind instrumentul)
• După înregistrare (scriere directă în cod)

Cea mai bună practică: marcați orice comentarii în partea de sus a fiecărui fișier script.

Inserarea funcțiilor prin meniu

Deși poți scrie direct linii simple de cod, este posibil să ai nevoie de un indiciu pentru a-ți aminti o funcție. De asemenea, poți utiliza instrumentul Steps Toolbox (cunoscut sub numele de Insert Function înainte de versiunea 12) pentru a găsi și insera orice funcție direct în scriptul tău.

Puteți găsi caseta de instrumente Steps în View → Steps Toolbox, așa cum se arată mai jos.

Aceasta va deschide o fereastră laterală. Uită-te la instantaneu:

Ce este parametrizarea?

Un parametru în VuGen este un container care conține o valoare înregistrată, care este înlocuită pentru diverși utilizatori.

În timpul execuției scriptului (în VuGen sau în operator de date cu caracter personal, ), o valoare dintr-o sursă externă (cum ar fi un fișier .txt, XML sau o bază de date) înlocuiește valoarea anterioară a parametrului.

Parametrizarea este utilă pentru trimiterea de valori dinamice (sau unice) către server. De exemplu, un proces de business poate fi nevoit să execute 10 iterații, alegând de fiecare dată un nume de utilizator unic.

De asemenea, ajută la simularea comportamentului din viața reală în raport cu sistemul subiect. Aruncați o privire la exemplele de mai jos.

Exemple de probleme:

• Un proces de business funcționează doar pentru data curentă, care provine de la server, deci nu poate fi transmis ca o cerere hardcoded.
• Uneori, aplicația client transmite 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 menține o memorie cache a datelor trimise către și de la server. Drept urmare, serverul nu primește informații despre comportamentul real al utilizatorului (unde serverul rulează un algoritm diferit în funcție de criteriile de căutare). Scriptul VUser se va executa cu succes, dar statisticile de performanță generate nu vor fi semnificative. Utilizarea unor date diferite prin parametrizare ajută la emularea activității de pe server, cum ar fi procedurile stocate, și exersează sistemul.
• O dată care este codificată hard în VUser în timpul înregistrării poate să nu mai fie validă odată ce data respectivă a trecut. Parametrizarea datei permite execuția VUser să aibă succes prin înlocuirea datei codificate hard. Astfel de câmpuri sau solicitări sunt candidații potriviți pentru parametrizare.

Puteți crea unul făcând clic dreapta pe valoarea înregistrată în vizualizarea Script și alegând Înlocuire cu un parametru. VuGen întreabă apoi ce tip furnizează valoarea:

Două opțiuni suplimentare decid modul în care datele sunt consumate în diferite iterații:

Ghidul de mai jos prezintă parametrizarea aplicată unui script înregistrat:

Clic aici dacă videoclipul nu este accesibil.

Setările de execuție și impactul acestora asupra simulării VUser

Setările de execuție contează la fel de mult ca scriptul VuGen. Cu configurații variate, puteți obține modele de testare complet diferite, motiv pentru care setările de execuție inconsistente sunt cauza obișnuită a rezultatelor nerepetabile. Să discutăm fiecare atribut pe rând.

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 că acest lucru clarifică de ce LoadRunner sugerează keeping tot codul de autentificare din vuser_init și partea de deconectare din vuser_end, ambele exclusiv.

Dacă ați creat mai multe acțiuni — de exemplu, Conectare, Deschidere ecran, Calculare chirie, Trimitere fonduri, Verificare sold și Deconectare — atunci scenariul de mai jos va avea loc pentru fiecare utilizator virtual:

Toți utilizatorii virtuali se vor autentifica, vor executa operațiunile Deschide Ecran, Calculează Chirie, Trimite Fonduri și Verifică Sold, apoi din nou Deschide Ecran, Calculează Chirie și așa mai departe, iterând de 10 ori, urmate de deconectare (o dată).

Aceasta este o setare puternică care permite scriptului să se comporte mai mult ca un utilizator real. Rețineți că un utilizator real nu se conectează și nu se deconectează de fiecare dată; de obicei, repetă aceiași pași.

De câte ori dai clic pe „Inbox” când îți verifici e-mailul înainte de a te deconecta?

pacing

Acest lucru este important. Majoritatea oamenilor nu pot înțelege diferența dintre ritm și timpul de gândire. Singura diferență este că ritmul 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 designul testului. Totuși, dacă doriți să aplicați o sarcină agresivă, luați în considerare opțiunea „Imediat ce se termină iterația anterioară”, așa cum se arată mai jos.

Log

Un jurnal, așa cum este înțeles în general, este o înregistrare a tuturor evenimentelor în timp ce rulați LoadRunner. Puteți activa jurnalul pentru a ști ce se întâmplă între aplicația dvs. și server.

LoadRunner oferă un mecanism puternic de înregistrare în jurnal, robust și scalabil. Acesta vă permite să păstrați doar un „Jurnal standard” sau un jurnal extins detaliat și configurabil, sau să dezactivați complet înregistrarea în jurnal.

Un jurnal standard este informativ și ușor de înțeles. Conține exact cantitatea potrivită de informații de care veți avea nevoie, în general, pentru a depana scripturile VUser.

În cazul Jurnalului Extins, toate informațiile standard din jurnal reprezintă un subset. În plus, puteți avea substituție de parametri. Aceasta îi spune componentei LoadRunner să includă informații complete despre toți parametrii (din parametrizare), inclusiv solicitări, precum și date de răspuns.

Dacă includeți „Datele returnate de server”, jurnalul va crește în lungime. Acesta va include toate informațiile HTML, etichetele, resursele și informațiile non-resursă direct în jurnal. Opțiunea este bună doar dacă aveți nevoie de o depanare serioasă. De obicei, acest lucru face ca fișierul jurnal să fie foarte mare și dificil de înțeles.

După cum probabil ați ghicit deja, dacă optați pentru „Avansat Trac„e” fișierul tău jurnal va fi imens. Trebuie să încerci. Vei observa că timpul necesar VuGen crește, de asemenea, semnificativ, deși acest lucru nu are niciun impact asupra timpului de răspuns la tranzacții raportat de VuGen. Acestea sunt informații foarte avansate și utile numai dacă înțelegi aplicația în cauză, comunicarea client-server dintre aplicația ta și hardware și detaliile la nivel de protocol. De obicei, aceste informații necesită un efort extrem pentru a fi citite și depanate.

Sfat:

• Indiferent de timpul necesar pentru VuGen atunci când jurnalul este activat, acesta nu are niciun impact asupra timpului de răspuns al tranzacției — costurile suplimentare de înregistrare sunt excluse din timpul măsurat.
• Dezactivați jurnalul dacă nu este necesar.
• Dezactivați jurnalul când ați terminat cu scripturile. Includerea scripturilor cu jurnalizarea activată va face ca Controlerul să ruleze mai încet și să raporteze mesaje persistente.
• Dezactivarea jurnalului va crește numărul maxim de utilizatori pe care îi puteți simula din LoadRunner.
• Luați în considerare utilizarea opțiunii „Trimiteți mesaje numai când apare o eroare” — aceasta dezactivează mesajele informative inutile și raportează doar mesajele legate de erori.

Think Times

Timpul de gândire este pur și simplu întârzierea dintre doi pași.

Timpul de gândire ajută la replicarea comportamentului utilizatorului, deoarece niciun utilizator real nu poate utiliza o aplicație precum o mașină. VuGen generează automat timpul de gândire. Aveți în continuare control complet pentru a elimina, multiplica sau fluctua durata timpului de gândire.

Ca să înțelegem mai bine: un utilizator poate deschide un ecran (un răspuns urmat de o solicitare) și apoi poate introduce un nume de utilizator și o parolă înainte de a apăsa Enter. Următoarea interacțiune dintre aplicație și server are loc atunci când utilizatorul dă clic pe „Conectare”. Timpul necesar utilizatorului pentru a introduce numele de utilizator și parola este Timpul de gândire în LoadRunner.

Dacă doriți să simulați încărcarea agresivă a aplicației, luați în considerare dezactivarea completă a timpului de gândire.

Totuși, pentru a simula comportamentul din viața reală, puteți alege „Utilizați timpul de gândire aleatoriu” și seta procentele după cum doriți.

Luați în considerare utilizarea funcției „Limit Think Time” (Timp Limitat de Gândire) pentru a limita timpul la o perioadă legitimă. De obicei, 30 de secunde sunt suficiente.

Simularea vitezei

Simularea vitezei se referă pur și simplu la capacitatea lățimii de bandă a fiecărei mașini client.

Întrucât simulăm mii de utilizatori virtuali (VUsers) prin LoadRunner, este remarcabil cât de simplă a simplificat LoadRunner simularea lățimii de bandă și a vitezei rețelei.

Dacă clienții tăi accesează aplicația ta la o viteză mai mare de 128 Kbps, poți controla acest lucru de aici. Vei putea simula comportamentul din viața reală, ceea ce ar trebui să te ajute să obții statisticile corecte de performanță.

Cea mai bună recomandare este să setați opțiunea „Utilizați lățimea de bandă maximă”. Acest lucru vă ajută să ignorați orice blocaje de performanță legate de rețea și să vă concentrați mai întâi pe potențialele probleme din aplicație. Puteți oricând rula testul de mai multe ori pentru a vedea comportamentul variat în circumstanțe diferite.

Emulare browser

Experiența utilizatorului nu depinde de browserul utilizat de un utilizator final, așa că acest lucru depășește în mare măsură sfera măsurătorilor de performanță. Cu toate acestea, puteți alege ce browser doriți să emulați, așa cum se arată în panoul de mai jos.

Când contează cu adevărat ce browser selectați în această configurație?

Veți utiliza această configurație dacă aplicația dvs. subiect este o aplicație web care returnează răspunsuri diferite pentru browsere diferite. De exemplu, este posibil să vedeți imagini și conținut diferite pentru Internet Explorer și Firefox.

O altă setare importantă este Simulează memoria cache a browserului. Dacă vrei să măsori timpul de răspuns cu memoria cache activată, bifează această casetă. Dacă te uiți la cea mai defavorabilă situație, evident că nu este o opțiune de luat în considerare.

Descărcarea resurselor non-HTML va permite LoadRunner să descarce orice CSS, JS și alte elemente media bogate. Această opțiune ar trebui bifată. Cu toate acestea, dacă doriți să o eliminați din designul testului de performanță, o puteți debifa.

Împuternicire

Cel mai bine este să eliminați complet proxy-ul din Mediu de testare — un proxy aflat în cale face ca rezultatele testelor să fie nesigure. Cu toate acestea, s-ar putea să vă confruntați cu situații în care acest lucru este inevitabil. Într-o astfel de situație, LoadRunner oferă setări proxy.

Vei lucra (sau ar trebui să lucrezi) cu setarea Fără proxy. O poți obține din browserul tău implicit. Totuși, nu uita să verifici ce browser este setat ca implicit și care este configurația proxy pentru acel browser.

Dacă utilizați un proxy și acesta necesită autentificare (sau un script), atunci puteți face clic pe butonul Autentificare, care duce la o fereastră nouă. Consultați captura de ecran de mai jos.

Folosește acest ecran pentru a introduce un nume de utilizator și o parolă pentru autentificarea pe serverul proxy. Apasă pe OK pentru a închide ecranul.

Felicitări. Ați terminat de configurat scriptul VuGen. Nu uitați să îl configurați pentru toate scripturile VUser.

Urmează veni corelație, rulând scenariul în operator de date cu caracter personal, și citirea rezultatelor în Analiza LoadRunner. Vezi Arhitectura LoadRunner și Încărcarea testelor ghiduri.

Întrebări frecvente