测试覆盖率指标有哪些
在软件开发和硬件外设固件测试中，测试覆盖率是衡量测试完整性的关键手段。尤其在外设设备如键盘、鼠标、耳机等产品的研发过程中，固件稳定性直接关系到用户体验。通过合理的覆盖率指标，可以发现潜在的逻辑漏洞或未覆盖的操作路径。
语句覆盖率（Statement Coverage）
这是最基础的指标，衡量代码中每一条可执行语句是否被执行过。比如一个鼠标驱动程序中的某个配置函数，如果其中有一行设置DPI的代码从未运行，那这部分功能就可能存在风险。
理想情况是达到100%，但在实际项目中，有些语句可能是为未来扩展预留的，或者只在特定硬件条件下触发。
分支覆盖率（Branch Coverage）
它关注的是程序中每一个判断分支是否都被执行过。比如一个键盘固件中判断“是否开启背光”的if-else结构，不仅要测试开启的情况，也要测试关闭的情况。
仅仅执行了if条件成立的路径，而不测试else，可能会遗漏背光控制失效的问题。这个指标比语句覆盖率更严格。
条件覆盖率（Condition Coverage）
当一个判断包含多个条件时，比如 if (battery > 20 && connected)，条件覆盖率要求每个子条件都分别取真和取假至少一次。
这意味着不仅要测电池电量高且连接正常的情况，还要单独测试低电量但连接、电量够但断连等组合，确保每个条件都能独立影响结果。
路径覆盖率（Path Coverage）
它要求程序中所有可能的执行路径都被覆盖。对于有多个嵌套条件的外设初始化流程，路径数量会迅速增加。
例如一个蓝牙耳机的配对流程，涉及电源状态、配对模式、连接历史等多个判断层，理论上可能有几十条路径。虽然完全覆盖难度大，但关键路径必须测试到位。
函数覆盖率（Function Coverage）
这个指标比较简单，就是看项目中定义的函数有多少被调用过。在外设固件中，某些错误处理函数可能很难触发，比如USB热插拔异常处理，但它们的存在意义重大。
通过模拟异常信号，确保这些函数被覆盖，能在真实用户遇到问题时避免死机或崩溃。
代码示例：简单判断结构的覆盖分析
if (voltage < 3.0) {
enter_low_power_mode();
} else {
normal_operation();
}要满足分支覆盖率，测试用例需要包括电压低于3.0V和高于等于3.0V两种情况。如果只在实验室常温下测试，忽略了低温导致电压下降的场景，就可能漏掉低功耗模式的bug。
实际应用中的取舍
并不是所有指标都要追求100%。比如路径覆盖率，在复杂状态下可能产生大量路径，测试成本过高。团队通常会结合外设使用场景，优先保障高频路径和安全相关逻辑的覆盖。
一款游戏鼠标固件更新后，重点应放在按键响应、轮询率切换、宏命令执行等核心功能的覆盖上，而不是过度纠结于极少使用的恢复出厂设置路径。
测试覆盖率只是手段，不是目的。真正重要的是通过这些指标发现盲区，让外设产品在各种使用环境下都能稳定工作。