一、測試用例力度
1、測試用例的本質：是在設計的過程中理解需求，檢驗需求，並把對軟件系統的測試方法思路記錄下來，以便指導將來的測試。
基於需求的測試用例設計
- 基於需求的用例場景來設計測試用例是最有效的方法，因為它直接覆蓋需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。
- 要把測試用例當成活得文檔，因為需求是活得，善變的，因此在設計測試用例方面要把敏捷方法“及時響應變更比遵循計划更有價值。
不要認為測試用例設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同階段都要重新回來重新評審和完善測試用例。
2、測試用例的評審
同行評審
- 測試用例有很多評審方法，同行評審是最敏捷的一種。
- “個體和交互比過程和工具更有價值”，這體現了測試用例設計之間思想的碰撞，通過探討、協作完成測試用例的設計。
用戶評審
- 顧客的寫作比合同更有價值。
如果測試是對產品的批判，則顧客應該指最終用戶或客戶代表
如果測試被定義為對開發提供幫助和支持，那么顧客就是程序員
二、軟件缺陷
1、定義:缺陷就是軟件的問題，最終表現為沒有滿足用戶的需求。
- 軟件未達到功能需求說明書的功能。
- 軟件中出現了需求說明書中指明不會出現的錯誤
- 軟件的功能超出了需求規格說明書指明的內容
- 軟件未達到需求說明書雖未指明而應達到的目標
- 軟件測試人員認為軟件難以理解、不宜使用、運行速度慢、或者最終用戶認為不好。
2、軟件缺陷的表現形式：
- 功能、特性沒有實現或部分實現
- 設計不合理，功能特性不明確，邏輯不清楚或存在矛盾。
- 產品結果與所期望的結果不一致。
- 沒有達到需求規格說明書所規定的性能指標等
- 運行出錯，包括運行中斷、系統奔潰、界面混亂等。
- 數據不准確、精度不夠、不完整或格式不統一。
- 用戶不能接受的其他問題，如存取時間過長，界面不美觀。
- 硬件或系統軟件存在其他問題。
3、缺陷狀態
- 提交（submit）：測試人員體交一個bug給程序員
- 打開(open)：確認體交提交缺陷，等待處理bug
- 拒絕(rejected):拒絕提交的缺陷，不需要修復或不是缺陷、重復缺陷、缺陷無法重現
- 修復(resolved)：缺陷被修復
- 關閉(closed)：確認修復的缺陷被關閉
- 推遲(later)：可以以后解決，但要確定修復日期或版本
4、缺陷程度的划分：
缺陷ID：缺陷的ID，可以根據ID追蹤缺陷
缺陷狀態：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況
缺陷標題：描述缺陷的標題
缺陷嚴重程度：對軟件程度的影響程度，分為致命、較嚴重、嚴重、一般、低
5-critical：系統奔潰、異常退出、死循環、嚴重的計算錯誤等
4-very hight：頻繁死機、系統大部分功能不能用
3-hight：功能點未實現、或不符合用戶需求、數據丟失
2-medium：影響一個相對獨立的功能、僅僅在特定條件發生、與產品需求定義不一致、斷斷續續出現問題
1-low:表面性錯誤（如錯別字）
缺陷的優先級：缺陷修復的先后順序，即那些缺陷優先修復、那些可以稍后修復
缺陷所屬模塊：缺陷所屬的項目和模塊，要能准確的定位至模塊
系統缺陷：由於程序引起的死機，異常退出；程序死循環；程序錯誤，不能執行正常工作或重要功能，是系統奔潰或資源不足
數據缺陷：數據計算錯誤；數據約束錯誤；數據輸入、輸出錯誤；
數據庫缺陷：數據庫發生死鎖；數據庫中的表、缺省值未加約束條件；數據庫連接錯誤；數據庫中有多余或少字段、空字段；
接口缺陷：數通信錯誤；程序接口錯誤；
功能缺陷：功能無法實現；功能實現錯誤；
安全性缺陷：用戶權限未實現；超時限制錯誤；訪問控制錯誤；加密錯誤；
兼容性缺陷：與需求規格配置兼容性不符；
性能缺陷：未達到預期的性能目標；性能測試中出錯，導致無法繼續測試；
界面缺陷：操作界面錯誤；打印內容格式錯誤；刪除時未給出提示；長時間操作未給出提示；界面不規范；
建議：功能建議；操作建議；
缺陷記錄者：體交缺陷的人員姓名
缺陷提交時間：
缺陷處理人：
處理結果描述：
缺陷處理時間：
缺陷驗證人：
驗證結果描述：
出缺陷詳細描述：缺陷重現步驟
缺陷環境描述：
必要的附件：bug截圖等資料；