有一次，當開發人員完成當前sprint 任務的**之後，測試人員、開發人員和產品經理一起來瀏覽產品、從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成**，但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多、開發**質量不高，驗收測試已經很緊張。如果再延遲兩天，測試沒法完成。產品經理說，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊！
什麼是敏捷測試呢？敏捷測試當然不能簡單地理解為測得更快，絕對不是比以前用更少時間進行測試，也不是將測試的範圍縮小了或將質量降低來減少測試任務。也有人說，只有敏捷開發，沒有敏捷測試。下面我們將要討論一下：
什麼是敏捷測試
假如將過去傳統的測試流程和方法硬塞入敏捷開發流程中，測試工作可能會事倍功半，測試人員可能會天天加班，而不能發揮應有的作用。敏捷測試應該是適應敏捷方法而採用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有不同的側重，例如減少測試計畫、測試用例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴於自動化測試。由於敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟體產品質量進行反饋。簡單地說，敏捷測試就是持續地對軟體質量問題進行及時地反饋，如圖1所示。
圖1 敏捷測試定義的形象描述
敏捷測試流程的優化
在敏捷方法中，需求變化比較快、產品開發周期很短，我們目前採用四周時間，也就是每個月發布乙個新版本。開發周期短，功能不斷累加，給軟體測試帶來很大的挑戰，軟體測試流程要做相應的調整。例如，我們原有的測試規範明確規定，首先要建立專案的主測試計畫書，然後再建立每個功能任務的測試計畫書，測試計畫書有嚴格的模板，而且需要和產品經理、開發人員討論，並和測試團隊其他人員（包括測試經理）討論，最終得到大家的認可和簽字才能通過，僅測試計畫經過「起草、評審和簽發」乙個完整的週期就需要乙個月。在敏捷方法中，不再要求寫幾十頁的測試計畫書，而是在每個迭代週期，寫出一頁紙的測試計畫，將測試要點（包括策略、特定方法、重點範圍等）列出來就可以了。
圖2 敏捷測試流程簡要圖
在敏捷測試流程中，如前所述，測試是乙個持續的質量反饋過程，測試中發現的問題要及時反饋給產品經理和開發人員，而且某些關鍵方面也要得到我們足夠的關注，主要有：
參與**複審（code review），並適當輔助開發人員進行單元測試。
在流程中增加乙個環節「產品走查（product walk-through）」——測試人員和產品經理、開發人員等在一起，從頭到尾將新功能看一遍，可直觀、快速地發現問題。
新功能的測試和回歸測試策略
測試任務簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應的策略，以提高測試的效率，最大限度地降低質量風險。新功能測試的策略主要有：
回歸測試是敏捷測試中需要面對的難點。每次迭代都會增加新的功能，乙個產品可能會經過十幾次、甚至幾十次迭代，回歸測試範圍在不斷增大，而每次迭代週期沒變，可能還是乙個月。這樣驗收測試的時間非常有限，所以回歸測試很大程度上依賴於自動化測試，因為很難將回歸測試控制在非常有限的範圍內。當然，還是有些辦法可以幫助我們減少回歸測試的範圍，例如：
自動化測試策略
由於開發周期短，需求、設計等方面溝通也需要花費很多時間，沒有足夠時間開發自動化測試指令碼，至少對新功能的測試很難實現自動化測試。這時候，就需要正確的策略來提高自動化測試的效益，如圖3所示，並說明如下。
圖3 自動化測試的策略
敏捷測試工具
自動化測試依賴於測試工具，所幸的是，目前已有很多敏捷測試工具。由於篇幅所限，這裡只是簡單地列出一些常用的敏捷測試工具，不再深入討論了。
測試人員在敏捷方法中的價值
在敏捷方法中，開發人員的主導作用更明顯，系統設計、程式設計實現、單元測試、重構等看似關鍵的一些任務都落在開發人員身上，測試人員容易被邊緣化。那麼，在敏捷方法中，測試人員的價值又如何體現呢？
理想情況下，測試人員掌握設計模式、具有很好的程式設計能力，可以和開發人員進行角色互換，如在當前版本開發中擔任測試人員角色，在下乙個版本開發中則擔任開發人員角色。這樣雙方對不同角色的工作有著更深刻的認識，消除溝通的障礙，開發的效率和質量會有進一步的提高。
總結
根據上面的討論和我們的實踐，最後針對敏捷測試進行乙個簡單的總結，就是：
敏捷測試的方法和實踐
有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗收測...
敏捷測試的方法和實踐 上
有一次，當開發人員完成當前 sprint 任務的 之後，測試人員與開發人員 產品經理一起來瀏覽產品 從頭到尾走一邊，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有 5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗...
敏捷測試的最佳實踐 一敏捷的實質
本文講述了作者在兩年的敏捷測試和開發工作有個非常有意思的遊戲能夠幫助大家理解敏捷和傳統開發的差異。遊戲有兩個角色，乙個是 老闆 另乙個是 員工 在 2 分鐘內，員工 需要在 老闆 的完全指揮下，即 向前一步，向後一步，停，向左一步，向右一步 完成 60 步移動的任務。員工 需要執行 老闆 的每乙個指...