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

　　敏銳的開發/測試人員從上面的示例腳本中，可以馬上嗅出一些“壞味道(Bad Smell)”: 代碼相似度非常高、可能變化的數據被硬編碼在測試代碼里、代碼可讀性差、測試代碼與頁面源碼耦合度大，等等。這些壞味道的出現，通常意味著需要進行重構，否則會愈演愈烈，最終變得尾大不掉。

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

　　3、 斷言條件繁瑣

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

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

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

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

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

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

　　作者簡介

　　殷坤，東軟集團資深測試經理、技術講師，10年軟件研發、實施、測試及項目管理工作經驗。 目前專注于敏捷項目管理及質量控制、過程改善、自動化測試、持續集成、用戶體驗提升等方面。

　　感謝侯伯薇對本文的審校。

　　給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博(@InfoQ)或者騰訊微博(@InfoQ)關注我們，并與我們的編輯和其他讀者朋友交流。

原文轉自：http://www.infoq.com/cn/articles/test-no-agile-enough?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk