单元测试的盲区是什么？代码走查能补哪些短板？

单元测试覆盖率报告上写着92%，CI流水线全绿，代码合并完成，准备上线。然后入网安评的代码审计反馈回来了：不通过。

这种事在项目里不算少见。单元测试跑得再好，有些问题它就是抓不住。它们不在某个具体的函数里面，而是在函数和函数之间的缝隙里，在开发者想不到的角落里，在那些“谁会这么用”的地方。

单元测试与代码走查

一、单元测试的天然盲区

单元测试的本质是“给定输入，验证输出”。它验证的是单个模块的行为。但一个系统出问题，往往不是某个函数算错了数，而是这些情况：

模块A返回了正确的数据，模块B也能正确处理数据，但A和B对同一个字段的理解不一致。A认为status=1表示“已支付”，B认为status=1表示“待支付”。单元测试单独跑A和B都过，合在一起就出问题。

某个函数在测试环境里从来没被传入过空值，测试用例没设计这个场景。上线后用户一提交空表单，直接空指针异常，页面白屏。

代码里写死了一个配置，比如超时时间100毫秒。测试环境内网延迟不到10毫秒，跑得很好。上线后跨机房通信延迟200毫秒起步，所有请求超时。

这些问题，单元测试抓不住。它度量的是“代码被执行过”，不是“代码在异常和恶意场景下也扛得住”。

二、第三方代码走查能补什么？

代码走查是让人去看代码，而不是让机器去跑代码。它不运行程序，但恰恰因为不运行，它能发现那些“运行起来才暴露”的问题的上游原因。第三方机构做代码走查，补的是以下几块：

1.模块之间的接口一致性。

看A和B对同一个字段的理解是不是一样的，参数传递有没有歧义，异常分支有没有对齐。

2.边界和异常路径的防御。

空值、超长字符串、并发竞争、网络中断，代码里有没有对应的兜底逻辑。

3.配置的可移植性。

有没有硬编码的路径、端口、超时时间。换个环境还能不能跑。

4.业务逻辑层面的漏洞。

退款逻辑里对“部分退款”和“全额退款”的状态判断有没有歧义。支付流程里金额参数能不能被篡改。权限校验是在服务端做的还是只在前端做了。

5.硬编码的敏感信息。

密钥、密码、Token有没有直接写在代码里。这些东西单元测试永远不会去检查。

三、入网安评的代码审计是什么？

入网安评的代码审计依据的是GB/T 39412-2020《信息安全技术 代码安全审计规范》，重点盯的是：

输入验证与表示，用户输入有没有过滤就直接拼到了SQL语句里、命令执行函数里。

访问控制，敏感接口有没有做身份认证和权限判断，有没有水平越权或垂直越权的可能。

安全特性，日志和配置文件里有没有记录密码、身份证号。加密机制有没有缺陷，密钥是不是硬编码。

异常处理，异常被吞掉之后有没有记录日志，上下文信息够不够。

这些问题跟“代码有没有被执行过”没有关系。覆盖率再高，也不代表代码在这些维度上是安全的。

四、为什么必须是第三方？

入网安评这类准入动作，核心前提之一是出具方独立于开发和运营方。自研团队自己做走查，在评审语境里叫“第一方自查”，效力层级最低。技术规范书里明确写着“第三方源代码审计报告”，“第三方”这三个字本身就是门槛。

第三方测试机构

评审认的是“独立第三方+资质+可追溯记录”。章是真的、认可范围附件里有对应的标准、用例编号和执行记录齐全、原始数据能倒查，这套东西自查材料天生给不了。

另外，一份全自动工具扫一遍、没有人工复核、没有误报剔除、没有风险分级、没有复测结论的报告，内行翻两三页就能看出来。评标专家和验收专家现在专门看两样：有没有误报说明，有没有复测通过结论。区分“扫描”和“审计”的分水岭就在人工复核那一步。

日常开发中，内部自测保代码健康。关键节点，委托第三方做深度走查。聚焦高风险模块：支付、权限、数据隔离、核心业务逻辑。带着检查清单查，别凭感觉翻。报告要有闭环，缺陷修了没有、修完验了没有，必须有复测记录。

单元测试保的是“代码被执行过”，代码走查保的是“代码在异常和恶意场景下也扛得住”。覆盖率数字再漂亮，也替代不了人工对代码逻辑的深度审视，入网安评要的，恰恰是后者的证据链。

标签：代码审计、单元测试