End-to-End-Tests und Integrationstests: was jeder findet (mit Beispielen)
End-to-End-Tests und Integrationstests: was jeder sieht, der Kassenfehler, den nur ein Test des Bildschirms findet, die Testpyramide und wie viele End-to-End-Tests Sie brauchen.
10 Min. LesezeitVon Ait Nohaila, Business Development Representative
End-to-End-Tests und Integrationstests: der Unterschied in einem Satz
Definition
Integrationstests prüfen, dass zwei oder mehr Teile einer Anwendung an ihrer Nahtstelle zusammenarbeiten, über Code oder eine API, während End-to-End-Tests die ganze Anwendung über ihren Bildschirm prüfen, so wie ein Nutzer sie durchläuft.
- Ein Integrationstest stellt dem Code eine Frage: Hat der Warenkorbdienst die Summe geliefert, die die Kasse erwartet?
- Ein End-to-End-Test stellt dem Bildschirm eine Frage: Sieht der Nutzer die richtige Summe dort, wo er sie erwartet?
- Beide werden gebraucht, und keiner kann die Frage des anderen beantworten.
Die beiden werden verwechselt, weil beide mehr als ein Teil auf einmal testen.Der Unterschied ist, wo der Test steht.Ein Integrationstest steht an der Nahtstelle zwischen zwei Teilen und beobachtet, was sie überquert.Ein End-to-End-Test steht dort, wo der Nutzer steht, vor dem Bildschirm, und beobachtet das Ergebnis von allem dahinter.
Integrationstests prüfen die Nahtstelle.Ein End-to-End-Test prüft, was gezeichnet wird.
E2E-Tests und Integrationstests im Vergleich
So schneiden die beiden bei den Fragen ab, die sich ein Team stellt, wenn es entscheidet, was automatisiert wird.
| Frage | Integrationstests | End-to-End-Tests |
|---|---|---|
| Umfang | Zwei oder mehr Teile der Anwendung, zusammen: ein Dienst und seine Datenbank, die API und das Modul, das sie aufruft. | Die ganze Anwendung, wie der Nutzer sie vorfindet, mit jedem Teil, von dem sie abhängt: der Bildschirm, die Dienste dahinter, oft andere Systeme wie ein Zahlungsanbieter. |
| Einstiegspunkt | Code oder eine API: Der Test ruft eine Funktion auf oder sendet eine Anfrage und liest die Antwort. | Der Bildschirm: Der Test klickt, tippt und liest, was gezeichnet wird, so wie ein Mensch es täte. |
| Was er findet | Einen Teil, der nicht mehr so antwortet, wie der nächste Teil es erwartet: ein umbenanntes Feld, einen falschen Status, einen fehlenden Datensatz. | Einen Ablauf, der dem Nutzer nicht mehr das richtige Ergebnis liefert: eine falsche Summe auf dem Bildschirm, eine Schaltfläche, die nichts tut, eine Seite, die sich nicht öffnet. |
| Geschwindigkeit | Millisekunden bis Sekunden pro Test.Hunderte können bei jedem Commit laufen. | Sekunden bis Minuten pro Ablauf.Eine Suite aus einigen Dutzend läuft bei jedem Build oder jede Nacht. |
| Kosten | Günstig zu schreiben für die Person, die die Nahtstelle entwickelt hat, und günstig auszuführen. | Teuer, wenn er aus Code besteht: Jedes Redesign macht Selektoren kaputt.Günstig, wenn er vom Bildschirm aufgezeichnet und ohne Code gepflegt wird. |
| Wer ihn schreibt | Das Entwicklungsteam, während es jede Nahtstelle baut. | Tester, QA-Engineers und Product Owner, die wissen, was der Nutzer erwartet; das Entwicklungsteam ebenso. |
| Wann er läuft | Bei jedem Commit, im Build, bevor etwas gemergt wird. | Bei jedem Build oder Pull-Request für einige kritische Abläufe, jede Nacht für die ganze Suite, auf jedem Browser und Gerät vor einem Release. |
Der Fehler, den ein Integrationstest nicht sehen kann
Nehmen Sie eine Kasse.Der Warenkorbdienst addiert die Artikel, der Preisdienst wendet den Versandtarif an, und die Kassenseite zeichnet das Ergebnis in drei Zeilen: Zwischensumme, Versand und Gesamt.Eines Tages räumt jemand im Entwicklungsteam die Kassenvorlage auf.Eine Zeile verrutscht.Der Code dahinter bleibt unberührt.
Der Integrationstest fragt die API nach der Summe des Warenkorbs und vergleicht sie mit der erwarteten Zahl.Er bekommt 48.90, genau richtig, und besteht.Jeder Dienst hat seine Arbeit getan, und die Nahtstelle zwischen ihnen ist in Ordnung.
Der End-to-End-Test tut, was ein Kunde tut: zwei Artikel hinzufügen, die Kasse öffnen und vor dem Bezahlen die Summe lesen.Auf dem Bildschirm ist die Zeile Gesamt leer, und 48.90 steht jetzt neben Versand.Ein Kunde liest, dass der Versand 48.90 kostet und nichts zu zahlen ist.Das ist ein Fehler, über den niemand streiten würde, und kein Integrationstest kann ihn sehen, weil ein Integrationstest nie auf die Seite schaut.
Dasselbe Muster verbirgt viele der Fehler, die bei den Nutzern ankommen.
- Eine in Dollar berechnete Summe, mit einem Eurozeichen gezeichnet.
- Eine Schaltfläche Bezahlen, die ein neues Banner aus dem sichtbaren Bereich schiebt.
- Eine Bestätigungsmeldung, die hinter dem Fenster erscheint.
- Eine Beschriftung, die nach einer Übersetzung zu lang für ihr Feld ist.
- In jedem Fall sind die Daten richtig und der Bildschirm ist falsch.
Es ist dieselbe Lücke, die der Artikel Visuelle Fehler, die Ihre automatisierten Tests übersehen von der anderen Seite beschreibt: Eine Prüfung, die fragt, ob ein Element existiert, kann nicht sagen, ob ein Mensch es sehen, lesen oder anklicken kann.
Die Testpyramide: wo sich jede Ebene ihren Platz verdient
Die Testpyramide ist das übliche Bild dafür, wie groß eine Suite sein sollte.Ihre Form handelt von Kosten, nicht von Wichtigkeit: Ein Unit-Test läuft in einer Millisekunde und lässt sich für jeden Fall schreiben, ein End-to-End-Test startet die echte Anwendung und folgt einem Ablauf, also gibt es weniger davon.
Die Testpyramide: wie viele Tests, und was jede Ebene sieht
Unit-Tests
Ein Unit-Test verdient sich seinen Platz, indem er eine falsche Berechnung in dem Moment fängt, in dem sie geschrieben wird, in der Funktion, die sie gemacht hat.
Integrationstests
Ein Integrationstest verdient sich seinen Platz, indem er eine gebrochene Nahtstelle fängt: ein Feld, das in einem Dienst umbenannt wurde und von einem anderen noch erwartet wird.
End-to-End-Tests
Ein End-to-End-Test verdient sich seinen Platz, indem er fängt, was nur der Bildschirm zeigt: die richtige Zahl im falschen Feld, die Schaltfläche, die sich nicht anklicken lässt, die Seite, die sich nie öffnet.
Systemtests stehen neben der Spitze der Pyramide, und viele Teams verwenden die beiden Namen für dasselbe.Die nützliche Unterscheidung: Systemtests prüfen die zusammengesetzte Anwendung gegen ihre Anforderungen, End-to-End-Tests folgen dem Ablauf eines Nutzers durch alles, was dieser Ablauf berührt.Die Seite Was End-to-End-Tests sind zeigt das ganze Bild.
Integrationstests oder End-to-End-Tests: wann welche
Die Wahl ist selten entweder oder.Jede Ebene ist bei einer anderen Art von Frage am günstigsten, und ein Team, das weiß, welche Frage es stellt, setzt den Test an die richtige Stelle.
Verwenden Sie einen Integrationstest, wenn es um eine Nahtstelle geht.
- Antwortet die API noch in der Form, die das Modul erwartet?
- Kommt die Bestellung mit jedem Feld in der Datenbank an?
- Kommt die Ablehnung des Zahlungsanbieters als der Fehler zurück, den der Code behandelt?
- Das sind viele kleine Fälle, die am besten schnell geprüft werden, bei jedem Commit, von der Person, die die Nahtstelle gebaut hat.
Verwenden Sie einen End-to-End-Test, wenn es um das Ergebnis des Nutzers geht.
- Kann sich ein Kunde anmelden, ein Produkt finden, bezahlen und die Bestätigung mit der richtigen Bestellnummer sehen?
- Öffnet sich der Bericht, den die Finanzabteilung jeden Montag exportiert, noch mit den richtigen Spalten?
- Das sind einige ganze Abläufe, geprüft dort, wo der Nutzer sie prüfen würde, bei jedem Build.
Verwenden Sie beide, wo Geld, Daten oder eine Anmeldung im Spiel sind.
- Die Kasse oben braucht ihre Integrationstests, damit eine falsche Summe an der Nahtstelle gefangen wird, die sie erzeugt hat, und ihren End-to-End-Test, damit auch eine richtige Summe an der falschen Stelle gefangen wird.
- Keiner hätte an diesem Tag den anderen ersetzen können.
Beide Ebenen sind Regressionstests: Sie werden nach jeder Änderung erneut ausgeführt, um zu beweisen, dass nichts kaputtgegangen ist, was funktioniert hat.Der Artikel Was ein Regressionstest ist erklärt, wann jede ausgeführt wird und warum Suiten aufgegeben werden, wenn sie mehr kosten, als sie fangen.
Wie viele End-to-End-Tests brauchen Sie?
Weniger, als Sie denken, und besser ausgewählt.Die Spitze der Pyramide ist kein Ort, um jeden Bildschirm aufzulisten.Sie ist ein Ort für die Abläufe, deren Ausfall am meisten wehtun würde, jeder vom ersten Klick bis zu dem Ergebnis verfolgt, für das der Nutzer gekommen ist, und jeder mit einer Prüfung dieses Ergebnisses.
Die meisten Anwendungen sind mit einer kurzen Liste abgedeckt.
- 1Registrierung und Anmeldung, einschließlich des Fehlers bei einem falschen Passwort.
- 2Die Hauptaufgabe, für die die Anwendung existiert: eine Bestellung aufgeben, einen Termin buchen, einen Kunden anlegen, einen Antrag einreichen.
- 3Die Zahlung, bis zur Bestätigung und ihrer Bestellnummer.
- 4Die Suche oder Liste, von der ein Nutzer jeden Tag ausgeht.
- 5Der Export oder Bericht, auf den sich ein Kunde verlässt.
- 6Jeder Ablauf, der einmal kaputtging und bei den Nutzern ankam.
Fünf bis fünfzehn solcher Abläufe, bei jedem Build ausgeführt, fangen das meiste von dem, was eine Integrationssuite durchlässt.Jeder endet mit einer Prüfung dessen, was der Bildschirm zeigt: die Summe, die Bestätigung, die exportierte Datei.Ein Test, der sich durch einen Ablauf klickt und nichts prüft, beweist wenig.
Was bei jedem Schritt geprüft wird, ist eine Wahl, die es sich bewusst zu treffen lohnt: ein Bild des Elements, seine Wörter oder das, was auf dem Bildschirm erschienen ist.Der Leitfaden Wählen, was ein Test prüft geht sie Schritt für Schritt durch.
Die End-to-End-Ebene ohne Code automatisieren
Die End-to-End-Ebene ist die, die die meisten Teams dünn lassen, weil sie am teuersten zu pflegen war: Codierte Tests finden Elemente über Selektoren, und jedes Redesign macht sie kaputt.GUI Test Studio nimmt den Code aus dieser Ebene heraus.Es testet Web-Apps, Windows-Desktop-Apps, Android-Smartphones und Spiele über ihren Bildschirm, so wie ein Nutzer es tut.
Aufzeichnen oder beschreiben
Klicken Sie auf Aufzeichnen und gehen Sie den Ablauf in Ihrer echten Anwendung durch: die Artikel hinzufügen, die Kasse öffnen, die Summe lesen.Die Klicks, die Eingaben und die Prüfungen dessen, was erschienen ist, werden zu einem Test, ohne eine Zeile Code.Sie können den Ablauf auch in einem Prompt für Ihren KI-Assistenten beschreiben, und der Test wird für Sie erstellt.Ihr erster Test, Schritt für Schritt dauert etwa zehn Minuten.
Der Test prüft, was der Bildschirm zeigt, nicht den Code dahinter.
- Eine Bild-Assertion vergleicht das Bild eines Elements, eine Text-Assertion liest seine Wörter, und eine Prüfung dessen, was erschienen ist, fängt den Dialog oder die Meldung, die der Schritt geöffnet hat.
- Die GTS Engine + AI findet jedes Element zuerst über die Barrierefreiheitsinformationen der Anwendung, und am Aussehen, wenn die Anwendung nichts sagt.
Bei jedem Build ausführen
gtr-cli führt die End-to-End-Suite auf einem Windows-Build-Rechner aus und antwortet so, wie eine Pipeline es erwartet: Ein fehlgeschlagener Ablauf lässt den Build fehlschlagen, eine JUnit-Datei füllt die Test-Registerkarte, und jedes Bild dessen, was fehlgeschlagen ist, wird neben den Integrationsergebnissen aufbewahrt.
gtr-cli run tests\journeys --countdown 0 --junit results\junit.xml --artifacts results\artifactsEs funktioniert in TeamCity, Jenkins, GitHub Actions, GitLab und Azure DevOps: siehe Tests in Ihrer Pipeline ausführen.
Der Konfidenzbericht sagt, was sich geändert hat
Jeder Lauf endet in einem Konfidenzbericht.Für jede Prüfung sagt er, ob das Element gefunden wurde und ob es noch so aussieht wie aufgezeichnet, mit dem erwarteten und dem gefundenen Bild nebeneinander und der Differenz umrandet.Für die Kasse oben zeigt er die Zeile Gesamt leer und 48.90 eine Zeile höher: genau das, was ein Tester in den Fehlerbericht geschrieben hätte.
Rauschen wird ignoriert und Regressionen werden gefangen.
- Leichte Rendering-Unterschiede, die kein Mensch bemerken würde, zählen nicht, während ein geändertes Wort, ein fehlendes Badge oder eine Zahl in der falschen Zeile die Prüfung fehlschlagen lässt.
- Weicht ein Bild ab, kann die intelligente KI-Analyse ein zweites Mal hinsehen und in einfachen Worten sagen, was sich geändert hat, in der Cloud mit Ihrem eigenen Schlüssel oder auf Ihrem eigenen Computer mit einem lokalen KI-Modell, einem von uns oder Ihrem eigenen.
Eine Änderung wird gepusht
Die Kassenvorlage wird aufgeräumt
Der Build läuft
Integrationstests, dann gtr-cli
Konfidenzbericht
Die Summe steht in der falschen Zeile
Vor dem Merge behoben
Der Nutzer hat es nie gesehen
Das Wichtigste in Kürze
- 1Integrationstests prüfen die Nahtstelle zwischen Teilen; ein End-to-End-Test prüft, was für den Nutzer gezeichnet wird.
- 2Derselbe Fehler kann zugleich grün und rot sein: Die API liefert die richtige Summe, der Bildschirm zeigt sie im falschen Feld.
- 3Die Form der Pyramide handelt von Kosten, nicht von Wichtigkeit: viele schnelle Tests unten, einige ganze Abläufe oben, jeder fängt, was die anderen nicht können.
- 4Verwenden Sie beide, wo Geld, Daten oder eine Anmeldung im Spiel sind, und wählen Sie die Ebene danach, wer den Fehlerbericht schreiben würde: ein Nutzer oder jemand aus dem Entwicklungsteam.
- 5Fünf bis fünfzehn Abläufe, jeder mit einer Prüfung seines Ergebnisses, decken das meiste von dem ab, was die Integrationssuite durchlässt, und sie lassen sich ohne Code aufzeichnen.
Fragen
Was ist der Unterschied zwischen End-to-End-Tests und Integrationstests?
Integrationstests prüfen, dass zwei oder mehr Teile einer Anwendung an ihrer Nahtstelle zusammenarbeiten, meist über Code oder eine API.End-to-End-Tests prüfen die ganze Anwendung über ihren Bildschirm, so wie ein Nutzer sie durchläuft.Ein Integrationstest kann bestehen, während der Bildschirm das Falsche zeigt.
Sind End-to-End-Tests dasselbe wie Systemtests?
Sie überschneiden sich, und viele Teams verwenden die Wörter für dasselbe.Systemtests prüfen die vollständige, zusammengesetzte Anwendung gegen ihre Anforderungen.End-to-End-Tests folgen dem Ablauf eines Nutzers vom ersten Klick bis zum Ergebnis, durch jeden Teil, den der Ablauf berührt, andere Systeme eingeschlossen.
Können Integrationstests End-to-End-Tests ersetzen?
Nein.Integrationstests beweisen, dass Teile zueinander passen, nicht, dass ein Nutzer auf dem Bildschirm das richtige Ergebnis bekommt.Eine Summe kann von jedem Dienst richtig berechnet und trotzdem im falschen Feld gezeichnet oder hinter einem Banner verborgen sein, und nur ein Test, der auf den Bildschirm schaut, sieht das.
Was sollte man zuerst schreiben, Integrationstests oder End-to-End-Tests?
Das Entwicklungsteam schreibt Integrationstests, während es jede Nahtstelle baut, also kommen diese meist zuerst.Die ersten End-to-End-Tests gehören zu den Abläufen, deren Ausfall am meisten wehtun würde, etwa Anmeldung und Kasse, und sie lassen sich aufzeichnen, sobald diese Abläufe funktionieren.
Wie viele End-to-End-Tests sollte ein Projekt haben?
Weniger, als Sie denken, und besser ausgewählt.Fünf bis fünfzehn Abläufe decken ab, was in den meisten Anwendungen auf keinen Fall kaputtgehen darf: Registrierung, Anmeldung, die Hauptaufgabe, die Zahlung, den Export, auf den sich Kunden verlassen.Jeder folgt einem Ablauf bis zu dem Ergebnis, für das der Nutzer gekommen ist, und prüft dieses Ergebnis.
Warum sind End-to-End-Tests langsamer als Integrationstests?
Ein End-to-End-Test startet die echte Anwendung, bedient ihre Bildschirme und wartet, bis jeder reagiert, also dauert ein Ablauf Sekunden bis Minuten, wo ein Integrationstest Millisekunden braucht.Deshalb decken End-to-End-Tests einige wichtige Abläufe ab, und Integrationstests viele Fälle.
Was ist die Testpyramide?
Die Testpyramide ist eine Art, eine Testsuite zu bemessen: viele schnelle Unit-Tests an der Basis, weniger Integrationstests in der Mitte und eine kleine Zahl von End-to-End-Tests an der Spitze.Jede Ebene fängt, was die Ebenen darunter nicht können, und die oberste Ebene ist die einzige, die sieht, was der Nutzer sieht.
Wer schreibt End-to-End-Tests?
Jeder, der weiß, was der Nutzer erwartet, kann es, wenn das Werkzeug keinen Code braucht.Mit GUI Test Studio zeichnet ein Tester oder ein Product Owner einen Ablauf auf, indem er die Anwendung benutzt, oder beschreibt ihn in einem Prompt, und der Test läuft mit gtr-cli bei jedem Build.
TeamCity, Jenkins, GitHub, GitLab und Azure DevOps sind Marken ihrer jeweiligen Inhaber.
Bereit, Ihren ersten Test aufzuzeichnen?
Jede Funktion, 15 Tage lang.
Lieber an der Art von App sehen, die Sie testen?Buchen Sie ein kostenloses 30-minütiges Gespräch mit unserem Team.