多年的測試經驗中，經常發現有這么一種現象：總有些提了的bug不能順利的被修復。這些bug往往有4個走向： 1.在被發現的版本中最終被解決，但中途花費較多周折。
2.有計劃的在后續的版本中被解決。
3.決定永遠不修復，卻變成潛在的炸彈，在后續版本中被迫修復。
4.決定永遠不修復，至今為止也一直沒有被修復。
近期對我們做過的項目做過一次較大的統計，統計嚴重程度中等及以上的缺陷，這四種走向第一種占到了50%左右，第二、三種各占20%，最后一種約占了10%。
這些沒有被修改的bug帶來的負面影響有：
1.大部分時候最終還得改了，是被迫改，項目組疲憊，在領導和客戶那里都落不了好。
2.這些bug積累到一定數量，發現系統快不能要了，得大規模重構，重構的過程不要太痛苦，最后沒準就推倒重來了（見過n個這樣這樣的案例了）。
3.拖得越久改起來越難，最近的一個案例是：某項目為了趕進度，使用了一個較低版本的底層組件，當時識別出低版本的底層組件特性有缺失，測試人員提出了功能bug，項目組決定忍了。一拖就是2年。結果項目很成功，越來越重要，與之交互的其它系統越來越多，但這個底層組件缺失特性的短板就越來越痛。最后不得不進行修復
工作（高版本組件替換），但發現由于代碼耦合太緊，已經不是一個月兩個月能搞定的事情了。大規模重構還是推到重來現在成了一個難題。
4.每天跟帶著太多毛病的系統朝夕相對，是殺死所有干系人士氣的慢性毒藥。當你的潛意識認為你在做的東西是一團shit，還有毛激情？想一想破窗效應馬上能夠反應過來。
怎樣降低大量bug長期遺留的現象呢？我有如下的一些建議：
1.提升內建質量。這句話高大上，內涵也很豐富，從軟件架構，開發過程，各種技術應用等各方面都能夠找到無數的提升點避免系統存在太多遺留bug，展開說真的要一本書了。從里邊抽取出最重要的一條精神：bug被發現的越早，修改遇到的阻力越小。
2.定期bug掃除，這其實是測試應該主動提出來的事情，并且應該讓這件事兒變成項目組的例行活動。其實如果做好了，樂趣還是很多的，效果也非常好。
3.如果是大型系統，或者項目群，很多bug是跨項目組的，這時候組織級的機制就要建立起來了，必要的時候需要跟考核制度掛鉤。這樣有一些三不管的重要bug才能被最終解決。
4.有些bug還真得睜一只眼閉一只眼了，約有10%的頑疾會這樣。難改，影響范圍有限。對這類bug最有效的辦法是：挖雷難，我給它上邊插個旗子讓使用者離他遠點兒好不好？有時候處理這些bug挺藝術的，運維，客服，售前，售后，都得長點兒心眼。