1、XX市XX軟件開發項目內部測試方案修訂人簽字：審核人簽字：批準人簽字：日期：日期：日期： 修訂歷史紀錄 變更類型：增加/修訂/刪除版本號日期變更類型修改人摘要備注V1.0目錄1引言41.1系統概述41.2文檔概述41.3范圍41.4目標讀者及閱讀建議51.5參考文檔52軟件測試環境52.1測試環境52.2參與組織62.3人員角色62.4測試工具63計劃73.1總體計劃7測試級7測試準備7測試類別73.2計劃執行的測試9測試范圍9測試重點10測試入口準則10測試通過標準103.3測試用例114測試實施114.1輪次執行114.2測試計劃114.3缺陷管理125測試評價126風險預估和應對137測

2、試輸出物141 引言1.1 系統概述隨著廣大XX市民百姓對住房需求的增加，住房市場呈現高速發展趨勢，管理中心各項業務得到了快速發展。業務的發展與信息系統的發展是相輔相成的，住房資金業務的快速發展、信息技術日新月異的發展和廣大市民百姓對政府服務水平預期的不斷提高，對管理中心信息化系統的建設提出了更高要求。為實現管理中心未來五年業務發展目標，通過業務需求驅動和先進技術需求驅動重構管理中心核心業務系統。本次系統重建的業務需求主要包括創新面向個人辦理業務的業務模式、豐富服務渠道、優化業務流程、提高資金管理水平、有效管控風險、提高辦公效率，促進信息共享等方面；技術需求包括構建全新技術架構重構核心系統、運

3、用云計算和大數據技術有效處理數據支持決策分析、持續提升安全體系建設、持續提升IT 服務保障體系建設、升級基礎設施條件等。1.2 文檔概述本文檔描述了XX市XX管理中心系統內部測試階段工作的相關情況，內容包括進行測試的環境、測試工作的標識以及測試工作的時間安排等，在實際工作中指導測試人員完成測試工作。主要包括以下幾點目的： 盡可能發現被測試軟件中的錯誤，以便開發人員進行修正，提高軟件的可靠性； 確定測試策略，并對測試策略加以說明。另，本文檔不涉及性能測試，具體內容見性能測試方案； 確定所需資源，對測試工作量進行估計； 客觀反映產品中存在的缺陷，為提高產品質量服務； 完成本階段的測試工作，為產品交

4、付做準備。1.3 范圍設計針對XX市XX中心業務系統的系統測試功能測試方案。通過上述方案用以驗證： 產品功能是否滿足需求規定并能夠正常運行功能測試； 用戶界面是否與需求保持一致，保證用戶界面的友好性、易操作性用戶界面測試； 產品性能是否滿足需求規定并能夠正常運行性能測試；1.4 目標讀者及閱讀建議目標讀者閱讀建議項目經理及評審人員全文檔仔細閱讀測試負責人及測試工程師全文檔仔細閱讀開發工程師仔細閱讀“章節2”-“章節4”，其他部分了解性閱讀1.5 參考文檔文檔參考內容作者或來源使用備注GBT-8567-2006計算機軟件文檔編制規范：軟件測試計劃(STP)文檔格式確定文檔格式及涉及內容需求規格說

5、明書項目組確定測試需求及策略大/中日程計劃測試計劃項目組確定測試計劃及人員安排2 軟件測試環境2.1 測試環境硬件用途客戶端硬件配置信息數量軟件分類軟件名稱版本操作系統瀏覽器數據庫客戶端服務器硬件配置信息數量軟件分類軟件名稱版本操作系統 WEB中間件數據庫2.2 參與組織參與方人員提供資源參與工作參與階段參與時間備注··········2.3 人員角色下表列出了在項目內部測試工作過程中的人員配備：角色人員職責項目經理· 提供技術指導并獲取適當資源· 負責整個項目中的協調工作測

6、試負責人· 編寫測試方案、計劃· 項目測試的日常管理工作· 監控測試工作，規避風險· 編寫系統測試報告等測試工程師· 編制和維護測試用例· 執行測試并記錄結果· 缺陷跟蹤開發工程師· 對程序缺陷進行修改· 程序新版本發布· 必要時參加進行功能測試2.4 測試工具工具類型工具名稱版本備注用例管理工具缺陷管理工具數據庫項目管理3 計劃3.1 總體計劃該系統測試的策略有功能測試、用戶界面測試和性能測試，功能測試要覆蓋系統中的每個功能。在功能測試時既要輸入正確的數據，測試功能是否滿足，也要對每個功能中的

7、每個數據輸入域故意輸入錯誤的數據，測試系統的健壯性。用戶界面測試核實各個窗口風格（包括顏色、字體、提示信息、圖標、Title等）都與需求保持一致，或符合可接受標準，保證用戶界面的友好性、易操作性，而且符合用戶操作習慣。性能測試往往針對軟件的一部分功能，進行專項測試。執行完一組工作后，及時檢查是否已達到預定目標，是否已執行完該過程所有的步驟等，如實際情況與計劃出入較大，應及時調整計劃。考慮到各種因素和條件的限制，采用黑盒測試方案，即根據軟件所需要的輸入數據的格式以及應該完成的功能，設計一些合法的測試用例和不合法的測試用例，特別是根據邊界條件設計一些邊界測試用例，以檢查系統是否能正確地完成預期功能

8、，得到希望的輸出；或者是對不合法的輸入和操作能夠正確地識別和防御。3.1.1 測試級執行的測試級別為系統級。3.1.2 測試準備 測試方案編寫完成并郵件告知項目組成員； 測試組根據需求規格說明書完成測試內容確認和重點交易列表，需項目經理或開發人員確認； 項目經理安排相關人員完成內部測試環境的配置； 測試開始前將與開發人員配合將“測試相關信息.xls”文檔整理完成，包括測試環境配置、Bugfree用戶信息，柜員信息等；3.1.3 測試類別3.1.3.1 功能測試功能測試側重于可以被直接追蹤利用例或業務功能和業務規則的所有測試需求。這些測試的目標在于核實能否正確的接受、處理和檢索數據以及業務規則是

9、否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面（GUI）與應用程序交互并分析輸出結果來驗證應用程序及其內部進程。以下列出測試方法概要：測試范圍：驗證數據精確度、數據類型、業務功能等相關方面的正確性測試目標：核實所有功能均已正常實現，且與需求一致。方法：利用有效的和無效的數據來執行各個用例或功能，以核實以下內容：· 在使用有效的數據時得到預期結果；· 在使用無效的數據時顯示相應的錯誤信息或警告；· 各業務規則都得到了正確的應用；依據：測試用例完成標準：· 所計劃的測試已全部執行· 所發現的缺陷已全部解決（無1,2級遺留缺陷）需考慮的特

10、殊事項3.1.3.2 用戶界面（UI）測試用戶界面（UI）測試用于核實用戶與軟件之間的交互。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，并符合公司或行業的標準。測試范圍：1、導航、鏈接、Cookie、頁面結構（包括菜單、背景、顏色）、字體、按鈕名稱、Title、提示信息的一致性等2、友好性、可操作性、易用性測試目標：核實各個窗口風格（包括顏色、字體、提示信息、圖標、Title等）都與需求保持一致，或符合可接受標準，能夠保證用戶界面的友好性、易操作性，而且符合用戶操作習慣。方法：WEB非功能性通用測試方法

11、，手工測試完成標準：UI符合可接受標準，能夠保證用戶界面的友好性、易操作性，而且符合用戶操作習慣需考慮的特殊事項重點測試網上業務平臺、政務網站等對外門戶的用戶界面。3.1.3.3 性能測試性能測試對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能測試的目標是核實性能需求是否都已滿足。實施和執行性能測試的目的是將測試對象的性能行為當作條件（例如工作量或硬件配置）的一種函數來進行測試和微調。測試范圍：多用戶長時間在線操作時性能方面的測試測試目標：核實系統在大流量的數據與多用戶操作時軟件性能的穩定性， 不造成系統崩潰或相關的異常現象。方法：使用loadrunner工具進行測試完成標準

12、：系統滿足用戶需求中所要求的性能要求需考慮的特殊事項3.2 計劃執行的測試3.2.1 測試范圍序號分類核心用例來源用例編寫人員測試策略備注1功能測試、用戶界面測試、性能測試234567891011121314151617181920212223242526272829303132注：具體各核心內容下的交易見“交易測試情況一覽表”，此處不逐一列出。3.2.2 測試重點測試重點主要從以下幾個方面考慮，針對測試重點，在用例的編寫與評審、人員安排、測試輪次、Bug解決要求等方面都應高于其他部分。 需求中，優先級高的重點功能或用戶的常用功能； 開發過程中，重點關注的模塊、功能及特性（此項通過交易的代碼修

13、改量等內容確定，由項目經理提供）； 相關領導的關注點和意見； 開發人員的能力和水平差異； 以往版本或其他項目中的常見問題；注：此項內容由項目經理配合進行確認，具體交易列表及重點測試交易，見“交易測試情況一覽表”，此處不逐一列出。3.2.3 測試入口準則 在提交測試組進行系統測試前，開發工程師需要經過自測試以及開發組組內互測； 測試組接收測試，且通過冒煙測試后，方可進行系統測試。3.2.4 測試通過標準 系統無業務邏輯錯誤和二級缺陷，經確定的所有缺陷都已得到商定的解決結果； 設計的測試用例全部執行完成，由于其他因素導致未能執行的用例有相應記錄； 2.1節中規定的所有功能點，測試覆蓋率=100%，

14、有效Bug的關閉率>=90%； 滿足聯合測試和第三方測評要求。3.3 測試用例1 測試用例分類l 測試用例與測試類型對應：功能測試用例、用戶界面測試用例及性能測試用例l 重點用例通過用例中的用例級別進行標記：A- 關鍵業務正常流測試B- 功能點詳細測試C- 交互測試：主要測試界面、易用性等內容D- 異常測試2 測試用例評審l 組內評審：測試組內部采用交叉評審方式，對已做成測試用例進行評審；l 組外評審：開發組的相關人員（由項目經理或部門經理指定），對測試一覽表中重點交易的用例進行評審；4 測試實施4.1 輪次執行輪次內容備注第一輪1、第二輪1、第三輪1.其他注意事項：1 測試工程師根據測

15、試用例進行測試，并將測試中發現的Bug，記錄到Bugfree中；2 開發工程師對Bug進行修改，并說明Bug產生的原因及產生階段；3 如果對需要修改的Bug意見不統一，則由項目經理確認修改意見；4 第二輪系統測試開始，測試工程師首先對第一輪測試中遺留的問題進行回歸驗證，即驗證上一輪發現的Bug是否已經全部得到解決。回歸測試完成后，測試工程師再根據測試用例，開展新的系統測試工作；5 第三輪系測試，結合核心系統進行測試，同時加強對業務系統中重點交易的測試。4.2 測試計劃項目里程碑任務開始時間結束時間輸出物執行人員備注制定測試方案編寫測試方案內部測試方案設計測試測試用例編寫測試用例測試用例評審測試

16、用例評審記錄表執行測試內部測試第一輪缺陷記錄、輪次測試報告內部測試第二輪缺陷記錄、輪次測試報告內部測試第三輪缺陷記錄、輪次測試報告評估測試測試總結內部測試報告注：輪次測試的具體內容會根據各子系統開發進度做適當調整。4.3 缺陷管理參見。5 測試評價系統測試完畢，提供以下度量指標結果用以評估項目質量并輸出測試報告：度量指標名稱定義/計算公式指標目的數據主要來源測試功能點總數（個）測試功能點總數各級測試功能點數之和；統計測試規模“附件1：交易測試情況一覽表.xls”功能點測試生產率（個/人月）功能點測試生產率 = 測試功能點總數 /測試組實際總工作量；衡量測試組的生產率系統功能測試輪次（輪）指測試

17、組實際進行的系統功能測試輪數；預估類似項目的平均測試輪數Bugfree測試覆蓋率（100%）功能點測試覆蓋率 =測試功能點總數 / 功能點總數； 衡量測試的覆蓋程度“附件1：交易測試情況一覽表.xls”功能點測試通過率（100%）完全通過功能點數/測試功能點總數由此指標，可衡量代碼開發的質量。Bug關閉率（100%）Bug總關閉率 = 已關閉Bug總數 / 有效Bug總數 * 100%1、衡量開發人員對Bug的解決程度；2、判斷產品交付時的遺留Bug數BugFree測試密度（個/功能）測試密度=實際測試用例數/功能點總數衡量測試用例顆粒度是否適當測試用例Bug密度1（個/功能）Bug密度1=實

18、際Bug數/功能點總數衡量bug產出是否在合理范圍內BugFreeBug密度2（個/功能）Bug密度2=實際Bug數/代碼變動數衡量代碼變動產生的bug數是合理BugFree6 風險預估和應對下表列出了在項目測試工作中存在的各種風險的假定，需要考慮項目測試過程中可能發生的具體事務，分別分析并加以應對，然后體現到測試計劃中。風險類型風險責任方風險內容處理優先級應對措施備注時間計劃人員風險資源協調插入事務任務超預期注：各個風險類型解釋如下：Ø 時間計劃：關鍵MileStone無法匹配的延期風險；Ø 人員風險：測試人員和需配合方的人員的變動導致的工作任務無法按計劃完成或者完成質量無法保證的風險，包括新人風險、人員變化、投入不足、投入質量不高等；Ø 資源協調：包括所需資源不能如期到位，或者資源質量低于預期等風險。比如測試工具開發的風險、各個階段交付物的質量風險等；Ø 插入事務：包括臨時插