需综合行、函数、分支三项指标判断测试充分性：行覆盖率识别未执行代码，函数覆盖率确保关键函数被调用，分支覆盖率验证条件逻辑双向覆盖，三者协同才能真实反映测试质量。
不能只看一个数字，得把行、函数、分支这三项指标放一起看，才能判断测试到底充不充分。
行覆盖率：先筛出明显没跑过的代码
它统计的是“哪些可执行行被运行过”，空行、注释、纯花括号不算。比如一个 if 块里有 4 行代码，只要进了这个分支，4 行全算覆盖；但如果整个 if 没触发，这 4 行就全红。
- 适合快速发现完全遗漏的逻辑块，比如某个错误提示函数压根没调用
- 容易虚高——只调用函数但不校验返回值，也能拉高行覆盖
- 看到某文件行覆盖低于 80%，优先检查是否漏写了基础用例
函数覆盖率：确认关键行为是否被验证
它只关心“函数有没有被调用过”，不深究内部怎么走。Istanbul 能识别函数声明、箭头函数（赋值给变量时）、类方法、getter/setter 等。
- 未覆盖的函数，常见原因是测试没走到调用链，或函数定义在条件分支里（如 if (false) function foo() {}）
- 导出的公共函数，建议每个都写至少一个最小调用测试，哪怕只传默认参数
- 报错路径里的函数（比如 catch 块中上报日志的函数）常被忽略，要特别留意
分支覆盖率：真正检验逻辑健壮性的硬指标
它盯住每一个决策点：if/else、switch case、三元运算符、while/for 条件等，看真假两个方向是否都走到了。一个 if (a && b) 算 1 个分支点，但要求整体为 true 和 false 各出现一次。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 当“% Branch”明显低于“% Lines”或“% Statements”时，说明大量代码虽被执行，但条件分支没跑全
- 金融、支付类项目建议不低于 80%，否则易漏掉超时重试、权限失败等关键路径
- 补测试的重点是带判断逻辑的函数，比如只测了 x > 0，还得补 x <= 0 的用例
怎么看报告、怎么设底线
Jest + Istanbul 生成的 HTML 报告里，同一文件会并列显示：
% Statements: 90% % Branch: 60% % Functions: 100% % Lines: 90%
如果分支覆盖只有 60%，而其他都是 90%+，这就是典型“代码跑了，但逻辑没跑全”。可以在 CI 中加约束，比如：
nyc --check-coverage --branches 80 --functions 90 --statements 90
不复杂但容易忽略。
