最近參與了幾個(gè)需求開發(fā)，BUG很少，有些需求沒BUG，有些才一個(gè)BUG，搞的測(cè)試人員還發(fā)牢騷說：

“

大佬，你負(fù)責(zé)的項(xiàng)目，bug都少的可憐，叫俺怎么活？

哈哈，其實(shí)測(cè)試人員要感謝我才對(duì)，因?yàn)殚_發(fā)人員的代碼質(zhì)量高了，會(huì)極大的提升測(cè)試人員測(cè)試的速度，因?yàn)闇y(cè)試過程中非常順暢，沒啥阻礙的東西。

設(shè)想一下，如果提測(cè)后，代碼BUG滿天飛，測(cè)試人員不斷的提BUG單，開發(fā)人員不斷的修復(fù)，一不小心還可能修復(fù)出其他BUG來呢，中間還穿插各種各樣不必要的討論，這些都嚴(yán)重影響了測(cè)試進(jìn)度，當(dāng)然也嚴(yán)重影響了測(cè)試人員和開發(fā)人員的心情。

因此：

最好是在開發(fā)階段就認(rèn)真起來，把代碼寫好，以求后續(xù)流程的順暢性。

那么如何做到寫代碼的時(shí)候，盡量避免BUG呢？趁這個(gè)機(jī)會(huì)也跟大家分享一下我的做法。

與產(chǎn)品經(jīng)理和經(jīng)驗(yàn)豐富的測(cè)試人員多溝通

需求階段

產(chǎn)品經(jīng)理正式開需求會(huì)議之前，一般都會(huì)先把需求文檔發(fā)出來，這個(gè)時(shí)候，開發(fā)人員一定要認(rèn)真的看并仔細(xì)分析，每個(gè)細(xì)節(jié)都要多想想，有疑問的地方及時(shí)跟產(chǎn)品經(jīng)理溝通。

另外，看需求的時(shí)候，最好跟熟悉業(yè)務(wù)的測(cè)試人員多多溝通，測(cè)試人員是對(duì)以往需求最清楚的人，能看到其他人看不到的細(xì)節(jié)。像我自己就經(jīng)常從測(cè)試人員那里，聽到了一些要命的而我卻忽略掉的需求細(xì)節(jié)。

代碼設(shè)計(jì)階段

我一般想好方案后，第一時(shí)間就會(huì)去找技術(shù)老大和熟悉業(yè)務(wù)的測(cè)試人員。

能做到技術(shù)老大，他的思路一般都是比較廣的，多聽聽他的意見是沒錯(cuò)的。另外，也要去找測(cè)試人員，有些開發(fā)可能認(rèn)為，技術(shù)方案怎么會(huì)去找測(cè)試人員商量呢？

請(qǐng)不要忘記，部分測(cè)試人員是對(duì)整個(gè)公司的大部分應(yīng)用和需求和業(yè)務(wù)都了如指掌的人，能清楚的知道系統(tǒng)與系統(tǒng)之間如何交互，整個(gè)鏈路是怎么走的，整個(gè)上下文又是怎么樣的。

當(dāng)開發(fā)人員的設(shè)計(jì)方案出來后，表面上看起來，完美無瑕，其實(shí)可能存在影響上下游系統(tǒng)的隱患。而多與熟悉業(yè)務(wù)的測(cè)試人員溝通，則可以盡早把這些問題暴露出來，減少影響和損失。

代碼開發(fā)階段

必須寫單元測(cè)試

單元測(cè)試的重要性，無論怎么強(qiáng)調(diào)都不為過。它是用于測(cè)試自己寫的代碼是否符合預(yù)期的極好的手段。尤其是在創(chuàng)業(yè)公司，需求都非常多，經(jīng)常需要改代碼，如果沒有一套完整的單元測(cè)試來回歸驗(yàn)證代碼，分分鐘由于新寫了代碼而破壞了原有的代碼功能。

單元測(cè)試可以讓開發(fā)人員放心大膽的改代碼，無需擔(dān)心影響之前的功能。

但是單元測(cè)試一定要認(rèn)真負(fù)責(zé)的寫，盡量覆蓋主流程業(yè)務(wù)。那種隨便寫寫，隨便驗(yàn)證的單元測(cè)試，不寫也罷，沒啥意義，還浪費(fèi)時(shí)間。

寫單元測(cè)試經(jīng)常犯的另外一個(gè)錯(cuò)誤是，由于急著改bug，忘記同時(shí)改單元測(cè)試了，導(dǎo)致之前跑過的單元測(cè)試，后面又跑不過了，這個(gè)是絕對(duì)不允許的，單元測(cè)試也必須持續(xù)維護(hù)的。

另外有一個(gè)點(diǎn)就是，開發(fā)人員提測(cè)后，理論上就可以接另外一個(gè)開發(fā)任務(wù)了，如果開發(fā)階段BUG太多的話，則會(huì)影響下一個(gè)開發(fā)任務(wù)的進(jìn)度。這個(gè)是開發(fā)經(jīng)理不愿意看到的。

不斷的重復(fù)的看自己的代碼

代碼提測(cè)前，要多看幾次，有時(shí)候能看出一些隱藏的代碼BUG的，有時(shí)候也會(huì)覺得，昨天寫的代碼，真垃圾，還是有蠻多代碼要優(yōu)化的。

在看代碼的時(shí)候，最好順便做到下面幾點(diǎn)：

代碼收攏性要強(qiáng)，不要存在那種類似的代碼滿天飛，能封裝起來的就封裝；

業(yè)務(wù)代碼一定要有必要的準(zhǔn)確的注釋，千萬別信那套方法名命名好了就能解釋清楚的鬼話；

代碼抽象層次要一致，不要跳躍，例如，你的業(yè)務(wù)方法，操作其他模塊業(yè)務(wù)表的時(shí)候，都是調(diào)用Service類的，就不要突然冒出個(gè)直接使用xxxxxMapper去操作數(shù)據(jù)庫(kù)表了；

流程性比較強(qiáng)，最好用 //1、 ?//2、 ?//3、 標(biāo)注一下，這樣會(huì)更加清晰。

必須做開發(fā)聯(lián)調(diào)

當(dāng)你的業(yè)務(wù)接口開發(fā)完成后，一定要做開發(fā)者之間的聯(lián)調(diào)。聯(lián)調(diào)是端對(duì)端的，就算其中一方做的再好，沒有聯(lián)調(diào)，還是會(huì)出問題。

開發(fā)聯(lián)調(diào)通過后，建議叫產(chǎn)品過來提前驗(yàn)收

一般來說，功能測(cè)試通過后，上線前，會(huì)讓產(chǎn)品先驗(yàn)收一下。但是我則喜歡開發(fā)聯(lián)調(diào)完后，就先拉上產(chǎn)品經(jīng)理，先大概驗(yàn)收一下。不要小看這一步，經(jīng)常能提早發(fā)現(xiàn)一些問題的。

開發(fā)人員列出改動(dòng)了哪些已有接口

列出改動(dòng)細(xì)節(jié)有個(gè)好處：

讓測(cè)試人員更加有針對(duì)性的做回歸測(cè)試。雖說每次項(xiàng)目上線前，測(cè)試人員會(huì)做回歸測(cè)試，但是很難做到全面回歸，而沒有回歸到的場(chǎng)景，到線上可能就會(huì)造成bug。如果開發(fā)人員能列出改動(dòng)點(diǎn)，則測(cè)試人員可以重點(diǎn)且認(rèn)真的回歸。

已有接口已經(jīng)是在線上驗(yàn)證過的接口，如果改動(dòng)了，是一定要做兼容性測(cè)試的，既要保證新功能可用，也要保證不影響舊功能。

盡最大努力,保證開發(fā)提測(cè)不delay

對(duì)于那種上線日期已經(jīng)定了，一般會(huì)采用倒排的方式，推導(dǎo)出，開發(fā)哪個(gè)時(shí)間點(diǎn)提測(cè)，測(cè)試人員什么時(shí)候介入測(cè)試，測(cè)試多少天等，都會(huì)安排好。

如果開發(fā)提測(cè)delay了，留給測(cè)試人員的測(cè)試時(shí)間就縮短了，會(huì)給測(cè)試人員造成很大的壓力，壓力一大，則更容易出錯(cuò)，直接影響測(cè)試質(zhì)量，也就影響了上線質(zhì)量。

當(dāng)出現(xiàn)了提測(cè)delay的苗頭，開發(fā)人員一定要及時(shí)反饋出來，由組長(zhǎng)或者經(jīng)理協(xié)調(diào)資源，進(jìn)行補(bǔ)救。

這里要重點(diǎn)強(qiáng)調(diào)的是，一個(gè)功能的提測(cè)，是涉及到前端、后端的，你想自己加班到深夜趕進(jìn)度也是沒用的，一定要以最快的速度，將問題暴露出來，由上級(jí)去協(xié)調(diào)一下，留下相關(guān)的人一起奮斗一下，盡量保證按時(shí)提測(cè)。

測(cè)試人員測(cè)試階段-看日志

不要以為提測(cè)后，就沒自己啥事了，最好還是抽少許時(shí)間，去測(cè)試機(jī)器上看看日志，觀察和分析一下入?yún)⒑统鰠⒌?#xff0c;看看有沒有什么異常或者不合理的數(shù)據(jù)。

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的硬核！尽量避免 BUG 手法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。