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

缺陷的定義

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

Bug是編程錯誤的結果；

Defact是與需求的偏離。

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

缺陷的屬性組成

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

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

缺陷的描寫

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

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

標題

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

描述內容

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

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

3、測試的環(huán)境、測試使用的數(shù)據(jù)也描寫清楚。

上傳截圖

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

缺陷的流程

1、我一般被測試人員所創(chuàng)建，然后由測試經(jīng)理做審核。

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

測試人員修正后，再提交給測試經(jīng)理審核。

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

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

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

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

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

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

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