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

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

　　不需要測試策略

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

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

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

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

　　不需要測試文檔

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

　　很多人會認爲，敏捷軟件測試是不需要文檔的，敏捷宣言中有一句“工作的軟件 高於(yú) 詳盡的文檔”，盡管敏捷宣言較後提到瞭(le)“右項也有價值，我們更重視左項的價值”，但人們往往會忽視右項的内容，導緻在很多剛開始實施敏捷開發的團隊中完全否定瞭(le)測試文檔的作用。

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

　　純(chún)自動化測(cè)試 or 純(chún)手動測(cè)試

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

　　也有一些人認爲，敏捷開發強調快速響應變(biàn)化，如果投入成本在自動化測試上，那麽肯定會導緻維護自動化測試帶來的資源浪費，所以應該採(cǎi)用純手動測試。

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

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

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

　　推薦敏捷測(cè)試以自動(dòng)化測(cè)試爲主，手動(dòng)測(cè)試爲輔。

　　敏捷QA = 敏捷Tester

　　在很多剛接觸敏捷實踐的團隊中，大家對敏捷QA的認識還停留在Tester的階段，認爲隻要用戶故事開發完成之後，QA去專職地做測(cè)試，發現缺陷就夠瞭(le)。

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

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

　　非功能性測試不重要

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

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

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

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

　　質量是QA的事兒

　　受傳(chuán)統觀念的影響，很多人還是會認爲質量是QA的事兒，如果産(chǎn)品發布後質量不好是QA的問題，其他角色和質量沒有太大的關系。

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

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

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

　　開發可以寫測(cè)試，不再需要QA瞭(le)

　　因爲敏捷團隊強調人人都爲質量負責，開發人員會採(cǎi)用TDD等方式寫大量的自動化測試，那麽是不是就不需要QA瞭(le)?

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

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

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

　　結論

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