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

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

　　但是如果就這樣應用在實(shí)際項目中，會(huì )從過(guò)程的角度暴露一些棘手的問(wèn)題：

　　測試腳本是“代碼級”的，那么應該由誰(shuí)來(lái)編寫(xiě)呢?

　　測試人員和開(kāi)發(fā)人員好像都有編寫(xiě)這些測試腳本義務(wù)，但似乎又都有不寫(xiě)的理由。

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

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

　　這時(shí)候測試人員可能會(huì )質(zhì)問(wèn)開(kāi)發(fā)人員：“做之前怎么不想清楚?都已經(jīng)測試完成的功能，為什么還總是反復修改?什么時(shí)候代碼才能穩定?”。

　　而開(kāi)發(fā)人員此時(shí)也會(huì )非常理直氣壯：“有Bug能不改么?頁(yè)面布局不合理導致用戶(hù)體驗差，能不改么?而且敏捷中的一個(gè)重要的實(shí)踐就是重構啊”。

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

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

　　1、 學(xué)習成本高

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

　　2、 腳本維護困難

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

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

　　3、 斷言條件繁瑣

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

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

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

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

　　想要有效的改善這些問(wèn)題，就必須讓自動(dòng)化測試變得“敏捷”起來(lái)!

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