Penetrační testování míří na odolnost komunikační vrstvy (serial protocol handling) vůči nečekaným vstupům a provozním podmínkám. Nejde o bezpečnostní audit ani o formální penetrační test v bezpečnostním smyslu. Cílem je odhalit chyby typu:
- firmware/aplikace zamrzne nebo spadne při nestandardní zprávě,
- parser se rozbije po částečném rámci nebo po chybně ukončeném řádku,
- stavový automat přejde do nekonzistentního stavu a už se neobnoví,
- vzniká přetížení (fronty, logování, UI), které postupně degraduje systém,
- chybí timeouts/retry nebo recovery strategie.
COM Guru Terminal je v tomto scénáři použit jako generátor řízené zátěže a „nepříjemných“ nebo nevalidních vstupů, který je opakovatelný a jednoduše přepínatelný mezi režimy.
1. Testovací topologie
- Testovaný prvek (aplikace nebo firmware přes převodník) komunikuje přes COM port.
- Terminál je protistrana komunikace:
- emuluje zařízení a posílá proud dat do aplikace, nebo
- emuluje aplikaci a posílá povely do zařízení.
Pro propojení může být dle potřeby použít virtuální kabel nebo použijte reálný COM port. Pro čistě protokolové robustnostní testy je virtuální propojení obvykle rychlejší a lépe reprodukovatelné. Pro testování reálných zařízení je potřeba reálný com port.
2. Základní principy lehkých robustnostních testů
- Jedna změna = jeden experiment
V každém běhu změňte pouze jednu dimenzi (rychlost, délku, formát, pořadí). Zvyšuje to schopnost lokalizovat problém. - Opakovatelnost
Vstupy posílejte tak, aby se daly spustit znovu (File player, Makra, jasně definované periody Timerů). - Pozorování dopadů
Sledujte: odpovědi, chybové kódy, latence, CPU/RAM, backlogy, ztráty rámců, reset/reconnect chování. - Bezpečný rozsah
Testujte pouze zařízení, která vlastníte nebo k nim máte oprávnění, a v prostředí, kde neohrozíte provoz.
3. Kategorie testů a jak je realizovat v aplikaci COM Guru Terminál
3.1 Zátěž a zahlcení linky
Cíl: ověřit chování při vysokém datovém toku a při dlouhodobé zátěži.
Typické scénáře
- extrémně krátká perioda odesílání (např. 1–10 ms),
- více paralelních toků (telemetrie + diagnostika + eventy),
- dlouhé zprávy / velké rámce.
Realizace
- Timer: nastavte periodické odesílání jedné zprávy s velmi krátkou periodou.
- Více Timerů: simulujte více „kanálů“ s různými periodami.
- File player: přehrávejte soubor s hustou sekvencí zpráv.
Co hodnotit
- zda testovaný prvek začne dropovat data, růst latency nebo zamrzat,
- zda se nezhoršuje stabilita v čase (memory leak, kumulace backlogu),
- jak se chová reconnect a restart komunikace po přetížení.
3.2) Fuzzing na úrovni protokolu (mix validních a nevalidních vstupů)
Cíl: odhalit slabiny parseru a validace vstupů.
Typické scénáře
- zprávy se špatným formátem (chybějící oddělovač, neukončený řádek, nadbytečná pole),
- hraniční hodnoty (min/max, příliš dlouhé číslo, prázdná hodnota),
- „téměř validní“ zprávy (správný prefix, špatný zbytek).
Realizace
- File player: soubor, kde jsou střídány validní a nevalidní řádky.
Co hodnotit
- zda parser selže řízeně (chyba + pokračování), nebo dojde k pádu/zacyklení,
- zda se po chybě systém vrátí do stabilního stavu a znovu synchronizuje framing.
Poznámka: pokud protokol používá CRC/checksum, „nevalidní“ zprávy volte cíleně (např. správný framing, špatná checksum) a sledujte, zda se chybová větev chová konzistentně.
3.3) Negativní testy časování (timeouts, opožděné odpovědi, ticho)
Cíl: prověřit, že request/response logika není křehká a umí pracovat s výpadky.
Typické scénáře
- zařízení (nebo host) občas neodpoví,
- odpověď přijde pozdě,
- odpovědi přicházejí v dávkách (burst), nikoli plynule.
Realizace
- Auto response: pravidla pro odpovědi na příkazy.
- Pro timeout test dočasně pravidlo vypněte nebo změňte odpověď na chybu.
- Timer / File player: simulace „ticha“ zastavením toku na definovaný interval.
- Makra: „Normal“, „Delayed“, „Silent“ režimy.
Co hodnotit
- zda existuje timeout a retry strategie,
- zda stavový automat nepřejde do nekonzistentního stavu po opožděné odpovědi,
- zda se po obnovení komunikace systém srovná bez restartu.
3.4) Stavový automat proti nestandardnímu pořadí příkazů
Cíl: ověřit, že zařízení/aplikace správně odmítá příkazy v nesprávném stavu a umí se zotavit.
Typické scénáře
STARTpředINIT,- opakované
STARTbezSTOP, - konfigurace během běhu, pokud protokol vyžaduje „idle“,
- „reset“ uprostřed sekvence.
Realizace
- File player: soubor se scénářem „wrong order“.
- Auto response: vracejte chybové kódy pro neplatné stavy, abyste otestovali reakci protistrany.
- Makra: krokové spouštění (např. „Init“, „Start“, „Inject wrong cmd“, „Recover“).
Co hodnotit
- konzistentní chybové odpovědi (stejné kódy, stejné texty),
- schopnost návratu do validního stavu bez restartu procesu.
4.5) „Špatný soused“ – rušení protokolu z pohledu protistrany
Cíl: otestovat, jak systém reaguje na protistranu, která se chová nekorektně, ale „reálně“.
Typické scénáře
- protistrana posílá duplicity odpovědí,
- protistrana posílá odpověď na jiný příkaz (mismatched correlation),
- protistrana posílá validní, ale nerelevantní zprávy ve špatný čas.
Realizace
- File player: sekvence s duplikacemi, mismatch odpověďmi a vloženými „noise“ řádky.
- Auto response: pravidla, která generují „nepříjemné“ odpovědi na vybrané příkazy.
Co hodnotit
- zda je implementována korelace request/response (pokud má být),
- zda systém umí ignorovat nerelevantní zprávy a nepřepíná stav chybně.
5. Praktická organizace testovací sady
- Baseline (kontrola)
stabilní telemetrie + korektní autoresponse. Slouží jako referenční běh. - Stress
zkrácené periody, paralelní streamy, dlouhé rámce. - Fault injection
fuzz soubory, vypnuté odpovědi, špatné pořadí příkazů, ticho.
Takto se dá rychle odlišit, zda problém vzniká z objemu dat, ze špatných vstupů, nebo z časování.
6. Využití AI pro generování testovacích vstupů
AI je praktická pro generování:
- syntakticky validních zpráv ve velkém množství,
- cíleně nevalidních variant (chybějící pole, špatné typy, extrémní délky),
- sad pokrývajících hraniční hodnoty.
7. Kritéria „test prošel“
Pro robustnostní testy je vhodné mít explicitní kritéria, například:
- proces nespadne a nezamrzne,
- po chybě dojde k obnově komunikace (bez restartu) do definovaného času,
- chybové odpovědi jsou konzistentní,
- při zátěži nedochází k nekonečnému růstu paměti nebo latencí,
- protokolová vrstva po poškozeném rámci znovu získá synchronizaci.
8. Stručný checklist pro první běh
- Po každém profilu ověřit: stabilitu, latenci, obnovení (revocery), konzistenci chyb.
- Baseline profil: korektní request/response a mírná telemetrie.
- Stress profil: 10× vyšší datová frekvence, více paralelních toků.
- Fault profil: mix valid/invalid + výpadky odpovědí + špatné pořadí příkazů.
Související články
COM Guru Terminal – sériový terminál nové generace pro Windows
COM Guru Terminál jako jednoduché SCADA centrum pro sériovou linku
COM Guru Terminál jako emulátor zařízení nebo aplikace na seriové lince
COM Guru Terminál – Ovládání a konfigurace zařízení
