敏捷测试介绍
敏捷測試介紹
有一次，當(dāng)開發(fā)人員完成當(dāng)前Sprint 任務(wù)的代碼之后，測試人員、開發(fā)人員和產(chǎn)品經(jīng)理一起來瀏覽產(chǎn)品、從頭到尾走一遍，產(chǎn)品經(jīng)理發(fā)現(xiàn)了問題，認(rèn)為需要對(duì)功能進(jìn)行比較大的修改。這時(shí)開發(fā)人員估計(jì)需要兩天時(shí)間才能完成代碼，但測試人員反對(duì)這樣做，我們本來只有5天測試時(shí)間，加上這次新做的功能比較多、開發(fā)代碼質(zhì)量不高，驗(yàn)收測試已經(jīng)很緊張。如果再延遲兩天，測試沒法完成。產(chǎn)品經(jīng)理說，你們不是在用敏捷測試方法，應(yīng)該測得很快，三天應(yīng)該能完成測試工作啊！
什么是敏捷測試呢？敏捷測試當(dāng)然不能簡單地理解為測得更快，絕對(duì)不是比以前用更少時(shí)間進(jìn)行測試，也不是將測試的范圍縮小了或?qū)?strong>質(zhì)量降低來減少測試任務(wù)。也有人說，只有敏捷開發(fā)，沒有敏捷測試。下面我們將要討論一下：
- 什么是敏捷測試？
- 敏捷測試有哪些流程改進(jìn)？
- 測試人員如何面對(duì)敏捷測試的挑戰(zhàn)？
- 在敏捷測試中如何制定相應(yīng)的自動(dòng)化測試策略？
什么是敏捷測試
假如將過去傳統(tǒng)的測試流程和方法硬塞入敏捷開發(fā)流程中，測試工作可能會(huì)事倍功半，測試人員可能會(huì)天天加班，而不能發(fā)揮應(yīng)有的作用。敏捷測試應(yīng)該是適應(yīng)敏捷方法而采用的新的測試流程、方法和實(shí)踐，對(duì)傳統(tǒng)的測試流程有所剪裁，有不同的側(cè)重，例如減少測試計(jì)劃、測試用例設(shè)計(jì)等工作的比重，增加與產(chǎn)品設(shè)計(jì)人員、開發(fā)人員的交流和協(xié)作。在敏捷測試流程中，參與單元測試，關(guān)注持續(xù)迭代的新功能，針對(duì)這些新功能進(jìn)行足夠的驗(yàn)收測試，而對(duì)原有功能的回歸測試則依賴于自動(dòng)化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時(shí)對(duì)需求、開發(fā)設(shè)計(jì)的評(píng)審，更重要的是能夠及時(shí)、持續(xù)的對(duì)軟件產(chǎn)品質(zhì)量進(jìn)行反饋。簡單地說，敏捷測試就是持續(xù)地對(duì)軟件質(zhì)量問題進(jìn)行及時(shí)地反饋，如圖1所示。
? ? ? ? ? ? ? ? ? ? ? ?
圖1 敏捷測試定義的形象描述
敏捷測試流程的優(yōu)化
在敏捷方法中，需求變化比較快、產(chǎn)品開發(fā)周期很短，我們目前采用四周時(shí)間，也就是每個(gè)月發(fā)布一個(gè)新版本。開發(fā)周期短，功能不斷累加，給軟件測試帶來很大的挑戰(zhàn)，軟件測試流程要做相應(yīng)的調(diào)整。例如，我們?cè)械臏y試規(guī)范明確規(guī)定，首先要建立項(xiàng)目的主測試計(jì)劃書，然后再建立每個(gè)功能任務(wù)的測試計(jì)劃書，測試計(jì)劃書有嚴(yán)格的模板，而且需要和產(chǎn)品經(jīng)理、開發(fā)人員討論，并和測試團(tuán)隊(duì)其他人員（包括測試經(jīng)理）討論，最終得到大家的認(rèn)可和簽字才能通過，僅測試計(jì)劃經(jīng)過“起草、評(píng)審和簽發(fā)”一個(gè)完整的周期就需要一個(gè)月。在敏捷方法中，不再要求寫幾十頁的測試計(jì)劃書，而是在每個(gè)迭代周期，寫出一頁紙的測試計(jì)劃，將測試要點(diǎn)（包括策略、特定方法、重點(diǎn)范圍等）列出來就可以了。
在原有測試規(guī)范中，要求先用Excel寫出測試用例，然后進(jìn)行討論、評(píng)審，評(píng)審?fù)ㄟ^以后再導(dǎo)入測試用例庫（在線管理系統(tǒng)）中。在敏捷測試中，可能不需要測試用例，而是針對(duì)Use Case或User Story直接進(jìn)行驗(yàn)證，并進(jìn)行探索性測試。而節(jié)約出來的時(shí)間，用于開發(fā)原有功能的自動(dòng)化測試腳本，為回歸測試服務(wù)。自動(dòng)化測試腳本將代替測試用例，成為軟件組織的財(cái)富。原有測試規(guī)范還要求進(jìn)行兩輪回歸測試，在敏捷測試中，只能進(jìn)行一輪回歸測試。綜合這些考慮，敏捷測試的流程簡單有效，如圖2所示。
?
圖2 敏捷測試流程簡要圖
在敏捷測試流程中，如前所述，測試是一個(gè)持續(xù)的質(zhì)量反饋過程，測試中發(fā)現(xiàn)的問題要及時(shí)反饋給產(chǎn)品經(jīng)理和開發(fā)人員，而且某些關(guān)鍵方面也要得到我們足夠的關(guān)注，主要有：
- 測試人員不僅要全程參與需求、產(chǎn)品功能設(shè)計(jì)等討論，而且要面對(duì)面地、充分地討論（包括帶語言、視頻的即時(shí)通訊），僅僅通過郵件是不夠的。
- 參與代碼復(fù)審（Code Review），并適當(dāng)輔助開發(fā)人員進(jìn)行單元測試。
- 在流程中增加一個(gè)環(huán)節(jié)“產(chǎn)品走查（Product Walk-through）”DEMO——測試人員和產(chǎn)品經(jīng)理、開發(fā)人員等在一起，從頭到尾將新功能看一遍，可直觀、快速地發(fā)現(xiàn)問題。
新功能的測試和回歸測試策略
測試任務(wù)簡單地可分為新功能測試和回歸測試。在敏捷方法中，針對(duì)這兩部分的測試建立相應(yīng)的策略，以提高測試的效率，最大限度地降低質(zhì)量風(fēng)險(xiǎn)。新功能測試的策略主要有：
- 不需要測試用例，直接基于用例和對(duì)需求的理解來完成新功能的驗(yàn)證。即使要寫測試用例，只要保證各個(gè)功能點(diǎn)被覆蓋，不要過于詳細(xì)（大顆粒度）。
- 持續(xù)地進(jìn)行驗(yàn)證，一旦某塊新代碼完成（Code Drop），就開始驗(yàn)證，而不是等到所有代碼完成后才開始測試。這也包括參與到單元測試和集成測試中。
- 實(shí)施端到端（End-to-End）的測試，確保完整的業(yè)務(wù)流程的實(shí)現(xiàn)，同時(shí)，也容易發(fā)現(xiàn)業(yè)務(wù)邏輯不夠清晰、不夠合理等各方面的問題。
- 閱讀代碼來發(fā)現(xiàn)問題，可以和開發(fā)人員工作保持同步，消除測試周期的壓力。
- 基于經(jīng)驗(yàn)，可以實(shí)施更多的探索性測試、組合交互性（Interoperation）測試和用戶場景(User Scenario)測試，更有效地發(fā)現(xiàn)埋藏較深的缺陷。
回歸測試是敏捷測試中需要面對(duì)的難點(diǎn)。每次迭代都會(huì)增加新的功能，一個(gè)產(chǎn)品可能會(huì)經(jīng)過十幾次、甚至幾十次迭代，回歸測試范圍在不斷增大，而每次迭代周期沒變，可能還是一個(gè)月。這樣驗(yàn)收測試的時(shí)間非常有限，所以回歸測試很大程度上依賴于自動(dòng)化測試，因?yàn)楹茈y將回歸測試控制在非常有限的范圍內(nèi)。當(dāng)然，還是有些辦法可以幫助我們減少回歸測試的范圍，例如：
- 通過執(zhí)行Code Diff 來了解代碼變動(dòng)的所有地方，再做代碼關(guān)聯(lián)分析，就可以明確知道要進(jìn)行哪些地方的回歸測試，回歸測試范圍會(huì)大大縮小。
- 基于風(fēng)險(xiǎn)和操作面分析來減少回歸測試的范圍，例如回歸測試只是保證主要功能點(diǎn)沒有問題，而忽視一些細(xì)節(jié)的問題。
- 持續(xù)測試的過程，只要有時(shí)間，就進(jìn)行測試，包括開發(fā)人員、產(chǎn)品設(shè)計(jì)人員都參與到日常的試用和測試中來。
自動(dòng)化測試策略
由于開發(fā)周期短，需求、設(shè)計(jì)等方面溝通也需要花費(fèi)很多時(shí)間，沒有足夠時(shí)間開發(fā)自動(dòng)化測試腳本，至少對(duì)新功能的測試很難實(shí)現(xiàn)自動(dòng)化測試。這時(shí)候，就需要正確的策略來提高自動(dòng)化測試的效益，如圖3所示，并說明如下。
?
圖3 自動(dòng)化測試的策略
- 構(gòu)建一個(gè)靈活的、開放的自動(dòng)化測試框架，如基于關(guān)鍵字驅(qū)動(dòng)的自動(dòng)化框架，使測試腳本的開發(fā)簡單易行，腳本維護(hù)也方便。
- 針對(duì)穩(wěn)定的產(chǎn)品特性開發(fā)自動(dòng)化測試腳本，也就是針對(duì)前期完成的已有功能開發(fā)自動(dòng)化測試的腳本,小部分主要功能自動(dòng)化,而大部分新功能測試采用手工測試
- 集中精力在單元層次上實(shí)現(xiàn)自動(dòng)化測試，主要由開發(fā)人員實(shí)施，測試人員提供單元測試框架，并輔助完成一些所需的基礎(chǔ)工作。
- 在產(chǎn)品設(shè)計(jì)、編程時(shí)就很好地考慮了自動(dòng)化測試的需求，使全面的、自動(dòng)化的底層測試、接口測試成為可能，盡量避免用戶界面（UI）的自動(dòng)化測試。
- 良好的IT基礎(chǔ)設(shè)施，包括自動(dòng)化構(gòu)建軟件包、自動(dòng)化版本驗(yàn)證（BVT）、自動(dòng)化部署、覆蓋率自動(dòng)產(chǎn)生等。
敏捷測試工具
自動(dòng)化測試依賴于測試工具，所幸的是，目前已有很多敏捷測試工具。由于篇幅所限，這里只是簡單地列出一些常用的敏捷測試工具，不再深入討論了。
- 單元測試工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
- 功能測試自動(dòng)化：ThoughtWorks Twist。
- Web功能測試（frontend）：Selenium IDE/RC、WatiR、WatiN。
- Web service測試工具（backend）：soapUI。
- 性能測試：JMeter+BadBoy。
- 驗(yàn)收測試框架：Fitnesse、Tellurium。
- 敏捷測試過程管理工具：微軟的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
- 業(yè)務(wù)智能（BI）應(yīng)用的測試框架：Oraylis BI.Quality （+ NUnit）。
- 其他一些協(xié)作工具等，如TestLink、BugZilla、BugFree、Wiki等。
測試人員在敏捷方法中的價(jià)值
在敏捷方法中，開發(fā)人員的主導(dǎo)作用更明顯，系統(tǒng)設(shè)計(jì)、編程實(shí)現(xiàn)、單元測試、重構(gòu)等看似關(guān)鍵的一些任務(wù)都落在開發(fā)人員身上，測試人員容易被邊緣化。那么，在敏捷方法中，測試人員的價(jià)值又如何體現(xiàn)呢？
- 在需求和功能設(shè)計(jì)討論上，測試人員可以站在客戶角度來闡述自己的觀點(diǎn)，扮演“用戶代表”角色，強(qiáng)調(diào)用戶體驗(yàn)，真正體現(xiàn)測試人員和開發(fā)人員的互補(bǔ)作用。
- 測試人員不僅扮演“用戶代表”角色，而且通過需求討論、代碼復(fù)審等各種活動(dòng)及時(shí)地提供質(zhì)量反饋，包括代碼質(zhì)量、接口一致性等，保證在產(chǎn)品構(gòu)造的整個(gè)過程中質(zhì)量受到足夠的關(guān)注，以提高質(zhì)量改進(jìn)的持續(xù)性和可視性。
- 測試人員應(yīng)積極參與單元測試，即使不參加單元測試，也應(yīng)督促開發(fā)人員進(jìn)行單元測試，確保單元測試達(dá)到80% 以上覆蓋率，確保開發(fā)出具有良好可測試性的代碼。
- 在敏捷方法中，往往將一個(gè)大的系統(tǒng)開發(fā)分解成多個(gè)小的子系統(tǒng)（模塊或組件），集成測試和端到端（End-to-End）測試顯得更為重要，測試人員在這些測試上能發(fā)揮更大的作用。
- 產(chǎn)品發(fā)布前，驗(yàn)收測試和回歸測試依然不可缺少，這更是測試人員的用武之地。
- 一個(gè)迭代周期結(jié)束后，對(duì)缺陷根本原因進(jìn)行分析、總結(jié)規(guī)律，幫助開發(fā)人員建立良好的習(xí)慣，預(yù)防缺陷，從根本上提高產(chǎn)品質(zhì)量。
理想情況下，測試人員掌握設(shè)計(jì)模式、具有很好的編程能力，可以和開發(fā)人員進(jìn)行角色互換，如在當(dāng)前版本開發(fā)中擔(dān)任測試人員角色，在下一個(gè)版本開發(fā)中則擔(dān)任開發(fā)人員角色。這樣雙方對(duì)不同角色的工作有著更深刻的認(rèn)識(shí)，消除溝通的障礙，開發(fā)的效率和質(zhì)量會(huì)有進(jìn)一步的提高。
總結(jié)
根據(jù)上面的討論和我們的實(shí)踐，最后針對(duì)敏捷測試進(jìn)行一個(gè)簡單的總結(jié)，就是：
- 敏捷測試就是持續(xù)測試、持續(xù)反饋，扮演“用戶代表”角色，確保產(chǎn)品滿足客戶的需求。
- 敏捷功能測試 = 新特性的手工測試（Use Case驗(yàn)證和探索性測試）+新功能的BVT測試(建議有) + 原有功能的自動(dòng)化測試 （回歸測試）。作為一個(gè)偷巧的辦法，某些情況下，可以對(duì)代碼進(jìn)行diff 檢查，比較代碼改動(dòng)的部分，讓測試更有針對(duì)性。
- 合理的利用自動(dòng)化。自動(dòng)化并不是越多越好。自動(dòng)化可以保證已有功能的回歸。對(duì)新增的功能，需要評(píng)估到底是自動(dòng)化效率高還是手動(dòng)測試效率高？我更傾向于對(duì)新增功能執(zhí)行手動(dòng)或者半自動(dòng)化的測試，而在產(chǎn)品發(fā)布之后再補(bǔ)充完善自動(dòng)化回歸腳本。隨著開發(fā)的進(jìn)行，產(chǎn)品質(zhì)量的提升，以及對(duì)產(chǎn)品了解程度的加深，對(duì)自動(dòng)化測試進(jìn)行持續(xù)改進(jìn)，提供更大的覆蓋，更好和更快速的驗(yàn)證。
- 敏捷開發(fā)追求持續(xù)的集成，持續(xù)的進(jìn)行單元測試和回歸測試。我們計(jì)劃與過程改進(jìn)一起推進(jìn)Check-In Test, BVT, daily regression test的自動(dòng)化，讓開發(fā)人員隨時(shí)可以得到關(guān)于代碼質(zhì)量的反饋（例如，每一次的check-in是否break了build），幫助開發(fā)人員生產(chǎn)出具有良好可測試性的代碼，進(jìn)而提升測試的效率。幫助開發(fā)，就是幫助測試自己。
- 通過自動(dòng)化和測試報(bào)告，建立可見的質(zhì)量度量體系，讓產(chǎn)品和代碼質(zhì)量反饋持續(xù)可
- 讓測試用例更有效率，避免在測試用例上面浪費(fèi)太多的時(shí)間。測試用例不是越多越詳細(xì)就好。太詳細(xì)的測試用例會(huì)降低測試效率，增加維護(hù)成本，并且會(huì)限制測試執(zhí)行人員的思維。如果你的Bug大部分是通過執(zhí)行測試用例發(fā)現(xiàn)的，那說明有兩個(gè)問題：你在測試用例上面浪費(fèi)了太多的時(shí)間，或者你在測試經(jīng)驗(yàn)上面比較欠缺。如何定義測試用例的粒度——從業(yè)務(wù)出發(fā)，測試用例只要覆蓋所有的業(yè)務(wù)功能和邏輯就夠了。而數(shù)據(jù)檢查、邊界條件的測試用例，就留給測試人員去執(zhí)行探索性的測試吧，希望每個(gè)人都增強(qiáng)探索性測試的意識(shí)。
- 為各系統(tǒng)維護(hù)一套測試點(diǎn)的checklist，越精簡越好。讓負(fù)責(zé)測試的人員（尤其是新手）能在幾分鐘之內(nèi)就知道有哪些測試點(diǎn)是被遺漏的、需要關(guān)注的。我們已經(jīng)把部分的checklist放在在wiki上了（例如引擎測試），希望大家都能參與進(jìn)來，不斷補(bǔ)充完善。
- 前端應(yīng)用的測試：UI變更頻繁，測試非常容易失效？是否可以考慮把測試重心向相對(duì)穩(wěn)定的接口測試傾斜？大家可以一起來思考。
- 開發(fā)和測試團(tuán)隊(duì)具有同樣的質(zhì)量目標(biāo)和質(zhì)量責(zé)任。開發(fā)人員有義務(wù)對(duì)產(chǎn)品的可測試性和可自動(dòng)化負(fù)責(zé)。如果你有這方面的需求，一定要跟開發(fā)人員講出來。
- 敏捷測試人員和開發(fā)人員的區(qū)別越來越小，理想情況下，敏捷方法中，測試人員和開發(fā)人員在不同的迭代周期可以互換。
- 敏捷測試流程依據(jù)不同的團(tuán)隊(duì)特點(diǎn)、不同產(chǎn)品的特點(diǎn)而不同，因地制宜，適合才是最好。
?
敏捷測試的定義
l 強(qiáng)調(diào)從客戶的角度，即使用系統(tǒng)的用戶的角度，來測試系統(tǒng)
l 重點(diǎn)關(guān)注持續(xù)迭代的測試新開發(fā)的功能，而不再強(qiáng)調(diào)傳統(tǒng)測試過程中嚴(yán)格的測試階段。
l 建議盡早開始測試，一旦系統(tǒng)某個(gè)層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時(shí)隨著測試深入，持續(xù)進(jìn)行回歸測試保證之前測試過內(nèi)容的正確性
轉(zhuǎn)載于:https://www.cnblogs.com/binyao/p/3272063.html
總結(jié)
- 上一篇： POJ 3034 Whac-a-Mole
- 下一篇： Ecsotre 参考