敏捷測試介紹
有一次，當開發人員完成當前sprint 任務的**之後，測試人員、開發人員和產品經理一起來瀏覽產品、從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成**，但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多、開發**質量不高，驗收測試已經很緊張。如果再延遲兩天，測試沒法完成。產品經理說，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊！
什麼是敏捷測試呢？敏捷測試當然不能簡單地理解為測得更快，絕對不是比以前用更少時間進行測試，也不是將測試的範圍縮小了或將質量降低來減少測試任務。也有人說，只有敏捷開發，沒有敏捷測試。下面我們將要討論一下：
什麼是敏捷測試
假如將過去傳統的測試流程和方法硬塞入敏捷開發流程中，測試工作可能會事倍功半，測試人員可能會天天加班，而不能發揮應有的作用。敏捷測試應該是適應敏捷方法而採用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有不同的側重，例如減少測試計畫、測試用例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴於自動化測試。由於敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟體產品質量進行反饋。簡單地說，敏捷測試就是持續地對軟體質量問題進行及時地反饋，如圖1所示。
圖1 敏捷測試定義的形象描述
敏捷測試流程的優化
在敏捷方法中，需求變化比較快、產品開發周期很短，我們目前採用四周時間，也就是每個月發布乙個新版本。開發周期短，功能不斷累加，給軟體測試帶來很大的挑戰，軟體測試流程要做相應的調整。例如，我們原有的測試規範明確規定，首先要建立專案的主測試計畫書，然後再建立每個功能任務的測試計畫書，測試計畫書有嚴格的模板，而且需要和產品經理、開發人員討論，並和測試團隊其他人員（包括測試經理）討論，最終得到大家的認可和簽字才能通過，僅測試計畫經過「起草、評審和簽發」乙個完整的週期就需要乙個月。在敏捷方法中，不再要求寫幾十頁的測試計畫書，而是在每個迭代週期，寫出一頁紙的測試計畫，將測試要點（包括策略、特定方法、重點範圍等）列出來就可以了。
use case或user story直接進行驗證，並進行探索性測試。而節約出來的時間，用於開發原有功能的自動化測試指令碼，為回歸測試服務。自動化測試指令碼將代替測試用例，成為軟體組織的財富。原有測試規範還要求進行兩輪回歸測試，在敏捷測試中，只能進行一輪回歸測試。綜合這些考慮，敏捷測試的流程簡單有效，如圖2所示。
圖2 敏捷測試流程簡要圖
在敏捷測試流程中，如前所述，測試是乙個持續的質量反饋過程，測試中發現的問題要及時反饋給產品經理和開發人員，而且某些關鍵方面也要得到我們足夠的關注，主要有：
參與**複審（code review），並適當輔助開發人員進行單元測試。
在流程中增加乙個環節「產品走查（product walk-through）」demo——測試人員和產品經理、開發人員等在一起，從頭到尾將新功能看一遍，可直觀、快速地發現問題。
新功能的測試和回歸測試策略
測試任務簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應的策略，以提高測試的效率，最大限度地降低質量風險。新功能測試的策略主要有：
回歸測試是敏捷測試中需要面對的難點。每次迭代都會增加新的功能，乙個產品可能會經過十幾次、甚至幾十次迭代，回歸測試範圍在不斷增大，而每次迭代週期沒變，可能還是乙個月。這樣驗收測試的時間非常有限，所以回歸測試很大程度上依賴於自動化測試，因為很難將回歸測試控制在非常有限的範圍內。當然，還是有些辦法可以幫助我們減少回歸測試的範圍，例如：
自動化測試策略
由於開發周期短，需求、設計等方面溝通也需要花費很多時間，沒有足夠時間開發自動化測試指令碼，至少對新功能的測試很難實現自動化測試。這時候，就需要正確的策略來提高自動化測試的效益，如圖3所示，並說明如下。
圖3 自動化測試的策略
敏捷測試工具
自動化測試依賴於測試工具，所幸的是，目前已有很多敏捷測試工具。由於篇幅所限，這裡只是簡單地列出一些常用的敏捷測試工具，不再深入討論了。
測試人員在敏捷方法中的價值
在敏捷方法中，開發人員的主導作用更明顯，系統設計、程式設計實現、單元測試、重構等看似關鍵的一些任務都落在開發人員身上，測試人員容易被邊緣化。那麼，在敏捷方法中，測試人員的價值又如何體現呢？
理想情況下，測試人員掌握設計模式、具有很好的程式設計能力，可以和開發人員進行角色互換，如在當前版本開發中擔任測試人員角色，在下乙個版本開發中則擔任開發人員角色。這樣雙方對不同角色的工作有著更深刻的認識，消除溝通的障礙，開發的效率和質量會有進一步的提高。
總結
根據上面的討論和我們的實踐，最後針對敏捷測試進行乙個簡單的總結，就是：
敏捷測試的定義
l 強調從客戶的角度，即使用系統的使用者的角度，來測試系統
l 重點關注持續迭代的測試新開發的功能，而不再強調傳統測試過程中嚴格的測試階段。
l 建議盡早開始測試，一旦系統某個層面可測，比如提供了模組功能，就要開始模組層面的單元測試，同時隨著測試深入，持續進行回歸測試保證之前測試過內容的正確性
敏捷 測試先行方法介紹
是的，現在肯定有讀者會這樣說了 我只在產品髮品之前寫測試。有些人可能會竊笑，對質量保證部門說三道四。還有一些人作為專案經理可能會添油加醋地說 我們可不會浪費時間寫測試 我們還得寫真正的 呢。那麼，採用tdd到底是什麼意思呢？tdd產生於敏捷開發運動，特別是極限程式設計 extreme program...
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...
敏捷開發介紹
敏捷開發 在敏捷開發興起前，人們普遍使用瀑布開發模型。瀑布開發主要流程是 需求分析 設計 編碼 測試和維護。瀑布開發對需求文件的依賴性很強，開發時間長，對變化和變更的響應難度大。導致產品投入市場太慢，員工士氣 動力和責任感不強，投資回報率低，常失敗。敏捷開發模型是瀑布開發模型後出現的一種迭代增量式的...