敏捷軟體測試指的是在敏捷軟體開發過程中跟質量相關的一系列活動，和傳統意義上的軟體測試有很多區別，因為敏捷軟體測試的概念一直比較模糊，所以經常會有人走入誤區，我曾經在瀑布型的軟體開發模式下做過幾年的測試人員，所以在剛剛接觸敏捷專案的時候也曾有過一些誤解，但是在敏捷軟體開發團隊工作將近5年後，對很多問題有了新的認識，以下針對幾個常見的誤區和大家分享一下我的理解。
測試策略關注的是目標和方法，即怎樣在限定的時間內有效利用有限的資源達到提前制定的目標，一般制定測試策略時會首先明確測試目標，然後確定需要哪些測試型別，各種測試型別所佔的大概比例，選擇測試框架，最後規劃一下軟體發布前需要經歷哪些測試階段。
很多人認為，敏捷軟體開發以使用者故事為單元，是不是集中精力在使用者故事測試就足夠了？是不是根本不需要考慮測試策略？
其實這是乙個很大的誤解，因為敏捷軟體開發通常都是迭代式的發布，週期比較短，資源非常有限，這就更需要我們統籌規劃，小到乙個使用者故事，大到乙個完整的使用者特性，都需要考慮怎麼合理利用測試資源，所以敏捷專案是非常需要測試策略的。
具體到實際專案中，通常團隊會在專案初期（迭代0）制定測試策略，明確目標(包括功能性需求的目標以及非功能性需求的目標)，然後確定在開發階段需要新增哪些自動化測試(包括單元測試，介面測試，契約測試，整合測試，系統級別的ui的使用者場景測試)，並規定這些測試的大概比率(符合測試金字塔)，選擇自動化測試框架（比如xunit）以及需要哪些手動測試(包括探索性測試，可用性測試等)，還要規劃每個發布週期需要進行的測試階段（比如新功能測試，回歸測試等），之後測試策略會對敏捷團隊的開發及測試起到非常重要的指導作用，當然，每個團隊因為專案的不同策略也會不同。
下圖就是乙個簡單的敏捷測試策略介紹:
測試文件通常包括測試計畫，測試用例，測試報告，測試缺陷等文件以及相對應的可以指導測試的一部分需求文件。
很多人會認為，敏捷軟體測試是不需要文件的，敏捷宣言中有一句「工作的軟體 高於 詳盡的文件」，儘管敏捷宣言最後提到了「右項也有價值，我們更重視左項的價值」，但人們往往會忽視右項的內容，導致在很多剛開始實施敏捷開發的團隊中完全否定了測試文件的作用。
首先不可否認，在實際的敏捷專案中，確實很少見傳統意義上的正式的專門的需求文件和測試文件，但這並不代表敏捷專案沒有文件，比如使用者故事本身就是需求的載體，使用者故事中的驗收條件就是敏捷測試文件的一部分， 另外很多敏捷軟體專案都會採用bdd的方式進行開發，將測試用例用業務人員能夠看懂的自然語言描述，並結合自動化實現，形成乙個融需求和測試為一體的文件，而且為了應對敏捷軟體測試變化快文件更新不及時導致的問題，很多敏捷專案都在使用living document。
敏捷測試
有些剛接觸敏捷的人認為敏捷軟體開發發布週期很短， 測試人員根本沒有時間做手動測試， 所以應該採用純自動化測試。
也有一些人認為，敏捷開發強調快速響應變化，如果投入成本在自動化測試上，那麼肯定會導致維護自動化測試帶來的資源浪費，所以應該採用純手動測試。
這是兩種極端的誤解，雖然這兩種觀點所考慮到的難點確實存在， 因為在敏捷軟體開發過程中， 迭代通常比較短，確實不會預留足夠多的時間來做手動測試， 所以必須要有足夠多的自動化測試來保障。
然而因為測試**本身可能存在缺陷，而且有很多部分難以被自動化測試覆蓋(比如介面的測試，可用性測試，探索性測試等)，所以敏捷測試也同樣離不開手動測試。
至於關於自動化測試維護成本的顧慮，敏捷專案也確實存在變化比較多的特點，但通常變的都是比較接近使用者的部分，所以應該儘量減少使用者級別的依賴介面的自動化測試，而多增加一些不容易變化的底層的單元測試介面測試等。
推薦敏捷測試以自動化測試為主，手動測試為輔。
敏捷測試
在很多剛接觸敏捷實踐的團隊中，大家對敏捷qa的認識還停留在tester的階段，認為只要使用者故事開發完成之後，qa去專職地做測試，發現缺陷就夠了。
這是乙個很大的誤解，首先qa(quality assurance/analyst)，不是單純意義的測試人員，通過這個角色的名稱我們可以看的出來敏捷qa強調的是質量保障和分析，而不單純是測試產品。
在實際的專案中，敏捷qa通常會從需求分析階段就開始參與整個軟體開發過程，通過在不同階段和團隊中的不同角色合作，幫助整個團隊對質量達成共識，並通過在不同階段的確認和驗證做到缺陷預防，而不是等到軟體開發完成後再去發現缺陷，所以對於敏捷qa來說，其目標是軟體開發完成後能夠發現的缺陷越少越好，而對於tester來說，發現越多的缺陷證明工作做得越優秀。
敏捷測試
非功能性測試指的是針對非功能性需求（軟體本身滿足使用者需求所必需的功能性需求以外的一些特性，比如安全，效能，可用性，相容性等）的測試，通常包括安全測試，效能測試，可用性測試，相容性測試等。
在敏捷軟體專案中，需求被切割成了很小的單元，在切割的過程中，非功能性需求是最容易被人忽略的一部分，而這導致的問題就是非功能性測試經常被團隊忽略，久而久之，就會形成這樣乙個誤解，認為非功能性測試是不重要的。
這個觀點非常不對，首先非功能性測試的重要性並不會因為軟體開發模式的不同而有所不同，尤其安全測試和效能測試的重要性正越來越多地被重視起來，因為很多產品必須考慮到使用者敏感資訊的安全以及效能導致的使用者滿意度，在敏捷專案中由於軟體會盡早發布，如果這些非功能性需求出現問題，就會更早地造成影響，很可能在軟體剛步入市場就損失掉大多數的使用者。
所以非功能性的測試和功能性測試同等重要，在實際的專案中，比較好的做法是將這些非功能性需求也加入到使用者故事的驗收條件中，在整個敏捷開發流程中對這些非功能性需求進行驗證。
受傳統觀念的影響，很多人還是會認為質量是qa的事兒，如果產品發布後質量不好是qa的問題，其他角色和質量沒有太大的關係。
首先這種認識太高估了qa對質量的作用，軟體的質量是在軟體開發過程中逐步形成的， 從需求分析階段是否真正的了解到了客戶想要的功能，到開發階段是否增加了足夠多的自動化測試保障，是否寫了足夠健壯的產品**，到最後測試階段是否測試了功能引入後整個系統的可用性，不同使用者路徑是否能正常工作等等，這些都是軟體質量的組成部分。
可以看得出來，在整個過程中，軟體的質量離不開敏捷團隊各種角色的付出，其中有業務分析人員對需求的準確把握，有開發人員對產品**的高標準實現，對自動化測試覆蓋率的保障，還有qa在整個過程中對質量相關活動的實施和保障，包括需求分析階段從qa的視角對業務的補充，開發階段對自動化測試的審查，以及探索性測試可用性測試等對產品質量的進一步保障。
所以在敏捷測試中更多時候我們會淡化角色的概念，強調團隊人人都為質量負責，這樣更有助於團隊的每一位成員都把質量作為非常重要的一部分，而不是依賴於某個人或者某個角色。
敏捷測試
因為敏捷團隊強調人人都為質量負責，開發人員會採用tdd等方式寫大量的自動化測試，那麼是不是就不需要qa了？
對於這個觀點，在社群有過很多激烈的討論，比如這篇文章《我們需要專職的qa嗎？》就曾經引起了很大的爭議，其實個人認為這篇文章裡提到的qa指的是tester，具體兩者的區別可參考前面的觀點；拋開這個，作者的某些觀點其實是很有價值的，比如作者最後提到了質量不是測出來的，要通過軟體生命週期各個階段相關活動的保障，而這些活動都離不開qa的參與。
首先需求分析階段，qa可以從不同的視角對於需求提出疑問，補充，修改，因為qa特有的技術背景，對於軟體的可用性等有更深入的理解，所以往往可以提出不同於業務分析師和開發人員的觀點；開發階段，qa也會審查開發人員寫的自動化測試，通過qa的專業測試背景幫助開發人員寫更有價值的測試，比如我們在專案中曾經發現開發人員寫了很多沒有業務價值的測試；測試階段，探索性測試，可用性測試，安全測試，效能測試等都是qa們在做的事情。
當然，如果業務分析師從各種視角把業務分析的透徹完美，開發人員可以寫非常有價值的測試，也可以做各種型別的手動測試，那麼去掉專職qa也不是不可以，那樣的話不是不需要qa，而是人人都是qa。
敏捷測試
以上列出來的七點是剛剛接觸敏捷測試時很容易進入的誤區，甚至有的觀點在一些已經施行敏捷很長時間的團隊中仍然存在，這些觀點很容易導致敏捷測試走上彎路，以上是結合實際專案經驗個人的一些思考，希望對大家有所幫助。
前端自動化測試
自動化測試框架jest 安裝jest npm install jest 24.8 0 d修改package.json中的test scripts 執行 npm run test 配置jest，執行會生成jest.config.js的js檔案 npx jest init 生成coverage資料夾的測...
前端工程自動化構建總結
總的來說，需求就兩點，一是需要乙個http伺服器，來供手機訪問靜態資源，另乙個是監聽 的改動並自動重新整理瀏覽器。要滿足這兩個需求的第三方工具，應當不難找，事實上像fis,yeoman,vuecli這樣的工具應當都可以做到。可是我覺得它們都太複雜了，雖然我只用到其中一點點功能，但是我不得不仔細的通讀...
Jenkins SVN 前端自動化部署
jenkins是什麼？昨天之前我也不知道。習慣上班之前刷刷新聞或技術相關知識 了解到jenkins。其實就是乙個自動打包自動部署的乙個工具，不過感覺挺好玩的。我比較菜好了一天多的時間才弄好。如果你也想用那就用吧反正一聽自動化就感覺挺高大上的 jenkins svn win vue專案 和別的軟體一樣...