測試計劃

---

測試計劃（Testing plan）的定義：

描述了要進行的測試活動的範圍、方法、資源和進度的文檔；
是對整個信息系統應用軟件組裝測試和確認測試。
它肯定測試項、被測特性、測試任務、誰執行任務、各類可能的風險。
測試計劃能夠有效預防計劃的風險，保障計劃的順利實施。

測試計劃的目的

（1）爲測試各項活動制定一個現實可行的、綜合的計劃，包括每項測試活動的對象、範圍、方法、進度和預期結果。
（2）爲項目實施創建一個組織模型，並定義測試項目中每一個角色的責任和工做內容。
（3）開發有效的測試模型，能正確地驗證正在開發的軟件系統。
（4）肯定測試所須要的時間和資源，以保證其可得到性、有效性。
（5）確立每一個測試階段測試完成以及測試成功的標準、要實現的目標。
（6）識別出測試活動中各類風險，並消除可能存在的風險，下降由不可能消除的風險所帶來的損失。

編寫測試計劃，就是爲了達到這些目的。

經過測試計劃能夠宏觀的指導測試的後續工做

測試計劃由誰編寫

測試計劃屬於管理型文檔，是由測試經理、測試主管或測試組長進行編寫。

測試計劃編寫的6個要素

1）why——爲何要進行這些測試；
2) what—測試哪些方面，不一樣階段的工做內容；
3) when—測試不一樣階段的起止時間；
4) where—相應文檔，缺陷的存放位置，測試環境等；
5) who—項目有關人員組成，安排哪些測試人員進行測試
6) how—如何去作，使用哪些測試工具以及測試方法進行測試。

上圖主要說明了制定測試計劃的相關步驟，下面就着重說明測試計劃的主要內容。

測試計劃主要內容

---

第1章 引言

1.1項目背景和目的

本次是關於健身房管理後臺三期項目的測試計劃，主要功能包括登陸、會員卡信息導入、會員信息導入、私教課和特點課的預定課程限制、潛客管理、簽到等管理後臺以及APP端的功能測試計劃。根據項目狀況，安排測試階段週期2周完成3輪測試工做、人員目前配備的是兩個測試人員，在兩週內結束測試，達到上線測試標準。三期結束以後能夠比較完整的交付用戶正式試用管理系統。

1.2參考資料

文檔資料	文檔說明	位置信息
項目可行性分析報告	項目可行性分析說明書	項目計劃\項目可行性分析報告
軟件需求規格說明書	軟件需求定義	...
軟件概要設計	軟件採用的框架、軟件的數據庫結構設計	...
軟件詳細設計	軟件數據庫每一個表的詳細設計等	...
用戶使用說明書	用戶使用說明文檔	...
...
...

1.3名詞解釋

本測試計劃中涉及如下名詞，解釋以下：

縮寫詞或術語	英文解釋	中文解釋
驗收測試		系統開發生命週期方法論的一個階段，這時相關的用戶和／或獨立測試人員根據測試計劃和結果對系統進行測試和接收
α測試		是由一個用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測試，Alpha測試不能由程序員或測試員完成
黑盒測試		測試人員不關心程序具體如何實現的一種測試方法
BUG		有時稱做defect（缺陷）或error（錯誤），軟件程序中存在的編程錯誤，可能會帶來沒必要要的反作用，軟件的功能和特性與設計規格說明書或用戶需求不一致的方面
β測試		測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在測試現場，Beta測試不能由程序員或測試員完成
....	....	....

1.4測試摘要

管理後臺V3期主要涉及的是管理後臺的會員卡的綁定、會員導入、會員卡導入等操做，須要重點關注，APP學員的會員信息和管理後臺同步；目前的支付方式中只使用次卡、儲值卡、期限卡支付；而微信和銀行卡支付目前暫不支持，因此此流程暫時不通。

1.4.1 重點事項

1. 會員信息導入
2. 會員卡信息導入
3. 會員卡綁定
4. 後臺控制用戶的課提早預定私教和特點課課程數
5. ....

1.4.2 爭議事項

簡要說明爭議事項。

1.4.3 風險評估

目前開發排期時間比較趕，致使測試時間不充分；因項目緣由沒法延期，因此須要側重點進行管理後臺的測試，APP的測試可根據實際狀況適當延期。其二：目先後臺管理系統沒有進行性能和壓力測試，在後期用戶數據量猛增可能會致使系統癱瘓的風險；其三：目前測試機型不充分，基本沒有進行兼容性測試；在用戶試用階段，建議試用目前已經驗證的常規機型和經常使用瀏覽器FirFox或chrome瀏覽器等。

1.4.4 時間進度

時間/事項	起始時間	結束時間
轉測時間	....	....
測試開始時間	...	...
測試結束時間	....	....
	...	...

簡要說明測試開始時間與發佈時間。

1.4.5 測試目標

測試發佈的質量目標：

測試計劃中全部測試方法和模塊已經執行經過

全部的測試案例已經執行過

全部的重要等級爲中、嚴重、很是嚴重的Bug已經解決並由測試驗證

第2章 項目背景

2.1測試範圍

目前三期項目的主要功能參考以下：

本次測試計劃主要涵蓋的測試範圍：管理後臺V3期和APP以及微信小程序，其中管理端的優先級最高，須要優先上線、其後是APP和小程序。目前涉及的測試方法主要包括接口測試、功能測試、集成測試、系統測試和驗收測試；其中接口和總體功能測試、驗收測試是目前測試的重點，具體參考原型和需求說明書。

2.2測試目標

模塊	測試方法	測試狀況	備註
登陸	功能/接口	經過
會員卡導入	功能/接口	經過
...

2.3聯繫方式

列出項目參與人員的職務、姓名、E-mail 和電話。

職務	姓名	E-Mail	電話
IOS/Android開發工程師	張三	zhangsan@qq.com	156***
後臺開發工程師	...	...	...
開發經理	...	...	...
測試負責人	...	...	...
測試人員	...	...	...

2.4風險及約束

風險和制約因素：

1. 需求變動更新延遲，致使開發延期
2. dev和beta環境常常崩潰，致使開發和測試浪費工做時間
3. 測試人員不足，可能致使測試不充分，須要增長人員等

2.5測試文檔

測試過程當中可能用到的參考文檔、概要設計設計文檔、詳細設計文檔以及保存位置，測試應產生測試用例、測試報告等文檔。

2.5.1測試參考文檔

文檔說明	做者	文檔位置（CVS）
需求規格說明書	張**	...
概要設計	...	...
詳細設計	...	...
管理後臺使用手冊	...	...
管理手冊	...	...
測試用例	...	...
API文檔	...
...	...	...

2.5.2測試提交文檔

文檔說明	做者	文檔位置（CVS）
《項目測試計劃》
《項目測試方案》（可根據項目狀況進行裁剪）
測試用例
《性能測試方案（報告）》
《產品操做手冊(後臺)》
《產品操做手冊(前臺)》
《產品接口說明》
《產品安裝維護手冊》
《產品錯誤代碼說明文檔》
《產品培訓操做文檔》
...	...	...

第3章質量目標

本次須要完成三期後臺的開發，該期結束以後，用戶能夠正式切換進入系統進行試用，APP和後臺以及小程序是一個完整的閉環。 需求中提出的功能已完成且測試經過，在線上系統能夠正常穩定運行。

3.1產品質量目標

用戶正式試用，環境穩定運行無異常。

測試質量目標	確認者（如需說明）
測試已實現的產品UI是否達到設計的要求
已實現的功能是否符合產品PO的預期，包括：各個功能點是否以實現，業務流程是否正確
全部的測試案例已經執行過
每一部分的測試已經被Test Lead確認完成
全部的重要等級爲的Bug已經解決並由測試驗證
產品規定的操做和運行穩定

第4章 資源需求

4.1培訓資料

培訓需求	培訓內容	培訓人員	開始時間	完成時間
業務流程	管理後臺的使用流程	張**
用戶操做說明	用戶操做手冊培訓

4.2測試環境

4.2.1硬件測試環境

服務器配置

機型（配置）	IP地址	操做系統	用途及特殊說明	軟件及版本	預計空間
ubuntu01	***	ubuntu16	服務器	***
ubuntu02		K8S服務
ubuntu03		docker服務..

客戶端配置

機型（配置）	IP地址	操做系統	用途及特殊說明	軟件及版本	預計空間
ThinkVision、16G內存	***	win10企業版	客戶機	Chrome74-32位
錘子手機		Android7.0
iPhone7p		IOS10.0

4.2.2軟件測試環境

軟件需求	用途
mysql數據庫
rabbit
...	...

4.3測試工具

此項目將列出測試使用的工具以及用途：

測試工具	用途
自動測試工具：selenium+python	自動化迴歸測試
JIRA	bug管理
confluence	項目管理工具
postman	接口自動化測試
JMeter	性能/接口自動化測試
...	...

第5章 測試策略

5.1 總體測試策略

使用里程碑技術在測試過程當中驗證每一個模塊，測試人員在需求評審階段參與測試工做，進行需求review、設計review、測試案例設計和測試開發。在系統開發完成以後，開發自測完成，正式進入執行測試階段。產品達到軟件產品質量要求和測試要求後發佈，並提交相關測試文檔。

5.2開始/中斷/完成標準

說明中斷/開始/完成測試的標準。

開始/中斷/完成測試	標準說明
開始測試標準	硬件環境可用且軟件正確安裝完成
中斷測試標準	安裝沒法正確完成或程序的文檔有至關多的失誤或系統服務異常或發現Block Bug
完成測試標準	完成測試計劃中的測試規劃並達到程序和測試質量目標,並由Test Lead/R&D Manager確認

5.3測試類型

測試類型	是否採用	說明
功能測試	採用	根據系統需求規格說明書、原型和設計文檔，檢查產品是否正確實現了功能。
流程測試	採用	按操做流程進行的測試，主要有業務流程、數據流程、邏輯流程、正反流程，檢查軟件在按流程操做時是否可以正確處理
邊界值測試	採用	選擇邊界數據進行測試，確保系統功能正常，程序無異常。
容錯性測試	採用	檢查系統的容錯能力，錯誤的數據輸入不會對功能和系統產生非正常的影響，且程序對錯誤的輸入有正確的提示信息
異常測試	採用	檢查系統可否處理異常
啓動中止測試	採用	檢查每一個模塊可否正常啓動中止、異常中止後可否正常啓動
安裝測試	採用	檢查系統可否正確安裝、配置
易用性測試	採用	檢查系統是否易用友好
界面測試	採用	檢查界面是否美觀合理
接口測試	採用	檢查系統可否與外部接口正常工做
配置測試	採用	檢查配置是否合理、配置是否正常
安全性和訪問控制測試	採用	應用程序級別的安全性：檢查Actor只能訪問其所屬用戶類型已被受權訪問的那些功能或數據。系統級別的安全性：檢查只有具有系統和應用程序訪問權限的Actor才能訪問系統和應用程序。
兼容性測試		須要考慮瀏覽器的兼容性以及不一樣手機類型的兼容性(FireFox\chrome\QQ瀏覽器等；華爲手機\iPhone手機\小米\vivo等手機)
迴歸測試	採用	檢查程序修改後有沒有引發新的錯誤、是否可以正常工做以及可否知足系統的需求
...	...	...

5.4 測試技術

測試技術	是否採用	說明
里程碑技術	採用	里程碑的達成標準及驗收方法在測試完後製訂
審評測試	採用	對軟件產品功能說明文檔和設計說明文檔進行檢查，在需求與設計階段進行
編寫測試用例	採用	在產品編碼階段編寫測試用例
集成測試	採用	檢測模塊集成後的系統是否達到需求對業務流程及數據流的處理是否符合標準、系統對業務流處理是否存在邏輯不嚴謹及錯誤以及是否存在不合理的標準及要求。
確認測試	採用	在產品發佈前，對照feature list 進行基本需求的確認，確認產品是否正確實現了功能。
系統測試	採用	包括迴歸測試
驗收測試	不採用	由工程實施人員進行
...	...	...

咱們要根據不一樣的測試類型考慮不一樣的測試方法，對於功能測試，咱們根據需求分析的思惟導圖和功能測試的測試用例覆蓋需求列表；兼容性測試，咱們要根據產品的應用場景來考慮，好比IE、Chorme、ios、android、不一樣機型等等；性能測試，根據產品架構、預估數據、線上數據來判斷須要執行性能測試的功能接口（好比登陸接口）；接口測試，安全性測試等等要根據實際的項目需求來肯定。

第6章 測試計劃

6.1進度計劃

主要包括里程碑計劃，包括階段、里程碑、資源等。

6.1.1測試時間進度

測試階段	開始時間	完成時間	測試人員	階段完成標誌
制定測試計劃	2019-05-01	2019-05-14	張**	輸出測試計劃說明書
需求Review				輸出需求說明書或原型
設計Review				輸出設計說明和原型
設計測試用例				輸出測試用例
測試實施
功能測試				功能模塊級別中以上bugs被修復，測試經過
集成測試				各個模塊間接口及功能bugs級別中以上bugs被修復，測試經過
系統測試				需求說明書中的功能所有實現且測試經過
驗收測試				產品和UI驗收經過
文檔編寫				輸出測試報告

6.1.2測試里程碑

里程碑	完成時間	完成標準
測試正式開始		完成可接受性測試和冒煙測試
測試執行	執行測試	完成全部里程碑測試和標準測試,測試種類包括確認測試和系統測試,且全部以發現的Bug等級爲很是嚴重/嚴重/中的Bug已修復,近期內無發現新的Bug等級爲很是嚴重/嚴重/中的Bug，等級低的bug根據實際項目時間安排擇優處理。
產品Release		重複進行主路徑測試和進行Bug檢查測試,產品處於可交付狀態並由測試經理和高級經理確認

6.2測試準備

6.2.1 測試環境準備

準備事項	開始時間	完成時間	測試人員	階段完成標誌
測試環境準備

6.2.2 安裝測試

準備事項	開始時間	完成時間	測試人員	階段完成標誌
安裝測試

6.2.3 冒煙測試

準備事項	開始時間	完成時間	測試人員	階段完成標誌
冒煙測試

6.3 具體測試實施任務和時間人員安排

測試功能點	開始時間	完成時間	測試人員	說明

以上是測試計劃實際狀況中的一個文檔輸出，那麼咱們如何才能輸出這樣文檔呢？

根據文檔內容要求，咱們須要肯定測試目標、測試範圍和測試策略，以及根據測試範圍和測試策略進行測試時間、人力等資源的安排等這幾個重點。

那麼如何肯定測試目標呢？

測試目標是有質量目標來肯定的，而質量目標則從如下三個維度來講明

1. 產品的商業價值：是質量第一仍是快速上線
2. 根據項目鐵三角原則：肯定是快速上線仍是0bug上線
3. 根據線上項目事故率：這個也是測試績效考覈的一個點，線上無P0和P1的事故

根據以上3點肯定測試計劃的測試目標。

如何確立測試範圍呢？

通常狀況下，測試範圍是根據需求文檔和原型綜合評判得出測試計劃的測試範圍，這裏通常狀況下建議使用思惟導圖進行需求分析，這裏主要有需求優先級、、需求的關聯功能、識別測試重點等肯定測試範圍，得出測試的關鍵功能、主要功能、強關聯功能 、次要功能、弱關聯功能等。

肯定測試策略

總體測試策略

1. 業務和技術深度掌握：深挖業務場景，掌握業務相關的接口
2. 多樣化的測試策略：主要有業務場景、交互，UI，兼容性，數據邏輯，業務邏輯，性能測試等多角度進行分析測試
3. 組內組外的充分溝通：在敏捷開發中顯得更加劇要

版本測試策略

1. 針對不一樣功能和優先級採用不一樣的測試策略：P1優先級的功能則須要用例的詳細設計，充分考慮用戶的實際使用場景，覆蓋功能的各類細節和異常狀況，在第一輪測試完成以後，P1的第二輪則通常是進行探索性測試，肯定所涉及的場景基本都被覆蓋。針對P2優先級的功能則須要用例的詳細設計，覆蓋用戶的各類實際使用場景，通常在第一輪測試完成以後，不須要第二輪的探索測試。而對於P3功能通常是直接進行測試要點的編寫，進行探索性測試便可。P4的功能通常是直接根據需求文檔進行測試。固然若是產品的商業價值可能不一樣的需求的優先級則有所不一樣，須要實際項目實際操做。
2. 交叉抽測和迴歸測試

如何制定工期、人員安排、進度安排

工期的評定

1. 出卡牌的方式
2. 頭腦風暴

人員安排

1. 須要考慮任務的關聯度和重要程度
2. 人員工做量分佈

進度安排

1. 提測時間安排
2. 通常使用甘特圖進行進度安排
3. 根據功能的優先級和重點以及人員的工做量狀況，排定進度表

里程碑進度安排

根據上面的進度安排制定的甘特圖，可能會出現顆粒度太細，沒法一目瞭然瞭解項目進度狀況，因此這個時候就須要里程碑，經過里程碑，劃分里程碑的進度。能夠根據不一樣的模塊相對大小劃分里程碑，這裏須要注意要加入測試前期的測試用例編寫的時間安排以及測試迴歸時所消耗的時間。

其餘影響

1. 研發計劃
2. 風險處理：須要根據風險的歷史庫和預先識別的風險制定風險策略
3. 研發流程：若是說項目質量要求比較高，咱們可能還須要制定冒煙測試計劃、單元測試、集成測試等

經過上面的測試計劃內容以及如何制定測試計劃的詳細說明，相信你能夠根據項目狀況制定一份確實可行的測試計劃啦，立刻行動起來吧......