我們的測試為什么不夠敏捷(3)

　　【注】業界常見的測試工具本質上還是針對頁面源碼來編寫(或生成)測試腳本的，即使提供了錄制工具，此類腳本的可讀性和后期可維護性還是非常差的。

　　3、 斷言條件繁瑣

　　業界常見的測試工具即使提供錄制腳本的功能，但是對于“斷言”還是需要人工插入的(工具做不到智能的判斷我們想要在哪里設置斷言)，于是斷言就成了自動化測試人員的“噩夢”。

　　斷言對象可能很“多”,頁面的信息量往往很大，需要在測試腳本中為每個斷言對象(比如，頁面某個文本框的值)補充斷言語句。

　　預期結果是可能“變”化的，甚至是動態的，因此預期結果的值如果與腳本邏輯耦合在一起，將來極難維護。 斷言機制比較“呆”板，對于 未設為斷言對象的字段，如果發生錯誤也是無法感知的，并且難以對于UI樣式或UI邏輯(比如，翻頁圖標應該灰顯)進行斷言。

　　換個角度可以理解為，如果這樣的斷言條件“多”的話，整個測試用例集會“變”的非常“呆”板!

　　想要有效的改善這些問題，就必須讓自動化測試變得“敏捷”起來!

　　在本系列后續的文章中會就“如何讓測試腳本易寫、易讀、易維護”、“如何讓斷言不再成為測試的負擔”、“如何通過持續集成讓測試用例發揮更大的價值”進行詳細的介紹，敬請關注!

原文轉自：http://www.infoq.com/cn/articles/test-no-agile-enough