北京軟件開發敏捷軟件開發是從1990年代開始逐漸引起廣泛關注的一種新型軟件開發方法，是能夠應對快速變化的需求的一種軟件開發能力，它作為一種新型的開發模式，被越來越多地應用到軟件項目中。

　　敏捷軟件測試指的是在敏捷軟件開發過程中跟質量相關的一系列活動，和傳統意義上的軟件測試有很多區別，因為敏捷軟件測試的概念一直比較模糊，所以經常會有人走入誤區，我曾經在瀑布型的軟件開發模式下做過幾年的測試人員，所以在剛剛接觸敏捷項目的時候也曾有過一些誤解，但是在敏捷軟件開發團隊工作將近5年后，對很多問題有了新的認識，以下針對幾個常見的誤區和大家分享一下我的理解。

　　不需要測試策略

　　測試策略關注的是目標和方法，即怎樣在限定的時間內有效利用有限的資源達到提前制定的目標，一般制定測試策略時會首先明確測試目標，然后確定需要哪些測試類型，各種測試類型所占的大概比例，選擇測試框架，較后規劃一下軟件發布前需要經歷哪些測試階段。

　　很多人認為，敏捷軟件開發以用戶故事為單元，是不是集中精力在用戶故事測試就足夠了?是不是根本不需要考慮測試策略?

　　其實這是一個很大的誤解，因為敏捷軟件開發通常都是迭代式的發布，周期比較短，資源非常有限，這就更需要我們統籌規劃，小到一個用戶故事，大到一個完整的用戶特性，都需要考慮怎么合理利用測試資源，所以敏捷項目是非常需要測試策略的。

　　具體到實際項目中，通常團隊會在項目初期(迭代0)制定測試策略，明確目標(包括功能性需求的目標以及非功能性需求的目標)，然后確定在開發階段需要添加哪些自動化測試(包括單元測試，接口測試，契約測試，集成測試，系統級別的UI的用戶場景測試)，并規定這些測試的大概比率(符合測試金字塔)，選擇自動化測試框架(比如XUnit)以及需要哪些手動測試(包括探索性測試，可用性測試等)，還要規劃每個發布周期需要進行的測試階段(比如新功能測試，回歸測試等)，之后測試策略會對敏捷團隊的開發及測試起到非常重要的指導作用，當然，每個團隊因為項目的不同策略也會不同。

　　不需要測試文檔

　　測試文檔通常包括測試計劃，測試用例，測試報告，測試缺陷等文檔以及相對應的可以指導測試的一部分需求文檔。

　　很多人會認為，敏捷軟件測試是不需要文檔的，敏捷宣言中有一句“工作的軟件 高于 詳盡的文檔”，盡管敏捷宣言較后提到了“右項也有價值，我們更重視左項的價值”，但人們往往會忽視右項的內容，導致在很多剛開始實施敏捷開發的團隊中完全否定了測試文檔的作用。

　　首先不可否認，在實際的敏捷項目中，確實很少見傳統意義上的正式的專門的需求文檔和測試文檔，但這并不代表敏捷項目沒有文檔，比如用戶故事本身就是需求的載體，用戶故事中的驗收條件就是敏捷測試文檔的一部分， 另外很多敏捷軟件項目都會采用BDD的方式進行開發，將測試用例用業務人員能夠看懂的自然語言描述，并結合自動化實現，形成一個融需求和測試為一體的文檔，而且為了應對敏捷軟件測試變化快文檔更新不及時導致的問題，很多敏捷項目都在使用Living document。

　　純自動化測試 or 純手動測試

　　有些剛接觸敏捷的人認為敏捷軟件開發發布周期很短， 測試人員根本沒有時間做手動測試， 所以應該采用純自動化測試。

　　也有一些人認為，敏捷開發強調快速響應變化，如果投入成本在自動化測試上，那么肯定會導致維護自動化測試帶來的資源浪費，所以應該采用純手動測試。

　　這是兩種極端的誤解，雖然這兩種觀點所考慮到的難點確實存在， 因為在敏捷軟件開發過程中， 迭代通常比較短，確實不會預留足夠多的時間來做手動測試， 所以必須要有足夠多的自動化測試來保障。

　　然而因為測試代碼本身可能存在缺陷，而且有很多部分難以被自動化測試覆蓋(比如界面的測試，可用性測試，探索性測試等)，所以敏捷測試也同樣離不開手動測試。

　　至于關于自動化測試維護成本的顧慮，敏捷項目也確實存在變化比較多的特點，但通常變的都是比較接近用戶的部分，所以應該盡量減少用戶級別的依賴界面的自動化測試，而多增加一些不容易變化的底層的單元測試接口測試等。

　　推薦敏捷測試以自動化測試為主，手動測試為輔。

　　敏捷QA = 敏捷Tester

　　在很多剛接觸敏捷實踐的團隊中，大家對敏捷QA的認識還停留在Tester的階段，認為只要用戶故事開發完成之后，QA去專職地做測試，發現缺陷就夠了。

　　這是一個很大的誤解，首先QA(Quality Assurance/Analyst)，不是單純意義的測試人員，通過這個角色的名稱我們可以看的出來敏捷QA強調的是質量保障和分析，而不單純是測試產品。

　　在實際的項目中，敏捷QA通常會從需求分析階段就開始參與整個軟件開發過程，通過在不同階段和團隊中的不同角色合作，幫助整個團隊對質量達成共識，并通過在不同階段的確認和驗證做到缺陷預防，而不是等到軟件開發完成后再去發現缺陷，所以對于敏捷QA來說，其目標是軟件開發完成后能夠發現的缺陷越少越好，而對于Tester來說，發現越多的缺陷證明工作做得越優秀。

　　非功能性測試不重要

　　非功能性測試指的是針對非功能性需求(軟件本身滿足用戶需求所必需的功能性需求以外的一些特性，比如安全，性能，可用性，兼容性等)的測試，通常包括安全測試，性能測試，可用性測試，兼容性測試等。

　　在敏捷軟件項目中，需求被切割成了很小的單元，在切割的過程中，非功能性需求是較容易被人忽略的一部分，而這導致的問題就是非功能性測試經常被團隊忽略，久而久之，就會形成這樣一個誤解，認為非功能性測試是不重要的。

　　這個觀點非常不對，首先非功能性測試的重要性并不會因為軟件開發模式的不同而有所不同，尤其安全測試和性能測試的重要性正越來越多地被重視起來，因為很多產品必須考慮到用戶敏感信息的安全以及性能導致的用戶滿意度，在敏捷項目中由于軟件會盡早發布，如果這些非功能性需求出現問題，就會更早地造成影響，很可能在軟件剛步入市場就損失掉大多數的用戶。

　　所以非功能性的測試和功能性測試同等重要，在實際的項目中，比較好的做法是將這些非功能性需求也加入到用戶故事的驗收條件中，在整個敏捷開發流程中對這些非功能性需求進行驗證。

　　質量是QA的事兒

　　受傳統觀念的影響，很多人還是會認為質量是QA的事兒，如果產品發布后質量不好是QA的問題，其他角色和質量沒有太大的關系。

　　首先這種認識太高估了QA對質量的作用，軟件的質量是在軟件開發過程中逐步形成的， 從需求分析階段是否真正的了解到了客戶想要的功能，到開發階段是否增加了足夠多的自動化測試保障，是否寫了足夠健壯的產品代碼，到較后測試階段是否測試了功能引入后整個系統的可用性，不同用戶路徑是否能正常工作等等，這些都是軟件質量的組成部分。

　　可以看得出來，在整個過程中，軟件的質量離不開敏捷團隊各種角色的付出，其中有業務分析人員對需求的準確把握，有開發人員對產品代碼的高標準實現，對自動化測試覆蓋率的保障，還有QA在整個過程中對質量相關活動的實施和保障，包括需求分析階段從QA的視角對業務的補充，開發階段對自動化測試的審查，以及探索性測試可用性測試等對產品質量的進一步保障。

　　所以在敏捷測試中更多時候我們會淡化角色的概念，強調團隊人人都為質量負責，這樣更有助于團隊的每一位成員都把質量作為非常重要的一部分，而不是依賴于某個人或者某個角色。

　　開發可以寫測試，不再需要QA了

　　因為敏捷團隊強調人人都為質量負責，開發人員會采用TDD等方式寫大量的自動化測試，那么是不是就不需要QA了?

　　對于這個觀點，在社區有過很多激烈的討論，比如這篇文章《我們需要專職的QA嗎?》就曾經引起了很大的爭議，其實個人認為這篇文章里提到的QA指的是Tester，具體兩者的區別可參考前面的觀點;拋開這個，作者的某些觀點其實是很有價值的，比如作者較后提到了質量不是測出來的，要通過軟件生命周期各個階段相關活動的保障，而這些活動都離不開QA的參與。

　　首先需求分析階段，QA可以從不同的視角對于需求提出疑問，補充，修改，因為QA特有的技術背景，對于軟件的可用性等有更深入的理解，所以往往可以提出不同于業務分析師和開發人員的觀點;開發階段，QA也會審查開發人員寫的自動化測試，通過QA的專業測試背景幫助開發人員寫更有價值的測試，比如我們在項目中曾經發現開發人員寫了很多沒有業務價值的測試;測試階段，探索性測試，可用性測試，安全測試，性能測試等都是QA們在做的事情。

　　當然，如果業務分析師從各種視角把業務分析的透徹完美，開發人員可以寫非常有價值的測試，也可以做各種類型的手動測試，那么去掉專職QA也不是不可以，那樣的話不是不需要QA，而是人人都是QA。

　　結論

　　以上列出來的七點是剛剛接觸敏捷測試時很容易進入的誤區，甚至有的觀點在一些已經施行敏捷很長時間的團隊中仍然存在，這些觀點很容易導致敏捷測試走上彎路，以上是結合實際項目經驗個人的一些思考，希望對大家有所幫助。