- 相關推薦
軟件測試工作計劃
軟件測試工作計劃：軟件測試計劃模板
第1章 引言
1.1目的
簡述本計劃的目的，旨在說明各種測試階段任務、人員分配和時間安排、工作規(guī)范等。
測試計劃在策略和方法的高度說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。另外，清晰的文檔結(jié)構能使任何一個讀者在瀏覽計劃的前面幾頁后，就能對項目有一個大概的認識。測試計劃只是測試的一個框架，很多細節(jié)需要跟開發(fā)人員或其他人員溝通，因此計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。在計劃目的中需要指明讀者對象。
1.2名詞解釋
列出本計劃中使用的專用術語及其定義
列出本計劃中使用的全部縮略語全稱及其定義
|
縮寫 詞或術語
|
英文解釋
|
中文解釋
|
|
|
|
|
|
|
|
|
1.3參考資料
列出本計劃各處參考的經(jīng)過核準的全部文檔和主要文獻。
1.4測試摘要
這一節(jié)主要說明測試計劃中重要的和可能有爭議的問題。本節(jié)的主要目的是將這些信息傳遞給那些可能不會通讀整個測試計劃文檔的人員(比如經(jīng)理或開發(fā)項目的負責人)。
1.4.1 重點事項
列出測試的重點事項。可以將問題按重要程度和優(yōu)先級羅列出來，然后在后面的章節(jié)中再對這些問題進行詳細說明，這樣就能讓對這些問題有重要影響的人員知道問題的所在
1.4.2 爭議事項
簡要說明爭議事項。
1.4.3 風險評估
通過對技術文檔的閱讀，對被測系統(tǒng)可能存在的問題：系統(tǒng)設計，數(shù)據(jù)庫設計，響應時間，計費策略，因測試環(huán)境不足可能存在的測試缺陷事先評估出來，以指導測試方案，進行有重點的測試.
1.4.4 時間進度
簡要說明測試開始時間與發(fā)布時間。
1.4.5 測試目標
簡要說明測試發(fā)布的質(zhì)量目標：
測試計劃中所有測試方法和模塊已經(jīng)執(zhí)行通過
所有的測試案例已經(jīng)執(zhí)行過
所有的重要等級為1/2的Bug已經(jīng)解決并由測試驗證
第2章 項目背景
2.1測試范圍
說明本計劃涵蓋的測試范圍，比如功能測試、集成測試、系統(tǒng)測試、驗收測試等。通常說明什么是要測試的，什么是不要測試的是非常重要的。明確規(guī)定這些問題后，測試人員對該做什么有一個清晰的認識。
(1)簡要地列出測試對象中將接受測試或?qū)⒉唤邮軠y試的那些性能和功能。
(2)如果在編寫此文檔的過程中作出的某些假設可能會影響測試設計、開發(fā)或?qū)嵤瑒t列出所有這些假設。
(3)列出可能會影響測試設計、開發(fā)或?qū)嵤┑乃酗L險或意外事件。
(4)列出可能會影響測試設計、開發(fā)或?qū)嵤┑乃屑s束。
提示和技巧：
需要測試和特別注意測試那些部分?
測試是否專么針對與某些問題的解決?
哪些部分不需要測試，為什么?
哪些部分需要推遲測試,為什么?
是否要驗證每個模塊的穩(wěn)定性?
測試的優(yōu)先級和先后順序
2.2測試目標
系統(tǒng)目標對測試人員了解自己需要做什么是非常重要的。測試項目負責人應積極與系統(tǒng)設計人員或開發(fā)人員溝通，以取得相關資料。測試人員必須知道系統(tǒng)是做什么并且?guī)椭椖繉崿F(xiàn)這種目標。在計劃中包括系統(tǒng)視圖和目標后，要確保所有的測試人員都知道項目和系統(tǒng)的目標。
通常情況下項目計劃都是模糊的。模糊的目標必須通過成員的努力轉(zhuǎn)換成可衡量和實現(xiàn)的東西。沒有固定的視圖和目標，你將無法完成部分任務。而且，你會發(fā)現(xiàn)很難將對產(chǎn)品的認識向別人轉(zhuǎn)述。
2.3聯(lián)系方式
列出項目參與人員的職務、姓名、E-mail 和電話。
|
職務
|
姓名
|
E-Mail
|
電話
|
|
開發(fā)工程師
|
|
|
|
|
CVS Builder
|
|
|
|
|
開發(fā)經(jīng)理
|
|
|
|
|
測試負責人
|
|
|
|
|
測試人員
|
|
|
|
2.4風險及約束
列出測試過程中可能存在的一些風險和制約因素，并給出規(guī)避方案。如：
由于客觀存在的設備、網(wǎng)絡等資源原因，使得測試不全面。明確說明哪些資源欠缺，產(chǎn)生什么約束
由于研發(fā)模式為現(xiàn)場定制，且上線時間壓力大，使得測試不充分。明確說明在此中約束下，測試如何應對
只針對專門的客戶群需求的測試。明確說明此約束下的客戶群和業(yè)務范圍。
2.5測試文檔
列出測試過程中可能用到的參考文檔、相關的設計文檔以及保存位置，測試完成后應產(chǎn)生的文檔。
2.5.1測試參考文檔
|
文檔說明
|
作者
|
文檔位置（CVS）
|
|
需求文檔
|
|
|
|
總體設計
|
|
|
|
白皮書
|
|
|
|
使用手冊
|
|
|
|
管理手冊
|
|
|
|
測試文檔
|
|
|
|
API文檔
|
|
|
|
|
|
|
2.5.2測試提交文檔
|
文檔說明
|
作者
|
文檔位置（CVS）
|
|
《總體測試計劃》
|
|
|
|
《總體測試方案》（可根據(jù)項目情況進行裁剪）
|
|
|
|
測試用例
|
|
|
|
《性能測試方案（報告）》
|
|
|
|
《測試報告》
|
|
|
|
《Readme》
|
|
|
|
《產(chǎn)品操作手冊(后臺)》
|
|
|
|
《產(chǎn)品操作手冊(前臺)》
|
|
|
|
《產(chǎn)品安裝維護手冊》
|
|
|
|
《產(chǎn)品錯誤代碼說明文檔》
|
|
|
第3章質(zhì)量目標
描述本階段測試目標和要求。質(zhì)量目標應該包括產(chǎn)品的質(zhì)量目標和測試小組的質(zhì)量目標。
質(zhì)量不僅是衡量系統(tǒng)的功能或性能是否正常。對系統(tǒng)來說，在開發(fā)過程中盡早建立全面的質(zhì)量標準與系統(tǒng)的及時發(fā)布是一樣重要的。質(zhì)量目標是一個強有力的工具，應該在系統(tǒng)開發(fā)過程中盡早建立。一個定義準確的質(zhì)量目標在以后的產(chǎn)品開發(fā)過程中幫助決策。例如，系統(tǒng)是否能夠正式發(fā)行?在代碼完成后，應該修復那些缺陷?在系統(tǒng)完成后那種類型的測試是最合適的?
3.1產(chǎn)品質(zhì)量目標
可以是產(chǎn)品的質(zhì)量達到什么樣的目標，產(chǎn)品的流程聯(lián)通性達到什么樣的要求。
|
測試質(zhì)量目標
|
確認者（如需說明）
|
|
測試已實現(xiàn)的產(chǎn)品是否達到設計的要求，包括：各個功能點是否以實現(xiàn)，業(yè)務流程是否正確
|
|
|
產(chǎn)品規(guī)定的操作和運行穩(wěn)定
|
|
3.2測試質(zhì)量目標
評價測試質(zhì)量的目標可以有：
|
測試質(zhì)量目標
|
確認者（如需說明）
|
|
所有的測試案例已經(jīng)執(zhí)行過
|
|
|
所有的自動測試腳本已經(jīng)執(zhí)行通過
|
|
|
所有的重要等級為1/2的Bug已經(jīng)解決并由測試驗證
|
|
|
每一部分的測試已經(jīng)被Test Lead確認完成
|
|
|
重要的功能不允許有等級為1/2/3的Bug
|
|
|
一般的功能或與最終使用者不直接聯(lián)系的功能不允許有等級為1/2的bug,且bug等級為3的問題不得超過1/功能
|
|
|
輕量的功能允許有少量2/3等級的錯誤
|
|
|
發(fā)現(xiàn)錯誤等級為1/2/3的Bug的速率正在下降并接近0
|
|
|
在最后的三天內(nèi)沒有發(fā)現(xiàn)錯誤等級為1/2/3類的Bug
|
|
第4章 資源需求
4.1培訓資料
|
培訓需求
|
培訓內(nèi)容
|
培訓人員
|
開始時間
|
完成時間
|
|
業(yè)務流程
|
|
|
|
|
|
安裝配置
|
|
|
|
|
|
工具使用
|
|
|
|
|
4.2測試環(huán)境
4.2.1硬件測試環(huán)境
描述建立測試環(huán)境所需要的設備、用途及軟件部署計劃。
“機型(配置)”：此處說明所需設備的機型要求以及內(nèi)存、CPU、硬盤大小的最低要求。
“用途及特殊說明”：此設備的用途，如數(shù)據(jù)庫服務器，web服務器，后臺開發(fā)等;如有特殊約束，如開放外部端口，封閉某端口，進行性能測試等，也寫在此列;
“軟件及版本”：詳細說明每臺設備上部署的自開發(fā)和第三方軟件的名稱和版本號，以便系統(tǒng)管理員按照此計劃分配測試資源;
“預計空間”：說明第三方軟件和應用程序的預計空間;
“環(huán)境約束說明”：建立此環(huán)境時的特殊約束。如需要開發(fā)外部訪問端口，需要進行性能測試等。
|
平臺1：SUN
|
|||||
|
機型（配置）
|
IP地址
|
操作系統(tǒng)
|
用途及特殊說明
|
軟件及版本
|
預計空間
|
|
SUN450
|
10.1.1.1
|
|
|
oracle8.1.2
|
2G
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平臺2：IBM
|
|||||
|
機型
|
IP地址
|
操作系統(tǒng)
|
用途
|
第三方軟件及版本
|
預計空間
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.2軟件測試環(huán)境
|
軟件需求
|
用途
|
|
|
|
4.3測試工具
此項目將列出測試使用的工具以及用途：
|
測試工具
|
用途
|
|
自動測試工具
|
|
第5章 測試策略
5.1 整體測試策略
本節(jié)的目的是說明計劃中使用的基本的測試過程。
使用里程碑技術在測試過程中驗證每個模塊，測試人員在需求階段參與測試工作，進行需求review、設計review、測試案例設計和測試開發(fā)，在系統(tǒng)開發(fā)完成之后，正式執(zhí)行測試。產(chǎn)品達到軟件產(chǎn)品質(zhì)量要求和測試要求后發(fā)布，并提交相關的測試文檔。
5.2開始/中斷/完成標準
說明中斷/開始/完成測試的標準。
|
開始/中斷/完成測試
|
標準說明
|
|
開始測試標準
|
硬件環(huán)境可用且軟件正確安裝完成
|
|
中斷測試標準
|
安裝無法正確完成或程序的文檔有相當多的失誤或系統(tǒng)服務異�；虬l(fā)現(xiàn)Block Bug
|
|
完成測試標準
|
完成測試計劃中的測試規(guī)劃并達到程序和測試質(zhì)量目標,并由Test Lead/R&D Manager確認
|
5.3測試類型
|
測試類型
|
是否采用
|
說明
|
|
功能測試
|
采用
|
根據(jù)系統(tǒng)需求文檔和設計文檔，檢查產(chǎn)品是否正確實現(xiàn)了功能。
|
|
流程測試
|
采用
|
按操作流程進行的測試，主要有業(yè)務流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查軟件在按流程操作時是否能夠正確處理
|
|
邊界值測試
|
采用
|
選擇邊界數(shù)據(jù)進行測試，確保系統(tǒng)功能正常，程序無異常。
|
|
容錯性測試
|
采用
|
檢查系統(tǒng)的容錯能力，錯誤的數(shù)據(jù)輸入不會對功能和系統(tǒng)產(chǎn)生非正常的影響，且程序?qū)﹀e誤的輸入有正確的提示信息
|
|
異常測試
|
采用
|
檢查系統(tǒng)能否處理異常
|
|
啟動停止測試
|
采用
|
檢查每個模塊能否正常啟動停止、異常停止后能否正常啟動
|
|
安裝測試
|
采用
|
檢查系統(tǒng)能否正確安裝、配置
|
|
易用性測試
|
采用
|
檢查系統(tǒng)是否易用友好
|
|
界面測試
|
采用
|
檢查界面是否美觀合理
|
|
接口測試
|
采用
|
檢查系統(tǒng)能否與外部接口正常工作
|
|
配置測試
|
采用
|
檢查配置是否合理、配置是否正常
|
|
安全性和訪問控制測試
|
采用
|
應用程序級別的安全性：檢查Actor只能訪問其所屬用戶類型已被授權訪問的那些功能或數(shù)據(jù)。
系統(tǒng)級別的安全性：檢查只有具備系統(tǒng)和應用程序訪問權限的Actor才能訪問系統(tǒng)和應用程序。
|
|
性能測試
|
采用
|
提取系統(tǒng)性能數(shù)據(jù)，檢查系統(tǒng)是否滿足在需求中所規(guī)定達到的性能。
|
|
壓力測試
|
采用
|
檢查系統(tǒng)能否承受大壓力，測試產(chǎn)品應該能夠在高強度條件下正常運行，不會出現(xiàn)任何錯誤。
|
|
兼容性測試
|
采用
|
對于 C/S 架構的系統(tǒng)來說，需要考慮客戶端支持的系統(tǒng)平臺。
對于 B/S 架構的系統(tǒng)來說需要考慮用戶端瀏覽器的版本。
|
|
割接/升級測試
|
采用
|
進行專門的割接測試或升級測試，提供工程升級割接方案
|
|
文擋測試
|
采用
|
檢查文檔是否足夠、描述是否合理
|
|
回歸測試
|
采用
|
檢查程序修改后有沒有引起新的錯誤、是否能夠正常工作以及能否滿足系統(tǒng)的需求
|
5.4 測試技術
|
測試技術
|
是否采用
|
說明
|
|
里程碑技術
|
采用
|
里程碑的達成標準及驗收方法在測試完后制訂
|
|
自動測試技術
|
采用
|
核心業(yè)務流程采用自動測試技術
|
|
審評測試
|
采用
|
對軟件產(chǎn)品功能說明文檔和設計說明文檔進行檢查，在需求與設計階段進行
|
|
編寫測試用例
|
采用
|
在產(chǎn)品編碼階段編寫測試用例
|
|
單元測試
|
不采用
|
由開發(fā)人員進行
|
|
集成測試
|
采用
|
檢測模塊集成后的系統(tǒng)是否達到需求對業(yè)務流程及數(shù)據(jù)流的處理是否符合標準、系統(tǒng)對業(yè)務流處理是否存在邏輯不嚴謹及錯誤以及是否存在不合理的標準及要求。
|
|
確認測試
|
采用
|
在產(chǎn)品發(fā)布前，對照feature list 進行基本需求的確認，確認產(chǎn)品是否正確實現(xiàn)了功能。
|
|
系統(tǒng)測試
|
采用
|
包括性能測試、壓力測試和回歸測試
|
|
驗收測試
|
不采用
|
由工程實施人員進行
|
第6章 測試計劃
6.1進度計劃
在此章節(jié)，對各階段的測試給出里程碑計劃，包括階段、里程碑、資源等。
6.1.1測試時間進度
|
測試階段
|
開始時間
|
完成時間
|
測試人員
|
階段完成標志
|
|
制定測試計劃
|
|
|
|
|
|
需求Review
|
|
|
|
|
|
設計Review
|
|
|
|
|
|
設計測試用例
|
|
|
|
|
|
測試開發(fā)
|
|
|
|
|
|
測試環(huán)境準備
|
|
|
|
|
|
測試實施
|
|
|
|
|
|
功能測試
|
|
|
|
|
|
集成測試
|
|
|
|
|
|
性能測試
|
|
|
|
|
|
系統(tǒng)測試
|
|
|
|
|
|
驗收測試
|
|
|
|
|
|
文檔編寫
|
|
|
|
|
6.1.2測試里程碑
|
里程碑
|
完成時間
|
完成標準
|
|
測試正式開始
|
|
完成可接受性測試和煙霧測試
|
|
進行CVS LOCK
|
進行cvs lock
|
完成所有里程碑測試和標準測試,測試種類包括確認測試和系統(tǒng)測試,且所有以發(fā)現(xiàn)的Bug等級為1/2/3的Bug已修復,近期內(nèi)無發(fā)現(xiàn)新的Bug等級為1/2/3的Bug
|
|
產(chǎn)品Release
|
|
重復進行主路徑測試和進行Bug檢查測試,產(chǎn)品處于可交付狀態(tài)并由測試經(jīng)理和高級經(jīng)理確認
|
6.2測試準備
6.2.1 測試環(huán)境準備
|
準備事項
|
開始時間
|
完成時間
|
測試人員
|
階段完成標志
|
|
測試環(huán)境準備
|
|
|
|
|
6.2.2 安裝測試
|
準備事項
|
開始時間
|
完成時間
|
測試人員
|
階段完成標志
|
|
安裝測試
|
|
|
|
|
6.2.3 煙霧測試
|
準備事項
|
開始時間
|
完成時間
|
測試人員
|
階段完成標志
|
|
煙霧測試
|
|
|
|
|
6.3 具體測試實施任務和時間人員安排
|
測試功能點
|
開始時間
|
完成時間
|
測試人員
|
說明
|
|
|
|
|
|
|
【軟件測試工作計劃】相關文章：
軟件測試方法概述10-26
軟件測試專業(yè)簡歷10-07
軟件測試實習報告11-25
軟件測試的實習報告05-19
測試軟件安全的方法10-05
軟件測試就業(yè)方向10-05
軟件測試簡歷模板10-06
軟件測試學習總結(jié)11-23
軟件測試的實習報告10-05
軟件測試個人總結(jié)07-22