敏捷測試過程中的自動化目前在國內來看基本上還只是停留在概念階段，據我所知，目前不少公司也都在嘗試過程中，而實際的實踐中能取得比較理想成果的，極為有限。而國外不少同仁也都對此持觀望甚至牴觸的態度。比如advancedqtp論壇的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、工作中*不斷地*開發自動化測試工具，提高自己的生產率
以上兩點的目的很簡單，就是要在保持產品質量處於乙個較高水平的情況下，幫助公司盡可能地快速交付新版本的產品。
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 IV
後記 在做了一段時間的推廣自動化測試的工作，情不自禁地想把自己的眼光放得更遠一些，究其原因，我很清楚地認識到，測試的最終目的是還是為了提高軟體的質量，而無論是自動化測試，還是continous integration，都還是是軟體的外部看問題。但軟體為什麼一直有解決不完的bug，如果不對軟體的內部有...
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 II
我先是自己來除錯原來一直跑不起來的case，發現之所以前面的case失敗了，會影響後面的case，其實是由於case之間的獨立性不好引起的。為了能解決這個問題，我還和team一起設計了乙個複雜的環境恢復的keyword，裡面判斷了不同情況下，如果有板子沒有起來，應該怎麼恢復的問題。用了這個方法，ca...
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 I
在中國的軟體行業，如果工作時間稍微長一點的話，應該都是從瀑布開發模式成長起來的，包括現在，很多公司其實還是採用瀑布開發的模式。當然，敏捷轉型也是軟體行業乙個很熱的topic。作為乙個在傳統的軟體測試行業工作了8年多，在敏捷開發模式也工作了3年多的乙個測試行業的老兵，很想從測試自動化的角度看兩種開發模...