Nieniszczące testowanie oprogramowania (NDT): czym jest i strategia testowania
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Testowanie nieniszczące weryfikuje, czy aplikacja zachowuje się poprawnie po otrzymaniu prawidłowych danych wejściowych, dlatego testerzy nazywają je również testowaniem ścieżki pozytywnej lub testowaniem ścieżki szczęśliwej. Potwierdza ono oczekiwane rezultaty w odniesieniu do udokumentowanych wymagań.
Co to jest nieniszczące testowanie oprogramowania?
Badania nieniszczące to rodzaj testowania oprogramowania, który obejmuje prawidłowe testowanie i interakcję z aplikacją. Innymi słowy, nieniszczące testowanie oprogramowania (NDT) można również nazwać testowaniem pozytywnym lub testowaniem szczęśliwej ścieżki. Daje oczekiwane rezultaty i udowadnia, że aplikacja działa zgodnie z oczekiwaniami.
Nazwa ta pochodzi z inżynierii, gdzie badania nieniszczące polegają na badaniu fizycznego komponentu bez jego uszkodzenia. W oprogramowaniu idea jest taka sama: aplikacja jest testowana zgodnie z przeznaczeniem i przechodzi test bez uszkodzeń.
Przykład: Wprowadzanie prawidłowych danych w module logowania i sprawdzanie, czy moduł akceptuje dane uwierzytelniające i przechodzi do następnej strony.
Zrzut ekranu poniżej przedstawia formularz logowania z prawidłową wartością wpisaną w polu nazwy użytkownika przed wykonaniem testu.
Aby przeprowadzić testy nieniszczące na powyższym przykładzie, wprowadź prawidłową nazwę użytkownika i hasło w formularzu logowania. Ponieważ wprowadzone dane są zgodne z wymaganiami, pożądany wynik jest pozytywny, a tester po prostu potwierdza, że aplikacja przechodzi do następnej strony.
Dlaczego nieniszczące testowanie oprogramowania (NDT)?
Testowanie nieniszczące odpowiada na pierwsze pytanie, jakie zadaje sobie każdy interesariusz w kontekście kompilacji: czy funkcja faktycznie działa tak, jak została poproszona? Oto powody, dla których zespoły przeprowadzają testy nieniszczące.
- Główną zaletą metody NDT jest to, że skutkuje ona poprawą jakości oprogramowania, ponieważ defekty wykryte w głównym przepływie zostają naprawione wcześnie.
- Aby wykazać, że funkcje oprogramowania działają zgodnie ze specyfikacją.
- Aby sprawdzić, czy wymagania dotyczące wydajności zostały spełnione.
- Aby sprawdzić, czy spełnione są wymagania użytkowników końcowych.
- Aby sprawdzić, czy niewielki fragment kodu lub funkcjonalności działa zgodnie z oczekiwaniami i nie zakłóca powiązanej funkcjonalności.
- Aby przedstawić dowody, które można przedstawić na testy akceptacyjne użytkownika zatwierdzenie, w którym klient chce zobaczyć zamierzone zachowanie, a nie tryby awarii.
Kiedy przeprowadzane są badania nieniszczące (NDT)?
Tutaj czas ma większe znaczenie niż w przypadku większości technik, ponieważ szczęśliwa ścieżka otwiera drogę do wszystkiego, co dzieje się dalej.
- Jest to pierwsza forma testowania, jaką tester wykonuje w aplikacji, czyli na początkowym etapie SDLC.
- Badania nieniszczące wykonuje się zwykle wtedy, gdy nie ma wystarczająco dużo czasu na przeprowadzenie pełnego cyklu testowego, ponieważ nadal stanowią one dowód spełnienia kryteriów akceptacji.
- Działa przed scenariuszami negatywnymi i destrukcyjnymi. Jeśli główny przepływ danych zostanie przerwany, testy obsługi błędów zgłoszą szum, a nie rzeczywiste defekty.
- Powtarza się po każdej naprawie usterki, gdzie nakłada się na testy regresji.
Strategia testów w badaniach nieniszczących
Strategia badań nieniszczących jest celowo prosta, a dyscyplina polega na zachowaniu pozytywnego nastawienia, a nie na stosowaniu odpowiednich narzędzi.
- Podejście do badań nieniszczących powinno być pozytywne.
- Celem techniki NDT jest udowodnienie, że aplikacja będzie działać, gdy zostaną podane prawidłowe dane wejściowe.
- Do przeprowadzenia badań nieniszczących nie są potrzebne żadne specjalne wymagania ani odpowiednie warunki.
- Najlepszą praktyką w zakresie badań nieniszczących jest sprawdzenie, czy system wykonuje to, co powinien.
Poniższy diagram podsumowuje, jak strategia ta jest zazwyczaj organizowana w cyklu testowym.
Jak pisać nieniszczące (pozytywne) przypadki testowe
Nieniszczący przypadek testowy jest przydatny tylko wtedy, gdy jego dane wejściowe są udowodnione i poprawne, a oczekiwany wynik wynika z wymagania, a nie z założenia testera. Poniższe kroki prowadzą do takiego właśnie walizka testowa.
Krok 1) Wybierz jedno kryterium akceptacji. Przeczytaj wymaganie i sformułuj je ponownie jako pojedyncze, weryfikowalne stwierdzenie, na przykład „pole nazwy użytkownika akceptuje od sześciu do dwudziestu znaków alfanumerycznych”.
Krok 2) Wybierz prawidłowe dane wejściowe. Wybierz wartości, które mieszczą się w dozwolonym zakresie. Podział równoważności w tym przypadku pomocna jest jedna reprezentatywna wartość na każdą prawidłową partycję.
Krok 3) Przed wykonaniem zapisz oczekiwany wynik. Oczekiwany wynik musi zostać zapisany w specyfikacji. Zapisanie go po uruchomieniu zmienia test w opis tego, co się wydarzyło podczas kompilacji.
Krok 4) Zachowaj kolejność wykonywania kroków. Kolejność powinna odpowiadać temu, jak prawdziwy użytkownik wykonałby zadanie, ponieważ celem tej techniki jest potwierdzenie zamierzonego przebiegu podróży.
Krok 5) Zapisz identyfikator wymagania. TracPrzywrócenie sprawy do jej kryteriów pozwala zespołowi udowodnić bezpieczeństwo podczas przeglądu.
Przykład działania modułu logowania wygląda następująco.
| Pole | Przypadek testu nieniszczącego |
|---|---|
| Wymaganie | Nazwa użytkownika akceptuje 6–20 znaków alfanumerycznych |
| Dane testowe | Nazwa użytkownika guru99tester, prawidłowe pasujące hasło |
| Cel | Otwórz stronę logowania, wprowadź dane uwierzytelniające i wybierz opcję Zaloguj |
| Spodziewany wynik | Poświadczenia zostały zaakceptowane i wyświetlona została strona główna |
| Typ | Pozytywna / szczęśliwa ścieżka |
Zauważ, że nic w tym przypadku nie próbuje przerwać pola. Przypadek, który wprowadza pięć znaków, aby wyświetlić komunikat o błędzie, to wynik negatywny, nie jest nieniszczące.
Przykłady badań nieniszczących
Poniższy przykład pokazuje, jak wyglądają testy nieniszczące w aplikacji wielomodułowej po usunięciu błędu.
- Aplikacja składa się z pięciu modułów: strony logowania, strony głównej, strony szczegółów użytkownika, strony tworzenia nowego użytkownika i strony tworzenia zadań.
- Załóżmy, że na stronie logowania występuje błąd: pole nazwy użytkownika akceptuje mniej niż sześć znaków alfanumerycznych. Jest to sprzeczne z wymaganiami, które stanowią, że nazwa użytkownika nie powinna zawierać mniej niż sześć znaków, więc takie zachowanie jest wadą.
- O błędzie należy powiadomić zespół programistów za pomocą standardowej metody proces zarządzania defektami, błąd został naprawiony, a kompilacja została odesłana do zespołu testującego.
- Zespół testowy sprawdza nie tylko stronę logowania, na której usunięto błąd, ale także testuje pozostałe moduły. Testując wszystkie moduły z prawidłowymi danymi, przeprowadza testy nieniszczące, aby upewnić się, że cała aplikacja nadal działa poprawnie.
Badania nieniszczące a badania niszczące
Obie techniki są często nauczane razem, ponieważ odpowiadają na przeciwstawne pytania dotyczące tej samej konstrukcji. Testowanie niszczące poszukuje punktu, w którym oprogramowanie przestaje działać, podczas gdy testy nieniszczące potwierdzają, że zamierzone zachowanie ma miejsce.
| WYGLĄD | Badania nieniszczące | Niszczące testy |
|---|---|---|
| Zamiar | Prawidłowo współpracuj z aplikacją i weryfikuj pozytywne wyniki | Podaj nietypowe lub nieprawidłowe dane wejściowe, aby znaleźć punkt awarii |
| Dane wejściowe | Prawidłowe dane pobrane z wymogu | Nieprawidłowe, uszkodzone lub niezgodne z kolejnością dane |
| Potrzebne wymagania | Tak — przypadki są pisane na podstawie kryteriów akceptacji | Niekoniecznie; testerzy pracują bez uprzedzeń związanych z historiami użytkownika |
| Co ujawnia | Słabości w funkcjonalności w stosunku do specyfikacji | Słabości w konstrukcji, solidności i odzyskiwalności |
| Powiązane techniki | Testowanie dymu, testy funkcjonalności | Testowanie małp, testowanie eksploracyjne |
Te dwie metody raczej się uzupełniają, a nie są alternatywą. Samo przeprowadzenie testów nieniszczących pozostawia obsługę błędów bez weryfikacji, a samo przeprowadzenie testów niszczących nigdy nie dowodzi, że produkt spełnia swoje zadanie.
Zalety i ograniczenia nieniszczącego testowania oprogramowania
Wiedza o tym, kiedy dana technika przestaje być użyteczna, jest tak samo ważna jak wiedza o tym, co obejmuje.
Zalety
- Szybkie projektowanie i wykonywanie, ponieważ dane testowe pochodzą bezpośrednio ze specyfikacji.
- Nie wymaga żadnego specjalnego środowiska, wstrzykiwania błędów ani uszkodzonego zestawu danych.
- Tworzy dowody, które są bezpośrednio powiązane z wymaganiami, co jest przydatne w audytach i zatwierdzeniach.
- Działa równie dobrze jak testowanie ręczne i zgodnie z planem testowanie automatyzacji, dzięki czemu te same przypadki można ponownie wykorzystać w zestawie regresji.
- Zapewnia wczesny i rzetelny sygnał o stanie konstrukcji na każdym poziomie, od jednostki do testy integracyjne do testowanie systemu.
Ograniczenia
- Pełne przejście nie mówi nic o tym, jak aplikacja zachowuje się w przypadku wprowadzenia nieprawidłowych danych, więc poważne błędy w obsłudze błędów mogą przetrwać to przejście.
- Zakres pokrycia jest ograniczony jakością wymagań. Wszystko, co nie jest określone, nigdy nie jest testowane.
- Może to wywołać fałszywe poczucie pewności, jeśli szczęśliwa ścieżka jest jedyną wypróbowaną przed uwolnieniem.
- Nie mierzy odporności, odzyskiwania ani wydajności w warunkach stresu, do których potrzebne są własne techniki z szerszego zestawu typy testowania oprogramowania.
Traktuj badania nieniszczące jako podstawę, na której opiera się każda inna technika, i planuj je w ramach szerszego planu. cykl życia testowania oprogramowania a nie jako jednorazową aktywność.
