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


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

 

　　TDD 向ATDD、BDD轉(zhuǎn)化?

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



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

 

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

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


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


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

　　TDD更重要的價值是其思想，像傳統(tǒng)的制造業(yè)，一定是先知道產(chǎn)品的質(zhì)量標準或驗收標準之后，才去設(shè)計、制造。從這個思想來看，TDD、ATDD和BDD都是一樣的。不一樣的是其具體的操作方法或?qū)嵺`，我們可以說，ATDD和BDD有一定的進步，但還沒有到達完美的地步，還有提升的空間。在未來，首先是如何靈活結(jié)合BDD、ATDD和TDD來構(gòu)成一個測試體系，是一個發(fā)展方向;其次，是在BDD、ATDD和TDD根本的、共同的思想基礎(chǔ)上，構(gòu)成一個全新的、更完善的敏捷測試框架。后者的可能性更大。

　　探索式測試的地位

 

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

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