這個作業屬於哪個課程 | 計科22級34班 |
---|---|
這個作業要求在哪裡 | 作業要求 |
這個作業的目標 | 根據團隊作業2《需求規格說明書》和老師的建議改進專案需求,並對系統進行初步設計 |
前言
本篇部落格是團隊作業的第三篇,在上一篇部落格需求規格說明書中我們展示了對專案的初步理解與分析。經過老師的點評與建議後,我們認識到了目前需求規格說明書中的不足之處,並進行了改進。同時,我們對整個專案的系統進行了初步的設計。
團隊簡介
-
隊名
拖延是你不隊
-
隊員學號
姓名 | 班級 | 學號 |
---|---|---|
艾彬(組長) | 計科4班 | 3122004730 |
陸宇星 | 計科4班 | 3122004491 |
範聖林 | 計科4班 | 3122004735 |
王佳偉 | 計科3班 | 3122004880 |
鄭瑋源 | 計科4班 | 3122004760 |
需求&原型改進
問題改進
經過上課老師的建議和組內討論後,對專案設計中存在問題進行修改
問題一:“流浪動物領養網站”是否真的需要“領養”功能?
修改一:刪去管理員的“決定動物領養歸屬”這一功能,改為鼓勵使用者在評論區上傳該流浪動物的近況
需求規格說明書的改進
對於需求的分析並沒有問題,但是對應設計的功能欠缺考慮
我們團隊專案的初衷是提供一個流浪動物的資訊平臺,幫助愛動物人士更好地自發改善流浪動物的生活。從這個角度來看,“管理員決定動物的領養歸屬”這一功能是不必要的,原因有三:1.流浪動物可以被多個愛動物人士照養,不需要將“主人”的頭銜交給某個使用者;2.決定權在管理員,管理員決定領養歸屬的依據不足,難以選擇;3.使用者群大多是學生,學生的住宿條件並不適合領養動物
針對這一點,改為鼓勵使用者在評論區上傳自己觀察到的流浪動物近況,目的是幫助關心此流浪動物的使用者瞭解其近況(如:健康狀態,活動區域……)
功能需求的4個象限
參考《構建之法》5節功能的定位和優先順序,給出功能分析的四個象限
①必須做且重要(Must-haves):
使用者釋出和瀏覽流浪動物帖子:提供使用者友好的介面,使使用者可以方便地釋出和瀏覽流浪動物帖子。確保帖子包括必要的詳細描述、動物的大致定位。
帖子管理與稽核: 為了保證帖子的內容符合網站的目標,引入管理員稽核機制,管理員對使用者釋出的帖子進行稽核,此時帖子僅對管理員和釋出使用者可見,只有稽核透過其他使用者才可瀏覽該帖子。
登入:管理員的賬號密碼是提前寫好的,透過特定的賬號可以登入管理員,並執行稽核功能。
②必須做但不重要(Nice-to-haves):
評論板塊: 為每篇帖子建立一個專門的板塊,供使用者評論。為其他關心該流浪動物的使用者提供最新的資訊。
定位資訊: 引入地圖定位功能,編寫帖子的使用者可以上傳流浪動物的位置資訊,為其他使用者提供流動物位置資訊的視覺化。
③不必做但重要(Not-so-importants):
最佳化使用者體驗: 確保網站的使用者介面簡潔直觀。考慮到使用者體驗的因素,例如載入、響應等設計,以提高使用者使用體驗。
④不必做且不重要(Won't-haves):
非關鍵性功能: 避免投入過多資源在一些不是核心業務的功能上,優先考慮滿足核心業務需求。
調整任務分解WBS及相應的專案進度計劃
根據修改後的需求,進行任務的拆解和計劃的調整
第9周 | 1.團隊組隊、團隊部落格 |
---|---|
2.團隊介紹、成員展示、角色分配、選題確定 | |
3.制定團隊計劃安排,團隊貢獻分的規定 | |
第 10 周 | 1.需求規格說明書 |
2.原型設計,隊員估計任務難度並學習必要的技術 | |
3. 平臺環境搭建完成、初步架構搭建 | |
第 11 周 | 1.編碼規範完成 |
2.原型改進(給目標使用者展現原型,並進一步理解需求) | |
3.架構設計,WBS, 團隊成員估計各自任務所需時間 | |
4.測試計劃 | |
第 12、13 周 | 1.團隊專案Alpha任務分配計劃 |
2.連續7天的Alpha敏捷衝刺,7 篇 每日Scrum Meeting部落格+程式碼提交 | |
第 14 周 | 1.使用者反饋+測試計劃改進 |
2.團隊Alpha階段個人總結 | |
3.團隊專案Alpha部落格:釋出說明、測試報告、展示部落格、專案管理 | |
第 15 周 | 1.團隊專案Alpha部落格:事後分析 |
系統設計
系統設計由後臺開發的同學完成
架構設計
- 專案為前後端分離模式,前端主要採用Vue3框架,後臺主要採用springboot進行專案開發,資料使用mysql進行儲存,前後端之間透過restful api進行互動
- 後端在收到請求後,先對請求進行預處理,校驗使用者的登入態、驗證介面許可權,透過驗證後,由介面層負責讀取資料載入到引數之中,傳遞給負責具體邏輯的服務層,服務層對傳來的引數進行相應的邏輯處理,再透過呼叫資料庫層的sql請求,完成資料的增刪改查
- 模組主要分為使用者模組和帖子模組
- 使用者模組主要是使用者登入註冊以及個人資訊修改相關的功能,在使用者登入後,將透過token作為其登入憑證,參與到預處理流程中的使用者登入態校驗和許可權校驗(管理員相關的介面只能由管理員呼叫)中
- 帖子模版主要是使用者的發帖功能,包含帖子的增刪改,以及管理員對帖子的稽核、主頁隨機推薦等功能,因為評論隸屬於帖子,評論功能也放在這塊裡面
資料庫設計
- 文字說明
- 表user:這個表儲存使用者資訊,包括使用者的id、名稱、班級、手機號等個人資訊
- 表post: 這個表儲存帖子內容,包括帖子的標題、內容、發帖人、餵養狀態以及定位
- 表comment: 這個表儲存評論內容,包括評論人、評論內容以及評論的父評論id
- 表post_image: 這個表儲存帖子相關的圖片資訊
Alpha任務分配計劃
Product Backlog
Sprint1
甘特圖
測試計劃
一、引言
-
專案背景:我們團隊決定做一個流浪動物領養網站,主要目的是為發現流浪動物或希望領養流浪動物的人提供交流的平臺。使用者可以釋出流浪動物的資訊帖子,也可以選擇領養他人帖子中的流浪動物。本網站的出發點是關愛動物,流浪動物的生活普遍非常悽慘,我們希望能儘自己的一份力改善這一狀況。
-
參考資料(計劃編寫依據:可行性分析報告/軟體需求定義/軟體概要設計/軟體詳細設計/使用者使用說明書/……)
如何編寫測試計劃 -
測試術語:定義測試過程中使用的專業術語。
-
測試用例(Test Case):描述了對軟體特定功能或場景的測試步驟、預期結果和實際結果的文件或指令碼。
-
缺陷(Defect):在軟體中發現的錯誤、問題或不符合規範的地方,需要被修復。
-
自動化測試(Automated Testing):使用自動化測試工具和指令碼來執行測試任務,提高測試效率和覆蓋範圍。
-
迴歸測試(Regression Testing):在軟體發生變更後,重新執行既有的測試用例,以確保修改不會引入新的問題。
-
白盒測試(White Box Testing):測試人員有關軟體內部結構和程式碼的詳細資訊,以編寫測試用例和進行測試。
-
黑盒測試(Black Box Testing):測試人員無需知道軟體內部結構和程式碼的詳細資訊,只需根據需求規格進行測試。
-
整合測試(Integration Testing):測試不同模組或元件之間的互動和整合,以驗證它們一起工作的正確性。
-
端到端測試(End-to-End Testing):測試軟體從開始到結束的整個流程,以確保整個系統的功能和效能都符合要求。
-
使用者驗收測試(User Acceptance Testing):由終端使用者或客戶執行的測試,以確認軟體是否滿足其預期需求。
-
效能測試(Performance Testing):測試軟體在不同負載條件下的效能表現,包括響應時間、吞吐量和併發使用者數等。
-
-
有關專案人員組成以及聯絡方式:
- 後端開發人員以及版本控制人員:範聖林 、王佳偉
- 前端開發人員:陸宇星
- 測試人員:鄭瑋源
- 專案經理:艾彬
二、任務概述
-
測試範圍:
- 功能測試:包括登入、註冊、瀏覽帖子、釋出帖子、修改個人資訊、評論帖子、稽核帖子等功能,包括輸入、輸出、處理和使用者介面等方面的功能測試。
- 效能測試:測試網站的響應時間、吞吐量等效能指標。
- 相容性測試:測試網站在不同瀏覽器、作業系統上的相容性。
- 安全測試:測試網站的安全性,包括使用者資料的保密性、完整性等。
-
測試目標:確保流浪動物網站在功能、效能、相容性和安全性等方面滿足使用者需求和設計要求。
-
其他測試內容:
- 測試需求分析:分析軟體需求,確定測試範圍和測試重點。
- 測試用例編寫:根據測試需求編寫詳細的測試用例。
- 測試環境搭建:搭建與生產環境相似的測試環境。
- 測試執行:按照測試計劃執行測試用例,記錄測試結果。
三、測試策略
-
測試人員:
- 測試負責人(鄭瑋源):負責測試計劃的制定、測試資源的協調和測試結果的評估。
-
測試方法:
- 白盒測試:對部分關鍵程式碼進行白盒測試,提高程式碼質量。
- 黑盒測試:以使用者的角度進行黑盒測試,確保軟體的功能和效能符合使用者需求。
-
工具引用及測試培訓:
- 工具引用:使用測試管理工具、自動化測試工具、效能測試工具等。
-
測試階段計劃:
① 進行各功能函式的白盒測試
人員:鄭瑋源
起止時間:開發全程②進行整體程式的白盒測試
人員:鄭瑋源
起止時間:基本開發完成至完全開發完成③進行整體程式的黑盒測試
人員:鄭瑋源
起止時間:基本開發完成至完全開發完成 -
測試停止及恢復條件:
- 測試停止條件:當所有測試用例執行完畢,缺陷修復率達到一定標準,效能指標滿足要求時,測試可以停止。
- 測試恢復條件:當軟體發生重大變更或發現嚴重缺陷時,需要重新進行測試。
-
測試文件及缺陷提交管理等:
- 測試文件:包括測試計劃、測試用例、測試報告等,應按照規範進行編寫和管理。
- 缺陷提交管理:使用缺陷管理工具對缺陷進行提交、跟蹤和管理。
-
測試環境:
- 作業系統:win11
- 測試工具:IDEA 2020.1
四、測試資源
-
硬體資源需求
一臺win10以上系統的個人電腦 -
軟體資源需求
IDEA或者其他IDE -
測試環境需求
配置好Java環境,且下載好測試外掛
五、風險評估
-
人力方面:人手充足,任務分配合理,風險較低
-
時間方面:計劃中安排的時間均較為充裕,風險較低
-
環境方面:該專案對開發環境要求不高,風險較低
-
資源方面:該專案對軟硬體裝置要求不高,風險較低
-
部門合作方面:團隊成員之間關係融洽,交流積極,風險較低
六、其他內容
-
測試計劃制定者:鄭瑋源
-
日期:2024.11.3
-
修改記錄:
- 2024.11.3 :第一版編寫
-
評審人員:
- 開發負責人:範聖林、陸宇星、王佳偉
- 測試負責人:鄭瑋源
- 專案經理:艾彬