Co to jest testowanie integracji systemu (SIT) z przykładem

Co to jest testowanie integracji systemów?

Testowanie integracji systemu to rodzaj testów oprogramowania przeprowadzanych w zintegrowanym środowisku sprzętowo-programowym w celu sprawdzenia zachowania całego systemu. Jest to testowanie kompletnego, zintegrowanego systemu w celu oceny zgodności systemu z określonymi wymaganiami.

Testowanie integracji systemu (SIT) jest wykonywane w celu weryfikacji interakcji między modułami systemu oprogramowania. Zajmuje się weryfikacją wysokopoziomowych i niskopoziomowych wymagań oprogramowania określonych w Specyfikacji / danych wymagań oprogramowania oraz w dokumencie projektu oprogramowania.

Weryfikuje również współistnienie systemu oprogramowania z innymi i testuje interfejs między modułami aplikacji. W tego typu testach 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.

W tym samouczku nauczysz się:

• Co to jest testowanie integracji systemów?
• Dlaczego testy integracji systemów
• Jak wykonać testy integracji systemów
• Kryteria wejścia i wyjścia dla testów integracyjnych
• Testowanie integracji sprzętu z oprogramowaniem
• Oprogramowanie do testowania integracji oprogramowania
• Podejście odgórne
• Podejście oddolne
• Podejście Big Bang

Dlaczego testy integracji systemów

W inżynierii oprogramowania testowanie integracji systemów jest wykonywane, ponieważ

• Pomaga wcześnie wykryć Wadę
• Dostępna będzie wcześniejsza informacja zwrotna na temat akceptowalności poszczególnych modułów
• Planowanie poprawek defektów jest elastyczne i może nałożyć się na rozwój
• Prawidłowy przepływ danych
• Prawidłowy przepływ sterowania
• Właściwy czas
• Prawidłowe wykorzystanie pamięci
• Zgodne z wymaganiami oprogramowania

Jak wykonać testy integracji systemów

Jest to systematyczna technika konstruowania struktury programu podczas przeprowadzania testów w celu wykrycia błędów związanych z interfejsami.

Wszystkie moduły są wcześniej zintegrowane, a cały program jest testowany jako całość. Ale podczas tego procesu prawdopodobnie napotkasz zestaw błędów.

Korekta takich błędów jest trudna, ponieważ przyczyny izolacji komplikuje ogromna rozbudowa całego programu. Gdy te błędy zostaną naprawione i poprawione, pojawi się nowy, a proces będzie kontynuowany płynnie w niekończącej się pętli . Aby uniknąć takiej sytuacji, stosuje się inne podejście - integrację przyrostową. Więcej szczegółów na temat podejścia przyrostowego zobaczymy w dalszej części samouczka.

Istnieje kilka metod przyrostowych, takich jak testy integracyjne przeprowadzane w systemie opartym na procesorze docelowym. Zastosowana metodologia to testowanie czarnoskrzynkowe. 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ąć w dużej mierze w środowisku hosta, przy czym jednostki specyficzne dla środowiska docelowego nadal są symulowane na hoście. 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 środowiska, takie jak błędy w alokacji i cofaniu przydziału pamięci. Praktyczność przeprowadzania integracji oprogramowania w środowisku hosta będzie zależeć od tego, ile jest określonych funkcji docelowych. W przypadku niektórych systemów wbudowanych sprzężenie ze środowiskiem docelowym będzie bardzo silne, co sprawi, że integracja oprogramowania w środowisku hosta będzie niepraktyczna.

W przypadku dużych opracowań oprogramowania integracja oprogramowania zostanie podzielona na kilka poziomów. Niższe poziomy integracji oprogramowania mogłyby opierać się głównie na środowisku hosta, przy czym późniejsze poziomy integracji oprogramowania stawałyby się bardziej zależne od środowiska docelowego.

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

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

Zwykle podczas przeprowadzania testów integracyjnych używana jest strategia ETVX (kryteria wejścia, zadanie, walidacja i kryteria 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

Zajęcia:

• W oparciu o wymagania wysokiego i niskiego poziomu twórz przypadki testowe i procedury
• Łącz kompilacje modułów niskiego poziomu, które implementują wspólną funkcjonalność
• Opracuj uprząż testową
• Przetestuj kompilację
• Po pomyślnym zakończeniu testu kompilacja jest łączona z innymi kompilacjami i testowana, aż system zostanie zintegrowany jako całość.
• Wykonaj ponownie wszystkie testy na platformie opartej na procesorze docelowym 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].

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 / oprogramowania jest przetestowanie zachowania opracowanego oprogramowania zintegrowanego z komponentem sprzętowym.

Testowanie integracji sprzętu i oprogramowania w oparciu o wymagania

Celem testowania integracji sprzętu / oprogramowania w oparciu o wymagania jest upewnienie się, że oprogramowanie na komputerze docelowym spełnia wymagania wysokiego poziomu. Typowe błędy ujawnione przez tę metodę testowania obejmują:

• Błędy interfejsów sprzętowych / programowych
• Naruszenia zasad partycjonowania oprogramowania.
• Brak możliwości wykrycia awarii za pomocą wbudowanego testu
• Niepoprawna reakcja na awarie sprzętu
• Błąd spowodowany sekwencjonowaniem, przejściowymi obciążeniami wejściowymi i przejściami mocy wejściowej
• Informacja zwrotna zapętla nieprawidłowe zachowanie
• Niepoprawne lub niewłaściwe sterowanie sprzętem do zarządzania pamięcią
• Problem rywalizacji o magistralę danych
• Nieprawidłowe działanie mechanizmu w celu weryfikacji kompatybilności i poprawności ładowanego w terenie oprogramowania

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

• Testowanie czarnoskrzynkowe jest podstawową metodologią testowania stosowaną na tym poziomie testowania.
• Zdefiniuj przypadki testowe tylko na podstawie wymagań wysokiego poziomu
• Test należy wykonać na standardowym sprzęcie produkcyjnym (docelowo)

Kwestie do rozważenia podczas projektowania przypadków testowych dla integracji HW / SW

• Prawidłowe pozyskiwanie wszystkich danych przez oprogramowanie
• Skalowanie i zakres danych zgodnie z oczekiwaniami od sprzętu do oprogramowania
• Prawidłowe przesyłanie danych z oprogramowania do sprzętu
• Dane w ramach specyfikacji (normalny zakres)
• Dane poza specyfikacjami (nieprawidłowy zakres)
• Dane graniczne
• Przerwanie przetwarzania
• wyczucie czasu
• 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ę, aż do zakończenia. Przypadki testowe zostaną specjalnie zaprojektowane w celu odpowiedniego testowania przerwań.

Oprogramowanie do testowania integracji oprogramowania

Jest to testowanie składnika oprogramowania komputerowego działającego na komputerze głównym / docelowym

Środowisko, podczas symulacji całego systemu [inne CSC] i na wysokim poziomie funkcjonalności.

Skupia się na zachowaniu CSC w symulowanym środowisku hosta / celu. Podejście stosowane do integracji oprogramowania może być podejściem przyrostowym (odgórnym, oddolnym lub połączeniem obu).

Podejście przyrostowe

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

Integracja przyrostowa jest przeciwieństwem podejścia do wielkiego wybuchu. Program jest zbudowany i testowany w małych segmentach, gdzie błędy są łatwiejsze do wyodrębnienia i poprawienia. Istnieje większe prawdopodobieństwo, że interfejsy zostaną całkowicie przetestowane i można zastosować systematyczne podejście do testów.

Istnieją dwa rodzaje testów przyrostowych

• Podejście odgórne
• Podejście oddolne

Podejście odgórne

W tego rodzaju podejściu indywidualny rozpoczyna się od testowania tylko interfejsu użytkownika, z podstawową funkcjonalnością symulowaną przez kody pośredniczące, a następnie przesuwa się w dół, integrując niższe i niższe warstwy, jak pokazano na poniższym obrazku.

• Zaczynając od głównego modułu sterującego, moduły są integrowane poprzez przechodzenie w dół w hierarchii sterowania
• Podmoduły głównego modułu sterującego są wbudowane w strukturę w pierwszej kolejności wszerz lub 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 służy jako sterownik testowy, 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 najpierw głębokość).
3. Testy są wykonywane po zintegrowaniu każdego modułu.
4. Po zakończeniu każdego zestawu testów, kolejny odgałęzienie jest zastępowane prawdziwym modułem po zakończeniu każdego zestawu testów
5. Aby upewnić się, że nie zostały wprowadzone nowe błędy, można przeprowadzić testy regresyjne.

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

Najczęstszy z tych problemów występuje, gdy przetwarzanie na niskich poziomach w hierarchii jest wymagane w celu odpowiedniego przetestowania wyższych poziomów.

Stuby zastępują moduły niskiego poziomu na początku testów odgórnych, a zatem żadne istotne dane nie mogą przepływać w górę w strukturze programu.

Wyzwania, przed którymi stoi tester:

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

Uwaga: pierwsze podejście powoduje, że tracimy kontrolę nad korespondencją między określonymi testami i włączaniem określonych modułów. Może to powodować trudności 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 prowadzić do znacznych kosztów ogólnych, ponieważ kody pośredniczące stają się coraz bardziej złożone.

Podejście oddolne

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

W tym podejściu przetwarzanie wymagane dla modułów podrzędnych do danego poziomu jest zawsze dostępne i eliminowana jest potrzeba stosowania stubów.

Ten proces testu integracji składa się z czterech etapów

1. Moduły niskiego poziomu są łączone w klastry, które wykonują określoną podfunkcję oprogramowania.
2. Sterownik jest napisany w celu koordynowania wejścia i wyjścia testu.
3. Klaster lub kompilacja jest testowana.
4. Sterowniki są usuwane, a klastry są łączone, poruszając się w górę w strukturze programu.

Wraz ze wzrostem integracji konieczne są oddzielne lekcje dla kierowców testowych. W rzeczywistości, jeśli dwa najwyższe poziomy struktury programu są zintegrowane odgórnie, liczba sterowników może zostać znacznie zmniejszona, a integracja klastrów jest znacznie uproszczona. Integracja przebiega według schematu zilustrowanego poniżej. Wraz ze wzrostem integracji konieczne są oddzielne lekcje dla kierowców testowych.

Uwaga: jeśli dwa górne poziomy struktury programu są zintegrowane „od góry do dołu”, liczba sterowników może zostać znacznie zmniejszona, a integracja kompilacji jest znacznie uproszczona.

Podejście Big Bang

W tym podejściu wszystkie moduły nie są zintegrowane, dopóki wszystkie moduły nie są gotowe. Gdy są 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ę niepowodzenia, ponieważ integruje się wszystko na raz.

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

Takie podejście jest stosowane tylko wtedy, gdy testy integracyjne muszą być wykonane od razu.

Podsumowanie:

• Integracja jest wykonywana w celu sprawdzenia interakcji między modułami systemu oprogramowania. Pomaga wcześnie wykryć defekt
• Testy integracyjne można przeprowadzić dla integracji sprzęt-oprogramowanie lub sprzęt-sprzęt
• Testowanie integracyjne przeprowadza się dwoma metodami
  • Podejście przyrostowe
  • Podejście Big Bang
• Podczas przeprowadzania testów integracyjnych generalnie używana jest strategia ETVX (kryteria wejścia, zadanie, walidacja i kryteria wyjścia).