Antwort.

Geschichte der Frage:

Rauch-Tests (smoke tests, „Rauchprüfungen“) entstanden ursprünglich als schneller Weg, um sicherzustellen, dass die grundlegendste Funktionalität des Systems nach der Bereitstellung oder Änderung des Codes funktioniert. Ihre Ideologie lautet: „Wenn etwas Kritisches kaputt ist, macht es keinen Sinn, detaillierte Prüfungen durchzuführen.“ Bei der Automatisierung wurden die ersten Rauch-Tests als kleine manuelle Skripte umgesetzt, um den Start der Anwendung, den Zugang zum Login-Bildschirm und grundlegende Aktionen zu überprüfen.

Problem:

Die Hauptschwierigkeiten bei der Automatisierung von Rauch-Tests sind die richtige Isolierung des minimalen Satzes von Szenarien, hohe Ausführungsgeschwindigkeit, minimale Abhängigkeit von instabilen Komponenten (z. B. externen Diensten) sowie visuelle und technische Unterstützung ihrer „Leichtigkeit und Transparenz“. Wenn dies nicht beachtet wird, wird die Rauch-Automatisierung entweder zu schwer oder gibt häufig falsche Alarme und erfordert viel Wartung.

Lösung:

Minimieren Sie die Anzahl der Rauch-Tests: Sie sollten nur die Überprüfungen der kritischsten „Eingangspunkte“ enthalten (z. B. Authentifizierung, Start des Hauptmoduls, Verfügbarkeit der Datenbank).
Führen Sie instabile Schritte und externe Abhängigkeiten aus den Rauch-Szenarien heraus oder stabilisieren Sie die Umgebungen mit „Stubs“.
Verwenden Sie Tagging (@smoke, Suite('smoke') usw.) und separate Abschnitte in der CI/CD-Pipeline, um die Rauch-Tests immer zuerst auszuführen.

Wichtige Merkmale:

Rauch-Szenarien sollten schnell ausgeführt werden und nur den stabilsten Teil der Infrastruktur verwenden.
Automatisierte Tests der Rauch-Klasse sollten keine UX-Details oder komplexen Workflows abdecken.
Rauch-Automatisierung erfordert strenge Kontrolle über Abhängigkeiten und minimalen Unterstützungs-Code.

Tückenfragen.

Kann man in das Rauch-Set Szenarien zur Überprüfung der Logik von Randfällen hinzufügen?

Nein, das Rauch-Set ist nur zur Überprüfung der Lebensfähigkeit und Verfügbarkeit des Hauptsystems gedacht, Randfälle sind hier überflüssig, sie würden die Ausführung verlangsamen und die Wartung komplizieren.

Muss man in Rauch-Tests eine mehrstufige Fehlerbehandlung und Wiederherstellung implementieren?

Oft wird fälschlicherweise angenommen, dass Rauch komplexe Wiederherstellungsmechanismen benötigt. Tatsächlich signalisiert es, wenn ein Rauch-Test fehlschlägt, ein kritisches Problem, das behoben werden muss, und nicht „umgangen“ werden sollte.

Sollten Rauch-Tests von Daten abhängen, die von anderen Tests zurückgelassen wurden?

Nein, Rauch-Tests sollten von keinen externen Testdaten und schon gar nicht von Artefakten anderer Tests abhängen. Dies ist eines der Schlüsselprinzipien ihrer Zuverlässigkeit.

Typische Fehler und Anti-Pattern

Überlastung der Rauch-Tests: zu viele Szenarien, Umsetzung in Regressionstests.
Code-Duplikation zwischen Rauch- und normalen Automatisierungstests.
Implizite Abhängigkeiten: der Test verwendet „schmutzige“ Daten/Artefakte von anderen Szenarien.

Beispiel aus dem Leben

Negativer Fall

In das Set der Rauch-Szenarien wurden 30 verschiedene Überprüfungen aufgenommen, von denen einige nicht nur den Start des Systems, sondern auch komplexe Algorithmen und Randfallbedingungen testen. Die Ausführung des Rauch-Starts dauerte 30 Minuten, gelegentlich fielen einige Überprüfungen aufgrund der Instabilität des Backends aus.

Vorteile:

Leicht, Engpässe im System zu erkennen.
Hohe Testabdeckung sofort nach dem Deployment.

Nachteile:

Der eigentliche Sinn des Rauches ist verloren gegangen: Eine „grüne“ Build-Version kann nur nach langer Wartezeit und Behebung unbedeutender Probleme für die Einführung des Systems in die Produktion erhalten werden.
Schwer, Tests zu warten und tatsächliche kritische Ausfälle zu erkennen.

Positiver Fall

Die Rauch-Gruppe wurde auf das strikte Minimum reduziert: Login, Öffnen der Hauptseite, Anfrage an die Datenbank, grundlegender API Handshake. Das Rauch-Framework arbeitet unabhängig von der Haupt-Testmatrix und ist immer zuerst in der CI/CD-Pipeline. Die Ergebnisse sind in einem separaten Chat und immer für schnelle Diagnosen verfügbar.