关于 hardware-tdd
用于制定硬件项目分阶段测试计划的技能，区分主机测试、仿真、构建和目标板证据。它帮助嵌入式开发者将需求对应到可观察的验证结果，不把编译或仿真当作物理行为的证明。
主要功能
- 01将需求映射到可观察测试
- 02在主机测试纯 C/C++ 逻辑
- 03在模型限制内使用仿真
- 04针对精确开发板编译
- 05区分验证阶段与证据
- 06记录失败及未验证项
适用场景
- 01规划嵌入式需求的测试
- 02用模拟传感器和执行器测试逻辑
- 03区分构建结果与目标板行为
- 04记录硬件检查的验证证据
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/hardware-tdd确认已加载。
详细介绍
硬件 TDD
在宣称功能完成前，先搭建测试阶梯。纯行为通常可以脱离目标硬件进行测试；电压、引脚复用、负载下的时序和物理组装仍需要目标硬件证据。
信息收集
记录准确的开发板/修订版、框架/工具链、硬件不变量、安全禁用条件、模拟器模型、可用仪器、测试夹具，以及用户要求的验证阶段。
流程
- 将需求转化为可观察行为和安全不变量。
- 使用时间、串行通信、传感器和执行器的伪对象，为纯 C/C++ 逻辑编写主机测试。保持硬件适配层精简。
- 仅对模拟器模型实际涵盖的外设和时序使用 Wokwi 或其他模拟器；记录模型的局限性。
- 使用选定的工具链进行针对准确开发板的编译和静态检查。
- 创建单项变更的目标硬件检查清单：断电连通性检查、受控上电、输入观测、输出禁用、复位/恢复和日志。
- 通过实体验证关卡索取测量结果、照片或串行输出。不要根据主机测试或编译日志推断目标硬件已成功。
- 将失败记录为证据，并确保下一项测试范围明确。
测试矩阵
| 层级 | 示例 | 可证明 | 无法证明 |
|---|---|---|---|
| 主机 | 消抖/状态/数据包解析器 | 确定性逻辑 | 引脚电压或接线 |
| 模拟 | 建模的传感器/LED/UART | 模拟的交互 | 稳压器、仿制品、电磁干扰、热行为 |
| 构建 | 准确的 FQBN/环境 | 源代码和依赖项可编译 | 上传或行为 |
| 目标硬件 | 串行输出、万用表、示波器、照片 | 观测到的硬件行为 | 除非带载，否则无法证明现场可靠性 |
| 系统 | 集成负载/故障场景 | 场景下的需求满足情况 | 未来部署的安全性 |
防止自我合理化
| 捷径 | 应对方式 |
|---|---|
| “单元测试通过了。” | 保持所有实体和系统阶段未完成。 |
| “Wokwi 与开发板一致。” | 列出模型未涵盖的内容，并在硬件上验证这些项目。 |
| “草图编译成功了。” | 分别要求上传身份信息和目标硬件观测结果。 |
| “照片证明它能工作。” | 要求提供开发板身份、测量背景和观测结果。 |
| “先标记完成，以后再测。” | 在取得证据前，将循环项目保持为阻塞状态或标记为 needs-review。 |
验证
- 每项需求都对应一项测试、一个验证阶段和一个产物路径。
- 分别标注主机/模拟/构建/目标硬件/系统测试结果。
- 仅限实体硬件的步骤应使用
embedded-project-loop中的具体Physical gate格式。 - 在报告中保留失败和未验证的案例，使其清晰可见。
共享输出约定
使用共享的 Arduino 技能约定：说明假设、所需工具及版本、实现步骤、各验证阶段的测试/证据、已知局限，以及恢复/安全注意事项。
评论
支持 Markdown