[Gamma階段]展現博客

水哥牛X團隊[Gamma階段]展現博客

微信小程序搜索「小小易校園」便可體驗

項目願景

• 想參加競賽，鍛鍊本身，卻找不到合適的隊友
• 想進行實習，體驗工做，天天不得不翻遍吐槽版的幾百條信息卻一無所得
• 發佈在吐槽版的「求組隊」被聊天淹沒，無人問津
• 想找特定競賽、特定類型實習的通知，只能一個一個本身翻找，心力交瘁

組隊、招募信息大多在吐槽版發佈，而吐槽版每日上百條的消息量每每致使信息曝光率極低，形成了」想找組隊、招募信息的人找不到，發佈組隊、招募信息的人得不到迴應「的現象。

所以，決定開發「小小易校園」小程序，提供一個針對各種競賽組隊、各種實習招募信息的統一發布平臺，提供如下服務：

• 首頁集中顯示各種招募信息，並提供分類瀏覽、關鍵詞搜索等檢索功能
• 支持圖片上傳的招募發佈功能，並提供便捷的發佈管理頁面，可查看申請者簡歷、接受，拒絕他人申請
• 申請感興趣的發佈，在個人申請界面隨時查看申請狀態，並提供可隨時修改的簡歷模板

項目整體完成狀況

截至Gamma階段結束，咱們完整實現了本來計劃的信息發佈、申請管理功能，還額外添加了數學建模比賽專用的組隊及隊友匹配模塊，總共實現了30個不一樣頁面，39個不一樣功能接口：

全部頁面

全部接口

其中，Gamma階段完成的美賽模塊功能及頁面以下：

首頁及問卷填寫頁面	搜索特定用戶邀請組隊	更換推薦隊友及邀請
查看已發送的邀請	查看收到的邀請

• 填寫數學建模比賽信息問卷，系統自動打分，並根據分數匹配隊友候選——匹配自動屏蔽隊伍中的隊友、以已邀請過的用戶
• 邀請用戶進入隊伍，或接受他人邀請參加其餘隊伍、退出隊伍等隊伍管理操做
• 根據用戶名搜索用戶，尋找特定用戶進行組隊
• 點擊用戶經過下拉欄直接查看專業、競賽經歷等信息，避免頁面跳轉的等待

用戶狀況

用戶數量及用戶分析

截至2019/06/17，共有用戶量400人：

而這400用戶中，年齡分佈以下：

可見，絕大多數用戶爲18-24歲的在校大學生或剛畢業的大學生，用戶狀況符合前期調研的預期。

用戶反饋及根據反饋的修改

在發佈了Gamma階段的第一個版本後，咱們收集了用戶反饋。用戶反饋的主要問題有：

• 問題1

本來的登陸頁面中，有獲取頭像與姓名、進入主頁兩個Button。獲取頭像與姓名按鈕用於點擊後獲取用戶頭像。但這一步每每形成用戶迷惑，不知道這兩個按鈕點擊的順序、影響。所以，咱們對登陸頁面進行了修改：

新的登陸頁面只保留進入主頁按鈕，若沒有用戶的微信頭像等信息，則自動彈出權限獲取窗口。

• 問題2

該反饋針對美賽模塊的原首頁：

該頁面中，「已發邀請」、「收到邀請」、「重填問卷」、「換一批」爲可點擊按鈕，「個人隊伍」、「推薦隊友」爲提示信息，不可點擊。其中，「推薦隊友」模塊中，任意點擊任意用戶可查看詳細信息。

針對這一頁面，用戶提出瞭如下反饋：

因爲顏色相近，致使用戶不清楚哪些按鈕能夠點擊而哪些按鈕不能，更不知道點擊用戶可查看詳細信息。爲了改進這一問題，咱們一開始嘗試經過「較爲灰色的部分不可點擊，顏色明亮部分能夠點擊」的方式解決。所以，咱們向藝術生尋求了配色幫助。然而。。。。。。。。

這樣的配色並不能讓可點擊按鈕更加明顯。。而且配色風格與咱們小程序的總體風格嚴重不搭。通過一番嘗試，咱們最終選擇將全部可點擊按鈕加上下劃線，做爲提示。

這樣，咱們既保留了配色的統1、美觀，也提升了可點擊與不可點擊部分的區分度。

軟件質量與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階段，咱們依舊針對每個接口都設計了相應的單元測試。如今，三個階段單元測試的總數高達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階段使用相同工具。基本參數以下：

• 併發用戶數：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階段的全部單元測試，保證了前兩個版本功能的正確性。
前端上，咱們對前兩個版本的頁面也進行了詳細測試，確保了原功能的正確性。並修復了一些新發現的問題，如：

• 部分機型沒法查看發出的申請簡歷問題
• 自動聯想表如今進行滑動屏幕時會斷定爲失焦，致使實際上超過一屏的聯想結果沒法選擇的問題