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

1、.敏捷開發(fā)測試規(guī)范（試行） 2012年9月版本記錄版本號日期修改人描述V0.12012/9周本文V0.1目錄1 概述31.1 編寫目的31.2 讀者對象31.3 術語定義32 敏捷測試流程32.1 需求驗證32.2 用例設計32.3 用例審核與維護32.4 測試計劃32.5 測試實施運行42.6 版本控制42.7 需求變更52.8 迭代末期“bug大掃除”53 敏捷測試方法與策略53.1 持續(xù)測試、持續(xù)反饋53.2 單元測試方法策略53.3 功能測試方法策略53.4 性能測試方法63.5 系統(tǒng)測試策略63.6 測試驅動研發(fā)73.7 持續(xù)集成測試74 終端移動互聯網測試74.1 用戶體驗測試74

2、.2 平臺兼容性測試74.3 不同網絡環(huán)境下測試84.4 多事務并發(fā)測試84.5 安裝、卸載測試85 測試工具和環(huán)境85.1 單元測試工具85.2 功能回歸測試工具85.3 性能測試工具95.4 持續(xù)集成測試環(huán)境96 測試人員要求96.1 人力需求96.2 測試人員能力要求97 附錄111 概述1.1 編寫目的ICT自主開發(fā)產品擬采用敏捷開發(fā)模式，為規(guī)范ICT支撐中心項目敏捷測試流程，明確敏捷開發(fā)模式下的術語定義，明確敏捷測試方法與策略，明確移動互聯網測試特有的測試內容，確定敏捷開發(fā)模式下用到的測試工具以及測試環(huán)境，以及初步確定敏捷測試人力需求計算方式與對人員能力要求，特制定本規(guī)范。本規(guī)范適用

3、于采用敏捷開發(fā)模式下的所有自主開發(fā)移動互聯網產品。1.2 讀者對象本規(guī)范讀者對象為軟件開發(fā)項目管理者、項目經理、測試經理、開發(fā)經理、開發(fā)組、測試組所有人員。1.3 術語定義敏捷開發(fā)模式下的幾種重要角色、產品文檔及過程會議術語如表1-1：術語中文說明 Product Owner（PO）產品所有者相當于項目經理、產品經理、產品負責人。產品用戶故事編寫負責人。Scrum Master （SM）敏捷開發(fā)組織者組織項目敏捷開發(fā)，負責協(xié)調、溝通、協(xié)助解決團隊內部非技術問題。Product Backlog產品需求產品待開發(fā)的功能項（用戶需求）Sprint Backlog迭代需求每個迭代需實現的功能項（產品需

4、求細化）User story用戶故事從用戶角度提出的需求Burndown chart燃盡圖產品需求、迭代需求完成的進度顯示圖Plan Meeting計劃會迭代計劃會，組織討論下個迭代開發(fā)內容，PO需參加講解產品需求。Standup Meeting每日立會每日立會，早上時間，主要討論每人當天工作內容。Review Meeting迭代評審會每個迭代結束時召開，展示迭代成果，聽取PO意見、建議。表1-12 敏捷測試流程2.1 驗證需求和設計敏捷測試強調問題暴露越早越好。需求和設計具體來說一般包括：（1）由項目經理根據需求文本而編寫的產品用戶故事或者是產品軟件需求規(guī)格說明書；（2）由開發(fā)人員根據產品用

5、戶故事而編寫的迭代用戶故事，或者是詳細設計、數據庫設計、系統(tǒng)方案設計、概要設計（可裁剪，根據開發(fā)系統(tǒng)規(guī)模決定是否裁剪。）。作為測試人員，審核重點是檢查產品用戶故事、迭代用戶故事對用戶需求定義的完整性、嚴密性和功能設計的可測性。在測試初期，測試人員要學會做靜態(tài)測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統(tǒng)的需求分析，設計和開發(fā)。更多的參與DB Design（數據庫設計），框架的評審中來。積極地參與前期工作，盡早的開始測試，并迅速反饋給設計和開發(fā)其靜態(tài)測試結果。需求和設計驗證產出物:測試需要提交評審結果。2.2 用例設計與審核 開

6、發(fā)人員根據產品用戶故事、迭代用戶故事，設計測試用例，測試人員負責測試用例審核。為保證測試用例的質量和可行性，確保測試工作的順利進行，讓開發(fā)人員、測試人員迅速地了解測試的重點并給出相應的意見和建議，用例設計人員在出輸出測試用例的同時，應出一份用戶故事與用例跟蹤表（見附件：產品故事-燃盡圖跟蹤表），其中注明測試用例已覆蓋了哪些用戶故事，具體每個用戶故事對應的測試用例編號，這樣其他項目組成員對測試用例進行查看的時候，能夠對測試用例的覆蓋率一目了然，對覆蓋率不足（如某個重點用戶故事的測試用例覆蓋不夠）的地方能夠及時給出意見。測試人員負責用例審核。2.3 測試計劃敏捷測試的測試計劃不需要復雜的計劃文檔，

7、寫出一頁紙的測試計劃，將測試要點（包括策略、特定方法、重點范圍等）列出來即可，模板見附件。2.4 測試實施運行敏捷開發(fā)模式中，測試與研發(fā)緊密結合在一起。測試主要有兩種：單元測試和驗證/接收測試。單元測試一般是由開發(fā)人員來完成的，接收測試是由客戶代表來完成。由于客戶通常無法在現場，一般由測試人員做驗證測試，最后由客戶進行接收測試。在每個版本發(fā)布給客戶之前必須由測試人員進行測試，發(fā)布版本之后由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下后面的迭代中完成。 單元測試在每日構件版本給測試前，開發(fā)首先要做單元測試，提前告知軟件中的薄弱環(huán)節(jié)，幫助測試人員調整測試重點。做單元測試的好處是可以提高

8、版本質量，減輕測試的工作量，減少淺層次的bug的發(fā)生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面。 驗證測試測試人員的驗證測試從總體上說就是將測試用例按計劃付諸實施的過程，以及驗證故障修復是否會引入新的故障。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現在開發(fā)和測試的相互協(xié)調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，測試執(zhí)行的一開始可以是針對部分用戶故事的，之后可以逐步擴展。接著開始采用迭代的過程完成測試任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性/用戶故事測試，可以對代碼中的可復用部分（組件，構件）做完整的

9、測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最后的幾個迭代應該用于完整的回歸測試，和關鍵的性能和穩(wěn)定性測試。 每日構件版本測試敏捷開發(fā)過程中除每個迭代中持續(xù)集成版本以外，還會有每日構件版本，每日構件版本測試用以驗證前天修復的故障，以及測試故障修復是否會引入新的故障。2.6 版本控制敏捷開發(fā)強調快速開發(fā)，持續(xù)集成。版本包括每日構件版本、持續(xù)集成版本、驗收測試版本三種類型。1）版本號約定每日構件版本號約定：PXXV0.0.0D0823 (D后面是日期)持續(xù)集成測試版本號約定：PXXV0.1.0B01（從B01開始遞增）驗收測試版本號約定：PXXV1.0.0B01（從B01開始遞增）說明：

10、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ā)布說明（Release Note）使客戶對發(fā)布的版本情況一目了然。Release Note中主要包括三方面的內容：F

11、ixed，New Features，Known Problems。其中，Fixed部分寫明此版本修復了上個版本中存在的的哪些比較大的bug；New Features部分寫明此版本新增加了哪些功能；Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善；或者列出需求不太明確的地方，有待客戶給出明確答復意見，在下個版本中完成。2.7 需求變更采用敏捷開發(fā)模式的項目中，客戶對于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應的歷史記錄，方便后期的管理和維護工作?？蓪⒚看蔚淖兏碛涗浀疆a品

12、故事-燃盡圖跟蹤表（見附件），并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步。同時更新項目管理系統(tǒng)上面的產品用戶故事與測試用例。2.8 迭代末期“bug大掃除”在項目開發(fā)的迭代末期，可以開展“bug大掃除”活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經理，開發(fā)人員甚至于高層管理人員都應參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助于發(fā)現更多的Bug；（3）為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時

13、，評出發(fā)現Bug最多，發(fā)現最嚴重Bug的個人，給以物質和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。3 敏捷測試方法與策略3.1 持續(xù)測試、持續(xù)反饋敏捷測試是持續(xù)測試、持續(xù)反饋的過程，測試人員扮演“用戶代表”角色，確保產品滿足客戶的需求。測試報表，測試日志都能及時得到反饋。3.2 單元測試方法策略單元測試是對功能模塊進行正確檢驗的測試工作，也是后續(xù)測試的基礎。目的是在于發(fā)現各模塊內部可能存在的各種差錯，因此需要從程序的內部結構出發(fā)設計測試用例，著重考慮以下五個方面：1）模塊接口：對所測模塊的數據流進行測試。2）局部數據結構：檢查不正確或不一致的數據類型說明、

14、使用尚未附值或尚未初始化的變量、錯誤的初始值或缺省值。3）路徑：雖然不可能做到窮舉測試，但要設計測試用例查找由于不正確的計算（包括算法錯、表達式符號表示不正確、運算精度不夠等）、不正確的比較或不正常的控制流（包括不同數據類型量的相互比較、不適當地修改了循環(huán)變量、錯誤的或不可能的循環(huán)終止條件等）而導致的錯誤。4）錯誤處理：檢查模塊有沒有對預見錯誤的條件設計比較完善的錯誤處理功能，保證其邏輯上的正確性。5）邊界：注意設計數據流、控制流中剛好等于、大于或小于確定的比較值的用例。單元測試除代碼走查外，敏捷團隊成員要能熟練單元測試工具開展單元測試，確保代碼質量。3.3 功能測試方法策略功能測試的目標主要

15、包括： 是否有遺漏需求； 是否正確的實現所有功能/用戶故事； 隱示需求在系統(tǒng)是否實現； 輸入、輸出是否正確；移動互聯網應用的功能測試側重于所有可直接追蹤到用例（用戶故事）、業(yè)務功能和業(yè)務規(guī)則的測試需求，這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業(yè)務規(guī)則的實施是否恰當。功能測試基于黑盒技術，通過圖形用戶界面（GUI）與應用程序進行交互，并對交到的輸出或結果進行分析，以此來核實實用程序及其內部進程正確與否。敏捷模式下的功能測試方法策略：已經實現功能的自動化測試。對前期迭代中已經實現的功能，采用工具進行自動化測試，即功能回歸自動化測試。新實現功能的手工測試。主要驗證用戶故事是否正確實現

16、，與用例是否相符。新實現功能的探索性測試。針對新實現的功能，除驗證用戶故事是否實現以外，還需要拓展測試內容。測試系統(tǒng)是否會有其他意想不到的異?；蛘呷毕?。探索性測試說明：探索性測試是一種測試風格，不是具體的某種測試技術，強調個人自由與職責，將測試相關學習、測試設計、測試執(zhí)行與結果分析三者相互支持和并行執(zhí)行。3.4 性能測試方法性能測試一般包括負載測試、強度測試/壓力測試、穩(wěn)定性測試/可靠性。負載測試是在一定的硬件、軟件及網絡環(huán)境下，通過模擬不同的用戶，執(zhí)行一種或多種業(yè)務，觀察系統(tǒng)在不同負載下的性能表現。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，

17、以及持續(xù)正常運行的能力。負載測試的目標是確定并確保系統(tǒng)在走出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。強度測試是性能測試一種，實施和執(zhí)行此類測試的目的是找出因資源不足或資源急用而導致的錯誤。如內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫或網絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。穩(wěn)定性測試評價系統(tǒng)在一定負荷情況下，長時間的運行情況。在一定的軟硬件及網絡環(huán)境中，通過模擬大量的用戶執(zhí)行多種業(yè)務處理大量數據，使系統(tǒng)在極限環(huán)境

18、下長時間運行，目的在于尋找系統(tǒng)的失效點。性能測試一般在系統(tǒng)版本穩(wěn)定后即可開展。移動互聯網產品的性能測試，可借助以下測試工具：LoadRunner，Monkey工具。3.5 系統(tǒng)測試策略敏捷開發(fā)模式下的系統(tǒng)測試也就是迭代末期的“bug大掃除”，這種測試是由項目團隊內部開展，系統(tǒng)測試目的是在于驗證軟件的功能和性能及其他特性是否與用戶的要求一致，主要包括類型的測試：1）用戶界面測試：測試用戶界面是否具有導航性、美觀性、行業(yè)或公司的規(guī)范性、是否滿足設計中要求的執(zhí)行功能。2） 性能測試：測試相應時間、事務處理效率和其他時間敏感的問題。3） 強度測試：測試資源（內存、硬盤）敏感的問題。4） 容量測試：測試

19、大量數據對系統(tǒng)的影響。5） 容錯測試：測試軟件系統(tǒng)克服軟件、硬件故障的能力。6） 安全性測試：測試軟件系統(tǒng)對非法侵入的防范能力。7） 配置測試：測試在不同網絡、服務器、工作站的不同軟硬件配置條件下，軟件系統(tǒng)的質量。9) 安裝測試：確保軟件系統(tǒng)在所有可能情況下的安裝效果和一旦安裝之后必須保證正確運行的質量。3.6 測試驅動研發(fā)測試驅動開發(fā)（英文全稱Test-Driven Development，簡稱TDD），以用戶故事為基準，包括產品用戶故事與迭代用戶故事，驅動研發(fā)逐步實現所有產品用戶故事以及每個迭代中的用戶故事。它要求在編寫某個功能的代碼之前先編寫按照用戶故障編寫出測試用例，然后通過測試用例驗

20、證來推動整個開發(fā)的進行。測試驅動研發(fā)總體分為二大步：1測試用例設計。開發(fā)、測試人員從設計文檔、用戶故事著手，參考客戶需求看看用戶故事是否已經覆蓋客戶的要求，對有疑問的地方與文檔設計人員、PO溝通清楚。當搞清楚整個設計思路以及所有用戶故事以后，再來進行測試用例設計。測試用例設計由開發(fā)人員完成，測試人員審核。測試用例需共享給項目組其他成員，因為其他成員開發(fā)的時候需要參照到這些測試用例，避免出現未考慮到的地方。2測試用例執(zhí)行。當某個用戶故事開發(fā)完成后，測試人員開始測試，驗證用戶故事是否實現，是否滿足用例預期結果。測試前或者測試中，測試人員及時與開發(fā)需隨時進行討論，討論這個用戶故事測試覆蓋點。之前測試

21、用例已經寫完了，但是這個測試用例是基于原有設計用戶故事的，實際的功能怎么樣子，并不非常清楚。而現在實際功能做出來了，對于一個測試人員而言，就能得到基本的測試點。而討論的目的就是盡可能全的把測試點覆蓋全。開發(fā)根據討論結果，更新測試用例，測試人員審核通過后作為后期測試驗收用戶故事的依據。3.7 持續(xù)集成測試持續(xù)集成測試是指開發(fā)團隊中的每個成員都盡量頻繁地把他們所做的工作更改合入到源碼庫中，并且還要驗證新合入的變化沒有造成任何破壞。這里的源碼庫指的是版本控制工具（比如：CVS或者SVN）管理的軟件源代碼儲存地。這里的頻繁程度和團隊所開發(fā)的軟件類型有關，但是一般來說頻度應該不大于1個小時。實現持續(xù)集成

22、測試的幾部分的工作： 1、將所有的源代碼保存在單一的地點，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）；2、支持自動化創(chuàng)建腳本，使創(chuàng)建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統(tǒng)的創(chuàng)建； 3、測試完全自動化，要求開發(fā)人員提供自測試的代碼，讓任何人都可以只輸入一條命令就運行一套完整的系統(tǒng)測試；4、確保所有人都可以得到最新、最好的可執(zhí)行文件。持續(xù)集成測試最基本的優(yōu)點就是：它完全避免了開發(fā)者們的除蟲會議-以前開發(fā)者們經常需要開這樣的會，因為某個人在工作的時候踩進了別人的領域、影響了別人的代碼，而被影響的人還不知道發(fā)生了什么，于是bug就出現了。這種bug是最難查的，因為問題不是出在

23、某一個人的領域里，而是出在兩個人的交流上面。隨著時間的推移，問題會逐漸惡化。通常，在集成階段出現的bug早在幾周甚至幾個月之前就已經存在了。結果，開發(fā)者需要在集成階段耗費大量的時間和精力來尋找這些bug的根源。 如果使用持續(xù)集成測試，這樣的bug絕大多數都可以在引入的同一天就被發(fā)現。而且，由于一天之中發(fā)生變動的部分并不多，所以可以很快找到出錯的位置。如果找不到bug究竟在哪里，你也可以不把這些錯誤的代碼集成到產品中去。即使在最壞的情況下，你也只是不添加引起bug的特性而已。所以，持續(xù)集成可以減少集成階段捉蟲消耗的時間，從而最終提高生產力。4 移動互聯網終端測試4.1 用戶體驗測試移動互聯網終端

24、應用用戶體驗測試從視、聽、觸、反應速度、可用性、易用性幾個方面出發(fā)，來測試終端應用的用戶體驗?！耙暋笔侵笐媒缑鎁I布局是否合理、視效是否美觀、顏色搭配是否協(xié)調、不同分辨率下是否可以正常運行?！奥牎笔轻槍哂幸纛l播放功能的應用，應用使用的各種音頻聽起來感覺是否悅耳、使人舒暢，有沒有雜音、電流音、刺耳的高音等。“觸”是指應用的使用觸感，與終端屏幕、鍵盤有一定相關性。應用中的各種窗口控件、對話框觸擊使用時觸感是否使用愉悅?！胺磻俣取笔侵附K端應用使用過程中，點擊某個功能按鈕、菜單后，應用的反應速度有多快，是否滿足用戶使用習慣。通常一個操作反應時間超過2秒，用戶便能夠感知到慢。如果超過3秒，容易使用

25、戶感到不滿。超過4秒，用戶則不愿意接受?！翱捎眯浴睖y試是指終端應用功能是否可用，有無缺陷。除基本功能實現以外，是否有其他明顯影響使用的缺陷，是否滿足正常操作習慣。“用戶體驗易用性”測試主要是檢測用戶在理解和使用系統(tǒng)方面到底有多好，是否存在障礙或難以理解的部分。用戶體驗易用性的測試方法，一般是通過用戶訪談，或邀請內測、小范圍公測等方式進行，通過不同實驗組的運營結果來判斷是否存在易用性缺陷。注意用戶體驗易用性測試由于缺乏有效的測試工具，必須大量的測試樣本才能獲得比較真實的測試數據，投入資源較多，測試周期較長。4.2 平臺兼容性測試兼容性測試是核實測試對象在不同的軟件系統(tǒng)、硬件配置中的運行情況，測試

26、系統(tǒng)在各種軟硬件配置，不同的參數配置下系統(tǒng)具有的功能、功耗、性能和用戶體驗。移動互聯網終端應用的兼容性測試包含內容：操作的兼容性：覆蓋智能機三個主流操作系統(tǒng)，iOS, Android和Windows Mobile。硬件兼容性：不同分辨率下的兼容性測試。4.3 不同網絡環(huán)境下測試驗證不同網絡環(huán)境下，終端應用功能與性能方面是否正常(數據業(yè)務是否會中斷，業(yè)務模塊是否出現異常)。網絡環(huán)境包含：3G強信號3G中強信號2G強信號2G中強信號4.4 多事務并發(fā)測試移動互聯網終端應用有自身的特殊性，終端上支持的應用很多，許多應用事務會并發(fā)產生（同一時間產生或者某一應用使用過程并發(fā)其他應用事務）。終端應用使用過

27、程通常會有以下一些并發(fā)事務：短信并發(fā)彩信并發(fā)來電并發(fā)鬧鐘、日程并發(fā)藍牙事務并發(fā)傳感器事務并發(fā)其他第三方應用事務并發(fā)（如天氣預報）4.5 安裝、卸載測試安裝測試驗證應用程序安裝包/APK安裝包能否成功安裝到移動終端上，以及安裝后能否正常打開使用。卸載測試驗證已經安裝的應用程序/APK包是否能成功地卸載。Android終端應用程序安裝、卸載測試可借助MonkeyRunner工具來開展。4.6 安全性、接口測試安全性測試側重于安全性的兩個關鍵方面：1應用程序級別的安全性，包括對數據或業(yè)務功能的訪問。應用程序級別的安全性可確保：在預期的安全性情況下，不同權限用戶只能訪問特定的功能或用例，或者只能訪問有

28、限的數據。例如，可能會允許所有人輸入數據，創(chuàng)建新賬戶，但只有管理員才能刪除這些數據或賬戶。如果具有數據級別的安全性，測試就可確?！坝脩纛愋鸵弧?能夠看到所有客戶消息（包括財務數據），而“用戶二”只能看見同一客戶的統(tǒng)計數據。2. 系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠程訪問。系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權限的用戶才能訪問應用程序，而且只能通過相應的網關來訪問。接口測試指測試應用與終端本地其他應用的接口，主要測試接口功能是否實現，是否會引起本地其他應用異常。本地其他應用主要包括：音頻模塊，視頻模塊，藍牙模塊，聯系人，短信，彩信，通話記錄等。5 測試工具和環(huán)境 5.1 單元測試工具 工具名稱：Junit（java），Qunit(JSP)，Visual Unit(C/C+)。適用測試類型：單元編碼完成輸出物：單元測試報告5.2 功能回歸測試工具工具名稱：QTP，MonkeyRunner。適用測試類型：穩(wěn)定模塊功能回歸測試，適用每日構件版本，持續(xù)集成版本。輸出物：測試報告5.3 性能測試工具工具名稱：LoadRunner，Monkey適用測試類型：迭代持續(xù)集成版本（選擇性執(zhí)行），最終驗收版本。輸出物：測試報告5.4 持續(xù)集成測試環(huán)境工具名稱：CruiseControl，