敏捷測試介紹
敏捷測試固然不能簡單地理解爲測得更快，絕對不是比之前用更少時間進行測試，也不是將測試的範圍縮小了或將質量下降來減小測試任務。也有人說，只有敏捷開發，沒有敏捷測試。下面咱們將要討論一下：
- 什麼是敏捷測試？
- 敏捷測試有哪些流程改進？
- 測試人員如何面對敏捷測試的挑戰？
- 在敏捷測試中如何制定相應的自動化測試策略？
什麼是敏捷測試
假如將過去傳統的測試流程和方法硬塞入敏捷開發流程中，測試工做可能會事倍功半，測試人員可能會每天加班，而不能發揮應有的做用。敏捷測試應該是適應敏捷方法而採用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有不一樣的側重，例如減小測試計劃、測試用例設計等工做的比重，增長與產品設計人員、開發人員的交流和協做。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的迴歸測試則依賴於自動化測試。因爲敏捷方法中迭代週期短，測試人員儘早開始測試，包括及時對需求、開發設計的評審，更重要的是可以及時、持續的對軟件產品質量進行反饋。簡單地說，敏捷測試就是持續地對軟件質量問題進行及時地反饋
敏捷測試流程的優化
在敏捷方法中，需求變化比較快、產品開發週期很短，咱們目前採用四周時間，也就是每月發佈一個新版本。開發週期短，功能不斷累加，給軟件測試帶來很大的挑戰，軟件測試流程要作相應的調整。例如，咱們原有的測試規範明確規定，首先要創建項目的主測試計劃書，而後再創建每一個功能任務的測試計劃書，測試計劃書有嚴格的模板，並且須要和產品經理、開發人員討論，並和測試團隊其餘人員（包括測試經理）討論，最終獲得你們的承認和簽字才能經過，僅測試計劃通過「起草、評審和簽發」一個完整的週期就須要一個月。在敏捷方法中，再也不要求寫幾十頁的測試計劃書，而是在每一個迭代週期，寫出一頁紙的測試計劃，將測試要點（包括策略、特定方法、重點範圍等）列出來就能夠了。
在原有測試規範中，要求先用Excel寫出測試用例，而後進行討論、評審，評審經過之後再導入測試用例庫（在線管理系統）中。在敏捷測試中，可能不須要測試用例，而是針對Use Case或User Story直接進行驗證，並進行探索性測試。而節約出來的時間，用於開發原有功能的自動化測試腳本，爲迴歸測試服務。自動化測試腳本將代替測試用例，成爲軟件組織的財富。原有測試規範還要求進行兩輪迴歸測試，在敏捷測試中，只能進行一輪迴歸測試。綜合這些考慮，敏捷測試的流程簡單有效，如圖2所示。
在敏捷測試流程中，如前所述，測試是一個持續的質量反饋過程，測試中發現的問題要及時反饋給產品經理和開發人員，並且某些關鍵方面也要獲得咱們足夠的關注，主要有：
- 測試人員不只要全程參與需求、產品功能設計等討論，並且要面對面地、充分地討論（包括帶語言、視頻的即時通信），僅僅經過郵件是不夠的。
- 參與代碼複審（Code Review），並適當輔助開發人員進行單元測試。
- 在流程中增長一個環節「產品走查（Product Walk-through）」DEMO——測試人員和產品經理、開發人員等在一塊兒，從頭至尾將新功能看一遍，可直觀、快速地發現問題。
新功能的測試和迴歸測試策略
測試任務簡單地可分爲新功能測試和迴歸測試。在敏捷方法中，針對這兩部分的測試創建相應的策略，以提升測試的效率，最大限度地下降質量風險。新功能測試的策略主要有：
- 不須要測試用例，直接基於用例和對需求的理解來完成新功能的驗證。即便要寫測試用例，只要保證各個功能點被覆蓋，不要過於詳細（大顆粒度）。
- 持續地進行驗證，一旦某塊新代碼完成（Code Drop），就開始驗證，而不是等到全部代碼完成後纔開始測試。這也包括參與到單元測試和集成測試中。
- 實施端到端（End-to-End）的測試，確保完整的業務流程的實現，同時，也容易發現業務邏輯不夠清晰、不夠合理等各方面的問題。
- 閱讀代碼來發現問題，能夠和開發人員工做保持同步，消除測試周期的壓力。
- 基於經驗，能夠實施更多的探索性測試、組合交互性（Interoperation）測試和用戶場景(User Scenario)測試，更有效地發現埋藏較深的缺陷。
迴歸測試是敏捷測試中須要面對的難點。每次迭代都會增長新的功能，一個產品可能會通過十幾回、甚至幾十次迭代，迴歸測試範圍在不斷增大，而每次迭代週期沒變，可能仍是一個月。這樣驗收測試的時間很是有限，因此迴歸測試很大程度上依賴於自動化測試，由於很難將回歸測試控制在很是有限的範圍內。固然，仍是有些辦法能夠幫助咱們減小回歸測試的範圍，例如：
- 經過執行Code Diff 來了解代碼變更的全部地方，再作代碼關聯分析，就能夠明確知道要進行哪些地方的迴歸測試，迴歸測試範圍會大大縮小。
- 基於風險和操做面分析來減小回歸測試的範圍，例如迴歸測試只是保證主要功能點沒有問題，而忽視一些細節的問題。
- 持續測試的過程，只要有時間，就進行測試，包括開發人員、產品設計人員都參與到平常的試用和測試中來。
自動化測試策略
因爲開發週期短，需求、設計等方面溝通也須要花費不少時間，沒有足夠時間開發自動化測試腳本，至少對新功能的測試很難實現自動化測試。這時候，就須要正確的策略來提升自動化測試的效益，如圖3所示，並說明以下。
- 構建一個靈活的、開放的自動化測試框架，如基於關鍵字驅動的自動化框架，使測試腳本的開發簡單易行，腳本維護也方便。
- 針對穩定的產品特性開發自動化測試腳本，也就是針對前期完成的已有功能開發自動化測試的腳本,小部分主要功能自動化,而大部分新功能測試採用手工測試
- 集中精力在單元層次上實現自動化測試，主要由開發人員實施，測試人員提供單元測試框架，並輔助完成一些所需的基礎工做。
- 在產品設計、編程時就很好地考慮了自動化測試的需求，使全面的、自動化的底層測試、接口測試成爲可能，儘可能避免用戶界面（UI）的自動化測試。
- 良好的IT基礎設施，包括自動化構建軟件包、自動化版本驗證（BVT）、自動化部署、覆蓋率自動產生等。
敏捷測試工具
自動化測試依賴於測試工具，所幸的是，目前已有不少敏捷測試工具。因爲篇幅所限，這裏只是簡單地列出一些經常使用的敏捷測試工具，再也不深刻討論了。
- 單元測試工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
- 功能測試自動化：ThoughtWorks Twist。
- Web功能測試（frontend）：Selenium IDE/RC、WatiR、WatiN。
- Web service測試工具（backend）：soapUI。
- 性能測試：JMeter+BadBoy。
- 驗收測試框架：Fitnesse、Tellurium。
- 敏捷測試過程管理工具：微軟的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
- 業務智能（BI）應用的測試框架：Oraylis BI.Quality （+ NUnit）。
- 其餘一些協做工具等，如TestLink、BugZilla、BugFree、Wiki等。
測試人員在敏捷方法中的價值
在敏捷方法中，開發人員的主導做用更明顯，系統設計、編程實現、單元測試、重構等看似關鍵的一些任務都落在開發人員身上，測試人員容易被邊緣化。那麼，在敏捷方法中，測試人員的價值又如何體現呢？
- 在需求和功能設計討論上，測試人員能夠站在客戶角度來闡述本身的觀點，扮演「用戶表明」角色，強調用戶體驗，真正體現測試人員和開發人員的互補做用。
- 測試人員不只扮演「用戶表明」角色，並且經過需求討論、代碼複審等各類活動及時地提供質量反饋，包括代碼質量、接口一致性等，保證在產品構造的整個過程當中質量受到足夠的關注，以提升質量改進的持續性和可視性。
- 測試人員應積極參與單元測試，即便不參加單元測試，也應督促開發人員進行單元測試，確保單元測試達到80% 以上覆蓋率，確保開發出具備良好可測試性的代碼。
- 在敏捷方法中，每每將一個大的系統開發分解成多個小的子系統（模塊或組件），集成測試和端到端（End-to-End）測試顯得更爲重要，測試人員在這些測試上能發揮更大的做用。
- 產品發佈前，驗收測試和迴歸測試依然不可缺乏，這更是測試人員的用武之地。
- 一個迭代週期結束後，對缺陷根本緣由進行分析、總結規律，幫助開發人員創建良好的習慣，預防缺陷，從根本上提升產品質量。
理想狀況下，測試人員掌握設計模式、具備很好的編程能力，能夠和開發人員進行角色互換，如在當前版本開發中擔任測試人員角色，在下一個版本開發中則擔任開發人員角色。這樣雙方對不一樣角色的工做有着更深入的認識，消除溝通的障礙，開發的效率和質量會有進一步的提升。
總結
根據上面的討論和咱們的實踐，最後針對敏捷測試進行一個簡單的總結，就是：
- 敏捷測試就是持續測試、持續反饋，扮演「用戶表明」角色，確保產品知足客戶的需求。
- 敏捷功能測試 = 新特性的手工測試（Use Case驗證和探索性測試）+新功能的BVT測試(建議有) + 原有功能的自動化測試 （迴歸測試）。做爲一個偷巧的辦法，某些狀況下，能夠對代碼進行diff 檢查，比較代碼改動的部分，讓測試更有針對性。
- 合理的利用自動化。自動化並非越多越好。自動化能夠保證已有功能的迴歸。對新增的功能，須要評估究竟是自動化效率高仍是手動測試效率高？我更傾向於對新增功能執行手動或者半自動化的測試，而在產品發佈以後再補充完善自動化迴歸腳本。隨着開發的進行，產品質量的提高，以及對產品瞭解程度的加深，對自動化測試進行持續改進，提供更大的覆蓋，更好和更快速的驗證。
- 敏捷開發追求持續的集成，持續的進行單元測試和迴歸測試。咱們計劃與過程改進一塊兒推動Check-In Test, BVT, daily regression test的自動化，讓開發人員隨時能夠獲得關於代碼質量的反饋（例如，每一次的check-in是否break了build），幫助開發人員生產出具備良好可測試性的代碼，進而提高測試的效率。幫助開發，就是幫助測試本身。
- 經過自動化和測試報告，創建可見的質量度量體系，讓產品和代碼質量反饋持續可
- 讓測試用例更有效率，避免在測試用例上面浪費太多的時間。測試用例不是越多越詳細就好。太詳細的測試用例會下降測試效率，增長維護成本，而且會限制測試執行人員的思惟。若是你的Bug大部分是經過執行測試用例發現的，那說明有兩個問題：你在測試用例上面浪費了太多的時間，或者你在測試經驗上面比較欠缺。如何定義測試用例的粒度——從業務出發，測試用例只要覆蓋全部的業務功能和邏輯就夠了。而數據檢查、邊界條件的測試用例，就留給測試人員去執行探索性的測試吧，但願每一個人都加強探索性測試的意識。
- 爲各系統維護一套測試點的checklist，越精簡越好。讓負責測試的人員（尤爲是新手）能在幾分鐘以內就知道有哪些測試點是被遺漏的、須要關注的。咱們已經把部分的checklist放在在wiki上了（例如引擎測試），但願你們都能參與進來，不斷補充完善。
- 前端應用的測試：UI變動頻繁，測試很是容易失效？是否能夠考慮把測試重心向相對穩定的接口測試傾斜？你們能夠一塊兒來思考。
- 開發和測試團隊具備一樣的質量目標和質量責任。開發人員有義務對產品的可測試性和可自動化負責。若是你有這方面的需求，必定要跟開發人員講出來。
- 敏捷測試人員和開發人員的區別愈來愈小，理想狀況下，敏捷方法中，測試人員和開發人員在不一樣的迭代週期能夠互換。
- 敏捷測試流程依據不一樣的團隊特色、不一樣產品的特色而不一樣，因地制宜，適合纔是最好。
我的工做經歷的一些經驗，總結了如下幾點：
一、測試人員儘量早的進入產品或項目的相關工做(這裏指的產品或項目，指的都是從頭開始的)，從產品的計劃、需求調研、評審工做的開始測試人員就進行參與，這麼作的目的有以下幾點：
a.讓測試人員儘量多的瞭解需求、瞭解業務，積極的提出問題
b.在下一步系統架構和接口設計以後，測試人員能夠進行儘早設計系統的接口測試用例
c.還能夠爲下一步編碼工做的單元測試作一個良好的鋪墊，在後期設計單元測試用例的同時，懂代碼的測試人員能夠直接的檢查開發人員的代碼邏輯和業務邏輯是否符合要求，這也就實現了用最少成本「雙人編程」。
二、綜合一些實際狀況考慮：根據一些實際調研，通常開發與測試的比例在1:6--1:10左右，能達到1:6的已經很不容易了，暫時不去討論這個比例問題，由於這個須要根據項目的實際狀況來看，我的看來：一些大型的互聯網公司是不差錢的，因此他們會盡量的在測試方面多投入或者說投入較高的，還有一些公司是不肯意在測試方面多投入可是又想多作測試的，還有一些就是儘量少投入的，其實這些均可以調整，調整的依據是兩個方面：一是確保公司對這個項目的重視和公司是真正的作測試，若是沒有領導的支持，準確的說沒有大領導的支持，測試工做是很難有效推動的，二是有效的安排測試人員，就是在項目的不一樣階段安排不一樣測試人員，在測試不是不少是時候，可使用半我的或者更少的測試人員，實現這一點的方法就是讓一個測試人員去服務多個項目便可，固然這個多個也是有數量限制的，由於一我的的精力也是有限。
三、從第前2條提出來的一個疑問：做者一直提倡讓測試人員儘量早的接觸產品和項目，這樣能讓測試人員充分了解項目，那麼如何讓一我的服務於多個測試項目？首先：明確一點，不是測試人員不從項目的開始就介入，測試人員就不能瞭解需求、不會測試。對於一個有經驗的測試人員來講，快速的熟悉項目的需求並非一件難事，若是說項目的各類邏輯真的是很複雜，項目經理也能夠根據用戶故事或者進行一些更爲細緻的安排來讓這些協調過來的測試人員開展測試工做。一人服務於多個項目，這種事情在國內應該是家常便飯的。
四、如何安排人員也是一個如何花錢的問題：這種體會最深的就應該是外包公司，是先花錢仍是後花錢仍是超支仍是項目失敗，想必外包公司對這方面算的是最細的了。早期發現問題早解決問題，後面的壓力就會小，不能早期的發現的問題，後面的團隊壓力就會像滾雪球一下愈來愈大。早期的測試投入當作一份成本的話，用這一份成本，來提前的發現問題的下降風險，後期纔開始投入測試的話，也算是用一份成本，可是若是發現問題，開發人員就追蹤、修改的成本是要遠遠大於初期的，項目的龐大和不穩定是讓開發人員準肯定位問題最大的困擾，還有測試人員作測試驗證、迴歸測試、自動化腳本的修改這一切成本。
五、在項目的中後期如何作好自動化測試工做？在項目中期的時候，問題會逐漸積累，測試的東西也會愈來愈多，開發和維護的東西愈來愈多，維護是指測試人員測試出來的bug須要修復，可是又不能由於修復bug就中止項目開發工做。隨着項目的推動，測試的效率保證是一個關鍵問題，這個時候自動化的推動和效率卻成了一個矛盾的問題。緣由有三：1.自動化代碼須要編寫和調試 2.自動化代碼測試結果須要和手動測試結果進行比對 (自動化測試結果和手動測試結果不一致會有發生)3.自動化測試代碼須要維護，尤爲是在需求變動和設計變動的時候，手動測試只須要肉眼對比，而自動化測試可能會將代碼進行較大改動。這三個問題大大下降了測試效率，這是手動測試必須成爲項目的主導。解決這一問題的辦法就是在項目測試集中的階段調整手動和自動測試人員的比例，自動化人員測試的範圍須要有一個合理的規劃，必須定時的提交自動化測試代碼，在手動測試完成後必須儘快的補充自動化測試代碼，在完成測試工做的同時也天然的與手動測試的結果進行了比較，至關於進行了1次迴歸測試。也就說仍是所有由手動測試人員進行第一輪全面覆蓋的測試。
六、在「敏捷」開發過程當中，自動化工程師先對哪一部分功能進行優先的用例實現：能夠從如下幾個方面進行考慮：1.優先考慮數據對比類型的功能，這種功能人工操做比較費眼力和時間 2.優先考慮已經測試出問題的功能，這樣能夠有效的對bug的功能進行迴歸檢查 3.用戶使用比較頻繁的功能 4.項目優先級比較高，比較核心的功能
7.強調一點：手動測試和自動化測試對於項目來講同等重要，不存在自動化測試人員高級於手動測試人員。若是說必定要說哪一個最重要的話，只能是看項目的不一樣階段，在項目前中期的時候的時候，手動測試佔據了核心地位，在後期的時候，自動化的全面覆蓋保證了迴歸測試的有效進行。
8.總結：關於敏捷開發和敏捷測試的一點心得：敏捷如今已經被推向了一個高潮，何爲敏捷？太多人有不一樣的看法，說到最後與敏捷最分不開的一詞就應該是「實踐」，敏捷是實踐出來的，不是效仿出來的，如今太多的公司和團隊在盲目的追求敏捷，拿scrum來講，有多少公司在作的只是scrum最最表象的一些東西，安排站會，制定sprint，總結會等等，可是這些真的給你的團隊帶來了改善了嗎？想必答案只有他們本身清楚。我心中的敏捷：敏捷---敏-結，敏就是敏捷，簡單的說就是要一個高效率，結：是指項目團隊的協做和內部團結,這一點很是重要。看那些成功實施敏捷的團隊和諸多的最佳實踐團隊他們都是團結一心的，整個項目團隊都有一個共同的目標和追求，而不是天天項目經理在驅使着你們在前進，每一個人都積極上進學習，遇到不懂的問題去總結、去學習，去突破，再去分享，而不是說，「這個問題太難了，這個技術太難了，這個。。。我可作不了」，若是每一個成員都採用這種排斥的內心，那麼這個團隊就永遠都敏捷不起來，還有就是在須要協做的時候，兩個項目組不要互相「踢皮球」，而是要敢於承擔責任，最廣泛的現象就是項目出現了問題，而後你們在會上開始掐架。這時候有人會問，本身出來擔責任不是傻嗎？其實否則，一個明智的老闆固然看的懂究竟是誰的責任，是否真正的須要人來承擔責任。若是這都作不到，證實這個老闆也就。。。再談實踐，筆者看來，很難有一個很細緻的又能夠公用的敏捷方法，即便如今最流行的scrum，也是一個很是抽象的概念，因此纔有諸多屢實施又不見成效的團隊，最好的推動敏捷的方法就是實踐，只有實踐才能發現問題，才能解決問題，最好找到一個適合本身的敏捷方法。
談談在敏捷的項目裏如何實行測試的工做。
敏捷的項目對測試的影響
- 文檔少，所以難以只是依賴文檔來設計測試。
- 短迭代，須要更短的時間完成測試的工做。
- 頻繁的變化，須要測試更具備探索性和適應性。
敏捷項目的正確測試觀念
- 項目是以結果爲導向的，因此測試一樣是結果導向。
- 不以發現缺陷多少爲目標。
- 以不斷提升軟件質量爲目標。
- 測試人員的做用是幫助開發人員不斷提升軟件的質量，是協助性的。
- 測試人員不是批判性的。
- 測試人員可以儘量的作可以作的工做，儘量的早工做。
- 「等待」在敏捷開發、敏捷測試範疇裏已經是一種錯誤概念。
敏捷測試的管理
- 敏捷項目的測試沒有嚴格的角色。人人都是測試。
- 以測試任務爲導向。測試任務便可以是開發來作，也能夠是測試人員來作。
- 相同的質量目標。開發和測試有着同一個質量目標，所以也承擔着一樣的責任。
- 關注質量的提高，測試周期與開發同步。
- 要有全局觀，不僅是專一於發現缺陷。
- 爲回滾作準備，本次迭代發佈失敗，可安全回滾至舊版本。
- 分享測試知識。
- 創建缺陷庫，指導開發人員避免再次發生一樣缺陷。
敏捷測試的執行
- 關注和推進單元測試。
- 持續改進自動化測試（由於軟件的變化，已經對產品的深刻了解）
- 短文檔（測試用例能夠不寫，測試計劃列測試點，測試類型，質量標準便可）。
- 對新增的或者引發變化的地方（可詢問開發人員協助）採起探索性測試。
- 對穩定的部分添加自動化測試。
咱們的項目以前的測試開發比例是1比5，質量基本達到客戶的要求，爲何1比5能夠，由於我說過，開發人員是能夠作測試的工做的。如今以爲惟一有不足的地方是對穩定的地方進行自動化的迴歸測試。還有，我但願在自動化的探索性測試上有所進步。
最後，我還說一點是，我看到不少項目靠加班，不會休息的團隊是不健康的團隊。其實，項目每每不是短時間行爲，一般一個產品的至少須要半年努力和投入，長
時間的超負荷運轉會使得工做效率低，身體透支等嚴重後果。項目中後期每每強度會比前期更大，這個時候，人員倒下和效率低不是一件好事情。因此，若是你的項目還要長期發展，應該幫助團隊認識到輕鬆的團隊氛圍，張弛有度的工做安排是項目成功的最好方式。
固然，不加班，不表明上班時間很差好乾。咱們要求就是8小時之內，每週40小時。
