我叫缺陷，也叫Bug，下面介紹一下我的生命周期

我叫缺陷，從被創建至關閉，到最后做缺陷分析，這是我的完整生命周期。我的整個生命周期貫穿著整個項目的項目周期，因此，掌握我的生命周期，不止是測試人員必修的課程，也是測試人員的靈魂。

缺陷的定義

對于軟件的缺陷來說，一般人都把我說是Bug，但正確的來說，應該是Defect，這兩者的區別是：

Bug是編程錯誤的結果；

Defact是與需求的偏離。

Defect不一定表示代碼中存在Bug，它可能是尚未實現但在軟件要求中定義的功能。實際上，無論是測試人員還是開發人員，還是習慣把我叫為Bug。

缺陷的屬性組成

我一般由標識（ID）、標題、類型、優先等級、嚴重程度、狀態、指派人組成，這些為項目最基本的、必要的屬性。

然而為了后面的一些數據便于跟蹤和分析，測試經理或項目經理更喜歡我的其它一些屬性，比如：我（缺陷）產生的根本原因、發現的階段、我（缺陷）所在系統、發現我（缺陷）的階段等。這些屬性，對整個項目的跟蹤與分析，起到非常重要的作用。

缺陷的描寫

我的整個描述非常重要，很多測試人員覺得這是件很簡單的事，然后把我寫得一塌糊涂。導致開發人員看到我后，完全不知道哪里出現了問題，得再去找測試人員溝通確認，浪費大家的時間及精力。

而項目最后為了跟蹤和分析要收集的信息，我的一些屬性更重要，開發人員和測試人員在選擇時，需要根據實際情況來做篩選，要不分析的結果就不正確了。

標題

總結出現問題的模塊和錯誤的信息。重點在于總結，很多測試人員把詳細描述里面的內容直接貼到標題中，以為這樣子搞定了我，但這樣子的標題沒有存在的意義。

描述內容

1、需要把操作的步驟和過程詳細的描寫清楚；

2、把預期結果和實際出現的結果也需要描寫出來；

3、測試的環境、測試使用的數據也描寫清楚。

上傳截圖

如果存在可以上傳截圖的路徑，盡量把出現問題的地方截圖上傳。

缺陷的流程

1、我一般被測試人員所創建，然后由測試經理做審核。

2、如果我被測試經理審核通過，我則被測試經理指向給系統應用的項目經理；如果測試經理審核我不通過，則把我指回給測試人員，讓測試人員進行修正。

測試人員修正后，再提交給測試經理審核。

3、項目經理收到我之后，進行分析，如果確認是需要修改的，則指派給對應的開發人員，如果確認我不是問題，或是我太不影響業務但太難修改，則把我指回給測試經理；

4、測試經理在收到由項目經理指派的我后，如果同意遺留，則把我指回給項目經理，然后狀態置為遺留，留著下個版本進行跟蹤。

如果根據需求，不同意遺留，則再把我指回給項目經理，進行修改；如果測試經理確認我不是問題，則把我進行撤消，指定提我的那個測試人員。

5、開發人員收到我之后，對我描述的內容進行分析修改，修改完成后，把我指回給測試人員，讓測試人員在版本更新后，進行驗證。

6、測試人員在版本更新，進行驗證我里面所描述的問題，如果驗證問題不存在，就關閉我；如果驗證問題仍然存在，則把我再提回給開發人員，讓他再進行排查及修改，直到問題修復完成，把我關閉。

特別說明：當一個項目沒有單獨的測試經理，由項目經理或測試組長兼任測試經理時，那測試人員創建的缺陷，則由他們來審核。

最后：在我的V：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。