Co to jest testowanie modułów? Definicja, przykłady
⚡ Inteligentne podsumowanie
Podczas testowania modułów sprawdzane są poszczególne podprogramy, podprocedury, klasy i procedury, a nie cały program. Dzięki temu usterki ujawniają się wewnątrz małego, dobrze zrozumiałego bloku kodu, gdzie ich zlokalizowanie i naprawa jest łatwiejsza.
Co to jest testowanie modułów?
Testowanie modułów To rodzaj testowania oprogramowania, który polega na sprawdzeniu poszczególnych podprogramów, podprogramów, klas lub procedur w programie. Zamiast testowania całego programu na raz, testowanie modułów zaleca testowanie mniejszych bloków składowych programu.
Testowanie modułów jest w dużej mierze zorientowane na „białą skrzynkę”. Celem testowania modułów nie jest wykazanie prawidłowego działania modułu, lecz wykazanie obecności w nim błędu. Ta inwersja ma znaczenie: przebieg, który nic nie wykrył, potwierdził bardzo niewiele, podczas gdy przebieg, który ujawnił defekt, spełnił swoje zadanie.
Testowanie na poziomie modułu pozwala również na wprowadzenie paralelizmu do procesu testowania, ponieważ daje możliwość testowania wielu modułów jednocześnie, zamiast oczekiwania na ich kompletną kompilację.
Dlaczego warto testować moduły
Zaleca się testowanie modułowe, ponieważ zmienia ono ekonomikę wykrywania defektów.
- Prawdopodobieństwo zidentyfikowania błędów lub usterek w mniejszych fragmentach programu staje się większe.
- Możliwe jest równoczesne testowanie wielu modułów, co pozwala na równoległe testowanie.
- Złożonością testów można łatwo zarządzać, ponieważ każdy moduł jest osobno rozumiany.
- W jednym module znaleziono wadę tracjest w stanie obsłużyć niewielką ilość kodu, więc czas debugowania znacznie się skraca.
Jak przeprowadzić testowanie modułów?
Projektowanie walizka testowa To ważny segment testowania modułowego. Projektując przypadki testowe dla testu modułowego, tester musi wziąć pod uwagę dwie kwestie.
- Specyfikacja modułu
- Kod źródłowy modułu
Przeanalizuj logikę modułu, korzystając z jednego lub więcej z białe pudełko metody, a następnie uzupełnij te przypadki testowe, stosując czarna skrzynka metody do specyfikacji modułu. Realistyczne wartości są równie ważne, jak wybrane ścieżki, dlatego przygotuj dane testowe w toku sprawy, a nie po jej zakończeniu.
Po zaprojektowaniu przypadków testowych kolejnym krokiem jest połączenie modułów do testowania. Stosowana metoda to: przyrostowe lub nieinkrementalny Metoda.
- Metoda nieinkrementalna — wszystkie moduły są testowane niezależnie. Najpierw łączy się wszystkie moduły, a następnie testuje cały program.
- Metoda przyrostowa — każdy moduł jest najpierw testowany, a następnie stopniowo dodawany do testowanej kolekcji. Przeprowadzany jest krok po kroku ponowny test.
- W ramach testów przyrostowych istnieją dwa podejścia: z góry na dół oraz oddolne testowanie.
- Aby uruchomić moduł z wybranymi danymi, niezbędny jest sterownik, który dostarcza dane testowe, monitoruje wykonywanie i przechwytuje wyniki.
Wybór pomiędzy tymi dwiema metodami jest kompromisem pomiędzy wysiłkiem związanym z przygotowaniem a możliwością diagnozy.
| WYGLĄD | Metoda przyrostowa | Metoda nieinkrementalna |
| Mieszana | Moduł po module dodawany do przetestowanej kolekcji | Wszystkie moduły połączone, a następnie przetestowane razem |
| Potrzebne rusztowanie | Więcej sterowników i szczątków, pisanych stopniowo | Mniej duplikatów testów, ponieważ obecne są prawdziwe moduły |
| Izolowanie błędów | Silny — błąd wskazuje na moduł, który właśnie dodano | Słaby — awaria może mieć miejsce w dowolnym miejscu |
| Najlepiej nadaje się do | Duże konstrukcje z wieloma interaktywnymi modułami | Małe programy z niewielką liczbą modułów i niskim sprzężeniem |
Sterowniki i stuby w testowaniu modułów
Wspomniany powyżej sterownik to połowa pary. Ponieważ testowany moduł rzadko znajduje się na górze lub na dole łańcucha wywołań, testerzy zastępują kodem fikcyjną to, czego brakuje po obu jego stronach.
- Kierowca — zastępuje moduł wywołujący powyżej modułu testowanego. Dostarcza dane testowe, wywołuje moduł, monitoruje wykonanie i przechwytuje wyniki. Testowanie od dołu do góry zależy od sterowników, ponieważ moduły niższego rzędu są gotowe przed modułami wyższego rzędu.
- Kikut — zastępuje wywołany moduł poniżej modułu testowanego. Przyjmuje wywołanie i zwraca ustaloną, znaną odpowiedź, dzięki czemu testowany moduł może ukończyć swoją ścieżkę. Testowanie odgórne opiera się na stubach, ponieważ moduły wyższego rzędu są gotowe jako pierwsze.
Rozwiązany przypadek ukonkretnia parowanie. Jeśli moduł obliczania płatności zostanie ukończony, a wywołujący go ekran płatności jeszcze nie, sterownik przekazuje modułowi zestaw sum zamówień i rejestruje otrzymane dane. Jeśli usługa wyszukiwania podatku, którą wywołuje moduł, również nie jest ukończona, szczątkowy moduł zwraca stałą stawkę podatku, dzięki czemu obliczenia nadal są wykonywane. Żaden z elementów rusztowania nie jest dostarczany; oba są odrzucane po dostarczeniu rzeczywistych modułów, dlatego nieporozumienie dotyczące duplikatów testów jest później wymieniane jako powtarzające się wyzwanie.
Przykładowe wskazówki dotyczące testowania modułów
Oto kilka wskazówek, które warto wziąć pod uwagę przed przeprowadzeniem testów modułu.
- Revprzejrzyj przypadki testowe przed ich użyciem.
- Unikaj nieporozumień co do źródła rozbieżności.
- Użyj narzędzi do automatycznego testowania.
- Sprawdź zmienne, które powinny pozostać niezmienione.
- Zamieniaj moduły między testerami, aby uniknąć autotestowania.
- Ponownie wykorzystaj przypadki testowe.
Piąta wskazówka ma większe znaczenie, niż sugeruje jej długość. Programista, który testuje tylko moduł, który właśnie został napisany, powtarza te same założenia, które doprowadziły do powstania błędu, dlatego rotacja modułów między osobami jest jednym z najtańszych sposobów na poprawę jakości.
Testowanie jednostkowe a testowanie modułowe
W wielu zespołach te dwa terminy są używane zamiennie, jednak autorstwo i zakres różnią się.
| Testowanie modułu | Testów jednostkowych |
| Testy modułowe to zbiór testów napisanych przez testera po napisaniu przez programistę części kodu | Testy jednostkowe to zbiór testów napisanych przez programistę w trakcie procesu tworzenia oprogramowania |
| Testowanie modułów może obejmować łączenie testów jednostkowych | Testowanie jednostkowe może polegać na testowaniu jednostek w izolacji |
Testowanie modułów, testowanie komponentów i testowanie integracji
Testowanie modułów odbywa się również obok dwóch sąsiednich poziomów, które łatwo z nim pomylić. Tabela oddziela je według tego, co jest testowane i kto zazwyczaj to wykonuje.
| WYGLĄD | Testowanie modułów | Testowanie komponentów | Testy integracyjne |
| W trakcie testów | Jeden podprogram, klasa lub procedura | Jeden samodzielny komponent z bezpośrednimi zależnościami | Interfejsy pomiędzy modułami łączonymi |
| Zwykły właściciel | Tester, po napisaniu kodu | Próbnik | Tester integracyjny |
| Rusztowanie | Sterowniki i ślepe | Zastępcze zależności zewnętrzne | Stopniowo coraz mniej dublerów testowych |
| Wada ujawniona | Błąd logiczny wewnątrz modułu | Błąd zachowania w komponencie | Błąd interfejsu i przekazywania danych |
W codziennym użytkowaniu testowanie komponentów i testowanie modułów są często traktowane jako ta sama czynność, podczas gdy testy integracyjne rozpoczyna się dopiero po zaliczeniu poszczególnych modułów.
Wyzwania w testowaniu modułów
To są wyzwania, z którymi zespoły spotykają się najczęściej, gdy wprowadzane są testy modułowe.
- Testowanie nieprzyrostowe wymaga więcej pracy — połączenie wszystkiego w pierwszej kolejności oznacza, że pojedyncza awaria może spowodować konieczność ponownego przeanalizowania przez testerów całego programu.
- Nieporozumienie testu podwójnego — zalążek zwracający nierealistyczną wartość powoduje zielony wynik, który niczego nie dowodzi.
- Często debuguję testy — kod szkieletowy ma swoje wady, a czas poświęcony na naprawianie sterownika to czas, który nie został przeznaczony na testowanie modułu.
- Trzeba zrozumieć kod — orientacja białego pudełka oznacza, że tester, który nie potrafi odczytać modułu, nie jest w stanie zaprojektować dla niego sensownych przypadków.
