敏捷開(kāi)發(fā)測(cè)試規(guī)范V01

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

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

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

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

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

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

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

8、是可以提高版本質(zhì)量，減輕測(cè)試的工作量，減少淺層次的bug的發(fā)生率，使測(cè)試人員能夠?qū)⒏嗟木ν度氲綄ふ疑顚哟蔚腷ug上面。· 驗(yàn)證測(cè)試測(cè)試人員的驗(yàn)證測(cè)試從總體上說(shuō)就是將測(cè)試用例按計(jì)劃付諸實(shí)施的過(guò)程，以及驗(yàn)證故障修復(fù)是否會(huì)引入新的故障。這一階段的測(cè)試必須在周密的計(jì)劃下進(jìn)行。這種計(jì)劃性首先體現(xiàn)在開(kāi)發(fā)和測(cè)試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項(xiàng)目的總體計(jì)劃共同推進(jìn)。從測(cè)試的過(guò)程來(lái)看，測(cè)試執(zhí)行的一開(kāi)始可以是針對(duì)部分用戶故事的，之后可以逐步擴(kuò)展。接著開(kāi)始采用迭代的過(guò)程完成測(cè)試任務(wù)，即將測(cè)試任務(wù)劃分為多個(gè)周期，一開(kāi)始可以做些關(guān)鍵的功能性/用戶故事測(cè)試，可以對(duì)代碼中的可復(fù)用部分

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

10、0B01（從B01開(kāi)始遞增）說(shuō)明：PXX為項(xiàng)目名，V0.0.0為每日構(gòu)件版本，V0.1.0為集成階段，V1.0.0為系統(tǒng)測(cè)試階段。2）版本發(fā)布規(guī)則每日構(gòu)件版本。每日發(fā)布每日構(gòu)件版本，用于驗(yàn)證當(dāng)天解決的故障，驗(yàn)證故障修改是否會(huì)引入新的故障。持續(xù)集成測(cè)試版本。每個(gè)迭代周期發(fā)布一個(gè)持續(xù)集成測(cè)試版本，如迭代周期為二周的，每個(gè)迭代周期可發(fā)布二個(gè)版本，由項(xiàng)目經(jīng)理、測(cè)試經(jīng)理協(xié)商決定。驗(yàn)收測(cè)試版本。項(xiàng)目開(kāi)發(fā)后期迭代發(fā)布驗(yàn)收測(cè)試版本，每個(gè)迭代發(fā)布一個(gè)驗(yàn)收測(cè)試版本（項(xiàng)目經(jīng)理和測(cè)試經(jīng)理協(xié)商決定）。3）版本發(fā)布說(shuō)明版本每次發(fā)布必須提供發(fā)布說(shuō)明（Release Note）使客戶對(duì)發(fā)布的版本情況一目了然。Release

11、Note中主要包括三方面的內(nèi)容：Fixed，New Features，Known Problems。其中，F(xiàn)ixed部分寫(xiě)明此版本修復(fù)了上個(gè)版本中存在的的哪些比較大的bug；New Features部分寫(xiě)明此版本新增加了哪些功能；Known Problems部分寫(xiě)明此版本尚存在哪些比較大的問(wèn)題，有待下個(gè)版本改善；或者列出需求不太明確的地方，有待客戶給出明確答復(fù)意見(jiàn)，在下個(gè)版本中完成。2.7 需求變更采用敏捷開(kāi)發(fā)模式的項(xiàng)目中，客戶對(duì)于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個(gè)項(xiàng)目進(jìn)行過(guò)程中，對(duì)不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應(yīng)的歷史記錄，方便后期的管理和維護(hù)

12、工作?？蓪⒚看蔚淖兏碛涗浀疆a(chǎn)品故事-燃盡圖跟蹤表（見(jiàn)附件），并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步。同時(shí)更新項(xiàng)目管理系統(tǒng)上面的產(chǎn)品用戶故事與測(cè)試用例。2.8 迭代末期“bug大掃除”在項(xiàng)目開(kāi)發(fā)的迭代末期，可以開(kāi)展“bug大掃除”活動(dòng)。劃出一個(gè)專門(mén)的時(shí)間段，在這期間所有參與項(xiàng)目的人員，集中全部精力，搜尋項(xiàng)目的Bug。注意以下要點(diǎn)：（1）盡管這是一個(gè)測(cè)試活動(dòng)，但參與者并不僅限于測(cè)試人員。項(xiàng)目經(jīng)理，開(kāi)發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動(dòng)員。目的是要集思廣益；（2）要鼓勵(lì)各部門(mén)，領(lǐng)域交叉搜索，因?yàn)樾碌乃悸泛鸵暯峭ǔＳ兄诎l(fā)現(xiàn)更多的Bug；（3）為調(diào)動(dòng)積極性，增強(qiáng)趣味性，可以

13、適當(dāng)引入競(jìng)爭(zhēng)機(jī)制，比如當(dāng)活動(dòng)結(jié)束時(shí)，評(píng)出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴(yán)重Bug的個(gè)人，給以物質(zhì)和精神獎(jiǎng)勵(lì)。（4）可以分專題展開(kāi)，比如安全性、用戶界面可用性、國(guó)際化和本地化等等。3 敏捷測(cè)試方法與策略3.1 持續(xù)測(cè)試、持續(xù)反饋敏捷測(cè)試是持續(xù)測(cè)試、持續(xù)反饋的過(guò)程，測(cè)試人員扮演“用戶代表”角色，確保產(chǎn)品滿足客戶的需求。測(cè)試報(bào)表，測(cè)試日志都能及時(shí)得到反饋。3.2 單元測(cè)試方法策略單元測(cè)試是對(duì)功能模塊進(jìn)行正確檢驗(yàn)的測(cè)試工作，也是后續(xù)測(cè)試的基礎(chǔ)。目的是在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)，因此需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，著重考慮以下五個(gè)方面：1）模塊接口：對(duì)所測(cè)模塊的數(shù)據(jù)流進(jìn)行測(cè)試。2）局部數(shù)據(jù)結(jié)構(gòu)：

14、檢查不正確或不一致的數(shù)據(jù)類型說(shuō)明、使用尚未附值或尚未初始化的變量、錯(cuò)誤的初始值或缺省值。3）路徑：雖然不可能做到窮舉測(cè)試，但要設(shè)計(jì)測(cè)試用例查找由于不正確的計(jì)算（包括算法錯(cuò)、表達(dá)式符號(hào)表示不正確、運(yùn)算精度不夠等）、不正確的比較或不正常的控制流（包括不同數(shù)據(jù)類型量的相互比較、不適當(dāng)?shù)匦薷牧搜h(huán)變量、錯(cuò)誤的或不可能的循環(huán)終止條件等）而導(dǎo)致的錯(cuò)誤。4）錯(cuò)誤處理：檢查模塊有沒(méi)有對(duì)預(yù)見(jiàn)錯(cuò)誤的條件設(shè)計(jì)比較完善的錯(cuò)誤處理功能，保證其邏輯上的正確性。5）邊界：注意設(shè)計(jì)數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值的用例。單元測(cè)試除代碼走查外，敏捷團(tuán)隊(duì)成員要能熟練單元測(cè)試工具開(kāi)展單元測(cè)試，確保代碼質(zhì)量。3.3

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

16、動(dòng)化測(cè)試，即功能回歸自動(dòng)化測(cè)試。新實(shí)現(xiàn)功能的手工測(cè)試。主要驗(yàn)證用戶故事是否正確實(shí)現(xiàn)，與用例是否相符。新實(shí)現(xiàn)功能的探索性測(cè)試。針對(duì)新實(shí)現(xiàn)的功能，除驗(yàn)證用戶故事是否實(shí)現(xiàn)以外，還需要拓展測(cè)試內(nèi)容。測(cè)試系統(tǒng)是否會(huì)有其他意想不到的異?；蛘呷毕?。探索性測(cè)試說(shuō)明：探索性測(cè)試是一種測(cè)試風(fēng)格，不是具體的某種測(cè)試技術(shù)，強(qiáng)調(diào)個(gè)人自由與職責(zé)，將測(cè)試相關(guān)學(xué)習(xí)、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行與結(jié)果分析三者相互支持和并行執(zhí)行。3.4 性能測(cè)試方法性能測(cè)試一般包括負(fù)載測(cè)試、強(qiáng)度測(cè)試/壓力測(cè)試、穩(wěn)定性測(cè)試/可靠性。負(fù)載測(cè)試是在一定的硬件、軟件及網(wǎng)絡(luò)環(huán)境下，通過(guò)模擬不同的用戶，執(zhí)行一種或多種業(yè)務(wù)，觀察系統(tǒng)在不同負(fù)載下的性能表現(xiàn)。在這種測(cè)試中

17、，將使測(cè)試對(duì)象承擔(dān)不同的工作量，以評(píng)測(cè)和評(píng)估測(cè)試對(duì)象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測(cè)試的目標(biāo)是確定并確保系統(tǒng)在走出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測(cè)試還要評(píng)估性能特征，例如，響應(yīng)時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。強(qiáng)度測(cè)試是性能測(cè)試一種，實(shí)施和執(zhí)行此類測(cè)試的目的是找出因資源不足或資源急用而導(dǎo)致的錯(cuò)誤。如內(nèi)存或磁盤(pán)空間不足，測(cè)試對(duì)象就可能會(huì)表現(xiàn)出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭(zhēng)用共享資源（如數(shù)據(jù)庫(kù)或網(wǎng)絡(luò)帶寬）而造成的。強(qiáng)度測(cè)試還可用于確定測(cè)試對(duì)象能夠處理的最大工作量。穩(wěn)定性測(cè)試評(píng)價(jià)系統(tǒng)在一定負(fù)荷情況下，長(zhǎng)時(shí)間的運(yùn)行情況。在一定

18、的軟硬件及網(wǎng)絡(luò)環(huán)境中，通過(guò)模擬大量的用戶執(zhí)行多種業(yè)務(wù)處理大量數(shù)據(jù)，使系統(tǒng)在極限環(huán)境下長(zhǎng)時(shí)間運(yùn)行，目的在于尋找系統(tǒng)的失效點(diǎn)。性能測(cè)試一般在系統(tǒng)版本穩(wěn)定后即可開(kāi)展。移動(dòng)互聯(lián)網(wǎng)產(chǎn)品的性能測(cè)試，可借助以下測(cè)試工具：LoadRunner，Monkey工具。3.5 系統(tǒng)測(cè)試策略敏捷開(kāi)發(fā)模式下的系統(tǒng)測(cè)試也就是迭代末期的“bug大掃除”，這種測(cè)試是由項(xiàng)目團(tuán)隊(duì)內(nèi)部開(kāi)展，系統(tǒng)測(cè)試目的是在于驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致，主要包括類型的測(cè)試：1）用戶界面測(cè)試：測(cè)試用戶界面是否具有導(dǎo)航性、美觀性、行業(yè)或公司的規(guī)范性、是否滿足設(shè)計(jì)中要求的執(zhí)行功能。2） 性能測(cè)試：測(cè)試相應(yīng)時(shí)間、事務(wù)處理效率和其他時(shí)間

19、敏感的問(wèn)題。3） 強(qiáng)度測(cè)試：測(cè)試資源（內(nèi)存、硬盤(pán)）敏感的問(wèn)題。4） 容量測(cè)試：測(cè)試大量數(shù)據(jù)對(duì)系統(tǒng)的影響。5） 容錯(cuò)測(cè)試：測(cè)試軟件系統(tǒng)克服軟件、硬件故障的能力。6） 安全性測(cè)試：測(cè)試軟件系統(tǒng)對(duì)非法侵入的防范能力。7） 配置測(cè)試：測(cè)試在不同網(wǎng)絡(luò)、服務(wù)器、工作站的不同軟硬件配置條件下，軟件系統(tǒng)的質(zhì)量。9) 安裝測(cè)試：確保軟件系統(tǒng)在所有可能情況下的安裝效果和一旦安裝之后必須保證正確運(yùn)行的質(zhì)量。3.6 測(cè)試驅(qū)動(dòng)研發(fā)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（英文全稱Test-Driven Development，簡(jiǎn)稱TDD），以用戶故事為基準(zhǔn)，包括產(chǎn)品用戶故事與迭代用戶故事，驅(qū)動(dòng)研發(fā)逐步實(shí)現(xiàn)所有產(chǎn)品用戶故事以及每個(gè)迭代中的用戶故事。

20、它要求在編寫(xiě)某個(gè)功能的代碼之前先編寫(xiě)按照用戶故障編寫(xiě)出測(cè)試用例，然后通過(guò)測(cè)試用例驗(yàn)證來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行。測(cè)試驅(qū)動(dòng)研發(fā)總體分為二大步：1測(cè)試用例設(shè)計(jì)。開(kāi)發(fā)、測(cè)試人員從設(shè)計(jì)文檔、用戶故事著手，參考客戶需求看看用戶故事是否已經(jīng)覆蓋客戶的要求，對(duì)有疑問(wèn)的地方與文檔設(shè)計(jì)人員、PO溝通清楚。當(dāng)搞清楚整個(gè)設(shè)計(jì)思路以及所有用戶故事以后，再來(lái)進(jìn)行測(cè)試用例設(shè)計(jì)。測(cè)試用例設(shè)計(jì)由開(kāi)發(fā)人員完成，測(cè)試人員審核。測(cè)試用例需共享給項(xiàng)目組其他成員，因?yàn)槠渌蓡T開(kāi)發(fā)的時(shí)候需要參照到這些測(cè)試用例，避免出現(xiàn)未考慮到的地方。2測(cè)試用例執(zhí)行。當(dāng)某個(gè)用戶故事開(kāi)發(fā)完成后，測(cè)試人員開(kāi)始測(cè)試，驗(yàn)證用戶故事是否實(shí)現(xiàn)，是否滿足用例預(yù)期結(jié)果。測(cè)試前

21、或者測(cè)試中，測(cè)試人員及時(shí)與開(kāi)發(fā)需隨時(shí)進(jìn)行討論，討論這個(gè)用戶故事測(cè)試覆蓋點(diǎn)。之前測(cè)試用例已經(jīng)寫(xiě)完了，但是這個(gè)測(cè)試用例是基于原有設(shè)計(jì)用戶故事的，實(shí)際的功能怎么樣子，并不非常清楚。而現(xiàn)在實(shí)際功能做出來(lái)了，對(duì)于一個(gè)測(cè)試人員而言，就能得到基本的測(cè)試點(diǎn)。而討論的目的就是盡可能全的把測(cè)試點(diǎn)覆蓋全。開(kāi)發(fā)根據(jù)討論結(jié)果，更新測(cè)試用例，測(cè)試人員審核通過(guò)后作為后期測(cè)試驗(yàn)收用戶故事的依據(jù)。3.7 持續(xù)集成測(cè)試持續(xù)集成測(cè)試是指開(kāi)發(fā)團(tuán)隊(duì)中的每個(gè)成員都盡量頻繁地把他們所做的工作更改合入到源碼庫(kù)中，并且還要驗(yàn)證新合入的變化沒(méi)有造成任何破壞。這里的源碼庫(kù)指的是版本控制工具（比如：CVS或者SVN）管理的軟件源代碼儲(chǔ)存地。這里的頻

22、繁程度和團(tuán)隊(duì)所開(kāi)發(fā)的軟件類型有關(guān)，但是一般來(lái)說(shuō)頻度應(yīng)該不大于1個(gè)小時(shí)。 實(shí)現(xiàn)持續(xù)集成測(cè)試的幾部分的工作： 1、將所有的源代碼保存在單一的地點(diǎn)，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）；2、支持自動(dòng)化創(chuàng)建腳本，使創(chuàng)建過(guò)程完全自動(dòng)化，讓任何人都可以只輸入一條命令就完成系統(tǒng)的創(chuàng)建； 3、測(cè)試完全自動(dòng)化，要求開(kāi)發(fā)人員提供自測(cè)試的代碼，讓任何人都可以只輸入一條命令就運(yùn)行一套完整的系統(tǒng)測(cè)試；4、確保所有人都可以得到最新、最好的可執(zhí)行文件。  持續(xù)集成測(cè)試最基本的優(yōu)點(diǎn)就是：它完全避免了開(kāi)發(fā)者們的"除蟲(chóng)會(huì)議"-以前開(kāi)發(fā)者們經(jīng)常需要開(kāi)這樣的會(huì)，因?yàn)槟?/p>

23、個(gè)人在工作的時(shí)候踩進(jìn)了別人的領(lǐng)域、影響了別人的代碼，而被影響的人還不知道發(fā)生了什么，于是bug就出現(xiàn)了。這種bug是最難查的，因?yàn)閱?wèn)題不是出在某一個(gè)人的領(lǐng)域里，而是出在兩個(gè)人的交流上面。隨著時(shí)間的推移，問(wèn)題會(huì)逐漸惡化。通常，在集成階段出現(xiàn)的bug早在幾周甚至幾個(gè)月之前就已經(jīng)存在了。結(jié)果，開(kāi)發(fā)者需要在集成階段耗費(fèi)大量的時(shí)間和精力來(lái)尋找這些bug的根源。 如果使用持續(xù)集成測(cè)試，這樣的bug絕大多數(shù)都可以在引入的同一天就被發(fā)現(xiàn)。而且，由于一天之中發(fā)生變動(dòng)的部分并不多，所以可以很快找到出錯(cuò)的位置。如果找不到bug究竟在哪里，你也可以不把這些錯(cuò)誤的代碼集成到產(chǎn)品中去。即使在最壞的情況下，你也只是不添加引

24、起bug的特性而已。所以，持續(xù)集成可以減少集成階段"捉蟲(chóng)"消耗的時(shí)間，從而最終提高生產(chǎn)力。4 移動(dòng)互聯(lián)網(wǎng)終端測(cè)試4.1 用戶體驗(yàn)測(cè)試移動(dòng)互聯(lián)網(wǎng)終端應(yīng)用用戶體驗(yàn)測(cè)試從視、聽(tīng)、觸、反應(yīng)速度、可用性、易用性幾個(gè)方面出發(fā)，來(lái)測(cè)試終端應(yīng)用的用戶體驗(yàn)?！耙暋笔侵笐?yīng)用界面UI布局是否合理、視效是否美觀、顏色搭配是否協(xié)調(diào)、不同分辨率下是否可以正常運(yùn)行?！奥?tīng)”是針對(duì)具有音頻播放功能的應(yīng)用，應(yīng)用使用的各種音頻聽(tīng)起來(lái)感覺(jué)是否悅耳、使人舒暢，有沒(méi)有雜音、電流音、刺耳的高音等?！坝|”是指應(yīng)用的使用觸感，與終端屏幕、鍵盤(pán)有一定相關(guān)性。應(yīng)用中的各種窗口控件、對(duì)話框觸擊使用時(shí)觸感是否使用愉悅。“反應(yīng)速度”

25、是指終端應(yīng)用使用過(guò)程中，點(diǎn)擊某個(gè)功能按鈕、菜單后，應(yīng)用的反應(yīng)速度有多快，是否滿足用戶使用習(xí)慣。通常一個(gè)操作反應(yīng)時(shí)間超過(guò)2秒，用戶便能夠感知到慢。如果超過(guò)3秒，容易使用戶感到不滿。超過(guò)4秒，用戶則不愿意接受?！翱捎眯浴睖y(cè)試是指終端應(yīng)用功能是否可用，有無(wú)缺陷。除基本功能實(shí)現(xiàn)以外，是否有其他明顯影響使用的缺陷，是否滿足正常操作習(xí)慣?！坝脩趔w驗(yàn)易用性”測(cè)試主要是檢測(cè)用戶在理解和使用系統(tǒng)方面到底有多好，是否存在障礙或難以理解的部分。用戶體驗(yàn)易用性的測(cè)試方法，一般是通過(guò)用戶訪談，或邀請(qǐng)內(nèi)測(cè)、小范圍公測(cè)等方式進(jìn)行，通過(guò)不同實(shí)驗(yàn)組的運(yùn)營(yíng)結(jié)果來(lái)判斷是否存在易用性缺陷。注意用戶體驗(yàn)易用性測(cè)試由于缺乏有效的測(cè)試工具

26、，必須大量的測(cè)試樣本才能獲得比較真實(shí)的測(cè)試數(shù)據(jù)，投入資源較多，測(cè)試周期較長(zhǎng)。4.2 平臺(tái)兼容性測(cè)試兼容性測(cè)試是核實(shí)測(cè)試對(duì)象在不同的軟件系統(tǒng)、硬件配置中的運(yùn)行情況，測(cè)試系統(tǒng)在各種軟硬件配置，不同的參數(shù)配置下系統(tǒng)具有的功能、功耗、性能和用戶體驗(yàn)。移動(dòng)互聯(lián)網(wǎng)終端應(yīng)用的兼容性測(cè)試包含內(nèi)容：操作的兼容性：覆蓋智能機(jī)三個(gè)主流操作系統(tǒng)，iOS, Android和Windows Mobile。硬件兼容性：不同分辨率下的兼容性測(cè)試。4.3 不同網(wǎng)絡(luò)環(huán)境下測(cè)試驗(yàn)證不同網(wǎng)絡(luò)環(huán)境下，終端應(yīng)用功能與性能方面是否正常(數(shù)據(jù)業(yè)務(wù)是否會(huì)中斷，業(yè)務(wù)模塊是否出現(xiàn)異常)。網(wǎng)絡(luò)環(huán)境包含：3G強(qiáng)信號(hào)3G中強(qiáng)信號(hào)2G強(qiáng)信號(hào)2G中強(qiáng)信號(hào)4

27、.4 多事務(wù)并發(fā)測(cè)試移動(dòng)互聯(lián)網(wǎng)終端應(yīng)用有自身的特殊性，終端上支持的應(yīng)用很多，許多應(yīng)用事務(wù)會(huì)并發(fā)產(chǎn)生（同一時(shí)間產(chǎn)生或者某一應(yīng)用使用過(guò)程并發(fā)其他應(yīng)用事務(wù)）。終端應(yīng)用使用過(guò)程通常會(huì)有以下一些并發(fā)事務(wù)：短信并發(fā)彩信并發(fā)來(lái)電并發(fā)鬧鐘、日程并發(fā)藍(lán)牙事務(wù)并發(fā)傳感器事務(wù)并發(fā)其他第三方應(yīng)用事務(wù)并發(fā)（如天氣預(yù)報(bào)）4.5 安裝、卸載測(cè)試安裝測(cè)試驗(yàn)證應(yīng)用程序安裝包/APK安裝包能否成功安裝到移動(dòng)終端上，以及安裝后能否正常打開(kāi)使用。卸載測(cè)試驗(yàn)證已經(jīng)安裝的應(yīng)用程序/APK包是否能成功地卸載。Android終端應(yīng)用程序安裝、卸載測(cè)試可借助MonkeyRunner工具來(lái)開(kāi)展。4.6 安全性、接口測(cè)試安全性測(cè)試側(cè)重于安全性的兩

28、個(gè)關(guān)鍵方面：1應(yīng)用程序級(jí)別的安全性，包括對(duì)數(shù)據(jù)或業(yè)務(wù)功能的訪問(wèn)。應(yīng)用程序級(jí)別的安全性可確保：在預(yù)期的安全性情況下，不同權(quán)限用戶只能訪問(wèn)特定的功能或用例，或者只能訪問(wèn)有限的數(shù)據(jù)。例如，可能會(huì)允許所有人輸入數(shù)據(jù)，創(chuàng)建新賬戶，但只有管理員才能刪除這些數(shù)據(jù)或賬戶。如果具有數(shù)據(jù)級(jí)別的安全性，測(cè)試就可確?！坝脩纛愋鸵弧?能夠看到所有客戶消息（包括財(cái)務(wù)數(shù)據(jù)），而“用戶二”只能看見(jiàn)同一客戶的統(tǒng)計(jì)數(shù)據(jù)。2. 系統(tǒng)級(jí)別的安全性，包括對(duì)系統(tǒng)的登錄或遠(yuǎn)程訪問(wèn)。系統(tǒng)級(jí)別的安全性可確保只有具備系統(tǒng)訪問(wèn)權(quán)限的用戶才能訪問(wèn)應(yīng)用程序，而且只能通過(guò)相應(yīng)的網(wǎng)關(guān)來(lái)訪問(wèn)。接口測(cè)試指測(cè)試應(yīng)用與終端本地其他應(yīng)用的接口，主要測(cè)試接口功能是否

29、實(shí)現(xiàn)，是否會(huì)引起本地其他應(yīng)用異常。本地其他應(yīng)用主要包括：音頻模塊，視頻模塊，藍(lán)牙模塊，聯(lián)系人，短信，彩信，通話記錄等。5 測(cè)試工具和環(huán)境 5.1 單元測(cè)試工具 工具名稱：Junit（java），Qunit(JSP)，Visual Unit(C/C+)。適用測(cè)試類型：?jiǎn)卧幋a完成輸出物：?jiǎn)卧獪y(cè)試報(bào)告5.2 功能回歸測(cè)試工具工具名稱：QTP，MonkeyRunner。適用測(cè)試類型：穩(wěn)定模塊功能回歸測(cè)試，適用每日構(gòu)件版本，持續(xù)集成版本。輸出物：測(cè)試報(bào)告5.3 性能測(cè)試工具工具名稱：LoadRunner，Monkey適用測(cè)試類型：迭代持續(xù)集成版本（選擇性執(zhí)行），最終驗(yàn)收版本。輸出物：測(cè)試報(bào)告5.4 持續(xù)集成測(cè)試環(huán)境工具名稱：Cruis