1 概述

隨著軟件行業的迅猛發展，軟件測試也逐漸受到越來越多的軟件公司所重視，然而開發出來的軟件直接就可以拿出來做測試嗎？根據近幾年來的實踐證明，在設計軟件時事先沒有對軟件的可測試性進行周密設計和部署的軟件在測試時總是很難于進行，直到測試無法進行下去為止。被測軟件在編碼時需要考慮給測試和后期的產品維護提供必要的手段和接口支持，即要求軟件具有可測試性?；诳蓽y試性的目標考慮，良好的架構設計，完備的接口，使得軟件測試更加高效和可行，同時產品維護也更加便利。

本文描述的范圍：可測試性定義、可測試性特征、可測試性設計。

讀者對象：系統分析和設計人員、開發人員、測試人員。

參考文獻：

1.《軟件可測試性需求設計》 Vince

2.《高質量C++/C編程指南》 林銳

3.《軟件工程思想》 林銳

2 軟件可測試性定義

2.1 可測試性定義

軟件的可測試性是指在一定的時間和成本前提下，進行測試設計、測試執行以此來發現軟件的問題，以及發現故障并隔離、定位其故障的能力特性。簡單的說，軟件的可測試性就是一個計算機程序能夠被測試的容易程度。

一般來說可測試性很好的軟件必然是一個強內聚、弱耦合、接口明確、意圖明晰的軟件，而不具可測試性的軟件往往具有過強的耦合和混亂的邏輯。

2.2 可測試性特征

1.可操作性：“運行得越好，被測試的效率越高。”

1)系統的錯誤很少；

2)沒有阻礙測試執行的錯誤；

3)產品在功能階段的演化(允許同時的開發和測試)。

2.可觀察性：“你所看見的就是你所測試的。”

1)每個輸入有唯一的輸出；

2)系統狀態和變量可見，或在運行中可查詢；

3)過去的系統狀態和變量可見，或在運行中可查詢(例如：事務日志)；

4)所有影響輸出的因素都可見；

5)容易識別錯誤輸出；

6)通過自測機制自動偵測內部錯誤；

7)自動報告內部錯誤；

8)可獲取源代碼。

3.可控制性：“對軟件的控制越好，測試越能夠被自動執行與優化。”

1)所有可能的輸出都產生于某種輸入組合；

2)通過某種輸入組合，所有的代碼都可能被執行；

3)測試工程師可直接控制軟件和硬件的狀態及變量；

4)輸入和輸出格式保持一致且有結構；

5)能夠便利地對測試進行說明、自動化和再生；

6)接口和模塊易控制；

7)業務流程和場景易控制。

4.可分解性：“通過控制測試范圍，能夠更快地分解問題，執行更靈巧的再測試。”

1)軟件系統由獨立模塊構成；

2)能夠獨立測試各軟件模塊；

3)業務流程和場景易分解。

5.簡單性：“需要測試的內容越少，測試的速度越快。”

1)功能簡單性(例如：特性集是滿足需求所需的最小集合)；

2)結構簡單性(例如：將體系結構模塊化以限制錯誤的繁殖)；

3)代碼簡單性(例如：采用代碼標準為檢查和維護提供方便)。

6.穩定性：“改變越少，對測試的破壞越小。”

1)軟件的變化是不經常的；

2)軟件的變化是可控制的；

3)軟件的變化不影響已有的測試；

4)軟件失效后能得到良好恢復和隔離。

7.易理解性：“得到的信息越多，進行的測試越靈巧。”

1)設計能夠被很好地理解并遵循行業規范；

2)內部、外部和共享構件之間的依賴性能夠被很好地理解；

3)設計的改變被通知；

4)可隨時獲取技術文檔；

5)技術文檔組織合理；

6)技術文檔明確詳細；

7)技術文檔精確性穩定；

8)相關環境配置說明與操作指導。

3軟件可測試性設計

3.1可測試性設計

軟件的可測試性特征主要表現是設立觀察點、控制點、觀察裝置、驅動裝置、隔離裝置。需要注意的是可測試性設計時必須要保證不能對軟件系統的任何功能有影響，不能產生附加的活動或者附加的測試，采取合適的設計模式對軟件進行設計。

1.堅持測試驅動設計（測試先行）的方法。

優先編寫測試代碼，這是標準的XP方法。不是說應該一次性編寫全部測試代碼后，再一次性全部實現。先寫驗收測試，再寫單元測試，編寫一些測試代碼，實現它們，再編寫一些測試代碼，再實現它們等等是個更好的辦法。設計以這種方式得以進展；在實現階段捕捉錯誤并在下一組測試中改正它，以這種方式編寫測試也更少會使人畏縮。

2.盡量做到每個操作對應一個函數，使函數小型化。

使用小型函數說明和重載帶缺省參數的函數將使在測試中調用這些函數變的愉快的多。否則，在測試這些函數時將不得不構造額外參數，如果參數很大，那么將很快導致代碼膨脹。更糟的是，它會誘使你編寫比在其它情況下更少的測試。

3. 數據的顯示與控制分離

把代碼移到 GUI 視圖的外面。然后各種 GUI 動作就能成了模型上的簡單方法調用。這樣，對GUI測試者來說，通過方法調用測試功能比間接地測試功能容易的多。另一個好處是它使修改程序功能而不影響視圖變的更容易。

4.可控制性設計

1)全局變量的可控制性設計

I.在外界使用適當的手段能夠直接或間接控制該變量,包括獲取、修改變量值等；

II. 可以將全局類型的變量進行分類并封裝到一個個接口中操作。

2)接口的可控制性設計

各接口在外界使用適當的手段能夠直接調用對該接口進行操作,這里所謂的適當的手段主要包括使用測試工具和增加額外代碼. 對于向外提供的接口的接洽處能夠人為的對接，比如構造測試環境模擬接口對接，這里所指的開放接口主要是指相對于整個被測系統，即為被測系統以外提供的接口。接口接洽處人為對接時各接口所要求的條件和所需的參數人為的能夠輕易達到和提供。

3)模塊的可控制性設計

對于每個相對獨立的模塊設計好所需要的驅動和樁都能單獨設計用例進行測試對應的功能，在測試運行期間模塊異常時能夠將其隔離而不影響測試。

4)業務流程的可控制性設計

在測試環境滿足的情況下能夠控制任一單獨業務流程，各業務流程具有流通性。

5)場景的可測試性設計

將一場景所涉及到的業務和接口整合到一個統一的接口使其能夠單獨操作該場景。

5.可分解性設計

1)業務流程的可分解性設計

對于復雜的業務流程需合理設定分解點，在測試時能夠對其進行分解。

2)場景的可分解性設計

對于復雜的場景需合理設定分解點，在測試時能夠對其進行分解。

6.穩定性設計

測試模塊發布合理，不能在后期追加的模塊為前期所測模塊引入新的不必要的測試活動。

7.易理解性設計

1)設計文檔的易理解性

I.設計參考標準

II.內容描述主次要分清

III.依賴關系描述明確

2)接口的易理解性

I.接口功能明確

II.參數有意義

3)業務的易理解性

4)場景的易理解性

8.可觀察性設計

1)業務執行狀態和過程可觀察性設計

2)異常情況可觀察性設計

9.測試驅動和樁的設置

為單個測試接口、測試業務、測試場景預留測試驅動和樁的接入點。

10.適合增量式開發的可測試性設計

在增量式開發過程中必須優先考慮測試樁和測試驅動實現的難易程度和真實性。

11.可查詢設計

1)對系統級別的全局變量或者狀態設置查詢接口；

2)某一業務或場景調用接口設置接口路徑查詢

12.自愈合功能

在某一場景中的局部出現故障時設置多路選擇或者其他干涉進行跳轉執行氣候的具有正常邏輯的功能。

13. 輸出結果

對于任何一項操作都要能產生預期的輸出,不管是正確的還是錯誤的甚至是異常的.測試結果的表現形式可以是數據、現象等，不管是以什么方式表現，都要有依可尋，在設計文檔中要有說明。對于測試結果易于判斷,具有可分析性、可獲得性.在設置的各個控制點或觀察點的結果易于查詢、修改等。

14.提供統一的操作執行面板

操作面板元素主要由輸入和輸出元素組成，如所執行的操作和對應的輸出，但可能被測系統是一個比較復雜的系統，由多個可以獨立的模塊組成，涉及到的操作和輸出比較多，各操作之間的關聯也比較復雜。在設計時統一的做一個操作面板，該操作面板成為一個可以操作整個被測系統的獨立模塊，一種是以命令的形式執行操作，直接以printf語句的形式輸出查看，另一種是以GUI的形式，輸入（執行的操作）輸出均在界面上執行和體現，這樣比較直觀。如下圖所示：

特別對于執行某一場景時要跟蹤該場景的關鍵過程和執行后的輸出參數，給出一系列可以分析的數據，該場景可以以執行過程分階段監控，將監控范圍內的數據輸出以供測試人員分析。

3.2 可測試性編碼

1.注釋需要詳盡。特別對于接口，要描述清楚功能、實現及參數；

2.使用模塊化方法，編碼低耦合、高內聚；

3.為集成測試與系統聯調準備調測開關及相應打印函數，并且要有詳細的說明；

4.為單元測試選擇恰當的測試點，并仔細構造測試代碼、測試用例，同時給出明確的注釋說明。測試代碼部分應作為（模塊中的）一個子模塊，以方便測試代碼在模塊中的安裝與拆卸（通過調測開關）；

5.使用斷言來發現軟件問題，提高代碼可測試性；

6.用斷言來檢查程序正常運行時不應發生但在調測時有可能發生的非法情況；

7.為測試自動化工具提供所需要的特定“鉤子（hook）”；

8.對于每個功能，提供訪問、修改“狀態”變量的接口，包括提供查詢、修改上層軟件、軟硬件接口、底層硬件狀態的接口及打??；

9.提供查詢系統狀態的接口。比如內存使用、程序使用進程數等；

10.對于測試因為環境等因素而可能無法測試的功能，提供接口模擬軟件實現該功能的過程；

11.對于修改功能，提供修改功能參數單位的接口，以便于進行如軟件性能等的測試；

12.出錯及異常處理保存記錄，記錄具有詳細的屬性，并且格式統一、意義明確；

13.在程序異常時，除了保留日志，還需要提供觀察、恢復的外部方法；

14.對全局變量、特殊結構，提供查詢的方法。

3.3 可測試性調試與定位

1.對于程序中所涉及到的變量盡可能的在調試過程中可以查詢及修改；

2.在整個軟件系統執行過程中為每個關鍵業務或相對獨立的業務設定一個調試點，便于系統集成和問題范圍的定位；

3.在設定好的調試點處對處理的業務輸出數據和全局數據進行可視化輸出，便于測試結果的分析。

3.4 測試所需文檔

1.需求規格說明書

2.概要設計說明書

3.詳細設計說明書

4.系統功能清單

5.系統運行環境搭建指導書

6.系統操作指導書