Czy uzasadnione jest brak kryteriów pozytywnych / negatywnych dla testu warunków skrajnych?

Dla jasności napisany przeze mnie test warunków skrajnych zwiększa obciążenie systemu, aż osiągnie punkt krytyczny. Teoretycznie działa w nieskończoność, ale ponieważ zasoby systemowe są skończone, oczekuje się, że po pewnym czasie ulegnie awarii. Mam oczekiwane obciążenie systemu, ale jest to testowane osobno w teście obciążenia . Celem tego testu warunków skrajnych jest ustalenie, ile obciążenia mogę nałożyć na system, zanim będę musiał wdrożyć skalowanie.

Jestem w trakcie pisania testu warunków skrajnych dla systemu i zastanawiam się, czy sensowne jest posiadanie kryteriów pozytywnych / negatywnych. Z natury testu obciążenie stale rośnie, dopóki nie osiągnie punktu zerwania (tj. Nie powiedzie się ). Oczywiście nie wiem, jaki jest ten punkt krytyczny, a zatem nie oczekuję obciążenia, które system może wytrzymać (teoretycznie zresztą).

Teraz mam inne testy wydajności przetestować system pod oczekiwanego obciążenia itd., Które można łatwo ustawić Pass / Fail kryteria, a ja mogła wykorzystać te kryteria jako podstawa do mojego testu wysiłkowego. Innymi słowy, mógłbym ustalić minimalny poziom odniesienia dla mojego testu warunków skrajnych, ale nie jestem pewien, czy jest to właściwe postępowanie (czy to „powielanie” mojego drugiego testu?).

Mam nadzieję, że ktoś z większym doświadczeniem w testowaniu wydajności może mi tutaj pomóc. Jakie kryteria pozytywnego / negatywnego zastosowały inne podczas testów warunków skrajnych (jeśli istnieją)?

testing stress-testing

— Alex
źródło

Jeśli nie masz pozytywnego / negatywnego wyniku, dlaczego przeprowadzasz test?

— RemcoGerlich,

@RemcoGerlich Więc mogę poznać granice systemu? Pomoże to w planowaniu zdolności produkcyjnych itp.

— Alex

Myślę, że to przy planowaniu wydajności decydujesz o minimalnym obciążeniu, jakie system musi obsłużyć (więc wtedy masz kryterium zaliczenia).

— RemcoGerlich,

@RemcoGerlich Może mam pomieszane warunki, ale zasadniczo mam oczekiwane obciążenie (które jest testowane osobno), ale używam tego testu warunków skrajnych, aby ustalić, w którym momencie (tj. Liczbie użytkowników) będę musiał skalować infrastrukturę. Jest to osobny test, ponieważ zmiany w systemie mogą zmienić obciążenie, które system może obsłużyć, co nie byłoby widoczne w teście obciążenia.

— Alex

@Alex, nie, nie masz problemów z warunkami. Dokładnie opisujesz test warunków skrajnych. Problem polega na tym, że nie ma pozytywnego / negatywnego wyniku testu warunków skrajnych, więc nie można go łatwo uruchomić przy użyciu narzędzi do „testowania jednostkowego”.

— David Arno,

Odpowiedzi:

W teście warunków skrajnych twoim zadaniem nie jest zdefiniowanie stresu, jaki powinien być w stanie przyjąć badany. Służy do pomiaru stresu, jaki musi podjąć, zanim zawiedzie.

Za pomocą kryteriów wydajności można określić, czym jest awaria naprężenia. Ale wynik testu warunków skrajnych nie jest pozytywny / negatywny. To „nie powiodło się po 90 godzinach przy 100% wykorzystaniu przy 50% obniżonej wentylacji”.

— candied_orange
źródło

jedno pytanie. Czy test warunków skrajnych powinien spowodować awarię systemu? Innymi słowy. Czy katastrofa jest tym, co uważamy za „awarię”?

— Laiv

@laiv Test warunków skrajnych powinien powodować stres. I pokaż, jak pacjent reaguje na stres. Jeśli powoduje awarię systemu, którą należy udokumentować. Testy warunków skrajnych powinny powodować awarie i pokazywać, jakie są ich przyczyny. Awaria systemu jest awarią, zakładając, że awaria systemu nie spełnia wymagań wydajności. Zwykle tak robią.

— candied_orange

Zależy to od wymagań, jeśli twoje wymagania określają, że oczekiwany wynik dla wydajności aplikacji to X, a tak naprawdę masz Y, więc jest to błąd.
Jeśli nie masz zdefiniowanych wymagań, możesz obciążyć system i zebrać dane graniczne, a następnie ustalić i udokumentować te ograniczenia.

— Thiago F. Peçanha
źródło

Możesz łatwo zaktualizować swój podstawowy test warunków skrajnych, aby obsługiwał również weryfikację pozytywnej / negatywnej kontroli jakości, coś w rodzaju „w stanie osiągnąć / utrzymać obciążenie X bez zerwania”. Idealnie, gdy X jest konfigurowalny (na przykład dla różnych gałęzi wydania).

Wynik byłby, failgdyby system zepsuł się, zanim obciążenie osiągnie X i passjeśli się nie zepsuje . Musisz po prostu przestać zwiększać obciążenie, gdy osiągnie wartość X w scenariuszu „podtrzymania”.

IMHO taki automatyczny test może być bardzo przydatny w kontekście CI / CD, szczególnie w oddziałach produkcyjnych.

— Dan Cornilescu
źródło