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 scenariu 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 dintre clicuri pe butoane (ora de gândire) va varia de la persoană la persoană. Sunt șanse ca unii utilizatori reali să vă acceseze aplicația prin DSL, iar unii să o acceseze printr-o dial-up. Așadar, pentru a obține senzația reală a utilizatorului final, trebuie să ne îmbunătățim scripturile pentru a se potrivi exact sau cel puțin foarte apropiat ca comportament de utilizatorii reali.

Cele de mai sus este cea mai importantă considerație atunci când desfășurați „Test de performanta”, dar există mai mult la un Script VU. Cum veți evalua cu exactitate timpul necesar unui VUser atunci când SUL este supus unui test de performanță? Cum ați ști dacă VUser a trecut sau a eșuat la un anumit moment? Care este cauza din spatele eșecului, dacă un proces backend a eșuat sau dacă 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

Tranzacțiile sunt mecanisme de măsurare a timpului de răspuns al serverului pentru orice operațiune. Cu cuvinte simple, utilizarea „Tranzacție” ajută la măsurarea timpului necesar sistemului pentru o anumită solicitare. Poate fi la fel de mic ca un clic pe un buton sau un apel AJAX la pierderea focalizării din caseta de text.

Aplicarea tranzacțiilor este simplă. Doar scrieți o linie de cod înainte ca cererea să fie făcută către server și închideți tranzacția când cererea se termină. 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(“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);

Puncte de reținut:

• Nu uitați că lucrați cu „C” și acesta este un limbaj sensibil la majuscule și minuscule.
• Caracterul punct (.) nu este permis în numele tranzacției, deși puteți utiliza spații și liniuță de subliniere.
• 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 și LoadRunner va gestiona automat erorile de server (HTTP 500, 400 etc.)
• Când aplicați tranzacții, asigurați-vă că nu există gând_timp extrasul este intercalat sau altfel tranzacția dvs. va include întotdeauna acea perioadă.
• Deoarece LoadRunner necesită un șir constant ca nume de tranzacție, o problemă comună la aplicarea tranzacției este nepotrivirea șirului. Dacă dați un alt nume 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ă prima? Pentru a-ți valida răspunsul, de ce să nu faci propria ta 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 cererilor ș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 singură linie de declarație care îi spune LoadRunner să introducă concurența. Inserați puncte de întâlnire în scripturile VUser pentru a emula încărcarea grea a utilizatorilor pe server.

Punctele de întâlnire indică VUser să aștepte în timpul execuției testului ca mai mulți VUser să ajungă la un anumit punct, astfel încât să poată îndeplini simultan o sarcină. De exemplu, pentru a emula sarcina maximă pe serverul băncii, puteți insera un punct de întâlnire care să îi solicite 100 VUser să depună numerar în conturile lor în același timp. Acest lucru poate fi realizat cu ușurință folosind rendezvous.

Dacă punctele de întâlnire nu sunt locurile corecte, VUserul va accesa diferite părți ale aplicației – chiar și pentru același script. Acest lucru se datorează faptului că fiecare utilizator VU primește timp de răspuns diferit și, prin urmare, puțini utilizatori rămân în urmă.

Sintaxă: lr_rendesvous(„Nume 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ție imediată de timp 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țelesul codului pentru oricine se referă la el în viitor. Acestea oferă informații despre operarea specifică și separă două secțiuni pentru distincție.

Puteți adăuga comentarii

• În timpul înregistrării (folosind instrument)
• 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 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 folosi Steps Toolbox (cunoscut ca 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 Steps sub View à Steps Toolbox.

Aceasta va deschide o fereastră laterală, uitați-vă la instantaneu:

Ce este parametrizarea?

A 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 Controller), valoarea dintr-o sursă externă (cum ar fi .txt, XML sau baza de date) înlocuiește valoarea anterioară a parametrului.

Parametrizarea este utilă în trimiterea de valori dinamice (sau unice) către server, de exemplu; se dorește ca un proces de afaceri să ruleze 10 iterații, dar alegerea unui nume de utilizator unic de fiecare dată.

De asemenea, ajută la stimularea unui comportament real al sistemului subiect. Aruncă 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 solicitare codificată.

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 un cache de date trimise către și de la server. Ca rezultat, serverul nu primește un comportament real al utilizatorului (în cazul în care serverul rulează un algoritm diferit în funcție de criteriile de căutare). În timp ce scriptul VUser se va executa cu succes, statisticile de performanță desenate nu vor fi semnificative. Utilizarea diferitelor date prin parametrizare ajută la emularea activității serverului (proceduri etc.) și la exercitarea sistemului.

O dată care este codificată în VUser în timpul înregistrării poate să nu mai fie valabilă când acea dată a trecut. Parametrizarea datei permite execuției VUser să reușească prin înlocuirea datei codificate. Astfel de câmpuri sau solicitări sunt candidații potriviți pentru parametrizare.

Clic aici dacă videoclipul nu este accesibil

Setările timpului de rulare și impactul lor asupra simulării VU

Setările timpului de execuție sunt la fel de importante ca și Scriptul dvs. VUGen. Cu diferite configurații, puteți obține diferite modele de testare. Acesta este motivul pentru care este posibil să ajungeți la rezultate nerepetabile dacă setările de timp de rulare nu sunt consecvente. 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 că acest lucru face mai clar de ce LoadRunner sugerează să păstrați tot codul de autentificare în vuser_init și partea Logout î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, atunci scenariul de mai jos va avea loc pentru fiecare utilizator VU:

Toți utilizatorii VU se vor autentifica, vor executa Ecran deschis, Calculați închirierea, Trimiteți fonduri, Verificați soldul – apoi – din nou Deschideți ecranul, Calculați închirierile… și așa mai departe – repetând de 10 ori – urmat de deconectare (o dată).

Aceasta este o setare puternică care vă permite să acționați mai mult ca un utilizator real. Amintiți-vă, un utilizator real nu se autentifică și nu se deconectează de fiecare dată – el, de obicei, repetă aceiași pași.

De câte ori faceți clic pe „Inbox” când vă verificați e-mailul înainte de deconectare?

pacing

Asta e important. În cea mai mare parte, oamenii sunt incapabili să înțeleagă diferența dintre ritm și timpul de gândire. Singura diferență este, „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 proiectarea testului. Cu toate acestea, dacă doriți să aveți o sarcină agresivă, luați în considerare optarea „De îndată ce se termină iterația anterioară”

Log

Un jurnal (așa cum se înțelege în general) este o evidență 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 de înregistrare puternic, care este robust și scalabil în sine. Vă permite să păstrați doar „Jurnal standard” sau un jurnal extins detaliat, configurabil sau să îl dezactivați complet.

Un jurnal standard este informativ și ușor de înțeles. Conține exact cantitatea potrivită de cunoștințe de care veți avea nevoie în general pentru depanarea scripturilor 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 solicitările, precum și datele de răspuns.

Dacă includeți „Date returnate de către server”, atunci jurnalul dvs. va fi lung. Aceasta va include toate informațiile HTML, etichete, resurse, non-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 și să nu fie ușor de înțeles.

După cum ați putea ghici până acum, dacă optați pentru „Advance Trace”, fișierul dvs. jurnal va fi masiv. Trebuie să încerci. Veți observa că timpul necesar 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, aceasta este o informație foarte avansată și poate utilă dacă înțelegeți aplicația subiect, comunicarea client-server dintre aplicația dvs. și hardware, precum și detaliile la nivel de protocol. De obicei, aceste informații sunt moarte prin esență, deoarece necesită eforturi extreme pentru a înțelege și a depana.

Sfat:

• Indiferent de cât timp durează VUGen când jurnalul este activat, nu are niciun impact asupra timpului de răspuns la tranzacție. HP numește acest fenomen „tehnologie de ultimă oră”.
• Dezactivați jurnalul dacă nu este necesar.
• Dezactivați jurnalul când ați terminat cu scripturile. Includerea scripturilor cu înregistrarea în jurnal activată va face ca controlerul să ruleze mai lent și să raporteze mesaje sâcâitoare.
• 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 mesajul numai când apare o eroare” – acest lucru va dezactiva mesajele de informații inutile și va raporta numai mesajele legate de eroare.

Think Times

Timpul de gândire 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 timp de gândire. Încă aveți control complet pentru a elimina, multiplica sau fluctua durata timpului de gândire.

Pentru a înțelege mai multe, de exemplu, un utilizator poate deschide un ecran (adică un răspuns urmat de o solicitare) și apoi poate furniza numele de utilizator și parola înainte de a apăsa enter. Următoarea interacțiune a aplicației cu serverul va avea loc atunci când face clic pe „Conectează-te”. Timpul necesar unui utilizator pentru a-și introduce numele de utilizator și parola este Think Time î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.

Cu toate acestea, pentru a simula un comportament asemănător real, puteți să „User Random Think Time” și să setați procentele după cum doriți.

Luați în considerare utilizarea Limitați timpul de gândire la o perioadă legitimă. De obicei, 30 de secunde sunt destul de bune.

Simularea vitezei

Simularea vitezei se referă pur și simplu la capacitatea de lățime de bandă pentru fiecare mașină client.

Deoarece simulăm mii de VUser prin LoadRunner, este uimitor cât de simplu a făcut LoadRunner să controleze simularea lățimii de bandă/vitezei rețelei.

Dacă sunteți clienți accesați aplicația dvs. peste 128 Kbps, o puteți controla de aici. Veți putea simula un „comportament asemănător real”, ceea ce ar trebui să vă ajute la obținerea statisticilor de performanță corecte.

Cea mai bună recomandare este să setați la Utilizare lățime de bandă maximă. Acest lucru vă va ajuta să ignorați orice blocaj de performanță legat de rețea și să vă concentrați mai întâi asupra oricăror probleme potențiale din aplicație. Puteți rula întotdeauna testul de mai multe ori pentru a vedea comportamentul diferit în diferite circumstanțe.

Emulare browser

Experiența utilizatorului nu depinde de browserul pe care îl folosește utilizatorul final. În mod clar, acest lucru depășește domeniul de aplicare al măsurilor de performanță. Cu toate acestea, puteți alege ce browser doriți să emulați.

Îți poți răspunde singur când exact va conta pentru tine să selectezi browserul potrivit în această configurație?

Veți folosi această configurație dacă aplicația subiect este o aplicație web, care returnează 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 memoriei cache a browserului. Dacă doriți să măsurați timpul de răspuns când memoria cache este activată, bifați această casetă. Dacă sunteți în căutarea celui mai rău caz, acest lucru nu este, evident, o considerație.

Descărcarea resurselor non-HTML va permite LoadRunner să descarce orice CSS, JS și alte media îmbogățite. Acest lucru ar trebui să rămână verificat. Cu toate acestea, dacă doriți să eliminați acest lucru din designul testului de performanță, îl puteți debifa.

Împuternicire

Cel mai bine este să eliminați complet proxy-ul din dvs Mediu de testare – acest lucru va face ca rezultatele testelor să fie 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) cu setarea Fără proxy. Îl puteți obține din browserul implicit. Cu toate acestea, nu uitați să verificați ce browser este setat ca implicit și care este configurația proxy 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 fereastră nouă. Consultați captura de ecran 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 dvs. VUser.