Co to jest narzędzie testowe HP LoadRunner? Architektura, komponenty

Co to jest LoadRunner?

LoadRunner to narzędzie do testowania wydajności, którego pionierem była firma Mercury w 1999 r. LoadRunner został później przejęty przez HPE w 2006 r. W 2016 r. LoadRunner został przejęty przez MicroFocus.

LoadRunner obsługuje różne narzędzia programistyczne, technologie i protokoły komunikacyjne. W rzeczywistości jest to jedyne narzędzie na rynku, które obsługuje tak dużą liczbę protokołów do przeprowadzania testów wydajności. Wyniki testów wydajności generowane przez oprogramowanie LoadRunner są wykorzystywane jako punkt odniesienia w stosunku do innych narzędzi

W tym samouczku nauczysz się:

• Dlaczego LoadRunner?
• Dlaczego potrzebujesz testów wydajności?
• Co to jest architektura LoadRunner?
• Plan testowania wydajności: szczegółowe kroki
• FAQ

Dlaczego LoadRunner?

LoadRunner jest nie tylko pionierskim narzędziem w testowaniu wydajności, ale nadal jest liderem rynku w paradygmacie testów wydajności. W niedawnej ocenie LoadRunner ma około 85% udziału w rynku w branży testów wydajności.

Ogólnie rzecz biorąc, narzędzie LoadRunner obsługuje RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex i Silverlight itp.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail i przede wszystkim Windows Socket. Nie ma na rynku konkurencyjnego narzędzia, które mogłoby oferować tak szeroką gamę protokołów w jednym narzędziu.

Tym, co bardziej przekonuje do wyboru LoadRunner w testowaniu oprogramowania, jest wiarygodność tego narzędzia. Narzędzie LoadRunner od dawna cieszy się renomą, ponieważ często można spotkać klientów weryfikujących testy wydajności za pomocą LoadRunner. Znajdziesz ulgę, jeśli już używasz LoadRunner do testowania wydajności.

Oprogramowanie LoadRunner jest ściśle zintegrowane z innymi narzędziami HP, takimi jak Unified Functional Test (QTP) i ALM (Application Lifecycle Management) i umożliwia wykonywanie kompleksowych procesów testowych.

LoadRunner działa na zasadzie symulacji Wirtualnych Użytkowników w przedmiotowej aplikacji. Użytkownicy wirtualni, określani również jako VUsers, replikują żądania klienta i oczekują odpowiedniej odpowiedzi na przekazanie transakcji.

Dlaczego potrzebujesz testów wydajności?

Szacunkowa strata w przychodach w wysokości 4,4 miliarda jest odnotowywana rocznie z powodu słabej wydajności sieci.

W dzisiejszych czasach Web 2.0 użytkownicy klikają, jeśli witryna nie odpowiada w ciągu 8 sekund. Wyobraź sobie, że czekasz 5 sekund, szukając Google lub wysyłając zaproszenie do znajomych na Facebooku. Konsekwencje przestojów w działaniu są często bardziej druzgocące, niż kiedykolwiek sobie wyobrażano. Mamy przykłady, takie jak te, które niedawno trafiły na Bank of America Online Banking, Amazon Web Services, Intuit czy Blackberry.

Według Dunn & Bradstreet, 59% firm z listy Fortune 500 doświadcza około 1,6 godziny przestoju tygodniowo. Biorąc pod uwagę, że przeciętna firma z listy Fortune 500, zatrudniająca co najmniej 10 000 pracowników, płaci 56 USD za godzinę, część kosztów przestoju w takiej organizacji wyniosłaby 896 000 USD tygodniowo, co przekłada się na ponad 46 mln USD rocznie.

Szacuje się, że zaledwie 5 minut przestoju Google.com (19 sierpnia 13) kosztuje giganta wyszukiwania aż 545 000 USD.

Szacuje się, że firmy straciły sprzedaż o wartości 1100 USD na sekundę z powodu niedawnej awarii usługi Amazon Web Service.

Gdy system oprogramowania jest wdrażany przez organizację, może napotkać wiele scenariuszy, które mogą skutkować opóźnieniem wydajności. Szereg czynników powoduje spowolnienie działania, kilka przykładów może obejmować:

• Zwiększona liczba rekordów obecnych w bazie danych
• Zwiększona liczba jednoczesnych żądań wysyłanych do systemu
• większa liczba użytkowników uzyskujących jednocześnie dostęp do systemu w porównaniu z przeszłością

Co to jest architektura LoadRunner?

Mówiąc ogólnie, architektura HP LoadRunner jest złożona, ale łatwa do zrozumienia.

Załóżmy, że przydzielono Cię do sprawdzenia wydajności Amazon.com dla 5000 użytkowników

W rzeczywistości tych wszystkich 5000 użytkowników nie będzie na stronie głównej, ale w innej sekcji witryn. Jak możemy inaczej symulować

VUGen:

VUGen lub Virtual User Generator to IDE (Integrated Development Environment) lub bogaty edytor kodowania. VUGen jest używany do replikacji zachowania System Under Load (SUL). VUGen zapewnia funkcję „nagrywania”, która rejestruje komunikację do i od klienta i serwera w postaci zakodowanego skryptu - zwanego również skryptem VUser.

Biorąc więc pod uwagę powyższy przykład, VUGen może nagrywać w celu symulacji następujących procesów biznesowych:

1. Przeglądanie strony produktów Amazon.com
2. Sprawdzić
3. Przetwarzanie płatności
4. Sprawdzanie strony Moje konto

Kontroler

Po sfinalizowaniu skryptu VUser Controller jest jednym z głównych komponentów LoadRunner, który kontroluje symulację obciążenia, zarządzając na przykład:

• Ile VUserów ma zostać zasymulowanych dla każdego procesu biznesowego lub grupy VUser
• Zachowanie VUserów (zwiększanie, zmniejszanie, równoczesny lub współbieżny charakter itp.)
• Charakter scenariusza obciążenia, np. Realne życie lub zorientowany na cel lub weryfikacja SLA
• Których wtryskiwaczy użyć, ile VUserów przy każdym wtryskiwaczu
• Sortuj wyniki okresowo
• Podszywanie się pod IP
• Zgłaszanie błędów
• Raportowanie transakcji itp.

Biorąc analogię z naszego przykładowego kontrolera, dodamy następujący parametr do skryptu VUGen

1) 3500 użytkowników przegląda stronę produktów Amazon.com

2) 750 użytkowników jest w kasie

3) 500 użytkowników przeprowadza przetwarzanie płatności

4) 250 użytkowników sprawdza stronę Moje konto TYLKO po zakończeniu przetwarzania płatności przez 500 użytkowników

Możliwe są jeszcze bardziej złożone scenariusze

1. Inicjuj 5 VUserów co 2 sekundy, aż do załadowania 3500 VUserów (surfowanie po stronie produktu Amazon).
2. Powtarzaj przez 30 minut
3. Zawieś iterację dla 25 VUserów
4. Uruchom ponownie 20 VUSerów
5. Inicjuj 2 użytkowników (w Kasa, Przetwarzanie płatności, Strona Moje konta) co sekundę.
6. 2500 VUserów zostanie wygenerowanych na Maszynie A
7. 2500 VUserów zostanie wygenerowanych na Maszynie B

Agenci Maszyna / Generatory obciążenia / Wtryskiwacze

Kontroler HP LoadRunner jest odpowiedzialny za symulację tysięcy VUserów - te VUsery zużywają zasoby sprzętowe, na przykład procesor i pamięć - w ten sposób nakładając ograniczenia na maszynę, która je symuluje. Poza tym Kontroler symuluje te VUsery z tej samej maszyny (na której znajduje się Kontroler), stąd wyniki mogą nie być dokładne. Aby rozwiązać ten problem, wszystkie VU są rozmieszczone na różnych maszynach, zwanych generatorami obciążenia lub wtryskiwaczami obciążenia.

Zgodnie z ogólną praktyką kontroler znajduje się na innej maszynie, a obciążenie jest symulowane z innych maszyn. W zależności od protokołu skryptów VUser i specyfikacji maszyny, do pełnej symulacji może być potrzebnych kilka wtryskiwaczy obciążenia. Na przykład, VUsery dla skryptu HTTP będą wymagały od 2 do 4 MB na VUser do symulacji, stąd 4 maszyny z 4 GB RAM każda będą potrzebne do symulacji obciążenia 10 000 VUserów.

Biorąc Analogię z naszego przykładu Amazon, wyjście tego komponentu będzie

Analiza:

Po wykonaniu scenariuszy obciążenia pojawia się rola komponentów „ Analiza ” LoadRunner.

Podczas wykonywania, kontroler tworzy zrzut wyników w postaci surowej i zawiera informacje, takie jak, która wersja LoadRunner utworzyła ten zrzut wyników i jakie były konfiguracje.

Wszystkie błędy i wyjątki są rejestrowane w bazie danych Microsoft Access o nazwie output.mdb. Komponent „Analiza” odczytuje ten plik bazy danych w celu wykonania różnego rodzaju analiz i generuje wykresy.

Te wykresy pokazują różne trendy, aby zrozumieć przyczyny błędów i niepowodzeń pod obciążeniem; w ten sposób pomaga określić, czy optymalizacja jest wymagana w SUL, serwerze (np. JBoss, Oracle) lub infrastrukturze.

Poniżej znajduje się przykład, w którym przepustowość może tworzyć wąskie gardło. Powiedzmy, że serwer WWW ma pojemność 1 GB / s, podczas gdy ruch danych przekracza tę pojemność, powodując cierpienie kolejnych użytkowników. Aby określić, czy system spełnia takie potrzeby, inżynier wydajności musi przeanalizować zachowanie aplikacji przy nietypowym obciążeniu. Poniżej znajduje się wykres generowany przez LoadRunner w celu uzyskania przepustowości.

Plan testowania wydajności: szczegółowe kroki

Plan testowania wydajności można ogólnie podzielić na 5 kroków:

• Planowanie testu obciążenia
• Twórz skrypty VUGen
• Tworzenie scenariuszy
• Wykonanie scenariusza
• Analiza wyników (po której następuje modyfikacja systemu)

Po zainstalowaniu LoadRunner przyjrzyjmy się kolejno krokom związanym z tym procesem.

Kroki związane z procesem testowania wydajności

Planowanie testu obciążenia

Planowanie testów wydajnościowych różni się od planowania SIT (testy integracji systemu) lub UAT (testy akceptacji użytkowników). Planowanie można dalej podzielić na małe etapy, jak opisano poniżej:

Zbierz swój zespół

Rozpoczynając testowanie LoadRunner, najlepiej udokumentować, kto będzie uczestniczył w działaniu z każdego zespołu zaangażowanego w proces.

Menadżer projektu:

Wyznacz kierownika projektu, który będzie właścicielem tego działania i będzie wskazywał na eskalację.

Ekspert funkcyjny / Analityk biznesowy:

Zapewnienie analizy użytkowania SUL i ekspertyzy biznesowej funkcjonalności strony internetowej / SUL

Ekspert ds. Testów wydajnościowych:

Tworzy zautomatyzowane testy wydajności i wykonuje scenariusze obciążenia

Architekt systemu:

Zawiera plan SUL

Programista stron internetowych i MŚP:

• Utrzymuje witrynę internetową i zapewnia aspekty monitorowania
• Tworzy stronę internetową i naprawia błędy

Administrator systemu:

• Utrzymuje zaangażowane serwery przez cały czas trwania projektu testowego

Zarys aplikacji i zaangażowanych procesów biznesowych:

Pomyślne testowanie obciążenia wymaga zaplanowania wykonania określonego procesu biznesowego. Proces biznesowy składa się z jasno zdefiniowanych kroków zgodnych z pożądanymi transakcjami biznesowymi - tak, aby osiągnąć cele związane z testowaniem obciążenia.

Metrykę wymagań można przygotować w celu wywołania obciążenia systemu przez użytkownika. Poniżej przykład systemu obecności w firmie:

W powyższym przykładzie liczby mówią o liczbie użytkowników połączonych z aplikacją (SUL) w danej godzinie. Możemy wyodrębnić maksymalną liczbę użytkowników podłączonych do procesu biznesowego o dowolnej porze dnia, która jest obliczana w kolumnach po prawej stronie.

Podobnie możemy określić całkowitą liczbę użytkowników połączonych z aplikacją (SUL) o dowolnej porze dnia. Jest to obliczane w ostatnim wierszu.

Powyższe 2 fakty łącznie dają nam całkowitą liczbę użytkowników, z którymi musimy przetestować system pod kątem wydajności.

Zdefiniuj procedury zarządzania danymi testowymi

Na statystyki i obserwacje wyciągnięte z testów wydajności duży wpływ mają liczne czynniki, o których wspomniano wcześniej. Przygotowanie danych testowych do testów wydajnościowych ma krytyczne znaczenie. Czasami określony proces biznesowy zużywa zestaw danych i tworzy inny zestaw danych. Weź poniższy przykład:

• Użytkownik „A” tworzy umowę finansową i przesyła ją do przeglądu.
• Inny użytkownik „B” zatwierdza 200 umów dziennie utworzonych przez użytkownika „A”
• Inny użytkownik „C” płaci około 150 umów dziennie zatwierdzonych przez użytkownika „B”

W takiej sytuacji Użytkownik B musi mieć w systemie „utworzonych” 200 umów. Poza tym użytkownik C potrzebuje 150 umów jako „zatwierdzonych”, aby zasymulować obciążenie 150 użytkowników.

To pośrednio oznacza, że ​​musisz utworzyć co najmniej 200 + 150 = 350 kontraktów.

Następnie zatwierdź 150 umów, które będą służyć jako dane testowe dla użytkownika C - pozostałe 200 umów posłuży jako dane testowe dla użytkownika B.

Monitory zewnętrzne

Spekuluj każdy czynnik, który mógłby wpłynąć na wydajność systemu. Na przykład zmniejszenie ilości sprzętu może mieć potencjalny wpływ na wydajność SUL (System Under Load).

Zbierz wszystkie czynniki i skonfiguruj monitory, abyś mógł je ocenić. Oto kilka przykładów:

• Procesor (dla serwera internetowego, serwera aplikacji, serwera bazy danych i wtryskiwaczy)
• RAM (dla serwera internetowego, serwera aplikacji, serwera bazy danych i wtryskiwaczy)
• Serwer sieci Web / aplikacji (na przykład IIS, JBoss, Jaguar Server, Tomcat itp.)
• Serwer DB (rozmiar PGA i SGA w przypadku Oracle i MSSQL Server, SP itp.)
• Wykorzystanie przepustowości sieci
• Wewnętrzna i zewnętrzna karta sieciowa w przypadku klastrowania
• Load Balancer (i rozkłada obciążenie równomiernie na wszystkie węzły klastrów)
• Strumień danych (oblicz, ile danych jest przesyłanych do i od klienta i serwera - następnie oblicz, czy pojemność karty sieciowej jest wystarczająca, aby zasymulować liczbę X użytkowników)

Twórz skrypty VUGen

Kolejnym krokiem po planowaniu jest stworzenie skryptów VUser.

Tworzenie scenariuszy

Następnym krokiem jest stworzenie scenariusza ładowania

Wykonanie scenariusza

Wykonanie scenariusza polega na emulowaniu obciążenia użytkownika na serwerze przez nakazanie wielu VUserom jednoczesnego wykonywania zadań.

Poziom obciążenia można ustawić, zwiększając i zmniejszając liczbę VUserów wykonujących zadania w tym samym czasie.

To wykonanie może spowodować, że serwer będzie działał pod wpływem stresu i zachowywał się nieprawidłowo. To jest właśnie cel testów wydajności. Narysowane wyniki są następnie wykorzystywane do szczegółowej analizy i identyfikacji przyczyn źródłowych.

Analiza wyników (po której następuje modyfikacja systemu)

Podczas wykonywania scenariusza LoadRunner rejestruje wydajność aplikacji przy różnych obciążeniach. Statystyki uzyskane podczas wykonywania testów są zapisywane i przeprowadzana jest analiza szczegółów. Narzędzie „Analiza HP” generuje różne wykresy, które pomagają w identyfikacji głównych przyczyn opóźnienia w działaniu systemu, a także awarii systemu.

Niektóre z uzyskanych wykresów obejmują:

• Czas do pierwszego bufora
• Czas reakcji transakcji
• Średni czas odpowiedzi transakcji
• Trafienia na sekundę
• Zasoby systemu Windows
• Statystyki błędów
• Podsumowanie transakcji

FAQ

Które aplikacje powinniśmy przetestować wydajności?

Testowanie wydajności jest zawsze wykonywane tylko dla systemów typu klient-serwer. Oznacza to, że żadna aplikacja, która nie jest architekturą opartą na kliencie i serwerze, nie może wymagać testów wydajności.

Na przykład Microsoft Calculator nie jest oparty na serwerze klient-serwer ani nie obsługuje wielu użytkowników; w związku z tym nie jest kandydatem do testów wydajności.

Jaka jest różnica między testowaniem wydajności a inżynierią wydajności

Ważne jest, aby zrozumieć różnicę między testowaniem wydajności a inżynierią wydajności. Porozumienie podzielono się poniżej:

Testowanie wydajności to dyscyplina zajmująca się testowaniem i raportowaniem bieżącej wydajności aplikacji przy różnych parametrach.

Inżynieria wydajności to proces, w ramach którego oprogramowanie jest testowane i dostrajane w celu osiągnięcia wymaganej wydajności. Ten proces ma na celu optymalizację najważniejszej cechy wydajności aplikacji, tj. Doświadczenia użytkownika.

Historycznie rzecz biorąc, testowanie i dostrajanie były wyraźnie oddzielnymi i często konkurującymi dziedzinami. Jednak w ciągu ostatnich kilku lat kilku grup testerów i programistów współpracowało niezależnie, aby stworzyć zespoły tuningowe. Ponieważ zespoły te odniosły znaczący sukces, koncepcja sprzęgania testów wydajnościowych z dostrajaniem wydajności przyjęła się i teraz nazywamy to inżynierią wydajności.