Was ist ein Regressionstest? End-to-End-Regressionstests ohne Code
Was ist ein Regressionstest, und warum erkennen End-to-End-Regressionstests, was Unit-Tests übersehen: was abgedeckt werden sollte, wann die Tests laufen und wie Sie Regressionstests ohne Code automatisieren.
11 Min. LesezeitVom Team von GUI Test Studio
Was ist ein Regressionstest?
Definition
Ein Regressionstest prüft, ob eine Änderung an einer Anwendung nichts kaputtgemacht hat, was bereits funktionierte.
- Eine neue Funktion, eine Fehlerkorrektur, ein Bibliotheksupdate oder eine neue Browserversion kann jeweils einen Teil der Anwendung kaputtmachen, den niemand angefasst hat.
- Nach der Änderung werden dieselben Tests erneut ausgeführt, und ein Test, der vorher bestanden hat und jetzt fehlschlägt, hat eine Regression gefunden.
Das Wort kommt vom Rückschritt: Die Anwendung hat sich zurückentwickelt, sie leistet heute weniger als gestern.Genau das macht eine Regression für Nutzer so ärgerlich.Etwas, auf das sie sich verlassen haben, funktioniert einfach nicht mehr.
Regressionen entstehen, weil Teile einer Anwendung auf eine Weise voneinander abhängen, die niemand im Kopf behält.Ein gemeinsamer Stil, eine Rundungsregel, ein umbenanntes Feld in einer API: Eine kleine Änderung an einer Stelle wirkt bis zu Bildschirmen weit davon entfernt.Die Person, die die Änderung gemacht hat, hat geprüft, was sie geändert hat, und sie hatte recht.Der Fehler liegt woanders.
Regressionstest und Fehlernachtest im Vergleich
Die beiden werden oft verwechselt, und sie beantworten verschiedene Fragen.
| Frage | Fehlernachtest | Regressionstest |
|---|---|---|
| Was prüft er? | Dass ein behobener Fehler wirklich behoben ist. | Dass die Korrektur oder eine andere Änderung nichts anderes kaputtgemacht hat. |
| Wo sieht er hin? | An die Stelle des Fehlers. | Überall sonst, vor allem auf das, worauf sich Nutzer verlassen. |
| Welche Tests? | Die Schritte, die den Fehler gezeigt haben. | Dieselbe Suite, nach jeder Änderung erneut ausgeführt. |
| Wann? | Einmal, nach der Korrektur. | Nach jeder Änderung, solange es die Anwendung gibt. |
Unit-, Integrations- und End-to-End-Regressionstests
Regressionstests gibt es auf jeder Ebene einer Anwendung, und jede Ebene sieht einen anderen Teil davon.
Wie viel von der Anwendung jeder Test sieht
Unit-Tests
Eine Funktion, für sich allein
Erkennt: Eine Berechnung, die den falschen Wert liefert
Integrationstests
Zwei oder drei Teile zusammen
Erkennt: Ein Dienst, der nicht mehr so antwortet, wie der nächste es erwartet
End-to-End-Tests
Die ganze Anwendung, über ihren Bildschirm
Erkennt: Eine Summe, eine Schaltfläche, eine Seite oder eine Meldung, die der Nutzer kaputt sieht
Unit- und Integrationstests sind schnell und präzise, und jedes Team sollte sie haben.Aber sie prüfen den Code so, wie der Entwickler ihn sich vorstellt.Ein Nutzer ruft nie eine Funktion auf: Er klickt auf eine Schaltfläche, liest eine Summe und erwartet, dass sich die nächste Seite öffnet.
Manche Regressionen gibt es nur auf dem Bildschirm, wo Unit-Tests nie hinsehen.
- Eine Stiländerung versteckt die Bezahlen-Schaltfläche hinter einem Banner.
- Eine Summe wird richtig berechnet und mit der falschen Währung angezeigt.
- Ein Dialog öffnet sich hinter dem Fenster.
- Eine Übersetzung ist zu lang, und die Beschriftung wird abgeschnitten.
Deshalb zählen End-to-End-Regressionstests am meisten: Ein End-to-End-Test bedient die ganze Anwendung über ihre Oberfläche, so wie ein Nutzer sie durchläuft, und prüft, was der Nutzer sieht.Das ganze Bild finden Sie unter Was sind End-to-End-Tests.
Ihre Nutzer führen Ihre Unit-Tests nicht aus.Sie benutzen Ihre Anwendung, Bildschirm für Bildschirm.
Funktionale und nicht-funktionale Regressionstests
Funktionale Tests prüfen, was die Anwendung tut: Die Bestellung wird aufgegeben, der Bericht wird exportiert, die Fehlermeldung erscheint, wenn ein Feld leer ist.Nicht-funktionale Tests prüfen, wie sie es tut: wie schnell, wie es aussieht, wie sie sich auf einem anderen Gerät oder in einem langsamen Netz verhält.
Funktionale Regression
Die Kasse gibt die Bestellung noch auf, und die Bestätigung zeigt noch die Bestellnummer.
Visuelle Regression
Der Bildschirm sieht noch so aus wie vorher: kein fehlendes Symbol, kein abgeschnittenes Wort, keine Schaltfläche in der falschen Farbe.
Nicht-funktionale Regression
Die Seite lädt noch rechtzeitig, und das Layout hält auch auf einem Smartphone und bei einer langsamen Verbindung.
Die meisten Regressionssuiten sind funktional, und die meisten visuellen und Layoutfehler rutschen durch sie hindurch, weil eine funktionale Prüfung fragt, ob ein Element existiert, nicht ob ein Mensch es sehen kann.Visuelle Fehler, die Ihre automatisierten Tests übersehen zeigt, warum.
Was gehört in eine Suite von End-to-End-Regressionstests?
Eine Regressionssuite, die alles abdecken will, wird nie fertig, und niemand vertraut ihr.Fangen Sie klein an, mit dem, was am meisten schaden würde, wenn es kaputtginge.
- 1
Die Abläufe auflisten, ohne die Nutzer nicht auskommen
Registrierung, Anmeldung, Suche, Kasse, der Bericht, den Ihre Kunden jeden Montag exportieren.Fünf bis zehn Abläufe, jeder vom ersten Klick bis zu dem Ergebnis, das der Nutzer erwartet.
- 2
Hinzufügen, was schon einmal kaputtging
Jeder Fehler, der einmal bei den Nutzern angekommen ist, verdient einen Test, damit er nie unbemerkt zurückkommt.So lernt eine Regressionssuite dazu.
- 3
Nach Risiko gewichten, nicht nach Anzahl der Bildschirme
Ein Bildschirm, den jeder Kunde jeden Tag nutzt, zählt mehr als zehn Einstellungsseiten.Geld, Daten und Anmeldung kommen zuerst.
- 4
Ergebnisse prüfen, nicht nur Klicks
Ein Test, der sich durch die Kasse klickt und nie die Summe prüft, beweist wenig.Jeder Ablauf endet bei dem, weswegen der Nutzer gekommen ist, und der Test prüft es: die Summe, die Bestätigung, die exportierte Datei.
- 5
Schnell genug bleiben, um bei jeder Änderung zu laufen
Markieren Sie eine Handvoll Abläufe als Smoke-Suite, die bei jedem Pull-Request in wenigen Minuten laufen.Der Rest läuft jede Nacht.
Wann sollten Regressionstests laufen?
Je früher eine Regression gefunden wird, desto billiger ist sie: Die Änderung ist dem Entwickler noch frisch im Gedächtnis, und es wurde noch nichts darauf aufgebaut.
| Wann | Was läuft | Warum |
|---|---|---|
| Jeder Pull-Request oder Build | Die Smoke-Suite: die kritischen Abläufe. | Ein Fehler wird vor dem Merge erkannt, solange die Änderung klein ist. |
| Jede Nacht | Die ganze Suite. | Alles wird einmal am Tag geprüft, ohne jemanden aufzuhalten. |
| Vor einem Release | Die ganze Suite, auf jedem Browser und Gerät, das Sie unterstützen. | Was die Nutzer wirklich bekommen, wird dort geprüft, wo sie es bekommen. |
| Nach einem Update, auf das Sie keinen Einfluss haben | Die ganze Suite. | Eine neue Browser-, Betriebssystem- oder Bibliotheksversion kann die Anwendung kaputtmachen, ohne dass sich eine Zeile Ihres Codes ändert. |
Kassenablauf, die letzten acht Builds
- #38
- #39
- #40
- #41
- #42
- Ab hier fehlgeschlagen#43
- #44
- #45
#42 der letzte bestandene Lauf#43 die Änderung, die Sie zuerst ansehen sollten#45 korrigiert und erneut geprüft
Warum automatisierte Regressionstests aufgegeben werden
Die meisten Teams sind sich einig, dass Regressionstests automatisiert werden sollten.Viele haben es versucht, und viele automatisierte Suiten werden am Ende abgeschaltet oder ignoriert.Die Gründe sind fast immer dieselben.
Die Suite kostet in der Pflege mehr, als sie einspart.
- Codierte Tests finden Schaltflächen über Selektoren, und jedes Redesign macht Dutzende davon auf einmal kaputt.
- Nur Entwickler können sie reparieren, und Entwickler bauen gerade Funktionen.
- Tests schlagen aus harmlosen Gründen fehl, wegen eines Farbtons oder eines Pixels Kantenglättung, also lesen die Leute die Ergebnisse nicht mehr.
- Die ganze Suite dauert Stunden, also läuft sie einmal pro Woche, und Regressionen warten tagelang darauf, gefunden zu werden.
End-to-End-Regressionstests ohne Code automatisieren
GUI Test Studio ist für End-to-End-Regressionstests von Web-Apps, Windows-Desktop-Apps, Smartphones und Spielen gebaut, über ihre Oberfläche, ohne Testcode, der geschrieben oder gepflegt werden muss.
Jeden Ablauf einmal aufzeichnen
Klicken Sie im GUI Test Runner-Recorder auf „Aufzeichnen“, und gehen Sie den Ablauf in Ihrer echten Anwendung durch, so wie ein Nutzer es tun würde.Die Klicks, die Eingaben und die Prüfungen dessen, was erschienen ist, werden zu einem Test.Sie können den Ablauf auch Ihrem KI-Assistenten in einem Prompt beschreiben, und der Test wird für Sie erstellt.
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.
- Die GTS Engine + AI findet jedes Element zuerst über die Barrierefreiheitsinformationen der Anwendung und am Aussehen, wenn die Anwendung nichts sagt, sodass ein Redesign des Codes hinter einer Schaltfläche den Test nicht kaputtmacht.
Ihn wie ein Video bearbeiten
Jeder Test öffnet sich in GUI Test Studio auf einer Zeitleiste: seine Schritte als Blöcke, seine Prüfungen daneben, die Aufzeichnung darüber.Ändern Sie eine Prüfung, fügen Sie eine Wartezeit hinzu, gruppieren Sie die Schritte eines Ablaufs: ohne Code, und jeder im Team kann es.Siehe die Zeitleiste.
Ihn bei jedem Build ausführen
gtr-cli führt die Suite auf einem Windows-Build-Rechner aus und antwortet so, wie eine Pipeline es erwartet: Ein fehlgeschlagener Test lässt den Build fehlschlagen, eine JUnit-Datei füllt die Registerkarte der Tests, und jedes Bild dessen, was fehlgeschlagen ist, wird aufbewahrt.
gtr-cli run tests\regression --countdown 0 --junit results\junit.xml --artifacts results\artifactsDas funktioniert in TeamCity, Jenkins, GitHub Actions, GitLab und Azure DevOps.Siehe Tests in Ihrer Pipeline ausführen.
Eine echte Regression oder harmloses Rauschen?
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 es aufgezeichnet wurde, mit dem erwarteten und dem gefundenen Bild nebeneinander und dem umrandeten Unterschied.
Rauschen wird ignoriert, und Regressionen werden erkannt.
- Leichte Rendering-Unterschiede, die kein Mensch bemerken würde, werden nicht gezählt.
- Ein geändertes Wort, ein fehlendes Badge oder eine grau gewordene Schaltfläche lässt die Prüfung fehlschlagen.
- Wenn sich ein Bild unterscheidet, kann die Intelligente KI-Analyse einen zweiten Blick darauf werfen und in einfachen Worten sagen, was sich geändert hat.
Eine gewollte Änderung wird mit einem Klick übernommen
Nicht jeder Unterschied ist eine Regression: Manchmal ist der neue Bildschirm der richtige.Übernehmen Sie im Konfidenzbericht, was der Lauf gefunden hat, als neues erwartetes Bild, und der nächste Lauf prüft dagegen.Für Bildschirme, die absichtlich abweichen, etwa einen dunklen Modus oder eine andere Sprache, behalten Baselines eine Version pro Umgebung.
Wissen, wann es angefangen hat
Jeder Lauf wird im Verlauf des Tests aufbewahrt.Wenn ein Ablauf fehlzuschlagen beginnt, zeigt der Verlauf den letzten Lauf, der bestanden hat, und den ersten, der fehlgeschlagen ist, und zwei Läufe lassen sich Prüfung für Prüfung vergleichen.
Jeder Browser und jedes Gerät, und ein Bug in Ihrem Tracker
Ein Web-Test, einmal aufgezeichnet, läuft in Chrome, Edge und Firefox, auf Smartphones und Tablets, in anderen Sprachen und Bildschirmgrößen: siehe Cross-Browser-Testing.Und ein fehlgeschlagener Lauf kann von selbst zu einem Jira-Vorgang werden, mit den Schritten zur Reproduktion und den Bildern: siehe fehlgeschlagene Tests als Jira-Bugs.
Eine Änderung wird gepusht
Eine Funktion, eine Korrektur, ein Update
Der Build läuft
gtr-cli führt die Suite aus
Konfidenzbericht
Regression oder Rauschen, mit Bildern
Merge oder erst korrigieren
Ein Fehlschlag blockiert die Änderung
Empfohlen
- Eine kleine Suite kritischer Abläufe bei jedem Build
- Prüfungen dessen, was der Nutzer am Ende jedes Ablaufs sieht
- Ein Test für jeden Fehler, der bei den Nutzern ankam
- Jeder Browser und jedes Gerät vor einem Release
Vermeiden
- Eine Suite, so groß, dass sie nur einmal pro Woche läuft
- Tests, die sich durch einen Ablauf klicken und nichts prüfen
- Fehlschläge, die niemand liest, weil die Hälfte davon Rauschen ist
- Tests, die nur Entwickler ändern können
Das Wichtigste in Kürze
- 1Ein Regressionstest prüft, ob eine Änderung nichts kaputtgemacht hat, was funktionierte. Dieselben Tests, nach jeder Änderung erneut ausgeführt.
- 2Der Fehlernachtest beweist eine Korrektur; der Regressionstest beweist, dass die Korrektur nichts anderes gekostet hat.
- 3End-to-End-Regressionstests erkennen, was Nutzer spüren: die Summen, Schaltflächen, Seiten und Meldungen, die Unit-Tests nie sehen.
- 4Klein anfangen: fünf bis zehn kritische Abläufe bei jedem Build, die ganze Suite jede Nacht, jeder Browser und jedes Gerät vor einem Release.
- 5Eine Suite muss eine Regression von Rauschen unterscheiden und wenig Pflege kosten, sonst wird sie aufgegeben.
Fragen
Was ist ein Regressionstest?
Ein Regressionstest prüft, ob eine Änderung an einer Anwendung nichts kaputtgemacht hat, was bereits funktionierte.Nach einer neuen Funktion, einer Fehlerkorrektur oder einem Update werden dieselben Tests erneut ausgeführt, und jeder Test, der vorher bestanden hat und jetzt fehlschlägt, weist auf eine Regression hin.
Was ist der Unterschied zwischen Regressionstest und Fehlernachtest?
Ein Fehlernachtest prüft, ob ein behobener Fehler wirklich behoben ist.Ein Regressionstest prüft, ob die Korrektur oder eine andere Änderung den Rest der Anwendung nicht kaputtgemacht hat.Der Fehlernachtest sieht auf eine Stelle, der Regressionstest auf alles andere.
Was sind End-to-End-Regressionstests?
End-to-End-Regressionstests führen nach jeder Änderung die wichtigen Abläufe einer Anwendung über ihre Oberfläche aus, so wie ein Nutzer sie durchläuft.Sie erkennen die Fehler, die sich nur auf dem Bildschirm zeigen: eine falsche Summe, eine Schaltfläche, die ihren Dialog nicht mehr öffnet, eine Seite, die nicht lädt.
Ist ein Regressionstest funktional oder nicht-funktional?
Beides.Die meisten Regressionstests sind funktional: Sie prüfen, ob Funktionen noch tun, was sie sollen.Eine Regression kann auch nicht-funktional sein, etwa eine Seite, die langsam geworden ist, oder ein Layout, das auf einem Smartphone kaputtgegangen ist, und solche Regressionen verdienen eigene Tests.
Wie oft sollten Sie Regressionstests ausführen?
Führen Sie bei jedem Pull-Request oder Build eine kurze Suite kritischer Abläufe aus, jede Nacht die ganze Suite und vor einem Release die ganze Suite auf jedem Browser und Gerät.Je früher eine Regression erkannt wird, desto billiger ist ihre Korrektur.
Lassen sich Regressionstests ohne Code automatisieren?
Ja.Mit GUI Test Studio zeichnen Sie einen Ablauf einmal auf, indem Sie die Anwendung benutzen, oder Sie beschreiben ihn in einem Prompt, und der Test wird für Sie erstellt.Er läuft mit gtr-cli bei jedem Build erneut, und niemand muss Testcode pflegen.
Was sind visuelle Regressionstests?
Visuelle Regressionstests vergleichen, was der Bildschirm jetzt zeigt, mit dem, was er vorher gezeigt hat, um Änderungen zu erkennen, die ein Nutzer sehen würde: ein fehlendes Symbol, ein abgeschnittenes Wort, eine Schaltfläche in der falschen Farbe.Sie sind eine Art der End-to-End-Regressionsprüfung.
OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps, Chrome, Edge und Firefox 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.