软件测试计划包括哪些内容，测试计划如何编写。分享测试计划模板
相信大多數(shù)的軟件測試工程師都聽說過或者簡單了解過測試計劃，但是你真的知道什么是測試計劃么？你真的知道如何編寫測試計劃么？
大多數(shù)人應(yīng)該是一臉茫然。
百度的結(jié)果五花八門，有沒有相對規(guī)范的標(biāo)準(zhǔn)呢？答案是沒有，至少我們沒有找到。
今天小編給大家分享一個全套測試計劃模板
一份完美的軟件測試計劃贈予你，拿走，不謝！
XX項目名稱測試計劃書
1.測試背景
為了保證XX項目測試工作的組織性，提高測試的工作質(zhì)量和效率，為XX項目測試工作提供完整的測試計劃、測試人員工作安排、測試輪次、測試方法、系統(tǒng)功能模塊覆蓋率以及測試風(fēng)險分析，確保測試項目平穩(wěn)有序的運行。
2.測試目標(biāo)
XXXX測試項目的測試目標(biāo)為：
? 接口程序覆蓋率100%，接口錯誤修改率100%
? 測試案例的功能覆蓋率達100%，執(zhí)行率達100%
? 已修改的測試問題回歸測試覆蓋率達100%
? 測試記錄閉環(huán)率達95%
3.測試范圍
? 測試計劃和設(shè)計：根據(jù)軟件需求說明書，制定測試計劃，測試方案，包括收集測試方法，測試用例，測試工具等。
? 單元測試：根據(jù)系統(tǒng)詳細設(shè)計，制定測試計劃，制定測試方案。此項目由開發(fā)人員自測。
? 集成測試：將各個模塊進行組合測試，保證所有功能和界面都正確。對產(chǎn)品重點模塊進行負載測試，確保軟件性能達到軟件需求說明書的要求
…………………………
4.測試輸出文檔
| 文檔 | 使用工具 | 提交日期 | 責(zé)任人 |
| 《測試計劃》 | Word | 測試經(jīng)理 | |
| 《測試用例》 | QC | 測試經(jīng)理 | |
| 《缺陷報告》 | QC | 測試經(jīng)理 | |
| 《測試報告》 | Excel | 測試經(jīng)理 |
? 項目的測試人員、職位、工作職責(zé)
| 角色 | 姓名 | 工作內(nèi)容 |
| 測試經(jīng)理 | 編寫測試計劃 缺陷管理 測試結(jié)果分析 | |
| 黑盒測試工程師 | 編寫測試用例 執(zhí)行測試 報告缺陷 | |
| 自動化測試工程師 | 編寫腳本 自動化測試執(zhí)行 | |
| 性能測試工程師 | 分析軟件功能 開發(fā)腳本 性能測試執(zhí)行 |
? 需要配合的部門與人員
| 角色 | 姓名 | 工作內(nèi)容 |
| 開發(fā)人員 | 協(xié)助搭建測試環(huán)境 | |
| 業(yè)務(wù)人員 | 協(xié)助測試人員理解需求，提供業(yè)務(wù)幫助 |
5.測試工具
? 測試管理工具為Quality Center、性能測試工具有LoadRunner、功能自動化測試工具為Quick Test Professional
| 用途 | 工具 | 生產(chǎn)廠商 | 版本 |
| 測試管理 | QC | HP | 9.0 |
| 性能測試 | LR | HP | 8.1 |
| 功能自動化 | QTP | HP | 9.2 |
6.測試規(guī)模以及工作量分析
XXXX項目為大型項目，測試工作包括為測試計劃、測試用例的編寫、集成測試的執(zhí)行、性能測試的執(zhí)行，涉及功能模塊較多，業(yè)務(wù)邏輯較為復(fù)雜，預(yù)估測試工作量如下所示。
? 測試工作量預(yù)估
| 任務(wù)階段 | 人數(shù) | 工作日 | 人日小計 | 備注 |
| 測試案例編寫 | 15 | 7 | 105 | |
| 測試執(zhí)行 | 15 | 23 | 345 |
? 功能點分析
| 模塊 | 子節(jié)點 | 測試人員 | 啟動時間 |
| XXXX | 登錄及整體架構(gòu) | 2022-10-24 | |
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| XXXXX | 2022-10-24 | ||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| XXX | 2022-10-24 | ||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 | |||
| 2022-10-24 |
7.測試進程
1）測試流程表
編輯
添加圖片注釋，不超過 140 字（可選）
2）測試過程描述
a.測試計劃階段
??編寫測試計劃
測試經(jīng)理根據(jù)項目計劃與項目業(yè)務(wù)需求說明書創(chuàng)建測試計劃，如果此需求發(fā)生變化，則將根據(jù)變化更新此項目測試計劃。
??評審測試計劃
ü 項目經(jīng)理瀏覽并評審《系統(tǒng)項目測試計劃》。
ü 測試經(jīng)理負責(zé)更新此文檔。
ü 項目經(jīng)理負責(zé)評審和批準(zhǔn)經(jīng)過更新的文檔。
ü 《項目測試計劃》的版本為1.0, 如果該計劃被更新，則版本的序號也隨之變更。
ü 測試工程師根據(jù)測試計劃執(zhí)行測試任務(wù)。
b.測試用例階段
??編寫測試用例
ü 分析《軟件需求說明書》。
ü 測試工程師根據(jù)《軟件需求說明書》編寫測試用例。
ü 冒煙測試用例需要被同時創(chuàng)建。
??評審測試用例
ü 測試組負責(zé)評審《測試用例》。
ü 在發(fā)現(xiàn)錯誤或問題的情況下，該測試用例將會被更新。
ü 測試經(jīng)理負責(zé)填寫《測試用例評審報告》。
ü 我們將《測試用例》的最初版本定義為1.0，如果該文件得到更新，其版本也會被同時更新。
c.測試階段
??冒煙測試
測試工程師負責(zé)根據(jù)《項目測試用例》進行冒煙測試，執(zhí)行測試用例的實際輸出結(jié)果是否符合預(yù)期結(jié)果，我們將此用例標(biāo)注為通過或者失敗，將結(jié)果返回給開發(fā)部門。
??系統(tǒng)測試
根據(jù)《項目測試計劃》和《項目測試用例》，測試工程師負責(zé)執(zhí)行測試用例：
ü 當(dāng)執(zhí)行測試用例時：
1. 如果實際輸出結(jié)果和預(yù)期輸出結(jié)果相同，該用例需要被標(biāo)注為通過。
2. 如果實際輸出結(jié)果和預(yù)期輸出結(jié)果不同，該用例需要被標(biāo)注為失敗。
3. 如果測試時遇到功能性缺陷導(dǎo)致用例不能執(zhí)行，該測試用例需要被標(biāo)注為鎖定，直到該缺陷被修復(fù)，才可以繼續(xù)執(zhí)行該測試用例。
4. 所有在測試過程發(fā)現(xiàn)的缺陷，需要被提交到Quality Center。
ü 測試用例在測試過程中將根據(jù)需要得到更新。
ü 測試經(jīng)理負責(zé)分析測試結(jié)果，對測試人員執(zhí)行的測試用例進行一定比率的內(nèi)部QC（質(zhì)量控制）。
ü 測試完成時，需得到測試經(jīng)理的批準(zhǔn)。
備注：所有的缺陷必須被提交到缺陷處理系統(tǒng)Quality Center。
d.測試總結(jié)階段
??分析和總結(jié)測試結(jié)果
ü 測試經(jīng)理總結(jié)各自的測試工作并在《項目測試總結(jié)》中填寫相應(yīng)的部分內(nèi)容。包括測試工具，測試技術(shù)，測試體會以及工作質(zhì)量等。
ü 測試經(jīng)理負責(zé)在《項目測試總結(jié)》中分析與總結(jié)測試數(shù)據(jù)，填寫包括測試人員工作效率，人力資源消耗，測試過程中經(jīng)驗與教訓(xùn)，評價整個項目過程中的測試質(zhì)量。
??測試完成
ü 測試經(jīng)理負責(zé)批準(zhǔn)測試完成。
ü 所有測試人員在《項目測試總結(jié)》中簽名，證明所有任務(wù)都已完成。
8.測試進度及時間資源
? XX網(wǎng)銀項目測試人員數(shù)量為15人，測試時間為450個工作日。
| 測試活動 | 計劃開始日期 | 計劃結(jié)束日期 | 實際開始日期 | 實際結(jié)束日期 |
| 測試計劃 | 2022-10-24 | 2022-10-27 | ||
| 設(shè)計測試用例 | 2022-10-26 | 2022-11-4 | ||
| 測試用例評審 | 2022-10-27 | 2022-11-5 | ||
| 環(huán)境搭建 | 2022-10-27 | 2022-10-28 | ||
| 系統(tǒng)測試 | 2022-10-28 | 2022-11-20 | ||
| 性能測試 | 2022-11-22 | 2022-12-2 | ||
| 測試總結(jié)報告 | 2022-11-29 | 2022-12-2 |
9.測試輪次安排
? XXXX測試項目測試輪次視項目情況而定，通常分為2輪，每輪的工作根據(jù)輪次的推進而改變。
| 測試活動 | 計劃開始日期 | 計劃結(jié)束日期 | 實際開始日期 | 實際結(jié)束日期 |
| 第一輪 | 2022-10-28 | 2022-11-12 | ||
| 第二輪 | 2022-11-13 | 2022-11-20 |
| 測試活動 | 測試內(nèi)容 | 人員 |
| 第一輪 | 冒煙測試、功能測試 | 15 |
| 第二輪 | 缺陷驗證、冒煙測試、功能測試、用戶界面測試、、兼容性測試 | 15 |
10.測試方法
1）功能類測試
功能類測試是銀行項目測試工作中的重點，在各個環(huán)節(jié)都需要有比較全面的考慮。先考慮測試案例的組織結(jié)構(gòu)，首先按照功能模塊（通常對應(yīng)系統(tǒng)中的一級菜單）歸類，然后針對各功能模塊下的每一個具體功能（即有獨立頁面的功能，簡稱子功能）再分類，分別設(shè)計不同方面的測試案例，案例的組織結(jié)構(gòu)如下：
——“XX模塊”
——“XX葉子功能1”
——冒煙測試
——頁面要素驗證
——必輸項驗證
——輸入項檢查
——聯(lián)動項檢查
——本功能流程測試
——通過性測試
——失效性測試
——“XX葉子功能2”
……
……
——總體規(guī)則驗證
——數(shù)據(jù)流轉(zhuǎn)測試
——后臺線程測試
數(shù)據(jù)流轉(zhuǎn)測試和后臺線程測試，這兩類案例可考慮根據(jù)情況，放在某一模塊下，或者單獨自成一部份。
對這幾類測試，做一個簡要的說明：
| 名稱 | 描述 | 備注 |
| 冒煙測試 | 對本功能正常的主線流程進行驗證而設(shè)計的案例 | 此案例專門用來做冒煙測試，通常每個子功能只需提供一條該案例，設(shè)計時只需保證該功能的正常操作流程（即僅輸入必要的有效數(shù)據(jù)）通過即可 |
| 總體規(guī)則 | 根據(jù)需求文檔中提供的總體規(guī)則來設(shè)計的用例。主要包括各個功能頁面風(fēng)格的一致性、操作習(xí)慣的一致、顯示格式的統(tǒng)一等。 | 通常一個項目的總體規(guī)則是固定的，既要保證案例的執(zhí)行覆蓋度，又要避免案例的冗余，所以總體規(guī)則可由一個人完成設(shè)計，在各個模塊下直接復(fù)用；測試執(zhí)行時，可根據(jù)需要來進行執(zhí)行情況的統(tǒng)計。 |
| 頁面\必輸項驗證 | 執(zhí)行該功能操作，頁面中所必須錄入/選擇的項目，是否在為空的情況下仍然可以通過提交的檢查。 | 各個頁面的必輸項不同，要考慮必輸項的顯示方式，以及非必輸項是否也被做了必輸限制等。 |
| 頁面\輸入項檢查 | 主要指在客戶端所進行的各類輸入數(shù)據(jù)項的合法性的檢查。 | 這部分案例主要指在客戶端能夠驗證或限制的內(nèi)容，如數(shù)據(jù)輸入長度限制、是否含有非法字符等。 |
| 頁面\聯(lián)動項檢查 | 主要指頁面中多個輸入或選擇項目之間，根據(jù)前一項的結(jié)果而對其它項是否產(chǎn)生了約束的檢查。 | 例如，城市的選擇，選擇了省之后，其下可選擇的市，是否進行了列表更新等。 |
| 本功能流程測試 | 當(dāng)前功能本身的操作及數(shù)據(jù)流程正確性的測試，包括正常流程和異常流程。 | 例如，執(zhí)行轉(zhuǎn)賬操作，輸入正確和錯誤密碼是否得到了正確的正常和異常返回結(jié)果；以及顯示的返回結(jié)果是否與實際結(jié)果一致等。 |
| 數(shù)據(jù)流轉(zhuǎn)測試 | 主要指銀行端與客戶端之間的數(shù)據(jù)通訊是否準(zhǔn)確，以及企業(yè)網(wǎng)銀授權(quán)、審核流程的數(shù)據(jù)流轉(zhuǎn)是否正確等。 | 例如，企業(yè)網(wǎng)銀在銀行端設(shè)定某種授權(quán)模式，在客戶端是否正確體現(xiàn)等；或銀行端修改了客戶信息、發(fā)布了客戶通知等在客戶端是否正確體現(xiàn)等。 |
| 后臺線程測試 | 驗證系統(tǒng)設(shè)定的在固定時間自動線程是否正確執(zhí)行。 | 例如，系統(tǒng)設(shè)定每天凌晨1點，某系統(tǒng)自動從主機同步網(wǎng)點數(shù)據(jù)進行更新等。 |
注：
? “數(shù)據(jù)流轉(zhuǎn)測試”從名稱和范圍上難與功能流程測試有明顯劃分的界限，可根據(jù)實際項目情況變更案例類別的名稱，或明確規(guī)定試用范圍；
? 實際項目中可能仍會有部分案例無法劃分在上述的類別中，可根據(jù)實際情況進行調(diào)整，或單獨形成一個補充案例。例如，主機錯誤碼在網(wǎng)銀系統(tǒng)未知的情況，是由于網(wǎng)銀數(shù)據(jù)庫基礎(chǔ)數(shù)據(jù)不完整，也應(yīng)屬于缺陷。
? “冒煙測試”的案例，僅執(zhí)行冒煙測試時使用，案例可能會與“本功能流程測試”的案例重復(fù)，但此處單獨提出，便于測試的執(zhí)行和統(tǒng)計，不算案例冗余。
2）兼容性測試
兼容性測試主要應(yīng)針對客戶端，并且根據(jù)客戶的要求并結(jié)合實際，來提供不同的測試方案，并非要盲目的兼容一切；B/S架構(gòu)項目兼容性測試的重點，在于瀏覽器兼容的測試
| 兼容對象 | 測試重點 | 備注 |
| 操作系統(tǒng) | 文件證書的導(dǎo)入，移動證書的識別是否正常 | 主要針對Vista系統(tǒng)測試，其他非MS操作系統(tǒng)根據(jù)需求以及可提供的驅(qū)動程序而定 |
| 瀏覽器 | 頁面各功能的可用性，界面顯示的美觀、一致性 | 此為兼容性測試的重點。通常需要兼容IE6、IE7 |
| Office類文檔 | 網(wǎng)銀系統(tǒng)中導(dǎo)出或生成的各類數(shù)據(jù)，使用不同版本的office（包括非MS的office），是否都能夠正常打開并準(zhǔn)確顯示 | 通常以office97以上版本作為測試對象 |
| 其它主流軟件 | 在網(wǎng)銀系統(tǒng)的使用過程中，如果同時打開其他主流軟件，是否會造成沖突（如QQ、MSN等） | 此測試僅能對已知的可能不兼容軟件進行測試，無法達到全面測試，需要總結(jié)實際經(jīng)驗來完善 |
| 硬件設(shè)備 | 網(wǎng)銀系統(tǒng)的使用中，對常見的輸入設(shè)備是否支持良好，尤其在使用特殊控件的位置和獨立的客戶端系統(tǒng)中（如使用USB鍵盤等） | 此測試僅能對已知的可能不兼容設(shè)備進行測試，無法達到全面測試，需要總結(jié)實際經(jīng)驗來完善 |
3）多語言測試
? 銀行系統(tǒng)的界面中，非簡體中文的語言應(yīng)由用戶來提供，或至少需要由用戶確認(rèn)語言使用的準(zhǔn)確性；
? 重點測試，使用非簡體中文的語言后，頁面內(nèi)容顯示的位置、格式等美觀性是否發(fā)生了變化，是否在可接受范圍內(nèi)；
? 多語言測試時，要對系統(tǒng)進行完整測試，以達到系統(tǒng)中各個位置（包括彈出的提示信息、異常時的錯誤信息等），都能夠以相應(yīng)的語言正確顯示。
4）性能測試
銀行系統(tǒng)中，性能測試主要針對客戶端進行測試，不同項目需求，對性能壓力的要求有所不同，銀行端在無特殊要求下無需進行性能測試。
性能測試的主要應(yīng)用策略：
? 負載測試：不斷增加壓力，直到超出預(yù)期性能指標(biāo)，或某種資源達到飽和狀態(tài)。
(1)能找到系統(tǒng)所能承受的壓力（在正常指標(biāo)、資源范圍內(nèi)，如響應(yīng)時間超過10秒，CPU大于70%）
(2)可以配合系統(tǒng)調(diào)優(yōu)
? 并發(fā)測試：并發(fā)訪問同一個應(yīng)用或模塊
(1)主要關(guān)注并發(fā)訪問時，是否內(nèi)存泄露、死鎖、其它資源爭用的問題。
(2)“并發(fā)用戶數(shù)”的估算，需要結(jié)合實際，并根據(jù)特定計算公式得出。
? 疲勞測試：較長時間的使系統(tǒng)處于一定壓力下，看是否能夠穩(wěn)定運行。
(1)使CPU或其他資源處于較高的利用率下，持續(xù)運行一定時間，并關(guān)注整體運行狀況。
(2)使CPU壓力增大，可以等同于小壓力情況下更長時間的運行效果，相當(dāng)于是“壓縮時間的測試”。
總結(jié)
以上是生活随笔為你收集整理的软件测试计划包括哪些内容，测试计划如何编写。分享测试计划模板的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 户外lisp导向牌如何安装_详细图解丨|
- 下一篇： 调和平均