聊聊自動化測試有效性(3)

　　以正交覆蓋為例，我們需要把影響流程分支走向的因子羅列出來。一般理論認為，缺陷的產生絕大多數是因為2個因素組合產生的，所以我們先做一個正交強度為2的配對來確認最小的測試組合范圍。然后將正交強度變為最大，得到一個最大的測試組合范圍，重新審視強度為2時的子集之外的其他案例是否有必測的理由。注：正交強度最大的組合結果集并不是簡單的笛卡爾乘積，因為組合條件之間可能存在一些邏輯限制;此外，鑒于篇幅有限，本文就不再羅列下表最終正交得出的測試組合結果。

　　圖3：保險業務操作偽場景分析正交表樣例

　　通過對前端業務操作流程的分析，可以建立完整的前端的測試用例庫，當然，前端的自動化測試可能只會選擇其中的一部分去做，如上文所述，自動化測試覆蓋率也可以很輕易地度量出來。在設計評審過程中，流程設計完成者需要向評審人員展示各個業務流程的測試組合結果，并且解釋通過怎樣的組合方法得到這些結果;進一步闡述依據什么樣的原則得出自動化測試范圍的選擇結果。

　　特性組件抽取

　　完成了對測試案例場景的界定，我們便已明確我們要在被測應用上做什么樣的操作，接下來的工作就是一些通用的簡易特性抽取。雖然很多人聲稱復用不是個好東西，但它在編寫測試腳本中適度的使用，卻也可以很好地減少測試腳本開發和維護成本。

　　第一層的特性抽取可以通過測試框架和工具來完成，簡易的二次封裝是保證測試書寫低復雜度和保證測試腳本健壯性的好辦法，就如同圖中對click方法的簡單封裝一樣。這件事情只需要一個像筆者一樣略微熟悉測試工具和被測應用特性的測試工程師即可完成。所以這個活動的成本不會太高，而帶來的效益卻還是很不錯的，至少可以給不熟悉測試工具的腳本開發者一段很長的學習緩沖期。

　　圖4：STAR測試框架中的Api樣例

　　接下來就是被測對象的共有特性組件做抽取，仍以前端自動化測試腳本開發為例，我們可以參照被測應用本身的組件復用規律來提取測試腳本中的公用頁面組件。例如，圖3所涉及的保全操作流程中，至少包含保全申請發起、質檢、核保這三個可公用的頁面組件。假如最終需要測試的場景案例有8個，其中5個必須質檢、4個必須人工核保，那么在這三個點上就可以節省 14(8+5+4-3)個測試Api的維護和開發成本。

　　共有特性組件既不能設計的過于粗糙，從而造成在不同的自動化測試腳本中無法統一支持;又不能過度抽象，進而導致可讀和可維護性變差。目標很簡單：任意一處純前端頁面的改動，我們只需要修改一個測試Api;任意一個分支場景的規則改動，我們只需要修改一個測試案例腳本的數據和驗證方法。

　　腳本重構與舍棄

　　雖然測試腳本應該被良好地規劃設計，但實際執行的時候可能會遇到一些問題，比如在識別公用特性組建時存在遺漏卻未在評審環節被發現，抑或被測應用的代碼重構甚至是流程再造同樣會要求我們去做這些對應的測試腳本重構的工作。

　　我每天都會從SVN上checkout我們組17個工程的測試腳本，之前經常會發現某些系統一次性update十數個甚至數十個文件。這時候我會問一聲為什么，最初得到的答復都是由于系統頁面發生變動，所以這部分測試腳本都需要同步修改。我的回復一律都是：重構，重新做公用組件抽取，立刻做，因為我們耗不起這個維護成本!幾次之后，再遇到這種情況，得到的答復便基本上都是：因為XX的變更影響了一些模塊的測試腳本，所以我重構了一下。這時候我的心里就比較嗨皮，比較有成就感了，因此我也樂于不斷地給大家灌輸這種從別處學來的理念，而測試腳本重構的動力也從單純的前端頁面變更驅動變得更加多樣化。

　　伴隨著測試腳本的開發，債務不可避免的在不斷產生，如果不加以管控，終有一天我們都會由于對之無法負擔而崩潰。所以我們如果真的重視自動化測試，我們就需要不斷地優化我們測試腳本的結構，讓它始終停留在我們可以控制的范圍之內。必要的時候我們可以放棄一些已經開發完成的但是優先級稍低的測試腳本，即便它們運行得很好。在負擔能力滿載的情況下，以放棄低優先級的部分為代價來換回我們對測試資產持續優化和維護的能力、換回我們對這種低端技術債務的負擔能力，始終都比承擔不可控甚至崩潰的風險要來得更加有價值。

原文轉自：http://www.uml.org.cn/Test/201307094.asp