軟件測試框架的底線

　　最近半年一直在應各業務團隊的需求優化自動化測試框架，簡化case的編寫和維護。隨著用戶對測試框架的使用不斷深入，對測試框架提的需求也越來越有挑戰性，也越來越“變態”。所以，也一直在思考，這些需求哪些是可以接受的?哪些可以變通接受?哪些應該直接拒絕呢?這就涉及測試框架的底線的問題。

　　我一直認為自動化測試中還是應該以人為主，工具和框架為輔，所以這里指的測試框架指的是輔助case編寫的框架，類似JUnit之類(不過主要用于功能測試中)，并不包括一些錄制回放工具。

　　我們都知道，自動化測試的成本很大一部分都在維護成本上(倒覺得編寫的成本是次要的)。一個case一旦寫成，我們當然期望它一次又一次的運行，并且隨著系統的演化而不斷演化。要讓case可以演化，就必須讓后來人能夠理解，能夠看懂case。而要讓case很好懂就必須很容易看出case的上下文環境。這就像我們理解一段話，如果單獨從一篇文章中摘抄一段話讓我們理解，我們可以覺得很費解，或者理解偏差，這就需要這段話所在的上下文來幫助我們理解。 case也是一樣，一個case不管是測試一個接口，還是測試一個業務流程(完整的或片段)，都應該能展現出case的全貌，能夠清楚明白的傾訴它所在的上下文：這個業務場景分成幾個大的步驟、在執行之前初始化了哪些數據等等。當然，這并不是說一個case要事無巨細，表達出所有細節。相反，應該在不影響理解的基礎上，盡量隱藏一些細節。

　　打開一個case，要讓閱讀的人能感覺這個case在講述一個完整的“故事”，更不應該產生case的運行與case的表現形式之間的gap。比如，這個case實際會運行三大步，但是因為測試框架提供某種magic tool，讓我們在case里只能看到一步。這樣雖然看起來case是簡單了，但是卻增加了理解的復雜性。就比如很多人寫單元測試時會將一些初始化的公共工作提取到 Before里，這樣表面上看起來每個case都變得更簡單了，但是每個case卻丟失了它一部分上下文，如果這個上下文對理解case非常重要的話就更不可取了。這個時候我們應該采取另一種重構手段：把本來應該放到Before里的公共部分抽取到一個公共方法中(并且給該方法起一個很好的名字)，然后在每個case之前插入該方法。這樣麻煩是麻煩了點，但是上下文立馬就傾訴出來了。

　　所以，我一直堅守的一個原則是測試框架應該盡可能為用戶提供抽象組合的可能性，只要用戶能夠想出的抽象，框架都應該能很好的支持，但要明確的是這些抽象都是用戶構思出的。測試框架不能越雷池半步，不能自作主張的提供某種magic tool將某些細節隱藏于無形。比如測試框架可以提供關鍵字支持，將一些細粒度的操作抽象為關鍵字復用;提供DSL支持，將一些通用的業務操作封裝成DSL;提供數據驅動的支持封裝通用數據。

　　舉個例子：比如我們有一個業務場景-生單。生單包括search, booking, order三個大步驟。這三個大步驟里又包含若干小步驟，要調用若干個接口來實現。那測試框架可以干的就是提供一種抽象手段，讓用戶可以將這些小步驟封裝出這三個大步驟，而測試框架不能干的是閱讀 case時只看見一個步驟-order，但實際執行的時候search和booking卻都執行了(作為前置步驟)。這是底線一。

　　框架的第二個底線應該是不斷地引導用戶向簡單case這個方向走，而不是隨著功能增多，讓用戶可以寫出更多更復雜的case。如果你認為提供這個功能后，用戶會利用這個case寫出更復雜的case，那就應該思考我是不是應該提供這個功能。功能自動化測試是一把雙刃劍，它的收益也是一個拋物現狀，如果 case的復雜度超過了一個度，那么收益曲線很容易就越過拋物線的頂峰，急劇下降，然后成本很容易超過收益。所以如期讓用戶寫出更復雜的case，倒不如干脆不提供該功能，讓用戶要麻煩十倍百倍來實現那個case，或許聰明的用戶就會尋求別的測試方式，比如單元測試。

　　額......動筆之前覺得好多想說的，動筆之后發現沒什么好說的，但又好想吐下槽(不吐難受啊)，所以寫的爛糟糟的，歡迎指教。

原文轉自：http://blog.sina.com.cn/s/blog_6ee6888a0101l5fu.html