經(jīng)過在公司1年多的code review的經(jīng)驗回顧：原來有fisheye，開發(fā)提交代碼后旺旺通知測試工程師，并通過讀代碼來了解測試范圍，并發(fā)現(xiàn)代碼中的錯誤。
后來，最近半年的項目、日常測試過程中都是開發(fā)提交代碼后，測試和開發(fā)一起借用SVN工具等代碼版本控制工具，或Eclipse 等IDE進行Code Review。
這其中的一個轉(zhuǎn)變就是測試由被動接收消息，到主動查看SVN 的log看代碼變動。測試工程師的態(tài)度由被動變?yōu)橹鲃?，是個不小的進步。
目前看來，進行 Code Review 的目的或效果有：
1、讓測試熟悉所測產(chǎn)品的業(yè)務代碼，提升代碼的閱讀能力；
2、提早發(fā)現(xiàn)代碼里面的bug，低成本保障質(zhì)量，防患于未然；
3、提前預知并評估并確認測試范圍，減少測試工作量；
4、促進開發(fā)、測試間的溝通、交流和協(xié)作。
功能測試工程師參加code review提前做的一些準備：
1、簡單的編碼規(guī)范
2、Java編程的基本知識
經(jīng)過這Code Review的實踐，感覺Code Review目前比較適合我們工作的方式是：
階段 | Code Review的方式 |
準備 | 1、了解開發(fā)的UC設計，及基本的編碼知識；
2、了解基本的代碼的編碼規(guī)范；
3、確定code review的范圍：業(yè)務的核心代碼邏輯。 |
形式 | 項目：會議室+投影儀。日常：在開發(fā)/測試的位置上即可。 |
參加人員 | PM，PTM，相關開發(fā)工程師、測試工程師 |
可以采用的方法 | 1、編碼人員講解，其他開發(fā)、測試人員檢查。
2、代碼靜態(tài)檢測工具：Findbug
3、缺陷檢查表，但是這個太正式了，不一定需要。 |
注意點 | 1、限時：一般不要超過1個小時為宜；如果量大，最好分批review。
2、不要現(xiàn)場修改代碼，發(fā)現(xiàn)問題后，測試可以直接在bug管理平臺記錄。 |
產(chǎn)出 | 1、Bug記錄；
2、靜態(tài)分析錯誤報告；
3、結(jié)果：code review 是否通過。 |
比較合適的，并且目前使用的流程是：
