缺陷報告
一、項目測試的基本流程（步驟）：
1、熟悉需求。
2、編寫、閱讀《測試計划》
說明：編寫《測試計划》一般由測試組長或經理完成
測試人員要閱讀並且執行《測試計划》
3、設計測試（編寫《測試用例》）
4、執行測試（執行測試用例），並且要記錄執行結果
5、記錄缺陷結果（缺陷報告），跟蹤、管理缺陷
6、測試總結（總結報告）
二、缺陷報告
1、什么是缺陷報告
測試人員發現缺陷，通過缺陷報告記錄缺陷將缺陷報告提交給開發方，並跟蹤和管理缺陷。缺陷報告是測試人員和開發人員之間重要的溝通工具。
2、缺陷報告如何編寫
說明：在企業中為了提高缺陷的管理效率和質量通常會使用管理工具，例如：qc，禪道，bugzilla等，不同企業使用工具不同，缺陷管理可能會有差異，但是大同小異。
1）缺陷報告的主要組成：
（1）缺陷編號（defect id）
記錄發現缺陷的順序號，可以通過編號唯一標識每條缺陷。
缺陷的編號是以項目為單位進行的。
在測試管理中，缺陷編號通常是自動生成的。
（2）缺陷標題（summary）
簡明扼要的描述該缺陷。（概括）
（3）缺陷發現者（detected by）
就是發現缺陷的測試人員自己。
通常在測試管理工具中會默認當前系統的登錄用戶
（4）指派給誰（assigned to）
首先測試人員將缺陷報告指派給開發方的負責人（開發經理）
然后再由開發經理將缺陷報告指派給相應的開發人員負責解決缺陷。
（5）提交缺陷的日期（detected on date）
發現缺陷，確認之后，要及時的將缺陷提交給開發方。
在測試管理工具中通常會自動將系統時間默認填入該項。
（6）發現缺陷的功能模塊（subject）
方便開發經理確認該缺陷由哪個開發人員負責
可以協助開發人員定位缺陷
（7）缺陷所屬的版本（detected in release/version）
說明：這里所指的版本不僅是最終發布的版本，也包括在軟件開發過程中形成的臨時版本。
版本的制定不是由測試人員完成的。（通常公司里是產品部門完成）
回歸測試：在新版本中對上一個版本中測過的功能重新再測試一遍。
為什么要做回歸測試：
1）修改的缺陷有可能會對原有功能帶來新的問題
2）新增加的功能有可能會給原有功能帶來新的缺陷
在企業中，往往會使用自動化工具來完成回歸測試，提高測試效率。
（8）缺陷的狀態（status）
描述缺陷當前的情況。
缺陷的處理過程
步驟1：測試人員填寫缺陷報告，提交給開發經理，此時狀態為：new（新的缺陷）
步驟2：開發經理要驗證缺陷,
情況1：缺陷驗證通過，開發經理會激活缺陷，並將缺陷指派給相應的開發人員。此時狀態為：open（打開/激活的缺陷，被開發方承認的缺陷）
情況2：缺陷驗證沒有通過，開發方會拒絕該缺陷。此時缺陷狀態為：rejected（被拒絕的缺陷）
擴展：被拒絕后測試人員首先要確認是否是由於操作或配置錯誤造成的假缺陷，然后如果是由於對於需求理解不同造成的可以跟產品部門溝通確認，最后如果是開發方不能重現該缺陷，要盡量溝通、配合重現。
如果還不能確定再去跟測試部門領導溝通反饋問題。經過上述過程如果最終確認是假缺陷，那么由測試人員或組長關閉該假缺陷；如果最終確認是缺陷，那么誰拒絕的誰負責激活，繼續完成缺陷處理流程。
步驟3：開發人員負責解決指派給他的缺陷。解決后將缺陷狀態設置為：fixed（解決的缺陷，待返測的缺陷）
步驟4：測試人員返測解決的缺陷，
情況1：如果返測通過，測試人員將缺陷關閉。此時狀態為：closed（關閉的缺陷，可歸檔的缺陷）
情況2：如果返測沒有通過，測試人員要將缺陷重新激活，此時設置缺陷狀態為：reopen（重新激活的缺陷），開發人員繼續修改缺陷，修改后再次將缺陷狀態設置為：fixed，測試人員再次返測，直到缺陷解決被關閉為止。
問題：缺陷的處理流程
用狀態來表示
1、缺陷的基本處理過程
New-->open-->fixed-->closed
2、帶有返測失敗（1次）的缺陷處理過程
New-->open-->fixed-->reopen-->fixed-->closed
3、被拒絕的缺陷的處理過程
1)假缺陷
New-->rejected-->closed
2)是缺陷
New-->rejected-->open-->fixed-->closed
(9)缺陷的嚴重程度（severity）
指明缺陷有多糟糕或對程序的影響有多大
缺陷的嚴重級別的分級定義（以qc為例）：
Urgent：致命的缺陷，例如造成計算機死機，系統崩潰等
Very high：非常嚴重的缺陷
High：嚴重的缺陷
Medium：一般的（中等的）缺陷
Low：提示、建議類的缺陷（小問題）
發現問題：缺陷的嚴重級別的定義是籠統的，在實踐中容易造成沖突，所以企業針對每個嚴重級別制定了詳細的說明。工作中要注意參考。（不同公司或者不同項目使用的缺陷嚴重級別定義文檔都會不同）
（10）缺陷的優先級（priority）
希望或建議開發方在什么時候或什么版本解決該缺陷
優先級的級別定義：
Urgent：需要開發人員放下手頭的開發任務立即解決的缺陷（通常是不解決會影響整個開發和測試進度的）
Very high：在當前版本內解決
High：在下一個版本中解決（常用）
Medium：在軟件發布之前解決
Low：盡量在軟件發布之前解決（有可能在軟件發布時帶有沒有解決的bug）
說明：不同企業，不同項目組對於軟件優先級的定義會不同，工作中要注意參考。
關於缺陷的嚴重程度和優先級問題：
1）影響缺陷優先級定義的因素有哪些？
（1）缺陷的嚴重程度—一般越嚴重缺陷的優先級越高（有時也會有嚴重程度低而優先級高的情況）
（2）缺陷影響的范圍—影響范圍越大，優先級越高
（3）開發人員的開發壓力—開發壓力越小，解決缺陷的優先級越高
（4）解決缺陷的成本（時間）--成本越低，解決缺陷的優先級越高
2）缺陷的嚴重程度和優先級是嚴格的正比關系嗎？
不是嚴格的成正比關系，例如：界面的錯誤別字，嚴重程度低，但是優先級高
3）缺陷的嚴重程度和優先級確定之后可以修改嗎？
缺陷的嚴重程度確定好后一般不改
缺陷的優先級可以修改，而且常常是拖延處理（delay）
4）是否有未解決的缺陷在軟件發布版本中存在?
有可能會有發現的但沒有解決的缺陷在發布的軟件版本中存在。
這類缺陷需要開bug討論會，討論投入和風險，權衡利弊后，才能決定。
企業可以通過打補丁或者升級版本的方式在后續將此類缺陷解決。
(11)缺陷描述（description）
說明：將發現缺陷的過程、數據記錄下來，讓開發人員能夠再現該缺陷（就是讓開發人員能知道並再現這個缺陷）
擴展：在缺陷報告中要求附帶證跡（截圖、視頻）
|