敏捷測試之我見

　　前兩天聽了公司一個關于敏捷開發的培訓，就在想是不是也有敏捷測試。盡管一個同事說根本沒有敏捷測試這個概念，但我仍不死心。Google了一下，這方面的文章確實有限，不過有就是對自己想法的一個最好肯定。

　　在我的理解對應敏捷開發的管理就是敏捷管理，同樣對應敏捷開發的測試即是敏捷測試。只是敏捷管理和敏捷測試同樣可以應用到非敏捷開發的項目中去。同樣敏捷管理和敏捷測試在敏捷開發中將會得到最大的體現，但能不能管理好和測試好就看你做的是不是真正的敏捷管理和敏捷測試，看你是不是真正的將敏捷的思想融入到管理與測試中去了。

　　敏捷開發強調的是敏捷設計，設計的靈活性、可擴展性和易維護性是敏捷設計的目標。而之所以要有這樣的目標就是為了適應多變化的需求，而敏捷開發中高度的迭代正是及早發現問題，及時修正并完善需求的有效方法。

　　那么敏捷測試的核心是什么呢，就是在設計階段之前充分學習該項目的行業知識，從最終用戶角度和實際出發充分的挖掘需求。在設計階段要完成對敏捷設計的靈活性、可擴展性和易維護性的檢查，這個工作最好由公司內部的其他結構師來完成，開發人員和測試人員列席并給出意見。在敏捷開發的高度迭代過程中，測試人員首先要從整個項目全局考慮，及早發現需要更改設計的問題，但時間上不能花太久，其實這個測試更多的是去看、去思考，而能不能發現問題就要看你對現有需求吃的是不是透徹，對整個項目是否有一個全局的把握，是否從最終用戶角度去考慮問題，是否以實現客戶的商業價值為目標;然后在最短時間內完成所有功能和業務邏輯的測試，最好是每人分配不同的功能和業務邏輯進行測試，這樣就可以在最短時間內及時將優先級較高的bug及時反饋給開發人員;最后在開發人員忙于修改那些優先級較高，難度較大比較耗時的bug時測試人員可以有充分的時間來對這一迭代進行較細致的測試，發現功能和業務邏輯中不易察覺的問題，次要功能問題、驗證、界面等等問題。

　　關于敏捷測試的測試用例問題。很多人覺得測試用例沒有用，其實那是因為測試用例只是又書寫了一遍需求，這樣的用例當然沒有用。對于敏捷測試，在寫測試用例時我們必須要花很短的時間寫出高質量的測試用例。在我認為敏捷的測試用例就是以簡潔的語言寫出所有測試點，甚至可以不要期望結果，因為很多期望結果要么能在需求中找到，要么對于一個有一年以上測試經驗的測試人員來說已成竹在胸。如果為了嚴謹，可簡單寫明結果，如果沒時間可在后期敏捷測試過程中工作量不飽滿時補上也未嘗不可。同時敏捷測試用例必須在敏捷測試過程中不斷得到更新，在我們測試過程中、思考過程中完成測試用例的更新，因為敏捷測試用例簡潔的特點不會花太多時間。

　　當然對于測試人員與開發人員的溝通問題也非常重要，如果測試人員覺得自己提出的bug別人可能會有疑義或者別人不仔細研讀并不能直觀地理解其意，那么最好在這個bug后面寫明自己的想法，開發人員在處理測試人員提交的bug時同樣如此，對于有不同看法的bug一定要加上注釋說明原委。在此基礎上再進行溝通，我想剩下的問題不會太多，不會耽誤雙方太多時間，這樣得溝通更易于讓人接受、效率更高。測試人員之間的溝通與交流同樣重要，每個測試人員對需求可能都有不同的理解，溝通可以使他們對需求的理解更趨于一直，更高效的發現問題。測試人員間相互查看對方提交的bug，同樣是一種更有效的溝通和交流方式，可以發現別人看問題的不同角度，從而取長補短共同進步?？傊诓挥绊憚e人工作的情況下盡可能與其他人做充分的溝通也是敏捷測試中的重要部分。

　　敏捷測試的管理同樣是一個非常重要的部分，有時間整理一下再做補充。

　　對于敏捷測試必須有一個非常良好的環境，這個環境能夠讓測試人員有非?；钴S的頭腦，良好的心態，能夠非常自由的去思考，愿意去思考。其實很簡單就是如果能讓每個測試人員下班的時候都是開開心心的回家，那么這個環境就是最好的環境。

　　關于敏捷測試的一個不成熟的定義：一種面臨迅速變化的需求和頻繁迭代，迅速制定出與當前迭代高度適應的測試策略，快速做好測試準備并執行測試，盡早的發現優先級較高的bug、在有限的時間內完成覆蓋率較高、測試較充分的測試。

原文轉自：http://www.anti-gravitydesign.com