Einführung in das Integrationstesten in Java
- Einführung in Integrationstests
- Bedeutung von Integrationstests
- Arten von Integrationstests
- Erforderliche Schritte für Integrationstests
Dieses Tutorial stellt Integrationstests vor und hebt hervor, wie wir sie von Unit-Tests unterscheiden können. Darüber hinaus werden verschiedene Arten von Integrationstests unter Berücksichtigung ihrer Vor- und Nachteile erörtert.
Dann lernen wir die erforderlichen Schritte zur Durchführung von Integrationstests kennen, gefolgt von einem realen Szenario zum Verständnis von Integrationstests.
Einführung in Integrationstests
Es gibt drei Arten von Tests in Testpyramide: Komponententests, Integrationstests und Funktionstests. Dieser Artikel dreht sich um Integrationstests, was bedeutet, dass wir prüfen, ob verschiedene Module wie erwartet funktionieren, wenn wir sie als Gruppe kombinieren.
Denken Sie daran, dass Software aus verschiedenen Modulen besteht, die mehrere Programmierer codiert haben. Hier besteht das primäre Ziel des Integrationstests darin, eine Schnittstelle zwischen zwei oder mehreren Softwaremodulen zu testen, indem sie logisch integriert und als Gruppe getestet werden.
Darüber hinaus bestimmt es die Korrektheit einer Schnittstelle, indem es Fehler in einer Interaktion zwischen verschiedenen Softwarekomponenten aufdeckt, wenn wir sie integrieren. Der Integrationstestprozess beginnt, nachdem alle Softwarekomponenten einem Komponententest unterzogen wurden.
Sehen Sie sich das Folgende an, um Unit-Tests und Integrationstests zu visualisieren.
Im Folgenden sind einige Punkte aufgeführt, um hervorzuheben, wie sich Integrationstests von Einheitentests unterscheiden.
| Unit-Tests | Integrationstests |
|---|---|
| Dabei ist sich der Entwickler des internen Aufbaus der Software bewusst. | Dabei kennt der Tester den internen Aufbau der Software nicht. |
| Jedes Modul wird separat getestet. | Wir kombinieren alle Module und testen in der Gruppe. |
| Es wird White-Box-Testing genannt. | Es ist als Black-Box-Test bekannt. |
| Es wird von einem Entwickler durchgeführt. | Das macht ein Tester. |
| Fehler finden ist hier einfach. | Das Aufdecken von Fehlern ist beim Integrationstest schwierig. |
| Bei Unit-Tests werden alle Projektkomponenten einzeln und unabhängig voneinander getestet, ohne auf die Fertigstellung anderer Komponenten zu warten. | Der Integrationstest wird durchgeführt, wenn alle Teile fertiggestellt sind. |
| Es ist kostengünstig. Auch die Wartung ist kostengünstiger. | Es ist teuer. Auch die Wartung ist kostspielig. |
| Die Modulspezifikation erfolgt zunächst. | Die Schnittstellenspezifikation wird zu Beginn durchgeführt. |
| Es geht darum, Code gründlich zu untersuchen. | Es geht um die detaillierte Sichtbarkeit der Integrationsstruktur. |
| Schnelle Ausführung als Integrationstests. | Hier ist die Geschwindigkeit aufgrund der Integration von Modulen vergleichsweise gering. |
Mehr dazu finden Sie hier.
Bedeutung von Integrationstests
Obwohl jede Softwarekomponente komponentengetestet wird, können aus verschiedenen Gründen Fehler aufgedeckt werden, was die Bedeutung von Integrationstests erhöht. Einige davon sind unten aufgeführt.
- Es ermöglicht eine bessere Integration von Softwaremodulen.
- Durch die Verwendung von Integrationstests können wir Änderungen an Daten während der Übertragung von Softwaremodulen verhindern.
- Es überwindet auch verschiedene Probleme des manuellen Testens.
- Integrationstests ermöglichen auch effektive Tests durch Drittanbieter.
- Es muss überprüft werden, ob alle Softwarekomponenten in einer Einheit funktionieren und wie erwartet eine Ausgabe erzeugen.
- Das Auffinden von Fehlern in externen Hardwareschnittstellen und Schnittstellen von Softwaremodulen mit einer Datenbank ist nützlich.
- Manchmal ändert ein Kunde die Anforderungen während der Entwicklung des Softwaremoduls. In diesem Fall besteht die Möglichkeit, dass neue Anforderungen nicht auf Unit-Test-Ebene getestet werden; Daher werden Integrationstests hier unerlässlich.
Arten von Integrationstests
In diesem Artikel werden zwei Ansätze für Integrationstests unter Berücksichtigung der Vor- und Nachteile erörtert.
- Urknall
- Inkrementell (weiter kategorisiert in Top-down-, Bottom-up- und Sandwich-Ansätze)
Big-Bang-Ansatz für Integrationstests
Bei diesem Ansatz integrieren wir alle zu testenden Softwarekomponenten als eine Einheit, die während des Testens als Entität bezeichnet wird. Dieser Integrationsprozess wird erst ausgeführt, wenn alle Komponenten im Komponententest abgeschlossen sind.
Verwechseln Sie es nicht mit Systemtests. Wir testen nur die Integration verschiedener Softwaremodule, nicht das gesamte System (durchgeführt im Systemtest).
Sein größter Vorteil ist, dass wir alle Softwarekomponenten integrieren und als eine Einheit testen können, während es auch schwierig ist, Fehler mit dem Big-Bang-Ansatz zu identifizieren. Daher ist es für alle kleinen Systeme geeignet.
Wir können uns den Big-Bang-Ansatz wie folgt vorstellen. Wir haben sechs verschiedene Module integriert und mit dem Urknall getestet.
Inkrementeller Ansatz für Integrationstests
Bei diesem Ansatz integrieren wir zwei oder mehrere Softwaremodule in logischem Zusammenhang und testen diese anschließend auf Funktionsfähigkeit der Anwendung. Dann werden andere verwandte Module/Komponenten inkrementell integriert und getestet.
Dieses Verfahren wird fortgesetzt, bis alle logisch verwandten Komponenten integriert und getestet sind.
Dieser Ansatz wird weiter in Top-down-, Bottom-up- und Sandwich-Ansätze kategorisiert. Lassen Sie uns jeden von ihnen unten durch die Stubs und Treiber lernen.
Stub– Wird von einem zu testenden Modul/einer zu testenden Komponente aufgerufen.Treiber- Hier wird das zu testende Modul/die Komponente aufgerufen.
Top-Down-Ansatz
Hier wird die Integration von oben nach unten gemäß dem Kontrollfluss des Softwaresystems durchgeführt. Mit diesem Ansatz testen wir Komponenten auf höherer Ebene und gehen dann zu Komponenten auf niedrigerer Ebene über, um die Softwarefunktionalität zu überprüfen.
Hier können wir Stubs verwenden, wenn einige Komponenten noch nicht gelesen wurden. Es ist ein organischer Weg, der mit dem übereinstimmt, was in der realen Umgebung passieren wird.
Ein weiterer Vorteil dieses Ansatzes ist, dass wir kritische Module vorrangig testen können. Auf diese Weise können wir Fehler auf einer höheren Ebene finden und diese zuerst beheben.
Andererseits geht es bei diesem Ansatz nur darum, Hauptfunktionen am Ende zu testen. Wir können es im folgenden Diagramm visualisieren.
Bottom-up-Ansatz
Hier testen wir zuerst Module auf niedrigerer Ebene, die verwendet werden, um beim Testen des Moduls auf höherer Ebene zu helfen. Dieses Verfahren wird fortgesetzt, bis wir alle Module/Komponenten auf der obersten Ebene getestet haben.
Beim Bottom-up-Ansatz verwenden wir Stimulatorprogramme, sogenannte Drivers. Defekte und Fehler lassen sich auf der unteren Ebene leicht finden, aber Probleme auf höherer Ebene lassen sich erst am Ende finden, wenn alle Komponenten integriert und getestet wurden.
Sandwich-Ansatz
Dieser Ansatz kombiniert Top-Down- und Bottom-Up-Ansätze und wird daher als Hybrid Integration Testing bezeichnet. Es verwendet Stubs und Treiber.
Hier werden Komponenten der obersten Ebene mit Komponenten der unteren Ebene getestet. Gleichzeitig werden untergeordnete Komponenten/Module mit den Modulen/Komponenten der obersten Ebene integriert und als System getestet.
Wir können uns diesen Ansatz wie folgt vorstellen:
Erforderliche Schritte für Integrationstests
Die folgenden Schritte sind unabhängig davon erforderlich, welche Software-Teststrategie (siehe oben) verwendet wird:
-
Erstellen Sie einen Integrationstestplan.
-
Entwerfen Sie Testszenarien, Fälle und Skripte.
-
Führen Sie alle Testfälle aus, gefolgt von der Aufdeckung und Meldung von Fehlern.
-
Behalten Sie den Überblick und testen Sie die Fehler erneut.
-
Die Schritte 3 und 4 werden wiederholt, bis wir eine erfolgreiche Integration erreichen.
Beispiel aus der Praxis zum Verständnis von Integrationstests
Angenommen, wir haben eine Methode namens performPayment(), die zwei Parameter akzeptiert, amount und service vom Typ double bzw. PaymentService.
Im Unit-Test testen wir es, indem wir ein Mock für das Argument service erstellen, während der Integrationstest ein Test ist, bei dem wir den tatsächlichen externen service verwenden, um sicherzustellen, dass dieser service auf unsere Eingabedaten reagiert wie erwartet.
