Smoke-Test

{{

Definition und Zweck

Ein Smoke-Test ist ein leichtes automatisiertes Überprüfungsverfahren, das eine Software-Pipeline von Anfang bis Ende mit repräsentativen oder minimalen Eingabedaten ausführt, um zu bestätigen, dass die Pipeline ohne Absturz bis zur Fertigstellung läuft und Ausgabedateien mit der erwarteten Struktur erzeugt. Der Test führt eine binäre Bestanden/Nicht bestanden-Bewertung durch – wenn ein Schritt eine nicht behandelte Ausnahme auslöst, keine Ausgabe erzeugt oder eine Ausgabe generiert, der kritische Spalten fehlen, gilt der Test als nicht bestanden und der Build wird sofort abgelehnt.

Der Begriff stammt aus dem Hardware-Engineering, wo die Metapher wörtlich gemeint ist. Wenn Ingenieure eine neu montierte Leiterplatte zum ersten Mal einschalteten, suchten sie nach Rauch, der aus durchgebrannten Komponenten austrat. Wenn Rauch auftrat, hatte die Platine einen katastrophalen Fehler und alle weiteren Tests wurden eingestellt. Die defekte Platine wurde entweder repariert oder entsorgt, bevor jemand Zeit in detaillierte Diagnosen investierte. Software-Smoke-Testing wendet das gleiche Prinzip an: Führen Sie den Code aus und prüfen Sie auf „Rauch" – Abstürze, nicht abgefangene Ausnahmen, fehlende Ausgaben – bevor Sie Zeit in detaillierte Validierungen investieren.

Im Kontext von Inspektionssoftware-Pipelines validiert ein Smoke-Test, dass jede Stufe der Verarbeitungskette mit repräsentativen Daten ausgeführt werden kann. Für TarmacView bedeutet dies, ein kleines Startbahn- oder Fahrbahnbild durch die gesamte Pipeline zu führen – von der Bildaufnahme über die Risserkennung, Defektklassifizierung, Oberflächenbewertung, Vermessungskartierung und Visualisierung – und zu überprüfen, dass jede Stufe fehlerfrei Ausgaben produziert. Dies ist besonders kritisch für Luftfahrtsoftware, bei der Pipeline-Fehler Flughafeninfrastrukturbewertungen verzögern können, die sich direkt auf die Flugsicherheit auswirken.

Der Begriff Build Verification Test (BVT) wird oft synonym mit Smoke-Test verwendet, wobei Microsoft der bekannteste Anwender dieser Terminologie ist. Die internen Entwicklungsprozesse von Microsoft – insbesondere für Windows und Office – haben Smoke-Testing in den 1990er Jahren als obligatorisches Qualitätstor institutionalisiert. Steve McConnells Code Complete identifiziert den „täglichen Build und Smoke-Test" als die höchste bewährte Industriepraxis für Reifegrad der kontinuierlichen Integration. Das Site Reliability Engineering (SRE)-Framework von Google positioniert Smoke-Tests unter „Systemtests" – der einfachste Typ, der speziell verwendet wird, um teure Testpipelines kurzzuschließen.

Der Zweck von Smoke-Tests ist dreifach:

1. Schnell scheitern – katastrophale Fehler innerhalb von Sekunden nach einer Codeänderung erkennen, bevor teure vollständige Pipeline-Läufe Rechenressourcen und Entwicklerzeit verbrauchen.
2. Abschotten – instabile Builds daran hindern, in Staging- oder Produktionsumgebungen zu gelangen, wo sie Testinfrastruktur verschwenden und andere Teams blockieren würden.
3. Rückmeldung – Entwicklern ein unmittelbares Signal geben, dass ihre Änderungen die Kernausführung der Pipeline nicht beschädigt haben, oft innerhalb von 60 Sekunden nach dem Commit.

Smoke-Tests nehmen die erste Stufe der Testpyramide ein und werden vor Unit-Tests, Integrationstests und End-to-End-Regressionspaketen ausgeführt. Sie sind so ausgelegt, dass sie für eine typische Inspektionspipeline in weniger als 60 Sekunden abgeschlossen sind, was sie für die Ausführung bei jedem Code-Commit in CI/CD geeignet macht. In hochreifen Softwareorganisationen werden Smoke-Tests bei jedem Push in jeden Zweig ausgeführt, nicht nur im Hauptzweig, und bieten die frühestmögliche Erkennung von Integrationsfehlern.

Historische Ursprünge und Branchenakzeptanz

Das Konzept des Smoke-Testing geht der Softwareentwicklung um Jahrzehnte voraus. Die erste dokumentierte Verwendung des Begriffs erscheint in der Sanitär- und Ofenprüfung aus dem 19. Jahrhundert. Ofenhersteller zündeten ein Feuer in einem neu montierten Ofen an, schlossen alle Klappen und beobachteten, wo Rauch austrat – wenn Rauch aus unbeabsichtigten Stellen austrat, hatte der Ofen Konstruktionsfehler. Diese gleiche Logik des „minimale Energie zuführen und beobachten, wo etwas bricht" wanderte Mitte des 20. Jahrhunderts zur Elektronikprüfung und schließlich in den 1980er und 1990er Jahren zur Softwareentwicklung.

Microsoft wird weithin zugeschrieben, Smoke-Testing in die gängige Softwareentwicklungspraxis eingeführt zu haben. In den späten 1990er Jahren übernahmen Microsofts Windows- und Office-Abteilungen das sogenannte Build Verification Testing (BVT) als obligatorischen Gate-Prozess. Jeder nächtliche Build musste eine Reihe von BVTs bestehen, bevor der Build an interne Tester freigegeben wurde. Wenn der BVT fehlschlug, galt der Build als „kaputt" und der verantwortliche Entwickler wurde unabhängig von der Tageszeit alarmiert. Diese Kultur der sofortigen Verantwortlichkeit für die Build-Qualität wurde grundlegend für Microsofts Ingenieurskultur und wurde umfassend in MSDN-Dokumentationen und Microsoft Press-Büchern dokumentiert.

Die Taxonomie von Crosslake Technologies (direkt von der Microsoft-Praxis abgeleitet) unterscheidet zwischen Smoke-Tests und BVTs. Smoke-Tests werden als „oberflächlich – stellen grundlegende Funktionalität sicher" beschrieben, laufen in Minuten und konzentrieren sich auf kritische Funktionen. BVTs werden als „eine Obermenge von Smoke-Tests" beschrieben, die „etwas gründlicher" sind, aber immer noch in Minuten, nicht Stunden, laufen. Beide erfüllen die gleiche Gate-Keeping-Funktion, aber BVTs umfassen eine breitere Reihe von kritischen Pfadszenarien.

Google hat Smoke-Testing durch seine SRE-Praktiken (Site Reliability Engineering) übernommen. Der Google Testing Blog behandelt Smoke-Testing als eine bekannte, vorausgesetzte Praxis und konzentriert sich mehr darauf, wie Smoke-Testergebnisse neben anderen Testtypen gewichtet werden können. Googles Ingenieurskultur betont Präzision bei Unit-Tests und gewichtete Konfidenzbewertung für breite Smoke-Test-Prüfungen und behandelt Smoke-Tests als Ergänzung zu, nicht als Ersatz für, rigorose Unit-Tests.

Im Luftfahrtsoftware-Bereich ordnet sich Smoke-Testing der Hardware/Software-Integrationstestphase zu, die in DO-178C Abschnitt 6.4.3 beschrieben wird. Obwohl DO-178C „Smoke-Testing" nicht explizit benennt, verlangt der Standard, dass das integrierte System „startet und grundlegende Funktionen funktionieren", bevor tiefere Tests durchgeführt werden. Dies ist funktional identisch mit Smoke-Testing. Für Flughafeninspektionssoftware, die unter ICAO Annex 14 betrieben wird – der die Gestaltung und den Betrieb von Flugplätzen regelt – bieten Smoke-Tests die Softwarezuverlässigkeitsgarantie, die für Bewertungen des Pavement Condition Index (PCI) benötigt wird, die in Flughafensicherheitsmanagementsysteme einfließen.

Smoke-Test vs. Unit-Test vs. Integrationstest

Zu verstehen, wo Smoke-Tests in der breiteren Testtaxonomie einzuordnen sind, ist für den Aufbau einer ausgewogenen Qualitätssicherungsstrategie unerlässlich. Die vier Haupttestebenen erfüllen komplementäre, aber unterschiedliche Rollen, die jeweils auf verschiedene Fehlermodi in verschiedenen Phasen des Pipeline-Lebenszyklus abzielen.

Unit-Tests validieren, dass einzelne Funktionen korrekte Ausgaben für gegebene Eingaben produzieren. Sie mocken alle externen Abhängigkeiten – Datenbanken, Dateisysteme, Netzwerkdienste, Hardwarebeschleuniger. Ein Unit-Test für eine Risserkennungsfunktion könnte überprüfen, ob sie Risse in einem synthetischen 10x10-Pixel-Array mit bekannten Risspositionen korrekt identifiziert. Unit-Tests sind eng und tief: Sie überprüfen die Logik einer einzelnen Funktion erschöpfend und decken Randfälle, Grenzbedingungen und Fehlerpfade ab. Unit-Tests können jedoch keine Integrationsfehler erkennen, da Abhängigkeiten gemockt sind – der Test beansprucht nie die tatsächliche Importkette, Konfigurationsladung oder den modulübergreifenden Datenfluss.

Integrationstests validieren, dass zwei oder mehr Komponenten korrekt zusammenarbeiten. Sie verwenden echte, aber kontrollierte Instanzen von Abhängigkeiten. Ein Integrationstest für TarmacView könnte überprüfen, dass die Bildaufnahmestufe Daten korrekt an das Risserkennungsmodell im erwarteten Tensorformat mit der richtigen Kanalreihenfolge und den Normalisierungsparametern übergibt. Integrationstests sind im Pipeline-Umfang enger als Smoke-Tests, aber tiefer in der Interaktionsvalidierung: Sie konzentrieren sich auf spezifische Komponentengrenzen statt auf die gesamte Pipeline.

Smoke-Tests validieren, dass die gesamte Pipeline ohne Absturz ausgeführt wird. Sie führen jede Stufe in Folge mit echten, wenn auch kleinen Daten aus. Smoke-Tests sind breit und flach – sie decken die gesamte Pipeline ab, überprüfen aber nur, dass die Ausführung abgeschlossen ist und Ausgaben existieren, nicht dass numerische Ergebnisse korrekt sind. Eine Risslängenberechnung, die 47,2 Pixel statt der korrekten 42,1 Pixel zurückgibt, besteht einen Smoke-Test, solange die Spalte length_px existiert und einen Gleitkommawert enthält.

Systemtests (auch End-to-End-Tests genannt) führen das vollständige System mit Daten im Produktionsumfang in einer produktionsähnlichen Umgebung aus. Sie überprüfen, ob das System seine funktionalen und nicht-funktionalen Anforderungen erfüllt, einschließlich Genauigkeit, Leistung und Zuverlässigkeit. Systemtests sind am teuersten in der Ausführung und Wartung und werden nur bei Release-Kandidaten ausgeführt, nicht bei jedem Commit.

In der Testpyramide bilden Smoke-Tests die Basisschicht – sie werden zuerst, am schnellsten und am häufigsten ausgeführt. Wenn ein Smoke-Test fehlschlägt, werden Unit- und Integrationstests für diesen Build typischerweise übersprungen oder als präventiv unzuverlässig markiert. Dies spart Rechenressourcen und Entwicklerzeit, indem schnell fehlgeschlagen wird, wenn die grundlegende Pipeline-Ausführung defekt ist.

Smoke-Test-Design – Repräsentative Minimaleingabe

Effektives Smoke-Test-Design konzentriert sich auf das Konzept der repräsentativen Minimaleingabe – der kleinste Datensatz, der jede Stufe der Pipeline beansprucht, ohne datenabhängige Randfälle auszulösen. Dies ist die wichtigste einzelne Designentscheidung beim Aufbau einer Smoke-Test-Suite.

Prinzipien der Smoke-Test-Eingabeauswahl

Prinzip 1: Minimal, aber nicht trivial. Die Eingabe muss groß genug sein, um jede Pipeline-Stufe zu durchlaufen, ohne Codepfade zu nehmen, die die eigentliche Verarbeitungslogik umgehen. Ein Ein-Pixel-Bild ist trivial – es würde zwar die Bildladung passieren, aber die Verarbeitungsalgorithmen würden degenerative Codepfade nehmen, die niemals auf echten Daten ausgeführt werden. Ein 256x256-Pixel-Bild einer tatsächlichen Flughafenstartbahn ist minimal und dennoch repräsentativ: Es beansprucht kachelbasierte Verarbeitungsalgorithmen, Farbnormalisierungsroutinen und Modellinferenzpfade, ohne übermäßige Rechenzeit zu erfordern.

Prinzip 2: Repräsentativ für Produktionsdaten. Die Eingabe sollte dasselbe Dateiformat, dieselbe Farbtiefe, dieselbe Metadatenstruktur und dieselben statistischen Eigenschaften wie Produktionsdaten aufweisen. Wenn Produktionsdaten von einer Phase One iXM-RS150F-Luftbildkamera stammen, die 16-Bit-TIFF-Dateien mit eingebetteten EXIF-GPS-Metadaten aufnimmt, muss die Smoke-Test-Eingabe diese Eigenschaften aufweisen. Die Verwendung synthetischer Daten, die sich von Produktionsdaten unterscheiden, macht den Zweck des Smoke-Tests zunichte, da Pipeline-Fehler oft auf unerwartete Eigenschaften realer Daten zurückzuführen sind – fehlende EXIF-Tags, unerwartete Farbprofile, nicht standardgemäße GeoTIFF-Projektionszeichenfolgen.

Prinzip 3: Fest und versioniert. Smoke-Test-Eingaben müssen zusammen mit dem Code als Binärdateien in die Versionskontrolle eingecheckt oder über Git LFS (Large File Storage) verwaltet werden. Sie sollten sich niemals ohne explizite Überprüfung durch Pull-Requests ändern. Eine sich ändernde Eingabe macht es unmöglich, Pipeline-Regressionen von Testdatenänderungen zu unterscheiden – ein Smoke-Test, der heute bestanden wird und morgen fehlschlägt, könnte entweder auf eine Code-Regression oder eine modifizierte Testeingabe hindeuten. Die Versionierung von Eingaben beseitigt diese Mehrdeutigkeit.

Prinzip 4: Schnell zu verarbeiten. Die gesamte Ausführungszeit der Smoke-Test-Suite sollte 60 Sekunden für eine typische Pipeline und 3 Minuten für komplexe mehrstufige Pipelines wie Inspektionssoftware nicht überschreiten. Diese Einschränkung bestimmt die Eingabegröße. Für bildbasierte Inspektionspipelines ist ein einzelnes 512x512-Pixel-Bild in der Regel ausreichend. Für Video-Pipelines ein einzelnes Bild oder ein 2-Sekunden-Clip. Für LiDAR-Pipelines ein einzelnes Flugliniensegment, das 100 Meter Fahrbahn abdeckt.

Prinzip 5: Enthält bekannte Merkmale. Die Testeingabe muss die Merkmale enthalten, die jede Pipeline-Stufe erkennen soll. Ein Smoke-Test für die Risserkennung ist nutzlos, wenn das Eingabebild keine Risse enthält – die Pipeline könnte die Risserkennung stillschweigend überspringen und dennoch bestehen. Testeingaben müssen so kuratiert werden, dass sie mindestens eine Instanz jedes erkennbaren Merkmals mit bekannter Ground Truth enthalten, auf die bei der Fehleranalyse Bezug genommen werden kann.

Beispiel einer Smoke-Test-Eingabe für TarmacView

Für die Inspektionspipeline von TarmacView ist die Smoke-Test-Eingabe ein einzelner RGB-Orthofotostreifen mit 1024x768 Pixeln einer Flughafenstartbahn, aufgenommen mit einem Bodenabstand (GSD) von 1 mm. Das Bild enthält mindestens einen sichtbaren Riss, einen Oberflächendefekt (z. B. Abbröckeln oder Abplatzen) und klare Fahrbahnmarkierungen. Dieses einzelne Bild:

• Beansprucht die Bildaufnahme-Stufe – Dekodierung, Farbkorrektur, Georeferenzierung
• Beansprucht das Risserkennungs-Modell – mindestens ein Riss vorhanden
• Beansprucht das Defektklassifizierungs-Modell – mindestens ein Defekt vorhanden
• Beansprucht die Vermessungskartierung-Stufe – Zuordnung geografischer Koordinaten
• Beansprucht die Visualisierungs-Stufe – Overlay-Rendering mit Anmerkungen
• Beansprucht die Bewertungs-Stufe – PCI-Berechnung oder Zustandsbewertung

Die erwartete Verarbeitungszeit für dieses einzelne Bild durch die gesamte Pipeline beträgt auf CI-Hardware unter 30 Sekunden und lässt Spielraum für die übrigen Smoke-Tests der Suite. Das Testbild wird im Repository unter tests/data/smoke/ gespeichert und über Git LFS versioniert.

TarmacView Smoke-Tests

Die Inspektionspipeline von TarmacView wird durch eine Reihe dedizierter Smoke-Test-Skripte validiert, die jeweils eine bestimmte Pipeline-Phase abdecken. Diese Skripte befinden sich im Verzeichnis scripts/ und folgen der Namenskonvention smoke_<phase>.py. Jedes Skript ist so konzipiert, dass es sowohl unabhängig (für die Entwicklung und Fehlersuche) als auch als Teil der CI-Suite (für automatische Abschottung) ausgeführt werden kann.

{{

smoke_analyze.py

Dieses Skript validiert die Bildanalyse-Phase. Es liest einen einzelnen repräsentativen Orthofotostreifen ein, führt die vollständige Analyse-Pipeline durch das Bildverarbeitungsmodul aus und überprüft:

• Das Bild wird aus dem TIFF-Containerformat ohne Fehler geladen und dekodiert
• Farbkorrektur und radiometrische Normalisierung werden erfolgreich abgeschlossen, wobei Rohsensorwerte in Reflexionswerte umgewandelt werden
• Georeferenzierungs-Metadaten werden geparst und angewendet, einschließlich UTM-Zonen- und Datumsinformationen
• Das verarbeitete Bild hat die erwarteten Abmessungen (1024x768 Pixel) und den erwarteten Datentyp (float32)
• Die Ausgabeanalyse-Datei wird unter dem erwarteten Pfad im Analyse-Ausgabeverzeichnis geschrieben
• Minimale und maximale Pixelwerte liegen innerhalb gültiger radiometrischer Bereiche

Das Skript akzeptiert ein --input-Argument, das auf das Testbild verweist, und ein --output-dir-Argument, das angibt, wo die Pipeline Ergebnisse schreiben soll. Wenn die Pipeline während eines Verarbeitungsschritts abstürzt, wird die Ausnahme abgefangen und der Test gibt einen strukturierten Fehlerbericht zurück.

smoke_assess.py

Dieses Skript validiert die Fahrbahnzustandsbewertungs-Phase. Es nimmt die Ausgabe der Analysephase (oder eine vorab generierte, in der Versionskontrolle gespeicherte Analysedatei), führt den Zustandsbewertungsalgorithmus aus und überprüft:

• Die Bewertungsfunktion wird ohne Fehler auf den Eingabedaten ausgeführt
• Zustandsindizes (Pavement Condition Index PCI oder Äquivalent) werden berechnet
• Die Ausgabebewertungsdatei enthält die erwarteten Spalten: pavement_id condition_index severity extent date_assessed
• Bewertungswerte liegen innerhalb eines gültigen numerischen Bereichs (0-100 für PCI, wobei 0 für fehlerhaft und 100 für perfekt steht)
• Die Ausgabedatei wird als Parquet-Datei mit dem erwarteten Schema geschrieben

Der Bewertungsalgorithmus in TarmacView folgt der Norm ASTM D5340 für die Flughafen-PCI-Berechnung, angepasst für die automatisierte bildbasierte Inspektion. Der Smoke-Test überprüft nicht, ob die PCI-Werte numerisch korrekt sind – er überprüft nur, dass die Berechnung läuft, Ergebnisse im erwarteten Format produziert und diese auf die Festplatte schreibt.

smoke_crack.py

Dieses Skript validiert die Risserkennungs-Phase. Es führt das Risserkennungsmodell auf einem Testbild aus, von dem bekannt ist, dass es Risse enthält, und überprüft:

• Das Modell wird erfolgreich aus seiner gespeicherten Gewichtsdatei geladen und führt Inferenz ohne Fehler durch
• Die PyTorch- oder TensorFlow-Laufzeitumgebung wird korrekt initialisiert, einschließlich CUDA/GPU-Initialisierung, falls verfügbar
• Die Ausgabe-Rissmaske hat dieselben Abmessungen wie das Eingabebild (1024x768)
• Mindestens ein Risspixel wird erkannt, was bestätigt, dass das Testbild bekannte Risse enthält und das Modell ansprechbar ist
• Die Risseigenschaftsdatei enthält die Spalten: crack_id length_px width_px orientation confidence classification
• Ausgabedateien werden unter den erwarteten Pfaden im Riss-Ausgabeverzeichnis geschrieben

Das von TarmacView verwendete Risserkennungsmodell ist eine U-Net-Architektur mit einem ResNet-50-Backbone, trainiert auf beschrifteten Fahrbahnbildern mehrerer Flughäfen. Das Smoke-Test-Eingabebild wurde speziell aus dem Validierungssatz ausgewählt, was bedeutet, dass es Risse enthält, die das Modell während des Trainings, aber nicht während der Testauswertung gesehen hat.

smoke_defect.py

Dieses Skript validiert die Oberflächendefektklassifizierungs-Phase. Es führt den Defektklassifikator auf einem Testbild mit bekannten Defekten aus (Abbröckeln, Abplatzen, Flicken, Verwitterung) und überprüft:

• Der Klassifikator lädt und erzeugt Vorhersagen ohne Fehler
• Die Ausgabeklassifizierungskarte stimmt mit den Abmessungen des Eingabebildes überein
• Mindestens eine Defektklasse wird vorhergesagt, was bestätigt, dass bekannte Defekte in der Eingabe vorhanden sind
• Die Defektbestandsdatei enthält die Spalten: defect_id defect_type area_px severity confidence timestamp
• Die geografische Ausgabedatei enthält gültige Koordinaten im erwarteten CRS (Koordinatenreferenzsystem)
• Die Anzahl der Defektpolygone ist angemessen (weder null noch verdächtig hoch)

Der Defektklassifikator verwendet eine Mask R-CNN-Architektur, die Instanzsegmentierungsmasken für jeden erkannten Defekt erzeugt. Der Smoke-Test überprüft, dass die Ausgabemaske die korrekten Abmessungen hat und die Bestandsdatei die erwarteten Schema-Spalten enthält. Er überprüft nicht, ob die Defektklassifizierungen korrekt sind – das erfordert eine separate Validierungssuite mit beschrifteten Ground-Truth-Daten.

smoke_survey.py

Dieses Skript validiert die Vermessungskartierungs-Phase. Es nimmt Riss- und Defektdaten aus vorgelagerten Stufen entgegen, führt das geografische Vermessungskartierungsmodul aus und überprüft:

• Die Zuordnung geografischer Koordinaten wird ohne Fehler abgeschlossen, wobei Pixelkoordinaten in reale Weltkoordinaten umgewandelt werden
• Die Ausgabevermessungsdatei enthält gültige Breiten- und Längengradspalten mit Werten innerhalb der erwarteten geografischen Grenzen
• Räumliche Beziehungen zwischen erkannten Merkmalen bleiben erhalten (Risse, die im Pixelraum benachbart sind, bleiben im geografischen Raum benachbart)
• Die Ausgabevermessungsdatei enthält die erwarteten Projektionsmetadaten einschließlich EPSG-Code
• Die Datei wird im erforderlichen Ausgabeformat geschrieben (GeoJSON oder Shapefile)
• Die Geometrietypen sind korrekt (LineString für Risse, Polygon für Defekte, Point für Vermessungsmarkierungen)

Das Vermessungskartierungsmodul verwendet die Orthofoto-Georeferenzierungsmetadaten, um eine projektive Transformation von Pixelkoordinaten in geografische Koordinaten durchzuführen. Der Smoke-Test überprüft, dass diese Transformation gültige geografische Koordinaten innerhalb der erwarteten Begrenzungsbox für das Testbild erzeugt. Ein Foto des am Flughafen aufgenommenen Testbildstandorts dient als visuelle Referenz für die Fehleranalyse.

smoke_seg_head.py (Visualisierungsphase)

Dieses Skript validiert die Visualisierungs- und Segmentierungs-Head-Phase – die letzte Stufe der Pipeline, die für Menschen lesbare Ausgaben erzeugt. Es nimmt die verarbeiteten Pipeline-Ausgaben entgegen, führt den Visualisierungs-Renderer aus und überprüft:

• Overlay-Bilder werden ohne Fehler gerendert, wobei Rissmasken, Defektpolygone und Bewertungsergebnisse auf dem Basis-Orthofoto kombiniert werden
• Die Ausgabevisualisierung stimmt mit den Eingabeabmessungen und dem Farbraum überein
• Legenden- und Anmerkungselemente sind vorhanden, einschließlich Maßstabsleiste, Nordpfeil und farbcodierter Schweregradlegende
• Die Berichterstellung wird erfolgreich abgeschlossen und erzeugt eine HTML- oder PDF-Zusammenfassung
• Finale Ausgabedateien werden unter den erwarteten Pfaden mit den korrekten Dateierweiterungen geschrieben (.png für Bilder, .html oder .pdf für Berichte)
• Dateigrößen sind nicht null und liegen innerhalb erwarteter Bereiche

Die Visualisierungsphase ist oft der erste Ort, an dem kumulative Pipeline-Fehler sichtbar werden. Eine Risserkennungsstufe, die eine Maske im falschen Koordinatenraum erzeugt, generiert eine Visualisierung, bei der Riss-Overlays relativ zum Basisbild verschoben sind. Der Smoke-Test erkennt dies indirekt, wenn das Rendering abstürzt, aber es ist der visuelle Regressionsprüftest – nicht der Smoke-Test – der visuelle Qualitätsregressionen erfasst.

Testorchestrierung und Ergebnisformat

Diese Smoke-Tests sind so konzipiert, dass sie sequenziell laufen, können aber auch unabhängig ausgeführt werden, wenn vorgelagerte Ausgaben zwischengespeichert sind. Die vollständige Suite ist auf CI-Hardware in unter 3 Minuten abgeschlossen. Jeder Test gibt einen strukturierten JSON-Bericht mit folgenden Feldern aus:

Der Test-Runner aggregiert einzelne JSON-Berichte zu einer Suite-Zusammenfassung, die im CI-Dashboard veröffentlicht und optional per Slack oder E-Mail zur Echtzeitbenachrichtigung gesendet wird.

Was Smoke-Tests überprüfen

Smoke-Tests sind bewusst eng in dem, was sie behaupten. Sie überprüfen drei Kategorien von Bedingungen und nichts weiter. Diese enge Ausrichtung ist beabsichtigt – sie hält Tests schnell, deterministisch und wartbar.

1. Pipeline läuft bis zur Fertigstellung

Die grundlegendste Behauptung: Wird der Code ohne Auslösen einer nicht behandelten Ausnahme ausgeführt? Dies umfasst:

• Importketten werden korrekt aufgelöst – alle Python-Modulimporte erfolgreich, transitive Abhängigkeiten installiert, keine Versionskonflikte
• Konfigurationsdateien werden ohne Fehler geparst – YAML-, JSON- oder TOML-Konfigurationsdateien sind syntaktisch gültig und enthalten erwartete Schlüssel
• Externe Abhängigkeiten sind erreichbar – Modellgewichtdateien sind unter erwarteten Pfaden vorhanden, Datenbankverbindungen erfolgreich, API-Endpunkte erreichbar
• Hardwarebeschleuniger sind verfügbar – GPU vorhanden und CUDA initialisiert korrekt, wenn die Pipeline GPU-Inferenz benötigt
• Dateisystempfade existieren und sind beschreibbar – Ausgabeverzeichnisse werden erstellt und haben korrekte Schreibberechtigungen
• Speichergrenzen werden nicht überschritten – die Pipeline verarbeitet die Testeingabe ohne Auslösen von Speicherüberlauffehler

Eine Pipeline, die beim Start oder während der Ausführung abstürzt, besteht den Smoke-Test nicht sofort. Der Fehlergrund wird aus dem Ausnahme-Traceback erfasst und gibt Entwicklern einen direkten Hinweis auf die Code-Stelle des Fehlers.

2. Ausgabedateien existieren

Nach Abschluss der Ausführung überprüft der Smoke-Test, dass Ausgabedateien unter den erwarteten Pfaden existieren. Dies umfasst:

• Hauptausgabedateien sind vorhanden – Ergebnisse, Berichte, verarbeitete Bilder, Modellausgaben
• Zwischendateien sind vorhanden – wenn der Pipeline-Vertrag festlegt, dass Zwischenausgaben persistent sein müssen, überprüft der Smoke-Test diese
• Dateigrößen sind nicht null – eine Null-Byte-Ausgabedatei zeigt an, dass die Stufe keine Daten produziert hat, was ein Fehler ist
• Dateiformatsignaturen sind gültig – der Datei-Header entspricht dem erwarteten Format (z. B. gültige PNG-Magic-Bytes, gültige GeoJSON-Struktur, gültige Parquet-Magic-Bytes)

Eine Pipeline, die behauptet fertig zu sein, aber keine Ausgabedateien erzeugt, besteht den Smoke-Test nicht. Dies erfasst stille Fehler, bei denen die Pipeline sauber beendet wird, aber kritische Schreiboperationen aufgrund falsch konfigurierter Ausgabepfade oder bedingter Logik, die unerwartet falsch ausgewertet wird, überspringt.

3. Schlüsselspalten in tabellarischer Ausgabe vorhanden

Für jede tabellarische Ausgabe (CSV, Parquet, GeoJSON-Feature-Collection) überprüft der Smoke-Test, dass erwartete Spalten namentlich existieren. Dies ist eine strukturelle Integritätsprüfung – das Spaltenschema muss dem entsprechen, was nachgelagerte Verbraucher erwarten.

Der Test verwendet eine Spaltenexistenzprüfung (keine Typenprüfung, keine Wertebereichsprüfung). Dies ist beabsichtigt – die Spaltenexistenz ist die minimale strukturelle Integritätsgarantie. Typ- und Bereichsprüfungen gehören in Integrations- und Validierungstests, wo die Kosten für ihre Ausführung durch die Tiefe der von ihnen gelieferten Informationen gerechtfertigt sind.

4. Datenformatkompatibilität

Die vierte Kategorie der Überprüfung, die Smoke-Tests durchführen – oft übersehen – ist die Datenformatkompatibilität. Der Smoke-Test überprüft, dass Ausgabedateien von den erwarteten nachgelagerten Verbrauchern zurückgelesen werden können. Für TarmacView bedeutet dies:

• Parquet-Dateien können von Pandas ohne Schema-Fehler gelesen werden
• GeoJSON-Dateien können von shapely und geopandas geparst werden
• GeoTIFF-Dateien können von rasterio mit korrekten CRS-Metadaten geöffnet werden
• JSON-Berichte können ohne Syntaxfehler deserialisiert werden
• CSV-Dateien haben konsistente Zeilenanzahlen über alle Spalten hinweg

Dies erfasst Formatversionskonflikte – zum Beispiel, wenn die Parquet-Bibliothek aktualisiert wird und ihre Kodierung ändert oder wenn die GeoJSON-Spezifikation weiterentwickelt wird und die Pipeline-Ausgabe nicht mehr konform ist.

Was Smoke-Tests NICHT überprüfen

Ebenso wichtig ist das Verständnis dafür, was Smoke-Tests bewusst ausschließen. Ein Missverständnis führt zu falschem Vertrauen in die Korrektheit der Pipeline – ein bestandener Smoke-Test bedeutet nicht, dass die Pipeline korrekt ist, sondern nur, dass sie nicht katastrophal defekt ist.

Numerische Genauigkeit

Smoke-Tests überprüfen nicht, dass berechnete Werte korrekt sind. Eine Risslängenberechnung, die 47,2 Pixel statt der korrekten 42,1 Pixel zurückgibt, besteht einen Smoke-Test, solange die Spalte length_px existiert und einen Float enthält. Die Genauigkeitsvalidierung gehört in Unit-Tests, wo der korrekte Wert fest codiert ist, und Integrationstests, wo Ergebnisse mit manuellen Messungen zertifizierter Prüfer verglichen werden.

Für Luftfahrt-Inspektionspipelines, die unter ICAO Annex 14 betrieben werden, ist die numerische Genauigkeit kritisch, da Zustandsbewertungen direkt die Wartungspriorisierung und Budgetzuweisung beeinflussen. Eine Pipeline, die Smoke-Tests besteht, aber ungenaue PCI-Werte produziert, könnte zu falschen Wartungsentscheidungen führen. Deshalb sind Smoke-Tests nur das erste Tor – ihnen müssen genauigkeitsorientierte Validierungstests folgen.

Randfälle

Smoke-Tests verwenden repräsentative, aber nicht gegnerische Eingaben. Sie testen nicht:

• Leere Bilder – vollständig schwarze oder weiße Bilder ohne Merkmale
• Beschädigte Dateien – abgeschnittene TIFF-Header, fehlende EXIF-Daten, Null-Byte-Dateien
• Extreme Lichtverhältnisse – überbelichtete oder unterbelichtete Bilder, beschattete Bilder, Nachtaufnahmen
• Bilder außerhalb erwarteter Auflösungsgrenzen – 100-Megapixel-Bilder oder Miniaturansichten unter 100 Pixeln
• Fehlende Metadaten – Bilder ohne Georeferenzierung, ohne EXIF-GPS, ohne Kamerakalibrierungsdaten
• Netzwerk-Zeitüberschreitungen – API-Aufrufe, die hängen bleiben oder 503-Fehler zurückgeben
• Gleichzeitiger Zugriff – mehrere Pipeline-Instanzen, die in dasselbe Ausgabeverzeichnis schreiben

Die Behandlung von Randfällen wird durch dedizierte Randfalltests validiert, die speziell auf jede Grenzbedingung abzielen. Diese Tests sind teurer in der Ausführung und werden in der Regel nächtlich und nicht bei jedem Commit ausgeführt.

Leistungsmerkmale

Smoke-Tests überprüfen, dass die Pipeline abgeschlossen wird, nicht dass sie innerhalb eines Leistungsbudgets abgeschlossen wird. Eine Pipeline, die in Smoke-Tests 10 Sekunden pro Bild benötigt, aber in der Produktion 100 Bilder pro Sekunde verarbeiten soll, besteht Smoke-Tests problemlos. Die Leistungsvalidierung erfordert dedizierte Benchmark-Tests mit Daten im Produktionsumfang und Zeitbehauptungen.

Für Flughafen-Inspektionspipelines ist die Leistung kritisch, da Flughäfen Hunderte von Fahrbahnbildern pro Untersuchung verarbeiten. Eine 10-fache Leistungsregression könnte Smoke-Tests auf einem einzelnen Bild noch bestehen, würde aber vollständige Untersuchungen undurchführbar machen. Leistungs-Benchmarks mit Zeitschwellenwerten sind das geeignete Werkzeug zur Erkennung solcher Regressionen.

Regression in nicht-kritischen Funktionen

Smoke-Tests decken nur den Kernausführungspfad ab. Funktionen, die nicht auf dem kritischen Pfad liegen – alternative Ausgabeformate, optionale Protokollierung, Telemetrie, Prüfpfade, experimentelle Exportfunktionen – werden nicht abgedeckt. Regressionen in diesen Bereichen müssen durch Regressions-Testsuiten erfasst werden, die speziell auf nicht-kritische Funktionalität abzielen.

Datenqualität

Smoke-Tests überprüfen nicht, dass Datenwerte intern konsistent sind. Zum Beispiel überprüft ein Smoke-Test, dass die Spalte crack_id existiert, aber nicht, dass alle crack_id-Werte eindeutig, nicht null oder innerhalb erwarteter Bereiche liegen. Die Datenqualitätsvalidierung erfordert dedizierte Datenqualitätstests mit Frameworks wie Great Expectations oder Pandera, die Datenverträge definieren und Datensätze dagegen validieren.

Smoke-Tests in CI/CD

Smoke-Tests liefern den größten Nutzen, wenn sie in die Continuous Integration und Continuous Deployment (CI/CD)-Pipeline integriert sind. Ihre Platzierung im Pipeline-Workflow bestimmt ihre Wirksamkeit als Qualitätstor.

{{

Pipeline-Platzierung

In einem typischen CI/CD-Workflow werden Smoke-Tests in der Build-Verifizierungsphase unmittelbar nach der Kompilierung und vor jeder anderen Testsuite ausgeführt:

Code-Commit → Build → Lint → Unit-Tests → Smoke-Tests → Integrationstests → Validierungstests → Bereitstellung

Die genaue Reihenfolge hängt von der Teststrategie des Projekts ab. Einige Organisationen führen Unit-Tests vor Smoke-Tests aus, mit der Begründung, dass Unit-Tests schneller sind und Logikfehler erkennen. Andere führen Smoke-Tests zuerst aus, mit der Begründung, dass eine Pipeline, die bei der grundlegenden Ausführung abstürzt, abgelehnt werden sollte, ohne Zeit mit Unit-Tests zu verschwenden. Die TarmacView-Pipeline führt Unit-Tests und Smoke-Tests parallel nach einem erfolgreichen Build aus, da sie unabhängige Fehlermodi abdecken und keine Abhängigkeiten voneinander haben.

Diese Platzierung stellt sicher, dass wenn der Build eine Pipeline erzeugt, die bei der grundlegenden Ausführung abstürzt, keine weitere Testinfrastruktur verbraucht wird. Die Rückkopplungsschleife wird in Minuten statt Stunden gemessen. Ein Entwickler, der einen Commit pusht, der die Importkette unterbricht, erhält innerhalb von 2-3 Minuten eine CI-Fehlermeldung, anstatt 4 Stunden auf das Scheitern der Integrationstest-Suite zu warten.

Gate-Logik

Die CI/CD-Pipeline verwendet ein hartes Gate: Wenn ein Smoke-Test fehlschlägt, hält die Pipeline an und fährt nicht mit nachfolgenden Stufen fort. Der Build wird als fehlgeschlagen markiert und Entwickler werden mit dem Smoke-Test-Fehlerbericht benachrichtigt. In der Standardkonfiguration ist keine manuelle Überschreibung erlaubt – eine bestandene Smoke-Test-Suite ist eine notwendige Bedingung für die Bereitstellung.

Diese Gate-Logik verhindert die folgenden Szenarien:

• Ein Team führt 4 Stunden lang Integrationstests durch, nur um festzustellen, dass die Pipeline beim Datenladen abstürzt – Rechenleistung wird verschwendet und andere Builds werden blockiert
• Ein Release-Kandidat wird in Staging bereitgestellt, wo das Datenbankschema während der Bereitstellungskonfiguration stillschweigend geändert wurde
• Eine Produktionsbereitstellung bricht aufgrund eines fehlenden Imports oder Dateipfads, der im letzten Commit eingeführt wurde

Das Gate wird in der Konfiguration der CI-Plattform implementiert. Für CircleCI bedeutet dies die Konfiguration von Workflow-Abhängigkeiten, sodass der smoke-test-Job vor integration-test und deploy läuft. Für GitHub Actions bedeutet dies die Verwendung des Schlüsselworts needs:, um die Auftragsreihenfolge durchzusetzen.

Parallele Ausführung und Nebenläufigkeit

Smoke-Tests innerhalb der Suite können parallel ausgeführt werden, wenn sie unabhängige Pipeline-Stufen testen. Die Smoke-Test-Suite von TarmacView verwendet wo möglich Parallelität:

• smoke_crack.py und smoke_defect.py haben keine Abhängigkeiten voneinander und können gleichzeitig ausgeführt werden, was die Gesamtsuitezeit um 40% reduziert
• smoke_analyze.py muss vor smoke_assess.py abgeschlossen sein, da die Bewertung die Analyseausgabe verbraucht
• smoke_survey.py ist von Riss- und Defektausgaben abhängig
• smoke_seg_head.py ist von allen vorgelagerten Ausgaben abhängig

Die Strategie für die parallele Ausführung wird im CI-Pipeline-YAML mittels auftragsbezogener Parallelität konfiguriert. Jeder Job läuft in seinem eigenen Container mit isolierten Abhängigkeiten, um Ressourcenkonflikte zu verhindern.

Berichterstattung und Benachrichtigung

Die CI/CD-Integration umfasst automatisierte Berichterstattung über mehrere Kanäle:

• Bestanden/Nicht bestanden-Status im CI-Dashboard mit farbcodierten Indikatoren (grün für bestanden, rot für nicht bestanden)
• Dauer pro Test erfasst für Trendanalyse – eine allmähliche Zunahme der Smoke-Test-Dauer kann auf eine Leistungsregression hindeuten
• Fehlerprotokolle als CI-Artefakte erfasst zur Entwicklerinspektion mit vollständigen Stack-Traces
• Slack- oder E-Mail-Benachrichtigungen bei Testfehlern mit Links zu Protokollen und dem fehlerhaften Commit
• Trenddiagramme mit Bestehensquote im Zeitverlauf mit Ziel von >99% im Hauptzweig
• Flaky-Test-Erkennung – ein Test, der beim gleichen Commit zwischen Bestehen und Nichtbestehen wechselt, wird zur Untersuchung markiert

CI/CD-Konfigurationsbeispiel

# .circleci/config.yml
version: 2.1

jobs:
  smoke-test:
    docker:
      - image: tarmacview/pipeline:ci
    parallelism: 3
    steps:
      - checkout
      - run: pip install -r requirements.txt
      - run: python scripts/smoke_analyze.py --input tests/data/smoke_image.tif --output-dir /tmp/smoke-output
      - run:
          name: "Parallel smoke tests"
          command: |
            python scripts/smoke_crack.py --input tests/data/smoke_image.tif --output-dir /tmp/smoke-output &
            python scripts/smoke_defect.py --input tests/data/smoke_image.tif --output-dir /tmp/smoke-output &
            wait
      - run: python scripts/smoke_assess.py --input /tmp/smoke-output/cracks.parquet --output-dir /tmp/smoke-output
      - run: python scripts/smoke_survey.py --input /tmp/smoke-output --output-dir /tmp/smoke-output
      - run: python scripts/smoke_seg_head.py --input /tmp/smoke-output --output-dir /tmp/smoke-output
      - store_artifacts:
          path: /tmp/smoke-output

workflows:
  version: 2
  build-and-test:
    jobs:
      - build
      - unit-tests:
          requires: [build]
      - smoke-test:
          requires: [build]
      - integration-tests:
          requires: [smoke-test]
      - deploy:
          requires: [integration-tests]

Smoke-Tests schreiben

Effektive Smoke-Tests zu schreiben erfordert Disziplin. Der Test muss schnell, zuverlässig und nur auf das fokussiert sein, was er erkennen soll. Jeder Smoke-Test folgt dem gleichen grundlegenden Muster: Führe die Pipeline-Stufe aus, überprüfe die Existenz der Ausgabe, überprüfe die minimale Schema-Korrektheit, melde Bestehen/Nichtbestehen in strukturiertem JSON.

Struktur eines Smoke-Tests

# smoke_crack.py — vereinfachtes Muster
import sys
import json
import time
from pathlib import Path
import pandas as pd

def test_smoke_crack(input_path: str, output_dir: str) -> dict:
    result = {
        "test_name": "smoke_crack",
        "passed": False,
        "duration_ms": 0,
        "output_files": [],
        "failure_reason": None,
        "input_path": input_path,
        "pipeline_version": "unknown"
    }

    start = time.time()

    try:
        # Schritt 1: Pipeline-Version abrufen
        from tarmacview import __version__
        result["pipeline_version"] = __version__

        # Schritt 2: Pipeline-Stufe mit echten Importen ausführen
        from tarmacview.pipeline.crack import detect_cracks
        output = detect_cracks(input_path, output_dir)

        # Schritt 3: Überprüfen, dass Ausgabedatei existiert und nicht leer ist
        output_path = Path(output["crack_mask_path"])
        assert output_path.exists(), f"Ausgabedatei nicht gefunden: {output_path}"
        assert output_path.stat().st_size > 0, f"Ausgabedatei ist leer: {output_path}"
        result["output_files"].append(str(output_path))

        # Schritt 4: Schlüsselspalten in tabellarischer Ausgabe überprüfen
        if output.get("crack_inventory_path"):
            inv_path = Path(output["crack_inventory_path"])
            assert inv_path.exists(), f"Bestandsdatei nicht gefunden: {inv_path}"
            df = pd.read_parquet(inv_path)
            required_columns = [
                "crack_id", "length_px", "width_px",
                "orientation", "confidence", "classification"
            ]
            for col in required_columns:
                assert col in df.columns, f"Erforderliche Spalte fehlt: {col}"
            result["output_files"].append(str(inv_path))

        # Schritt 5: Überprüfen, dass Ausgabemaske-Abmessungen mit Eingabe übereinstimmen
        from PIL import Image
        input_img = Image.open(input_path)
        mask_img = Image.open(output_path)
        assert input_img.size == mask_img.size, \
            f"Maskenabmessungen {mask_img.size} stimmen nicht mit Eingabe {input_img.size} überein"

        result["passed"] = True

    except Exception as e:
        result["failure_reason"] = f"{type(e).__name__}: {str(e)}"
        result["passed"] = False

    result["duration_ms"] = int((time.time() - start) * 1000)
    return result

if __name__ == "__main__":
    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument("--input", required=True)
    parser.add_argument("--output-dir", default="/tmp/smoke-output")
    args = parser.parse_args()

    result = test_smoke_crack(args.input, args.output_dir)
    print(json.dumps(result, indent=2))
    sys.exit(0 if result["passed"] else 1)

Gestaltungsregeln

1. Eine Behauptung pro Kategorie. Bestätige, dass die Ausführung abgeschlossen wird. Bestätige, dass die Ausgabe existiert. Bestätige, dass Spalten existieren. Bestätige keine numerischen Bereiche, exakte Dateigrößen oder Datenqualitätsmetriken. Jede zusätzliche Behauptung erhöht die Testwartungskosten und verringert die Testzuverlässigkeit.

2. Echte Importe verwenden. Keine Pipeline-Module mocken. Der Smoke-Test muss die tatsächliche Importkette beanspruchen, um Importfehler und fehlende Abhängigkeiten zu erkennen. Ein Smoke-Test, der unittest.mock verwendet, um Importfehler zu unterdrücken, macht seinen eigenen Zweck zunichte.

3. Minimale Einrichtung und Bereinigung. Der Test sollte keine Datenbankeinrichtung, keinen Dienststart und keine externe Konfiguration über die Testeingabedatei hinaus erfordern. Wenn eine Einrichtung erforderlich ist, sollte sie Teil der CI-Job-Definition sein, nicht des Testskripts. Jeder Smoke-Test sollte auf dem Laptop eines Entwicklers mit einem einzigen Befehl ausführbar sein.

4. Deterministisch. Die gleiche Eingabe muss immer das gleiche Bestehens-/Nichtbestehens-Ergebnis liefern. Zufalls-Seeds müssen in der Pipeline-Konfiguration festgelegt werden. Testeingabedateien müssen versioniert sein. Nicht-deterministische Smoke-Tests sind schlimmer als nutzlos – sie untergraben das Vertrauen in die gesamte Testinfrastruktur.

5. In sich geschlossene strukturierte Ausgabe. Der Test sollte bei Abschluss eine strukturierte JSON-Ausgabe ausgeben, sodass CI-Systeme Ergebnisse ohne benutzerdefinierte Protokollanalyse parsen können. Das JSON-Schema sollte über alle Smoke-Tests der Suite hinweg konsistent sein.

6. Schnell. Jeder Test muss auf CI-Hardware in unter 60 Sekunden abgeschlossen sein. Wenn ein Test diese Grenze konsequent überschreitet, optimiere den Test, bevor du ihn zur Suite hinzufügst. Ein Smoke-Test, der 5 Minuten dauert, wird von Entwicklern, die Tests lokal ausführen, übersprungen.

Häufige Fallstricke

• Zu viel testen. Das Hinzufügen von Genauigkeitsbehauptungen oder Wertebereichsprüfungen verwandelt einen Smoke-Test in einen Integrationstest. H alte ihn flach. Der Test sollte weniger als 60 Sekunden zum Schreiben und weniger als 60 Sekunden zum Ausführen benötigen.
• Importfehler ignorieren. Ein Smoke-Test, der alle Ausnahmen weitgehend mit einem generischen except Exception abfängt, könnte Importfehler übersehen. Lasse einige Ausnahmen propagieren oder protokolliere Importfehler zumindest separat.
• Produktionsdaten verwenden. Produktionsdaten sind groß, unkontrolliert und können sensible Informationen enthalten, einschließlich Flughafensicherheitszonen und urheberrechtlich geschütztem Bildmaterial. Verwende eine feste, kleine synthetische oder kuratierte Eingabe.
• Veränderliche Testeingaben. Testeingaben, die auf Netzwerklaufwerken oder Cloud-Speichern gespeichert sind, können sich ohne Versionskontrolle ändern. Testeingaben immer im Repository oder über Git LFS versionieren.
• GPU-Verfügbarkeit annehmen. Wenn die Pipeline eine GPU für die Inferenz benötigt, sollte der Smoke-Test die Abwesenheit einer GPU elegant behandeln, indem er entweder den GPU-abhängigen Test überspringt oder auf CPU-Fallback läuft.
• Hartcodierte Dateipfade. Niemals absolute Dateipfade in Smoke-Tests hartcodieren. Verwende relative Pfade und das Argument --output-dir, um flexible Ausführungsumgebungen zu ermöglichen.

Interpretation von Smoke-Test-Fehlschlägen

Wenn ein Smoke-Test fehlschlägt, muss sich der Entwicklungsworkflow vom „Entwickeln" zum „Diagnostizieren und Beheben" verschieben. Eine effektive Fehlerinterpretation folgt einem strukturierten Ansatz, der Fehlersymptome wahrscheinlichen Grundursachen zuordnet.

Fehlerkategorien

Fehlerbehandlungsworkflow

Wenn ein Smoke-Test in CI fehlschlägt, ist der empfohlene Antwortworkflow:

1. Den Fehlerbericht prüfen. Die strukturierte JSON-Ausgabe des Smoke-Tests enthält das Feld failure_reason, das den Ausnahmetyp und die Nachricht enthält. Dies ist der schnellste Weg, um zu verstehen, was kaputt gegangen ist.

2. Identifizieren, ob der Fehler eine Code-Regression oder ein Infrastrukturproblem ist. Ein ModuleNotFoundError für ein Paket, das gestern installiert wurde, deutet auf eine Regression hin. Ein Timeout, das bei allen Builds gleichzeitig auftritt, deutet auf ein Infrastrukturproblem hin (Netzwerkausfall, CI-Runner-Verschlechterung).

3. Zurücksetzen, wenn die Grundursache nicht innerhalb von 15 Minuten offensichtlich ist. Die Smoke-Test-Suite ist schnell, speziell um eine schnelle Rücknahme zu ermöglichen. Ein Build, der Smoke-Tests nicht besteht, sollte sofort zurückgesetzt werden, um die CI-Pipeline für andere Entwickler freizugeben.

4. Mit der Testeingabe untersuchen. Führe den fehlgeschlagenen Smoke-Test lokal mit derselben versionierten Testeingabe aus. Die Reproduktion des Fehlers lokal eliminiert CI-spezifische Variablen (Containerunterschiede, Ressourcengrenzen, Parallelitätsprobleme).

5. Beheben und einen Unit-Test hinzufügen. Sobald die Grundursache identifiziert ist, behebe den Code und füge auf der entsprechenden Ebene einen Unit-Test hinzu, der den Fehler erkannt hätte. Dies verhindert, dass dieselbe Art von Regression erneut auftritt.

6. Überprüfen, dass die Fehlerbehebung Smoke-Tests besteht. Führe die vollständige Smoke-Test-Suite lokal aus, bevor du die Fehlerbehebung pushst. Dies stellt sicher, dass die Fehlerbehebung keine neuen Fehler in anderen Pipeline-Stufen einführt.

Falsch-Positive und Flaky-Tests

Smoke-Tests können Falsch-Positive erzeugen – der Test schlägt fehl, aber die Pipeline ist tatsächlich funktionsfähig. Häufige Ursachen sind:

• Ressourcenkonflikte in CI – mehrere gleichzeitig laufende Builds erschöpfen Arbeitsspeicher oder Festplattenspeicher
• Netzwerkabhängige Tests – Tests, die externe APIs kontaktieren oder Modellgewichte von entfernten Speicherorten herunterladen
• Zeitabhängige Tests – Tests, die annehmen, dass bestimmte Operationen innerhalb eines bestimmten Zeitfensters abgeschlossen werden
• Dateisystem-Race-Conditions – parallele Tests, die in überlappende Ausgabeverzeichnisse schreiben

Flaky-Smoke-Tests untergraben das Vertrauen in die Testinfrastruktur. Entwickler, die sehen, dass Smoke-Tests zufällig fehlschlagen, werden beginnen, Fehler zu ignorieren. Die Lösung ist eine aggressive Entflaktifizierung: Identifiziere die Grundursache der Flakigkeit und härte den Test. Wenn ein Test mit angemessenem Aufwand nicht zuverlässig gemacht werden kann, sollte er in eine Testsuite mit niedrigerer Priorität verschoben oder durch ein robusteres Design ersetzt werden.

Smoke-Tests im Luftfahrtsoftware-Kontext

Für Luftfahrtsoftware, einschließlich Flughafen-Inspektionspipelines, haben Smoke-Tests aufgrund der sicherheitskritischen Natur der Domäne eine zusätzliche Bedeutung. Unter DO-178C (Software Considerations in Airborne Systems and Equipment Certification) folgt die Softwareverifizierung einem rigorosen anforderungsbasierten Prozess. Obwohl DO-178C „Smoke-Testing" nicht explizit nennt, erfordert das Konzept des Hardware/Software-Integrationstests gemäß Abschnitt 6.4.3, dass das integrierte System „startet und grundlegende Funktionen funktionieren" – das funktionale Äquivalent eines Smoke-Tests.

Unter ICAO Annex 14 Band I – Aerodrome Design and Operations – wirkt sich der Zustand von Flughafenstartbahnen direkt auf die Flugsicherheit aus. Ein Fahrbahnversagen auf einer Startbahn kann zu Flugzeugschäden oder Kontrollverlust während Start und Landung führen. Software, die für die automatisierte Fahrbahninspektion verwendet wird, muss daher Zuverlässigkeitsstandards erfüllen, die den Sicherheitsauswirkungen ihrer Ausgabe entsprechen. Smoke-Tests bieten die erste Verteidigungslinie gegen Softwarefehler, die Fahrbahnzustandsbewertungen beeinträchtigen könnten.

Für TarmacView sind Smoke-Tests Teil eines breiteren Softwarequalitätssicherungsrahmens, der umfasst:

• Rückverfolgbarkeit von Anforderungen – jedes Pipeline-Merkmal ist mit einer dokumentierten Anforderung verknüpft
• Unit-Test-Abdeckung – >90% Zeilenabdeckung für Kernalgorithmen
• Smoke-Test-Abdeckung – 100% der Pipeline-Stufen durch Smoke-Tests abgedeckt
• Integrationstest-Abdeckung – jede Komponentengrenze mit echten Daten getestet
• Validierungstests – Pipeline-Ergebnisse werden mit manueller Inspektion durch zertifizierte Flughafenprüfer verglichen
• Leistungs-Benchmarks – Durchsatz und Latenz werden pro Release verfolgt

Dieser mehrschichtige Ansatz stellt sicher, dass Smoke-Tests als erstes Tor dienen, ohne das einzige Tor zu sein. Ein bestandener Smoke-Test bedeutet, dass die Pipeline strukturell solide ist. Aber es sind die Integrationstests, Validierungstests und Leistungs-Benchmarks, die das Vertrauen schaffen, das benötigt wird, um die Ausgabe von TarmacView für reale Flughafenwartungsentscheidungen zu verwenden.

Fazit

Smoke-Testing ist eine grundlegende Softwarequalitätspraxis, die im Verhältnis zu ihren Implementierungskosten einen überproportionalen Nutzen liefert. Für Inspektionssoftware-Pipelines wie TarmacView erkennen Smoke-Tests Integrationsfehler – defekte Importe, fehlende Dateien, Schema-Konflikte – in Sekunden statt Stunden. Sie dienen als erstes Tor in CI/CD und lehnen instabile Builds ab, bevor sie Testinfrastruktur verbrauchen. Die TarmacView Smoke-Test-Suite deckt jede Pipeline-Phase ab – von der Bildaufnahme über die Risserkennung, Defektklassifizierung, Oberflächenbewertung, Vermessungskartierung und Visualisierung – wobei jeder Test überprüft, dass die Stufe läuft, Ausgaben produziert und erwartete Spaltenschemata einhält.

Der Schlüssel zu effektivem Smoke-Testing ist das Verständnis seines engen Umfangs. Smoke-Tests überprüfen, dass die Pipeline läuft und Ausgaben produziert. Sie überprüfen nicht die Genauigkeit, Leistung, Randfallbehandlung oder Datenqualität. Diese werden durch andere Testtypen im breiteren Qualitätssicherungsrahmen validiert. Wenn Smoke-Tests mit dieser Disziplin entworfen werden – repräsentative minimale Eingaben, schnelle Ausführungszeiten, breite aber flache Abdeckung – bieten sie die schnelle, zuverlässige Fehlererkennung, die CI/CD-Pipelines für sicherheitskritische Luftfahrtsoftware effektiv macht.