wandering1
59e6d77224
假 CH395F 的第三批、也是 NET 域最后一块。net_events.c 覆盖 175/179 = 97.8%。共享 假芯片本批补齐**对端六元组**（get_remot_ipp 的 6 字节）与**链路变更计数**（ link_change_count / link_up_cached 改为可预置，原来硬编码 0/1）。 钉住的契约（都是真机上会发生、却不能按需复现的那类）： - 对端六元组解析：remote_ip 是**低字节在前**拼的（192.168.1.50 -> 0x3201A8C0，与 网络序相反）。钉住它是防止有人"顺手改成大端"，让所有按 IP 比对/白名单静默错位。 - 陈旧中断防误判：芯片说 TCP 还 ESTABLISHED 时，迟到的 DISCONNECT 一律忽略并报 ERROR（拆活会话的代价是 104 主站看到莫名掉线）；一条数据都没收就报断且芯片接收区 还有字节，判为疑似误报、只置 lost_conn_seen 延后交给对账器。 - 正常断开：优雅级沉降 + session_dead + last_peer_port 记旧端口 + 转 CLOSED + 发事件。 - 超时：ESTABLISHED 走隔离级沉降并置 released_abnormal —— 这正是 net_pending 收尾时 把挂起 recv 报成 CONNRESET 而不是 0 的那条输入（TC-NETPEND-014），**跨文件因果** 只有两边都能离线跑才可测。 - 丢中断自愈：芯片已连上而软件还写着 LISTENING 时补一次 accept；若软件已 CLOSED 则 只留痕不凭空造会话（TC-NETEV-042b 记现状）。 - 对账器：100ms 周期闸门（同一时刻不重复查芯片）；链路计数**基线那趟不打日志** （0xFFFF 哨兵，否则每次上电都冒一条假"link up"）、变化即留痕；五种不一致形态的 稳定计数分三档（会话死亡要连观 4 次、芯片偷重开监听 2 次、丢 CONNECT 自接 1 次）； 动作后 1000ms 冷却内不重复折腾；U11 重同步（软件 CLOSED 而芯片在 LISTEN -> 直接跟 芯片，不做多余重建）；不在用的槽位直接跳过。 三条初判失败的复盘（都是**我的期望值/场景写错**，实现是对的）：① remote_ip 字节序 我按网络序写了期望；② 自愈场景我用了 CLOSED 态，而 accept 分支只认 LISTENING/ CONNECTING，改场景并补一条现状断言；③ 链路"基线不打日志"我测在非基线场景（s_ link_last 是函数内 static，跨场景本就延续）。对账器的 s_last/s_bad[]/s_cool[] 都是 函数内 static（外部够不着），因此每个形态**各占一个 fd**、时基单调前进，互不串扰。 覆盖率与台账：套件 24 → 25 全绿；files_tested 28 → 29；未触及 .c 38 → 37；分母 3,766 → 3,945 行；line=3472/3945（**88.0%**，连涨两批）、func=263/290（90.7%）。 恒等式 37 = 3(P1 剩) + 5(P2) + 29(P3) 仍咬合。编号补建 TC-HOST-NETEV（游标 058）， 族数 18 → 19。 自查：test-cppcheck Passed（含补齐后的假芯片）；check_ids --strict 通过；doc-links 35 处（= 存量）；16 个新增/改动文件 BOM/CR/U+FFFD/行尾逐项净。零生产代码改动，未跑 @build。--all-files 仍只有 mem-numbers / mem-budget（.map 台账漂移，等 Lead 合并后 统一 --write 回填）与 ui-golden（simulator/tests/ref/*.bin 不入库，新 worktree 没有 黄金参考）三条失败，与本分支改动无关；提交按并行分支约定走 --no-verify。
test/ — 测试代码与主机端脚本
测试分两部分，物理隔离在两个子目录：
board/—— 板端测试套件（.c/.h，编入固件由 testTask 执行）host/—— 主机端脚本（.py，PC 侧驱动板子并判读结果）
目录结构
| 目录 | 内容 | README |
|---|---|---|
board/ |
板端测试套件（编入 Keil 工程，占 RAM） | board/README.md |
host/ |
PC 端测试/判读脚本（Python） | host/README.md |
run_all_suites.py |
多套件回归编排（改宏 → 构建 → 烧录 → 采集，try/finally 保证还原开关）；--check-build = 只编译不烧录（纯离机） |
本文 §多套件回归 |
运行方式
# @test 一键闭环（推荐）
& '.venv\Scripts\python.exe' .dsh/skills/serial-boot-test/scripts/run_boot_test.py
# 单独校验日志
& '.venv\Scripts\python.exe' .dsh/skills/serial-boot-test/scripts/verify_log.py <日志文件>
# 多套件回归编排（需真机；自动改开关 + 构建 + 烧录 + 采集，结束后还原）
& '.venv\Scripts\python.exe' test/run_all_suites.py
& '.venv\Scripts\python.exe' test/run_all_suites.py --suites STORAGE,GD5F
& '.venv\Scripts\python.exe' test/run_all_suites.py --dry-run # 只看计划
# 只编译不烧录（S6；不需要 MCU / 串口 / ST-LINK，验证 4 套件可编译性）
& '.venv\Scripts\python.exe' test/run_all_suites.py --check-build
退出码约定：0=PASS / 1=FAIL / 2=采集或烧录错误 / 3=用法或预检错误。
多套件回归（run_all_suites.py）
套件互斥（编译期 #error）意味着跑 4 个套件要手工循环 4 轮。本脚本把它编排成一条
命令，并且无条件还原 test_config.h——跑完忘还原 = 测试固件进库，这是它存在的
核心理由（与提交期门禁 test-suite-switch 互为独立防线）。
⚠️ 每轮要真机烧录 + 采集，4 套件约数分钟起；破坏性套件还会改设备持久状态。 仅回归窗口用，绝不挂 pre-commit。
--check-build 则相反：只改宏 + @build，不烧录不采集，无需任何硬件，用于防止
"测试套件长期编不过而无人知"（2026-08~09 CH395F 套件实例）。改动 test/board/ 下测试
代码后建议先跑它——实测 4 套件均 BUILD_OK: 0 errors, 0 warnings。
⚠️ 注意
- 本目录被 pre-commit 门禁排除（测试代码不受 C 规范约束）
board/套件占用 RAM，启用前先核算预算（见docs/内存管理/）- Keil 工程已同步：
board/下 7 个.c编入MDK-ARM/STM32F4-Demo.uvprojx， IncludePath 含../test/board；移动文件须同步改工程文件 - 套件选择开关：
board/test_config.h的TEST_SUITE_*（互斥，一次只启用一个） - 测试缓冲用分 Phase 复用静态缓冲（避免
L6406E溢出）
相关文档
docs/测试说明/测试开发标准流程.md— L0~L3 分层与门禁决策表docs/测试说明/自动化测试流程.md—@test细节与失败模式- 各模块测试指南：
docs/测试说明/*_Test_Guide.md docs/测试说明/链路延迟测试说明.md