敏捷測試過程中的自動化目前在國內來看基本上還只是停留在概念階段，據我所知，目前不少公司也都在嘗試過程中，而實際的實踐中能取得比較理想成果的，極為有限。而國外不少同仁也都對此持觀望甚至抵觸的態度。比如advanced QTP論壇的administrator Meir大大 就認為敏捷過程中的自動化是完全不現實的，理由就是sprint間隔時間內沒辦法完成一個完整自動化過程的設計，而頻繁的變更會導致自動化資源的大量浪費，ROI上無任何前景可言。

　　從我個人觀點來看，沒必要保持如此的悲觀，但更不能過於樂觀。敏捷過程是IT發展的產物，自動化從概念上來看是確認一個sprint成功的重要一關。敏捷過程需要有自動化測試，但卻不能盲目讓自動化介入，否則很可能適得其反。

　　個人略作了下小結，由於敏捷模式的種種特色，敏捷過程中的自動化實現所需要滿足的條件比常規的自動化測試活動茍刻的多，除了普通自動化過程必須具備的條件之外，主要還有以下幾點：

　　1、對於自動化工程師的要求更高，除了解決種種突發異常的自動化技能以外，還需要對項目的業務知識有比較多的了解。

　　在敏捷模式中，文檔不會像傳統的模式中那樣完備，測試的case可能會相對簡易，不少內容都只是口口相傳，敏捷團隊的成員也不可能專門派一個人出來輔助自動化工程師解決業務問題，那麽就要求自動化工程師對於業務知識比較了解了，就算對項目了解有限，但至少要有背景知識，大多數情況下能理解一句話中所包含甚至是隱含的一系列業務操作。

　　2、項目成員結構上，自動化工程師需要成為敏捷團隊的一員，而不是編外人士。理由很簡單，敏捷團隊經常會召開類似頭腦風暴的會議，一個短暫而激烈的會議足以決定一個變更，然後大家立馬投入工作中。這時自動化工程師若作為編外人士，那很可能就得不到這第一手的消息了，很可能吭哧吭哧好不容易碼完的腳本還沒跑過就得改了。

　　3、對於項目、產品的要求。被測系統必須是非常適合自動化的，在自動化腳本開發過程中不應當遇到被某個技術實現難倒的問題，敏捷模式下是沒可能有幾天甚至一周的時間去處理某個自動化的技術細節的。這就需要在接受項目前做自動化可行性評估的時候考慮周全，是否有某些核心的功能無法被自動化，可以接受多少功能不被自動化。

　　另外各story間不能有太強的依賴，因為很可能自動化工程師無法完成對所有功能的自動化，而一個story的需求變更也不應導致其它story有太多變化。

　　4、對於BA的要求。BA需要對產品的主要功能非常了解，非常清楚哪些功能是不太會變更，而哪些部分是不太有把握的，同時對客戶也要有一定的掌控能力。這樣除了提供主要的測試點以外，還能結合變更來給同為最高級別的測試點附加上自動化優先級，在很大的程度上避免自動化工程師的重復勞動。

　　總的來說，要實施自動化，對團隊的成員素質要求非常高，也要求成員間的配合比較默契。說實話，真的很難，但並不是不可實現。

會員 maguschen：

　　這個問題有點大，我現在所處的公司也是應用了敏捷開發，下面分享一下我們公司做自動化測試的一些經驗

　　首先，敏捷開發並不是部分同學想象中的那樣，沒有文檔沒有需求，開發來了就幹，幹幾個月就丟給客戶一個版本讓他們用去，我們公司一般6個星期是一個release周期，在這6個星期裏面，可以做的事情是非常多的

　　1、需求，需求通常來自於PM，在一個release周期的開始，QA通常沒太多事情需要做，比較重要的工作就是跟PM溝通當前feature的一些情況，在這個時候，QA可以做一些自動化測試的準備。例如在某個release裏面我知道在接下來的測試當中我需要頻繁地比較CSV文件，那麽作為QA就應該在項目還不是很緊張的時候就開支準備自動化測試的腳本，例如剛才說的這個CSV文件比較工作

　　2、開始開發，如果公司是實時TDD開發，那麽這個時候QA可以做的事情大概有2個，幫助開發寫單元測試用例，並且實施自動化測試（主要是單元測試），另一個是review（雖然不是自動化測試的內容）

　　3、正式提交測試，OK，這個時候是我們QA比較忙的時候了，這時候很有可能出現幾個情況，1. 跟我的預想一樣，我真的需要一個CSV文件比較工作，並且只需要這一個工具，並且我已經完成了，那麽就可以進行測試了。2. 可能有一些新的自動化測試需求跑出來了，例如每天晚上自動比較幾萬個CSV文件並且把測試結果發給相關的人，這時候作為QA，在考慮資源允許的情況下，應該盡早完成這個工具，而不是每天晚上爬起來看結果並非法郵件

　　4、發布完畢以後，回過頭來看工具，是否有值得改進的地方，是否能夠改進一下就能夠給整個Team使用

　　以上算是一個release周期裏面的一些微觀的工作，宏觀上來說需要做點什麽事情呢？

　　現在提到的敏捷開發，都有一個很突出的特點，就是產品快速交付給客戶，為了快速交付這個目的，公司裏面每個團隊都作出了努力，那麽具體到QA團隊，肯定就是要在保持測試質量得到保證的前提下，盡可能地縮減測試所需要的時間，使得產品按時按質交付。要達到這個目的，總靠一些AD-HOC的工作（例如剛才提到的突然寫個CSV比較工具）是不可能達到要求的，那應該如何進行呢？

　　敏捷開發也是開發，產品不是孫悟空，不會某一天就從石頭裏面爆出來了。在產品開發的前期（例如0.1, 0.2版本之類），盡可能地想辦法搭建一個自動化回歸測試的框架，這個框架的特點有：1. 快速完成回歸測試； 2.能夠快速地添加測試用例並且跑起來；3.能夠隨著產品的演化而不斷改進（不能是那種用1~2個release就要扔的東西）；4.維護的成本要低（在一個release周期裏面如果自動化測試需求有變化，不應該需要超過1個星期的時間才能改好，當然翻天覆地的變化除外）

　　綜上所述， 我認為在敏捷開發裏面的自動化測試是有2條路線，並且這2條路是並行的，缺一不可

　　1、至少一個自動化回歸測試框架，保證release前能夠對產品進行覆蓋較為全面的回歸測試

　　2、工作中*不斷地*開發自動化測試工具，提高自己的生產率

　　以上兩點的目的很簡單，就是要在保持產品質量處於一個較高水平的情況下，幫助公司盡可能地快速交付新版本的產品。

敏捷開發模式下的自動化測試研究