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

短視將來的BUG

很多軟件BUG都是設計人員或者實現人員的眼光短淺造成的，出名的例子就是“千年蟲”問題。

其他短視的BUG例子還有我們以前的身份證號碼，原來的15位的編號根本不符合一人一號的設計要求，重碼的現象相當嚴重。所以出現了18位號碼。

再如：中國移動開發了134號段的號碼?，F在又有了159號段。

靜態文檔的BUG

文檔BUG的定義很簡單，即說明模糊、描述不完整和過期的都屬于文檔BUG。

說明模糊特指無充分的信息判斷如何正確地處理事情。例如設計文檔中說明了對類實例方法的調用，卻沒說明邊界條件和特殊的調用順序。

描述不完整特指文檔信息不足以支持用戶完成某項工作。例如某套軟件的某一項操作有具體的前置條件，而客戶從文檔上并沒有獲取關于該前置操作的相關信息，客戶便認為軟件存在著BUG。

過期文檔本身就是錯的并且無法彌補，這種現象經常發生在后期對系統功能修改而沒有及時更新對應的文檔，造成了文檔的不一致性。

5、BUG的生命周期

BUG初始狀態（Unconfirmed&New態）

BUG分配狀態（Assigned態）

BUG重新分配狀態（Reassigned態）

BUG修復狀態（Resolved&Fixed態）

BUG驗證狀態（Vertified&Fixed態）

BUG重新打開狀態（Reopen態）

BUG關閉狀態（Closed&Fixed態）

6、BUG生命歷程的5種典型過程

（1）BUGStart--> BUG初始狀態 -->BUG分配狀態-->BUG重新分配狀態 --> BUG修復狀態 -->BUG驗證狀態 --> BUG關閉狀態

測試人員發現BUG并且將該BUG標記為Unconfirmed&New狀態，下一步測試人員在排除BUG的登記錯誤后，將該BUG置為Assigned狀態。實現人員接到該BUG通告

進行BUG確認，確認成功后該BUG狀態被置為Reassigned狀態，當實現人員修復BUG后該BUG置為Resolved&Fixed狀態。測試人員對實現人員修復后的BUG進行確

認測試，如果該BUG被正確修復了，那么其狀態被置為Closed&Fixed狀態，同時意味著該BUG的整個生命周期終結了

（2）BUGStart--> BUG修復狀態 --> BUG驗證狀態 -->BUG關閉狀態

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