Czym jest SIT? Testowanie integracji systemów z przykładem

Co to jest testowanie integracji systemu?

Konfiguracja Testy integracyjne definiuje się jako rodzaj testowania oprogramowania przeprowadzanego w zintegrowanym środowisku sprzętu i oprogramowania w celu sprawdzenia zachowania całego systemu. Jest to testowanie przeprowadzane na kompletnym, zintegrowanym systemie w celu oceny zgodności systemu z określonymi wymaganiami.

Testowanie integracji systemów (SIT) przeprowadza się w celu weryfikacji interakcji między modułami systemu oprogramowania. Polega ono na weryfikacji wymagań wysokiego i niskiego poziomu oprogramowania określonych w Specyfikacji/Danych Wymagań Oprogramowania oraz Dokumencie Projektowym Oprogramowania.

SIT weryfikuje również współistnienie systemu oprogramowania z innymi systemami oraz testuje interfejs między modułami aplikacji. W tym typie testowania moduły są najpierw testowane indywidualnie, a następnie łączone w system. Na przykład, komponenty oprogramowania i/lub sprzętu są łączone i testowane stopniowo, aż do zintegrowania całego systemu.

Powyższy diagram przedstawia postęp, który definiuje SIT: oddzielnie weryfikowane moduły są scalane krok po kroku, aż do momentu, gdy pojedynczy, zintegrowany system pozostaje poddawany testom.

Dlaczego warto testować integrację systemu?

W inżynierii oprogramowania testowanie integracji systemów odbywa się, ponieważ:

• Pomaga wykryć Wada wcześnie
• Wcześniejsza informacja zwrotna na temat akceptowalności poszczególnych modułów będzie dostępna
• Planowanie napraw defektów jest elastyczne i może pokrywać się z rozwojem
• Prawidłowy przepływ danych
• Prawidłowy przepływ sterowania
• Prawidłowy czas
• Prawidłowe wykorzystanie pamięci
• Skoryguj wymaganiami oprogramowania

Testowanie integracji systemów a testowanie systemowe a testowanie akceptacji użytkownika

Ponieważ te trzy poziomy następują jeden po drugim, często są mylone. Testowanie systemu bada jedną ukończoną kompilację pod kątem jej wymagań, SIT bada połączenia między kompilacjami i Testów akceptacyjnych użytkownika Analizuje kondycję firmy z punktu widzenia klienta. Poniższa tabela je rozdziela.

Parametr	Testowanie integracji systemu	Testowanie systemu	Testów akceptacyjnych użytkownika
Głowny cel	Interfejsy i przepływ danych pomiędzy zintegrowanymi modułami	Zachowanie całościowo zmontowanej kompilacji	Kondycja biznesowa do rzeczywistego użytku
Poziom testowania	Poziom drugi	Poziom trzeci	Poziom końcowy przed uruchomieniem
Technika	Czarna skrzynka	Czarne pudełko, białe pudełko lub szare pudełko	Czarna skrzynka
Wykonane przez	Testerzy integracyjni i programiści	Niezależny zespół testowy	Klienci lub użytkownicy końcowi
Typowe wady	Interfejs, synchronizacja, pamięć i mapa danychping błędy	Błędy funkcjonalne i niefunkcjonalne systemu	Niedopasowanie użyteczności i wymagań
Działa, gdy	Po Testów jednostkowych	Po SIT	Po testach systemowych

Kolejność ma znaczenie. Moduły przechodzą testy jednostkowe, SIT weryfikuje interfejsy, testowanie systemowe weryfikuje zmontowany produkt, a UAT potwierdza, że ​​produkt spełnia oczekiwania biznesowe. Pomińping SIT przekazuje wady interfejsu do testów UAT, gdzie każda poprawka kosztuje o wiele więcej.

Jak przeprowadzić test integracji systemu

Jest to systematyczna technika konstruowania struktury programu przy jednoczesnym przeprowadzaniu testów mających na celu wykrycie błędów związanych z interfejsem.

Wszystkie moduły są z góry zintegrowane, a cały program jest testowany jako całość. Jednak podczas tego procesu prawdopodobnie napotkany zostanie zestaw błędów.

Korygowanie takich błędów jest trudne, gdyż izolowanie przyczyn komplikuje rozległa rozbudowa całego programu. Gdy te błędy zostaną naprawione i poprawione, pojawi się nowy, a proces będzie przebiegał płynnie w nieskończonej pętli. Aby uniknąć tej sytuacji, stosuje się inne podejście – integrację przyrostową. Podejście przyrostowe zostanie szczegółowo wyjaśnione w następnej sekcji.

Istnieją metody przyrostowe, takie jak testy integracyjne przeprowadzane na systemie opartym na docelowym procesorze. Zastosowana metodologia to Czarny Box Testy. Można zastosować integrację oddolną lub odgórną.

Przypadki testowe są definiowane wyłącznie przy użyciu wymagań oprogramowania wysokiego poziomu.

Integrację oprogramowania można również osiągnąć głównie w środowisku hosta, przy czym w hoście nadal symuluje się jednostki specyficzne dla środowiska docelowego. Ponownie konieczne będzie powtórzenie testów w środowisku docelowym w celu potwierdzenia.

Testy potwierdzające na tym poziomie pozwolą zidentyfikować problemy specyficzne dla danego środowiska, takie jak błędy w alokacji i zwalnianiu pamięci. Praktyczność integracji oprogramowania w środowisku hosta będzie zależeć od zakresu funkcjonalności specyficznych dla danego systemu docelowego. W przypadku niektórych systemów wbudowanych sprzężenie ze środowiskiem docelowym będzie bardzo silne, co uniemożliwi przeprowadzenie integracji oprogramowania w środowisku hosta.

Duże zmiany w oprogramowaniu podzielą integrację oprogramowania na szereg poziomów. Niższe poziomy integracji oprogramowania mogą być oparte głównie na środowisku hosta, a późniejsze poziomy integracji oprogramowania mogą stawać się bardziej zależne od środowiska docelowego.

Uwaga: Jeśli testowane jest tylko oprogramowanie, nazywa się to testowaniem integracji oprogramowania [SSIT], a jeśli testowany jest zarówno sprzęt, jak i oprogramowanie, nazywa się to testowaniem integracji oprogramowania sprzętowego [HSIT].

Podejście przyrostowe

Ponieważ integrowanie wszystkiego naraz utrudnia izolowanie defektów, większość zespołów stosuje opisaną tutaj metodę przyrostową.

Testowanie przyrostowe to metoda testowania integracyjnego. W tego typu metodzie testowania najpierw testujesz każdy moduł oprogramowania indywidualnie, a następnie kontynuujesz testowanie, dołączając do niego kolejne moduły, potem kolejne i tak dalej.

Integracja przyrostowa jest przeciwieństwem podejścia opartego na wielkim wybuchu. Program jest konstruowany i testowany w małych segmentach, w których błędy są łatwiejsze do wyizolowania i poprawienia. Istnieje większe prawdopodobieństwo, że interfejsy zostaną całkowicie przetestowane i można zastosować systematyczne podejście testowe.

Istnieją dwa rodzaje testów przyrostowych

• Podejście od góry do dołu
• Podejście oddolne

Podejście odgórne

W tego typu podejściu każdy zaczyna od przetestowania tylko interfejsu użytkownika z podstawową funkcjonalnością symulowaną za pomocą kodów pośredniczących, a następnie przechodzi w dół, integrując coraz niższe warstwy, jak pokazano na poniższym obrazku.

• Począwszy od głównego modułu sterującego, moduły są integrowane poprzez przechodzenie w dół hierarchii sterowania
• Podmoduły głównego modułu sterującego są włączane do konstrukcji albo wszerz, albo w głąb.
• Integracja w głąb integruje wszystkie moduły na głównej ścieżce sterowania struktury, jak pokazano na poniższym schemacie:

Proces integracji modułów przebiega w następujący sposób:

1. Główny moduł sterujący pełni funkcję sterownika testowego, a odgałęzienia zastępują wszystkie moduły bezpośrednio podporządkowane głównemu modułowi sterującemu.
2. Podrzędne odcinki są zastępowane pojedynczo rzeczywistymi modułami, w zależności od wybranego podejścia (najpierw szerokość lub głębokość).
3. Testy są wykonywane po zintegrowaniu każdego modułu.
4. Po zakończeniu każdego zestawu testów kolejny odcinek końcowy jest zastępowany prawdziwym modułem po zakończeniu każdego zestawu testów
5. Aby mieć pewność, że nie zostały wprowadzone nowe błędy Testy regresji można wykonać.

Proces trwa od kroku 2 aż do zbudowania całej struktury programu. Strategia odgórna wydaje się stosunkowo nieskomplikowana, jednak w praktyce pojawiają się problemy logistyczne.

Najczęstsze z tych problemów występują, gdy wymagane jest przetwarzanie na niższych poziomach hierarchii, aby odpowiednio przetestować wyższe poziomy.

Stuby zastępują moduły niskiego poziomu na początku testowania odgórnego i dlatego żadne istotne dane nie mogą przepływać w górę struktury programu.

Wyzwania, przed którymi może stanąć Tester:

• Opóźnij wiele testów do czasu zastąpienia fragmentów rzeczywistymi modułami.
• Opracuj kody pośredniczące, które wykonują ograniczone funkcje symulujące rzeczywisty moduł.
• Integruj oprogramowanie od dołu hierarchii w górę.

Uwaga: Pierwsze podejście powoduje, że tracimy kontrolę nad zgodnością pomiędzy konkretnymi testami a włączeniem konkretnych modułów. Może to skutkować trudnościami w określeniu przyczyny błędów, co zwykle narusza wysoce ograniczony charakter podejścia odgórnego.

Drugie podejście jest wykonalne, ale może wiązać się ze znacznym obciążeniem, ponieważ szkielety stają się coraz bardziej złożone.

Podejście oddolne

Integracja oddolna rozpoczyna budowę i testowanie modułów na najniższym poziomie struktury programu. W tym procesie moduły są integrowane od dołu do góry.

W tym podejściu obróbka wymagana dla modułów podległych danemu poziomowi jest zawsze dostępna i eliminuje potrzebę stosowania odcinków pośrednich.

Ten proces testu integracji jest wykonywany w serii czterech kroków

1. Moduły niskiego poziomu są łączone w klastry realizujące określone podfunkcje oprogramowania.
2. Napisano sterownik w celu koordynowania danych wejściowych i wyjściowych przypadków testowych.
3. Przeprowadzono test klastra lub kompilacji.
4. Sterowniki są usuwane, a klastry są łączone i przesuwane w górę struktury programu.

Wraz z postępem integracji w górę, rośnie potrzeba oddzielnych lekcji dotyczących sterowników testowych. W rzeczywistości, jeśli dwa najwyższe poziomy struktury programu zostaną zintegrowane odgórnie, liczba sterowników może zostać znacznie zmniejszona, a integracja klastrów znacznie uproszczona. Integracja przebiega zgodnie ze schematem przedstawionym poniżej.

Uwaga: Jeśli dwa najwyższe poziomy struktury programu zostaną zintegrowane od góry do dołu, można znacznie zmniejszyć liczbę sterowników, a integracja kompilacji zostanie znacznie uproszczona.

Podejście Wielkiego Wybuchu

W tym podejściu wszystkie moduły nie są integrowane, dopóki wszystkie moduły nie będą gotowe. Kiedy już będą gotowe, wszystkie moduły są integrowane, a następnie wykonywane, aby wiedzieć, czy wszystkie zintegrowane moduły działają, czy nie.

W tym podejściu trudno jest poznać pierwotną przyczynę awarii, ponieważ integruje się wszystko na raz.

Ponadto będzie duże prawdopodobieństwo wystąpienia błędów krytycznych w środowisku produkcyjnym.

Podejście to stosuje się tylko wtedy, gdy konieczne jest natychmiastowe wykonanie testów integracyjnych.

Testowanie integracji oprogramowania sprzętowego

Testowanie integracji oprogramowania sprzętowego to proces testowania komponentów oprogramowania komputerowego (CSC) pod kątem funkcjonalności wysokiego poziomu w docelowym środowisku sprzętowym. Celem testów integracji sprzętu i oprogramowania jest przetestowanie zachowania opracowanego oprogramowania zintegrowanego z komponentem sprzętowym.

Testowanie integracji sprzętu i oprogramowania oparte na wymaganiach

Celem testów integracji sprzętu i oprogramowania opartych na wymaganiach jest upewnienie się, że oprogramowanie na komputerze docelowym spełni wymagania wysokiego poziomu. Typowe błędy wykrywane przez tę metodę testowania obejmują:

• Błędy interfejsów sprzętowych/programowych
• Naruszenia partycjonowania oprogramowania.
• Brak możliwości wykrycia awarii za pomocą wbudowanego testu
• Nieprawidłowa reakcja na awarie sprzętu
• Błąd wynikający z kolejności, przejściowych obciążeń wejściowych i przejściowych mocy wejściowych
• Nieprawidłowe zachowanie w pętli sprzężenia zwrotnego
• Nieprawidłowa lub niewłaściwa kontrola sprzętu zarządzającego pamięcią
• Problem z rywalizacją o magistralę danych
• Nieprawidłowe działanie mechanizmu weryfikującego zgodność i poprawność oprogramowania ładowalnego w terenie

Integracja oprogramowania sprzętowego zajmuje się weryfikacją wymagań wysokiego poziomu. Wszystkie testy na tym poziomie przeprowadzane są na sprzęcie docelowym.

• Na tym poziomie testowania podstawową metodologią testowania jest testowanie metodą czarnej skrzynki.
• określić przypadki testowe wyłącznie z wymagań wysokiego poziomu
• Test należy przeprowadzić na standardowym sprzęcie produkcyjnym (w miejscu docelowym)

Rzeczy do rozważenia podczas projektowania przypadków testowych do integracji sprzętu/oprogramowania

• Prawidłowe pozyskiwanie wszystkich danych przez oprogramowanie
• Skalowanie i zakres danych zgodnie z oczekiwaniami, od sprzętu po oprogramowanie
• Prawidłowe przesyłanie danych z oprogramowania do sprzętu
• Dane w granicach specyfikacji (normalny zakres)
• Dane poza specyfikacjami (nienormalny zakres)
• Dane graniczne
• Przerywa przetwarzanie
• Chronometraż
• Prawidłowe wykorzystanie pamięci (adresowanie, nakładanie się itp.)
• Przejścia stanów

Uwaga: W przypadku testowania przerwań wszystkie przerwania będą weryfikowane niezależnie od początkowego żądania, poprzez pełną obsługę i po zakończeniu. Przypadki testowe zostaną specjalnie zaprojektowane w celu odpowiedniego testowania przerwań.

Testowanie integracji oprogramowania z oprogramowaniem

Polega na testowaniu składnika oprogramowania komputerowego działającego w środowisku komputera hosta/docelowego, symulując jednocześnie cały system [inne CSC] i funkcjonalność wysokiego poziomu.

Koncentruje się na zachowaniu CSC w symulowanym środowisku hosta/docelowym. Podejście stosowane do integracji oprogramowania może być przyrostowe (odgórne, oddolne lub połączenie obu, zwane również podejściem kanapkowym lub hybrydowym).

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

Po ustaleniu podejścia i dwóch wariantów integracji, pozostaje pytanie, kiedy zespół może rozpocząć i kiedy zakończyć pracę. Zazwyczaj podczas testów integracyjnych stosuje się strategię ETVX (kryteria wejścia, zadania, walidacji i wyjścia).

Kryteria wejścia:

• Zakończenie Testów jednostkowych

wejścia:

• Dane dotyczące wymagań oprogramowania
• Dokument projektu oprogramowania
• Plan weryfikacji oprogramowania
• Dokumenty dotyczące integracji oprogramowania

Działalność:

• Na podstawie wymagań wysokiego i niskiego poziomu tworzymy przypadki testowe i procedury
• Łącz kompilacje modułów niskiego poziomu, które implementują wspólną funkcjonalność
• Opracuj uprząż testową
• Przetestuj kompilację
• Po pozytywnym wyniku testu kompilacja jest łączona z innymi kompilacjami i testowana, aż system zostanie zintegrowany jako całość.
• Wykonaj ponownie wszystkie testy na docelowej platformie opartej na procesorze i uzyskaj wyniki

Kryteria wyjścia:

• Pomyślne zakończenie integracji modułu Oprogramowania na docelowym sprzęcie
• Prawidłowe działanie oprogramowania zgodnie z określonymi wymaganiami

Wyjścia

• Raporty z testów integracji
• Przypadki i procedury testowe oprogramowania [SVCP].

Typowe wyzwania w testowaniu integracji systemów

Nawet przy solidnym podejściu i jasnych kryteriach wyjścia, zintegrowane środowiska stwarzają problemy, które nigdy nie ujawniają się podczas testów jednostkowych. Ich wczesne rozpoznanie pozwala zachować realistyczny harmonogram.

• Niezgodność środowiska: zintegrowany Środowisko testowe rzadko odzwierciedla produkcję, więc błędy czasowe i konfiguracyjne ujawniają się dopiero bardzo późno.
• Gotowość do uzależnienia: Interfejsy innych firm i starsze wersje są często niedokończone, co zmusza testerów do polegania na szkieletach i symulatorach znacznie dłużej, niż planowano.
• Niespójność danych: dwa moduły mogą reprezentować ten sam rekord w różny sposób, powodując ukryte niezgodności zamiast widocznych błędów.
• Własność wadliwa: gdy awaria dotyczy dwóch zespołów, analiza przyczyn źródłowych i zarządzanie defektami zauważalnie zwolnić.
• Koszt regresji: każdy nowy interfejs powiększa testy regresji pakiet, więc ręczne ponowne wykonywanie szybko staje się niemożliwe do utrzymania.

Większość z nich to ryzyko związane z harmonogramem, a nie techniczne ślepe uliczki. Uzgodnienie dat gotowości interfejsu, zakresu symulatora i odpowiedzialności za triaż usterek przed integracją pierwszej kompilacji eliminuje większość z nich. W przypadku interfejsów należących do dostawcy należy również zapisać uzgodniony format wiadomości i kontakt do eskalacji, ponieważ brak właściciela opóźnia naprawę dłużej, niż uzasadnia to defekt.

Najlepsze praktyki testowania integracji systemów

Powtarzalny cykl SIT zależy mniej od narzędzi, a bardziej od dyscypliny związanej z interfejsami, danymi i dowodami. Pięć poniższych praktyk sprawdza się zarówno w przypadku małych wersji oprogramowania wbudowanego, jak i w przypadku dużych środowisk obejmujących wielu dostawców, a każda z nich redukuje liczbę poprawek na późniejszych etapach testów.

1. Najpierw zmapuj każdy interfejs. Przed napisaniem choćby jednego przypadku testowego wypisz każdą wymianę danych, jej kierunek, protokół i właściciela.
2. Ustal priorytety według ryzyka. Zweryfikuj interfejsy przesyłające pieniądze, tożsamość lub dane regulowane przed interfejsami kosmetycznymi.
3. Zaprojektuj realistyczne dane testowe. Obejmują zakresy normalne, brzeżne i nietypowe, dzięki czemu błędy skalowania i zaokrągleń ujawniają się wcześnie.
4. Zautomatyzuj ścieżki stabilne. Interfejs przewodowy sprawdza się w ciągła integracja potoku, dzięki czemu każda kompilacja wymaga ich ponownej weryfikacji.
5. Zachowaj dowody tracmożliwy. Połącz każdy wynik z wymaganiem za pomocą tracmacierz możliwości więc kryteria wyjścia można udowodnić, a nie twierdzić.

⚠ Wskazówka: Zablokuj specyfikacje interfejsu przed rozpoczęciem integracji. Późna zmiana formatu komunikatu unieważnia przypadki testowe po obu stronach interfejsu i jest najczęstszą przyczyną przeróbek SIT.

FAQ