测试人员参与代码检视的收益：
a）测试人员可以在早期就能够熟知系统，提前发现代码中的BUG；
b）提高测试工程师阅读代码和写代码能力；
c）测试工程师的经验积累后，可以避免一些很常见，很普通低级的错误；
d）测试取得话语权，促进开发与测试的更多平等沟通；
e）对于开发新员工的代码，收益会加倍（新员工容易犯业务上的低级错误）。
第零步：（比如新参与某系统的测试）
a）学习业务知识；
b）学习系统整体架构；
c）开发同学讲解设计架构、代码结构；
d）熟悉使用系统，找到阅读代码下手点：从日志、业务入口、SqlMap等；
e）从流程或者数据流阅读下去，然后一步步深入到代码中。
第一步：（code review准备）
a）当需求已经确定，测试同学需要参与方案的讨论；
b）开发开始编写代码，测试进行测试用例设计；
c）当开发某个类或者功能或者方法已经基本稳定，让开发串讲实现方式（避免出现实现方式不合理）；
d）测试同学可以开始review开发的代码，同时补充或者去重复测试用例（story或者sdv测试用例）。
第二步：（code review进行）
a）对代码的规范进行检视；
b）对代码的可测试性进行检视；
c）从业务场景的角度去review代码，如果实现存在的问题，那基本上可以发现；
d）对于发现的问题，建议分时段给开发，否则会打乱开发的写代码节奏；
e）如果你还不懂设计、不懂架构，那么可以从是否浪费CPU、是否浪费内存的角度看代码。
第三步：（code review后）
a）转测试后，应该不出现实现方案不合理的情况；
b）有结果统计，这个迭代review的记录数，可以横向比较；
c）迭代总结，开发与测试一起进行经验教训分享。
