基礎理論篇

• • • 一、軟件缺陷
    • • 1.1. 缺陷的定義
      • 1.2. 缺陷的判定標準
      • 1.3. 缺陷的產生原因
      • 1.4. 缺陷的生命周期
      • 1.5. 缺陷的核心內容
      • 1.6. 缺陷的提交要素
    • 二、項目中缺陷的管理流程
    • • 2.1.缺陷跟蹤流程及注意事項
      • 2.2.缺陷報告編寫規則
      • 2.3.使用excel管理缺陷報告示例
      • 2.4.使用禪道管理用例和缺陷報告示例

一、軟件缺陷

1.1. 缺陷的定義

軟件在所有過程中存在的任何問題都叫軟件的缺陷，簡稱bug

1.2. 缺陷的判定標準

軟件未實現需求規格說明書中明確要求的功能 - - 少功能
軟件出現了需求規格說明書中指明不應該出現的錯誤 - - 功能錯誤
軟件超出需求規格說明書指明的范圍（比如每個員工都可以查看某公司的工資流水） - - 多功能
軟件出現了需求規格說明書中雖然未明確按應該實現的要求（登錄成功沒有跳轉到首頁，刪除敏感信息時沒有進行二次確認） - - 隱形功能錯誤
軟件難理解，不易使用，運用緩慢，用戶體驗不好（如春運買票提示系統繁忙） - - 不易使用

如何區分前端和后端錯誤
1.界面錯誤和兼容性錯誤一般是前端的bug
2.功能錯誤可以使用抓包（查看請求和響應，檢測后端返回數據和前端顯示數據）的方法來區分前后端錯誤

1.3. 缺陷的產生原因

是軟件就有缺陷
需求階段（產品）：需求描述不易理解，有歧義，錯誤
設計階段（架構師）：設計文檔存在錯誤或缺陷，數據庫及前后端架構
編碼階段（前端和后端）：代碼出現錯誤
運行階段（兼容性）：軟硬件系統本身故障導致軟件缺陷

1.4. 缺陷的生命周期

（需求。設計和編碼階段）注入bug – （測試階段）發現bug – （開發修復）解決bug – 回歸測試 – 上線運行階段（軟硬件系統兼容性等）

1.5. 缺陷的核心內容

缺陷的標題：（操作數據描述+預期+實際）
缺陷的描述：（前置+步驟+預期+實際）
缺陷的預制條件
缺陷的復現步驟
缺陷的預期結果
缺陷的實際結果
缺陷的必要附件

1.6. 缺陷的提交要素

1.缺陷Id：可以使用用例Id，要求唯一
2.缺陷標題：操作數據描述+預期+實際（或者：測試步驟描述+實際+需求）
例1：輸入4位自然數qq號；期望結果：不通過（提示：必須為6-10位自然數）；實際結果：通過
例2：密碼為空；期望結果：不通過（提示：密碼不能為空）；實際結果：登錄成功
3.所屬模塊
4.缺陷嚴重程度：S1（嚴重：主功能）、S2（一般：次要功能）、S3（優化：易用性、界面）、S4（建議性問題）
5.缺陷優先級：
業務+單功能
業務正向錯誤P0（登錄搜索添加到購物車下單支付其中一項失敗）（24h內解決）
業務逆向錯誤P1（因為未登錄導致添加購物車失敗 ）（發布前修復）
單功能正向錯誤P2（正確用戶名+正確密碼登錄失敗）（下個版本中修復）
單功能逆向錯誤P3（正確用戶名+錯誤密碼登錄成功）
6.缺陷狀態：新建new，激活reopen，已關閉closed，已解決fixed（可以進行回歸測試），in progress（進行中），延期delay/postpone，拒絕rejected，過期
7.缺陷的類型：代碼錯誤、兼容性問題、設計缺陷、性能問題
功能錯誤、界面（UI）錯誤、兼容性、數據、易用性、改進建議、架構
8.缺陷描述：前置條件+復現步驟+預期結果+實際結果，操作步驟中必須給出測的數據（自己驗證的用例）（預期結果一定與世界結果相反）
例1：
[前置] 1.打開qq界面
[步驟] 1.輸入qq：1234 ，2.點擊驗證
[預期] 不通過，提示必須為6-10位自然數
[實際] 通過
9.附件：包括日志和錯誤界面
10.創建人、指派人、修復日期…

二、項目中缺陷的管理流程

當你發現bug后怎么辦：確認bug是否可復現，如果可復現再提交bug
缺陷編寫規范：準確、具體、次序清晰、簡潔易懂
缺陷管理工具：禪道：三管融合（產品管理、項目管理、質量管理）、jira
禪道的特點：三權分立（產品部門 - 構象者，研發部門 - 執行者，測試部門 - 保證者）、四角協同（產品經理，項目經理，研發團隊，測試團隊）

實際測試中bug不可復現怎么辦？
1.多次重復測試，不出現先記錄
2.回顧bug出現的操作流程和測試環境的配置，是否由于誤操作或環境臨時故障引起
3.請開發協助自己查找當前測試模塊是否有對應的日志信息（日志位置可以問開發）
4.考慮更換一套環境查看是否能復現上述問題
5.后續的版本測試，要關注剛說測試該功能時是否還出現上述問題
6.后續幫辦還出現，需要開發協助打印日志進行分析定位

2.1.缺陷跟蹤流程及注意事項

提交缺陷 – 分配缺陷 – 處理缺陷 – 回歸測試 – 關閉缺陷
權限跟蹤作用：描述開發和測試如何協同配合處理bug

測試處理狀態：新建new，激活reopen，已關閉closed
開發處理狀態：已解決fixed（可以進行回歸測試），in progress（進行中），延期delay/postpone，拒絕rejected，過期

注意：
1.確保bug準確性、可復現
2.描述簡單易懂具體
3.不能用感情色彩，和模棱兩可的詞匯（是否，可能），不要用人稱代詞（你應該怎么修改 ）

2.2.缺陷報告編寫規則

可復現，唯一性，規范性（遵循公司要求）

2.3.使用excel管理缺陷報告示例

2.4.使用禪道管理用例和缺陷報告示例

創建用例 – 評審用例 – 執行用例（選擇測試結果） – 失敗轉bug – 提交bug（輸入缺陷核心要素） – 開發確認bug – 解決bug – 關閉bug

創建用例（單條，多條（導出導入模板））

評審用例

執行用例


提交缺陷（轉bug或提bug）

可以進行缺陷管理和用例管理，但用例管理使用的不多（可以直接使用excel，使用禪道進行用例管理的優點是可以記錄執行結果，測試不通過可以直接轉bug）


跟蹤缺陷（指派bug給開發 - 開發確認bug - 開發解決bug ）


驗證缺陷（回歸測試 - 成功關閉，失敗重新打開）

總結

以上是生活随笔為你收集整理的软件测试 - 缺陷管理篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。