如何提升軟體的可測試性（二）

Apr. 01 16:00~17:09

 

第一集談到提升軟體可測性的SOCK model，接下來的幾集要再回頭從《Software Architecture in Practice》這本書的角度來探討提升軟體可測性的方法。

首先看一下這本書第二版中提到的提升可測試性的方法：

本照片採用Old HTC One X（簡稱「舊一」）拍攝…

第二版書中提到提升可測試性的方法看起來比較簡單，畢竟第二版是2003年出版的，離現在已經有整整10年的光陰。至於內容就不多加說明，請直接看第三版中提升可測試性的方法：

策略一樣還是分成兩大類，只不過從原本的Manage Input/Output與Internal Monitoring改成Control and Observer System State與Limit Complexity。耶，這些策略怎麼跟SOCK很像啊：

• Control and Observer System State：SOCK中的Observer與Control。
• Limit Complexity：SOCK中的Simple。

只差了Knowledge這個項目沒列被列入。總之，英雄所見略同，大體而言要提升可測試性就是要具備SOCK就對了。但是《Software Architecture in Practice》書中針對Control and Observer System State與Limit Complexity有再進一步的切割幾項不同的方法，接下來分幾次分別介紹這些方法。

***

Specialized Interfaces

透過一個特製的介面來幫助測試程式讀取或設定待測程式的狀態，例如從最簡單的getter與setter、特殊的report函數傳回物件的所有狀態、reset函數重設物件的狀態、或是透過設定讓物件可以輸出詳細的debug訊息或是調整不同的log訊息層級。

透過專門的介面來達到測試的目的在硬體界是非常普遍的一種方法，例如有些硬體特別留了RS232、USB或是LED介面讓工程師可以用來顯示系統狀態與錯誤訊息。但是有些人認為在軟體元件或類別當中，專門設計一些針對測試而存在的介面或方法（method）是一種不好的作法。

作者在書中也提到，這些針對測試而存在的介面，要能夠與正常的介面清楚的區分開來，以便萬一有需要的時候可以從系統中移除。例如，鄉民們可以在建構系統中區分debug與release這兩種不同的建構目標，在debug版本中可包含這接為了測試而存在的介面，若有需要可在release版本中將其移除。

***

Record/Playback

「錄製/播放」是一種很常見的測試方法，經常使用在UI測試。但這邊所提到的record/playback倒不是在談UI測試，而是因為有些錯誤或是bug很難被重複產生，因此就算是工程師想要去解這些bug，也無從解起。好吧，萬一工程師靠著第六感宣稱把bug給解了，測試人員也無從檢驗起。

如果鄉民們的系統允許測試人員可以透過某個介面來紀錄系統的狀態，而最後又可以透過這個介面把紀錄好的狀態餵給它，然後重新執行一次系統，則便可提升系統的可測試性。從這個定義來看，如果鄉民們的系統可以提供一個介面，使得傳統採用capture/replay的UI測試工具可以很方便的透過錄製與播放方式來產生與執行測試案例，那麼鄉民們的系統便具備某種程度的可測試性。

***

內容有點多，讓Teddy喝口水，休息一下，下集待續。

***

友藏內心獨白：怎麼搞得好像吳樂天講古一樣。