軟體測試基礎（五）

軟體測試基礎（五）

一、軟體質量

軟體質量 包括兩個相關但截然不同的概念——功能性質量（Functional Quality）和結構性質量（Structural Quality）。功能性質量反映的是軟體是否按照設計實現並滿足相應功能性需求（Functional Requirements）；結構性質量反映的是軟體是否滿足相關的非功能性

需求（Non-Functional Requirements，NFR）。

要評價軟體的功能性質量和結構性質量，有一系列衡量指標。有了衡量指標以後，另

一個重要的問題就是如何獲得這些指標的量化數值。軟體測試是驗證這些指標的有效方

法。通過測試可以在一定程度上模擬真實的使用場景，並得到質量指標的具體水平。如果

測試發現某些指標無法達到要求，則需要對系統進行改進，以求通過測試。測試的通過指

標是根據質量的需求來定義的，系統通過了測試，可以從量化的角度說明它符合需求。

正確性（Correctness）反映了實現的功能達到設計規範並滿足用戶需求的程度。這是功能性質量的基本指標。正確性可以通過功能測試來驗證。

可靠性（Reliability）衡量在規定的時間和條件下，系統維持其性能水準的程度。這是結構性需求的重要指標。對於企業級的應用系統，對可靠性通常都有很高的要求。可靠性指標可以通功系統可靠性測試獲取。

易用性（Usability）反映用戶掌握軟體操作及理解軟體事務所需付出的時間及努力程度。具體的指標諸如界面是否友好，是否有在線幫助，是否提供容易理解的異常信息等。易用性指標通常由功能測試獲得。

可移植性（Portability）衡量系統從一個平台轉移到另一個平台的容易程度，包括把程序從一種軟/硬體環境轉移到另一種軟/硬體環境的容易程度等。大型軟體的安裝和部署可能也是一個複雜的過程，高可移植性的系統應該是容易安裝和更新的。此外，企業級系統對多國語言的支持程度也是可移植性的一個衡量指標。可移植性在多平台的功能、系統測試、安裝測試、多國語言測試中得到驗證。

可遷移性（Migratability）衡量系統版本升級的容易程度。大型系統的遷移通常是一件非常複雜的事情，可遷移性需要通過遷移測試來驗證。

效率（Efficiency）衡量系統執行某功能所需的計算機資源和時間有效程度，包括功能和性能是否經過優化，是否檢驗內存泄漏或溢出問題等。效率是系統測試的一個重要檢測點。

可維護性、可擴展性（Maintainability、Scalability）反映當環境改變或出現錯誤時，執行修改或修復的難易程度。系統的設計是否很好地考慮日後擴展的需求，架構是否靈活等因素決定可維護性和可擴展性。系統測試可以獲得系統的可擴展性指標。

健壯性（Robustness）衡量系統在接受異常或錯誤輸入後能否返回正確的提示信息且不影響正確運作的指標。詳細的功能測試是檢驗健壯性的主要方法。

安全性（Security）衡量系統對攻擊性或不當的訪問的抵禦能力，檢測的方向包括在受到沒有授權的訪問時系統對自身及數據的保護程度，系統的安全機制是否正確地實現，系統在受到攻擊時是否能保持正常的業務運作等。系統測試有專門的測試涵蓋安全性的審核。

有了諸多衡量質量的指標，軟體的好壞就可以量化了，可見有效的測試是軟體質量的重要保證。測試除了提供量化指標以外，還可以作為動力來驅動開發的進度，這就是極限編程倡導的測試驅動開發（Test-Driven Development，TDD）。

測試驅動開發的要點是先寫測試程序，然後再編碼實現使其通過測試。測試可以有效推動需求的實現，但是測試場景的覆蓋度不足以涵蓋所有的分支，因此，開發前的完整設計及第一輪開發過後的詳細功能測試能夠避免測試場景的覆蓋問題。這樣，測試場景相當於提供給開發人員的指導性主線，加快主要功能點的開發速度。

測試驅動開發的方法為開發提供一種新的方式，測試處於主導的位置。但測試的更重要作用還是在於提供衡量軟體質量的量化指標。因此，我們認為，軟體的好壞是由測試決定的。

二、缺陷（Bug）

典型的缺陷生命周期流程圖

缺陷（Bug），一般是指系統存在的問題或者需要加強的細節。從廣義的角度而言，系統中任何需要修改或強化的任務都可以歸類為缺陷。發現缺陷的人員在系統中創建一個新的缺陷，對於這個缺陷而言，創建的人是缺陷的創始人（Originator）。創始人會明確說明缺陷的內容，包括測試的時間、環境、測步和問題的描述、建議等。缺陷創建後，它處於開啟（Open）狀態，在任何時候它都會有一個直接的負責人（Owner），負責人是必須對缺陷採取行動的那個人。負責人的義務是推動缺陷的解決。初始化的時候，系統會根據一定的規則指定缺陷的負責人，創始人或者被指定的負責人可以重新指定（Assign）更適合解決該缺陷的人員為新的負責人。

針對一個開啟狀態的缺陷，首要的任務是驗證其有效性，因為在不少情況下，缺陷對應的問題是由於不符合規定的操作導致的。遇到這種缺陷時，負責人僅需要把缺陷退回（Return）給創始人。如果缺陷被返回，創始人可以再次確認缺陷是否合法，假如缺陷確實合法，則可以重新開啟（Reopen）缺陷，使缺陷回到開啟狀態；如果證實缺陷僅是不符合規定的操作引起的問題，則可以把它取消（Cancel）。取消狀態是缺陷生命周期的其中一種終結狀態。如果負責人經過驗證後證實了缺陷的有效性，那麼下一步的工作就是謀求解決方法。開始考慮解決方案前，需要接受（Accept）這個缺陷，使缺陷的狀態從開啟轉成工作中（Working）。

在工作中狀態下，缺陷的負責人可以與測試人員（缺陷創始人）及相關人員一同討論問題的原因和解決辦法，並根據方案對文檔或系統進行修改。修改完成以後，負責人需要把缺陷的狀態改為驗證（Verify）狀態，並創建一個驗證記錄（VerificationRecord）供缺陷創始人驗證。這時缺陷的創始人同時也是負責人。如果驗證通過，問題已經解決，則缺陷創始人可以認可（Accept）這個解決方案，這時缺陷的狀態會變成認可（Accept）。系統可以關閉（Close）處於認可狀態的缺陷。

從開啟到關閉狀態的流程，是缺陷生命周期的主要流程。在任何時候，基於新線索的發現，缺陷創始人都可以取消缺陷。有一些問題可能在不同的測試用例中以不同的方式暴露出來，或者分別被不同的測試人員發現，這種問題所被報出的缺陷最終都會被歸結為同一個缺陷。缺陷負責人僅需要跟蹤第一個被創建的缺陷（主缺陷），而其他缺陷會被標上重複（Duplicate）的記號。然後，驗證缺陷的步驟無論是對主缺陷還是重複缺陷的創建人都是必需的。

這種基於狀態的缺陷生命周期管理模型有利於跟蹤缺陷的狀況並推動缺陷的及早解決。缺陷的屬性中會包括重要性、嚴重性、發現時間等信息，根據這些信息，項目組可以把更多資源分配給更重要的、嚴重的和緊急的缺陷。

三、缺陷管理

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

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

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

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

相關術語：

（1）Bug：電腦系統或者程序中存在的任何一種破壞正常運轉能力的問題或者缺陷，都可以稱之為「Bug」；有時也泛指因軟體產品內部引起的軟體產品最終運行時和預期結果的偏離。

（2）缺陷報告單：指測試執行過程中，發現缺陷失效後，提出書面的報告，提供給開發人員作為定位缺陷的依據

2、軟體測試錯誤嚴重程度：

（1）Critical：不能執行正常工作功能或重要功能。或者危及人身安全。

（2）Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬於更正辦法）

（3）Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬於更正辦法）

（4）Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。

（5）Other：其它錯誤

同行評審錯誤嚴重程度：

（1）Major：主要的，較大的缺陷

（2）Minor：次要的，小的缺陷

3、缺陷優先順序（Priority）：

（1）Resolve Immediately：缺陷必須被立即解決。

（2）Normal Queue：缺陷需要正常排隊等待修復或列入軟體發布清單。

（3）Not Urgent：缺陷可以在方便時被糾正。

4、缺陷管理的基本流程

（1）首先項目創建並初始化；

（2）測試人員發現錯誤，提交錯誤報告，此時缺陷狀態為New；

（3）項目經理收到測試人員提交的錯誤報告，對其進行確認，並分配給開發人員，此時缺陷狀態為Open；

（4）開發人員收到分配的錯誤，對其進行修正，並將缺陷狀態改為Fixed，再次將缺陷發送給測試人員進行確認；

（5）測試人員對修復的錯誤進行驗證，錯誤消除，缺陷狀態改為Closed，否則錯誤狀態將重啟；

（6）如果錯誤暫時無法修改或者開發員認為無必要修改，錯誤將提交給評審委員會進行檢查是否有必要對其進行修改，如果沒有必要進行修改，則關閉項目缺陷；

（7）如果有必要進行修改則返回（4）；

5、缺陷報告

（1）缺陷報告是描述軟體缺陷現象和重現步驟地集合。

（2）軟體缺陷報告Software Bug Report （SBR）或軟體問題報告Software Problem Report （SPR）

6、缺陷報告的作用

（1）缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值

（2）缺陷報告可以把軟體存在的缺陷準確的描述出來，便於開發人員修正

（3）缺陷報告可以反映項目/產品當前的質量狀態，便於項目整體進度和質量控制

（4）軟體測試缺陷報告是軟體測試的輸出成果之一，可以衡量測試人員的工作能力

7、「5C」原則

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

（2）步驟簡潔(Concise)：只包含必不可少的信息，不包括任何多餘的內容

（3）內容清晰(Clear) ：每個組成部分的描述清晰，易於理解

（4）結構完整(Complete) ：包含重現該缺陷的完整步驟和其他本質信息

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

8、缺陷報告的內容

（1）缺陷的標題；

（2）缺陷的基本信息；

• 測試的軟體和硬體環境；
• 測試的軟體版本；
• 缺陷的類型；
• 缺陷的嚴重程度；
• 缺陷的處理優先順序。

（3）復現缺陷的操作步驟；

（4）缺陷的實際結果描述；

（5）期望的正確結果描述；

（6）注釋文字和截取的缺陷圖像

推薦閱讀：