Test dymny (Smoke Test)

{{

Definicja i cel

Test dymny to lekka, zautomatyzowana procedura weryfikacyjna, która wykonuje pipeline oprogramowania kompleksowo na reprezentatywnych lub minimalnych danych wejściowych, aby potwierdzić, że pipeline działa do końca bez awarii i produkuje pliki wyjściowe o oczekiwanej strukturze. Test przeprowadza binarną ocenę zaliczenia/niezaliczenia — jeśli którykolwiek krok zgłosi nieobsłużony wyjątek, nie wyprodukuje danych wyjściowych lub wygeneruje dane wyjściowe pozbawione krytycznych kolumn, test kończy się niepowodzeniem, a kompilacja jest natychmiast odrzucana.

Termin pochodzi z inżynierii sprzętowej, gdzie metafora jest dosłowna. Gdy inżynierowie po raz pierwszy włączali zasilanie nowo zmontowanej płytki drukowanej, obserwowali, czy dym nie wydobywa się z przepalonych komponentów. Jeśli pojawił się dym, płytka miała katastrofalną awarię i wszelkie dalsze testowanie było wstrzymywane. Wadliwą płytkę naprawiano lub odrzucano, zanim ktokolwiek zainwestował czas w szczegółową diagnostykę. Testowanie dymne w oprogramowaniu stosuje identyczną zasadę: uruchom kod i sprawdź, czy nie ma „dymu" — awarii, nieobsłużonych wyjątków, brakujących wyników — przed zainwestowaniem czasu w szczegółową walidację.

W kontekście pipeline’ów oprogramowania inspekcyjnego test dymny waliduje, że każdy etap łańcucha przetwarzania może zostać wykonany na reprezentatywnych danych. Dla TarmacView oznacza to podanie małego obrazu drogi startowej lub nawierzchni przez cały pipeline — od wczytywania obrazu przez wykrywanie spękań, klasyfikację defektów, ocenę nawierzchni, mapowanie geodezyjne i wizualizację — i sprawdzenie, że każdy etap produkuje wyniki bez błędów. Jest to szczególnie istotne w oprogramowaniu lotniczym, gdzie awarie pipeline’u mogą opóźnić oceny infrastruktury lotniskowej, które bezpośrednio wpływają na bezpieczeństwo lotów.

Termin test weryfikacji kompilacji (BVT) jest często używany zamiennie z testem dymnym, a Microsoft jest najwybitniejszym adoptującym tę terminologię. Wewnętrzne procesy deweloperskie Microsoftu — szczególnie dla Windows i Office — zinstytucjonalizowały testowanie dymne jako obowiązkową bramkę jakości w latach 90. Code Complete Steve’a McConnella określa „codzienną kompilację i test dymny" jako najwyższą praktykę branżową w zakresie dojrzałości ciągłej integracji. Framework Site Reliability Engineering (SRE) Google pozycjonuje testy dymne w ramach „testów systemowych" — najprostszego typu używanego specjalnie do skracania kosztownych pipeline’ów testowych.

Cel testowania dymnego jest trojaki:

1. Szybkie wykrywanie awarii — wykrywanie katastrofalnych awarii w ciągu sekund od zmiany kodu, zanim kosztowne, pełne uruchomienia pipeline’u pochłoną zasoby obliczeniowe i czas programistów.
2. Pełnienie roli bramki — zapobieganie przechodzeniu niestabilnych kompilacji do środowisk stagingowych lub produkcyjnych, gdzie marnowałyby infrastrukturę testową i blokowały inne zespoły.
3. Informacja zwrotna — dostarczanie programistom natychmiastowego sygnału, że ich zmiany nie zepsuły podstawowego działania pipeline’u, często w ciągu 60 sekund od zatwierdzenia.

Testy dymne zajmują pierwszy poziom piramidy testowania, wykonując się przed testami jednostkowymi, integracyjnymi i kompleksowymi zestawami regresyjnymi. Są zaprojektowane tak, aby kończyć się w poniżej 60 sekund dla typowego pipeline’u inspekcyjnego, co czyni je odpowiednimi do wykonywania przy każdym zatwierdzeniu kodu w CI/CD. W organizacjach o wysokiej dojrzałości oprogramowania testy dymne uruchamiane są przy każdym pushu do dowolnego brancha, nie tylko głównego, zapewniając najwcześniejsze możliwe wykrycie błędów integracyjnych.

Historyczne pochodzenie i adopcja w branży

Koncepcja testowania dymnego poprzedza inżynierię oprogramowania o dekady. Pierwsze udokumentowane użycie tego wyrażenia pojawia się w testowaniu instalacji wodno-kanalizacyjnych i pieców z XIX wieku. Producenci pieców rozpalali ogień wewnątrz nowo zmontowanego pieca, zamykali wszystkie przepustnice i obserwowali, gdzie wydobywa się dym — jeśli dym pojawiał się w niezamierzonych miejscach, piec miał wady konstrukcyjne. Ta sama logika „przyłóż minimalną moc i obserwuj, gdzie coś się psuje" migrowała do testowania elektroniki w połowie XX wieku, a wreszcie do inżynierii oprogramowania w latach 80. i 90.

Microsoft jest powszechnie uznawany za wprowadzenie testowania dymnego do głównego nurtu inżynierii oprogramowania. Pod koniec lat 90. działy Windows i Office Microsoftu przyjęły to, co nazwano testowaniem weryfikacji kompilacji (BVT), jako obowiązkowy proces bramkujący. Każda nocna kompilacja musiała przejść zestaw BVT, zanim została udostępniona wewnętrznym testerom. Jeśli BVT zakończył się niepowodzeniem, kompilacja była „zepsuta", a odpowiedzialny programista był powiadamiany niezależnie od pory dnia. Ta kultura natychmiastowej odpowiedzialności za jakość kompilacji stała się fundamentem kultury inżynieryjnej Microsoftu i została szeroko udokumentowana w dokumentacji MSDN i książkach Microsoft Press.

Taksonomia Crosslake Technologies (wywodząca się bezpośrednio z praktyki Microsoftu) rozróżnia testy dymne i BVT. Testy dymne opisywane są jako „pobieżne — zapewniają, że podstawowa funkcjonalność działa", wykonujące się w minutach i skupione na krytycznych funkcjach. BVT opisywane są jako „nadzbiór testów dymnych", które są „nieco bardziej dokładne", ale wciąż wykonują się w minutach, a nie godzinach. Obie pełnią tę samą funkcję bramkującą, ale BVT obejmują szerszy zestaw scenariuszy ścieżki krytycznej.

Google przyjęło testowanie dymne poprzez swoje praktyki SRE (Inżynieria Niezawodności Systemów). Blog testowy Google traktuje testowanie dymne jako znaną, przyjętą praktykę, skupiając się bardziej na tym, jak ważyć wyniki testów dymnych obok innych typów testów. Kultura inżynieryjna Google kładzie nacisk na precyzję w testach jednostkowych i ważone oceny ufności dla szerokich kontroli w stylu testów dymnych, traktując testy dymne jako uzupełnienie, a nie zastąpienie rygorystycznych testów jednostkowych.

W domenie oprogramowania lotniczego testowanie dymne odpowiada fazie testowania integracji sprzętu/oprogramowania opisanej w DO-178C, sekcja 6.4.3. Chociaż DO-178C nie wymienia wyraźnie „testowania dymnego", norma wymaga, aby zintegrowany system „uruchamiał się, a podstawowe funkcje działały" przed rozpoczęciem głębszych testów. Jest to funkcjonalnie identyczne z testowaniem dymnym. Dla oprogramowania inspekcji lotnisk działającego zgodnie z Załącznikiem 14 ICAO — który reguluje projektowanie i eksploatację lotnisk — testy dymne zapewniają niezawodność oprogramowania niezbędną do wsparcia ocen wskaźnika stanu nawierzchni (PCI), które zasilają systemy zarządzania bezpieczeństwem lotnisk.

Test dymny a test jednostkowy a test integracyjny

Zrozumienie, gdzie testy dymne mieszczą się w szerszej taksonomii testowania, jest niezbędne do zbudowania zrównoważonej strategii zapewniania jakości. Cztery główne poziomy testowania pełnią komplementarne, ale odrębne role, każdy celując w różne tryby awarii na różnych etapach cyklu życia pipeline’u.

Testy jednostkowe walidują, że poszczególne funkcje produkują poprawne wyniki dla danych wejściowych. Mockują wszystkie zewnętrzne zależności — bazy danych, systemy plików, usługi sieciowe, akceleratory sprzętowe. Test jednostkowy dla funkcji wykrywania spękań może weryfikować, że poprawnie identyfikuje ona spękania w syntetycznej tablicy 10×10 pikseli o znanych pozycjach spękań. Testy jednostkowe są wąskie i głębokie: weryfikują logikę pojedynczej funkcji wyczerpująco, pokrywając przypadki brzegowe, warunki graniczne i ścieżki błędów. Testy jednostkowe nie mogą jednak wyłapać błędów integracyjnych, ponieważ zależności są zamockowane — test nigdy nie ćwiczy rzeczywistego łańcucha importów, ładowania konfiguracji ani przepływu danych między modułami.

Testy integracyjne walidują, że dwa lub więcej komponentów współpracuje ze sobą poprawnie. Używają rzeczywistych, ale kontrolowanych instancji zależności. Test integracyjny dla TarmacView może weryfikować, że etap wczytywania obrazu poprawnie przekazuje dane do modelu wykrywania spękań w oczekiwanym formacie tensorowym z prawidłowym porządkiem kanałów i parametrami normalizacji. Testy integracyjne są węższe niż testy dymne pod względem zakresu pipeline’u, ale głębsze pod względem walidacji interakcji: skupiają się na konkretnych granicach komponentów, a nie na całym pipeline’ie.

Testy dymne walidują, że cały pipeline wykonuje się bez awarii. Uruchamiają każdy etap sekwencyjnie z rzeczywistymi, choć małymi danymi. Testy dymne są szerokie i płytkie — obejmują cały pipeline, ale weryfikują jedynie, że wykonanie się zakończyło i dane wyjściowe istnieją, a nie że wyniki numeryczne są poprawne. Obliczenie długości spękania zwracające 47,2 piksela zamiast prawidłowych 42,1 piksela przechodzi test dymny, o ile kolumna length_px istnieje i zawiera wartość zmiennoprzecinkową.

Testy systemowe (zwane także testami kompleksowymi) uruchamiają kompletny system z danymi w skali produkcyjnej w środowisku zbliżonym do produkcyjnego. Weryfikują, że system spełnia swoje wymagania funkcjonalne i niefunkcjonalne, w tym dokładność, wydajność i niezawodność. Testy systemowe są najdroższe w uruchamianiu i utrzymaniu i wykonują się tylko na kandydatach do wydania, a nie przy każdym zatwierdzeniu.

W piramidzie testowania testy dymne stanowią warstwę podstawową — wykonują się najpierw, najszybciej i najczęściej. Jeśli test dymny zakończy się niepowodzeniem, testy jednostkowe i integracyjne na tej kompilacji są zazwyczaj pomijane lub oznaczane jako wstępnie zawodne. Oszczędza to zasoby obliczeniowe i czas programistów poprzez szybkie wykrywanie awarii, gdy podstawowe działanie pipeline’u jest zepsute.

Projektowanie testów dymnych — reprezentatywne minimalne dane wejściowe

Skuteczne projektowanie testów dymnych koncentruje się na koncepcji reprezentatywnych minimalnych danych wejściowych — najmniejszego zestawu danych, który ćwiczy każdy etap pipeline’u bez wyzwalania przypadków brzegowych zależnych od danych. Jest to najważniejsza decyzja projektowa przy budowaniu zestawu testów dymnych.

Zasady wyboru danych wejściowych do testów dymnych

Zasada 1: Minimalne, ale nie trywialne. Dane wejściowe muszą być wystarczająco duże, aby przejść przez każdy etap pipeline’u bez wchodzenia na ścieżki kodu omijające rzeczywistą logikę przetwarzania. Obraz o jednym pikselu jest trywialny — przejdzie przez ładowanie obrazu, ale algorytmy przetwarzania wejdą na zdegenerowane ścieżki kodu, które nigdy nie są wykonywane na rzeczywistych danych. Obraz 256×256 pikseli rzeczywistej nawierzchni drogi startowej jest minimalny, a jednocześnie reprezentatywny: ćwiczy algorytmy przetwarzania oparte na kafelkach, procedury normalizacji kolorów i ścieżki wnioskowania modeli bez wymagania nadmiernego czasu obliczeniowego.

Zasada 2: Reprezentatywne dla danych produkcyjnych. Dane wejściowe powinny mieć ten sam format pliku, głębię kolorów, strukturę metadanych i właściwości statystyczne co dane produkcyjne. Jeśli dane produkcyjne pochodzą z kamery lotniczej Phase One iXM-RS150F przechwytującej 16-bitowe pliki TIFF z osadzonymi metadanymi EXIF GPS, dane wejściowe testu dymnego muszą odpowiadać tym charakterystykom. Używanie danych syntetycznych różniących się od danych produkcyjnych niweczy cel testu dymnego, ponieważ awarie pipeline’u często wynikają z nieoczekiwanych właściwości rzeczywistych danych — brakujących tagów EXIF, nieoczekiwanych profili kolorów, niestandardowych ciągów projekcji GeoTIFF.

Zasada 3: Stałe i kontrolowane wersjami. Dane wejściowe testów dymnych muszą być przechowywane w systemie kontroli wersji wraz z kodem jako pliki binarne lub zarządzane przez Git LFS (Large File Storage). Nigdy nie powinny się zmieniać bez wyraźnego przeglądu poprzez pull requesty. Zmieniające się dane wejściowe uniemożliwiają odróżnienie regresji pipeline’u od zmian danych testowych — test dymny, który przechodzi dzisiaj, a kończy się niepowodzeniem jutro, może wskazywać zarówno na regresję kodu, jak i zmodyfikowane dane testowe. Kontrolowanie wersji danych wejściowych eliminuje tę niejednoznaczność.

Zasada 4: Szybkie w przetwarzaniu. Całkowity czas wykonania zestawu testów dymnych nie powinien przekraczać 60 sekund dla typowego pipeline’u i 3 minut dla złożonych, wieloetapowych pipeline’ów, takich jak oprogramowanie inspekcyjne. To ograniczenie determinuje rozmiar danych wejściowych. Dla pipeline’ów inspekcyjnych opartych na obrazach pojedynczy obraz 512×512 pikseli jest zazwyczaj wystarczający. Dla pipeline’ów wideo — pojedyncza klatka lub 2-sekundowy klip. Dla pipeline’ów LiDAR — pojedynczy segment linii lotu obejmujący 100 metrów nawierzchni.

Zasada 5: Zawiera znane cechy. Dane wejściowe testu muszą zawierać cechy, które każdy etap pipeline’u jest zaprojektowany do wykrywania. Test dymny do wykrywania spękań jest bezużyteczny, jeśli obraz wejściowy nie zawiera spękań — pipeline mógłby po cichu pominąć wykrywanie spękań i nadal przejść test. Dane wejściowe testów muszą być dobrane tak, aby zawierały co najmniej jeden egzemplarz każdej wykrywalnej cechy ze znanym wzorcem referencyjnym, który można wykorzystać podczas analizy awarii.

Przykład danych wejściowych testu dymnego dla TarmacView

Dla pipeline’u inspekcyjnego TarmacView danymi wejściowymi testu dymnego jest pojedynczy pasek ortofotomapy RGB o rozmiarze 1024×768 pikseli nawierzchni lotniskowej, przechwycony z naziemną odległością próbkowania (GSD) 1 mm. Obraz zawiera co najmniej jedną widoczną spękanie, jeden defekt nawierzchni (np. wybojenie lub spalling) oraz wyraźne oznakowanie nawierzchni. Ten pojedynczy obraz:

• Ćwiczy etap wczytywania obrazu — dekodowanie, korekcję kolorów, georeferencję
• Ćwiczy model wykrywania spękań — co najmniej jedno spękanie obecne
• Ćwiczy model klasyfikacji defektów — co najmniej jeden defekt obecny
• Ćwiczy etap mapowania geodezyjnego — przypisanie współrzędnych geoprzestrzennych
• Ćwiczy etap wizualizacji — renderowanie nakładek z adnotacjami
• Ćwiczy etap oceny — obliczanie PCI lub punktacji stanu

Oczekiwany czas przetwarzania tego pojedynczego obrazu przez cały pipeline wynosi poniżej 30 sekund na sprzęcie CI, pozostawiając margines dla pozostałych testów dymnych w zestawie. Obraz testowy jest przechowywany w repozytorium pod ścieżką tests/data/smoke/ i jest kontrolowany wersjami przez Git LFS.

Testy dymne TarmacView

Pipeline inspekcyjny TarmacView jest walidowany przez zestaw dedykowanych skryptów testów dymnych, każdy obejmujący konkretną fazę pipeline’u. Skrypty te znajdują się w katalogu scripts/, zgodnie z konwencją nazewnictwa smoke_<faza>.py. Każdy skrypt jest zaprojektowany tak, aby można go było uruchomić zarówno samodzielnie (do debugowania podczas rozwoju), jak i jako część zestawu CI (do automatycznego bramkowania).

{{

smoke_analyze.py

Ten skrypt waliduje fazę analizy obrazu. Wczytuje pojedynczy reprezentatywny pasek ortofotomapy, uruchamia pełny pipeline analizy przez moduł przetwarzania obrazu i weryfikuje:

• Obraz jest ładowany i dekodowany bez błędów z formatu kontenera TIFF
• Korekcja kolorów i normalizacja radiometryczna kończą się pomyślnie, konwertując surowe wartości czujników na wartości odbicia
• Metadane georeferencyjne są parsowane i stosowane, w tym informacje o strefie UTM i datumie
• Przetworzony obraz ma oczekiwane wymiary (1024×768 pikseli) i typ danych (float32)
• Wyjściowy plik analizy jest zapisywany pod oczekiwaną ścieżką w katalogu wyjściowym analizy
• Minimalne i maksymalne wartości pikseli mieszczą się w prawidłowych zakresach radiometrycznych

Skrypt akceptuje argument --input wskazujący obraz testowy oraz argument --output-dir określający, gdzie pipeline powinien zapisywać wyniki. Jeśli pipeline ulegnie awarii podczas dowolnego kroku przetwarzania, wyjątek jest przechwytywany, a test zwraca strukturalny raport awarii.

smoke_assess.py

Ten skrypt waliduje fazę oceny stanu nawierzchni. Pobiera wynik fazy analizy (lub predefiniowany plik analizy przechowywany w kontroli wersji), uruchamia algorytm oceny stanu i weryfikuje:

• Funkcja oceny wykonuje się bez błędów na danych wejściowych
• Wskaźniki stanu (wskaźnik stanu nawierzchni PCI lub równoważny) są obliczane
• Wyjściowy plik oceny zawiera oczekiwane kolumny: pavement_id, condition_index, severity, extent, date_assessed
• Wyniki oceny mieszczą się w prawidłowym zakresie numerycznym (0–100 dla PCI, gdzie 0 oznacza awarię, a 100 stan idealny)
• Plik wyjściowy jest zapisywany jako plik Parquet z oczekiwanym schematem

Algorytm oceny w TarmacView jest zgodny z normą ASTM D5340 dotyczącą obliczania PCI dla lotnisk, dostosowaną do zautomatyzowanej inspekcji opartej na obrazach. Test dymny nie weryfikuje, czy wartości PCI są numerycznie poprawne — weryfikuje jedynie, że obliczenia są wykonywane, produkują wyniki w oczekiwanym formacie i są zapisywane na dysku.

smoke_crack.py

Ten skrypt waliduje fazę wykrywania spękań. Uruchamia model wykrywania spękań na obrazie testowym znanym z zawierania spękań i weryfikuje:

• Model ładuje się pomyślnie z pliku wag i wykonuje wnioskowanie bez błędów
• Środowisko uruchomieniowe PyTorch lub TensorFlow inicjalizuje się poprawnie, w tym inicjalizacja CUDA/GPU jeśli dostępna
• Wyjściowa maska spękań ma te same wymiary co obraz wejściowy (1024×768)
• Wykryto co najmniej jeden piksel spękania, potwierdzając, że obraz testowy zawiera znane spękania, a model reaguje
• Plik właściwości spękań zawiera kolumny: crack_id, length_px, width_px, orientation, confidence, classification
• Pliki wyjściowe są zapisywane pod oczekiwanymi ścieżkami w katalogu wyjściowym spękań

Model wykrywania spękań używany przez TarmacView to architektura U-Net z szkieletem ResNet-50 wytrenowana na oznakowanych obrazach nawierzchni z wielu lotnisk. Obraz wejściowy testu dymnego został specjalnie wybrany ze zbioru walidacyjnego, co oznacza, że zawiera spękania, które model widział podczas treningu, ale nie podczas ewaluacji na zbiorze testowym.

smoke_defect.py

Ten skrypt waliduje fazę klasyfikacji defektów nawierzchni. Uruchamia klasyfikator defektów na obrazie testowym zawierającym znane defekty (wybojenia, spalling, łatania, wietrzenie) i weryfikuje:

• Klasyfikator ładuje się i produkuje predykcje bez błędów
• Wyjściowa mapa klasyfikacji odpowiada wymiarom obrazu wejściowego
• Przewidziana jest co najmniej jedna klasa defektu, potwierdzając, że znane defekty są obecne na wejściu
• Plik inwentaryzacji defektów zawiera kolumny: defect_id, defect_type, area_px, severity, confidence, timestamp
• Wyjściowy plik geoprzestrzenny zawiera prawidłowe współrzędne w oczekiwanym układzie CRS (układzie odniesienia współrzędnych)
• Liczby poligonów defektów są rozsądne (niezerowe i nie podejrzanie wysokie)

Klasyfikator defektów używa architektury Mask R-CNN, która produkuje maski segmentacji instancji dla każdego wykrytego defektu. Test dymny sprawdza, czy wyjściowa maska ma prawidłowe wymiary i czy plik inwentaryzacji zawiera oczekiwane kolumny schematu. Nie sprawdza, czy klasyfikacje defektów są poprawne — to wymaga oddzielnego zestawu walidacyjnego z oznakowanymi danymi referencyjnymi.

smoke_survey.py

Ten skrypt waliduje fazę mapowania geodezyjnego. Pobiera dane o spękaniach i defektach wyprodukowane przez poprzednie etapy, uruchamia moduł mapowania geodezyjnego i weryfikuje:

• Przypisanie współrzędnych geoprzestrzennych kończy się bez błędów, konwertując współrzędne pikseli na współrzędne świata rzeczywistego
• Wyjściowy plik geodezyjny zawiera prawidłowe kolumny szerokości i długości geograficznej z wartościami w oczekiwanych granicach geograficznych
• Relacje przestrzenne między wykrytymi cechami są zachowane (spękania sąsiadujące w przestrzeni pikseli pozostają sąsiadujące w przestrzeni geograficznej)
• Wyjściowy plik geodezyjny zawiera oczekiwane metadane projekcji, w tym kod EPSG
• Plik jest zapisywany w wymaganym formacie wyjściowym (GeoJSON lub Shapefile)
• Typy geometrii są prawidłowe (LineString dla spękań, Polygon dla defektów, Point dla znaczników geodezyjnych)

Moduł mapowania geodezyjnego wykorzystuje metadane georeferencyjne ortofotomapy do wykonania transformacji projekcyjnej ze współrzędnych pikseli na współrzędne geograficzne. Test dymny weryfikuje, że ta transformacja produkuje prawidłowe współrzędne geograficzne w oczekiwanym prostokącie ograniczającym dla obrazu testowego. Zdjęcie lokalizacji obrazu testowego wykonane na lotnisku stanowi wizualne odniesienie do analizy awarii.

smoke_seg_head.py (Faza wizualizacji)

Ten skrypt waliduje fazę wizualizacji i głowicy segmentacji — końcowy etap pipeline’u, który produkuje dane wyjściowe czytelne dla człowieka. Pobiera przetworzone wyniki pipeline’u, uruchamia mechanizm renderowania wizualizacji i weryfikuje:

• Obrazy z nakładkami renderują się bez błędów, łącząc maski spękań, poligony defektów i wyniki oceny na bazowej ortofotomapie
• Wyjściowa wizualizacja odpowiada wymiarom wejściowym i przestrzeni kolorów
• Elementy legendy i adnotacji są obecne, w tym skala, strzałka północy i kolorowa legenda dotkliwości
• Generowanie raportu kończy się pomyślnie, produkując podsumowanie w formacie HTML lub PDF
• Końcowe pliki wyjściowe są zapisywane pod oczekiwanymi ścieżkami z prawidłowymi rozszerzeniami plików (.png dla obrazów, .html lub .pdf dla raportów)
• Rozmiary plików są niezerowe i mieszczą się w oczekiwanych zakresach

Faza wizualizacji jest często pierwszym miejscem, gdzie skumulowane błędy pipeline’u stają się widoczne. Etap wykrywania spękań, który produkuje maskę w niewłaściwej przestrzeni współrzędnych, wygeneruje wizualizację, w której nakładki spękań są przesunięte względem obrazu bazowego. Test dymny wykrywa to pośrednio, jeśli renderowanie ulegnie awarii, ale to regresyjny test inspekcji wizualnej — a nie test dymny — wyłapuje regresje jakości wizualnej.

Orkiestracja testów i format wyników

Te testy dymne są zaprojektowane do uruchamiania sekwencyjnego, ale mogą również wykonywać się niezależnie, jeśli wyniki poprzednich etapów są buforowane. Pełny zestaw kończy się w poniżej 3 minut na sprzęcie CI. Każdy test wyprowadza strukturalny raport JSON z polami:

Uruchamiacz testów agreguje poszczególne raporty JSON w podsumowanie zestawu, które jest publikowane na dashboardzie CI i opcjonalnie wysyłane przez Slack lub e-mail w celu powiadomienia w czasie rzeczywistym.

Co weryfikują testy dymne

Testy dymne są celowo wąskie w tym, co potwierdzają. Weryfikują trzy kategorie warunków i nic więcej. Ten wąski zakres jest zamierzony — utrzymuje testy szybkimi, deterministycznymi i łatwymi w utrzymaniu.

1. Pipeline wykonuje się do końca

Najbardziej podstawowe twierdzenie: czy kod wykonuje się bez zgłaszania nieobsłużonego wyjątku? Obejmuje to:

• Łańcuchy importów rozwiązują się poprawnie — wszystkie importy modułów Pythona kończą się sukcesem, zależności przechodnie są zainstalowane, konflikty wersji nie występują
• Pliki konfiguracyjne parsują się bez błędów — pliki konfiguracyjne YAML, JSON lub TOML są składniowo prawidłowe i zawierają oczekiwane klucze
• Zależności zewnętrzne są dostępne — pliki wag modeli znajdują się pod oczekiwanymi ścieżkami, połączenia z bazami danych udają się, endpointy API są osiągalne
• Akceleratory sprzętowe są dostępne — GPU jest obecne, a CUDA inicjalizuje się poprawnie, jeśli pipeline wymaga wnioskowania na GPU
• Ścieżki systemu plików istnieją i są zapisywalne — katalogi wyjściowe są tworzone i mają prawidłowe uprawnienia do zapisu
• Limity pamięci nie są przekroczone — pipeline przetwarza dane wejściowe testu bez wyzwalania błędów braku pamięci

Pipeline, który ulega awarii podczas uruchamiania lub w trakcie wykonania, natychmiast kończy test dymny niepowodzeniem. Przyczyna awarii jest przechwytywana z tracebacka wyjątku, dostarczając programistom bezpośredniego wskaźnika do lokalizacji awarii w kodzie.

2. Pliki wyjściowe istnieją

Po zakończeniu wykonania test dymny sprawdza, czy pliki wyjściowe istnieją pod oczekiwanymi ścieżkami. Obejmuje to:

• Główne pliki wyjściowe są obecne — raporty wyników, przetworzone obrazy, wyniki modeli
• Pliki pośrednie są obecne — jeśli kontrakt pipeline’u określa, że wyniki pośrednie muszą być utrwalone, test dymny sprawdza ich obecność
• Rozmiary plików są niezerowe — plik wyjściowy o zerowej długości wskazuje, że etap nie wyprodukował danych, co jest niepowodzeniem
• Sygnatury formatu plików są prawidłowe — nagłówek pliku odpowiada oczekiwanemu formatowi (np. prawidłowe bajty magiczne PNG, prawidłowa struktura GeoJSON, prawidłowe bajty magiczne Parquet)

Pipeline, który deklaruje zakończenie, ale nie produkuje plików wyjściowych, kończy test dymny niepowodzeniem. Wyłapuje to ciche awarie, w których pipeline kończy działanie czysto, ale pomija krytyczne operacje zapisu z powodu błędnie skonfigurowanych ścieżek wyjściowych lub logiki warunkowej, która nieoczekiwanie daje wartość fałsz.

3. Kluczowe kolumny obecne w wyjściu tabelarycznym

Dla każdego wyjścia tabelarycznego (CSV, Parquet, kolekcja cech GeoJSON) test dymny weryfikuje, że oczekiwane kolumny istnieją po nazwie. Jest to kontrola integralności strukturalnej — schemat kolumn musi odpowiadać temu, czego oczekują konsumenci downstream.

Test używa sprawdzenia istnienia kolumn (nie sprawdzenia typu, nie sprawdzenia zakresu wartości). Jest to zamierzone — istnienie kolumn to minimalna gwarancja integralności strukturalnej. Sprawdzenia typu i zakresu należą do testów integracyjnych i walidacyjnych, gdzie koszt ich uruchomienia jest uzasadniony głębią informacji, które dostarczają.

4. Kompatybilność formatu danych

Czwarta kategoria weryfikacji, którą wykonują testy dymne — często pomijana — to kompatybilność formatu danych. Test dymny weryfikuje, że pliki wyjściowe mogą być odczytane przez oczekiwanych konsumentów downstream. Dla TarmacView oznacza to:

• Pliki Parquet mogą być odczytane przez Pandas bez błędów schematu
• Pliki GeoJSON mogą być sparsowane przez shapely i geopandas
• Pliki GeoTIFF mogą być otwarte przez rasterio z prawidłowymi metadanymi CRS
• Raporty JSON mogą być deserializowane bez błędów składniowych
• Pliki CSV mają spójną liczbę wierszy we wszystkich kolumnach

Wyłapuje to niezgodności wersji formatów — na przykład jeśli biblioteka Parquet zostanie zaktualizowana i zmieni swoje kodowanie, lub jeśli specyfikacja GeoJSON ewoluuje, a wyjście pipeline’u przestanie być zgodne.

Czego testy dymne NIE weryfikują

Równie ważne jest zrozumienie, co testy dymne celowo wykluczają. Niezrozumienie tego prowadzi do fałszywego poczucia pewności co do poprawności pipeline’u — pozytywny wynik testu dymnego nie oznacza, że pipeline jest poprawny, tylko że nie jest katastrofalnie uszkodzony.

Dokładność numeryczna

Testy dymne nie weryfikują, że obliczone wartości są poprawne. Obliczenie długości spękania zwracające 47,2 piksela zamiast prawidłowych 42,1 piksela przechodzi test dymny, o ile kolumna length_px istnieje i zawiera liczbę zmiennoprzecinkową. Walidacja dokładności należy do testów jednostkowych, gdzie poprawna wartość jest zakodowana na stałe, oraz testów integracyjnych, gdzie wyniki są porównywane z ręcznymi pomiarami certyfikowanych inspektorów.

Dla pipeline’ów inspekcji lotniczej działających zgodnie z Załącznikiem 14 ICAO dokładność numeryczna jest krytyczna, ponieważ oceny stanu bezpośrednio wpływają na priorytetyzację konserwacji i alokację budżetu. Pipeline, który przechodzi testy dymne, ale produkuje niedokładne wyniki PCI, może prowadzić do błędnych decyzji konserwacyjnych. Dlatego testy dymne są tylko pierwszą bramką — muszą być następcze przez testy walidacyjne skoncentrowane na dokładności.

Przypadki brzegowe

Testy dymne używają reprezentatywnych, ale nieadwersarialnych danych wejściowych. Nie testują:

• Pustych obrazów — całkowicie czarnych lub całkowicie białych obrazów, które nie zawierają żadnych cech
• Uszkodzonych plików — obciętych nagłówków TIFF, brakujących danych EXIF, plików o zerowej długości
• Ekstremalnych warunków oświetleniowych — prześwietlonych lub niedoświetlonych obrazów, zacienionych obrazów, przechwyconych nocą
• Obrazów poza oczekiwanymi limitami rozdzielczości — obrazów o 100 megapikselach lub miniatur poniżej 100 pikseli
• Brakujących metadanych — obrazów bez georeferencji, bez EXIF GPS, bez danych kalibracji kamery
• Przekroczeń czasu sieci — wywołań API, które zawieszają się lub zwracają błędy 503
• Dostępu współbieżnego — wielu instancji pipeline’u zapisujących do tego samego katalogu wyjściowego

Obsługa przypadków brzegowych jest walidowana przez dedykowane testy przypadków brzegowych, które celowo atakują każdy warunek graniczny. Testy te są droższe w uruchamianiu i są zazwyczaj wykonywane nocnie, a nie przy każdym zatwierdzeniu.

Charakterystyki wydajnościowe

Testy dymne weryfikują, że pipeline kończy działanie, a nie że kończy w ramach budżetu wydajnościowego. Pipeline, który zajmuje 10 sekund na obraz w testach dymnych, ale ma przetwarzać 100 obrazów na sekundę w produkcji, przechodzi testy dymne bez problemu. Walidacja wydajności wymaga dedykowanych testów porównawczych z danymi w skali produkcyjnej i asercjami czasowymi.

Dla pipeline’ów inspekcji lotnisk wydajność jest krytyczna, ponieważ lotniska przetwarzają setki obrazów nawierzchni na jedno badanie. 10-krotna regresja wydajności może nadal przechodzić testy dymne na pojedynczym obrazie, ale uczyniłaby pełne badania niewykonalnymi. Testy porównawcze wydajności z progami czasowymi są odpowiednim narzędziem do wykrywania takich regresji.

Regresja w cechach niekrytycznych

Testy dymne obejmują tylko podstawową ścieżkę wykonania. Cechy nie znajdujące się na ścieżce krytycznej — alternatywne formaty wyjściowe, opcjonalne logowanie, telemetria, ścieżki audytu, eksperymentalne funkcje eksportu — nie są objęte. Regresje w tych obszarach muszą być wyłapywane przez zestawy testów regresyjnych, które celowo atakują funkcjonalności niekrytyczne.

Jakość danych

Testy dymne nie weryfikują, że wartości danych są wewnętrznie spójne. Na przykład test dymny sprawdza, że kolumna crack_id istnieje, ale nie weryfikuje, że wszystkie wartości crack_id są unikalne, niepuste ani mieszczą się w oczekiwanych zakresach. Walidacja jakości danych wymaga dedykowanych testów jakości danych z wykorzystaniem frameworków takich jak Great Expectations lub Pandera, które definiują kontrakty danych i walidują zestawy danych względem nich.

Testy dymne w CI/CD

Testy dymne dostarczają maksymalną wartość, gdy są zintegrowane z pipeline’m ciągłej integracji i ciągłego wdrażania (CI/CD). Ich umiejscowienie w przepływie pracy pipeline’u determinuje ich skuteczność jako bramki jakości.

{{

Umiejscowienie w pipeline’ie

W typowym przepływie pracy CI/CD testy dymne wykonują się na etapie weryfikacji kompilacji, bezpośrednio po kompilacji i przed wszystkimi innymi zestawami testów:

Zatwierdzenie kodu → Kompilacja → Lint → Testy jednostkowe → Testy dymne → Testy integracyjne → Testy walidacyjne → Wdrożenie

Dokładna kolejność zależy od strategii testowania projektu. Niektóre organizacje uruchamiają testy jednostkowe przed testami dymnymi, argumentując, że testy jednostkowe są szybsze i wyłapują błędy logiczne. Inne uruchamiają testy dymne jako pierwsze, argumentując, że pipeline, który ulega awarii przy podstawowym wykonaniu, powinien być odrzucony bez poświęcania czasu na testy jednostkowe. Pipeline TarmacView uruchamia testy jednostkowe i testy dymne równolegle po udanej kompilacji, ponieważ obejmują one niezależne tryby awarii i nie mają współzależności.

To umiejscowienie zapewnia, że jeśli kompilacja wyprodukuje pipeline, który ulega awarii przy podstawowym wykonaniu, żadna dalsza infrastruktura testowa nie jest zużywana. Pętla sprzężenia zwrotnego mierzona jest w minutach, a nie godzinach. Programista, który pushuje zatwierdzenie zrywające łańcuch importów, otrzymuje powiadomienie o niepowodzeniu CI w ciągu 2–3 minut, zamiast czekać 4 godziny, aż zestaw testów integracyjnych zakończy się niepowodzeniem.

Logika bramki

Pipeline CI/CD używa twardej bramki: jeśli jakikolwiek test dymny zakończy się niepowodzeniem, pipeline zatrzymuje się i nie przechodzi do kolejnych etapów. Kompilacja jest oznaczona jako nieudana, a programiści są powiadamiani z raportem awarii testu dymnego. W domyślnej konfiguracji nie jest dozwolone żadne ręczne nadpisanie — pozytywny wynik zestawu testów dymnych jest warunkiem koniecznym do wdrożenia.

Ta logika bramki zapobiega następującym scenariuszom:

• Zespół uruchamia testy integracyjne przez 4 godziny, tylko po to, by odkryć, że pipeline ulega awarii przy ładowaniu danych — marnując zasoby obliczeniowe i blokując inne kompilacje
• Kandydat do wydania jest wdrażany do środowiska stagingowego, gdzie schemat bazy danych został po cichu zmieniony podczas konfiguracji wdrożenia
• Wdrożenie produkcyjne psuje się z powodu brakującego importu lub ścieżki pliku, która została wprowadzona w ostatnim zatwierdzeniu

Bramka jest zaimplementowana w konfiguracji platformy CI. Dla CircleCI oznacza to skonfigurowanie zależności przepływu pracy tak, aby zadanie smoke-test było uruchamiane przed integration-test i deploy. Dla GitHub Actions oznacza to użycie słowa kluczowego needs: do wymuszenia kolejności zadań.

Równoległe wykonywanie i współbieżność

Testy dymne w ramach zestawu mogą być uruchamiane równolegle, jeśli testują niezależne etapy pipeline’u. Zestaw testów dymnych TarmacView używa równoległości, gdzie to możliwe:

• smoke_crack.py i smoke_defect.py nie mają współzależności i mogą być wykonywane równocześnie, redukując całkowity czas zestawu o 40%
• smoke_analyze.py musi zostać ukończony przed smoke_assess.py, ponieważ ocena zużywa wyniki analizy
• smoke_survey.py zależy od wyników spękań i defektów
• smoke_seg_head.py zależy od wszystkich wyników upstream

Strategia równoległego wykonywania jest skonfigurowana w YAML pipeline’u CI przy użyciu równoległości na poziomie zadań. Każde zadanie działa we własnym kontenerze z izolowanymi zależnościami, zapobiegając rywalizacji o zasoby.

Raportowanie i powiadomienia

Integracja CI/CD obejmuje automatyczne raportowanie z wieloma kanałami:

• Status zaliczenia/niezaliczenia na dashboardzie CI z kolorowymi wskaźnikami (zielony dla zaliczenia, czerwony dla niezaliczenia)
• Czas trwania śledzony dla każdego testu do analizy trendów — stopniowy wzrost czasu trwania testu dymnego może wskazywać na regresję wydajności
• Logi awarii przechwycone jako artefakty CI do inspekcji przez programistów z pełnymi tracebackami stosu
• Powiadomienia przez Slack lub e-mail w przypadku awarii testu z linkami do logów i zatwierdzenia powodującego problem
• Wykresy trendów pokazujące wskaźnik pozytywnych wyników w czasie z celem >99% na głównym branchu
• Wykrywanie niestabilnych testów — test, który naprzemiennie zalicza i nie zalicza na tym samym zatwierdzeniu, jest oznaczany do zbadania

Przykład konfiguracji CI/CD

# .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: "Równoległe testy dymne"
          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]

Pisanie testów dymnych

Pisanie skutecznych testów dymnych wymaga dyscypliny. Test musi być szybki, niezawodny i skoncentrowany wyłącznie na tym, co ma wykrywać. Każdy test dymny podąża za tym samym podstawowym wzorcem: uruchom etap pipeline’u, sprawdź istnienie wyników, zweryfikuj minimalną poprawność schematu, zgłoś zaliczenie/niezaliczenie w strukturalnym formacie JSON.

Struktura testu dymnego

# smoke_crack.py — uproszczony wzorzec
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:
        # Krok 1: Pobierz wersję pipeline'u
        from tarmacview import __version__
        result["pipeline_version"] = __version__

        # Krok 2: Uruchom etap pipeline'u z rzeczywistymi importami
        from tarmacview.pipeline.crack import detect_cracks
        output = detect_cracks(input_path, output_dir)

        # Krok 3: Sprawdź, czy plik wyjściowy istnieje i nie jest pusty
        output_path = Path(output["crack_mask_path"])
        assert output_path.exists(), f"Plik wyjściowy nie został znaleziony: {output_path}"
        assert output_path.stat().st_size > 0, f"Plik wyjściowy jest pusty: {output_path}"
        result["output_files"].append(str(output_path))

        # Krok 4: Sprawdź kluczowe kolumny w wyjściu tabelarycznym
        if output.get("crack_inventory_path"):
            inv_path = Path(output["crack_inventory_path"])
            assert inv_path.exists(), f"Plik inwentaryzacji nie został znaleziony: {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"Brak wymaganej kolumny: {col}"
            result["output_files"].append(str(inv_path))

        # Krok 5: Sprawdź, czy wymiary maski wyjściowej odpowiadają wejściu
        from PIL import Image
        input_img = Image.open(input_path)
        mask_img = Image.open(output_path)
        assert input_img.size == mask_img.size, \
            f"Wymiary maski {mask_img.size} nie odpowiadają wejściu {input_img.size}"

        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)

Zasady projektowania

1. Jedna asercja na kategorię. Twierdź, że wykonanie się kończy. Twierdź, że dane wyjściowe istnieją. Twierdź, że kolumny istnieją. Nie twierdź zakresów numerycznych, dokładnych rozmiarów plików ani metryk jakości danych. Każda dodatkowa asercja zwiększa koszt utrzymania testu i zmniejsza jego niezawodność.

2. Używaj rzeczywistych importów. Nie mockuj modułów pipeline’u. Test dymny musi ćwiczyć rzeczywisty łańcuch importów, aby wyłapać błędy importu i brakujące zależności. Test dymny, który używa unittest.mock do tłumienia błędów importu, niweczy własny cel.

3. Minimalna konfiguracja i porządkowanie. Test nie powinien wymagać konfiguracji bazy danych, uruchamiania usług ani zewnętrznej konfiguracji poza plikiem danych wejściowych. Jeśli wymagana jest konfiguracja, powinna być częścią definicji zadania CI, a nie skryptu testowego. Każdy test dymny powinien być uruchamialny na laptopie programisty za pomocą pojedynczego polecenia.

4. Deterministyczność. Te same dane wejściowe muszą zawsze dawać ten sam wynik zaliczenia/niezaliczenia. Ziarna losowości muszą być ustalone w konfiguracji pipeline’u. Pliki danych wejściowych testów muszą być kontrolowane wersjami. Niedeterministyczne testy dymne są gorsze niż bezużyteczne — niszczą zaufanie do całej infrastruktury testowej.