測試計劃的設計和編寫

最近入職了新公司，項目組只有我一個測試，自成一家，哈哈，領導讓編寫測試計劃，因而在網上看了不少，最終本身擬了一份，但願能和你們共勉！

目錄

1     引言... 4

1.1      產品簡介... 4

1.2      編寫目的... 4

1.3      參考文檔... 4

1.4      限制條件... 5

2     測試概要... 5

2.1      測試目標... 5

2.2      測試範圍... 5

2.3      測試資源... 6

2.3.1       測試人力資源... 6

2.3.2       測試環境... 6

2.3.3       BUG管理工具... 6

3     測試規範... 7

3.1      測試接收標準... 7

3.2      BUG規範... 7

4     測試策略... 9

4.1      測試流程及工做量估算... 9

4.2      測試種類... 10

4.2.1       功能測試... 11

4.2.2       容錯性測試... 12

4.2.3       易用性測試... 13

4.2.4       UI（界面）測試... 13

4.2.5       接口測試... 14

4.2.6       系統測試... 14

4.2.7       兼容性測試... 15

4.2.8       性能測試... 15

4.2.9       安裝卸載測試... 17

5     發佈標準... 17

5.1      測試輸出文檔... 17

5.2      測試完成標準... 18

5.3      產品發佈標準... 18

6     測試風險... 18

 

1     引言

1.1    產品簡介

1.2    編寫目的

此文檔根據項目需求文檔，制定測試策略、評估測試風險，肯定所需的資源，並對測試的工做量進行估計，進行人員和進度安排，而且列出測試項目的可交付元素。

本文檔預期讀者對象主要爲項目經理、產品、開發、測試等。

1.3    參考文檔

序號	名稱	做者	備註
	詳細設計文檔
	設計原型

 

1.4    限制條件

本測試計劃受限於開發人員提交測試的內容和時間。根據開發人員提交模塊的實際狀況，本計劃會作出相應修改。

2     測試概要

2.1    測試目標

經過測試，達到如下目標：

1. 測試已實現的產品是否達到設計的要求，包括：各個功能點是否以實現，業務流程是否正確。
2. 產品規定的操做和系統運行穩定。
3. Bug數和缺陷率控制在可接收的範圍以內，遺留BUG通常不超過全部BUG的10%。

2.2    測試範圍

列出測試最終須要交付的功能模塊列表

2.3    測試資源

2.3.1   測試人力資源

角色	人員	職責
測試負責人	XXX	測試環境搭建 制定測試計劃 制定測試規範 測試用例審覈 控制測試進度 與相關部門、人員溝通
測試設計人員	XXX	設計測試用例 準備測試數據
測試執行人員	XXX	按計劃執行測試用例 記錄執行過程 提出糾正建議措施
缺陷管理人員	全部測試執行人員	記錄、報告所發現的缺陷 跟蹤缺陷修改過程 迴歸測試已修復缺陷
測試報告人員	XXX	分析測試結果 編寫測試報告

 

2.3.2   測試環境

1. 服務器環境

操做系統：windows          IP:

操做系統：linux              IP:

1. 終端環境

PC：windows10（ie十、chrome、Firefox）、windows7（ie十、chrome、Firefox）

1. 網絡環境

公司辦公內網、外網

2.3.3   BUG管理工具

在測試過程當中發現的缺陷及可用性問題，使用禪道來進行 bug 管理。

3     測試規範

3.1    測試接收標準

開始/中斷測試標準	標準說明
開始測試標準	一、代碼編譯經過 二、軟件能夠正確安裝運行 三、實現功能與產品設計出入不大 四、冒煙測試經過
中斷測試標準	一、安裝沒法正確完成 二、程序代碼編譯不經過 三、系統服務異常 四、發現阻塞功能的BUG

 

3.2    BUG規範

測試人員提交缺陷記錄時，應清晰、準確地描述缺陷發生的條件和步驟，並

設置缺陷的嚴重等級以下：

缺陷級別	描述
一級 （致命問題）	1. 程序運行過程當中不斷申請，但沒有徹底釋放資源，形成系統性能愈來愈低，並出現無規律的死機現象。 2. 程序運行致使系統崩潰。 3. 由程序引發的資源嚴重不足、非法退出等。 4. 嚴重的關鍵計算錯誤（如計費等）。 5. 數據庫發生死鎖，且沒法自動恢復。 6. 與需求要求差距較大。 7. 系統無響應。
二級 （嚴重問題）	1. 因錯誤操做致使的程序中斷。 2. 功能沒有實現。 3. 正確操做致使的錯誤結果。 4. 與數據庫鏈接錯誤,沒法自動恢復。 5. 數據通信錯誤，沒法自動恢復。 6. 數據庫的表、業務規則、缺省值未加完整性等約束條件。 7. 界面中的信息不能及時刷新，不能正確反映當前數據狀態，可能誤導用戶。（數據庫中剩餘記錄個數和參數設置對話框中的預設值經常顯示爲歷史值而不是當前值） 8. 對輸入數據沒有進行充分而且有效的有效性檢查，形成不合要求的數據進入數據庫。
三級 （普通問題）	1. 操做界面錯誤。（包括數據窗口內列名定義、含義是否一致，界面中英文混雜，界面元素良莠不齊，文字顯示不全） 2. 打印內容、格式錯誤。 3. 刪除操做未給出提示。 4. 數據庫表中有過多的空字段。 5. 提示信息意文不明或爲原始的英文提示。 6. 要求用戶輸入多餘的、原本系統能夠自動獲取的數據。（服務是否啓動，安裝後用戶須要手動修改某些配置文件）。 7. 輔助說明描述不清楚，有歧義。 8. 長操做未給用戶提示。
四級 （改進問題）	1. 輔助說明描述不清楚。 2. 輸入輸出不規範。 3. 可輸入區域和只讀區域沒有明顯的區分標誌。 4. 某一項功能的冗餘操做太多。如：對話框嵌套層次太多，影響用戶操做。 5. 不能記憶用戶的設置或操做習慣，用戶每次進入系統都須要從新操做初始環境。 6. 不符合用戶操做習慣。（快捷鍵定義不科學、不實用，鍵位分佈不合理、按鍵太多，甚至沒有快捷鍵）。 7. 界面不規範。 8. 提示窗口文字未採用行業術語。

 

4     測試策略

4.1    測試流程及工做量估算

任務	時間	執行人員	預期工做量	備註
編寫測試計劃		XXX	2
測試計劃review及修改		XXX	1
測試環境搭建		XXX	4
測試用例編寫		XXX	4
冒煙測試		XXX	2	依據開發提測時間變更
第一輪功能測試		XXX	4	執行測試用例，包括邊界值測試、兼容性測試、易用性測試、用戶界面測試、安全性測試等
第二輪功能測試		XXX	3	BUG複測及功能驗證
迴歸測試		XXX	1	全面迴歸測試
性能測試	-			待定，需確認具體性能測試方案和工具
發佈測試	-			產品發佈方案確認後再規劃
測試報告總結		XXX	2	時間待定
備註：因爲測試時可能會出現多個測試計劃並行測試執行的狀況，測試預估時間只做參考。

 

4.2    測試種類

本次測試計劃對系統進行如下類型的測試，針對不一樣的測試類型分別進行規劃和設計，包括測試方法和標準等。測試類型羅列以下：

測試類型	是否採用	說明
功能測試	採用	根據系統需求文檔和設計文檔，檢查系統是否正確實現了功能
邊界值測試	採用	選擇邊界數據進行測試，確保系統功能正常，程序無異常
容錯性測試	採用	檢查系統的容錯能力，錯誤的數據輸入不會對功能和系統產生非正常的影響，程序對錯誤的輸入有正確的提示信息
異常測試	採用	檢查系統可否處理異常
易用性測試	採用	檢查系統是否易用友好
UI（界面）測試	採用	檢查界面是否美觀合理，便於操做，符合操做習慣
流程測試	採用	按操做流程進行的測試，主要有業務流程、數據流程、邏輯流程，檢查軟件在按流程操做時是否可以正確處理
接口測試	採用	檢查系統接口可否正常工做
系統測試	採用	系統根據集成方案部署安裝到軟硬件環境後的運行狀況
兼容性測試	採用	對於 C/S 架構的系統來講，須要考慮客戶端支持的系統平臺；對於 B/S 架構的系統來講須要考慮用戶端瀏覽器的版本
穩定性測試	採用	利用工具長時間不斷的對系統進行操做
安全性測試	採用	系統應用級別的安全性：檢查角色只能訪問其所屬用戶類型已被受權訪問的那些功能或數據。
性能測試	採用	提取系統性能數據，檢查系統是否知足在需求中所規定達到的性能。
安裝卸載測試	採用	檢查系統可否正確安裝、配置

 

4.2.1    功能測試

功能測試應側重於全部可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是覈實數據的接收、處理和檢索是否正確，以及業務規則的實施是否恰當。此類測試基於黑盒技術，該技術經過圖形用戶界面（GUI）與應用程序進行交互，並對交互的輸出或結果進行分析，以此來覈實應用程序及其內部進程。

測試目標	覆蓋本次測試範圍的全部功能測試
測試範圍	測試內容
技術	1.設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略等 2.利用有效的和無效的數據來執行各個用例、用例流或功能，以覈實如下內容： （1）在使用有效數據時獲得預期的結果。 （2）在使用無效數據時顯示相應的錯誤消息或警告消息。 （3）各業務規則都獲得了正確的應用。
開始標準	經過冒煙測試
完成標準	不能遺留一，二級缺陷,三級普通缺陷90%獲得修改而且經過複測，四級改進缺陷80%獲得修改而且經過複測
測試重點和優先級	重點測試的功能和優先級安排
需考慮的特殊事項	考慮數據庫數據存儲的正確性； 考慮業務邊界值的測試（邊界值測試）； 考慮業務異常狀況的測試（異常測試）； 考慮業務流程、數據流程、邏輯流程的測試（流程測試）

 

4.2.2   容錯性測試

容錯性測試主要檢查系統的容錯能力，檢查軟件在異常條件下自身是否具備防禦性的措施或者某種災難性恢復手段。

 

測試目標	檢查軟件容錯能力
測試範圍
技術	1.輸入異常數據或進行異常操做，以檢驗系統的保護性。若是系統的容錯性好，系統只給出提示或內部消化掉，而不會致使系統出錯甚至崩潰。 2.災難恢復性測試。經過各類手段，讓軟件強制性地發生故障，而後驗證系統已保存的用戶數據是否丟失，系統和數據是否能儘快恢復。
開始標準	功能測試階段
完成標準	不能遺留一，二級缺陷,三級普通缺陷90%獲得修改而且經過複測，四級改進缺陷80%獲得修改而且經過複測
測試重點和優先級	重點考慮各類異常狀況，災難恢復性測試需創建在系統有較好的容災機制。
需考慮的特殊事項	考慮不按正常流程操做系統； 考慮使用非正常手段訪問（例如直接使用內部連接地址訪問，直接使用訪問協議訪問） 考慮數據不符合實際規則（例如數據填寫不完整、輸入不存在的日期、數字或文本超出設定值、輸入空格、上傳不符合類型的文件等） 考慮多系統登陸、超時登陸等 如下幾點爲環境容錯測試，即容災機制需考慮的問題： 在網絡出現故障時，是否有其餘網絡進行自動的切換和鏈接 在系統斷電時，是否有其餘的供電系統能進行自動切換 在系統服務器出現問題時，是否有其餘的備用服務器能進行自動切換 考慮當多個客戶端同時請求系統資源（例如硬盤、內存、CPU等），是否對資源會產生死鎖問題，及死鎖解決方案

 

4.2.3   易用性測試

易用性測試是指用戶使用軟件時是否感受方便，好比是否最多點擊鼠標三次就能夠達到用戶的目的。易用性測試應當集中體如今界面美觀、功能實用、處理有效幾個方面。

測試目標	檢查系統是否易用友好
測試範圍
技術	通常從導航，圖形，內容，總體界面等幾個方面入手，主要考慮以下幾個方面: (1)易理解性;(2)易學習性;(3)易操做性(4)吸引性;(5)依從性。 具體測試點以下： 1.查詢、添加、刪除、修改操做相關提示信息的一致性，可理解性 2.輸入限制的正確性 3.系統各類提示信息的正確性，可理解性，一致性
開始標準	功能測試階段
完成標準	不能遺留一，二級缺陷,三級普通缺陷90%獲得修改而且經過複測，四級改進缺陷80%獲得修改而且經過複測
測試重點和優先級
需考慮的特殊事項	考慮系統被頻繁使用的功能支持快捷方式或默認值方式； 考慮2秒鐘法則——用戶在使用某類系統時的等待反應不該該超過2秒； 考慮3次點擊法則——用戶在3次點擊以內若是尚未找到他們想要的信息或瞭解產品/網站的特點，他們就會離開； 考慮全部提示信息應該能夠幫助用戶完成功能使用，而且儘量通俗易懂，言簡意賅

 

4.2.4   UI（界面）測試

用戶界面（UI）測試主要用於覈實用戶與軟件之間的交互。UI測試的目標是確保用戶界面會經過測試對象的功能來爲用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，並符合公司或行業的標準。

測試目標	測試UI界面的瀏覽是否能夠正確反映業務的功能和需求，是否能與原型圖保持一致
測試範圍
技術	UI界面測試包括窗口與窗口之間、字段與字段之間的瀏覽，以及各類訪問方法（Tab鍵、鼠標移動、和快捷鍵）的使用，窗口的對象和特徵（例如，菜單、圖標、文字、大小、位置、狀態和中心）等
開始標準	功能測試階段
完成標準	成功地核實出各個窗口都與原型圖保持一致，或符合可接受標準
測試重點和優先級
需考慮的特殊事項	考慮直觀性、一致性、靈活性、溫馨性等

 

4.2.5   接口測試

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

接口測試也屬於功能測試，測試流程是首先根據接口文檔編寫測試用例（用例編寫能夠按照功能測試的規則來編寫，例如等價類劃分，邊界值等設計方法），而後執行測試，查看不一樣的參數請求，判斷接口的返回數據是否達到預期，可能須要轉換接口數據格式，常見爲json格式，而且需根據需求支持一種或多種接口請求方式（例如GET請求、POST請求等），請求協議爲http或https等。

測試目標	保證接口調用的正確性
測試範圍
技術	1.使用接口測試工具postman進行接口調用測試， 2.使用jmeter維護自動化接口測試， 3.使用fiddler進行接口請求抓取
開始標準	功能測試階段
完成標準	不能遺留一，二級缺陷,三級普通缺陷90%獲得修改而且經過複測，四級改進缺陷80%獲得修改而且經過複測
測試重點和優先級
需考慮的特殊事項	考慮接口參數必填、非必填 考慮業務異常狀況 考慮接口參數異常（如參數爲null，參數爲特殊字符） 考慮接口參數邊界值測試 考慮接口返回數據的正確性 考慮接口請求超時的狀況 考慮接口請求失敗的狀況，業務是否可逆，數據是否存儲或取消

 

4.2.6   系統測試

系統測試主要目的爲檢測系統是否達到需求對業務流程及數據流的處理是否符合標準，檢測系統對業務流處理是否存在邏輯不嚴謹及錯誤，檢測需求是否存在不合理的標準及要求。此階段測試是基於功能測試完成的狀況下。

測試目標	檢測整個系統業務流程，數據流的正確性
測試範圍
技術	利用有效的和無效的數據來執行各個用例、用例流或功能，以覈實如下內容： 1.在使用有效數據時獲得預期的結果。 2.在使用無效數據時顯示相應的錯誤消息或警告消息。 3.各業務規則都獲得了正確的應用。
開始標準	功能測試完成後
完成標準	所計劃的測試已所有執行。 所發現的等級高的缺陷已所有解決。
測試重點和優先級	重點測試系統之間交互，數據傳送等
需考慮的特殊事項	考慮不一樣系統的交互流程是否存在冗餘步驟，及可優化點

 

4.2.7   兼容性測試

兼容性測試主要檢驗被測試軟件在特定的硬件平臺上、不一樣的應用軟件之間、不一樣的操做系統平臺上、不一樣的網絡等環境中是否可以很友好的運行測試。

 

測試目標	檢測程序兼容性
測試範圍
技術	1.測試軟件是否能在不一樣的操做系統平臺上兼容，或測試軟件是否能在同一操做平臺的不一樣版本上兼容； 2.軟件自己可否向前或向後兼容（考慮版本迭代的狀況）； 3.測試軟件可否與其餘相關的軟件兼容； 4.測試軟件可否支持不一樣瀏覽器的兼容； 5.測試軟件可否支持不一樣分辨率的兼容； 6.數據兼容性測試，主要是指數據可否共享等。
開始標準	功能測試階段
完成標準	不能遺留一，二級缺陷,三級普通缺陷90%獲得修改而且經過複測，四級改進缺陷80%獲得修改而且經過複測
測試重點和優先級
需考慮的特殊事項	需考慮後期版本迭代，不一樣系統不一樣版本之間的兼容性

 

4.2.8   性能測試

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。性能測試是爲了驗證軟件系統是否可以達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最後起到優化系統的目的。性能測試通常包括如下幾種類型：

1.基準測試：在給系統施加較低壓力時，查看系統的運行情況並記錄相關數據作爲基礎參考。

2.負載測試：是指對系統不斷地增長壓力或持續一段時間增長必定壓力，直到系統的某項或多項性能指標達到安全臨界值，例如某種資源已經達到飽和狀態等。

3.壓力測試：壓力測試是評估系統處於或超過預期負載時系統的運行狀況，關注系統在峯值負載時或超出最大負載狀況下的處理能力。

4.穩定性測試：在給系統加載必定業務壓力的狀況下，使系統運行一段時間，以此檢測系統是否穩定。

5.併發測試：測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時，是否存在死鎖或者其餘性能問題。

 

測試目標	檢測系統性能，發現性能瓶頸，進行性能調優
測試範圍
技術	待肯定詳細的性能測試方案
開始標準	測試工做完成後，系統穩定後
完成標準	達到需求要求的性能標準
測試重點和優先級
需考慮的特殊事項	性能測試通常參考指標有響應時間、吞吐量、併發數、資源利用率、事務處理能力（TPS）等。 性能測試通常關注點以下： 1.響應時間快慢，服務器端的處理速度 2.服務器端的使用狀況 3.數據庫端的資源使用狀況 4.最大用戶訪問數量 5.同時處理最大業務數量 6.考察系統可否支撐7x24小時運轉 7.內存資源、線程資源可否正常回收 8.代碼，算法，sql語句設計是否合理 9.整個系統的穩定性，可恢復性

 

4.2.9   安裝卸載測試

安裝卸載測試是爲了確保該軟件在正常狀況和異常狀況的不一樣條件下（例如，進行首次安裝、升級、完整的或自定義的安裝，卸載重安裝等）都能成功進行安裝，異常狀況包括磁盤空間不足、缺乏目錄建立權限等，覈實軟件在安裝後可當即正常運行，覈實軟件能夠正常進行卸載。

 

測試目標	檢查程序包是否能夠正常進行安裝部署和卸載
測試範圍	-
技術	1.軟件在不一樣操做系統下安裝的過程。 2.軟件安裝後的是否可以正常運行，安裝後的文件夾及文件是否寫到了指定的目錄裏。 3. 軟件安裝過程是否能夠取消 4.測試使用系統自帶的添加刪除（以WIDOWSXP爲例）程序卸載的狀況 5.測試軟件自帶的卸載程序 6.測試卸載之後從新安裝 7.測試安裝和卸載時的提示信息是否合理
開始標準	測試階段完成，有安裝包打包方案後
完成標準	安裝成功可以運行系統，卸載成功無殘留
測試重點和優先級
需考慮的特殊事項	考慮安裝和卸載過程當中出現的意外狀況的測試（如死機、斷電、重啓） 考慮舊版本升級操做

 

5    發佈標準

5.1    測試輸出文檔

本次測試完成後的提交物：

• 測試計劃
• 測試用例
• 測試Bug單
• 使用手冊
• 測試報告

5.2    測試完成標準

本次測試過程當中，計劃測試完成的標準以下：

1. 需求規格說明書中的需求必須所有實現並測試經過。
2. 主流程暢通，系統沒有一類和二類Bug（參考3.2 BUG規範），沒有影響用戶正常使用的BUG。
3. 全部功能和性能測試用例100％執行完成。
4. 剩餘三類四類有爭議的bug，若是沒法達成一致，測試人員需與產品、開發、項目經理開會討論決定是否遺留有爭議的Bug，若最終決定項目上線時有遺留BUG，需將BUG說明附在測試結果報告裏，給出緣由或最終解決方案。
5. 測試報告編寫完成，測試收尾工做結束。
6. 項目處於試運行或上線階段。

5.3    產品發佈標準

本次測試過程當中，計劃產品發佈上線的標準以下：

1. 按照交互文檔、需求文檔徹底的實現需求。
2. 符合交互稿的交互設計規範、符合視覺要求，並已經經過設計評審。
3. 核心代碼100％通過代碼Review。
4. 容許遺留可能會對用戶正常使用形成必定影響的三類、四類缺陷，但應在發佈前告知項目組，並經風險評估一致贊成發佈後方可發佈。

6     測試風險

本次測試過程當中，可能出現的風險以下：

1. 開發提交測試版本比該計劃延遲，發生此種狀況時，執行測試的時間應該合理順延；
2. 若是測試計劃執行過程當中出現需求變動超出預計的狀況，可能致使編寫測試用例和執行測試相關工做量增長，測試進度延遲；
3. 若是開發提測版本質量較低，bug較多，可能致使比該計劃更多輪次的迴歸測試；
4. 人員調整、人員經驗以及對軟件的熟悉度可能會影響測試計劃；
5. 測試需依賴於服務器環境，若是環境不穩定，如代碼編譯不經過，tomcat異常、jar包異常、數據庫異常等狀況，可能會影響測試進度。