敏捷開發(fā)測試規(guī)范

敏捷開發(fā)測試規(guī)范（試行）2012年9月版本記錄版本號日期修改人描述V0.12012/9周本文V0.1目錄1概述 31.1編寫目的 31.2讀者對象 31.3術語定義 32敏捷測試流程 32.1需求驗證 42.2用例設計 42.3用例審核與維護 錯誤!未定義書簽。2.4測試計劃 42.5測試實施運行 42.6版本控制 52.7需求變更 62.8迭代末期“bug大掃除” 63敏捷測試方法與策略 73.1持續(xù)測試、持續(xù)反饋 73.2單元測試方法策略 73.3功能測試方法策略 73.4性能測試方法 83.5系統(tǒng)測試策略 93.6測試驅動研發(fā) 93.7持續(xù)集成測試 104終端移動互聯網測試 114.1用戶體驗測試 114.2平臺兼容性測試 124.3不同網絡環(huán)境下測試 124.4多事務并發(fā)測試 124.5安裝、卸載測試 135測試工具和環(huán)境 135.1單元測試工具 135.2功能回歸測試工具 145.3性能測試工具 145.4持續(xù)集成測試環(huán)境 146測試人員要求 146.1人力需求 146.2測試人員能力要求 147附錄 16 敏捷開發(fā)模式中，測試與研發(fā)緊密結合在一起。測試主要有兩種：單元測試和驗證/接收測試。單元測試一般是由開發(fā)人員來完成的，接收測試是由客戶代表來完成。由于客戶通常無法在現場，一般由測試人員做驗證測試，最后由客戶進行接收測試。在每個版本發(fā)布給客戶之前必須由測試人員進行測試，發(fā)布版本之后由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下后面的迭代中完成?！卧獪y試在每日構件版本給測試前，開發(fā)首先要做單元測試，提前告知軟件中的薄弱環(huán)節(jié)，幫助測試人員調整測試重點。做單元測試的好處是可以提高版本質量，減輕測試的工作量，減少淺層次的bug的發(fā)生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面?！を炞C測試測試人員的驗證測試從總體上說就是將測試用例按計劃付諸實施的過程，以及驗證故障修復是否會引入新的故障。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現在開發(fā)和測試的相互協(xié)調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，測試執(zhí)行的一開始可以是針對部分用戶故事的，之后可以逐步擴展。接著開始采用迭代的過程完成測試任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性/用戶故事測試，可以對代碼中的可復用部分（組件，構件）做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最后的幾個迭代應該用于完整的回歸測試，和關鍵的性能和穩(wěn)定性測試?！っ咳諛嫾姹緶y試敏捷開發(fā)過程中除每個迭代中持續(xù)集成版本以外，還會有每日構件版本，每日構件版本測試用以驗證前天修復的故障，以及測試故障修復是否會引入新的故障。2.6版本控制 敏捷開發(fā)強調快速開發(fā)，持續(xù)集成。版本包括每日構件版本、持續(xù)集成版本、驗收測試版本三種類型。1）版本號約定每日構件版本號約定：PXXV0.0.0D0823(D后面是日期)持續(xù)集成測試版本號約定：PXXV0.1.0B01（從B01開始遞增）驗收測試版本號約定：PXXV1.0.0B01（從B01開始遞增）說明：PXX為項目名，V0.0.0為每日構件版本，V0.1.0為集成階段，V1.0.0為系統(tǒng)測試階段。2）版本發(fā)布規(guī)則每日構件版本。每日發(fā)布每日構件版本，用于驗證當天解決的故障，驗證故障修改是否會引入新的故障。持續(xù)集成測試版本。每個迭代周期發(fā)布一個持續(xù)集成測試版本，如迭代周期為二周的，每個迭代周期可發(fā)布二個版本，由項目經理、測試經理協(xié)商決定。驗收測試版本。項目開發(fā)后期迭代發(fā)布驗收測試版本，每個迭代發(fā)布一個驗收測試版本（項目經理和測試經理協(xié)商決定）。3）版本發(fā)布說明版本每次發(fā)布必須提供發(fā)布說明（ReleaseNote）使客戶對發(fā)布的版本情況一目了然。ReleaseNote中主要包括三方面的內容：Fixed，NewFeatures，KnownProblems。其中，Fixed部分寫明此版本修復了上個版本中存在的的哪些比較大的bug；NewFeatures部分寫明此版本新增加了哪些功能；KnownProblems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善；或者列出需求不太明確的地方，有待客戶給出明確答復意見，在下個版本中完成。2.7需求變更 采用敏捷開發(fā)模式的項目中，客戶對于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應的歷史記錄，方便后期的管理和維護工作?？蓪⒚看蔚淖兏碛涗浀疆a品故事-燃盡圖跟蹤表（見附件），并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步。同時更新項目管理系統(tǒng)上面的產品用戶故事與測試用例。2.8迭代末期“bug大掃除”在項目開發(fā)的迭代末期，可以開展“bug大掃除”活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經理，開發(fā)人員甚至于高層管理人員都應參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助于發(fā)現更多的Bug；（3）為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發(fā)現Bug最多，發(fā)現最嚴重Bug的個人，給以物質和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。 3敏捷測試方法與策略3.1持續(xù)測試、持續(xù)反饋敏捷測試是持續(xù)測試、持續(xù)反饋的過程，測試人員扮演“用戶代表”角色，確保產品滿足客戶的需求。測試報表，測試日志都能及時得到反饋。3.2單元測試方法策略單元測試是對功能模塊進行正確檢驗的測試工作，也是后續(xù)測試的基礎。目的是在于發(fā)現各模塊內部可能存在的各種差錯，因此需要從程序的內部結構出發(fā)設計測試用例，著重考慮以下五個方面：1）模塊接口：對所測模塊的數據流進行測試。2）局部數據結構：檢查不正確或不一致的數據類型說明、使用尚未附值或尚未初始化的變量、錯誤的初始值或缺省值。3）路徑：雖然不可能做到窮舉測試，但要設計測試用例查找由于不正確的計算（包括算法錯、表達式符號表示不正確、運算精度不夠等）、不正確的比較或不正常的控制流（包括不同數據類型量的相互比較、不適當地修改了循環(huán)變量、錯誤的或不可能的循環(huán)終止條件等）而導致的錯誤。4）錯誤處理：檢查模塊有沒有對預見錯誤的條件設計比較完善的錯誤處理功能，保證其邏輯上的正確性。5）邊界：注意設計數據流、控制流中剛好等于、大于或小于確定的比較值的用例。單元測試除代碼走查外，敏捷團隊成員要能熟練單元測試工具開展單元測試，確保代碼質量。3.3功能測試方法策略功能測試的目標主要包括：是否有遺漏需求；是否正確的實現所有功能/用戶故事；隱示需求在系統(tǒng)是否實現；輸入、輸出是否正確；移動互聯網應用的功能測試側重于所有可直接追蹤到用例（用戶故事）、業(yè)務功能和業(yè)務規(guī)則的測試需求，這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業(yè)務規(guī)則的實施是否恰當。功能測試基于黑盒技術，通過圖形用戶界面（GUI）與應用程序進行交互，并對交到的輸出或結果進行分析，以此來核實實用程序及其內部進程正確與否。敏捷模式下的功能測試方法策略：已經實現功能的自動化測試。對前期迭代中已經實現的功能，采用工具進行自動化測試，即功能回歸自動化測試。新實現功能的手工測試。主要驗證用戶故事是否正確實現，與用例是否相符。新實現功能的探索性測試。針對新實現的功能，除驗證用戶故事是否實現以外，還需要拓展測試內容。測試系統(tǒng)是否會有其他意想不到的異常或者缺陷。探索性測試說明：探索性測試是一種測試風格，不是具體的某種測試技術，強調個人自由與職責，將測試相關學習、測試設計、測試執(zhí)行與結果分析三者相互支持和并行執(zhí)行。3.4性能測試方法性能測試一般包括負載測試、強度測試/壓力測試、穩(wěn)定性測試/可靠性。負載測試是在一定的硬件、軟件及網絡環(huán)境下，通過模擬不同的用戶，執(zhí)行一種或多種業(yè)務，觀察系統(tǒng)在不同負載下的性能表現。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運行的能力。負載測試的目標是確定并確保系統(tǒng)在走出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。強度測試是性能測試一種，實施和執(zhí)行此類測試的目的是找出因資源不足或資源急用而導致的錯誤。如內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫或網絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。穩(wěn)定性測試評價系統(tǒng)在一定負荷情況下，長時間的運行情況。在一定的軟硬件及網絡環(huán)境中，通過模擬大量的用戶執(zhí)行多種業(yè)務處理大量數據，使系統(tǒng)在極限環(huán)境下長時間運行，目的在于尋找系統(tǒng)的失效點。性能測試一般在系統(tǒng)版本穩(wěn)定后即可開展。移動互聯網產品的性能測試，可借助以下測試工具：LoadRunner，Monkey工具。3.5系統(tǒng)測試策略敏捷開發(fā)模式下的系統(tǒng)測試也就是迭代末期的“bug大掃除”，這種測試是由項目團隊內部開展，系統(tǒng)測試目的是在于驗證軟件的功能和性能及其他特性是否與用戶的要求一致，主要包括類型的測試：1）用戶界面測試：測試用戶界面是否具有導航性、美觀性、行業(yè)或公司的規(guī)范性、是否滿足設計中要求的執(zhí)行功能。性能測試：測試相應時間、事務處理效率和其他時間敏感的問題。強度測試：測試資源（內存、硬盤）敏感的問題。容量測試：測試大量數據對系統(tǒng)的影響。容錯測試：測試軟件系統(tǒng)克服軟件、硬件故障的能力。安全性測試：測試軟件系統(tǒng)對非法侵入的防范能力。配置測試：測試在不同網絡、服務器、工作站的不同軟硬件配置條件下，軟件系統(tǒng)的質量。9)安裝測試：確保軟件系統(tǒng)在所有可能情況下的安裝效果和一旦安裝之后必須保證正確運行的質量。3.6測試驅動研發(fā)測試驅動開發(fā)（英文全稱Test-DrivenDevelopment，簡稱TDD），以用戶故事為基準，包括產品用戶故事與迭代用戶故事，驅動研發(fā)逐步實現所有產品用戶故事以及每個迭代中的用戶故事。它要求在編寫某個功能的代碼之前先編寫按照用戶故障編寫出測試用例，然后通過測試用例驗證來推動整個開發(fā)的進行。測試驅動研發(fā)總體分為二大步：1．測試用例設計。開發(fā)、測試人員從設計文檔、用戶故事著手，參考客戶需求看看用戶故事是否已經覆蓋客戶的要求，對有疑問的地方與文檔設計人員、PO溝通清楚。當搞清楚整個設計思路以及所有用戶故事以后，再來進行測試用例設計。測試用例設計由開發(fā)人員完成，測試人員審核。測試用例需共享給項目組其他成員，因為其他成員開發(fā)的時候需要參照到這些測試用例，避免出現未考慮到的地方。2．測試用例執(zhí)行。當某個用戶故事開發(fā)完成后，測試人員開始測試，驗證用戶故事是否實現，是否滿足用例預期結果。測試前或者測試中，測試人員及時與開發(fā)需隨時進行討論，討論這個用戶故事測試覆蓋點。之前測試用例已經寫完了，但是這個測試用例是基于原有設計用戶故事的，實際的功能怎么樣子，并不非常清楚。而現在實際功能做出來了，對于一個測試人員而言，就能得到基本的測試點。而討論的目的就是盡可能全的把測試點覆蓋全。開發(fā)根據討論結果，更新測試用例，測試人員審核通過后作為后期測試驗收用戶故事的依據。3.7持續(xù)集成測試持續(xù)集成測試是指開發(fā)團隊中的每個成員都盡量頻繁地把他們所做的工作更改合入到源碼庫中，并且還要驗證新合入的變化沒有造成任何破壞。這里的源碼庫指的是版本控制工具（比如：CVS或者SVN）管理的軟件源代碼儲存地。這里的頻繁程度和團隊所開發(fā)的軟件類型有關，但是一般來說頻度應該不大于1個小時。

實現持續(xù)集成測試的幾部分的工作：1、將所有的源代碼保存在單一的地點，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）；2、支持自動化創(chuàng)建腳本，使創(chuàng)建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統(tǒng)的創(chuàng)建；3、測試完全自動化，要求開發(fā)人員提供自測試的代碼，讓任何人都可以只輸入一條命令就運行一套完整的系統(tǒng)測試；4、確保所有人都可以得到最新、最好的可執(zhí)行文件。

持續(xù)集成測試最基本的優(yōu)點就是：它完全避免了開發(fā)者們的"除蟲會議"--以前開發(fā)者們經常需要開這樣的會，因為某個人在工作的時候踩進了別人的領域、影響了別人的代碼，而被影響的人還不知道發(fā)生了什么，于是bug就出現了。這種bug是最難查的，因為問題不是出在某一個人的領域里，而是出在兩個人的交流上面。隨著時間的推移，問題會逐漸惡化。通常，在集成階段出現的bug早在幾周甚至幾個月之前就已經存在了。結果，開發(fā)者需要在集成階段耗費大量的時間和精力來尋找這些bug的根源。如果使用持續(xù)集成測試，這樣的bug絕大多數都可以在引入的同一天就被發(fā)現。而且，由于一天之中發(fā)生變動的部分并不多，所以可以很快找到出錯的位置。如果找不到bug究竟在哪里，你也可以不把這些錯誤的代碼集成到產品中去。即使在最壞的情況下，你也只是不添加引起bug的特性而已。所以，持續(xù)集成可以減少集成階段"捉蟲"消耗的時間，從而最終提高生產力。4移動互聯網終端測試4.1用戶體驗測試 移動互聯網終端應用用戶體驗測試從視、聽、觸、反應速度、可用性、易用性幾個方面出發(fā)，來測試終端應用的用戶體驗。 “視”是指應用界面UI布局是否合理、視效是否美觀、顏色搭配是否協(xié)調、不同分辨率下是否可以正常運行。 “聽”是針對具有音頻播放功能的應用，應用使用的各種音頻聽起來感覺是否悅耳、使人舒暢，有沒有雜音、電流音、刺耳的高音等。 “觸”是指應用的使用觸感，與終端屏幕、鍵盤有一定相關性。應用中的各種窗口控件、對話框觸擊使用時觸感是否使用愉悅。 “反應速度”是指終端應用使用過程中，點擊某個功能按鈕、菜單后，應用的反應速度有多快，是否滿足用戶使用習慣。通常一個操作反應時間超過2秒，用戶便能夠感知到慢。如果超過3秒，容易使用戶感到不滿。超過4秒，用戶則不愿意接受。 “可用性”測試是指終端應用功能是否可用，有無缺陷。除基本功能實現以外，是否有其他明顯影響使用的缺陷，是否滿足正常操作習慣。 “用戶體驗易用性”測試主要是檢測用戶在理解和使用系統(tǒng)方面到底有多好，是否存在障礙或難以理解的部分。 用戶體驗易用性的測試方法，一般是通過用戶訪談，或邀請內測、小范圍公測等方式進行，通過不同實驗組的運營結果來判斷是否存在易用性缺陷。注意用戶體驗易用性測試由于缺乏有效的測試工具，必須大量的測試樣本才能獲得比較真實的測試數據，投入資源較多，測試周期較長。4.2平臺兼容性測試兼容性測試是核實測試對象在不同的軟件系統(tǒng)、硬件配置中的運行情況，測試系統(tǒng)在各種軟硬件配置，不同的參數配置下系統(tǒng)具有的功能、功耗、性能和用戶體驗。移動互聯網終端應用的兼容性測試包含內容：操作的兼容性：覆蓋智能機三個主流操作系統(tǒng)，iOS,Android和WindowsMobile。硬件兼容性：不同分辨率下的兼容性測試。4.3不同網絡環(huán)境下測試驗證不同網絡環(huán)境下，終端應用功能與性能方面是否正常(數據業(yè)務是否會中斷，業(yè)務模塊是否出現異常)。網絡環(huán)境包含：3G強信號3G中強信號2G強信號2G中強信號4.4多事務并發(fā)測試移動互聯網終端應用有自身的特殊性，終端上支持的應用很多，許多應用事務會并發(fā)產生（同一時間產生或者某一應用使用過程并發(fā)其他應用事務）。終端應用使用過程通常會有以下一些并發(fā)事務：短信并發(fā)彩信并發(fā)來電并發(fā)鬧鐘、日程并發(fā)藍牙事務并發(fā)傳感器事務并發(fā)其他第三方應用事務并發(fā)（如天氣預報）4.5安裝、卸載測試安裝測試驗證應用程序安裝包/APK安裝包能否成功安裝到移動終端上，以及安裝后能否正常打開使用。卸載測試驗證已經安裝的應用程序/APK包是否能成功地卸載。Android終端應用程序安裝、卸載測試可借助MonkeyRunner工具來開展。4.6安全性、接口測試安全性測試側重于安全性的兩個關鍵方面：1．應用程序級別的安全性，包括對數據或業(yè)務功能的訪問。應用程序級別的安全性可確保：在預期的安全性情況下，不同權限用戶只能訪問特定的功能或用例，或者只能訪問有限的數據。例如，可能會允許所有人輸入數據，創(chuàng)建新賬戶，但只有管理員才能刪除這些數據或賬戶。如果具有數據級別的安全性，測試就可確?！坝脩纛愋鸵弧蹦軌蚩吹剿锌蛻粝ⅲòㄘ攧諗祿?，而“用戶二”只能看見同一客戶的統(tǒng)計數據。2.系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠程訪問。系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權限的用戶才能訪問應用程序，而且只能通過相應的網關來訪問。接口測試指測試應用與終端本地其他應用的接口，主要測試接口功能是否實現，是否會引起本地其他應用異常。本地其他應用主要包括：音頻模塊，視頻模塊，藍牙模塊，聯系人，短信，彩信，通話記錄等。5測試工具和環(huán)境 5.1單元測試工具 工具名稱：Junit（java），Qunit(JSP)，VisualUnit(C/C++)。適用測試類型：單元編碼完成 輸出物：單元測試報告 5.2功能回歸測試工具工具名稱：QTP，MonkeyRunner。適用測試類型：穩(wěn)定模塊功能回歸測試，適用每日構件版本，持續(xù)集成版本。 輸出物：測試報告 5.3性能測試工具工具名稱：LoadRunner，Monkey適用測試類