Was ist ein Beispiel für Systemintegrationstests (SIT)?

Was ist Systemintegrationstest?

System Integrationstests ist definiert als eine Art Softwaretest, der in einer integrierten Hardware- und Softwareumgebung durchgeführt wird, um das Verhalten des gesamten Systems zu überprüfen. Dabei handelt es sich um Tests, die an einem vollständigen, integrierten System durchgeführt werden, um die Konformität des Systems mit seinen spezifizierten Anforderungen zu bewerten.

Systemintegrationstests (SIT) werden durchgeführt, um die Interaktionen zwischen den Modulen eines Softwaresystems zu überprüfen. Es befasst sich mit der Überprüfung der hohen und niedrigen Softwareanforderungen, die in der Softwareanforderungsspezifikation/-daten und dem Softwaredesigndokument festgelegt sind. Es überprüft außerdem die Koexistenz eines Softwaresystems mit anderen und testet die Schnittstelle zwischen Modulen der Softwareanwendung. Bei dieser Art des Testens werden Module zunächst einzeln getestet und dann zu einem System kombiniert. Beispielsweise werden Software- und/oder Hardwarekomponenten kombiniert und schrittweise getestet, bis das gesamte System integriert ist.

Warum Systemintegrationstests durchführen?

In der Softwareentwicklung werden Systemintegrationstests durchgeführt, weil:

• Es hilft beim Erkennen Defekt früh
• Eine frühere Rückmeldung zur Akzeptanz des einzelnen Moduls wird verfügbar sein
• Die Planung von Fehlerbehebungen ist flexibel und kann mit der Entwicklung überschnitten werden
• Korrekter Datenfluss
• Korrekter Kontrollfluss
• Richtiges Timing
• Korrekte Speichernutzung
• Korrekt mit den Softwareanforderungen

So führen Sie Systemintegrationstests durch

Dabei handelt es sich um eine systematische Technik zum Aufbau der Programmstruktur bei der Durchführung von Tests zur Aufdeckung von Schnittstellenfehlern.

Alle Module werden vorab integriert und das gesamte Programm als Ganzes getestet. Während dieses Vorgangs kann es jedoch zu einer Reihe von Fehlern kommen.

Die Korrektur solcher Fehler ist schwierig, da die Isolierung der Ursachen durch die enorme Erweiterung des gesamten Programms erschwert wird. Sobald diese Fehler behoben und behoben sind, erscheint ein neuer und der Prozess läuft nahtlos in einer Endlosschleife weiter. Um diese Situation zu vermeiden, wird ein anderer Ansatz verwendet: inkrementelle Integration. Wir werden später im Tutorial mehr Details zu einem inkrementellen Ansatz sehen.

Es gibt einige inkrementelle Methoden, z. B. werden Integrationstests auf einem System durchgeführt, das auf dem Zielprozessor basiert. Die verwendete Methodik ist Schwarz Box Testen. Es kann entweder eine Bottom-Up- oder eine Top-Down-Integration verwendet werden.

Testfälle werden ausschließlich anhand der allgemeinen Softwareanforderungen definiert.

Die Softwareintegration kann auch weitgehend in der Host-Umgebung erfolgen, wobei für die Zielumgebung spezifische Einheiten weiterhin im Host simuliert werden. Zur Bestätigung sind erneut wiederholte Tests in der Zielumgebung erforderlich.

Bestätigungstests auf dieser Ebene identifizieren umgebungsspezifische Probleme, wie z. B. Fehler bei der Speicherzuweisung und -freigabe. Die Praktikabilität des Dirigierens Softwareintegration in der Hostumgebung hängt davon ab, wie viel zielspezifische Funktionalität vorhanden ist. Bei einigen eingebetteten Systemen ist die Kopplung mit der Zielumgebung sehr stark, was eine Softwareintegration in der Hostumgebung unpraktisch macht.

Bei großen Softwareentwicklungen wird die Softwareintegration in mehrere Ebenen unterteilt. Die unteren Ebenen der Softwareintegration könnten überwiegend in der Hostumgebung angesiedelt sein, während spätere Ebenen der Softwareintegration stärker von der Zielumgebung abhängig werden.

Hinweis: Wenn nur Software getestet wird, spricht man von Software-Software-Integrationstests (SSIT), und wenn sowohl Hardware als auch Software getestet werden, spricht man von Hardware-Software-Integrationstests (HSIT).

Eintritts- und Austrittskriterien für Integrationstests

Normalerweise wird bei der Durchführung von Integrationstests die ETVX-Strategie (Eintrittskriterien, Aufgaben, Validierung und Austrittskriterien) verwendet.

Eintrittskriterien:

• Beendigung von Unit Tests

Eingänge:

• Daten zu Softwareanforderungen
• Dokument zum Softwaredesign
• Softwareverifizierungsplan
• Software-Integrationsdokumente

Aktivitäten:

• Basierend auf den High- und Low-Level-Anforderungen erstellen Sie Testfälle und -verfahren
• Kombinieren Sie Low-Level-Modul-Builds, die eine gemeinsame Funktionalität implementieren
• Entwickeln Sie ein Testgeschirr
• Testen Sie den Build
• Sobald der Test bestanden ist, wird der Build mit anderen Builds kombiniert und getestet, bis das System als Ganzes integriert ist.
• Führen Sie alle Tests auf der Zielprozessor-basierten Plattform erneut aus und erhalten Sie die Ergebnisse

Ausgangskriterien:

• Erfolgreicher Abschluss der Integration des Softwaremoduls auf der Zielhardware
• Korrekte Leistung der Software gemäß den spezifizierten Anforderungen

Ausgänge

• Integrationstestberichte
• Softwaretestfälle und -verfahren [SVCP].

Testen der Hardware-Software-Integration

Testen der Hardware-Software-Integration ist ein Prozess zum Testen von Computersoftwarekomponenten (CSC) auf High-Level-Funktionalitäten in der Zielhardwareumgebung. Das Ziel des Hardware-/Software-Integrationstests besteht darin, das Verhalten der entwickelten Software zu testen, die in die Hardwarekomponente integriert ist.

Anforderungsbasiertes Testen der Hardware-Software-Integration

Das Ziel anforderungsbasierter Hardware-/Software-Integrationstests besteht darin, sicherzustellen, dass die Software auf dem Zielcomputer die hohen Anforderungen erfüllt. Zu den typischen Fehlern, die diese Testmethode aufdeckt, gehören:

• Fehler bei der Hardware-/Software-Schnittstelle
• Verstöße gegen die Softwarepartitionierung.
• Unfähigkeit, Fehler durch den integrierten Test zu erkennen
• Falsche Reaktion auf Hardwarefehler
• Fehler aufgrund von Sequenzierung, transienten Eingangslasten und Eingangsleistungstransienten
• Rückkopplungsschleifen führen zu falschem Verhalten
• Falsche oder unsachgemäße Steuerung der Speicherverwaltungshardware
• Problem mit Datenbuskonflikten
• Fehlerhafter Betrieb des Mechanismus zur Überprüfung der Kompatibilität und Richtigkeit der vor Ort ladbaren Software

Die Hardware-Software-Integration befasst sich mit der Überprüfung der High-Level-Anforderungen. Alle Tests auf dieser Ebene werden auf der Zielhardware durchgeführt.

• Auf dieser Testebene wird als primäre Testmethode der Black-Box-Test verwendet.
• Definierung Testfälle nur aus den High-Level-Anforderungen
• Ein Test muss auf serienmäßiger Standardhardware (am Ziel) durchgeführt werden.

Dinge, die beim Entwerfen von Testfällen für die HW/SW-Integration zu beachten sind

• Korrekte Erfassung aller Daten durch die Software
• Skalierung und Datenumfang wie erwartet von Hardware bis Software
• Korrekte Ausgabe der Daten von der Software zur Hardware
• Daten innerhalb der Spezifikationen (Normalbereich)
• Daten außerhalb der Spezifikationen (abnormaler Bereich)
• Grenzdaten
• Unterbricht die Verarbeitung
• Timing
• Korrekte Speichernutzung (Adressierung, Überlappungen usw.)
• Zustandsübergänge

Hinweis: Beim Interrupt-Testen werden alle Interrupts unabhängig von der ersten Anfrage über die vollständige Wartung bis hin zur Fertigstellung verifiziert. Testfälle werden speziell entwickelt, um Interrupts angemessen zu testen.

Software-zu-Software-Integrationstests

Es handelt sich um das Testen der Computersoftwarekomponente, die auf dem Host-/Zielcomputer ausgeführt wird.

Umgebung, bei der Simulation des gesamten Systems [anderer CSCs] und auf der High-Level-Funktionalität.

Der Schwerpunkt liegt auf dem Verhalten eines CSC in einer simulierten Host-/Zielumgebung. Der für die Softwareintegration verwendete Ansatz kann ein inkrementeller Ansatz sein (Top-Down-Ansatz, Bottom-Up-Ansatz oder eine Kombination aus beidem).

Inkrementeller Ansatz

Inkrementelles Testen ist eine Möglichkeit zum Integrationstest. Bei dieser Art von Testmethode testen Sie zunächst jedes Modul der Software einzeln und fahren dann mit dem Testen fort, indem Sie ihm andere Module anhängen, dann ein weiteres und so weiter.

Inkrementelle Integration ist der Gegensatz zum Big-Bang-Ansatz. Das Programm wird in kleinen Abschnitten erstellt und getestet, in denen Fehler leichter isoliert und korrigiert werden können. Es ist wahrscheinlicher, dass Schnittstellen vollständig getestet werden, und es kann ein systematischer Testansatz angewendet werden.

Es gibt zwei Arten von inkrementellen Tests

• Top-down-Ansatz
• Bottom-Up-Ansatz

Top-Down-Ansatz

Bei dieser Art von Ansatz testet der Einzelne zunächst nur die Benutzeroberfläche, wobei die zugrunde liegende Funktionalität durch Stubs simuliert wird, und geht dann nach unten, indem er immer tiefere Schichten integriert, wie in der Abbildung unten gezeigt.

• Beginnend mit dem Hauptsteuermodul werden die Module nach unten durch die Steuerhierarchie integriert
• Untermodule des Hauptsteuermoduls werden entweder in der Breite zuerst oder in der Tiefe zuerst in die Struktur integriert.
• Bei der Tiefenintegration werden alle Module auf einem Hauptkontrollpfad der Struktur integriert, wie im folgenden Diagramm dargestellt:

Der Modulintegrationsprozess wird folgendermaßen durchgeführt:

1. Das Hauptsteuermodul wird als Testtreiber verwendet und die Stubs ersetzen alle dem Hauptsteuermodul direkt untergeordneten Module.
2. Die untergeordneten Stubs werden je nach gewähltem Ansatz (Breite zuerst oder Tiefe zuerst) einzeln durch tatsächliche Module ersetzt.
3. Bei der Integration jedes Moduls werden Tests durchgeführt.
4. Nach Abschluss jedes Testsatzes wird nach Abschluss jedes Testsatzes ein weiterer Stub durch ein echtes Modul ersetzt
5. Um sicherzustellen, dass keine neuen Fehler eingeführt wurden Regressionstests durchgeführt werden kann.

Der Prozess wird von Schritt 2 an fortgesetzt, bis die gesamte Programmstruktur aufgebaut ist. Die Top-Down-Strategie klingt relativ unkompliziert, in der Praxis treten jedoch logistische Probleme auf.

Am häufigsten treten diese Probleme auf, wenn die Verarbeitung auf niedrigen Hierarchieebenen erforderlich ist, um die oberen Ebenen angemessen zu testen.

Stubs ersetzen Low-Level-Module zu Beginn des Top-Down-Tests und daher können keine signifikanten Daten in der Programmstruktur nach oben fließen.

Herausforderungen, mit denen Tester konfrontiert sein könnten:

• Verzögern Sie viele Tests, bis Stubs durch tatsächliche Module ersetzt werden.
• Entwickeln Sie Stubs, die begrenzte Funktionen ausführen, die das tatsächliche Modul simulieren.
• Integrieren Sie die Software vom unteren Ende der Hierarchie nach oben.

Hinweis: Der erste Ansatz führt dazu, dass wir einen Teil der Kontrolle über die Korrespondenz zwischen bestimmten Tests und der Einbindung bestimmter Module verlieren. Dies kann dazu führen, dass es schwierig wird, die Fehlerursache zu bestimmen, was tendenziell gegen die stark eingeschränkte Natur des Top-Down-Ansatzes verstößt.

Der zweite Ansatz ist praktikabel, kann aber zu erheblichem Mehraufwand führen, da Stubs zunehmend komplexer werden.

Bottom-up-Ansatz

Die Bottom-up-Integration beginnt mit der Konstruktion und dem Testen von Modulen auf der untersten Ebene der Programmstruktur. Dabei werden die Module von unten nach oben integriert.

Bei diesem Ansatz ist die Verarbeitung, die für die einer bestimmten Ebene untergeordneten Module erforderlich ist, immer verfügbar und die Notwendigkeit von Stubs entfällt.

Dieser Integrationstestprozess wird in einer Reihe von vier Schritten durchgeführt

1. Low-Level-Module werden zu Clustern kombiniert, die eine bestimmte Software-Teilfunktion ausführen.
2. Ein Treiber wird geschrieben, um die Eingabe und Ausgabe von Testfällen zu koordinieren.
3. Der Cluster oder Build wird getestet.
4. Treiber werden entfernt und Cluster werden aufwärts in der Programmstruktur kombiniert.

Mit zunehmender Integration wird es notwendig, separate Testfahrerstunden zu absolvieren. Tatsächlich kann die Anzahl der Fahrer erheblich reduziert und die Integration von Clustern erheblich vereinfacht werden, wenn die beiden obersten Ebenen der Programmstruktur von oben nach unten integriert werden. Die Integration folgt dem unten dargestellten Muster. Mit zunehmender Integration wird es notwendig, separate Testfahrerstunden zu absolvieren.

Hinweis: Wenn die beiden obersten Ebenen der Programmstruktur von oben nach unten integriert werden, kann die Anzahl der Treiber erheblich reduziert und die Integration von Builds erheblich vereinfacht werden.

Urknall-Ansatz

Bei diesem Ansatz werden alle Module erst dann integriert, wenn alle Module bereit sind. Sobald sie fertig sind, werden alle Module integriert und dann ausgeführt, um festzustellen, ob alle integrierten Module funktionieren oder nicht.

Bei diesem Ansatz ist es schwierig, die Grundursache des Fehlers zu ermitteln, da alles auf einmal integriert wird.

Außerdem besteht eine hohe Wahrscheinlichkeit, dass kritische Fehler in der Produktionsumgebung auftreten.

Dieser Ansatz wird nur angewendet, wenn Integrationstests sofort durchgeführt werden müssen.

Zusammenfassung

• Die Integration wird durchgeführt, um die Interaktionen zwischen den Modulen eines Softwaresystems zu überprüfen. Es hilft, Mängel frühzeitig zu erkennen
• Integrationstests können für die Hardware-Software- oder Hardware-Hardware-Integration durchgeführt werden
• Integrationstests werden mit zwei Methoden durchgeführt
  • Inkrementeller Ansatz
  • Urknall-Ansatz
• Bei der Durchführung von Integrationstests wird im Allgemeinen die ETVX-Strategie (Eintrittskriterien, Aufgaben, Validierung und Austrittskriterien) verwendet.