在一個團隊中, 如果沒有code review, 直接允許開發提交代碼到版本庫並部署環境, 那么在正式開始測試之前的代碼走查就非常有必要了。
這里說的走查不是使用工具在持續化集成之前進行代碼規范的檢查, 而是根據PRD文檔, 驗證代碼的實現是否符合需求描述。
在開始測試之前我都會先同步開發的代碼, 然后詢問開發人員具體有哪些接口涉及到本次功能提測, 之后從每個接口入手, 查看業務邏輯層與數據庫訪問層代碼, 看其實現是否與需求相符, 並找出一些明顯的錯誤。這樣做的目的只有一個, 那就是節省時間。其實這些問題應該在開發提交代碼前由code review發現的， 但是由於團隊剛剛組建，沒有形成一套合理的流程，而且時間非常有限。其實這些惡性bug都是可以在測試階段發現的，而且是在冒煙測試階段就能輕易發現，但是問題還是時間緊，不如先走查一遍代碼，將錯誤處與開發溝通，之后提bug，將具體哪行哪個位置的問題標出，這樣可以大大加快測試進展，起碼可以快速使得測試通過冒煙階段，節約一些時間。
下面就舉幾個栗子說明我在走查階段發現的幾個明顯的問題：
首先看這段代碼：
在數據庫讀取的時候查詢的是UNSETTLED類型的賬單，但查詢結果直接賦值給了名為settledBills的引用，好吧，之后的代碼就都是錯的了。
再舉個栗子：
這里調用了dubbo服務接口，對接另一個系統，傳入的枚舉UNSETTLE_BILL_REPAY，代表償還未出賬單的意思，但是這個代碼是用來償還已出賬單的service層代碼。。。
其實這種問題在我們項目的代碼里發現的很多很多，在兩個系統對接的時候，兩方開發人員幾乎不溝通，看哪個接口像就直接調用了，之后就都推給測試去測了，發現了問題再改，發現不了就呵呵了，不說了，都是淚。。。
總結一下，面對不靠譜、不溝通的開發，幾乎沒有管理的項目，一切靠測試手動發現問題實在是鴨梨山大啊。