為什么測試同學(xué)要進(jìn)行code review？
為什么測試同學(xué)要看代碼？這是很多開發(fā)同學(xué)、甚至部分測試同學(xué)都很疑惑的一個問題。其實在測試中結(jié)合進(jìn)行code review可以大大提升測試的質(zhì)量和效率。具體原因如下：一、可以用更低的成本發(fā)現(xiàn)問題
1. 很多時候一些簡單的錯誤通過code review就可以發(fā)現(xiàn)，比如計算錯誤（計算一年或者三個月的公式是否正確）、數(shù)據(jù)類型（給金額的值用double類型來處理是否合適）、方法錯誤（應(yīng)該用方法A卻用了方法B）、處理遺漏（某次改動需要將某個方法的傳參A（a,b,c）改成A（a,b,d），但是可能并沒有改完）。
2. 了解代碼邏輯，在coding階段發(fā)現(xiàn)問題，可以提高發(fā)現(xiàn)問題的概率和降低修復(fù)問題的成本。開發(fā)的一些bug可能花幾分鐘看代碼就能看出來，而單純靠執(zhí)行測試還不一定能發(fā)現(xiàn)這個錯誤。我們的目標(biāo)不是為了執(zhí)行測試而測試，而是要交付更高質(zhì)量的產(chǎn)品，并且是在更短的時間交付質(zhì)量更高的產(chǎn)品。
3. 設(shè)計的不合理也可以通過代碼看出來，特別是對新項目。有的開發(fā)真的會認(rèn)為能把功能上線就行，有問題后面再進(jìn)行重構(gòu)，所以前期設(shè)計時毫不注意，這是不對的。后面重構(gòu)的成本意想不到，而且技術(shù)債務(wù)越堆越多，想重構(gòu)都難下手，這樣的項目在提測時就應(yīng)該打回去。
二、讓測試更加精準(zhǔn)
測試同學(xué)在設(shè)計用例和執(zhí)行測試時如果知道代碼邏輯，就能更加精準(zhǔn)地基于風(fēng)險進(jìn)行測試，并且能降低遺漏的風(fēng)險。就舉功能測試的例子來說，兩個同學(xué)測試同一個功能，甲僅基于原型進(jìn)行測試，乙除了原型還了解代碼邏輯，你覺得哪個同學(xué)測試覆蓋率會高一些。對某個入口，乙在測試中有針對性地對前提條件進(jìn)行組合測試，而甲只是基于業(yè)務(wù)經(jīng)驗進(jìn)行測試，可能測試用例中大部分都是無效的。你可能會說，如果給甲多一點時間，或者他經(jīng)驗更豐富一些，他能寫出最完美的測試用例和做最完善的測試。是的甲確實可以，但是考慮過效率和成本問題嗎？
三、避免夾帶/誤刪而測試同學(xué)不知情
如果你沒看過代碼，開發(fā)提測的代碼中可能夾帶/誤刪而未通知你呢。除了新項目測試時會全面一些，迭代項目的話大家的測試點都是基于改動點和影響范圍的，不可能進(jìn)行全量測試，這時候開發(fā)改動了其它部分并且認(rèn)為這不影響功能（比如重構(gòu)），可能就沒在改動點里說明，那測試同學(xué)就很容易忽略了。而如果剛好這部分功能上線后出了問題呢，難道測試同學(xué)真的不需要負(fù)責(zé)嗎？
四、上線版本管理
還有一種情況，如果上線的代碼不是你測試的代碼呢，可能是開發(fā)同學(xué)的誤操作或者在即將上線時改了東西。雖然這可能涉及到版本管理和上線規(guī)范的問題，但是測試同學(xué)通過檢查發(fā)布的版本中是不是這次測試的對象，開發(fā)在上線前是不是又改了東西，就能避免這樣的問題。作為測試同學(xué)，不能認(rèn)為我只確保測試階段的問題，我發(fā)測試報告之后的意外情況就概不負(fù)責(zé)了。要對全流程進(jìn)行質(zhì)量把控，不能把測試工作僅限于測試本身，應(yīng)該多關(guān)注質(zhì)量管理問題。
五、小需求通過code review可直接上線
有的小需求小改動直接通過code review可以評估能否上線或者可以直接給產(chǎn)品驗收的，就無需再執(zhí)行測試了。比如開發(fā)修改配置文件、修改參數(shù)等，對這些改動進(jìn)行測試是沒有太大必要的。當(dāng)然前提是需要準(zhǔn)確評估，雖然偶爾還是會出現(xiàn)測試同學(xué)評估可以直接上線，結(jié)果上線后出現(xiàn)線上問題的情況。
那么怎么做code review呢？以下列出一些方法供大家參考。
1. 對大項目來說，一般改動非常多，而且可能涉及好幾個系統(tǒng)的改動，詳細(xì)過代碼不太實際，可以提測后和開發(fā)同學(xué)結(jié)對review一次代碼，主要是評估是否有其他改動點，同時可以根據(jù)具體邏輯完善測試用例。然后測試階段開發(fā)修復(fù)bug提交的代碼每一次都要過一遍，主要看這次改動能否解決問題，以及改動方式和范圍會不會影響其他功能。
2. 對小需求/fix來說，改動的范圍不多，測試同學(xué)自己結(jié)合commit看改動點即可。
對于新接手的開發(fā)提交的代碼需要更加謹(jǐn)慎，除了看這次的改動點，還需要留意是否不小心改了其它地方的代碼。
在review時要特別注意哪些方面呢？
1. 處理邏輯 在A出現(xiàn)了某個異常之后沒有進(jìn)行步驟B。
2. 數(shù)據(jù)類型 對某個值用int/double類型是否合適。
3. 公式計算
4. 可以關(guān)注規(guī)范問題如打印日志的規(guī)范。
總而言之，code review基本是發(fā)現(xiàn)和修復(fù)問題成本最低的方式，測試同學(xué)進(jìn)行code review可以大大提高測試質(zhì)量和效率，同時還可以提高編程能力。能有權(quán)限看代碼就要合理使用（可能有的公司會不給測試同學(xué)開權(quán)限）當(dāng)然有權(quán)限也需要謹(jǐn)慎，不能做違反紀(jì)律法律和道德的事情。
頁:
[1]