為什么測(cè)試同學(xué)要進(jìn)行code review？

為什么測(cè)試同學(xué)要看代碼？這是很多開(kāi)發(fā)同學(xué)、甚至部分測(cè)試同學(xué)都很疑惑的一個(gè)問(wèn)題。其實(shí)在測(cè)試中結(jié)合進(jìn)行code review可以大大提升測(cè)試的質(zhì)量和效率。具體原因如下：

一、可以用更低的成本發(fā)現(xiàn)問(wèn)題

1. 很多時(shí)候一些簡(jiǎn)單的錯(cuò)誤通過(guò)code review就可以發(fā)現(xiàn)，比如計(jì)算錯(cuò)誤（計(jì)算一年或者三個(gè)月的公式是否正確）、數(shù)據(jù)類型（給金額的值用double類型來(lái)處理是否合適）、方法錯(cuò)誤（應(yīng)該用方法A卻用了方法B）、處理遺漏（某次改動(dòng)需要將某個(gè)方法的傳參A（a,b,c）改成A（a,b,d），但是可能并沒(méi)有改完）。

2. 了解代碼邏輯，在coding階段發(fā)現(xiàn)問(wèn)題，可以提高發(fā)現(xiàn)問(wèn)題的概率和降低修復(fù)問(wèn)題的成本。開(kāi)發(fā)的一些bug可能花幾分鐘看代碼就能看出來(lái)，而單純靠執(zhí)行測(cè)試還不一定能發(fā)現(xiàn)這個(gè)錯(cuò)誤。我們的目標(biāo)不是為了執(zhí)行測(cè)試而測(cè)試，而是要交付更高質(zhì)量的產(chǎn)品，并且是在更短的時(shí)間交付質(zhì)量更高的產(chǎn)品。

3. 設(shè)計(jì)的不合理也可以通過(guò)代碼看出來(lái)，特別是對(duì)新項(xiàng)目。有的開(kāi)發(fā)真的會(huì)認(rèn)為能把功能上線就行，有問(wèn)題后面再進(jìn)行重構(gòu)，所以前期設(shè)計(jì)時(shí)毫不注意，這是不對(duì)的。后面重構(gòu)的成本意想不到，而且技術(shù)債務(wù)越堆越多，想重構(gòu)都難下手，這樣的項(xiàng)目在提測(cè)時(shí)就應(yīng)該打回去。

二、讓測(cè)試更加精準(zhǔn)

測(cè)試同學(xué)在設(shè)計(jì)用例和執(zhí)行測(cè)試時(shí)如果知道代碼邏輯，就能更加精準(zhǔn)地基于風(fēng)險(xiǎn)進(jìn)行測(cè)試，并且能降低遺漏的風(fēng)險(xiǎn)。就舉功能測(cè)試的例子來(lái)說(shuō)，兩個(gè)同學(xué)測(cè)試同一個(gè)功能，甲僅基于原型進(jìn)行測(cè)試，乙除了原型還了解代碼邏輯，你覺(jué)得哪個(gè)同學(xué)測(cè)試覆蓋率會(huì)高一些。對(duì)某個(gè)入口，乙在測(cè)試中有針對(duì)性地對(duì)前提條件進(jìn)行組合測(cè)試，而甲只是基于業(yè)務(wù)經(jīng)驗(yàn)進(jìn)行測(cè)試，可能測(cè)試用例中大部分都是無(wú)效的。你可能會(huì)說(shuō)，如果給甲多一點(diǎn)時(shí)間，或者他經(jīng)驗(yàn)更豐富一些，他能寫(xiě)出最完美的測(cè)試用例和做最完善的測(cè)試。是的甲確實(shí)可以，但是考慮過(guò)效率和成本問(wèn)題嗎？

三、避免夾帶/誤刪而測(cè)試同學(xué)不知情

如果你沒(méi)看過(guò)代碼，開(kāi)發(fā)提測(cè)的代碼中可能夾帶/誤刪而未通知你呢。除了新項(xiàng)目測(cè)試時(shí)會(huì)全面一些，迭代項(xiàng)目的話大家的測(cè)試點(diǎn)都是基于改動(dòng)點(diǎn)和影響范圍的，不可能進(jìn)行全量測(cè)試，這時(shí)候開(kāi)發(fā)改動(dòng)了其它部分并且認(rèn)為這不影響功能（比如重構(gòu)），可能就沒(méi)在改動(dòng)點(diǎn)里說(shuō)明，那測(cè)試同學(xué)就很容易忽略了。而如果剛好這部分功能上線后出了問(wèn)題呢，難道測(cè)試同學(xué)真的不需要負(fù)責(zé)嗎？

四、上線版本管理

還有一種情況，如果上線的代碼不是你測(cè)試的代碼呢，可能是開(kāi)發(fā)同學(xué)的誤操作或者在即將上線時(shí)改了東西。雖然這可能涉及到版本管理和上線規(guī)范的問(wèn)題，但是測(cè)試同學(xué)通過(guò)檢查發(fā)布的版本中是不是這次測(cè)試的對(duì)象，開(kāi)發(fā)在上線前是不是又改了東西，就能避免這樣的問(wèn)題。作為測(cè)試同學(xué)，不能認(rèn)為我只確保測(cè)試階段的問(wèn)題，我發(fā)測(cè)試報(bào)告之后的意外情況就概不負(fù)責(zé)了。要對(duì)全流程進(jìn)行質(zhì)量把控，不能把測(cè)試工作僅限于測(cè)試本身，應(yīng)該多關(guān)注質(zhì)量管理問(wèn)題。

五、小需求通過(guò)code review可直接上線

有的小需求小改動(dòng)直接通過(guò)code review可以評(píng)估能否上線或者可以直接給產(chǎn)品驗(yàn)收的，就無(wú)需再執(zhí)行測(cè)試了。比如開(kāi)發(fā)修改配置文件、修改參數(shù)等，對(duì)這些改動(dòng)進(jìn)行測(cè)試是沒(méi)有太大必要的。當(dāng)然前提是需要準(zhǔn)確評(píng)估，雖然偶爾還是會(huì)出現(xiàn)測(cè)試同學(xué)評(píng)估可以直接上線，結(jié)果上線后出現(xiàn)線上問(wèn)題的情況。

那么怎么做code review呢？以下列出一些方法供大家參考。

1. 對(duì)大項(xiàng)目來(lái)說(shuō)，一般改動(dòng)非常多，而且可能涉及好幾個(gè)系統(tǒng)的改動(dòng)，詳細(xì)過(guò)代碼不太實(shí)際，可以提測(cè)后和開(kāi)發(fā)同學(xué)結(jié)對(duì)review一次代碼，主要是評(píng)估是否有其他改動(dòng)點(diǎn)，同時(shí)可以根據(jù)具體邏輯完善測(cè)試用例。然后測(cè)試階段開(kāi)發(fā)修復(fù)bug提交的代碼每一次都要過(guò)一遍，主要看這次改動(dòng)能否解決問(wèn)題，以及改動(dòng)方式和范圍會(huì)不會(huì)影響其他功能。
2. 對(duì)小需求/fix來(lái)說(shuō)，改動(dòng)的范圍不多，測(cè)試同學(xué)自己結(jié)合commit看改動(dòng)點(diǎn)即可。
對(duì)于新接手的開(kāi)發(fā)提交的代碼需要更加謹(jǐn)慎，除了看這次的改動(dòng)點(diǎn)，還需要留意是否不小心改了其它地方的代碼。

在review時(shí)要特別注意哪些方面呢？

1. 處理邏輯 在A出現(xiàn)了某個(gè)異常之后沒(méi)有進(jìn)行步驟B。
2. 數(shù)據(jù)類型 對(duì)某個(gè)值用int/double類型是否合適。
3. 公式計(jì)算
4. 可以關(guān)注規(guī)范問(wèn)題如打印日志的規(guī)范。

總而言之，code review基本是發(fā)現(xiàn)和修復(fù)問(wèn)題成本最低的方式，測(cè)試同學(xué)進(jìn)行code review可以大大提高測(cè)試質(zhì)量和效率，同時(shí)還可以提高編程能力。能有權(quán)限看代碼就要合理使用（可能有的公司會(huì)不給測(cè)試同學(xué)開(kāi)權(quán)限）當(dāng)然有權(quán)限也需要謹(jǐn)慎，不能做違反紀(jì)律法律和道德的事情。