[原文發(fā)表在https://hespr.blogspot.jp/2009/03/blog-post.html 寫在2009年3月
最近發(fā)現被人盜版了多處, 重新發(fā)布在CSDN]

最近讀了《我和敏捷團隊的五個約定》（from InfoQ），很是贊同，但是那些約定不少本來就來自于傳統(tǒng)方法，似乎并沒有體現敏捷團隊的特點。
在敏捷開發(fā)的測試方面有沒有不一樣于傳統(tǒng)開發(fā)測試的并且是有效的實踐？
從敏捷團隊的組建上來說，敏捷團隊并沒有要求安排專門的測試人員，甚至于在某些的方法中不建議清楚的區(qū)分開發(fā)人員角色和測試人員角色。 本文討論的是已經存在獨立測試團隊的情況，如何在敏捷開發(fā)中進行高效的測試。

實踐1：測試保護開發(fā)

通過快速的自動化測試跟進開發(fā)，保證新增和修改不破壞已經獲得的成果。
典型步驟如下：
1，開發(fā)人員根據需求，采用TDD，編寫代碼，實現界面和接口。
2，幾乎同步，測試人員編寫自動化測試，主要是黑盒自動化測試，也不排除白盒自動化測試。
3，一般保證，代碼出來后的第2天，相關的自動化測試代碼開發(fā)完成。

實踐2：成為大敏捷團隊的成員

子實踐1：參加相關會議，如果是SCRUM，參加SCRUM所有要求的會議。

子實踐2：可以閱讀和修改最大范圍的配置項（比如文檔，代碼，工作項）

子實踐3：一起工作，比如把位子搬到開發(fā)人員旁邊，如果同時參加多個項目，選擇一個較近距離的位子。

說明：這個實踐本身的宗旨與傳統(tǒng)做法并無根本區(qū)別，這里的區(qū)別在于程度。

實踐3：與定期構建一起執(zhí)行測試人員的自動化測試用例，或者定期構建包括測試人員的自動化測試。

這里用了”測試人員的自動化測試用例“，也有做法是測試人員和開發(fā)人員一起維護自動化測試用例，并沒有“測試人員的自動化測試用例“，這里主要說明無論測試人員貢獻的自動化測試用例處于何種形式，無論構建是否包括測試人員的自動化測試用例，就是要求自動化測試能與構建為基來執(zhí)行。

子實踐1：維護一套自動化測試環(huán)境，可以自動獲得最新的##測試用例和構建成果

子實踐2：測試結果可以自動發(fā)布到合適的地方，缺陷得到跟蹤管理

實踐4：設計更多黑盒手工場景化測試用例，安排更多隨機場景測試

關 注于局部功能的測試用例在敏捷開發(fā)中往往已經被自動化實現了。因此為了發(fā)布的測試中，值得設計更多黑盒手工場景化測試用例。選擇一些典型場景化測試用例開 發(fā)為自動化測試用例也是可以的，但是此類測試用例的自動化開發(fā)所需工作量較大，要看測試團隊的投入和質量目標安排，如果有象微軟一樣的測試開發(fā)工程師，就 另當別論了。一般而言，從經濟角度出發(fā)，黑盒手工場景化測試用例是發(fā)現潛在缺陷的有效且經濟的手段，如果存在豐富經驗的測試人員，隨機場景測試也是值得更 多采用的。本實踐在傳統(tǒng)測試中也有，這里要強調的特別之處是可以考慮手工測試全部用場景化測試，大幅減少針對單一功能或局部功能的測試用例。

對測試人員的要求

從以上實踐可以看到，測試人員所要掌握的技能有黑盒自動化測試、場景化測試，最好也要常握白盒自動化測試，定期構建和自動測試報告

工具支持

常見的有fit,fitnesse, white, watir, selenium, cruisecontrol, QTP, robot, xUnit系列，xFit系列等等

效果和校驗

上述的實踐是否有效、是否高效，可以觀察如下幾點：
1，達到發(fā)布條件所需的測試輪次是否減少？測試缺陷密度是否減少？
2，獲得快速發(fā)布的能力，發(fā)布工期偏差是否減小？
3，測試所需總的工作量是否在測試團隊承受的范圍之內，尤其關注測試后期的工作量是否大幅減少，減少的數量是否比在測試前期增加的數量要更大？

如果沒有獲得正面收益，就需反思了。

總結

以上是生活随笔為你收集整理的独立测试团队在敏捷开发中的几个特别实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。