Narzędzie do testowania LoadRunner – komponenty i Architektura

Co to jest LoadRunner?

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

LoadRunner obsługuje różne narzędzia programistyczne, technologie i protokoły komunikacyjne. Tak naprawdę jest to jedyne narzędzie na rynku, które obsługuje tak dużą liczbę protokołów do przeprowadzenia Test wydajności. Wyniki testu wydajności generowane przez oprogramowanie LoadRunner służą jako punkt odniesienia w porównaniu z innymi narzędziami

Film LoadRunner

Dlaczego LoadRunner?

LoadRunner jest nie tylko pionierskim narzędziem w testowaniu wydajności, ale nadal jest liderem na rynku w paradygmacie testów wydajnościowych. Z ostatniej oceny wynika, że ​​LoadRunner ma około 85% udziału w rynku w branży testów wydajnościowych.

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 Serwer, Citrix, RTE, Mail i ponad wszystko, Windows Gniazdo elektryczne. Nie ma na rynku konkurencyjnego narzędzia, które oferowałoby tak szeroką gamę protokołów w jednym narzędziu.

Tym, co bardziej przekonuje do wybrania LoadRunnera do testowania oprogramowania, jest wiarygodność tego narzędzia. Narzędzie LoadRunner od dawna cieszy się reputacją, którą często można spotkać klienci krzyżowo weryfikują Twoje testy porównawcze za pomocą LoadRunner. Odczujesz ulgę, jeśli już używasz LoadRunner do celów testowania wydajności.

Oprogramowanie LoadRunner jest ściśle zintegrowane z innymi narzędziami HP, takimi jak ujednolicony test funkcjonalny (QTP) i ALM (zarządzanie cyklem życia aplikacji), co umożliwia przeprowadzanie kompleksowych procesów testowych.

LoadRunner działa na zasadzie symulowania wirtualnych użytkowników w danej aplikacji. Ci Wirtualni Użytkownicy, zwani również VUżytkownikami, replikują żądania klientów i oczekują odpowiedniej odpowiedzi na przekazanie transakcji.

Dlaczego potrzebujesz testów wydajnościowych?

Szacuje strata 4.4 miliarda dolarów przychodów jest rejestrowane co roku ze względu na słabą wydajność sieci.

W dzisiejszej epoce Web 2.0 użytkownicy klikają, jeśli strona internetowa nie odpowiada w ciągu 8 sekund. Wyobraź sobie, że czekasz 5 sekund, szukając w Google lub wysyłając prośbę o dodanie do znajomych na Facebooku. Skutki przestoju wydajności są często bardziej niszczycielskie, niż kiedykolwiek sobie wyobrażaliśmy. Mamy przykłady, takie jak te, które niedawno dotknęły Bank of America Online Banking, Amazon Usługi sieciowe, Intuit lub Blackberry.

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

Szacuje się, że zaledwie 5-minutowa przerwa w działaniu Google.com (19-13-545,000) będzie kosztować giganta wyszukiwania aż XNUMX XNUMX dolarów.

Szacuje się, że z powodu niedawnego kryzysu firmy traciły sprzedaż wartą 1100 dolarów na sekundę Amazon Awaria usług internetowych.

Gdy organizacja wdraża system oprogramowania, może napotkać wiele scenariuszy, które mogą skutkować opóźnieniem wydajności. Istnieje wiele czynników powodujących spowolnienie wydajności, kilka przykładów może obejmować:

• Zwiększona ilość rekordów znajdujących się w bazie
• Zwiększona liczba jednoczesnych żądań kierowanych do systemu
• większa liczba użytkowników korzystających jednocześnie z systemu w porównaniu do przeszłości

Co to jest LoadRunner Architektura?

Ogólnie rzecz biorąc, architektura HP LoadRunner jest złożona, ale łatwa do zrozumienia.

Załóżmy, że zostałeś przydzielony do sprawdzania wydajności Amazon.com dla 5000 użytkowników

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

VUGen

VUGen lub użytkownik wirtualny Generator to IDE (Integrated Development Environment) lub bogaty edytor kodowania. VUGen służy do replikowania zachowania systemu pod obciążeniem (SUL). VUGen zapewnia funkcję „nagrywania”, która rejestruje komunikację do i od klienta i serwera w formie zakodowanego skryptu – zwanego także skryptem VUser.

Biorąc pod uwagę powyższy przykład, VUGen może rejestrować i symulować następujące procesy biznesowe:

1. Surfowanie po stronie produktów Amazon.com
2. Wymeldować Się
3. Przetwarzanie płatności
4. Sprawdzanie strony Moje konto

kontroler

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

• Ilu użytkowników VUser należy symulować dla każdego procesu biznesowego lub grupy VUser
• Zachowanie użytkowników wirtualnych (zwiększanie, zmniejszanie, jednoczesność lub współbieżność itp.)
• Charakter scenariusza obciążenia, np. Real Life lub Zorientowany na cel lub weryfikacja SLA
• Jakich wtryskiwaczy użyć, ilu użytkowników V na każdy wtryskiwacz
• Zestawiaj wyniki okresowo
• Fałszowanie adresów IP
• Zgłaszanie błędów
• Raportowanie transakcji itp.

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

1) 3500 użytkowników Surfowanie po stronie produktów Amazon.com

2) 750 użytkowników jest zarejestrowanych Wymeldować Się

3) 500 użytkowników przeprowadzanie przetwarzania płatności

4) 250 użytkowników Sprawdzanie strony Moje konto TYLKO po przetworzeniu płatności przez 500 użytkowników

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

1. Inicjuj 5 użytkowników VU co 2 sekundy, aż do obciążenia 3500 użytkowników V (surfowanie Amazon strona produktu) została osiągnięta.
2. Powtarzaj przez 30 minut
3. Zawieś iterację dla 25 użytkowników V
4. Uruchom ponownie 20 VUSerów
5. Inicjuj 2 użytkowników (w kasie, przetwarzaniu płatności, stronie Moje konta) co sekundę.
6. Na maszynie A zostanie wygenerowanych 2500 użytkowników V
7. Na Maszynie B zostanie wygenerowanych 2500 użytkowników V

Agenci Maszyna/Ładunek Generators/Wtryskiwacze

Kontroler HP LoadRunner jest odpowiedzialny za symulowanie tysięcy użytkowników V – ci VUżytkownicy zużywają zasoby sprzętowe, na przykład procesor i pamięć – w ten sposób ograniczając maszynę, która ich symuluje. Poza tym Kontroler symuluje tych użytkowników V z tej samej maszyny (na której znajduje się Kontroler), dlatego wyniki mogą nie być dokładne. Aby rozwiązać ten problem, wszyscy użytkownicy V są rozproszeni na różnych komputerach, tzw Załadować Generators lub Załaduj wtryskiwacze.

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ć wymagana pewna liczba Load Injectorów. Na przykład użytkownicy VUsers dla skryptu HTTP będą potrzebowali 2-4MB na VUser do symulacji, zatem do symulacji obciążenia 4 4 VUser potrzebne będą 10,000 maszyny z XNUMX GB RAM każda.

Biorąc analogię z naszego Amazon Przykład, wyjściem tego komponentu będzie

Analiza

Po wykonaniu scenariuszy ładowania rola „Analiza” pojawiają się komponenty LoadRunner.

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

Wszystkie błędy i wyjątki są rejestrowane w pliku a Microsoft dostęp do bazy danych, o nazwie, wyjście.mdb. Komponent „Analiza” odczytuje plik bazy danych w celu przeprowadzenia różnych typów analiz i generowania wykresów.

Wykresy te pokazują różne trendy, co pozwala zrozumieć przyczyny błędów i awarii pod obciążeniem; pomagają w ten sposób ustalić, czy wymagana jest optymalizacja w SUL, serwerze (np. JBoss, Oracle) lub infrastrukturę.

Poniżej znajduje się przykład, w którym przepustowość może powodować wąskie gardło. Załóżmy, że serwer WWW ma przepustowość 1 GB/s, podczas gdy ruch danych przekracza tę pojemność, powodując cierpienie kolejnych użytkowników. Aby określić, czy system zaspokaja 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.

Jak przeprowadzić testy wydajności

Plan działania w zakresie testów wydajnościowych można ogólnie podzielić na 5 kroków:

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

Teraz, gdy masz już zainstalowany LoadRunner, przyjrzyjmy się kolejno krokom składającym się na ten proces.

Etapy procesu testowania wydajności

Krok 1) Planowanie testu obciążeniowego

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

Zbierz swój zespół

Rozpoczynając pracę z testowaniem 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 osobą odpowiedzialną za eskalację.

Ekspert funkcyjny/Analityk biznesowy:

Zapewnia analizę użytkowania SUL i zapewnia wiedzę specjalistyczną na temat funkcjonalności biznesowej strony internetowej/SUL

Ekspert ds. testów wydajnościowych:

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

Konfiguracja Architakt:

Zawiera plan SUL

Twórca stron internetowych i MŚP:

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

Administrator systemu:

• Utrzymuje zaangażowane serwery przez cały projekt testowy

Omów zastosowania i procesy biznesowe, których to dotyczy:

Udany Testowanie obciążenia wymaga zaplanowania przeprowadzenia określonego procesu biznesowego. Proces biznesowy składa się z jasno określonych kroków zgodnych z pożądanymi transakcjami biznesowymi – tak aby osiągnąć cele związane z testowaniem obciążenia.

Można przygotować metrykę wymagań, aby uzyskać obciążenie systemu przez użytkowników. Poniżej przykładowy system obecności w firmie:

W powyższym przykładzie liczby dotyczą ilości użytkowników podłączonych do aplikacji (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 skrajnych prawych kolumnach.

Podobnie możemy wywnioskować całkowitą liczbę użytkowników podłączonych do aplikacji (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

Jak wspomniano wcześniej, na statystyki i obserwacje wyciągnięte z testów wydajnościowych duży wpływ ma wiele czynników. Przygotowanie danych testowych do testów wydajnościowych ma kluczowe znaczenie. Czasami określony proces biznesowy zużywa zestaw danych i generuje 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 tej sytuacji Użytkownik B musi mieć w systemie „utworzonych” 200 umów. Poza tym użytkownik C potrzebuje 150 umów jako „zatwierdzonych”, aby symulować obciążenie 150 użytkowników.

Oznacza to pośrednio, ż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 będą służyć jako dane testowe dla użytkownika B.

Monitory zarysowe

Przeanalizuj każdy czynnik, który może mieć wpływ na wydajność systemu. Na przykład zmniejszenie ilości sprzętu będzie miało potencjalny wpływ na wydajność SUL (System Under Load).

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

• Procesor (dla serwera WWW, serwera aplikacji, serwera bazy danych i wstrzykiwaczy)
• RAM (dla serwera WWW, serwera aplikacji, serwera bazy danych i wstrzykiwaczy)
• Serwer WWW/aplikacji (na przykład IIS, JBoss, Jaguar Server, Tomcat itp.)
• Serwer DB (rozmiar PGA i SGA w przypadku Oracle i serwer MSSQL, SP itp.)
• Wykorzystanie przepustowości sieci
• Wewnętrzna i zewnętrzna karta sieciowa w przypadku klastrowania
• Moduł równoważenia obciążenia (i równomierne rozłożenie obciążenia na wszystkie węzły klastra)
• Strumień danych (oblicz, ile danych jest przesyłanych do i od klienta i serwera, a następnie oblicz, czy pojemność karty sieciowej jest wystarczająca do symulacji X liczby użytkowników)

Krok 2) Utwórz skrypty VUGen

Następnym krokiem po zaplanowaniu jest tworzenie Skrypty VUser.

Krok 3) Tworzenie scenariusza

Następnym krokiem jest utworzenie scenariusza obciążenia

Krok 4) Wykonanie scenariusza

Wykonywanie scenariuszy polega na emulowaniu obciążenia serwera przez użytkowników poprzez polecenie wielu użytkownikom wirtualnym jednoczesnego wykonywania zadań.

Możesz ustawić poziom obciążenia, zwiększając i zmniejszając liczbę VUżytkowników wykonujących zadania w tym samym czasie.

Wykonanie to może spowodować, że serwer będzie obciążony i będzie zachowywał się nieprawidłowo. Taki jest właśnie cel testów wydajności. Uzyskane wyniki są następnie wykorzystywane do szczegółowej analizy i identyfikacji pierwotnej przyczyny.

Krok 5) Analiza wyników (po której następuje udoskonalanie systemu)

Podczas wykonywania scenariusza LoadRunner rejestruje wydajność aplikacji przy różnych obciążeniach. Statystyki pobrane z wykonania testu są zapisywane, a analiza szczegółów jest wykonywana. Narzędzie „HP Analysis” generuje różne wykresy, które pomagają w identyfikacji przyczyn źródłowych opóźnienia wydajności systemu, a także awarii systemu.

Niektóre z uzyskanych wykresów obejmują:

• Czas na pierwszy bufor
• Czas reakcji transakcji
• Średni czas reakcji na transakcję
• Trafienia na sekundę
• Windows Zasoby
• Statystyki błędów
• Podsumowanie transakcji

FAQ