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

　　敏捷軟件測試指的是在敏捷軟件開發(fā)過程中跟質(zhì)量相關(guān)的一系列活動，和傳統(tǒng)意義上的軟件測試有很多區(qū)別，因?yàn)槊艚蒈浖y試的概念一直比較模糊，所以經(jīng)常會有人走入誤區(qū)，我曾經(jīng)在瀑布型的軟件開發(fā)模式下做過幾年的測試人員，所以在剛剛接觸敏捷項(xiàng)目的時(shí)候也曾有過一些誤解，但是在敏捷軟件開發(fā)團(tuán)隊(duì)工作將近5年后，對很多問題有了新的認(rèn)識，以下針對幾個(gè)常見的誤區(qū)和大家分享一下我的理解。

　　不需要測試策略

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

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

　　其實(shí)這是一個(gè)很大的誤解，因?yàn)槊艚蒈浖_發(fā)通常都是迭代式的發(fā)布，周期比較短，資源非常有限，這就更需要我們統(tǒng)籌規(guī)劃，小到一個(gè)用戶故事，大到一個(gè)完整的用戶特性，都需要考慮怎么合理利用測試資源，所以敏捷項(xiàng)目是非常需要測試策略的。

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

　　不需要測試文檔

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

　　很多人會認(rèn)為，敏捷軟件測試是不需要文檔的，敏捷宣言中有一句“工作的軟件 高于 詳盡的文檔”，盡管敏捷宣言較后提到了“右項(xiàng)也有價(jià)值，我們更重視左項(xiàng)的價(jià)值”，但人們往往會忽視右項(xiàng)的內(nèi)容，導(dǎo)致在很多剛開始實(shí)施敏捷開發(fā)的團(tuán)隊(duì)中完全否定了測試文檔的作用。

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

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

　　有些剛接觸敏捷的人認(rèn)為敏捷軟件開發(fā)發(fā)布周期很短， 測試人員根本沒有時(shí)間做手動測試， 所以應(yīng)該采用純自動化測試。

　　也有一些人認(rèn)為，敏捷開發(fā)強(qiáng)調(diào)快速響應(yīng)變化，如果投入成本在自動化測試上，那么肯定會導(dǎo)致維護(hù)自動化測試帶來的資源浪費(fèi)，所以應(yīng)該采用純手動測試。

　　這是兩種極端的誤解，雖然這兩種觀點(diǎn)所考慮到的難點(diǎn)確實(shí)存在， 因?yàn)樵诿艚蒈浖_發(fā)過程中， 迭代通常比較短，確實(shí)不會預(yù)留足夠多的時(shí)間來做手動測試， 所以必須要有足夠多的自動化測試來保障。

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

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

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

　　敏捷QA = 敏捷Tester

　　在很多剛接觸敏捷實(shí)踐的團(tuán)隊(duì)中，大家對敏捷QA的認(rèn)識還停留在Tester的階段，認(rèn)為只要用戶故事開發(fā)完成之后，QA去專職地做測試，發(fā)現(xiàn)缺陷就夠了。

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

　　在實(shí)際的項(xiàng)目中，敏捷QA通常會從需求分析階段就開始參與整個(gè)軟件開發(fā)過程，通過在不同階段和團(tuán)隊(duì)中的不同角色合作，幫助整個(gè)團(tuán)隊(duì)對質(zhì)量達(dá)成共識，并通過在不同階段的確認(rèn)和驗(yàn)證做到缺陷預(yù)防，而不是等到軟件開發(fā)完成后再去發(fā)現(xiàn)缺陷，所以對于敏捷QA來說，其目標(biāo)是軟件開發(fā)完成后能夠發(fā)現(xiàn)的缺陷越少越好，而對于Tester來說，發(fā)現(xiàn)越多的缺陷證明工作做得越優(yōu)秀。

　　非功能性測試不重要

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

　　在敏捷軟件項(xiàng)目中，需求被切割成了很小的單元，在切割的過程中，非功能性需求是較容易被人忽略的一部分，而這導(dǎo)致的問題就是非功能性測試經(jīng)常被團(tuán)隊(duì)忽略，久而久之，就會形成這樣一個(gè)誤解，認(rèn)為非功能性測試是不重要的。

　　這個(gè)觀點(diǎn)非常不對，首先非功能性測試的重要性并不會因?yàn)檐浖_發(fā)模式的不同而有所不同，尤其安全測試和性能測試的重要性正越來越多地被重視起來，因?yàn)楹芏喈a(chǎn)品必須考慮到用戶敏感信息的安全以及性能導(dǎo)致的用戶滿意度，在敏捷項(xiàng)目中由于軟件會盡早發(fā)布，如果這些非功能性需求出現(xiàn)問題，就會更早地造成影響，很可能在軟件剛步入市場就損失掉大多數(shù)的用戶。

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

　　質(zhì)量是QA的事兒

　　受傳統(tǒng)觀念的影響，很多人還是會認(rèn)為質(zhì)量是QA的事兒，如果產(chǎn)品發(fā)布后質(zhì)量不好是QA的問題，其他角色和質(zhì)量沒有太大的關(guān)系。

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

　　可以看得出來，在整個(gè)過程中，軟件的質(zhì)量離不開敏捷團(tuán)隊(duì)各種角色的付出，其中有業(yè)務(wù)分析人員對需求的準(zhǔn)確把握，有開發(fā)人員對產(chǎn)品代碼的高標(biāo)準(zhǔn)實(shí)現(xiàn)，對自動化測試覆蓋率的保障，還有QA在整個(gè)過程中對質(zhì)量相關(guān)活動的實(shí)施和保障，包括需求分析階段從QA的視角對業(yè)務(wù)的補(bǔ)充，開發(fā)階段對自動化測試的審查，以及探索性測試可用性測試等對產(chǎn)品質(zhì)量的進(jìn)一步保障。

　　所以在敏捷測試中更多時(shí)候我們會淡化角色的概念，強(qiáng)調(diào)團(tuán)隊(duì)人人都為質(zhì)量負(fù)責(zé)，這樣更有助于團(tuán)隊(duì)的每一位成員都把質(zhì)量作為非常重要的一部分，而不是依賴于某個(gè)人或者某個(gè)角色。

　　開發(fā)可以寫測試，不再需要QA了

　　因?yàn)槊艚輬F(tuán)隊(duì)強(qiáng)調(diào)人人都為質(zhì)量負(fù)責(zé)，開發(fā)人員會采用TDD等方式寫大量的自動化測試，那么是不是就不需要QA了?

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

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

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

　　結(jié)論

　　以上列出來的七點(diǎn)是剛剛接觸敏捷測試時(shí)很容易進(jìn)入的誤區(qū)，甚至有的觀點(diǎn)在一些已經(jīng)施行敏捷很長時(shí)間的團(tuán)隊(duì)中仍然存在，這些觀點(diǎn)很容易導(dǎo)致敏捷測試走上彎路，以上是結(jié)合實(shí)際項(xiàng)目經(jīng)驗(yàn)個(gè)人的一些思考，希望對大家有所幫助。