缺陷管理

缺陷管理是最開始也是最基礎的測試必備技能。在工作了很多年後仍然會發現大量的測試人員沒有辦法合理的做好缺陷管理。
在我眼中的缺陷管理包含以下幾層概念：

1. 缺陷的描述
2. 缺陷的定義
3. 缺陷的跟蹤
4. 缺陷的度量分析

也許你覺得作為測試提一個缺陷很簡單，但是要提一個好的缺陷其實是非常難的。在這裡其實還有個隱藏的屬性，叫做缺陷的概念，也就是說什麼是缺陷？
一般來說缺陷有兩種情況，一個是違反了所謂的規則，還有一種是我們無法接受這樣的情況。比如對於美來說，每一個人心目中都有一種對美的定義，你會覺得她很美，但是換個人來看待就未必。所謂的情人眼裡出西施應該是指個人需求下的狹義定義。而大眾情人就是那種所謂的約定俗成的廣義規則。
我們做一個軟體面向的物件是不同的，甚至我們需要超出使用者需求來做一點東西的，所以對於缺陷的判斷成為了一個非常困難的事情，這裡只能說對於缺陷這種東西，不要用肉眼去看要用心眼去看。

缺陷的描述

關於缺陷的描述，無非就是當別人看到你寫了一堆關於這個缺陷的巴拉巴拉後，是不是明白了5w1h，然後能夠根據你的建議開始進行缺陷的修改。本質上有一點就是缺陷的描述就像議論文，一定要有說服力。如果你寫出來的東西都不能讓別人覺得有道理，你又怎麼讓別人願意按照你的邏輯去修改這個缺陷呢。
為了方便把缺陷寫的更容易理解，所以現在無論是Excel的記錄方式還是使用系統的記錄方式，我們都會將一個缺陷分割為很多個屬性，來便於管理和理解，常見的屬性包括：
標題，詳細說明，版本，環境，發現人，發現時間，修復人，修復時間，修復說明，狀態，嚴重級別，優先順序別等。
本著不浪費筆墨和浪費閱讀者理解的前提下，缺陷應該是寫的越簡單越說明問題是最好的。但是在我遇到的大多數情況下，作為小白寫出來的缺陷往往是無法閱讀和理解的，因為小白總會覺得自己寫出來的東西別人肯定看得懂，而忽略了很多背景或者參考的說明，常見的問題無非是：
我的xx功能出錯了；點選某個按鈕無效果；無法啟動軟體等。
包括在各個QQ群的提問，也經常會出現這樣的無頭無腦，毫無內涵的提問，讓別人完全無法回答。甚至常常讓我想當你在工作幾年後開始學習自動化或者效能測試的時候，連一個問題或者缺陷都無法合理明確的描述出來，你做自動化和效能測試能靠譜麼？能解決問題麼？
但是寫好一個缺陷又不是簡單看幾個例子就行的，它需要時間和足夠多的練習才能做到，讓別人看了會明白what、why、where、when、who以及how，甚至還能明白什麼是對的，並且應該做成什麼樣。
如果想要提升自己的缺陷描述能力最簡單的方法就是學會吐槽，而且要吐槽吐的到位，那麼你就能在生活中反覆的鍛鍊如何使用最精簡的語句來說明問題的關鍵，而不是總在問題的外圍徘徊；而同樣命中靶心的另外一個要素就是你能從本質知道這個問題的“身世”，就像你手中的一個小骰子，只能有這樣幾種結果。
等你能夠通過吐槽收集能量讓你的呆毛蹦起的時候，你就能完成讓別人俯首稱臣，乖乖改你的BUG了。

缺陷的定義

在這裡缺陷的定義主要是指如何判斷缺陷的嚴重級別和優先順序別，而不是這個問題是一個建議還是一個缺陷？請注意我用了建議和缺陷來區分問題的兩種情況。這和前面說到的有類似之處到底你確定了這是一個問題，還是你覺得這樣可能不太合理。
當一個問題被提出，該問題必須要讓別人非常明確的看出它到底會帶來什麼後果，需要在什麼樣的時間內修復，這樣才能有效的讓別人重視它。看過蝴蝶效應的朋友應該知道，一個問題如果被輕視，那麼隨著放大後其結果可能是非常嚴重的，也許只是一個很小的疏忽或者不重視。
對於提交缺陷的我們來說，需要有能力去評估一個問題的優先順序（是不是應該立即修復）和嚴重級別（它會帶來什麼樣的後果），而優先順序和嚴重級別之間又不是完全強聯絡也並非完全沒有聯絡。
或許大家對優先順序和嚴重等級的概念會混淆，覺得有點模糊。一般大家會覺得嚴重等級高的BUG，優先等級一定為高。但這僅是一個包含於的關係，會存在這樣一種情況嚴重等級低（或許只是小的介面問題，例如圖片在頁面的位置不精確），但優先等級高。或許這樣說比較抽象。那麼我們來舉個例子，INTEL 對於企業LOGO 的精確度要求很高，因為這代表了企業形象。所以有關於LOGO 的相關BUG對於系統的嚴重等級為低，但優先等級都是高的。 缺陷的屬性與你所屬的行業以及公司文化也是息息相關的。
當沒有經驗的時候，或者你無法知道該問題是否在關鍵路徑以及影響的後果時，問問有經驗的人是比較好的方式。而這也是測試人員的一個基本功，能夠分清楚輕重緩急。

缺陷的跟蹤

可能大家對缺陷的跟蹤相對來說比較熟悉，因為基本上如果工作了都在使用缺陷系統，不斷處理著缺陷的生存週期（new,fix,reopen,close等等），缺陷生存週期的目的是為了方便我們跟蹤一個缺陷的不同狀態，判斷其所在的階段。
而在不同公司，不同的流程下，該流程也不盡相同，合適自己公司的才是最好的。好比缺陷跟蹤就像是快遞跟蹤一樣，以前我們發一封郵件，完全不知道對方什麼時候收到，現在這封郵件到哪裡了，而現在我們可以非常方面的在網站上隨時查詢得到該快遞所在的具體位置及簽收過程。
那麼對於小白來說首先要理解缺陷跟蹤及狀態的原理，進一步還要能配置管理這樣的系統，幫助公司完成這樣的管理工作。
缺陷的度量分析
在有了好的缺陷描述，好的定義和跟蹤後，那麼基本上缺陷已經可以很好的在某個系統內運轉起來了，接著我們要做的事情說得好聽點就是大資料分析了。從這些專案資料中，我們要分析出一些藏在資料後的規律，比較常見的包含：

1. 常見缺陷導致的原因
2. 常見缺陷被修復的時間
3. 系統每天新增或修復的缺陷數
4. 缺陷的收斂情況

這些資料可以有效的幫助我們看出一些以前看不出的問題，但是這個在中國效果並不明顯，因為我們的資料進入就存在不少的國情，而在分析及結果處理上也存在著相應的國情，所以一般公司在做度量分析的時候，往往是越做效果越差，吃力不討好。但是不得不說不能因為它效果不好而不做它，如何正確的採集、分析資料，需要一些時間和團隊成熟度後，才能發揮其效果的。
對於缺陷管理這次我提的內容會比較概念點，因為缺陷本身的例子外面很容易查詢到，而大家也會有一些自己比較成熟的看法，讓我想起如何拍一張好照片的問題了，答案是啥呢？
如果你想拍一張好照片，請先拍1000張照片，選最好的哪一張作為參考！
如果你想寫一個好缺陷，請先寫1000個缺陷，選最好的哪個缺陷作為參考吧！

結語

跟大家推薦一個學習資料分享群：175317069，裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們們一起加油吧！