易校小程式
測試計劃
2018年01月15日
産品名稱 | 易校 | ||
文檔編号 | 版本号 | 頁 數 | 16 |
文檔名稱: 叮咚車管家測試計劃
作者: | 那穎 | 日期: | 2018-01-15 |
稽核: | |||
準許: |
評審意見: 确 認: 日 期: |
位址:河北省石家莊市長安區石家莊鐵道大學
郵編 050000
總機: Fax:
目錄
第一章 總論 1
1.1 項目背景........................................................................................................ 1
1.2 項目目标........................................................................................................ 1
1.3 系統視圖........................................................................................................ 1
1.4 文檔目的........................................................................................................ 2
1.5 文檔摘要........................................................................................................ 2
第二章 測試政策 3
2.1 整體政策........................................................................................................ 3
2.2 測試範圍........................................................................................................ 4
2.3 風險分析........................................................................................................ 5
第三章 測試方法 6
3.1 裡程碑技術.................................................................................................... 6
3.2 測試用例設計................................................................................................ 6
3.3 測試實施過程................................................................................................ 6
3.4 測試方法綜述................................................................................................ 7
第四章 測試組織 8
4.1 測試團隊結構................................................................................................ 8
4.2 功能劃分........................................................................................................ 8
4.3 聯系方式........................................................................................................ 9
第五章 資源需求 10
5.1 教育訓練需求...................................................................................................... 10
5.2 硬體需求...................................................................................................... 10
5.3 軟體需求...................................................................................................... 10
5.4 辦公空間需求.............................................................................................. 10
5.5 相關資訊儲存的位置................................................................................... 11
第六章 時間進度安排 12
第七章 測試過程管理 13
7.1 測試文檔...................................................................................................... 13
7.2 缺陷處理過程.............................................................................................. 14
7.3 測試報告...................................................................................................... 15
第八章 附件 16
第九章 變更記錄 17
第一章 總論
1.1 項目背景
由于丢東西,找東西的事情每天都在上演,空間說說,朋友圈,官方QQ,資訊比較冗雜,沒有一個固定的平台來專門提供學生。此外,教室查詢也是學生的一大痛點,不清楚哪個教室什麼時候沒課,想要上自習,卻總是不友善。針對本校學生的痛點,希望能給學生提供一個友善快捷的平台,讓學生校園生活變得容易!
1.2 項目目标
普及到石家莊鐵道大學全體師生。
1.3 文檔目的
本測試計劃主要有兩類閱聽人:測試管理人員(項目經理、客戶指派人員)和測試人員。
u 項目經理根據該測試計劃制定進一步的計劃、安排(工作任務配置設定、時間進度安排)和控制測試過程;
u 客戶指派人員通過該測試計劃了解測試過程和相關資訊。
u 測試人員根據該測試計劃中制定的範圍、方法确定測試需求、設計測試用例、執行和記錄測試過程并記錄和報告缺陷。
本文檔主要闡述易校小程式測試過程中的一些細節,為易校小程式的測試工作提供一個架構和規範:
l 确定項目測試的政策、範圍和方法;
l 使項目測試工作的所有參與人員(客戶方參與人員、測試管理者、測試人員)對本項目測試的目标、範圍、政策、方法、組織、資源等有一個清晰的認識;
l 使項目測試工作的所有參與人員了解測試控制過程;
l 從政策角度說明本項目測試的組織和管理,指導測試進展,并作為項目測試工作實施的依據;
l 本文檔是本項目測試整個過程進行的依據、規範和标準;
在測試過程中嚴格按照本文檔的制定的規範去執行。
1.4 文檔摘要
在項目測試中很多因素決定了測試的成敗和效率,同進也潛藏一定的測試風險。在本文檔中,主要通過以下方面對項目進行分析、計劃和控制。
l 系統了解
測試人員通過基本教育訓練和使用系統來加強對項目的了解;了解深度如何?
l 測試政策
對于本項目,采用何種測試政策?測試哪些範圍?存在什麼樣的風險?
l 測試需求
定義測試範圍、測試重點,以及測試的目标;
l 測試設計
采用何種測試方法?測試用例由誰設計和編寫?測試實施過程;
l 測試環境
需要什麼樣的測試環境?以及測試環境的一些資訊;
l 過程控制
測試文檔如何管理?缺陷如何處理?測試過程如何控制?
第二章 測試政策
2.1 整體政策
本項目的特點:
- 參與的測試人員都是第一次接觸測試計劃
- 系統已經做過一些測試,并且已經在運作
- 相對于項目要做的事情來說,時間進度非常緊(要建立一個基本完善的測試規範、要設計整套測試用例和執行一輪完整的測試)
- 本次項目測試的隻對系統進行一輪測試
根據以上特點,制定本項目的測試過程政策如下:
-
以80/20原理為指導。
盡量做到在有限的時間裡發現盡可能多的缺陷(尤其是嚴重缺陷)
- 測試計劃與需求制定、用例設計同步進行
-
必須制定測試需求。
通過确定要測試的内容和各自的優先級、重要性,使測試設計工作更有目的性,在需求的指導下設計出更多更有效的用例。
-
逐漸完善測試用例庫。
測試用例庫的建設是一個不斷完善的過程,我們要在有限的時間裡,先設計出一整套的測試用例,重要的部分用例需要設計得完善一些,一般部分的則指出測試的要點,在以後的測試工作中再不斷去完善測試用例庫。
-
測試過程要受到控制。
根據事先定義的測試執行順序進行測試,并填寫測試記錄表,保證測試過程是受控的。
-
确定重點。
測試重點放在各子系統的功能實作上,問題較多的省中心管理系統和證書管理系統則是重中之重。
-
不測試題實作技術。
本次測試不對叮咚車管家子系統中的技師app實作的核心技術(環境仿真等)進行測試驗證。
測試技術
u 本項目采用黑盒測試技術。
u 本項目測試過程中将不會采用測試工具。
依據标準
本次測試中測試文檔的編寫、測試用例的編寫、具體的執行測試以及測試中各項資源的配置設定和估算,都是以叮咚公司提供的各子系統的使用手冊盒練習指導手冊為标準,軟體的執行以系統邏輯設計構架為依據。
測試過程
2.2 測試範圍
制定本次項目測試範圍的依據為:
l 各子系統所包含的功能
要測試的子系統:
測試内容 | 測試範圍 |
功能測試 | l 失物招領子產品 l 個人中心子產品 l 教室查詢子產品 |
性能測試 | 一、子產品 三個子產品進行性能測試: 1、失物招領子產品 2、個人中心子產品 3、教室查詢子產品 二、資料量 以易校小程式Bmob資料庫中存在十萬條預約記錄為标準,測試如下性能資料: 1、新XX資料入庫性能 2、修改XX資料 3、XX功能性能 三、硬體配置 不同硬體配置對系統性能的影響 1、一般配置的性能(CPU:PⅢ 667、記憶體128M) 2、在一般配置的基礎上增加記憶體後的性能(CPU:PⅢ 667、記憶體256M) 3、在一般配置的基礎上更新CPU後的性能(CPU:P4、記憶體128M) |
2.3 風險分析
1、測試人員對系統熟悉程度的風險:
參與本項目的測試人員都是第一次接觸該類型系統,在經過短期的系統教育訓練後,仍然有可能沒有完全掌握系統的業務細節,這将在後面的測試設計和測試執行工作造成一些測試逃逸現象(即一些要測試的方面沒有測到)。
2、系統資料方面的風險:
本項目被測試的系統沒有完備的開發文檔,測試人員做測試設計時能夠參考的隻是使用手冊和訓練手冊,以及通過教育訓練和初步使用後對系統的了解,可能導緻測試人員在初期無法全面地對系統進行深入的測試。
3、時間方面的風險:
本次項目時間隻有半個月,卻要完成測試規範的制定、整套測試用例的設計和執行一輪完整的測試,時間進度非常緊張,可能導緻測試設計工作不夠完善。
第三章 測試方法
3.1 裡程碑技術
在本項目中,我們将整個測試過程分為幾個裡程碑,達到一個裡程碑後才能轉換到下一階段,以控制整個過程。
我們将整個測試過程分為以下幾個裡程碑:
裡程碑 | 完成标準 |
系統教育訓練: |
|
測試需求: |
|
測試設計: |
|
測試執行: |
|
結果分析: |
|
3.2 測試用例設計
本次測試的測試案例,是在經過系統教育訓練後,由測試人員根據客戶對系統的介紹和自己對系統的了解按照系統層次結構組織編寫。
l 本系統案例的編寫采用黑盒測試常用的分析方法設計用例;
l 對于每一個測試用例,測試設計人員應為其指定輸入(或操作)、預期輸出(或結果);
l 每一個測試用例,都必須有詳細的測試步驟描述;
l 本次測試設計的所有測試用例均需以規範的文檔方式儲存;
l 在整個測試過程中,可根據項目實際情況對測試用例進行适當的變更;
l 測試用例中測試資料的準備,在客戶的指導和協助下準備。
l 按照系統的運作結構安排用例的執行;
3.3 測試實施過程
本項目由兩位測試人員分别負責不同的子系統的測試,實施過程如下:
1、準備測試所需環境
2、準備測試所需資料
3、按照系統運作結構執行相應測試用例
4、記錄測試過程和發現的缺陷
5、報告缺陷
3.4 測試方法綜述
本項目測試包括:
u 功能測試 測試各功能是否有缺陷
u 性能測試 測試系統在一定環境下的性能資料
u 測試人員執行測試時,要嚴格按照測試用例中的内容來執行測試工作。
u 測試人員要将測試執行過程記錄到測試執行記錄文檔中。
u 測試人員要對測試中發現的問題記錄到缺陷記錄中。
u 測試組織
3.5 測試團隊結構
角色 | 人員 | 職責 |
項目組組長 | 寇肖萌 | u 組織測試教育訓練 u 組織環境搭建 u 制定測試計劃 u 制定測試規範 u 需求、用例稽核 u 控制測試進度 u 與相關部門、人員溝通 |
客戶指派 | u 協助溝通 u 組織系統教育訓練 u 協助确定測試需求 u 協助準備測試環境和資料 | |
測試需求制定 | 袁亞琴 | u 制定測試需求 |
測試設計 | u 設計測試用例 u 準備測試資料 | |
測試執行 | u 按計劃執行測試用例 u 記錄執行過程 u 提出糾正建議措施 | |
缺陷報告 | u 記錄、報告所發現的缺陷 | |
測試分析 | u 分析測試結果 u 編寫成測試分析報告 |
3.6 功能劃分
姓名 | 負責範圍 |
u 訂單子產品 u 個人中心子產品 | |
u 失物招領子產品 |
3.7 聯系方式
手機 | 電話 | ||
13001499597 | [email protected] | ||
第四章 資源需求
4.1 教育訓練需求
由于參與本次測試的測試人員對考試管理系統都不了解,需要韓氏集團對這些測試人員進行系統的相關教育訓練。教育訓練内容包括:
u 系統架構的教育訓練
u 系統資料流程的教育訓練
u 各子系統的功能教育訓練
u 在實際使用過程中哪些部分問題比較多
u 哪些部分是本次的重點測試對象
4.2 硬體需求
本次共有兩名測試人員,需要單獨使用的android手機三台。
名稱 | 數量 | 配置 | 其它說明 |
測試機 | 3 | ||
4.3 辦公空間需求
本次測試在土木樓進行,需要提供平均每人至少2平米的辦公空間。
4.4 相關資訊儲存的位置
類型 | 位置 | 說明 |
Bmob伺服器 | devserver | 管理者密碼:123 |
第五章 時間進度安排
第六章 測試過程管理
6.1 測試文檔
6.1.1 編号規則
子系統編号
目的是定義要測試的各子系統的編号,以唯一辨別各子系統。
本項目需要測試的各自系統的編号如下:
階段 | 子產品名稱 | 編号 |
第一階段 | 失物招領子產品 | 01 |
教室查詢子產品 | 02 | |
第二階段 | 個人中心子產品 |
測試項編号規則
這裡的測試項,是指測試需求和測試用例等。
為了便于區分和管理測試項,并且唯一地辨別測試項,需要對測試項規定一種編号規則。我們制定編号規則如下:
系統識别碼.測試項識别碼.子系統編号.子產品編号.自行編号
編号名稱 | 定義 | |
系統識别碼 | 測試項目/系統的辨別,在項目開始時自行定義,要求不與其他項目的辨別沖突。 | 全國計算機資訊高新技術考試系統 系統識别碼為 LD |
測試項識别碼 | 用于辨別是何種測試項(測試用例、測試需求) | 測試需求 R 測試用例 C 缺陷記錄 D |
各子系統的編号 | 與子系統編号中定義的一樣 | |
子產品編号 | 唯一辨別同一子系統中的各子產品 | 需求設計人員制定需求時自行定義 |
自行編号 | 測試項序号 | 測試項設計人員自行定義,要求順序辨別 |
例子: LD.R.01.01.1
LD.C.11.02.11
LD.D.12.01.11
6.2 缺陷處理過程
本項目隻對系統進行一輪測試,測試過程不需要做缺陷跟蹤。
特定義缺陷處理過程如下:
1、測試員每天記錄當天發現的缺陷
2、測試員每天下班前将記錄的缺陷發送給項目經理
3、項目經理将目前的缺陷記錄轉發給客戶指派人員
4、測試結束時項目經理将所有缺陷整合成一個完整的缺陷文檔,同其它測試文檔一同送出給客戶
6.3 測試報告
測試過程中,需要産生以下報告:
報告名稱 | 報告内容 | 編制者 | 接受者 |
測試工作周報 | u 一周工作彙報, u 哪些做得好,為什麼? u 有什麼問題,如何改進? | 測試人員 項目經理 | 測試人員向項目經理彙報,項目經理向客戶代表和公司上司彙報 |
測試階段報告 | 達到裡程碑後,彙報該階段的主要工作、存在的問題和解決方法/建議等 | 客戶代表 公司上司 | |
測試總結報告 | u 測試過程概要 u 測試分析總結 u 建議 |
第七章 附件
第八章 變更記錄
版本 | 修改内容描述 | 修改人 | 日期 | 備注 |