Dymový test

{{

Definícia a účel

Dymový test je ľahký automatizovaný overovací postup, ktorý vykoná softvérový pipeline end-to-end na reprezentatívnych alebo minimálnych vstupných dátach, aby potvrdil, že pipeline prebehne do konca bez zlyhania a produkuje výstupné súbory s očakávanou štruktúrou. Test vykonáva binárne vyhodnotenie úspešnosti/neúspešnosti – ak ktorýkoľvek krok vyvolá neošetrenú výnimku, neprodukuje žiadny výstup alebo vygeneruje výstup s chýbajúcimi kritickými stĺpcami, test zlyhá a zostava je okamžite odmietnutá.

Termín pochádza z hardvérového inžinierstva, kde je metafora doslovná. Keď inžinieri po prvýkrát zapojili novo zostavenú dosku plošných spojov, sledovali, či z vyhorených súčiastok neuniká dym. Ak sa dym objavil, doska mala katastrofálne zlyhanie a všetko ďalšie testovanie sa zastavilo. Chybná doska bola buď opravená, alebo vyradená skôr, než niekto investoval čas do podrobnej diagnostiky. Dymové testovanie softvéru aplikuje rovnaký princíp: spustite kód a skontrolujte „dym" – zlyhania, neošetrené výnimky, chýbajúce výstupy – skôr než investujete čas do podrobnej validácie.

V kontexte inšpekčných softvérových pipeline dymový test overuje, že každá fáza spracovateľského reťazca dokáže pracovať s reprezentatívnymi dátami. Pre TarmacView to znamená vloženie malého obrazu dráhy alebo vozovky cez celý pipeline – od príjmu obrazu cez detekciu trhlín, klasifikáciu defektov, hodnotenie povrchu, mapovanie prieskumu až po vizualizáciu – a overenie, že každá fáza produkuje výstup bez chýb. Toto je obzvlášť kritické pre letiskový softvér, kde zlyhania pipeline môžu oneskoriť hodnotenia letiskovej infraštruktúry, ktoré priamo ovplyvňujú bezpečnosť letov.

Termín test overenia zostavy (BVT) sa často používa zameniteľne s dymovým testom, pričom Microsoft je najvýraznejším prijímateľom tejto terminológie. Interné vývojové procesy Microsoftu – najmä pre Windows a Office – inštitucionalizovali dymové testovanie ako povinnú kvalitatívnu bránu v 90. rokoch. Steve McConnell v knihe Code Complete označuje „dennú zostavu a dymový test" za najlepšiu priemyselnú prax pre zrelosť kontinuálnej integrácie. Rámec Site Reliability Engineering (SRE) od Googlu zaraďuje dymové testy pod „systémové testy" – najjednoduchší typ používaný špecificky na skratovanie drahých testovacích pipeline.

Účel dymového testovania je trojaký:

1. Rýchle zlyhanie – detekcia katastrofálnych zlyhaní v priebehu sekúnd od zmeny kódu skôr, než drahé behy celého pipeline spotrebujú výpočtové zdroje a čas vývojárov.
2. Brána kvality – zabránenie nestabilným zostavám v postupe do staging alebo produkčného prostredia, kde by plytvali testovacou infraštruktúrou a blokovali iné tímy.
3. Spätná väzba – poskytnutie okamžitého signálu vývojárom, že ich zmeny nenarušili základné vykonávanie pipeline, často do 60 sekúnd od commitu.

Dymové testy zaberajú prvú úroveň testovacej pyramídy, pričom sa vykonávajú pred jednotkovými testami, integračnými testami a end-to-end regresnými sadami. Sú navrhnuté tak, aby boli dokončené do 60 sekúnd pre typický inšpekčný pipeline, čo ich robí vhodnými na vykonávanie pri každom commite kódu v CI/CD. V vysokokvalitných softvérových organizáciách sa dymové testy spúšťajú pri každom pushe do akejkoľvek vetvy, nielen do hlavnej vetvy, čo poskytuje čo najskoršiu možnú detekciu integračných zlyhaní.

Historické korene a priemyselné prijatie

Koncept dymového testovania predchádza softvérové inžinierstvo o desaťročia. Prvé dokumentované použitie tohto slovného spojenia sa objavuje v testovaní inštalatérstva a kachlí z 19. storočia. Výrobcovia kachlí zapálili oheň vo vnútri novo zostavenej kachle, zatvorili všetky klapky a pozorovali, kde dym uniká – ak dym vychádzal z nezamýšľaných miest, kachle mali konštrukčné chyby. Rovnaká logika „aplikuj minimálnu energiu a pozoruj, kde sa veci rozbijú" migrovala do testovania elektroniky v polovici 20. storočia a napokon do softvérového inžinierstva v 80. a 90. rokoch.

Microsoftu sa všeobecne pripisuje zásluha za prinášanie dymového testovania do mainstreamovej softvérovej inžinierskej praxe. Koncom 90. rokov divízie Windows a Office spoločnosti Microsoft prijali to, čo nazývali Build Verification Testing (BVT), ako povinný bránový proces. Každá nočná zostava musela prejsť sadou BVT, kým bola zostava uvoľnená interným testerom. Ak BVT zlyhala, zostava bola „rozbitá" a zodpovedný vývojár bol kontaktovaný bez ohľadu na dennú dobu. Táto kultúra okamžitej zodpovednosti za kvalitu zostavy sa stala základom inžinierskej kultúry Microsoftu a bola rozsiahlo zdokumentovaná v dokumentácii MSDN a knihách Microsoft Press.

Taxonómia Crosslake Technologies (odvodená priamo z praxe Microsoftu) rozlišuje medzi dymovými testami a BVT. Dymové testy sú opísané ako „povrchné – zabezpečujú, že základná funkcionalita funguje", trvajú minúty a sú zamerané na kritické funkcie. BVT sú opísané ako „nadmnožina dymových testov", ktoré sú „mierne dôkladnejšie", ale stále trvajú minúty, nie hodiny. Oba slúžia rovnakej bránovej funkcii, ale BVT zahŕňajú širšiu sadu kritických scenárov.

Google prijal dymové testovanie prostredníctvom svojich praktík SRE (Site Reliability Engineering). Blog Google Testing Blog považuje dymové testovanie za známu, samozrejmú prax, pričom sa viac zameriava na to, ako vážiť výsledky dymových testov spolu s inými typmi testov. Inžinierska kultúra Googlu kladie dôraz na presnosť v jednotkových testoch a vážené skóre spoľahlivosti pre široké kontroly typu dymových testov, pričom dymové testy považuje za doplnkové k rigoróznemu jednotkovému testovaniu, nie za jeho náhradu.

V oblasti letiskového softvéru dymové testovanie zodpovedá fáze Hardvérovo/softvérovej integračnej testovania opísanej v DO-178C, časti 6.4.3. Hoci DO-178C výslovne nenazýva „dymové testovanie", norma vyžaduje, aby integrovaný systém „nabootoval a základné funkcie fungovali" predtým, ako začne hlbšie testovanie. Toto je funkčne identické s dymovým testovaním. Pre letiskový inšpekčný softvér pracujúci podľa ICAO Annex 14 – ktorý upravuje návrh a prevádzku letísk – poskytujú dymové testy záruku spoľahlivosti softvéru potrebnú na podporu hodnotení Indexu stavu vozovky (PCI), ktoré vstupujú do systémov riadenia bezpečnosti letísk.

Dymový test vs. jednotkový test vs. integračný test

Pochopenie toho, kam dymové testy zapadajú do širšej testovacej taxonómie, je nevyhnutné pre budovanie vyváženej stratégie zabezpečenia kvality. Štyri hlavné úrovne testovania zastávajú doplnkové, ale odlišné úlohy, pričom každá sa zameriava na rôzne režimy zlyhania v rôznych fázach životného cyklu pipeline.

Jednotkové testy overujú, že jednotlivé funkcie produkujú správne výstupy pre dané vstupy. Mockujú všetky externé závislosti – databázy, súborové systémy, sieťové služby, hardvérové akcelerátory. Jednotkový test pre funkciu detekcie trhlín by mohol overiť, že správne identifikuje trhliny v syntetickom 10x10 pixelovom poli so známymi pozíciami trhlín. Jednotkové testy sú úzke a hlboké: overujú logiku jedinej funkcie vyčerpávajúcim spôsobom, pokrývajúc okrajové prípady, hraničné podmienky a chybové cesty. Jednotkové testy však nedokážu zachytiť integračné zlyhania, pretože závislosti sú mockované – test nikdy necvičí skutočný reťazec importov, načítanie konfigurácie ani medzimodulový tok dát.

Integračné testy overujú, že dve alebo viac komponentov spolupracuje správne. Používajú reálne, ale kontrolované inštancie závislostí. Integračný test pre TarmacView by mohol overiť, že fáza príjmu obrazu správne odovzdá dáta modelu detekcie trhlín v očakávanom tensorovom formáte so správnym usporiadaním kanálov a normalizačnými parametrami. Integračné testy sú užšie ako dymové testy v rozsahu pipeline, ale hlbšie v overovaní interakcií: zameriavajú sa na špecifické hranice komponentov, nie na celý pipeline.

Dymové testy overujú, že celý pipeline sa vykoná bez zlyhania. Spúšťajú každú fázu v poradí s reálnymi, hoci malými dátami. Dymové testy sú široké a plytké – pokrývajú celý pipeline, ale overujú iba to, že vykonávanie bolo dokončené a výstupy existujú, nie že numerické výsledky sú správne. Výpočet dĺžky trhliny, ktorý vráti 47,2 pixelov namiesto správnych 42,1 pixelov, prejde dymovým testom, pokiaľ stĺpec length_px existuje a obsahuje hodnotu s pohyblivou rádovou čiarkou.

Systémové testy (tiež nazývané end-to-end testy) spúšťajú kompletný systém s produkčnými dátami v prostredí podobnom produkčnému. Overujú, že systém spĺňa svoje funkčné a nefunkčné požiadavky vrátane presnosti, výkonu a spoľahlivosti. Systémové testy sú najdrahšie na spustenie a údržbu a vykonávajú sa len na kandidátoch na vydanie, nie pri každom commite.

V testovacej pyramíde tvoria dymové testy základnú vrstvu – spúšťajú sa prvé, najrýchlejšie a najčastejšie. Ak dymový test zlyhá, jednotkové a integračné testy na tejto zostave sú typicky preskočené alebo označené ako preventívne nespoľahlivé. To šetrí výpočtové zdroje a čas vývojárov tým, že zlyhanie nastane rýchlo, keď je základné vykonávanie pipeline narušené.

Návrh dymového testu – reprezentatívny minimálny vstup

Efektívny návrh dymového testu sa sústreďuje na koncept reprezentatívneho minimálneho vstupu – najmenší dataset, ktorý precvičí každú fázu pipeline bez spúšťania okrajových prípadov závislých od dát. Toto je jediné najdôležitejšie rozhodnutie pri budovaní sady dymových testov.

Princípy výberu vstupu dymového testu

Princíp 1: Minimálny, ale nie triviálny. Vstup musí byť dostatočne veľký na to, aby prešiel každou fázou pipeline bez použitia kódových ciest, ktoré obchádzajú skutočnú logiku spracovania. Jednopixelový obraz je triviálny – prešiel by načítaním obrazu, ale spracovacie algoritmy by použili degenerované kódové cesty, ktoré sa nikdy nevykonajú na reálnych dátach. 256x256 pixelový obraz skutočného letiskového povrchu je minimálny, ale reprezentatívny: precvičuje algoritmy spracovania založené na dlaždiciach, rutiny normalizácie farieb a cesty inferencie modelov bez nadmerného výpočtového času.

Princíp 2: Reprezentatívny voči produkčným dátam. Vstup by mal mať rovnaký formát súboru, farebnú hĺbku, štruktúru metadát a štatistické vlastnosti ako produkčné dáta. Ak produkčné dáta pochádzajú z leteckej kamery Phase One iXM-RS150F zachytávajúcej 16-bitové TIFF súbory s vloženými EXIF GPS metadátami, vstup dymového testu musí zodpovedať týmto charakteristikám. Použitie syntetických dát, ktoré sa líšia od produkčných, marí účel dymového testu, pretože zlyhania pipeline často pramenia z neočakávaných vlastností reálnych dát – chýbajúcich EXIF tagov, neočakávaných farebných profilov, neštandardných GeoTIFF projekčných reťazcov.

Princíp 3: Fixný a verzovaný. Vstupy dymových testov musia byť uložené v správe verzií spolu s kódom ako binárne súbory alebo spravované cez Git LFS (Large File Storage). Nikdy by sa nemali meniť bez explicitného preskúmania prostredníctvom pull requestov. Meniaci sa vstup znemožňuje rozlíšiť regresie pipeline od zmien v testovacích dátach – dymový test, ktorý dnes prejde a zajtra zlyhá, by mohol indikovať buď regresiu kódu, alebo upravený testovací vstup. Verzovanie vstupov túto nejednoznačnosť odstraňuje.

Princíp 4: Rýchly na spracovanie. Celkové vykonanie sady dymových testov by nemalo presiahnuť 60 sekúnd pre typický pipeline a 3 minúty pre zložité viacstupňové pipeline, ako je inšpekčný softvér. Toto obmedzenie určuje veľkosť vstupu. Pre obrazové inšpekčné pipeline je typicky postačujúci jeden 512x512 pixelový obraz. Pre video pipeline jeden snímok alebo 2-sekundový klip. Pre LiDAR pipeline jeden segment letovej línie pokrývajúci 100 metrov povrchu.

Princíp 5: Obsahuje známe vlastnosti. Testovací vstup musí obsahovať vlastnosti, ktoré je každá fáza pipeline navrhnutá detekovať. Dymový test detekcie trhlín je zbytočný, ak vstupný obraz neobsahuje žiadne trhliny – pipeline by mohol ticho preskočiť detekciu trhlín a stále prejsť. Testovacie vstupy musia byť starostlivo vybrané tak, aby obsahovali aspoň jednu inštanciu každej detekovateľnej vlastnosti so známou základnou pravdou, ktorá môže byť použitá pri analýze zlyhaní.

Príklad vstupu dymového testu pre TarmacView

Pre inšpekčný pipeline TarmacView je vstupom dymového testu jeden 1024x768 pixelový RGB ortofoto pás letiskového povrchu zachytený s priestorovým rozlíšením 1 mm (GSD). Obraz obsahuje aspoň jednu viditeľnú trhlinu, jeden povrchový defekt (napr. vydrolenie alebo odlupovanie) a jasné značenie povrchu. Tento jediný obraz:

• Precvičuje fázu príjmu obrazu – dekódovanie, farebnú korekciu, georeferencovanie
• Precvičuje model detekcie trhlín – prítomná aspoň jedna trhlina
• Precvičuje model klasifikácie defektov – prítomný aspoň jeden defekt
• Precvičuje fázu mapovania prieskumu – priradenie geopriestorových súradníc
• Precvičuje fázu vizualizácie – vykresľovanie prekrytí s anotáciami
• Precvičuje fázu hodnotenia – výpočet PCI alebo hodnotenie stavu

Očakávaný čas spracovania tohto jediného obrazu celým pipeline je menej ako 30 sekúnd na CI hardvéri, čo ponecháva rezervu pre zvyšné dymové testy v sade. Testovací obraz je uložený v repozitári pod tests/data/smoke/ a je verzovaný prostredníctvom Git LFS.

Dymové testy TarmacView

Inšpekčný pipeline TarmacView je overovaný sadou špecializovaných skriptov dymových testov, pričom každý pokrýva špecifickú fázu pipeline. Tieto skripty sa nachádzajú v adresári scripts/ a dodržiavajú konvenciu pomenovania smoke_<fáza>.py. Každý skript je navrhnutý tak, aby bol spustiteľný samostatne (pre vývojové ladenie) aj ako súčasť CI sady (pre automatizované bránenie).

{{

smoke_analyze.py

Tento skript overuje fázu analýzy obrazu. Načíta jeden reprezentatívny ortofoto pás, spustí celý analytický pipeline cez modul spracovania obrazu a overuje:

• Obraz je načítaný a dekódovaný bez chýb z formátu TIFF
• Farebná korekcia a rádiometrická normalizácia sú dokončené, konvertujúc surové hodnoty senzora na odrazivosť
• Georeferenčné metadáta sú spracované a aplikované vrátane informácií o UTM zóne a dátume
• Spracovaný obraz má očakávané rozmery (1024x768 pixelov) a dátový typ (float32)
• Výstupný analytický súbor je zapísaný na očakávanú cestu v adresári analytických výstupov
• Minimálne a maximálne hodnoty pixelov spadajú do platných rádiometrických rozsahov

Skript prijíma argument --input ukazujúci na testovací obraz a argument --output-dir určujúci, kam má pipeline zapisovať výsledky. Ak pipeline zlyhá počas ktoréhokoľvek kroku spracovania, výnimka je zachytená a test vráti štruktúrovanú správu o zlyhaní.

smoke_assess.py

Tento skript overuje fázu hodnotenia stavu vozovky. Zoberie výstup analytickej fázy (alebo vopred vygenerovaný analytický súbor uložený v správe verzií), spustí algoritmus hodnotenia stavu a overuje:

• Hodnotiaca funkcia sa vykoná bez chýb na vstupných dátach
• Indexy stavu (PCI alebo ekvivalent) sú vypočítané
• Výstupný hodnotiaci súbor obsahuje očakávané stĺpce: pavement_id, condition_index, severity, extent, date_assessed
• Hodnotenia spadajú do platného numerického rozsahu (0–100 pre PCI, kde 0 je zlyhané a 100 je perfektné)
• Výstupný súbor je zapísaný ako Parquet súbor s očakávanou schémou

Algoritmus hodnotenia v TarmacView nasleduje normu ASTM D5340 pre výpočet PCI na letiskách, prispôsobený pre automatizovanú obrazovú inšpekciu. Dymový test neoveruje, že hodnoty PCI sú numericky správne – overuje iba to, že výpočet prebehne, produkuje výsledky v očakávanom formáte a zapíše ich na disk.

smoke_crack.py

Tento skript overuje fázu detekcie trhlín. Spustí model detekcie trhlín na testovacom obraze, o ktorom je známe, že obsahuje trhliny, a overuje:

• Model sa úspešne načíta z uloženého súboru váh a produkuje inferenciu bez chýb
• Runtime PyTorch alebo TensorFlow sa inicializuje správne vrátane inicializácie CUDA/GPU, ak je k dispozícii
• Výstupná maska trhlín má rovnaké rozmery ako vstupný obraz (1024x768)
• Je detekovaný aspoň jeden pixel trhliny, čo potvrdzuje, že testovací obraz obsahuje známe trhliny a model je responzívny
• Súbor vlastností trhlín obsahuje stĺpce: crack_id, length_px, width_px, orientation, confidence, classification
• Výstupné súbory sú zapísané na očakávané cesty v adresári výstupov trhlín

Model detekcie trhlín používaný TarmacView je architektúra U-Net s chrbtovou sieťou ResNet-50 trénovaný na označených obrázkoch povrchov z viacerých letísk. Vstupný obraz dymového testu bol špecificky vybraný z validačnej množiny, čo znamená, že obsahuje trhliny, ktoré model videl počas trénovania, ale nie počas vyhodnocovania testovacej množiny.

smoke_defect.py

Tento skript overuje fázu klasifikácie povrchových defektov. Spustí klasifikátor defektov na testovacom obraze obsahujúcom známe defekty (vydrolenie, odlupovanie, vysprávky, zvetrávanie) a overuje:

• Klasifikátor sa načíta a produkuje predikcie bez chýb
• Výstupná klasifikačná mapa zodpovedá rozmerom vstupného obrazu
• Je predikovaná aspoň jedna trieda defektu, čo potvrdzuje prítomnosť známych defektov vo vstupe
• Inventárny súbor defektov obsahuje stĺpce: defect_id, defect_type, area_px, severity, confidence, timestamp
• Výstupný geopriestorový súbor obsahuje platné súradnice v očakávanom CRS (súradnicový referenčný systém)
• Počty polygónov defektov sú primerané (nie nulové a nie podozrivo vysoké)

Klasifikátor defektov používa architektúru Mask R-CNN, ktorá produkuje segmentačné masky inštancií pre každý detekovaný defekt. Dymový test kontroluje, že výstupná maska má správne rozmery a že inventárny súbor obsahuje očakávané stĺpce schémy. Nekontroluje, či sú klasifikácie defektov správne – to vyžaduje samostatnú validačnú sadu s označenými údajmi základnej pravdy.

smoke_survey.py

Tento skript overuje fázu mapovania prieskumu. Zoberie dáta o trhlinách a defektoch produkované predchádzajúcimi fázami, spustí modul geopriestorového mapovania prieskumu a overuje:

• Priradenie geopriestorových súradníc je dokončené bez chýb, konvertujúc pixelové súradnice na súradnice reálneho sveta
• Výstupný súbor prieskumu obsahuje platné stĺpce zemepisnej šírky a dĺžky s hodnotami v rámci očakávaných geografických hraníc
• Priestorové vzťahy medzi detekovanými vlastnosťami sú zachované (trhliny, ktoré sú susedné v pixelovom priestore, zostávajú susedné v geografickom priestore)
• Výstupný súbor prieskumu obsahuje očakávané projekčné metadáta vrátane EPSG kódu
• Súbor je zapísaný v požadovanom výstupnom formáte (GeoJSON alebo Shapefile)
• Typy geometrií sú správne (LineString pre trhliny, Polygon pre defekty, Point pre prieskumné značky)

Modul mapovania prieskumu používa georeferenčné metadáta ortofoto na vykonanie projektívnej transformácie z pixelových súradníc na geografické súradnice. Dymový test overuje, že táto transformácia produkuje platné geografické súradnice v rámci očakávaného ohraničujúceho boxu pre testovací obraz. Fotografia miesta testovacieho obrazu nasnímaná na letisku poskytuje vizuálny krížový odkaz pre analýzu zlyhaní.

smoke_seg_head.py (Fáza vizualizácie)

Tento skript overuje fázu vizualizácie a segmentačnej hlavy – záverečnú fázu pipeline, ktorá produkuje čitateľný výstup. Zoberie spracované výstupy pipeline, spustí vykresľovač vizualizácie a overuje:

• Prekryvné obrazy sa vykreslia bez chýb, kombinujúc masky trhlín, polygóny defektov a hodnotiace skóre na základné ortofoto
• Výstupná vizualizácia zodpovedá vstupným rozmerom a farebnému priestoru
• Prvky legendy a anotácií sú prítomné vrátane mierky, severky a farebne odlíšenej legendy závažnosti
• Generovanie správy je úspešne dokončené, produkujúc HTML alebo PDF sumár
• Konečné výstupné súbory sú zapísané na očakávané cesty so správnymi príponami (.png pre obrazy, .html alebo .pdf pre správy)
• Veľkosti súborov sú nenulové a v rámci očakávaných rozsahov

Fáza vizualizácie je často prvým miestom, kde sa kumulatívne chyby pipeline stanú viditeľnými. Fáza detekcie trhlín, ktorá produkuje masku v nesprávnom súradnicovom priestore, vygeneruje vizualizáciu, kde sú prekryvy trhlín posunuté voči základnému obrazu. Dymový test to detekuje nepriamo, ak vykresľovanie zlyhá, ale je to vizuálny regresný test – nie dymový test – ktorý zachytáva regresie vizuálnej kvality.

Orchestrácia testov a formát výsledkov

Tieto dymové testy sú navrhnuté tak, aby bežali v poradí, ale môžu sa vykonávať aj nezávisle, ak sú výstupy predchádzajúcich fáz uložené do vyrovnávacej pamäte. Celá sada je dokončená za menej ako 3 minúty na CI hardvéri. Každý test vypíše štruktúrovanú JSON správu s poľami:

Spúšťač testov agreguje jednotlivé JSON správy do súhrnu sady, ktorý je zverejnený na CI dashboarde a voliteľne odoslaný na Slack alebo e-mail pre okamžité upozornenie.

Čo dymové testy overujú

Dymové testy sú zámerne úzke v tom, čo tvrdia. Overujú tri kategórie podmienok a nič viac. Tento úzky rozsah je zámerný – udržiava testy rýchle, deterministické a ľahko udržiavateľné.

1. Pipeline prebehne do konca

Najzákladnejšie tvrdenie: vykoná sa kód bez vyvolania neošetrenej výnimky? Toto zahŕňa:

• Reťazce importov sa vyriešia správne – všetky importy Python modulov sú úspešné, tranzitívne závislosti sú nainštalované, neexistujú konflikty verzií
• Konfiguračné súbory sa parsujú bez chýb – YAML, JSON alebo TOML konfiguračné súbory sú syntakticky platné a obsahujú očakávané kľúče
• Externé závislosti sú dostupné – súbory s váhami modelov sú prítomné na očakávaných cestách, databázové pripojenia sú úspešné, API endpointy sú dosiahnuteľné
• Hardvérové akcelerátory sú k dispozícii – GPU je prítomné a CUDA sa inicializuje správne, ak pipeline vyžaduje GPU inferenciu
• Cesty súborového systému existujú a sú zapisovateľné – výstupné adresáre sú vytvorené a majú správne oprávnenia na zápis
• Pamäťové limity nie sú prekročené – pipeline spracuje testovací vstup bez spustenia chýb nedostatku pamäte

Pipeline, ktorý zlyhá pri štarte alebo počas vykonávania, okamžite zlyhá v dymovom teste. Dôvod zlyhania je zachytený z trasovania výnimky, čo poskytuje vývojárom priamy ukazovateľ na miesto zlyhania v kóde.

2. Výstupné súbory existujú

Po dokončení vykonávania dymový test skontroluje, že výstupné súbory existujú na očakávaných cestách. Toto zahŕňa:

• Hlavné výstupné súbory sú prítomné – výsledky, správy, spracované obrazy, výstupy modelov
• Medzisúbory sú prítomné – ak zmluva pipeline špecifikuje, že medzivýstupy musia byť perzistentné, dymový test ich skontroluje
• Veľkosti súborov sú nenulové – výstupný súbor s nulovou veľkosťou indikuje, že fáza neprodukovala žiadne dáta, čo je zlyhanie
• Signatúry formátov súborov sú platné – hlavička súboru zodpovedá očakávanému formátu (napr. platné PNG magické byty, platná GeoJSON štruktúra, platné Parquet magické byty)

Pipeline, ktorý tvrdí, že je dokončený, ale neprodukuje žiadne výstupné súbory, zlyhá v dymovom teste. To zachytáva tiché zlyhania, kde pipeline skončí čisto, ale preskočí kritické operácie zápisu kvôli nesprávne nakonfigurovaným výstupným cestám alebo podmienenej logike, ktorá sa neočakávane vyhodnotí ako nepravdivá.

3. Kľúčové stĺpce sú prítomné v tabuľkovom výstupe

Pre akýkoľvek tabuľkový výstup (CSV, Parquet, GeoJSON feature collection) dymový test overuje, že očakávané stĺpce existujú podľa názvu. Toto je kontrola štrukturálnej integrity – schéma stĺpcov musí zodpovedať tomu, čo očakávajú downstream spotrebitelia.

Test používa kontrolu existencie stĺpcov (nie kontrolu typu, nie kontrolu rozsahu hodnôt). Toto je zámerné – existencia stĺpcov je minimálna záruka štrukturálnej integrity. Kontroly typu a rozsahu patria do integračných a validačných testov, kde sú náklady na ich spustenie odôvodnené hĺbkou informácií, ktoré poskytujú.

4. Kompatibilita formátu dát

Štvrtá kategória overovania, ktorú dymové testy vykonávajú – často prehliadaná – je kompatibilita formátu dát. Dymový test overuje, že výstupné súbory môžu byť prečítané späť očakávanými downstream spotrebiteľmi. Pre TarmacView to znamená:

• Parquet súbory môžu byť čítané knižnicou Pandas bez chýb schémy
• GeoJSON súbory môžu byť parsované knižnicami shapely a geopandas
• GeoTIFF súbory môžu byť otvorené knižnicou rasterio so správnymi CRS metadátami
• JSON správy môžu byť deserializované bez syntaktických chýb
• CSV súbory majú konzistentné počty riadkov naprieč stĺpcami

Toto zachytáva nezrovnalosti verzií formátov – napríklad ak je knižnica Parquet aktualizovaná a zmení svoje kódovanie, alebo ak sa špecifikácia GeoJSON vyvíja a výstup pipeline už viac nevyhovuje.

Čo dymové testy NEOVERUJÚ

Rovnako dôležité je pochopiť, čo dymové testy zámerne vylučujú. Nesprávne pochopenie tohto vedie k falošnej dôvere v správnosť pipeline – úspešný dymový test neznamená, že pipeline je správny, len že nie je katastrofálne rozbitý.

Numerická presnosť

Dymové testy neoverujú, že vypočítané hodnoty sú správne. Výpočet dĺžky trhliny, ktorý vráti 47,2 pixelov namiesto správnych 42,1 pixelov, prejde dymovým testom, pokiaľ stĺpec length_px existuje a obsahuje float. Validácia presnosti patrí do jednotkových testov, kde je správna hodnota pevne zakódovaná, a integračných testov, kde sú výsledky porovnávané s manuálnymi meraniami certifikovaných inšpektorov.

Pre letiskové inšpekčné pipeline pracujúce podľa ICAO Annex 14 je numerická presnosť kritická, pretože hodnotenia stavu priamo ovplyvňujú priority údržby a alokáciu rozpočtu. Pipeline, ktorý prejde dymovými testami, ale produkuje nepresné PCI skóre, by mohol viesť k nesprávnym rozhodnutiam o údržbe. Preto sú dymové testy len prvou bránou – musia nasledovať validačné testy zamerané na presnosť.

Okrajové prípady

Dymové testy používajú reprezentatívne, ale neadverzárne vstupy. Netestujú:

• Prázdne obrazy – úplne čierne alebo biele obrazy, ktoré neobsahujú žiadne vlastnosti
• Poškodené súbory – skrátené TIFF hlavičky, chýbajúce EXIF dáta, súbory s nulovou veľkosťou
• Extrémne svetelné podmienky – preexponované alebo podexponované obrazy, zatienené obrazy, nočné zábery
• Obrazy presahujúce očakávané rozlíšenie – 100-megapixelové obrazy alebo miniatúry pod 100 pixelov
• Chýbajúce metadáta – obrazy bez georeferencovania, bez EXIF GPS, bez kalibračných dát kamery
• Sieťové time-outy – API volania, ktoré visia alebo vracajú 503 chyby
• Súbežný prístup – viacero inštancií pipeline zapisujúcich do rovnakého výstupného adresára

Spracovanie okrajových prípadov je overované špecializovanými testami okrajových prípadov, ktoré sa špecificky zameriavajú na každú hraničnú podmienku. Tieto testy sú drahšie na spustenie a typicky sa vykonávajú denne, nie pri každom commite.

Výkonnostné charakteristiky

Dymové testy overujú, že pipeline dokončí, nie že dokončí v rámci výkonnostného rozpočtu. Pipeline, ktorý trvá 10 sekúnd na obraz v dymových testoch, ale očakáva sa, že spracuje 100 obrazov za sekundu v produkcii, prejde dymovými testami bez problémov. Validácia výkonu vyžaduje špecializované benchmarkové testy s produkčnými dátami a časovými tvrdeniami.

Pre letiskové inšpekčné pipeline je výkon kritický, pretože letiská spracúvajú stovky obrazov povrchu na jeden prieskum. 10-násobná regresia výkonu by mohla stále prejsť dymovými testami na jednom obraze, ale urobila by plné prieskumy nerealizovateľnými. Výkonnostné benchmarky s časovými prahmi sú vhodným nástrojom na detekciu takýchto regresií.

Regresia v nekritických vlastnostiach

Dymové testy pokrývajú len hlavnú cestu vykonávania. Vlastnosti, ktoré nie sú na kritickej ceste – alternatívne výstupné formáty, voliteľné logovanie, telemetria, audítorské stopy, experimentálne exportné funkcie – nie sú pokryté. Regresie v týchto oblastiach musia byť zachytené regresnými testovacími sadami, ktoré sa špecificky zameriavajú na nekritickú funkcionalitu.

Kvalita dát

Dymové testy neoverujú, že dátové hodnoty sú vnútorne konzistentné. Napríklad dymový test kontroluje, že stĺpec crack_id existuje, ale neoveruje, že všetky hodnoty crack_id sú jedinečné, nenulové alebo v rámci očakávaných rozsahov. Validácia kvality dát vyžaduje špecializované testy kvality dát používajúce rámce ako Great Expectations alebo Pandera, ktoré definujú dátové kontrakty a validujú datasety voči nim.

Dymové testy v CI/CD

Dymové testy prinášajú maximálnu hodnotu, keď sú integrované do pipeline kontinuálnej integrácie a kontinuálneho nasadzovania (CI/CD). Ich umiestnenie v pracovnom toku pipeline určuje ich efektívnosť ako kvalitatívnej brány.

{{

Umiestnenie v pipeline

V typickom CI/CD pracovnom toku sa dymové testy vykonávajú v fáze overenia zostavy ihneď po kompilácii a pred akoukoľvek inou testovacou sadou:

Commit kódu → Zostava → Lint → Jednotkové testy → Dymové testy → Integračné testy → Validačné testy → Nasadenie

Presné poradie závisí od testovacej stratégie projektu. Niektoré organizácie spúšťajú jednotkové testy pred dymovými testami, argumentujúc, že jednotkové testy sú rýchlejšie a zachytávajú logické chyby. Iné spúšťajú dymové testy ako prvé, argumentujúc, že pipeline, ktorý zlyhá pri základnom vykonávaní, by mal byť odmietnutý bez plytvania časom na jednotkové testy. Pipeline TarmacView spúšťa jednotkové testy a dymové testy paralelne po úspešnej zostave, pretože pokrývajú nezávislé režimy zlyhania a nemajú vzájomné závislosti.

Toto umiestnenie zaisťuje, že ak zostava produkuje pipeline, ktorý zlyhá pri základnom vykonávaní, nie je spotrebovaná žiadna ďalšia testovacia infraštruktúra. Spätnoväzbová slučka sa meria v minútach nie hodinách. Vývojár, ktorý pushne commit, ktorý rozbije reťazec importov, dostane notifikáciu o zlyhaní CI do 2–3 minút, namiesto čakania 4 hodín, kým zlyhá integračná testovacia sada.

Logika brány

CI/CD pipeline používa tvrdú bránu: ak niektorý dymový test zlyhá, pipeline sa zastaví a nepokračuje do ďalších fáz. Zostava je označená ako zlyhaná a vývojári sú upozornení správou o zlyhaní dymového testu. V predvolenej konfigurácii nie je povolené žiadne manuálne prepísanie – úspešná sada dymových testov je nevyhnutnou podmienkou pre nasadenie.

Táto logika brány zabraňuje nasledujúcim scenárom:

• Tím spúšťa integračné testy 4 hodiny, len aby zistil, že pipeline zlyháva pri načítaní dát – plytvanie výpočtami a blokovanie iných zostáv
• Kandidát na vydanie je nasadený do stagingu, kde bola schéma databázy ticho zmenená počas konfigurácie nasadenia
• Produkčné nasadenie zlyhá kvôli chýbajúcemu importu alebo ceste k súboru, ktorá bola zavedená v poslednom commite

Bránová logika je implementovaná v konfigurácii CI platformy. Pre CircleCI to znamená konfiguráciu pracovných tokov tak, že úloha smoke-test beží pred integration-test a deploy. Pre GitHub Actions to znamená použitie kľúčového slova needs: na vynútenie poradia úloh.

Paralelné vykonávanie a súbežnosť

Dymové testy v rámci sady môžu bežať paralelne, ak testujú nezávislé fázy pipeline. Sada dymových testov TarmacView používa paralelizmus tam, kde je to možné:

• smoke_crack.py a smoke_defect.py nemajú vzájomné závislosti a môžu byť vykonávané súbežne, čo znižuje celkový čas sady o 40%
• smoke_analyze.py musí byť dokončený pred smoke_assess.py, pretože hodnotenie spotrebúva výstup analýzy
• smoke_survey.py závisí od výstupov trhlín a defektov
• smoke_seg_head.py závisí od všetkých výstupov predchádzajúcich fáz

Stratégia paralelného vykonávania je nakonfigurovaná v YAML CI pipeline pomocou paralelizmu na úrovni úloh. Každá úloha beží vo vlastnom kontajneri s izolovanými závislosťami, čo zabraňuje konkurencii o zdroje.

Reportovanie a notifikácie

Integrácia CI/CD zahŕňa automatizované reportovanie s viacerými kanálmi:

• Stav Úspech/Neúspech na CI dashboarde s farebne odlíšenými indikátormi (zelená pre úspech, červená pre neúspech)
• Trvanie sledované na test pre trendovú analýzu – postupný nárast trvania dymového testu môže indikovať regresiu výkonu
• Logy zlyhania zachytené ako CI artefakty na preskúmanie vývojárom s úplnými trasovaniami zásobníka
• Slack alebo e-mailové notifikácie pri zlyhaní testu s odkazmi na logy a problematický commit
• Trendové grafy zobrazujúce mieru úspešnosti v čase s cieľom >99% na hlavnej vetve
• Detekcia nestabilných testov – test, ktorý alternuje medzi úspechom a neúspechom na rovnakom commite, je označený na vyšetrenie

Príklad konfigurácie 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: "Paralelné dymové testy"
          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]

Písanie dymových testov

Písanie efektívnych dymových testov si vyžaduje disciplínu. Test musí byť rýchly, spoľahlivý a zameraný len na to, čo je navrhnutý detekovať. Každý dymový test nasleduje rovnaký základný vzor: spustiť fázu pipeline, skontrolovať existenciu výstupu, overiť minimálnu správnosť schémy, nahlásiť úspech/neúspech v štruktúrovanom JSON.

Štruktúra dymového testu

# smoke_crack.py — zjednodušený vzor
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: Získať verziu pipeline
        from tarmacview import __version__
        result["pipeline_version"] = __version__

        # Krok 2: Spustiť fázu pipeline s reálnymi importami
        from tarmacview.pipeline.crack import detect_cracks
        output = detect_cracks(input_path, output_dir)

        # Krok 3: Overiť, že výstupný súbor existuje a nie je prázdny
        output_path = Path(output["crack_mask_path"])
        assert output_path.exists(), f"Výstupný súbor nenájdený: {output_path}"
        assert output_path.stat().st_size > 0, f"Výstupný súbor je prázdny: {output_path}"
        result["output_files"].append(str(output_path))

        # Krok 4: Overiť kľúčové stĺpce v tabuľkovom výstupe
        if output.get("crack_inventory_path"):
            inv_path = Path(output["crack_inventory_path"])
            assert inv_path.exists(), f"Inventárny súbor nenájdený: {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"Chýbajúci požadovaný stĺpec: {col}"
            result["output_files"].append(str(inv_path))

        # Krok 5: Overiť, že rozmery výstupnej masky zodpovedajú vstupu
        from PIL import Image
        input_img = Image.open(input_path)
        mask_img = Image.open(output_path)
        assert input_img.size == mask_img.size, \
            f"Rozmery masky {mask_img.size} nezodpovedajú vstupu {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)

Pravidlá návrhu

1. Jedno tvrdenie na kategóriu. Tvrdiť, že vykonávanie je dokončené. Tvrdiť, že výstup existuje. Tvrdiť, že stĺpce existujú. Netvrdiť numerické rozsahy, presné veľkosti súborov alebo metriky kvality dát. Každé ďalšie tvrdenie zvyšuje náklady na údržbu testu a znižuje jeho spoľahlivosť.

2. Používať reálne importy. Nemockovať moduly pipeline. Dymový test musí precvičiť skutočný reťazec importov, aby zachytil chyby importov a chýbajúce závislosti. Dymový test, ktorý používa unittest.mock na potlačenie chýb importov, marí vlastný účel.

3. Minimálne nastavenie a upratanie. Test by nemal vyžadovať žiadne nastavenie databázy, žiadne spúšťanie služieb, žiadnu externú konfiguráciu okrem testovacieho vstupného súboru. Ak je nastavenie potrebné, malo by byť súčasťou definície CI úlohy, nie testovacieho skriptu. Každý dymový test by mal byť spustiteľný na vývojárskom notebooku jediným príkazom.

4. Deterministický. Rovnaký vstup musí vždy produkovať rovnaký výsledok úspechu/neúspechu. Náhodné semená musia byť fixované v konfigurácii pipeline. Testovacie vstupné súbory musia byť verzované. Nedeterministické dymové testy sú horšie ako zbytočné – narúšajú dôveru v celú testovaciu infraštruktúru.

5. Sebaobsiahnutý štruktúrovaný výstup. Test by mal po dokončení vypísať štruktúrovaný JSON výstup, čo uľahčuje CI systémom parsovať výsledky bez vlastného parsovania logov. JSON schéma by mala byť konzistentná naprieč všetkými dymovými testami v sade.

6. Rýchly. Každý test musí byť dokončený do 60 sekúnd na CI hardvéri. Ak test konzistentne presahuje tento limit, optimalizujte test pred pridaním do sady. Dymový test, ktorý trvá 5 minút, bude preskakovaný vývojármi spúšťajúcimi testy lokálne.

Bežné nástrahy, ktorým sa vyhnúť

• Testovanie príliš veľa. Pridávanie tvrdení o presnosti alebo kontrol rozsahu hodnôt mení dymový test na integračný test. Udržujte ho plytký. Test by mal trvať menej ako 60 sekúnd na napísanie a menej ako 60 sekúnd na vykonanie.
• Ignorovanie chýb importov. Dymový test, ktorý zachytáva všetky výnimky široko pomocou všeobecného except Exception, môže prehliadnuť zlyhania importov. Nechajte niektoré výnimky propagovať alebo aspoň logujte chyby importov samostatne.
• Používanie produkčných dát. Produkčné dáta sú veľké, nekontrolované a môžu obsahovať citlivé informácie vrátane letiskových bezpečnostných zón a chránených snímok. Používajte fixný malý syntetický alebo starostlivo vybraný vstup.
• Meniteľné testovacie vstupy. Testovacie vstupy uložené na sieťových diskoch alebo v cloudovom úložisku sa môžu meniť bez správy verzií. Vždy verzujte testovacie vstupy v repozitári alebo prostredníctvom Git LFS.
• Predpokladanie dostupnosti GPU. Ak pipeline vyžaduje GPU pre inferenciu, dymový test by mal elegantne spracovať absenciu GPU buď preskočením testu závislého od GPU, alebo spustením na CPU zálohe.
• Pevne zakódované cesty k súborom. Nikdy pevne nekódujte absolútne cesty k súborom v dymových testoch. Používajte relatívne cesty a argument --output-dir, aby ste umožnili flexibilné prostredia vykonávania.

Interpretácia zlyhaní dymových testov

Keď dymový test zlyhá, vývojový pracovný tok sa musí presunúť z „vývoja" na „diagnostiku a opravu". Efektívna interpretácia zlyhaní nasleduje štruktúrovaný prístup, ktorý mapuje symptómy zlyhania na pravdepodobné koreňové príčiny.

Kategórie zlyhaní

Pracovný postup reakcie na zlyhanie

Keď dymový test zlyhá v CI, odporúčaný pracovný postup reakcie je:

1. Skontrolovať správu o zlyhaní. Štruktúrovaný JSON výstup z dymového testu obsahuje pole failure_reason, ktoré obsahuje typ výnimky a správu. Toto je najrýchlejšia cesta k pochopeniu toho, čo sa pokazilo.

2. Identifikovať, či je zlyhanie regresiou kódu alebo problémom infraštruktúry. ModuleNotFoundError na balíku, ktorý bol nainštalovaný včera, naznačuje regresiu. Timeout, ktorý sa objavuje na všetkých zostavách súčasne, naznačuje problém infraštruktúry (výpadok siete, degradácia CI bežca).

3. Vrátiť späť, ak koreňová príčina nie je zrejmá do 15 minút. Sada dymových testov je rýchla špecificky preto, aby umožnila rýchle vrátenie. Zostava, ktorá zlyhá v dymových testoch, by mala byť okamžite vrátená späť, aby sa odblokoval CI pipeline pre ostatných vývojárov.

4. Vyšetriť s testovacím vstupom. Spustiť zlyhávajúci dymový test lokálne s rovnakým verzovaným testovacím vstupom. Reprodukovanie zlyhania lokálne eliminuje CI-špecifické premenné (rozdiely v kontajneroch, limity zdrojov, problémy s paralelizmom).

5. Opraviť a pridať jednotkový test. Po identifikácii koreňovej príčiny opraviť kód a pridať jednotkový test na primeranej úrovni, ktorý by zlyhanie zachytil. Toto zabraňuje opakovaniu rovnakej triedy regresie.

6. Overiť, že oprava prejde dymovými testami. Spustiť celú sadu dymových testov lokálne pred pushnutím opravy. To zaisťuje, že oprava nezavádza nové zlyhania v iných fázach pipeline.

Falošné pozitíva a nestabilné testy

Dymové testy môžu produkovať falošné pozitíva – test zlyhá, ale pipeline je v skutočnosti funkčný. Bežné príčiny zahŕňajú:

• Konkurencia o zdroje v CI – viacero zostáv bežiacich súčasne vyčerpáva pamäť alebo miesto na disku
• Testy závislé od siete – testy, ktoré kontaktujú externé API alebo sťahujú váhy modelov zo vzdialeného úložiska
• Testy závislé od načasovania – testy, ktoré predpokladajú, že určité operácie sa dokončia v rámci špecifického časového okna
• Preteky súborového systému – paralelné testy zapisujúce do prekrývajúcich sa výstupných adresárov

Nestabilné dymové testy narúšajú dôveru v testovaciu infraštruktúru. Vývojári, ktorí vidia, že dymové testy zlyhávajú náhodne, začnú ignorovať zlyhania. Riešením je agresívne odstraňovanie nestability: identifikovať koreňovú príčinu nestability a spevniť test. Ak test nemožno urobiť spoľahlivým s primeraným úsilím, mal by byť presunutý do testovacej sady s nižšou prioritou alebo nahradený robustnejším návrhom.

Dymové testy v kontexte letiskového softvéru

Pre letiskový softvér vrátane letiskových inšpekčných pipeline majú dymové testy dodatočný význam kvôli bezpečnostne kritickej povahe domény. Podľa DO-178C (Softvérové aspekty v certifikácii palubných systémov a zariadení) nasleduje verifikácia softvéru rigorózny proces založený na požiadavkách. Hoci DO-178C výslovne nenazýva „dymové testovanie", koncept Hardvérovo/softvéroveho integračného testovania definovaný v časti 6.4.3 vyžaduje, aby integrovaný systém „nabootoval a základné funkcie fungovali" – funkčný ekvivalent dymového testu.

Podľa ICAO Annex 14, zväzok I – Návrh a prevádzka letísk – stav letiskových povrchov priamo ovplyvňuje bezpečnosť lietadiel. Zlyhanie povrchu na dráhe môže spôsobiť poškodenie lietadla alebo stratu kontroly počas vzletu a pristátia. Softvér používaný na automatizovanú inšpekciu povrchov musí preto spĺňať normy spoľahlivosti zodpovedajúce bezpečnostným dôsledkom svojho výstupu. Dymové testy poskytujú prvú líniu obrany proti chybám softvéru, ktoré by mohli ohroziť hodnotenia stavu povrchov.

Pre TarmacView sú dymové testy súčasťou širšieho rámca zabezpečenia kvality softvéru, ktorý zahŕňa:

• Sledovateľnosť požiadaviek – každá vlastnosť pipeline je prepojená s dokumentovanou požiadavkou
• Pokrytie jednotkovými testami – >90% pokrytie riadkov pre základné algoritmy
• Pokrytie dymovými testami – 100% fáz pipeline pokrytých dymovými testami
• Pokrytie integračnými testami – každá hranica komponentu testovaná s reálnymi dátami
• Validačné testy – výsledky pipeline porovnávané s manuálnou inšpekciou certifikovanými letiskovými inšpektormi
• Výkonnostné benchmarky – priepustnosť a latencia sledované na vydanie

Tento viacvrstvový prístup zaisťuje, že dymové testy slúžia ako prvá brána bez toho, aby boli jedinou bránou. Úspešný dymový test znamená, že pipeline je štrukturálne v poriadku. Ale sú to integračné testy, validačné testy a výkonnostné benchmarky, ktoré poskytujú dôveru potrebnú na používanie výstupov TarmacView pre skutočné rozhodnutia o údržbe letísk.

Záver

Dymové testovanie je základná softvérová kvalitatívna prax, ktorá prináša nadmerne veľkú hodnotu v pomere k svojim implementačným nákladom. Pre inšpekčné softvérové pipeline ako TarmacView zachytávajú dymové testy integračné zlyhania – rozbité importy, chýbajúce súbory, nezrovnalosti schém – v sekundách namiesto hodín. Slúžia ako prvá brána v CI/CD, odmietajúc nestabilné zostavy skôr, než spotrebujú testovaciu infraštruktúru. Sada dymových testov TarmacView pokrýva každú fázu pipeline od príjmu obrazu cez detekciu trhlín, klasifikáciu defektov, hodnotenie povrchu, mapovanie prieskumu až po vizualizáciu, pričom každý test overuje, že fáza beží, produkuje výstup a udržiava očakávané schémy stĺpcov.

Kľúčom k efektívnemu dymovému testovaniu je pochopenie jeho úzkeho rozsahu. Dymové testy overujú, že pipeline beží a produkuje výstup. Neoverujú presnosť, výkon, spracovanie okrajových prípadov ani kvalitu dát. Tieto aspekty sú overované inými typmi testov v širšom rámci zabezpečenia kvality. Keď sú dymové testy navrhnuté s touto disciplínou – reprezentatívne minimálne vstupy, rýchle časy vykonávania, široké ale plytké pokrytie – poskytujú rýchlu a spoľahlivú detekciu zlyhaní, ktorá robí CI/CD pipeline efektívnymi pre bezpečnostne kritický letiskový softvér.