分支覆盖率低说明if/else、switch、三元运算符等分支未被执行，应通过覆盖率报告定位标红分支，检查条件真假组合是否穷尽，结合调试日志和输入源反推缺失路径。
分支覆盖率低，说明代码中某些 if/else、switch、三元运算符、逻辑运算符（&&、||）等产生的分支路径没有被执行到。要定位未执行的条件判断逻辑，关键不是“猜”，而是借助工具+结构化分析，快速聚焦可疑位置。
看覆盖率报告中的具体未覆盖分支
现代测试覆盖率工具（如 Istanbul / nyc、Jest 内置报告、Vitest）都会在 HTML 报告中高亮显示未覆盖的分支，通常用红色标记：
- if 语句只走了 if 分支，没走 else 分支 → 报告会标出 else 所在行或括号后的
else关键字 - switch 中某个 case 或 default 没触发 → 对应 case 行被标红
- 逻辑表达式如
a && b：若 a 为 false 后 b 永远不执行，则 b 的计算部分被视为“未覆盖分支”
直接点击报告中的文件，逐行查看哪些 if、else、case、?: 被标红，这就是最精准的起点。
检查条件表达式的真假组合是否穷尽
很多分支未覆盖，本质是测试用例没构造出让条件为 false（或特定值）的输入。尤其注意：
- 布尔变量：是否只测了
true，漏了false？比如if (isLoading)，测试里始终设isLoading = true - 空值/边界值：字符串空串
''、数组空数组[]、对象null/undefined、数字0、NaN是否都覆盖？ - 逻辑运算符短路：对
a && b，需分别设计a=true, b=true和a=false, b=任意的用例；对a || b，需有a=false, b=true的场景
用调试或日志临时“探针”验证执行流
如果报告不够直观，或逻辑嵌套深难以推理，可在可疑 if 前后加一行 console.log('reach if A') 或使用 debugger：
- 运行测试，观察哪些 log 没输出 → 对应分支确实没进
- 在未触发的
else或case内打 debugger，看测试运行时是否停住 - 注意：日志仅用于定位，确认问题后及时删除，避免污染测试输出
从函数入参和状态反推缺失路径
回到被测函数本身，列出所有影响分支的输入源：
- 函数参数（尤其是布尔、枚举、对象字段）
- 闭包变量或模块级状态（如配置 flag、全局开关）
- 外部依赖返回值（mock 时是否只 mock 了成功路径？）
例如函数 formatName(user) 中有 if (user?.role === 'admin')，就要确保测试传入的 user 至少包含 { role: 'admin' } 和 { role: 'user' } 两种情况。
