測試技術(shù)方案模板

1、XX市XX軟件開發(fā)項目內(nèi)部測試方案修訂人簽字：審核人簽字：批準(zhǔn)人簽字：日期：日期：日期：修訂歷史紀(jì)錄變更類型：增加/修訂/刪除版本號日期變更類型修改人摘要備注V1.014 / 14目錄1 弓I言41.1 系統(tǒng)概述41.2 文檔概述41.3 范圍41.4 目標(biāo)讀者及閱讀建議51.5 參考文檔52 軟件測試環(huán)境52.1 測試環(huán)境52.2 參與組織62.3 人員角色62.4 測試工具63 計劃73.1 總體計戈U73.1.1 測試級73.1.2 測試準(zhǔn)備73.1.3 測試類別73.2 計劃執(zhí)行的測試93.2.1 測試范圍93.2.2 測試重點103.2.3 測試入口準(zhǔn)則103.2.4 測試通過標(biāo)準(zhǔn)1

2、03.3 測試用例114 測試實施114.1 輪次執(zhí)行114.2 測試計劃124.3 缺陷管理125 測試評價126 風(fēng)險預(yù)估和應(yīng)對137 測試輸出物141引言1.1 系統(tǒng)概述隨著廣大XX市民百姓對住房需求的增加，住房市場呈現(xiàn)高速發(fā)展趨勢，管理中心各項業(yè)務(wù)得到了快速發(fā)展。業(yè)務(wù)的發(fā)展與信息系統(tǒng)的發(fā)展是相輔相成的，住房資金業(yè)務(wù)的快速發(fā)展、信息技術(shù)日新月異的發(fā)展和廣大市民百姓對政府服務(wù)水平預(yù)期的不斷提高，對管理中心信息化系統(tǒng)的建設(shè)提出了更高要求。為實現(xiàn)管理中心未來五年業(yè)務(wù)發(fā)展目標(biāo)，通過業(yè)務(wù)需求驅(qū)動和先進(jìn)技術(shù)需求驅(qū)動重構(gòu)管理中心核心業(yè)務(wù)系統(tǒng)。本次系統(tǒng)重建的業(yè)務(wù)需求主要包括創(chuàng)新面向個人辦理業(yè)務(wù)的業(yè)務(wù)模式

3、、豐富服務(wù)渠道、優(yōu)化業(yè)務(wù)流程、提高資金管理水平、有效管控風(fēng)險、提高辦公效率，促進(jìn)信息共享等方面；技術(shù)需求包括構(gòu)建全新技術(shù)架構(gòu)重構(gòu)核心系統(tǒng)、運用云計算和大數(shù)據(jù)技術(shù)有效處理數(shù)據(jù)支持決策分析、持續(xù)提升安全體系建設(shè)、持續(xù)提升IT服務(wù)保障體系建設(shè)、升級基礎(chǔ)設(shè)施條件等。1.2 文檔概述本文檔描述了XX市XX管理中心系統(tǒng)內(nèi)部測試階段工作的相關(guān)情況，內(nèi)容包括進(jìn)行測試的環(huán)境、測試工作的標(biāo)識以及測試工作的時間安排等，在實際工作中指導(dǎo)測試人員完成測試工作。主要包括以下幾點目的： 盡可能發(fā)現(xiàn)被測試軟件中的錯誤，以便開發(fā)人員進(jìn)行修正，提高軟件的可靠性； 確定測試策略，并對測試策略加以說明。另，本文檔不涉及性能測試，具體

4、內(nèi)容見性能測試方案； 確定所需資源，對測試工作量進(jìn)行估計； 客觀反映產(chǎn)品中存在的缺陷，為提高產(chǎn)品質(zhì)量服務(wù)； 完成本階段的測試工作，為產(chǎn)品交付做準(zhǔn)備。1.3 范圍設(shè)計針對XX市XX中心業(yè)務(wù)系統(tǒng)的系統(tǒng)測試一功能測試方案。通過上述方案用以驗證： 產(chǎn)品功能是否滿足需求規(guī)定并能夠正常運行一一功能測試； 用戶界面是否與需求保持一致，保證用戶界面的友好性、易操作性一一用戶界面測試； 產(chǎn)品性能是否滿足需求規(guī)定并能夠正常運行一一性能測試；1.4 目標(biāo)讀者及閱讀建議目標(biāo)讀者閱讀建議項目經(jīng)理及評審人員全文檔仔細(xì)閱讀測試負(fù)責(zé)人及測試工程師全文檔仔細(xì)閱讀開發(fā)工程師仔細(xì)閱讀“章節(jié)2”-“章節(jié)4”，其他部分了解性閱讀1.5

5、 參考文檔文檔參考內(nèi)容作者或來源使用備注GBT-8567-2006計算機軟件文檔編制規(guī)范：軟件測試計劃（STP）文檔格式確定文檔格式及涉及內(nèi)容需求規(guī)格說明書項目組確定測試需求及策略大/中日程計劃測試計劃項目組確定測試計劃及人員安排2軟件測試環(huán)境2.1 測試環(huán)境硬件用途客戶端硬件配置信息數(shù)量軟件分類軟件名稱版本操作系統(tǒng)瀏覽器數(shù)據(jù)庫客戶端服務(wù)器硬件配置信息數(shù)量軟件分類軟件名稱版本操作系統(tǒng)WEB中間件數(shù)據(jù)庫2.2 參與組織參與方人員提供資源參與工作參與階段參與時間備注?2.3 人員角色卜表列出了在項目內(nèi)部測試工作過程中的人員配備:角色人員職責(zé)項目經(jīng)理?提供技術(shù)指導(dǎo)并獲取適當(dāng)資源?負(fù)責(zé)整個項目中的協(xié)調(diào)

6、工作測試負(fù)責(zé)人?編寫測試方案、計劃?項目測試的日常管理工作?監(jiān)控測試工作，規(guī)避風(fēng)險?編寫系統(tǒng)測試報告等測試工程師?編制和維護(hù)測試用例?執(zhí)行測試并記錄結(jié)果?缺陷跟蹤開發(fā)工程師?對程序缺陷進(jìn)行修改?程序新版本發(fā)布?必要時參加進(jìn)行功能測試2.4 測試工具工具類型工具名稱版本備注用例管理工具缺陷管理工具數(shù)據(jù)庫項目管理3計劃3.1 總體計劃該系統(tǒng)測試的策略有功能測試、用戶界面測試和性能測試，功能測試要覆蓋系統(tǒng)中的每個功能。在功能測試時既要輸入正確的數(shù)據(jù)，測試功能是否滿足，也要對每個功能中的每個數(shù)據(jù)輸入域故意輸入錯誤的數(shù)據(jù)，測試系統(tǒng)的健壯性。用戶界面測試核實各個窗口風(fēng)格（包括顏色、字體、提示信息、圖標(biāo)、T

7、itle等）都與需求保持一致，或符合可接受標(biāo)準(zhǔn)，保證用戶界面的友好性、易操作性，而且符合用戶操作習(xí)慣。性能測試往往針對軟件的一部分功能，進(jìn)行專項測試。執(zhí)行完一組工作后，及時檢查是否已達(dá)到預(yù)定目標(biāo)，是否已執(zhí)行完該過程所有的步驟等，如實際情況與計劃出入較大，應(yīng)及時調(diào)整計劃?？紤]到各種因素和條件的限制，采用黑盒測試方案，即根據(jù)軟件所需要的輸入數(shù)據(jù)的格式以及應(yīng)該完成的功能，設(shè)計一些合法的測試用例和不合法的測試用例，特別是根據(jù)邊界條件設(shè)計一些邊界測試用例，以檢查系統(tǒng)是否能正確地完成預(yù)期功能，得到希望的輸出；或者是對不合法的輸入和操作能夠正確地識別和防御。3.1.1 測試級執(zhí)行的測試級別為系統(tǒng)級。3.1.

8、2 測試準(zhǔn)備 測試方案編寫完成并郵件告知項目組成員； 測試組根據(jù)需求規(guī)格說明書完成測試內(nèi)容確認(rèn)和重點交易列表，需項目經(jīng)理或開發(fā)人員確認(rèn)； 項目經(jīng)理安排相關(guān)人員完成內(nèi)部測試環(huán)境的配置； 測試開始前將與開發(fā)人員配合將“測試相關(guān)信息.xls”文檔整理完成，包括測試環(huán)境配置、Bugfree用戶信息，柜員信息等；3.1.3 測試類別3.1.3.1 功能測試功能測試側(cè)重于可以被直接追蹤利用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的所有測試需求。這些測試的目標(biāo)在于核實能否正確的接受、處理和檢索數(shù)據(jù)以及業(yè)務(wù)規(guī)則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面（GUI）與應(yīng)用程序交互并分析輸出結(jié)果來驗證應(yīng)用程序及其內(nèi)

9、部進(jìn)程。以下列出測試方法概要：測試范圍：驗證數(shù)據(jù)精確度、數(shù)據(jù)類型、業(yè)務(wù)功能等相關(guān)方面的正確性測試目標(biāo)：核實所有功能均已正常實現(xiàn)，且與需求一致。方法：利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例或功能，以核實以下內(nèi)容：?在使用有效的數(shù)據(jù)時得到預(yù)期結(jié)果；?在使用無效的數(shù)據(jù)時顯示相應(yīng)的錯誤信息或警告；?各業(yè)務(wù)規(guī)則都得到了正確的應(yīng)用；依據(jù)：測試用例完成標(biāo)準(zhǔn)：?所計劃的測試已全部執(zhí)行?所發(fā)現(xiàn)的缺陷已全部解決（無1,2級遺留缺陷）需考慮的特殊事項3.1.3.2 用戶界面（UI）測試用戶界面（UI）測試用于核實用戶與軟件之間的交互。UI測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。另

10、外，UI測試還可確保UI中的對象按照預(yù)期的方式運行，并符合公司或行業(yè)的標(biāo)準(zhǔn)。測試范圍：1、導(dǎo)航、鏈接、Cookie、貝囿結(jié)構(gòu)（包括菜單、背景、顏色）、字體、按鈕名稱、Title、提示信息的f性等2、友好性、可操作性、易用性測試目標(biāo)：核實各個窗口風(fēng)格（包括顏色、字體、提示信息、圖標(biāo)、Title等）都與需求保持一致，或符合可接受標(biāo)準(zhǔn)，能夠保證用戶界面的友好性、易操作性，而且符合用戶操作習(xí)慣。方法：WEB非功能性通用測試方法，手工測試完成標(biāo)準(zhǔn)：UI符合可接受標(biāo)準(zhǔn)，能夠保證用戶界面的友好性、易操作性，而且符合用戶操作習(xí)慣需考慮的特殊事項重點測試網(wǎng)上業(yè)務(wù)平臺、政務(wù)網(wǎng)站等對外門戶的用戶界面。3.1.3.3

11、 性能測試性能測試對響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的需求進(jìn)行評測和評估。性能測試的目標(biāo)是核實性能需求是否都已滿足。實施和執(zhí)行性能測試的目的是將測試對象的性能行為當(dāng)作條件（例如工作量或硬件配置）的一種函數(shù)來進(jìn)行測試和微調(diào)。測試范圍：多用戶長時間在線操作時性能方面的測試測試目標(biāo)：核實系統(tǒng)在大流量的數(shù)據(jù)與多用戶操作時軟件性能的穩(wěn)定性，不造成系統(tǒng)崩潰或相關(guān)的異?，F(xiàn)象。方法：使用loadrunner工具進(jìn)行測試完成標(biāo)準(zhǔn)：系統(tǒng)滿足用戶需求中所要求的性能要求需考慮的特殊事項3.2 計劃執(zhí)行的測試3.2.1 測試范圍序號分類核心用例來源用例編寫人員測試策略備注1功能測試、用戶界面測試、性能測試2345

12、6789101112131415161718192021序號分類核心用例來源用例編寫人員測試策略備注2223242526272829303132注：具體各核心內(nèi)容下的交易見“交易測試情況一覽表”，此處不逐一列出。3.2.2 測試重點測試重點主要從以下幾個方面考慮，針對測試重點，在用例的編寫與評審、人員安排、測試輪次、Bug解決要求等方面都應(yīng)高于其他部分。 需求中，優(yōu)先級高的重點功能或用戶的常用功能； 開發(fā)過程中，重點關(guān)注的模塊、功能及特性（此項通過交易的代碼修改量等內(nèi)容確定，由項目經(jīng)理提供）； 相關(guān)領(lǐng)導(dǎo)的關(guān)注點和意見； 開發(fā)人員的能力和水平差異； 以往版本或其他項目中的常見問題；注：此項內(nèi)容由

13、項目經(jīng)理配合進(jìn)行確認(rèn)，具體交易列表及重點測試交易，見“交易測試情況一覽表”，此處不逐一列出。3.2.3 測試入口準(zhǔn)則在提交測試組進(jìn)行系統(tǒng)測試前，開發(fā)工程師需要經(jīng)過自測試以及開發(fā)組組內(nèi)互測；測試組接收測試，且通過冒煙測試后，方可進(jìn)行系統(tǒng)測試。3.2.4 測試通過標(biāo)準(zhǔn)系統(tǒng)無業(yè)務(wù)邏輯錯誤和二級缺陷，經(jīng)確定的所有缺陷都已得到商定的解決結(jié)果； 設(shè)計的測試用例全部執(zhí)行完成，由于其他因素導(dǎo)致未能執(zhí)行的用例有相應(yīng)記錄； 2.1節(jié)中規(guī)定的所有功能點，測試覆蓋率=100%,有效Bug的關(guān)閉率=90%; 滿足聯(lián)合測試和第三方測評要求。3.3測試用例1測試用例分類測試用例與測試類型對應(yīng)：功能測試用例、用戶界面測試用例

14、及性能測試用例重點用例通過用例中的用例級別進(jìn)行標(biāo)記：A-關(guān)鍵業(yè)務(wù)正常流測試B-功能點詳細(xì)測試C-交互測試：主要測試界面、易用性等內(nèi)容D-異常測試2測試用例評審組內(nèi)評審：測試組內(nèi)部采用交叉評審方式，對已做成測試用例進(jìn)行評審；組外評審：開發(fā)組的相關(guān)人員（由項目經(jīng)理或部門經(jīng)理指定），對測試一覽表中重點交易的用例進(jìn)行評審；4測試實施4.1輪次執(zhí)行輪次內(nèi)容備注第一輪1、第二輪1、第三輪1.其他注意事項：1測試工程師根據(jù)測試用例進(jìn)行測試，并將測試中發(fā)現(xiàn)的Bug,記錄到Bugfree中;2開發(fā)工程師對Bug進(jìn)行修改，并說明Bug產(chǎn)生的原因及產(chǎn)生階段；3如果對需要修改的Bug意見不統(tǒng)一，則由項目經(jīng)理確認(rèn)修改意

15、見；4第二輪系統(tǒng)測試開始，測試工程師首先對第一輪測試中遺留的問題進(jìn)行回歸驗證，即驗證上一輪發(fā)現(xiàn)的Bug是否已經(jīng)全部得到解決?；貧w測試完成后，測試工程師再根據(jù)測試用例，開展新的系統(tǒng)測試工作；5第三輪系測試，結(jié)合核心系統(tǒng)進(jìn)行測試，同時加強對業(yè)務(wù)系統(tǒng)中重點交易的測試。4.2測試計劃項目里程碑任務(wù)開始時間結(jié)束時間輸出物執(zhí)行人員備注制定測試方案編寫測試方案內(nèi)部測試方案設(shè)計測試測試用例編寫測試用例測試用例評審測試用例評審記錄表執(zhí)行測試內(nèi)部測試第一輪缺陷記錄、輪次測試報告內(nèi)部測試第二輪缺陷記錄、輪次測試報告內(nèi)部測試第三輪缺陷記錄、輪次測試報告評估測試測試總結(jié)內(nèi)部測試報告注：輪次測試的具體內(nèi)容會根據(jù)各子系統(tǒng)開

16、發(fā)進(jìn)度做適當(dāng)調(diào)整。4.3缺陷管理參見«03Bugfree填寫規(guī)范V1.0.4.doc。5測試評價系統(tǒng)測試完畢，提供以下度量指標(biāo)結(jié)果用以評估項目質(zhì)量并輸出測試報告:度量指標(biāo)名稱定義/計算公式指標(biāo)目的數(shù)據(jù)主要來源測試功能點總數(shù)（個）測試功能點總數(shù)=各級測試功能點數(shù)之和；統(tǒng)計測試規(guī)?！案郊?:交易測試情況一覽表.xls”功能點測試生產(chǎn)率（個/人月）功能點測試生產(chǎn)率=測試功能點總數(shù)/測試組實際總工作衡量測試組的生產(chǎn)率度量指標(biāo)名稱定義/計算公式指標(biāo)目的數(shù)據(jù)主要來源量；系統(tǒng)功能測試輪次（輪）指測試組實際進(jìn)行的系統(tǒng)功能測試輪數(shù)；預(yù)估類似項目的平均測試輪數(shù)Bugfree測試覆蓋率（100%）功能點測

17、試覆蓋率=測試功能點總數(shù)/功能點總數(shù)；衡量測試的覆蓋程度“附件1:交易測試情況一覽表.xls”功能點測試通過率（100%）完全通過功能點數(shù)/測試功能點總數(shù)由此指標(biāo)，可衡量代碼開發(fā)的質(zhì)量。Bug關(guān)閉率(100%)Bug總關(guān)閉率=已關(guān)閉Bug總數(shù)/有效Bug總數(shù)*100%1、衡量開發(fā)人員對Bug的解決程度；2、判斷產(chǎn)品交付時的遺留Bug數(shù)BugFree測試密度（個/功能）測試密度=實際測試用區(qū)J數(shù)/功能點總數(shù)衡量測試用例顆粒度是否適當(dāng)測試用例Bug密度1（個/功能）Bug密度1=實際Bug數(shù)/功能點總數(shù)衡量bug產(chǎn)出是否在合理范圍內(nèi)BugFreeBug密度2（個/功能）Bug密度2=實際Bug數(shù)/

18、代碼變動數(shù)衡量代碼變動產(chǎn)生的bug數(shù)是合理BugFree6風(fēng)險預(yù)估和應(yīng)對下表列出了在項目測試工作中存在的各種風(fēng)險的假定，需要考慮項目測試過程中可能發(fā)生的具體事務(wù)，分別分析并加以應(yīng)對，然后體現(xiàn)到測試計劃中。風(fēng)險類型風(fēng)險責(zé)任方風(fēng)險內(nèi)容處理優(yōu)先級應(yīng)對措施備注時間計劃人員風(fēng)險資源協(xié)調(diào)插入事務(wù)任務(wù)超預(yù)期注：各個風(fēng)險類型解釋如下：?時間計劃：關(guān)鍵Milestone無法匹配的延期風(fēng)險；?人員風(fēng)險：測試人員和需配合方的人員的變動導(dǎo)致的工作任務(wù)無法按計劃完成或者完成質(zhì)量無法保證的風(fēng)險，包括新人風(fēng)險、人員變化、投入不足、投入質(zhì)量不高等；?資源協(xié)調(diào)：包括所需資源不能如期到位，或者資源質(zhì)量低于預(yù)期等風(fēng)險。比如測試工具開發(fā)的風(fēng)險、各個階段交付物的質(zhì)量風(fēng)險等；?插入事務(wù)：包括臨