W ścisłym tego słowa znaczeniu nie można wysuwać żadnych roszczeń, dopóki nie zostanie ustalona jakość zestawu testów. Zaliczenie 100% testów nie ma znaczenia, jeśli większość testów jest trywialna lub powtarzalna.
Pytanie brzmi: czy w historii projektu którykolwiek z testów wykrył błędy? Celem testu jest znalezienie błędów. A jeśli nie, to nie zdały egzaminu. Zamiast poprawiać jakość kodu, mogą jedynie dawać fałszywe poczucie bezpieczeństwa.
Aby ulepszyć swoje projekty testowe, możesz użyć (1) technik whitebox, (2) technik blackbox i (3) testów mutacji.
(1) Oto kilka dobrych technik whitebox do zastosowania w projektach testowych. Test białej skrzynki jest konstruowany z uwzględnieniem konkretnego kodu źródłowego. Jednym z ważnych aspektów testów whitebox jest pokrycie kodu:
- Czy wywoływana jest każda funkcja? [Zasięg funkcjonalny]
- Czy każde polecenie jest wykonywane? [Pokrycie wyciągiem - zarówno pokrycie funkcjonalne, jak i pokrycie wyciągu są bardzo podstawowe, ale lepsze niż nic]
- Czy dla każdej decyzji (takiej jak
iflub while) masz test, który wymusza, aby był prawdziwy, a drugi, który wymusza, aby był fałszywy? [Zakres decyzji]
- Czy dla każdego warunku, który jest koniunkcją (zastosowaniami
&&) lub rozłączeniem (zastosowaniami ||), każde podwyrażenie ma test, w którym jest to prawda / fałsz? [Pokrycie warunków]
- Pokrycie w pętli: Czy masz test, który wymusza 0 iteracji, 1 iterację, 2 iteracje?
- Czy każdy
breakz nich obejmuje pętlę?
(2) Techniki Blackbox są stosowane, gdy wymagania są dostępne, ale sam kod nie jest. Może to prowadzić do wysokiej jakości testów:
- Czy Twoje testy Blackbox obejmują wiele celów testowych? Chcesz, aby twoje testy były „tłuste”: nie tylko testują one funkcję X, ale także testują Y i Z. Interakcja między różnymi funkcjami to świetny sposób na znalezienie błędów.
- Jedynym przypadkiem, w którym nie chcesz testów „grubych”, jest testowanie warunku błędu. Na przykład testowanie pod kątem nieprawidłowych danych wejściowych użytkownika. Jeśli próbujesz osiągnąć wiele nieprawidłowych celów testowania danych wejściowych (na przykład nieprawidłowy kod pocztowy i nieprawidłowy adres ulicy), prawdopodobne jest, że jeden przypadek maskuje drugi.
- Rozważ typy danych wejściowych i utwórz „klasę równoważności” dla typów danych wejściowych. Na przykład, jeśli Twój kod sprawdza, czy trójkąt jest równoboczny, test wykorzystujący trójkąt o bokach (1, 1, 1) prawdopodobnie wykryje te same rodzaje błędów, co dane testowe (2, 2, 2) i (3, 3, 3) znajdzie. Lepiej poświęcić czas na myślenie o innych klasach danych wejściowych. Na przykład, jeśli twój program obsługuje podatki, będziesz potrzebować testu dla każdej grupy podatkowej. [Nazywa się to partycjonowaniem równoważności.]
- Przypadki szczególne są często związane z wadami. Dane testowe powinny również mieć wartości graniczne, takie jak te na, powyżej lub poniżej krawędzi zadania równoważności. Na przykład testując algorytm sortowania, będziesz chciał przetestować pustą tablicę, tablicę z jednym elementem, tablicę z dwoma elementami, a następnie tablicę bardzo dużą. Należy rozważyć przypadki graniczne nie tylko dla danych wejściowych, ale także dla danych wyjściowych. [To jest analiza wartości granicznej wywołania.]
- Inną techniką jest „zgadywanie błędów”. Czy masz wrażenie, że wypróbujesz specjalną kombinację, która sprawi, że Twój program się zepsuje? Więc po prostu spróbuj! Pamiętaj: Twoim celem jest znalezienie błędów, a nie potwierdzenie, że program jest prawidłowy . Niektórzy ludzie potrafią zgadywać błędy.
(3) Na koniec załóżmy, że masz już wiele fajnych testów zasięgu whitebox i zastosowałeś techniki blackbox. Co jeszcze możesz zrobić? Czas przetestować swoje testy . Jedną z technik, której można użyć, jest testowanie mutacji.
Podczas testowania mutacji dokonujesz modyfikacji (kopii) swojego programu, mając nadzieję na stworzenie błędu. Mutacją może być:
Zmień odniesienie jednej zmiennej na inną zmienną; Wstaw funkcję abs (); Zmień mniej niż na większą niż; Usuń oświadczenie; Zamień zmienną na stałą; Usuń metodę zastępującą; Usuń odwołanie do super metody; Zmień kolejność argumentów
Stwórz kilkadziesiąt mutantów w różnych miejscach swojego programu [program będzie nadal musiał się skompilować, aby przetestować]. Jeśli twoje testy nie wykryją tych błędów, musisz teraz napisać test, który może znaleźć błąd w zmutowanej wersji twojego programu. Gdy test znajdzie błąd, zabiłeś mutanta i możesz spróbować innego.
Dodatek : Zapomniałem wspomnieć o tym efekcie: Błędy mają tendencję do skupiania się . Oznacza to, że im więcej błędów znajdziesz w jednym module, tym większe prawdopodobieństwo, że znajdziesz więcej błędów. Tak więc, jeśli test się nie powiedzie (to znaczy test się powiedzie, ponieważ celem jest znalezienie błędów), należy nie tylko naprawić błąd, ale także napisać więcej testów dla modułu, używając powyższe techniki.
Dopóki znajdziesz błędy w stałym tempie, działania testowe muszą być kontynuowane. Tylko w przypadku spadku liczby wykrytych błędów możesz mieć pewność, że podjąłeś starania w zakresie testowania na tym etapie rozwoju.