軟體可測試性設計

軟體可測試性設計
作者：張元禮

http://blog.csdn.net/vincetest

1  概述
    隨著軟體行業的迅猛發展，軟體測試也逐漸受到越來越多的軟體公司所重視，然而開發出來的軟體直接就可以拿出來做測試嗎？根據近幾年來的實踐證明，在設計軟體時事先沒有對軟體的可測試性進行周密設計和部署的軟體在測試時總是很難於進行，直到測試無法進行下去為止。被測軟體在編碼時需要考慮給測試和後期的產品維護提供必要的手段和介面支援，即要求軟體具有可測試性。基於可測試性的目標考慮，良好的架構設計，完備的介面，使得軟體測試更加高效和可行，同時產品維護也更加便利。 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

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

    讀者對象：系統分析和設計人員、開發人員、測試人員。
 
    參考文獻：
    1.《軟體可測試性需求設計》               Vince
    2.《高品質C++/C編程指南》              林銳
    3.《軟體工程思想》                          林銳

  【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

2  軟體可測試性定義
2.1  可測試性定義
    軟體的可測試性是指在一定的時間和成本前提下，進行測試設計、測試執行以此來發現軟體的問題，以及發現故障並隔離、定位其故障的能力特性。簡單的說，軟體的可測試性就是一個電腦程式能夠被測試的容易程度。
    一般來說可測試性很好的軟體必然是一個強內聚、弱耦合、介面明確、意圖明晰的軟體，而不具可測試性的軟體往往具有過強的耦合和混亂的邏輯。

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

 

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)相關環境配置說明與操作指導。

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

3軟體可測試性設計
3.1可測試性設計
    軟體的可測試性特徵主要表現是設立觀察點、控制點、觀察裝置、驅動裝置、隔離裝置。需要注意的是可測試性設計時必須要保證不能對軟體系統的任何功能有影響，不能產生附加的活動或者附加的測試，採取合適的設計模式對軟體進行設計。
  1.堅持測試驅動設計（測試先行）的方法。
    優先編寫測試代碼，這是標準的XP方法。不是說應該一次性編寫全部測試代碼後，再一次性全部實現。先寫驗收測試，再寫單元測試，編寫一些測試代碼，實現它們，再編寫一些測試代碼，再實現它們等等是個更好的辦法。設計以這種方式得以進展；在實現階段捕捉錯誤並在下一組測試中改正它，以這種方式編寫測試也更少會使人畏縮。【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

  2.盡量做到每個操作對應一個函數，使函數小型化。
    使用小型函數說明和重載帶預設參數的函數將使在測試中調用這些函數變的愉快的多。否則，在測試這些函數時將不得不構造額外參數，如果參數很大，那麼將很快導致代碼膨脹。更糟的是，它會誘使你編寫比在其它情況下更少的測試。

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

  4.可控制性設計【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】
   1)全域變數的可控制性設計
     I.在外界使用適當的手段能夠直接或間接控制該變數,包括擷取、修改變數值等；
     II. 可以將全域類型的變數進行分類並封裝到一個個介面中操作。
   2)介面的可控制性設計
     各介面在外界使用適當的手段能夠直接調用對該介面進行操作,這裡所謂的適當的手段主要包括使用測試載入器和增加額外代碼. 對於向外提供的介面的接洽處能夠人為的對接，比如構造測試環境類比介面對接，這裡所指的開放介面主要是指相對於整個被測系統，即為被測系統以外提供的介面。介面接洽處人為對接時各介面所要求的條件和所需的參數人為的能夠輕易達到和提供。
   3)模組的可控制性設計
     對於每個相對獨立的模組設計好所需要的驅動和樁都能單獨設計用例進行測試對應的功能，在測試回合期間模組異常時能夠將其隔離而不影響測試。
   4)商務程序的可控制性設計
     在測試環境滿足的情況下能夠控制任一單獨商務程序，各商務程序具有流通性。
   5)情境的可測試性設計
     將一情境所涉及到的業務和介面整合到一個統一的介面使其能夠單獨操作該情境。

  5.可分解性設計
    1)商務程序的可分解性設計
      對於複雜的商務程序需合理設定分解點，在測試時能夠對其進行分解。
    2)情境的可分解性設計
      對於複雜的情境需合理設定分解點，在測試時能夠對其進行分解。

  6.穩定性設計
    測試模組發布合理，不能在後期追加的模組為前期所測模組引入新的不必要的測試活動。【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

  7.易理解性設計
    1)設計文檔的易理解性
      I.設計參考標準
      II.內容描述主次要分清
      III.依賴關係描述明確
    2)介面的易理解性
      I.介面功能明確
      II.參數有意義
    3)業務的易理解性
    4)情境的易理解性

  8.可觀察性設計
    1)業務執行狀態和過程可觀察性設計
    2)異常情況可觀察性設計

  9.測試驅動和樁的設定
    為單個測試介面、測試業務、測試情境預留測試驅動和樁的存取點。

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

  11.可查詢設計【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】
    1)對系統層級的全域變數或者狀態設定查詢介面；
    2)某一業務或情境調用介面設定介面路徑查詢

  12.自癒合功能
     在某一情境中的局部出現故障時設定多路選擇或者其他幹涉進行跳轉執行氣候的具有正常邏輯的功能。

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

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

    特別對於執行某一情境時要跟蹤該情境的關鍵過程和執行後的輸出參數，給出一系列可以分析的資料，該情境可以以執行過程分階段監控，將監控範圍內的資料輸出以供測試人員分析。

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

3.2  可測試性編碼
  1.注釋需要詳盡。特別對於介面，要描述清楚功能、實現及參數；
  2.使用模組化方法，編碼低耦合、高內聚；
  3.為整合測試與系統聯調準備調測開關及相應列印函數，並且要有詳細的說明；
  4.為單元測試選擇恰當的測試點，並仔細構造測試代碼、測試案例，同時給出明確的注釋說明。測試代碼部分應作為（模組中的）一個子模組，以方便測試代碼在模組中的安裝與拆卸（通過調測開關）；
  5.使用斷言來發現軟體問題，提高代碼可測試性；
  6.用斷言來檢查程式正常運行時不應發生但在調測時有可能發生的非法情況；
  7.為測試自動化工具提供所需要的特定“鉤子（hook）”；
  8.對於每個功能，提供訪問、修改“狀態”變數的介面，包括提供查詢、修改上層軟體、軟硬體介面、底層硬體狀態的介面及列印；
  9.提供查詢系統狀態的介面。比如記憶體使用量、程式使用進程數等；
  10.對於測試因為環境等因素而可能無法測試的功能，提供介面類比軟體實現該功能的過程；
  11.對於修改功能，提供修改功能參數單位的介面，以便於進行如軟體效能等的測試；
  12.出錯及異常處理儲存記錄，記錄具有詳細的屬性，並且格式統一、意義明確；
  13.在程式異常時，除了保留日誌，還需要提供觀察、恢複的外部方法；
  14.對全域變數、特殊結構，提供查詢的方法。

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

3.3  可測試性調試與定位
  1.對於程式中所涉及到的變數儘可能的在調試過程中可以查詢及修改；
  2.在整個軟體系統執行過程中為每個關鍵業務或相對獨立的業務設定一個調試驗，便於系統整合和問題範圍的定位；
  3.在設定好的調試驗處對處理的業務輸出資料和全域資料進行可視化輸出，便於測試結果的分析。

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

3.4  測試所需文檔
  1.需求規格說明書
  2.概要設計說明書
  3.詳細設計說明書
  4.系統功能清單
  5.系統運行環境搭建指導書
  6.系統操作指導書

 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

歡迎轉載此文，轉載時請註明文章來源：張元禮的部落格http://blog.csdn.net/vincetest