经过在公司1年多的code review的经验回顾：原来有fisheye，开发提交代码后旺旺通知测试工程师，并通过读代码来了解测试范围，并发现代码中的错误。
后来，最近半年的项目、日常测试过程中都是开发提交代码后，测试和开发一起借用SVN工具等代码版本控制工具，或Eclipse 等IDE进行Code Review。
这其中的一个转变就是测试由被动接收消息，到主动查看SVN 的log看代码变动。测试工程师的态度由被动变为主动，是个不小的进步。
目前看来，进行 Code Review 的目的或效果有：
1、让测试熟悉所测产品的业务代码，提升代码的阅读能力；
2、提早发现代码里面的bug，低成本保障质量，防患于未然；
3、提前预知并评估并确认测试范围，减少测试工作量；
4、促进开发、测试间的沟通、交流和协作。
功能测试工程师参加code review提前做的一些准备：
1、简单的编码规范
2、Java编程的基本知识
经过这Code Review的实践，感觉Code Review目前比较适合我们工作的方式是：
阶段 | Code Review的方式 |
准备 | 1、了解开发的UC设计，及基本的编码知识；
2、了解基本的代码的编码规范；
3、确定code review的范围：业务的核心代码逻辑。 |
形式 | 项目：会议室+投影仪。日常：在开发/测试的位置上即可。 |
参加人员 | PM，PTM，相关开发工程师、测试工程师 |
可以采用的方法 | 1、编码人员讲解，其他开发、测试人员检查。
2、代码静态检测工具：Findbug
3、缺陷检查表，但是这个太正式了，不一定需要。 |
注意点 | 1、限时：一般不要超过1个小时为宜；如果量大，最好分批review。
2、不要现场修改代码，发现问题后，测试可以直接在bug管理平台记录。 |
产出 | 1、Bug记录；
2、静态分析错误报告；
3、结果：code review 是否通过。 |
比较合适的，并且目前使用的流程是：
