文章目錄
一、缺陷的基本概述
1、缺陷的定義（重要）：
2、缺陷屬性
二、缺陷的生命週期（重要）
三、缺陷的識別
四、缺陷報告
五、測試需求、測試用例、缺陷報告的關係？
①軟體未實現產品說明書要求的功能
②軟體出現了產品說明書指明不該出現的功能
③軟體實現了產品說明書未提到的功能
④軟體未實現產品說明書雖未明確提及但應該實現的目標
⑤軟體難以理解、不易使用、執行緩慢或者（從測試角度看）終端使用者會認為不好
1、缺陷的型別：
功能、使用者介面、文件、軟體包、效能、系統/模組介面
①致命：系統任何乙個主要功能完全喪失，使用者資料收到破壞，系統崩潰、懸掛、宕機，或者危及人身安全。
②嚴重：系統的主要功能部分喪失，資料不能儲存，系統的次要功能完全喪失，系統所提供的的功能或服務收到明顯的影響。
③一般：系統的次要功能沒有完全實現，但不影響使用者的正常使用。例如：提示資訊不太準確或使用者介面差、操作時間長等一些問題。
④較小：是操作者不方便或遇到麻煩，但它不影響功能的操作和執行，如個別不影響產品理解的錯別字、文字排列不整齊等小問題。
注意：結合缺陷的影響，結合軟體的具體功能（業務或者流程）
注意：優先順序的衡量，一般可以根據測試的軟體系統的全業務流程劃分，軟體的基本功能的缺陷，優先順序高，甚至需要立即解決。軟體的備選流、基本功能測試中的反向測試的內容，優先順序較低，甚至有些可改可不改。
缺陷的嚴重程度和優先順序有什麼關係？
1、沒有任何直接的關係，嚴重程度是指缺陷對軟體的影響，而優先順序是指缺陷對測試的影響。
2、不要認為嚴重的缺陷，修復優先順序就高；
3、如果碰到，優先順序和嚴重程度都高的缺陷，也只是偶然。例如，qq的幫助按鈕，會有經常閃退的現象。嚴重程度很高，但是優先順序就很低。又例如企業logo錯誤，不影響任何功能，但是必須優先修復。
提交缺陷時能不能誇大或降低缺陷的嚴重程度或者優先順序？
不能，不能搞「狼來了」，也不能搞私人關係，"幫"好朋友減少不良影響。要公正、客觀。
4、缺陷的狀態：
缺陷狀態指缺陷的處理進度。
發現缺陷時缺陷處理的前提，但是還沒有進入缺陷的處理流程。
5、缺陷的起源：
缺陷起源是指缺陷引起的故障或事件第一次被檢測到的階段。
缺陷起源有：需求、構架、設計、編碼、測試、使用者。
缺陷**指缺陷的起因。缺陷被發現的階段，直接原因。
7、缺陷的根源：
缺陷根源指發生錯誤的根本因素。一般發生在總結階段。
缺陷根源有：測試策略、過程/工具和方法、團隊/人、缺乏組織和通訊、硬體、軟體、工作環境。
類似於面試官提問：針對你工作中發現的乙個bug，說說這個bug的處理過程。其實就是要說明缺陷的生命週期中，每乙個環節由誰做什麼。
1、發現缺陷。由測試人員發現。開發人員也能知道自己**寫錯了，但是不會廣而告之。
2、提交缺陷。由測試人員提交。
3、確認缺陷。一般由測試主管、質量保證、產品經理進行確認。
4、分配缺陷。經確認後，有效的缺陷會指派給相關人員進行處理。一般由誰確認的缺陷，就由誰分配。分配的物件可能是開發，也可能是ui、產品經理。
5、修復缺陷。主要由開發修復，也有可能產品經理、ui修復問題。
6、驗證缺陷。測試去驗證缺陷有沒有修復成功。
7、關閉缺陷。只能是測試人員進行，否則出現了問題，測試人員一律不背鍋。
依據：需求文件、設計文件、產品原型、測試用例，都是客觀的依據。
同行業類似的成熟軟體，和開發人員溝通，和有經驗的測試人員溝通，同行業隱式需求。這些都是帶有主觀色彩的依據。
測試人員在識別缺陷的時候，要很靈活地對待。
1、缺陷報告模板：
缺陷編號。bug_專案名稱_模組名稱_功能名稱_0001
所屬模組。一級模組/二級模組/**模組
優先順序。缺陷的修復緊急程度。p1>p2>p3>p4
嚴重程度。s1>s2>s3>s4。
缺陷概述。用一句話描述缺陷的基本情況（時間、地點、人物、事件）。
缺陷描述。將缺陷的復現步驟、預期結果和實際結果列出來。缺陷描述的準則：可再現，除了類似閃退、崩潰等不可再現的缺陷。不做評價，不對缺陷出現的嚴重程度和缺陷表現出來的效果進行主觀臆斷。
提交人。
備註。一般寫產生該缺陷的特殊情況。將bug的截圖作為備註資訊。
2、缺陷報告編寫目的：
3、預期讀者：開發人員、質量管理、市場人員、運維人員。
所以缺陷報告要寫得很直白、清晰明了。
4、缺陷報告編寫準則：準確、清晰、簡潔、完整、一致。
缺陷報告本身要保證沒有任何表述性的錯誤。
5、缺陷跟蹤系統：禪道、alm、jira等
測試的基本流程：獲取測試需求--編寫測試計畫--制訂測試方案--設計和開發測試用例--執行測試--提交缺陷--測試分析和評審--測試總結--準備下一版本的測試
獲取測試需求是測試工作的重點，也是第一步。通過需求的分析，了解和掌握測試的方向和內容。例如：
1）分析出系統的模組和組織結構
2）分析出軟體的基本功能和執行流程。（業務分析）包括可能會有哪些人或者哪些角色要用。
3）識別出軟體的重要功能和次要功能。
獲取測試需求的過程中，測試人員就要有相應的分析成果，一般用xmind這樣的思維導圖工具進行分析，或者使用需求跟蹤矩陣來完成測試需求的獲取和分析。
設定測試需求的正、反向和優先順序。
當有了測試需求之後，就開始針對每乙個需求點進行測試用例的設計。也就是，每乙個需求點，都要被測試。
因此測試的過程中，衡量需求的覆蓋程度，就非常重要。使用公式進行計算和說明：需求的覆蓋程度=被測試時用例覆蓋的需求數/需求點總數。
如果需求覆蓋度<100%，那一定說明了測試的覆蓋度不夠。
測試中，最能體現測試人員工作量的指標就是缺陷的數量和用例的數量。
1）設計的測試用例總量 tc。
2）執行的測試用例數量 ec。
3）未執行的測試用例數量 wc。
4）執行通過的測試用例總量 sc。
5）執行失敗的測試用例總量 fc。
6）提交的缺陷的總量 bc。
以上幾個資料，它們要符合以下的數量關係：
1)tc>=ec
2)tc=ec+wc
3)ec=sc+fc
4)bc>=fc。提交的bug數量，多於執行未通過的用例數。一條用例的預期結果數量是固定的（甚至是唯一的）。說明了，測試過程中發現的缺陷，除一部分是用例執行失敗帶來的，還有一部分是測試人員自身的經驗和直覺帶來的。
5）通過 sc/ec 可以表現出系統的質量是否合格。
6）通過 ec/tc 可以表現出系統的需求是否得到滿足。
缺陷調研報告 缺陷整改報告
第 頁缺陷整改報告 篇一 現場檢查缺陷專案整改報告 現場檢查缺陷專案整改報告 某市食品藥品監督管理局 由市局委派的現場檢查組對我公司藥品經營質量管理情況 進行了現場檢查。經過檢查組認真 仔細檢查，我公司在藥品經營質 量管理方面存在一般缺陷專案 項 嚴重缺陷專案 項。對此我公司高度重視，組織了現場檢查...
提交缺陷報告
軟體出現了產品說明書指明不會出現的錯誤 軟體功能超出產品說明書指明範圍 軟體未達到產品說明書雖未指出但應達到的目標 軟體測試員認為軟體難以理解 不易使用 執行速度緩慢，或者終端使用者認為不好。重複缺陷 質量管理人員 市場人員 技術支援人員 clear 清晰 concise 簡潔 complete 完...
編寫和管理缺陷報告
缺陷報告的用途 1.記錄缺陷 2.缺陷分類 3.缺陷跟蹤 缺陷分類 1.按缺陷的嚴重程度 影響進度的問題 宕機功能問題 介面問題 建議2.按修復缺陷的優先順序 應立即修復的問題 在產品發布之前必須修復的問題 如果時間允許應該修復的問題 可以在發布版本中存在的問題 備註 缺陷的嚴重程度和優先順序各軟體...