整體測試方案

1、文檔編號：ie custo昭體測試方案v1.0海關信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目整體測試方案令中科軟科技股份有限公司sinosoft coxtd二零一六年九月關于本文檔項目名稱海關信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目主 題整體測試方案標 識iecustom體測試方案v1.0說 明系統(tǒng)測試前，需要制定方案，以便對測試工作進行指導。適用對象甲方項目負責人、有美人員中科軟項目工程領導小組、項目經(jīng)理、項目組全體成員以及相關人員修訂歷史版本早節(jié)日期作者說明v1.0c2016年9月5日羅晨說明：類型一創(chuàng)建（c）、修改（u）、刪除（d）、增加（a）;評審記錄角色簽名日期說明第1章概述1.1.1 編寫目的1

2、.1.2 讀者對象1.1.3 項目背景1.第2章測試方案概述2.2.1 測試目標2.2.2 測試范圍2.2.3 參考資料2.第3章測試環(huán)境3.第4章測試方案5.4.1 測試依據(jù)5.4.2 功能測試5.4.3 性能測試5.4.4 內部測試5.4.4.1 測試策略5.4.4.2 測試管理7.第5章用戶測試1.35.1 測試管理1.35.1.1 組織機構1.35.1.2 角色職責1.35.1.3 測試安排1.45.1.4 測試步驟1.45.1.5 測試管理工具145.1.6 用戶問題處理、反饋流程 1.45.1.7 測試通過準則 155.1.8 測試異常中止準則 1.55.1.9 風險分析及預防16

3、精選范本第1章概述1.1 編寫目的編寫本測試方案的目的是為客戶、項目經(jīng)理、開發(fā)人員、測試工程師、維 護人員等項目相關人員提供海關信息數(shù)據(jù)采集與數(shù)據(jù)應用與平臺測試項目整體 系統(tǒng)測試指導。1.2 讀者對象本測試方案可能的合法讀者對象為客戶、項目經(jīng)理、開發(fā)人員、測試人 員、維護人員。1.3 項目背景隨著經(jīng)濟環(huán)境、執(zhí)法環(huán)境的變化，海關大監(jiān)管、關警融合、分類通關等各 項業(yè)務的不斷深入，加快通關速度和大通關對緝私工作提出了更高的要求，情 報工作在海關各工作特別是緝私工作中的地位和作用日益凸顯，所擔負的職責 更加繁重，任務更加艱巨，海關人力資源與監(jiān)管要求直接的矛盾突出。為了提 開海關大監(jiān)管的綜合執(zhí)法能力及海

4、關緝私辦案能力，必須借助現(xiàn)代化情報工作 機制及計算機情報信息系統(tǒng)支持，完善情報機制，體現(xiàn)情報信息服務，增強對 全國海關情報業(yè)務的掌控能力。精選范本第3章測試環(huán)境2.1 測試目標(1)系統(tǒng)界面操作無明顯異常，符合業(yè)務需求規(guī)定；(2)根據(jù)需求規(guī)格說明書，總體設計、詳細設計文檔實現(xiàn)整體功能測試；(3)系統(tǒng)主要流程，無異常，符合需求；(4)根據(jù)需求進行性能測試、穩(wěn)定性、健全性及安全測試；(5)所有測試用例100%mt;(6)所有缺陷處于 closed、rejected、pending狀態(tài)；(7)缺陷修改要求：high級缺陷修復率應達到100% medium級缺陷修復 率應達到95%z上；low級缺陷修

5、復率應達到60%z上。2.2 測試范圍本次測試主要針對海關信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺項目的軟件需求規(guī)格 說明書中涉及的要求進行完整性測試，包括界面、功能和流程的全面測試，以 及性能測試、穩(wěn)定性、健全性及安全測試等。本次測試采用黑盒測試的方法為 主，輔助進行代碼審查。2.3 參考資料海關信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目需求規(guī)格說明書海關信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目合同公司軟件測試規(guī)范。測試環(huán)境分類測試環(huán)境名稱硬件環(huán)境軟件環(huán)境客戶端pc機1(172.17.9.106)pentium(r)d cpu3.00ghz2.99ghz, 1.99gb內存windowsxpprofessional s

6、p2pc機2(172.17.9.123)pentium(r)d cpu3.00ghz2.99ghz, 1.99gb內存windowsxpprofessional sp2服務器端應用服務器待定待定數(shù)據(jù)庫服務器企業(yè)端(172.16.1.108):ibm xderies_366 intel(r) xeon(7m) mp cup3.16ghz3.17ghz3.25gb 內存中心端(172.17.16.22):systemmodel:ibm,7040-671number of processors:16processor clock speed:1500 mhzcpu type: 64-bitmemor

7、y size: 16384 mbhard disk: 109200mb企業(yè)端：windows2003serverenterpriseedition sp2中心端：aix version 5.3mq服務器(企業(yè)端：172.17.16.14 ;中心端172.17.16.13)systemmodel:ibm,7026-6m1number of processors: 8processor clock speed: 752 mhzcpu type: 64-bitmemory size: 8192 mbhard disk:36400mbaix version 5.3mq6.0力口 m機精選范本其它(17

8、2.17.8.250)分中心（郵箱客戶 端）同pc機1和pc機2同pc機1和pc機2瀏覽器ie6表4.1測試環(huán)境精選范本第4章測試方案4.1 測試依據(jù)在本項目實施過程中編寫的需求、設計、計劃、測試方案、測試報告等產 出物，需要通過客戶、項目經(jīng)理、 qa測試經(jīng)理等該項目相關人員審核。4.2 功能測試測試人員根據(jù)通過審核的需求、設計、測試方案等文檔編寫測試用例，要 求測試用例的功能覆蓋率要達到100%測試過程中測試人員嚴格執(zhí)行測試用例 并記錄測試結果，驗證系統(tǒng)的功能實現(xiàn)是否達到需求、設計要求，是否滿足客 戶目標。測試用例執(zhí)行率達到100%測試過程中所有問題提交 bugfree。4.3 性能測試應用

9、系統(tǒng)經(jīng)過系統(tǒng)測試后形成相對穩(wěn)定版本，測試組在穩(wěn)定版本的基礎上 選擇性能測試點進行性能測試，測試組負責編寫性能測試方案，對系統(tǒng)進行壓 力測試、并發(fā)測試、穩(wěn)定性測試。測試過程中使用性能測試工具loadrunner。執(zhí)行性能測試時，同時填寫性能測試記錄表、性能測試調優(yōu)過程記錄表。4.4 內部測試4.4.1 測試策略測試過程按三個步驟進行，即單元測試、集成測試、系統(tǒng)測試，根據(jù)不同 階段測試的測重點不同。4.4.1.1 單元測試首先按照系統(tǒng)、子系統(tǒng)和模塊進行劃分，但最終的單元必須是功能模塊，或面向對象過程中的若干個類。單元測試是對功能模塊進行正確性檢驗的測試工 作，也是后續(xù)測試的基礎。目的是在于發(fā)現(xiàn)各模

10、塊內部可能存在的各種差錯， 因此需要從程序的內部結構出發(fā)設計測試用例，著重考慮以下五個方面：精選范本1）模塊接口：對所測模塊的數(shù)據(jù)流進行測試。2）局部數(shù)據(jù)結構：檢查不正確或不一致的數(shù)據(jù)類型說明、使用尚未賦值或 尚未初始化的變量、錯誤的初始值或缺省值。3）路徑：雖然不可能做到窮舉測試，但要設計測試用例查找由于不正確的計算（包括算法錯、表達式的符號表示不正確、運算精度不夠等）、不正確的比較或不正常的控制流（包括不同數(shù)據(jù)類型量的相互比較、不適當?shù)匦薷牧搜h(huán)變 量、錯誤的或不可能的循環(huán)終止條件等）而導致的錯誤。4）錯誤處理：檢查模塊有沒有對預見錯誤的條件設計比較完善的錯誤處理 功能，保證其邏輯上的正確

11、性。5）邊界：注意設計數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值 的用例。4.4.1.2 集成測試集成測試也叫組裝測試或聯(lián)合測試（接口聯(lián)調測試）。通常，在單元測試的 基礎上需要將所有的模塊按照設計要求組裝成系統(tǒng)，這時需要考慮的問題：1）在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失。2） 一個模塊的功能是否會對另一個模塊的功能產生不利的影響。3）各個子功能組合起來，能否達到預期要求的父功能。4）全局數(shù)據(jù)結構是否有問題。5）單元模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。4.4.1.3 系統(tǒng)測試系統(tǒng)測試目的是在于驗證軟件的功能和性能及其他特性是否與用戶的要求 一致，主

12、要是下列類型的測試：1）用戶界面測試：測試用戶界面是否具有導航性、美觀性、行業(yè)或公司的 規(guī)范性、是否滿足設計中要求的執(zhí)行功能。2）功能測試：驗證功能實現(xiàn)是否滿足客戶需求3）性能測試：測試相應時間、事務處理效率和其他時間敏感的問題。4）可靠性測試：測試系統(tǒng)對數(shù)據(jù)有效性檢查能力和抵御誤操作的能力。5）容量測試：測試大量數(shù)據(jù)對系統(tǒng)的影響。6）容錯性測試：測試軟件系統(tǒng)克服軟件、硬件故障的能力。7）數(shù)據(jù)安全測試：測試系統(tǒng)在出現(xiàn)異常情況下，是否可以保護數(shù)據(jù)不丟 失；測試系統(tǒng)能否可以進行數(shù)據(jù)庫的備份和恢復。8）易用性測試：重點關注系統(tǒng)的易理解性、易操作性、易學性。9）安裝部署測試：確保軟件系統(tǒng)在所有可能情況

13、下的安裝效果和一旦安裝 部署之后必須保證正確運行的質量。4.4.2 測試管理4.4.2.1 組織機構項目.責人 ）項目經(jīng)理 k測試經(jīng)理*1v . 開發(fā)人員 : 測試人員4.4.2.2角色職責角色職責測試經(jīng)理- 負責與項目經(jīng)理溝通，進行測試的整體策劃、制定測試計戈|j、組織測試實施、分析測試結果，控制測試進度和bug清除率。測試員- 負責檢查測試環(huán)境、測試版本、編寫并執(zhí)行測試大綱、測試 用例、報告缺陷、驗證修改結果，進行測試數(shù)據(jù)統(tǒng)計，提交 測試報告。項目經(jīng)理- 負責與測試經(jīng)理溝通，參與測試的整體策劃、提供測試依據(jù) 等相關材料；介紹系統(tǒng)功能，負責測試組與開發(fā)組間協(xié)調。程序員- 按時部署測試環(huán)境、數(shù)

14、據(jù)，提交可測試的軟件版本，協(xié)助測試員編寫用例，及時修改缺陷、填寫修改記錄。qa工程師- 對測試過程、測試結果進行規(guī)范性檢查項目負責人- 評價測試結果4.4.2.3 測試安排總體測試時間：2016年9月1日一2016年11月13日。第一階段測試：2016年9月1日2016年10月9日，開發(fā)人員編寫 代碼，完成系統(tǒng)功能開發(fā)，并對完成的功能模塊進行單元測試、集成測試；第二階段測試：2016年10月10日一2016年10月25日，測試組對項 目的軟件系統(tǒng)進行功能測試，由開發(fā)人員完成所有問題的修改。第三階段測試：2016年10月26日一2016年11月4日，測試組進行 性能測試并完成問題修改。4.4.2

15、.4 測試步驟具體測試步驟：1、對整體流程進行測試，保證系統(tǒng)整體業(yè)務流程可以走通。2、對整體業(yè)務流程中的分支流程進行測試，保證系統(tǒng)業(yè)務分支流程可以走 通。3、各業(yè)務系統(tǒng)流程測試4、各子系統(tǒng)功能點測試。5、覆蓋性測試。6、系統(tǒng)性能測試?；貧w測試貫穿每個測試階段。系統(tǒng)整體流程如下說明：1、基礎數(shù)據(jù)由數(shù)據(jù)采集系統(tǒng)從進出口相關執(zhí)法部門采集，包括涉毒信息、 旅客信息、航班信息等，形成基礎數(shù)據(jù)。2、系統(tǒng)進行數(shù)據(jù)收集存儲、數(shù)據(jù)加工處理、主題數(shù)據(jù)建立等處理，進行主 數(shù)據(jù)轉換加載與業(yè)務數(shù)據(jù)轉換加載，產生中間過程數(shù)據(jù)，具有時間戳和 更新標記。3、對集成數(shù)據(jù)進行分析，滿足實時查詢與統(tǒng)計需要，形成統(tǒng)計報表。4、動態(tài)數(shù)

16、據(jù)倉庫存放風險數(shù)據(jù)、預警數(shù)據(jù)。5、對預警數(shù)據(jù)進行評分、排名并設置消息推送。4.4.2.5測試管理工具工具名稱：bugfree3.0來源：官方網(wǎng)站功能：測試用例、缺陷管理，自動統(tǒng)計測試結果4.4.2.6缺陷處理流程bugfree3.0規(guī)定缺陷有三種狀態(tài)（見表-1）、七種解決方案（見表-2）表-1缺陷有三種狀態(tài)缺陷狀態(tài)說明active（激活）bug的初始狀態(tài)。任何新建的bug狀態(tài)都是active。可以通過編輯功能修改bug的內容，并指派給合適的人員解決。resolved（解決）解決中或解決完畢狀態(tài)。closed（關閉）已修復bug、或解決方案（見表-2）被驗證無誤之后可以關閉。該bug處理完畢。如

17、果沒后真止解決或者重新復現(xiàn)，可以重新激活，bug狀態(tài)重新變?yōu)閍ctive。按照bugfree3.0.4缺陷處理流程，測試者、bug修改者都可以使用bugfree 報告bug,測試者跟蹤bug狀態(tài)，驗證處理結果，直至關閉。具體過程：1、報告者提交一個bug,缺陷生命周期開始，bugfree自動將狀態(tài)置為active （激活狀態(tài)），報告者將bug指派給修改bug的程序員；2、程序員接受bug,點擊解決按鈕，進行bug的修改，并指派bug修改后的 驗證人（默認該bug的報告者），bug變?yōu)閞esolved （解決狀態(tài)），程序員 選才b bug解決方案：表-2七種解決方案bug解決方案方案說明處理規(guī)則

18、fixed （后效bug）確認是bug,修改完畢、提交驗證。測試員驗證，修改正確、可以關閉；否 則，重新激活。external （后效bug）外部因素（比如瀏覽器、 操作系統(tǒng)、其他第二方軟 件）造成的問題。項目經(jīng)理確認、必要時與客戶和相關方協(xié)商解決，測試員驗證后關閉；否則，重新激活。postponed （有效 bug）目前不必修改的問題（發(fā) 現(xiàn)的太晚了，下一個版本 討論是否解決）。項目經(jīng)理確認、必要時與客戶協(xié)商，如果同意卜一個版本討論或修改，保持解決”狀態(tài)和當前解決方案/、艾；否則，重新激活，選擇fixed/exterral方某進行修改；wori tfix （有效 bug）是個問題，但是不影響

19、系 統(tǒng)使用。項目經(jīng)理確認，確實/、值得修改、可讓 測試員關閉；否則，重新激活，選擇適當?shù)姆桨高M行修改；bydesign （無效 bug）就是這么設計的，不是bug。項目經(jīng)理確認，必要時與客戶協(xié)商，如 果的確不是bug,需求和設計就是這樣、 或受限于開發(fā)環(huán)境和工具，可讓測試員 關閉；否則，重新激活，選擇適當?shù)姆桨?進行修改；duplicate （無效 bug）重復的bug。測試員確認，確實是重報、測試員可以 關閉；否則，重新激活，選擇適當?shù)姆?案進行修改；notrepro （無效 bug）無法復現(xiàn)的問題。項目經(jīng)理確認，確實無法復現(xiàn)，指定專人跟蹤，如果一段時間內 bug小冉重 現(xiàn)，可讓測試員關閉；

20、否則，重新激 活，選擇適當?shù)姆桨高M行修改。*需項目經(jīng)理確認的問題也可委托開發(fā)組長、技術骨干審查，關鍵問題由開發(fā)組 長報項目經(jīng)理確認。3、bug報告者和修改者參考程序員填寫的 bug解決方案，按照上表定義的處理 規(guī)則，需要時請項目經(jīng)理確認，將可以關閉的bug置為closed（關閉狀態(tài)）；否則，重新激活、置為 active （激活狀態(tài)）。4.4.2.7 測試通過準則充分性：計劃測試的功能至少全部測試了一遍;至少對缺陷高發(fā)點進行了回歸測試；測試用例覆蓋率100%測試用例執(zhí)行率100%bug消除率：有效bug消除率95犯上；其中:1-2級bug清除率100%3-4級bug消除率95犯上；遺留bug必須

21、得到客戶認可4.4.2.8 測試異常中止準則1、系統(tǒng)的一二級錯誤太多、不能繼續(xù)測試；2、發(fā)現(xiàn)明顯設計錯誤、導致測試對象完全錯誤;3、發(fā)現(xiàn)測試對象與用戶需求完全不符合；4、測試環(huán)境沒有保障；5、測試人員或缺陷修改人員缺席。4.4.2.9 風險分析及預防嚴格遵循軟件測試規(guī)范，做到：組織規(guī)范、流程規(guī)范、文檔規(guī)范依據(jù)評審通過的需求規(guī)格說明書、設計書編寫測試用例；需求、設計變更時要有客戶變更記錄；要求測試大綱和用例：測試大綱和用例覆蓋軟件所有的功能要點和主要業(yè)務流程；每一條用例應給出測試數(shù)據(jù)（需要輸入數(shù)據(jù)時）、執(zhí)行步驟、方法、預 期結果。測試大綱和用例應經(jīng)過項目經(jīng)理審查、客戶負責人評審。4.4.2.10

22、 提交成果物整體測試方案測試用例bug-覽表測試報告第5章用戶測試用戶測試過程中重點關注需求文檔中描述的功能是否都已經(jīng)實現(xiàn)，主要對 系統(tǒng)進行易用性測試、可靠性測試、容錯性測試。具測試依據(jù)及測試環(huán)境同測 試組相同。5.1 測試管理5.1.1 組織機構項目組領導甲方頊目負責人5.1.2 角色職責角色職責用戶測試代表負責檢查測試環(huán)境、測試版本、報告缺陷、驗證修改結果，進 行測試數(shù)據(jù)統(tǒng)計，提交用戶測試報告。項目經(jīng)理負責與甲方測試人員溝通， 參與測試的整體策劃、 提供測試依 據(jù)等相關材料；介紹系統(tǒng)功能，負責甲方測試人員與開發(fā)組間 協(xié)調。開發(fā)組按時部署測試環(huán)境、 數(shù)據(jù)，提交可測試的軟件版本， 編寫測試用例、測試大綱，及時修改缺陷、填寫修改記錄。qa工程師對測試過程、測試結果進行規(guī)范性檢查甲方項目負責人評價測試結果5.1.3 測試安排測試時間：2016年11月5日2016年11月20日，業(yè)主進行測試并完成 問題修改。5.1.4 測試步驟第一步：測試開始前，由項目經(jīng)理介紹已實現(xiàn)的功能、業(yè)務流程，保證用戶 方測試員深入理解系統(tǒng)功能和業(yè)務流程