一篇文章講清楚如何對軟件缺陷進行管理(2)

軟件的復雜性

程序員的錯誤

過于疲勞。讓程序員持續地開發，疲于奔命地完成某項任務，這時候的他認為休息比編碼質量有更重要的意義。

不守規矩。程序員按照自己心中的藍圖去描繪一個美麗的烏托邦，或者隨心所欲地使用自我編碼格式，完全不遵守項目的開發準則。

過于熱心。程序員經常犯這樣的錯誤，沒有經過嚴格的驗證和全局的考慮，任意修改設計并且認為這會產生更好的效果。

心不在焉。

需求變化

客戶并不了解需求變化所帶來的后果，就算知道了他們還是會堅持這么做。并且在客戶的眼里，他們只需要看到變化，卻從不考慮變化所需的額外工作時間。

需求變化的后果可能會造成重新設計或者日程調整，已完成工作、重做或者被完全拋棄，整個項目環境可能要因此改變等。

頻繁小的變化或者幾次重大的變化，項目各部分之間已知或者未知的依賴關系就會相互影響，從而導致更多問題的出現。

需求變化增加了項目操作的復雜性，產生了大量不確定因素，并且還可能打擊參與人員的工作積極性。一個需求變化頻繁的項目或者產品是沒有任何測試價值的。

時間壓力

時間是一種寶貴的資源。

所有軟件項目時間都需要被精確估算?？墒菉A雜著預計、猜測這些不穩定的因素，當最終期限迫近和關鍵時刻到來之際，錯誤也就跟著出現了。

文檔貧乏

貧乏或者差勁的文檔使得代碼維護和修改變得異常艱辛，其結果是帶來許多錯誤。

區分職業實現人員的方法并不是看他有幾年的編碼經驗，而在于其是否有良好的先文檔后實現的習慣。

文檔代表著一種特殊的記憶，沒有它的存在對人對己都不利。

軟件開發工具

總是希望通過更加先進的工具來避免BUG的出現，這就患上了典型的銀彈綜合癥。

開發工具可能使我們擺脫某些問題的出現，并且提高工作效率。實際上，現代的開發工具對整個軟件質量尤其是可靠性并沒有什么重大的影響。

3、Bug如何穿透測試

原文轉自：http://www.uml.org.cn/Test/201611161.asp