Czym jest testowanie destrukcyjne oprogramowania?
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Testowanie destrukcyjne polega na celowym testowaniu oprogramowania aż do momentu jego awarii, ujawniając konkretne punkty, w których odporność oprogramowania zanika w wyniku niewłaściwego użytkowania, błędnych danych wejściowych i nieprzewidywalnego zachowania, czego zwykłe kontrole funkcjonalne nigdy nie potrafią wykryć.
Co to są badania niszczące?
Testowanie niszczące to metoda testowania oprogramowania służąca do znajdowania punktów awarii w programie. W tej technice aplikacja jest celowo poddawana awarii, aby można było sprawdzić jej odporność i zidentyfikować punkty awarii. W przeciwieństwie do metod testowania, które weryfikują, co aplikacja powinna robić, testowanie destrukcyjne bada nieprzewidywalne zachowania użytkowników w aplikacji.
Znajomość pierwotnych wymagań nie jest konieczna do przeprowadzenia testów niszczących. Pewna wiedza jest jednak pomocna w rozwojuping dobra strategia testowania.
Poniższa ilustracja obrazuje tę ideę — tester pracuje wbrew produktowi, a nie z nim.
Dlaczego przeprowadza się badania niszczące?
- Pomaga zrozumieć przewidywalne zachowanie oprogramowania w przypadku jego niewłaściwego użycia.
- Pomaga sprawdzić solidność oprogramowania.
- Ujawnia rzadkie defekty, na które zwykli użytkownicy nigdy nie zwracają uwagi, ale które ujawniają się na późniejszym etapie produkcji.
Badania niszczące a badania nieniszczące
Te dwa podejścia uzupełniają się, a nie rywalizują. Badania nieniszczące — zwane również testowaniem pozytywnym lub testowaniem ścieżki szczęścia — poprawnie współdziała z oprogramowaniem i pozostawia kompilację nienaruszoną. Testowanie destrukcyjne działa odwrotnie: dostarcza nieprawidłowe dane i błędne sekwencje, aż coś się zepsuje.
| WYGLĄD | Testowanie niszczące | Badania nieniszczące |
| Intencja | Wymuś niepowodzenie aplikacji | Potwierdź, że aplikacja działa zgodnie ze specyfikacją |
| Użyte dane wejściowe | Nieprawidłowy, wadliwy, poza zakresem, poza kolejnością | Prawidłowe dane w oczekiwanym zakresie |
| Pytanie odpowiedziało | Gdzie i jak się psuje? | Czy robi to co powinien? |
| Wymagania dotyczące wiedzy | Opcjonalnie | Istotny |
| Typowy koszt | Wyższy — eksploracyjny i otwarty | Niższy — skryptowany i powtarzalny |
| Wynik | Punkty awarii, ograniczenia zasięgu, zachowanie odzyskiwania | Zaliczony lub niezaliczony zgodnie ze specyfikacją |
Co sprawdzasz podczas badań niszczących?
Testowanie destrukcyjne bierze pod uwagę obie strony granicy zachowania:
- Prawidłowe zachowanie oprogramowania
- Nieprawidłowe działanie oprogramowania
- Niewłaściwe użycie
- Niewłaściwe dane wejściowe
- Prawidłowe dane wyjściowe
Podczas całego ćwiczenia muszą być spełnione dwa warunki:
- Oprogramowanie nigdy nie będzie przetwarzać ani akceptować nieprawidłowych danych wejściowych.
- Niezależnie od prawidłowości danych wejściowych, oprogramowanie powinno zawsze generować poprawne dane wyjściowe.
Jak przeprowadzić badania niszczące?
Testowanie destrukcyjne obejmuje wiele czynności, takich jak projektowanie zestawu skryptów testowych, wykonywanie tych skryptów, zgłaszanie błędów, zamykanie błędów i dostarczanie interesariuszom na koniec iteracji metryk dotyczących zaliczenia lub niezaliczenia testu.
Istnieje wiele sposobów na jego uruchomienie. Poniżej kilka przykładów.
- Metoda analizy punktów awarii: Przewodnik po systemie, który ocenia, co może pójść nie tak w różnych punktach. Pomoc od analityk Biznesowy można przyjąć dla tej strategii.
- Recenzja rówieśnicza testera: Weź swój przypadki testowe przeanalizowane lub sprawdzone przez innego testera, który jest mniej zaznajomiony z systemem lub funkcją.
- Przegląd biznesowy przypadków testowych: Użytkownicy końcowi lub eksperci często wymyślają uzasadnione scenariusze, których testerzy nie dostrzegają, ponieważ uwaga testera skupia się na określonych wymaganiach.
- Przeprowadź testy eksploracyjne, korzystając z arkuszy uruchomieniowych: testowanie eksploracyjne Arkusze przebiegu rejestrują wykonane testy, umożliwiają powtarzanie testów i utrzymują kontrolę nad pokryciem testami.
- Użyj innego źródła: poproś kogoś innego o zepsucie oprogramowania i przeanalizowanie znalezionych scenariuszy.
Przykład badań niszczących
Rozważmy ekrany logowania i profilowania w aplikacji bankowej. Niszczące hasło zadziałałoby w takich przypadkach:
- Wklej ciąg 5,000 znaków do pola ograniczonego do 50 znaków i potwierdź, że pole odrzuci ciąg zamiast go bezgłośnie skrócić.
- Wprowadź litery, symbole i wartości ujemne w polu kwoty liczbowej.
- Przerwij oczekiwaną sekwencję — otwórz stronę potwierdzenia płatności bezpośrednio, nie wykonując poprzedniego kroku.
- Naciskaj przycisk „Prześlij” szybko i wielokrotnie, aby sprawdzić, czy nie utworzyły się duplikaty rekordów.
- Rozłącz sieć w trakcie transakcji i sprawdź, czy aplikacja odzyska połączenie bez problemów, czy też pozostawi częściowy zapis.
Każdy przypadek ma określone oczekiwania: jasny komunikat walidacyjny, brak uszkodzeń danych i brak nieobsłużonych wyjątków. Wszystko inne to punkt awarii, który warto zgłosić jako defekt.
Metody badań niszczących
W inżynierii oprogramowania stosuje się następujące metody w celu realizacji celów testowania destrukcyjnego:
- Testowanie alfa/beta
- Testy regresji
- Testowanie interfejsu
- Podział równoważności
- Testowanie pętli
- Testowanie akceptacyjne i tak dalej
Techniki badań niszczących
Poniższe techniki można stosować z pewnymi modyfikacjami:
- Testowanie białoskrzynkowe
- Testy bezpieczeństwa
- Testowanie defektów
- Testowanie dymu, i tak dalej
Sąsiadujące techniki, które warto dodać, gdy celem jest solidność, to: testy negatywne, stress testing, testowanie regeneracji oraz testowanie rozmycia.
Zalety i wady badań niszczących
Warto jasno określić ten kompromis przed zaplanowaniem wprowadzenia tej techniki na rynek.
Zalety
- Revwykrywa punkty krytyczne, których testowanie zgodne ze specyfikacją nigdy nie osiągnie.
- Ustala rzeczywiste granice zasięgu, dzięki czemu można pewnie obsługiwać produkt w ich obrębie.
- Ujawnia rzadkie wady, które ujawniają się w produkcji długo po premierze.
- Sprawdza trwałość, odzyskiwalność i obsługę błędów w przypadku nadużyć.
Wady
- Mają charakter otwarty, więc nie można ich łatwo zagwarantować ani zmierzyć.
- Zajmuje dużo czasu i zależy od doświadczenia i kreatywności testera.
- Odtworzenie wyników może być trudne bez dokładnego rejestrowania wykonanych czynności.
- Źle kontrolowane przebiegi mogą uszkodzić współdzielone dane testowe, dlatego wymagane jest odizolowane środowisko.
