[軟件測試][軟件缺陷][四][學習筆記]

1.缺陷的基本概念

1.1.缺陷的定義

軟件未實現(xiàn)產(chǎn)品說明書要求的功能

軟件出現(xiàn)了產(chǎn)品說明書指明不應該出現(xiàn)的功能

軟件實現(xiàn)了產(chǎn)品說明書未提到的功能

軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應該實現(xiàn)的目標

軟件難以理解、不易使用、運行緩慢或者（從測試的角度看）最終用戶會認為不好

1.2.缺陷的屬性

1.3.缺陷的類型

缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類

需求分析、設計階段，文檔類型缺陷多

集成測試階段，一般接口類型缺陷多

系統(tǒng)測試階段，功能、界面類型缺陷多

驗收測試階段，更多關注性能缺陷

實施過程，遇到一些軟件包的缺陷

1.4.缺陷的嚴重程度

缺陷嚴重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度

1.5.缺陷修復優(yōu)先級

缺陷的優(yōu)先級指缺陷必須被修復的緊急程度

優(yōu)先級衡量小技巧：一般可以根據(jù)測試的軟件系統(tǒng)的全業(yè)務流程劃分，軟件的基本功能的缺陷，優(yōu)先級高，甚至需要立即解決，軟件的備選項，基本功能測試中的反向測試功能，優(yōu)先級較低，甚至有些可改可不改

問題：缺陷的嚴重程度和缺陷修復優(yōu)先級有什么關系？

二者沒有任何關系 不要認為嚴重的缺陷，修復優(yōu)先級就高 如果碰到，優(yōu)先級和嚴重程度都高的缺陷，一般較少遇見。比如，QQ的幫助按鈕，會經(jīng)常閃退，嚴重程度很高，但優(yōu)先級低；企業(yè)logo錯誤，不影響任何功能，但必須優(yōu)先修復

問題：提交缺陷時能不能夸大或降低缺陷的嚴重程度或者優(yōu)先級

不能，也不能因為私人關系減少錯誤報告

1.6.缺陷的狀態(tài)

缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況

1.7.缺陷起源

缺陷起源指缺陷引起的故障或事件第一個被檢測到的階段

1.8.缺陷來源

缺陷來源指缺陷的起因

1.9.缺陷根源

起源、來源、根源，一般關注較多的是缺陷的來源（直接原因），在測試總結的時候，關注缺陷的根源。

缺陷根源指發(fā)生錯誤的根本因素

2.缺陷的生命周期

發(fā)現(xiàn)缺陷

測試人員進行，開發(fā)也可能知道自己哪里寫錯了

提交缺陷

測試人員進行，開發(fā)也會提交bug

確認缺陷

一般由測試主管、或者質量保證（QA），由產(chǎn)品經(jīng)理進行確認

分配缺陷

經(jīng)確認后，有效的缺陷會指派給相關人員進行處理，一般由誰確認的缺陷，就由誰分配，分配的對象可能是開發(fā)，也可能是UI，可能是產(chǎn)品經(jīng)理

修復缺陷

主要由開發(fā)修復，也有可能是產(chǎn)品經(jīng)理修復問題，也可能是UI修復問題

驗證缺陷

測試去驗證缺陷有沒有修復成功，如果不成功，回到步驟2進行提交

關閉缺陷

只能是測試人員進行

問題：針對工作中發(fā)現(xiàn)的一個bug，說說這個bug的處理過程（缺陷的生命周期中每個環(huán)節(jié)由誰做什么）

3.缺陷的識別

通過測試用例中的預期結果進行識別

通過需求規(guī)格說明書進行識別

通過用戶手冊及其他文檔進行識別

通過同行業(yè)相類似成熟的商業(yè)軟件來識別

通過和開發(fā)人員的溝通進行識別

通過和有經(jīng)驗的測試人員溝通進行識別

參考同行業(yè)隱式需求進行識別

4.缺陷報告

4.1.編寫目的和預期讀者

缺陷報告編寫目的

易于搜索軟件測試報告的缺陷

報告的軟件缺陷進行了必要的隔離，報告的缺陷信息更具體、準確

軟件開發(fā)人員希望獲得缺陷的本質特征和復現(xiàn)步驟

市場和技術支持等部門希望獲得缺陷類型分布以及對市場和用戶的影響程度

預期讀者

開發(fā)人員、質量管理人員、市場人員、運維人員等等

由于缺陷報告的讀者很多，所以缺陷報告要寫的很直白，清晰明了

4.2.報告編寫準則

Correct（準確）：每個組成部分的描述準確，不會引起誤解

Clear（清晰）：每個組成部分的描述清晰，易于理解

Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內容

Complete（完整）：包含復現(xiàn)該缺陷的完整步驟和其他本質信息

Consistent（一致）：按照一致的格式書寫全部缺陷報告

缺陷編號，Bug_項目名稱_模塊名稱_功能名稱_0001 所屬模塊，一級模塊/二級模塊/三級模塊 優(yōu)先級，缺陷的修復緊急程度，P1>P2>P3>P4（缺陷優(yōu)先級） 嚴重程度，S1>S2>S3>S4 缺陷概述，用一句話去描述缺陷的基本情況 缺陷描述，將缺陷的復現(xiàn)步驟，預期結果和實際結果列出來 提交人，寫上提交人的名字 備注，一般寫產(chǎn)生該缺陷的特殊情況，將bug截圖作為備注信息

4.3.缺陷描述準則

單一準則

可以再現(xiàn)

完整統(tǒng)一

短小簡練

特定條件

補充完善

不做評價

缺陷跟蹤系統(tǒng)

Bugzilla，英文，安裝比較繁瑣

Bugfree，中文，安裝簡單，用例缺陷的跟蹤，功能單一

禪道，中文，國產(chǎn)，項目，產(chǎn)品，測試，功能齊全，開源免費

QC（ALM），英文，功能齊全

JIRA，Java環(huán)境，主流（商業(yè)）

企業(yè)自己開發(fā)

問題

測試需求和測試用例，缺陷報告的關系？ 測試的基本流程：獲取測試需求->編寫測試計劃->指定測試方案->設計和開發(fā)測試用例->執(zhí)行測試->提交缺陷->測試分析和評審->測試總結->準備下一版本測試。 獲取測試需求是測試工作的重點，也是第一步，通過需求的分析，了解和掌握測試的方向和內容。例如：分析出系統(tǒng)的模塊和組織結構；分析出軟件的基本功能和運行流程，（業(yè)務分析）包括可能會有哪些人或者哪些角色要用；識別出軟件的重要功能和次要功能。 獲取測試需求的過程中，測試人員就要有相應的分析成果，一般用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í)行失敗的測試用例總量，F(xiàn)C （6）提交的缺陷的總量，BC 以上數(shù)據(jù)，要符合以下的數(shù)量關系：TC>=EC，TC=EC+WC，EC=SC+FC，BC>=FC（提交bug數(shù)量多于執(zhí)行未通過的用例數(shù)，一條測試用例的預期結果數(shù)量固定甚至唯一，說明了，測試過程中發(fā)現(xiàn)的缺陷，除一部分是用例執(zhí)行失敗帶來的，還有一部分應該是測試人員自身的經(jīng)驗和直覺帶來的）。 通過SC/EC可以表現(xiàn)出系統(tǒng)的質量是否合格。 通過EC/TC可以表現(xiàn)出整個系統(tǒng)的需求是否得到滿足。

自動化測試

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。