---

影響Test Case ROI的另外一項重要因素，是軟體可測試性(Software Testability)

Ref:
http://en.wikipedia.org/wiki/Software_testability



在極端的狀況下，例如把所有邏輯都寫在main()裡面的程式，或是直接把所有邏輯
用像是這樣的if包起來的程式：

if ($_POST['Submit'] == true) {
    ....
} else {
    ....
}

然後裡面塞了三千多行程式，這將摧毀這個程式的單元測試的可測試性。

所以，通常會說「不，寫自動化單元測試程式碼很花時間。」
或是
「寫自動化單元測試程式碼很困難」當成理由的人，其主要的原因不是出在測試程式碼
，而是在被測程式上。



先看wiki上面有哪些評估可測試性的要素：


開發者沒有用較簡單的方式透過單元測試程式碼改變元件的狀態成預期的測試初始狀態，
，那撰寫單元測試程式碼就會是一種苦差事。

舉例來說，採用Domain物件/ORM，由於對資料庫的操作已經物件化，所以可以透過單元
測試程式碼直接產生物件送入邏輯元件處理，切除與資料庫的相依性。

另外，在GUI整合測試時，開發者如果能夠提供一些後門，或是一致性的ID，這也可以提
高可測試性。



開發者一樣可以透過開放取得內部數值的函數或屬性增加可觀察性。

3.isolateability：測試獨立性，這是為什麼要使用Unit Test Framework的原因之一，
因為可以透過Stub、Mock機制去取代原本待測元件與其他元件的相依性。但是只靠
Stub、Mock這種單元測試技術是不夠的，如果待測程式或元件本身與其他元件或類別
的耦合度太高而且沒有設計任何可以讓Stub、Mock插入的空間（比如透過建構式、
透過屬性，甚至透過IoC等等技巧），那測試也很難進行。

4.separation of concerns：SoC，簡單來說就是程式是不是經過正確封裝、模組化，
使其函數、類別各司其值，而不是塞成一大團，如同前文所述。透過重構流程可以
增加SoC，進而增加可測試性。



多寫註解、盡量減少多層迴圈等等各種開發規範這邊都派得上用場。

6.automatability：待測元件的可自動化程度。一般來說單元測試是針對程式碼測試，
所以這方面本來沒有什麼問題，可自動化程度主要對於整合測試有比較大的影響。

Script跟API的可自動化程度高於GUI的可自動化程度。不同的GUI可自動化程度也不同，
例如Ext的可自動化程度就低於傳統HTML 4.0。



採用雲端技術跟虛擬化可以快速建構測試平台，跨平台自動化測試就能降低異質性。

當然還有一些細微的部分，可以自己去發掘，但是以上我都舉了一些簡單的例子，
什麼會降低、什麼可以提高可測試性。

其中，以單元測試而言最重要的是測試獨立性，沒有測試獨立性的單元測試非常脆弱。
因為他很容易因為某個參與測試過程元件的錯誤導致一大票的單元測試一起錯。那這
根本失去的單元測試的意義，找不出真正錯誤的點。

然而，測試獨立性需要多加一些協助分離相依性的Code，對開發產品沒有直接幫助
，經常被開發者忽略。

而在整合測試層面，我認為最重要的是可觀察性以及元件的可控制性，因為整合測試
有可能非常複雜，而且整合測試常常會產生一些必須經過複雜評估的結果，過低的
可觀察性會使自動化測試失去效果，而過低的可控制性會使整合測試自動化非常難做
。

Test Driven Development 之前在幾篇文章討論過，但這一點卻被經常忽略。




另外一種高深的方法就是Design For Testability，但老實說，我不知道要怎麼做這種
東西，這只不過是維基上面寫的，TDD比較實在。

--
所有我的作品，請到.....
～四十八個德瑞克～http://blog.derekhsu.homeip.net
馬皇本紀：http://blog.derekhsu.homeip.net/2009/08/821
上官先生傳：http://blog.derekhsu.homeip.net/2009/08/825

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 175.181.113.203

--