Smoke-Tests und synthetische Transaktionen: Sicherstellen, dass Ihr Deployment wirklich funktioniert

Sie haben gerade zugesehen, wie Ihre Pipeline grün wurde. Unit-Tests bestanden, Integrationstests bestanden, selbst die End-to-End-Tests kamen sauber zurück. Sie drücken auf Deploy, der Fortschrittsbalken füllt sich, und die Pipeline meldet Erfolg. Aber hier ist die unbequeme Wahrheit: Keiner dieser Tests lief in der tatsächlichen Produktionsumgebung. Sie liefen alle woanders – auf einem CI-Runner, einem Staging-Server, einem lokalen Rechner. In dem Moment, in dem Ihre Anwendung auf echter Infrastruktur landet, kann trotzdem alles kaputtgehen.

Deshalb gibt es Smoke-Tests und synthetische Transaktionen. Sie ersetzen nicht Ihre bestehende Testsuite. Sie sind eine separate Schicht, die eine andere Frage beantwortet: nicht „Ist der Code korrekt?", sondern „Hat das Deployment tatsächlich funktioniert?"

Die einfachste Prüfung: Smoke-Tests

Ein Smoke-Test ist das Basisszenario nach einem Deployment. Er beantwortet eine Frage: Ist die Anwendung am Leben und antwortet sie?

Stellen Sie es sich vor wie das Einschalten eines neuen Server-Racks im Rechenzentrum. Bevor Sie eine ernsthafte Workload ausführen, prüfen Sie, ob die Betriebsanzeige leuchtet, die Lüfter laufen und Sie das Management-Interface anpingen können. Sie führen keinen vollständigen Benchmark durch. Sie bestätigen nur, dass das Ding hochgefahren ist.

Für eine Webanwendung kann ein Smoke-Test eine einzelne HTTP-Anfrage an den Health-Check-Endpunkt sein. Für einen Backend-Dienst könnte es die Prüfung sein, ob der Prozess läuft und auf dem erwarteten Port horcht. Für eine mobile App könnte es bedeuten, zu überprüfen, ob die App auf einem echten Gerät ohne Absturz startet.

Die wichtigsten Eigenschaften eines guten Smoke-Tests sind Geschwindigkeit und Einfachheit. Er sollte in Sekunden abgeschlossen sein, nicht in Minuten. Er sollte nicht von komplexer Geschäftslogik oder externen Systemen abhängen, die vorübergehend nicht verfügbar sein könnten. Wenn Ihr Smoke-Test eine Datenbankverbindung, einen Cache-Server und drei Drittanbieter-APIs benötigt, ist er kein Smoke-Test mehr – sondern etwas ganz anderes.

So sehen ein praktischer Smoke-Test und eine synthetische Transaktion in Bash aus:

# Smoke-Test: schneller Health-Check
curl -f -s -o /dev/null http://myapp.com/health || exit 1

echo "Smoke-Test bestanden"

# Synthetische Transaktion: Benutzer-Login und Suche simulieren
#!/bin/bash
set -e

BASE="http://myapp.com"

# Schritt 1: Login-Seite laden
curl -s -o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 200 || exit 1

# Schritt 2: Login-Formular absenden (simuliert)
curl -s -c /tmp/cookies.txt -b /tmp/cookies.txt \
  -d "username=testuser&password=testpass" \
  -o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 302 || exit 1

# Schritt 3: Nach einem Produkt suchen
curl -s -b /tmp/cookies.txt "$BASE/search?q=laptop" | grep -q "results" || exit 1

echo "Synthetische Transaktion bestanden"

Platzieren Sie Ihren Smoke-Test als ersten Schritt nach dem Deployment, bevor Traffic zur neuen Version geleitet wird. Wenn der Smoke-Test fehlschlägt, sollte die Pipeline sofort anhalten. Fahren Sie nicht mit tiefergehenden Prüfungen fort. Leiten Sie keinen Benutzer-Traffic um. Das Deployment ist auf der grundlegendsten Ebene fehlgeschlagen, und nichts anderes ist wichtig, bis das behoben ist.

Tiefer gehen: Synthetische Transaktionen

Eine synthetische Transaktion führt die Verifizierung einen Schritt weiter. Anstatt nur zu prüfen, ob die Anwendung lebt, simuliert sie echtes Benutzerverhalten. Sie durchläuft die kritischen Pfade Ihrer Anwendung so, wie es ein echter Benutzer tun würde, aber sie läuft automatisch, ausgelöst durch die Pipeline.

Stellen Sie sich eine E-Commerce-Anwendung vor. Eine synthetische Transaktion könnte:

  1. Die Startseite öffnen
  2. Nach einem Produkt suchen
  3. Das Produkt in den Warenkorb legen
  4. Zur Kasse gehen
  5. Den Kauf abschließen

Jeder Schritt prüft, ob die Antwort korrekt ist, ob Seiten richtig laden, ob der Warenkorb tatsächlich das richtige Element enthält und ob die Bestellbestätigung erscheint. Wenn ein Schritt fehlschlägt, schlägt die synthetische Transaktion fehl.

Synthetische Transaktionen sind aufwändiger als Smoke-Tests. Sie brauchen länger – oft mehrere Minuten statt Sekunden. Sie hängen von mehr Teilen des Systems ab, die korrekt funktionieren müssen. Aber sie fangen Probleme, die Smoke-Tests nicht erkennen.

Ein häufiges Szenario: Der Smoke-Test besteht, weil der Health-Check-Endpunkt 200 OK zurückgibt. Aber die Login-Seite gibt einen 500er-Fehler zurück, weil eine Konfigurationsdatei während des Deployments nicht korrekt kopiert wurde. Der Smoke-Test hat die Login-Seite nie geprüft. Die synthetische Transaktion würde es sofort erkennen.

Wo sie in Ihre Pipeline passen

Smoke-Tests und synthetische Transaktionen erfüllen unterschiedliche Zwecke und sollten in verschiedenen Phasen Ihrer Deployment-Pipeline erscheinen.

Der Smoke-Test kommt zuerst, unmittelbar nach Abschluss des Deployments. Er ist Ihr Gatekeeper. Wenn die Anwendung nicht einmal läuft, hat es keinen Sinn, irgendetwas anderes auszuführen. Die Pipeline sollte schnell fehlschlagen und anhalten.

Die synthetische Transaktion läuft, nachdem der Smoke-Test bestanden wurde. Sie ist Ihre tiefere Verifizierung, bevor Benutzer-Traffic eintrifft. Wenn die synthetische Transaktion fehlschlägt, haben Sie noch Zeit, das Deployment zu stoppen, bevor Benutzer auf das Problem stoßen.

In der Praxis brauchen Sie nicht viele synthetische Transaktionen. Zwei bis fünf Szenarien, die Ihre kritischsten Benutzerreisen abdecken, reichen normalerweise aus. Das Ziel ist nicht erschöpfendes Testen – das haben Sie bereits vor dem Deployment gemacht. Das Ziel ist zu bestätigen, dass das Deployment selbst nichts kaputtgemacht hat.

Was diese Tests erkennen, was andere übersehen

Pre-Deployment-Tests laufen in kontrollierten Umgebungen. Sie verwenden Testdatenbanken, Mock-Dienste und Konfigurationsdateien, die sich von der Produktion unterscheiden können. Selbst mit Staging-Umgebungen, die die Produktion genau nachbilden, gibt es Unterschiede.

Smoke-Tests und synthetische Transaktionen laufen in der tatsächlichen Produktionsumgebung. Sie erkennen Probleme, die nur dort auftreten:

  • Unterschiede in der Umgebungskonfiguration zwischen Staging und Produktion
  • Fehlende Abhängigkeiten oder falsche Versionen in der Produktion
  • Berechtigungsprobleme, die nur im Produktionskonto oder -cluster existieren
  • Netzwerkrichtlinien, die legitimen Traffic blockieren
  • SSL-Zertifikatsprobleme
  • Fehlkonfigurationen des Load Balancers
  • Erschöpfung des Datenbank-Verbindungspools unter realen Bedingungen

Dies sind keine theoretischen Probleme. Sie treten regelmäßig in Teams jeder Größe auf. Ein Konfigurationswert, der in Staging perfekt funktioniert, aber in der Produktion einen Tippfehler hat. Ein Secret, das in Staging rotiert wurde, aber nicht in der Produktion. Eine Firewall-Regel, die den Port des neuen Dienstes blockiert. Diese Probleme werden niemals von Pre-Deployment-Tests erkannt, weil diese Tests nicht gegen die reale Umgebung laufen.

Eine praktische Checkliste

Beachten Sie bei der Implementierung von Smoke-Tests und synthetischen Transaktionen für Ihre Pipeline diese Punkte:

  • Halten Sie Smoke-Tests unter 10 Sekunden. Wenn sie länger dauern, vereinfachen Sie sie.
  • Platzieren Sie Smoke-Tests unmittelbar nach dem Deployment, vor dem Traffic-Routing.
  • Lassen Sie die Pipeline bei einem fehlgeschlagenen Smoke-Test fehlschlagen. Fahren Sie nicht fort.
  • Führen Sie synthetische Transaktionen aus, nachdem Smoke-Tests bestanden wurden, vor der vollständigen Traffic-Umschaltung.
  • Beschränken Sie synthetische Transaktionen auf 2-5 kritische Benutzerreisen.
  • Verwenden Sie synthetische Transaktionen nicht für erschöpfende Tests. Dafür sind Ihre Pre-Deployment-Tests da.
  • Überwachen Sie die Ergebnisse synthetischer Transaktionen über die Zeit. Ein Muster von intermittierenden Fehlern kann auf ein zugrunde liegendes Problem hinweisen.
  • Stellen Sie sicher, dass synthetische Transaktionen gegen die tatsächliche Produktionsumgebung laufen, nicht gegen ein Staging-Replikat.

Die konkrete Erkenntnis

Ihre Pre-Deployment-Tests verifizieren, dass Ihr Code korrekt ist. Ihre Smoke-Tests und synthetischen Transaktionen verifizieren, dass Ihr Deployment erfolgreich war. Sie sind nicht dasselbe, und eines kann das andere nicht ersetzen. Eine grüne Pipeline bedeutet, dass Ihr Code alle Prüfungen in einer kontrollierten Umgebung bestanden hat. Ein erfolgreicher Smoke-Test bedeutet, dass Ihre Anwendung tatsächlich in der Produktion läuft. Eine bestandene synthetische Transaktion bedeutet, dass Ihre Benutzer ihre wichtigsten Aufgaben erledigen können. Fügen Sie beide zu Ihrer Deployment-Pipeline hinzu, und Sie werden die Probleme erkennen, die nur auftreten, wenn Code auf die Realität trifft.