軟件測試之缺陷管理

一、軟件缺陷的基本概念

1、軟件缺陷的基本概念主要分為：缺陷、故障、失效這三種。

（1）缺陷（defect）：存在于軟件之中的偏差，可被激活，以靜態的形式存在于軟件內部，相當于bug;

（2）故障（Fault）：軟件運行中出現的狀態，可引起意外情況，若不加處理，可產生失效，是一個動態行為；

（3）失效（Failure）：軟件運行時產生的外部異常行為結果，表現與用戶需求不一致，功能能力終止，用戶無法完成所需要的應用。

二、軟件缺陷的三個基本概念的相互關系

1、bug一定會被激活嗎？激活后一定表現為故障嗎？

答案是不一定，任何一個軟件即便測試的非常嚴格，在發布后也會存在遺漏的bug，但是這些bug在用戶使用的時候不一定會被激活，因為有些bug隱藏的比較深，用戶在使用的過程中不可能觸發這些bug，所以這些bug一直隱藏在軟件內部，沒有被激活，也就是說即使軟件內部有bug，軟件也可以正常運行，但也有可能，在某些情況下，這些bug會被激活，表現為故障*。

2、故障一定會導致失效嗎？

答案也是不一定，開發人員在做設計的時候，更多的考慮了在軟件使用期間可能出現的故障，然后針對這些故障采取的一些預防的措施，比如：數據庫會出現的數據丟失的問題，為了避免這種失效的出現，產品開發人員在做設計的時候，也許會采取數據庫時時備份的方式，也就是在本地有一個數據庫，在異地也有一個數據庫，這個地方的數據庫會實現時時的備份，當其中一個數據庫出現了異常，那另外一個數據庫還可以啟動工作，所以說，缺陷不一定會導致故障，故障不一定會導致失效。

三、軟件缺陷報告單

缺陷報告單是任何缺陷修改的一個起始，也就是我們測試人員在進行測試執行的時候，發現了一個缺陷，發現缺陷后，我們不要口頭和開發人員交流，因為口頭的交流不僅沒有任何的約束力，而且有可能表達不清楚，所以我們要把缺陷落實在紙面上，也就是要測試人員填寫缺陷報告單。

缺陷報告單的作用：
?
1、測試執行過程中，發現缺陷失效后（不一定是失效，也許是故障，一般來說這個缺陷在測試階段被發現往往表現為產品失效），提出書面的報告，提供給開發人員作為定位缺陷的依據，也作為日后缺陷度量的數據依據，開發人員接到缺陷報告單后，他會根據缺陷報告單上描述的缺陷外在表現來重現這個問題，然后找出這個問題，也就是缺陷產生的根源。
?
2、缺陷報告還可以作為我們日后缺陷度量的數據依據，度量是對整個產品進行考核，比如說，我們的軟件在什么時候可以發布，什么時候可以交付給客戶等等問題，這個時候我們往往從缺陷度量的數據來看，比如我們子啊最后一輪進行測試的過程中，每千行代碼只有0.1個缺陷，說明我們產品的質量已經非常高了，而且遺留的缺陷也就非常少了，這個時候就可以發布產品了，所以這個缺陷的統計數據時非常重要的，它可以作為缺陷度量的依據。

四、軟件缺陷管理的目的

缺陷管理的目的是：對各個階段測試發現的缺陷進行跟蹤管理，以保證各級缺陷的修復率達到標準，主要實現以下目標：

（1）保證信息的一致性；

（2）保證缺陷得到有效的跟蹤，縮短溝通時間，解決問題更高效；

（3）收集缺陷數據并進行數據分析，作為缺陷度量的依據。

五、軟件缺陷管理工具

軟件缺陷管理的流程一定要有相關的軟件進行支撐，否則軟件缺陷管理的流程是無法正常運行的，就類似于我們在做開發的過程中，開發JAVA相關的程序我們就需要JBOSS這樣的工具，，如果我們開發C++就需要Visual C++工具，在軟件缺陷跟蹤中我們也需要一些工具，比如商用工具Mercury Quality Center是目前非常強大的軟件測試管理工具，它的功能包括業務管理、測試用例的管理、缺陷的分析及測試腳本的管理，所有缺陷僅僅是其一個點；Rational ClearQuest它主要用于變更控制和缺陷管理這一塊，此外還有Bugzilla,Mantis,Jira三個開源工具。

使用商用的軟件缺陷管理工具或軟件測試工具，好處是由商家提供一系列支持、工具的相關制定以及后期的升級服務，所以商用軟件缺陷管理工具從整體的易用性和可用性來看，要比開源工具好得多，開源工具最大的好處就是便宜，不用去花錢購買，但是易用性和可用性相對來說就弱一些。

六、軟件缺陷管理的相關角色

軟件開發和軟件測試的任何一個流程，都應該有流程的入口，流程的出口，還有流程的具體過程以及參與到這些過程中的相關角色。

在軟件跟蹤的流程當中，有以下幾類角色：

（1）軟件開發人員；

（2）軟件測試人員；

（3）軟件測試項目經理；

（4）軟件開發項目經理；

（5）CCB（Change Control Board）：變更控制委員會。所謂的變更控制委員會，他是在開發人員和測試人員對缺陷出現爭議的時候，做出最后的裁判；

（6）配置管理員：就是測試人員提交BUG，開發人員修改，修改完check in ，那么在check in這個過程中需要配置管理員參與進來，只有經過配置管理員授權，開發人員才有資格把代碼從本地Check in到服務器中去，所以配置管理員在軟件缺陷管理中也很重要。

軟件缺陷報告的內容以及缺陷的相關屬性

一、軟件缺陷報告的內容

1、Bug Title/Summary：缺陷標題/簡單描述

對測試執行過程中實際出現的問題的描述，盡量要簡單概要。

2、Repro Step：重現步驟

（1）描述問題的基本環境，包括操作系統、硬件環境、網絡環境、被測試軟件的運行環境；

（2）簡單概括的描述清楚軟件出現異常時，測試人員的操作步驟和使用數據；

（3）缺陷原因的分析；比如說：因為不支持字符集，而導致的亂碼...等等。

（4）要寫清楚，重復操作了多少次，這個bug依然出現。（不能操作一次就提交bug,因為有可能是自己操作失誤。）

（5）相關附件：為了讓開發人員更好的了解Bug。（如果從GUI界面上可以反映出軟件的異常，可以截取界面，粘貼在問題單上或者日志、數據包）；

（6）屬性（在下面詳細說明）：缺陷報告中除了對缺陷的基本描述外，我們還要對其屬性進行說明。

二、軟件缺陷的相關屬性

測試人員在提交缺陷的時候，需要把缺陷，發現缺陷的過程以及缺陷的一些表現都要描述出來，除此之外這些缺陷還有一定的相關屬性，也要填寫出來。

下面我們列舉六個比較重要的缺陷屬性。

屬性1、缺陷發現人

在提交缺陷的時候測試人員一般是缺陷的發現人，這個字段也很重要，比如到QC里面統計一下本季度哪一個測試人員發現的BUG比較多。

屬性2、缺陷發現時間

缺陷發現時間也是一個統計的計數點，或者數據點，缺陷趨勢圖就是按照時間軸來排列的，如果缺少了缺陷發現時間，這個圖是做不出來的，沒有缺陷趨勢圖，我們就不能進行產品的度量，就不知道產品在什么時候發布是比較合適的。

屬性3、缺陷狀態

軟件缺陷狀態這個屬性是非常重要的，在任何的軟件報告中，這一個屬性是一定要有的。
下面我們主要列出了在QC中常用的幾種狀態：

New:缺陷的初始狀態；Open：開發人員開始修改缺陷；Fixed：開發人員修改缺陷完畢；Closed：回歸測試通過；Reopen：回歸測試失敗；Postpone：推遲修改；Rejected：開發人員認為不是程序問題，不用修改；Duplicate：與已提交的Defect重復；Abandon：被Reject和Duplicate的Defect，測試人員確認后的確不是問題，將Defect置為此狀態。

New是缺陷的初始狀態，所謂初始狀態就是發現問題，發現問題，提交問題后，這個缺陷就處于New狀態；

提交給開發人員后，開發人員接受這個問題，那么就把這個缺陷的狀態就更改為Open；

開發人員修改缺陷之后，就會把這個缺陷的狀態改為Fixed；

然后提交給測試人員，測試人員進行回歸測試，回歸測試通過，就把狀態改為Closed；

我們可以看到New--Open--fixed--closed這個狀態是一個比較理想的缺陷流程，也就是測試人員提交問題，開發人員接受并修改問題，然后測試人員進行回歸測試通過。

但是我們一般在缺陷跟蹤流程當中也會遇到一些問題：

1、比如說回歸測試失敗，這個狀態就是Reopen，也就是說測試人員在進行回歸測試的時候失敗了，就要把這個缺陷的狀態改為Reopen，然后再提交給開發人員進行修改，開發人員修改完之后，把這個缺陷的狀態改為Fixed，然后又提交給測試人員，測試人員再一次進行回歸測試，直到回歸測試成功，把這個缺陷的狀態改為Closed。

2、Postpone：推遲修改，比如當我們把問題提交給開發人員的時候，開發人員覺得也接受這個問題，但是暫時無法修改，那就可以把這個問題置為推遲狀態，此時這個缺陷的狀態就是Postpone。

3、當我們提交的Defect與別熱提交的相同時，缺陷就被置為Duplicate狀態。

4、比如說開發人員覺得測試人員提交的不是問題，不用修改，可以將這個BUG置為Reject狀態。

5、被Reject和Duplicate的Defect，我們最終要把它置為Abandon狀態。

屬性4、缺陷嚴重程度（Severity）

缺陷的嚴重程度就是：站在用戶的交付，bug出現之后對軟件質量的破壞程度，也就是說這個軟件缺陷的存在將對這個軟件的功能和性能產生怎么樣的影響。

一般來說，軟件的嚴重程度分為五個等級：

第一個等級：致命的軟件缺陷(Fatal)

造成系統或應用程序崩潰、死機、系統掛起，或造成數據丟失，主要功能完全喪失，導致本模塊以及相關模塊異常等問題。如代碼錯誤，死循環，數據庫發生死鎖、與數據庫連接錯誤或數據通訊錯誤，未考慮異常操作，功能錯誤等。
第二個等級：嚴重錯誤的軟件缺陷（critical）

嚴重錯誤的軟件缺陷（critical）：系統的主要功能部分喪失、數據不能保存，系統的次要功能完全喪失。問題局限在本模塊，導致模塊功能失效或異常退出。如致命的錯誤聲明，程序接口錯誤，數據庫的表、業務規則、缺省值未加完整性等約束條件。
第三個等級：一般錯誤的軟件缺陷（major）

一般錯誤的軟件缺陷（major）：次要功能沒有完全實現但不影響使用。如：提示信息不太準確，或用戶界面差，操作時間長，模塊功能部分失效等，打印內容、格式錯誤，刪除操作未給出提示，數據庫表中有過多的空字段等。
第四個等級：較小錯誤的軟件缺陷（Minor）

較小錯誤的軟件缺陷（Minor），使操作者不方便或遇到麻煩，但它不影響功能性的操作和執行，如錯別字、界面不規范（字體大小不統一，文字排列不整齊，可輸入區域和只讀區域沒有明顯的區分標志），輔助說明描述不清楚。
第五個等級：建議問題的軟件缺陷（Enhancemental）

建議問題的軟件缺陷（Enhancemental）：由問題提出人對測試對象的改進意見或測試人員提出的建議、質疑。

屬性5、缺陷的優先級（Priority）

站在開發/項目的角度，綜合權衡修改bug的時間、成本、技術和風險，決定bug修改的先后順序。

優先級每個公司都有自己的標準，例如某公司的標準為：
?
P0：必須當天修改，8小時內修改；（優先級最高的）
?
P1：1~2內修改；
?
P2：2~4天內；
?
P3：一周內；
?
P4：發布周期內或者不修改。

屬性6、缺陷的類型

1、質量特性的角度

（1）功能；（2）性能；（3）安全性；（4）易用性；（5）可靠性。

2、功能性角度

（1）錯誤（Error）；（2）遺漏（Missing）；（3）多余的（Extra）；（4）可優化（Improvement /Enhancement /suggestion）

3、缺陷產生的原因：

（1）需求不清晰，導致設計目標偏離客戶端需求，從而引起功能或產品特征上的缺陷；

（2）對程序邏輯路徑或數據范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤；

（3）新技術的應用，可能涉及技術或系統兼容的問題，事先沒有考慮到；

（4）可能由于不支持字符集，而導致的亂碼。

等等的一些原因。

屬性7、缺陷所屬版本

在軟件開發測試的過程中，版本的管理是非常重要的，也就屬于配置管理的范疇，測試人員開始測試的時候肯定從配置庫里面提取最新的版本；

比如說1.0版本，那么測試完成之后，把問題提交給開發人員，開發人員對1.0版本的源代碼進行修改，那么這個修改完之后的版本肯定是1.0的下一個版本，也就是1.1版本，修改完之后測試人員要進行回歸測試，這個時候測試人員進行回歸測試的版本一定是最新版本，即1.1版本。
細分的話，缺陷所屬版本還應該有三個屬性：（1）發現缺陷的版本；（2）修改bug的版本；（3）回歸測試的版本。

所以說，只有缺陷所屬版本在開發過程中規定明確落實下來，我們的產品質量才能有保證，不會造成開發和測試的混亂。

屬性8、缺陷修改日期

最后一個缺陷的屬性是缺陷修改日期，是主要對開發人員進行考核的參數，比如測試人員在3月份提交了一個測試報告單，開發人員在12月份才修改這個問題，由此可見，開發人員修改這個問題的響應時間太長。所以缺陷修改日期往往可以作為績效考核或者其他的一些數據統計的基礎。