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