測試計划模板的編寫

 

1 概述

在整個系統測試階段,相關的系統測試工作的開展需要進行各方面的明確,在系統測試計划中主要是針對系統測試階段各個不同崗位所擔負的相關職責,防范由於職責不清所造成的系統測試工作的混亂現象.明確定義相關的系統測試范圍,防止由於測試分工而造成的遺測.在該計划中一定要對系統測試過程中可能出現的各種風險進行預防和規避.

1.1 文檔目的

本文檔主要闡述xxx統測試計划。

xxxxx對今后軟件開發人員概要設計、詳細設計和編碼有着重要的指導作用。

1.2 文檔讀者

測試人員、研發人員、項目管理人員。

1.3 文檔范圍

所屬產品	所屬模塊	需求名稱
Xxxxx

 

2 用戶需求概述

xxxxxxxxxxx

3 系統功能需求

xxxxxxxxxx

4 參考資料

參照文檔《xxxxx-需求規格說明書》

5 條件與限制

測試限制條件主要存在於大屏測試和三方工具調用：

1. 測試工具：需要使用Jmeter在PC上模擬在線用戶數量峰值和正常值。（視項目情況是否需要性能測試）
2. 測試人員時間：由於測試人員時間有限，無法全覆蓋所有的條件組合，只對測試用例全覆蓋進行測試。
3. 三方工具調用：多部門、多公司聯合開發，聯調、配合時間存在一定的風險性。

 

6 測試方案

6.1 測試環境

6.1.1 PC測試

瀏覽器

 

瀏覽器	備注
Google	全功能測試
FireFox	兼容性測試
360	兼容性測試
IE 11及以上	兼容性測試
Opera	兼容性測試

 

6.2 測試類型

6.2.1 測試需求列表

                                測試需求列表（2019/xx/xxxx)

所屬產品	所屬模塊	需求名稱	測試類型
xxx

 

6.2.2 功能測試

測試對象：測試需求列表（見禪道需求點）里所有標注“功能測試”的需求，需進行全面功能測試。

測試標准及要點：按照測試用例執行。

測試用例：在執行前需進行內部評審，並用禪道工具進行執行狀況跟蹤。

6.2.3 性能測試

PS:視情況是否需要性能測試

測試對象：測試需求列表（見禪道需求點）里所有標注“性能測試”的需求

測試工具：Jmeter，在PC上對系統進行施壓

測試時間：所有功能的性能測試需在相應功能模塊完成並通過功能測試后再執行

 

測試場景

分類	用戶量	指標	優先級	備注
事務處理類	300 （非高峰期）	前端系統訪問響應時間≤5秒	中	前端系統指標測試需結合Jmeter的報告   后端CPU利用率可使用Jmeter插件在服務器安裝，Jmeter自動監控；若不允許裝插件，則使用人工監控記錄
查詢類	300  （非高峰期）	前端系統訪問響應時間≤2秒 后端CPU利用率<=50% 后端內存利用率<=50%	高
	1000 （高峰期）	系統訪問響應時間≤10秒 后端CPU利用率<=70% 后端內存利用率<=70%	高
	3000 （極限）	系統未崩潰 請求未返回大量錯誤	低
統計類	簡單統計類	系統響應時間≤10秒	中	手動啟動業務全過程跟蹤
	復雜統計類	系統響應時間≤30秒	中	手動啟動運行月報

6.2.4 易用性測試

測試對象：測試需求列表（見禪道需求點）里所有標注“易用性”測試的需求。

測試內容：

1. 應用系統提供一致性的中文圖形用戶界面、顏色統一、協調、美觀。字體應統一大小。
2. 應用系統對普通用戶的操作界面應該以B/S方式實現。
3. 應用系統必須支持同時打開多個管理窗口以對不同任務進行並行的操作。
4. 應用系統應該支持通過Tab鍵或回車鍵可以訪問到同一個窗口的所有空間對象。
5. 查詢時，若為日期條件、數值條件支持范圍查詢。
6. 查詢時，若為字符型條件支持模糊查詢。
7. 系統必須采用分頁機制顯示查詢結果，並顯示返回的記錄數目、當前頁和總頁數。
8. 應用系統的查詢統計結果可以轉存為EXECL等常見格式文件。
9. 應用系統發現用戶提交有誤信息，必須以彈出窗口的形式明確提示用戶錯誤的原因，並把界面控制焦點置於發生錯誤的控件對象上。
10. 應用系統的操作界面必須明確標識出必填的輸入信息。
11. 在導致系統數據發生變化的操作執行之前，系統應該彈出提示窗口供用戶確認。
12. 對於復雜的信息結構，系統應該采用分欄的機制在同一個窗口中顯示不同的信息內容，並自動刷新不同部分的信息內容。
13. 當應用系統正在執行用戶提交的請求而無法返回時，必須明確標識系統處於繁忙階段。
14. 應用系統功能菜單必須按照功能域、功能項的分類方法進行組織。
15. 對於操作員無權限使用的菜單功能，應用系統不顯示該菜單或將其設置為不可用狀態。
16. 系統必須提供在線幫助功能，對於每一個操作功能都能查找到相應的詳細使用說明。
17. 操作員登錄系統后，系統必須能夠主動地提醒等待該操作員處理的任務。
18. 應用系統提供FAQ功能，支持常見問題的管理、發布等。
19. 應用系統提供問題管理功能，支持常見問題的收集、反饋等。
20. 經常性的面向基層的具體崗位的業務處理界面必須簡潔、實用、直觀，數據信息分層顯示，常用的排前，不常用的靠后或消隱。
21. 操作鍵序符合工作處理步驟，能自動跳轉，以提高日常業務處理效率。

6.2.5 安全性測試

測試對象：測試需求列表（見禪道需求點）里所有標注“安全性”測試的需求。

測試內容：

1. 登錄/注銷：對用戶進行身份識別和鑒別；登錄失敗后，采取結束會話、限制非法登錄次數和當網絡登錄連接超時自動退出等措施；登錄時采用加密技術
2. 執行“刪除”、“退出”等有風險操作時，應有“確認”、“放棄”提示對話框。
3. 身份鑒別信息具有不易被冒用的特點，口令有復雜度要求，如口令長度至少八位以上，同時包含字母、數字、特殊字符等，並定期更換口令。
4. 系統應該對用戶在客戶端輸入或導入的數據進行長度、范圍、數據類型等屬性的合法性進行檢驗，對不合法的數據應該禁止輸入系統，並且提示明確的錯誤信息。
5. 系統應該在服務器端對將要存儲到后台數據庫中的數據進行合法性檢驗，對不合法的數據應該舍棄，並報警。
6. 系統應該能夠允許多用戶同時對同一個系統資源進行不相沖突的訪問操作，並且設定保護措施，防止相互可能造成的沖突。
7. 系統應該禁止客戶端用戶執行相互矛盾的操作，例如兩個用戶同時修改一個資源。

6.2.6 兼容性測試

測試對象：測試需求列表（見禪道需求點）里所有標注“兼容性”測試的需求，參考如下。

測試內容：

1. 瀏覽器兼容測試：測試程序在不同瀏覽器上是否可以正常運行，功能能否正常使用；
2. 屏幕尺寸和分辨率兼容測試：測試程序在不同分辨率下能否正常顯示；
3. 操作系統兼容測試：測試程序在不同的操作系統下面能否正常運行，功能能否正常使用，顯示是否正確等；
4. 不同設備型號兼容測試：針對於APP，現在移動設備型號五花八門，主要測試APP在主流設備上能否正常運行，會不會出現崩潰的現象。

6.2.7 可移植性測試

測試對象：測試需求列表（見禪道需求點）里所有標注“可移植性”測試的需求，參考如下。

測試內容：

1. 可安裝性測試：使用安裝向導或遵照安裝手冊的步驟（包括執行必需的安裝腳本），功能是否可以成功地進行軟件安裝。
2. 共存性/兼容性測試：不存在相互依賴關系的計算機系統可以在同一環境（例如：同一個硬件平台）中運行，而不影響彼此的行為（如資源沖突）
3. 適應性測試：測試一個應用程序是否能夠在所有特定的目標環境（硬件、軟件、中間件、操作系統等）中正確地運行。
4. 可替換性測試：在集成過程中會有一些可替換的組件集成構成一個完整的系統。

6.3 測試策略

6.3.1 基本功能測試

對測試對象的功能測試應側重於所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。此類測試基於黑盒技術。

表6-1 功能測試策略

測試目標	確保測試的功能正常，其中包括導航，數據輸入，處理和檢索等功能。
測試范圍	需求中明確的功能項。
技術	利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內容： 1.在使用有效數據時得到預期的結果。 2.在使用無效數據時顯示相應的錯誤消息或警告消息。 3.各業務規則都得到了正確的應用。
開始標准	所有功能均已完成，並已提交測試。
完成標准	所計划的測試已全部執行。所發現的缺陷已全部解決。
需考慮的特殊事項	無

 

6.3.2 用戶界面及易用性測試

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

表6-2 用戶界面測試策略

測試目標	1.通過測試進行的瀏覽可正確反映業務的功能和需求，包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab鍵、鼠標移動、和快捷鍵）的使用； 2.窗口的對象和特征（例如，菜單、大小、位置、狀態和中心）都符合標准。
測試范圍	系統業務應用模塊的所有子系統。
技術	為每個窗口創建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，並處於正常的對象狀態。
開始標准	所有項目功能均可正常進行。
完成標准	成功地核實出各個窗口都與基准版本保持一致，或符合可接受標准。
需考慮的特殊事項

 

7 測試計划

7.1 測試資源

                                     測試人員表

姓名	角色	角色描述	具體職責
xxxx	測試主任	研發測試質量管理	協調溝通任務、評審測試用例、制定測試計划、輔助測試
xxxx	測試人員	研發測試	制定測試計划、編寫測試報告、編寫測試用例、執行測試、編寫用戶操作手冊

 

7.2 測試進度安排

                        測試任務安排（第一期 – 預發布時間2019/9/10）

任務標號	任務名稱	工期（天）	開始時間	結束時間	人員
1	測試准備	4	2019/8/27	2019/8/30	xxxx
2	執行數據測試	5	2019/9/2	2019/9/6	xxxx
3	執行功能測試	2	2019/9/5	2019/9/6	xxxx
4	執行驗收測試	2	2019/9/9	2019/9/10	xxxx
5	編寫系統測試報告	3	2019/9/11	2019/9/13	xxxx
6	編寫操作手冊	3	2019/9/12	2019/9/14	xxxx

具體任務安排請參考禪道需求點

***禪道需求點***

 

7.3 測試准備工作

                             測試准備工作

測試類型	測試准備內容	負責人	截止日期
所有	修訂測試計划	xxxx	xxxx
功能測試 易用性測試	編寫測試用例	xxxx	xxxx
	測試環境搭建	xxxx	xxxx
	評審測試用例	xxxx	xxxx
兼容性測試 可移植性測試	軟件資源（瀏覽器）	xxxx	xxxx
性能測試	選定性能測試場景、測試工具 制定性能測試步驟	xxxx	xxxx
驗收測試	驗收測試場景、用例	xxxx	xxxx

7.4 風險評估

風險評估

風險分析	預防措施	責任人
測試開始時間受制於開發進度，若開始時間較晚，可能無法在預定的交付時間完成所有測試	隨時跟蹤開發進度調整測試時間計划，若發現測試開始時間較已設定時間延遲時間太長，與項目經理溝通，在進度、范圍、質量之間進行平衡。	xxxxx
測試周期時間可能會受開發質量影響，如bug太多則會延長測試時長	與相應團隊成員分析質量原因 與項目管理團隊溝通是否在進度、范圍、質量之間進行平衡	xxxxx
硬件性能的風險	本系統涉及到后端大量數據的比對及清洗，對系統硬件本身的運算能力、存儲等有較高要求。如果硬件性能無法得到保障，將導致數據清洗時間過長、系統運行緩慢，影響較大。
網絡環境的風險	本系統是部署在電子政務外網及互聯網兩個網絡之中，並且大部分功能都需要進行數據查詢及網絡通信，因此網絡環境決定了查詢及應用速度的快慢，如果不能保證良好的網絡環境，將對系統造成一定影響
第三方軟件部署的風險	本系統所采購第三方軟件均是嚴格對應標書的技術標准，並且系統部署時，所有的軟件提供商均會現場進行部署和支撐，因此該風險較小。
開發技術的風險	系統前端使用技術：ES6/React，Webpack,Node.js，Canvas。前端風險可能主要在使用了大量HTML5技術，對老舊瀏覽器的兼容性支持不好。推薦使用IE10+或Chrome、Firefox瀏覽器，並且會在系統提供相應瀏覽器下載。后端使用技術：Java8, Spring Boot 1.4。后端使用了成熟的Java EE技術，采用了Spring技術棧。

7.5 系統測試進入准則

系統測試進入准則

標准名稱	標准說明	風險
測試用例	測試用例通過測試內部評審、以及其他項目團隊成員同意（如項目經理）	說明：每個功能測試的測試用例編寫測試要點、測試步驟、預期結果、實際結果。因此測試時，不同測試人員的操作具有一定的局限性，對用例可能會有不同的理解。 控制：測試人員在測試前都參與用例的評審，熟悉每個測試用例的測試要點，及設計目的，以保證用例規定的所有要點都被覆蓋。
需求	需求需要測試人員、開發人員評審通過，並上傳至禪道	說明：需求理解的不同，測試人員、開發人員在編寫用例、編寫代碼存在一定的誤差。 控制：在每次編寫用例、代碼前，與需求人員對需求進行評審，達成一致在進行執行操作。
概要/詳細設計	概要/詳細設計需要項目人員、測試人員評審通過，並上傳至禪道
功能	功能開發完成	說明：開發人員提交功能至測試環境。 控制：在禪道上創建測試版本，開發人員提交版本說明，包括該版本中新增加的功能特性、修改的缺陷、可能存在的問題以及測試重點的建議等
冒煙測試	開發單元測試完成 系統冒煙測試通過
性能測試	性能測試場景方案制定完成，並且通過測試內部評審、項目經理同意	說明：對系統非高峰期和高峰期的用戶數量並未明確說明 控制：與項目經理進行確認、可以多測幾組數據，如1000、2000、3000

 

7.6 系統測試退出准則

系統測試退出准則

標准名稱	標准說明	風險控制說明
最低標准	測試用例：覆蓋率100%，通過率90% 遺留bug： 不存在嚴重程度為“1”和“2”的bug 嚴重程度為“3”的bug數量≤15	將未通過的測試用例導出與項目經理分析並確認是否可接受 在階段結束之前，與項目經理和其他項目團隊成員確認需在交付前解決的bug 清單
合理標准	測試用例：覆蓋率100%，通過率95% 遺留bug： 不存在嚴重程度為“1”和“2”的bug 嚴重程度為“3”的bug數量≤10
較高標准	測試用例：覆蓋率100%，通過率98% 遺留bug：無

 

Bug等級說明：

嚴重程度為1（致命）：系統崩潰、中斷、死機、數據丟失、安全問題、主要功能未實現、嚴重錯誤且沒有應急解決方案、系統性能嚴重低於最低要求

嚴重程度為2（嚴重）：數據錯誤、程序邏輯錯誤

嚴重程度為3（一般）：功能小錯誤且有應急解決方案

嚴重程度為4（輕微）：人機交互或界面優化建議、提示語等拼寫小錯誤，不影響用戶正常使用。