Co to jest System Integration Testing?
System Integration Testing (SIT) to całościowe testowanie całego systemu, który składa się z wielu podsystemów. Głównym celem SIT jest zapewnienie, że wszystkie zależności pomiędzy modułami oprogramowania funkcjonują prawidłowo, a integralność danych jest zachowana pomiędzy różnymi modułami całego systemu.
SUT (System Under Test) może składać się ze sprzętu, bazy danych, oprogramowania, kombinacji sprzętu i oprogramowania lub systemu, który wymaga interakcji człowieka (HITL – Human in the Loop Testing).
W kontekście inżynierii oprogramowania i testowania oprogramowania, SIT może być rozpatrywany jako proces testowania, który sprawdza współwystępowanie systemu oprogramowania z innymi.
SIT ma warunek wstępny, w którym wiele bazowych zintegrowanych systemów już przeszło i przeszło testy systemowe. SIT testuje następnie wymagane interakcje pomiędzy tymi systemami jako całością. Rezultaty SIT są przekazywane do UAT (User Acceptance Testing).
Potrzeba Testu Integracji Systemu
Główną funkcją SIT jest testowanie zależności pomiędzy różnymi komponentami systemu i stąd, testowanie regresji jest ważną częścią SIT.
Dla projektów zespołowych, SIT jest częścią STLC (Software Testing lifecycle). Generalnie, runda pre-SIT jest przeprowadzana przez dostawcę oprogramowania, zanim klient uruchomi swoje własne przypadki testowe SIT.
W większości organizacji pracujących w projektach IT według modelu Agile sprint, runda SIT jest przeprowadzana przez zespół QA przed każdym wydaniem. Defekty wykryte podczas SIT są odsyłane do zespołu deweloperskiego, który pracuje nad poprawkami.
Wydanie MVP (Minimum Viable Product) ze sprintu udaje się tylko wtedy, gdy przejdzie przez SIT.
SIT jest wymagany, aby ujawnić błędy, które występują, gdy interakcja zachodzi pomiędzy zintegrowanymi podsystemami.
W systemie używanych jest kilka komponentów i nie mogą one być testowane jednostkowo. Nawet jeśli jednostka jest testowana indywidualnie, to również istnieje możliwość, że może zawieść, gdy jest połączona w systemie, ponieważ istnieje wiele problemów, które powstają, gdy podsystemy wchodzą ze sobą w interakcje.
Tak więc, SIT jest bardzo wymagany do ujawnienia i naprawienia błędów przed wdrożeniem systemu u użytkownika. SIT wykrywa usterki na wczesnym etapie, a tym samym oszczędza czas i koszty naprawy później. Pomaga również uzyskać wcześniejszą informację zwrotną na temat akceptowalności modułu.
Ziarnistość SIT
SIT może być przeprowadzony na trzech różnych poziomach ziarnistości:
(i) Testowanie Wewnątrzsystemowe: Jest to niski poziom testów integracyjnych, które mają na celu połączenie modułów razem, aby zbudować zunifikowany system.
(ii) Testowanie między systemami: Jest to testowanie wysokiego poziomu, które wymaga połączenia niezależnie testowanych systemów.
(iii) Testowanie parami: Tutaj, tylko dwa wzajemnie połączone podsystemy w całym systemie są testowane w tym samym czasie. Ma to na celu zapewnienie, że te dwa podsystemy mogą funkcjonować dobrze, kiedy są połączone razem, zakładając, że inne podsystemy już działają dobrze.
Jak przeprowadzić Testy Integracji Systemu?
Najprostszym sposobem na przeprowadzenie SIT jest metoda Data-driven. Wymaga ona minimalnego użycia narzędzi do testowania oprogramowania.
Najpierw następuje wymiana danych (import i eksport danych) pomiędzy komponentami systemu, a następnie badane jest zachowanie każdego pola danych w ramach poszczególnych warstw.
Po zintegrowaniu oprogramowania, istnieją trzy główne stany przepływu danych, jak wspomniano poniżej:
#1) Stan danych w warstwie integracji
Warstwa integracji działa jako interfejs pomiędzy importem i eksportem danych. Przeprowadzenie SIT w tej warstwie wymaga podstawowej wiedzy na temat pewnych technologii, takich jak schemat (XSD), XML, WSDL, DTD i EDI.
Wykonanie wymiany danych w tej warstwie może być zbadane poprzez następujące kroki:
- Weryfikacja właściwości danych w tej warstwie względem BRD/ FRD/ TRD (dokument wymagań biznesowych/ dokument wymagań funkcjonalnych/ dokument wymagań technicznych).
- Sprawdzenie żądania usługi sieciowej przy użyciu XSD i WSDL.
- Uruchomienie kilku testów jednostkowych i walidacja mapowań danych i żądań.
- Przegląd logów oprogramowania pośredniczącego.
#2) Stan danych w warstwie bazy danych
Wykonanie SIT w tej warstwie wymaga podstawowej znajomości SQL i procedur składowanych.
Wydajność wymiany danych w tej warstwie może być zbadana poprzez następujące kroki:
- Sprawdzenie, czy wszystkie dane z warstwy integracyjnej dotarły z powodzeniem do warstwy bazy danych i czy zostały popełnione.
- Weryfikacja właściwości tabel i kolumn względem BRD/ FRD/ TRD.
- Weryfikacja ograniczeń i reguł walidacji danych zastosowanych w bazie danych zgodnie ze specyfikacją biznesową.
- Sprawdź procedury składowane pod kątem przetwarzania danych.
- Przeglądaj logi serwera.
#3) Stan danych w warstwie aplikacji
SIT może być wykonany w tej warstwie poprzez następujące kroki:
- Sprawdź czy wszystkie wymagane pola są widoczne w UI.
- Wykonaj kilka pozytywnych i negatywnych przypadków testowych i waliduj właściwości danych.
Uwaga: Może być wiele kombinacji odpowiadających importowi i eksportowi danych. Będziesz musiał wykonać SIT dla najlepszych kombinacji biorąc pod uwagę czas, który masz do dyspozycji.
Testowanie Systemu Vs Testowanie Integracji Systemu
Różnice pomiędzy Testowaniem Systemu a SIT:
| SIT (Testowanie Integracji Systemu) | Testowanie Systemu |
|---|---|
| SIT jest przeprowadzany głównie w celu sprawdzenia, jak poszczególne moduły oddziałują ze sobą, gdy są zintegrowane w system jako całość. | Testy systemowe są przeprowadzane głównie w celu sprawdzenia, czy cały system działa zgodnie z oczekiwaniami w odniesieniu do określonych wymagań. |
| Testowanie jest przeprowadzane po testach jednostkowych i będzie przeprowadzane za każdym razem, gdy nowy moduł zostanie dodany do systemu. | Testowanie jest przeprowadzane na poziomie końcowym, tj.tj. po zakończeniu testów integracyjnych i tuż przed dostarczeniem systemu do UAT. |
| Jest to testowanie niskiego poziomu. | Jest to testowanie wysokiego poziomu. |
| Przypadki testowe SIT koncentrują się na interfejsie pomiędzy komponentami systemu. | Przypadki testowe, w tym przypadku, koncentrują się na symulacji rzeczywistych scenariuszy. |
Testowanie Integracji Systemu Vs Testowanie Akceptacji Użytkownika
Tutaj jest różnica pomiędzy SIT i UAT:
| SIT (System Integration Testing) | UAT (User Acceptance Testing) |
|---|---|
| Testowanie to odbywa się z perspektywy interfejsów pomiędzy modułami. | Testowanie to jest z perspektywy wymagań użytkownika. |
| SIT jest wykonywane przez programistów i testerów. | UAT jest wykonywane przez klientów i użytkowników końcowych. |
| Dokonywany po testach jednostkowych i przed testami systemowymi. | Jest to ostatni poziom testowania i jest wykonywany po testach systemowych. |
| Generalnie, problemy znalezione w SIT byłyby związane z przepływem danych, przepływem sterowania, itp. | Zagadnienia znalezione w UAT byłyby generalnie jak funkcje, które nie działają zgodnie z wymaganiami użytkownika. |
Poniższy obrazek dotyczący poziomów testowania sprawi, że przepływ od testów jednostkowych do UAT będzie dla ciebie jasny:
Przykład SIT
Załóżmy, że firma używa oprogramowania do przechowywania danych klientów.
To oprogramowanie posiada dwa ekrany w UI – Ekran 1 & Ekran 2, oraz posiada bazę danych. Szczegóły wprowadzone w Ekranie 1 i Ekranie 2 są wprowadzane do bazy danych. Jak na razie firma jest zadowolona z tego oprogramowania.
Jednakże kilka lat później firma stwierdza, że oprogramowanie nie spełnia wymagań i istnieje potrzeba jego ulepszenia. W związku z tym opracowano Ekran 3 i bazę danych. Teraz, ten system posiadający Ekran 3 i bazę danych jest zintegrowany ze starszym/istniejącym oprogramowaniem.
Teraz, testowanie wykonywane na całym systemie po integracji nazywane jest Testem Integracji Systemu. Tutaj, współistnienie nowego systemu z istniejącym jest testowane w celu zapewnienia, że cały zintegrowany system działa dobrze.
Techniki SIT
Głównie, istnieją 4 podejścia do przeprowadzania SIT:
- Podejście odgórne
- Podejście oddolne
- Podejście kanapkowe
- Podejście wielkiego wybuchu
Podejście odgórne i podejście oddolne są rodzajami podejść przyrostowych. Zacznijmy dyskusję od podejścia Top-down.
#1) Podejście Top-Down:
W tym podejściu, testowanie rozpoczyna się od najwyższego modułu aplikacji, tj. UI, który nazywamy sterownikiem testowym.
Funkcjonalność podstawowych modułów jest symulowana za pomocą stubów. Górny moduł jest integrowany z modułem niższego poziomu jeden po drugim, a następnie funkcjonalność jest testowana.
Po zakończeniu każdego testu, stub jest zastępowany przez prawdziwy moduł. Moduły mogą być integrowane albo w sposób szeroki (breadth-first), albo w sposób głęboki (depth-first). Testy są kontynuowane aż do zbudowania całej aplikacji.
Zaletą tego podejścia jest to, że nie ma potrzeby stosowania sterowników, a przypadki testowe mogą być określone w odniesieniu do funkcjonalności systemu.
Głównym wyzwaniem w tego typu podejściu jest zależność od dostępności funkcjonalności modułów niższego poziomu. Może wystąpić opóźnienie w testach do czasu zastąpienia rzeczywistych modułów stubami. Pisanie stubów jest również trudne.
#2) Podejście oddolne:
Eliminuje ono ograniczenia podejścia odgórnego.
W tej metodzie, po pierwsze, moduły najniższego poziomu są łączone w klastry. Klastry te służą jako podfunkcje aplikacji. Następnie tworzony jest sterownik, który zarządza wejściem i wyjściem przypadku testowego. Po tym, klaster jest testowany.
Po przetestowaniu klastra, sterownik jest usuwany, a klaster jest łączony z kolejnym wyższym poziomem. Proces ten trwa aż do uzyskania całej struktury aplikacji.
W tym podejściu nie ma potrzeby stosowania stubów. Staje się on uproszczony, ponieważ przetwarzanie przesuwa się w górę, a zapotrzebowanie na sterowniki zmniejsza się. To podejście jest zalecane do robienia SIT dla systemów obiektowych, systemów czasu rzeczywistego i systemów o ścisłych wymaganiach wydajnościowych.
Jednakże ograniczeniem tego podejścia jest to, że najważniejszy podsystem, czyli UI jest testowany na końcu.
#3) Podejście kanapkowe:
Podejście top down i bottom up omówione powyżej są połączone razem.
System jest postrzegany jako posiadający trzy warstwy – warstwę środkową, która jest warstwą docelową, warstwę powyżej celu i warstwę poniżej celu. Testowanie odbywa się w obu kierunkach i gromadzi się w warstwie docelowej, która jest pośrodku i jest to zilustrowane na poniższym obrazku.
Sandwich Testing Strategy
Zaletą tego podejścia jest to, że górna i dolna warstwa systemu mogą być testowane równolegle. Jednak ograniczeniem tego podejścia jest to, że nie testuje ono w sposób wyczerpujący poszczególnych podsystemów przed integracją.
Aby wyeliminować to ograniczenie, zmodyfikowaliśmy testowanie kanapkowe, w którym integracja warstwy górnej, środkowej i dolnej jest testowana równolegle przy użyciu stubów i sterowników.
#4) Podejście Wielkiego Wybuchu:
W tym podejściu, integracja jest wykonywana, gdy wszystkie moduły aplikacji są całkowicie gotowe. Testowanie odbywa się po integracji wszystkich modułów w celu sprawdzenia, czy zintegrowany system działa, czy nie.
W tym podejściu trudno jest znaleźć przyczynę problemu, ponieważ wszystko jest zintegrowane na raz, w przeciwieństwie do testowania przyrostowego. To podejście jest ogólnie przyjęte kiedy tylko jedna runda SIT jest wymagana.
Podsumowanie
W tym artykule, dowiedzieliśmy się co to jest Testowanie Integracji Systemu (SIT) i dlaczego ważne jest jego wykonanie.
Zrozumieliśmy podstawowe koncepcje, techniki, podejścia i metody zaangażowane w wykonywanie SIT. Przeszliśmy również przez to, jak SIT różni się od UAT i testowania systemu.
Mamy nadzieję, że podobał Ci się ten wspaniały artykuł!