第一階段第二節 關於Bug的優先順序

來自專欄從零開始學產品5 人贊了文章

一 什麼是Bug

Bug簡單來說，就是指應該發生的事情沒有發生，或者是不該發生的事情發生了。

構建一個系統，相當於是重新創造了一個世界，如果把我們所在的世界當成是一場巨大的玄幻小說，每一個系統都可以被稱之為一個密境，或者是遊戲里常見的副本。

而產品經理就是密境的設計者，你可以去定製這個密境運行的規則，展示出來的樣子，通常由程序員們去按照你預期的樣子去構建。

但是程序員小哥哥們往往會出很多問題，在上一節我們講到過，環境是要分成開發，測試和線上的，而測試人員工作的平台就是測試環境，在測試環境，我們的職責就是儘可能的找出超出我們預計之外的問題。

這種問題，我們稱之為Bug。為什麼叫做Bug？大概和打掃房間時發現屋子裡面有蟑螂一樣，程序員們需要耐心，細緻的找遍屋子裡的每一個角落，找到蟑螂存在的痕迹，並消除掉。

我們來看一下，跟Bug相關的幾個問題。

1.Bug是不是可以被完全消除？

2.是不是程序員的水準越高，寫出來的Bug就越少？

3.應該在什麼階段去測試？

4.什麼樣的Bug可以上線？

第一個問題，Bug是不是可以不被寫出來？為什麼程序員總是會寫出來各種各樣的Bug？

做為一個曾經的程序員，也是現在的程序員，同時也是未來的程序員，我可以負責任的告訴你，Bug一定存在，多熟練的工程師都沒用。

Bug就像是宿命一樣，伴隨著程序員的終生，而這也是人類最有意思的事情，它不像程序世界裡一樣充滿了確定性，人是會犯劃的，會漏掉各種各樣的細節。

各種分支條件，極端運行情況，大多數程序員只能保證在大多數情況下不出意外。

可是Bug可以被消除，已經發現的Bug，除非特別難復現的，正常來講都可以消除掉。

當然那些因為一開始系統構造的錯誤架構問題產生的Bug特別難修復。

在這個問題上，我想表達的含義就是，正確的認知Bug，不要因為Bug的存在而產生困惑，我們想做的，能做的，就是儘可能的減少Bug，以及在測試環境發現Bug後，快速的修復Bug。

第二個問題， 是不是程序員的水準越高，寫出來的Bug就越少？

這是一件很有意思的事情，程序員之所以會犯錯，很大的可能性是他不知道自己在犯錯，而不是故意在犯錯。在這種情形之下，如果能夠有快速的反饋，他會修復自己犯下的錯誤，並且提醒自己不要再犯同樣的錯誤。

Bug的修復史其實是程序員的成長史，好的程序員，會有足夠多的經驗做出預判，另外，在他們交付測試之前，往往會比測試人員測試的更仔細，以便提前發現自己的問題。

「讓其他人發現自己寫的程序有Bug，是程序員的恥辱。」 -by 暗滅大人

做為產品和測試，很多時候並不太懂技術，不知道誰的水平高低，但是他們的感受很直接，誰做的項目容易出問題，誰負責的模塊總是出故障，誰花的時間更少，心裡會很清楚。

第三個問題 應該在什麼階段去測試

不要在開發階段就進入測試，除非是開發人員的請求。

測試人員必須明確這一點，也需要向開發人員明確的提出自己的要求。

開發階段進駐測試階段，關鍵的環節就在於是Demo，我應該會在第四節講到Demo的事情。

在這裡需要明確的，就是測試人員工作的環境，就應該是測試環境，一個不被打擾的，穩定的環境。

不是開發，也不是線上。

第四個問題 什麼樣的Bug可以上線？

這其實就是今天想要描述的Bug的優先順序。

產品經理和測試人員需要明確的是，什麼時候我應該發布系統，什麼時候我應該放棄發布系統，什麼時候我應該捨棄一些功能。

在後續的敏捷開發中，我會介紹到Story的優先順序，這是通常用來解決上線問題的重要決策支持。而在測試階段，Bug的級別往往是我們決定是否能夠上線的關鍵因素。

正常來說，不影響主要功能使用，僅僅影響用戶體驗的非關鍵業務邏輯，是可以上線之後再發布的。這是一個權衡，在時間和體驗之間選擇一個最佳的平衡點，每一家的系統要解決的問題不一樣，情形不一樣，通常都是看產品經理和測試人員和公司主要負責人共同的決定。

這也是Bug要區分優先順序的重要原因，另一個原因就是開發人員要按順序修復Bug。

二 Bug的優先順序

對事情進行輕重緩急的分類，是人類生存史上的重要支柱。

Bug的優先順序用來標誌Bug的嚴重程度，以便用於在Bug修復和上線之間提供決策支持。

通常會分成以下幾種。

• critical
• block
• major
• normal
• minor

五種級別的劃分，並不是單純的12345分級這麼簡單，而是分別對應有它自己的含義。

Critical的Bug是最嚴重的，代表著系統崩潰，完全不可用。這種Bug出現，就是最嚴重的事故，完全打不開，比如說，網站無法訪問，點擊出現系統錯誤，直接跳轉到404頁面。

要注意的就是，Bug的嚴重程度和它易於修復的程度並不總是一致，舉個例子，當用戶打開修真院網址的時候發現打不開，這是非常嚴重的，Critical級別的Bug。最後發現原因很簡單，域名過期，解決方案也很簡單，就是交錢續費而已。

一個系統是否能正常運行，並不在於導致它不能運行的問題複雜或簡單。

Block的Bug也是非常嚴重的，它的含義是，用戶的操作被卡住了，無法進行下一步。系統並沒有大規模的崩潰，而是無法進行到下一步。拿12306來說，當你選好車票的時候，想要點擊購買，這個時候卻發現購買按鈕點擊之後無法使用，而其他的一切功能都正常。

這就是Block級別的Bug，一個地方卡死，導致你無法進行下一步的操作。

通常，在線上出現的Critical和Block，都可以稱之為事故了。

Major的Bug是嚴重的，也是在Bug體系里的一個分界線，絕大多數團隊在初期的目標，都應該是在提交測試之前，完全消除Major級別的Bug，減少Normal級別的Bug數量。

Major的Bug通常是指流程可以走的通，但是關鍵的業務或者是數據錯誤，影響用戶的正常使用。比如說，在修真院的師兄弟體系中，你加入了班級，按理來說應該分配一個師兄。你按提示完成操作，但是卻沒有被分配到任何師兄。

這種級別的Bug往往是不沒有任何操作流程上的問題，但是就是和預期的結果不對，而且影響了用戶的正常使用，特別是在關鍵業務邏輯上。

Normal的Bug就比較常見了，像一些分支業務邏輯里，偶爾會出現的問題，又或者是一些不太重要的地方出現的錯誤。通常我們知道他是一個Bug，但是對大部分用戶來說都無關緊要，可以用，可以不用，我們知道他有Bug，噢，沒關係，我可以等等。

Normal的Bug應該被控制數量，我們建議的數量，是在開發人員提交測試之後，不超過3個。

Normal的Bug通常情況下都很容易被發現，不需要花太大的力氣去尋找。

Minor的Bug，指那些無傷大雅的小問題，通常是指兼容性，不重要的文案錯別字，樣式錯誤等。

這種Bug上原則上的修復時間看開發人員的空閑期。

以上五種Bug級別，分別對應了在系統中對用戶使用時候的影響度。需要特別指出的是，很多人在時間特別趕，或者是不好的開發流程習慣中，喜歡用一個詞來描述：主邏輯。

主邏輯先跑通，再去看其他的細節問題。

在時間特別緊，非常極端的情況下，允許這種情景出現。但是大多數時間裡，我們都不贊成這種做法。

開發人員在Demo之前，不存在主邏輯跑通的問題，應該是交付所有的正常可使用的功能。

在這個前提下，才會有測試人員去測試環境測試的價值和意義。

三 區分Bug優先順序的意義

我們剛剛提到過，當Bug的優先順序劃分出來之後，對我們修復Bug和規划上線提供了決策的依據。

這個依據，就是以Major的Bug為分界線，通常而言，有Major以上的Bug是不允許上線的-都跑不通流程，你發布上線幹嘛呢？

而在開發人員安排修復Bug的時候，也一定是優先安排Major的Bug，而不是先去修復Normal和Minor的Bug。

常犯的一個錯誤是，單獨給開發人員留一個修復Bug的時間。當然開發流程並不是由產品經理來決定，雖然這是面向產品經理的教程，但是我還是想說一下，在正常的項目管理中，不存在單獨修復Bug的時間點。

這一點，在和研發團隊交流的過程中格式的重要，我可能會在講到敏捷開發的時候提到這些。在當前，產品經理和測試人員需要明確的就是，守好Demo這一關，做好Bug優先順序的處理工作。

另外，在提Bug的時候，要注意，一定要描述清楚Bug出現時間的操作步驟（關鍵點附截圖），使用環境（操作系統，手機型號，瀏覽器版本，上下文）和預期結果（正確的結果是什麼），同時標明是偶現，還是必現，以及提供重現的數據。

這對於開發人員來說，非常重要。畢竟他們天生會說：在我這裡沒問題啊（是你這個SB不會用吧）。

一旦出現Major的Bug，開發人員應當停掉手上的項目開發，第一時間將Major Bug修復，並提交到測試環境。

而關於系統能否發布上線的一個非常重要的依據就是，是否還存在Major級別以上的Bug，如果存在了，能否把這個模塊去掉，先去上線沒有問題的模塊。

在App的發版上更複雜一些，頻繁的發布版本不是一個好的用戶體現。

好了，這是關於Bug優先順序的問題，有任何問題，歡迎討論~~

推薦閱讀：