敏捷開發模式下如何更好的進行測試

最近CTO組建了一個敏捷開發團隊，團隊人員包括  PM、設計、開發、測試角色，主要由PM來主導團隊走向，因為以前並沒有參加過敏捷開發的經驗，對敏捷開發做了簡單理解后，參考了前人的一些意見，總結出在

敏捷開發模式下如何更好的進行測試

 

首先：意識的轉變：

意識需要從發現Bug轉變為預防Bug出現，

從越多發現Bug轉變為越早發現Bug

測試人員應該及時跟上開發和需求人員的腳步，及時地更新測試用例，並提醒大家需求的變更是不是超過了限度，該控制控制了

 

測試前期：1.全程參與需求討論，最早在需求討論階段，幫助需求和開發對需求有正確和共同的認識，例如 主導更多的用戶場景、異常等討論

　　　　　2.測試的用例同樣有優先級,針對性編寫用例（重點）

　　　　　3.對每個迭代所要達到的目標爛熟於心， 說測試是貫徹開發始終的

 

　

 

測試中: 1.與開發溝通上又直接交流、靈活應對變化，質量控制，什么bug是重要的，什么是可以后期去做，分清bug優先級

             2.引入能幫助測試更簡便的測試工具和方法，如自動化測試，可以幫助測試人員有更多的時間去探索性測試

 

測試產出：測試用例、測試報告

 

scrum

測試團隊的主要職責是盡早給出質量反饋，做到風險前移：
1) 最早在需求討論階段，幫助需求和開發對需求有正確和共同的認識，例如 主導更多的用戶場景、異常等討論
2) 用於測試的用例同樣有優先級， 最高的優先級是“用戶使用最多”以及“最容易發生bug”的場景交集
3) 縮短測試時間，更 多使用自動化，例如Cucumber、Fitness、Selenium等的使用
4) 測試工作的過程和結果可視化(最后有產出結果)，方便團隊內的溝通
另外，測試團隊需要有一線工作的意識：測試人員需要參加計划、估算、執行、回顧等與產品交付相關的任何環節

 

 

 

下面是百度、知乎下的各前輩的知識，十分感謝各位大神的經驗。

敏捷開發、測試相關鏈接（全英文。。。。）：http://www.methodsandtools.com/archive/archive.php?id=88、http://www.ambysoft.com/essays/agileTesting.html

知乎相關鏈接：https://www.zhihu.com/question/19624692

目的一定要清晰：

測試人員也需要對每個迭代所要達到的目標爛熟於心， 說測試是貫徹開發始終的

 

 

敏捷測試關鍵成功要素

1.使用團隊整體參與的方法

2.采用敏捷測試思維（直接交流、靈活應對變化、鼓勵嘗試新技術方法嘗試最簡單的方法來滿足測試需要。）

3.自動化回歸測試（自動化冒煙測試、自動化單元測試）

4.提供並獲取反饋。

5.構建核心實踐的基礎（持續集成、測試環境、管理技術債務、增量工作、編碼和測試同一過程）

6.與客戶合作

7.保持大局觀

敏捷過程中，測試的主要職責應該是對每次迭代的產出物做驗證，確保產出物滿足產品設計需求，質量合格。

 

1. .需求的把握。測試要對不斷變化的需求都能把握住，以PO（product ower）的標准來要求自己，敏捷的要旨是小步快跑，保證每一步都是對的，這樣在團隊中就需要有人來保證我們做出來的東西是沒有偏離需求的，這個角色只有測試勝任；

 

2.團隊節奏的控制。不知道大家有沒有做過敏捷項目，迭代不斷的出現延遲，問題單越來越多，大家疲於根據計划加班。這個時候我們可不可以把下個迭代要做的事情暫時先停下來，留一個迭代或者半個迭代來解決問題，重新讀下代碼，找出那些異味的代碼（smelly code）重寫一下。找找我們流程中的問題並改進。這個事情也是由測試人員來提出比較合適；

3.質量控制。

這當然是測試的傳統的工作，找出問題，讓開發人員來解決。對於一個tester來說，質量控制Quality Control比質量保證Quality Assurence更重要。在敏捷階段，不是說發現的所有問題都需要馬上讓開發人員去改，因為或許這個bug對應的需求還不明確，或許下輪的重構就能自動解決問題，或許當前這個迭代使用的技術解決這個問題代價太大... 總之，這里是比較靈活的，也是比較考驗測試人員的經驗的，什么問題應該馬上解決，什么問題可以討論。

 

 

4.測試盡可能去參與集成測試的，只是這個過程對測試來說比較痛苦，需要了解代碼，有一定的編碼能力。

 

5.測試產出

文檔，測試分析，問題單，測試需求分析等等。。。 這個也是和產品的形態有關，如果是輕量級的產品完全不需要做很多事情，或者很多事情可以合並來做，產出一份文檔或者結果就可以。

 

6.關於自動化測試

第一，在敏捷里面測試有一個 很重要的產出就是自動化測試， 有了自動化測試之后測試人員有更多的時間去做探索性的測試， 並且自動化測試能夠給予團隊一個很好的反饋， 你改動了代碼之后是否對系統有影響都能及時的反饋出來。 第二，測試團隊對需求的影響。 測試人員在設計測試用例時就會對用戶的場景和預期的行為有一個描述，就會出現一些產品人員考慮不到的情況，這樣便可以更加完善需求，提升產品的體驗和質量。

 

 

用例：用例一定要全

 

1，文檔要全，而且要保證質量，不過測試用例例外，看情況而來。

測試人員應該着眼於關鍵點，一個全面的測試用例也常常被證明40%以上的用例是徒勞的。根據經驗能夠判斷出哪里是潛在bug、缺陷和主要數據流關鍵點，針對這些地方寫測試用例，方便管理也能夠判斷數據流階段性的正確。還有就是TDD在開發過程中的保證，前期的需求討論，測試人員參與程度應比開發人員更高，而系統架構確定、軟件架構確定，都是由開發和測試共同決定，並在開發過程中出現需求變動，也保持軟件架構的相對穩定，因為 軟件架構的改動對於測試人員來講 不單單是改動，很可能是重新來過。

 

2，這個不管是不是敏捷的， 前期都盡量挖掘客戶的需求，不留下任何潛在的需求。開發過程中的需求變動，根據經驗來說，還沒有遇上過需求不變的。這個其實是很無奈的，這是由客戶方不夠專業引起的，這也確實沒有辦法，只能是期望變動不是翻天覆地的。

 

3，開發過程差不多，或者說一樣也可以，但敏捷方法對人員上的控制有一些建議，來使人員工作效率更高，交流成本更低。在這方面來講，敏捷對於人的 性格也有要求，不是每個人都適合參加敏捷開發，在搞人這方面上，敏捷只是提出了一些建議，最佳實踐還是得根據公司人員和公司內部結構的實際情況來定了。