Menu

Co to jest testowanie przyrostowe: szczegółowe wyjaśnienie z przykładami

what is incremental testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Z pomocą tego artykułu zamierzam omówić jedno z ważnych podejść integracyjnych - testowanie przyrostowe.

Pod koniec tej sekcji publiczność będzie miała wystarczającą wiedzę na temat:

  • Co to jest testowanie przyrostowe?
  • Jego cel
  • Metodologie
  • Zalety
  • Wady

Czego się nauczysz:

Co to jest testowanie przyrostowe

Testowanie przyrostowe, znane również jako testowanie przyrostowe integracji, jest jednym z podejść testowania integracyjnego i obejmuje jego podstawowe pojęcia.

To jest jak test, który łączy w sobie moduł i integrację strategia testowania .

Testowanie przyrostowe

W ramach tego testu testujemy każdy moduł indywidualnie w fazie testów jednostkowych, a następnie moduły są integrowane przyrostowo i testowane, aby zapewnić płynny interfejs i interakcję między modułami.

W tym podejściu każdy moduł jest łączony przyrostowo, tj. Jeden po drugim, aż wszystkie moduły lub komponenty zostaną dodane logicznie w celu utworzenia wymaganej aplikacji, zamiast integrować cały system od razu, a następnie przeprowadzać testy na produkcie końcowym. Zintegrowane moduły są testowane jako grupa, aby zapewnić pomyślną integrację i przepływ danych między modułami.

Podobnie jak w przypadku testów integracyjnych, głównym celem tych testów jest sprawdzenie interfejsu, zintegrowanych łączy i przepływu informacji między modułami. Ten proces jest powtarzany, aż moduły zostaną połączone i pomyślnie przetestowane.

Przykład

Rozumiemy tę koncepcję na przykładzie:

System lub aplikacja składa się z następujących modułów:

Aplikacja oprogramowania

Podejście do testowania integracji przyrostowej

  • Każdy moduł, tj. M1, M2, M3 itd., Jest testowany indywidualnie w ramach testów jednostkowych
  • Moduły są łączone przyrostowo, tj. Jeden po drugim i testowane pod kątem udanej interakcji
  • Na ryc. 2 moduł M1 i moduł M2 są połączone i przetestowane
  • Na ryc. 3 dodano i przetestowano moduł M3
  • Na ryc. 4 dodano moduł M4 i przeprowadzono testy, aby upewnić się, że wszystko działa poprawnie
  • Pozostałe moduły są również dodawane stopniowo na każdym kroku i testowane pod kątem pomyślnej integracji

Rys2

Połączone dwa moduły

Rys3

Połączone 3 moduły

Rys4

Połączone cztery moduły

Cel testu przyrostowego

  • Aby zapewnić pomyślną współpracę różnych modułów po integracji
  • Identyfikuj usterki wcześniej iw każdej fazie. Daje to programistom przewagę w określeniu, gdzie jest problem. Tak jak w przypadku, gdy testowanie po zintegrowaniu M1 i M2 zakończyło się pomyślnie, ale po dodaniu M3 test kończy się niepowodzeniem; pomoże to deweloperowi w oddzieleniu problemu
  • Problemy można naprawiać we wczesnej fazie bez wielu przeróbek i mniejszym kosztem

Przyrostowe metodologie testowania integracji

Zanim zaczniemy ten temat, chciałbym przedstawić krótkie wprowadzenie Krotki i sterowniki ponieważ będziemy często używać tych terminów.

Stuby i sterowniki to pseudokod lub fikcyjny kod używany w Integration lub testowanie komponentów gdy jeden lub więcej modułów nie jest opracowanych, ale są wymagane do przetestowania innego modułu.

Stubs są używane w podejściu do testowania odgórnego i są nazywane „programami”. Stuby pomagają symulować interfejs między modułami dolnej dźwigni, które nie są dostępne lub opracowane.

Kierowcy są używane w podejściu do testowania oddolnego i są znane jako „programy wywołujące”. Sterowniki pomagają symulować interfejs między modułami najwyższego poziomu, które nie są opracowane lub dostępne.

Pytanie, które może się pojawić niektórym z nas, brzmi: dlaczego nie zaczekać, aż wszystkie moduły aplikacji zostaną opracowane, zamiast używać kodu pośredniczącego / sterownika przed rozpoczęciem testów?

Prosta odpowiedź jest taka, że ​​wydłuża to czas realizacji projektu, ponieważ testerzy będą siedzieć bezczynnie, dopóki nie zostaną opracowane wszystkie moduły. Utrudnia to również analizę źródłową defektu. Ten typ podejścia do testowania jest znany jako testowanie integracji Big-Bang.

Teraz, gdy omówiliśmy kody zwrotne i sterowniki, przejdźmy do różne metodologie testowania przyrostowego:

# 1) Z góry na dół

Jak sama nazwa wskazuje, testowanie odbywa się od góry do dołu, czyli od modułu centralnego do modułu podrzędnego. Najpierw testowane są moduły tworzące górną warstwę aplikacji.

Podejście to jest zgodne ze strukturalnym przepływem testowanej aplikacji. Niedostępne lub nieopracowane moduły lub komponenty są zastępowane kodami.

Zrozummy to na przykładzie:

  • Moduł : Logowanie do witryny internetowej aka L
  • Moduł : Zamówienie aka O
    • Podsumowanie zamówienia modułów, czyli system operacyjny (jeszcze nie opracowany)
  • Moduł : Płatność aka P.
    • Moduł płatności gotówką, czyli CP
    • Moduł Debet / Credit Payment aka DP (jeszcze nie opracowany)
    • Moduł Wallet Payment aka WP (jeszcze nie opracowany)
  • Moduł: Raportowanie aka R (jeszcze nie opracowane)

Podejście odgórne

Odgórne podejście do testowania integracji przyrostowej

Zostaną wyprowadzone następujące przypadki testowe:

Przypadek testowy 1: Moduł L i Moduł O zostaną zintegrowane i przetestowane
Przypadek testowy 2: Moduły L, O i P zostaną zintegrowane i przetestowane
Przypadek testowy 3: Moduły L, O, P i R zostaną zintegrowane i przetestowane.

I tak na innych przypadkach testowych są wyprowadzane.

Ten typ testowania, w którym wszystkie moduły w warstwie są najpierw integrowane i testowane, nazywa się „najpierw wszerz”. Inna kategoria to „najpierw głębia”.

Następujące przypadki testowe zostaną wyprowadzone dla „najpierw głębi”:

Przypadek testowy 1: Moduł L i Moduł O zostaną zintegrowane i przetestowane
Przypadek testowy 2: Moduły L, O i OS zostaną zintegrowane i przetestowane
Przypadek testowy 3: Moduł L, O, OS, P zostanie zintegrowany i przetestowany
Przypadek testowy 4: Moduł L, O, OS, P, CP zostanie zintegrowany i przetestowany

I tak na innych przypadkach testowych są wyprowadzane.

Zalety metodologii odgórnej

  • Wczesna ekspozycja wad architektonicznych
  • Opisuje działanie aplikacji jako całości na wczesnych etapach i pomaga we wczesnym ujawnieniu wad projektu
  • Główne punkty kontrolne są testowane wcześnie

De-merity metodologii odgórnej

  • Znaczące moduły są testowane pod koniec cyklu
  • Zapisanie warunków testowych jest bardzo trudne
  • Odcisk nie jest idealną implementacją powiązanego modułu. Po prostu symuluje przepływ danych między dwoma modułami

# 2) Oddolne

W tym podejściu testowanie odbywa się od dołu do góry, tj. Moduły w dolnej warstwie są integrowane i testowane jako pierwsze, a następnie kolejno integrowane są inne moduły, gdy się poruszamy. Niedostępne lub nieopracowane moduły są zastępowane przez sterowniki.

najlepszy darmowy program do czyszczenia rejestru dla systemu Windows 10

Spójrzmy na poniższy przykład, aby lepiej zrozumieć:

Moduły Ranga, Oceny, Procent i Klasa sportowa nie zostały jeszcze opracowane, więc zostaną zastąpione powiązanym sterownikiem:

Podejście oddolne

Podejście oddolne do testowania integracji przyrostowej

Zostaną wyprowadzone następujące przypadki testowe:

Przypadek testowy 1: Testowanie jednostkowe modułu Praktyczne i teoretyczne
Przypadek testowy 2: Integracja i testowanie modułów Marks-Practical-Teoria
Przypadek testowy 3 : Integracja i testowanie modułów Procent-Marks-Praktyczna-Teoria
Przypadek testowy 4: Testowanie jednostkowe modułu Sports Grade
Przypadek testowy 5: Integracja i testowanie modułów Rank-Sports Grade-Percentage-Marks-Practical-Theory

Zalety metodologii oddolnej

  • Ta metodologia jest bardzo przydatna w zastosowaniach, w których stosowany jest model projektowania oddolnego
  • Łatwiej jest stworzyć warunki testowe w podejściu oddolnym
  • Rozpoczęcie testowania na najniższym poziomie hierarchii oznacza testowanie krytycznych modułów lub funkcjonalności na wczesnym etapie. Pomaga to we wczesnym wykrywaniu błędów
  • Wady interfejsu są wykrywane na wczesnym etapie

Zalety metodologii oddolnej

  • Sterowniki są trudniejsze do napisania niż stub
  • Wady projektowe wychwytywane są na późniejszym etapie
  • W tym podejściu nie mamy działającej aplikacji, dopóki nie zostanie zbudowany ostatni moduł
  • Sterownik nie jest pełną implementacją powiązanego modułu. Po prostu symuluje przepływ danych między dwoma modułami.

# 3) Testowanie kanapek

Podejście to jest połączeniem metodologii odgórnej i oddolnej. Stub i sterowniki są używane w przypadku niekompletnych lub nieopracowanych modułów.

Podejście testowe

  • Określono warstwę środkową, na podstawie której przeprowadzane są testy oddolne i odgórne. Ta warstwa środkowa jest również nazywana warstwą docelową
  • Warstwa docelowa jest identyfikowana zgodnie z podejściem heurystycznym, tj. Należy wybrać warstwę, która pozwala na minimalne użycie kodów skrótów i sterowników
  • Testowanie odgórne rozpoczyna się od warstwy środkowej i przechodzi w dół w kierunku modułów niższego poziomu. Ta warstwa poniżej warstwy środkowej jest nazywana warstwą dolną
  • Testowanie oddolne również zaczyna się od warstwy środkowej i przechodzi w górę w kierunku modułów warstwy górnej. Ta warstwa nad warstwą środkową jest nazywana warstwą górną
  • Przy użyciu kodów pośredniczących i sterowników testowane są odpowiednio interfejs użytkownika i funkcje modułów niższego poziomu
  • Ostatecznie do wykonania końcowego testu pozostaje tylko środkowa warstwa

Przykład:

Przykład testu kanapkowego

Następujące przypadki testowe można uzyskać za pomocą strategii testowania warstwowego:

Przypadek testowy 1: Test A, X, Y i Z indywidualnie - gdzie Test A podlega testowi górnej warstwy, a test X, Y i Z testom dolnej warstwy
Przypadek testowy 2: Test A, G, H i I
Przypadek testowy 3: Przetestuj G, X i Y
Przypadek testowy 4: Ręka testowa Z
Przypadek testowy 5: Test A, G, H, I, X, Y i Z

Zalety metodologii testowania kanapek

  • Jest to bardzo korzystne w przypadku dużego projektu, który obejmuje różne podprojekty
  • Metody testowania odgórnego i oddolnego mogą działać równolegle

Zalety metodologii testowania kanapek

  • Przed unifikacją modułów podsystemy i ich interfejsy nie są dokładnie testowane
  • Wyższy koszt ze względu na zaangażowanie zarówno odgórnej, jak i oddolnej metodologii testowania
  • Tego typu testowanie nie jest zalecane w przypadku systemu, w którym moduły są w dużym stopniu współzależne

Wniosek

Testowanie przyrostowe wchodzi w zakres testów integracyjnych. W tym podejściu do testowania, testy integracyjne są wykonywane na pojedynczym module jako część testów jednostkowych, aw następnej fazie moduły lub komponenty aplikacji są integrowane przyrostowo, a testy są wykonywane na połączonych modułach jako grupa.

Spośród trzech metodologii Przyrostowego Testowania Integracji wybór metodyki do wyboru zależy od struktury aplikacji, a także od umiejscowienia modułów wysokiego ryzyka.

Wszystkie trzy metodologie testowania przyrostowego należą do kategorii horyzontalnej ze względu na następujące aspekty behawioralne:

  • Wszystkie trzy metodologie koncentrują się na testowaniu warstw
  • Wszystkie rozważają projekt strukturalny lub hierarchiczny
  • Wszystkie z nich stopniowo integrują warstwy

Zalety:

Dzięki takiemu podejściu do testowania łatwiej jest wcześnie zidentyfikować defekty, a także pomaga programistom określić przyczynę problemu. Ponieważ wykorzystuje podstawy testowania strukturalnego, to podejście do testowania jest bardzo skuteczne i dokładne.

Wady:

Tego typu podejście do testowania jest czasochłonne ze względu na użycie kodów pośredniczących i sterowników. Jest również powtarzalny.

O autor: Ten pomocny poradnik został napisany przez Nehę B. Jest ona certyfikowanym przez ISTQB głównym analitykiem ds. Jakości z ponad 8-letnim doświadczeniem.

Daj nam znać, jeśli masz jakieś pytania / sugestie.

rekomendowane lektury

^