如何創建可維護的自動化驗收測試

　　測試即開發

　　這里的測試指的是自動化測試，從軟件的本質上看，測試的自動化乃是測試方面的軟件開發，萬變不離其宗，這也就意味著那些凡是屬于軟件開發的定律或者原則也同樣適用于測試自動化。對于沒有寫過代碼或者代碼經驗較少的人來說，或許這其中的道理不能一眼就瞧得出來。

　　通常情況下軟件開發的很大一部分開銷是維護——修修補補，更新不斷。軟件的可維護性強，則開發成本低，同理，測試的自動化開發成功與否也很大程度上體現在它的可維護性成本大小上。我接觸過的很多試圖嘗試引進自動化測試的機構沒幾個月就決定放棄自動化測試，問之棄因，你會發現大多是因為自動化腳本過于不穩定以及隨之衍生的難維護性。舉個例子，界面上重命名一個按鈕會導致大批的測試用例失敗，而與此同時花費在調通和更新這些用例身上的時間成本又太高。

　　有些團隊或機構在自動化測試上取得了成功，難道他們的自動化就可以避免掉這樣的維護費用問題?當然不可能。而成功與失敗的團隊之間一個重要的區別就是：在對待測試開發的維護問題上，失敗者往往是被昂貴的維護費用嚇住而放棄自動化計劃，而成功者則是從一開始就做足了應對措施。那些在自動化取得成功的團隊懂得測試即開發這一道理，明白測試開發一旦開始，維護在所難免，所以他們會深思熟慮，想方設法降低維護成本。

　　軟件需求的變更和系統實現的變更會影響測試，需要測試做出相應的調整，這二者任意一種變更都可能導致一系列的自動化測試失敗。如果一些自動化測試不能同步新的軟件變更和產品新特性，那么它們將會被淘汰，其測試結果也不會得到運用。而要使其回歸正常，我們必須不斷調整測試以配合需求和系統實現的變更。維護的成本開始顯山露水。

　　因此如果需求和實現的變化是必然的，那么降低自動化測試維護成本的方法只有一個，即編寫適應性強的測試腳本。

　　暴露太多無關緊要的細節或者重復這兩大關鍵因素使得修改代碼的困難大大增加，無數慘痛的經驗教訓讓軟件開發人員對此深有體會，對于那些正在從事和將要從事的自動化測試開發者們，也肯定不想重蹈覆轍。

　　驗收測試和系統的任務

　　驗收測試用來檢測一個系統是否正確履行了某一特定任務。也就意味著，驗收測試的核心是關注它所要驗證的功能點是否正確，而不考慮用了何種技術、何種方法去測試。

　　現在假定我們要測某個系統的創建賬號這個特性，系統通過傳遞給Create命令用戶名和密碼來創建新賬號。創建賬號特性的功能之一是驗證密碼的有效性。一個合法的密碼長度必須介于6~16字符之間且至少包含一個字母、一個數字以及一個標點符號。如果用戶提交的密碼合法，Create命令創建成功并報告Account Created;反之，Create命令不會執行創建過程，同時報告Invalid Password。這就是功能職責的本質。無論軟件系統以何種技術實現，Web應用也好，GUI桌面應用也罷或者是命令行執行的程序，也不管會不會有人像德州電鋸殺人狂里的休維特一樣，揮舞瘋狂的電鋸恐嚇要鋸斷那些輸錯密碼童鞋的指頭，總之，系統需執行此項職責(密碼檢查是系統必須實現的職責)。

　　無關緊要的細節

　　表1 不良自動化測試用例腳本

　　列表1展示的是一段不良自動化測試用例腳本，該測試用例用來檢測Create命令的密碼有效性檢查這一職責。

　　這段測試腳本問題很多，一眼望去，最明顯的是可讀性很差，我們看到第二行The create command validates passwords，這是測試的標題，表明該測試的測試點和職責，但往下讀時，我們會發現，里面充斥了太多累贅的單詞和煩人的諸如“{$@^”這樣的符號，讓人不知其所言。

　　仔細看一下，我們可以挑出來幾個密碼，比如1234!@$^!緊接著再加把勁，啊哈，我們會發現一些密碼會導致status值為Invalid Password，而另一些會使得status值為Account Created。從另一方面看，我們可能也會注意不到上述內容因為該測試腳本在密碼和狀態status之間夾雜了太多的實現細節，或曰：測試噪聲。試想，這些特殊的符號$、@、^以及單詞Run、Ruby、fred究竟和密碼及其有效性有什么關系!對于自動化測試的腳本來說，從用例的可讀性和可維護性角度看這些都是無關緊要的過程實現細節。

　　過多無關緊要的細節是怎樣毀掉可維護性的?假設我們的系統安全分析師指出六位長度的密碼本身不安全。于是為了增強安全性，我們將密碼長度下限由六改成十，這是一個典型的需求變更，請思考，這時候列表1的測試腳本哪里需要修改?怎樣改?答案恐怕沒那么簡單。

　　讓我們再來考慮一個更有挑戰性的需求變更。假如我們想讓系統管理員能夠為任一種情況設定具體的密碼長度最長與最短值。這時候該怎么修改剛才的測試腳本?答案還是無法一眼看出?？峙聸]那么簡單。

　　這其中的原因“恐怕”在于測試腳本沒有清晰表達它所要測試的功能職責。當看不出一段測試用例腳本的本質 ，通常意味著需求變更之時測試人員會需要花數倍的代價來修改原測試腳本。

　　因此，為方便識別本質就要隱藏非必要細節的，以使自動化腳本用戶更容易看到測試的本質，在上面創建用戶的例子中，大多數非必要的細節是如何調用Create命令。該系統是基于Ruby的命令行程序，現在讓我們再次返回列表1的測式腳本里解讀一番，黑色字體加深的第一行告訴自動化測試框架Robot啟動Ruby解釋器，加載被測程序文件app/cli.rb，并調用Create命令，參數值為用戶名fred以及密碼1234!@$^，最后命令返回的結果存在變量${status}中，呵，數數不必要的實現，細節至少有5~6個之多!

　　再來看字體加深的第二行，實現命令返回值和期望值Invalid Password的比較，雖然看起來比剛才那一行較容易理解 ，但措辭笨重，并且過分的語法細節容易分散人們的注意力。

　　通過Robot自動化框架我們可以把實現細節提煉成關鍵字(Keyword)，使之以類似子函數的形式為測試用例腳本調用，一個完整的自動化測試用例便可由數個關鍵字組合而成。

　　現在我們演示如何使用關鍵字來隱藏不必要的實現細節。一個可行的方法就是問自己這樣一個問題：假設自己對被測系統實現一無所知，該如何寫出自動化測試腳本的第一步?是的，即使對實現一無所知也無大礙，我們只需 知道我們要測試創建用戶這個產品特性——被測系統顯然要提供的功能。繼而我們知道創建用戶即是被測系統的必要職責，而且從系統需求分析可知創建用戶需要提供用戶名和密碼。

原文轉自：http://www.anti-gravitydesign.com