<ruby id="rxdll"></ruby><strike id="rxdll"></strike>

    <rp id="rxdll"></rp>
      <del id="rxdll"><meter id="rxdll"></meter></del>
      <pre id="rxdll"><font id="rxdll"></font></pre>
        <pre id="rxdll"></pre>
      <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

      <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
      <i id="rxdll"><dfn id="rxdll"></dfn></i>
      <font id="rxdll"><meter id="rxdll"></meter></font>

        <mark id="rxdll"><dfn id="rxdll"></dfn></mark>
        • 軟件測試技術
        • 軟件測試博客
        • 軟件測試視頻
        • 開源軟件測試技術
        • 軟件測試論壇
        • 軟件測試沙龍
        • 軟件測試資料下載
        • 軟件測試雜志
        • 軟件測試人才招聘
          暫時沒有公告

        字號: | 推薦給好友 上一篇 | 下一篇

        敏捷測試的方法和最佳實踐

        發布: 2011-2-28 09:48 | 作者: 朱少民 | 來源: 領測軟件測試網采編 | 查看: 306次 | 進入軟件測試論壇討論

        領測軟件測試網

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

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

          l 究竟什么是敏捷測試?

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

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

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

          等等各種問題。

          1. 什么是敏捷測試

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

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

          2. 敏捷測試流程的優化

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

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

          圖2 敏捷測試流程簡要圖

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

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

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

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

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

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

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

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

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

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

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

        延伸閱讀

        文章來源于領測軟件測試網 http://www.k11sc111.com/

        21/212>

        關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
        版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
        北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備10010545號-5
        技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

        軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

        国产女主播精品_国产片婬乱18一级毛片视频_国产午夜激无码av毛片不卡_国产精品欧美久久久天天影院
          <ruby id="rxdll"></ruby><strike id="rxdll"></strike>

          <rp id="rxdll"></rp>
            <del id="rxdll"><meter id="rxdll"></meter></del>
            <pre id="rxdll"><font id="rxdll"></font></pre>
              <pre id="rxdll"></pre>
            <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

            <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
            <i id="rxdll"><dfn id="rxdll"></dfn></i>
            <font id="rxdll"><meter id="rxdll"></meter></font>

              <mark id="rxdll"><dfn id="rxdll"></dfn></mark>