wandering1
adabb6af12
现象（2026-10-25 三条道并行开发实测，看板 task-10）：全量 ci_local 的 L0 里 test-cppcheck / test-coverage 偶发 "files were modified by this hook"，单独重跑 即绿、工作树零改动。根因在 unit_test_harness：obj/exe 直接落在**全机共用**的 %TEMP%，名字由套件名派生（%TEMP%\net_socket_tests.exe、%TEMP%\net_socket_obj）， 多棵工作树并行跑同名套件必然互踩。 真正要命的不是编不过，而是**结论张冠李戴**：A 树编译完，B 树把同名 exe 又盖一 遍，A 树随后 subprocess 执行的是 B 树编出来的二进制——两棵树的 summary_marker 一模一样，harness 分辨不出来，于是拿别人的运行结果给自己判 PASS。这种失败不会 变红，只会静默给出错误结论，比红难查一个量级。 修法（不是加锁）： - 产物根按**工作树**分家：%TEMP%\dtu_host\<仓库根路径 sha1 前 10 位>\。树身份取 harness 文件自身位置（test/host/common 往上三级），不依赖 cwd/环境变量；工作树 之间只联接 .venv 与模拟器 SDK，test/host 每棵树各有一份，所以这个身份可靠。 - **每次运行再独占一个子目录** runs\<pid>-<纳秒>\，obj 与 exe 都放进去，跑完 finally 删（含 Ctrl-C 路径）。这一步顺带把"同树并发同名套件"也消灭了：两个 进程既拿不到同一个 exe，也拿不到同一个 .obj（实测共享根时并发会因 obj 撞名 直接编不过，返回 rc=2）。没有牺牲缓存：每个测试单元就一个 .c，cl 每次整体重编， "共享 obj 省编译"本来就是错觉。**不加锁**：这里没有需要互斥的独占资源，只是 名字撞了；加锁等于把 L0.5 变成 build/bench 那样的全局串行。 - 独占目录里留 <exe>.owner.json（suite / repo_root / pid / started）：需要证明"这 份产物属于哪棵树哪次跑"时有的可查，不必靠时间戳猜。 - 编译返回 0 但产物不存在 → 明确报环境错误，绝不跑来路不明的二进制。 - 两个开关：DTU_HOST_BUILD 改产物根（CI/容器固定路径），DTU_HOST_BUILD_KEEP=1 保留本次目录（要单步调试 exe 时用）。判据单一事实源 = host_build_root()。 - scripts/check_test_coverage.py 同源改造：work_root 由固定共享名 dtu_test_cov 改为 复用 harness 的 host_build_root()/coverage，并同步 --work-dir 帮助文案与 docstring （docs 里"并行期每人只跑 --module 自己模块"那条规避就此作废，它是为绕开旧共享名 而写的）。顺带删掉因此不再使用的 import tempfile。 附带修一处同族不诚实（做本任务时从自己的输出里发现）：ci_local 的收尾那行以前 无条件打印"L0 + L0b + L0c + L0.5 全部通过"，--l05-only 时等于把没跑过的段宣布 为通过——正是 A-5 那个"SKIP 冒充 PASS"的镜像版。改为只列本次真正跑过的段。 自证（都是实跑，不是推演）： - 两棵树身份并发跑同一套件：把修好的 harness 复制成 A/B 两个树身份（repo_root 不 同 → 两个不同产物根），套件 BUILD 从真仓库加载，各跑 4 轮并发 → 8/8 rc=0， 两侧 roots 分别是 …\55deb98e3b 与 …\902100bc41，互不可见。 - 敌意场景：把两边 DTU_HOST_BUILD 强行指到同一目录（旧写法必撞 exe/obj）→ 8/8 rc=0，共享根下只剩一个空的 runs/。同树并发同理被这一条覆盖。 - 单套：test/host/sha256 rc=0（13/13），产物确实落在 …\4b9166f602\runs\<pid>-…； 覆盖率 --module sha256 rc=0（line=111/114 func=7/7），落在 …\coverage\sha256。 - 全量：ci_local --l05-only → 33 runner(s)，2276/2276 assertions passed，fail=0。 - 临时目录与 scratch 已清理（脚本在仓库外，不入库；ci-artifacts/ 之外无残留）。 文档：test/host/common/README.md 新增"产物目录归属"一节（落点结构、为什么按树、 为什么每次独占、两个开关、一行命令查当前树的产物根）；harness 顶部注释是判据正文。 docs 侧两处按分工归 lead 在 done 时统一改，合并请求里已给可直接粘贴的替换文本： docs/测试说明/主机单测覆盖率口径.md 的产物目录条与"坑 12"、以及并行任务工作树 方案.md 的产物归属条。AGENTS.md 与 docs/** 本次一个字节没动。 RAM/Flash 增量：0 B（纯测试工具链，不进固件）。gate：见提交钩子输出，未用 --no-verify。 遗留：tools/font_gen/make_font.py 同样用固定共享名（%TEMP%\simsun_regular.ttf、 font_extra_<cp>.c）——同一类跨树竞态，但属道B 字体域，我没动，建议另开一张卡。
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