究竟什么是敏捷測試

　　時至今日，還討論這樣一個老話題，是否感覺老調重彈?因為兩年前(2010年底)時任谷歌中國測試經理的段念先生就寫了一篇文章《什么是敏捷軟件測試》(刊登在InfoQ網站上[1])， 就已經談到這個話題，“敏捷軟件測試更多的是一種理念，而非過程”。在2011年，我自己也寫了一篇文章《敏捷測試的思考和新發展》，刊登在《程序員》雜志上，談到“在BDD、ATDD和TDD最根本的、共同的思想基礎上，構成一個全新的、更完善的敏捷測試框架”[2]。而更早的時候(2010年10月)，寫了一篇《敏捷測試的方法和實踐》(也刊登在《程序員》雜志上)，開始的那一小節就在討論 “什么是敏捷測試”，簡單地說，“敏捷測試就是持續地對軟件質量問題進行及時地反饋”[3]。不過，篇幅不多、匆匆而過，說得還不夠明朗。如果再往前，早在2009年，Lisa Crispin和Janet Gergory就寫了一本書《Agile Testing: A practical Guide for testers and Agile Teams》, 國內在2010年出了它的中文版本[4]，在第1章就論述了敏捷測試的定義，側重從測試的敏捷形式和“敏捷測試”的實踐等來彰顯敏捷測試，對敏捷測試和傳統測試的區別進行了分析(雖然作者把傳統測試局限于瀑布模型，這顯然是不對的)，讓我們看到一些敏捷測試的特點，如圖1所示。但作者也承認“敏捷測試對不同的人意味著不同的含義”。

　　圖1 傳統測試與敏捷測試 [4]

　　這樣看來，“敏捷測試(Agile Testing)”就不是一個新概念了，但為什么不少人還是不理解什么敏捷測試呢?現在偶爾還看到一些文章或微博帖子還在討論什么是敏捷測試，但似乎云里霧里、不知所云，感覺“敏捷測試”在許多人的心目中還是比較模糊。估計是以前的文章，包括我的文章，沒有把“敏捷測試”說透，所以有了再寫一篇文章的想法，盡量一次把“敏捷測試”這個內涵給大家說清楚。以后，有機會再討論傳統測試團隊如何轉型、敏捷文化下測試團隊如何建設等。

　　首先，可以明確的是，敏捷測試既不是一種方法(如黑盒方法、白盒方法等)，也不是一種方式(如探索式測試)。因為在敏捷測試中可以采用已有的各種方法，包括白盒方法、黑盒方法;在敏捷中也可以采用探索式測試(exploratory test)，也可以采用基于腳本的測試(scripted test)。那敏捷測試是什么?敏捷測試應該是一套解決方案、一類測試操作與管理的框架、一組實踐或由一定順序的測試活動構成的特定的測試流程。就像Scrum一樣，Scrum可以理解為敏捷方法的具體實現的框架、一組實踐或具體的解決方案。簡單地說，敏捷測試就是順應敏捷開發方法、力求達到質量和效率平衡的一系列的測試實踐。讓我們看看Wikipedia 是如何描述敏捷測試的：

　　Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.

　　它強調敏捷測試是遵守敏捷開發方法原則之下的軟件測試實踐，由跨功能敏捷團隊的所有人員參與(包括測試人員以其專業特長的特殊貢獻)以保證持續的、快速的業務價值交付。所以要理解敏捷測試，我們還是要回過頭來仔細看一下“敏捷宣言”背后所蘊含的12條原則。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先認真閱讀以下完整的敏捷宣言，不僅僅是那四句話。

　　1. 方法論上的敏捷測試

　　先從敏捷開發這一方法論層次來討論什么是敏捷測試，即敏捷測試有什么具體特征，或有哪些主要實踐，然后再就目前非常熱的敏捷具體框架Scrum來討論Scrum中的敏捷測試(或稱為Scrum Testing)。先研究一下敏捷宣言背后所蘊含的12條原則[5]：

　　1) 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

　　2) 欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

　　3) 經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。

　　4) 業務人員和開發人員必須相互合作，項目中的每一天都不例外。

　　5) 激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

　　6) 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

　　7) 可工作的軟件是進度的首要度量標準。

　　8) 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

　　9) 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

　　10) 以簡潔為本，它是極力減少不必要工作量的藝術。

　　11) 最好的架構、需求和設計出自自組織團隊。

　　12) 團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

　　這12條原則中沒有一條直接談到測試，那是否說明沒有敏捷測試呢?有開發就有測試，只是原來參加敏捷宣言的17人，基本是清一色程序員，沒有在原則中單獨闡述一下測試的原則。但其中一些原則和測試的關聯性很強，例如：

　　1) 軟件測試如何支撐或協助“持續不斷地及早交付有價值的軟件”?如何在非常有限的時間內進行充分的測試?這就是我們經常在敏捷測試中強調的“自動化測試”，如果沒有自動化測試，就沒有敏捷，就不能持續不斷地及早交付有價值的軟件，而且還要“使客戶滿意”。

　　2) “欣然面對需求變化，即使在開發后期也一樣”和傳統的開發原則是不同的，傳統的開發希望有嚴格的需求變更控制，越到后期控制越嚴。而敏捷開發擁抱變化，那么測試如何適應這種變化?如何快速地完成回歸測試?這可能要依賴于開發做好單元測試，或全員參與測試，以及全面支持系統級的、端到端的回歸測試的自動化測試執行。

原文轉自：http://blog.csdn.net/kerryzhu/article/details/8812589