隨著這幾年敏捷概念和方法的流行，越來越多的組織和項目選擇了敏捷開發模式。那麼對於測試人員來說，究竟敏捷測試與傳統測試有什麼區別？測試人員在一個敏捷項目中需要如何轉變才能適應當前這種流行的測試模式呢？今天我們就來探討一下！
一、什麼是敏捷測試？
首先，究竟什麼是敏捷測試？在我個人看來，敏捷測試是一種注重"以人為本"，快速迭代的開發方式。因為人是一個項目中的關鍵所在，故以人為本；快速迭代，即我們進行短週期的開發，上線，反饋，優化，使得項目易於調整，故而敏捷。
二、敏捷測試在項目中的應用形式：
體現在三個方面：每日站會、極限編程、測試驅動開發。
每日站會：也就是每天早晨15分鐘到30分鐘的會議時間，最多不超過45分鐘，會議形式是項目組中的成員佔到白板前逐個介紹昨天完成的事項，遇到的問題，或好的方法分享，今天計劃完成的工作內容等；
對於存在的問題，項目成員可以提出自己的好的見解幫助同事；白板上會寫上需求池、開發就緒、開發中的SR、已完成SR、測試就緒、測試中的SR、測試完成的SR、驗收就緒、驗收中的SR、驗收完成的SR；
每個SR會寫上story的內容，開發人員，計劃開始時間，計劃結束時間，實際開始、結束時間、完成該SR用了多少時間，計劃用多長時間等；通過分析白板上story的進度情況，看項目是否存在進度延遲的情況，若存在，項目經理提出疑問，分析原因，找出改進方法。
極限編程（Extreme Programming，XP）是一種可以使開發人員快速生產高質量代碼的軟件開發過程。XP中開發人員可以結對編程，提高代碼的質量。
測試驅動開發，敏捷測試中每個story都有計劃開始和結束的時間點，開發人員對自己負責的story進行分析設計的時候，測試人員需要對story進行分析設計測試用例，在開發提交測試人員測試story的時候，開發人員需要向測試人員show case，說明開發的story功能已經實現可以開始測試了；此時測試人員根據測試用例進行測試；如果到story需要提交給測試人員進行測試的時間點了開發人員還未完成story功能的開發，測試人員就要督促開發人員進行提交測試，延遲提交或存在分析的情況下，需要反饋給項目進行重新制定措施。
三、敏捷測試與傳統測試的區別
1.項目相當於開發與測試並行，項目整體時間較快。
2.模塊提交較快，測試時較有壓迫感。
3.工作任務劃分清晰，工作效率較高。
4.項目規劃要合理，不然測試時會出現複測的現象，加大工作量。
5.發現問題需跟緊，項目中人員都比較忙，問題很容易被遺忘。
6.耗時、或較難解決對項目影響不大的問題一般會遺留到下個階段解決。
7.發現BUG能夠很快的解決，對相關的模塊的測試影響比較小。
8.版本更換比較勤，影響到測試的速度。
9.要多與開發溝通。
10.要注意版本的更新情況。
11.測試人員幾乎要參加整個項目組的所有會議。
四、敏捷測試中的關鍵過程
在一個sprint中，測試人員的工作內容主要分為五個部分：user story分析、測試用例設計開發、測試執行和分析、測試持續集成、迴歸測試。這五個部分的工作均要持續到sprint結束，只是啟動時刻有早有晚，具體如下圖所示
user story分析工作：敏捷測試是不斷確認客戶的需求得以圓滿實現，因此對用戶需求的分析、理解需要一直持續下去，發現有偏差及時糾正，及時設置合理的驗收點、測試項。
Testcase Develop工作：設計測試用例，完成測試代碼的開發、測試數據的準備，並及時與開發人員溝通軟件接口，確保測試代碼能夠成功驅動業務代碼。
Testing & Analysing工作：執行測試，統計測試覆蓋率，分析測試結果，若發現bug，及時溝通，並協助定位bug。
Continuous Integration工作：將測試代碼進行集成，以保證當前功能若被後續集成代碼汙染是能夠及時得到報警，不斷地完善軟件產品的功能基線。
RegressionTesting工作：在完成全部user story後，對所有代碼進行完整的迴歸測試，對所有bug修復情況進行確認。
五、敏捷測試人員怎麼提高開發生產率呢？
在敏捷測試中，測試人員則是幫助加快進度的人，也就是提高生產率的人。
1、若缺陷發現越及時越容易修改
比如在1天內就能發現，則1天內發生的改動很少，很容易找到問題。這就需要一個自動測試工具來以接近實時地發現缺陷。
比如如果在每天能進行一次持續集成，則集成測試不能通過的原因會很單一很容易定位。設想一個數字電視系統，從授權/編碼/加密/複用/調製/發送/接收/分流/解密/顯示……環節很多信息很不透明，若在最後一刻才做集成，基本上無法判斷問題出在哪裡。
2、若發現缺陷的人就是製造缺陷的人，則越容易修改。
比如如果開發人員有自動測試工具能快速看看自己寫的程序有沒有問題，而不是交給測試人員發現，則更容易修改。想象一下編譯器就知道了，如果編譯活動都要委派給別人（最然現在很難想象，在軟件開發的極早期其實就是這樣的），效率會很低。
3、一個開發人員花費在查找和修改bug的時間越少，則開發效率越高。
另外一個推論是：在0缺陷的產品上增加一個功能，比缺陷纏身的產品上要容易得多。
因此1和2兩條的推論就是開發效率提高。
六、敏捷測試的人做什麼？
1. 不斷推進自動化測試的效率和效果。
2. 不斷推進持續集成的效率和效果。
3. 不斷提高開發人員開發功能而非處理缺陷的時間（即使缺陷是開發人員自己製造自己修改）。
當然有一個前提，就是每個軟件對待需求/進度/質量/成本的目標和策略是不同的，敏捷測試人員不能有本位主義，不能片面追求測試活動本身的效果，而是應該幫助開發團隊達成其目標和策略。
七、總結：
測試人員是敏捷團隊非常重要的一環，測試人員的成長對敏捷團隊非常重要。從傳統測試工作轉入敏捷測試工作必然會遇到很多不適，但是隻要堅持對敏捷的學習和各種新工具的開發使用，一切都能夠適應下來。
誰都知道，變化，才是永遠不變的，敏捷則是我們應對變化的武器。
閱讀更多 Atstudy網校 的文章
