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.

  • 🎯 Cel: Celem jest wykrycie błędów w module, a nie pokazanie, że moduł działa.
  • Orientacja: Technika ta opiera się w dużej mierze na białych skrzynkach, uzupełnionych przypadkami czarnych skrzynek zaczerpniętymi ze specyfikacji.
  • Równoległość: Możliwe jest testowanie kilku modułów jednocześnie, co skraca czas trwania testów.
  • 🔗 Dwie metody: Moduły można łączyć przyrostowo, krok po kroku lub nie-przyrostowo w jednym przejściu.
  • 🧰 Rusztowanie: Sterowniki dostarczają dane testowe do modułu, natomiast moduły zastępcze zastępują wywoływane przez niego moduły.
  • 🆚 Własność: Testerzy piszą testy modułowe po kodowaniu, natomiast programiści piszą testy jednostkowe w trakcie.
  • ⚠️ wyzwania: Większość wysiłku pochłania praca bez przyrostu, źle zrozumiane dublowanie testów i częste debugowanie.

Wyjaśnienie testowania modułów za pomocą metod, sterowników, szczątków i porównań

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.

FAQ

Rodzina xUnit obejmuje większość języków, a biblioteki mockingowe dostarczają szablony, a narzędzie do pokrycia pokazuje, które ścieżki zostały osiągnięte. Wybór zależy od języka modułu, a nie od poziomu testowania.

Model odczytuje kod źródłowy modułu, wylicza gałęzie i proponuje przypadek dla każdej z nich, łącznie z wartościami granicznymi, które często są pomijane podczas ręcznego przetwarzania. Revwidok pozostaje konieczny, ponieważ wygenerowane przypadki potwierdzają to, co kod robi, a nie to, czego wymaga specyfikacja.

Tak, a rusztowania to obszar, w którym asystenci sprawdzają się najlepiej, ponieważ sterownik lub stub to powtarzalny kod o znanym kształcie. Zwracane wartości nadal wymagają decyzji człowieka, ponieważ wiarygodnie wyglądający stub może ukryć poszukiwany defekt.

Wystarczy, że każda gałąź i każda granica w module została przetestowana co najmniej raz. Sam cel procentowy jest mylący, ponieważ wysokie pokrycie instrukcji może nadal pozostawiać niesprawdzone wyniki decyzji.

Po skompilowaniu modułu i przed przetestowaniem jego interfejsów, jest to pierwszy poziom testowania zastosowanego do dostarczonego kodu, dlatego wykryte tu defekty nigdy nie docierają do etapu integracji ani systemu.

Postępuj zgodnie z istniejącym kodem. Metoda „z góry na dół” pasuje do projektów, w których logika sterowania jest pisana jako pierwsza, a moduły niższego rzędu są szczątkowe; metoda „z dołu do góry” pasuje do projektów, w których moduły narzędziowe są najpierw umieszczane, a sterowniki je wywołują.

Moduł kompiluje się bezproblemowo, jego specyfikacja jest dostępna, zależności są obecne lub zaślepione, a dane testowe są gotowe. Rozpoczęcie bez specyfikacji zamienia ćwiczenie w opis kodu.

Testowanie nigdy nie dowodzi, że moduł nie ma defektów, a jedynie, że przetrwał próby. Projektowanie przebiegów próbujących uszkodzić moduł zwraca zatem więcej informacji niż projektowanie przebiegów, które mają szansę na powodzenie.

Podsumuj ten post następująco: