第1章引言
1.1目的
本測試計劃文件作為指導此測試專案循序漸進的基礎，幫助我們安排合適的資源和進度，避免可能的風險。本文件有助於實現以下目標：
1) 確定現有專案的資訊和應測試的軟體結構。
2) 列出推薦的測試需求
3) 推薦可採用的測試策略，並對這些策略加以詳細說明
4) 確定所需的資源，並對測試的工作量進行估計。
5) 列出測試專案的可交付元素，包括用例以及測試報告等。
1.2名詞解釋
|
縮寫詞或術語 |
英文解釋 |
中文解釋 |
|
Debug |
debug |
漏洞 |
1.3測試摘要
1.3.1 重點事項
l 測試軟體執行情況是否正常
l 測試軟體功能的準確性
l 測試軟體的效能得分
1.3.2 時間進度
在軟體開發出之後開始測試，大約測試半周的時間。
1.3.3 測試目標
測試計劃中所有測試方法和模組能執行通過
所有的測試案例能執行過
所有的重要等級為1/2的Bug能解決並由測試驗證
第2章專案背景
2.1測試範圍
（1）手機系統出現問題的情況不去測試。
（2）名單的檔案大小會影響軟體的載入速度。
（3）手機突然關機會影響載入檔案的資料。
2.2測試目標
測試計劃中所有測試方法和模組能執行通過
所有的測試案例能執行過
所有的重要等級為1/2的Bug能解決並由測試驗證
2.3聯絡方式
|
職務 |
姓名 |
|
開發工程師 |
張昊 |
|
CVS Builder |
曹金鈺 |
|
開發經理 |
郭翠 |
|
測試負責人 |
王建斌 |
2.4風險及約束
l 手機系統出現問題的情況不去測試。
l 名單的檔案大小會影響軟體的載入速度。
l 手機突然關機會影響載入檔案的資料。
2.5測試文件
2.5.1測試參考文件
|
文件說明 |
作者 |
|
需求文件 |
張昊 |
|
總體設計 |
張昊 |
|
白皮書 |
王建斌 |
|
使用手冊 |
王建斌 |
|
管理手冊 |
曹金鈺 |
|
測試文件 |
曹金鈺 |
|
API文件 |
郭翠 |
2.5.2測試提交文件
|
文件說明 |
作者 |
|
《總體測試計劃》 |
張昊 |
|
《總體測試方案》（可根據專案情況進行裁剪） |
張昊 |
|
測試用例 |
王建斌 |
|
《效能測試方案（報告）》 |
王建斌 |
|
《測試報告》 |
曹金鈺 |
|
《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 整體測試策略
用Junit進行測試，將測試結果寫到測試文件裡。
4.2開始/中斷/完成標準
說明中斷/開始/完成測試的標準。
|
開始/中斷/完成測試 |
標準說明 |
|
開始測試標準 |
硬體環境可用且軟體正確安裝完成 |
|
中斷測試標準 |
安裝無法正確完成或程式的文件有相當多的失誤或系統服務異常或發現Block Bug |
|
完成測試標準 |
完成測試計劃中的測試規劃並達到程式和測試質量目標,並由Test Lead/R&D Manager確認 |
4.3測試型別
|
測試型別 |
是否採用 |
說明 |
|
功能測試 |
採用 |
根據系統需求文件和設計文件，檢查產品是否正確實現了功能。 |
|
流程測試 |
採用 |
按操作流程進行的測試，主要有業務流程、資料流程、邏輯流程、正反流程，檢查軟體在按流程操作時是否能夠正確處理 |
|
邊界值測試 |
採用 |
選擇邊界資料進行測試，確保系統功能正常，程式無異常。 |
|
容錯性測試 |
採用 |
檢查系統的容錯能力，錯誤的資料輸入不會對功能和系統產生非正常的影響，且程式對錯誤的輸入有正確的提示資訊 |
|
異常測試 |
採用 |
檢查系統能否處理異常 |
|
啟動停止測試 |
採用 |
檢查每個模組能否正常啟動停止、異常停止後能否正常啟動 |
|
安裝測試 |
採用 |
檢查系統能否正確安裝、配置 |
|
易用性測試 |
採用 |
檢查系統是否易用友好 |
|
介面測試 |
採用 |
檢查介面是否美觀合理 |
|
介面測試 |
採用 |
檢查系統能否與外部介面正常工作 |
|
配置測試 |
採用 |
檢查配置是否合理、配置是否正常 |
|
安全性和訪問控制測試 |
採用 |
應用程式級別的安全性：檢查Actor只能訪問其所屬使用者型別已被授權訪問的那些功能或資料。 系統級別的安全性：檢查只有具備系統和應用程式訪問許可權的Actor才能訪問系統和應用程式。 |
|
效能測試 |
採用 |
提取系統效能資料，檢查系統是否滿足在需求中所規定達到的效能。 |
|
壓力測試 |
採用 |
檢查系統能否承受大壓力，測試產品應該能夠在高強度條件下正常執行，不會出現任何錯誤。 |
|
相容性測試 |
採用 |
對於 C/S 架構的系統來說，需要考慮客戶端支援的系統平臺。 對於 B/S 架構的系統來說需要考慮使用者端瀏覽器的版本。 |
|
割接/升級測試 |
採用 |
進行專門的割接測試或升級測試，提供工程升級割接方案 |
|
文擋測試 |
採用 |
檢查文件是否足夠、描述是否合理 |
|
迴歸測試 |
採用 |
檢查程式修改後有沒有引起新的錯誤、是否能夠正常工作以及能否滿足系統的需求 |
4.4 測試技術
|
測試技術 |
是否採用 |
說明 |
|
里程碑技術 |
採用 |
里程碑的達成標準及驗收方法在測試完後製訂 |
|
自動測試技術 |
採用 |
核心業務流程採用自動測試技術 |
|
審評測試 |
採用 |
對軟體產品功能說明文件和設計說明文件進行檢查，在需求與設計階段進行 |
|
編寫測試用例 |
採用 |
在產品編碼階段編寫測試用例 |
|
單元測試 |
不採用 |
由開發人員進行 |
|
整合測試 |
採用 |
檢測模組整合後的系統是否達到需求對業務流程及資料流的處理是否符合標準、系統對業務流處理是否存在邏輯不嚴謹及錯誤以及是否存在不合理的標準及要求。 |
|
確認測試 |
採用 |
在產品釋出前，對照feature list 進行基本需求的確認，確認產品是否正確實現了功能。 |
|
系統測試 |
採用 |
包括效能測試、壓力測試和迴歸測試 |
|
驗收測試 |
不採用 |
由工程實施人員進行 |
第5章測試計劃
5.1進度計劃
在此章節，對各階段的測試給出里程碑計劃，包括階段、里程碑、資源等。
5.1.1測試時間進度
|
測試階段 |
開始時間 |
完成時間 |
測試人員 |
|
制定測試計劃 |
6月2日 |
6月10日 |
張昊 |
|
需求Review |
6月2日 |
6月10日 |
張昊 |
|
設計Review |
6月2日 |
6月10日 |
張昊 |
|
設計測試用例 |
6月2日 |
6月10日 |
張昊 |
|
測試開發 |
6月2日 |
6月10日 |
張昊 |
|
測試環境準備 |
6月2日 |
6月10日 |
張昊 |
|
測試實施 |
6月2日 |
6月10日 |
張昊 |
|
功能測試 |
6月2日 |
6月10日 |
張昊 |
|
整合測試 |
6月2日 |
6月10日 |
張昊 |
|
效能測試 |
6月2日 |
6月10日 |
張昊 |
|
系統測試 |
6月2日 |
6月10日 |
張昊 |
|
驗收測試 |
6月2日 |
6月10日 |
張昊 |
|
文件編寫 |
6月2日 |
6月10日 |
張昊 |
5.1.2測試里程碑
|
里程碑 |
完成時間 |
完成標準 |
|
測試正式開始 |
6月2日 |
完成可接受性測試和煙霧測試 |
|
進行CVS LOCK |
進行cvs lock |
完成所有里程碑測試和標準測試,測試種類包括確認測試和系統測試,且所有以發現的Bug等級為1/2/3的Bug已修復,近期內無發現新的Bug等級為1/2/3的Bug |
|
產品Release |
6月2日 |
重複進行主路徑測試和進行Bug檢查測試,產品處於可交付狀態並由測試經理和高階經理確認 |
5.2測試準備
5.2.1 測試環境準備
|
準備事項 |
開始時間 |
完成時間 |
測試人員 |
|
測試環境準備 |
6月2日 |
6月10日 |
張昊 |
5.2.2 安裝測試
|
準備事項 |
開始時間 |
完成時間 |
測試人員 |
|
安裝測試 |
6月2日 |
6月10日 |
張昊 |
5.2.3 煙霧測試
|
準備事項 |
開始時間 |
完成時間 |
測試人員 |
|
煙霧測試 |
6月2日 |
6月10日 |
張昊 |