自動化測試：功能測試設計七技巧

　　自動化功能測試，或用戶界面(UI)測試，以難以維護而著稱，而且沒有足夠的能力找出缺陷。然而，在大多數情況下出現故障的原因不是測試工具或者測試框架，而是個別測試本身跟蹤設計不良。

　　下面有七個功能測試設計技巧，讓UI測試更加可維護和更強力。

　　不要只是點擊 要檢查后續狀態

　　很多自動化測試工具包含一個特性，就是可以自動記錄一系列動作，然后回放。盡管這樣的記錄/回放功能在創建測試時容易駕馭，但是單純的記錄/回放動作會導致不良測試。具體而言，記錄/回放測試并不會檢測應用中操縱元素后的應用狀態。

　　點擊、鍵入、選擇以及其他的功能都會以某種方式改變應用的狀態。好的測試會在應用中操作元素后檢查本身的結果。如果自動化測試跟隨一個鏈接，就要讓測試檢查結果頁是否正確。如果測試生成一個報告，就要檢查報告內容是否正確。

　　等待，請勿停止

　　通常，一個應用在結果可以用測試檢查之前需要一些時間。這一點在 Ajax在Web瀏覽器調用中尤為普遍。簡單地進行測試停止或者在檢查這樣的結果之前休眠幾秒是很吸引人的，但是停止或者休眠是不良實踐，如果應用用過長時間返回，然后測試就會生成錯誤失敗。如果應用更快地返回，然后測試在轉移的過程中就是浪費時間。

　　取代停止或者休眠，讓測試等待應用的具體方面出現了。這不僅僅讓測試減少錯誤失敗的傾向，而且也導致了更強的測試，因此測試根據生成的測試等待方面，實際等待檢查應用結果。

　　使用分離定位 不是索引

　　做測試的時候要是像“點擊這個頁面上的第三個鏈接”或者“選擇列表上的第五個元素”這樣就更好了。代替根據索引操縱應用的具體方面，為這樣的元素找出或者創建唯一識別符值得努力。

　　如果命令鏈接改變了，或者命令列表改變了，測試就會導向一種預期外的路徑，維護這樣不可預知的測試相當難。

　　用正則表達式檢查排列次序

　　應用以正確的序列顯示給用戶非常重要。無論是表格的列數還是列表的元素，或者是頁面本身的文本，自動化測試檢測事物正確的排列很重要。

　　這有一堆事情應該以“一”、“二”、“三”的順序出現。測試可以使用類似的正則表達式檢查出這些事情序列。下面是一個使用簡化的正則表達式“glob”的例子，“glob”在Selenium以及其他自動化測試工具中可用：

以下是引用片段：
| getText | glob:one*two*three |
| click | sort_thing |
| getText | glob:three*two*one | 

　　這個測試檢查的第一步是輸入文本“one”，隨后是文本“two”，然后是“three”。“*”表明測試允許“one”"two""three"之間任意的字符。測試第二步點擊導致“one”“two”“three”倒序排列，然后測試第三步檢查這個排列是否成功了。

　　一次且僅一次

　　正如上面所指出的，在應用中等待一個元素出現是較好的實踐。通常這樣的例子中一旦元素出現，測試會希望操作這個元素，實例就是點擊。這是抽象通用動作到期自己的方法或者模型的最佳實踐，然后測試按需調用這些動作。下面是一個例子，在Fitnesse和Selenium語法中wait-for-and-click抽象。

以下是引用片段：
!| scenario | Wait for and click | elementLocator |
| waitForElementPresent | @elementLocator |
| click | @elementLocator |
So from a test itself we need only write:
| open | www.foo.com |
| Wait for and click | link=Welcome to Foo! | 

　　這個例子中僅節省了一行鍵入，如果“Wait for and click”在測試套件中執行了數百次或者數千次，可維護性和可讀性。另一個動作例子就是抽象到期自己可能登陸的模型，選擇列表中的所有元素，為一系列錯誤做檢查。

　　不要使用條件語句

　　有時，測試環境具有不可預見性。在這樣的案例中，在測試中使用條件語句很誘人，例如“if this element exists, click it, if it does not exist, do something else.”這種方法會存在很多問題。一個問題就是類似使用索引代替具體定位器導致的問題：如果應用測試改變，自動化測試將會以完全不可預期和位置路徑傳下去，導致錯誤失敗(或者更糟糕的是錯誤成功)，讓維護更加困難。另一個問題是條件語句聲明的一個分支(錯誤地)出現在一起，測試在引入時從未顯示一個缺陷。

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