1.1目的
本計劃將要對軟體系統進行一系列的測試，黑盒、白盒、內測、試運營、公測、運營等階段。
|
工作內容 |
人數（人） |
工作時間（日） |
|
產品策劃、功能設計 |
1 |
3 |
|
互動設計 |
1 |
10 |
|
佈局設計 |
2 |
10 |
|
介面設計 |
1 |
5 |
|
程式開發 （Android客戶端、server工程師） |
4 |
15 |
|
產品測試 |
5 |
5 |
|
共計 |
* |
48 |
產品測試一共5天，黑盒1一天，白盒2天，其餘一共3天。
1.2名詞解釋
|
縮寫詞或術語 |
英文解釋 |
中文解釋 |
|
Debug |
進行debug除錯 |
|
|
|
|
|
1.3參考資料
《構建之法》、《軟體工程導論》
1.4測試摘要
本次針對“醫天下”系統進行各方面的測試，包括軟體系統的效能，bug的修復程度，是否有卡頓，以及一些更強烈的使用者體感。
1.4.1 重點事項
1、購物車支付過程中的安全事務。
2、路線規劃的準確度。
3、是否有延遲問題。
1.4.2 爭議事項
佈局方面存在著較大爭議。
1.4.3 風險評估
預計在系統的開發過程中，佈局問題是使用者體感覺得不好的地方，應該增強一下使用者的體感，還有就是功能遠遠不能滿足使用者（功能量少）。
1.4.4 測試目標
首先，可以保證系統的執行情況；
其次，系統漏洞bug需要不斷的修復；
再次，使用者體感不斷的增加；
最後，達到運營階段。
第2章專案背景
2.1測試範圍
說明本計劃涵蓋的測試範圍，比如功能測試、整合測試、系統測試、驗收測試等。通常說明什麼是要測試的，什麼是不要測試的是非常重要的。明確規定這些問題後，測試人員對該做什麼有一個清晰的認識。
功能測試：
<1>測試路線規劃功能是否準確
<2>測試線上掛號功能是否可行
<3>測試線上尋求專家是否卡頓
<4>測試線上購藥系統是否出現一些致命性的漏洞
系統測試：
<1>測試系統是否能夠正常執行
<2>測試系統執行是否卡頓
2.2聯絡方式
列出專案參與人員的職務、姓名、E-mail 和電話。
|
職務 |
姓名 |
|
電話 |
|
開發工程師 |
朱雲鋮 |
Zhuyuncheng1994@qq.com |
136****6326 |
|
CVS Builder |
李偉 |
136****2372 |
|
|
開發經理 |
朱雲鋮 |
136****6326 |
|
|
測試負責人 |
劉世賢 |
136****9021 |
|
|
測試人員 |
黃彥瀟 |
Huangyanxiao@qq.com |
136****0071 |
2.3測試文件
列出測試過程中可能用到的參考文件、相關的設計文件以及儲存位置，測試完成後應產生的文件。
2.5.1測試參考文件
|
文件說明 |
作者 |
文件位置（CVS） |
|
需求文件 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
總體設計 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
白皮書 |
劉世賢 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
使用手冊 |
李偉 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
管理手冊 |
李偉 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
測試文件 |
黃彥瀟 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
API文件 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
|
|
|
2.5.2測試提交文件
|
文件說明 |
作者 |
文件位置（CVS） |
|
《總體測試計劃》 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《總體測試方案》（可根據專案情況進行裁剪） |
劉世賢 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
測試用例 |
劉世賢 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《效能測試方案（報告）》 |
李偉 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《測試報告》 |
黃彥瀟 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《Readme》 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《產品操作手冊(後臺)》 |
劉世賢 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《產品操作手冊(前臺)》 |
朱雲鋮 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《產品安裝維護手冊》 |
李偉 |
https://github.com/zyc8023/Ivan/blob/master/ |
|
《產品錯誤程式碼說明文件》 |
李偉 |
https://github.com/zyc8023/Ivan/blob/master/ |
第3章質量目標
3.1產品質量目標
可以是產品的質量達到什麼樣的目標，產品的流程聯通性達到什麼樣的要求。
|
測試質量目標 |
確認者（如需說明） |
|
測試已實現的產品是否達到設計的要求，包括：各個功能點是否以實現，業務流程是否正確 |
朱雲鋮 |
|
產品規定的操作和執行穩定 |
朱雲鋮 |
3.2測試質量目標
評價測試質量的目標可以有：
|
測試質量目標 |
確認者（如需說明） |
|
所有的測試案例已經執行過 |
朱雲鋮 |
|
所有的自動測試指令碼已經執行通過 |
李偉 |
|
所有的重要等級為1/2的Bug已經解決並由測試驗證 |
劉世賢 |
|
每一部分的測試已經被Test Lead確認完成 |
朱雲鋮 |
|
重要的功能不允許有等級為1/2/3的Bug |
劉世賢 |
|
一般的功能或與最終使用者不直接聯絡的功能不允許有等級為1/2的bug,且bug等級為3的問題不得超過1/功能 |
黃彥瀟 |
|
輕量的功能允許有少量2/3等級的錯誤 |
劉世賢 |
|
發現錯誤等級為1/2/3的Bug的速率正在下降並接近0 |
李偉 |
|
在最後的三天內沒有發現錯誤等級為1/2/3類的Bug |
朱雲鋮 |
第4章資源需求
4.1培訓資料
|
培訓需求 |
培訓內容 |
培訓人員 |
開始時間 |
完成時間 |
|
業務流程 |
Andriod |
Yul老師 |
6.15 |
6.20 |
|
安裝配置 |
佈局 |
Ivan老師 |
6.15 |
6.25 |
|
工具使用 |
Junit |
--- |
6.15 |
6.20 |
4.2測試環境
4.2.1硬體測試環境
“機型（配置）”：Android 2.2
“軟體及版本”：1.0
4.3測試工具
|
測試工具 |
用途 |
|
自動測試工具 |
用於測試軟體系統的整體效能 |
第5章測試策略
5.1 整體測試策略
使用各方面效能測試的工具，對本系統整體的效能進行一系列的測試。
5.2開始/中斷/完成標準
說明中斷/開始/完成測試的標準。
|
開始/中斷/完成測試 |
標準說明 |
|
開始測試標準 |
硬體環境可用且軟體正確安裝完成 |
|
中斷測試標準 |
安裝無法正確完成或程式的文件有相當多的失誤或系統服務異常或發現Block Bug |
|
完成測試標準 |
完成測試計劃中的測試規劃並達到程式和測試質量目標,並由Test Lead/R&D Manager確認 |
5.3測試型別
|
測試型別 |
是否採用 |
說明 |
|
功能測試 |
採用 |
根據系統需求文件和設計文件，檢查產品是否正確實現了功能。 |
|
流程測試 |
採用 |
按操作流程進行的測試，主要有業務流程、資料流程、邏輯流程、正反流程，檢查軟體在按流程操作時是否能夠正確處理 |
|
邊界值測試 |
採用 |
選擇邊界資料進行測試，確保系統功能正常，程式無異常。 |
|
容錯性測試 |
採用 |
檢查系統的容錯能力，錯誤的資料輸入不會對功能和系統產生非正常的影響，且程式對錯誤的輸入有正確的提示資訊 |
|
異常測試 |
採用 |
檢查系統能否處理異常 |
|
啟動停止測試 |
採用 |
檢查每個模組能否正常啟動停止、異常停止後能否正常啟動 |
|
安裝測試 |
採用 |
檢查系統能否正確安裝、配置 |
|
易用性測試 |
採用 |
檢查系統是否易用友好 |
|
介面測試 |
採用 |
檢查介面是否美觀合理 |
|
介面測試 |
採用 |
檢查系統能否與外部介面正常工作 |
|
配置測試 |
採用 |
檢查配置是否合理、配置是否正常 |
|
安全性和訪問控制測試 |
採用 |
應用程式級別的安全性：檢查Actor只能訪問其所屬使用者型別已被授權訪問的那些功能或資料。 系統級別的安全性：檢查只有具備系統和應用程式訪問許可權的Actor才能訪問系統和應用程式。 |
|
效能測試 |
採用 |
提取系統效能資料，檢查系統是否滿足在需求中所規定達到的效能。 |
|
壓力測試 |
採用 |
檢查系統能否承受大壓力，測試產品應該能夠在高強度條件下正常執行，不會出現任何錯誤。 |
|
相容性測試 |
採用 |
對於 C/S 架構的系統來說，需要考慮客戶端支援的系統平臺。 對於 B/S 架構的系統來說需要考慮使用者端瀏覽器的版本。 |
|
割接/升級測試 |
採用 |
進行專門的割接測試或升級測試，提供工程升級割接方案 |
|
文擋測試 |
採用 |
檢查文件是否足夠、描述是否合理 |
|
迴歸測試 |
採用 |
檢查程式修改後有沒有引起新的錯誤、是否能夠正常工作以及能否滿足系統的需求 |
5.4 測試技術
|
測試技術 |
是否採用 |
說明 |
|
里程碑技術 |
採用 |
里程碑的達成標準及驗收方法在測試完後製訂 |
|
自動測試技術 |
採用 |
核心業務流程採用自動測試技術 |
|
審評測試 |
採用 |
對軟體產品功能說明文件和設計說明文件進行檢查，在需求與設計階段進行 |
|
編寫測試用例 |
採用 |
在產品編碼階段編寫測試用例 |
|
單元測試 |
不採用 |
由開發人員進行 |
|
整合測試 |
採用 |
檢測模組整合後的系統是否達到需求對業務流程及資料流的處理是否符合標準、系統對業務流處理是否存在邏輯不嚴謹及錯誤以及是否存在不合理的標準及要求。 |
|
確認測試 |
採用 |
在產品釋出前，對照feature list 進行基本需求的確認，確認產品是否正確實現了功能。 |
|
系統測試 |
採用 |
包括效能測試、壓力測試和迴歸測試 |
|
驗收測試 |
不採用 |
由工程實施人員進行 |
第6章測試計劃
6.1進度計劃
在此章節，對各階段的測試給出里程碑計劃，包括階段、里程碑、資源等。
6.1.1測試時間進度
|
測試階段 |
開始時間 |
完成時間 |
測試人員 |
|
制定測試計劃 |
6.10 |
6.15 |
朱雲鋮 |
|
需求Review |
6.10 |
6.18 |
李偉 |
|
設計Review |
6.10 |
6.17 |
李偉 |
|
設計測試用例 |
6.10 |
6.19 |
劉世賢 |
|
測試開發 |
5.10 |
6.05 |
劉世賢 |
|
測試環境準備 |
6.10 |
6.15 |
黃彥瀟 |
|
測試實施 |
6.15 |
6.30 |
黃彥瀟 |
6.2測試準備
6.2.1 測試環境準備
|
準備事項 |
開始時間 |
完成時間 |
測試人員 |
|
測試環境準備 |
6.10 |
6.15 |
黃彥瀟 |
6.2.2 安裝測試
|
準備事項 |
開始時間 |
完成時間 |
測試人員 |
|
安裝測試 |
6．30 |
6.30 |
朱雲鋮 |
6.3 具體測試實施任務和時間人員安排
|
測試功能點 |
開始時間 |
完成時間 |
測試人員 |
說明 |
|
路線檢索 |
6.15 |
6.16 |
朱雲鋮 |
測試反應速度 |
|
路線規劃 |
6.16 |
6.17 |
李偉 |
測試是否準確 |
|
線上掛號 |
6.17 |
6.17 |
劉世賢 |
測試是否卡頓 |
|
線上求醫 |
6.17 |
6.18 |
黃彥瀟 |
測試是否可行 |
|
線上購藥 |
6.18 |
6.18 |
朱雲鋮 |
測試是否出現致命錯誤 |
|
智慧控制 |
6.19 |
6.20 |
朱雲鋮 |
配合硬體測試 |