Testy obciążeniowe w oprogramowaniu: znaczenie i przykłady
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Testy obciążeniowe (Soak Testing) polegają na długotrwałym, realistycznym obciążeniu aplikacji, aby wykryć problemy, które pojawiają się dopiero po pewnym czasie. Wycieki pamięci, wyczerpanie połączenia i spadek wydajności to defekty, które ma on wykrywać.
Czym jest testowanie zanurzeniowe?
Testowanie namaczania to rodzaj testów niefunkcjonalnych, które służą do pomiaru wydajności aplikacji pod ogromnym obciążeniem przez dłuższy okres czasu. Celem testów Soak jest upewnienie się, czy aplikacja wytrzymuje duże natężenie użytkowania oraz sprawdzenie, co stanie się poza oczekiwaniami projektowymi.
Poniższy obraz przedstawia cykl testowy pokazujący, na jakim etapie znajduje się test namaczania (Rodzaj testu wydajności) jest wykonywana w aplikacji.
W tego typu testach zasadniczo monitorowane jest wykorzystanie pamięci przez aplikację w systemie. Testuje się na poziomie systemu, aby sprawdzić, czy system wytrzyma bardzo duże natężenie użytkowania i zobaczyć, co stanie się poza jego oczekiwaniami projektowymi.
Dlaczego warto testować namoczenie?
System może zachowywać się normalnie, gdy jest używany przez 2 godziny, ale gdy ten sam system jest używany nieprzerwanie przez 10 godzin lub dłużej, może ulec awarii lub zachowywać się nienormalnie/losowo/może ulec awarii. Aby przewidzieć taką awarię, przeprowadza się testowanie zanurzeniowe.
Kiedy wykonać test namaczania?
Testy zanurzeniowe należy przeprowadzać w następujących scenariuszach: –
- Zanim build zostanie wdrożony u klienta, tj. przed wydaniem jakiejkolwiek aplikacji na określonej platformie, musi przejść pomyślnie serię testów obciążeniowych przy wysokim lub równoważnym poziomie ruchu. Następnie przeprowadza się badanie nasiąkania. Pomaga nam określić, jak uruchomić dowolną konkretną aplikację przez dłuższy czas. Jeśli w okresie, np. w trybie Soak, zostaną wykryte problemy takie jak wycieki/uszkodzenia pamięci, należy to natychmiast zgłosić.
- Najlepszy czas na testowanie namaczania to weekendy, ponieważ aplikacja musi działać tak długo, jak przez dzień lub noc. Zależy to całkowicie od ograniczeń sytuacji testowej. Testy namaczania są jednym z najważniejszych wymogów zgodności, których każda firma musi bardzo rygorystycznie przestrzegać.
Strategia testowania namaczania
Testowanie długotrwałej sesji to strategia polegająca na tym, że system jest obciążony przez dłuższy czas.
Prostym przykładem jest sytuacja, gdy użytkownik pozostaje zalogowany do systemu przez wiele godzin, wykonując szereg transakcji biznesowych. W ten sposób powstaje wiele danych. Może wystąpić duże obciążenie na serwerze systemu/bazy danych, co może skutkować zatrzymaniem/awarią systemu/serwera bazy danych.
W ramach testu namaczania przy długiej sesji, czynności wielodniowe (powiedzmy 30 dni) są wykonywane w ograniczonych ramach czasowych (powiedzmy 2 dni). Liczba transakcji w tym ograniczonym przedziale czasowym powinna odpowiadać lub przewyższać liczbę transakcji obejmujących wiele dni. Należy skupić się na liczbie przetworzonych transakcji. Najważniejszą częścią testu namaczania jest sprawdzenie dostępnej pamięci w procesorze i ilości pamięci, która będzie używana. Musimy zarejestrować użycie pamięci na początku i na końcu testu namaczania. W razie potrzeby należy uwzględnić wykorzystanie pamięci przez obiekty takie jak Java Maszyny wirtualne są również ważne i należy je monitorować.
Poniżej znajduje się kilka dodatkowych kontroli, które musi wykonać każdy użytkownik/tester przed rozpoczęciem testowania zanurzenia:
a) Monitoruj zużycie zasobów bazy danych.
b) Monitoruj zużycie zasobów serwera (bez wykorzystania procesora).
c) Test namaczania powinien być uruchamiany przy realistycznej współbieżności użytkowników.
Charakterystyka badania nasiąkania
Standardowa metoda testowania zanurzeniowego powinna mieć następujące cechy: –
- Czas trwania większości testów namaczania jest często określany na podstawie dostępnego czasu.
- Każda aplikacja musi działać bez przerwy, jeśli wymaga dłuższego czasu.
- Powinien obejmować wszystkie scenariusze uzgodnione przez zainteresowane strony.
- Przeważnie każdy system ma regularne okno konserwacji, a czas pomiędzy takimi oknami jest kluczowym czynnikiem przy określaniu zakresu testu namaczania.
Przykłady testów zanurzeniowych
- W przypadku domeny bankowej, gdzie jest duża ilość danych od sprzedawców, tester będzie obciążał system nieprzerwanie od 70 do 150 godzin, aby sprawdzić, jak aplikacja zachowuje się w tym okresie ładowania.
- Załóżmy, że jest 33,000 60 logowań, które muszą zostać przepuszczone przez system, co stanowi siedem i pół dnia aktywności. W tym przypadku 70-6 godzin Soak Test można rozpocząć w piątek wieczorem około godziny XNUMX:XNUMX, a zakończyć go można Monday rano o 6 rano. Tylko dzięki takiemu testowi możliwe będzie zaobserwowanie jakiegokolwiek pogorszenia wydajności w kontrolowanych warunkach.
- W przypadku gier wideo, Mobile aplikacje itp. wymagają pozostawienia gry lub aplikacji w stanie uruchomionym na dłuższy czas, w różnych trybach działania - takich jak bezczynność, wstrzymanie na ekranie tytułowym itd., aby sprawdzić, czy aplikacja jest w stanie obsłużyć oczekiwane ciągłe obciążenie.
Typowe problemy obserwowane podczas testów namaczania
- Alokacja pamięci (wycieki pamięci, które ostatecznie skutkują kryzysem pamięci lub błędami zaokrąglania, które ujawniają się dopiero z czasem).
- Wykorzystanie zasobów bazy danych (niepowodzenie zamknięcia kursorów bazy danych w pewnych warunkach, co ostatecznie doprowadziłoby do zatrzymania całego systemu).
- Może to również prowadzić do pogorszenia wydajności, tj. do zapewnienia, że czas reakcji po długim okresie ciągłej aktywności będzie tak dobry, jak na początku testu.
- Niezamknięcie połączeń między warstwami systemu wielowarstwowego w pewnych okolicznościach może spowodować zablokowanie niektórych lub wszystkich modułów systemu.
- Stopniowa degradacja czasu odpowiedzi niektórych funkcji, gdy wewnętrzne struktury danych stają się mniej wydajne podczas długiego testu.
Jak ten test pasuje do rodziny testów wydajnościowych
Testowanie wydajności to termin ogólny. Poniższe warianty różnią się jedynie kształtem przyłożonego obciążenia i czasem jego utrzymywania, dlatego tak często są ze sobą mylone.
| Rodzaj testu | Wzór obciążenia | Pytanie, na które odpowiada |
|---|---|---|
| Testowanie obciążenia | Oczekiwane obciążenie szczytowe, krótki czas trwania | Czy system spełnia swoje cele przy normalnym, szczytowym natężeniu ruchu? |
| Test naprężeń | Zwiększony ponad pojemność aż do awarii | Gdzie następuje przerwa i czy awaria przebiega gładko? |
| Testowanie Spike'a | Nagły, ekstremalny wzrost, a następnie wycofanie | Czy przeżywa i dochodzi do siebie po szoku komunikacyjnym? |
| Testy wytrzymałościowe | Normalne obciążenie utrzymywane przez wiele godzin | Czy wydajność pogarsza się z czasem? |
| Testowanie zanurzeniowe | Długotrwałe obciążenie przez dłuższy okres | Czy występują wycieki pamięci lub wyczerpanie zasobów? |
| Testy stabilności | Zmienne obciążenie w różnych warunkach | Czy system pozostaje niezawodny w zmieniających się warunkach? |
| Testowanie głośności | Zwykli użytkownicy, bardzo duża ilość danych | Czy system radzi sobie ze wzrostem bazy danych? |
Test wytrzymałościowy i test zanurzeniowy są często traktowane jako synonimy. W powszechnym użyciu są to: oba utrzymują stałe obciążenie przez długi czas. Tam, gdzie zespoły je rozróżniają, testy wytrzymałościowe koncentrują się na tym, czy czasy reakcji rosną, podczas gdy testy nasączenia koncentrują się na zużyciu zasobów, takich jak pamięć, uchwyty plików i pule połączeń. Uruchomienie takiego testu zazwyczaj dostarcza dowodów na oba te zjawiska.
Kluczowe wskaźniki do uchwycenia podczas testu
Wydajność testu jest tak dobra, jak to, co rejestrujesz podczas jego wykonywania. Zarejestruj te sześć parametrów po stronie serwera i klienta, a następnie porównaj je z danymi bazowymi, a nie z przeczuciem.
| metryczny | Co ci to mówi | Znak ostrzegawczy |
|---|---|---|
| Średni czas odpowiedzi | Typowe doświadczenie użytkownika | Jakiekolwiek przesunięcie w górę w poprzek biegu |
| 95. percentyl czasu reakcji | Doświadczenia najwolniejszych użytkowników | Znacznie powyżej średniej, co oznacza niespójność |
| Wydajność | Liczba żądań obsłużonych na sekundę | Spadek przy stałym obciążeniu |
| Poziom błędu | Udział nieudanych lub przekroczonych limitów czasu żądań | Każde przekroczenie ustalonego progu |
| Wykorzystanie procesora i pamięci | Zapas zasobów serwera | Pamięć, która pnie się w górę i nigdy nie powraca |
| Połączenia i wątki bazy danych | Wyczerpanie basenu | Liczba, która stale rośnie bez wydawania |
Odczytaj średnią i percentyl jednocześnie. Średnia 800 ms przy 95. percentylu 900 ms opisuje spójny system. Ta sama średnia przy 95. percentylu 9 sekund oznacza, że jeden na dwudziestu użytkowników ma problemy, a średnia to ukrywa.
Zwróć uwagę na kształt, nie tylko na wartość. W przypadku każdego długotrwałego testu płaska linia zasobów oznacza zaliczenie testu, a rosnąca – przeciek, nawet jeśli w chwili zakończenia testu liczba bezwzględna nadal mieści się w limicie.
