人們常說說時間就是金錢，效率就是生命。不論對開發還是測試，效率都可以說是項目的生命。不想提高效率的工程師不是好經理!(嗯?不太對吧-,-)言歸正傳，本系列“高效率測試”短文希望能夠給大家介紹一些微軟測試團隊如何提高效率的實踐，謹和大家一起探討。
做過測試工作的人或許都知道，測試一個產品的工作量是比其開發的工作量要大得多的(在微軟，一個團隊測試人員的數目與開發人員的理想的比例是1.5比1)。做過測試工作的人也一定知道，這個“1.5倍”的黃金比例由于開發進度，項目需求的原因常常不容易滿足——即使是在微軟，這樣一個對軟件測試有巨大投入的公司�？梢韵胂�，一邊是緊迫的項目進度，一邊又是必須提供給用戶最高質量產品的不可侵犯的原則，這事兒對測試團隊就是一個地地道道的“杯具”。所幸的是，微軟的工程師們總能絞盡腦汁，螺螄殼里做道場，榨干每一行代碼、每一個測試用例的價值，最終把“杯具”變成“洗具”。下面就給大家講一個我參與的項目中利用策略模式(Strategy Pattern)做更高效測試的例子。
首先介紹一下產品背景。該產品是典型的數據庫 -> WebService -> Web三層架構，其中WebService和Web界面均是提供給用戶的開放接口，而他們提供的操作都是針對對象的創建，讀取，更新和刪除。對我們測試團隊而言，WebService和Web兩種用戶訪問界面是必測無疑的。這兩種界面的具體操作完全不同，譬如在Web界面上創建對象需要填寫并提交表單，而在 WebService界面中則是一個WCF(Windows Communication Foundation)的調用，但是他們對后臺而言則是完全相同的�？梢杂孟旅孢@個圖來表示。
這時候工程師們就動起了腦筋：既然Web界面和WebService界面對于后臺而言是相同的，也就是說Web界面的測試 和WebService界面的測試可以共享測試的過程(Scenario)和數據(Data)，只是具體實施操作的時候有所不同。這不就是設計模式中的策略模式嗎?沒錯，把邏輯操作(這里是測試步驟)抽象出來，可以在運行時切換具體實現的，就是策略模式。具體而言呢，對WebService的各種操作實現就是一個策略，對Web界面的操作實現也是一個策略。當工程師們實現自動化測試用例的時候，他們并不關心他在通過Web還是通過WebService做操作，他們只關心的是：用什么數據，做什么步驟。至于怎么做，是運行時根據環境決定的。這其中的關系可以用下面的圖表示：
基于在我所在項目組的實踐，我們發現利用策略模式的好處有：
1) 同樣的自動化測試用例可以同時測試Web界面和WebService界面，成倍的簡化了自動化測試代碼的編寫工作。
2) 清晰的分離了“做什么”和“怎么做”。編寫測試代碼可以更關注測試的步驟和邏輯。
3) 在項目的初始階段，WebService界面的操作會比較穩定，而Web界面往往會由于復雜度更高而不穩定。這時候可以使用WebService策略開發并運行自動化測試，等到Web界面穩定了，再把環境變量設為Web策略，就可以完全測試Web界面了。而常規的做法，如果Web界面不穩定，甚至只是某一個模塊不穩定，就會減慢或阻礙整個團隊的測試開發，進度大大受阻。
4) 當運行一個Web界面測試的時候，如果測試結果失敗，可以動態調整為使用WebService策略重新測試。這樣可以“自動”地幫助開發測試人員定位問題發生在Web層還是在WebService層。
5) 整體測試框架具有較高的擴展性。如果產品需要新增PowerShell作為另一個用戶界面，那么只需要實現PowerShellTestStrategy，就可以讓大多數測試用例運行在PowerShell上。
在微軟，其實還有很多做高效測試的例子，下次有機會再拿出來曬吧。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
