缺陷和缺陷报告_质量缺陷报告
文章目錄
一、缺陷的基本概述
1、缺陷的定義（重要）：
2、缺陷屬性
二、缺陷的生命周期（重要）
三、缺陷的識別
四、缺陷報告
五、測試需求、測試用例、缺陷報告的關(guān)系？
一、缺陷的基本概述
1、缺陷的定義（重要）：
①軟件未實現(xiàn)產(chǎn)品說明書要求的功能
②軟件出現(xiàn)了產(chǎn)品說明書指明不該出現(xiàn)的功能
③軟件實現(xiàn)了產(chǎn)品說明書未提到的功能
④軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應該實現(xiàn)的目標
⑤軟件難以理解、不易使用、運行緩慢或者（從測試角度看）最終用戶會認為不好
2、缺陷屬性
1、缺陷的類型：
功能、用戶界面、文檔、軟件包、性能、系統(tǒng)/模塊接口
注意：需求分析、設計階段，文檔類型缺陷多；
集成測試階段，一般接口類型的缺陷多一些；
系統(tǒng)測試階段，功能、界面類型的缺陷多一些；
驗收測試階段，更多地關(guān)注性能缺陷；
實施過程，可能會遇到一些軟件包的缺陷。
2、缺陷的嚴重程度：缺陷的故障對軟件的影響，每個公司和團隊的分類標準略有不同。
①致命：系統(tǒng)任何一個主要功能完全喪失，用戶數(shù)據(jù)收到破壞，系統(tǒng)崩潰、懸掛、死機，或者危及人身安全。
②嚴重：系統(tǒng)的主要功能部分喪失，數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失，系統(tǒng)所提供的的功能或服務收到明顯的影響。
③一般：系統(tǒng)的次要功能沒有完全實現(xiàn)，但不影響用戶的正常使用。例如：提示信息不太準確或用戶界面差、操作時間長等一些問題。
④較小：是操作者不方便或遇到麻煩，但它不影響功能的操作和執(zhí)行，如個別不影響產(chǎn)品理解的錯別字、文字排列不整齊等小問題。
注意：結(jié)合缺陷的影響，結(jié)合軟件的具體功能（業(yè)務或者流程）
3、缺陷的修復優(yōu)先級：很大程度上取決于缺陷對測試工作的影響程度。有以下等級：立即解決、高優(yōu)先級、正常排隊、低優(yōu)先級。
例如：電商系統(tǒng)的用戶注冊功能無法使用（導致無法登錄、購買、結(jié)算、支付、下單、物流跟蹤、收獲、評論等功能無法進行），就必須立即修復。但是電商系統(tǒng)中關(guān)于用戶購買流程幫助說明的網(wǎng)頁鏈接點擊404頁面，就比較次要。
注意：優(yōu)先級的衡量，一般可以根據(jù)測試的軟件系統(tǒng)的全業(yè)務流程劃分，軟件的基本功能的缺陷，優(yōu)先級高，甚至需要立即解決。軟件的備選流、基本功能測試中的反向測試的內(nèi)容，優(yōu)先級較低，甚至有些可改可不改。
缺陷的嚴重程度和優(yōu)先級有什么關(guān)系？
1、沒有任何直接的關(guān)系，嚴重程度是指缺陷對軟件的影響，而優(yōu)先級是指缺陷對測試的影響。
2、不要認為嚴重的缺陷，修復優(yōu)先級就高；
3、如果碰到，優(yōu)先級和嚴重程度都高的缺陷，也只是偶然。例如，QQ的幫助按鈕，會有經(jīng)常閃退的現(xiàn)象。嚴重程度很高，但是優(yōu)先級就很低。又例如企業(yè)logo錯誤，不影響任何功能，但是必須優(yōu)先修復。
提交缺陷時能不能夸大或降低缺陷的嚴重程度或者優(yōu)先級？
不能，不能搞“狼來了”，也不能搞私人關(guān)系，”幫”好朋友減少不良影響。要公正、客觀。
4、缺陷的狀態(tài)：
缺陷狀態(tài)指缺陷的處理進度。
發(fā)現(xiàn)缺陷時缺陷處理的前提，但是還沒有進入缺陷的處理流程。
①激活/打開（新建）：由測試人員進行標注。
②確認：確認新提交的缺陷是一個真實有效的缺陷。一般由測試主管或者質(zhì)量保證、產(chǎn)品經(jīng)理進行確認。經(jīng)確認后，有效的缺陷會指派給相關(guān)人員進行處理。
③已修復/修正。缺陷修復，一般由開發(fā)人員進行。
④關(guān)閉/非激活。缺陷被修復完成后，經(jīng)過測試人員的驗證后，沒有問題。
⑤重新打開。經(jīng)過測試人員的驗證后，缺陷沒有修復成功，需要重新打開進行再次處理和修復。
⑥推遲。缺陷現(xiàn)在不修復，推遲到下一個版本或階段。測試要跟開發(fā)或者其他相關(guān)管理人員進行確認。
⑦保留。缺陷暫時修復不了，一般也是由開發(fā)人員去設定。也需要測試人員進行確認。
⑧不能重現(xiàn)。開發(fā)按照缺陷的復現(xiàn)步驟不能再次發(fā)現(xiàn)缺陷。一般閃退、崩潰類型的缺陷具有類似的特征。或者由于操作系統(tǒng)的差異，瀏覽器的緩存等信息，出現(xiàn)的問題。所以作為測試人員，提交bug之前，要再三確認bug。
⑨需要更多信息。作為測試人員，提交bug的時候，要盡可能把所有相關(guān)的文件一起提交（圖片、視頻）。
⑩重復。測試中，一定要避免這種情況的出現(xiàn)。尤其在軟件的某個功能頻繁被多個模塊（由不同的測試人員測試）調(diào)用的情況下。
?不是缺陷。一定不要在測試工程師的工作生涯中被開發(fā)標注缺陷狀態(tài)為不是bug。
?需要修改軟件規(guī)格說明書。缺陷不是技術(shù)原因造成的，而是由于需求不明確或設計不明確。
5、缺陷的起源：
缺陷起源是指缺陷引起的故障或事件第一次被檢測到的階段。
缺陷起源有：需求、構(gòu)架、設計、編碼、測試、用戶。
6、缺陷的來源：
缺陷來源指缺陷的起因。缺陷被發(fā)現(xiàn)的階段，直接原因。
缺陷來源有：需求說明書、設計文檔、系統(tǒng)集成接口、數(shù)據(jù)流（庫）、程序代碼。
7、缺陷的根源：
缺陷根源指發(fā)生錯誤的根本因素。一般發(fā)生在總結(jié)階段。
缺陷根源有：測試策略、過程/工具和方法、團隊/人、缺乏組織和通訊、硬件、軟件、工作環(huán)境。
二、缺陷的生命周期（重要）
類似于面試官提問：針對你工作中發(fā)現(xiàn)的一個bug，說說這個bug的處理過程。其實就是要說明缺陷的生命周期中，每一個環(huán)節(jié)由誰做什么。
1、發(fā)現(xiàn)缺陷。由測試人員發(fā)現(xiàn)。開發(fā)人員也能知道自己哪里寫錯了，但是不會廣而告之。
2、提交缺陷。由測試人員提交。
3、確認缺陷。一般由測試主管、質(zhì)量保證、產(chǎn)品經(jīng)理進行確認。
4、分配缺陷。經(jīng)確認后，有效的缺陷會指派給相關(guān)人員進行處理。一般由誰確認的缺陷，就由誰分配。分配的對象可能是開發(fā)，也可能是UI、產(chǎn)品經(jīng)理。
5、修復缺陷。主要由開發(fā)修復，也有可能產(chǎn)品經(jīng)理、UI修復問題。
6、驗證缺陷。測試去驗證缺陷有沒有修復成功。
7、關(guān)閉缺陷。只能是測試人員進行，否則出現(xiàn)了問題，測試人員一律不背鍋。
三、缺陷的識別
依據(jù)：需求文檔、設計文檔、產(chǎn)品原型、測試用例，都是客觀的依據(jù)。
同行業(yè)類似的成熟軟件，和開發(fā)人員溝通，和有經(jīng)驗的測試人員溝通，同行業(yè)隱式需求。這些都是帶有主觀色彩的依據(jù)。
測試人員在識別缺陷的時候，要很靈活地對待。
四、缺陷報告
1、缺陷報告模板：
- 缺陷編號。Bug_項目名稱_模塊名稱_功能名稱_0001
- 所屬模塊。一級模塊/二級模塊/三級模塊
- 優(yōu)先級。缺陷的修復緊急程度。P1>P2>P3>P4
- 嚴重程度。S1>S2>S3>S4。
- 缺陷概述。用一句話描述缺陷的基本情況（時間、地點、人物、事件）。
- 缺陷描述。將缺陷的復現(xiàn)步驟、預期結(jié)果和實際結(jié)果列出來。缺陷描述的準則：可再現(xiàn)，除了類似閃退、崩潰等不可再現(xiàn)的缺陷。不做評價，不對缺陷出現(xiàn)的嚴重程度和缺陷表現(xiàn)出來的效果進行主觀臆斷。
- 提交人。
- 備注。一般寫產(chǎn)生該缺陷的特殊情況。將Bug的截圖作為備注信息。
2、缺陷報告編寫目的：
- 展現(xiàn)缺陷的詳細信息
- 展現(xiàn)缺陷的影響程度和方式
3、預期讀者：開發(fā)人員、質(zhì)量管理、市場人員、運維人員。
所以缺陷報告要寫得很直白、清晰明了。
4、缺陷報告編寫準則：準確、清晰、簡潔、完整、一致。
缺陷報告本身要保證沒有任何表述性的錯誤。
5、缺陷跟蹤系統(tǒng)：禪道、ALM、JIRA等
五、測試需求、測試用例、缺陷報告的關(guān)系？
測試的基本流程：獲取測試需求–編寫測試計劃–制訂測試方案–設計和開發(fā)測試用例–執(zhí)行測試–提交缺陷–測試分析和評審–測試總結(jié)–準備下一版本的測試
獲取測試需求是測試工作的重點，也是第一步。通過需求的分析，了解和掌握測試的方向和內(nèi)容。例如：
1）分析出系統(tǒng)的模塊和組織結(jié)構(gòu)
2）分析出軟件的基本功能和運行流程。（業(yè)務分析）包括可能會有哪些人或者哪些角色要用。
3）識別出軟件的重要功能和次要功能。
獲取測試需求的過程中，測試人員就要有相應的分析成果，一般用xmind這樣的思維導圖工具進行分析，或者使用需求跟蹤矩陣來完成測試需求的獲取和分析。
設定測試需求的正、反向和優(yōu)先級。
當有了測試需求之后，就開始針對每一個需求點進行測試用例的設計。也就是，每一個需求點，都要被測試。
因此測試的過程中，衡量需求的覆蓋程度，就非常重要。使用公式進行計算和說明：需求的覆蓋程度=被測試時用例覆蓋的需求數(shù)/需求點總數(shù)。
如果需求覆蓋度<100%，那一定說明了測試的覆蓋度不夠。
測試中，最能體現(xiàn)測試人員工作量的指標就是缺陷的數(shù)量和用例的數(shù)量。
1）設計的測試用例總量 TC。
2）執(zhí)行的測試用例數(shù)量 EC。
3）未執(zhí)行的測試用例數(shù)量 WC。
4）執(zhí)行通過的測試用例總量 SC。
5）執(zhí)行失敗的測試用例總量 FC。
6）提交的缺陷的總量 BC。
以上幾個數(shù)據(jù)，它們要符合以下的數(shù)量關(guān)系：
1)TC>=EC
2)TC=EC+WC
3)EC=SC+FC
4)BC>=FC。提交的Bug數(shù)量，多于執(zhí)行未通過的用例數(shù)。一條用例的預期結(jié)果數(shù)量是固定的（甚至是唯一的）。說明了，測試過程中發(fā)現(xiàn)的缺陷，除一部分是用例執(zhí)行失敗帶來的，還有一部分是測試人員自身的經(jīng)驗和直覺帶來的。
5）通過 SC/EC 可以表現(xiàn)出系統(tǒng)的質(zhì)量是否合格。
6）通過 EC/TC 可以表現(xiàn)出系統(tǒng)的需求是否得到滿足。
總結(jié)
以上是生活随笔為你收集整理的缺陷和缺陷报告_质量缺陷报告的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式与人工智能课程(part15)--
- 下一篇： 电脑机箱rgb啥意思