軟體用例寫作與缺陷管理

　　第一部分 用例寫作

　　由測試用例設計得出用例的內容，然後按照用例寫作規範落實到文件中，兩者是形式和內容的關係。一個好的測試用例必須包含

　　足夠的內容，可以將這些內容拆分成八個要素，只要把這八個要素寫的完整準確，這個用例就算是寫的比較好了（感覺和小學作文三段式填鴨差不多）。

　　通用用例的八要素：測試專案、用例編號、測試標題、重要級別、預置條件、測試輸入、操作步驟、預期輸出。

說明：

　　1) 關於重要級別：

用例的重要級別一般分成三個：高、中、低，具體會按照實際情況進行劃分。通常，高階別對應保證系統基本功能、核心業務、重要特性、實際使用頻率較高的用例；中級別對應重要程度介於高和低之間的測試用例；低階別對應實際使用頻率不高、對系統業務功能影響不大的模組或功能的測試用例。 用例的重要級別和對應的需求的重要級別有關，需求的重要級別一般分成高、中、低，劃分需求的重要級別有利於進行迭代開發，把不同的需求先後來實現。用例的重要級別還和該用例的測試目的有關，針對正常情況的測試用例的重要級別比針對異常情況的用例的重要級別要高。

　　2) 預期輸出：

　　預期輸出是測試用例中非常重要的部分，要想判斷被測物件是否工作正常，都需要透過預期輸出來進行判斷。一旦預期輸出寫的不準確或者不全，整個測試用例的作用將會大打折扣。

　　3) 疑問：a.是否每個測試用例都要寫的很詳細？

　　寫作測試用例的目的有兩個：一是幫助用例設計人員將用例考慮的更全面；二是提供給執行測試用例的人看。因此測試用例到底寫到什麼程度，是寫的詳細還是寫的簡單，和測試用例由誰來執行有很大關係。如果用例是用例設計人員自己執行，那麼可以寫的簡單一些，比如就寫測試編號、測試標題、重要級別即可。如果用例是給自己組內的測試人員進行交叉執行，那麼測試用例就要寫的稍微詳細一些。若用例是給其他人來執行的，比如將測試用例的執行外包出去，那麼就需要測試用例寫的非常詳細了。

　　在編寫預期輸出時可以從以下三個方面來進行考慮：

　　1.介面顯示：在操作步驟執行完後，可以在介面上看到什麼顯示，比如註冊功能的測試，輸入註冊資訊，點選註冊，會在介面上看到註冊成功的提示資訊。

　　2.資料庫變化：在操作步驟執行完畢後，資料庫中的記錄會發生相應的變化，比如刪除功能的測試，點選刪除後，資料庫中該記錄就會被刪除。

　　3.相關資訊的變化：即在操作步驟執行完後，一些和被測物件相關的資訊會發生變化，比如登出功能的測試，點選登出後，以前能訪問的頁面將無法再訪問。

　　第二部分 缺陷管理

　　1.概念

　　缺陷的基本概念：缺陷、故障、失效。

　　缺陷（Defect）：存在於軟體之中的偏差，可被啟用，以靜態形式存在於軟體內部，相當於bug；

　　故障（Fault）：軟體執行中出現的狀態，可引起意外情況，若不加處理，可產生失效，是一個動態行為；

　　失效（Failure）：軟體執行時產生的外部異常行為結果，表現與使用者需求不一致，功能能力終止，使用者無法完成所需要的應用。

　　缺陷報告單的概念

　　缺陷報告是任何缺陷修改的起始。測試員在測試執行時發現缺陷之後，將此缺陷的相關資訊記錄到缺陷報告。然後，通報給開發人員進行確認和修復。

　　缺陷報告單可以作為後期缺陷度量的資料依據，也是對整個產品的考核。

　　2.缺陷的管理流程

缺陷的管理流程與缺陷的生命週期一致，不贅述。當然也有一些殭屍缺陷，即永遠也死不了的缺陷（在缺陷管理工具中是遺留狀態，而且由於系統歷史原因，導致一直遺留，每次版本升級也無人過問）。

　　3.缺陷管理的目標

　　1) 缺陷跟蹤

　　2) 缺陷分析