4、语句覆盖率分析：定义与意义、如何收集语句覆盖率、常见遗漏场景分析

4.1 语句覆盖率到底是个啥？

咱们先聊点实在的。语句覆盖率，说白了就是——你的测试用例跑了多少行代码。

举个例子。你写了一个函数，总共100行C代码。测试跑完之后，统计出来有80行被执行过。那语句覆盖率就是80%。

听起来很简单对吧？但我在项目中遇到过不少同事，觉得这玩意儿太基础，不屑一顾。结果呢？产品交付前发现一个低级bug——某条if分支里的语句从来没被执行过。嗯，这就是忽视语句覆盖率的代价。

我个人习惯，把语句覆盖率当作代码健康的「体温计」。体温正常不代表没病，但体温异常肯定有问题。同样的，语句覆盖率高不代表代码没bug，但覆盖率低，说明你的测试根本没到位。

4.2 为什么我们要关注它？

你可能会问：覆盖率指标那么多，分支覆盖率、MC/DC覆盖率，哪个不比语句覆盖率高级？为什么还要讲这个？

我跟你讲，原因有三：

1. 它是基础中的基础。 分支覆盖率再高，如果语句都没跑全，那都是空中楼阁。我记得有一次做AUTOSAR模块测试，分支覆盖率做到了95%，但语句覆盖率只有60%。一查才发现，好几个大函数体根本没进入过。
2. 它最容易理解。 跟项目经理汇报时，你说「语句覆盖率85%」，他秒懂。你说「MC/DC覆盖率70%」，他得愣三秒。别笑，这是真事。
3. 它是发现「死代码」的利器。 如果某段代码长期覆盖不到，要么是测试没写，要么是代码根本没用。后者更可怕——冗余代码会误导维护人员。

4.3 怎么收集语句覆盖率？

收集方法其实不复杂。我常用的工具有这么几类：

工具/方法	适用场景	我的使用感受
Simulink Coverage Analyzer	模型在环（MIL）测试	最方便，跑完测试自动出报告。但要注意它统计的是模型块执行情况，不是代码行。
Polyspace / Code Prover	代码级静态+动态分析	精度高，但配置麻烦。我一般用于最终验证。
手工插桩	嵌入式裸机环境	老派但可靠。在关键模块里加个计数器，跑完看计数。我早期做ECU测试时常用这招。
GCOV / LCOV	C代码单元测试	开源免费，配合Jenkins用很香。但需要目标机支持。

具体操作步骤，我以Simulink Coverage Analyzer为例：

1. 打开你的Simulink模型
2. 点击菜单栏：Analysis → Coverage → Settings
3. 勾选「Statement Coverage」
4. 运行测试用例（可以是Signal Builder或Test Harness）
5. 测试结束后，点击「Coverage Report」查看结果
6. 重点关注红色标注的未覆盖语句

嗯，这里要注意：Simulink的语句覆盖率统计的是模型中的块执行情况，不是生成的代码。如果你做的是MIL测试，这完全够用。但如果你需要代码级的语句覆盖率，那就得上Polyspace或者GCOV了。

4.4 常见遗漏场景分析

这部分是我最想跟你聊的。做了这么多年测试，我发现语句覆盖率低，往往不是因为测试用例少，而是因为漏掉了某些「刁钻」的场景。

场景一：边界条件没覆盖

你看这段代码：

if (speed > 100) {
    warning_flag = 1;
    activate_brake_assist();
} else {
    warning_flag = 0;
}

测试时只给了speed=50和speed=120两个值。看起来else分支和if分支都跑了？不对！你想想看，speed=100这个边界值呢？等于100的时候，走的是else分支。但很多测试人员会忽略这个点。

我曾经在一个项目中，就因为没测边界值，导致车速刚好100km/h时，制动辅助系统该触发却没触发。嗯，那是一次挺深刻的教训。

场景二：异常路径被遗忘

再来看这个：

status = read_sensor(&data);
if (status != OK) {
    error_handler();
    return;
}
process_data(data);

很多测试用例只给了status=OK的情况。error_handler()那行代码从来没被执行过。等到传感器真的坏了，才发现错误处理函数里有bug——日志打印格式错了，导致看门狗超时复位。

我建议：每个错误处理分支，至少写一个用例去触发它。 哪怕你觉得「这个错误不可能发生」，也要测。因为「不可能」在嵌入式世界里，往往意味着「迟早会发生」。

场景三：循环体内的语句

循环体是语句覆盖率的「重灾区」。比如：

for (i = 0; i < MAX_RETRY; i++) {
    if (try_again() == SUCCESS) {
        break;
    }
    log_retry(i);
}

如果第一次try_again就成功了，那log_retry()这行代码永远跑不到。循环体后半部分的语句，可能一次都没执行过。

怎么破？我的做法是：构造一个「永远失败」的输入，让循环跑满。 这样就能确保循环体内所有语句都被覆盖到。

场景四：条件表达式中的短路逻辑

这个坑比较隐蔽。看代码：

if (ptr != NULL && ptr->value > 10) {
    do_something();
}

如果ptr为NULL，第二个条件根本不会执行。但如果你只测了ptr非空的情况，那没问题。可如果你只测了ptr为空的情况，那ptr->value > 10这行「语句」其实没被覆盖——虽然它写在代码里，但编译器/工具可能认为它是条件表达式的一部分，不算独立语句。

嗯，这里要提醒你：不同工具对「语句」的定义有细微差别。 有的工具把整个if条件算一条语句，有的把每个子条件分开算。我建议你搞清楚自己用的工具是怎么统计的，不然容易产生误判。

4.5 提升语句覆盖率的实用技巧

最后，分享几个我自己的实操经验：

• 先跑「快乐路径」，再补「异常路径」。 别一上来就想着全覆盖，先把正常功能跑通，覆盖率通常能到60%-70%。剩下的30%基本都是边界、异常、错误处理。
• 用覆盖率报告反推测试用例。 报告里标红的代码，就是你的「待办事项清单」。我习惯把报告打印出来，一条一条打勾，很有成就感。
• 别追求100%。 有些代码确实无法覆盖，比如硬件抽象层里某些特定型号才有的分支。强行覆盖反而会引入无效测试。我个人觉得，90%-95%是MIL测试阶段比较合理的目标。
• 自动化收集。 手动跑一次两次还行，项目大了必须自动化。我一般把覆盖率收集集成到CI流水线里，每次提交代码自动跑、自动出报告。省心省力。

好了，关于语句覆盖率，今天就聊到这儿。下一节咱们讲分支覆盖率，那个更有意思——你会发现，语句覆盖率高，不代表分支都测全了。嗯，到时候再细说。