Menü

Was ist inkrementelles Testen? Detaillierte Erläuterung mit Beispielen

what is incremental testing

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Mit Hilfe dieses Artikels werde ich einen der wichtigsten Integrationsansätze behandeln - Inkrementelles Testen.

Am Ende dieses Abschnitts wird das Publikum über folgende Kenntnisse verfügen:

  • Was ist inkrementelles Testen?
  • Sein Ziel
  • Methoden
  • Vorteile
  • Nachteile

Was du lernen wirst:

Was ist inkrementelles Testen?

Inkrementelles Testen, auch als inkrementelles Integrationstest bekannt, ist einer der Ansätze des Integrationstests und beinhaltet seine grundlegenden Konzepte.

Es ist wie ein Test, der Modul und Integration kombiniert Teststrategie .

Inkrementelle Tests

Bei diesem Test testen wir jedes Modul einzeln in der Unit-Test-Phase. Anschließend werden die Module schrittweise integriert und getestet, um eine reibungslose Schnittstelle und Interaktion zwischen den Modulen sicherzustellen.

Bei diesem Ansatz wird jedes Modul inkrementell kombiniert, d. H. Eins nach dem anderen, bis alle Module oder Komponenten logisch hinzugefügt sind, um die erforderliche Anwendung zu erstellen, anstatt das gesamte System auf einmal zu integrieren und dann Tests am Endprodukt durchzuführen. Integrierte Module werden als Gruppe getestet, um eine erfolgreiche Integration und einen erfolgreichen Datenfluss zwischen Modulen sicherzustellen.

Wie beim Integrationstest liegt der Hauptfokus dieses Tests auf der Überprüfung der Schnittstelle, der integrierten Verknüpfungen und des Informationsflusses zwischen den Modulen. Dieser Vorgang wird wiederholt, bis die Module kombiniert und erfolgreich getestet wurden.

Beispiel

Lassen Sie uns dieses Konzept anhand eines Beispiels verstehen:

Das System oder die Softwareanwendung besteht aus folgenden Modulen:

Computerprogramm

Testansatz für inkrementelle Integration

  • Jedes Modul, d. H. M1, M2, M3 usw., wird einzeln als Teil des Einheitentests getestet
  • Module werden inkrementell kombiniert, d. H. Einer nach dem anderen, und auf erfolgreiche Interaktion getestet
  • In Abb. 2 werden Modul M1 und Modul M2 kombiniert und getestet
  • In Abb. 3 wird das Modul M3 hinzugefügt und getestet
  • In Abb. 4 wird Modul M4 hinzugefügt und getestet, um sicherzustellen, dass alles erfolgreich zusammenarbeitet
  • Die restlichen Module werden bei jedem Schritt schrittweise hinzugefügt und auf erfolgreiche Integration getestet

Abb2

Kombiniert zwei Module

Abb. 3

Kombiniert 3 Module

Was ist die beste Task-Management-Software?

Abb4

Kombinierte vier Module

Ziel des inkrementellen Tests

  • Um sicherzustellen, dass verschiedene Module nach der Integration erfolgreich zusammenarbeiten
  • Identifizieren Sie die Fehler früher und in jeder Phase. Dies gibt Entwicklern einen Vorteil, um festzustellen, wo das Problem liegt. Zum Beispiel, wenn das Testen nach der Integration von M1 und M2 erfolgreich ist, aber wenn M3 hinzugefügt wird, schlägt der Test fehl; Dies hilft dem Entwickler bei der Trennung des Problems
  • Probleme können in der frühen Phase ohne viel Nacharbeit und zu geringeren Kosten behoben werden

Inkrementelle Integrationstestmethoden

Bevor wir mit diesem Thema beginnen, möchte ich eine kurze Einführung geben Stubs und Fahrer da wir diese Begriffe oft verwenden werden.

Stubs und Treiber sind Pseudocode oder Dummy-Code, der in Integration oder verwendet wird Komponententest wenn ein oder mehrere Module nicht entwickelt wurden, aber zum Testen eines anderen Moduls erforderlich sind.

Stubs werden im Top-Down-Testansatz verwendet und als 'aufgerufene Programme' bezeichnet. Stubs helfen dabei, die Schnittstelle zwischen Modulen mit niedrigerem Hebel zu simulieren, die nicht verfügbar oder entwickelt sind.

Treiber werden im Bottom-up-Testansatz verwendet und als 'Aufruf von Programmen' bezeichnet. Treiber helfen bei der Simulation der Schnittstelle zwischen Modulen der obersten Ebene, die nicht entwickelt oder verfügbar sind.

Eine Frage, die einigen von uns möglicherweise einfällt, ist, warum sie nicht warten müssen, bis alle Anwendungsmodule entwickelt sind, anstatt Stub / Treiber zu verwenden, bevor sie mit dem Testen beginnen.

Die einfache Antwort ist, dass dies die Projektausführungszeit verlängert, da die Tester im Leerlauf sitzen, bis alle Module entwickelt sind. Dies erschwert auch die Wurzelanalyse des Defekts. Diese Art von Testansatz wird als Urknall-Integrationstest bezeichnet.

Nachdem wir uns nun mit Stubs und Treibern befasst haben, fahren wir mit fort verschiedene Methoden des inkrementellen Testens:

# 1) Von oben nach unten

Wie der Name schon sagt, findet das Testen von oben nach unten statt, d. H. Vom Zentralmodul zum Untermodul. Module, die die oberste Anwendungsebene umrahmen, werden zuerst getestet.

Dieser Ansatz folgt dem strukturellen Ablauf der zu testenden Anwendung. Nicht verfügbare oder nicht entwickelte Module oder Komponenten werden durch Stubs ersetzt.

Lassen Sie uns dies anhand eines Beispiels verstehen:

  • Modul : Website Login aka L.
  • Modul : Bestellung aka O.
    • Modulbestellübersicht aka OS (noch nicht entwickelt)
  • Modul : Zahlung aka P.
    • Modul Barzahlung aka CP
    • Modul Debit / Credit Payment aka DP (noch nicht entwickelt)
    • Module Wallet Payment aka WP (noch nicht entwickelt)
  • Modul: Berichterstattung aka R (noch nicht entwickelt)

Top-Down-Ansatz

Top-down-Testansatz für inkrementelle Integration

Folgende Testfälle werden abgeleitet:

wie man Array-Index außerhalb der Grenzen Ausnahme in Java löst

Testfall1: Modul L und Modul O werden integriert und getestet
Testfall2: Modul L, O und P werden integriert und getestet
Testfall3: Modul L, O, P und R werden integriert und getestet.

Und so weiter werden andere Testfälle abgeleitet.

Diese Art des Testens, bei dem alle Module auf einer Ebene zuerst integriert und getestet werden, wird als 'Breite zuerst' bezeichnet. Eine andere Kategorie ist 'Tiefe zuerst'.

Folgende Testfälle werden für 'Tiefe zuerst' abgeleitet:

Testfall1: Modul L und Modul O werden integriert und getestet
Testfall2: Modul L, O und OS werden integriert und getestet
Testfall3: Modul L, O, OS, P wird integriert und getestet
Testfall4: Modul L, O, OS, P, CP wird integriert und getestet

Und so weiter werden andere Testfälle abgeleitet.

Vorzüge der Top-Down-Methodik

  • Frühzeitige Aufdeckung von Architekturfehlern
  • Es beschreibt die Funktionsweise einer Anwendung als Ganzes in einem frühen Stadium und hilft bei der frühzeitigen Offenlegung von Konstruktionsfehlern
  • Hauptkontrollpunkte werden frühzeitig getestet

Nachteile der Top-Down-Methodik

  • Wichtige Module werden spät im Zyklus getestet
  • Es ist sehr schwierig, Testbedingungen zu schreiben
  • Ein Stub ist keine perfekte Implementierung eines verwandten Moduls. Es simuliert lediglich den Datenfluss zwischen zwei Modulen

# 2) Bottom-up

Bei diesem Ansatz findet das Testen von unten nach oben statt, d. H. Die Module in der unteren Schicht werden zuerst integriert und getestet, und dann werden nacheinander andere Module integriert, wenn wir uns nach oben bewegen. Nicht verfügbare oder nicht entwickelte Module werden durch Treiber ersetzt.

Schauen wir uns zum besseren Verständnis ein unten genanntes Beispiel an:

Modulrang, Noten, Prozentsatz und Sportnote sind noch nicht entwickelt, daher werden sie durch verwandte Treiber ersetzt:

Bottom-Up-Ansatz

Bottom-up-Testansatz für inkrementelle Integration

Folgende Testfälle werden abgeleitet:

Testfall1: Unit Testing des Moduls Praktisch und Theorie
Testfall2: Integration und Prüfung von Modulen Marks-Practical-Theory
Testfall3 : Integration und Testen von Modulen Percentage-Marks-Practical-Theory
Testfall4: Unit Testing von Module Sports Grade
Testfall5: Integration und Test von Modulen Rang-Sport Grad-Prozent-Noten-Praktische-Theorie

Vorzüge der Bottom-up-Methodik

  • Diese Methode ist sehr nützlich für Anwendungen, bei denen ein Bottom-up-Entwurfsmodell verwendet wird
  • Es ist einfacher, Testbedingungen im Bottom-up-Ansatz zu erstellen
  • Um mit dem Testen auf der untersten Hierarchieebene zu beginnen, müssen kritische Module oder Funktionen frühzeitig getestet werden. Dies hilft bei der frühzeitigen Erkennung von Fehlern
  • Schnittstellenfehler werden frühzeitig erkannt

Nachteile der Bottom-up-Methodik

  • Treiber sind schwieriger zu schreiben als Stub
  • Konstruktionsfehler werden in der späteren Phase erkannt
  • Bei diesem Ansatz haben wir keine funktionierende Anwendung, bis das letzte Modul erstellt wurde
  • Der Treiber ist keine vollständige Implementierung des zugehörigen Moduls. Es simuliert lediglich den Datenfluss zwischen zwei Modulen.

# 3) Sandwich-Tests

Dieser Ansatz ist eine Mischung aus Top-Down- und Bottom-Up-Methoden. Stub und Treiber werden für unvollständige oder nicht entwickelte Module verwendet.

Testansatz

  • Es wird eine mittlere Schicht identifiziert, von der aus Bottom-Up- und Top-Down-Tests durchgeführt werden. Diese mittlere Schicht wird auch als Zielschicht bezeichnet
  • Die Zielschicht wird gemäß dem heuristischen Ansatz identifiziert, d. H. Eine Schicht ausgewählt, die eine minimale Verwendung von Stubs und Treibern ermöglicht
  • Top-Down-Tests beginnen in der mittleren Schicht und bewegen sich nach unten in Richtung der Module der unteren Ebene. Diese Schicht unter der mittleren Schicht wird als untere Schicht bezeichnet
  • Bottom-up-Tests beginnen ebenfalls in der mittleren Schicht und gehen in Richtung der Module der obersten Schicht. Diese Schicht über der mittleren Schicht wird als oberste Schicht bezeichnet
  • Unter Verwendung von Stubs und Treibern werden die Benutzeroberfläche und die Funktionen von Modulen niedrigerer Ebene getestet
  • Am Ende bleibt nur die mittlere Schicht für die Ausführung des endgültigen Tests übrig

Beispiel:

Sandwich-Testbeispiel

Folgende Testfälle können mit der Sandwich-Teststrategie abgeleitet werden:

Testfall1: Test A, X, Y und Z einzeln - wobei Test A unter den Test der obersten Schicht und Test X, Y und Z unter die Tests der unteren Schicht fällt
Testfall2: Test A, G, H und ich
Testfall3: Teste G, X und Y.
Testfall4: Test Hand Z
Testfall5: Test A, G, H, I, X, Y und Z.

Vorzüge der Sandwich-Testmethode

  • Es ist sehr vorteilhaft für ein großes Projekt, das verschiedene Teilprojekte hat
  • Top-Down- und Bottom-Up-Testmethoden können nebeneinander ausgeführt werden

Nachteile der Sandwich-Testmethode

  • Vor der Modulvereinigung werden Subsysteme und ihre Schnittstellen nicht gründlich getestet
  • Höhere Kosten aufgrund der Einbeziehung von Top-Down- und Bottom-Up-Testmethoden
  • Diese Art des Testens wird für ein System nicht empfohlen, bei dem Module stark voneinander abhängig sind

Fazit

Inkrementelles Testen fällt unter das Integrations-Testen. Bei diesem Testansatz werden Integrationstests für das einzelne Modul als Teil des Komponententests durchgeführt. In der nächsten Phase werden Module oder Komponenten der Anwendung schrittweise integriert, und die Tests werden für kombinierte Module als Gruppe durchgeführt.

Von drei Methoden für inkrementelle Integrationstests hängt die Auswahl der zu wählenden Methode von der Struktur der Anwendung und auch von der Position der Module mit hohem Risiko ab.

Alle drei Methoden für inkrementelle Tests fallen aufgrund folgender Verhaltensaspekte unter die Kategorie Horizontal:

  • Alle drei Methoden konzentrieren sich auf Schichttests
  • Alle betrachten ein strukturelles oder hierarchisches Design
  • Alle von ihnen integrieren Ebenen inkrementell

Verdienste:

Mit diesem Testansatz ist es einfacher, Fehler frühzeitig zu erkennen, und der Entwickler kann die Ursache des Problems ermitteln. Da die Grundlagen des strukturierten Testens verwendet werden, ist dieser Testansatz sehr effektiv und genau.

Fehler:

Diese Art von Testansatz ist aufgrund der Verwendung von Stubs und Treibern zeitaufwändig. Es wiederholt sich auch.

Über die Autor: Dieses hilfreiche Tutorial wurde von Neha B verfasst. Sie ist ISTQB-zertifizierte Lead Quality Analystin mit mehr als 8 Jahren Erfahrung.

Lassen Sie uns wissen, wenn Sie Fragen / Anregungen haben.

Literatur-Empfehlungen

^