[Gamma阶段]展示博客
水哥牛X團隊[Gamma階段]展示博客
微信小程序搜索“小小易校園”即可體驗
項目愿景
- 想參加競賽，鍛煉自己，卻找不到合適的隊友
- 想進行實習，體驗工作，每天不得不翻遍吐槽版的幾百條信息卻一無所獲
- 發布在吐槽版的“求組隊”被聊天淹沒，無人問津
- 想找特定競賽、特定類型實習的通知，只能一個一個自己翻找，心力交瘁
組隊、招募信息大多在吐槽版發布，而吐槽版每日上百條的消息量往往導致信息曝光率極低，造成了”想找組隊、招募信息的人找不到，發布組隊、招募信息的人得不到回應“的現象。
因此，決定開發“小小易校園”小程序，提供一個針對各類競賽組隊、各類實習招募信息的統一發布平臺，提供以下服務：
- 首頁集中顯示各類招募信息，并提供分類瀏覽、關鍵詞搜索等檢索功能
- 支持圖片上傳的招募發布功能，并提供便捷的發布管理頁面，可查看申請者簡歷、接受，拒絕他人申請
- 申請感興趣的發布，在我的申請界面隨時查看申請狀態，并提供可隨時修改的簡歷模板
項目總體完成情況
截至Gamma階段結束，我們完整實現了原本計劃的信息發布、申請管理功能，還額外添加了數學建模比賽專用的組隊及隊友匹配模塊，總共實現了30個不同頁面，39個不同功能接口：
| 所有頁面 | 所有接口 |
其中，Gamma階段完成的美賽模塊功能及頁面如下：
| 首頁及問卷填寫頁面 | 搜索特定用戶邀請組隊 | 更換推薦隊友及邀請 |
| 查看已發送的邀請 | 查看收到的邀請 |
- 填寫數學建模比賽信息問卷，系統自動打分，并根據分數匹配隊友候選——匹配自動屏蔽隊伍中的隊友、以已邀請過的用戶
- 邀請用戶進入隊伍，或接受他人邀請參加其他隊伍、退出隊伍等隊伍管理操作
- 根據用戶名搜索用戶，尋找特定用戶進行組隊
- 點擊用戶通過下拉欄直接查看專業、競賽經歷等信息，避免頁面跳轉的等待
用戶情況
用戶數量及用戶分析
截至2019/06/17，共有用戶量400人：
而這400用戶中，年齡分布如下：
可見，絕大多數用戶為18-24歲的在校大學生或剛畢業的大學生，用戶情況符合前期調研的預期。
用戶反饋及根據反饋的修改
在發布了Gamma階段的第一個版本后，我們收集了用戶反饋。用戶反饋的主要問題有：
- 問題1
原本的登錄頁面中，有獲取頭像與姓名、進入主頁兩個Button。獲取頭像與姓名按鈕用于點擊后獲取用戶頭像。但這一步往往造成用戶迷惑，不知道這兩個按鈕點擊的順序、影響。因此，我們對登錄頁面進行了修改：
新的登錄頁面只保留進入主頁按鈕，若沒有用戶的微信頭像等信息，則自動彈出權限獲取窗口。
- 問題2
該反饋針對美賽模塊的原首頁：
該頁面中，“已發邀請”、“收到邀請”、“重填問卷”、“換一批”為可點擊按鈕，“我的隊伍”、“推薦隊友”為提示信息，不可點擊。其中，“推薦隊友”模塊中，任意點擊任意用戶可查看詳細信息。
針對這一頁面，用戶提出了以下反饋：
由于顏色相近，導致用戶不清楚哪些按鈕可以點擊而哪些按鈕不能，更不知道點擊用戶可查看詳細信息。為了改進這一問題，我們一開始嘗試通過“較為灰色的部分不可點擊，顏色明亮部分可以點擊”的方式解決。因此，我們向藝術生尋求了配色幫助。然而。。。。。。。。
這樣的配色并不能讓可點擊按鈕更加明顯。。并且配色風格與我們小程序的整體風格嚴重不搭。經過一番嘗試，我們最終選擇將所有可點擊按鈕加上下劃線，作為提示。
這樣，我們既保留了配色的統一、美觀，也提高了可點擊與不可點擊部分的區分度。
軟件質量與Alpha版本的對比
Alpha版本如同Alpha版本出口條件所述，主要為了完成計劃的各類主要功能，為工期工作提供框架。因此，Alpha版本的產品在UI上非常簡陋。在之后兩個版本，我們大幅度優化了UI，幾乎對所有頁面的前端xsml代碼進行了重構。通過長時間的努力，我們也取得了顯著的成果。以下是兩個版本的UI對比：
| 原頁面 | 新頁面 |
| 原主頁 | 新主頁 |
| 原我的發布 | 新我的發布 |
| 原我的申請 | 新我的申請 |
| 原發布詳情 | 新發布詳情 |
從上述對比可以看到UI、布局、配色的大幅度提升。
除頁面的優化外，自Alpha版本以來還進行了大量的BUG修復及操作修改，其中重大問題包括但不限于：
缺乏加載提示，網絡出現問題時顯示一片空白，導致用戶不清楚出現了何種問題
我們在之后的階段對所有頁面加入了加載提示：
修復了大輸入框在IOS端字體重影的問題（小程序自帶UI控件BUG）
自動聯想標簽的失焦問題：
自動聯想的標簽在Beta版本在進行滑動下拉等操作時也會判定為失焦，而自動關閉。這樣導致在備選項較多，超過一個屏幕長度時，用戶在進行滑動屏幕，想選擇屏幕外的標簽時，會判定為失焦而自動關閉。這一問題在之后得到了解決。
獲取頭像后無法登陸的問題
總而言之，Alpha版本是一個”能用“的版本，但存在諸多因為沒有經驗導致的設計問題、程序BUG。而在Gamma階段，我們不但修復了之前各類極度影響用戶體驗的BUG，還在UI設計方面下了更多功夫，引入了更多諸如圖標、不規則多邊形、圓角矩形、陰影等設計元素，將軟件質量大大提升。
| 原主頁 | 新模塊主頁 |
相比Alpha階段在軟件工程質量上的提高
相比Alpha階段，我們在軟件工程質量上的提高主要體現在三個方面：
- 明確了每個人擅長的工作，對分工進行了細化，讓每個人的工作效率盡量最大化
除了基本的PM、開發、測試的分工，我們經過Alpha階段的磨合，為每個人都分配了最適合的任務：
| byw | PM | 所有博客、進度追蹤、頁面設計、功能策劃、接口初步規劃、issues管理，盡量讓其他成員專注于編程 |
| wb | 前端開發 | 和bsh同寢室，共同負責大部分前端頁面的完成。 |
| bsh | 前端開發 | 負責部分前端頁面的完成及測試矩陣的完成 |
| szy | 后端開發 | 后端部分開發，后端接口的詳細設計，接口的單元測試 |
| lw | 后端開發 | 后端部分開發，服務器的一切管理事物，壓力測試 |
| lqh | 前端開發 | 小部分前端頁面開發，微信機器人的完成，博客gif的錄制 |
從Beta階段開始我們明確了這一詳細分工，這樣每位成員都能明確自己在每個迭代不同階段的職責，促進了任務的順利進行。
- 完善、詳細的前期規劃設計工作
經過Alpha階段，我們意識到了設計得越詳細，實現時的問題就越少。
在Alpha階段我們的接口設計較為簡單。在實現過程中，我們發現，接口作為前后端對接之處，任何一點理解上的不一致都會導致嚴重影響正常使用的bug發生。因此，我們在之后的階段中將接口設計盡量細致，對每個參數、返回值的類型、名稱、條件都做了相應要求。
- 將前端的UI、布局與實現過程分離
在Alpha階段，我們將前端每個頁面完全交給負責的相應開發人員。當時我們認為，由開發者決定用什么樣的控件、進行怎樣的布局，最大程度方便開發者，讓開發者選擇自己熟悉、使用方便的控件。因此，Alpha階段的頁面設計圖極其簡單：
但是，在實際運作過程中我們發現，前端開發人員不但要考慮如何可靠的實現功能，還要考慮布局、配色（尤其是配色。。。），不但沒有起到方便前端開發的作用，反而還大大拖慢了前端的開發進度，還導致頁面的美觀程度不盡人意。。因此，在之后的階段中，由PM負責對頁面進行詳細設計：
在有詳細的設計案后，前端開發人員有了具體的目標，反而提高了前端開發的速度，前端頁面的質量也有了巨大的提升。
我們在合作過程中學到的軟工知識
- 利用用戶反饋進行改正是提升品質的最快最好方法
無論怎樣精心的設計，都難免有遺漏之處。而當局者迷，發現這些漏洞的最好方法，莫過于發布體驗版或邀請用戶試用。用戶看待產品的角度與開發者、設計者有極大的不同，而用戶提出的問題往往也是在體驗中最明顯、影響最顯著的問題。因此，根據用戶的反饋修改產品是最高效、最準確的方法之一。 - 在長時間固定每位成員的職責后，能一定程度促進成員自覺，甚至提前完成任務
若分工或詳細職責頻繁更換時，往往需要PM話費較多經歷提醒成員其負責的工作、工作的DDL，對于PM和開發成員來說都不是一個好的體驗。而具體的分工確定后，每位成員對自己的職業非常清晰，知道自己在每個迭代的不同時期有何責任，一定程度上提高了成員工作的積極性和自主性，對于整體開發過程的體驗有較大的提升。 - 將設計與實現工作分離是提升效率及工作完成質量的重要步驟
在Alpha階段，我們將各個頁面完全交給負責的同學完整。我們原本的期望是，開發同學在工作時，可以根據自己的編程習慣等，選擇最適合自己，自己認為最方便最好用的空間、第三方庫。我們希望盡量不對前端開發人員進行限制，來方便他們進行開發。但實際工作中，由于開發者不但要考慮功能的可靠實現，還要考慮頁面的布局、設計，造成了進度緩慢，且設計質量不高。因此， - 功能越多、越方便接入用戶的平臺，往往審查條件越嚴格。留出足夠的緩沖時間以防萬一非常重要
我們的產品發布在微信小程序平臺上。微信小程序可用微信登錄，不用安裝直接從微信進入，具有巨大的流量引入優勢。但是，微信小程序的審查也非常嚴格：任何具有“信息發布類”功能的小程序，都需要通過注冊企業申請企業版小程序才可發布。并且，若企業版小程序具有任何審查員認為是“招聘、中介類”功能，還需要進一步提供“人力資源管理證”，才能通過審核。這一點在Beta階段為我們造成了較大的困擾。因此，在Gamma階段發布時，我們預留了足夠的時間，并且在發布前將后臺數據中和招聘類似的實習類發布下架，避免審查人員誤解，在通過審核后再重新上線。
團隊貢獻分
Gamma階段成員的貢獻分如下：
| bsh 1167 | 前端負責人 | 50 | 完成美賽查看申請者的界面完成美賽查看申請者，同意申請，拒絕申請等頁面功能完成美賽查看我的邀請的界面修復了上階段拒絕以后的圖標顯示BUG |
| byw 1173 | PM | 51 | 每日例會的召開與主持每日例會博客撰寫Gamma階段整體計劃規劃每日任務分配及Issues管理所有新頁面的設計測試報告、發布說明博客的撰寫功能、接口的規劃 |
| lqh 1168 | 微信監聽機器人開發 | 54 | 學習了微信小程序的開發 完成了前端美賽問卷調查頁面的實現完成了小程序新增功能展示的錄屏及gif制作 |
| lw 1175 | 后端負責人及測試 | 47 | gamma階段主要負責實現了獲取美賽信息修改美賽信息，搜索用戶，獲取美賽隊伍信息，提交評分，獲取推薦隊員，退出隊伍等7個后端接口實現了上述信息的相關的數據表最后進行了壓力測試 |
| wb 1155 | 前端開發及測試 | 52 | 完成美賽頁面完成美賽搜索功能完成美賽換一批功能完成美賽個人信息功能修復上階段無法查看申請者簡歷的bug修復上階段無法查看自己投遞的簡歷的bug修復上階段主頁進入不方便的bug |
| szy 1170 | 后端開發及測試 | 46 | 美賽后端邀請功能共5個接口所有單元測試的完成，包括之前版本的回歸測試及修改后端諸多BUG的修復協助前端進行ios系統的測試 |
其他階段的貢獻分參見貢獻分匯總博客
產品測試
在Gamma階段，我們同樣從單元測試、 壓力測試、前端測試矩陣三個方面進行了詳細的測試。
單元測試
單元測試的主要目的，是測試后端所有接口的工作是否正常。其內容主要包含兩方面：
- 接口在正常情況下是否能發揮預期功能
- 接口在異常情況下是否能返回預期錯誤信息
Gamma階段的所有單元測試與Alpha、Beta階段相同，在pycharm下使用Coverage工具進行測試。經過修改后已經通過了所有單元測試。
在Gamma階段，我們依舊針對每一個接口都設計了相應的單元測試?，F在，三個階段單元測試的總數高達203個。
在運行完所有單元測試后，單元測試的代碼覆蓋率高達96%，切實確保了所有接口的正確性。
單元測試中發現的bug如下：
后端單元測試Bug匯總
| /mcm/invite/<int:user_id>/ | 調用接口時返回錯誤碼500 | 數據庫操作時搜索的鍵名錯誤 | 是 |
| /mcm/invitations/send/ | 后端返回的邀請信息全是自己的信息，實際上應為被邀請者的信息 | 對數據庫搜索到的數據進行的索引錯誤 | 是 |
| /mcm/accept/<int:invitation_id>/ | 同意后未加入隊伍 | 更新數據庫是未進行保存 | 是 |
| /mcm/quit/ | 用戶退出隊伍后未成為單人隊伍的隊長 | 未更新用戶身份字段 | 是 |
| /mcm/accept/<int:invitation_id>/ | 邀請同意后被邀請者仍能在邀請列表里看見 | 未對被邀請者可見的邀請信息進行過濾 | 是 |
| /mcm/invite/<int:user_id>/ | 能夠邀請隊友 | 發出邀請是應過濾現有隊友 | 是 |
| /my/profile/modify/ | 無法修改個人資料 | account超出最大長度限制 | 是 |
| /mcm/search/user/ | 返回的user_id不正確 | 返回的user_id為整數，應改為string類型 | 是 |
| /mcm/match/ | 返回的推薦用戶中包含自己 | 沒有設置相關的查詢過濾條件 | 是 |
| /mcm/search/user/ | 無法獲取name參數 | name參數在url中，不能從body中獲取 | 是 |
| /mcm/match/ | 獲取推薦用戶時沒有正確過濾已發送邀請的用戶 | 設置的相關查詢過濾條件不正確 | 是 |
| /mcm/quit/ | 用戶作為隊員退出某一隊伍單獨一人時未自動成為隊長 | 缺少對數據表中相關字段的設置 | 是 |
| /mcm/invite/<int:user_id>/ | 調用接口時返回錯誤碼500 | 數據庫操作時搜索的鍵名錯誤 | 是 |
| /mcm/invitations/send/ | 后端返回的邀請信息全是自己的信息，實際上應為被邀請者的信息 | 對數據庫搜索到的數據進行的索引錯誤 | 是 |
| /mcm/accept/<int:invitation_id>/ | 同意后未加入隊伍 | 更新數據庫是未進行保存 | 是 |
| /mcm/quit/ | 用戶退出隊伍后未成為單人隊伍的隊長 | 未更新用戶身份字段 | 是 |
| /mcm/accept/<int:invitation_id>/ | 邀請同意后被邀請者仍能在邀請列表里看見 | 未對被邀請者可見的邀請信息進行過濾 | 是 |
| /mcm/invite/<int:user_id>/ | 能夠邀請隊友 | 發出邀請是應過濾現有隊友 | 是 |
表中詳細列出的BUG的現象及具體原因，目前后端發現的所有BUG均已解決。
壓力測試
進行的壓力測試與Beta階段使用相同工具?；緟等缦?#xff1a;
- 并發用戶數：500
- 總請求數 ：5135
進行壓力測試后的結果如下：
- 測試結果：
總請求數量為5135個的情況下，失敗請求數為2，表現良好。
平均響應時間為0.905s，吞吐率為51.2req/s。
Gamma階段壓力測試的表現相比Beta階段，有較大提升。
Beta階段壓力測試詳情請見這里
前端功能測試
對于前端的功能測試，仍采用與Alpha階段相同的方式，即在不同的機型、不同的操作系統下，對每個頁面的每個功能進行一一測試，以檢測其功能的正確性。前端功能測試的測試矩陣如下：
| 測試機型 | 測試環境 | 登錄 | 搜索 | 查看分類標簽 | 首頁智能推薦 | 修改個人信息 | 修改簡歷 | 查看招募 | 發布招募 | 查看我的發布 | 采納申請 | 申請招募 | 查看我的申請 | 填寫美賽個人信息 | 填寫美賽問卷 | 換一批推薦 | 退出隊伍 | 邀請推薦隊友 | 查看已發邀請 | 查看收到邀請 | 接受和拒絕邀請 | 搜索用戶 | 頁面排版 |
| Redmi K20 Pro | Android 9.0 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 顯示的人錯誤（偶爾） | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
| Mi6 | Android 9.0 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 顯示的人錯誤（偶爾） | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
| Honor Play | Android 9.0 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 顯示的人錯誤（偶爾） | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
| IQOO | Android 9.0 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 顯示的人錯誤（偶爾） | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
| iphone7 | IOS | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無法查看個人簡歷 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
| iphone8 | IOS | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無法查看申請者 | 無法查看申請者 | 無問題 | 無法查看個人簡歷 | 無問題 | 無問題 | 無問題 | 退出隊伍有時顯示其他人 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 | 無問題 |
回歸測試
從后端的接口測試部分可以看見，在進行Gamma階段的單元測試時，我們同時運行了前兩個階段已完成的單元測試，并對測試失敗的接口進行了修正，最后順利通過了Alpha、Beta階段的所有單元測試，保證了前兩個版本功能的正確性。
前端上，我們對前兩個版本的頁面也進行了詳細測試，確保了原功能的正確性。并修復了一些新發現的問題，如：
- 部分機型無法查看發出的申請簡歷問題
- 自動聯想表現在進行滑動屏幕時會判定為失焦，導致實際上超過一屏的聯想結果無法選擇的問題
轉載于:https://www.cnblogs.com/Water-T/p/11040366.html
總結
以上是生活随笔為你收集整理的[Gamma阶段]展示博客的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 虚拟化运维平台云安对政府机构的解决方案
- 下一篇： excel导出文本格式设置为数值(eas