我們的測試為什么不夠敏捷？
測試是為了保證軟件的質量，敏捷測試關鍵是保證可以持續、及時的對軟件質量情況進行全面的反饋。由于在敏捷開發過程中每個迭代都會增加功能、修復缺陷或重構代碼，所以在完成當前迭代新增特性測試工作的同時，還要通過回歸測試來保證歷史功能不受影響。為此我們期望：
測試范圍足夠廣：
- 測試用例要覆蓋所有功能；
- 要在各種可能的環境下作兼容性測試；
- 系統的穩定性、性能都要測試； </ul>
- 每日構建產生的版本要保證可用；
- 每個迭代都需要對歷史功能做回歸測試；
- 釋放前或上線后如果打了補丁，就需要回歸； </ul>
- 上線時間提前確定，研發進度延期，測試計劃被迫延后；
- 最后階段經常會臨時增加測試任務；
- 所有人都知道還需要再經過一輪測試，但時間沒有了； </ul>
- 臨時從其他項目抽調的測試人員不能立刻有效的開展測試工作；
- “搞不清楚”本項目的研發人員到底是不會做測試還是不愿做測試； </ul>
- 提交給測試的版本為什么研發人員不先做通過性測試？
- 這次代碼改動量不大，有必要再花那么多時間回歸么？
- 當初不是承諾這次修改肯定不會影響以前的功能么？
- 怎么不早說要支持 Chrome 瀏覽器，現在哪還有時間測試啊？
- 怎么能讓現場出現這種低級的 Bug，打補丁后為什么不仔細回歸一遍？ </ul>
- 大量機械的、重復性的回歸測試；
- 結果的正確性不依賴主觀判斷的測試；
- 需要模擬大量數據、大量并發量的測試；
- 需要不間斷執行的測試（比如7*24 小時持續執行）；
- 需要短時間內完成的大量測試用例執行（比如完整的功能回歸測試）； </ul>
- Selenium IDE </ul>
- Selenium RC </ul>
- Selenium WebDriver </ul>
- Selenium Grid </ul>
- By.xpath ()表示通過 XPath 來定位頁面元素；
- click ()表示在找到的當前控件上執行點擊操作； </ul>
- sendKeys ()表示在找到的當前控件上輸入字符；
- 2~9 行表示通過輸入或點擊選擇的方式為用戶相關屬性賦值；
- 第 10 行表示點擊“保存”按鈕（點擊后會自動轉向用戶列表頁面）；
- 11~12 行表示查找頁面上文本內容為新增帳號的 div，并斷言該 div 是存在的（不為空）； </ul>
- 第 1 行表示點擊“刪除”按鈕；
- 2~3 行表示查找頁面上文本內容為新增帳號的 div，并斷言該 div 已經不存在了（為空）； </ul>
- 測試腳本是“代碼級”的，那么應該由誰來編寫呢？ </ul>
- 測試腳本必須不斷的修改才能在最新版本上跑通，誰該為此買單？ </ul>
測試頻率足夠高：
但實際情況往往不遂人愿：
實際測試周期變短：
有效測試資源稀缺：
因此由于客觀上的資源和時間限制，完整的、及時回歸測試在人工測試情況下，往往是不可能完成的任務。團隊內部也會產生各種爭執：
爭執越演越烈，最終有團隊成員爆發了：“這簡直不是人干的活！”。
您怎么看待這句話呢？
其實話糙理不糙，用更理性的語言翻譯一下就是“有些工作不應該以人工的方式來完成”，比如：
通過自動化測試可以極大的提升回歸測試、穩定性測試以及兼容性測試的工作效率，在保障產品質量和持續構建等方面起到舉足輕重的作用。特別是在敏捷開發模式下，自動化測試是必不可少的。
目前業界的商業/開源自動化測試工具有很多，比如，功能測試工具有 QTP、Selenium 等，性能測試有 LoadRunner、JMeter 等。其工作原理無非都是通過“測試腳本”和“測試數據”來完成“測試過程”，并比較“測試結果”，進而形成“測試報告”。
本文不對這些測試工具的差異或優劣進行對比，只以作者目前采用的 Selenium 為例進行分析：敏捷開發模式需要自動化測試，但自動化測試本身的敏捷性又如何呢？
Selenium 是針對 Web 應用的開源自動化測試工具，通過編寫模擬用戶操作的腳本，它會打開瀏覽器對 Web 應用進行黑盒測試。可以方便的用于功能測試、兼容性測試、 穩定性測試及并發測試。目前已被主流瀏覽器廠商廣泛支持，同時也是很多其它自動化測試工具（比如，RobotFramework）的底層核心技術。Selenium 由 IDE、Remote Control（簡稱 RC）、WebDriver、Grid 四個工程組成：
是一個用于錄制/回放測試腳本的 Firefox 附加組件，錄制的腳本可以生成基于 Selenium RC 的測試代碼（Java、Ruby、C#等）。適用于快速入門，不太適用于實際較大的測試項目；
RC 由 Server 和 Client 組成兩部分組成，Server 負責加載/關閉瀏覽器以及作為 HTTP 代理來訪問 Web 應用，Clinet 支持多種編程語言和測試框架（TestNG、JUnit、NUnit 等）。
WebDriver 作為 Selenium2 的核心特性提供比 RC 更簡潔易用的 API，是官方推薦的 RC 替代方案。可以更好的支持動態網頁，不需要再額外啟動一個獨立的 Server。
是 Selenium 的一個擴展工具，可以很方便地同時在多臺機器上和異構環境中并行運行多個 RC 或 WebDriver 用例。
Selenium RC 是通過在瀏覽器加載時“注入”JS 函數來操縱后續的瀏覽器行為，Selenium WebDriver 則通過直接調用各個瀏覽器內置的本地事件來達到這一目的。WebDriver 目前已經作為 W3C 規范草案，提交由 Google、Mozilla 等瀏覽器廠商討論。
WebDriver 規范定義一組與平臺、語言無關的接口，包括發現和操作頁面上的元素以及控制瀏覽器行為，主要用于支持 Web 應用的自動化測試。WebDriver 的核心是通過 findElement 方法返回 DOM 對象（WebElement），通過 WebElement 可以對 DOM 對象進行操作（獲取屬性、觸發事件等）。其中 findElement 方法需要的元素定位器（Locator）支持 ID、XPath、CSS、超鏈接文本等多種方式。
</blockquote>“WebDriver”顧名思義就是“Web 瀏覽器驅動”，它專注于解決如何通過外部命令（通常為測試用例）操作瀏覽器的問題。至于測試用例按照什么順序執行、執行過程中如何傳遞數據、測試結果如何斷言、如何報告，則可以通過集成其它優秀的專業測試框架（比如，TestNG）來實現（WebDriver 沒有必要重復造輪子）。
下面用以“用戶管理”為例，來看看用 WebDriver 實現的“增加”和“刪除”測試腳本（只示意部分關鍵代碼）。
1、在用戶列表頁面點擊“新增”按鈕，跳轉到新增用戶頁面：
webDriver.findElement (By.xpath ("http://a[contains (@id,'addUserBtn')]//button")) .click ();.
腳本解讀：
2、在新增用戶頁面，輸入“帳號”、“密碼”、“姓名”，選擇“性別”、“生日”和“國籍”，然后點擊“保存”按鈕，回到用戶列表頁面，并判斷是否增加成功：
1) String account="autotest2";2) webDriver.findElement (By.xpath ("http://div[contains (@id,'account_userForm')]//input")) .sendKeys (account);3) webDriver.findElement (By.xpath ("http://div[contains (@id,'password_userForm')]//input")) .sendKeys ("1");4) webDriver.findElement (By.xpath ("http://div[contains (@id,'name_userForm')]//input")) .sendKeys (account);5) webDriver.findElement (By.xpath ("http://div[contains (@id,'sex_userForm')]//input")) .click ();6) webDriver.findElement (By.xpath ("http://span[text ()='女']")) .click (); 7) webDriver.findElement (By.xpath ("http://div[contains (@id,'birthdate_userForm')]//input")) .click ();8) webDriver.findElement (By.xpath ("http://div[contains (@id,'nationality_userForm')]//input")) .click ();9) webDriver.findElement (By.xpath ("http://span[text ()='中國']")) .click (); 10) webDriver.findElement (By.xpath ("http://a[contains (@id,'userSaveBtn')]//button")) .click (); 11) WebElement ele = webDriver.findElement (By.xpath ("http://div[text ()='"+account+"']")); 12) Assert.assertNotNull (ele);
腳本解讀：
3、刪除剛剛增加的人員，然后判斷是否刪除成功：
1) webDriver.findElement (By.xpath ("http://a[contains (@id,'deleteUserBtn')]//button")) .click ();2) WebElement ele = webDriver.findElement (By.xpath ("http://div[text ()='"+account+"']"));3) Assert.assertNull (ele);
腳本解讀：
通過上面的腳本就可以實現“用戶增加、刪除”的自動化測試，并且可以跨瀏覽器。看到這里您會不會覺得整體還不錯，如果測試腳本再能通過錄制的方式自動生成就更好了！
“看”起來確實還不錯，但在實際項目中用起來就沒那么爽了。這其實是在技術/工具選型時普遍存在的現象：在驗證/試用階段的評價很高，但在投入生產使用時會遇到各種各樣的問題，因此大家在選型階段除了考慮功能，還要考慮技術/工具本身的開放性和可擴展性。
上面的方案單純從技術的角度來講是很不錯的：開源、社區活躍、標準化程度高、支持跨瀏覽器、腳本回放穩定、可集成性高，等等。
但是如果就這樣應用在實際項目中，會從過程的角度暴露一些棘手的問題：
測試人員和開發人員好像都有編寫這些測試腳本義務，但似乎又都有不寫的理由。
在敏捷開發過程中需要快速響應需求的變化（新增、變更），這一點整個團隊都好理解。因此如果需求發生變化，開發人員修改代碼、測試人員修改測試 腳本，一切順理成章，大家相安無事。但是在用戶需求沒有變化時，開發人員頻繁修改代碼的情況也很常見：比如，修改 Bug、針對“壞味道”做重構、調整頁面布局或樣式。于是在“毫無征兆”的情況下，測試腳本又無法執行了！
這時候測試人員可能會質問開發人員：“做之前怎么不想清楚？都已經測試完成的功能，為什么還總是反復修改？什么時候代碼才能穩定？”。
而開發人員此時也會非常理直氣壯：“有 Bug 能不改么？頁面布局不合理導致用戶體驗差，能不改么？而且敏捷中的一個重要的實踐就是重構啊”。
大家又是似乎都有道理、也都有苦衷。我雖然作為測試人員，但是在這個問題上還是“偏向于”開發人員的： 在軟件生命周期的各個階段（需求、設計、開發、測試）中，后面的階段對前置階段是有一定依賴的，所以越往后期響應變化的難度越大。比如，在“開發”環節不 僅需要響應“需求”的變化（新增、變更），而且需要響應“設計”的變化。從這個角度來看，“測試”本就應該響應“開發”的變化。
對于在實際項目自動化測試過程中遇到的上述問題，歸根到底是因為“自動化測試方案本身的敏捷程度不夠”，主要體現在如下三個方面：
1、 學習成本高
測試人員除了要掌握 WebDriver 接口之外，還要掌握 XPath、TestNG 的用法，甚至還需要對功能的前臺實現有一定了解。
2、 腳本維護困難
敏銳的開發/測試人員從上面的示例腳本中，可以馬上嗅出一些“壞味道（Bad Smell）”: 代碼相似度非常高、可能變化的數據被硬編碼在測試代碼里、代碼可讀性差、測試代碼與頁面源碼耦合度大，等等。這些壞味道的出現，通常意味著需要進行重構， 否則會愈演愈烈，最終變得尾大不掉。
【注】業界常見的測試工具本質上還是針對頁面源碼來編寫（或生成）測試腳本的，即使提供了錄制工具，此類腳本的可讀性和后期可維護性還是非常差的。
3、 斷言條件繁瑣
業界常見的測試工具即使提供錄制腳本的功能，但是對于“斷言”還是需要人工插入的（工具做不到智能的判斷我們想要在哪里設置斷言），于是斷言就成了自動化測試人員的“噩夢”。
斷言對象可能很“多”，頁面的信息量往往很大，需要在測試腳本中為每個斷言對象（比如，頁面某個文本框的值）補充斷言語句。
預期結果是可能“變”化的，甚至是動態的，因此預期結果的值如果與腳本邏輯耦合在一起，將來極難維護。 斷言機制比較“呆”板，對于未設為斷言對象的字段，如果發生錯誤也是無法感知的，并且難以對于 UI 樣式或 UI 邏輯（比如，翻頁圖標應該灰顯）進行斷言。
換個角度可以理解為，如果這樣的斷言條件“多”的話，整個測試用例集會“變”的非常“呆”板！
想要有效的改善這些問題，就必須讓自動化測試變得“敏捷”起來！
在本系列后續的文章中會就“如何讓測試腳本易寫、易讀、易維護”、“如何讓斷言不再成為測試的負擔”、“如何通過持續集成讓測試用例發揮更大的價值”進行詳細的介紹，敬請關注！
作者簡介
殷坤，東軟集團資深測試經理、技術講師，10 年軟件研發、實施、測試及項目管理工作經驗。 目前專注于敏捷項目管理及質量控制、過程改善、自動化測試、持續集成、用戶體驗提升等方面來自: InfoQ本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
