1、BUG的影響

精神的摧殘

誰會願意得到垃圾團隊的稱號？

BUG有著無窮的生命力，你會很悲觀，認為自己已經無能為力了，這種情緒會在長時間的工作後加重。

大家都厭倦重複處理相同的問題，測試人員也已經煩透了長長的BUG列表，精神壓力與日俱增。

低生產率和低等產品質量，耗費了大量的資源。有時管理層並沒有意識到發生了什麼問題，為了保證專案的最終交付，他們為專案輸送了源源不斷的新人，由於培訓無法跟進，最終導致了整個產品開發的崩潰。

形象的損失

如果某些公司的某些產品出現了重大BUG，勢必會牽連降低公司的形象，至少我們有理由相信該公司的產品質量不穩定。

電子商務更能體現形象，如果網站很長時間才能響應客戶服務，或者出現了丟失訂單、混亂訂單的現象，這樣的網站會很快被客戶拋棄，客戶一旦離開就很難回頭。

形象的損失帶來的後果是巨大的，產品不被市場所認可，甚至公司也不再被市場所認可。

財富的流失

產品的開發需要資金，公司的運轉需要資金，壞的市場形象需要公司花費更多的資金來挽回聲譽。

有BUG的軟體產品後期維護也是一個大問題

2、BUG的產生

交流的誤解

羞澀。跟客戶交流的時候總是用很小的聲音說明自己的觀點，表現力度不夠；或者靜靜地坐在會議室的角落，沒有任何思想地觀看別人的激烈討論。

膽怯。專案參與人員缺乏對客戶的瞭解，造成盲目跟從心理。交流的時候只是去聽，從不敢反駁或者提出相反的意見。

**依賴。**部分專案參與人員認為交流的時候，只要有一個人做會議筆記就可以了，總是找一種感情上的依託。

輕視。擁有專業知識的專案人員不重視客戶所說的，或者認為客戶所說的簡直就是天方夜譚，毫無科學根據。

健忘。自信能記住會議上所有討論內容而不作筆記，結果在實際的設計或者開發過程中遺忘了部分要點和注意事項。

**誤解。**這是人類相互之間普遍存在的一種現象。

大家的認知層面、各自擁有的知識、處事原則各不相同，難免會產生這種情況，可以通過相互培訓及有效的交流來避免這種情況的發生。

軟體的複雜性

程式設計師的錯誤

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

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

**過於熱心。**程式設計師經常犯這樣的錯誤，沒有經過嚴格的驗證和全域性的考慮，任意修改設計並且認為這會產生更好的效果。

心不在焉。

需求變化

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

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

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

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

時間壓力

時間是一種寶貴的資源。

所有軟體專案時間都需要被精確估算。可是夾雜著預計、猜測這些不穩定的因素，當最終期限迫近和關鍵時刻到來之際，錯誤也就跟著出現了。

文件貧乏

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

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

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

軟體開發工具

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

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

3、Bug如何穿透測試

代價太大

正規的軟體公司會引入QA，對專案整個過程進行全方位的質量保證工作。但是執行QA需要呼叫很多的資源，比如要檢查和複審需求階段輸出的標準工件，就需要高水平的分析員加入，但是通常他們時間很少很寶貴，並且不會有太多的精力顧及此事。

在設計和實現階段，隨著大量審查工作的介入，所有該階段的參與人員都要付出更多的時間和精力來參與。

這些形式的檢查、審查和測試延長了整個專案的開發過程，這些附加的工作時間都會直接變成附加費用，大大增加了整個專案的造價。

市場決策

即使測試人員發現了產品中的BUG，但是公司會覺得修復BUG將延長整個產品的釋出時間，有可能錯過銷售的旺季（可能是每年的5-10月份），並且會打亂整個公司針對該產品的銷售計劃，在確認產品中的BUG不是非常嚴重的情況下，軟體被銷售了。但是，如果這是航天、醫療、股票交易的管控軟體系統，如帶有BUG，則釋出後果是非常嚴重的，但是對於某些行業這樣的做法是可行的。

時間緊迫

測試要花費大量的時間，至今尚未有一種自動化的測試工具能夠全面和高效率地測試一套軟體產品。

測試專案經理接到測試任務後表現得過於樂觀，沒有考慮任務的風險。

開發人員過高估計自己的能力，認為所有的BUG都是微不足道、便於修復的。他讓測試工作和編碼工作同時進行，這樣根本沒辦法保證測試的正確性。並且在時間緊迫的時候，大多數測試員只是選擇明顯的幾條程式路徑測試或者輸入不完整的測試資料，這些都造成了大量的BUG紕漏。

現場證據

有時會遇到這種問題，發現了BUG但是不知道怎麼把它明顯地表示出來。不能向開發人員提供足夠的證據報告，是測試人員的恥辱，開發人員同樣會根據這樣的報告譏笑測試人員的所作所為。

BUG的可重現性，與導致BUG出現的原因有著密切的聯絡。

BUG的可重現性也體現了測試人員對軟體系統的熟悉程度。

BUG的可重現性，也體現在操作的順序上。

過於自信

開發人員是非常不誠懇的測試人員，他們總是說“我做的肯定沒問題”或者“不可能呀，它在我的機器上跑得好好的”。有的時候專案管理者也很自負，過於相信團隊成員的表現，而不去理會測試人員或者客戶的抱怨。

Titanic災難就充分體現了人類的自信，我們有足夠的水密艙就算破了5個船也不會沉。

沒有詳細的測試計劃，沒有嚴謹的測試行為，不再關注每個細小的環節，這樣BUG就從旁邊悄悄溜走了。

模糊提交

測試環境

缺少必要的測試工具和裝置。在一個比較大型的網站中，系統在正常負載情況下的效能非常重要，如果測試人員沒有一種有效的測試工具或者必要的硬體裝置，那麼就很難去模擬、再現系統負載的環境。

缺少必要的系統配置。如果是Java開發的程式，我們可能會在多種作業系統上去驗證它的正確性和穩定性。

缺少必要的測試用例。好的測試模型可以減少更多的BUG，也可以發現更多潛在的BUG。好的測試用例不僅僅是一系列測試方法的組合，它更大的用處在於和歷史積累BUG記錄的對比分析。

4、Bug的種類

需求階段的BUG——來源：

模糊不清的需求

忽略的需求

衝突的需求

分析、設計階段的BUG——來源：

忽略設計

混亂的設計 ：這樣的情況發生在兩種設計性質完全相反的情況中，如果在實際的系統中，某塊地址規定不允許被多執行緒訪問，而方案卻被設計成以多執行緒方式進行，則會在此層面上產生BUG，嚴重的會造成整個系統的崩潰。

模糊的設計：模糊BUG產生的原因在於設計人員對需求沒有清晰的認識，或者需求本身就是含糊不清的。

實現階段的BUG——來源：

遺漏的功能

記憶體溢位：屬於一種比較嚴重的軟體BUG型別。例如，軟體執行了某些強行向作業系統保護地址寫入資料的指令，導致整個環境的徹底崩潰；再如：數值除零導致堆疊溢位

其他實現：表現為出現的錯誤難以定位其型別，比如在產品化階段，測試人員或者終端使用者提出的部分提高程式執行效率的建議，當然開發人員並不完全處理這些問題，但是這些建議將成為一種特殊的BUG型別，被保留在專案資料庫中。

配置階段的BUG

配置階段的BUG是最危險的，往往體現在軟體交付或者最後的系統測試中。

配置階段的BUG出現的原因是複雜的，比較典型的是舊的程式碼覆蓋了新的程式碼；或者測試伺服器上的程式碼和實現人員本機最新程式碼版本不一致。這些情況造成了錯誤程式碼被修改後，經過一個時間段再次迴歸測試時又會出現同樣的問題。

配置階段的BUG解決方案也很簡單，專案組可以指定專人（整合員）進行配置和整合管理，整合員保證正確整合整個系統，並將最新的程式碼釋出到測試伺服器或者客戶伺服器上。這個階段由QA（質量保證）部門負責監管和控制，規定整合的時間間隔和最佳整合時間，統一維護一份專案組整合人員和整合時間列表。

短視將來的BUG

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

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

再如：中國移動開發了134號段的號碼。現在又有了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關閉狀態

迴歸測試後，如果部分登記BUG再次出現，測試人員可直接將已登記的Closed&Fixed狀態的BUG轉入修復流程，等實現人員修復BUG後將該BUG置為

Resolved&Fixed狀態。測試人員對實現人員修復後的BUG進行確認測試，如果該BUG被正確修復了，那麼其狀態被置為Closed&Fixed狀態，同時意味著該BUG的整個生命週期終結了

（3）BUGStart–> BUG初始狀態 --> BUG分配狀態–>BUG重新分配狀態

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

進行BUG確認，確認失敗後該BUG狀態被置為Reassigned狀態併發送回BUG起始階段

（4）BUGStart–> BUG初始狀態 --> BUG分配狀態–>BUG重新分配狀態 --> BUG修復狀態 -->BUG重新開啟狀態

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

進行BUG確認，確認成功後該BUG狀態被置為Reassigned狀態，當實現人員修復BUG後該BUG置為Resolved&Fixed狀態，但是實現人員發現該BUG與其他實現人員

的BUG有關聯關係，可能導致本次修復無效，所以實現人員將該BUG置為Reopen狀態傳送回BUG起始階段

（5）BUGStart–> BUG初始狀態 --> BUG分配狀態–>BUG重新分配狀態 --> BUG修復狀態 -->BUG驗證狀態 --> BUG重新開啟狀態

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

修復後的BUG進行確認測試，驗證成功後測試人員懷疑該BUG並非真正修復，將該BUG置為Reopen狀態傳送回BUG起始階段

7、BUG的流轉狀態關鍵字

未確定的（Unconfirmed）。這個BUG最近才被發現，還沒有人確認它是否真的存在，如果有別的測試人員碰到了同樣的問題，就可以將這個Bug標誌為New，或者將這個Bug刪除，或者做上closed標記。

新加入的（New）。這個BUG最近被測試人員新增到Bug列表中，已經被證實存在且必須修改的。即將被分配，如果分配了可以標誌為Assigned，未分配則將保留New標誌，或者做上Resolved標記。

確認分配的（Assigned）。測試人員將BUG的修復任務分配給具體的實現人員，如果BUG不屬於被分配實現人員的範圍，可置為Reassigned，等待被重新指定相關修改人員。

重新分配的（Reassigned）。該BUG不屬於被分配實現人員的範圍，可置為 Reassigned等待被重新指定相關修改人員。

需要幫助的（Needinfo）。測試人員或實現人員無法對發現的BUG進行精確定位或描述，需要相關實現人員協助，以更深刻地認識和修復這個Bug。

重複出現的（Reopened）。該BUG已經不是第一次被發現，它可以被標誌為Assigned或者Resolved。

已解決的（Resolved）。實現人員對被分配給自己的BUG進行修改，修改完以後，修改狀態。

重新啟用的（Reopen）。當實現人員發現某些BUG具有關聯性，即使該BUG被正確修復了，也會被髮送到起始狀態等待迴歸再次確認。或測試人員發現該BUG沒有被真正修改後，重置狀態。

正在驗證的（Verified）。測試人員對標記為Resolved狀態的BUG進行驗證。

安全關閉的（Closed）。該BUG已經被完全解決。

8、BUG的解決關鍵字

已經修復（Fixed），該BUG被正確修復了，並且得到了測試人員的確認。

無法修復（Wontfix），發現的BUG永遠不會被修復，或者該BUG牽涉面太廣需要委員會決定。

下版本解決（Later），發現的BUG不會在產品的這個版本中解決，將在下一個版本中被修復。

無法確定（Remind），發現的BUG可能不會在產品的這個版本中解決，也可能會。

重複的（Duplicate），發現的BUG是一個已存在BUG的復件。

無法證實（Incomplete），用了所有的方法都不能再現這個BUG，沒有更多的線索來證實這BUG的存在，即使看程式原始碼也無法確認這個Bug的出現。

測試錯誤（NotaBUG），BUG報告出現了錯誤，將正確的軟體過程報告成BUG了。

無效的（Invalid），描述的問題不是BUG，屬於測試人員輸入錯誤，通過此項來取消。

問題歸檔（Worksforme），所有要重現這個BUG的企圖都是無效的，如果該BUG有更多的資訊出現，則重新分配這個BUG，而現在只把它列入問題歸檔。

9、BUG的嚴重等級

危急的（Critical)，能使不相關的系統內軟體（或整個系統）損壞，或造成嚴重的資訊遺失，或為安裝該軟體包的系統引入安全漏洞。

重大的（Grave)，使該軟體包無法或幾乎不可用，或造成資料遺失，或引入一個允許侵入此軟體包使用者之帳號的安全漏洞。

嚴重的（Serious)，該軟體包違反了“必須”或“必要”的規定，或者是軟體包維護人員和測試人員認為該軟體包已不適合釋出。

鎖定的（Blocker)，這個Bug阻礙了後面的操作，需要馬上或者儘快排除。

重要的（Important)，該錯誤影響了軟體包可用性，但不至造成所有人都不可用。

常規的（Normal)，為預設，適用於大部份的錯誤。

輕微的（Minor)，該錯誤不致影響軟體包的使用，而且應該很容易解決。

微不足道的（Trivial)，該錯誤無關緊要，多指外觀GUI上的字元拼寫錯誤，不影響整個專案。

10、BUG處理的優先等級

立刻修復（Immediate），這個BUG已經阻礙了開發工作或者測試工作，需要立刻修改。

馬上修復（Urgent），這個BUG阻礙了軟體的一部分應用，如果不修復它將妨礙下面計劃的實施。

儘快修復（High），真實存在的並不是很嚴重，在版本釋出之前修復。

正常修復（Normal），有充足的時間來修復這個問題，並且這個BUG給現行的系統的影響不大。

考慮修復（Low），不是什麼關鍵BUG，當時間允許的時候可以考慮修復。