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

1、Word 格式XX市 XX軟件開發(fā)項目內(nèi)部測試方案修訂人簽字：審核人簽字：批準人簽字：日期：日期：日期：完美整理Word 格式修訂歷史紀錄變更類型：增加 / 修訂 / 刪除版本號日期變更類型修改人摘要備注V1.0完美整理Word 格式目錄1引言 . .41.1系統(tǒng)概述 . .41.2文檔概述 . .41.3范圍 . .41.4目標讀者及閱讀建議 . .51.5參考文檔 . .52軟件測試環(huán)境 . .52.1測試環(huán)境 . .52.2參與組織 . .62.3人員角色 . .62.4測試工具 . .63計劃 . .73.1總體計劃 . .73.1.1測試級 .73.1.2測試準備 .73.1.3測試

2、類別 .73.2計劃執(zhí)行的測試 . .93.2.1測試范圍 .93.2.2測試重點 .103.2.3測試入口準則 .103.2.4測試通過標準 .103.3測試用例 . .114測試實施 . .114.1輪次執(zhí)行 . .114.2測試計劃 . .114.3缺陷管理 . .125測試評價 . .126風險預(yù)估和應(yīng)對 . .137測試輸出物 . .14完美整理Word 格式1 引言1.1系統(tǒng)概述隨著廣大XX市民百姓對住房需求的增加，住房市場呈現(xiàn)高速發(fā)展趨勢，管理中心各項業(yè)務(wù)得到了快速發(fā)展。業(yè)務(wù)的發(fā)展與信息系統(tǒng)的發(fā)展是相輔相成的，住房資金業(yè)務(wù)的快速發(fā)展、信息技術(shù)日新月異的發(fā)展和廣大市民百姓對政府服務(wù)

3、水平預(yù)期的不斷提高，對管理中心信息化系統(tǒng)的建設(shè)提出了更高要求。為實現(xiàn)管理中心未來五年業(yè)務(wù)發(fā)展目標，通過業(yè)務(wù)需求驅(qū)動和先進技術(shù)需求驅(qū)動重構(gòu)管理中心核心業(yè)務(wù)系統(tǒng)。本次系統(tǒng)重建的業(yè)務(wù)需求主要包括創(chuàng)新面向個人辦理業(yè)務(wù)的業(yè)務(wù)模式、豐富服務(wù)渠道、優(yōu)化業(yè)務(wù)流程、提高資金管理水平、有效管控風險、提高辦公效率， 促進信息共享等方面；技術(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)容包括進行測試的環(huán)境、 測試工作的標識以及

4、測試工作的時間安排等，在實際工作中指導(dǎo)測試人員完成測試工作。主要包括以下幾點目的： 盡可能發(fā)現(xiàn)被測試軟件中的錯誤，以便開發(fā)人員進行修正，提高軟件的可靠性； 確定測試策略， 并對測試策略加以說明。另，本文檔不涉及性能測試，具體內(nèi)容見性能測試方案； 確定所需資源，對測試工作量進行估計； 客觀反映產(chǎn)品中存在的缺陷，為提高產(chǎn)品質(zhì)量服務(wù)； 完成本階段的測試工作，為產(chǎn)品交付做準備。1.3范圍設(shè)計針對XX市 XX 中心業(yè)務(wù)系統(tǒng)的系統(tǒng)測試功能測試方案。通過上述方案用以驗證： 產(chǎn)品功能是否滿足需求規(guī)定并能夠正常運行功能測試； 用戶界面是否與需求保持一致，保證用戶界面的友好性、易操作性用戶界面測試； 產(chǎn)品性能是否

5、滿足需求規(guī)定并能夠正常運行性能測試；完美整理Word 格式1.4目標讀者及閱讀建議目標讀者閱讀建議項目經(jīng)理及評審人員全文檔仔細閱讀測試負責人及測試工程師全文檔仔細閱讀開發(fā)工程師仔細閱讀“章節(jié)2” - “章節(jié)4”，其他部分了解性閱讀1.5參考文檔文檔參考內(nèi)容作者或來源使用備注GBT-8567-2006 計算機軟文檔格式確定文檔格式及涉及內(nèi)容件文檔編制規(guī)范： 軟件測試計劃 (STP)需求規(guī)格說明書項目組確定測試需求及策略大/ 中日程計劃測試計劃項目組確定測試計劃及人員安排2 軟件測試環(huán)境2.1測試環(huán)境硬件配置信息數(shù)量軟件分類軟件名稱版本客戶端操作系統(tǒng)硬瀏覽器件數(shù)據(jù)庫客戶端用硬件配置信息數(shù)量途軟件分

6、類軟件名稱版本服務(wù)器操作系統(tǒng)WEB中間件數(shù)據(jù)庫完美整理Word 格式2.2參與組織參與參與參與人員提供資源參與工作備注方階段時間2.3人員角色下表列出了在項目內(nèi)部測試工作過程中的人員配備：角色人員職責項目經(jīng)理提供技術(shù)指導(dǎo)并獲取適當資源負責整個項目中的協(xié)調(diào)工作測試負責人編寫測試方案、計劃項目測試的日常管理工作監(jiān)控測試工作，規(guī)避風險編寫系統(tǒng)測試報告等測試工程師編制和維護測試用例執(zhí)行測試并記錄結(jié)果缺陷跟蹤開發(fā)工程師對程序缺陷進行修改程序新版本發(fā)布必要時參加進行功能測試2.4測試工具工具類型工具名稱版本備注用例管理工具缺陷管理工具數(shù)據(jù)庫項目管理完美整理Word 格式3 計劃3.1總體計劃該系統(tǒng)測試的策

7、略有功能測試、 用戶界面測試和性能測試， 功能測試要覆蓋系統(tǒng)中的每個功能。 在功能測試時既要輸入正確的數(shù)據(jù)， 測試功能是否滿足， 也要對每個功能中的每個數(shù)據(jù)輸入域故意輸入錯誤的數(shù)據(jù)，測試系統(tǒng)的健壯性。用戶界面測試核實各個窗口風格（包括顏色、字體、提示信息、圖標、Title等）都與需求保持一致，或符合可接受標準，保證用戶界面的友好性、易操作性，而且符合用戶操作習慣。性能測試往往針對軟件的一部分功能，進行專項測試。 執(zhí)行完一組工作后，及時檢查是否已達到預(yù)定目標， 是否已執(zhí)行完該過程所有的步驟等，如實際情況與計劃出入較大，應(yīng)及時調(diào)整計劃?？紤]到各種因素和條件的限制，采用黑盒測試方案，即根據(jù)軟件所需要

8、的輸入數(shù)據(jù)的格式以及應(yīng)該完成的功能，設(shè)計一些合法的測試用例和不合法的測試用例，特別是根據(jù)邊界條件設(shè)計一些邊界測試用例，以檢查系統(tǒng)是否能正確地完成預(yù)期功能，得到希望的輸出；或者是對不合法的輸入和操作能夠正確地識別和防御。測試級執(zhí)行的測試級別為系統(tǒng)級。測試準備 測試方案編寫完成并郵件告知項目組成員； 測試組根據(jù)需求規(guī)格說明書完成測試內(nèi)容確認和重點交易列表，需項目經(jīng)理或開發(fā)人員確認； 項目經(jīng)理安排相關(guān)人員完成內(nèi)部測試環(huán)境的配置； 測試開始前將與開發(fā)人員配合將“測試相關(guān)信息.xls”文檔整理完成， 包括測試環(huán)境配置、 Bugfree 用戶信息，柜員信息等；測試類別功能測試功能測試側(cè)重于可以被直接追蹤利

9、用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的所有測試需求。這些測試的目標在于核實能否正確的接受、處理和檢索數(shù)據(jù)以及業(yè)務(wù)規(guī)則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面（GUI）與應(yīng)用程序交互并分析輸完美整理Word 格式出結(jié)果來驗證應(yīng)用程序及其內(nèi)部進程。以下列出測試方法概要：測試范圍：驗證數(shù)據(jù)精確度、數(shù)據(jù)類型、業(yè)務(wù)功能等相關(guān)方面的正確性測試目標：核實所有功能均已正常實現(xiàn)，且與需求一致。方法：利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例或功能，以核實以下內(nèi)容：在使用有效的數(shù)據(jù)時得到預(yù)期結(jié)果；在使用無效的數(shù)據(jù)時顯示相應(yīng)的錯誤信息或警告；各業(yè)務(wù)規(guī)則都得到了正確的應(yīng)用；依據(jù)：測試用例完成標準：所計劃的測試已全部

10、執(zhí)行所發(fā)現(xiàn)的缺陷已全部解決（無1,2 級遺留缺陷）需考慮的特殊事項用戶界面（ UI ）測試用戶界面（ UI ）測試用于核實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預(yù)期的方式運行，并符合公司或行業(yè)的標準。測試范圍：1、導(dǎo)航、鏈接、Cookie 、頁面結(jié)構(gòu)（包括菜單、背景、顏色）、字體、按鈕名稱、Title、提示信息的一致性等2、友好性、可操作性、易用性測試目標：核實各個窗口風格（包括顏色、字體、提示信息、圖標、Title等）都與需求保持一致，或符合可接受標準，能夠保證用戶界面的友好性、易

11、操作性，而且符合用戶操作習慣。方法：WEB非功能性通用測試方法，手工測試完成標準：UI 符合可接受標準，能夠保證用戶界面的友好性、易操作性，而且符合用戶操作習慣需考慮的特殊重點測試網(wǎng)上業(yè)務(wù)平臺、政務(wù)網(wǎng)站等對外門戶的用戶界面。事項性能測試性能測試對響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的需求進行評測和評估。性能測試的目標是核實性能需求是否都已滿足。 實施和執(zhí)行性能測試的目的是將測試對象的性能行為當作條件（例如工作量或硬件配置）的一種函數(shù)來進行測試和微調(diào)。測試范圍：多用戶長時間在線操作時性能方面的測試測試目標：核實系統(tǒng)在大流量的數(shù)據(jù)與多用戶操作時軟件性能的穩(wěn)定性，不完美整理Word 格式造成系統(tǒng)崩

12、潰或相關(guān)的異?，F(xiàn)象。方法：使用 loadrunner工具進行測試完成標準：系統(tǒng)滿足用戶需求中所要求的性能要求需考慮的特殊事項3.2計劃執(zhí)行的測試測試范圍序分類核心用例來源用例編寫測試策略備注號人員1功能測試、用戶界面測試、性能測試234567891011121314151617181920212223完美整理Word 格式序分類核心用例來源用例編寫測試策略備注號人員242526272829303132注：具體各核心內(nèi)容下的交易見“交易測試情況一覽表”，此處不逐一列出。測試重點測試重點主要從以下幾個方面考慮， 針對測試重點， 在用例的編寫與評審、 人員安排、測試輪次、 BUG解決要求等方面都應(yīng)高

13、于其他部分。 需求中，優(yōu)先級高的重點功能或用戶的常用功能； 開發(fā)過程中， 重點關(guān)注的模塊、功能及特性 （此項通過交易的代碼修改量等內(nèi)容確定，由項目經(jīng)理提供）； 相關(guān)領(lǐng)導(dǎo)的關(guān)注點和意見； 開發(fā)人員的能力和水平差異； 以往版本或其他項目中的常見問題；注：此項內(nèi)容由項目經(jīng)理配合進行確認，具體交易列表及重點測試交易，見“交易測試情況一覽表” ，此處不逐一列出。測試入口準則 在提交測試組進行系統(tǒng)測試前，開發(fā)工程師需要經(jīng)過自測試以及開發(fā)組組內(nèi)互測； 測試組接收測試，且通過冒煙測試后，方可進行系統(tǒng)測試。測試通過標準 系統(tǒng)無業(yè)務(wù)邏輯錯誤和二級缺陷，經(jīng)確定的所有缺陷都已得到商定的解決結(jié)果； 設(shè)計的測試用例全部執(zhí)

14、行完成，由于其他因素導(dǎo)致未能執(zhí)行的用例有相應(yīng)記錄； 2.1 節(jié)中規(guī)定的所有功能點，測試覆蓋率=100%，有效 Bug 的關(guān)閉率 >=90%； 滿足聯(lián)合測試和第三方測評要求。完美整理Word 格式3.3測試用例1 測試用例分類測試用例與測試類型對應(yīng)： 功能測試用例、 用戶界面測試用例及性能測試用例重點用例通過用例中的用例級別進行標記：A-關(guān)鍵業(yè)務(wù)正常流測試B-功能點詳細測試C-交互測試：主要測試界面、易用性等內(nèi)容D-異常測試2 測試用例評審組內(nèi)評審：測試組內(nèi)部采用交叉評審方式，對已做成測試用例進行評審；組外評審：開發(fā)組的相關(guān)人員（由項目經(jīng)理或部門經(jīng)理指定），對測試一覽表中重點交易的用例進行

15、評審；4 測試實施4.1輪次執(zhí)行輪次內(nèi)容備注第一輪1、第二輪1、第三輪1.其他注意事項：1測試工程師根據(jù)測試用例進行測試，并將測試中發(fā)現(xiàn)的 Bug，記錄到 Bugfree中；2開發(fā)工程師對 Bug 進行修改，并說明Bug 產(chǎn)生的原因及產(chǎn)生階段；3如果對需要修改的 Bug 意見不統(tǒng)一，則由項目經(jīng)理確認修改意見；4 第二輪系統(tǒng)測試開始，測試工程師首先對第一輪測試中遺留的問題進行回歸驗證，即驗證上一輪發(fā)現(xiàn)的 Bug 是否已經(jīng)全部得到解決。 回歸測試完成后， 測試工程師再根據(jù)測試用例，開展新的系統(tǒng)測試工作；5 第三輪系測試， 結(jié)合核心系統(tǒng)進行測試， 同時加強對業(yè)務(wù)系統(tǒng)中重點交易的測試。4.2測試計劃項

16、目任務(wù)開始時間結(jié)束時間輸出物執(zhí)行人員備注里程碑完美整理Word 格式項目任務(wù)開始時間結(jié)束時間輸出物執(zhí)行人員備注里程碑制定測試編 寫 測內(nèi)部測試方案試方案方案設(shè)計測試測 試 用測試用例例編寫測 試 用測試用例例評審評審記錄表執(zhí)行測試內(nèi) 部 測缺陷記錄、試 第一輪次測試輪報告內(nèi) 部 測缺陷記錄、試 第二輪次測試輪報告內(nèi) 部 測缺陷記錄、試 第三輪次測試輪報告評估測試測 試 總內(nèi)部測試結(jié)報告注：輪次測試的具體內(nèi)容會根據(jù)各子系統(tǒng)開發(fā)進度做適當調(diào)整。4.3缺陷管理參見 03 Bugfree填寫規(guī)范。5 測試評價系統(tǒng)測試完畢，提供以下度量指標結(jié)果用以評估項目質(zhì)量并輸出測試報告：度量指標名稱定義 / 計算公

17、式指標目的數(shù)據(jù)主要來源測試功能點總數(shù)測試功能點總數(shù)統(tǒng)計測試規(guī)?！案郊?1：交易測（個）各級測試功能點數(shù)試 情況一覽之和；表 .xls”功能點測試生產(chǎn)功能點測試生產(chǎn)率衡量測試組的生產(chǎn)率（個 / 人月）= 測試功能點總數(shù)率/ 測試組實際總工作量；系統(tǒng)功能測試指測試組實際進行預(yù)估類似項目的平Bugfree輪次（輪）的系統(tǒng)功能測試輪均測試輪數(shù)完美整理Word 格式度量指標名稱定義 / 計算公式指標目的數(shù)據(jù)主要來源數(shù)；測試覆蓋率功能點測試覆蓋率衡量測試的覆蓋程“附件 1：交易測（ 100%）=測試功能點總數(shù)/度試 情況一覽功能點總數(shù)；表 .xls”功能點測試通過完全通過功能點數(shù)/由此指標， 可衡量代率（

18、 100%）測試功能點總數(shù)碼開發(fā)的質(zhì)量。Bug 關(guān)閉 率Bug 總關(guān)閉率 =已1、衡量開發(fā)人員對BugFree（ 100%）關(guān)閉 Bug 總數(shù) /有Bug 的解決程度；效 Bug 總數(shù) * 100%2、判斷產(chǎn)品交付時的遺留 Bug 數(shù)測試密度（個 / 功測試密度 =實際測試衡量測試用例顆粒測試用例能）用例數(shù) / 功能點總數(shù)度是否適當Bug 密度1（個 /Bug 密度 1=實際 Bug衡量 bug 產(chǎn)出是否BugFree功能）數(shù) / 功能點總數(shù)在合理范圍內(nèi)Bug 密度2（個 /Bug 密度 2=實際 Bug衡量代碼變動產(chǎn)生BugFree功能）數(shù) / 代碼變動數(shù)的 bug 數(shù)是合理6 風險預(yù)估和應(yīng)對下表列出了在項目測試工作中存在的各種風險的假定，需要考慮項目測試過程中可能發(fā)生的具體事務(wù)，分別分析并加以應(yīng)對，然后體現(xiàn)到測試計劃中。風險責處理優(yōu)風險類型風險內(nèi)容應(yīng)對措施備注任方先級時間計劃人員風險資源協(xié)調(diào)插入事務(wù)任務(wù)超預(yù)期注：各個風險類型解釋如下：時間計劃：關(guān)鍵MileStone無法匹配的延期風險；人員風險： 測試人員和需配合方的人員的變動導(dǎo)致的工作任務(wù)無法按計劃完成或者完成質(zhì)量無法保證的風險，包括新人風險、人員變化、投入不足、投入質(zhì)量不高等；資源協(xié)調(diào)：包括所需資源不能如期到位，或者資源質(zhì)量低于預(yù)期等風險。比如測試工具開發(fā)的風險、各個階段交付物的質(zhì)量風險等；插入事務(wù)：包括臨時插入高