軟件測試方案的編寫

重慶市XXXX（標題）

系統測試方案 

 

重慶XXXXX有限公司

2018年5月

1.項目概述

1.1.測試目的

本測試方案為XXXX項目的測試方案，目的是針對系統測試過程進行一個完整的安排，同時對重慶市信用信息應用平台二期工程LED大屏及配套改造的各個模塊進行整理，給測試人員及相關人員提前了解相關的計划安排。

1.2.測試目標

XXXX項目的測試目標是實現項目需求正確理解、開發按需求進行編制編碼，業務功能實現正常，測試驗證BUG達到上線標准。

1.3.測試人員

XXXX項目測試人員、項目管理人員。

1.4.測試參考文檔

《重慶市XXXX-招標文件》

《重慶市XXXX-投標文件》

《重慶市XXXX-需求規格說明書》

《重慶市XXXX-系統詳細設計說明書》

《重慶市XXXX-數據庫設計說明書》

《重慶市XXXX-接口設計說明書》 

2.用戶需求概述

系統名稱	功能名稱	內容描述

3.設計運行環境

3.1.網絡環境要求

運行環境為政務外網環境和互聯網環境，通過網閘和防火牆進行隔離。

序號	需求項	需求參數
1	互聯網出口帶寬	>=200M
2	互聯網和電子政務外網互聯	>=1000MB
3	互聯網內部網絡	>=10000MB
4	電子政務外網內部網絡	>=10000MB
5	內網網絡延遲	<30ms
6	外部網絡延遲	<50ms
7	Packets丟包率	<0.01%/1000s

 

4.測試方案

4.1.測試環境

瀏覽器

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

 

屏幕大小及分辨率

屏幕大小	分辨率	備注
15.6 英寸	1920 * 1080	兼容性測試
15.6 英寸	1280 * 720	兼容性測試
23.8英寸	1920 * 1080	兼容性測試

 

4.2.測試需求

4.2.1.測試需求列表

序號	功能名稱	測試類型
1	1.1供給側-第一產業	功能測試、數據測試
2	1.2供給側-第二產業	功能測試、數據測試

 

4.2.2.功能測試

測試對象：測試需求列表（見章節4.2.1）里所有標注“功能測試”的需求。

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

4.2.3.性能測試

測試對象：測試需求列表（見章節4.2.1）里所有標注“性能測試”的需求

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

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

分類	用戶量	指標	優先級	備注
登錄	100 （高峰期）	系統平均響應時間≤0.2秒 系統最大響應時間≤0.5秒	中	前端系統指標測試需結合Jmeter的報告   后端CPU利用率可使用Jmeter插件在服務器安裝，Jmeter自動監控；若不允許裝插件，則使用人工監控記錄
	300 （極限）	系統平均響應時間≤0.3秒 系統最大響應時間≤0.8秒	低
查詢、統計類	100並發 （普通查詢、統計）	系統平均響應時間≤0.2秒 系統最大響應時間≤0.5秒 后端CPU利用率<=50% 后端內存利用率<=50%	高
	100並發 （大數據量查詢、統計）	系統平均響應時間≤0.5秒 系統最大響應時間≤1秒 后端CPU利用率<=70% 后端內存利用率<=70%	高

4.2.4.易用性測試

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

測試內容：

1. 應用系統提供一致性的中文圖形用戶界面、顏色統一、協調、美觀。字體應統一大小。
2. 應用系統對普通用戶的操作界面應該以B/S方式實現。
3. 應用系統必須支持同時打開多個管理窗口以對不同任務進行並行的操作。
4. 應用系統應該支持通過Tab鍵或回車鍵可以訪問到同一個窗口的所有空間對象。
5. 查詢時，若為日期條件、數值條件支持范圍查詢。
6. 查詢時，若為字符型條件支持模糊查詢。
7. 系統必須采用分頁機制顯示查詢結果，並顯示返回的記錄數目、當前頁和總頁數。
8. 應用系統的查詢統計結果可以轉存為EXECL等常見格式文件。
9. 應用系統發現用戶提交有誤信息，必須以彈出窗口的形式明確提示用戶錯誤的原因，並把界面控制焦點置於發生錯誤的控件對象上。
10. 應用系統的操作界面必須明確標識出必填的輸入信息。
11. 在導致系統數據發生變化的操作執行之前，系統應該彈出提示窗口供用戶確認。
12. 對於復雜的信息結構，系統應該采用分欄的機制在同一個窗口中顯示不同的信息內容，並自動刷新不同部分的信息內容。
13. 當應用系統正在執行用戶提交的請求而無法返回時，必須明確標識系統處於繁忙階段。
14. 應用系統功能菜單必須按照功能域、功能項的分類方法進行組織。
15. 對於操作員無權限使用的菜單功能，應用系統不顯示該菜單或將其設置為不可用狀態。

4.2.5.安全性測試

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

測試內容：

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

5.測試計划

5.1.測試人員

表５－1－１：測試人員

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

 

5.2.測試准備工作

表５－2－１：測試准備工作

測試類型	測試准備內容	負責人
所有	編寫測試計划	XXXX
功能測試 易用性測試	編寫測試用例	XXX
	評審測試用例	XXXX
兼容性測試	軟件資源（各個瀏覽器）	XXXX

5.3風險評估

表５－3－１：風險評估

風險分析	預防措施	責任人
測試開始時間受制於開發進度，若開始時間較晚，可能無法在預定的交付時間完成所有測試	隨時跟蹤開發進度調整測試時間計划，若發現測試開始時間較已設定時間延遲時間太長，與項目經理溝通，在進度、范圍、質量之間進行平衡。	XXXX
測試周期時間可能會受開發質量影響，如bug太多則會延長測試時長	與相應團隊成員分析質量原因 與項目管理團隊溝通是否在進度、范圍、質量之間進行平衡	XXXX
測試人員對需求的熟練程度、詳細設計文檔的熟悉程度	盡量按照測試用例對所有功能進行全面覆蓋。	XXXX

5.4.系統測試進入准則

表５－4－１：系統測試進入准則

標准名稱	標准說明	風險
測試用例	測試用例通過測試內部評審、以及其他項目團隊成員同意（如項目經理）	說明：由於個人的測試思維和時間關系，測試時可能會有一定的疏漏，測試操作也具有一定的隨機性，不會按部就班。 控制：測試人員在測試前都參與用例的評審，熟悉每個測試用例的測試要點，及設計目的，以保證用例規定的所有要點都被覆蓋。
冒煙測試	開發單元測試完成 系統冒煙測試通過	說明：編寫系統測試用例之前，先准備好冒煙測試用例，待所有的冒煙測試用例（開發版）由開發人員執行通過完后，測試人員方可進行冒煙測試（測試版）和系統測試用例的執行 控制：冒煙測試用例主要針對各頁面元素檢查、主體流程的功能及頁面各鏈接和按鈕跳轉是否正確進行測試。

5.5.系統測試退出准則

表５－5－１：系統測試退出准則

 

標准名稱	標准說明	風險控制說明
最低標准	測試用例：覆蓋率100%，通過率90% 遺留bug：所有嚴重程度為“1”的修復完畢並通過驗證；存在少量嚴重程度為“2”；	將未通過的測試用例導出與項目經理分析並確認是否可接受 在階段結束之前，與項目經理和其他項目團隊成員確認需在交付前解決的bug list
合理標准	測試用例：覆蓋率100%，通過率95% 遺留bug：所有嚴重程度為“1”和“2”的bug修復完畢並通過測試驗證
較高標准	測試用例：覆蓋率100%，通過率99% 遺留bug：只存在少量嚴重程度“3”和“4”的並且其優先級也為“3”或者“4”

 

Bug等級說明：

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

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

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

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

 

6.測試用例

6.1.功能測試用例

用例標題	步驟	預期
1.1供給側-第一產業	1. 點擊重慶市宏觀經濟運行大數據展示系統 2.查看第一產業的數據正確性 3.查看第一產業的功能點信息正確性	1. 進入網站首頁，查看數據正確性顯示 2.數字每三位逗號隔開，單位為億元。 3.內容：標題（第一產業）、第一產業增加值（季度累計）、XX,XXX億元、累計同比（XX）、重慶與全國均值折線圖顯示、季度趨勢圖顯示

6.2.性能測試用例 

用例標題	步驟	預期
001-1000用戶並發統一社會信用代碼查詢	1. JmeterGUI模式下創建線程組，並將線程數設置為1000 2. 減少負載機資源不足影響，調整ramp-up period為10秒，即用戶啟動及准備時間為10秒 3. 新增事務控制器 3.1 添加登錄接口進行登錄 3.2 添加“統一社會信用代碼”查詢接口，在該接口上添加Synchronizing Timer集合控制組件，並設置模擬1000用戶集合后才執行請求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式執行腳本后分析結果	1. 2. 3. 4.平均響應時間≤2秒，最長響應時間不超過5秒;后端CPU利用率<=50%，后端內存利用率<=50%
002-1000用戶並發登錄	1. JmeterGUI模式下創建線程組，並將線程數設置為1000 2. 減少負載機資源不足影響，調整ramp-up period為10秒，即用戶啟動及准備時間為10秒 3. 添加登錄接口進行登錄，在該接口上添加Synchronizing Timer集合控制組件，並設置模擬1000用戶集合后才執行發請求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式執行腳本后分析結果	1. 2. 3. 4.平均響應時間≤2秒，最長響應時間不超過5秒
003-3000用戶並發登錄	1. JmeterGUI模式下創建線程組，並將線程數設置為3000 2. 減少負載機資源不足影響，調整ramp-up period為10秒，即用戶啟動及准備時間為30秒 3. 添加登錄接口進行登錄，在該接口上添加Synchronizing Timer集合控制組件，並設置模擬3000用戶集合后才執行發請求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式執行腳本后分析結果	1. 2. 3. 4.平均響應時間≤3秒，最長響應時間不超過8秒
003-1000用戶並發企業信用詳情查看	1. JmeterGUI模式下創建線程組，並將線程數設置為1000 2. 減少負載機資源不足影響，調整ramp-up period為10秒，即用戶啟動及准備時間為10秒 3. 新增事務控制器 3.1 添加登錄接口進行登錄 3.2 添加“企業信息詳情”查詢接口，在該接口上添加Synchronizing Timer集合控制組件，並設置模擬1000用戶集合后才執行請求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式執行腳本后分析結果	1. 2. 3. 4.平均響應時間≤5秒，最長響應時間不超過10秒;后端CPU利用率<=70%，后端內存利用率<=70%