Co to jest przykład testowania integracji systemu (SIT).

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 systemu (SIT) przeprowadza się w celu sprawdzenia interakcji pomiędzy modułami systemu oprogramowania. Zajmuje się weryfikacją wymagań oprogramowania wysokiego i niskiego poziomu określonych w Specyfikacji/Danych Wymagań Oprogramowania i Dokumencie Projektu Oprogramowania. Weryfikuje także współistnienie systemu oprogramowania z innymi i testuje interfejs pomię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.

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

Jak przeprowadzić test integracji systemu

Jest to systematyczna technika konstruowania struktury programu podczas przeprowadzania testów w celu wykrycia 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, Incremental Integration. Więcej szczegółów na temat podejścia incremental zobaczymy później w tym samouczku.

Istnieją metody przyrostowe, takie jak testy integracyjne przeprowadzane na systemie opartym na docelowym procesorze. Zastosowana metodologia to Czarny Box Testowanie. 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 środowiska, takie jak błędy w alokacji i dealokacji pamięci. Praktyczność dyrygentury integracja oprogramowania w środowisku hosta będzie zależeć od tego, ile jest tam funkcjonalności specyficznych dla celu. W przypadku niektórych systemów wbudowanych sprzężenie ze środowiskiem docelowym będzie bardzo silne, co sprawi, że przeprowadzenie integracji oprogramowania w środowisku hosta będzie niepraktyczne.

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].

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

Zwykle podczas wykonywania testów integracyjnych stosowana 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

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].

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

Jest to testowanie komponentu oprogramowania komputerowego działającego w komputerze hosta/docelowym

Środowisko, symulując cały system [inne CSC] i na wysokim poziomie funkcjonalności.

Koncentruje się na zachowaniu CSC w symulowanym środowisku hosta/docelowego. Podejście stosowane w integracji oprogramowania może być podejściem przyrostowym (od góry do dołu, od dołu do góry lub połączenie obu).

Podejście przyrostowe

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.

W miarę jak integracja przesuwa się w górę, potrzeba osobnych lekcji sterowników testowych. W rzeczywistości, jeśli dwa najwyższe poziomy struktury programu są zintegrowane od góry do dołu, liczba sterowników może zostać znacznie zmniejszona, a integracja klastrów jest znacznie uproszczona. Integracja przebiega zgodnie ze schematem zilustrowanym poniżej. W miarę jak integracja przesuwa się w górę, potrzeba osobnych lekcji sterowników testowych.

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.

Podsumowanie

• Integracja ma na celu weryfikację interakcji pomiędzy modułami systemu oprogramowania. Pomaga wcześnie wykryć wadę
• Testy integracyjne można przeprowadzić w przypadku integracji sprzętu i oprogramowania lub sprzętu i sprzętu
• Testowanie integracyjne odbywa się dwiema metodami
  • Podejście przyrostowe
  • Podejście Wielkiego Wybuchu
• Podczas przeprowadzania testów integracyjnych ogólnie stosowana jest strategia ETVX (kryteria wejścia, zadanie, walidacja i kryteria wyjścia).