【測試基礎第六篇】bug定義及生命周期
- bug定義
- 狹義：軟件程序的漏洞或缺陷
- 廣義：測試工程師或用戶所發現和提出的軟件可改進的細節（增強型、建議性）或需求文檔存在差異的功能實現
- 職責：發現bug，提給開發，讓其修改
- 狹義：軟件程序的漏洞或缺陷
- bug類型–了解
- 代碼（功能）錯誤—最常見–優先級偏高
- 界面優化–UI測試–優先級偏低
- 設計缺陷–優化建議：需求就不合理–優先級偏低
- 代碼（功能）錯誤—最常見–優先級偏高
- bug的等級–優先級
- 致命錯誤–blocker
- 常規操作引起的系統崩潰、死機、死循環、閃退
- 造成數據泄露的安全性問題，比如惡意攻擊造成的賬戶私密信息泄露
- 涉及金錢計算–公司巨大損失、業務
- 阻斷性測試，所有測試工作進行不下去（冒煙測試）
- 權限問題–愛奇藝會員
- 常規操作引起的系統崩潰、死機、死循環、閃退
- 嚴重錯誤–critical
- 重要功能不能實現
- 錯誤的涉及面廣，影響到其他重要功能正常時間
- 非常規操作導致的程序崩潰、死機、死循環、閃退
- 外觀（界面）難以接受的缺陷
- 密碼明文顯示
- 偶現的致命性bug
- 重要功能不能實現
- 一般錯誤–major–會遇到最多
- 注意：不影響產品的運行、不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷
- 次要功能不能正常實現
- 操作界面錯誤（功能與列明定義、含義不一致）
- 查詢結果、數據錯誤顯示
- 簡單的輸入限制未放在前端進行控制
- 刪除操作未給出提示—友好一點
- 偶現的嚴重性bug
- 注意：不影響產品的運行、不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷
- 細微錯誤–minor
- 注意：程序在一些顯示上不美觀、不符合用戶習慣、一些文字錯誤–用戶體驗
- 1.界面不規範
- 2.輔助說明描述步清除
- 3.提示窗口文字未採用行業術語
- 4.界面存在文字錯誤
- 注意：程序在一些顯示上不美觀、不符合用戶習慣、一些文字錯誤–用戶體驗
- 改進建議–enhancement–新需求下一個版本
- 可以提高產品質量的建議，包括新需求和對需求的改進
- 可以提高產品質量的建議，包括新需求和對需求的改進
- 致命錯誤–blocker
- bug生命周期（管理流程）—重點
- Bug生命周期：被發現到被關閉的過程
- 一般缺陷狀態：發現–新建（提bug）–指派–已解決–待驗–關閉
- 注意：若bug沒有解決好，需要重新打開（激活）–指派–已解決–待驗，循環這個過程。中間其他狀態：拒絕、延期等。
- bug跟蹤管理流程
- 流程圖
- 狀態處理
- 梳理
- 【發現bug】要先確認，防止環境問題、操作問題等一些外因引起的bug。會被開發認為是無效Bug。
- 【新建（new）】提bug的人或測試老大指派（開發或開發老大），跟進bug，推進開發修復Bug
- 【重複bug（duplicated）】要求開發備註一下重複bug的 id，方便測試人員確認是不是一個問題，如果是重複的，要加備註，關閉。如果不是一個bug，重新激活（reopened），重新指派開發。
- 【不是缺陷（invalid）】（1）By design設計如此（2）對需求理解不一致導致操作失誤–要討論一下：①拿到需求，再次需求分析，從用戶角度開發，找到證據，羅列證據，嘗試說服開發。②無果，找產品或項目經理確認，若是bug，開發修復，不是bug，別糾結，但也留好證據（郵件截圖，備註到bug里）。
- 【無法復現（un-reproduced）】（1）開發無法復現：確認測試環境可否再復現，若可以復現，幫助開發復現，仍無法復現，讓他到測試環境調試定位（2）測試和開發都無法復現，要嘗試跟蹤3-5個版本，每個版本復現超過10次，仍然無法復現，在Bug中加備註(我復現的次數、跟蹤版本數)，關閉該bug，記錄到自己的筆記中。
- 【開發確認Bug後，不予解決（wontfix）】原因bug級別低（建議性Bug、ui的bug），（1）首先要站在用戶角度，說服開發，無果的話（2）找產品確認（3）加備註留證據，最後關閉bug
- 【延期（delayed）】（1）建議性的bug，作為下一個版本的需求（2）上線之前，修復影響較大（性價比低），此時，要分析①對用戶的影響，影響用戶體驗，就要修復②bug嚴重級別高，找項目經理、產品拍板確認。若不修復，備註（留證據）。—延期bug不關閉–掛起狀態
- 【已修復（resolved-fixed）】開發修復後，指派給測試，測試驗證（bug步驟、結果重新操作一遍），驗證後（1）已驗證（verified）加備註–項目結束（closed）（2）仍然存在，reopened重新激活，指派開發，開發確認bug，解決Bug。加備註
- 【發現bug】要先確認，防止環境問題、操作問題等一些外因引起的bug。會被開發認為是無效Bug。
- 加備註：方便跟蹤、查閱bug
- 流程圖
- Bug生命周期：被發現到被關閉的過程
- bug跟蹤管理–缺陷管理工具
- 工具
- 禪道（zentao）、bugzilla、jira、bugfree、Readmine、easybug、Mantis、QC(QualityCenter)、TD
- 禪道（zentao）、bugzilla、jira、bugfree、Readmine、easybug、Mantis、QC(QualityCenter)、TD
- 提bug
- 所屬產品、項目、模塊、影響版本（主幹、分支）、當前指派、截止日期（測試不填）、bug類型、操作系統、瀏覽器、bug標題【重要】、嚴重程度、優先級（測試不填）、重現步驟（實際結果、期望結果）、抄送、附件
- 所屬產品、項目、模塊、影響版本（主幹、分支）、當前指派、截止日期（測試不填）、bug類型、操作系統、瀏覽器、bug標題【重要】、嚴重程度、優先級（測試不填）、重現步驟（實際結果、期望結果）、抄送、附件
- 提交bug包含內容
- 【bug標題】標題要清晰簡潔， 寫明bug描述;如果沒有選擇功能模塊，最好在標題中標註功能模塊。讓查有bug的人員清楚知道你所表達的意思。bug的功能模塊+ bug的操作+ bug的結果。
- 【重現步驟】詳細寫下發現bug的測試步驟-結果-預期。能指導開發重現這個bug。附上測試數據。實際結果用截圖直觀。
- 【實際結果】出現bug的結果，粘貼bug截圖、日誌截圖–直觀，證據(有圖有真相)
- 【預期結果】記得寫清楚預期—-參照測試用例的預期結果
- 【bug類型和嚴重程度】便於後續測試結果分析， bug的統計
- 【bug測試環境】什麼系統，哪個版本等。兼容性問題、難以重現問題
- 【附件】日誌文件， 文件測試數據。圖片、崩潰日誌文件等
- 【bug標題】標題要清晰簡潔， 寫明bug描述;如果沒有選擇功能模塊，最好在標題中標註功能模塊。讓查有bug的人員清楚知道你所表達的意思。bug的功能模塊+ bug的操作+ bug的結果。
- 注意
- 參考公司前輩寫的bug,依葫蘆畫瓢，拓展測試思維。
- 偶現Bug的復現率也可以寫一下。
- 參考公司前輩寫的bug,依葫蘆畫瓢，拓展測試思維。
- 工具
- 常見筆試面試題
- 1:有沒有你印象深刻的bug? bug的原因/bug當時怎麼解決?
- 2: bug的生命周期? (筆試)
- 指被發現到被關閉的過程。一般缺陷狀態：發現–新建（提bug）–指派–已解決–待驗–關閉。延期、不予解決。
- 指被發現到被關閉的過程。一般缺陷狀態：發現–新建（提bug）–指派–已解決–待驗–關閉。延期、不予解決。
- 3:當你開了一個bug,但是開發不認為是bug,如何處理?
- （1）By design設計如此（2）對需求理解不一致導致操作失誤–要討論一下：①拿到需求，再次需求分析，從用戶角度開發，找到證據，羅列證據，嘗試說服開發。②無果，找產品或項目經理確認，若是bug，開發修復，不是bug，別糾結，但也留好證據（郵件截圖，備註到bug里）。
- （1）By design設計如此（2）對需求理解不一致導致操作失誤–要討論一下：①拿到需求，再次需求分析，從用戶角度開發，找到證據，羅列證據，嘗試說服開發。②無果，找產品或項目經理確認，若是bug，開發修復，不是bug，別糾結，但也留好證據（郵件截圖，備註到bug里）。
- 4:你在發現bug並確認bug的過程中，對於復現率不高的bug怎麼處理?
- 無法復現（un-reproduced）：（1）開發無法復現：確認測試環境可否再復現，若可以復現，幫助開發復現，仍無法復現，讓他到測試環境調試定位（2）測試和開發都無法復現，要嘗試跟蹤3-5個版本，每個版本復現超過10次，仍然無法復現，在Bug中加備註(我復現的次數、跟蹤版本數)，關閉該bug，記錄到自己的筆記中。
- 無法復現（un-reproduced）：（1）開發無法復現：確認測試環境可否再復現，若可以復現，幫助開發復現，仍無法復現，讓他到測試環境調試定位（2）測試和開發都無法復現，要嘗試跟蹤3-5個版本，每個版本復現超過10次，仍然無法復現，在Bug中加備註(我復現的次數、跟蹤版本數)，關閉該bug，記錄到自己的筆記中。
- 1:有沒有你印象深刻的bug? bug的原因/bug當時怎麼解決?
