軟件缺陷(Defect),常常又被叫做Bug。 所謂軟件缺陷,即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤,或者隱藏的功能缺陷。缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義:從產品內部看,缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題;從產品外部看,缺陷是系統所需要實現的某種功能的失效或違背。
bug標題
?一、Bug 標題的「三段式」黃金結構?
?公式?:
[模塊/功能] + 具體現象 + 觸發條件(可選)
?關鍵要素?:
- ?模塊定位?:直接關聯代碼庫或功能模塊(如?
[支付網關]
、[用戶注冊]
) - ?現象描述?:用技術語言說明錯誤表現(如?
HTTP 500 錯誤
、內存泄漏
) - ?條件限定?:標注特定場景或邊界值(如?
iOS 17.4
、并發用戶>1000時
)
?示例對比?:
? 合格標題:
[訂單結算] 使用多張滿減券時金額計算錯誤(總金額>500元必現)
? 不合格標題:
結算金額不對
?二、6 種高頻場景的標題優化方案?
?1. 功能邏輯錯誤?
? 規范寫法:
[消息推送] 用戶屏蔽群組后仍接收@全體成員通知(服務端過濾邏輯失效)
? 包含要素:
- 模塊:消息推送
- 現象:屏蔽后仍接收通知
- 條件:@全體成員
- 根因線索:服務端過濾失效
?2. 界面交互問題?
? 規范寫法:
[個人中心] 深色模式下編輯按鈕圖標不可見(對比度低于 WCAG 標準)
? 技術關鍵詞:
深色模式
、對比度
、WCAG
(直接關聯開發修復標準)
?3. 性能問題?
? 規范寫法:
[商品搜索] 關鍵詞含特殊字符時接口響應時間>5s(%符號觸發全表掃描)
? 數據化表達:
>5s
(量化指標)、全表掃描
(指向SQL優化點)
?4. 兼容性問題?
? 規范寫法:
[文件上傳] Safari 15.1 瀏覽器無法拖拽上傳.zip文件(macOS Monterey)
? 環境精準定位:
瀏覽器版本 + 操作系統版本 + 文件類型
?5. 安全性漏洞?
? 規范寫法:
[API鑒權] /userinfo 接口未校驗JWT令牌iss字段導致越權訪問
? 漏洞細節:
iss字段
(具體參數)、越權訪問
(風險等級)
?6. 數據一致性錯誤?
? 規范寫法:
[庫存同步] 秒殺活動結束后數據庫庫存未回滾(超賣3件商品)
? 影響量化:
超賣3件
(明確業務損失)
?三、標題編寫的「三要三不要」原則?
?? 必須遵守的「三要」?
- ?要包含技術術語?:
- 使用?
NullPointerException
?而非 "程序報錯" - 使用?
主從同步延遲
?而非 "數據沒更新"
- 使用?
- ?要體現復現規律?:
- 標注?
連續操作5次后必現
?或?概率30%
- 標注?
- ?要關聯代碼位置?(可選):
- 標注?
(UserService.java:87)
?或?API:/v2/payment
- 標注?
?🚫 嚴格避免的「三不要」?
- ?不要用模糊代詞?:
- ? "那個功能有問題" → ? "[語音轉寫] 60秒以上音頻轉譯失敗"
- ?不要省略關鍵條件?:
- ? "圖片上傳失敗" → ? "[圖床服務] 上傳10MB以上PNG圖片返回413錯誤"
- ?不要混搭多個問題?:
- ? "登錄閃退和支付報錯" → 拆分為兩個獨立Bug
bug等級
?一、Bug 嚴重等級劃分(按影響程度降序排列)?
-
?致命(Critical/Blocker)?
- 導致系統崩潰、死機、數據丟失或核心功能完全失效
- ?典型場景?:
- 支付接口崩潰導致交易中斷 ?15
- 數據庫死鎖引發用戶數據損壞 ?45
- 內存泄漏引發系統卡頓至無響應 ?68
-
?嚴重(Major)?
- 主要功能未實現或存在嚴重偏差,但系統仍可運行
- ?典型場景?:
- 訂單提交后未生成唯一流水號 ?26
- 核心算法計算錯誤導致價格偏差 10% 以上 ?36
- 接口超時未返回數據(響應時間 >10秒) ?38
-
?一般(Minor)?
- 次要功能缺陷或界面交互問題
- ?典型場景?:
- 用戶頭像上傳后預覽變形 ?48
- 表單必填項未標注紅色星號 ?36
- 分頁控件頁碼顯示錯位 ?8
-
?提示(Trivial/Suggestion)?
- 不影響功能使用的體驗優化項
- ?典型場景?:
- 按鈕文字存在錯別字(如“登陸”應為“登錄”) ?68
- 夜間模式對比度過低導致閱讀困難 ?8
- 頁面加載動畫幀率不足 ?3
Bug 類型分類?
-
?功能邏輯錯誤?
- 需求實現偏差(如搜索功能未過濾敏感詞) ?38
- 業務流程斷裂(如退款申請無法提交至風控系統) ?8
-
?性能問題?
- 高并發場景下接口吞吐量下降 50% ?36
- 內存占用持續增長未釋放(每小時增加 10MB) ?8
-
?界面缺陷?
- 多語言環境下文本溢出容器 ?8
- 深色模式部分圖標未反色 ?8
-
?兼容性問題?
- iOS 17.4 系統下地圖控件渲染異常 ?8
- Chrome 120+ 版本瀏覽器表格布局錯亂 ?68
-
?安全性漏洞?
- SQL 注入風險(如未過濾?
' OR 1=1 --
) ?18 - JWT 令牌未設置過期時間 ?8
- SQL 注入風險(如未過濾?
?優先級定義(按修復緊急程度排序)?
優先級 | 響應標準 | 對應場景示例 | 來源 |
---|---|---|---|
?P0? | 需立即修復(24小時內) | 線上支付功能完全癱瘓 | ?13 |
?P1? | 下一版本必須修復 | 核心功能缺失導致用戶流失 | ?34 |
?P2? | 可排期至后續迭代修復 | 非核心頁面加載速度慢于 3 秒 | ?34 |
?P3? | 建議優化但不強制修復 | 頁面 footer 版權信息年份未更新 | ?37 |
實際結果、預期結果
?一、復現步驟的「三層遞進式」寫法?
?原始步驟(需優化)?
textCopy Code
1. 打開APP 2. 進入個人中心 3. 點擊設置 4. 修改昵稱為"測試_User123" 5. 返回個人主頁 6. 昵稱未更新
?優化后版本?
textCopy Code
[前置條件] 賬號已完成手機號+郵箱綁定 [操作鏈路] 1. 觸發數據修改: - 訪問路徑:首頁 > 個人中心 > 賬號設置 - 修改字段:昵稱 → 輸入"Test#2024"(包含特殊字符) - 點擊保存 2. 驗證數據同步: - 返回個人主頁 - 退出重新登錄 - 調用API檢查用戶表`display_name`字段
?優化要點?:
- 區分操作階段(修改 → 驗證)
- 包含邊界值測試數據(特殊字符)
- 增加技術驗證手段(API查詢)
?二、預期結果 vs 實際結果的「數據化對比」模板?
?標準寫法?
維度 | 預期結果 | 實際結果 |
---|---|---|
?界面反饋? | 顯示綠色Toast提示"修改成功" | 無任何提示 |
?數據存儲? | 數據庫user_profile 表nickname 字段更新 | 數據庫值未變更(Last_modified=舊時間戳) |
?系統聯動? | 用戶搜索接口返回新昵稱 | 接口仍返回原昵稱 |
?優勢?:
- 多維度驗證(前端+后端+接口)
- 使用技術字段名精準定位問題層級
?三、錯誤案例 vs 規范案例對照表?
?1. 復現步驟對比?
?錯誤案例?:
textCopy Code
1. 隨便操作幾次就崩潰了
?規范案例?:
textCopy Code
[壓力測試場景] 1. 在1分鐘內連續執行: - 快速切換商品分類標簽(>20次) - 上下滑動頁面(每秒3次) 2. 觀察內存占用(Android Profiler工具監控)
?2. 實際結果對比?
?錯誤案例?:
textCopy Code
實際結果:頁面看起來不對勁
?規范案例?:
textCopy Code
實際結果: 1. 布局坍塌:價格標簽與購買按鈕重疊 2. 控制臺報錯:`TypeError: Cannot read 'price' of null` 3. 內存峰值:從200MB升至850MB后閃退
?總結:
完整描述一個 Bug 所需的關鍵步驟和內容要素
?一、描述 Bug 的必備操作?
-
?明確標題?
? 格式:[模塊名稱] + 問題現象
? 示例:[登錄模塊] 輸入正確驗證碼后仍提示"驗證碼錯誤"
-
?填寫基礎信息?
- 測試環境(如:瀏覽器版本/設備型號/操作系統)
- 發現時間
- 測試人員
- 關聯需求或任務編號
-
?詳細復現步驟?
? 要求:清晰、可復現、無歧義
? 示例:textCopy Code
1. 打開APP,點擊"登錄"按鈕 2. 輸入手機號 138‌****‌1234 3. 點擊"獲取驗證碼",收到短信驗證碼"123456" 4. 輸入驗證碼并點擊"確認"
-
?預期結果 vs 實際結果?
- 預期結果:根據需求文檔應出現的正確行為
- 實際結果:當前觀察到的錯誤現象
-
?補充信息?
- 優先級(P0/P1/P2/P3)
- 嚴重程度(致命/嚴重/一般/建議)
- 附件(截圖/日志/錄屏)
- 是否必現(100%復現/偶現)
?二、完整 Bug 示例?
?標題?
[支付模塊] 使用支付寶付款成功后訂單狀態仍顯示"待支付"
?環境信息?
- 設備:iPhone 14 Pro / iOS 16.4.1
- APP版本:v2.3.0
- 網絡:WiFi
- 測試時間:2023-10-20 14:30
?復現步驟?
- 選擇商品加入購物車
- 進入結算頁,選擇"支付寶"支付方式
- 跳轉至支付寶APP完成指紋支付
- 返回商戶APP查看訂單詳情
?預期結果?
訂單狀態應更新為"已支付",生成交易流水號?實際結果?
- 訂單狀態仍顯示"待支付"
- 控制臺出現錯誤日志:
ERR_CODE: 5003, Payment callback failed
?附件?
- 支付寶支付成功截圖
- 商戶APP訂單狀態截圖
- 抓包日志文件(附加網盤鏈接)
?優先級/嚴重性?
- 優先級:P0(阻塞核心流程)
- 嚴重性:致命
?備注?
- 該問題在Android端同樣存在
- 支付回調接口響應時間為8秒(超過正常3秒閾值)
?三、高質量 Bug 報告要點?
- ?客觀描述?:避免主觀判斷(如:"這個功能設計得很爛")
- ?最小化復現?:排除無關操作步驟
- ?數據支撐?:提供請求參數、錯誤日志等關鍵信息
- ?版本控制?:明確出現問題的代碼版本
- ?關聯分析?:說明是否影響其他模塊
通過規范化的 Bug 描述,可有效提升開發修復效率,減少溝通成本。建議使用 Jira、TAPD 等專業工具進行跟蹤管理。