it-swarm-eu.dev

Was genau ist ein Integrationstest?

Meine Freunde und ich hatten Mühe, genau zu klassifizieren, was ein Integrationstest ist.

Auf dem Heimweg wurde mir gerade klar, dass sich jedes Mal, wenn ich versuche, ein reales Beispiel für einen Integrationstest zu geben, herausstellt, dass es sich um einen Abnahmetest handelt, d. H. Etwas, das ein Geschäftsmann laut aussprechen würde und das angibt, was das System liefern soll.

Ich habe die Dokumentation Ruby on Rails) auf ihre Klassifizierung dieser Testtypen überprüft und bin jetzt völlig fertig.

Können Sie mir eine kurze akademische Beschreibung eines Integrationstests anhand eines Beispiels aus der Praxis geben?

116
Martin Blore

Im Moment gefällt mir diese Aussage: "Es ist nicht wichtig, wie du es nennst, aber was es tut" von Gojko Adzic in dieser Artikel .

Sie müssen wirklich mit den Leuten, die über die Tests sprechen, angeben, was Sie testen möchten.

Es gibt viele Menschen, die unterschiedliche Ansichten haben, je nachdem, welche Rolle sie spielen.

Für Tester ist TMap eine allgemein anerkannte Testmethode in den Niederlanden. TMap macht die folgende Unterscheidung.

  • gerätetest
  • geräteintegrationstest
  • systemtest
  • systemintegrationstest
  • abnahmetest (alle Arten/Stufen)
  • funktionsabnahmeprüfung
  • benutzerakzeptanztest
  • produktionsabnahmetest

Sie haben spezifischere Arten von Tests, die innerhalb der oben genannten Tests durchgeführt werden können. Schauen Sie sich dieses Word-Dokument an, um eine Übersicht zu erhalten.

Wikipedia hat auch eine Schöne Übersicht .

Das Buch der pragmatische Programmierer sagt:

  • ein Unit-Test ist ein Test, der ein Modul ausübt
  • integrationstests zeigen, dass die Hauptteile eines Systems gut zusammenarbeiten

Wenn ich mir diese verschiedenen Quellen anschaue und einige meiner eigenen Erfahrungen und Meinungen einbringe, würde ich zunächst nach drei Kategorien unterscheiden

  • wer macht die Tests im Allgemeinen
  • was getestet wird
  • was ist das Ziel des Tests

    • Unit Test : Testlogik in Klassen von Programmierern, um die Korrektheit auf Codeebene zu zeigen. Sie sollten schnell sein und nicht von anderen Teilen des Systems abhängen, die Sie nicht testen möchten
    • Funktionaler Abnahmetest : Testen Sie Anwendungsfall-Szenarien anhand eines begrenzten (speziell erstellten) Datensatzes, der von der Testabteilung erstellt wurde, um zu zeigen, dass jedes angegebene Szenario wie angegeben funktioniert.
    • Benutzerakzeptanztest : Testanwendungsszenarien in der Produktion wie Daten, die von Vertretern der Benutzer erstellt wurden, um sie dazu zu bringen, die Anwendung offiziell anzunehmen
    • Integrationstest : Testen Sie die Kommunikationspfade zwischen verschiedenen Teilen des Moduls, die von der Testabteilung oder von Entwicklern durchgeführt wurden, um zu zeigen, dass alle Module korrekt zusammenarbeiten.

Meine obige Liste ist nur ein Anfang und ein Vorschlag, aber ich denke wirklich: "Es ist nicht wichtig, wie Sie es nennen, aber was es tut."

Hoffe das hilft.

26-10-2016 Bearbeiten: Erst kürzlich wurde eine sehr nette Einführung auf YouTube veröffentlicht nit-Tests vs. Integrationstests - MPJ's Musings - FunFunFunction # 55

81
KeesDijk

integrationstest stellt sich heraus, dass es sich um einen Abnahmetest handelt

Offensichtlich.

Diese beiden sind fast dasselbe. Die Testdefinition weist jedoch einige geringfügig unterschiedliche Dimensionen auf.

Integration == das System als Ganzes.

Akzeptanz == das System als Ganzes.

Der einzige Unterschied - und das ist subtil - ist die Definition der Testfälle.

Integration == Testfälle zum Testen der Tiefe und des Integrationsgrades. Funktioniert es für alle Edge-Fälle und Eckfälle? Testfälle sind in der Regel technisch und werden von Designern und Programmierern geschrieben.

Akzeptanz == Testfälle, um nur die endbenutzerorientierten 80% des Funktionsumfangs auszuüben. Nicht alle Edge- und Corner-Cases. Testfälle sind in der Regel nicht technisch und werden von Endbenutzern geschrieben.

31
S.Lott

Ich persönlich stelle mir einen Integrationstest gerne als einen Feature-Test vor, wenn jede Komponente des Systems real ist, keine Scheinobjekte.

Ein echtes Repository, eine echte Datenbank, eine echte Benutzeroberfläche. Sie testen bestimmte Funktionen, wenn das System vollständig zusammengebaut ist und so ist, wie es bei der Bereitstellung sein soll.

16
user8685

In meiner (ich gebe zu) kleinen Erfahrung habe ich verstanden, dass die Word-Integration wirklich zu Missverständnissen führen kann: Es ist wirklich schwierig, etwas vollständig Isoliertes in einem System zu finden, einige Elemente müssen mit Sicherheit integriert werden.

So habe ich mich daran gewöhnt, folgende Unterscheidungen zu treffen:

  • Ich benutze Unit Test , um alle Verhaltensweisen zu identifizieren, zu dokumentieren und zu betonen, für die die Klasse, die ich teste, verantwortlich ist.
  • Ich mache Integrationstests , wenn ich eine Komponente (möglicherweise mehr als eine) in meinem System habe, die sich mit einer anderen unterhält " externes "System. (weiter unten ...)
  • Ich implementiere einen Abnahmetest , um einen bestimmten Workflow zu definieren, zu dokumentieren und zu betonen, der vom System erwartet wird.

In der Integrationstestdefinition meinte ich mit extern ein System, das außerhalb meines Entwicklungsbereichs liegt : Ich kann das Verhalten aus irgendeinem Grund nicht sofort ändern. Es kann sich um eine Bibliothek handeln, eine Komponente des Systems, die nicht geändert werden kann (dh sie wird mit anderen Projekten im Unternehmen geteilt), eine Datenbank usw. Für diese Tests muss ich etwas einrichten, das der realen Umgebung des Systems sehr ähnlich ist funktioniert in: Ein externes System muss initialisiert und auf einen bestimmten Zustand gesetzt werden; realistische Daten müssen in der Datenbank registriert sein; usw.

Wenn ich stattdessen Abnahmetests durchführe, fälsche ich Dinge: Ich arbeite an etwas anderem, ich arbeite an den Spezifikationen des Systems, nicht auf die Fähigkeit, mit externen Entitäten zusammenzuarbeiten.

Dies ist wirklich eine engere Sichtweise als das, was KeesDijk zuvor beschrieben hat. Ich nehme jedoch an, dass die Projekte, an denen ich bisher gearbeitet habe, klein genug waren, um mir diese Vereinfachungsstufe zu ermöglichen.

8
Marco Ciambrone

Ein Integrationstest bestätigt, dass Komponenten eines komplexen Systems (z. B. Software, Flugzeuge, Kraftwerk) wie geplant zusammenarbeiten.

Stellen wir uns vor, wir sprechen von einem Flugzeug (mit Software ist es abstrakter und es ist schwierig, den Unterschied zu machen). Die Integrationstests umfassen Folgendes:

  • korrekte Interaktion zwischen einigen Komponenten. Beispiel: Beim Drücken der Starttaste startet der Motor und der Propeller erreicht die erwartete Drehzahl (Flugzeug bleibt noch am Boden)
  • korrekte Interaktion mit externen Komponenten. Beispiel: Überprüfen Sie, ob das eingebettete Funkgerät mit einem stationären Funkgerät kommunizieren kann (Flugzeuge noch am Boden).
  • korrekte Interaktion zwischen allen beteiligten Komponenten, so dass das gesamte System wie erwartet funktioniert. Beispiel: Eine Besatzung von Testpiloten und Ingenieuren startet das Flugzeug und fliegt damit (alle tragen Fallschirme ...).

Der Integrationstest behebt ein technisches Problem , nämlich dass das System trotz seiner Unterteilung in Komponenten funktioniert. In der Software können die Komponenten Anwendungsfälle, Module, Funktionen, Schnittstellen, Bibliotheken usw. sein.

Der Abnahmetest bestätigt, dass das Produkt für den Zweck geeignet ist. Sie werden grundsätzlich vom Kunden durchgeführt. In Anlehnung an die Flugzeuganalogie wird Folgendes überprüft:

  • die geplanten Geschäftsszenarien führen in einer nahezu realen Situation zum erwarteten Ergebnis. Beispiel: Üben Sie ein Boarding mit Testpassagieren, um zu überprüfen, ob das Personal das Boarding wie erwartet anhand der Betriebsverfahren überwachen kann. Einige Szenarien könnten so einfach sein, dass sie wie ein Komponententest aussehen würden, aber sie werden vom Benutzer durchgeführt (z. B. versuchen Sie die elektrischen Stecker mit den Geräten des Unternehmens).
  • das System arbeitet in einer fast realen Geschäftssituation. Beispiel: Machen Sie einen leeren Testflug zwischen zwei realen Zielen mit neu ausgebildeten Piloten der Fluggesellschaft, um zu überprüfen, ob der Treibstoffverbrauch wie versprochen ist.

Der Abnahmetest befasst sich eher mit einem Verantwortungsproblem . In einer Kunden/Lieferanten-Beziehung kann es eine vertragliche Verantwortung sein (Einhaltung aller Anforderungen). In jedem Fall liegt es aber auch in der Verantwortung der verwendenden Organisation, sicherzustellen, dass ihre Aufgaben mit dem System ausgeführt werden können, und unvorhergesehene Probleme umsichtig zu vermeiden (z. B. wie diese Eisenbahngesellschaft, die bei Abnahmetests feststellte, dass sie einige Quais verkürzen musste, weil Die neuen Wagen waren 5 cm zu groß - kein Scherz!).

Schlussfolgerungen: Integrations- und Abnahmetests überschneiden sich. Beide wollen zeigen, dass das gesamte System funktioniert. Das "Ganze" könnte jedoch für den Kunden größer sein (da das System selbst Teil eines größeren Organisationssystems sein kann) und für den Systemintegrator technischer:

(enter image description here

7
Christophe

Integrationstests sind nichts anderes als die Überprüfung der Verbindung und Richtigkeit des Datenflusses zwischen zwei oder mehr Modulen.

Zum Beispiel: Wenn wir eine E-Mail (ein Modul) verfassen und an eine gültige Benutzer-ID (zweites Modul) senden, besteht der Integrationstest darin, zu überprüfen, ob die gesendete E-Mail in den gesendeten Elementen vorhanden ist.

1
Anita

Eine praktisch Definition eines Integrationstests lautet: Jeder Test, der die Interaktion mit etwas außerhalb des Prozesses erfordert.

Zum Beispiel:

  • Das Dateisystem
  • Das Netzwerk
  • Eine Datenbank
  • Eine externe API

Es gibt eine Art Vertrag zwischen Ihrem Prozess und der Außenwelt, und die minimale Überprüfung, dass der Vertrag das Ziel eines Integrationstests sein sollte. d.h. es sollte nicht mehr tun, als den Vertrag zu verifizieren. Wenn dies der Fall ist, bewegen Sie sich in Richtung des System-/End-to-End-Bereichs.

Unit-Tests können die gesamte Logik innerhalb Ihrer Prozessgrenze testen und dies problemlos, genau, da keine Abhängigkeiten von der langsamen/fragilen/komplexen "Außenwelt" bestehen.

Obwohl es Integrationstests gibt, wird diese Definition nicht behandelt (daher habe ich sie als praktisch Definition bezeichnet. Ich denke, sie sind viel weniger verbreitet/nützlich.

N.B. Genau genommen würde diese Definition auch System-/End-to-End-Tests abdecken. In meiner Philosophie sind sie eine Form des "extremen" Integrationstests, weshalb ihre Namen einen anderen Aspekt betonen. In der anderen Richtung kann ein Einheitentest als Integrationstest von Nullkomponenten betrachtet werden, d. H. Alle Tests können als irgendwo im Integrationsspektrum liegend betrachtet werden und zwischen 0-n Komponenten integrieren :-)

0
Schneider