Was ist Regression Testing?

Was ist Regression Testing?

Regression Testing ist die Praxis, Ihre bestehende Test-Suite gegen jede Code-Änderung erneut auszuführen, um zu bestätigen, dass nichts zuvor Funktionierendes kaputt gegangen ist. Das Wort "Regression" bedeutet einen Rückwärtsschritt: ein Feature, das gestern bestanden hat und heute scheitert. Regression Tests fangen diese Rückwärtsschritte, bevor sie Benutzer erreichen.

Jeder ausgelieferte Bug wird zum Samen eines Regression Tests. Der Fix landet mit einem neuen Test, der den Bug reproduziert, und von da an stellt die Suite sicher, dass dieser Bug nie zurückkehrt. Über Jahre wird die Regression Suite zum ausführbaren Gedächtnis jedes Defekts, den das Team bezahlt hat.

Regression Testing vs Smoke Testing vs Full QA

Drei Schichten, zunehmender Scope:

• Smoke Testing: Sekunden. Ist der Build hochgekommen? 5-15 Critical-Path-Checks. Nur Gate.
• Regression Testing: Minuten bis eine Stunde. Ist etwas, das früher funktionierte, jetzt kaputt? Hunderte bis Tausende von Tests, die jedes ausgelieferte Feature abdecken.
• Full QA / Acceptance: Stunden, oft manuell. Erfüllt jeder Flow die Spec für den anstehenden Release? Inkl. exploratorische + manuelle Checks.

Regression sitzt in der Mitte und ist der Test-Typ, in den die meisten Teams am stärksten investieren, weil er automatisierbar, wiederholbar ist und jeden Merge gatet.

Funktional vs visuell vs Performance-Regression

• Funktionale Regression. Unit-, Integration-, End-to-End-Tests. "In den Warenkorb legen fügt noch ein Item hinzu." Die Mehrheit jeder Regression Suite.
• Visuelle Regression. Screenshot-Vergleich; Pixel-Diffs markieren unbeabsichtigte CSS- oder Layout-Änderungen. Tools: Percy, Chromatic, Playwrights toHaveScreenshot().
• Performance-Regression. p95-Latenz bei erwarteter Last sollte zwischen Releases nicht degradieren. Führen Sie einen Load Test gegen die Baseline und den neuen Build aus; asserten Sie, dass Latenz, Durchsatz und Fehlerrate nicht schlechter wurden. Leicht zu überspringen und das Erste, das in Production zubeißt.

Wann Regression Tests ausführen

1. Bei jedem Pull Request. Vor dem Merge. Der PR mergt nicht, es sei denn, Regression besteht.
2. Bei jedem Main-Branch-Commit. Fängt Integrations-Issues von gleichzeitigen PRs, die einzeln jeweils bestanden haben.
3. Pre-Release. Ein vollständiger Regression-Run gegen den Release Candidate vor dem Deploy. Oft langsamer / gründlicher als der Per-PR-Run.
4. Nightly. Die teuren Teile der Suite (Browser-Tests, Performance-Regression, langlaufende Integration) laufen über Nacht, ohne den Entwickler-Flow zu blockieren.

Wichtige Regression-Testing-Praktiken

1. Jeder behobene Bug bekommt einen Test. Fix und Regression Test landen im selben Commit. Keine Ausnahmen.
2. Tests sind deterministisch. Flaky Regression Tests trainieren das Team, Failures zu ignorieren. Eliminieren Sie Timing-Annahmen, mocken Sie externe Services, fixen oder löschen Sie Flakes innerhalb einer Woche.
3. Tests laufen schnell. Ein voller PR-blockierender Regression Run sollte in unter 10 Minuten fertig sein; sonst context-switchen Entwickler und verlieren Flow. Parallelisieren.
4. Performance ist Teil von Regression. Ein Load Test in CI/CD mit Assertions auf p95 + Fehlerrate fängt den langsamen Drift, den funktionale Tests verfehlen.

Wie Performance-Regression ausführen

Nehmen Sie dasselbe Skript, das Sie für Load Testing verwenden, und führen Sie es gegen sowohl den Baseline-Build als auch den neuen Build bei identischer Last aus. Vergleichen Sie p95, p99, Durchsatz und Fehlerrate.

In JMeter speichern Sie den JTL-Output und diffen Sie aggregierte Metriken. In k6 verwenden Sie thresholds im Skript: http_req_duration: ['p(95)<800'] bricht den Build, wenn p95 800 ms überschreitet. Gescheiterte Thresholds setzen den Exit Code, sodass CI die Regression automatisch fängt.

Für Multi-Region-Last gegen einen echten CDN-Edge, führen Sie von LoadFocus aus. Performance-Regression, die von einer einzelnen lokalen Maschine lief, verfehlt Regressionen in geo-verteilten Pfaden (DNS, Edge Cache, regionales Datenbank-Failover).

Wenn Ihr Team keine Zeit hat, Performance-Regression in CI zu bauen, bietet LoadFocus Load Testing Services, wo Ingenieure die Regressions-Szenarien designen, sie in Ihre Pipeline verdrahten und Failures gegen historische Baselines triagieren.