Parametryzacja, funkcje, transakcje w LoadRunner

Nagrany skrypt może symulować wirtualnego użytkownika; jednakże samo nagranie może nie wystarczyć do odtworzenia „prawdziwego zachowania użytkownika”.

Kiedy skrypt jest rejestrowany, obejmuje on pojedynczy i prosty przebieg przedmiotowego wniosku. Natomiast prawdziwy użytkownik może wykonać wiele iteracji dowolnego procesu przed wylogowaniem. Opóźnienie pomiędzy kliknięciami przycisków (czas namysłu) będzie się różnić w zależności od osoby. Istnieje prawdopodobieństwo, że niektórzy prawdziwi użytkownicy uzyskują dostęp do Twojej aplikacji przez DSL, a inni przez połączenie telefoniczne. Aby zatem uzyskać realne wrażenie użytkownika końcowego, musimy ulepszyć nasze skrypty, aby były dokładnie dopasowane lub przynajmniej bardzo zbliżone zachowaniem do rzeczywistych użytkowników.

Powyższe jest najważniejszym czynnikiem, który należy wziąć pod uwagę podczas przeprowadzania „Test wydajności”, ale w skrypcie VU kryje się coś więcej. W jaki sposób zmierzysz dokładną ilość czasu potrzebną użytkownikowi V, gdy SUL przechodzi test wydajności? Skąd wiesz, czy VUser przeszedł lub nie w pewnym momencie? Jaka jest przyczyna awarii, czy zawiodł jakiś proces zaplecza lub zasoby serwera były ograniczone?

Musimy ulepszyć nasz skrypt, aby pomógł odpowiedzieć na wszystkie powyższe pytania.

Korzystanie z transakcji

Transakcje to mechanizmy mierzące czas odpowiedzi serwera na dowolną operację. Mówiąc prościej, użycie „Transakcji” pomaga zmierzyć czas potrzebny systemowi na konkretne żądanie. Może to być coś tak małego jak kliknięcie przycisku lub wywołanie AJAX po utracie fokusu z pola tekstowego.

Stosowanie transakcji jest proste. Po prostu napisz jedną linię kodu przed wysłaniem żądania do serwera i zamknij transakcję po zakończeniu żądania. LoadRunner wymaga jedynie ciągu znaków jako nazwy transakcji.

Aby otworzyć transakcję, użyj tej linii kodu:

lr_start_transaction(“Transaction Name”);

Aby zamknąć transakcję, użyj tej linii kodu:

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

The informuje LoadRunner, czy ta konkretna transakcja zakończyła się sukcesem, czy niepowodzeniem. Możliwe parametry to:

• LR_AUTO
• LR_PASS
• LR_FAIL

Przykład:

lr_end_transaction(“Mój_login”, LR_AUTO);
lr_end_transaction(“001_Nazwa_panelu otwarcia”, LR_PASS);
lr_end_transaction(“Nazwa transakcji_przepływu_biznesu”, LR_FAIL);

Punkty do zapamiętania:

• Nie zapominaj, że pracujesz w języku „C”, w którym rozróżniana jest wielkość liter.
• Znak kropki (.) nie jest dozwolony w nazwie transakcji, chociaż można używać spacji i podkreśleń.
• Jeśli dobrze rozgałęziłeś swój kod i dodałeś punkty kontrolne, aby zweryfikować odpowiedź z serwera, możesz użyć niestandardowej obsługi błędów, takiej jak LR_PASS lub LR_FAIL. W przeciwnym razie możesz użyć LR_AUTO, a LoadRunner automatycznie obsłuży błąd serwera (HTTP 500, 400 itd.)
• Podczas stosowania transakcji upewnij się, że nie ma czas_myślenia oświadczenie będzie umieszczone w środkowej części, w przeciwnym razie transakcja zawsze będzie obejmować ten okres.
• Ponieważ LoadRunner wymaga stałego ciągu znaków jako nazwy transakcji, częstym problemem podczas stosowania transakcji jest niedopasowanie ciągu. Jeśli przy otwieraniu i zamykaniu transakcji podasz inną nazwę, popełnisz co najmniej 2 błędy. Ponieważ otwarta transakcja nigdy nie została zamknięta, LoadRunner zwróci błąd. Poza tym transakcja, którą próbujesz zamknąć, nigdy nie została otwarta, co spowodowało błąd.
• Czy potrafisz użyć swojej inteligencji i odpowiedzieć sobie, który z powyższych błędów zostanie zgłoszony jako pierwszy? Aby potwierdzić swoją odpowiedź, dlaczego nie popełnić własnego błędu? Jeśli odpowiedziałeś poprawnie, jesteś na dobrej drodze. Jeśli odpowiedziałeś źle, musisz się skupić.
• Ponieważ LoadRunner automatycznie dba o synchronizację żądań i odpowiedzi, nie musisz martwić się o odpowiedź podczas stosowania transakcji.

Zrozumienie czasu myślenia, punktów spotkania i komentarzy

Punkty spotkań

Rendezvous Points oznaczają „miejsca spotkań”. To tylko jedna linia instrukcji, która mówi LoadRunnerowi, aby wprowadził współbieżność. Wstawiasz punkty spotkania do skryptów VUser, aby emulować duże obciążenie użytkowników na serwerze.

Punkty spotkania instruują VUser, aby podczas wykonywania testu poczekał, aż wielu VUser dotrze do określonego punktu, aby mogli jednocześnie wykonać zadanie. Na przykład, aby emulować szczytowe obciążenie serwera banku, możesz wstawić punkt spotkania instruujący 100 użytkowników V, aby w tym samym czasie wpłacili gotówkę na swoje konta. Można to łatwo osiągnąć za pomocą spotkania.

Jeśli punkty spotkania nie zostaną umieszczone prawidłowo, VUser będzie miał dostęp do różnych części aplikacji – nawet w przypadku tego samego skryptu. Dzieje się tak, ponieważ każdy użytkownik VUser ma inny czas reakcji i dlatego niewielu użytkowników pozostaje w tyle.

Składnia: lr_rendesvous („Nazwa logiczna”);

Najlepsze Praktyki:

• Poprzedź miejsce spotkania prefiksem „rdv_”, aby zapewnić lepszą czytelność kodu; np. „rdv_Login”
• Usuń wszelkie natychmiastowe stwierdzenia dotyczące czasu do namysłu
• Stosowanie punktów spotkania w widoku skryptu (po nagraniu)

Komentarze

Dodaj komentarze, aby opisać działanie, fragment kodu lub linię kodu. Komentarze pomagają uczynić kod zrozumiałym dla każdego, kto będzie się do niego odwoływał w przyszłości. Dostarczają informacji o konkretnej operacji i oddzielają dwie sekcje w celu rozróżnienia.

Możesz dodawać komentarze

• Podczas nagrywania (przy użyciu narzędzia)
• Po nagraniu (bezpośrednio zapisaniu kodu)

Najlepsza praktyka: Zaznacz wszelkie komentarze na górze każdego pliku skryptu

Wstawianie funkcji poprzez menu

Chociaż możesz bezpośrednio pisać proste linie kodu, możesz potrzebować wskazówki, aby przypomnieć sobie funkcję. Możesz również użyć Steps Toolbox (znanego jako Insert Function przed wersją 12), aby znaleźć i wstawić dowolną funkcję bezpośrednio do swojego skryptu.

Pasek narzędzi Kroki znajdziesz w menu Widok > Skrzynka narzędziowa Kroki.

Otworzy się boczne okno, spójrz na migawkę:

Co to jest parametryzacja?

A parametr w VUGen jest kontenerem zawierającym zarejestrowaną wartość, która jest zastępowana dla różnych użytkowników.

Podczas wykonywania skryptu (w VUGen lub Controllerze) wartość ze źródła zewnętrznego (np. .txt, XML lub baza danych) zastępuje poprzednią wartość parametru.

Parametryzacja jest przydatna na przykład przy wysyłaniu dynamicznych (lub unikalnych) wartości do serwera; proces biznesowy powinien wykonywać 10 iteracji, ale za każdym razem wybierać unikalną nazwę użytkownika.

Pomaga także w stymulowaniu rzeczywistych zachowań systemu podmiotowego. Spójrz na poniższy przykład:

Przykłady problemów:

Proces biznesowy działa tylko dla bieżącej daty pochodzącej z serwera, dlatego nie można go przekazać jako żądania zakodowanego na stałe.

Czasami aplikacja kliencka przekazuje do serwera unikalny identyfikator (np. session_id), aby proces mógł być kontynuowany (nawet dla pojedynczego użytkownika) – w takim przypadku pomaga parametryzacja.

Często aplikacja kliencka przechowuje pamięć podręczną danych wysyłanych do i z serwera. W rezultacie serwer nie otrzymuje rzeczywistego zachowania użytkownika (w przypadku, gdy serwer uruchamia inny algorytm w zależności od kryteriów wyszukiwania). Chociaż skrypt VUser zostanie pomyślnie wykonany, wygenerowane statystyki wydajności nie będą miarodajne. Używanie różnych danych poprzez parametryzację pomaga emulować działania po stronie serwera (procedury itp.) i ćwiczy system.

Data zakodowana na stałe w VUser podczas nagrywania może nie być już ważna po jej przekroczeniu. Parametryzacja daty umożliwia pomyślne wykonanie VUser poprzez zastąpienie zakodowanej na stałe daty. Takie pola lub żądania są właściwymi kandydatami do parametryzacji.

Kliknij tutaj jeśli film nie jest dostępny

Ustawienia czasu pracy i ich wpływ na symulację VU

Ustawienia czasu wykonywania są tak samo ważne, jak Twój skrypt VUGen. Dzięki różnym konfiguracjom można uzyskać różne projekty testów. Dlatego też możesz uzyskać niepowtarzalne wyniki, jeśli ustawienia czasu wykonywania nie będą spójne. Omówmy każdy atrybut jeden po drugim.

Uruchom logikę

Run Logic określa, ile razy zostaną wykonane wszystkie akcje, z wyjątkiem vuser_init i vuser_end.

Prawdopodobnie to wyjaśnia, dlaczego LoadRunner sugeruje trzymanie całego kodu logowania w vuser_init i części wylogowania w vuser_end, oba wyłącznie.

Jeśli utworzyłeś wiele akcji, powiedzmy, zaloguj się, otwórz ekran, oblicz czynsz, prześlij środki, sprawdź saldo i wyloguj się, wówczas dla każdego użytkownika VUser będzie miał miejsce poniższy scenariusz:

Wszyscy użytkownicy V będą się logować, uruchamiać ekran otwarty, obliczać czynsz, przesyłać środki, sprawdzać saldo – a następnie – ponownie otwierać ekran, obliczać czynsze… i tak dalej – powtarzając 10 razy – a następnie wylogowując się (raz).

Jest to potężne ustawienie, które pozwala zachowywać się bardziej jak prawdziwy użytkownik. Pamiętaj, że prawdziwy użytkownik nie loguje się i nie wylogowuje za każdym razem – zazwyczaj powtarza te same kroki.

Ile razy klikasz „Skrzynka odbiorcza” podczas sprawdzania poczty przed wylogowaniem?

stymulacja

To jest ważne. Przeważnie ludzie nie są w stanie zrozumieć różnicy pomiędzy tempem a czasem myślenia. Jedyna różnica jest taka, „tempo odnosi się do opóźnienia między iteracjami”, podczas gdy czas myślenia to opóźnienie między dowolnymi 2 krokami.

Zalecane ustawienie zależy od projektu testu. Jeśli jednak szukasz agresywnego obciążenia, rozważ opcję „Zaraz po zakończeniu poprzedniej iteracji”

Zaloguj

Dziennik (w ogólnym rozumieniu) to rejestracja wszystkich zdarzeń zachodzących podczas uruchamiania LoadRunnera. Możesz włączyć dziennik, aby wiedzieć, co dzieje się między Twoją aplikacją a serwerem.

LoadRunner zapewnia potężny mechanizm rejestrowania, który sam w sobie jest solidny i skalowalny. Pozwala zachować tylko „Dziennik standardowy” lub szczegółowy, konfigurowalny dziennik rozszerzony lub całkowicie go wyłączyć.

Standardowy dziennik ma charakter informacyjny i jest łatwo zrozumiały. Zawiera odpowiednią ilość wiedzy, która będzie ogólnie potrzebna do rozwiązywania problemów ze skryptami VUser.

W przypadku dziennika rozszerzonego wszystkie informacje dziennika standardowego stanowią podzbiór. Dodatkowo możesz zastosować podstawienie parametrów. To mówi komponentowi LoadRunner, aby zawierał pełne informacje o wszystkich parametrach (z parametryzacji), w tym o żądaniach, a także dane odpowiedzi.

Jeśli uwzględnisz „Dane zwrócone przez serwer”, dziennik będzie długi. Będzie to obejmować cały kod HTML, znaczniki, zasoby i informacje inne niż zasoby zawarte bezpośrednio w dzienniku. Opcja jest dobra tylko wtedy, gdy potrzebujesz poważnego rozwiązywania problemów. Zwykle powoduje to, że plik dziennika ma bardzo duży rozmiar i jest trudny do zrozumienia.

Jak zapewne już zgadłeś, jeśli wybierzesz „Advance Trace”, Twój plik dziennika będzie ogromny. Musisz tego spróbować. Zauważysz, że czas potrzebny VUGenowi również znacznie się wydłużył, chociaż nie będzie to miało wpływu na czas odpowiedzi transakcji raportowany przez VUGen. Jednak są to bardzo zaawansowane informacje i mogą być przydatne, jeśli rozumiesz przedmiotową aplikację, komunikację klienta z serwerem między Twoją aplikacją a sprzętem, a także szczegóły na poziomie protokołu. Zazwyczaj te informacje są martwe z istoty, ponieważ wymagają ekstremalnych wysiłków, aby je zrozumieć i rozwiązać problemy.

Porady:

• Bez względu na to, ile czasu zajmuje VUGen po włączeniu dziennika, nie ma to wpływu na czas odpowiedzi transakcji. HP nazywa to zjawisko „najnowocześniejszą technologią”.
• Wyłącz dziennik, jeśli nie jest wymagany.
• Wyłącz dziennik, gdy skończysz ze skryptami. Dołączenie skryptów z włączonym logowaniem spowoduje wolniejsze działanie kontrolera i zgłaszanie dokuczliwych komunikatów.
• Wyłączenie dziennika zwiększy pojemność maksymalnej liczby użytkowników, których możesz symulować za pomocą LoadRunner.
• Rozważ użycie opcji „Wyślij wiadomość tylko w przypadku wystąpienia błędu” – wyciszy to niepotrzebne wiadomości informacyjne i zgłosi tylko wiadomości związane z błędami.

Pomyśl razy

Czas myślenia to po prostu opóźnienie między dwoma krokami.

Think Time pomaga odtworzyć zachowanie użytkownika, ponieważ żaden prawdziwy użytkownik nie może korzystać z żadnej aplikacji takiej jak maszyna (VUGen). VUGen automatycznie generuje czas do namysłu. Nadal masz pełną kontrolę nad usuwaniem, mnożeniem lub zmienianiem czasu trwania czasu myślenia.

Aby na przykład zrozumieć więcej, użytkownik może otworzyć ekran (jest to odpowiedź, po której następuje żądanie), a następnie podać nazwę użytkownika i hasło przed naciśnięciem Enter. Kolejna interakcja aplikacji z serwerem nastąpi po kliknięciu przycisku „Zaloguj się”. Czas potrzebny użytkownikowi na wpisanie nazwy użytkownika i hasła to Czas myślenia w LoadRunner.

Jeśli chcesz symulować agresywne obciążenie aplikacji, rozważ całkowite wyłączenie czasu myślenia.

Aby jednak zasymulować rzeczywiste zachowanie, możesz ustawić „Czas losowego myślenia użytkownika” i ustawić wartości procentowe według potrzeb.

Rozważ użycie opcji Ogranicz czas namysłu do uzasadnionego okresu. Zwykle 30 sekund jest wystarczająco dobre.

Symulacja prędkości

Symulacja prędkości odnosi się po prostu do przepustowości każdego komputera klienckiego.

Ponieważ symulujemy tysiące użytkowników VUser za pomocą LoadRunner, zdumiewające jest, jak proste stało się LoadRunner w kontrolowaniu symulacji przepustowości/prędkości sieci.

Jeśli jesteś klientem uzyskującym dostęp do aplikacji z szybkością 128 Kb/s, możesz stąd nią sterować. Będziesz mógł symulować „prawdziwe zachowanie”, co powinno pomóc w uzyskaniu odpowiednich statystyk wydajności.

Najlepszą rekomendacją jest ustawienie Użyj maksymalnej przepustowości. Pomoże to pominąć wszelkie wąskie gardła w wydajności związane z siecią i skupić się w pierwszej kolejności na wszelkich potencjalnych problemach w aplikacji. Zawsze możesz uruchomić test wiele razy, aby zobaczyć różne zachowania w różnych okolicznościach.

Emulacja przeglądarki

Doświadczenie użytkownika nie zależy od przeglądarki, z której korzysta użytkownik końcowy. Oczywiście wykracza to poza zakres miar wydajności. Możesz jednak wybrać przeglądarkę, którą chcesz emulować.

Czy potrafisz sobie odpowiedzieć, kiedy dokładnie będzie dla Ciebie istotne, aby w tej konfiguracji wybrać odpowiednią przeglądarkę?

Skorzystasz z tej konfiguracji, jeśli przedmiotem aplikacji jest aplikacja internetowa, która zwraca różne odpowiedzi dla różnych przeglądarek. Na przykład możesz zobaczyć różne obrazy i zawartość dla IE i Firefox itd.

Innym ważnym ustawieniem jest Simulate browser cache. Jeśli chcesz ocenić czas reakcji, gdy cache jest włączony, zaznacz to pole. Jeśli szukasz najgorszej sytuacji, to oczywiście nie jest to brane pod uwagę.

Pobieranie zasobów innych niż HTML umożliwi LoadRunnerowi pobranie dowolnego CSS, JS i innych multimediów. Należy to sprawdzić. Jeśli jednak chcesz wyeliminować to z projektu testu wydajności, możesz odznaczyć to pole.

lufka

Najlepiej całkowicie wyeliminować serwer proxy ze swojego Środowisko testowe – spowoduje to, że wyniki testu będą niewiarygodne. Możesz jednak spotkać się z sytuacjami, w których jest to nieuniknione. W takiej sytuacji LoadRunner ułatwia ustawienia proxy.

Będziesz pracować (lub powinieneś pracować) z ustawieniem Brak serwera proxy. Można go uzyskać w domyślnej przeglądarce. Nie zapomnij jednak sprawdzić, która przeglądarka jest ustawiona jako domyślna i jaka jest konfiguracja proxy dla domyślnej przeglądarki.

Jeśli korzystasz z serwera proxy i wymaga on uwierzytelnienia (lub skryptu), możesz kliknąć przycisk Uwierzytelnij, co spowoduje wyświetlenie nowego okna. Patrz poniższy zrzut ekranu.

Użyj tego ekranu, aby podać nazwę użytkownika i hasło w celu uwierzytelnienia na serwerze proxy. Kliknij OK, aby zamknąć ekran.

Gratulacje. Konfiguracja skryptu VUGen została zakończona. Nie zapomnij skonfigurować go dla wszystkich skryptów VUser.