敏捷自動化測試(3)

　　腳本解讀：

　　1)第1行表示點擊“刪除”按鈕;

　　2)2~3行表示查找頁面上文本內容為新增帳號的div，并斷言該div已經不存在了(為空);

　　通過上面的腳本就可以實現“用戶增加、刪除”的自動化測試，并且可以跨瀏覽器?？吹竭@里您會不會覺得整體還不錯，如果測試腳本再能通過錄制的方式自動生成就更好了!

　　“看”起來確實還不錯，但在實際項目中用起來就沒那么爽了。這其實是在技術/工具選型時普遍存在的現象：在驗證/試用階段的評價很高，但在投入生產使用時會遇到各種各樣的問題，因此大家在選型階段除了考慮功能，還要考慮技術/工具本身的開放性和可擴展性。

　　上面的方案單純從技術的角度來講是很不錯的：開源、社區活躍、標準化程度高、支持跨瀏覽器、腳本回放穩定、可集成性高，等等。

　　但是如果就這樣應用在實際項目中，會從過程的角度暴露一些棘手的問題：

　　測試腳本是“代碼級”的，那么應該由誰來編寫呢?

　　測試人員和開發人員好像都有編寫這些測試腳本義務，但似乎又都有不寫的理由。

　　測試腳本必須不斷的修改才能在最新版本上跑通，誰該為此買單?

　　在敏捷開發過程中需要快速響應需求的變化(新增、變更)，這一點整個團隊都好理解。因此如果需求發生變化，開發人員修改代碼、測試人員修改測試腳本，一切順理成章，大家相安無事。但是在用戶需求沒有變化時，開發人員頻繁修改代碼的情況也很常見：比如，修改Bug、針對“壞味道”做重構、調整頁面布局或樣式。于是在“毫無征兆”的情況下，測試腳本又無法執行了!

　　這時候測試人員可能會質問開發人員：“做之前怎么不想清楚?都已經測試完成的功能，為什么還總是反復修改?什么時候代碼才能穩定?”。

　　而開發人員此時也會非常理直氣壯：“有Bug能不改么?頁面布局不合理導致用戶體驗差，能不改么?而且敏捷中的一個重要的實踐就是重構啊”。

　　大家又是似乎都有道理、也都有苦衷。我雖然作為測試人員，但是在這個問題上還是“偏向于”開發人員的： 在軟件生命周期的各個階段(需求、設計、開發、測試)中，后面的階段對前置階段是有一定依賴的，所以越往后期響應變化的難度越大。比如，在“開發”環節不僅需要響應“需求”的變化(新增、變更)，而且需要響應“設計”的變化。從這個角度來看，“測試”本就應該響應“開發”的變化。

　　對于在實際項目自動化測試過程中遇到的上述問題，歸根到底是因為“自動化測試方案本身的敏捷程度不夠”，主要體現在如下三個方面：

　　1、 學習成本高

　　測試人員除了要掌握WebDriver接口之外，還要掌握XPath、TestNG的用法，甚至還需要對功能的前臺實現有一定了解。

　　2、 腳本維護困難

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

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

　　3、 斷言條件繁瑣

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

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

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

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

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