團隊作業3需求改進與系統設計
需求改進與系統設計
一、需求與原型改進
1.1改進的原型
1、改進說明
對於此次二期原型制作 我們添加了整套的後臺管理系統 後臺管理系統共分為審核管理,用戶管理,權限管理,遺失管理,招領管理五大模塊 與前臺信息進行一一對接 保證管理人員能在後臺界面實時高效的對網站信息完成管理更替和審核
2、高保真原型 3、高保真原型下載地址
https://git.coding.net/ma744191948/team.work.git
1.2改進的原型需求規格說明書
1、改進說明
項目背景進行修改。
開發目標進行了修改補充。
用戶角色分析表進行了補充。學生方面增加了安全性。
網站界面標準添加了四個新的標準,使網站界面更加標準美化。
網站設計驗收標準添加了建設方面的標準,使網站設計更為規範。
2、需求規格說明書下載地址
https://git.coding.net/ma744191948/need.git
二、系統設計
2.1系統架構設計
開發級需求分析
在開發過程中,團隊本身在開發的起始階段確定了基本的開發級需求分析:
經過上一次的結對作業,我們對於合作開發這件事已經加深了一層理解,也更加清楚合作開發和個人開發的不同。因此我們會在開始開發前就制定好代碼規範,在實行過程中,按照構建之法書中的要求來進行代碼的實現,修改,測試,維護等等。
經過討論我們決定使用已經學習過的代碼語言來實現頁面(例如:java,js,servlet,jsp等等),對於這幾種語言我們團隊都有一些開發經驗,再次開發時會提高一些開發效率,而且這幾種語言已經可以解決我們項目開發中的大部分問題。對於解決不了的問題,我們會進行學習,好在團隊學習積極性較高,學習能力較強,由於網頁功能較為復雜,我們團隊將盡可能的使用成熟的框架技術,實現對開發效率和開發質量的需求。
需求回顧:
我們想要做一個關於失物招領的平臺,現在每天東師有大量的學生丟失物品,而我們開發這樣一個網站,是方便撿到的人可以將物品信息發布在網上,然後丟失東西的人可以在我們的網站上進行搜索查詢,方便東師學生生活,這樣一個專門的網站,可以減少用戶丟失重要物品而找不到的情況,極大的幫助了這些遺失物品的人。
架構設計
1.設計摘要說明
首先從架構的層次上,對本身的設計進行最簡短的概述:
前端頁面 |
直接與用戶打交道,發出提供用戶增加,減少,修改,查詢遺失物品功能的請求 |
後端系統 |
負責處理用戶的請求,並銜接搜索系統,使用戶對數據進行操作 |
搜索系統 |
負責搜集、整合數據,並響應網站後端的搜索請求,提供搜索結果 |
因此不妨設計東師拾遺的概念架構圖如下圖所示:
2.前端頁面設計
前端開發將依據UI設計的交互進行開發,主要用到的語言有:html、css、jquery、js。開發過程會用到Bootstrap框架,以完成響應式布局。開發工具將用到sublime tex,後期與後端調試時將用到IDE。前端開發會積極做好與UI設計人員和後臺開發人員的溝通,力求界面美觀大方,交互符合用戶需求。
3.後端系統設計
為了達到我們的開發級需求,我們選擇使用java語言進行後端開發,並使用SpringMVC框架。
比較同意一種說法,Java最大的優勢不是它的跨平臺性而是它龐大而完善的生態系統。它的流行最主要原因還是由其生態系統決定的。
Java語言各方面比較均衡,擁有最值得信賴的GC,避免很多碼農的低級錯誤。並且天生的面向對象設計,更容易模塊化開發。再加上Java強類型靜態語言,只要框架已搭好,即便開發人員能力不足,也基本能保證代碼質量,這在大項目的協作開發、維護方面很有優勢。開源,擁有大量的第三方庫,並且大部分質量有保證,可以拿來就用,對軟件生產效率的提升所帶來的巨大價值。正如一句話所說:“我們不生產代碼,我們只是Github的搬運工。”並且Java擁有很多殺手級應用,如Spring,Apache、Android,Hadoop,Spark等。
為了提高我們的開發效率,我們決定使用SpringMVC框架如果沒有MVC設計模式。程序間的各層之間依賴非常強,耦合度高。嚴重違背了高內聚低耦合的設計原則。而WebMVC將控制邏輯和功能處理,模型和視圖進行了分離。降低耦合。
後端系統主要有兩部分功能,一部分是與用戶系統相關的功能,如用戶的登陸、管理、發布還有完成等等,另一部分則是與搜索引擎的銜接。同時還有一個模塊負責整個站點的銜接、整合等。
ps:數據庫架構
信息架構的方面,我們認為數據庫的設計也至關重要。
建立用戶實體類,物品實體類,用戶實體類中聲明所有需要用到的屬性。用戶和物品在關系上呈現一對多的關系。兩者之間通過用戶的id實現關聯。
由於拾遺物品是經過分類的,對於這些物品不同分類設置不同鍵值,類似於Map存儲方式。
對於開發過程:首先實現用戶模塊,再增加主站模塊實現與數據庫信息之間各種不同的操作。最後通過數據庫查詢實現搜索模塊,搜索過程中支持關鍵字模糊查詢。
平臺架構設計
1.tomcat服務器
Tomcat是Apache 軟件基金會(Apache Software Foundation)的Jakarta 項目中的一個核心項目,由Apache、Sun 和其他一些公司及個人共同開發而成。由於有了Sun 的參與和支持,最新的Servlet 和JSP 規範總是能在Tomcat 中得到體現,Tomcat 5支持最新的Servlet 2.4 和JSP 2.0 規範。因為Tomcat 技術先進、性能穩定,而且免費,因而深受Java 愛好者的喜愛並得到了部分軟件開發商的認可,成為目前比較流行的Web 應用服務器。
2.搜索系統
數據庫查詢是數據庫的最主要功能之一。為了增加數據庫的查詢效率,我們準備使用索引數據結構。
使用索引結構的原因如下:
我們都希望查詢數據的速度能盡可能的快,因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找(linear search),這種復雜度為O(n)的算法在數據量很大時顯然是糟糕的,好在計算機科學的發展提供了很多更優秀的查找算法,例如二分查找(binary search)、二叉樹查找(binary tree search)等。如果稍微分析一下會發現,每種查找算法都只能應用於特定的數據結構之上,例如二分查找要求被檢索數據有序,而二叉樹查找只能應用於二叉查找樹上,但是數據本身的組織結構不可能完全滿足各種數據結構(例如,理論上不可能同時將兩列都按順序進行組織),所以,在數據之外,數據庫系統還維護著滿足特定查找算法的數據結構,這些數據結構以某種方式引用(指向)數據,這樣就可以在這些數據結構上實現高級查找算法。這種數據結構,就是索引。
我們準備使用上圖的索引方式:
左邊是數據表,一共有兩列七條記錄,最左邊的是數據記錄的物理地址(註意邏輯上相鄰的記錄在磁盤上也並不是一定物理相鄰的)。為了加快Col2的查找,可以維護一個右邊所示的二叉查找樹,每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針,這樣就可以運用二叉查找在O(log2n)O(log2n)的復雜度內獲取到相應數據。
2.2任務分解WBS
三、測試計劃
3.1測試計劃
目錄
1、引言
項目背景
參考資料
測試術語(新增)
2、任務概述
測試範圍
測試目標
3、測試策略
測試人員需求、分工(新增)
測試方法
測試工具
測試階段預估及日程計劃
測試變量矩陣量
4、測試資源
5、風險評估
6、其他內容
引言
項目背景
目前市場上有許多類似的失物招領網站,但是大多數都沒有針對性。大多數高校失物招領還是依靠校內實體站點或者公眾號的方式進行失物招領,具有即時性,但是並不方便,範圍不夠廣。基於在校大學生的特性,我們希望基於網站,建立一款針對在校大學生的半實名制可搜索的失物招領網站。
參考資料
測試需求分析總結
https://www.cnblogs.com/hanxiaomin/p/6132828.html
網站測試流程、要求及測試報告
http://lib.csdn.net/article/softwaretest/24298?knId=1307
測試需求分析
https://wenku.baidu.com/view/63d77034336c1eb91b375d1f.html
《東師拾遺》需求規格說明書
https://git.coding.net/ma744191948/need.git
測試術語
測試術語 |
名詞解釋 |
輪播 |
輪播為網站首頁中的流動播放的圖片,主要為較為緊急的老師或學生丟失的最新的物品信息 |
權限管理 |
對於管理員的權限及學生老師用戶權限的管理區域 |
種類 |
用於用戶搜索物品關鍵詞時網頁提供的一些熱搜詞及分類 |
用戶管理 |
對於用戶的增刪改查管理 |
任務概述
測試範圍
針對於網頁進行的各項實用性能測試(包括用戶界面及管理員界面)
制作者測試:美工頁面測試、程序員頁面測試
全面測試:頁面框架結構問題、錯別字、常識問題
發布測試:環境不同導致的問題
測試目標
鏈接測試能通過
表單測試能通過
Cookies測試能通過
數據庫測試能通過
性能測試能基本通過,盡量提高性能
可用性測試能通過
兼容性測試能通過firefox,chrome,360
測試策略
測試人員需求、分工
分析、缺陷、矯正測試:馬越、李可欣、劉士齊
產品完成驗證:馬越、翁夢蕾、楊帆
測試方法
手動測試:每個鏈接、文字都由人工編輯測試
測試為交互驗證方式,互相督促,互相驗證
壓力測試:使用http_upload壓力測試
測試工具
Junit單元測試工具
http_upload壓力測試工具
WebPagetest 前端性能測試工具
測試階段預估及日程計劃
測試階段
|
測試任務
|
工作量估計 |
人員分配 |
時間安排 |
第一階段 功能測試 |
|
復雜 |
全體人員 |
開發階段 |
第二階段 系統測試 |
1.完成所有模塊的組合測試 2.確定所有業務流向和數據都是正確的。 |
中等 |
前端開發人員、後端開發人員 |
Alpha階段結束後2天 |
第三階段 性能測試 |
在多用戶訪問,交替進行負荷壓迫測試 |
復雜 |
全體人員、邀請部分用戶參與 |
Beta階段結束後2天 |
第四階段 兼容測試 |
軟件在各個軟件平臺上的運行情況 |
中等 |
全體人員 |
Beta階段結束後4天 |
測試變量矩陣量
|
用戶類型 |
屏幕分辨率 |
操作系統 |
默認語言 |
瀏覽器 |
網絡速度 |
組合總數 |
變量數目 |
3 |
2 |
3 |
2 |
3 |
3 |
324 |
|
管理員 |
800*600(像素) |
Windows10 |
簡體中文 |
360 |
撥號 |
|
|
已註冊用戶 |
1024*768(像素) |
Windows7 |
英文 |
Firefox |
ADSL |
|
|
未註冊用戶 |
|
mac |
|
|
局域網 |
|
|
|
|
|
|
|
|
|
測試資源
人力資源:全部開發人員及邀請用戶測試人員
物力資源:
Windows10操作系統
Windows7 操作系統
Mac操作系統
google瀏覽器、firefox瀏覽器
風險評估
網站進度風險:時間較短,開發人員較少,人員配比不平均,可能導致網站按時交付時出現部分問題
網站需求風險:需求分析文檔可能會有不足,造成後期的問題
技術開發風險:技術不成熟,可能導致網站性能較差
網站設計風險:並不是由專業人員設計,交互性可能略微落後
人員流失風險:人員流失導致網站進度拖慢
競爭風險:同期可能有較多網站與之進行競爭
其他內容
測試計劃制定者:翁夢蕾、李可欣
日期:2018年5月30日
修改記錄:暫無
評審人員:馬越
開發負責人:李可欣、翁夢蕾、楊帆、劉士齊
測試負責人:馬越
團隊作業3需求改進與系統設計