軟體測驗程序中提交缺陷是測驗工程師最常做的一件事，也是開發工程師解決問題的依據，所以需要對缺陷進行管理和分析，缺陷管理主要是管理從提交缺陷到解決缺陷這一系列的程序，包括流程中角色的變換，
缺陷分析主要對測驗程序中所發現的缺陷進行分類分析，分析缺陷分布的情況，并對缺陷產生的原因進行歸納分類，為改善研發和測驗程序提供依據，本章節我們先講解“缺陷管理與分析”的內容，
缺陷報告的發展：早期并沒有缺陷的概念，直到第一臺計算機誕生后才有人提出Bug一詞，那時僅僅是將缺陷使用Bug這個詞來描述，而并未真正對缺陷的產生進行詳細的描述，1945 年美國的哈珀將軍第一次通過報告的形式來描述缺陷，
Bug的由來
Bug一詞的原意是“臭蟲”或“蟲子”，現在在軟體測驗程序中所有發現的問題，我們都喜歡使用“Bug”這個詞來描述，
早期第一代的計算機是由許多龐大且昂貴的真空管組成，并利用大量的電子真空管發光，可能正是由于計算機運行產生的光和熱，導致一只小蟲子鉆進了一支真空管內，使整個計算機無法作業，
研究人員花費很長時間才找到小蟲子所在的真空管，將其取出后，計算機又恢復正常，后來“Bug”這個名詞就沿用下來，表示計算機系統或程式中隱藏的錯誤、缺陷或問題，與Bug 相對應，人們將發現Bug 并加以糾正的程序稱為“Debug”，即“捉蟲子”或“殺蟲子”，
遺憾的是，在中文中一直沒有找到一個恰當的詞來準確地翻譯“Bug”的意思，因此就一直使用“Bug”一詞來表示，所以測驗中所有的問題我們都稱之為“Bug”，
一份簡單的缺陷報告
從計算機誕生之日起，就存在Bug，但早期并沒有針對缺陷的相關報告，第一個使用缺陷報告的方式來記錄Bug 的是美國海軍編程員、編譯器的發明者格蕾斯· 哈珀(Grace Hopper)，哈珀后來成為了美國海軍的一個將軍，領導了著名計算機語言Cobol 的開發，
1945年9月9日下午15點，哈珀中尉正帶領著她的小組構造一個稱為“馬克二型”的計算機，
當時的計算機并不完全是電子計算機，還使用著大量的繼電器，那時正處于第二次世界大戰期間，哈珀的團隊在一間第一次世界大戰時建造的老建筑中作業，夏天很炎熱又沒有空調，所有的窗戶都敞開散熱，突然“馬克二型”死機了，研究員想盡了辦法，最后定位到第70 號繼電器出現故障，仔細研究發現原來是一只飛蛾在繼電器里面，當然飛蛾被繼電器電死了，她小心地使用鑷子將飛蛾取出來，并用透明膠布貼到記錄本中，這是第一次對缺陷進行描述，
早期的缺陷報告描述是很簡單的，只對缺陷的步驟進行描述，下面是一份簡單的缺陷報告，
缺陷標題：Arial、Wingdings 和Symbol 字體會破壞新檔案缺陷產生的步驟：
- (1)啟動WordEdit 編輯器，然后創建新檔案;
- (2)輸入四行文本，如重復輸入內容“The quick fox jumps over the lazy brown dog”;
- (3)選中所有四行文本，然后選擇字體下拉選單，并選擇“Arial”字體，所有文本被轉換成控制字符、數字和其他明顯的隨機二進制資料，
這是一份簡單的缺陷報告，現在的缺陷報告所包含的元素已經豐富了很多，
一份好的缺陷報告
一份好的缺陷報告應該包含以下元素：缺陷ID 號、嚴重等級、歸屬版本、歸屬模塊、簡要描述、詳細描述、附件、提交日期、提交人、當前狀態、當前負責人和當前測驗環境，
(1)缺陷ID號
- 缺陷ID號即提交Bug 的ID號，一般情況下，當我們在缺陷管理系統中提交Bug 時，缺陷管理系統會自動生成一個ID 號，并不需要人為的定義，當然不同的缺陷管理系統生成缺陷ID 號的方式有所不同，
(2)嚴重等級
- 缺陷嚴重等級是缺陷報告中最重要的屬性之一，缺陷的嚴重等級分為：致命、嚴重、一般和建議四類，衡量缺陷的嚴重等級必須考慮兩個維度：該功能在客戶端使用的頻率和缺陷帶來的影響詳見7.3.1 小節，
(3)歸屬版本
- 歸屬版本是指當前測驗的版本，即發現該Bug 所測驗的系統版本，
(4)歸屬模塊
- 歸屬模塊是指測驗哪個模塊發現Bug 的，即該Bug 是由哪個模塊引起的，
(5)簡要描述
- 簡要描述即使用一句話簡要地概述該Bug 的內容，簡要描述要簡單明了，最好是一看便知道其含義，一般不超過15 個字，
(6)詳細描述
- 詳細描述是Bug報告中的核心內容之一，需要通過詳細的步驟來介紹發現Bug 的程序，一般分步驟地描述，這樣讓讀Bug 的人更輕松、更省時且易理解，對于一些建議的問題，在詳細描述里面還應該寫明建議將功能修改成什么樣，
(7)附件
- 附件是用來輔助描述Bug的內容，一般包括以下幾種形式：圖片、日志檔案、組態檔等，對于一些操作步驟或Bug 的結果，如果不能很準確地描述，應該借助圖片來幫助描述，圖片可以讓開發工程師很簡單地了解Bug 的步驟和結果;日志檔案主要是將出現Bug 時的日志檔案附帶給開發工程師，這樣便于分析Bug 出現的原因;相關組態檔主要是在出現Bug 時，將系統的相關組態檔附帶給開發工程師，便于分析Bug 出現的原因，
(8)提交日期
- 提交日期是指提交Bug時的日期，一般情況下缺陷管理工具會自動生成，
(9)提交人
- 提交人是指提交該Bug 的測驗工程師，
(10)當前狀態
- 當前狀態是指Bug 當前的狀態，Bug 狀態在7.3.4 節有詳細的介紹，每到一個步驟Bug 都有一個對應的狀態，而這個狀態一定要更新正確，
(11)當前負責人
- 當前負責人是指該Bug 由哪些開發工程師負責修復，
(12)當前測驗環境
- 當前測驗環境是指發現該Bug 時所處的環境，測驗環境主要包括使用的瀏覽器、解析度、作業系統和相關硬體資訊，
- 1)瀏覽器是指當前測驗使用的是哪個廠家的瀏覽器及相關的版本，主要用于分析一些瀏覽器兼容的問題，
- 2)解析度是指當前測驗時系統的解析度，主要用于分析一些關于界面顯示的問題，
- 3)作業系統是指當前測驗時的作業系統，應該介紹是什么作業系統以及是32 位還是64 位，
- 4)相關硬體資訊更多的是用于嵌入式系統的描述上，在純軟體的系統中一般不需要描述此項內容，對于嵌入式的測驗應該描述清楚主板、電源板、介面板等其他硬體的版本資訊，
缺陷報告應該遵循以下幾個原則：
- Correct(準確)：每個組成部分的描述應該準確無誤，不會引起誤解，
- Clear(清晰)：每個組成部分的描述應該清晰，易于理解，
- Concise(簡潔)：只包含必不可少的資訊，不包括任何冗余的內容，
- Complete(完整)：包含修改該缺陷的完整步驟和其他本質資訊，
- Consistent(一致)：按照一致的格式書寫全部缺陷報告，
本章節關于“軟體測驗—缺陷管理與分析”的內容就學習到這里，大家覺得文章有用的話記得每天來這里和小編一起學習漲薪技能哦，
最后感謝每一個認真閱讀我文章的人，看著粉絲一路的上漲和關注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：
這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你!
關注我的公眾號：程式員小濠免費獲取~
碼字不易，文章對你有幫助的話，點個贊收個藏，給作者一個鼓勵，也方便你下次能夠快速查找，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/299964.html
標籤：其他
上一篇：軟體測驗復習整理
下一篇：Jmeter的基本使用