4、静态测试方法：代码审查、走查、正式评审的技术要点
静态测试，说白了就是不跑代码也能找bug。很多人觉得这活儿没技术含量，其实恰恰相反。我做了十几年嵌入式软件测试，见过太多动态测试跑得欢、一上星就翻车的案例。原因很简单——有些问题，跑一万次也跑不出来，但人眼扫一遍就能发现。
今天咱们就聊聊静态测试的三种主流形式：代码审查、走查、正式评审。这三者各有各的用处，也各有各的坑。
4.1 代码审查：最基础也最容易被忽视
代码审查，就是一个人读代码，另一个人在旁边看着。听起来简单吧？但实际操作中，我见过太多人把这事儿干成了“走过场”。
技术要点：
- 审查清单要提前准备——别空着手去。我习惯把常见的航天级错误列成清单，比如：中断嵌套是否合理、临界区保护是否到位、看门狗喂食时机对不对。
- 每次审查不超过200行——人的注意力是有限的。超过这个量，效率直线下降。我曾经硬着头皮审了500行，结果后面300行基本是白看。
- 审查者要提前熟悉代码——别到了会上才第一次看代码。那样你只能发现拼写错误，发现不了逻辑问题。
4.2 走查：让代码“跑”在脑子里
走查和审查最大的区别是什么？走查需要模拟执行。说白了，就是一群人围着一份代码，手动模拟数据流和控制流。
技术要点：
- 选好测试用例——走查不是漫无目的地读代码。你得准备几个典型的输入场景，然后跟着数据走一遍。我一般会选：正常路径、边界条件、异常情况。
- 作者自己讲解——让写代码的人逐行解释。你想想看，如果他解释不清楚某段逻辑，那这段代码八成有问题。
- 记录所有疑问——走查过程中不要打断讲解，先把疑问记下来。等一轮走完再集中讨论。这样效率更高。
避坑指南：我曾经参与过一个走查，大家太投入了，对着一个变量命名争论了半小时。结果核心逻辑反而没时间看。记住：走查的目标是找bug，不是搞代码评审会。
4.3 正式评审：最严格也最耗时
正式评审，也叫Fagan评审。这是航天级软件最常用的方式。为什么？因为它有完整的流程、角色分工和度量标准。
角色分工：
| 角色 | 职责 | 注意事项 |
|---|---|---|
| 主持人 | 控制流程、确保不跑题 | 不能是作者本人 |
| 作者 | 提供材料、回答问题 | 不要辩解，先记录 |
| 评审员 | 提前审查、提出问题 | 3-5人最佳 |
| 记录员 | 记录所有问题和决议 | 会后要跟踪闭环 |
技术要点：
- 会前准备是关键——正式评审80%的工作在会前。评审员必须提前阅读材料，并提交初步意见。我见过有人开会时才第一次翻开文档，那基本等于浪费时间。
- 控制会议时长——我建议每次评审不超过2小时。超过这个时间，人的判断力会明显下降。如果材料太多，就分多次评审。
- 关注缺陷类型——航天级软件最怕的是逻辑错误和时序问题。别在代码格式上浪费太多时间。那些问题交给工具去处理。
重要提醒：正式评审的结论必须明确：通过、有条件通过、或重新评审。不要搞“差不多过了”这种模糊结论。航天软件容不得“差不多”。
4.4 三种方法的对比与选择
这三种方法不是互斥的，而是互补的。我一般这样用：
- 日常开发：用代码审查。快速、灵活，适合小范围修改。
- 关键模块：用走查。比如中断处理、任务调度、内存管理这些核心代码。
- 里程碑节点：用正式评审。比如需求确认、架构设计、关键算法。
为什么会这样？你想想看，代码审查成本最低，适合高频使用。走查需要多人参与，适合重要但不频繁的场景。正式评审最重，适合决定项目走向的关键节点。
我的经验：在航天项目中，我建议把三种方法组合使用。比如：每周一次代码审查，每月一次走查，每个里程碑一次正式评审。这样既能保证质量，又不会让团队太累。
4.5 常见误区与避坑指南
做了这么多年，我总结了几条最常见的坑：
- 误区一：静态测试可以替代动态测试——不行。静态测试找的是逻辑错误和设计缺陷，动态测试验证的是运行时行为。两者缺一不可。
- 误区二：人越多越好——不是。评审员超过7人，效率反而下降。我一般控制在3-5人。
- 误区三：只关注代码，不关注文档——航天级软件，文档和代码同等重要。需求文档、设计文档、测试文档都要纳入评审范围。
避坑指南：我曾经遇到过一个项目，代码审查做得很好，但需求文档没人看。结果代码实现了错误的需求，白白浪费了三个月。从那以后，我坚持“先审文档，再审代码”。
嗯，静态测试这块儿就聊到这儿。记住一句话：静态测试不是走过场，而是用最小的成本，发现最致命的问题。下一章咱们聊聊动态测试方法，到时候再细说。