Füstteszt

{{

Definíció és Cél

A füstteszt egy könnyű súlyú automatizált ellenőrzési eljárás, amely egy szoftverpipeline-t futtat végpontok között reprezentatív vagy minimális bemeneti adatokon, hogy megerősítse: a pipeline összeomlás nélkül fut le, és a kimeneti fájlok az elvárt szerkezettel rendelkeznek. A teszt bináris sikeres/sikertelen kiértékelést végez – ha bármely lépés kezeletlen kivételt dob, nem produkál kimenetet, vagy a kimenetből hiányoznak kritikus oszlopok, a teszt megbukik, és a build azonnal elutasításra kerül.

A kifejezés a hardvermérnökségből származik, ahol a metafora szó szerinti. Amikor a mérnökök első alkalommal kapcsoltak be egy újonnan összeszerelt áramköri lapot, figyelték, hogy száll-e ki füst a kiégett alkatrészekből. Ha füst jelent meg, a lap katasztrofális meghibásodást szenvedett, és minden további tesztelés leállt. A hibás lapot vagy megjavították, vagy kidobták, mielőtt bárki időt fektetett volna a részletes diagnosztikába. A szoftveres füsttesztelés ugyanezt az elvet alkalmazza: futtasd a kódot, és ellenőrizd a “füstöt” – összeomlások, el nem kapott kivételek, hiányzó kimenetek – mielőtt időt fektetnél a részletes validációba.

A felügyeleti szoftver-pipeline-ok kontextusában a füstteszt azt validálja, hogy a feldolgozási lánc minden szakasza képes-e reprezentatív adatokon végrehajtódni. A TarmacView esetében ez egy kis kifutópálya- vagy burkolatkép átfuttatását jelenti a teljes pipeline-on – a képbeolvasástól a repedésdetektáláson, hibabesoroláson, felületfelmérésen, térképezésen és vizualizáción át – és annak ellenőrzését, hogy minden szakasz hibamentes kimenetet produkál. Ez különösen kritikus a repüléssel kapcsolatos szoftvereknél, ahol a pipeline-hibák késleltethetik a repülőtéri infrastruktúra-felméréseket, amelyek közvetlenül befolyásolják a repülésbiztonságot.

A build-verifikációs teszt (BVT) kifejezést gyakran használják a füstteszt szinonimájaként, a Microsoft a legjelentősebb átvevője ennek a terminológiának. A Microsoft belső fejlesztési folyamatai – különösen a Windows és Office esetében – a füsttesztelést kötelező minőségi kapuként intézményesítették az 1990-es években. Steve McConnell Code Complete című könyve a “napi build és füsttesztet” a legmagasabb szintű iparági bevált gyakorlatként azonosítja a folyamatos integráció érettségének mérésére. A Google Site Reliability Engineering (SRE) keretrendszere a füstteszteket a “rendszertesztelés” kategóriába sorolja – ezek a legegyszerűbb típusok, amelyeket kifejezetten a költséges tesztelési pipeline-ok lerövidítésére használnak.

A füsttesztelés célja háromirányú:

1. Gyors hibafelismerés – katasztrofális hibák észlelése másodperceken belül egy kódváltozás után, mielőtt a költséges teljes pipeline-futtatások felemésztenék a számítási erőforrásokat és a fejlesztők idejét.
2. Kapuzás – instabil build-ek megakadályozása abban, hogy staging vagy éles környezetbe jussanak, ahol pazarlóan használnák a tesztinfrastruktúrát és blokkolnák más csapatok munkáját.
3. Visszacsatolás – azonnali jelzés biztosítása a fejlesztők számára arról, hogy változtatásaik nem törték meg a pipeline alapvető végrehajtását, gyakran a kommitot követő 60 másodpercen belül.

A füsttesztek a tesztelési piramis első szintjét foglalják el, az egységtesztek, integrációs tesztek és végpontok közötti regressziós szettek előtt futnak. Úgy tervezték őket, hogy egy tipikus felügyeleti pipeline esetében 60 másodperc alatt elkészüljenek, ami alkalmassá teszi őket minden egyes kódkommitnál történő futtatásra a CI/CD-ben. Magas tesztelési érettségű szervezetekben a füsttesztek minden push-nál futnak bármely ágon, nem csak a főágon, biztosítva a lehető legkorábbi észlelést az integrációs hibákra.

Történelmi Eredet és Iparági Elfogadás

A füsttesztelés koncepciója évtizedekkel megelőzi a szoftvermérnökséget. A kifejezés első dokumentált használata a vízvezeték- és kályhatesztelésből származik a 19. századból. A kályhagyártók tüzet gyújtottak egy újonnan összeszerelt kályhában, elzárták az összes csappantyút, és figyelték, hogy hol szivárog a füst – ha nem kívánt helyeken tört elő a füst, a kályha gyártási hibával rendelkezett. Ugyanez a logika – “alkalmazz minimális energiát, és figyeld, hol törik el a dolog” – vándorolt át az elektronikai tesztelésbe a 20. század közepén, majd végül a szoftvermérnökségbe az 1980-as és 1990-es években.

A Microsoft széles körben elismerten hozta be a füsttesztelést a mainstream szoftvermérnökségi gyakorlatba. Az 1990-es évek végén a Microsoft Windows és Office divíziói bevezették az úgynevezett Build Verification Testing (BVT) eljárást kötelező kapuzási folyamatként. Minden éjszakai build-nek át kellett esnie egy BVT-szerten, mielőtt a build belső tesztelőkhöz került. Ha a BVT megbukott, a build “eltörtnek” számított, és a felelős fejlesztőt az időponttól függetlenül értesítették. Ez az azonnali elszámoltathatósági kultúra a build minőségéért a Microsoft mérnöki kultúrájának alapkövévé vált, és széles körben dokumentálták az MSDN dokumentációban és a Microsoft Press könyveiben.

A Crosslake Technologies taxonómiája (amely közvetlenül a Microsoft gyakorlatából ered) különbséget tesz a füsttesztek és a BVT-k között. A füstteszteket “felületes – alapvető funkciók működésének biztosítása” jelleggel írják le, percek alatt futnak, és a kritikus funkciókra összpontosítanak. A BVT-ket “a füsttesztek bővített halmazaként” írják le, amelyek “kissé alaposabbak”, de szintén percek alatt futnak, nem órák alatt. Mindkettő ugyanazt a kapuzási funkciót szolgálja, de a BVT-k szélesebb körű kritikus útvonal forgatókönyveket tartalmaznak.

A Google az SRE (Site Reliability Engineering) gyakorlatán keresztül vette át a füsttesztelést. A Google Testing Blog a füsttesztelést ismert, elfogadott gyakorlatként kezeli, inkább arra összpontosítva, hogyan kell súlyozni a füsttesztek eredményeit más tesztelési típusok mellett. A Google mérnöki kultúrája a precizitást hangsúlyozza az egységtesztekben és a súlyozott megbízhatósági pontozást a füstteszt-jellegű széles körű ellenőrzéseknél, a füstteszteket az egységtesztek kiegészítőinek tekintve, nem pedig helyettesítőinek.

A repüléssel kapcsolatos szoftverek területén a füsttesztelés a DO-178C 6.4.3 szakaszában leírt Hardver/Szoftver Integrációs Tesztelési fázisba illeszkedik. Bár a DO-178C nem nevezi kifejezetten “füsttesztelésnek” a fogalmat, a szabvány megköveteli, hogy az integrált rendszer “boot-oljon és az alapvető funkciók működjenek”, mielőtt a mélyebb tesztelés megkezdődik. Ez funkcionálisan azonos a füstteszteléssel. Az ICAO Annex 14 – amely a repülőterek tervezését és üzemeltetését szabályozza – hatálya alá tartozó repülőtéri felügyeleti szoftverek esetében a füsttesztek biztosítják a szoftver megbízhatóságának garanciáját, amely a repülőtéri biztonsági irányítási rendszereket tápláló Burkolatállapot-index (PCI) felmérések támogatásához szükséges.

Füstteszt vs Egységteszt vs Integrációs Teszt

Annak megértése, hogy hol helyezkednek el a füsttesztek a tágabb tesztelési taxonómiában, elengedhetetlen a kiegyensúlyozott minőségbiztosítási stratégia felépítéséhez. A négy fő tesztelési szint egymást kiegészítő, de eltérő szerepet tölt be, mindegyik más-más meghibásodási módot célozva a pipeline-életciklus különböző szakaszaiban.

Egységtesztek azt validálják, hogy az egyes függvények a megadott bemenetekre helyes kimeneteket produkálnak. Minden külső függőséget mock-olnak – adatbázisok, fájlrendszerek, hálózati szolgáltatások, hardvergyorsítók. Egy repedésdetektáló függvény egységtesztje ellenőrizheti, hogy a függvény helyesen azonosítja-e a repedéseket egy szintetikus 10x10 pixeles tömbben ismert repedéspozíciókkal. Az egységtesztek szűkek és mélyek: egyetlen függvény logikáját ellenőrzik kimerítően, lefedve a szélsőséges eseteket, határfeltételeket és hibautakat. Az egységtesztek azonban nem képesek elkapni az integrációs hibákat, mert a függőségek mock-olva vannak – a teszt soha nem gyakoroltatja a tényleges importláncot, konfigurációbetöltést vagy modulok közötti adatáramlást.

Integrációs tesztek azt validálják, hogy két vagy több komponens együtt helyesen működik-e. Valós, de kontrollált példányait használják a függőségeknek. A TarmacView egy integrációs tesztje ellenőrizheti, hogy a képbeolvasási szakasz helyesen adja-e át az adatokat a repedésdetektáló modellnek a várt tenzor formátumban, a megfelelő csatornasorrenddel és normalizációs paraméterekkel. Az integrációs tesztek szűkebbek a pipeline hatókörében, mint a füsttesztek, de mélyebbek az interakciók validálásában: konkrét komponenshatárokra összpontosítanak a teljes pipeline helyett.

Füsttesztek azt validálják, hogy a teljes pipeline összeomlás nélkül végrehajtódik. Minden szakaszt egymás után futtatnak valós, bár kis adatokkal. A füsttesztek szélesek és sekélyek – lefedik a teljes pipeline-t, de csak azt ellenőrzik, hogy a végrehajtás befejeződik és a kimenetek léteznek, nem pedig azt, hogy a numerikus eredmények helyesek-e. Egy repedéshossz-számítás, amely 47,2 képpontot ad vissza a helyes 42,1 helyett, átmegy a füstteszten, amíg a length_px oszlop létezik és lebegőpontos értéket tartalmaz.

Rendszertesztelés (más néven végpontok közötti tesztelés) a teljes rendszert futtatja éles méretű adatokkal egy éleshez hasonló környezetben. Azt ellenőrzik, hogy a rendszer megfelel-e funkcionális és nem funkcionális követelményeinek, beleértve a pontosságot, teljesítményt és megbízhatóságot. A rendszertesztelés a legdrágább futtatni és karbantartani, és csak kiadásjelölteken fut, nem minden kommitnál.

A tesztelési piramisban a füsttesztek alkotják az alapréteget – ezek futnak először, leggyorsabban és leggyakrabban. Ha egy füstteszt megbukik, az adott build-en az egység- és integrációs teszteket kihagyják, vagy megbízhatatlannak jelölik. Ez számítási erőforrásokat és fejlesztői időt takarít meg azáltal, hogy gyorsan jelez a hibáról, amikor a pipeline alapvető végrehajtása hibás.

Füstteszt Tervezés – Reprezentatív Minimális Bemenet

A hatékony füstteszt-tervezés középpontjában a reprezentatív minimális bemenet koncepciója áll – az a legkisebb adathalmaz, amely a pipeline minden szakaszát gyakoroltatja anélkül, hogy adatfüggő szélsőséges eseteket aktiválna. Ez a legfontosabb tervezési döntés egy füstteszt-szert felépítésekor.

A Füstteszt Bemenet Kiválasztásának Elvei

1. elv: Minimális, de nem triviális. A bemenetnek elég nagynak kell lennie ahhoz, hogy áthaladjon a pipeline minden szakaszán anélkül, hogy olyan kódútvonalakat járna be, amelyek megkerülik a valódi feldolgozási logikát. Egy egypixeles kép triviális – átmenne a képbetöltésen, de a feldolgozó algoritmusok degenerált kódútvonalakat járnának be, amelyek soha nem futnak le valós adatokon. Egy 256x256 pixeles kép tényleges kifutópálya-burkolatról minimális, mégis reprezentatív: gyakoroltatja a csempézett feldolgozó algoritmusokat, színnormalizációs rutinokat és modell-kiértékelési útvonalakat anélkül, hogy túlzott számítási időt igényelne.

2. elv: Reprezentatív az éles adatokhoz képest. A bemenetnek ugyanazokkal a fájlformátummal, színmélységgel, metaadat-szerkezettel és statisztikai tulajdonságokkal kell rendelkeznie, mint az éles adatoknak. Ha az éles adatok egy Phase One iXM-RS150F légi kamerából származnak, amely 16 bites TIFF fájlokat rögzít beágyazott EXIF GPS metaadatokkal, a füstteszt bemenetének is ezeket a jellemzőket kell tükröznie. Szintetikus adatok használata, amelyek eltérnek az éles adatoktól, meghiúsítja a füstteszt célját, mert a pipeline-hibák gyakran az éles adatok váratlan tulajdonságaiból erednek – hiányzó EXIF címkék, váratlan színprofilok, nem szabványos GeoTIFF vetületi karakterláncok.

3. elv: Rögzített és verziókezelt. A füstteszt bemeneteket a kóddal együtt verziókezelésbe kell venni bináris fájlként, vagy Git LFS-en (Large File Storage) keresztül kell kezelni. Soha nem változhatnak explicit felülvizsgálat nélkül pull request-eken keresztül. A változó bemenet lehetetlenné teszi a pipeline-regressziók és a tesztadatok változásainak megkülönböztetését – egy füstteszt, amely ma sikeres és holnap sikertelen, jelezhet akár kódregressziót, akár módosított tesztbemenetet. A bemenetek verziókezelése kiküszöböli ezt a kétértelműséget.

4. elv: Gyorsan feldolgozható. A teljes füstteszt-szert végrehajtási ideje nem haladhatja meg a 60 másodpercet egy tipikus pipeline esetében, és a 3 percet összetett több szakaszos pipeline-ok – például felügyeleti szoftverek – esetében. Ez a korlát határozza meg a bemenet méretét. Kép alapú felügyeleti pipeline-okhoz egyetlen 512x512 pixeles kép általában elegendő. Videó-pipeline-okhoz egyetlen képkocka vagy egy 2 másodperces klip. LiDAR pipeline-okhoz egyetlen repülési vonalszakasz, amely 100 méternyi burkolatot fed le.

5. elv: Ismert jellemzőket tartalmaz. A tesztbemenetnek tartalmaznia kell azokat a jellemzőket, amelyeket a pipeline egyes szakaszai detektálni hivatottak. Egy repedésdetektálásra szolgáló füstteszt haszontalan, ha a bemeneti kép nem tartalmaz repedéseket – a pipeline csendben átugorhatná a repedésdetektálást, és így is sikeres lenne. A tesztbemeneteket úgy kell összeválogatni, hogy az egyes detektálható jellemzőkből legalább egy példányt tartalmazzanak ismert alapigazsággal, amelyre a hibaelemzés során hivatkozni lehet.

Füstteszt Bemeneti Példa TarmacView-hoz

A TarmacView felügyeleti pipeline-jához a füstteszt bemenet egyetlen 1024x768 pixeles RGB ortofotó sáv repülőtéri burkolatról, 1 mm-es terepi mintavételezési távolsággal (GSD) rögzítve. A kép legalább egy látható repedést, egy felületi hibát (pl. kátyúsodás vagy kitöredezés) és egyértelmű burkolati jelzéseket tartalmaz. Ez az egyetlen kép:

• Gyakoroltatja a képbeolvasási szakaszt – dekódolás, színkorrekció, georeferálás
• Gyakoroltatja a repedésdetektáló modellt – legalább egy repedés jelen van
• Gyakoroltatja a hibabesoroló modellt – legalább egy hiba jelen van
• Gyakoroltatja a térképezési szakaszt – geotérbeli koordináta-hozzárendelés
• Gyakoroltatja a vizualizációs szakaszt – fedvény-megjelenítés feliratokkal
• Gyakoroltatja a kiértékelési szakaszt – PCI számítás vagy állapotpontozás

A várt feldolgozási idő ennél az egyetlen képnél a teljes pipeline-on keresztül 30 másodperc alatt van CI-hardveren, ami időt hagy a szert további füsttesztjeinek. A tesztképet a tests/data/smoke/ könyvtárban tárolja a tároló, és Git LFS-en keresztül verziókezelt.

TarmacView Füsttesztek

A TarmacView felügyeleti pipeline-ját dedikált füstteszt szkriptek sorozata validálja, amelyek mindegyike egy adott pipeline-fázist fed le. Ezek a szkriptek a scripts/ könyvtárban találhatók a smoke_<fázis>.py elnevezési konvenciót követve. Minden szkript önállóan (fejlesztési hibakereséshez) és a CI-szert részeként (automatizált kapuzáshoz) is futtatható.

{{

smoke_analyze.py

Ez a szkript a képfeldolgozási fázist validálja. Beolvas egyetlen reprezentatív ortofotó sávot, lefuttatja a teljes feldolgozási pipeline-t a képfeldolgozó modulon keresztül, és ellenőrzi:

• A kép betöltése és dekódolása hibamentesen történik a TIFF konténerformátumból
• A színkorrekció és radiometriai normalizáció sikeresen lezajlik, a nyers érzékelőértékeket reflexióvá alakítva
• A georeferálási metaadatok elemzése és alkalmazása megtörténik, beleértve az UTM zóna és datuminformációkat
• A feldolgozott kép a várt méretekkel (1024x768 pixel) és adattípussal (float32) rendelkezik
• A kimeneti feldolgozási fájl a várt útvonalra íródik a feldolgozási kimeneti könyvtárban
• A minimális és maximális pixelértékek az érvényes radiometriai tartományon belül vannak

A szkript elfogad egy --input argumentumot, amely a tesztképre mutat, és egy --output-dir argumentumot, amely meghatározza, hogy a pipeline hova írja az eredményeket. Ha a pipeline bármely feldolgozási lépésben összeomlik, a kivétel elkapásra kerül, és a teszt strukturált hibajelentést ad vissza.

smoke_assess.py

Ez a szkript a burkolat állapotfelmérési fázist validálja. A feldolgozási fázis kimenetét (vagy egy verziókezelésben tárolt előre generált feldolgozási fájlt) veszi bemenetként, lefuttatja az állapotfelmérő algoritmust, és ellenőrzi:

• Az állapotfelmérő függvény hibamentesen fut le a bemeneti adatokon
• Az állapotindexek (Burkolatállapot-index PCI vagy azzal egyenértékű) kiszámításra kerülnek
• A kimeneti állapotfelmérési fájl a várt oszlopokat tartalmazza: pavement_id, condition_index, severity, extent, date_assessed
• Az állapotpontszámok az érvényes numerikus tartományon belül vannak (0–100 PCI esetén, ahol a 0 a teljes meghibásodást, a 100 a tökéletes állapotot jelzi)
• A kimeneti fájl Parquet fájlként íródik a várt sémával

A TarmacView állapotfelmérő algoritmusa az ASTM D5340 szabványt követi a repülőtéri PCI számításhoz, automatizált képalapú felügyelethez adaptálva. A füstteszt nem ellenőrzi, hogy a PCI értékek numerikusan helyesek-e – csak azt ellenőrzi, hogy a számítás lefut, az eredményeket a várt formátumban állítja elő, és lemezre írja őket.

smoke_crack.py

Ez a szkript a repedésdetektálási fázist validálja. Lefuttatja a repedésdetektáló modellt egy ismerten repedéseket tartalmazó tesztképen, és ellenőrzi:

• A modell sikeresen betöltődik a mentett súlyfájlból, és hibamentesen produkál következtetést
• A PyTorch vagy TensorFlow futtatókörnyezet megfelelően inicializálódik, beleértve a CUDA/GPU inicializálást, ha rendelkezésre áll
• A kimeneti repedésmaszk mérete megegyezik a bemeneti kép méretével (1024x768)
• Legalább egy repedéspixel detektálásra kerül, megerősítve, hogy a tesztkép ismert repedéseket tartalmaz, és a modell reagál
• A repedés tulajdonságait tartalmazó fájl az alábbi oszlopokat tartalmazza: crack_id, length_px, width_px, orientation, confidence, classification
• A kimeneti fájlok a várt útvonalakra íródnak a repedések kimeneti könyvtárában

A TarmacView által használt repedésdetektáló modell egy U-Net architektúra ResNet-50 törzzsel, amely több repülőtérről származó feliratozott burkolati képeken lett betanítva. A füstteszt bemeneti képet kifejezetten a validációs halmazból választották ki, ami azt jelenti, hogy olyan repedéseket tartalmaz, amelyeket a modell a tanítás során már látott, de a tesztkészlet kiértékelése során nem.

smoke_defect.py

Ez a szkript a felületi hibák osztályozási fázisát validálja. Lefuttatja a hibabesorolót egy ismert hibákat (kátyúsodás, kitöredezés, foltozás, időjárás okozta károsodás) tartalmazó tesztképen, és ellenőrzi:

• A osztályozó betöltődik és hibamentesen produkál előrejelzéseket
• A kimeneti osztályozási térkép mérete megegyezik a bemeneti kép méretével
• Legalább egy hibakategória előrejelzésre kerül, megerősítve, hogy ismert hibák vannak a bemenetben
• A hibaleltár fájl az alábbi oszlopokat tartalmazza: defect_id, defect_type, area_px, severity, confidence, timestamp
• A kimeneti geotérbeli fájl érvényes koordinátákat tartalmaz a várt CRS-ben (koordináta-referenciarendszer)
• A hibapoligonok száma ésszerű (nem nulla és nem gyanúsan magas)

A hibabesoroló egy Mask R-CNN architektúrát használ, amely példány-szegmentációs maszkokat hoz létre minden észlelt hibához. A füstteszt ellenőrzi, hogy a kimeneti maszk méretei helyesek-e, és hogy a leltárfájl tartalmazza-e a várt sémaoszlopokat. Nem ellenőrzi, hogy a hibabesorolások helyesek-e – ehhez külön validációs szettre van szükség feliratozott alapigazság adatokkal.

smoke_survey.py

Ez a szkript a térképezési fázist validálja. A felsőbb szakaszok által előállított repedés- és hibaadatokat veszi bemenetként, lefuttatja a geotérbeli térképező modult, és ellenőrzi:

• A geotérbeli koordináta-hozzárendelés hibamentesen befejeződik, a pixelkoordinátákat valós világkoordinátákká alakítva
• A kimeneti térképfájl érvényes szélességi és hosszúsági oszlopokat tartalmaz, a várt földrajzi határokon belüli értékekkel
• A detektált jellemzők közötti térbeli kapcsolatok megőrződnek (a pixel térben szomszédos repedések a földrajzi térben is szomszédosak maradnak)
• A térkép kimeneti fájl a várt vetületi metaadatokat tartalmazza, beleértve az EPSG kódot
• A fájl a megkövetelt kimeneti formátumban íródik (GeoJSON vagy Shapefile)
• A geometriai típusok helyesek (LineString repedésekhez, Polygon hibákhoz, Point térképjelzőkhöz)

A térképező modul az ortofotó georeferálási metaadatait használja a pixelkoordináták földrajzi koordinátákká történő projektív transzformációjához. A füstteszt ellenőrzi, hogy ez a transzformáció érvényes földrajzi koordinátákat állít-e elő a tesztkép várt befoglaló téglalapján belül. A tesztkép helyszínéről a repülőtéren készült fénykép vizuális keresztreferenciát biztosít a hibaelemzéshez.

smoke_seg_head.py (Vizualizációs Fázis)

Ez a szkript a vizualizációs és szegmentációs fej fázist validálja – a pipeline utolsó szakaszát, amely emberi olvasásra alkalmas kimenetet állít elő. A feldolgozott pipeline-kimeneteket veszi, lefuttatja a vizualizációs megjelenítőt, és ellenőrzi:

• A fedvényképek hibamentesen jelennek meg, a repedésmaszkokat, hibapoligonokat és állapotpontszámokat kombinálva az alap ortofotón
• A kimeneti vizualizáció mérete és színtere megegyezik a bemenettel
• A jelmagyarázat és a felirat elemek jelen vannak, beleértve a léptéksávot, északi irányjelzőt és színkódolt súlyossági jelmagyarázatot
• A jelentésgenerálás sikeresen befejeződik, HTML vagy PDF összefoglalót előállítva
• A végső kimeneti fájlok a várt útvonalakra íródnak a helyes fájlkiterjesztésekkel (.png képekhez, .html vagy .pdf jelentésekhez)
• A fájlméretek nem nullák és a várt tartományon belül vannak

A vizualizációs fázis gyakran az első hely, ahol a kumulatív pipeline-hibák láthatóvá válnak. Egy repedésdetektálási szakasz, amely rossz koordinátatérben hoz létre maszkot, olyan vizualizációt eredményez, ahol a repedésfedvények eltolódnak az alapképhez képest. A füstteszt ezt közvetetten érzékeli, ha a megjelenítés összeomlik, de a vizuális ellenőrzési regressziós teszt – nem a füstteszt – az, ami a vizuális minőségi regressziókat kiszűri.

Teszt Orkesztráció és Eredményformátum

Ezek a füsttesztek sorosan futnak, de önállóan is végrehajthatók, ha a felsőbb szakaszok kimenetei gyorsítótárazva vannak. A teljes szert kevesebb mint 3 perc alatt fut le CI-hardveren. Minden teszt strukturált JSON jelentést ad ki a következő mezőkkel:

A teszfuttató az egyes JSON jelentéseket egy szert összesítésbe gyűjti, amelyet közzétesz a CI műszerfalon, és opcionálisan elküld Slackre vagy e-mailbe valós idejű értesítésként.

Mit Ellenőriznek a Füsttesztek

A füsttesztek szándékosan szűk körben állítanak ki állításokat. Három kategóriájú feltételt ellenőriznek, és semmi többet. Ez a szűk hatókör szándékos – gyorsan, determinisztikusan és könnyen karbantarthatóvá teszi a teszteket.

1. A Pipeline Lefut a Befejezésig

A legalapvetőbb állítás: a kód végrehajtódik-e anélkül, hogy kezeletlen kivételt dobna? Ez magában foglalja:

• Az importláncok helyesen feloldódnak – minden Python modulimport sikeres, a tranzitív függőségek telepítve vannak, verzióütközések nem állnak fenn
• A konfigurációs fájlok hibamentesen értelmezhetők – a YAML, JSON vagy TOML konfigurációs fájlok szintaktikailag érvényesek és a várt kulcsokat tartalmazzák
• A külső függőségek elérhetők – a modellsúlyfájlok a várt útvonalakon jelen vannak, az adatbázis-kapcsolatok sikeresek, az API végpontok elérhetők
• A hardvergyorsítók rendelkezésre állnak – a GPU jelen van, és a CUDA megfelelően inicializálódik, ha a pipeline GPU következtetést igényel
• A fájlrendszerbeli útvonalak léteznek és írhatók – a kimeneti könyvtárak létrejönnek, és megfelelő írási jogosultságokkal rendelkeznek
• A memóriakorlátok nem haladódnak meg – a pipeline a tesztbemenetet memóriahiányos hibák kiváltása nélkül dolgozza fel

Egy olyan pipeline, amely induláskor vagy végrehajtás közben összeomlik, azonnal megbuktatja a füsttesztet. A hiba okát a kivétel visszakövetéséből rögzítik, közvetlen mutatót biztosítva a fejlesztőknek a hiba kódhelyére.

2. A Kimeneti Fájlok Léteznek

A végrehajtás befejezése után a füstteszt ellenőrzi, hogy a kimeneti fájlok a várt útvonalakon léteznek. Ez magában foglalja:

• A fő kimeneti fájlok jelen vannak – eredmények, jelentések, feldolgozott képek, modellkimenetek
• A köztes fájlok jelen vannak – ha a pipeline szerződése előírja, hogy a köztes kimeneteket meg kell őrizni, a füstteszt ellenőrzi azokat
• A fájlméretek nem nullák – a nulla bájtos kimeneti fájl azt jelzi, hogy a szakasz nem termelt adatot, ami hiba
• A fájlformátum-aláírások érvényesek – a fájlfejléc megegyezik a várt formátummal (pl. érvényes PNG mágikus bájtok, érvényes GeoJSON szerkezet, érvényes Parquet mágikus bájtok)

Egy olyan pipeline, amely azt állítja, hogy befejeződött, de nem hoz létre kimeneti fájlokat, megbuktatja a füsttesztet. Ez elkapja a csendes hibákat, ahol a pipeline tisztán kilép, de kihagyja a kritikus írási műveleteket hibásan konfigurált kimeneti útvonalak vagy váratlanul hamisra kiértékelt feltételes logika miatt.

3. Kulcsfontosságú Oszlopok Jelenléte a Táblázatos Kimenetben

Minden táblázatos kimenetnél (CSV, Parquet, GeoJSON feature collection) a füstteszt ellenőrzi, hogy a várt oszlopok név szerint léteznek. Ez egy szerkezeti integritási ellenőrzés – az oszlopsémának meg kell egyeznie azzal, amit a downstream felhasználók elvárnak.

A teszt oszlop-létezési ellenőrzést használ (nem típusellenőrzést, nem értéktartomány-ellenőrzést). Ez szándékos – az oszlop létezése a minimális szerkezeti integritási garancia. A típus- és tartományellenőrzések az integrációs és validációs tesztek közé tartoznak, ahol a futtatás költségét indokolja a kapott információ mélysége.

4. Adatformátum-kompatibilitás

A füsttesztek által végzett ellenőrzések negyedik kategóriája – amelyet gyakran figyelmen kívül hagynak – az adatformátum-kompatibilitás. A füstteszt ellenőrzi, hogy a kimeneti fájlok visszaolvashatók-e a várt downstream felhasználók által. TarmacView esetében ez a következőket jelenti:

• A Parquet fájlok olvashatók a Pandas segítségével séma hibák nélkül
• A GeoJSON fájlok feldolgozhatók a shapely és geopandas könyvtárakkal
• A GeoTIFF fájlok megnyithatók a rasterio segítségével helyes CRS metaadatokkal
• A JSON jelentések deszerializálhatók szintaktikai hibák nélkül
• A CSV fájlok konzisztens sorokkal rendelkeznek az oszlopok között

Ez elkapja a formátumverziók közötti eltéréseket – például ha a Parquet könyvtárat frissítik és az megváltoztatja a kódolást, vagy ha a GeoJSON specifikáció fejlődik, és a pipeline kimenete már nem felel meg neki.

Mit NEM Ellenőriznek a Füsttesztek

Ugyanilyen fontos megérteni, hogy mit zárnak ki szándékosan a füsttesztek. Ennek félreértése hamis biztonságérzethez vezet a pipeline helyességét illetően – egy sikeres füstteszt nem jelenti azt, hogy a pipeline helyes, csak azt, hogy nem katasztrofálisan hibás.

Numerikus Pontosság

A füsttesztek nem ellenőrzik, hogy a számított értékek helyesek-e. Egy repedéshossz-számítás, amely 47,2 képpontot ad vissza a helyes 42,1 helyett, átmegy a füstteszten, amíg a length_px oszlop létezik és float értéket tartalmaz. A pontosság validálása az egységtesztek közé tartozik, ahol a helyes érték beégetve szerepel, és az integrációs tesztek közé, ahol az eredményeket tanúsított szakemberek kézi méréseivel hasonlítják össze.

Az ICAO Annex 14 hatálya alá tartozó repülőtéri felügyeleti pipeline-ok esetében a numerikus pontosság kritikus, mert az állapotfelmérések közvetlenül befolyásolják a karbantartási prioritásokat és a költségvetés-elosztást. Egy olyan pipeline, amely átmegy a füstteszteken, de pontatlan PCI pontszámokat produkál, hibás karbantartási döntésekhez vezethet. Ezért a füsttesztek csak az első kapu – pontosságra összpontosító validációs teszteknek kell követniük őket.

Szélsőséges Esetek

A füsttesztek reprezentatív, de nem ellenséges bemeneteket használnak. Nem tesztelik:

• Üres képek – teljesen fekete vagy fehér képek, amelyek nem tartalmaznak jellemzőket
• Sérült fájlok – csonka TIFF fejlécek, hiányzó EXIF adatok, nulla bájtos fájlok
• Extrém fényviszonyok – túlexponált vagy alulexponált képek, árnyékos képek, éjszakai felvételek
• A várt felbontáson túli képek – 100 megapixeles képek vagy 100 pixel alatti miniatűrök
• Hiányzó metaadatok – georeferálás nélküli képek, EXIF GPS nélkül, kamera kalibrációs adatok nélkül
• Hálózati időtúllépések – API hívások, amelyek elakadnak vagy 503-as hibát adnak
• Egyidejű hozzáférés – több pipeline-példány ugyanabba a kimeneti könyvtárba ír

A szélsőséges esetek kezelését dedikált szélsőséges eset tesztek validálják, amelyek kifejezetten az egyes határfeltételeket célozzák. Ezek a tesztek drágábbak futtatni, és általában éjszakánként futnak, nem minden kommitnál.

Teljesítményjellemzők

A füsttesztek azt ellenőrzik, hogy a pipeline befejeződik, nem azt, hogy egy teljesítménykereten belül fejeződik be. Egy olyan pipeline, amely füsttesztekben 10 másodpercet vesz igénybe képenként, de az élesben 100 képet kell feldolgoznia másodpercenként, gond nélkül átmegy a füstteszteken. A teljesítmény validálásához dedikált benchmark tesztek szükségesek éles méretű adatokkal és időküszöbökkel.

Repülőtéri felügyeleti pipeline-ok esetében a teljesítmény kritikus, mert a repülőterek felmérésenként több száz burkolati képet dolgoznak fel. Egy 10-szeres teljesítményregresszió még átmehet a füstteszteken egyetlen képen, de teljes felméréseket lehetetlenné tenne. A teljesítmény-benchmarkok időküszöbökkel a megfelelő eszközök az ilyen regressziók észlelésére.

Regresszió a Nem Kritikus Funkciókban

A füsttesztek csak a mag végrehajtási útvonalat fedik le. A nem kritikus útvonalon lévő funkciók – alternatív kimeneti formátumok, opcionális naplózás, telemetria, audit nyomvonalak, kísérleti export funkciók – nem fedettek. Az ezen területeken bekövetkező regressziót regressziós teszt szetteknek kell elkapniuk, amelyek kifejezetten a nem kritikus funkciókat célozzák.

Adatminőség

A füsttesztek nem ellenőrzik, hogy az adatértékek belsőleg konzisztensek-e. Például egy füstteszt ellenőrzi, hogy a crack_id oszlop létezik-e, de nem ellenőrzi, hogy az összes crack_id érték egyedi, nem nulla, vagy a várt tartományon belül van-e. Az adatminőség validálásához dedikált adatminőségi tesztek szükségesek olyan keretrendszerekkel, mint a Great Expectations vagy a Pandera, amelyek adatszerződéseket definiálnak és adathalmazokat érvényesítenek ezek alapján.

Füsttesztek a CI/CD-ben

A füsttesztek akkor nyújtják a legnagyobb értéket, ha integrálva vannak a folyamatos integrációs és folyamatos telepítési (CI/CD) pipeline-ba. A pipeline munkafolyamatban elfoglalt helyük meghatározza a minőségi kapuként betöltött hatékonyságukat.

{{

Elhelyezés a Pipeline-ban

Egy tipikus CI/CD munkafolyamatban a füsttesztek a build-verifikációs szakaszban futnak, közvetlenül a fordítás után és minden más tesztelési szert előtt:

Kód Kommit → Build → Lint → Egységtesztek → Füsttesztek → Integrációs tesztek → Validációs tesztek → Telepítés

A pontos sorrend a projekt tesztelési stratégiájától függ. Egyes szervezetek az egységteszteket futtatják először azzal az indokkal, hogy azok gyorsabbak és logikai hibákat fognak el. Mások a füstteszteket futtatják először azzal érvelve, hogy egy olyan pipeline-t, amely az alapvető végrehajtáson összeomlik, el kell utasítani anélkül, hogy időt vesztegetnénk az egységtesztekre. A TarmacView pipeline párhuzamosan futtatja az egységteszteket és a füstteszteket egy sikeres build után, mivel független meghibásodási módokat fednek le, és nincsenek kölcsönös függőségeik.

Ez az elhelyezés biztosítja, hogy ha a build olyan pipeline-t hoz létre, amely az alapvető végrehajtáson összeomlik, akkor nem fogy további tesztinfrastruktúra. A visszacsatolási hurkot percekben, nem órákban mérik. Az a fejlesztő, aki olyan kommitot push-ol, amely megtöri az importláncot, 2-3 percen belül CI hibaértesítést kap, ahelyett, hogy 4 órát várna az integrációs teszt szett bukására.

Kapu Logika

A CI/CD pipeline kemény kaput használ: ha bármely füstteszt megbukik, a pipeline megáll, és nem lép tovább a következő szakaszokba. A build sikertelenként van megjelölve, és a fejlesztők értesítést kapnak a füstteszt hibajelentésével. Az alapértelmezett konfigurációban nincs manuális felülbírálási lehetőség – a sikeres füstteszt-szert szükséges feltétel a telepítéshez.

Ez a kapulogika megakadályozza a következő forgatókönyveket:

• Egy csapat 4 órán át futtat integrációs teszteket, csak hogy rájöjjön, a pipeline az adatbetöltésnél összeomlik – pazarló számítás és más build-ek blokkolása
• Egy kiadásjelölt staging környezetbe kerül telepítésre, ahol az adatbázissémát csendben megváltoztatták a telepítési konfiguráció során
• Egy éles telepítés meghibásodik egy hiányzó import vagy fájlútvonal miatt, amely az utolsó kommitban került be

A kapu a CI platform konfigurációjában van implementálva. CircleCI esetében ez azt jelenti, hogy a munkafolyamat-függőségeket úgy kell konfigurálni, hogy a smoke-test feladat az integration-test és a deploy előtt fusson. GitHub Actions esetében ez a needs: kulcsszó használatát jelenti a feladatok sorrendjének kényszerítésére.

Párhuzamos Végrehajtás és Konkurencia

A szerten belüli füsttesztek párhuzamosan futhatnak, ha független pipeline-szakaszokat tesztelnek. A TarmacView füstteszt-szertje lehetőség szerint párhuzamosítást használ:

• A smoke_crack.py és a smoke_defect.py nem rendelkezik kölcsönös függőségekkel, és egyidejűleg futhat, 40%-kal csökkentve a teljes szertidőt
• A smoke_analyze.py-nak be kell fejeződnie a smoke_assess.py előtt, mivel az utóbbi a feldolgozás kimenetét használja fel
• A smoke_survey.py függ a repedés- és hibakimenetektől
• A smoke_seg_head.py függ az összes felsőbb szakasz kimenetétől

A párhuzamos végrehajtási stratégia a CI pipeline YAML-ben van konfigurálva feladatszintű párhuzamosítással. Minden feladat saját konténerben fut elszigetelt függőségekkel, megakadályozva az erőforrás-versengést.

Jelentéskészítés és Értesítés

A CI/CD integráció automatizált jelentéskészítést foglal magában több csatornán keresztül:

• Sikeres/Sikertelen állapot a CI műszerfalon színkódolt jelzőkkel (zöld a sikerhez, piros a sikertelenséghez)
• Időtartam követése tesztenként trendelemzéshez – a füstteszt időtartamának fokozatos növekedése teljesítményregressziót jelezhet
• Hibanaplók rögzítése CI összetevőként fejlesztői vizsgálathoz teljes veremkövetéssel
• Slack vagy e-mail értesítések teszt hiba esetén a naplókra és a hibás kommitra mutató linkekkel
• Trendgrafikonok a sikerességi ráta időbeli alakulásáról, >99%-os céllal a főágon
• Pöttyös tesztészlelés – egy teszt, amely váltakozva sikeres és sikertelen ugyanazon a kommiton, vizsgálatra kerül

CI/CD Konfigurációs Példa

# .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]

Füsttesztek Írása

Hatékony füsttesztek írása fegyelmet igényel. A tesztnek gyorsnak, megbízhatónak kell lennie, és csak arra kell összpontosítania, amit detektálni hivatott. Minden füstteszt ugyanazt az alapvető mintát követi: futtasd a pipeline szakaszt, ellenőrizd a kimenet létezését, ellenőrizd a minimális séma helyességét, jelentsd a sikeres/sikertelen eredményt strukturált JSON formátumban.

Egy Füstteszt Szerkezete

# smoke_crack.py — simplified pattern
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:
        # Step 1: Get pipeline version
        from tarmacview import __version__
        result["pipeline_version"] = __version__

        # Step 2: Run the pipeline stage with real imports
        from tarmacview.pipeline.crack import detect_cracks
        output = detect_cracks(input_path, output_dir)

        # Step 3: Verify output file exists and is non-empty
        output_path = Path(output["crack_mask_path"])
        assert output_path.exists(), f"Output file not found: {output_path}"
        assert output_path.stat().st_size > 0, f"Output file is empty: {output_path}"
        result["output_files"].append(str(output_path))

        # Step 4: Verify key columns in tabular output
        if output.get("crack_inventory_path"):
            inv_path = Path(output["crack_inventory_path"])
            assert inv_path.exists(), f"Inventory file not found: {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"Missing required column: {col}"
            result["output_files"].append(str(inv_path))

        # Step 5: Verify output mask dimensions match input
        from PIL import Image
        input_img = Image.open(input_path)
        mask_img = Image.open(output_path)
        assert input_img.size == mask_img.size, \
            f"Mask dimensions {mask_img.size} do not match input {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)

Tervezési Szabályok

1. Kategóriánként egy állítás. Állítsd, hogy a végrehajtás befejeződött. Állítsd, hogy a kimenet létezik. Állítsd, hogy az oszlopok léteznek. Ne állíts numerikus tartományokat, pontos fájlméreteket vagy adatminőségi mutatókat. Minden további állítás növeli a teszt karbantartási költségét és csökkenti a teszt megbízhatóságát.

2. Használj valós importokat. Ne mock-old a pipeline moduljait. A füsttesztnek a tényleges importláncot kell gyakoroltatnia, hogy elkapja az importálási hibákat és a hiányzó függőségeket. Az a füstteszt, amely a unittest.mock segítségével elnyomja az importálási hibákat, meghiúsítja saját célját.

3. Minimális beállítás és takarítás. A teszt nem igényelhet adatbázis-beállítást, szolgáltatásindítást vagy a teszt bemeneti fájlon kívüli külső konfigurációt. Ha beállítás szükséges, annak a CI feladatdefiníció részét kell képeznie, nem a teszt szkriptének. Minden füsttesztnek futtathatónak kell lennie egy fejlesztő laptopján egyetlen paranccsal.

4. Determinisztikus. Ugyanaz a bemenet mindig ugyanazt a sikeres/sikertelen eredményt kell produkálja. A véletlenszerű magokat rögzíteni kell a pipeline konfigurációjában. A teszt bemeneti fájloknak verziókezelteknek kell lenniük. A nem determinisztikus füsttesztek rosszabbak, mint a haszontalanok – aláássák a teljes tesztinfrastruktúrába vetett bizalmat.

5. Önálló strukturált kimenet. A tesztnek strukturált JSON kimenetet kell kiírnia a befejezéskor, megkönnyítve a CI rendszerek számára az eredmények elemzését egyedi naplóelemzés nélkül. A JSON sémának konzisztensnek kell lennie a szert összes füsttesztje között.

6. Gyors. Minden tesztnek 60 másodpercen belül be kell fejeződnie CI-hardveren. Ha egy teszt következetesen túllépi ezt a határt, optimalizálni kell a tesztet, mielőtt hozzáadnánk a szerthez. Egy 5 percig tartó füsttesztet a fejlesztők kihagynak, amikor helyben futtatják a teszteket.

Gyakori Buktatók Elkerülése

• Túl sokat tesztelni. Pontossági állítások vagy értéktartomány-ellenőrzések hozzáadása integrációs tesztté változtatja a füsttesztet. Tartsd sekélyen. A teszt megírása kevesebb mint 60 másodpercet, végrehajtása kevesebb mint 60 másodpercet vegyen igénybe.
• Importálási hibák figyelmen kívül hagyása. Az a füstteszt, amely minden kivételt széles körben elkap egy általános except Exception segítségével, elmulaszthatja az importálási hibákat. Hagyj néhány kivételt továbbterjedni, vagy legalább naplózd az importálási hibákat külön.
• Éles adatok használata. Az éles adatok nagyok, kontrollálatlanok, és érzékeny információkat tartalmazhatnak, beleértve a repülőtéri biztonsági övezeteket és szerzői jog által védett képeket. Használj rögzített, kis szintetikus vagy gondozott bemenetet.
• Változtatható tesztbemenetek. A hálózati meghajtókon vagy felhőtárhelyen tárolt tesztbemenetek verziókezelés nélkül megváltozhatnak. Mindig verziókezeld a tesztbemeneteket a tárolóban vagy Git LFS-en keresztül.
• GPU rendelkezésre állásának feltételezése. Ha a pipeline GPU-t igényel a következtetéshez, a füsttesztnek kecsesen kell kezelnie a GPU hiányát vagy a GPU-függő teszt kihagyásával, vagy CPU tartalék futtatásával.
• Kódba égetett fájlútvonalak. Soha ne égj abszolút fájlútvonalakat a füsttesztekbe. Használj relatív útvonalakat és a --output-dir argumentumot a rugalmas végrehajtási környezetek biztosításához.

Füstteszt Hibák Értelmezése

Amikor egy füstteszt megbukik, a fejlesztési munkafolyamatnak “fejlesztésről” “diagnosztizálásra és javításra” kell váltania. A hatékony hibaértelmezés strukturált megközelítést követ, amely a hibák tüneteit a valószínű kiváltó okokhoz rendeli.

Hiba Kategóriák

Hibakezelési Munkafolyamat

Amikor egy füstteszt megbukik a CI-ben, az ajánlott válaszadási munkafolyamat a következő:

1. Ellenőrizd a hibajelentést. A füstteszt strukturált JSON kimenete tartalmazza a failure_reason mezőt, amely a kivétel típusát és üzenetét tartalmazza. Ez a leggyorsabb út annak megértéséhez, hogy mi tört el.

2. Határozd meg, hogy a hiba kódregresszió vagy infrastruktúra-probléma. Egy ModuleNotFoundError egy tegnap telepített csomag esetében regresszióra utal. Egy Timeout, amely egyszerre minden build-en megjelenik, infrastruktúra-problémára utal (hálózati kimaradás, CI futató degradáció).

3. Vond vissza, ha a kiváltó ok nem nyilvánvaló 15 percen belül. A füstteszt-szert kifejezetten azért gyors, hogy lehetővé tegye a gyors visszavonást. Egy build-et, amely megbukik a füstteszteken, azonnal vissza kell vonni a CI pipeline más fejlesztők számára való felszabadításához.

4. Vizsgáld meg a tesztbemenettel. Futtasd le a hibás füsttesztet helyben ugyanazzal a verziókezelt tesztbemenettel. A hiba helyi reprodukálása kiküszöböli a CI-specifikus változókat (konténerkülönbségek, erőforráskorlátok, párhuzamossági problémák).

5. Javítsd ki, és adj hozzá egy egységtesztet. Miután a kiváltó okot azonosítottad, javítsd a kódot, és adj hozzá egy egységtesztet a megfelelő szinten, amely elkapta volna a hibát. Ez megakadályozza az azonos osztályú regresszió megismétlődését.

6. Ellenőrizd, hogy a javítás átmegy a füstteszteken. Futtasd le a teljes füstteszt-szertet helyben, mielőtt push-olod a javítást. Ez biztosítja, hogy a javítás ne vezessen be új hibákat más pipeline-szakaszokban.

Téves Pozitív Eredmények és Pöttyös Tesztek

A füsttesztek téves pozitív eredményeket produkálhatnak – a teszt megbukik, de a pipeline valójában működőképes. Gyakori okok:

• Erőforrás-versengés a CI-ben – több build egyidejű futása kimeríti a memóriát vagy a lemezterületet
• Hálózatfüggő tesztek – olyan tesztek, amelyek külső API-kat érnek el vagy modellsúlyokat töltenek le távoli tárolóból
• Időzítésfüggő tesztek – olyan tesztek, amelyek feltételezik, hogy bizonyos műveletek egy adott időablakon belül befejeződnek
• Fájlrendszer versenyhelyzetek – párhuzamos tesztek, amelyek átfedő kimeneti könyvtárakba írnak

A pöttyös füsttesztek aláássák a tesztinfrastruktúrába vetett bizalmat. Azok a fejlesztők, akik véletlenszerűen bukó füstteszteket látnak, elkezdik figyelmen kívül hagyni a hibákat. A megoldás az agresszív stabilizálás: a pöttyösség kiváltó okának azonosítása és a teszt megerősítése. Ha egy teszt ésszerű erőfeszítéssel nem tehető megbízhatóvá, akkor alacsonyabb prioritású tesztelési szettbe kell helyezni, vagy robusztusabb tervre kell cserélni.

Füsttesztek a Repülési Szoftverek Kontextusában

Repülési szoftverek – beleértve a repülőtéri felügyeleti pipeline-okat – esetében a füsttesztek további jelentőséggel bírnak a terület biztonságkritikus jellege miatt. A DO-178C (Szoftver szempontok a légi fedélzeti rendszerekben és berendezések tanúsításában) keretében a szoftververifikáció szigorú követelmény-alapú folyamatot követ. Bár a DO-178C nem nevezi kifejezetten “füsttesztelésnek” a fogalmat, a 6.4.3 szakaszban meghatározott Hardver/Szoftver Integrációs Tesztelés koncepciója megköveteli, hogy az integrált rendszer “boot-oljon és az alapvető funkciók működjenek” – ami funkcionálisan a füstteszt megfelelője.

Az ICAO Annex 14 I. kötete – Repülőterek tervezése és üzemeltetése – alapján a repülőtéri burkolatok állapota közvetlenül befolyásolja a repülőgép-biztonságot. A burkolat meghibásodása egy kifutópályán repülőgép-károsodást vagy irányításvesztést okozhat felszállás és leszállás során. A repülőtéri burkolatok automatizált felügyeletére használt szoftvereknek ezért a kimenetük biztonsági vonatkozásaival arányos megbízhatósági szabványoknak kell megfelelniük. A füsttesztek biztosítják az első védelmi vonalat a szoftverhibákkal szemben, amelyek veszélyeztethetik a burkolat állapotfelméréseit.

A TarmacView esetében a füsttesztek egy tágabb szoftverminőség-biztosítási keretrendszer részét képezik, amely a következőket foglalja magában:

• Követelmények visszakövethetősége – minden pipeline funkció egy dokumentált követelményhez kapcsolódik
• Egységteszt lefedettség – >90%-os kódsor lefedettség az alapvető algoritmusokhoz
• Füstteszt lefedettség – a pipeline szakaszok 100%-a lefedve füsttesztekkel
• Integrációs teszt lefedettség – minden komponenshatár tesztelve valós adatokkal
• Validációs tesztek – pipeline eredmények összehasonlítása tanúsított repülőtéri ellenőrök által végzett manuális vizsgálattal
• Teljesítmény-benchmarkok – átviteli sebesség és késleltetés nyomon követése kiadásonként

Ez a többrétegű megközelítés biztosítja, hogy a füsttesztek az első kapuként szolgáljanak anélkül, hogy az egyetlen kapu lennének. A sikeres füstteszt azt jelenti, hogy a pipeline szerkezetileg rendben van. De az integrációs tesztek, validációs tesztek és teljesítmény-benchmarkok azok, amelyek megadják a szükséges bizalmat ahhoz, hogy a TarmacView kimenetét valós repülőtéri karbantartási döntésekhez használják.

Következtetés

A füsttesztelés egy alapvető szoftverminőségi gyakorlat, amely a megvalósítási költségéhez képest kiemelkedő értéket nyújt. A TarmacView-hoz hasonló felügyeleti szoftver-pipeline-ok esetében a füsttesztek másodpercek alatt – nem órák alatt – kapják el az integrációs hibákat (törött importok, hiányzó fájlok, sémaeltérések). Első kapuként szolgálnak a CI/CD-ben, elutasítva az instabil build-eket, mielőtt azok felemésztenék a tesztinfrastruktúrát. A TarmacView füstteszt-szertje a pipeline minden fázisát lefedi a képbeolvasástól a repedésdetektáláson, hibabesoroláson, felületfelmérésen, térképezésen és vizualizáción át, ahol minden teszt ellenőrzi, hogy a szakasz lefut, kimenetet produkál, és fenntartja a várt oszlopsémákat.

A hatékony füsttesztelés kulcsa a szűk hatókör megértése. A füsttesztek ellenőrzik, hogy a pipeline fut és kimenetet produkál. Nem ellenőrzik a pontosságot, teljesítményt, szélsőséges esetek kezelését vagy adatminőséget. Ezeket más tesztelési típusok validálják a tágabb minőségbiztosítási keretrendszerben. Amikor a füsttesztek ezzel a fegyelemmel készülnek – reprezentatív minimális bemenetek, gyors végrehajtási idő, széles de sekély lefedettség –, gyors és megbízható hibafelismerést biztosítanak, ami hatékonnyá teszi a CI/CD pipeline-okat a biztonságkritikus repülési szoftverek számára.