Menu

Co to jest testowanie integracji (samouczek z przykładem testowania integracji)

what is integration testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Co to jest testowanie integracyjne: poznaj przykłady testów integracyjnych

Testy integracyjne są wykonywane w celu przetestowania modułów / komponentów po integracji, aby sprawdzić, czy działają zgodnie z oczekiwaniami, tj. Aby przetestować moduły, które działają dobrze indywidualnie, nie ma problemów podczas integracji.

Mówiąc w kategoriach testowania dużych aplikacji za pomocą techniki testowania czarną skrzynką, chodzi o połączenie wielu modułów, które są ze sobą ściśle powiązane. Możemy zastosować koncepcje techniki testowania integracji do testowania tego typu scenariuszy.

Lista samouczków z tej serii:

Samouczek nr 1: Co to jest testowanie integracyjne? (Ten samouczek)
Samouczek nr 2: Co to jest testowanie przyrostowe
Samouczek nr 3: Co to jest testowanie komponentów
Samouczek nr 4: Ciągła integracja
Samouczek nr 5 Różnica między testowaniem jednostkowym a integracją
Samouczek nr 6: 10 najlepszych narzędzi do testowania integracji

czym jest testowanie integracji

Czego się nauczysz:

Co to jest testowanie integracyjne?

Znaczenie testów integracyjnych jest dość proste - Zintegruj / połącz testowany moduł jeden po drugim i przetestuj zachowanie jako połączoną jednostkę.

Główną funkcją lub celem tego testowania jest przetestowanie interfejsów między jednostkami / modułami.

Zwykle przeprowadzamy testy integracyjne po „testach jednostkowych”. Gdy wszystkie poszczególne jednostki zostaną utworzone i przetestowane, zaczynamy łączyć te moduły „Testowane jednostkowo” i zaczynamy przeprowadzać zintegrowane testy.

Główną funkcją lub celem tego testowania jest przetestowanie interfejsów między jednostkami / modułami.

Poszczególne moduły są najpierw testowane oddzielnie. Po przetestowaniu modułów są one integrowane jeden po drugim, aż do zintegrowania wszystkich modułów, w celu sprawdzenia zachowania kombinacji i sprawdzenia, czy wymagania zostały wdrożone poprawnie, czy nie.

W tym miejscu powinniśmy zrozumieć, że testowanie integracyjne nie odbywa się na końcu cyklu, a raczej jest przeprowadzane jednocześnie z rozwojem. Dlatego w większości przypadków wszystkie moduły nie są dostępne do testowania, a oto wyzwanie polega na przetestowaniu czegoś, co nie istnieje!

Dlaczego test integracji?

Uważamy, że testy integracyjne są złożone i wymagają pewnych umiejętności programistycznych i logicznych. To prawda! Jaki jest więc cel integracji tych testów z naszą strategią testowania?

Oto kilka powodów:

  1. W prawdziwym świecie, gdy tworzone są aplikacje, są one dzielone na mniejsze moduły, a poszczególnym programistom przypisuje się 1 moduł. Logika zaimplementowana przez jednego programistę jest zupełnie inna niż u innego, dlatego ważne jest, aby sprawdzić, czy logika zaimplementowana przez programistę jest zgodna z oczekiwaniami i renderować poprawną wartość zgodnie z określonymi standardami.
  2. Niejednokrotnie wygląd lub struktura danych zmienia się, gdy przemieszczają się z jednego modułu do drugiego. Niektóre wartości są dołączane lub usuwane, co powoduje problemy w późniejszych modułach.
  3. Moduły współdziałają również z niektórymi narzędziami lub interfejsami API stron trzecich, które również muszą zostać przetestowane, czy dane akceptowane przez ten interfejs API / narzędzie są poprawne i czy wygenerowana odpowiedź jest również zgodna z oczekiwaniami.
  4. Bardzo częsty problem podczas testowania - Częsta zmiana wymagań! :) Wiele razy deweloper wdraża zmiany bez testowania jednostkowego. Testowanie integracyjne staje się wtedy ważne.

Zalety

Jest kilka zalet tego testu, a kilka z nich wymieniono poniżej.

  • To testowanie zapewnia, że ​​zintegrowane moduły / komponenty działają poprawnie.
  • Testowanie integracyjne można rozpocząć, gdy dostępne będą testowane moduły. Nie wymaga ukończenia drugiego modułu w celu wykonania testów, ponieważ kody skrócone i sterowniki mogą być używane do tego samego.
  • Wykrywa błędy związane z interfejsem.

Wyzwania

Poniżej wymieniono kilka wyzwań związanych z testem integracji.

# 1) Testowanie integracyjne oznacza testowanie dwóch lub więcej zintegrowanych systemów w celu upewnienia się, że system działa poprawnie. Należy przetestować nie tylko łącza integracyjne, ale także wyczerpujące testy uwzględniające środowisko, aby upewnić się, że zintegrowany system działa poprawnie.

Mogą istnieć różne ścieżki i permutacje, które można zastosować do testowania zintegrowanego systemu.

#dwa) Zarządzanie testami integracyjnymi staje się skomplikowane z powodu kilku czynników związanych z tym, takich jak baza danych, platforma, środowisko itp.

# 3) Integracja każdego nowego systemu ze starszym systemem wymaga wielu zmian i wysiłków testowych. To samo dotyczy integracji dowolnych dwóch starszych systemów.

# 4) Integracja dwóch różnych systemów opracowanych przez dwie różne firmy jest dużym wyzwaniem, ponieważ nie ma pewności, jak jeden z systemów wpłynie na drugi system, jeśli w którymkolwiek z nich zostaną wprowadzone jakiekolwiek zmiany.

Aby zminimalizować wpływ podczas tworzenia systemu, należy wziąć pod uwagę kilka rzeczy, takich jak możliwa integracja z innymi systemami itp.

Rodzaje testów integracyjnych

Poniżej podano rodzaj integracji testów wraz z jej zaletami i wadami.

Podejście Big Bang:

Podejście Big Bang integruje wszystkie moduły za jednym zamachem, tj. Nie polega na integracji modułów jeden po drugim. Weryfikuje, czy system działa zgodnie z oczekiwaniami, czy nie po integracji. Jeśli jakikolwiek problem zostanie wykryty w całkowicie zintegrowanym module, trudno będzie ustalić, który moduł spowodował problem.

Podejście Big Bang to czasochłonny proces znajdowania modułu, który sam ma defekt, ponieważ zajmie to trochę czasu, a po wykryciu defektu naprawienie tego samego kosztowałoby dużo, ponieważ defekt zostanie wykryty na późniejszym etapie.

Podejście Big Bang

Zalety podejścia Big Bang:

  • To dobre podejście do małych systemów.

Wady podejścia Big Bang:

  • Trudno jest wykryć moduł, który powoduje problem.
  • Podejście Big Bang wymaga wszystkich modułów razem do testowania, co z kolei prowadzi do skrócenia czasu testowania, ponieważ projektowanie, rozwój i integracja zajmowałyby większość czasu.
  • Testowanie odbywa się tylko od razu, co nie pozostawia czasu na samodzielne testowanie krytycznych modułów.

Kroki testowania integracji:

  1. Przygotuj integrację Plan testów.
  2. Przygotuj scenariusze testów i przypadki testowe integracji.
  3. Przygotuj skrypty automatyzacji testów.
  4. Wykonuj przypadki testowe.
  5. Zgłoś wady.
  6. Śledź i ponownie testuj usterki.
  7. Ponowne testowanie i testowanie trwa do zakończenia testów integracyjnych.

Podejścia do integracji testów

Istnieją zasadniczo 2 podejścia do integracji testów:

  1. Podejście oddolne
  2. Podejście odgórne.

Rozważmy poniższy rysunek, aby przetestować podejścia:

Integracja 1

Podejście oddolne:

Testowanie oddolne, jak sugeruje nazwa, zaczyna się od najniższej lub najbardziej wewnętrznej jednostki aplikacji i stopniowo przesuwa się w górę. Testy integracyjne rozpoczynają się od najniższego modułu i stopniowo przechodzą w kierunku wyższych modułów aplikacji. Ta integracja trwa do momentu zintegrowania wszystkich modułów i przetestowania całej aplikacji jako pojedynczej jednostki.

W tym przypadku moduły B1C1, B1C2 i B2C1, B2C2 są najniższymi modułami, które są testowane jednostkowo. Moduły B1 i B2 nie zostały jeszcze opracowane. Funkcjonalność modułu B1 i B2 polega na tym, że wywołuje on moduły B1C1, B1C2 i B2C1, B2C2. Ponieważ B1 i B2 nie zostały jeszcze opracowane, potrzebowalibyśmy jakiegoś programu lub „stymulatora”, który będzie nazywał moduły B1C1, B1C2 i B2C1, B2C2. Te programy stymulujące nazywają się KIEROWCY .

W prostych słowach 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. Technika oddolna wymaga, aby sterownik modułu przekazywał dane wejściowe przypadku testowego do interfejsu testowanego modułu.

Zaletą tego podejścia jest to, że jeśli poważny błąd występuje w najniższej jednostce programu, łatwiej jest go wykryć i można podjąć działania naprawcze.

Wadą jest to, że główny program faktycznie nie istnieje, dopóki ostatni moduł nie zostanie zintegrowany i przetestowany. W rezultacie wady projektowe wyższego poziomu zostaną wykryte dopiero na końcu.

Podejście odgórne

Ta technika zaczyna się od najwyższego modułu i stopniowo przechodzi w niższe moduły. Tylko moduł górny jest testowany oddzielnie. Następnie dolne moduły są integrowane jeden po drugim. Proces jest powtarzany, aż wszystkie moduły zostaną zintegrowane i przetestowane.

najlepsze oprogramowanie do odzyskiwania usuniętych plików

W kontekście naszego rysunku, testowanie zaczyna się od modułu A, a niższe moduły B1 i B2 są zintegrowane jeden po drugim. Tutaj dolne moduły B1 i B2 nie są faktycznie dostępne do integracji. Aby przetestować najwyższe moduły A, opracowujemy „ STUBS ”.

„Stubs” można określić jako fragment kodu, który akceptuje dane wejściowe / żądania z modułu głównego i zwraca wyniki / odpowiedź. W ten sposób pomimo braku niższych modułów jesteśmy w stanie przetestować moduł górny.

W praktycznych scenariuszach zachowanie kodów pośredniczących nie jest takie proste, jak się wydaje. W dobie złożonych modułów i architektury, zwany modułem, w większości przypadków obejmuje złożoną logikę biznesową, taką jak połączenie z bazą danych. W rezultacie tworzenie Stubów staje się tak złożone i czasochłonne, jak prawdziwy moduł. W niektórych przypadkach moduł Stub może okazać się większy niż moduł stymulowany.

Zarówno Stuby, jak i sterowniki są fałszywymi fragmentami kodu używanymi do testowania „nieistniejących” modułów. Wyzwalają funkcje / metody i zwracają odpowiedź, która jest porównywana z oczekiwanym zachowaniem

Podsumujmy pewną różnicę między Stubs and Driver :

StubsKierowca
Używany w podejściu odgórnymUżywany w podejściu oddolnym
Najwyższy moduł jest testowany jako pierwszyNajniższe moduły są testowane jako pierwsze.
Stymuluje niższy poziom składnikówStymuluje wyższy poziom składników
Fikcyjny program komponentów niższego poziomuFikcyjny program dla komponentu wyższego poziomu

Jedyną zmianą na tym świecie jest Stała, więc mamy inne podejście zwane „ Testowanie kanapkowe ”, Która łączy cechy podejścia odgórnego i oddolnego. Kiedy testujemy ogromne programy, takie jak systemy operacyjne, musimy mieć więcej technik, które są wydajne i zwiększają pewność siebie. Testowanie warstwowe odgrywa tutaj bardzo ważną rolę, gdzie jednocześnie rozpoczyna się testowanie odgórne i oddolne.

Integracja rozpoczyna się od warstwy środkowej i porusza się jednocześnie w górę iw dół. W przypadku naszej figury nasze testy zaczną się od B1 i B2, gdzie jedno ramię przetestuje górny moduł A, a drugie ramię przetestuje dolne moduły B1C1, B1C2 i B2C1, B2C2.

Ponieważ obie metody rozpoczynają się jednocześnie, technika ta jest nieco złożona i wymaga większej liczby osób oraz określonych zestawów umiejętności, a tym samym zwiększa koszty.

Test integracji aplikacji GUI

Porozmawiajmy teraz o tym, jak możemy implikować testowanie integracji w technice czarnej skrzynki.

Wszyscy rozumiemy, że aplikacja internetowa jest aplikacją wielowarstwową. Mamy interfejs, który jest widoczny dla użytkownika, mamy warstwę środkową, która ma logikę biznesową, mamy więcej warstwy środkowej, która przeprowadza pewne walidacje, integruje niektóre interfejsy API stron trzecich itp., A następnie mamy warstwę tylną, która jest Baza danych.

Przykład testowania integracji:

Sprawdźmy poniższy przykład:

Jestem właścicielem firmy reklamowej i zamieszczam ogłoszenia na różnych stronach internetowych. Pod koniec miesiąca chcę sprawdzić, ile osób widziało moje reklamy i ile kliknęło moje reklamy. Potrzebuję raportu z wyświetlanych reklam i naliczam odpowiednią opłatę moim klientom.

Oprogramowanie GenNext opracował dla mnie ten produkt, a poniżej była architektura:

Integracja 2

CEBULA - Moduł interfejsu użytkownika, który jest widoczny dla użytkownika końcowego, w którym podane są wszystkie wejścia.
BL - Jest to moduł Business Logic, który zawiera wszystkie obliczenia i metody biznesowe.
VAL - Jest modułem walidacji, który posiada wszystkie walidacje poprawności danych wejściowych.
CNT - Jest to moduł treści, który ma całą zawartość statyczną, specyficzną dla danych wejściowych wprowadzonych przez użytkownika. Te treści są wyświetlane w raportach.
W - Jest to moduł Engine, ten moduł odczytuje wszystkie dane, które pochodzą z modułu BL, VAL i CNT i wyodrębnia zapytanie SQL i wyzwala je do bazy danych.
Planista - to moduł, który planuje wszystkie raporty na podstawie wyboru użytkowników (miesięczne, kwartalne, półroczne i roczne)
DB - Czy baza danych.

Teraz, widząc architekturę całej aplikacji internetowej jako pojedynczej jednostki, testy integracji w tym przypadku skupią się na przepływie danych między modułami.

Oto pytania:

  1. W jaki sposób moduł BL, VAL i CNT będą odczytywać i interpretować dane wprowadzone w module UI?
  2. Czy moduł BL, VAL i CNT otrzymuje prawidłowe dane z interfejsu użytkownika?
  3. W jakim formacie dane z BL, VAL i CNT są przesyłane do modułu EQ?
  4. W jaki sposób EQ odczyta dane i wyodrębni zapytanie?
  5. Czy zapytanie zostało poprawnie wyodrębnione?
  6. Czy harmonogram pobiera prawidłowe dane do raportów?
  7. Czy zestaw wyników otrzymany przez EN z bazy danych jest poprawny i zgodny z oczekiwaniami?
  8. Czy EN jest w stanie wysłać odpowiedź z powrotem do modułu BL, VAL i CNT?
  9. Czy moduł UI jest w stanie odczytać dane i odpowiednio wyświetlić je w interfejsie?

W prawdziwym świecie przesyłanie danych odbywa się w formacie XML. Więc jakiekolwiek dane, które użytkownik wprowadzi do interfejsu użytkownika, zostaną przekonwertowane na format XML.

W naszym scenariuszu dane wprowadzone w module UI są konwertowane do pliku XML, który jest interpretowany przez 3 moduły BL, VAL i CNT. Moduł EN odczytuje wynikowy plik XML wygenerowany przez 3 moduły i wyodrębnia z niego kod SQL i zapytania do bazy danych. Moduł EN również otrzymuje zestaw wyników i konwertuje go na plik XML i zwraca go z powrotem do modułu UI, który konwertuje wyniki w formie czytelnej dla użytkownika i wyświetla je.

W środku mamy moduł harmonogramu, który odbiera zestaw wyników z modułu EN, tworzy i planuje raporty.

Gdzie więc pojawia się testowanie integracyjne?

Cóż, sprawdzenie, czy informacje / dane przepływają poprawnie, czy nie, będzie testem integracyjnym, który w tym przypadku będzie sprawdzaniem poprawności plików XML. Czy pliki XML są generowane poprawnie? Czy mają prawidłowe dane? Czy dane są prawidłowo przesyłane z jednego modułu do drugiego? Wszystkie te rzeczy zostaną przetestowane w ramach testów integracyjnych.

Spróbuj wygenerować lub pobrać pliki XML, zaktualizuj tagi i sprawdź zachowanie. Jest to coś zupełnie innego niż zwykłe testowanie, które zwykle przeprowadzają testerzy, ale zwiększy to wiedzę testerów i zrozumienie aplikacji.

Kilka innych przykładowych warunków testowych może wyglądać następująco:

  • Czy opcje menu generują prawidłowe okno?
  • Czy okna mogą wywołać testowane okno?
  • Dla każdego okna określ wywołania funkcji dla okna, na które aplikacja powinna zezwalać.
  • Zidentyfikuj wszystkie wywołania z okna do innych funkcji, na które aplikacja powinna zezwalać
  • Identyfikuj wywołania odwracalne: zamknięcie wywoływanego okna powinno powrócić do okna wywołania.
  • Identyfikuj nieodwracalne wywołania: wywołanie okna zamyka się, zanim pojawi się wywoływane okno.
  • Przetestuj różne sposoby wykonywania wywołań w innym oknie, np. - menu, przyciski, słowa kluczowe.

Kroki do rozpoczęcia testów integracyjnych

  1. Zapoznaj się z architekturą swojej aplikacji.
  2. Zidentyfikuj moduły
  3. Zrozum, co robi każdy moduł
  4. Dowiedz się, w jaki sposób dane są przesyłane z jednego modułu do drugiego.
  5. Zrozum, w jaki sposób dane są wprowadzane i odbierane w systemie (punkt wejścia i punkt wyjścia aplikacji)
  6. Segreguj aplikację, aby odpowiadała Twoim potrzebom testowym.
  7. Zidentyfikuj i utwórz warunki testowe
  8. Przyjmuj jeden warunek naraz i zapisz przypadki testowe.

Kryteria wejścia / wyjścia dla testów integracyjnych

Kryteria wejścia:

  • Dokument planu testów integracyjnych zostaje podpisany i zatwierdzony.
  • Przygotowano testy integracji.
  • Dane testowe zostały utworzone.
  • Testów jednostkowych opracowanych modułów / komponentów jest kompletna.
  • Wszystkie krytyczne usterki o wysokim priorytecie są zamknięte.
  • Środowisko testowe jest skonfigurowane do integracji.

Kryteria wyjścia:

  • Wszystkie przypadki testów integracji zostały wykonane.
  • Żadne krytyczne i priorytetowe usterki P1 i P2 nie są otwierane.
  • Raport z testu został przygotowany.

Przypadki testów integracji

Przypadki testów integracji koncentrują się głównie na interfejs między modułami, zintegrowane łącza, transfer danych między modułami jako moduły / komponenty, które zostały już przetestowane jednostkowo, tj. funkcjonalność i inne aspekty testowania zostały już uwzględnione.

Tak więc głównym pomysłem jest sprawdzenie, czy integracja dwóch modułów roboczych działa zgodnie z oczekiwaniami po integracji.

Na przykład przypadki testów integracji dla aplikacji Linkedin obejmują:

  • Weryfikacja łącza interfejsu pomiędzy stroną logowania a stroną główną, czyli gdy użytkownik wprowadzi dane uwierzytelniające i loguje się, powinien zostać przekierowany na stronę główną.
  • Weryfikacja łącza interfejsu między stroną główną a stroną profilu, tj. Strona profilu powinna się otworzyć.
  • Sprawdź łącze interfejsu między stroną sieciową a stronami połączenia, tj. Kliknięcie przycisku akceptacji na Zaproszeniach strony sieciowej powinno po kliknięciu wyświetlić zaakceptowane zaproszenie na stronie połączenia.
  • Sprawdź łącze interfejsu między stronami powiadomień i przycisk „gratulacje”, tj. Kliknięcie przycisku „gratulacje” powinno kierować do nowego okna wiadomości.

Dla tej konkretnej witryny można napisać wiele przypadków testów integracji. Powyższe cztery punkty to tylko przykład pozwalający zrozumieć, jakie przypadki testowe integracji są zawarte w testowaniu.

Czy integracja jest techniką białej czy czarnej skrzynki?

Technikę testowania integracji można policzyć zarówno w czarnych skrzynkach, jak i technika białej skrzynki . Technika czarnej skrzynki to sytuacja, w której tester nie musi mieć żadnej wewnętrznej wiedzy o systemie, tj. znajomość kodowania nie jest wymagana, podczas gdy technika białej skrzynki wymaga wewnętrznej wiedzy o aplikacji.

Teraz, podczas przeprowadzania testów integracyjnych, może obejmować testowanie dwóch zintegrowanych usług internetowych, które będą pobierać dane z bazy danych i dostarczać dane zgodnie z wymaganiami, co oznacza, że ​​można je przetestować za pomocą techniki testowania białej skrzynki, podczas gdy można przetestować integrację nowej funkcji w witrynie używając techniki czarnej skrzynki.

Tak więc nie jest specyficzne, że testowanie integracji jest techniką czarnej lub białej skrzynki.

Narzędzia do testowania integracji

Dostępnych jest kilka narzędzi do tego testowania.

Poniżej podano listę narzędzi:

  • Rational Integration Tester
  • Kątomierz
  • Parowy
  • TESSY

Aby uzyskać więcej informacji na temat powyższych narzędzi, zapoznaj się z tym samouczkiem:

10 najlepszych narzędzi do testowania integracji do pisania testów integracji

Testowanie integracji systemów

Test integracji systemu jest wykonywany w celu przetestowania kompletny zintegrowany system .

Moduły lub komponenty są testowane indywidualnie w ramach testów jednostkowych przed integracją komponentów.

Po przetestowaniu wszystkich modułów testowanie integracji systemu odbywa się poprzez integrację wszystkich modułów, a system jako całość jest testowany.

Różnica między testowaniem integracyjnym a testowaniem systemu

Testowanie integracyjne to testowanie, w którym jeden lub dwa moduły, które są testowane jednostkowo, są integrowane w celu testowania, a weryfikacja jest wykonywana w celu sprawdzenia, czy zintegrowane moduły działają zgodnie z oczekiwaniami, czy nie.

Testowanie systemu to testowanie, w którym system jako całość jest testowany, tj. wszystkie moduły / komponenty są ze sobą zintegrowane w celu sprawdzenia, czy system działa zgodnie z oczekiwaniami i czy nie występują problemy z powodu zintegrowanych modułów.

Wniosek

Chodzi o testy integracyjne i ich implementację zarówno w technice białej, jak i czarnej skrzynki. Mam nadzieję, że wyjaśniliśmy to jasno za pomocą odpowiednich przykładów.

Integracja testów jest ważną częścią cyklu testowania, ponieważ ułatwia znalezienie defektu, gdy dwa lub więcej modułów jest zintegrowanych w celu zintegrowania wszystkich modułów w pierwszym etapie.

Pomaga w wykrywaniu defektów na wczesnym etapie, co z kolei oszczędza wysiłek i koszty. Zapewnia, że ​​zintegrowane moduły działają prawidłowo zgodnie z oczekiwaniami.

Mam nadzieję, że ten samouczek informacyjny na temat testowania integracji wzbogaciłby Twoją wiedzę na temat tej koncepcji.

rekomendowane lektury

^