Zarejestrowany skrypt może symulować wirtualnego użytkownika; jednak samo nagranie może nie wystarczyć do odtworzenia „rzeczywistego zachowania użytkownika”.
Nagranie scenariusza obejmuje pojedynczy i prosty przebieg wniosku przedmiotowego. Natomiast rzeczywisty użytkownik może wykonać wiele iteracji dowolnego procesu, zanim się wyloguje. Opóźnienie między kliknięciami przycisków (czas przemyślenia) 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 niektórzy przez dial-up. Tak więc, aby uzyskać prawdziwe 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żniejszą kwestią podczas przeprowadzania „Testów wydajności”, ale skrypt VU to coś więcej. W jaki sposób zmierzysz dokładną ilość czasu potrzebną użytkownikowi VUser, gdy SUL przechodzi test wydajności? Skąd możesz wiedzieć, czy VUser przeszedł lub zawiódł w pewnym momencie? Jaka jest przyczyna niepowodzenia, czy jakiś proces zaplecza nie powiódł się lub czy zasoby serwera były ograniczone?
Musimy ulepszyć nasz skrypt, aby pomóc odpowiedzieć na wszystkie powyższe pytania.
- Korzystanie z transakcji
- Zrozumienie czasu na myślenie, punktów spotkań i komentarzy
- Wstawianie funkcji przez menu
- Co to jest parametryzacja?
- Ustawienia czasu wykonywania i ich wpływ na symulację VU
- Uruchom logikę
- Tempo
- Log
- Think Times
- Symulacja prędkości
- Emulacja przeglądarki
- Pełnomocnik
Korzystanie z transakcji
Transakcje to mechanizmy mierzące czas odpowiedzi serwera dla dowolnej operacji. Mówiąc prościej, użycie „Transakcji” pomaga zmierzyć czas potrzebny systemowi na wykonanie określonego żądania. Może to być tak małe, 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 tylko ciągu znaków jako nazwy transakcji.
Aby otworzyć transakcję, użyj tej linii kodu:
lr_start_transaction („Nazwa transakcji”);
Aby zamknąć transakcję, użyj tej linii kodu:
lr_end_transaction („Nazwa transakcji”,);
- LR_AUTO
- LR_PASS
- LR_FAIL
Przykład:
lr_end_transaction („My_Login”, LR_AUTO);
lr_end_transaction („Business_Workflow_Transaction Name”, LR_FAIL);
Punkty do zapamiętania:
- Nie zapominaj, że pracujesz z „C” i jest to język uwzględniający wielkość liter.
- Znak kropki (.) Nie jest dozwolony w nazwie transakcji, chociaż można użyć spacji i podkreślenia.
- Jeśli dobrze rozgałęziłeś swój kod i dodałeś punkty kontrolne do weryfikacji odpowiedzi 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 itp.)
- Stosując transakcje, upewnij się, że żadne oświadczenie think_time nie jest przekładane , w przeciwnym razie transakcja zawsze będzie zawierać ten okres.
- Ponieważ LoadRunner wymaga stałego ciągu jako nazwy transakcji, częstym problemem podczas stosowania transakcji jest niezgodność ciągu. Jeśli podasz inną nazwę podczas otwierania i zamykania transakcji, 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 powoduje błąd.
- Czy możesz 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 dobrze odpowiedziałeś, jesteś na dobrej drodze. Jeśli źle odpowiedziałeś, musisz się skupić.
- Ponieważ LoadRunner automatycznie dba o synchronizację żądań i odpowiedzi, nie będziesz musiał martwić się o odpowiedź podczas stosowania transakcji.
Zrozumienie czasu na myślenie, punktów spotkań i komentarzy
Punkty spotkań
Punkty spotkań oznaczają „punkty spotkań”. To tylko jeden wiersz instrukcji, który informuje LoadRunner o wprowadzeniu współbieżności. Wstawiasz punkty spotkań do skryptów VUser, aby emulować duże obciążenie serwera przez użytkowników.
Punkty Rendezvous instruują VUser, aby podczas wykonywania testu czekał, aż wiele VUser dotrze do określonego punktu, aby mogły jednocześnie wykonywać zadanie. Na przykład, aby emulować obciążenie szczytowe na serwerze banku, możesz wstawić punkt spotkania, w którym 100 VUser będzie wpłacać gotówkę na swoje konta w tym samym czasie. Można to łatwo osiągnąć za pomocą rendezvous.
Jeśli punkty spotkania nie zostaną umieszczone poprawnie, VUser będzie miał dostęp do różnych części aplikacji - nawet dla tego samego skryptu. Dzieje się tak, ponieważ każdy VUser ma inny czas odpowiedzi, a zatem niewielu użytkowników pozostaje w tyle.
Składnia: lr_rendesvous („Nazwa logiczna”);
Najlepsze praktyki:
- Przedrostek punktu spotkania przedrostkiem „rdv_” dla lepszej czytelności kodu; np. „rdv_Login”
- Usuń wszelkie natychmiastowe stwierdzenia dotyczące czasu do namysłu
- Stosowanie punktów spotkań w widoku skryptu (po nagraniu)
Komentarze
Dodaj komentarze opisujące działanie, fragment kodu lub wiersz kodu. Komentarze pomagają uczynić kod zrozumiałym dla każdego, kto odwołuje się do niego w przyszłości. Dostarczają informacji o konkretnej operacji i oddzielają dwie sekcje dla rozróżnienia.
Możesz dodawać komentarze
- Podczas nagrywania (za pomocą narzędzia)
- Po nagraniu (bezpośrednie wpisanie kodu)
Najlepsza praktyka: zaznacz wszelkie komentarze na górze każdego pliku skryptu
Wstawianie funkcji przez menu
Chociaż możesz bezpośrednio pisać proste wiersze kodu, możesz potrzebować wskazówki, aby przywołać funkcję. Możesz także użyć Steps Toolbox (znanego jako Insert Function przed wersją 12), aby znaleźć i wstawić dowolną funkcję bezpośrednio do skryptu.
Pasek narzędzi Steps znajduje się w menu View àSteps Toolbox.
Otworzy się boczne okno, spójrz na migawkę:
Co to jest parametryzacja?
Parametr w VUGen jest kontener, który zawiera nagraną wartość, która jest zastąpiona przez różnych użytkowników.
Podczas wykonywania skryptu (w VUGen lub Controller) wartość z zewnętrznego źródła (np. .Txt, XML lub baza danych) zastępuje poprzednią wartość parametru.
Parametryzacja jest przydatna na przykład do wysyłania dynamicznych (lub unikalnych) wartości do serwera; proces biznesowy ma uruchamiać 10 iteracji, ale za każdym razem wybiera unikalną nazwę użytkownika.
Pomaga również w stymulowaniu rzeczywistego zachowania w systemie podmiotu. Spójrz na poniższy przykład:
Przykłady problemów:
Proces biznesowy działa tylko dla bieżącej daty, która pochodzi z serwera, dlatego nie może być przekazana jako zakodowane żądanie.
Czasami aplikacja kliencka przekazuje do serwera unikalny identyfikator (na przykład identyfikator_sesji), 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 iz 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 wykonany pomyślnie, narysowane statystyki wydajności nie będą miały znaczenia. Używanie różnych danych poprzez parametryzację pomaga emulować aktywność po stronie serwera (procedury itp.) I ćwiczyć system.
Data, która jest zakodowana na stałe w VUser podczas zapisu, może przestać obowiązywać po upływie tej daty. Parametryzacja daty umożliwia pomyślne wykonanie VUser przez zastąpienie daty zakodowanej na stałe. Takie pola lub żądania są odpowiednimi kandydatami do parametryzacji.
Kliknij tutaj, jeśli wideo nie jest dostępne
Ustawienia czasu wykonywania i ich wpływ na symulację VU
Ustawienia czasu wykonywania są tak samo ważne jak Twój skrypt VUGen. Przy różnych konfiguracjach można uzyskać różne projekty testów. Dlatego możesz otrzymać niepowtarzalne wyniki, jeśli ustawienia czasu wykonywania nie są spójne. Omówmy każdy atrybut jeden po drugim.
Uruchom logikę
Run Logic definiuje, ile razy będą wykonywane wszystkie akcje, z wyjątkiem vuser_init i vuser_end.
Prawdopodobnie to wyjaśnia, dlaczego LoadRunner sugeruje przechowywanie całego kodu logowania w vuser_init, a część Logout w vuser_end, oba wyłącznie.
Jeśli utworzyłeś wiele akcji, powiedzmy: Zaloguj się, Otwórz ekran, Oblicz wypożyczenie, Prześlij środki, Sprawdź saldo i wyloguj się, wówczas dla każdego VUser zostanie zastosowany poniższy scenariusz:
Wszyscy VUsers zalogują się, wykonają otwarty ekran, obliczą czynsz, prześlą środki, sprawdzą saldo - potem - znowu - otwórz ekran, obliczą czynsze… i tak dalej - powtarzając 10 razy - po czym wylogują się (raz).
To potężne ustawienie, które pozwala działać 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 „skrzynkę odbiorczą” podczas sprawdzania poczty e-mail przed wylogowaniem?
Tempo
To jest ważne. Przeważnie ludzie nie są w stanie zrozumieć różnicy między tempem a czasem przemyśleń. Jedyna różnica polega na tym, że „stymulacja 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ę „Jak tylko zakończy się poprzednia iteracja”
Log
Dziennik (w powszechnym rozumieniu) to księgowość wszystkich zdarzeń podczas uruchamiania LoadRunner. Możesz włączyć dziennik, aby wiedzieć, co dzieje się między Twoją aplikacją a serwerem.
LoadRunner zapewnia potężny mechanizm logowania, który jest solidny i samoczynnie skalowalny. Pozwala zachować tylko „Dziennik standardowy” lub szczegółowy, konfigurowalny dziennik rozszerzony lub całkowicie go wyłączyć.
Standardowy dziennik zawiera wiele informacji i jest łatwy do zrozumienia. Zawiera tylko odpowiednią ilość wiedzy, której będziesz zazwyczaj potrzebować przy rozwiązywaniu problemów ze skryptami VUser.
W przypadku dziennika rozszerzonego wszystkie informacje dziennika standardowego są podzbiorem. Dodatkowo możesz mieć podstawianie parametrów. To mówi komponentowi LoadRunner, aby zawierał pełne informacje o wszystkich parametrach (od parametryzacji), w tym o żądaniach, a także o danych odpowiedzi.
Jeśli uwzględnisz „Dane zwrócone przez serwer”, Twój dziennik będzie obszerny. Obejmuje to cały kod HTML, tagi, zasoby i informacje niezwiązane z zasobami zawarte bezpośrednio w dzienniku. Ta opcja jest dobra tylko wtedy, gdy potrzebujesz poważnego rozwiązania problemu. Zwykle powoduje to, że plik dziennika jest bardzo duży i trudny do zrozumienia.
Jak można się domyślić, jeśli zdecydujesz się na „Advance Trace”, Twój plik dziennika będzie ogromny. Musisz spróbować. Zauważysz, że ilość czasu zajmowanego przez VUGen również znacznie się zwiększyła, chociaż nie będzie to miało wpływu na czas odpowiedzi transakcji zgłaszany przez VUGen. Są to jednak bardzo zaawansowane informacje i mogą być przydatne, jeśli rozumiesz temat aplikacji, komunikację między klientem a serwerem między aplikacją a sprzętem, a także szczegóły dotyczące poziomu protokołu. Zwykle te informacje są martwe ze swej istoty, ponieważ ich zrozumienie i rozwiązywanie problemów wymaga ogromnych wysiłków.
Porady:
- Bez względu na to, ile czasu zajmuje VUGen po włączeniu logowania, 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 po zakończeniu pracy ze skryptami. Dołączenie skryptów z włączonym rejestrowaniem spowoduje, że kontroler będzie działał wolniej i będzie zgłaszał dokuczliwe komunikaty.
- Wyłączenie dziennika zwiększy pojemność maksymalnej liczby użytkowników, których możesz zasymulować z LoadRunner.
- Rozważ użycie opcji „Wyślij wiadomość tylko wtedy, gdy wystąpi błąd” - spowoduje to wyciszenie niepotrzebnych komunikatów informacyjnych i wyświetlenie tylko komunikatów związanych z błędami.
Think Times
Think Time to po prostu opóźnienie między dwoma krokami.
Think Time pomaga replikować zachowanie użytkownika, ponieważ żaden prawdziwy użytkownik nie może używać żadnej aplikacji, takiej jak maszyna (VUGen). VUGen automatycznie generuje czas do namysłu. Nadal masz pełną kontrolę nad usuwaniem, pomnażaniem lub zmienianiem czasu trwania myślenia.
Aby lepiej zrozumieć, na przykład użytkownik może otworzyć ekran (czyli odpowiedź, po której następuje żądanie), a następnie podać nazwę użytkownika i hasło przed naciśnięciem klawisza Enter. Następna interakcja aplikacji z serwerem nastąpi po kliknięciu „Zaloguj się”. Czas, w którym użytkownik wpisał swoją nazwę użytkownika i hasło, to Think Time w LoadRunner.
Jeśli chcesz zasymulować agresywne obciążenie aplikacji, rozważ całkowite wyłączenie czasu do namysłu.
Jednak, aby zasymulować rzeczywiste zachowanie, możesz „Losowo myśleć o użytkowniku” i ustawić wartości procentowe według potrzeb.
Rozważ skorzystanie z opcji Ogranicz czas do myślenia do dozwolonego okresu. Zwykle wystarczy 30 sekund.
Symulacja prędkości
Symulacja prędkości odnosi się po prostu do przepustowości dla każdego komputera klienckiego.
Ponieważ symulujemy tysiące VUserów za pomocą LoadRunner, niesamowite jest, jak proste jest narzędzie LoadRunner do kontrolowania symulacji przepustowości / prędkości sieci.
Jeśli jesteś klientem, który uzyskuje dostęp do Twojej aplikacji z szybkością 128 Kb / s, możesz nią sterować tutaj. Będziesz mógł zasymulować „rzeczywiste zachowanie”, co powinno pomóc w uzyskaniu właściwych statystyk wydajności.
Najlepszym zaleceniem jest ustawienie Użyj maksymalnej przepustowości. Pomoże to zignorować wszelkie wąskie gardła wydajności związane z siecią i skupić się najpierw na wszelkich potencjalnych problemach z aplikacją. 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 ważne, aby wybrać odpowiednią przeglądarkę w tej konfiguracji?
Będziesz używał tej konfiguracji, jeśli jesteś przedmiotem aplikacji to aplikacja internetowa, zwracająca różne odpowiedzi dla różnych przeglądarek. Na przykład możesz zobaczyć różne obrazy i treści dla IE i Firefox itp.
Kolejnym ważnym ustawieniem jest Symulacja pamięci podręcznej przeglądarki. Jeśli chcesz zmierzyć czas odpowiedzi przy włączonej pamięci podręcznej, zaznacz to pole. Jeśli szukasz najgorszej sytuacji, oczywiście nie jest to brane pod uwagę.
Pobieranie zasobów innych niż HTML pozwoli LoadRunner pobrać dowolny CSS, JS i inne multimedia. Należy to sprawdzić. Jeśli jednak chcesz wyeliminować to z projektu testu wydajności, możesz odznaczyć tę opcję.
Pełnomocnik
Najlepiej całkowicie wyeliminować proxy ze środowiska testowego - spowoduje to, że wyniki testów będą niewiarygodne. Możesz jednak napotkać sytuacje, w których jest to nieuniknione. W takiej sytuacji LoadRunner ułatwia konfigurację ustawień proxy.
Będziesz pracować (lub powinieneś pracować) bez ustawienia proxy. Możesz go pobrać z domyślnej przeglądarki. Nie zapomnij jednak sprawdzić, która przeglądarka jest ustawiona jako domyślna i jaka jest konfiguracja proxy dla przeglądarki domyślnej.
Jeśli używasz proxy i wymaga uwierzytelnienia (lub skryptu), możesz kliknąć przycisk Uwierzytelnij, który prowadzi do nowego okna. Zobacz 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 swoich skryptów VUser.