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