Co to jest test objętościowy? Ucz się na przykładach
⚡ Inteligentne podsumowanie
Testowanie objętościowe polega na poddaniu aplikacji działaniu bardzo dużej ilości danych, aby sprawdzić, jak pamięć masowa, zapytania i czasy odpowiedzi zachowują się wraz ze wzrostem bazy danych. Nazywa się to również testowaniem rozpływowym i skaluje dane, a nie liczbę użytkowników.

Co to jest test objętościowy?
Testowanie głośności to rodzaj testowania oprogramowania, podczas którego oprogramowanie poddawane jest działaniu ogromnej ilości danych. Nazywa się to również tzw testy powodziowe. Testowanie woluminów ma na celu analizę wydajności systemu poprzez zwiększenie objętości danych w bazie danych.
Za pomocą testów objętościowych można zbadać wpływ dużej ilości danych na czas reakcji i zachowanie systemu.
Na przykład serwis strumieniowego przesyłania muzyki można przetestować przy użyciu katalogu zawierającego 50 milionów tracks oraz tabelę historii odsłuchiwania zawierającą miliardy wierszy, aby sprawdzić, czy zapytania wyszukiwania i rekomendacji nadal zwracają wyniki w akceptowalnym czasie.
Zwróć uwagę na różnicę: badanie objętości zwiększa ilość danych system się utrzymuje. Zwiększanie liczba jednoczesnych użytkowników jest testowanie obciążeniowe, które jest innym testem i ma inny cel.
Korzyści z testów objętościowych
- Wczesne zidentyfikowanie problemów z wydajnością pozwala uniknąć znacznie wyższych kosztów ich rozwiązania w trakcie produkcji
- Pomaga w szybszym uruchomieniu planów skalowalności
- Wczesna identyfikacja wąskich gardeł
- Zapewnia, że Twój system jest teraz zdolny do rzeczywistego użycia
Dlaczego należy wykonywać testy objętościowe?
Celem przeprowadzenia badania objętości jest
- Sprawdź wydajność systemu przy rosnącej ilości danych w bazie danych
- Określ problemy, które mogą pojawić się, gdy zbiór danych stanie się duży
- Aby określić punkt, w którym stabilność systemu ulega pogorszeniu
- Testowanie objętości pomoże określić wydajność systemu lub aplikacji – wolumen normalny i duży
Jak wykonać testowanie objętości
Podczas testowania objętościowego należy sprawdzić następujące rzeczy
- Przetestuj, aby sprawdzić, czy nastąpiła utrata danych
- Sprawdź czas reakcji systemu
- Sprawdź, czy dane są przechowywane poprawnie, czy nie
- Sprawdź, czy dane nie zostały nadpisane bez żadnego powiadomienia
- Sprawdź, czy ostrzeżenia i komunikaty o błędach faktycznie pojawiają się po osiągnięciu limitu głośności
- Sprawdź, czy duża ilość danych wpływa na szybkość przetwarzania
- Sprawdź, czy system ma zasoby pamięci i magazynu wymagane przez wolumin
- Potwierdź, że test głośności obejmuje cały system, a nie pojedynczy komponent
- Czy istnieje ryzyko, jeśli ilość danych jest większa niż określona?
- Sprawdź, czy istnieje gwarancja, że ilość danych nie przekroczy określonego maksimum
Najlepsze praktyki dotyczące testowania dużej objętości
Kilka z poniższych praktyk jest wspólnych z testowaniem obciążeniowym, ponieważ zazwyczaj oba są uruchamiane w tym samym środowisku. Te specyficzne dla woluminu dotyczą samego zestawu danych:
- Zatrzymaj wszystkie serwery i sprawdź wszystkie dzienniki
- Przed testem obciążenia ręcznie wykonaj scenariusz aplikacji
- W przypadku najbardziej przydatnych wyników liczba użytkowników jest zdumiewająca
- Aby pokonać ograniczenia licencyjne, zrównoważ czas potrzebny na przemyślenie
- Bądź ostrożny z nową wersją
- Po ustaleniu poziomu bazowego przeanalizuj przypadek użycia wymagający ulepszeń
- Powtarzanie poszczególnych części testów objętościowych staje się nieuniknione w przypadku wąskiego gardła wydajności
Testowanie objętościowe a testowanie obciążeniowe
| Testowanie głośności | Testowanie obciążenia |
|---|---|
|
|
|
|
Wyzwania w testowaniu objętościowym
- Fragmentacja pamięci trudna do wygenerowania
- Dynamiczne generowanie kluczy
- Relacyjny Integrity wygenerowanych danych
Porównanie tego testu z innymi testami wydajności
Testowanie wydajności to rodzina testów, które różnią się kształtem przyłożonego obciążenia, dlatego tak łatwo je pomylić.
| Rodzaj testu | Co jest zwiększone | Pytanie, na które odpowiada |
|---|---|---|
| Testowanie obciążenia | Jednoczesnych użytkowników do oczekiwanego szczytu | Czy spełnia cele przy normalnym, szczytowym natężeniu ruchu? |
| Testowanie głośności | Dane przechowywane w bazie danych | Czy system radzi sobie ze wzrostem zbioru danych? |
| Test naprężeń | Obciążenie przekraczające pojemność, aż do awarii | Gdzie się psuje i jak? |
| Testowanie Spike'a | Załaduj natychmiast i niezwykle | Czy przeżywa i otrząsa się z szoku? |
| Testy wytrzymałościowe | Czas trwania przy normalnym obciążeniu | Czy wydajność pogarsza się z czasem? |
| Testowanie zanurzeniowe | Czas trwania, oglądanie zasobów | Czy występują wycieki pamięci lub uchwytów? |
| Testy stabilności | Różne warunki | Czy system pozostaje niezawodny w zmieniających się warunkach? |
Najważniejsze tutaj jest rozróżnienie: testy objętościowe skalują dane, testy obciążenia skalują użytkowników. Raport, który trwa dwie sekundy dla dziesięciu tysięcy wierszy i dwie minuty dla dziesięciu milionów wierszy, ma problem z objętością, a nie obciążeniem, i żadna dodatkowa pojemność serwera nie rozwiąże tego problemu.
Jak generować dane testowe do testowania objętości
W sekcji poświęconej wyzwaniom zaznaczono, że generowanie realistycznych danych jest najtrudniejszą częścią testowania wolumenu. W praktyce stosuje się cztery podejścia, z których każde wiąże się z pewnym kompromisem.
| Podejście | Realizm | Główna wada |
|---|---|---|
| Kopia danych produkcyjnych | Najwyższa | Narażenie na naruszenie prywatności i zgodności |
| Zamaskowana kopia produkcyjna | Wysoki | Maskowanie może naruszyć integralność referencyjną |
| Generacja syntetyczna | Średni | Dystrybucje mogą nie odpowiadać rzeczywistości |
| Odtworzony ruch produkcyjny | Wysoki | Wymaga infrastruktury przechwytującej |
Bez względu na to, którą drogę wybierzesz, muszą zostać spełnione trzy właściwości, inaczej test nie wykaże żadnych przydatnych wyników.
- Integralność referencyjna. Każdy klucz obcy musi zostać rozwiązany. Milion osieroconych wierszy obciąża mechanizm pamięci masowej, ale nigdy ścieżki łączenia, z których faktycznie korzysta aplikacja.
- Realistyczna kardynalność. Jeśli tabela produkcyjna zawiera dziesięć milionów wierszy dla dwustu klientów, wygenerowanie dziesięciu milionów wierszy dla dziesięciu milionów klientów spowoduje powstanie zupełnie różnych planów zapytań.
- Realistyczna dystrybucja. Rzeczywiste dane są przekłamane. Jednorodne, losowe dane ukrywają gorące partycje i konflikty indeksów, które powodują incydenty produkcyjne.
Praktyczne ostrzeżenie dotyczące prywatności. Kopiowanie danych produkcyjnych do środowiska testowego jest najczęstszą przyczyną wycieku danych w testach. Zamaskuj pola danych osobowych przed opuszczeniem kopii produkcyjnej, a nie później.
