信息中心交通gis共享服務(wù)平臺-系統(tǒng)測試計劃

1、目 錄1.引言31.1編寫目的. 31.2內(nèi)容范圍. 31.3準入條件. 31.4術(shù)語31.5參考資料42. 項目基本情況52.1 項目背景52.2 系統(tǒng)部署62.2.1 部署系統(tǒng)內(nèi)容63. 測試方案總體思路73.1測試對象. 73.2測試目標. 73.3測試規(guī)劃. 73.3.1測試分類73.3.2測試方法83.3.3測試用例編寫要點93.3.4本方案采用的技術(shù)和方法143.4 測試狀態(tài)控制153.4.1 錯誤級別定義153.4.2測試進入標準173.4.3測試暫停和再啟動標準193.4.4測試停止標準193.4.5測試里程碑214.環(huán)境準備. 225.測試安排. 236.測試管理. 246.

2、1 單元測試246.1.1 單元測試方法246.1.2 單元測試工具246.2 集成測試246.2.1集成測試內(nèi)容256.2.2測試用例256.2.3測試整理及上報256.3 系統(tǒng)測試266.3.1 系統(tǒng)測試內(nèi)容266.3.2 系統(tǒng)測試. 276.4 驗收測試286.4.1驗收測試內(nèi)容286.4.2測試用例設(shè)計規(guī)格286.4.3測試用例291. 引言1.1 編寫目的本文檔對省交通 GIS 共享實施過程中所建設(shè)的相關(guān)的測試方案進行描述。本文檔將作為系統(tǒng)實施測試以及用戶驗收的依據(jù)。本文檔的讀者包括：項目小組項目開發(fā)團隊所有成員1.2 內(nèi)容范圍該測試方案總體由：項目基本情況、測試方案總體思路、測試環(huán)

3、境準備、安排、測試管理和進度安排等幾部分內(nèi)容組成。1.3 準入條件該測試方案主要進行集成測試、系統(tǒng)測試和驗收測試：在應(yīng)用開發(fā)完成單元測試后進行集成測試在相關(guān)各子系統(tǒng)部署并納入實際運行環(huán)境后進行系統(tǒng)測試在完成系統(tǒng)試運行后進行驗收測試1.4 術(shù)語1、單元測試：由開發(fā)進行的單元測試，重點模塊的單元測試可交由專門的測試進行。單元測試覆蓋所有子系統(tǒng)的新開發(fā)的功能模塊。2、集成測試：在單元測試的基礎(chǔ)上 ,將所有模塊按照設(shè)計要求組裝成一個完整的系統(tǒng)進行的測試,又可以叫做組裝測試。3、系統(tǒng)測試：系統(tǒng)測試是把經(jīng)過確認的納入到部署之后實際運行環(huán)境中，與其他系統(tǒng)成分組合在一起進試。目的在于驗證系統(tǒng)在真實運行環(huán)境中的

4、功能和性能特性。檢查已實現(xiàn)的是否滿足了需求說明書中確定了的各種需求、以及配置是否完整、正確。4、驗收測試：驗收測試是由用戶組織進行的系統(tǒng)測試，目的驗證系統(tǒng)確實滿足了用戶的功能和性能需求。1.5 參考資料省交通 GIS 共享-需求分析說明書2. 項目基本情況2.1 項目背景“十二五”期間，是我省交通大發(fā)展的時期，各級交通部門應(yīng)以新的時代要求，充分履行行業(yè)管理和公眾服務(wù)等方面的職能，需要盡快展開行業(yè)基礎(chǔ)數(shù)據(jù)資源和業(yè)務(wù)系統(tǒng)建設(shè)，實現(xiàn)資源共享、推動業(yè)務(wù)協(xié)同，提高管理決策水平以及公共服務(wù)質(zhì)量。隨著我省路網(wǎng)的不斷完善、經(jīng)濟社會的不斷發(fā)展，交通將持續(xù)增長，對我省路網(wǎng)的運行監(jiān)測能力、運營管理效率和信息服務(wù)水平

5、提出更高的要求，改進服務(wù)的訴求將持續(xù)增強。服務(wù)的目標，從原來的“走得了”提高到“走得好”。應(yīng)用現(xiàn)代，整合多種交通出行信息資源，為公眾提供綜合出行信息服務(wù)，實現(xiàn)優(yōu)質(zhì)的服務(wù)，既是行業(yè)發(fā)展的需要，也是社會的迫切要求。根據(jù)省交通信息化“十二五”專項規(guī)劃總體框架，規(guī)劃將省級數(shù)據(jù)中心、路網(wǎng)運行監(jiān)測與管理系統(tǒng)、路政巡查管理系統(tǒng)、省級道路運政管理系統(tǒng)、綜合查詢分析系統(tǒng)和公眾出行系統(tǒng)建設(shè)明確列為我省“十二五”期間交通信息化的建設(shè)任務(wù)，數(shù)據(jù)中心作為信息化發(fā)展的基礎(chǔ)支撐，是我省交通信息化“十二五”期間建設(shè)的首要任務(wù)。為推動提高省干線公路運行管理與出行服務(wù)水平，省交通運輸廳以部示范工程為契機，開展“省干線公路運行監(jiān)測

6、與信息服務(wù)系統(tǒng)工程”建設(shè)，根據(jù)項目要求，要構(gòu)建省級數(shù)據(jù)中心、干線公路運行狀態(tài)監(jiān)測分析系統(tǒng)、高速公路路政巡查管理系統(tǒng)、省級道路運政聯(lián)網(wǎng)系統(tǒng)、行業(yè)綜合查詢分析系統(tǒng)和公眾出行信息服務(wù)系統(tǒng)。根據(jù)部示范推廣項目建設(shè)小組的安排，信息中心承擔省級數(shù)據(jù)中心、行業(yè)綜合查詢和分析系統(tǒng)以及公眾出行信息服務(wù)系統(tǒng)建設(shè)。以整合行業(yè)信息資源為基礎(chǔ)，建立全省交通地理，建設(shè)交通數(shù)據(jù)中心，建設(shè)行業(yè)綜合查詢和分析系統(tǒng)以及公眾出行信息服務(wù)系統(tǒng)，編制相關(guān)技術(shù)、管理規(guī)范，為行業(yè)管理部門業(yè)務(wù)協(xié)同提供基礎(chǔ)，同時為全面推進交通信息化建設(shè)提供支撐。2.2 系統(tǒng)部署2.2.1部署系統(tǒng)內(nèi)容根據(jù)推廣工程建設(shè)內(nèi)容和工程建設(shè)目標要求，本次工程需部置的系統(tǒng)

7、從體系結(jié)構(gòu)上分為三個層次：數(shù)據(jù)資源、交換、與共享層系統(tǒng)；。交通信息資源中心層數(shù)據(jù)庫管理系統(tǒng)；綜合業(yè)務(wù)應(yīng)用層基于 GIS 的地圖查詢與展現(xiàn)系統(tǒng)。3. 測試方案總體思路3.1 測試對象本方案測試對象為省交通 GIS 共享實施過程中所建設(shè)的各功能模塊。項目質(zhì)量控制組針對各個功能的實現(xiàn)和系統(tǒng)功能的測試。3.2 測試目標1、測試已實現(xiàn)的系統(tǒng)是否達到設(shè)計的要求，包括：各個功能點是否已實現(xiàn)，業(yè)務(wù)流程是否正確；2、系統(tǒng)規(guī)定的操作和運行穩(wěn)定；3、Bug 數(shù)和缺陷率控制在可接收的范圍之內(nèi)。3.3 測試規(guī)劃3.3.1測試分類按測試的性質(zhì)來分，可分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試又可分為文檔測試和代碼測試。動態(tài)測試又稱

8、為運行程序測試，或運行代碼測試，它又分為黑盒子測試和白盒子測試。所謂靜態(tài)測試，就是測試（包括程序員、分析員）用眼睛看文檔和源程序，用頭腦分析文檔和源程序，用筆或用電子編輯工具批注所發(fā)現(xiàn)。這里特別要強調(diào)靜態(tài)代碼測試（Code Reviews），事實證明它是一種行之有效的好方法，因為它具有如下優(yōu)點：促進編程規(guī)范化，如編程風格、命名規(guī)范、注釋行、算法分析；能在早期發(fā)現(xiàn)錯誤，防止錯誤與發(fā)散；能發(fā)現(xiàn)小概率事件錯誤，這樣的錯誤路徑很少走，功能測試很難發(fā)現(xiàn)；一般能在早期發(fā)現(xiàn)大部分錯誤。所謂動態(tài)測試，就是在計算機或網(wǎng)絡(luò)上運行被測試的系統(tǒng)，按照事先規(guī)定的測試計劃，運行實現(xiàn)準備的測試用例，取得運行的結(jié)果或數(shù)據(jù)，再

9、將此結(jié)果或數(shù)據(jù)與測試計劃中的計劃結(jié)果或數(shù)據(jù)相比較。若兩者一致，測試通過；若兩者不一致，則發(fā)現(xiàn)有錯誤，并找出錯誤。3.3.2測試方法從測試或方法上來說，測試一般分為兩大類方能測試和路徑測試，即黑盒測試和白盒測試。產(chǎn)品或項目的黑盒測試方法是：面向需求分析中的功能，性能等內(nèi)容，涉及測試用例，搭建測試環(huán)境，輸入測試用例，運行被測試的系統(tǒng)，獲得測試數(shù)據(jù)，將、數(shù)據(jù)與計劃結(jié)果、數(shù)據(jù)相比較，取得，根據(jù)形成測試。該方法適合測試部門的測試和用戶，對系統(tǒng)進行集成測試、系統(tǒng)測試和驗收測試，或?qū)M件和中間件進行接口與功能測試，也適合評測組織的確認測試、驗收測試、鑒定測試和登記測試。黑盒測試是一種宏觀功能上的測試，隨著生

10、產(chǎn)和組裝技術(shù)的發(fā)展，黑盒測試方法越來越普及。面向程序路徑的白盒測試方法是：對程序的執(zhí)行路徑，搭建測試環(huán)境，設(shè)計枚舉用例，進行枚舉測試，取得測試數(shù)據(jù)，形成測試。該方法不適合大單元、大系統(tǒng)的測試，也不適合于評測中心、測試部門的測試。它只適合于很小的單元測試，以及從事底層工作、生產(chǎn)構(gòu)件的測試進試。因為白盒測試是一種粒度很小的測試，即程序級的微觀上的測試。在實際應(yīng)用中，任何一種的功能都是有限的，所以功能測試是有窮盡的，而某些的執(zhí)行路徑是無限的，或者說是無窮的。例如，分支與循環(huán)的組合程序，執(zhí)行路徑可能是無窮的，所以的路徑測試可能是無窮盡的。依然有無窮多的路徑，如果要測試完成會花費大量的時間、精力，是很不

11、現(xiàn)實的。為了解決這種問題，比較好的辦法是以靜態(tài)代碼測試為主，即用“順序、選擇(如：if-then-else)、循環(huán)(如：do-while 或do-until)”3 種基本結(jié)構(gòu)，一行一行地分析測試其源程序，通過此種靜態(tài)代碼測試先發(fā)現(xiàn)大部分錯誤；與此同時，以白盒測試為輔，選擇幾條典型的程序路徑進試。3.3.3測試用例編寫要點1.3.3.1 目的確立測試用例編寫的要點，以保證使用最有效的測試用例，保證測試質(zhì)量。1.3.3.2 術(shù)語解釋1、測試分析：對重要業(yè)務(wù)、重要流程進試前的分析。2、業(yè)務(wù)流程測試用例：關(guān)于產(chǎn)品業(yè)務(wù)、重要流程的測試用例。1.3.3.3 業(yè)務(wù)流程測試用例編寫原則1、系統(tǒng)性對于系統(tǒng)業(yè)務(wù)流

12、程要能夠完整說明整個系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關(guān)系；對于模塊業(yè)務(wù)流程要能夠說明清楚子系統(tǒng)功能、重要功能點以及它們之間的關(guān)系；2、連貫性對于系統(tǒng)業(yè)務(wù)流程來說，各個子系統(tǒng)之間是如何連接在一起，如果需要接口，各個子系統(tǒng)之間是否有正確的接口；如果是依靠頁面，頁面是否正確；對于模塊業(yè)務(wù)流程來說，同級模塊以及上下級模塊是如何一個子系統(tǒng)，其功能接口是否連貫；1.3.3.4 測試用例設(shè)計的方法1、 等價類劃分法確定等價類的原則如果輸入條件決定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。如果輸入條件規(guī)定了輸入值的集合，或者規(guī)定了“必須如何”的條件，此時可確立一個有效

13、等價類和一個無效等價類；如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)γ總€輸入值分別進行處理，此時可為每一個輸入值確立一個有效等價類，此外，針對這組值確立一個無效等價類，它是所有不允許輸入值的集合；如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同的角度規(guī)則）；如果確知，已劃分的等價類中各元素在程序中的處理方式不同，則應(yīng)將此等價類進一步劃分成更小的等價類。測試用例的選擇原則為每一個等價類規(guī)定一個唯一的；設(shè)計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直至所有的有效等價類都被覆蓋過；設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的

14、無效等價類，重復這一步，直至所有的無效等價類都被覆蓋為止。2、 邊界值分析法測試用例的選擇原則如果輸入了條件規(guī)定了值的范圍，則應(yīng)取剛達到這個范圍的邊界值，以及剛剛這個邊界范圍的值作為測試輸入數(shù)據(jù)；如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大多 1、比最小小 1 的數(shù)作為測試輸入數(shù)據(jù)；根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則；如果程序的規(guī)格說明給出的輸入輸出域是有序集合，則應(yīng)選取集合的每一個元素和最后一個元素作為測試用列；如果程序中使用了一個數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當選擇這個數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例；分析規(guī)格說明，找出其他可能的邊界條件。邊界條件是指計劃的操作界限所在的邊緣條件。數(shù)

15、據(jù)類型：如果測試問題包含確定的邊界,那么數(shù)據(jù)類型可能是：數(shù)值速度字符地址位置尺寸數(shù)量數(shù)據(jù)特征：同時,考慮這些類型的下述特征：第一個/最后一個、最小值/最大值開始/完成、超過/在內(nèi)空/滿、最短/最長最慢/最快、最早/最遲最大/最小、最高/最低相鄰/最遠越界測試：通常是簡單加 1 或者很小的數(shù)(對于最大值)和減少 1 或者很小的數(shù)(對于最小值)，例如：第一個減 1/最后一個加 1開始減 1/完成加 1空了再減/滿了再加慢上加慢/快上加快最大數(shù)加 1/最小數(shù)減 1最小值減 1/最大值加 1剛好超過/剛好在內(nèi)短了再短/長了再長早了更早/晚了更晚最高加 1/最低減 1另一些該注意的輸入：默認、空白、空值

16、、零值和無；、錯誤、不正確和數(shù)據(jù)。1.3.3.5 測試用例設(shè)計的原則1、全面性應(yīng)盡可能覆蓋程序的各種路徑；應(yīng)考慮存在跨年、跨月的數(shù)據(jù)；大量數(shù)據(jù)并發(fā)測試的準備。2、正確性輸入界面后的數(shù)據(jù)應(yīng)與測試文檔所的數(shù)據(jù)一致；預期結(jié)果應(yīng)與測試數(shù)據(jù)發(fā)生的業(yè)務(wù)吻合；符合正常業(yè)務(wù)慣例；測試數(shù)據(jù)應(yīng)符合用戶實際工作業(yè)務(wù)流程；兼顧各種業(yè)務(wù)變化的可能。3、 仿真性地名、號碼等應(yīng)具有模擬功能，符合一般名慣例。4、可操作性測試用例中應(yīng)寫清測試的操作步驟，不同的操作步驟相對應(yīng)的操作結(jié)果。1.3.3.6 測試用例優(yōu)先級優(yōu)先級由需求組根據(jù)業(yè)務(wù)確定對于 A、B 級應(yīng)重點考慮3.3.4本方案采用的技術(shù)和方法此測試方案主要采用動態(tài)測試技術(shù)

17、和靜態(tài)測試技術(shù)相結(jié)合的方法。動態(tài)測試中主要運用黑盒測試方法：黑盒測試用例設(shè)計方法包括等價類劃分、邊界值分析以及錯誤推測等設(shè)計原則。靜態(tài)測試中主要運用技術(shù)評審的方式，模塊輔之以代碼的方法。測試用例優(yōu)先級描述A重要的模塊功能和業(yè)務(wù)流程B比較重要的模塊功能和業(yè)務(wù)流程C次重要的模塊功能和業(yè)務(wù)流程D不重要的模塊功能和業(yè)務(wù)流程E系統(tǒng)小單元、系統(tǒng)容錯功能3.4 測試狀態(tài)控制3.4.1錯誤級別定義一級：不能完全滿足系統(tǒng)要求，基本功能未完全實現(xiàn)；系統(tǒng)或掛起等導致系統(tǒng)不能繼續(xù)運行。包括以下各種錯誤：由于程序所引起的死機,退出；死循環(huán)；數(shù)據(jù)庫發(fā)生死鎖；因錯誤操作導致的程序中斷；功能錯誤；與數(shù)據(jù)庫連接錯誤；數(shù)據(jù)通訊錯

18、誤。二級：嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有更正辦法（重新安裝或重新啟動該不屬于更正辦法）。使系統(tǒng)不穩(wěn)定、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結(jié)果，或部分功能無法執(zhí)行，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。包括以下各種錯誤：程序接口錯誤；因錯誤操作迫使程序中斷；系統(tǒng)可被執(zhí)行，但操作功能無法執(zhí)行（含指令）；單項操作功能可被執(zhí)行，但在此功能中某些小功能（含指令參數(shù)的使用）無法被執(zhí)行（對系統(tǒng)非致命的）；在小功能項的某些項目（選項）使用無效（對系統(tǒng)非致命的）；業(yè)務(wù)流程不正確；功能實現(xiàn)不完整，如刪除時沒有考慮數(shù)據(jù)關(guān)聯(lián)；功能的實現(xiàn)不正確，如在系統(tǒng)實現(xiàn)的界面上，一些可接受輸入的控件點擊后無作用

19、；對數(shù)據(jù)庫的操作不能正確實現(xiàn)；報表格式以及打印內(nèi)容錯誤（行列不完整，數(shù)據(jù)顯示不在所對應(yīng)的行列等導致數(shù)據(jù)顯示結(jié)果不正確的錯誤）。三級：嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法（重新安裝或重新啟動該不屬于更正辦法）。系統(tǒng)性能或響應(yīng)時間變慢、產(chǎn)生錯誤的中間結(jié)果但不影響最終結(jié)果等影響有限；包括以下各種錯誤：操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）；打印內(nèi)容、格式錯誤（只影響報表的格式或外觀，不影響數(shù)據(jù)顯示結(jié)果的錯誤）；簡單的輸入限制未放臺進行控制；刪除操作未給出提示 已捉的系統(tǒng)，不影響繼續(xù)操作；雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時間受到影響；不能定位焦點或定位有誤，影響功

20、能實現(xiàn)；顯示不正確但輸出正確；增刪改功能，在本界面不能實現(xiàn)，但在另一界面可以補充實現(xiàn)。四級：使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。界面拼寫錯誤或用戶使用不方便等小問題或需。包括以下各種錯誤：界面不規(guī)范；輔助說明描述不清楚；輸入輸出不規(guī)范；長時間操作未給用戶提示；提示窗口文字未采用行業(yè)術(shù)語；可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志；必填項與非必填加以區(qū)別；滾動條無效；鍵盤支持不好，如在可輸入多行的字段中，不支持回車換行；或?qū)ο嗤侄?，在不同界面支持不同的快捷方式；界面不刷新，影響功能實現(xiàn)。五級：其他錯誤光標跳轉(zhuǎn)設(shè)置不好，鼠標（光標）定位錯誤；一些建議性問題。3.4.2測試進入

21、標準接收標準為程序員經(jīng)過單元測試后，提交測試時應(yīng)達到的最低標準，如不滿足，則返還開發(fā)，重新提交測試。3.4.2.1接收資料完整1、經(jīng)過程序源代碼審核；2、待測版本的程序文件包、安裝包；3、應(yīng)用開發(fā)組應(yīng)提供的必要的文檔、說明書和需求；4、必要的測試數(shù)據(jù)、文件。3.4.2.2程序界面1、界面風格界面風格一致（包括控件的大小、快捷鍵令名稱），美觀大方；無錯字別字，最好能望。2、菜單項問題各菜單項功能均已實現(xiàn)；各菜單項快捷鍵可以使用。3.4.2.3 功能實現(xiàn)1、說明書規(guī)定的功能或程序員提交的功能說明書的功能均已實現(xiàn)；2、基本流程可以走通；3、界面上的功能均實現(xiàn)，符合設(shè)計文擋規(guī)定的功能；4、打開界面上的

22、功能，時間符合需求規(guī)格中的性能要求；5、正確實現(xiàn)左右鍵功能（如果有）；左鍵拖動功能已實現(xiàn)；右鍵功能與菜單項功能對應(yīng)；右鍵的快捷鍵應(yīng)與菜單項一致。6、提示信息提示、警告、或錯誤說明應(yīng)該清楚、明了、恰當；的輸入或操作應(yīng)有足夠的提示說明；由于誤操作得到的反饋信息，應(yīng)該能夠指導用戶的下一步操作。7、數(shù)據(jù)庫的增刪改問題增刪改功能可以實現(xiàn)；增刪改時響應(yīng)時間符合需求規(guī)格中的性能要求。8、數(shù)據(jù)的查詢能夠及時查詢所需要的數(shù)據(jù)；查詢響應(yīng)時間符合需求規(guī)格中的性能要求；能被主模塊調(diào)起或調(diào)起子模塊。3.4.3測試暫停和再啟動標準測試環(huán)境發(fā)生變化（場地、網(wǎng)絡(luò)、硬件、等），又處于不可使用狀態(tài)；系統(tǒng)有大量錯誤或嚴重錯誤，以至

23、于繼續(xù)測試沒有任何意義；錯誤得到修改后，需要重新啟動測試；開發(fā)組提供錯誤修改后的安裝程序以及再啟動測試的相關(guān)說明；測試組安裝修改后的程序。必要，需要重新初始化測試數(shù)據(jù)，重新執(zhí)試規(guī)程，恢復到發(fā)生錯誤前的狀態(tài)。3.4.4測試停止標準3.4.4.1 概述1、目的本文檔的目的是為功能測試、系統(tǒng)測試提供停止標準。2、詞匯表缺陷（Defect）缺陷是對產(chǎn)品預期屬性的偏離現(xiàn)象。覆蓋率（Coverage rate）語句覆蓋率、測試用例執(zhí)行覆蓋率，測試需求覆蓋率等的總稱。3.4.4.2測試停止標準1、測試暫停、停止標準系統(tǒng)在進行功能、系統(tǒng)測試時，發(fā)現(xiàn)一級錯誤（大于等于 1）、二級錯誤（大于等于 2）暫停測試返回

24、開發(fā)。系統(tǒng)經(jīng)過功能、系統(tǒng)測試，分別達到功能、系統(tǒng)測試停止標準。項目需暫停以進行調(diào)整時，測試應(yīng)隨之暫停，并備份暫停點數(shù)據(jù)。項目在其開發(fā)生命周期內(nèi)出現(xiàn)估算，進度偏差，需暫?；蚪K止時，測試應(yīng)隨之暫停或終止，并備份暫停或終止點數(shù)據(jù)。2、功能測試停止標準功能測試用例設(shè)計已經(jīng)通過項目組評審確認；按照功能測試計劃完成了功能測試；達到了功能測試計劃中關(guān)于功能測試所規(guī)定的覆蓋率的要求；系統(tǒng)達到詳細設(shè)計定義的各項功能，性能；在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復率達到標準。3、系統(tǒng)測試停止標準系統(tǒng)測試用例設(shè)計已經(jīng)通過項目組評審確認；按照系統(tǒng)測試計劃完成了系統(tǒng)測試；達到了測試計劃中關(guān)于系統(tǒng)測試所規(guī)定的覆蓋

25、率的要求；系統(tǒng)滿足需求規(guī)格說明書的要求；在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復率達到標準。4、缺陷修復率標準二級錯誤修復率應(yīng)達到 100%；四級錯誤修復率應(yīng)達到 95%以上；五級錯誤修復率應(yīng)達到 60%以上。5、覆蓋率標準測試用例執(zhí)行覆蓋率應(yīng)達到 100%（功能測試用例均以執(zhí)行）；測試需求執(zhí)行覆蓋率應(yīng)達到 100%（業(yè)務(wù)測試用例均以執(zhí)行）。3.4.5測試里程碑里程碑任務(wù)標志測試計劃系統(tǒng)測試計劃測試用例設(shè)計、準備系統(tǒng)測試方案、系統(tǒng)測試用例單元測試N/A集成測試N/A系統(tǒng)測試系統(tǒng)測試驗收測試驗收測試項目結(jié)束N/A4. 環(huán)境準備系統(tǒng)的單元測試和集成測試工作在開發(fā)測試環(huán)境進行，系統(tǒng)測試和驗收

26、測試在實際的用戶環(huán)境進行。關(guān)于系統(tǒng)的實際運行環(huán)境，可參考本次工程的建設(shè)方案資料。本章主要對開發(fā)測試環(huán)境進行介紹。注：為了避免可能存在的開發(fā)測試環(huán)境與用戶實際運行環(huán)境的差別引起的測試差異對系統(tǒng)實際運行效果的影響，開發(fā)測試環(huán)境的設(shè)計盡量模擬用戶實際運行環(huán)境。5. 測試安排測試方案由項目的質(zhì)量控制組牽頭組織實施，測試安排計劃如下：1、單元測試單元測試工作由程序員在開發(fā)編碼的同時進行。2、 集成測試測試部下設(shè)專門的測試小組，負責集成測試相關(guān)工作。包括：測試用例設(shè)計、測試數(shù)據(jù)準備、待測系統(tǒng)接收、測試工作執(zhí)行、Bug 發(fā)現(xiàn)、Bug、Bug、以及和開發(fā)團隊配合針對修改后提交的新版本進行進一步的測試，直至滿足

27、測試停止標準完成測試。3、系統(tǒng)測試在系統(tǒng)部署并納入實際運行環(huán)境后，由項目的測試小組、系統(tǒng)支持組與用戶積極配合進行系統(tǒng)測試。確保系統(tǒng)在真實運行環(huán)境中的功能和性能特性。檢查已實現(xiàn)的是否滿足了需求說明書中確定了的各種需求、以及配置是否完整、正確。對可能會出現(xiàn)的系統(tǒng)功能、性能上，及時發(fā)現(xiàn)并解決。4、驗收測試在試運行工作后期，由用戶組織進行系統(tǒng)的驗收測試，確保系統(tǒng)確實滿足了用戶的功能和性能需求，通過后系統(tǒng)完成試運行進入正式運行階段。此工作由用戶組織，項目的質(zhì)量控制組、系統(tǒng)支持組需進行積極配合。6. 測試管理6.1 單元測試單元測試管理主要包括兩部分內(nèi)容，一個為測試方法的選擇，另一個為單元測試工具的應(yīng)用。

28、6.1.1 單元測試方法首先，以靜態(tài)代碼測試為主，對于每一個程序單元使用“順序、選擇(如：if-then-else)、循環(huán)(如：do-while 或 do-until)”等基本結(jié)構(gòu)，進行源程序的分析測試。其次，以白盒測試為輔，對程序單元內(nèi)及單元間的典型程序路徑進行測試。6.1.2 單元測試工具要求開發(fā)在開發(fā)環(huán)境中必須配置單元測試工具或插件，如在Eclipse 集成開發(fā)環(huán)境中安裝使用 JUnit 單元測試框架、在 Delphi 開發(fā)開發(fā)環(huán)境中安裝使用 DUnit 單元測試框架。這樣，開發(fā)可以在集成的環(huán)境里非常方便地編寫 TestCase 和測試套件，并且這些被編寫的 TestCase和測試套件可

29、以被保存下來便于在后續(xù)的開發(fā)過程中隨時重復的使用。通過單元測試工具的應(yīng)用，不僅可以提高測試工作效率，同時也可促進開發(fā)單元測試的主動性。6.2 集成測試6.2.1集成測試內(nèi)容1、根據(jù)系統(tǒng)需求規(guī)格及系統(tǒng)設(shè)計文檔進試用例（包括功能、性能）的設(shè)計及測試數(shù)據(jù)的準備。2、測試環(huán)境的搭建。3、測試過程的管理：開發(fā)提交可測試程序版本并提供相關(guān)文檔及說明資料；測試按照測試用例進行集成測試；測試對程序 Bug 的發(fā)現(xiàn)及整理，并一并上報 Bug 管理系統(tǒng) JIRA；開發(fā)通過 JIRA 系統(tǒng)和測試進行交互，并對 Bug 進行修復，經(jīng)過單元測試后再次提交新的可測試版本；測試繼續(xù)新一輪集成測試，并按照上述步驟直至所有問題

30、全部被解決。4、測試的審核和結(jié)果：某系統(tǒng)某輪次的集成測試完成后，所有測試用例全部通過，則認為該系統(tǒng)的集成測試通過。6.2.2測試用例完整的系統(tǒng)測試用例請參見系統(tǒng)測試用例。6.2.3測試整理及上報6.2.3.1 測試整理根據(jù)整理出的測試用例對系統(tǒng)進試，并詳細測試的結(jié)果信息，包括：用例序號功能點（通過/未通過）未通過時的情景描述測試測試時間補充說明等6.2.3.2 測試上報將每一個輪次的測試提交上報至 BugFree 系統(tǒng)，充分利用BugFree 系統(tǒng)為測試與開發(fā)提供的協(xié)同工作機制。6.3 系統(tǒng)測試6.3.1系統(tǒng)測試內(nèi)容1、系統(tǒng)在用戶實際運行環(huán)境的部署：把經(jīng)過集成測試確認的納入到部署之后的實際運行環(huán)境中，準備與其它系統(tǒng)成分組合在一起進試。2、使用與集成測試相同的測試用例（包括功能、性能）設(shè)計及測試數(shù)據(jù)，并結(jié)合用戶的試運行情況進行系統(tǒng)測試。3、測試過程的管理：實施及測試按照