測試計劃模板

項目編號：XX系統(tǒng)測試計劃文檔編號：版本信息：建立日期：創(chuàng)建人：審核人：批準人：批準日期：保管人：存放位置：公司LOGO文檔修訂記錄版本號變化狀態(tài)變更內(nèi)容修改日期變更人*變化狀態(tài)：C――創(chuàng)建，A——增加，M——修改，D——刪除文檔審批信息版本號審核人審核日期批準人批準日期備注

目

錄1

概述1.1

目的1.2

假定和約束1.2.1

假設(shè)條件..........1.2.2

約束條件..........1.3

參考資料2

測試需求2.1

產(chǎn)品描述2.2

測試范圍2.3

測試內(nèi)容2.3.1

功能測試..........2.3.2

數(shù)據(jù)和數(shù)據(jù)庫完整性測試2.3.3

接口測試..........2.3.4

功能測試..........2.3.5

用戶界面測試......2.3.6

安全性和訪問控制測試2.3.7

故障轉(zhuǎn)移和恢復(fù)測試2.3.8

性能測試..........2.3.9

系統(tǒng)部署測試......2.4

測試優(yōu)先級3

項目標(biāo)準4

交付工件5

估算5.1

規(guī)模估算5.2

工作量估算6

組織結(jié)構(gòu)和角色6.1

特殊技能要求6.2

角色職責(zé)7

資源計劃7.1

軟件資源7.2

硬件資源7.3

人力資源8

生命周期9

測試策略10

測試進度計劃10.1

里程碑計劃10.2

測試進度計劃11

監(jiān)控計劃11.1

監(jiān)控計劃11.2

評審計劃11.3

項目風(fēng)險12

質(zhì)量保證計劃12.1

質(zhì)量目標(biāo)12.2

過程檢查12.3

產(chǎn)品檢查12.4

質(zhì)量報告13

培訓(xùn)計劃14

度量分析計劃15

附件15.1

缺陷級別定義15.2

再現(xiàn)程度定義15.3

缺陷狀態(tài)定義15.4

測試風(fēng)險評估15.5

附錄1概述1.1目的簡單介紹被測系統(tǒng)以及被測系統(tǒng)的應(yīng)用。1.2假定和約束1.2.1假設(shè)條件1.2.1.1測試人員本次測試開始之前，要求測試人員：已閱讀需求規(guī)格說明書等相關(guān)文檔；熟悉被測系統(tǒng)，能夠獨立進行操作并且完成測試；能夠編寫有效的測試用例；能夠正確描述Bug現(xiàn)象，正確選擇Bug屬性。1.2.1.2測試環(huán)境測試環(huán)境干凈、獨立、穩(wěn)定；測試數(shù)據(jù)足夠且準確、有效；1.2.2約束條件下面是一些可能會導(dǎo)致計劃不準確或影響測試過程的制約條件，這些情況會影響測試進度和測試效果。遇到下列問題，由XX協(xié)商解決。測試數(shù)據(jù)不充分；測試環(huán)境不穩(wěn)定或配置不到位；測試過程中遇到重大阻塞性的問題；軟件的缺陷比較嚴重，直接影響到測試的繼續(xù)進行；開發(fā)人員或測試支持人員支持、配合不到位；另外，需要長時間地進行系統(tǒng)穩(wěn)定性測試，可能導(dǎo)致測試工期延長。1.3參考資料2測試需求2.1產(chǎn)品描述對于測試產(chǎn)品的相關(guān)描述信息。2.2測試范圍系統(tǒng)測試、多操作系統(tǒng)平臺測試（WindwosXP、Windows2000、Windows98）、性能測試（壓力測試、負載測試）、穩(wěn)定性測試、兼容性測試（與windows2000、XP兼容性）、安裝卸載測試和易用性測試。1)單元測試單元測試主要由開發(fā)人員來完成。2)集成測試集成測試的主要目的是檢測系統(tǒng)是否達到需求對業(yè)務(wù)流程及數(shù)據(jù)流的處理是否符合標(biāo)準，檢測系統(tǒng)對業(yè)務(wù)流處理是否存在邏輯不嚴謹及錯誤，檢測需求是否存在不合理的標(biāo)準及要求。此階段測試基于功能完成的測試。測試的內(nèi)容包括單元間的接口以及集成后的功能，本項目采用漸增式集成方式。3)系統(tǒng)測試系統(tǒng)測試是通過與系統(tǒng)的需求規(guī)格作比較，發(fā)現(xiàn)軟件與系統(tǒng)需求規(guī)格不相符合或與之矛盾的地方。它將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合起來，在模擬實際運行（使用）環(huán)境下，對系統(tǒng)進行的測試。2.3測試內(nèi)容

下面列出所有測試點均為測試內(nèi)容，未列出的本次測試不予考慮。2.3.1功能測試詳見《需求功能矩陣.xls》。2.3.2數(shù)據(jù)和數(shù)據(jù)庫完整性測試數(shù)據(jù)庫和數(shù)據(jù)庫進程作為一個子系統(tǒng)來進行測試。在將測試對象的用戶界面用作數(shù)據(jù)的接口的同時，還將考慮對數(shù)據(jù)庫管理系統(tǒng)（DBMS）進行相關(guān)的存儲測試。測試目標(biāo)：方法：完成標(biāo)準：需考慮的特殊事項：2.3.3接口測試由于XX其它系統(tǒng)協(xié)同工作，所以系統(tǒng)在實際工作中會調(diào)中其它系統(tǒng)，同時系統(tǒng)內(nèi)部功能模塊的調(diào)用。測試目標(biāo)：方法：完成標(biāo)準：需考慮的特殊事項：2.3.4功能測試試對象的功能測試側(cè)重于可以被直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的所有測試需求。這些測試的目標(biāo)在于核實能否正確地接受、處理和檢索數(shù)據(jù)以及業(yè)務(wù)規(guī)則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面(GUI)與應(yīng)用程序交互并分析輸出結(jié)果來驗證應(yīng)用程序及其內(nèi)部進程。以下列出的本系統(tǒng)的測試方法概要：測試目標(biāo)：方法：完成標(biāo)準：需考慮的特殊事項：2.3.5用戶界面測試通過用戶界面(UI)測試來核實用戶與軟件的交互。UI測試的目標(biāo)在于確保用戶界面向用戶提供了適當(dāng)?shù)脑L問和瀏覽測試對象功能的操作。測試目標(biāo)：方法：完成標(biāo)準：需考慮的特殊事項：2.3.6安全性和訪問控制測試由于題庫管理系統(tǒng)主要用于組織統(tǒng)考或入學(xué)測試，對于安全性要求較高。對于整個系統(tǒng)，需要完整的權(quán)限控制，防止某些人惡意的攻擊系統(tǒng)，修改原始記錄。同時對于數(shù)據(jù)庫中的數(shù)據(jù)需要定時備份，防止系統(tǒng)數(shù)據(jù)丟失。此外，系統(tǒng)要求用戶在登陸時需要身份驗證，嚴格區(qū)分每個角色的使用權(quán)限,安全性的訪問控制測試主要集中在對用戶權(quán)限管理測試模塊中。2.3.7故障轉(zhuǎn)移和恢復(fù)測試出現(xiàn)故障時及時方便地找到產(chǎn)生故障的原因和位置，并能方便地進行局部修改。具有對于系統(tǒng)數(shù)據(jù)丟失的補救措施，保證系統(tǒng)的安全性，可靠性。此項測試主要集中在數(shù)據(jù)備份\恢復(fù)功能模塊中。2.3.8性能測試采用測試工具LoadRunner進行測試，測試包括：負載測試、強度測試和穩(wěn)定性測試。找出系統(tǒng)瓶頸，并進行優(yōu)化，但系統(tǒng)能達到，要求XX個用戶并發(fā)情況下，響應(yīng)時間小于等于15秒。系統(tǒng)支持最高XX個并發(fā)，在XXM帶寬下，支持XX左右用戶的同時訪問。2.3.9系統(tǒng)部署測試系統(tǒng)開發(fā)測試完畢后，進行系統(tǒng)部署測試，確保系統(tǒng)的正常運行。測試目標(biāo)：方法：完成標(biāo)準：需考慮的特殊事項：2.4測試優(yōu)先級測試類型優(yōu)先級說明3項目標(biāo)準達到本次系統(tǒng)測試預(yù)定的質(zhì)量標(biāo)準：不允許出現(xiàn)“致命”BUG和“嚴重”BUG；一般“BUG”不超過6個；可以出現(xiàn)微小級別的BUG不超過10個；功能點覆蓋率務(wù)必達到100%；無易用性問題。4交付工件

過程工作產(chǎn)品5估算5.1規(guī)模估算測試用例數(shù)：XX條說明：根據(jù)《題庫子系統(tǒng)功能列表.doc》功能范圍說明：這次開發(fā)所要實現(xiàn)22個功能點。加上故障轉(zhuǎn)移和恢復(fù)測試、系統(tǒng)部署測試、數(shù)據(jù)和數(shù)據(jù)庫完整性測試和安全性和訪問控制測試?？偣惨M行測試的功能點為XX個。每個功能點平均用例數(shù)在XX條左右，一個功能點包涵，功能測試、流程測試和性能測試三部，此外，還要在WindwosXP、Windows2000、Windows98三個平臺上進行測試。因此，測試用例數(shù)=XX條：此外三個平臺測試用例可以重用，因此實際用例數(shù)為XX條，執(zhí)行用例數(shù)為：XX條；此外測試用例數(shù)跟著需求變更，做出相應(yīng)調(diào)整。最終用例數(shù)，以最終需求為準。1.1工作量估算

測試工作量：（待定）人月。2組織結(jié)構(gòu)和角色2.1特殊技能要求項目中要用到熟練使用自動化測試工具、熟悉在線考務(wù)系統(tǒng)經(jīng)驗的人。2.2角色職責(zé)角色職責(zé)描述姓名聯(lián)系方式測試PM?批準測試計劃、配置管理計劃、質(zhì)量保證計劃?確定測試用例、確定測試用例的優(yōu)先級并實施測試用例。?制定和修改項目的組織結(jié)構(gòu)和配置管理策略；?負責(zé)管理項目成員嚴格按照測試計劃進行測試。Tester?編寫測試用例。?開發(fā)自動化測試腳本。?執(zhí)行測試。CM?負責(zé)編寫和維護《配置管理計劃》；?負責(zé)配置庫的建議和維護；?負責(zé)配置項的建立和維護；?負責(zé)配置庫權(quán)限的分配；?軟件配置管理工具的日常管理與維護；?負責(zé)基線的標(biāo)識及發(fā)布；?負責(zé)開發(fā)人員軟件配置管理方面的培訓(xùn)工作；?上報配置狀態(tài)報告。Developer?測試支持工作?修改bug3資源計劃3.1軟件資源軟件資源版本獲取方式與時間使用說明3.2硬件資源硬件資源配置獲取方式與時間使用說明3.3人力資源測試周期為XX年XX月XX日－XX年XX月XX日；測試人員每日工作時間為9:00－18:00，每周工作五天；測試人員正常每天的工作時間平均8小時。封閉開發(fā)期間每天的工作時間13小時4生命周期生命周期模型：V模型。原因：本項目的需求明確、理解充分，并且較為穩(wěn)定，由于工期比較緊，確保測試能按時完成，測試在開發(fā)工作的始執(zhí)行。需求階段進行測試準備工作。5測試策略下面是本測試各執(zhí)行階段的主要活動預(yù)計的流程圖開發(fā)必要的測試工具準備測試數(shù)據(jù)填寫《需求功能矩陣》編寫測試報告獲取測試需求編寫測試報告測試評估本次測試只做系統(tǒng)測試。主要是以手工和自動化工具相結(jié)合的方式測試系統(tǒng)在基本功能和性能方面符合需求規(guī)格說明書和用戶普遍期望的程度。找出系統(tǒng)在功能和性能方面與需求不符合的地方。關(guān)于功能測試的測試用例，請參見測試用例文檔《題庫管理系統(tǒng)測試用例》；6測試進度計劃6.1里程碑計劃里程碑名稱時間6.2測試進度計劃7監(jiān)控計劃7.1監(jiān)控計劃?項目組成員每天填寫工作日志，項目經(jīng)理根據(jù)項目組成員提交的日志匯總成項目日報；?項目每周召開一次項目例會。每周提交《項目周報》。?根據(jù)不同的時機項目經(jīng)理召集項目組成員召開會議，通報階段性工作情況及下階段計劃安排7.2評審計劃評審對象評審時機評審方式評審參加人評審確認人7.3項目風(fēng)險8質(zhì)量保證計劃8.1質(zhì)量目標(biāo)文檔錯誤率文檔名稱錯誤數(shù)測試用例目標(biāo)測試用例密度覆蓋率目標(biāo)測試階段覆蓋率BUG率目標(biāo)測試階段Bug摘出目標(biāo)8.2過程檢查過程檢查時機檢查要點需求獲取測試設(shè)計測試執(zhí)行測試評估測試總結(jié)8.3產(chǎn)品檢查工作產(chǎn)品檢查時機檢查要點需求跟蹤矩陣測試計劃測試用例缺陷報告測試報告8.4質(zhì)量報告9培訓(xùn)計劃10度量分析計劃11附件11.1缺陷級別定義致命BUG：直接發(fā)生導(dǎo)致系統(tǒng)死機、藍屏、響應(yīng)時間過長、主要功能沒有實現(xiàn)、重大的阻塞性的問題（即：后續(xù)依賴此操作的其他重要操作無法進行）。嚴重BUG：程序發(fā)生錯誤，但不影響系統(tǒng)和其它程序運行的，次要功能沒有實現(xiàn)或間接發(fā)生的（經(jīng)過幾步不相關(guān)操作后發(fā)生的）導(dǎo)致主要需求不能實現(xiàn)，包括主要界面的文字錯誤等。一般BUG：間接發(fā)生的（經(jīng)過幾步不相關(guān)操作后發(fā)生的）導(dǎo)致次要需求不能正常實現(xiàn)。微小BUG：不影響軟件的功能，但影響軟件的品質(zhì)。11.2再現(xiàn)程度定義每次出現(xiàn)：出現(xiàn)概率100%經(jīng)常出現(xiàn)：出現(xiàn)概率大于20%很少出現(xiàn)：出現(xiàn)概率小于20%出現(xiàn)一次：在整個測試工作中只出現(xiàn)一次11.3缺陷狀態(tài)定義待修復(fù)：測試人員發(fā)現(xiàn)的，開發(fā)人員還沒有修復(fù)的缺陷待驗證：開發(fā)人員已經(jīng)修改，測試人員還沒有驗證的缺陷已解決：已經(jīng)修復(fù)的缺陷遺留：經(jīng)評審后認定在本版本中可以不修改的缺陷11.4測試風(fēng)險評估根據(jù)項目測試任務(wù)量大，測試時間緊張的特點，以下列出項目測試中可能存在的風(fēng)險：在執(zhí)行測試過程中由于測試人員的離職或請假，導(dǎo)致測試周期的延長；測試過程中非人為因素的測試用例的丟失（數(shù)據(jù)備份失效、病毒攻擊等），導(dǎo)致執(zhí)行測試周期延長；，測試數(shù)據(jù)設(shè)計覆蓋率未達到相應(yīng)的及別，再次整理測試數(shù)據(jù)導(dǎo)致測試時間延長；針對以上可能存在的風(fēng)險，采取的措施為：部門備有項目測試機動人員，確保項目測試過程中不會因測試人員的缺崗而導(dǎo)致測試周期的延長；在測試過程中，由專人負責(zé)項目配置，以防止非人為因素造成的測試用例丟失；為項目測試配備資深的測試人員，確保測試數(shù)據(jù)的高覆蓋率11.5附錄以下是一些與測試有關(guān)的任務(wù)：

?

制定測試計劃-

確定測試需求