敏捷測試的思考和新發展

文 / 朱少民

2010年為《程序員》雜志寫了一篇《敏捷測試的方法和實踐》，我們可以回過頭來，看看過去的一年，敏捷測試發生了哪些變化。首先，我做了一個實驗，分別打開2010年和2011年的“STAREAST Conference at-a-Glance”，輸入Agile，2010年顯示10個結果，而2011年顯示17個結果，有一個很大的增長，說明敏捷測試越來越引起大家的關注。這只是一個表面的現象，我們還需要真正了解發生了哪些實質性的變化。

舉一個例子，《敏捷測試：測試人員和測試團隊的實踐指南》的作者Lisa Crispin在StarEast 2011上有一個演講——Agile Testing: After the First Year, What’s Next? 其中提到，我們從傳統開發方法轉向敏捷方法，由于開發人員掌握了測試驅動開發（TDD，Test Driven Development），而測試人員部分地實現了驗收測試和回歸測試的自動化，所以我們活下來了，但我們在接下來深入實施敏捷測試時，還會面臨新的挑戰，甚至要克服更大的困難。當測試人員有了一年的經驗，并擁有了敏捷方法的價值觀、原則和實踐之后，我們還不得不考慮如何不斷改進持續的發布、如何有效地管理技術債務、如何對客戶的需求有更好的理解，這就要求我們掌握更深的敏捷測試技術，例如將“精益（Lean）方法”用于改進敏捷測試的績效，以及重構自動化測試的設計或腳本以提高投入產出比。 

TDD 向ATDD、BDD轉化？

以前人們談到敏捷方法，就會談到TDD或UTDD（Unit TDD），但是究竟有多少個公司在采用TDD方法來寫代碼？而在采用TDD開發方法的公司中，又有多少程序員在全面使用TDD方法呢？TDD是一個糾結的問題。一方面，TDD的確是一個好東西，先寫測試用例、后寫代碼，保證程序員第一次就把代碼寫對，也徹底解決了代碼的可測試性問題，在代碼層次上把缺陷的預防做到淋漓盡致。另一方面，多數項目很緊張，不可能給程序員足夠時間去實施TDD，程序員對實現有極大興趣，而對測試缺乏興趣，多數程序員也不愿意或不會主動去做TDD。這樣，TDD實踐還存在較大困難，有比較多的爭議。我看到一位作者寫道：組里頭TDD說了3年，據我所知，看完兩本TDD名著，并堅持寫單元測試的人只有我一個（我組里有開發人員15名）。

圖1 TDD和ATDD之間的關系

為了解決TDD實施不力，在過去一年，越來越多的人關注ATDD，即驗收測試驅動開發（Acceptance Test Driven Development）。從2003年開始，人們逐漸實踐TDD，而ATDD 是在2007年Lasse Koskela寫了一本書《測試驅動：Java開發人員的TDD和ATDD》 ，才開始引起大家的更多關注。從那時算起也有四年了，但在國內，則是最近一兩年的事。當然，我們可以將TDD和ATDD結合起來使用，形成一種混合的方法模型。TDD和ATDD之間的關系，可以用圖1來描述。

接著，BDD（行為驅動開發，Behavior Driven Development）也開始大行其道，那BDD是不是“做得比較好的TDD”呢？概念越來越多，概念的界限就難以確定，BDD可以看成ATDD的延伸，只是BDD更強調用戶的視角、用戶的行為，為ATDD注入了“Given，When，Then”這樣特定的需求描述語言。2009年，BDD創始人在倫敦發表的“敏捷規格、BDD和極限測試交流”中，對BDD給出了如下定義：

BDD是第二代的、由外及內的、基于拉動的（pull）、多方利益相關者的（stakeholder）、多尺度的、高度自動化的敏捷方法。它描述了一個交互循環，可以具有帶有良好定義的輸出（即工作中交付的結果）：已測試過的軟件。

但這個定義看起來還不夠好，至少讓我們明白起來還有一定的困難。實際上，BDD具有自己特定的“Given，When，Then”行為描述語言，和敏捷的user story極為吻合。所以“Given，When，Then” 行為描述語言才是BDD最顯著的特征。

TDD在寫測試用例時，常常會提出“我們應該先測什么”，然后針對測試的條件來填充代碼，而BDD則試圖換一種方式去思考問題，即問自己“預期的行為是什么？”，可能會寫出結構更好的代碼。說到底，BDD更關注客戶的需求，通過了解客戶的不同行為，對客戶的需求有更深刻的理解，從而借助對需求逐漸深入的理解來驅動軟件開發。

TDD更重要的價值是其思想，就像傳統的制造業，一定是先知道產品的質量標準或驗收標準之后，才去設計、制造。從這個思想來看，TDD、ATDD和BDD都是一樣的。不一樣的是其具體的操作方法或實踐，我們可以說，ATDD和BDD有一定的進步，但還沒有到達完美的地步，還有提升的空間。在未來，首先就是如何靈活結合BDD、ATDD和TDD來構成一個測試體系，是一個發展方向；其次，就是在BDD、ATDD和TDD最根本的、共同的思想基礎上，構成一個全新的、更完善的敏捷測試框架。后者的可能性更大。

探索式測試的地位

在過去一兩年，在敏捷方法中探索式測試（Exploring Test，ET）也是一個熱門話題，甚至有些人想用探索式測試來代替傳統的用例測試（case-based test）或腳本測試（scripted  test），走向另一個極端。探索式測試是對用例測試的補充，在非敏捷開發方法中也可以使用。只是在非敏捷開發方法中，有較為嚴格的需求規范和設計文檔，有充分的時間去設計足夠的測試用例，探索式測試只是作為一種輔助的手段發現一些隱藏很深的缺陷，并成為一種產品學習的工具以完善測試用例。然而，在敏捷測試中，由于迭代快、需求變化相對頻繁，缺乏詳細的需求描述文檔和足夠的設計描述文檔，探索式測試發揮更大的作用，甚至在新功能測試中發揮決定性的作用。需要提醒的是，在敏捷測試中，回歸測試應該仍然以用例測試為主，可以這樣說，回歸測試還是百分之百的用例測試。

探索式測試，實際早在1984年就由James Bach和Cem Kaner提出來，但為什么直到最近幾年才比較熱呢？這主要得益于敏捷開發方法的興起，而敏捷開發方法的興起又得益于互聯網應用的迅速擴張。大家都知道，互聯網應用越來越普遍，競爭越來越激烈，迫切要求互聯網應用產品發布要快，再加上許多互聯網產品的開發，都極具創新性、摸著石頭過河，其需求不明確，要求開發周期短，頻繁發布新的版本，及時獲得市場和用戶的反饋，不斷修正以更好地滿足用戶的需求。針對被測對象，所掌握的信息不夠充分的情況下，探索式測試就是一種很有效的測試方法。而且，把測試過程寫下來（腳本化）需要時間，在敏捷測試中，時間顯得更為珍貴。如果需求變化快，腳本化的測試用例維護成本也過高、甚至是極大的浪費。探索式測試的倡議者還認為，測試執行過程應該是智力活動的過程，這一過程越善于思考、越流暢，我們越有機會發現缺陷。而用例測試方法，有太多的停頓、不夠流暢，會破壞這一過程。

在敏捷測試中，當我們沒有清晰的可參照文檔、沒有機會創建測試，我們自然會采用探索式測試。在James A.Whittaker 的《探索式軟件測試》出版之后，探索式測試再次被推向高潮，人們覺得有更多成熟的探索方法可以使用，例如：賣點測試法、破壞測試法、地標測試法、收藏家測試法、極限測試法、超模測試法、深巷測試法、配角測試法、強迫癥測試法、取消測試法、通宵測試法、混票測試法。

但探索式測試缺乏良好的系統性、復用性，而且有些探索執行最終被證明是沒有價值的。而我們關注有價值的探索式測試，將它們記錄下來，使之成為固定的測試用例，用于將來的（后繼的迭代周期）回歸測試。回歸測試驗證已有功能是否正常運行，需要良好的系統性和很高的覆蓋率，確保發布產品的質量，而且回歸測試是不斷重復的，在極有限的時間內完成越來越多的測試任務，這需要自動化執行、高效率執行回歸測試。而這一切，依賴于相對穩定的測試用例。概括起來，敏捷測試可以看成：新功能的（手動）探索式測試 + 腳本化（基于測試用例的）自動回歸測試。

敏捷測試的自動化

沒有自動化，就沒有持續集成，也就沒有敏捷。在敏捷測試中自動化測試就更加迫切，這一點比較容易理解，每個迭代（如Scrum中的Sprint）都在增加新的功能，而迭代周期的時間相對固定，隨著時間的推移，已實現的功能越來越多，這就要求越來越多的回歸測試在時間相對固定的周期內完成。如果沒有自動化測試，這是不可能完成的任務。

在過去一年中，敏捷測試的自動化又發生了哪些變化？如何重構自動化測試腳本以提高產出投入比（ROI）？下面就簡單討論一下敏捷自動化測試框架和敏捷測試工具等內容。

敏捷測試對測試工具要求簡單、實用，隨時可用，而對敏捷測試來說，自動化測試框架更為重要，它將負責集成各種測試工具，包括單元測試工具和驗收測試工具等，還負責與持續集成、缺陷管理系統等整個開發環境集成。作為敏捷測試的自動化框架，一般會選擇輕量型、開放類型的框架。說到這種類型的框架，可以參考RobotFramework（http://code.google.com/p/robotframework/）。在最近一年，其版本發布比較頻繁，也日漸成熟。RobotFramework是基于Python開發的、可擴展的框架，所以適用于多種接口的復雜軟件（如用戶接口、命令行、Web Service、編程接口等）的測試。適合敏捷測試的框架還有Thoughtworks Mingle + Cruise + Twist，它能幫助測試人員和開發人員敏捷項目管理和協同工作、持續集成、測試自動化，允許使用BDD開發模式和Groovy動態語言來編寫測試腳本，包括手動和自動方式來創建可復用的自動化測試腳本，并結合測試領域特定語言（DSL）實現自動化測試。無論是RobotFramework，還是Twist，它們都支持Selenium 2.0，這也反映了Selenium在敏捷自動化測試中的重要地位。當然，敏捷測試也可以采用類似Selenium 2.0+ WebDriver +PushtoTest那樣的組合框架。

敏捷測試工具很多，但對敏捷測試來說，我們更要關注能夠適應ATDD或BDD的測試工具，如Cucumber、RSpec、NBehave /CBehave /JBehave、EasyB、JDave等。也可以結合先前熟悉的測試工具開展工作，例如用自己熟悉的WatiN來結合SpecFlow 完成BDD模式的自動化測試。采用傳統的微軟Visual Studio也是可以的，因為在其 2010版本中，增強了對敏捷測試的支持，包括：

• 發布了Scrum流程模板Visual Studio Scrum 1.0；

• 支持“測試優先”的開發，支持ATDD；

• TDD的插件TestDriven.NET。

敏捷測試管理

基于敏捷測試的管理，更多體現了基于需求測試和基于風險測試的平衡。對于新功能測試，不僅采用探索式測試，還要考慮基于需求的測試方法，借助類似BenderRBT這樣的工具，進行需求的因果分析，建立其判定表并進行優化，從而建立非常高效的測試用例，使敏捷測試跟上開發的節奏成為可能。但整個測試周期，包括跨迭代周期的回歸測試，都需要對測試風險進行有效的評估，在效率和質量上達到平衡，以保證所發布的產品的質量。

敏捷測試的管理，一定不要急躁、不要急于求成，要循序漸進獲得改進，特別是從相對傳統的測試方法轉型到敏捷測試的團隊來說，更要逐漸轉型，如同敏捷方法本身所追求的“小步快跑”式迭代，這種轉型本身也應被視為迭代過程，而不是突然某個早上，一切都變了。在敏捷測試管理中，不要試圖通過一個迭代解決所碰到的各種問題，而是一個迭代只解決一兩個問題，隨著時間的推移，踏踏實實地、逐步地解決各個問題，即進入一個良性的循環，最終解決各種問題，使團隊轉型成功，無論在測試效率和質量上獲得質的飛躍。

在敏捷測試管理中，盡管有比較多的原則要支持，例如“以人為本、為客戶創造價值、面對面的溝通、簡單化、響應變化和享受樂趣”等，但最重要的是以下幾個方面。

• 持續的質量反饋：在整個開發過程中，持續關注質量，關注用戶需求，發現任何階段性成果的問題，持續向產品經理、開發人員等提供質量反饋。

• 持續改進測試方法，不斷學習新方法和提高測試技術能力，不僅和開發人員保持技術同步，而且團隊成員能力保持同步成長，想方設法把工作做到極致。

• 讓團隊具有很高的自我組織能力，每個成員都積極主動工作，自己能夠解決自己的問題。

讓我們享受敏捷測試的樂趣，享受成功！

來自: http://www.programmer.com.cn/8040/