移動端測試入門系列：測試基礎理論 (二) 之 缺陷 (BUG)[第四期]

做測試的小夥伴，缺陷相關的知識是必備的。如下內容通過蒐集和篩選（感謝原作者），你必須要掌握，方可邁入測試行列。

軟體缺陷定義（BUG）
軟體沒有實現產品的說明書所描述的功能。
軟體實現了產品說明書描述不應有的功能。
軟體執行了產品說明書沒講的操作。
軟體沒有實現產品說明書沒描述但應該實現的功能（使用者體驗相關）。
從軟體測試員的角度來看，軟體難以理解、不易使用、執行緩慢，或者終端使用者認為不對。

常用的缺陷追蹤系統
JIRA
Readmine
Bugzilla
禪道(bugfree升級版）
mantis

缺陷處理流程（簡易版）

提交缺陷一般的必填項
標題：
應保持簡短、準確、提供缺陷的本質資訊。
儘量以缺陷發生的原因與結果的方式相結合的方式書寫；
儘量避免使用模糊不清的詞語，例如：“功能中斷”、“功能不正確”、“行為不起作用”等，應該使用具體文字說明缺陷的症狀；
為了便於他人理解，儘量避免使用俚語或過分具體的測試細節；

復現步驟：
應該包含如何使用別人很容易理解缺陷的復現步驟。
為了達到這個要求，書寫的測試步驟應當是完整的、簡潔的、準確的、可復現的；
儘量避免包含過多冗餘步驟，且句子結構混淆、可讀性差、難以理解；包含的操作步驟過少，缺少必要的復現步驟；

期望結果：
描述應與實際結果的描述方式相同，通常列出產品達到什麼樣的功能或效果。
附件：對缺陷的補充說明，例如缺陷的截圖、測試使用的資料等。

缺陷嚴重程度

缺陷優先順序

缺陷狀態

很多測試的小夥伴剛開始會把嚴重程度和優先順序搞混。一般來說，如下的搭配不會有什麼大問題：致命缺陷對應緊急，嚴重缺陷對應優先順序高，一般缺陷對應一般優先順序，輕微和建議對應低優先順序。但是我們也需要知道，這些並不是固定搭配，主要還是看這個缺陷對當前上線版本的影響範圍。舉個例子：某個子功能點選後會導致崩潰，這算是致命問題，但是通過線上監控顯示，該功能對於使用者來說使用率極低，或者使用的互動路徑很深，換句話說缺陷觸發的情況很低，所以某種程度上來說它並不算是一個緊急優先順序，不需要立刻發版解決，可以等到下個迭代版本再修復。我們可以把缺陷定為高優先順序。

下面以常用的jira系統為例，看一條缺陷包括那些欄位資訊：

下一期預告（每週一更）：
移動端基礎知識（Android）