文章目錄
一、需求&原型改進
1. 需求改進
針對課堂討論環節老師和其他組的問題及建議，對修改選題及需求進行修改
問題1：你們的用戶量還可以進行修改，如果真正做出來的話，你們的用戶量還可以再提高很多。
修改1：我們將用戶量進行更改，從初期合作對象爲院內社團、學生組織，後期爲廣州大學城高校的各個社團、學生組織。
問題2：上週的需求規格說明書不夠完善
修改2：對上週的需求規格說明書進行了進一步的補充和完善
2. 修改說明書
修改完善上週提交的需求規格說明書
（1）項目功能修改
網頁端（管理端）：
- 賬號註冊，需填寫社團信息；
- 編輯所屬社團簡介、部門信息；
- 上傳照片至社團相冊；
- 發佈招新信息；
- 編輯、發佈通知；
- 查看、修改、刪除報名人員的狀態。
小程序端（學生端）：
- 賬號註冊，需填寫個人信息；
- 查看社團的信息；
- 報名社團，填寫報名表；
- 查看招新情況進度；
- 接受通知。
（2）預期的用戶數量
招新通第一版開發測試完成後，我們將與學院內各個社團、學生組織合作，預計的用戶量爲學院內大一級的學生，預計人數爲1,000到1,200人。
伴隨着合作社團的增加，產品升級迭代，我們將於廣州大學城各高校的社團、學生組織合作，用戶量預計將達到10,000到50,000人。
（3）應用場景設計
家明是一名剛進大學的大學生，想要在大學中創出自己的一片天地。家明在師兄師姐的接待下對學校有了一個大體的瞭解，但當他面對“百團大戰”時，還是不敢進到人羣中向師兄師姐諮詢。他看到最外面的社團有貼小程序的二維碼，於是他打開微信掃一掃，發現在小程序上可以看到衆多社團的介紹，還可以對師兄師姐進行提問，甚至於還可以報名。家明最後在小程序上對自己感興趣的社團都查閱、詢問了一番，最後選擇報名了羽毛球協會、創業俱樂部這兩個社團。
3.功能分析
參考《構建之法》5節功能的定位和優先級，給出功能分析的四個象限
| 外圍功能 | 殺手功能 | |
|---|---|---|
| 必須要求 | 通過小程序瀏覽社團 | 通過小程序進行招新報名、查看面試進度 通過網頁對招新人員信息進行增刪查改 |
| 輔助要求 | 界面跳轉、美化 | - |
4. 調整WBS及計劃
根據修改後的需求，調整任務分解WBS及相應的項目進度計劃
二、系統設計
1. 總體設計
2. 數據庫設計
（1）管理端用戶
| 列名 | 類型 | 備註 |
|---|---|---|
| id | int | 主鍵 |
| user_name | varchar | |
| pass_word | varchar | |
| stu_id | varchar | 學號 |
| pho_num | varchar |
（2）學生端用戶
| 列名 | 類型 | 備註 |
|---|---|---|
| id | int | 主鍵 |
| user_name | varchar | |
| pass_word | varchar | |
| stu_id | varchar | 學號 |
| pho_num | varchar | |
| college | varchar | |
| stu_class | varchar | |
| mailbox | varchar | |
| school | varchar |
3.社團設計
| 列名 | 類型 | 備註 |
|---|---|---|
| id | int | 主鍵 |
| club_name | varchar | |
| club_desc | longtext | |
| Amin_id | int | 外鍵，級聯管理端用戶id |
| school | varchar |
三、Alpha任務分配計劃
1. Product Backlog
依據項目組能提供的總時間、功能模塊的優先級以及模塊之間的依賴關係，在Product Backlog中選取待實現的功能項。
| Product Backlog | Sprint Backlog |
|---|---|
| 用戶模塊 | 登錄註冊，個人信息、社團信息填寫 |
| 首頁模塊 | 瀏覽、報名社團 |
| 通知模塊 | 發佈通知（網頁），接受通知（小程序） |
2. Sprint Backlog
對已選擇的功能項再做進一步分解，分解爲1-10小時左右的任務，構成Sprint Backlog。在PM的協助下，編碼的同學對任務進行認領。
| 任務 | 負責人 | 開始日期 | 結束日期 | 預計工時 |
|---|---|---|---|---|
| Alpha版本 | ||||
| 數據庫 | 辜仰淦 | 2020年5月15日 | 2020年5月23日 | 8h |
| 建立數據庫 | 辜仰淦 | 2020年5月15日 | 2020年5月17日 | 2h |
| 實現基本操作 | 辜仰淦 | 2020年5月18日 | 2020年5月23日 | 6h |
| 前端頁面（小程序） | 陳餘、姜達成 | 2020年5月15日 | 2020年5月25日 | 10h |
| 首頁 | 陳餘 | 2020年5月15日 | 2020年5月23日 | 3h |
| 發現 | 陳餘 | 2020年5月15日 | 2020年5月23日 | 3h |
| 個人信息 | 陳餘 | 2020年5月15日 | 2020年5月23日 | 2h |
| 通知 | 姜達成 | 2020年5月24日 | 2020年5月25日 | 2h |
| 反饋與建議 | 陳餘 | 2020年5月24日 | 2020年5月25日 | 2h |
| 設置 | 陳餘 | 2020年5月24日 | 2020年5月25日 | 2h |
| 前端頁面（網頁） | 郭奕材、王煜墉 | 2020年5月15日 | 2020年5月25日 | 18h |
| 社團信息 | 郭奕材 | 2020年5月15日 | 2020年5月25日 | 10h |
| 發佈通知 | 2020年5月15日 | 2020年5月25日 | 2h | |
| 報名人員信息瀏覽 | 王煜墉 | 2020年5月15日 | 2020年5月25日 | 10h |
| UI設計（小程序） | 劉婉兒 | 2020年5月15日 | 2020年5月20日 | - |
| UI設計（網頁） | 劉婉兒 | 2020年5月15日 | 2020年5月20日 | - |
| 測試總結 | 郭奕材、陳餘、辜仰淦、王煜墉 | 2020年5月26日 | 2020年5月28日 | - |
| 測試 | 2020年5月26日 | 2020年5月28日 | - | |
| 總結 | 2020年5月26日 | 2020年5月28日 | - |
3. 以甘特圖的方式擬定迭代衝刺計劃。
四、測試計劃
1.測試術語
黑盒測試，功能測試，測試項，嚴重性
性能測試（Performance Testing）：
在一定負載情況下，系統響應時間、搜索篩選結果等性能是否滿足用戶特定的性能需求。
負載測試（Load Testing）：
在一定的軟甲、硬件及網絡環境下，在不同虛擬用戶數量的情況下進行一種或者多種業務，測試服務器的性能指標是否在用戶要求的範圍內，用於確定系統所能承受的最大用戶數、最大有效用戶數以及不同用戶數下的系統響應時間和服務器的資源利用率
壓力/強度測試（Stress Testing）：
在一定軟件、硬件及網絡環境下，模擬大量的虛擬用戶想服務器產生負載, 使服務器的資源處於極限狀態下並長時間連續運行,目的是用來測試服務器高負載情況下是否能夠穩定工作。
配置測試（Configuration Testing）：
在一定的軟件，硬件及網絡環境下, 在數據庫中構造不同數量級別的數據記錄,運行一種或多種業務,在一定虛擬用戶數量的情況下,獲取不同配置的性能指標,由於選擇最佳的設備及參數配置。通過配置測試可以將性能缺陷放大,方便定位瓶頸。
2.測試人員
郭奕材、辜仰淦、王煜墉、陳餘
3.任務概述
測試範圍
小程序、網頁端的所有功能
| 測試類型 | 是否完成測試 | 測試優先級 | 說明 |
|---|---|---|---|
| 註冊賬號 | 最高級 | 學生、社團負責人註冊賬號時使用的信息是否能通過 | |
| token測試 | 中等 | 檢查前端是否能正常接收併發送token認證，服務端能否接收並解析token | |
| 進入網站 | 高級 | 通過發佈的鏈接是否能進入網站 | |
| 修改個人信息 | 中等 | 學生、社團負責人在修改個人信息時，是否檢測敏感字符 | |
| 數據庫測試 | 低 | 數據信息是否一致：用戶提交的信息是否正確，數據輸出錯誤：主要由網絡或程序本身設計問題等引起 |
壓力測試： 測試系統的限制和故障恢復能力,即測試web應用
系統會不會崩潰，在什麼情況下會崩潰。
測試的區域包括表單、登陸和信息傳輸頁面等
測試目標
所有功能均能正常實現，能應對多用戶需求
測試用例編寫
4.測試策略
測試人員需求、分工
郭奕材、陳餘：用戶測試
辜仰淦：性能測試
王煜墉：壓力測試
測試方法
手動測試、黑盒測試
工具引用及測試培訓
手動，內訓
測試階段計劃
（工作內容、人員安排、起止時間等）
測試停止及恢復條件
測試停止條件：開發人員需要更改代碼
恢復條件：確認代碼修改無誤
測試文檔及缺陷提交管理等
在每次做完測試後都要記錄並且上傳
測試環境
Windows系統、電信移動網
5.測試資源
硬件資源需求
計算機、安卓手機、蘋果手機
軟件資源需求
谷歌瀏覽器、微信、sql server/my sql
測試環境需求
移動網絡或WIFI網絡
測試人員需求
用戶測試：郭奕材、陳餘
性能測試：辜仰淦
壓力測試：王煜墉
6.風險評估
人力方面；
人力充足
時間方面；
時間充足，當一個功能開發完成後，就開始測試，以節約時間
環境方面；
缺少對Linux瀏覽器環境的測試
資源方面
無
部門合作方面
測試人員隨時報告測試結果給開發人員，開發人員根據報告進行代碼修改