1、敏捷測試,1,2,2,目錄,一、敏捷測試介紹 二、敏捷測試實踐 三、敏捷測試核心價值及帶來的挑戰(zhàn),2,2,一、敏捷測試介紹,1.1 敏捷測試定義 1.2 敏捷測試實質(zhì) 1.3 敏捷測試流程 1.4 敏捷測試與傳統(tǒng)測試對比,3,什么是我們談論的敏捷測試？,4,2,1.1 敏捷測試的定義,首先敏捷測試(Agile testing)是測試的一種，原有測試定義中通過執(zhí)行被測系統(tǒng)發(fā)現(xiàn)問題，通過測試這種活動能夠提供對被測系統(tǒng)提供度量等概念還是適用的。 敏捷測試是遵循敏捷宣言的一種測試實踐： 1、強調(diào)從客戶的角度，即是從使用系統(tǒng)的用戶的角度，來測試系統(tǒng)。 2、重點關(guān)注持續(xù)迭代的測試新開發(fā)的功能，而不再強調(diào)傳

2、統(tǒng)測試過程中嚴格的測試階段。 3、建議盡早開始測試，一旦系統(tǒng)某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨著測試深入，持續(xù)進行回歸測試保證之前測試過內(nèi)容的正確性。,5,2,1.2 敏捷測試定義的形象描述,6,2,1.3 敏捷測試的實質(zhì),假如將過去傳統(tǒng)的測試流程和方法硬塞入敏捷開發(fā)流程中，測試工作可能會事倍功半，測試人員可能會天天加班，而不能發(fā)揮應有的作用。敏捷測試應該是適應敏捷方法而采用的新的測試流程、方法和實踐，對傳統(tǒng)的測試流程有所剪裁，有不同的側(cè)重，例如減少測試計劃、測試用例設(shè)計等工作的比重，增加與產(chǎn)品設(shè)計人員、開發(fā)人員的交流和協(xié)作。在敏捷測試流程中，參與單元測試，關(guān)

3、注持續(xù)迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發(fā)設(shè)計的評審，更重要的是能夠及時、持續(xù)的對軟件產(chǎn)品質(zhì)量進行反饋。,7,2,敏捷測試的實質(zhì),簡而言之，敏捷測試就是持續(xù)地對軟件質(zhì)量問題進行及時地反饋 . 同時，敏捷測試也意味著測試遵循敏捷的基本原則，接納敏捷的核心價值觀（交流，簡單，反饋，勇氣） 保持簡單 以任務為導向，而不以過程或是角色為導向 通過溝通和反饋保證測試能夠建立合適的質(zhì)量標準 盡可能減少測試周期的時間需求 敏捷測試要求“交付可用產(chǎn)品”而非單純的“發(fā)現(xiàn)缺陷”,8,2,關(guān)于敏

4、捷測試我們知道多少？,9,2,1.4 敏捷測試VS傳統(tǒng)測試,10,2,傳統(tǒng)的測試,在原有測試規(guī)范中，要求先用Excel寫出測試用例，然后進行討論、評審，評審通過以后再導入測試用例庫（在線管理系統(tǒng)）中。,11,2,敏捷的測試,在敏捷方法中，需求變化比較快、產(chǎn)品開發(fā)周期很短，我們目前采用四周時間，也就是每個月發(fā)布一個新版本。開發(fā)周期短，功能不斷累加，給軟件測試帶來很大的挑戰(zhàn)，軟件測試流程要做相應的調(diào)整。例如，我們原有的測試規(guī)范明確規(guī)定，首先要建立項目的主測試計劃書，然后再建立每個功能任務的測試計劃書，測試計劃書有嚴格的模板，而且需要和產(chǎn)品經(jīng)理、開發(fā)人員討論，并和測試團隊其他人員（包括測試經(jīng)理）討論

5、，最終得到大家的認可和簽字才能通過，僅測試計劃經(jīng)過“起草、評審和簽發(fā)”一個完整的周期就需要一個月。在敏捷方法中，不再要求寫幾十頁的測試計劃書，而是在每個迭代周期，寫出一頁紙的測試計劃，將測試要點（包括策略、特定方法、重點范圍等）列出來就可以了。,12,2,敏捷測試流程,在敏捷測試中，可能不需要測試用例，而是針對Use Case或User Story直接進行驗證，并進行探索性測試。而節(jié)約出來的時間，用于開發(fā)原有功能的自動化測試腳本，為回歸測試服務。自動化測試腳本將代替測試用例，成為軟件組織的財富。原有測試規(guī)范還要求進行兩輪回歸測試，在敏捷測試中，只能進行一輪回歸測試。綜合這些考慮，敏捷測試的流程

6、簡單有效，如下圖所示。,13,2,敏捷測試流程,14,2,敏捷測試流程,在敏捷測試流程中，如前所述，測試是一個持續(xù)的質(zhì)量反饋過程，測試中發(fā)現(xiàn)的問題要及時反饋給產(chǎn)品經(jīng)理和開發(fā)人員，而且某些關(guān)鍵方面也要得到我們足夠的關(guān)注，主要有： 測試人員不僅要全程參與需求、產(chǎn)品功能設(shè)計等討論，而且要面對面地、充分地討論（包括帶語言、視頻的即時通訊），僅僅通過郵件是不夠的。 參與代碼復審（Code Review），并適當輔助開發(fā)人員進行單元測試。 在流程中增加一個環(huán)節(jié)“產(chǎn)品走查（Product Walk-through）”測試人員和產(chǎn)品經(jīng)理、開發(fā)人員等在一起，從頭到尾將新功能看一遍，可直觀、快速地發(fā)現(xiàn)問題。,15

7、,2,2,敏捷測試體現(xiàn)的與傳統(tǒng)測試的不同,作用于產(chǎn)品（Critique product）的測試 探索性測試（Exploratory Testing） 場景測試（Scenario Testing） 用戶驗收測試（UAT） 性能測試，安全性測試 作用于支持團隊（Supporting the team）的測試 單元測試 模塊/組件級別的測試 功能測試 用戶故事（User Story）測試 ,16,2,二、敏捷測試實踐,2.1 測試過程 2.2 測試策略 2.3 測試方法 2.4 測試工具,17,2.1測試過程,針對一個迭代周期 計劃一個迭代周期內(nèi)的測試 了解細節(jié)，確定測試范圍 創(chuàng)建并執(zhí)行測試 發(fā)布

8、敏捷測試中的持續(xù)任務 提高代碼質(zhì)量與產(chǎn)品質(zhì)量 從更多層面建立測試（單元測試、模塊測試、系統(tǒng)測試等） 建立產(chǎn)品的質(zhì)量度量 改進自動化測試（更穩(wěn)定，更高的覆蓋率）,18,2,2.1測試過程,計劃的內(nèi)容 產(chǎn)品發(fā)布標準（驗收測試準則） 需要在本迭代周期內(nèi)測試的內(nèi)容 需要安排的測試類型 需要使用的測試環(huán)境（包括數(shù)據(jù)） 管理計劃管理 一頁紙測試計劃（ One Page Test Plan） 可以使用各種形式表達測試計劃：在線文檔，測試點列表，自動測試列表，白板或是電子表格,19,2,2.2敏捷測試策略,2.2.1 新功能的測試和回歸測試策略 2.2.2 自動化測試策略,20,2,2.2.1 新功能的測試和

9、回歸測試策略,測試任務簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應的策略，以提高測試的效率，最大限度地降低質(zhì)量風險。新功能測試的策略主要有： 不需要測試用例，直接基于用例和對需求的理解來完成新功能的驗證。即使要寫測試用例，只要保證各個功能點被覆蓋，不要過于詳細（大顆粒度）。 持續(xù)地進行驗證，一旦某塊新代碼完成（Code Drop），就開始驗證，而不是等到所有代碼完成后才開始測試。這也包括參與到單元測試和集成測試中。 實施端到端（End-to-End）的測試，確保完整的業(yè)務流程的實現(xiàn)，同時，也容易發(fā)現(xiàn)業(yè)務邏輯不夠清晰、不夠合理等各方面的問題。 閱讀代碼來發(fā)現(xiàn)問題，可

10、以和開發(fā)人員工作保持同步，消除測試周期的壓力。 基于經(jīng)驗，可以實施更多的探索性測試、組合交互性（Interoperation）測試和用戶場景(User Scenario)測試，更有效地發(fā)現(xiàn)埋藏較深的缺陷。,21,2,2.2.1 新功能的測試和回歸測試策略,回歸測試是敏捷測試中需要面對的難點。每次迭代都會增加新的功能，一個產(chǎn)品可能會經(jīng)過十幾次、甚至幾十次迭代，回歸測試范圍在不斷增大，而每次迭代周期沒變，可能還是一個月。這樣驗收測試的時間非常有限，所以回歸測試很大程度上依賴于自動化測試，因為很難將回歸測試控制在非常有限的范圍內(nèi)。當然，還是有些辦法可以幫助我們減少回歸測試的范圍，例如： 通過執(zhí)行Co

11、de Diff 來了解代碼變動的所有地方，再做代碼關(guān)聯(lián)分析，就可以明確知道要進行哪些地方的回歸測試，回歸測試范圍會大大縮小。 基于風險和操作面分析來減少回歸測試的范圍，例如回歸測試只是保證主要功能點沒有問題，而忽視一些細節(jié)的問題。 持續(xù)測試的過程，只要有時間，就進行測試，包括開發(fā)人員、產(chǎn)品設(shè)計人員都參與到日常的試用和測試中來。,22,2,2.2.2自動化測試策略,由于開發(fā)周期短，需求、設(shè)計等方面溝通也需要花費很多時間，沒有足夠時間開發(fā)自動化測試腳本，至少對新功能的測試很難實現(xiàn)自動化測試。這時候，就需要正確的策略來提高自動化測試的效益，如圖所示，并說明如下。,23,2,2.2.2自動化測試策略,

12、24,2,2.2.2自動化測試策略,構(gòu)建一個靈活的、開放的自動化測試框架，如基于關(guān)鍵字驅(qū)動的自動化框架，使測試腳本的開發(fā)簡單易行，腳本維護也方便。 針對穩(wěn)定的產(chǎn)品特性開發(fā)自動化測試腳本，也就是針對前期完成的已有功能開發(fā)自動化測試的腳本，而大部分新功能測試采用手工測試 集中精力在單元層次上實現(xiàn)自動化測試，主要由開發(fā)人員實施，測試人員提供單元測試框架，并輔助完成一些所需的基礎(chǔ)工作。 在產(chǎn)品設(shè)計、編程時就很好地考慮了自動化測試的需求，使全面的、自動化的底層測試、接口測試成為可能，盡量避免用戶界面（UI）的自動化測試。 良好的IT基礎(chǔ)設(shè)施，包括自動化構(gòu)建軟件包、自動化版本驗證（BVT）、自動化部署、覆

13、蓋率自動產(chǎn)生等。,25,2,2.2.3 敏捷測試中的測試方法,探索性測試：主要用于探索和測試新功能，或是基于對應用的了解發(fā)現(xiàn)可能的缺陷 基于腳本的手工測試：在某些無法自動化測試的部分，使用手工測試或是半自動測試執(zhí)行某些回歸測試用例 自動化測試 從不同層次/級別驗證應用 性能測試，安全性測試，模糊測試（Fuzz Testing）等 通過重構(gòu)等方式建立更加穩(wěn)定的自動化測試,26,2,2.2.4測試工具,單元測試與模塊測試 xUnit工具 Mock工具 HTTP/HTML層面測試工具 HttpUnit WebDriver(HtmlUnit) UI層面的測試工具 Selenium/Webdriver

14、Watir/WatiN,27,2,2.2.4 測試工具,性能測試工具 JMeter 持續(xù)集成工具 安全性測試工具 其他測試工具 Link Checker Crawler Fuzz測試工具,28,2,2.2.4用自動化手段幫助確定測試范圍,Diff技術(shù),29,2,Diff工具,Diff的作用 識別應用中發(fā)生變化的部分 包括對接口，UI等各層面的檢查 發(fā)生變化的部分是需要重點測試和覆蓋的部分 不同的Diff方法 HTML diff DOM tree diff Image Diff 接口數(shù)據(jù)Diff ,30,2,三 敏捷測試核心價值及帶來的挑戰(zhàn),3.1 敏捷測試的核心價值 3.2 敏捷測試帶來的挑戰(zhàn)

15、 3.3 如何組建敏捷測試團隊,31,2,3.1 敏捷測試核心價值觀,共享質(zhì)量目標 開發(fā)和測試團隊共享同樣的質(zhì)量目標，當然也共享同樣的質(zhì)量責任，每個工程師在測試方面都同樣承擔任務 在產(chǎn)品中內(nèi)建可測試性 為產(chǎn)品建立更好的自動化測試不僅僅依賴于測試工程師的工作，更重要的是，產(chǎn)品本身內(nèi)建的可測試性 關(guān)注產(chǎn)品質(zhì)量的提升，測試周期的縮短，而不是僅專注于發(fā)現(xiàn)缺陷,32,2,3.2 敏捷測試帶來的挑戰(zhàn),質(zhì)量文化上的挑戰(zhàn) 發(fā)現(xiàn)缺陷 vs. 在產(chǎn)品中內(nèi)建質(zhì)量 敏捷帶來的擔心：測試工程師應該做什么？ 敏捷帶來的擔心：測試工程師能夠做什么？,33,2,3.2敏捷測試中的測試工程師可以做什么,獲取和明確用戶的質(zhì)量期望 建立合適的系統(tǒng)測試、用戶驗收測試質(zhì)量標準 建立可見的質(zhì)量度量體系，讓產(chǎn)品和代碼質(zhì)量反饋持續(xù)可見 推進單元測試、開發(fā)測試，促進代碼質(zhì)量 建立持續(xù)構(gòu)建框架 建立與維護合適的自動化測試以減少測試的時間投入,34,2,3.2 敏捷測試帶來的挑戰(zhàn),測試工程師面臨的挑戰(zhàn) 必須通過與開發(fā)團隊的密切合作獲取產(chǎn)品信息，制定測試計劃而不是依賴文檔 必須密切介入開發(fā)過程，參與設(shè)計，甚至是代碼 必須能夠自我驅(qū)動 必須具有足夠的自動化測試技能與探索性測試技能,35,2,3.2 敏捷測試帶來的挑戰(zhàn),與開發(fā)工程師密切合作