整體測試方案

1、文檔編號：IECUSTOM-整體測試方案V1.0海關信息數據采集與數據應用平臺測試項目 整體測試方案二零一六年九月關于本文檔項目名稱海關信息數據采集與數據應用平臺測試項目主 題整體測試方案標 識IECUSTOM-整體測試方案V1.0說 明系統(tǒng)測試前，需要制定方案，以便對測試工作進行指導。適用對象甲方項目負責人、有關人員中科軟項目工程領導小組、項目經理、項目組全體成員以及相關人員修訂歷史版本章節(jié)類型日期作者說明V1.0C2016年9月5日羅晨說明：類型創(chuàng)建（C）、修改（U）、刪除（D）、增加（A）；評審記錄角色簽名日期說明目 錄第 1 章概述11.1編寫目的11.2讀者對象11.3項目背景1第

2、2 章測試方案概述22.1測試目標22.2測試范圍22.3參考資料2第 3 章測試環(huán)境3第 4 章測試方案54.1測試依據54.2功能測試54.3性能測試54.4內部測試5測試策略5測試管理7第 5 章用戶測試135.1測試管理13組織機構13角色職責13測試安排14測試步驟14測試管理工具14用戶問題處理、反饋流程14測試通過準則15測試異常中止準則15風險分析及預防16第 1 章 概述1.1 編寫目的編寫本測試方案的目的是為客戶、項目經理、開發(fā)人員、測試工程師、維護人員等項目相關人員提供海關信息數據采集與數據應用與平臺測試項目整體系統(tǒng)測試指導。1.2 讀者對象本測試方案可能的合法讀者對象為

3、客戶、項目經理、開發(fā)人員、測試人員、維護人員。1.3 項目背景隨著經濟環(huán)境、執(zhí)法環(huán)境的變化，海關大監(jiān)管、關警融合、分類通關等各項業(yè)務的不斷深入，加快通關速度和大通關對緝私工作提出了更高的要求，情報工作在海關各工作特別是緝私工作中的地位和作用日益凸顯，所擔負的職責更加繁重，任務更加艱巨，海關人力資源與監(jiān)管要求直接的矛盾突出。為了提升海關大監(jiān)管的綜合執(zhí)法能力及海關緝私辦案能力，必須借助現(xiàn)代化情報工作機制及計算機情報信息系統(tǒng)支持，完善情報機制，體現(xiàn)情報信息服務，增強對全國海關情報業(yè)務的掌控能力。第 2 章 測試方案概述2.1 測試目標（1）系統(tǒng)界面操作無明顯異常，符合業(yè)務需求規(guī)定；（2）根據需求規(guī)格

4、說明書，總體設計、詳細設計文檔實現(xiàn)整體功能測試；（3）系統(tǒng)主要流程，無異常，符合需求；（4）根據需求進行性能測試、穩(wěn)定性、健全性及安全測試； （5）所有測試用例100%執(zhí)行；（6）所有缺陷處于Closed、Rejected、Pending狀態(tài)；（7）缺陷修改要求：High級缺陷修復率應達到100%；Medium級缺陷修復率應達到95%以上；Low級缺陷修復率應達到60%以上。2.2 測試范圍本次測試主要針對海關信息數據采集與數據應用平臺項目的軟件需求規(guī)格說明書中涉及的要求進行完整性測試，包括界面、功能和流程的全面測試，以及性能測試、穩(wěn)定性、健全性及安全測試等。本次測試采用黑盒測試的方法為主，輔

5、助進行代碼審查。2.3 參考資料海關信息數據采集與數據應用平臺測試項目需求規(guī)格說明書海關信息數據采集與數據應用平臺測試項目合同公司軟件測試規(guī)范。第 3 章 測試環(huán)境測試環(huán)境分類測試環(huán)境名稱硬件環(huán)境軟件環(huán)境客戶端PC機1(172.17.9.106)Pentium(R) D CPU 3.00GHZ2.99GHZ,1.99GB內存Windows XP Professional SP2PC機2(172.17.9.123)Pentium(R) D CPU 3.00GHZ2.99GHZ,1.99GB內存Windows XP Professional SP2服務器端應用服務器待定待定數據庫服務器企業(yè)端(17

6、2.16.1.108)：IBM XDERIES_366 Intel（R）Xeon(7M) MP CUP 3.16GHz 3.17GHz 3.25GB內存中心端(172.17.16.22)：System Model: IBM,7040-671Number Of Processors: 16Processor Clock Speed: 1500 MHzCPU Type: 64-bitMemory Size: 16384 MBHard Disk: 109200MB企業(yè)端：Windows 2003 Server Enterprise Edition SP2中心端：AIX Version 5.3MQ服務

7、器(企業(yè)端：172.17.16.14；中心端172.17.16.13)System Model: IBM,7026-6M1Number Of Processors: 8Processor Clock Speed: 752 MHzCPU Type: 64-bitMemory Size: 8192 MBHard Disk:36400MBAIX Version 5.3MQ6.0其 它加M機(172.17.8.250)分中心（郵箱客戶端）同PC機1和PC機2同PC機1和PC機2瀏覽器IE6表4.1 測試環(huán)境第 4 章 測試方案4.1 測試依據在本項目實施過程中編寫的需求、設計、計劃、測試方案、測試報告

8、等產出物，需要通過客戶、項目經理、QA、測試經理等該項目相關人員審核。4.2 功能測試測試人員根據通過審核的需求、設計、測試方案等文檔編寫測試用例，要求測試用例的功能覆蓋率要達到100%，測試過程中測試人員嚴格執(zhí)行測試用例并記錄測試結果，驗證系統(tǒng)的功能實現(xiàn)是否達到需求、設計要求，是否滿足客戶目標。測試用例執(zhí)行率達到100%。測試過程中所有問題提交BugFree。4.3 性能測試應用系統(tǒng)經過系統(tǒng)測試后形成相對穩(wěn)定版本，測試組在穩(wěn)定版本的基礎上選擇性能測試點進行性能測試，測試組負責編寫性能測試方案，對系統(tǒng)進行壓力測試、并發(fā)測試、穩(wěn)定性測試。測試過程中使用性能測試工具LoadRunner。執(zhí)行性能測

9、試時，同時填寫性能測試記錄表、性能測試調優(yōu)過程記錄表。4.4 內部測試4.4.1 測試策略測試過程按三個步驟進行，即單元測試、集成測試、系統(tǒng)測試，根據不同階段測試的測重點不同。4.4.1.1 單元測試首先按照系統(tǒng)、子系統(tǒng)和模塊進行劃分，但最終的單元必須是功能模塊,或面向對象過程中的若干個類。單元測試是對功能模塊進行正確性檢驗的測試工作，也是后續(xù)測試的基礎。目的是在于發(fā)現(xiàn)各模塊內部可能存在的各種差錯，因此需要從程序的內部結構出發(fā)設計測試用例，著重考慮以下五個方面：1) 模塊接口：對所測模塊的數據流進行測試。2) 局部數據結構：檢查不正確或不一致的數據類型說明、使用尚未賦值或尚未初始化的變量、錯誤

10、的初始值或缺省值。3) 路徑：雖然不可能做到窮舉測試，但要設計測試用例查找由于不正確的計算（包括算法錯、表達式的符號表示不正確、運算精度不夠等）、不正確的比較或不正常的控制流（包括不同數據類型量的相互比較、不適當地修改了循環(huán)變量、錯誤的或不可能的循環(huán)終止條件等）而導致的錯誤。4) 錯誤處理：檢查模塊有沒有對預見錯誤的條件設計比較完善的錯誤處理功能，保證其邏輯上的正確性。5) 邊界：注意設計數據流、控制流中剛好等于、大于或小于確定的比較值的用例。4.4.1.2 集成測試集成測試也叫組裝測試或聯(lián)合測試（接口聯(lián)調測試）。通常，在單元測試的基礎上需要將所有的模塊按照設計要求組裝成系統(tǒng)，這時需要考慮的問

11、題：1) 在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失。2) 一個模塊的功能是否會對另一個模塊的功能產生不利的影響。3) 各個子功能組合起來，能否達到預期要求的父功能。4) 全局數據結構是否有問題。5) 單元模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。4.4.1.3 系統(tǒng)測試系統(tǒng)測試目的是在于驗證軟件的功能和性能及其他特性是否與用戶的要求一致，主要是下列類型的測試：1) 用戶界面測試：測試用戶界面是否具有導航性、美觀性、行業(yè)或公司的規(guī)范性、是否滿足設計中要求的執(zhí)行功能。2) 功能測試：驗證功能實現(xiàn)是否滿足客戶需求。3) 性能測試：測試相應時間、事務處理效率和其他時間敏感

12、的問題。4) 可靠性測試：測試系統(tǒng)對數據有效性檢查能力和抵御誤操作的能力。5) 容量測試：測試大量數據對系統(tǒng)的影響。6) 容錯性測試：測試軟件系統(tǒng)克服軟件、硬件故障的能力。7) 數據安全測試：測試系統(tǒng)在出現(xiàn)異常情況下，是否可以保護數據不丟失；測試系統(tǒng)能否可以進行數據庫的備份和恢復。8) 易用性測試：重點關注系統(tǒng)的易理解性、易操作性、易學性。9) 安裝部署測試：確保軟件系統(tǒng)在所有可能情況下的安裝效果和一旦安裝部署之后必須保證正確運行的質量。4.4.2 測試管理4.4.2.1 組織機構測試經理測試人員項目經理項目負責人開發(fā)人員4.4.2.2 角色職責角色職責測試經理- 負責與項目經理溝通，進行測試

13、的整體策劃、制定測試計劃、組織測試實施、分析測試結果，控制測試進度和Bug清除率。測試員- 負責檢查測試環(huán)境、測試版本、編寫并執(zhí)行測試大綱、測試用例、報告缺陷、驗證修改結果，進行測試數據統(tǒng)計，提交測試報告。項目經理- 負責與測試經理溝通，參與測試的整體策劃、提供測試依據等相關材料；介紹系統(tǒng)功能，負責測試組與開發(fā)組間協(xié)調。程序員- 按時部署測試環(huán)境、數據，提交可測試的軟件版本，協(xié)助測試員編寫用例，及時修改缺陷、填寫修改記錄。QA工程師- 對測試過程、測試結果進行規(guī)范性檢查項目負責人- 評價測試結果4.4.2.3 測試安排總體測試時間：2016年9月1日2016年11月13日。第一階段測試：201

14、6年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.4 測試步驟具體測試步驟：1、 對整體流程進行測試，保證系統(tǒng)整體業(yè)務流程可以走通。2、 對整體業(yè)務流程中的分支流程進行測試，保證系統(tǒng)業(yè)務分支流程可以走通。3、 各業(yè)務系統(tǒng)流程測試4、 各子系統(tǒng)功能點測試。5、 覆蓋性測試。6、 系統(tǒng)性能測試?；貧w測試貫穿每個

15、測試階段。系統(tǒng)整體流程如下說明：1、基礎數據由數據采集系統(tǒng)從進出口相關執(zhí)法部門采集，包括涉毒信息、旅客信息、航班信息等，形成基礎數據。2、系統(tǒng)進行數據收集存儲、數據加工處理、主題數據建立等處理，進行主數據轉換加載與業(yè)務數據轉換加載，產生中間過程數據，具有時間戳和更新標記。3、對集成數據進行分析，滿足實時查詢與統(tǒng)計需要，形成統(tǒng)計報表。4、動態(tài)數據倉庫存放風險數據、預警數據。5、對預警數據進行評分、排名并設置消息推送。4.4.2.5 測試管理工具工具名稱：Bugfree3.0來源：官方網站功能：測試用例、缺陷管理，自動統(tǒng)計測試結果4.4.2.6 缺陷處理流程Bugfree3.0規(guī)定缺陷有三種狀態(tài)（

16、見表-1）、七種解決方案（見表-2）。表-1缺陷有三種狀態(tài)缺陷狀態(tài)說明Active(激活)Bug的初始狀態(tài)。任何新建的Bug狀態(tài)都是Active?？梢酝ㄟ^編輯功能修改Bug的內容，并指派給合適的人員解決。Resolved(解決)解決中或解決完畢狀態(tài)。Closed(關閉)已修復Bug、或解決方案（見表-2）被驗證無誤之后可以關閉。該Bug處理完畢。如果沒有真正解決或者重新復現(xiàn)，可以重新激活，Bug狀態(tài)重新變?yōu)锳ctive。按照Bugfree缺陷處理流程，測試者、Bug修改者都可以使用Bugfree報告Bug，測試者跟蹤Bug狀態(tài)，驗證處理結果，直至關閉。具體過程：1、 報告者提交一個Bug，缺陷

17、生命周期開始，Bugfree自動將狀態(tài)置為Active（激活狀態(tài)），報告者將Bug指派給修改Bug的程序員；2、 程序員接受Bug，點擊解決按鈕，進行Bug的修改，并指派Bug修改后的驗證人（默認該Bug的報告者），Bug變?yōu)镽esolved（解決狀態(tài)），程序員選擇Bug解決方案：表-2七種解決方案Bug解決方案方案說明處理規(guī)則Fixed（有效Bug）確認是Bug，修改完畢、提交驗證。測試員驗證，修改正確、可以關閉；否則，重新激活。External（有效Bug）外部因素（比如瀏覽器、操作系統(tǒng)、其他第三方軟件）造成的問題。項目經理確認、必要時與客戶和相關方協(xié)商解決，測試員驗證后關閉；否則，重新激

18、活。Postponed（有效Bug）目前不必修改的問題（發(fā)現(xiàn)的太晚了，下一個版本討論是否解決）。項目經理確認、必要時與客戶協(xié)商，如果同意下一個版本討論或修改，保持“解決”狀態(tài)和當前解決方案不變；否則，重新激活，選擇Fixed/External方案進行修改；WontFix（有效Bug）是個問題，但是不影響系統(tǒng)使用。項目經理確認，確實不值得修改、可讓測試員關閉；否則，重新激活，選擇適當的方案進行修改；ByDesign（無效Bug）就是這么設計的，不是Bug。項目經理確認，必要時與客戶協(xié)商，如果的確不是Bug，需求和設計就是這樣、或受限于開發(fā)環(huán)境和工具，可讓測試員關閉；否則，重新激活,選擇適當的方案

19、進行修改；Duplicate（無效Bug）重復的Bug。測試員確認，確實是重報、測試員可以關閉；否則，重新激活，選擇適當的方案進行修改；NotRepro（無效Bug）無法復現(xiàn)的問題。項目經理確認，確實無法復現(xiàn)，指定專人跟蹤，如果一段時間內Bug不再重現(xiàn)，可讓測試員關閉；否則，重新激活，選擇適當的方案進行修改。*需項目經理確認的問題也可委托開發(fā)組長、技術骨干審查，關鍵問題由開發(fā)組長報項目經理確認。3、 Bug報告者和修改者參考程序員填寫的Bug解決方案，按照上表定義的處理規(guī)則，需要時請項目經理確認，將可以關閉的Bug置為Closed（關閉狀態(tài)）；否則，重新激活、置為Active（激活狀態(tài)）。4.

20、4.2.7 測試通過準則充分性：計劃測試的功能至少全部測試了一遍；至少對缺陷高發(fā)點進行了回歸測試；測試用例覆蓋率100%；測試用例執(zhí)行率100%；Bug清除率：有效Bug清除率95%以上；其中：1-2級Bug清除率100%3-4級Bug清除率95%以上；遺留Bug必須得到客戶認可。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ī)范依據評審通過的

21、需求規(guī)格說明書、設計書編寫測試用例；需求、設計變更時要有客戶變更記錄；要求測試大綱和用例：測試大綱和用例覆蓋軟件所有的功能要點和主要業(yè)務流程；每一條用例應給出測試數據（需要輸入數據時）、執(zhí)行步驟、方法、預期結果。測試大綱和用例應經過項目經理審查、客戶負責人評審。4.4.2.10 提交成果物Ø 整體測試方案Ø 測試用例Ø BUG一覽表Ø 測試報告第 5 章 用戶測試用戶測試過程中重點關注需求文檔中描述的功能是否都已經實現(xiàn)，主要對系統(tǒng)進行易用性測試、可靠性測試、容錯性測試。其測試依據及測試環(huán)境同測試組相同。5.1 測試管理5.1.1 組織機構5.1.2 角色

22、職責角色職責用戶測試代表負責檢查測試環(huán)境、測試版本、報告缺陷、驗證修改結果，進行測試數據統(tǒng)計，提交用戶測試報告。項目經理負責與甲方測試人員溝通，參與測試的整體策劃、提供測試依據等相關材料；介紹系統(tǒng)功能，負責甲方測試人員與開發(fā)組間協(xié)調。開發(fā)組按時部署測試環(huán)境、數據，提交可測試的軟件版本，編寫測試用例、測試大綱，及時修改缺陷、填寫修改記錄。QA工程師對測試過程、測試結果進行規(guī)范性檢查甲方項目負責人評價測試結果5.1.3 測試安排測試時間： 2016年11月5日2016年11月20日，業(yè)主進行測試并完成問題修改。5.1.4 測試步驟第一步：測試開始前，由項目經理介紹已實現(xiàn)的功能、業(yè)務流程，保證用戶方測試員深入理解系統(tǒng)功能和業(yè)務流程，執(zhí)行測試用例。