敏捷測試的方法和實踐

發表于:2014-03-03來源:豆瓣作者:@行知-追尋技術之美點擊數: 標簽:敏捷測試
以前做開發的時候,我們嘗試過敏捷,現在回過來想想,當時我們的測試人員比開發更加迷茫,常常會不知道如何開始自己的工作?,F在,回到測試的崗位,重新思考這個問題,發現還是很難定義敏捷過程中測試的一些定義,下面是朱少民在程序員雜志上發表的一篇文章,

  以前做開發的時候,我們嘗試過敏捷,現在回過來想想,當時我們的測試人員比開發更加迷茫,常常會不知道如何開始自己的工作?,F在,回到測試的崗位,重新思考這個問題,發現還是很難定義敏捷過程中測試的一些定義,下面是朱少民在程序員雜志上發表的一篇文章,我覺得很有用處,分享之:

  有一次,當開發人員完成當前Sprint 任務的代碼之后,測試人員、開發人員和產品經理一起來瀏覽產品、從頭到尾走一遍,產品經理發現了問題,認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成代碼,但測試人員反對這樣做,我們本來只有5天測試時間,加上這次新做的功能比較多、開發代碼質量不高,驗收測試已經很緊張。如果再延遲兩天,測試沒法完成。產品經理說,你們不是在用敏捷測試方法,應該測得很快,三天應該能完成測試工作啊!

  什么是敏捷測試呢?敏捷測試當然不能簡單地理解為測得更快,絕對不是比以前用更少時間進行測試,也不是將測試的范圍縮小了或將質量降低來減少測試任務。也有人說,只有敏捷開發,沒有敏捷測試。下面我們將要討論一下:

  究竟什么是敏捷測試?

  敏捷測試有哪些流程改進?

  測試人員如何面對敏捷測試的挑戰?

  在敏捷測試中如何制定相應的自動化測試策略?

  什么是敏捷測試

  假如將過去傳統的測試流程和方法硬塞入敏捷開發流程中,測試工作可能會事倍功半,測試人員可能會天天加班,而不能發揮應有的作用。敏捷測試應該是適應敏捷方法而采用的新的測試流程、方法和實踐,對傳統的測試流程有所剪裁,有不同的側重,例如減少測試計劃、測試用例設計等工作的比重,增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中,參與單元測試,關注持續迭代的新功能,針對這些新功能進行足夠的驗收測試,而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短,測試人員盡早開始測試,包括及時對需求、開發設計的評審,更重要的是能夠及時、持續的對軟件產品質量進行反饋。簡單地說,敏捷測試就是持續地對軟件質量問題進行及時地反饋,如圖1所示。

圖1  敏捷測試定義的形象描述

  圖1 敏捷測試定義的形象描述

  敏捷測試流程的優化

  在敏捷方法中,需求變化比較快、產品開發周期很短,我們目前采用四周時間,也就是每個月發布一個新版本。開發周期短,功能不斷累加,給軟件測試帶來很大的挑戰,軟件測試流程要做相應的調整。例如,我們原有的測試規范明確規定,首先要建立項目的主測試計劃書,然后再建立每個功能任務的測試計劃書,測試計劃書有嚴格的模板,而且需要和產品經理、開發人員討論,并和測試團隊其他人員(包括測試經理)討論,最終得到大家的認可和簽字才能通過,僅測試計劃經過“起草、評審和簽發”一個完整的周期就需要一個月。在敏捷方法中,不再要求寫幾十頁的測試計劃書,而是在每個迭代周期,寫出一頁紙的測試計劃,將測試要點(包括策略、特定方法、重點范圍等)列出來就可以了。

  在原有測試規范中,要求先用Excel寫出測試用例,然后進行討論、評審,評審通過以后再導入測試用例庫(在線管理系統)中。在敏捷測試中,可能不需要測試用例,而是針對Use Case或User Story直接進行驗證,并進行探索性測試。而節約出來的時間,用于開發原有功能的自動化測試腳本,為回歸測試服務。自動化測試腳本將代替測試用例,成為軟件組織的財富。原有測試規范還要求進行兩輪回歸測試,在敏捷測試中,只能進行一輪回歸測試。綜合這些考慮,敏捷測試的流程簡單有效,如圖2所示。

圖2  敏捷測試流程簡要圖

  圖2 敏捷測試流程簡要圖

  在敏捷測試流程中,如前所述,測試是一個持續的質量反饋過程,測試中發現的問題要及時反饋給產品經理和開發人員,而且某些關鍵方面也要得到我們足夠的關注,主要有:

  測試人員不僅要全程參與需求、產品功能設計等討論,而且要面對面地、充分地討論(包括帶語言、視頻的即時通訊),僅僅通過郵件是不夠的。

  參與代碼復審(Code Review),并適當輔助開發人員進行單元測試。

  在流程中增加一個環節“產品走查(Product Walk-through)”——測試人員和產品經理、開發人員等在一起,從頭到尾將新功能看一遍,可直觀、快速地發現問題。

  新功能的測試和回歸測試策略

  測試任務簡單地可分為新功能測試和回歸測試。在敏捷方法中,針對這兩部分的測試建立相應的策略,以提高測試的效率,最大限度地降低質量風險。新功能測試的策略主要有:

  不需要測試用例,直接基于用例和對需求的理解來完成新功能的驗證。即使要寫測試用例,只要保證各個功能點被覆蓋,不要過于詳細(大顆粒度)。

  持續地進行驗證,一旦某塊新代碼完成(Code Drop),就開始驗證,而不是等到所有代碼完成后才開始測試。這也包括參與到單元測試和集成測試中。

  實施端到端(End-to-End)的測試,確保完整的業務流程的實現,同時,也容易發現業務邏輯不夠清晰、不夠合理等各方面的問題。

  閱讀代碼來發現問題,可以和開發人員工作保持同步,消除測試周期的壓力。

  基于經驗,可以實施更多的探索性測試、組合交互性(Interoperation)測試和用戶場景(User Scenario)測試,更有效地發現埋藏較深的缺陷。

  回歸測試是敏捷測試中需要面對的難點。每次迭代都會增加新的功能,一個產品可能會經過十幾次、甚至幾十次迭代,回歸測試范圍在不斷增大,而每次迭代周期沒變,可能還是一個月。這樣驗收測試的時間非常有限,所以回歸測試很大程度上依賴于自動化測試,因為很難將回歸測試控制在非常有限的范圍內。當然,還是有些辦法可以幫助我們減少回歸測試的范圍,例如:

  通過執行Code Diff 來了解代碼變動的所有地方,再做代碼關聯分析,就可以明確知道要進行哪些地方的回歸測試,回歸測試范圍會大大縮小。

原文轉自:http://www.wangyuxiong.com/archives/51277

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97