敏捷測試VS傳統測試對比，6招玩轉敏捷測試！

隨著這幾年敏捷概念和方法的流行，越來越多的組織和專案選擇了敏捷開發模式。那麼對於測試人員來說，究竟敏捷測試與傳統測試有什麼區別？測試人員在一個敏捷專案中需要如何轉變才能適應當前這種流行的測試模式呢？今天我們就來探討一下！

一、什麼是敏捷測試？

首先，究竟什麼是敏捷測試？在我個人看來，敏捷測試是一種注重“以人為本”，快速迭代的開發方式。因為人是一個專案中的關鍵所在，故以人為本；快速迭代，即我們進行短週期的開發，上線，反饋，最佳化，使得專案易於調整，故而敏捷。

二、敏捷測試在專案中的應用形式：

體現在三個方面：每日站會、極限程式設計、測試驅動開發。

每日站會： 也就是每天早晨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. 不斷提高開發人員開發功能而非處理缺陷的時間（即使缺陷是開發人員自己製造自己修改）。

當然有一個前提，就是每個軟體對待需求/進度/質量/成本的目標和策略是不同的，敏捷測試人員不能有本位主義，不能片面追求測試活動本身的效果，而是應該幫助開發團隊達成其目標和策略。

七、總結：

測試人員是敏捷團隊非常重要的一環，測試人員的成長對敏捷團隊非常重要。從傳統測試工作轉入敏捷測試工作必然會遇到很多不適，但是隻要堅持對敏捷的學習和各種新工具的開發使用，一切都能夠適應下來。

誰都知道，變化，才是永遠不變的，敏捷則是我們應對變化的武器。