軟件缺陷（bug）"，即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。一般來說，軟件缺陷的屬性包括缺陷標識、缺陷類型、缺陷嚴重程度、缺陷優先級、缺陷來源、缺陷原因等。
種類型：
（1）設計不合理;
（2）功能、特性沒有實現或部分實現;
（3）運行出錯，包括運行中斷、系統崩潰、界面混亂等;
（4）與需求不一致，在執行TestCase時則為實際結果和預期結果不一致;
（5）用戶不能接受的其他問題，如存取時間過長、界面不美觀;
（6）軟件實現了需求未提到的功能。
軟件缺陷有四種級別，分別為：致命的(Fatal)，嚴重的(Critical)，一般的(Major)，微小的(Minor)。
常用的軟件缺陷的優先級表示方法可分為：立即解決P1、高優先級P2、正常排隊P3、低優先級P4。立即解決是指缺陷導致系統幾乎不能使用或者測試不能繼續，需立即修復；高優先級是指缺陷嚴重影響測試，需要優先考慮；正常排隊是指缺陷需要正常排隊等待修復；而低優先級是指缺陷可以在開發人員有時間的時候再被糾正。
三種常用的技術工具供大家參考。
（1）20/80原則
80%的有效工作往往是在20%的時間內完成的，而20%的工作是在80%的時間內完成的：哪些軟件缺陷是最重要的，哪些軟件缺陷是最關鍵的。
（2）ABC法則
手邊的軟件缺陷並不一定就具有第一優先處理的重要性。只有正確的判斷，才可將測試活動效率增加數倍。
（3）四象限原則，把軟件缺陷進行分類
四個象限，然后只需記住四個字就行，那就是"輕重緩急"。"輕"，指的是相對重要但不緊急的軟件缺陷；"重"，是指最重要也是最緊急的軟件缺陷；"緩"，指的是不重要也不緊急的軟件缺陷；"急"，則是指不是最重要但卻最為緊急的軟件缺陷。理清這種關系之后，就算同時測試許多不同類型的軟件缺陷，也會很快清楚哪些軟件缺陷是必須馬上完成；
軟件缺陷的三種基本狀態：
（1）激活狀態(Active或Open)。
（2）已修正狀態(Fixed或Resolved)。
（3）關閉或非激活狀態(Close或Inactive)。
三、軟件缺陷分析產生原因及分類
軟件缺陷分析產生原因主要有三方面：技術問題，團隊合作，軟件本身。
從測試觀點我們將軟件缺陷分為五類，分別為：功能缺陷，系統缺陷，加工缺陷，數據缺陷，代碼缺陷。
四、軟件測試心理學問題
（1）程序測試的過程具有破壞性。
（2）程序員應避免測試自己的程序。
（3）程序設計組織不應測試自己的程序。
bug預防策略
發現bug，找出bug的根源，然后尋找一個方法來預防類似的bug在將來出現
1) Bug發現和初步分析
QC工程師的一個重要職責就是試圖發現bug的根本原因。QC小組在檢驗產品質量時，不應該將產品看作一個黑盒，而應該像開發人員那樣了解產品的內在，包括深入源代碼，理解產品的設計和實現。這些能力都是QC小組開始bug分析的基本要求。
(2) Bug修訂和進一步分析
一如既往，發現一個bug之后，開發人員應該負責處理它。但是，如果bug的發現過程包含了bug根本原因的初步分析，那么關於如何解決這個bug，開發人員可能擁有了更多的信息。雖然這不是QC工程師bug初步分析的目的，但是它可能為開發人員提供了更多的觀點。除了修正缺陷以及記錄實現的具體步驟，開發人員還應該對bug進行進一步的分析。這次分析應該着眼於導致bug產生的開發情景。
(3) bug預防分析
分析的最后一步就是尋找一個預防類似錯誤的方法。這一方法不僅涉及到開發、QC工程師，還涉及到不直接負責代碼編寫的資深開發人員。
這一階段的成果是一些有用的實踐經驗，開發人員可以通過這些實踐預防bug而不是修正bug。
Bug預防分析是整個bug分析過程的核心。這一階段總結出的實踐可以在更廣泛的范圍內預防潛在的缺陷。
類似bug產生的幾率卻非常高。所以，盡管這一類bug是隨機的，但仍然可以被預見並防止發生。
(4) 發布經驗
分析得出的實踐經驗應該被記錄並發布，這樣其他的開發人員就可以通過學習這些經驗避免類似的錯誤。一個發布經驗最好的辦法就是知識庫。
測試缺陷分析務實篇
陷泄露率，就是有多少本階段引入的缺陷沒有在本階段發現而是被泄露到后階段環節才被發現。其計算公式為：缺陷泄漏率=（下游發現的本階段的缺陷數/本階段注入的缺陷總數）*100%。顯然，它等於[1-缺陷移除率]。它反映的是本階段質量控制措施落實的成效。
下面是一個分析例子：
以找出我們產品/項目的高危模塊來。這些模塊導致了我們產品的主要缺陷。主要用到的分析手段是數據透視表和柏拉圖。讓我們看看下面的例子：
簡單的OA系統，它只有5個子系統。我們把這些子系統各有多少缺陷列出來，找到了改善質量的關鍵模塊是后台交易模塊。
這是一個較為復雜的MIS系統，有近20個功能塊。這個時候，可以利用柏拉圖識別出占80%問題的那少數模塊，針對其采取強於其它產品組成部分的質量控制措施。
需要指出的是：采用缺陷分布只是分析的第一步。它只不過提供了你分析影響產品質量的那些重點模塊，其信息不足以給出更深層次的原因。需要針對這些高危模塊進行進一步的分析，識別缺陷的產生根源。
下面是一個如何運用測試分布模型進行質量預測的例子：--需要開發和測試高度一致
如果需求階段發現了10個缺陷，就可以預計到設計階段我大概要清除70個缺陷，依次可以估計到后階段各個環節的缺陷數，作為我們該階段工作的交付准則。並且，可以預測到產品發布后的使用表現會出現大約2個故障泄露到用戶手中。
個項目的系統測試階段發現的故障為例進行過程有效性回溯分析：
導致在集成測試過程中未能充分發現這些缺陷的原因主要有：
1、測試環境不具備，導致部分測試項必須到系統測試階段才具備測試條件；
2、測試設計中某些測試項的缺失，需要加強測試設計的評審工作；
3、回歸測試過程中，開發部只是對測試故障進行驗證，而對bug fix波及的范圍缺乏分析和驗證；
對這些分析結論，我們就可以制定針對性的整改措施。如：
- 加強開發部的故障波及分析及波及分析驗證工作；
- 項目計划中加強對測試需求的關注，提前采購和協調必要的測試環境；
- 每次回歸對泄露的缺陷開發部都作相應的復盤，並根據復盤結果，完善單元測試和集成測試的測試設計；
- 利用缺陷分類來進行缺陷的根源分析
對於測試出來的BUG進行缺陷分類，按照BUG的類型分布，找出那些關鍵的缺陷類型，進一步分析其產生的根源，從而針對性的制定改進措施。
下面以一個項目的系統測試故障為例進行分析：
從系統測試故障來看，有較多故障是由接口原因造成的，細分有以下幾種原因：
1、跨項目間的接口，接口設計文檔的更改沒有建立互相通知的機制，導致接口問題到系統測試時候才暴露出來；
2、部門內部跨子系統的接口，由於本項目設計文檔按功能規划編寫的，而不是按照產品組件，一般由主要承接功能工作的組編寫該文檔，接口內容可能不為其他開發組理解並熟悉，導致因接口問題而出錯；
3、系統設計基線化后，更改系統接口，沒有走嚴格的變更流程，進行波及分析，導致該接口變更只在某個子系統中被修改，而使錯誤遺漏下來；
那么我們可以針對性的制定改進建議：
1、對接口文檔的評審一定要識別受影響的相關干系人，使他們了解並參與接口設計的把關；
2、對基線化的接口設計文檔的變更一定要提交變更單給ＣＣＢ決策，並做好充分的波及影響分析，以便同步修改所有關聯的下游代碼；
3、概要設計文檔按子系統規划，詳細設計文檔按模塊規划，通過相關組參加評審協調接口設計；
缺陷趨勢就是將每月新生成的缺陷數、每月被解決的缺陷數和每月遺留的缺陷數標成一個趨勢圖表。一般在項目的開始階段發現缺陷數曲線會呈上升趨勢，到項目中后期被修復缺陷數曲線會趨於上升；而發現缺陷數曲線應總體趨於下降；同時處於OPEN狀態的缺陷也應該總體呈下降趨勢，到項目最后，三條曲線都趨向於零。如：
項目經理會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目測試缺陷趨於零的時間。在一定的歷史經驗的基礎上分析使用這一圖表會得到很多有價值的信息，比如說，可分析開發和測試在人力資源的配比上是否恰當，可以分析出某個嚴重的缺陷所造成的項目質量的波動。對於異常的波動，如本來應該越測試越收斂的，卻到了某個點，發現的故障數反而呈上升趨勢，那么，這些點往往有一些特殊事件的發生。如：
- 在該時間段送測的回歸版本增加了新的功能，導致缺陷引入；
- 該回歸版本開發部沒有進行集成測試就直接送測？等等。
1、ODC缺陷分析：由IBM 的waston中心推出。Phontol.com將一個缺陷在生命周期的各環節的屬性組織起來，從單維度、多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用於評估測試活動、指導測試改進和整個研發流程的改進；同時根據各階段缺陷分布得到缺陷去除過程特征模型，用於對測試活動進行評估和預測。Phontol.com上面回答中涉及到的缺陷分布、缺陷趨勢等都屬於這個方法中的一個角度而已。
2、Gompertz分析：根據測試的累積投入時間和累積缺陷增長情況，擬合得到符合自己過程能力的缺陷增長Gompertz曲線，用來評估軟件測試的充分性、預測軟件極限缺陷數和退出測試所需時間、作為測試退出的判斷依據、指導測試計划和策略的調整；
3、Rayleigh分析：通過生命周期各階段缺陷發現情況得到缺陷Rayleigh曲線，用於評估軟件質量、預測軟件現場質量；
4、四象限分析：根據軟件內部各模塊、子系統、特性測試所累積時間和缺陷去除情況，和累積時間和缺陷去除情況的基線進行比較，得到各個模塊、子系統、特性測試分別所位於的區間，從而判斷哪些部分測試可以退出、哪些測試還需加強，用於指導測試計划和策略的調整；
5、根本原因分析：利用魚骨圖、柏拉圖等分析缺陷產生的根本原因，根據這些根本原因采取措施，改進開發和測試過程；
6、缺陷注入分析：對被測軟件注入一些缺陷，通過已有用例進行測試，根據這些刻意注入缺陷的發現情況，判斷測試的有效性、充分性，預測軟件殘留缺陷數。Phontol.com在06年軟件評測師考試中有一題就是考這個思路，參見這個帖子我的回復：
http://bbs.51testing.com/thread-114979-1-1.html
7、DRE/DRM分析：通過已有項目歷史數據，得到軟件生命周期各階段缺陷注入和排除的模型，用於設定各階段質量目標，評估測試活動。
至於缺陷預防，基本上是兩個方面：
1、測試活動盡量提前，通過及時消除開發前期階段引入的缺陷，防止這些缺陷遺留並放大到后續環節；
2、通過對已有缺陷進行分析（例如上面的ODC分析等），找出產生這些缺陷的技術上不足和流程上不足，通過對這些不足進行改進，防止類似缺陷再次發生。
作為一名測試人員，最大的成就就是像福爾摩斯一樣，利用超強的觀察力，嚴密的邏輯推理能力，迅速找出軟件的"罪犯"，將其繩之以法。可是在成為"福爾摩斯"之前，觀察力、邏輯推理能力，是需要不斷訓練的。這篇文章實際就是軟件測試的"犯罪心理學"(初級版)：利用軟件缺陷數據，對缺陷進行分類匯總，計算缺陷分析指標，進而發現軟件生命周期的各個階段的不足，制定相應改進方法，增強軟件過程人為活動的規范性，最終目標提升軟件交付質量，提升測試效率
一、缺陷管理庫
缺陷管理庫記錄了缺陷相關的資料，為缺陷分析提供了詳細的信息，而只有正確的信息，才能保障正確的分析結果。
1.1 缺陷定義
軟件缺陷是指在產品說明、設計、編碼階段中的任何不足。一般要求將需求評審、設計評審、代碼檢查、測試、項目組內部發現、用戶反饋等幾種手段發現的缺陷都統一記錄在缺陷跟蹤系統中，進行統一管理、統計。而目前很多項目缺陷跟蹤系統中往往只包含了測試階段的缺陷統計，在此基礎上的缺陷分析勢必存在局限性。
1.2 缺陷信息
為了便於缺陷定位、跟蹤和修改，需要收集盡量多的有效信息，比較常見的缺陷信息如下：
- 缺陷描述
- 被測產品信息：比如App名稱、版本號
- 測試環境：wifi、數據網絡、測試環境、生產環境
- 測試機型：機型、系統版本號
- 測試步驟
- 預期及實際結果
- 復現概率
- 測試輔助信息：截圖、視頻、日志
- 缺陷狀態
- 缺陷優先級：標識處理和修正軟件缺陷的先后順序指標
- 缺陷嚴重程度
- 缺陷發生的組件
- 缺陷創建時間
- 缺陷發現人
- 缺陷責任修改人
- 缺陷修復時間
- 缺陷產生原因
在提交缺陷時，需要遵循以下5個原則：
- 准確性：缺陷每個組成部分描述准確，不會產生誤解
- 完整性：復現該缺陷完整的步驟、截圖、日志
- 一致性：按照一致的格式書寫全部缺陷信息
- 簡潔性：只包含必不可少的信息，不包括任何多余的內容
- 清晰性：每個組成部分的描述清晰，易於理解
這一步其實可以理解成培養測試人員的觀察能力，信息收集能力。只有不斷觀察、收集正確信息，才可以為后續的偵查做好准備工作。
二、缺陷分析
缺陷分析是在形成缺陷管理庫的基礎上，對缺陷進行宏觀及微觀緯度的分析。通過缺陷分析，發現各種類型缺陷發生的概率，確定缺陷集中的區域，明確缺陷的發展趨勢，追蹤和分析缺陷產生的原因。在此分析基礎上，對軟件生命周期中各個角色、項目流程做改善和優化，提高軟件測試質量，提升測試效率。
缺陷分析僅僅是一種手段，而非最終目的。利用缺陷分析結論，反思和回溯缺陷產生的各個階段，思考如何避免類似問題，不再踩坑，在下次測試中得到提升，才是我們想要的結果。同樣的，缺陷分析的成果是一個持續改進優化閉環的過程，它是測試人員潛移默化中測試能力的提升，也是項目流程中各個角色共同保障產品質量意識的推動。例如缺陷分析發現很多需求缺陷是到測試階段才發現，那么就有必要加大需求評審力度；缺陷分析發現開發修復缺陷引入新缺陷比例很高，那么開發團隊在修復缺陷的時候要考慮到對周邊區域的影響，並且要通知相關區域的專家加強代碼審查。當然測試團隊也要盡可能多的在相關區域做一些回歸測試。大家可以結合自身項目來利用缺陷分析優化項目實踐。
三、宏觀缺陷分析技術
宏觀缺陷分析是指對缺陷信息進行分類和匯總，利用統計的方法計算分析相關指標，編寫缺陷分析報告的活動。宏觀缺陷分析的方法很多，這里主要關注缺陷發展趨勢分析、缺陷分布狀況分析、缺陷注入-發現分析。
3.1 缺陷發展趨勢分析
項目管理中一項非常重要但十分困難的工作就是平衡進度、質量和成本。測試人員可以提供缺陷提交、缺陷修復的趨勢圖表，幫助管理者從中發現一些簡單的缺陷發展趨勢（這種缺陷可以是本文論述的廣義缺陷發現手段確定的，也可以是單純的測試手段發現的），從而了解軟件質量趨勢。
這里給出一個常用的分析圖，x軸代表時間，y軸代表以下四種類型缺陷的數量：
- 發現數：累計的所有被發現bug的數量
- 關閉數：累計的所有被關閉bug的數量
- 日（期）發現數：當日（期）發現的缺陷數量
- 日（期）關閉數：當日（期）關閉的缺陷數量
圖1：缺陷分析發展趨勢圖
3.2 缺陷分布狀況分析
3.2.1 缺陷嚴重程度分布
缺陷嚴重程度度量有助於識別不同嚴重程度缺陷在所有缺陷中的比重，有助於開發測試人員資源的計划和分配。
這里給出一個常用的缺陷嚴重程度分析圖，x軸代表時間，y軸代表各嚴重級別的缺陷數量。
圖2：缺陷嚴重程度分布圖
通過缺陷嚴重程度圖表，分析各嚴重程度缺陷發現趨勢，判斷產品質量是否趨於穩定。如果高嚴重程度的缺陷大量增加通常意味着產品質量出現問題。
3.2.2 缺陷模塊分布
按照缺陷對應的產品組成部分來匯總缺陷數據，利用這樣的分布，可以找出我們產品高危模塊，針對高危模塊，調整測試策略。
3.2.3 ODC（正交缺陷分析）
正交缺陷分類法（Orthogonal Defect Classification，ODC）介紹了一種不同於大家常用的非常有效的軟件缺陷分類及分析方法，它定義了八個正交的缺陷屬性用於對缺陷的分類。所謂正交性是指缺陷屬性之間不存在關聯性，各自獨立，沒有重疊的冗余信息。
- 對於缺陷提交者，他需要給這個缺陷分配“活動（Activity）”、“觸發（Trigger）”、“影響（Impact）”這三個屬性。
- Activity：項目生命周期的一個階段，該缺陷發生在該階段，例如需求、設計、代碼階段，即缺陷發現階段
- Trigger：可以理解成測試的手段
- Impact：對用戶的影響，例如安全性、易用性
- 當一個開發人員關閉一個缺陷時，他可以分配“階段（Age）”、“來源（Source）”、“限定符（Qualifier）”、“類型（Type）”以及“目標（Target）”這五個屬性。
- Age：描述缺陷對應的代碼屬於新代碼，舊代碼，還是修復bug引入
- Source：定義缺陷來源，是自身代碼問題，還是第三方代碼導致
- Qualifier：指明了所進行的修復應歸於缺失，錯誤或者還是外來的代碼或者信息
- Type：缺陷真正的原因，例如初始化、算法等
- Target：描述缺陷是由於設計還是編碼引入，即缺陷注入階段
關於ODC分析方法，需要結合實際項目，對不同屬性進行篩選，優化不同屬性對應的值。
軟件缺陷分析方法：ODC 這篇文章中詳細解釋了ODC各屬性及對應的值。
3.3 缺陷注入-發現矩陣
利用缺陷的兩個重要屬性：缺陷發現階段、缺陷注入階段，分析缺陷數據，繪制出"缺陷注入-發現矩陣"，從中分析項目生命周期各個環節的質量，優化相關流程。
- 缺陷移除率：（本階段發現的缺陷數/本階段注入的缺陷數)*100%，它反映的是該活動階段的缺陷清除能力
- 缺陷泄漏率：（下游發現的本階段的缺陷數/本階段注入的缺陷總數）*100%，它反映的是本階段質量控制措施落實的成效
圖3：缺陷注入-發現矩陣
如上圖例子，需求階段一共注入了34個缺陷，需求評審時只發現了4個，設計過程中發現了15個，編碼和單元測試階段發現了12個，系統測試階段發現3個。這樣，需求階段的缺陷移除率 4/34*100%=11.76%。這個結果說明，我們需要重新審視需求評審，加大需求評審力度。另外，編碼階段的缺陷大部分依賴於系統測試發現，很顯然，項目開發過程中的單元測試和集成測試活動開展不夠深入。我們可以進一步分析這些系統測試出來的測試缺陷，是不是可以被更前端的評審/測試/設計討論活動所替代。
四、微觀缺陷分析技術
微觀缺陷分析是指從單個有價值的缺陷入手，追蹤和分析缺陷產生的本質原因。
並不是所有的缺陷都有必要去做微觀缺陷分析，因此首先需要挑選"合適的缺陷"。這里給出幾點建議
- 選擇典型有代表性的：同類型的一系列問題
- 選擇有發現難度：積累缺陷庫，對測試用例做補充
- 選擇有推廣意義的：該缺陷很普遍，可以推廣到其他業務線
- 再挑選合適的缺陷后，我們緊接着需要收集該缺陷相關的有效信息進行下一步缺陷原因分析。這些缺陷信息包括提交缺陷時信息，同時也包括和開發討論獲取的信息。
接着就是追蹤缺陷產生的真正原因。網絡上有很多總結的分析方法，有"望、聞、問、切"診斷法，有"5W"法，還有"探案分析法"。其實個人覺得在這一步驟中，更多需要積累經驗，善於追根究底，多問為什么，多理解產品實現邏輯，產品設計思路，有了這些基礎之后，合理的推理分析即可。
下面這兩篇文章是非常好的結合實踐總結的微觀缺陷分析，大家可以通過他們的分析積累經驗。
如何做好軟件缺陷管理的分析和復現
一、軟件缺陷報告包含的內容
1、報告編號：為了方便對缺陷進行管理，每個缺陷必須賦予一個唯一的編號，規則根據需要和需求進行制定；
2、標題：標題用簡單的方式可以傳達缺陷的基本信息，標題應該簡短並盡量做到唯一，因為這個缺陷可能在以前的版本修改過；
3、報告人：缺陷報告的原始創造人，有時也應該包含報告的修訂者；
4、報告的日期：首次報告的日期。讓開發人員知道創建缺陷報告的日期是很重要的，因為這個缺陷有可能在以前的版本有改過；
5、程序或組件的民稱：可分辨測試對象；
6、版本號：測試可能跨越多個版本的軟件，提供版本信息可以方便對缺陷進行管理；
7、配置：發現缺陷的軟件和硬件配置。如操做系統類型、是否用游覽器、處理器的類型和速度；
8、缺陷的類型：如代碼錯誤、設計你問題和文檔不匹配；
9、嚴重性：描述報告的嚴重性；
10、優先級：由開發人員或管理人員確定；
11、關鍵詞：使用關鍵詞以便分類查找缺陷報告；
12、缺陷描述：對發現的問題進行詳細描述
13、重現步驟：這些步驟必須是有限的，並且描述的信息足夠讀者知道正確的執行就可以重現報告的缺陷；
14、結果對比：在執行了重現步驟后，將期望結果與實際結果進行對比
下面是一個軟件缺陷模板
二、缺陷的嚴重性和優先等級
1、缺陷的嚴重性
0級（致命）：最嚴重等級，缺陷導致系統任何一個主要功能完全喪失、用戶數據受到破壞、系統崩潰、懸掛、死機等；
1級（嚴重）：系統的主要功能部分喪失、數據不能完全保存，系統的次要功能完全喪失，系統所提供的功能或服務收到明顯影響；
2級（一般）：系統的次要功能沒有完全實現，但不影響用戶的正常使用。例如，提示信息不太准確；或用戶界面差、操做時間稍長等問題；
3級（微小）：操作者不方便或遇到麻煩，但不影響功能的操做和執行，如字體不美觀、按鈕大小不很合適、字體排列不對齊等一些小問題。
2、缺陷的優先級
立即解決（p1級）：缺陷導致系統幾乎不能完全運行、使用，或嚴重妨礙測試的執行，需立即修正、盡快修正；
高優先級（p2級）：缺陷嚴重，影響測試，需要優先考慮修正，如不超過24小時修正；
正常排隊（p3級）：缺陷需要修正，但可以正常排隊等待修正；
低優先級（p4級）：缺陷可以在開發人員有時間的時候被修正，如果沒時間可以不修正。
三、軟件缺陷的生命周期
缺陷的生命周期可以簡單地表現為：打開（open）—修正(fixed或solved)—關閉（close）
軟件缺陷狀態的描述：
打開/激活：缺陷的起始狀態，或重新打開的狀態。問題存在或依舊沒有解決，等待修正，如新報告的缺陷、補充完整信息后在打開；
已修正：已經被開發人員檢查、修復過的缺陷，通過單元測試，認為及解決但還待測試人員驗證；
關閉/非激活：測試人員驗證后，確認缺陷不存在的狀態；
無法解決：由於技術原因或者第三方軟件的缺陷，開發人員目前不能解決的缺陷；
延遲：這個缺陷不嚴重，被推遲修正，可以在下一個版本解決；
功能增強：該問題符合 當前的設計規格說明書，但有一個待改進問題；
不是缺陷：開發人員認為不是問題，十年測試人員的誤報缺陷；
不能再現：開發人員不能復現這個軟件缺陷，需要測試人員檢查缺陷復現步驟；
需要更多信息：開發不能復現這個軟件缺陷，但開發人員需要一些信息，例如：缺陷的日志文件、圖片等。