前言

今天的話題，是所有測(cè)試員都會(huì)經(jīng)歷的，也多為此苦惱過。墨白借此談?wù)勛约旱目捶ǎ磺蠼鉀Q現(xiàn)狀，只希望大家看完此文后能少一些苦惱。

現(xiàn)狀分析

之前，墨白身邊一位測(cè)試?yán)先颂崃艘粋€(gè)打印文字溢出的缺陷，但該缺陷的負(fù)責(zé)人，一個(gè)年輕的程序員以項(xiàng)目臨近上線沒時(shí)間修改，且該缺陷影響很小而駁回，態(tài)度強(qiáng)硬（強(qiáng)硬的訴苦），那位測(cè)試專家從開始的堅(jiān)持到最后無奈妥協(xié)，讓墨白感觸良多。

程序員為什么不愿意修改bug？

無非是沒時(shí)間，問題太小，重現(xiàn)不了，理解不了，在實(shí)際環(huán)境中不太可能發(fā)生，問題只出現(xiàn)在沒有人用的非常特殊的設(shè)備配置上 ，改正缺陷的風(fēng)險(xiǎn)太大（特別是臨近封版），不會(huì)影響程序的實(shí)際用戶等。

我們測(cè)試人員為什么苦惱？

可能是覺得封版之前bug就應(yīng)該全部解決（強(qiáng)迫癥），也可能是覺得程序員沒有理解bug的嚴(yán)重性，也許是bug明顯違反規(guī)范，也可能是覺得缺陷肯定會(huì)影響到用戶。

我們?yōu)槭裁措y以說服程序員去修改那些bug？

說一說我看到的：測(cè)試員過于執(zhí)著（bug并非必須修改），測(cè)試員不清楚說服程序員的技巧，測(cè)試員看輕自己（程序員一旦強(qiáng)勢(shì)，測(cè)試員就低聲下氣），測(cè)試員技術(shù)水平低（不清楚修改bug的成本，可能只是加一個(gè)字段就能修復(fù)，開發(fā)說成本大，測(cè)試員就以為真的很大）。

應(yīng)對(duì)措施

應(yīng)對(duì)措施本應(yīng)跟先將問題分類，分析根源之后再一一作答。不過本文不是嚴(yán)謹(jǐn)?shù)膶W(xué)術(shù)報(bào)告，只談幾點(diǎn)一般性的措施。

如何說服開發(fā)改正bug？

· 解釋問題會(huì)怎樣影響產(chǎn)品的正常使用？

· 會(huì)破壞什么數(shù)據(jù)？

· 用戶如何經(jīng)常遇到這個(gè)問題？

· 市面上類似產(chǎn)品的有關(guān)評(píng)論

· 指出類似的問題給客戶帶來的麻煩

· 多引用技術(shù)支持收集的數(shù)據(jù)

· 以前的版本通過了這個(gè)功能的測(cè)試

· 與其他項(xiàng)目干系人溝通。找出如果程序錯(cuò)誤不修改受影響最大的人（或修改后受益的人），確定程序錯(cuò)誤會(huì)給他們帶來多大麻煩。讓關(guān)心這個(gè)模塊的人去說服。

· 列舉一些場(chǎng)景，說明合理的用戶在合理地使用程序時(shí)會(huì)遇到的程序錯(cuò)誤，或產(chǎn)生的疑問。

· 補(bǔ)充做一些后續(xù)測(cè)試，尋找該程序錯(cuò)誤更嚴(yán)重的后果，或?qū)ふ冶仍阱e(cuò)誤報(bào)告中所描述的更廣環(huán)境下出現(xiàn)的情況。

補(bǔ)充 　

1、對(duì)于上面最后一點(diǎn)做點(diǎn)補(bǔ)充：如果程序員不修改某bug而我們決定反駁，不要完全依賴自己最初測(cè)試報(bào)告中的語(yǔ)言和信息。盡可能做一些補(bǔ)充測(cè)試，或列舉更有效的例子，否則不僅浪費(fèi)自己的時(shí)間，而且損害自己的信譽(yù)，影響自身的說服力。

2、不必堅(jiān)持修改所有bug。項(xiàng)目經(jīng)理可能會(huì)因?yàn)轱L(fēng)險(xiǎn)、費(fèi)用等方面的原因，拒絕修改某些bug，這種情況下，我們測(cè)試員不需要堅(jiān)持修改全部缺陷，除非能說明某缺陷可能引入的嚴(yán)重風(fēng)險(xiǎn)。

另外，以下措施有助于推動(dòng)bug的解決：

1、養(yǎng)成良好的報(bào)告編寫習(xí)慣：比如在報(bào)告中描述問題出現(xiàn)的多種配置（需核實(shí)），或者在報(bào)告中預(yù)測(cè)某種可能并提供相關(guān)信息（特別是難以復(fù)現(xiàn)的bug） 。好的錯(cuò)誤報(bào)告會(huì)推動(dòng)問題的修正。

2、先等一等，在評(píng)審時(shí)看看大家反映，以靜制動(dòng)，提供補(bǔ)充信息。

3、多用事實(shí)和數(shù)據(jù)說話，例如“某個(gè)類似系統(tǒng)也有這個(gè)問題，客戶因?yàn)槟莻€(gè)問題，對(duì)程序的意見很大，因?yàn)榭蛻羝骄恐芤速M(fèi)XX時(shí)間在上面”

4、學(xué)習(xí)編程，理解bug產(chǎn)生的原因，助于寫出更好的報(bào)告，以及理解bug修復(fù)成本。

注意點(diǎn)

1、關(guān)于利用bug管理系統(tǒng)監(jiān)視程序員的表現(xiàn)。有的測(cè)試經(jīng)理嘗試用bug跟蹤數(shù)據(jù)來促使程序員修改bug，比如利用數(shù)據(jù)反饋某程序員是否存在大量的bug未修改，或是否修改時(shí)間過長(zhǎng)，或是否總是推遲修改。是否應(yīng)該推行這種制度這里不做評(píng)論，不過建議推行時(shí)需注意引導(dǎo)程序員的情緒，否則很容易引起某些程序員的反感，他們會(huì)在某些時(shí)候大肆放大測(cè)試員的無能，或者發(fā)表不利于測(cè)試部的言論。不過這也是正常的，bug管理工具只要被用于行政或人事管理，而不是技術(shù)管理，就會(huì)產(chǎn)生這些問題。

2、關(guān)閉bug的權(quán)限應(yīng)控制在測(cè)試員手中。除非經(jīng)過測(cè)試員的驗(yàn)證，否則bug都不能閉環(huán)。在某些情況下，程序員會(huì)將未修復(fù)的bug置為“延期修改 ”、“非程序錯(cuò)誤不予修改”“重復(fù)缺陷不予修改 ”，測(cè)試員需要且有義務(wù)對(duì)此提出質(zhì)疑。

3、盡量避免“延期修改”變?yōu)椤坝啦恍薷摹薄Ｔ诤芏喙局校琤ug標(biāo)記為“延期修改”即意味著“永不修改”。為避免這種情況，有一種可行的措施是在下一版本做項(xiàng)目范圍評(píng)審時(shí)即提出這些缺陷，那時(shí)候的進(jìn)度壓力最小，而且項(xiàng)目經(jīng)理也最理智、最清醒。另外，發(fā)現(xiàn)“延期修改”的bug后，若持反對(duì)意見，建議盡快跟測(cè)試經(jīng)理或者項(xiàng)目經(jīng)理進(jìn)行溝通。

4、bug修改后盡快驗(yàn)證，回歸不通過后盡快跟程序員溝通，否則時(shí)間耽誤越久，程序員記得的內(nèi)容越少。

5、如果bug多次回歸不通過，或在臨近封版時(shí)發(fā)現(xiàn)嚴(yán)重缺陷，不僅要在缺陷管理工具中記錄，更應(yīng)該直接找到相應(yīng)的程序員進(jìn)行溝通。

最后感謝每一個(gè)認(rèn)真閱讀我文章的人，看著粉絲一路的上漲和關(guān)注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對(duì)于【軟件測(cè)試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉(cāng)庫(kù)，這個(gè)倉(cāng)庫(kù)也陪伴上萬(wàn)個(gè)測(cè)試工程師們走過最艱難的路程，希望也能幫助到你!

在我的QQ技術(shù)交流群里（技術(shù)交流和資源共享，廣告勿擾）

可以自助拿走，群號(hào)：310357728群里的免費(fèi)資料都是筆者十多年測(cè)試生涯的精華。還有同行大神一起交流技術(shù)哦

如果對(duì)你有一點(diǎn)點(diǎn)幫助，各位的「點(diǎn)贊」就是小編創(chuàng)作的最大動(dòng)力，我們下篇文章見！

?