Menu

Co to jest testowanie komponentów lub testowanie modułów (poznaj przykłady)

what is component testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Co to jest testowanie komponentów nazywane również testowaniem modułów w testowaniu oprogramowania:

Komponent jest najniższą jednostką dowolnej aplikacji. A więc testowanie komponentów; jak sama nazwa wskazuje, jest techniką testowania najniższej lub najmniejszej jednostki dowolnej aplikacji.

Testowanie modułowe jest czasami nazywane również testowaniem programów lub modułów.

O aplikacji można myśleć jako o kombinacji i integracji wielu małych pojedynczych modułów. Zanim przetestujemy cały system, konieczne jest dokładne przetestowanie każdego komponentu LUB najmniejszej jednostki aplikacji.

jak otworzyć jar za pomocą java

W takim przypadku moduły lub jednostki są testowane niezależnie. Każdy moduł otrzymuje dane wejściowe, wykonuje pewne przetwarzanie i generuje dane wyjściowe. Dane wyjściowe są następnie weryfikowane pod kątem oczekiwanej funkcji.

Co to jest testowanie komponentów

Aplikacje mają ogromny charakter i przetestowanie całego systemu jest wyzwaniem. Może to prowadzić do wielu luk w pokryciu testowym. Dlatego przed przejściem do testów integracyjnych lub funkcjonalnych zaleca się rozpoczęcie od testów modułowych.

Przeczytaj także=> Różnica w testach jednostkowych, integracyjnych i funkcjonalnych

Czego się nauczysz:

Testowanie komponentów

To rodzaj testów typu white box.

Zatem testowanie komponentów wyszukuje błędy i weryfikuje działanie modułów / programów, które są oddzielnie testowane.

Istnieje strategia testowania i plan testów dla testowania modułowego. Dla każdego komponentu istnieje scenariusz testowy, który zostanie dalej podzielony na przypadki testowe. Poniższy diagram przedstawia to samo:

Testowanie komponentów

Cel testowania komponentów

Głównym celem testowania komponentów jest weryfikacja zachowania wejścia / wyjścia obiektu testowego. Zapewnia, że ​​funkcjonalność obiektu testowego działa poprawnie i całkowicie poprawnie, zgodnie z wymaganą specyfikacją.

Dane wejściowe do testowania na poziomie komponentów

Cztery główne dane wejściowe do testowania na poziomie komponentów to:

  • Plan testów projektu
  • wymagania systemowe
  • Specyfikacje komponentów
  • Implementacje komponentów

Kto przeprowadza testy komponentów?

Testowanie komponentów jest wykonywane przez służby QA lub testera.

Co jest testowane w ramach testów komponentów?

Testowanie modułowe może uwzględniać weryfikację funkcjonalnych lub specyficznych niefunkcjonalnych charakterystyk komponentów systemu.

Może to być testowanie zachowania zasobów (np. Określanie wycieków pamięci), testowanie wydajności, testy strukturalne itp.

Kiedy kończy się testowanie komponentów?

Testowanie komponentów jest przeprowadzane po przeprowadzeniu testów jednostkowych.

Komponenty są testowane zaraz po ich utworzeniu, więc istnieje prawdopodobieństwo, że wyniki pobrane z testowanego komponentu zależą od innych komponentów, które z kolei nie są obecnie opracowywane.

W zależności od modelu cyklu rozwojowego, testowanie komponentów może być wykonywane w oderwaniu od innych komponentów systemu. Izolacja ma na celu zapobieżenie wpływom zewnętrznym.

Tak więc, aby przetestować ten komponent, używamy skrótów i sterownikówdo symulacji interfejsu między komponentami oprogramowania.

Testowanie integracyjne jest wykonywane po testowaniu komponentów.

Strategia testów testowania komponentów

W zależności od poziomu testowania, testowanie komponentów jest podzielone na dwie części:

  1. Testowanie komponentów w małych (ctis)
  2. Testowanie komponentów w dużych rozmiarach (CTIL)

Gdy testowanie modułowe jest wykonywane w oderwaniu od innych komponentów, nazywa się to testowaniem modułowym w small. Odbywa się to bez rozważania integracji z innymi komponentami.

Gdy testowanie modułowe jest wykonywane bez izolacji z innymi składnikami oprogramowania, nazywa się je ogólnie testowaniem modułowym. Dzieje się tak, gdy istnieje zależność od przepływu funkcjonalności komponentów i dlatego nie możemy ich wyizolować.

Jeśli komponenty, od których mamy zależność, nie są jeszcze opracowane, zamiast rzeczywistych komponentów używamy obiektów fikcyjnych. Te fikcyjne obiekty to skrót (nazywany funkcją) i sterownik (funkcja wywołująca).

Kodeksy i sterowniki

Zanim przejdę do omówienia odcinków kodu i sterowników, powinienem omówić z różnica między testami modułowymi a testami integracyjnymi. Powodem jest to, że kody pośredniczące i sterowniki są również używane w testowaniu integracyjnym, więc może to prowadzić do niejasności między tymi dwiema technikami testowania.

Technika testowania integracji to technika, w której łączymy 2 komponenty sekwencyjnie i razem testujemy zintegrowany system. Dane z jednego systemu przechodzą do innego, a poprawność danych jest sprawdzana dla systemu zintegrowanego.

W przeciwieństwie do testowania modułów, w których pojedynczy komponent / moduł jest dokładnie testowany przed integracją z innymi komponentami. Można więc powiedzieć, że testy modułowe są wykonywane przed testami integracyjnymi.

Zarówno integracja, jak i komponenty używają Kodeksy i sterowniki .

„Kierowcy” są fałszywymi programami, które są używane do wywoływania funkcji najniższego modułu w przypadku, gdy funkcja wywołująca nie istnieje.

„Stubs” można nazwać kodem fragmentem kodu, który akceptuje dane wejściowe / żądania z modułu głównego i zwraca wyniki / odpowiedź

Jak wyjaśniono wcześniej, komponenty są testowane indywidualnie i niezależnie. Tak więc mogą istnieć pewne cechy komponentów, zależne od innego komponentu, który nie jest obecnie rozwijany. Tak więc, aby przetestować komponenty z tymi „nierozwiniętymi” funkcjami, musimy użyć pewnych stymulujących agentów, które przetwarzałyby dane i zwracały je do komponentów wywołujących.

W ten sposób upewniamy się, że poszczególne komponenty są dokładnie testowane.

poszczególne komponenty są dokładnie testowane

Tutaj widzimy, że:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— to składniki
  • C1, C2 i C3 razem tworzą podjednostkę 1
  • C4 i C5 razem tworzą podjednostkę 2
  • C6, C7 i C8 razem tworzą jednostkę podrzędną 3
  • Sam C9 tworzy podjednostkę 4
  • Podjednostka 1 i podjednostka 2 tworzą razem jednostkę biznesową 1
  • Podjednostka 3 i podjednostka 4 razem tworzą Jednostkę Biznesową 2
  • Jednostka biznesowa 1 i jednostka biznesowa 2 składają się na wniosek.
  • Tak więc testowanie komponentów w tym przypadku polegałoby na przetestowaniu poszczególnych komponentów, które są od C1 do C9.
  • Plik Netto Strzałka między jednostką podrzędną 1 i jednostką podrzędną 2 wskazuje punkt testowania integracji.
  • Podobnie Netto Strzałka pomiędzy podjednostką 3 i podjednostką 4 wskazuje punkt testowania integracji
  • Zielona strzałka między jednostką biznesową 1 a jednostką biznesową 2 przedstawia punkt testowania integracji

Dlatego robilibyśmy:

  • SKŁADNIK testowanie dla C1 do C9
  • INTEGRACJA testowanie między jednostkami podrzędnymi i jednostkami biznesowymi
  • SYSTEM testowanie Aplikacji jako całości

Przykład

Do tej pory musieliśmy ustalić, że testowanie komponentów jest jakaś technika testowania w białej skrzynce . Cóż, może to być prawda. Ale to nie znaczy, że tej techniki nie można zastosować w technice testowania czarnoskrzynkowego.

gdzie jest klucz bezpieczeństwa sieci

Rozważ ogromną aplikację internetową, która zaczyna się od strony logowania. Jako tester (to również w zwinnym świecie) nie mogliśmy czekać, aż cała aplikacja zostanie opracowana i będzie gotowa do testowania. Aby wydłużyć czas wprowadzenia produktu na rynek, musimy wcześnie rozpocząć testy. Tak więc, kiedy widzimy, że strona logowania została opracowana, musimy nalegać, aby została nam udostępniona do testowania.

Gdy tylko strona logowania będzie dostępna do przetestowania, możesz wykonać wszystkie przypadki testowe (pozytywne i negatywne), aby upewnić się, że funkcjonalność strony logowania działa zgodnie z oczekiwaniami.

Zalety testowania strony logowania w tym momencie to:

Niektóre błędy oprogramowania wskazują na problem z łącznością fizyczną
  • Interfejs użytkownika jest testowany pod kątem użyteczności (błędy ortograficzne, logo, wyrównanie, formatowanie itp.)
  • Spróbuj użyć negatywne techniki testowania jak uwierzytelnianie i autoryzacja. W takich przypadkach istnieje duże prawdopodobieństwo znalezienia usterek.
  • Wykorzystanie technik takich jak SQL Injections zapewniłoby zbadanie naruszenia bezpieczeństwa na bardzo wczesnym etapie.

Błędy, które zarejestrujesz na tym etapie, będą stanowić „wyciągnięte wnioski” dla zespołu programistów i zostaną zaimplementowane w kodowaniu kolejnej strony. Dlatego wczesne testowanie zapewnia lepszą jakość stron, które nie zostały jeszcze opracowane.

Ponieważ inne kolejne strony nie zostały jeszcze opracowane, możesz potrzebować kodów pośredniczących w celu sprawdzenia poprawności działania strony logowania. Na przykład ,możesz potrzebować prostej strony z napisem „logowanie powiodło się” w przypadku poprawnych poświadczeń i wyskakującego okienka z komunikatem o błędzie w przypadku nieprawidłowych poświadczeń.

Możesz przejść przez nasz wcześniejszy samouczek Testy integracyjne aby mieć więcej informacji na temat kodów kreskowych i sterowników.

Jak pisać przypadki testowe komponentów?

Przypadki testowe do testowania modułowego pochodzą z produktów pracy, na przykład projektu oprogramowania lub modelu danych. Każdy komponent jest testowany za pomocą sekwencji przypadków testowych, w których każdy przypadek testowy obejmuje określoną kombinację danych wejściowych / wyjściowych, tj. Częściową funkcjonalność.

Poniżej znajduje się przykładowy fragment przypadku testowego komponentu dla modułu logowania.

Podobnie możemy napisać inne przypadki testowe.

przypadki testowe

Testowanie komponentów a testowanie jednostkowe

Pierwsza różnica między testami modułowymi a testami jednostkowymi polega na tym, że pierwszy z nich jest wykonywany przez testerów, a drugi przez programistów lub specjalistów SDET.

Testowanie jednostkowe jest przeprowadzane na poziomie szczegółowym. Z drugiej strony, testowanie komponentów odbywa się na poziomie aplikacji. W testach jednostkowych sprawdza się, czy indywidualny program lub fragment kodu jest wykonywany zgodnie z określonym. W testach modułowych każdy obiekt oprogramowania jest testowany oddzielnie, z izolacją lub bez izolacji z innymi komponentami / obiektem systemu.

Testowanie modułowe jest więc podobne do testów jednostkowych, ale odbywa się na wyższym poziomie integracji iw kontekście aplikacji (nie tylko w kontekście tej jednostki / programu, jak w przypadku testów jednostkowych).

Komponent Vs Interfejs Vs Integracja Vs Testowanie systemów

Składnik jak wyjaśniłem, jest najniższą jednostką aplikacji, która jest testowana niezależnie.

Na berło jest warstwą łączącą 2 komponenty. Testowanie platformy lub interfejsu, na którym współdziałają dwa komponenty, nazywa się testowaniem interfejsu.

Teraz testowanie interfejsu wygląda trochę inaczej. Te interfejsy są w większości API lub usługi internetowe , więc testowanie tych interfejsów nie byłoby podobne do techniki Black Box, raczej wykonywałbyś pewnego rodzaju testy API lub testowanie usług internetowych przy użyciu SOAP UI lub jakimkolwiek innym narzędziem.

Po zakończeniu testowania interfejsu pojawia się plik Testy integracyjne .

Podczas testu integracyjnego łączymy kolejno poszczególne testowane komponenty i testujemy je przyrostowo. Podczas integracji sprawdzamy, czy poszczególne komponenty połączone jeden po drugim zachowują się zgodnie z oczekiwaniami, a dane nie są zmieniane podczas przepływu z 1 modułu do innego modułu.

Gdy wszystkie komponenty zostaną zintegrowane i przetestowane, wykonujemy Testowanie systemów aby przetestować całą aplikację / system jako całość. Ten test weryfikuje wymagania biznesowe w stosunku do wdrożonego oprogramowania.

Wniosek

powiedziałabym to Testów jednostkowych i testowanie komponentów odbywa się równolegle.

W przeciwieństwie do testów jednostkowych, które są wykonywane przez zespół programistów, testowanie komponentów / modułów jest wykonywane przez zespół testujący. Przed rozpoczęciem testów integracyjnych zawsze zaleca się przeprowadzenie testów komponentowych.

Jeśli testowanie komponentów jest solidne, w testach integracyjnych znajdziemy mniej błędów. Pojawiłyby się problemy, ale te kwestie byłyby związane ze środowiskiem integracji lub wyzwaniami konfiguracyjnymi. Możesz upewnić się, że funkcjonalność zintegrowanych komponentów działa poprawnie.

Mam nadzieję, że ten samouczek był przydatny do zrozumienia testowania komponentów, integracji i systemu. Jeśli nadal masz pytania, nie wahaj się zapytać nas w komentarzach.

rekomendowane lektury

^