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

Apr. 02 22:22~23:29

 

越複雜的軟體越難理解，當然也就很難測試。一般測試可簡單分為四個步驟：

1. 準備測試環境。
2. 執行測試。
3. 比對測試結果（actual result是否等於expected result）。
4. 分析測試報告。

如果待測程式很複雜，則上述四個步驟也會變得很複雜，有時候光是準備測試環境就夠累人了，更不用說還要執行測試並且比對結果。萬一測試失敗，對於一個複雜的待測程式而言，測試者要花更多的時間來分析失敗的原因。

Limit Complexity可以提升可測試性，這一系列的最後一篇介紹這個分類底下的兩種提升可測試性方法。

Limit Structural Complexity

有幾種方法可以用來限制軟體結構的複雜度，包含：

• 避免軟體元件形成循環參考。循環參考不但會導致軟體不易測試，也會讓建構變得比較麻煩。
• 將元件內部結構與外部隔離，可套用Facade pattern或物件導向設計的封裝技巧。
• 減少元件之間不必要的相依性，物件導向設計原則有一條叫做Don't Talk To Strangers就是提醒設計物件的時候只和必要的「熟人」打交道，以免增加物件之間不必要的相依性。
• 在物件導向語言中，減少繼承的階層。
• 遵守high cohesion、low coupling、separation of concerns等通用的軟體設計原則。
• 透過軟體架構來管理結構，例如layered架構與plug-in架構。
  

Limit Nondeterminism

「不確定性」是很多人的敵人，也是測試的敵人。系統行為的不確定性越低，可測試性當然也就越高（越容易測試）。相對於前一項「限制結構的複雜度」，「limit nondeterminism」談的是限制行為的複雜度。軟體系統有哪些是屬於不確定性的行為？最簡單也很常見的就是multithreaded系統，這種系統的行為很難預測，也非常難以測試。

限制不確定性並不是說有什麼辦法可以全部排除系統中所有的不確定性，因為實務上可能無法做到（我就是需要一個多執行緒或是事件驅動的系統啊）。這個作法是要提醒鄉民們要留意系統的那些部分具備不確定性的行為，如果可能的話盡量想辦法排除。

怎麼排除？以下是幾個具體的例子，請參考Teddy之前寫過的這幾篇《對付時好時壞的測試案例(1)：還沒痊癒，就先隔離》、《對付時好時壞的測試案例(2)：Lack of Isolation》、《對付時好時壞的測試案例(3)：Asynchronous Behavior》、《對付時好時壞的測試案例(4)：Remote Services》、《對付時好時壞的測試案例(5)：Time》、《對付時好時壞的測試案例(6)：Resource Leaks》。

***

友藏內心獨白：好像有一點點快要串起來的感覺。