軟件的缺陷
在軟件的開發與使用過程當中每每會出現與咱們預料以外的各類影響軟件功能的錯誤。
在IT行業咱們稱這些影響軟件正常功能的錯誤叫缺陷。
這篇文章將要和你們介紹軟件的缺陷，以及在項目中測試人員如何管理這些缺陷
1、瞭解缺陷web
1. 定義：缺陷又稱BUG。計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。從產品內部來看，缺陷是軟件產品開發或維護過程當中存在的錯誤、毛病等各類問題；從產品外部看，缺陷就是系統所須要實現的某種功能的失效或違背。數據庫
2. 缺陷的來源：來源於軟件生命週期的各個階段工具
3. 產生緣由：post
產品說明書不全，不完整和不許確，修改頻繁，溝通不順暢和理解不一樣，軟件設計過程當中的考慮不周到，片面，多變理解和溝通不足測試
4. 缺陷的評價標準spa
• 軟件未實現需求規格說明書（SRS）要求的功能
• 軟件未實現需求規格說明書（SRS）雖未明確說起但應該實現的目標
• 軟件出現了需求規格說明書（SRS）指明不該出現的錯誤
• 軟件實現了需求規格說明書（SRS）未提到的功能
• 軟件難以理解、不易使用、運行緩慢，或者從測試工程師的角度來看——最終用戶會認爲很差開放源代碼
5. 缺陷的屬性設計
項目中，大多數都是用工具來管理缺陷的，因此像缺陷ID、發現的時間、發現人等都是自動生成的3d
相關附件中，測試人員能夠附上BUG的截圖、跟蹤日誌等版本控制
6. 缺陷的類型
遺漏、錯誤、額外的實現、改進
7. 缺陷優先級的劃分
表示處理和修正軟件缺陷的前後順序的指標，即那些缺陷須要優先修正，哪些缺陷能夠稍後修正
8. 缺陷嚴重程度的劃分
指因缺陷引發的故障對軟件產品的影響程度
9. 缺陷跟蹤的交付物
缺陷報告單（Bug Report）：也叫缺陷跟蹤單。測試執行過程當中，發現軟件失效後，提出書面的報告，提供給開發人員或者其餘負責人員做爲定位缺陷的依據，也做爲往後缺陷度量的數據依據
缺陷管理工具中的BUG report
10. 缺陷的生命週期
就是指缺陷從開始到最後徹底解決，並經過驗證和確認的過程。
在這個過程當中缺陷報告的狀態不斷髮生着變化，記錄着缺陷被處理的過程。
11. 缺陷的流程及對應的狀態
狀態說明：
1. 新建（new）：測試人員提交新問題標識的狀態
2. 打開（open）：已經確認爲是BUG的狀態
3. 已修復（fixed）：爲開發人員修改問題後所標誌的狀態，等待測試驗證
4. 從新打開（reopen）：測試人員對修改問題進行驗證後沒有經過所標誌的狀態或者已經修改正確的問題又從新出現錯誤，由測試人員改變。
5. 已關閉（closed）：爲測試人員對修改問題進行驗證後經過所標誌的狀態。由測試人員改變
6. 拒絕（rejected）：開發人員認爲不是BUG、描述不清楚、重複、不能復現、不採納所提意見建議、或雖然是個錯誤但還沒到非改不可的地步故忽略不急、或者測試人員提錯、從而拒絕的問題。由BUG分配人或者開發人員來設置。
7. 重複（duplicated）表示該BUG已經被其它測試人員找出來了，或者開發認爲緣由是相同的（但從測試來看，認爲出現的地方不一樣、表現有所不一樣等），後者建議重視，單獨提出這個bug，由於若是不提，可能會影響咱們後續的跟蹤。
8. 延期（postponed）：因爲時間、進度、重要程度或者技術/需求等方面的緣由認爲不能解決、延期解決、或者本版不作保留待到後續版本解決的Bug。
放棄（abandon）：被拒絕或重複的缺陷，測試人員確認後的確不是問題，將缺陷置爲此狀態，abandon是一種特殊意義的closed（測試人員標記的狀態）
12. 缺陷的狀態遷移矩陣
2、缺陷管理
1. 缺陷溝通（溝通是測試人員的主要工做之一）
2. 簡單的BUG跟蹤流程
3. 軟件測試缺陷管理流程
4. 缺陷管理中常出現的問題和應對方法
問題：
• 提交的缺陷開發人員不承認怎麼辦？
• 如何處理不能重現的缺陷？
• 如何處理好與開發人員及其餘相關人員的關係？
• 缺陷太多怎麼辦？
• 找不到缺陷怎麼辦？
• 缺陷得不到及時修復怎麼辦？
• 如何處理缺陷級別定義之爭？
• 如何處理缺陷跟蹤中的扯皮現象？
解決方法：
1. 測試人員要對本身有自信，由於咱們有依據，確認本身沒有問題後，開發若還不承認，能夠向領導尋求幫助
2. 養成出現缺陷立馬記錄下來的習慣（截圖）方便後續處理，避免背鍋
3. 注意溝通的語氣（委婉），工做之餘培養好關係
4. 重點關注缺陷多的模塊，缺陷太多的模塊直接打回給開發
5. 先分析本身，是否是本身設計的用例不全，有沒有覆蓋需求
6. 及時跟蹤缺陷，及時瞭解開發修復的進度，若遲遲得不到修復的話上報領導
7. 先和開發解釋，解釋不了能夠尋求幫忙（這種狀況通常不會出現）
8. 確保自身沒有問題，儘可能說服開發，若不行上報領導
5. 缺陷報告的書寫
書寫準則（5C）：
• Correct（準確）---每一個組成部分的描述準確，不會引發誤解
• Clear（清晰）---每一個組成部分的描述清晰，易於理解
• Concise（簡潔）---只包含必不可少的信息，不包括任何多餘的內容
• Complete（完整）---包含復現該缺陷的完整步驟和其餘本質信息
• Consistent（一致）---按照一致的格式書寫所有缺陷報告
缺陷報告的寫做要點：
• 再現：通常是儘可能三次再現故障，若是問題是間斷的，那要報告問題發生頻率。
• 初步定位：可能影響再現的變量，例如配置變化、工做流、數據庫，這些均可能改變錯誤的特徵。
• 推廣：肯定系統其餘部分是否可能出現這種錯誤，以及使用不一樣的數據時是否存在着這種問題等等，特別是那些可能存在更加嚴重特徵的部分。
• 壓縮：精簡任何沒必要要的信息，特別是冗餘的測試步驟。
• 去除歧義：使用清晰的語言，尤爲是避免使用那些有多個不一樣或相反含義的詞彙。
• 中立：公正的表達本身的意思，對錯誤及其特徵的事實進行陳述，避免誇張、幽默或諷刺。
• 評審：至少有一個同行，最好是一個有經驗的測試工程師或測試經理，在遞交錯誤報告以前本身先閱讀一遍。
缺陷報告單的基本內容
BUG的摘要要用一句話的形式簡明扼要地將BUG藐視出來，要清晰指出BUG所在部位以及其錯誤類型。
3、經常使用的缺陷管理工具
1. 缺陷管理的目的
• 保證信息的一致性
• 保證缺陷獲得有效的跟蹤，縮短溝通時間，解決問題更高效
• 利於缺陷分析、產品度量，使項目狀況可視化增強
2. 經常使用的缺陷管理工具
1. QC（QC是TD的升級版，QC的升級就是ALM）
2. 禪道(bugfree升級版）
3. Mantis
4. JIRA
5. TestLink
6. Bugzilla
7. Redmine
TD不只能夠管理缺陷，還能夠管理測試、需求乃至整個項目過程（收費）
禪道：也是項目管理工具，不只能夠管理缺陷，基於敏捷開發模型，一樣適用與其它開發模型（開源）
3. 經常使用工具說明
1. QC 商業購買 --基於Web的測試管理工具，能夠組織和管理應用程序測試流程的全部階段，包括指定測試需求、計劃測試、執行測試和跟蹤缺陷。此外，經過Quality Center還能夠建立報告和圖來監控測試流程。
2. 禪道 國產開源 -- 本地化作的比較好。禪道是爲研發類項目/團隊量身定製的一款管理軟件，覆蓋產品開發的整個生命週期，頁面簡潔、流程清晰。
3. Mantis 開源 -- 是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操做的形式提供項目管理及缺陷跟蹤服務。正己守道 厚德載物
4. TestLink 開源，能夠與Mantis集成；是sourceforge的開放源代碼項目之一，做爲基於web的測試管理系統。
5. JIRA 開源，可二次開發，是Atlassian公司出品的項目與事務跟蹤工具。
6. Bugzilla 是Mozilla公司提供的一款開源的免費Bug（錯誤或是缺陷）追蹤系統，用來幫助你管理軟件開發，創建完善的BUG跟蹤體系
7. Redmine 是一個開源的、基於web的項目管理和缺陷跟蹤工具。它用日曆和甘特圖輔助項目及進度可視化顯示，同時它支持多項目管理。Redmine是一個自由開放源碼軟件的解決方案，它提供集成的項目管理功能，問題跟蹤，併爲多個版本控制的選項的支持。