整體測試方案(共20頁)_第1頁
整體測試方案(共20頁)_第2頁
整體測試方案(共20頁)_第3頁
整體測試方案(共20頁)_第4頁
整體測試方案(共20頁)_第5頁
已閱讀5頁,還剩16頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、精選優(yōu)質(zhì)文檔-傾情為你奉上文檔編號:IECUSTOM-整體測試方案V1.0海關(guān)信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目 整體測試方案二零一六年九月專心-專注-專業(yè)關(guān)于本文檔項目名稱海關(guān)信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目主 題整體測試方案標 識IECUSTOM-整體測試方案V1.0說 明系統(tǒng)測試前,需要制定方案,以便對測試工作進行指導。適用對象甲方項目負責人、有關(guān)人員中科軟項目工程領(lǐng)導小組、項目經(jīng)理、項目組全體成員以及相關(guān)人員修訂歷史版本章節(jié)類型日期作者說明V1.0C2016年9月5日羅晨說明:類型創(chuàng)建(C)、修改(U)、刪除(D)、增加(A);評審記錄角色簽名日期說明目 錄第 1 章 概述1.1 編

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

3、及計算機情報信息系統(tǒng)支持,完善情報機制,體現(xiàn)情報信息服務(wù),增強對全國海關(guān)情報業(yè)務(wù)的掌控能力。第 2 章 測試方案概述2.1 測試目標(1)系統(tǒng)界面操作無明顯異常,符合業(yè)務(wù)需求規(guī)定;(2)根據(jù)需求規(guī)格說明書,總體設(shè)計、詳細設(shè)計文檔實現(xiàn)整體功能測試;(3)系統(tǒng)主要流程,無異常,符合需求;(4)根據(jù)需求進行性能測試、穩(wěn)定性、健全性及安全測試; (5)所有測試用例100%執(zhí)行;(6)所有缺陷處于Closed、Rejected、Pending狀態(tài);(7)缺陷修改要求:High級缺陷修復率應達到100%;Medium級缺陷修復率應達到95%以上;Low級缺陷修復率應達到60%以上。2.2 測試范圍本次測試

4、主要針對海關(guān)信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺項目的軟件需求規(guī)格說明書中涉及的要求進行完整性測試,包括界面、功能和流程的全面測試,以及性能測試、穩(wěn)定性、健全性及安全測試等。本次測試采用黑盒測試的方法為主,輔助進行代碼審查。2.3 參考資料海關(guān)信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目需求規(guī)格說明書海關(guān)信息數(shù)據(jù)采集與數(shù)據(jù)應用平臺測試項目合同公司軟件測試規(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內(nèi)存Windows XP Professional SP2PC機2(172.17

5、.9.123)Pentium(R) D CPU 3.00GHZ2.99GHZ,1.99GB內(nèi)存Windows XP Professional SP2服務(wù)器端應用服務(wù)器待定待定數(shù)據(jù)庫服務(wù)器企業(yè)端(172.16.1.108):IBM XDERIES_366 Intel(R)Xeon(7M) MP CUP 3.16GHz 3.17GHz 3.25GB內(nèi)存中心端(172.17.16.22):System Model: IBM,7040-671Number Of Processors: 16Processor Clock Speed: 1500 MHzCPU Type: 64-bitMemory Siz

6、e: 16384 MBHard Disk: MB企業(yè)端:Windows 2003 Server Enterprise Edition SP2中心端:AIX Version 5.3MQ服務(wù)器(企業(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)

7、分中心(郵箱客戶端)同PC機1和PC機2同PC機1和PC機2瀏覽器IE6表4.1 測試環(huán)境第 4 章 測試方案4.1 測試依據(jù)在本項目實施過程中編寫的需求、設(shè)計、計劃、測試方案、測試報告等產(chǎn)出物,需要通過客戶、項目經(jīng)理、QA、測試經(jīng)理等該項目相關(guān)人員審核。4.2 功能測試測試人員根據(jù)通過審核的需求、設(shè)計、測試方案等文檔編寫測試用例,要求測試用例的功能覆蓋率要達到100%,測試過程中測試人員嚴格執(zhí)行測試用例并記錄測試結(jié)果,驗證系統(tǒng)的功能實現(xiàn)是否達到需求、設(shè)計要求,是否滿足客戶目標。測試用例執(zhí)行率達到100%。測試過程中所有問題提交BugFree。4.3 性能測試應用系統(tǒng)經(jīng)過系統(tǒng)測試后形成相對穩(wěn)定

8、版本,測試組在穩(wěn)定版本的基礎(chǔ)上選擇性能測試點進行性能測試,測試組負責編寫性能測試方案,對系統(tǒng)進行壓力測試、并發(fā)測試、穩(wěn)定性測試。測試過程中使用性能測試工具LoadRunner。執(zhí)行性能測試時,同時填寫性能測試記錄表、性能測試調(diào)優(yōu)過程記錄表。4.4 內(nèi)部測試4.4.1 測試策略測試過程按三個步驟進行,即單元測試、集成測試、系統(tǒng)測試,根據(jù)不同階段測試的測重點不同。4.4.1.1 單元測試首先按照系統(tǒng)、子系統(tǒng)和模塊進行劃分,但最終的單元必須是功能模塊,或面向?qū)ο筮^程中的若干個類。單元測試是對功能模塊進行正確性檢驗的測試工作,也是后續(xù)測試的基礎(chǔ)。目的是在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯,因此需要從程

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

10、于、大于或小于確定的比較值的用例。4.4.1.2 集成測試集成測試也叫組裝測試或聯(lián)合測試(接口聯(lián)調(diào)測試)。通常,在單元測試的基礎(chǔ)上需要將所有的模塊按照設(shè)計要求組裝成系統(tǒng),這時需要考慮的問題:1) 在把各個模塊連接起來的時候,穿越模塊接口的數(shù)據(jù)是否會丟失。2) 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響。3) 各個子功能組合起來,能否達到預期要求的父功能。4) 全局數(shù)據(jù)結(jié)構(gòu)是否有問題。5) 單元模塊的誤差累積起來,是否會放大,從而達到不能接受的程度。4.4.1.3 系統(tǒng)測試系統(tǒng)測試目的是在于驗證軟件的功能和性能及其他特性是否與用戶的要求一致,主要是下列類型的測試:1) 用戶界面測試:測

11、試用戶界面是否具有導航性、美觀性、行業(yè)或公司的規(guī)范性、是否滿足設(shè)計中要求的執(zhí)行功能。2) 功能測試:驗證功能實現(xiàn)是否滿足客戶需求。3) 性能測試:測試相應時間、事務(wù)處理效率和其他時間敏感的問題。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) 易用性測試:重點關(guān)注系統(tǒng)的易理解性、易操作性、易學性。9) 安裝部署測試:確保軟件系統(tǒng)在所有可能情況下的安裝效果和一旦安裝部署

12、之后必須保證正確運行的質(zhì)量。4.4.2 測試管理4.4.2.1 組織機構(gòu)測試經(jīng)理測試人員項目經(jīng)理項目負責人開發(fā)人員4.4.2.2 角色職責角色職責測試經(jīng)理- 負責與項目經(jīng)理溝通,進行測試的整體策劃、制定測試計劃、組織測試實施、分析測試結(jié)果,控制測試進度和Bug清除率。測試員- 負責檢查測試環(huán)境、測試版本、編寫并執(zhí)行測試大綱、測試用例、報告缺陷、驗證修改結(jié)果,進行測試數(shù)據(jù)統(tǒng)計,提交測試報告。項目經(jīng)理- 負責與測試經(jīng)理溝通,參與測試的整體策劃、提供測試依據(jù)等相關(guān)材料;介紹系統(tǒng)功能,負責測試組與開發(fā)組間協(xié)調(diào)。程序員- 按時部署測試環(huán)境、數(shù)據(jù),提交可測試的軟件版本,協(xié)助測試員編寫用例,及時修改缺陷、填

13、寫修改記錄。QA工程師- 對測試過程、測試結(jié)果進行規(guī)范性檢查項目負責人- 評價測試結(jié)果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.4 測試步驟具體測試步驟:1、 對整體流程進行測試,保證系統(tǒng)整體業(yè)務(wù)流程

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

15、送。4.4.2.5 測試管理工具工具名稱:Bugfree3.0來源:官方網(wǎng)站功能:測試用例、缺陷管理,自動統(tǒng)計測試結(jié)果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的內(nèi)容,并指派給合適的人員解決。Resolved(解決)解決中或解決完畢狀態(tài)。Closed(關(guān)閉)已修復Bug、或解決方案(見表-2)被驗證無誤之后可以關(guān)閉。該Bug處理完畢。如果沒有真正解決或者重新復現(xiàn),可以重新激活,Bug狀態(tài)重新變?yōu)锳c

16、tive。按照Bugfree3.0.4缺陷處理流程,測試者、Bug修改者都可以使用Bugfree報告Bug,測試者跟蹤Bug狀態(tài),驗證處理結(jié)果,直至關(guān)閉。具體過程:1、 報告者提交一個Bug,缺陷生命周期開始,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,修改完畢、提交驗證。測試員驗證,修改

17、正確、可以關(guān)閉;否則,重新激活。External(有效Bug)外部因素(比如瀏覽器、操作系統(tǒng)、其他第三方軟件)造成的問題。項目經(jīng)理確認、必要時與客戶和相關(guān)方協(xié)商解決,測試員驗證后關(guān)閉;否則,重新激活。Postponed(有效Bug)目前不必修改的問題(發(fā)現(xiàn)的太晚了,下一個版本討論是否解決)。項目經(jīng)理確認、必要時與客戶協(xié)商,如果同意下一個版本討論或修改,保持“解決”狀態(tài)和當前解決方案不變;否則,重新激活,選擇Fixed/External方案進行修改;WontFix(有效Bug)是個問題,但是不影響系統(tǒng)使用。項目經(jīng)理確認,確實不值得修改、可讓測試員關(guān)閉;否則,重新激活,選擇適當?shù)姆桨高M行修改;By

18、Design(無效Bug)就是這么設(shè)計的,不是Bug。項目經(jīng)理確認,必要時與客戶協(xié)商,如果的確不是Bug,需求和設(shè)計就是這樣、或受限于開發(fā)環(huán)境和工具,可讓測試員關(guān)閉;否則,重新激活,選擇適當?shù)姆桨高M行修改;Duplicate(無效Bug)重復的Bug。測試員確認,確實是重報、測試員可以關(guān)閉;否則,重新激活,選擇適當?shù)姆桨高M行修改;NotRepro(無效Bug)無法復現(xiàn)的問題。項目經(jīng)理確認,確實無法復現(xiàn),指定專人跟蹤,如果一段時間內(nèi)Bug不再重現(xiàn),可讓測試員關(guān)閉;否則,重新激活,選擇適當?shù)姆桨高M行修改。*需項目經(jīng)理確認的問題也可委托開發(fā)組長、技術(shù)骨干審查,關(guān)鍵問題由開發(fā)組長報項目經(jīng)理確認。3、

19、Bug報告者和修改者參考程序員填寫的Bug解決方案,按照上表定義的處理規(guī)則,需要時請項目經(jīng)理確認,將可以關(guān)閉的Bug置為Closed(關(guān)閉狀態(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必須得到客戶認可。4.4.2.8 測試異常中止準則1、 系統(tǒng)的一二級錯誤太多、不能繼續(xù)測試;2、 發(fā)現(xiàn)明顯設(shè)計錯誤、導致測試對象完全錯誤;3

20、、 發(fā)現(xiàn)測試對象與用戶需求完全不符合;4、 測試環(huán)境沒有保障;5、 測試人員或缺陷修改人員缺席。4.4.2.9 風險分析及預防嚴格遵循軟件測試規(guī)范,做到:組織規(guī)范、流程規(guī)范、文檔規(guī)范依據(jù)評審通過的需求規(guī)格說明書、設(shè)計書編寫測試用例;需求、設(shè)計變更時要有客戶變更記錄;要求測試大綱和用例:測試大綱和用例覆蓋軟件所有的功能要點和主要業(yè)務(wù)流程;每一條用例應給出測試數(shù)據(jù)(需要輸入數(shù)據(jù)時)、執(zhí)行步驟、方法、預期結(jié)果。測試大綱和用例應經(jīng)過項目經(jīng)理審查、客戶負責人評審。4.4.2.10 提交成果物Ø 整體測試方案Ø 測試用例Ø BUG一覽表Ø 測試報告第 5 章 用戶測

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論