前端工程重要分支——前端自動化測試初探

敏捷軟件測試指的是在敏捷軟件開發過程當中跟質量相關的一系列活動，和傳統意義上的軟件測試有不少區別，由於敏捷軟件測試的概念一直比較模糊，因此常常會有人走入誤區，我曾經在瀑布型的軟件開發模式下作過幾年的測試人員，因此在剛剛接觸敏捷項目的時候也曾有過一些誤解，可是在敏捷軟件開發團隊工做將近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。

敏捷測試

結論

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