國庫信息處理系統(tǒng)-系統(tǒng)測試計劃方案

1、國息處理系統(tǒng)測試計劃方案資料，請遵照公司的規(guī)定保存使用文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標識：當前版本：作 者：完成日期：JD-TIPS -IT-PLAN1.0.1靖雪峰2004-8-2版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1.0.0靖雪峰2005-8-11.0.1靖雪峰2005-8-26增加測試資源內容； 增加測試用例編寫方案及相關約定內 容；目 錄1.概述62.適用對象和范圍63.術語、名詞定義63.1.3.2.3.3.3.4.3.5.3.6.3.7.3.8.3.9.3.10.3.11.3.12.3.13.系統(tǒng)測試6黑盒測試（功能測試）6白盒測試6灰盒測試7健壯性測試（容錯能

2、力/恢復能力測試）7接口測試7強度測試7壓力測試7性能測試7安全測試8可靠性測試8安裝/反安裝測試8文檔測試84.測試工作流程94.1.4.2.4.3.4.4.測試管理總流程9制定測試計劃工作流程9設計測試用例工作流程10試工作流程10測試工作總體流程10單元測試工作流程11集成測試工作流程12系統(tǒng)測試工作流程13驗收測試工作流程15執(zhí)4.4.1.4.4.2.4.4.3.4.4.4.4.4.5.4.5.缺陷管理與改錯流程165.測試參考文檔和測試提交文檔165.1.5.2.測試參考文檔16測試提交文檔176.測試資源176.1.人力資源176.1.1.6.1.2.、角色及職責17培訓計劃176

3、.2.測試環(huán)境186.2.1.6.2.2.環(huán)境18服務端列表196.3.測試工具207.測試方法和方式208.通過測試的標準219.測試中斷與開始的標準2110.測試策略2210.1.10.2.10.3.10.4.10.5.10.6.10.7.10.8.10.9.10.10.10.11.10.12.10.13.10.14.數(shù)據(jù)和數(shù)據(jù)庫完整性測試22接口測試22集成測試23功能測試24用戶界面測試26性能評測27負載測試28強度測試29容量測試30安全性和控制測試31故障轉移和恢復測試32配置測試34安裝/反安裝測試35文檔測試3511.測試范圍與測試任務3511.1. 測試范圍3611.1.1

4、.11.1.2.11.1.3.11.1.4.測試對象36需要測試的產品功能36不需要測試的產品功能36測試覆蓋3611.2. 測試任務3611.3. 測試.3812.測試進度4013.測試用例編寫方案及相關約定4113.1.13.2.13.3.13.4.編寫原則41衡量測試用例設計的質量標準41測試用例管理41測試用例與開發(fā)的對應關系約定4213.5.13.6.13.7.測試用例類型約定42測試階段、類型與執(zhí)行角色的關系約定43測試用例.4314.缺陷管理與改錯計劃4314.1.14.2.14.3.流程圖43缺陷管理.43缺陷管理規(guī)則4315.實施建議44附錄一 缺陷分類44附錄二 缺陷嚴重程

5、度45附錄三 優(yōu)先級46附錄四 測試計劃意見461. 概述為了提高檢測出錯誤的幾率，使測試能有計劃地、有條不紊地進行，就必須要編制測試相關文件。而標準化的測試文件就如同一種通用的參照體系，可達到便于交流的目的。文件中所規(guī)定的內容可以作為對測試過程完備性的對照檢查表，故采用這些文件將會提高測試過程的每個階段的能見度，極大地提高測試工作的可管理性。2. 適用對象和范圍主要針對對象為管理、開發(fā)和測試。3. 術語、名詞定義3.1. 系統(tǒng)測試系統(tǒng)測試是通過與系統(tǒng)的需求規(guī)格作比較，發(fā)現(xiàn)與系統(tǒng)需求規(guī)格不相符合或與之的地方。它將通過確認測試的，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持、數(shù)

6、據(jù)和等其他系統(tǒng)元素結合起來，在實際運行（使用）環(huán)境下，對計算機系統(tǒng)進行的測試。3.2. 黑盒測試（功能測試）黑盒測試是基于系統(tǒng)需求規(guī)格，在不知道系統(tǒng)或組件的結構的情況下進行的測試。通常又將黑盒測試叫做：基于規(guī)格的測試、輸入輸出測試、功能測試或數(shù)據(jù)驅動測試。是基于用戶觀點出發(fā)的測試。主要是驗證功能是否符合需求，包括原定功能的檢驗、是否有冗余功能、遺漏功能。3.3. 白盒測試白盒測試也叫結構測試、邏輯驅動測試或給予程序的測試。主要是分析程序的構造，并根據(jù)構造設計測試用例。3.4. 灰盒測試可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間, 對有所了解, 但不見得到了如指掌的程度, 卻

7、可以結合這些了解做些比黑盒多點的測試。3.5. 健壯性測試（容錯能力/恢復能力測試）側重于程序容錯能力的測試。本測試在單元測試階段和系統(tǒng)測試階段都要進行。如數(shù)據(jù)邊界測試、數(shù)據(jù)測試、異常中斷測試等等，主要是驗證程序對各種異常情況是否進行正確處理。3.6. 接口測試程序員對各個模塊進行系統(tǒng)聯(lián)調的測試，包含程序內接口和程序外接口測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在集成測試階段完成的。建議由開發(fā)進行。3.7. 強度測試強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如，當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；定量地

8、增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；運行需要最大空間（或其他資源）的測試用例；運行可能導致虛存操作系統(tǒng)動的測試用例，等等?；虼疟P數(shù)據(jù)劇烈抖3.8. 壓力測試對系統(tǒng)不斷施加壓力的測試，是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。例如測試一個Web 站點在大量的負荷下，何時系統(tǒng)的響應會或失敗。3.9. 性能測試在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統(tǒng)的整體。它和通常所說的強度、壓力/負載測試有密切關系。所以壓力和強度測試應該于性能測試一同進行。3.10. 安全測試主要是測試系統(tǒng)在沒有的或者外部用戶對系統(tǒng)進行或者破壞時如何進行處理，是否

9、仍能保證數(shù)據(jù)的安全。測試進行?？梢詫W些技術，來對系統(tǒng)3.11. 可靠性測試這里是比較狹義的可靠性測試，它主要是對系統(tǒng)能否穩(wěn)定運行進行一個統(tǒng)計，在實際工作中如果沒有條件可以不必特意去做。重點做好與之緊密相關的功能測試、健壯性測試就可以了。3.12. 安裝/反安裝測試安裝測試主要檢驗是否可以正確安裝， 安裝文件的各項設置是否有效， 安裝后能否影響原系統(tǒng)；反安裝是逆過程，測試是否刪除干凈，是否會影響原系統(tǒng)等。3.13. 文檔測試主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗文檔是否和實際應用存在差別。文檔測試主要檢查文檔的正確性、完備性和可理解性。正確性是指的功能和操作寫錯

10、，也不允許文檔內容前后。完備性是指文檔不可以“虎頭蛇尾”，更不許漏掉關鍵內容。文檔測試不需要編寫測試用例。4. 測試工作流程4.1. 測試管理總流程迭代缺陷管理與改錯執(zhí)行測試用例4.2. 制定測試計劃工作流程測試計劃輸入項目計劃書確定測試相關規(guī)范和約定確定階段的測試范圍和任務確定測試方法和方式確定測試環(huán)境與輔助工具確定測試完成準則確定測試與任務表輸入需求規(guī)格說明書設計測試用例制定測試計劃4.3. 設計測試用例工作流程依據(jù)需求文檔生成依據(jù)概要設計、體系設計文檔依據(jù)詳細設計文檔生成4.4. 執(zhí)試工作流程4.4.1.測試工作總體流程結項總結階段驗收測試階段系統(tǒng)測試階段集成測試階段單元黑盒測試階編碼及

11、單元白盒測試階設計階段詳細設計階段單元測試對應的用例集成測試對應的用例概要設計階段結束后系統(tǒng)測試對應的用例需求分析階段結束后說明：集成測試和系統(tǒng)測試的反饋意見可能導致設計文檔（需求或數(shù)據(jù)庫）的修改。4.4.2.單元測試工作流程循環(huán)單元測試進入集成測試單元總結測試達到測試要求編碼審核提交 Bug測試用例審核編碼及白盒測試測試用例詳細設計4.4.3.集成測試工作流程集成測試進入系統(tǒng)測試集成測試總結達到集成測試要求單元測試審核提交 Bug測試用例審核接上一階段測試用例4.4.4.系統(tǒng)測試工作流程業(yè)務測試壓力測試說明：壓力測試為模擬用戶正常使用時，系統(tǒng)正常工作的最小時間。進入性能測試審核壓力測試返回開

12、發(fā)修改準備數(shù)據(jù)庫業(yè)務測試審核模擬多用戶接上一階段力測試提交業(yè)務測試達到業(yè)務測試要求確認測試審核提交 Bug業(yè)務測試用例審核接上一階段業(yè)務測試用例性能測試說明：測試系統(tǒng)的極限（最多使用人數(shù)和數(shù)據(jù)庫的極限容量）。進入驗收測試審核提交測試返回開發(fā)修改安裝測試系統(tǒng)測試審核接上一階段進入安裝測試審核提交測試返回開發(fā)修改系統(tǒng)增加數(shù)據(jù)量壓力測試審核模擬用戶數(shù)量接上一階段4.4.5.驗收測試工作流程驗收測試說明：驗收測試的應包含非本系統(tǒng)的。進入結項總結階段返回開發(fā)修改審核提交測試準備測試安裝測試審核業(yè)務測試用例審核接上一階段業(yè)務測試用例4.5. 缺陷管理與改錯流程否是由項目經理或測試組長確認是否為 bug否是

13、測試或項目經理再次確認是否為 bug5. 測試參考文檔和測試提交文檔5.1. 測試參考文檔下表列出了制定測試計劃時所使用的文檔，并標明了各文檔的可用性：文檔（版本/日期）已創(chuàng)建或可用已被接收或已經過復審作者或來源備注需求規(guī)格說明書是 否 是 否 概要設計是 否 是 否 測試員回歸測試開發(fā)修復 bug 將狀態(tài)置為（FIXED）將 bug 狀態(tài)置為（OPEN/REOPEN）將 bug 狀態(tài)置為（CLOSE）測試員發(fā)現(xiàn)一個 bug（當前狀態(tài)置為 NEW）5.2. 測試提交文檔6. 測試資源6.1. 人力資源6.1.1.、角色及職責6.1.2.培訓計劃培訓項參與授課計劃培訓時間角色職責、任務備注項目經

14、理靖雪峰測試小組長、測試設計員測試設計員測試員測試設計員測試員開發(fā)文檔（版本/日期）已創(chuàng)建或可用已被接收或已經過復審作者或來源備 注測試計劃及方案測試用例測試是 否 是 否 是 否 是 否 是 否 是 否 可考慮通過td 產生可考慮通過td 產生詳細設計是 否 是 否 模塊開發(fā)手冊 測試計劃及方案測試用戶操作手冊安裝指南是 否 是 否 是 否 是 否 是 否 是 否 是 否 是 否 是 否 是 否 6.2. 測試環(huán)境下表列出了測試的系統(tǒng)環(huán)境6.2.1.環(huán)境類別名稱版本生產廠商/自產用途備注（負責提供并安排支持）開發(fā)工具JBuilder2005Borland接口模擬器開發(fā)WSAD5.1.2IBM

15、應用開發(fā)MB？消息流開發(fā)MQ？erDesigner數(shù)據(jù)庫設計環(huán)境（相關作系統(tǒng)等）開發(fā)運行支撐系統(tǒng)硬件環(huán)境（網絡、設備等）客戶端服務端請參照服務端列表網絡備注具體參照需求規(guī)格說明書需求約定、概要設計說明書設計約定。編程技術工具網絡硬件環(huán)境第產品MQ、MB 培訓DB2 數(shù)據(jù)庫培訓6.2.2.服務端列表物理位置機器名機器型號切換器編號服務器配置用戶名/操作系統(tǒng)用途IP 地址自上而下第 5 臺Hxlw-win-1DELL/142522CPU,4GAdministrator 無Win2000 SrvSack4DB210.1.5.94自上而下第 6 臺Hxlw-win-2DELL/142532CPU,4G

16、Administrator 無Win2000 SrvSack4MB,MQ10.1.5.91自上而下第 10臺Hxinux-2DELL/142542CPU,4GRoot/123456RedhatAS3.0Linux未連接自上而下第 11臺Hxlw-wasDELL/142552CPU,4GAdministrator 無Win2000 SrvSack4WASWSAD10.1.5.93自上而下第 12臺ccseverDELL/142562CPU,4GAdministrator 無Win2000SrvSack4ClearCase10.1.5.92用途機器名(IP)用戶/機器型號機器配制操作系統(tǒng)備注數(shù)據(jù)庫

17、服務器Hxlw-win-1(10.1.5.94)db2admin/db2adminPC-ServerDELL/14252*2.8GHz/2GB/280GBWin2000Srvsp4MB、MQ 服務器Hxlw-win-2(10.1.5.91)db2admin/db2adminPC-ServerDELL/14252*2.8GHz/2GB/280GBWin2000Srvsp4WAS、WSAD服務器Hxlw-was(10.1.5.93)administratorPC-ServerDELL/14252*2.8GHz/4GB/280GBWin2000Srvsp4TD 服務器Ccsever(10.1.5.9

18、2)AdministratorDELL/14252*2.8GHz/4GB/280GBWin2000Srvsp4運行、支撐.JDK1.3.1的運行環(huán)境WAS5.1IBM應用服務器Db28.2IBM數(shù)據(jù)庫服務器MQ530.8CSD08IBM消息中間件WBI-MB5.0.4IBM信息總線操作系統(tǒng)6.3. 測試工具7. 測試方法和方式測試方式主要以手工測試為主，在條件允許的情況下使用自動化測試工具進試。說明：黑盒測試是依據(jù)用戶能看到的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)他們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對應關系，特別是針對功能進試。主要由測試小組黑盒測試覆蓋范圍完成執(zhí)行黑盒測試。測試方法測試覆

19、蓋率執(zhí)行描述黑盒測試100%測試功能測試或數(shù)據(jù)驅動測試灰盒測試1020%測試或開發(fā)靜態(tài)的白盒測試或動態(tài)的黑盒測試白盒測試5%開發(fā)結構測試或邏輯驅動測試用途工具生產廠商/自產版本備注測試管理TestDirectorMercuryerActive7.6具體使用約定請參照測試工具使用約定及開發(fā)與測試配合工作規(guī)范壓力測試LoadRunnerMercuryerActive7.8功能測試WinRunnerMercuryerActive7.6XML 工具Xml Spy2005、驗證 XML，通過XSD 生成 XML 文件DB2 數(shù)據(jù)庫工具DBTool自產1.0對 TIPS 數(shù)據(jù)庫進行操作日志文件工具LogF

20、ileMonitor自產1.0MQ 隊列工具Monitor自產1.0通過 MQ 的 BROWSE 或GET 方式系統(tǒng)信息測試用例覆蓋黑盒測試輸入覆蓋輸出覆蓋測試用例覆蓋：測試用例的沒一個用例都被測試過輸入覆蓋：測試過程中所輸入的數(shù)據(jù)或資料必須一再的試驗，如在程序安裝過程中輸入用戶名時，測試者必須反復輸入不同長度的中文、英文或數(shù)字等來做測試。輸出覆蓋：測試過程中程序所產生的行為、反映及數(shù)據(jù)必須都一再地試驗，如不同情況的窗口的內容、運算結果數(shù)據(jù)等都必須反復地測試審核。8.通過測試的標準一般有“基于測試用例”和“基于缺陷密度” 兩種評比準則，在這里準則如下：功能性測試用例通過率達到 100；非功能性

21、測試用例通過率達到 95；采用前者。（3）沒有高于優(yōu)先級 3 以上備選通過辦法：。根據(jù)實際情況由段是否結束。開發(fā)部門的經理、項目經理和測試等共同確定本階9. 測試中斷與開始的標準當優(yōu)先級 1當優(yōu)先級 2當優(yōu)先級 3超過總體問題的 1/3 時超過總體問題的 1/2 時超過總體問題的 3/4 時測試重新開始時的回歸測試項目10.測試策略10.1.數(shù)據(jù)和數(shù)據(jù)庫完整性測試10.2.接口測試測試目標確保接口調用的正確性測試范圍：所有、硬件接口，輸入輸出數(shù)據(jù)技術：開始標準：完成標準：測試重點和優(yōu)先級：測試目標：確保數(shù)據(jù)庫方法和進程正常運行，數(shù)據(jù)不會遭到損壞測試范圍：技術：調用各個數(shù)據(jù)庫方法和進程，并在其中

22、填充有效的和無效的數(shù)據(jù)（或對數(shù)據(jù)的請求）。檢查數(shù)據(jù)庫，確保數(shù)據(jù)已按預期的方式填充，并且所有的數(shù)據(jù)庫事件已正常發(fā)生；或者檢查所返回的數(shù)據(jù)，確保正當?shù)睦碛蓹z索到了正確的數(shù)據(jù)開始標準：完成標準：所有的數(shù)據(jù)庫方法和進程都按照設計的方式運行，數(shù)據(jù)沒有遭到損壞。測試重點和優(yōu)先級：需考慮的特殊事項：測試可能需要 DBMS 開發(fā)環(huán)境或驅動程序在數(shù)據(jù)庫中直接輸入或修改數(shù)據(jù)。進程應該以手工方式調用。應使用小型或最小的數(shù)據(jù)庫（的數(shù)量有限）來使所有無法接受的事件具有更大的可視度。10.3. 集成測試測試目標檢測需求務流程，數(shù)據(jù)流的正確性測試范圍：需求中明確的業(yè)務流程，或組合不同功能模塊而形成一個大的功需考慮的特殊事項

23、：接口的限制條件10.4. 功能測試測試目標確保測試的功能正常，其中包括，數(shù)據(jù)輸入，報文發(fā)送、轉發(fā)、能。技術：利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實以下內容：在使用有效數(shù)據(jù)時得到預期的結果。在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。開始標準：在完成某個集成測試時必須達到標準各模塊接口都已完成編碼完成標準：所計劃的測試已全部執(zhí)行。所發(fā)現(xiàn)的缺陷已全部解決。測試重點和優(yōu)先級：測試重點指在測試過程中需著重測試的地方，優(yōu)先級可以根據(jù)需求及嚴重來定需考慮的特殊事項：確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或（的或外部的）接收，處理和檢索等功

24、能。測試范圍：聯(lián)網交換子系統(tǒng)(包括所有聯(lián)網交易功能),信息整理子系統(tǒng)(包括所有應用功能,運行管理子系統(tǒng)(包括所有管理功能),國 息處理系統(tǒng)的運行流程(其中包括日間,日切窗口,對帳(其中包括與高業(yè)的對帳,與 TBS 的對帳,與稅局的對帳) 技術：利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實以下內容：在使用有效數(shù)據(jù)時得到預期的結果。在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。開始標準：各功能項都已完成開發(fā)完成標準：具體參照本文通過測試的標準。測試重點和優(yōu)先級：需考慮的特殊事項：功能是否符合需求功能是否完整功能是否有作用功能是否無錯誤10.5. 用戶界面

25、測試測試目標核實以下內容：通過測試進行的瀏覽可正確反映業(yè)務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種 方法（Tab鍵、鼠標移動、和快捷鍵）的使用窗口的對象和特征（例如，菜單、大小、位置、狀態(tài)和中心）都符合標準。測試范圍：技術：為每個窗口創(chuàng)建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態(tài)。開始標準：完成標準：成功地核實出各個窗口都與基準版本保持一致，或符合可接受標準測試重點和優(yōu)先級：需考慮的特殊事項：并不是所有定制或第對象的特征都可。10.6. 性能評測測試目標核實所指定的事務或業(yè)務功能在以下情況下的性能行為：正常的預期工作量預期的

26、最繁重工作量測試范圍：技術：使用為功能或業(yè)務周期測試制定的測試過程。通過修改數(shù)據(jù)文件來增加事務數(shù)量，或通過修改來增加每項事務的迭代數(shù)量。應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多個客戶機（虛擬的或實際的客戶機，請參見下面的“需要考慮的特殊事項”）上重復。開始標準：完成標準：單個事務或單個用戶：在每個預期時間范圍內成功地完成測試，沒有發(fā)生任何故障。多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發(fā)生任何故障。測試重點和優(yōu)先級：需考慮的特殊事項：綜合的性能測試還包括在服務器上添加工作量?？刹捎枚喾N方法來執(zhí)行此操作，其中包括：直接將“事務強行分配到” 服務器上

27、，這通常以“結構化語言”（SQL）調用的形式來實現(xiàn)。通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數(shù)百個）客戶機。此負載可通過“ 終端仿真（Remote Terminal Emulation）工具來實現(xiàn)。此技術還可用于在網絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運 試 ）在系統(tǒng)上添加負載。性能測試應該在 的計算機上或在 的機時內執(zhí)行，以便實現(xiàn)完全的控制和精確的評測。性能測試所用的數(shù)據(jù)庫應該是實際大小或相同縮放比例的數(shù)據(jù)庫。10.7. 負載測試測試目標核實所指定的事務或商業(yè)理由在不同的工作量條件下的性能行為時間。測試范圍：技術：使用為功能或業(yè)務周期測試制定的測試。通過修改數(shù)據(jù)文件來增加

28、事務數(shù)量，或通過修改來增加每項事務發(fā)生的次數(shù)。開始標準：完成標準：多個事務或多個用戶：在可接受的時間范圍內成功地完成測試，沒有發(fā)生任何故障。測試重點和優(yōu)先級：需考慮的特殊事項：負載測試應該在的計算機上或在的機時內執(zhí)行，以便實現(xiàn)完全的控制和精確的評測。負載測試所用的數(shù)據(jù)庫應該是實際大小或相同縮放比例的數(shù)據(jù)庫。10.8. 強度測試測試目標核實測試對象能夠在以下強度條件下正常運行，不會出現(xiàn)任何錯誤：服務器上幾乎沒有或根本沒有可用的內存（RAM 和 DASD）連接或模擬了最大實際（實際允許）數(shù)量的客戶機多個用戶對相同的數(shù)據(jù)或帳戶執(zhí)行相同的事務最繁重的事務量或的事務組合（請參見上面的“性能測試”）。注：

29、強度測試的目標可表述為確定和那些使系統(tǒng)無法繼續(xù)正常運行的情況或條件?？蛻魴C的強度測試在“配置測試”的第 3.1.11 節(jié)中進行了說明。測試范圍：技術：使用為性能評測或負載測試制定的測試。要對有限的資源進試，就應該在一臺計算機上運試，而且應該減少或限務器上的 RAM 和 DASD。對于其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或的事務組合。開始標準：完成標準：所計劃的測試已全部執(zhí)行，并且在達到或超出指定的系統(tǒng)限制時沒有出現(xiàn)任何 故障，或者導致系統(tǒng)出現(xiàn)故障條件的并不在指定的條件范圍之內。測試重點和優(yōu)先級：需考慮的特殊事項：如果要增加網絡工作強度，可能會需要使

30、用網絡工具來給網絡加載消息或信息包。應該暫時減少用于系統(tǒng)的 DASD，以限制數(shù)據(jù)庫可用空間的增長。使多個客戶機對相同的或數(shù)據(jù)帳戶同時進行的達到同步。10.9. 容量測試測試目標核實測試對象在以下高容量條件下能否正常運行：連接或模擬了最大（實際或實際允許）數(shù)量的客戶機，所有客戶機在長時間內執(zhí)行相同的、且情況（性能）的業(yè)務功能。已達到最大的數(shù)據(jù)庫大小（實際的或按比例縮放的），而且同時執(zhí)行多個查詢或報表事務。測試范圍：技術：使用為性能評測或負載測試制定的測試。應該使用多臺客戶機來運行相同的測試或互補的測試，以便在長時間內產生最繁重的事務量或 的事務組合（請參見上面的“強度測試”）創(chuàng)建最大的數(shù)據(jù)庫大小

31、（實際的、按比例縮放的、或填充了代表性數(shù)據(jù)的數(shù)據(jù)庫），并使用多臺客戶機在長時間內同時運行查詢和報表事務。開始標準：完成標準：所計劃的測試已全部執(zhí)行，而且達到或超出指定的系統(tǒng)限制時沒有出現(xiàn)任何故障。測試重點和優(yōu)先級：需考慮的特殊事項：對于上述的高容量條件，哪個時間段是可以接受的時間？10.10. 安全性和控制測試安全性和控制測試側重于安全性的兩個關鍵方面：應用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務功能的系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或。測試目標應用程序級別的安全性：核實 Actor 只能其所屬用戶類型已被的那些功能或數(shù)據(jù)。系統(tǒng)級別的安全性：核實只有具備系統(tǒng)和應用程序權限的Actor 才能系統(tǒng)和應

32、用程序。測試范圍：技術：應用程序級別的安全性：確定并列出各用戶類型及其被的功能或數(shù)據(jù)。為各用戶類型創(chuàng)建測試，并通過創(chuàng)建各用戶類型所特有的事務來核實其權限。修改用戶類型并為相同的用戶重新運試。對于每種用戶類型，確保正確地提供或了這些附加的功能或數(shù)據(jù)。系統(tǒng)級別的：請參見以下的“需考慮的特殊事項”。開始標準：完成標準：各種已知的 Actor 類型都可 相應的功能或數(shù)據(jù)，而且所有事務都按照預期的方式運行，并在先前的應用程序功能測試中運行了所有的事務。測試重點和優(yōu)先級：需考慮的特殊事項：必須與相應的網絡或系統(tǒng)管理員一直對系統(tǒng)權進行檢查和。由于此測試可能是網絡管理可系統(tǒng)管理的職能，可能會不需要執(zhí)行此測試。

33、10.11. 故障轉移和恢復測試測試目標確?；謴瓦M程（手工或自動）將數(shù)據(jù)庫、應用程序和系統(tǒng)正確地恢復到預期的已知狀態(tài)。測試中將包括以下各種情況：客戶機斷電服務器斷電通過網絡服務器產生的通信中斷DASD 和/或 DASD 控制器被中斷、斷電或與 DASD 和/或 DASD 控制器的通信中斷周期未完成（數(shù)據(jù)過濾進程被中斷，數(shù)據(jù)同步進程被中斷）。數(shù)據(jù)庫指針或關鍵字無效數(shù)據(jù)庫中的數(shù)據(jù)元素無效或遭到破壞測試范圍：技術：應該使用為功能和業(yè)務周期測試創(chuàng)建的測試來創(chuàng)建一系列的事務。一旦達到預期的測試起點，就應該分別執(zhí)行或模擬以下操作：客戶機斷電：關閉 PC 機的電源。服務器斷電：模擬或啟動服務器的斷電過程。通

34、過網絡服務器產生的中斷：模擬或啟動網絡的通信中斷（實際斷開通信線路的連接或關閉網絡服務器或路由器的電源）。DASD 和 DASD 控制器被中斷、斷電或與 DASD 和 DASD 控制器的通信中斷：模擬與一個或多個 DASD控制器或設備的通信，或實際取消這種通信。一旦實現(xiàn)了上述情況（或模擬情況），就應該執(zhí)行其他事務。而且一旦達到第二個測試點狀態(tài)，就應調用恢復過程。在測試不完整的周期時，所使用的技術與上述技術相同，只不過應異常終止或提前終止數(shù)據(jù)庫進程本身。對以下情況的測試需要達到一個已知的數(shù)據(jù)庫狀態(tài)。當破壞若干個數(shù)據(jù)庫字段、指針和關鍵字時，該以手工方式在數(shù)據(jù)庫中（通過數(shù)據(jù)庫工具）直接進行。其他事務

35、應該通過使用“應用程序功能測和“業(yè)務周期測試”中的測試來執(zhí)行，并且應執(zhí)行完整的周期。開始標準：完成標準：在所有上述情況中，應用程序、數(shù)據(jù)庫和系統(tǒng)應該在恢復過程完成時立即返回到一個已知的預期狀態(tài)。此狀態(tài)包括僅限于已知損壞的字段、指針或關鍵字范圍內的數(shù)據(jù)損壞，以及表明進程或事務因中斷面未被完成的報表。測試重點和優(yōu)先級：需考慮的特殊事項：恢復測試會給其他操作帶來許多的麻煩。斷開纜線連接的方法（模擬斷電或通信中斷）可能并不可取或不可行。所以，可能會需要采用其他方法，例如性工具。需要系統(tǒng)（或計算機操作）、數(shù)據(jù)庫和網絡組中的資源。這些測試應該在工作時間之外或在一立的計算機上運行。10.12. 配置測試測試

36、目標核實測試可在所需的硬件和配置中正常運行。測試范圍：技術：使用功能測試。在測試過程中或在測試開始之前，打開各種與非測試對象相關的（例如應用程序：Excel 和 Word），然后將其關閉。執(zhí)行所選的事務，以模擬 Actor 與測試對象非測試對象之間的交互。重復上述步驟，盡量減少客戶機工作站上的常規(guī)可用內存。開始標準：完成標準：對于測試對象非測試對象的各種組合，所有事務都成功完成，沒有出現(xiàn)任何故障。測試重點和優(yōu)先級：需考慮的特殊 事項：需要、可以使用并可以通過桌面哪種非測試對象？通常使用的是哪些應用程序？應用程序正在運行什么數(shù)據(jù)？例如，在 Excel 中打開的大型電子表格，或是在 Word 中打

37、開的 100 頁文檔。作為此測試的一部分，應將整修系統(tǒng)、Netware、網絡服務器、數(shù)據(jù)庫等都下來。10.13. 安裝/反安裝測試10.14. 文檔測試11.測試范圍與測試任務根據(jù)業(yè)務需求和用例，來確定測試項，并確定采用什么測試，并考慮優(yōu)先級測試目標主要檢查文檔的正確性、完備性和可理解性測試范圍：主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主技術：瀏覽開始標準：相關文檔評審完成完成標準：沒有明顯的遺漏、不一致、和描述的確測試重點和優(yōu)先級：文檔內容前后、描述項遺漏需考慮的特殊事項：測試目標核實在以下情況下，測試對象可正確地安裝到各種所需的硬件配置中：首次安裝。以前從未安裝過項

38、目名稱的新計算機更新。以前安裝過相同版本的項目名稱的計算機更新。以前安裝過Project Name的較早版本的計算機安裝后立即正常運行測試范圍：技術：手工開發(fā)或開發(fā)自動，以驗證目標計算機的狀況 首次安裝項目名稱從未安裝過；項目名稱安裝過相同或較早的版本。啟動或執(zhí)行安裝。使用預先確定的功能測試子集來運行事務。開始標準：國息處理系統(tǒng)可以正常運行,配置和設備完成標準：國息處理系統(tǒng)成功執(zhí)行，沒有出現(xiàn)任何故障。測試重點和優(yōu)先級：需考慮的特殊事項：應該選擇項目名稱的哪些事務才能準確地測試出項目名稱應用程序已經成功安裝，而且沒有遺漏主要的構件？。測試是保證產品質量的重要，沒有測試的開發(fā)是不完整的開發(fā)過程。在

39、項目測試過程中，測試組在項目不同階段都定義了相應的任務，包括前期計劃、用例設計到執(zhí)試，充分保證了項目測試的完整性和充分性。國息處理系統(tǒng)項目的測試包括單元測試，集成測試和系統(tǒng)測試三個主要部分，測試活動從 2005-8 月開始執(zhí)行，直至項目生命周期結束。整個測試過程嚴格遵守測試流程規(guī)定，為保證質量實施關鍵活動。測試過程以項目測試為主，盡可能多地發(fā)現(xiàn)系統(tǒng)缺陷，并盡最大可能保證系統(tǒng)的穩(wěn)定性，兼容性，可重復性以和強壯性。測試范圍測試對象程序相關文件需求文檔、安裝手冊、使用手冊11.1.2. 需要測試的產品功能產品使用功能產品安裝產品卸載產品資料庫11.1.3. 不需要測試的產品功能第成熟產品功能被刪除的

40、功能被外包的功能11.1.4. 測試覆蓋功能（用例）覆蓋輸入域覆蓋輸出域覆蓋11.2. 測試任務本次測試主要包括單元測試、集成測試、系統(tǒng)測試。單元測試由開發(fā)互檢為主，測試提供相應的工具，以及測試知識的相關培訓。集成測試和系統(tǒng)測試由開發(fā)同測試聯(lián)合完成，由測試編寫測試計劃，測試方案，測試用例以及測試。測試實施過程需要開發(fā)的參與。制定測試計劃: (測試設計員)制定測試計劃的目的是收集和組織測試計劃信息，并且創(chuàng)建測試計劃。確定測試需求根據(jù)需求工件集收集和組織測試需求信息，確定測試需求。制定測試策略針對測試需求定義測試類型、測試方法以及需要的測試工具等。建立測試通過準則根據(jù)項目實際情況為每一個層次的測試

41、建立通過準則。確定資源和進度確定測試需要的軟硬件資源、人力資源以及測試進度。5. 評審測試計劃根據(jù)評審規(guī)范對測試計劃進行評審設計測試: (測試設計員)設計測試的目的是為每一個測試需求確定測試用例集，并且確定執(zhí)試用例的測試過程。設計測試用例：對每一個測試需求，確定其要的測試用例。對每一個測試用例，確定其輸入及預期結果。確定測試用例的測試環(huán)境配置、需要的驅動界面或穩(wěn)定樁。編寫測試用例文檔開發(fā)測試過程：根據(jù)界面原型為每一個測試用例定義詳細的測試步驟。為每一測試步驟定義詳細的測試結果驗證方法。為測試用例準備輸入數(shù)據(jù)。編寫測試過程文檔。在實施測試時對測試過程進行更改。設計驅動程序或穩(wěn)定樁設計單元測試和集

42、成測試需要的驅動程序和穩(wěn)定樁。實施測試: (開發(fā)和測試)實施測試的目的是創(chuàng)建可重用的測試，并且實施測試驅動程序和穩(wěn)定樁。編寫驅動程序和穩(wěn)定樁根據(jù)設計編寫測試需要的測試驅動程序和穩(wěn)定樁。實施單元測試: (開發(fā)實現(xiàn)的功能。)執(zhí)行單元測試的目的是驗證單元的結構以及單元1.執(zhí)行單元測試按照測試過程手工執(zhí)行單元測試或運單元測試。試自動執(zhí)行2.單元將單元作詳細，并將提交給相關組。3.回歸測試對修改后的單元執(zhí)行回歸測試實施集成測試: (開發(fā)或測試員)執(zhí)行集成測試的目的是驗證單元之間的接口以及集成工作版本的功能、性能等。1.執(zhí)行集成測試按照測試過程手工執(zhí)行集成測試或運集成測試。試自動執(zhí)行2.集成將集成作詳細，

43、并將提交給相關組。3.回歸測試對修改后的工作版本執(zhí)行回歸測試，或者對增量集成后的版本執(zhí)行回歸測試。實施系統(tǒng)測試: (測試)執(zhí)行系統(tǒng)測試的目的是確認系統(tǒng)工作版本滿足需求。1.執(zhí)行系統(tǒng)測試按照測試過程手工執(zhí)行系統(tǒng)測試或運系統(tǒng)測試。試自動執(zhí)行2.系統(tǒng)將系統(tǒng)作詳細，并將提交給相關組。3.回歸測試對修改后的系統(tǒng)版本執(zhí)行回歸測試。11.3. 測試分階段對應不同測試設計項和測試執(zhí)行項，在需求階段主要側重設計功能測試用例（建議按業(yè)務流程和系統(tǒng)功能分類），在設計階段側重設計界面測試用例。而在編碼、或集成階段側重執(zhí)行單元測試和集成測試（建議按系統(tǒng)結構分類）?？筛鶕?jù)需要同步進試用例設計。而文檔測試的執(zhí)行（需求、設計

44、、手冊等）貫穿各個階段，可以不用寫測試用例。測試階段信息項需求階段測試設計項測試策略優(yōu)先級執(zhí)試條件實時扣稅交易功能測試高系統(tǒng)編碼完成實時沖正交易高與商業(yè)對賬高定時批量扣稅交易中定時批量撤銷交易中與對賬中查詢交易狀態(tài)中自繳核銷交易中端繳款交易中連接測試中退庫交易低更正交易低免抵調交易低與 TBS 核對低自繳核銷、退庫、更正、免抵調撤銷低磁盤提入應繳信息低磁盤提出應繳信息低磁盤提入扣款結果低磁盤提出扣款結果低磁盤提入退息低磁盤提入更正信息低磁盤提入免抵調信息低信息高錄入劃撥高手工銷號中上傳入庫明細中上傳收入報表中上傳財政庫存報表中手工錄入低手工錄入退庫低手工復核退庫低手工錄入更正手工復核更正手工銷

45、號退庫手工銷號更正手工銷號更正退息更正信息導出本級 TIPS 數(shù)據(jù)導入TIPS 數(shù)據(jù)導入變更資料系統(tǒng)日切高關鍵業(yè)務管理中角色管理中用戶管理中日志管理中異常管理中測試執(zhí)行項測試策略優(yōu)先級執(zhí)試條件需求文檔測試文檔測試設計階段測試設計項測試策略優(yōu)先級執(zhí)試條件界面操作界面測試關注的性能問題性能測試測試執(zhí)行項測試策略優(yōu)先級執(zhí)試條件界面設計文檔測試文檔測試其他設計文檔測試文檔測試編碼、集成測試設計項測試策略優(yōu)先級執(zhí)試條件12.測試進度測試活動計劃開始日期實際開始日期結束日期制定測試計劃設計測試用例集成測試系統(tǒng)測試性能測試安裝測試用戶驗收測試對測試進行評估產品發(fā)布階段可以不設計或部分設計測試用例單元、集成測

46、試測試執(zhí)行項測試策略優(yōu)先級執(zhí)試條件TIES模擬器接口TISS繳款書錄入收入退還書錄入TIMS系統(tǒng)初始化公共數(shù)據(jù)管理系統(tǒng)運行參數(shù)管理系統(tǒng)系統(tǒng)實現(xiàn)完成階段測試設計項測試策略優(yōu)先級執(zhí)試條件安裝/反安裝測試安裝測試測試執(zhí)行項測試策略優(yōu)先級執(zhí)試條件需求階段的測試設計項設計階段的測試設計項安裝/反安裝測試設計項文檔功能測試性能測試界面測試安裝 / 反安裝測試文檔測試按 測 試 設 計項 優(yōu) 先 級 執(zhí)行13.測試用例編寫方案及相關約定13.1. 編寫原則（1）基本的原則就是：“一點多例”，就是針對一個測試點或者功能點，編寫多個測試用例，從多個方面進（2）單元測試由開發(fā)試。各個部分的用例編寫的都貫穿著這一基

47、本執(zhí)行，可以自身決定是否編寫單元測試用例。（3）對于每個用例事件流，測試需求的詳細列表至少會包括一個測試需求。對于需求規(guī)格說明功能描述，將至少派生一個測試需求。（4） 測試項描述-簡明測試用例所要涉及的項和特性、對于每一項、可考慮以下文件：需求說明書、設計說明書、用戶手冊、操作手冊。（5）輸入說明描述-規(guī)定執(zhí)試用例所需的各個輸入。有些輸入可以用值（允許適當?shù)恼`差）來規(guī)定。而另一些輸入，如常數(shù)表或事務文件可以用名來規(guī)定。規(guī)定所有合適的數(shù)據(jù)庫、文件、終端信息傳送的值。（6）輸出說明描述- 規(guī)定測試項的所有輸出和特性（如：響應時間）。提供各個輸出或特性的正確值。（7）測試用例的設計，始終要考慮測試的

48、執(zhí)行，同時測試發(fā)現(xiàn)可以用來完善測試設計。和總結的經驗也13.2. 衡量測試用例設計的質量標準（1）可測性： 測試用例的所有步驟是可測的，測試的步驟是具體可實施后的，按照每個步驟是可以走通的。可驗證： 測試的每個步驟驗證點是具體、可驗證的。期望結果不是抽象的描述，而是可獲得的。（2）（3）全面性：測試執(zhí)行，無須考慮怎么測、而是參照測試用例設計的步驟執(zhí)行，測試數(shù)據(jù)的準備也要在測試設計時考慮，而且要具備高覆蓋率和全面性。13.3. 測試用例管理通過 TestDirector 來管理和測試用例請參照測試工具使用約定及開發(fā)與測試配合工作規(guī)范中相應描述。13.4. 測試用例與開發(fā)的對應關系約定13.5. 測試用例類型約定測試用例對應測試類型測試覆蓋率（測試）測試覆蓋率（其他）功能測試用例主要包括功能測試、健壯性測試、可靠性測試90%100%性能測試用例性能測試、壓力測試、強度測試10%集成測試用例接口測試、健壯性測試、可靠性測試40%50%50%安全測試用例安全測試10%用戶界面測試用例用戶界面測試、少量功能測試100%80%安裝/反安裝測試用例安裝/反安裝測試100%80%開發(fā)階段依據(jù)文檔編寫的用例需求分析階段結束后需求文檔系統(tǒng)測試對應的用例概要設計階段結束后概要設