• 測試環境
  • 作業系統：Android
  • 測試版本：版本號2.1.1
• 可復現性
  • 測試次數：5
  • Bug產生次數：5
    

Bug① 奇奇怪怪的頁面跳轉

首先是我覺得在測試過程中發現的，對使用者體驗感影響最大的，就是頁面跳轉功能的bug。

1.情況描述
當開啟某個功能頁下面的子頁面，再返回時，軟體並不是逐層返回上一個頁面到首頁，而是在功能頁，上次開啟的頁面，之間反覆跳轉，當遍歷了一遍你在這個功能頁開啟過的所有子頁面後，才返回到首頁。

例如：從下圖的功能列表頁面中開啟某個功能
開啟順序為：軟體首頁 → 一卡通功能列表頁 → a功能頁 → 返回一卡通功能頁 → b功能頁 → 一卡通功能列表頁

如此使用了一卡通功能頁內的兩個功能後，又返回了一卡通功能頁，現在如果點選返回按鈕的話，正常情況下，應該是直接返回到軟體首頁，但是Bug就在這裡出現了。

返回順序為（此操作只點擊了軟體左上角返回按鈕）：一卡通功能列表頁 → b功能頁 → 一卡通功能列表頁 → a功能頁 → 一卡通功能列表頁 → 軟體首頁

且下圖中，左上角白色的返回按鈕不起作用。

2.Bug分析

• 可能成因：返回按鈕設定的是返回上一瀏覽頁面，所以就根據你開啟的順序再一個一個重新訪問回去，直到回到首頁
• Bug嚴重等級（6顆滿）：❤❤❤
  • 系統功能：除跳轉錯誤外，並未對系統功能有較大的影響
  • 使用者體驗：使用者體驗感較差，不能快速返回首頁，需多次操作
  • 安全性：對安全性無明顯影響
• 預期改進：對返回按鈕做指定頁面的跳轉就可以了。

Bug② 只有表面功夫的功能模組

使用過i至誠的都知道，這個軟體內有許許多多的功能，但是其實很多功能都只是放了一個按鈕在那邊，並沒有真正可以實現的功能。或者是有一套完整的功能，但是並沒有實際投入使用。

1.情況描述

下圖中，更換頭像的拍照功能是無法開啟相機的

下圖中，一卡通餘額模組，和圖書借閱模組沒法跳轉到詳情頁面，這裡我不知道是本來的設計就是如此還是軟體Bug，但是在我的理解裡，如果點選可跳轉到該模組的詳情頁面就更好了。
且未讀郵件模組，開啟是一個報錯的空頁面，如圖所示：

下圖中，開啟校園社團模組，是一個只有框架的空模組。

下圖中，日程模組既沒有辦法根據學生的班級資訊自動生成課程表等日程資訊，也沒有辦法自己新增日程資訊，基本上就是一個沒有用途的擺設模組。

如此的模組其實還有一些，我只挑選了一些最典型的模組進行展示。

2.Bug分析

• 可能成因：使用者不太會使用這些功能，或有學習官網和微信公眾號這些有同樣功能，又高頻使用的地方，所以就沒有進行深入開發。
• Bug嚴重等級（6顆滿）：❤❤❤
  • 系統功能：只有外殼，無法實際使用
  • 使用者體驗：對實際需要使用的人來說，體驗感是比較差的。但是確實使用頻率不算高，所以總體體驗感只能算較差。
  • 安全性：對安全性無明顯影響
• 預期改進：許多功能在微信公眾號和學校官網都可以實現，但是如果能統一在一個軟體上就更加方便了，我覺得主要原因可能還是對軟體宣傳不到位，不是我這樣特意來測評的話，基本上不知道會有這些功能，而且大家還是更習慣用原本的途徑使用，建議將功能開發完善，並在日常學習工作中呼籲使用。

Bug③ 摸不到頭腦的搜尋功能

在事務功能頁面內，搜尋一串數字，歷史搜尋記錄卻顯示從單個數字開始搜尋，直到顯示成一串數字。而且我輸入的是申請事件的流水號，但是並沒有搜尋的結果，不太清楚這裡的搜尋功能具體是如何判定的。

2.Bug分析

• 可能成因：想要在客戶沒有輸入完整數字的時候就搜尋到相應的內容，所以在每輸入一個數字的時候就進行自動搜尋，但是忘記從歷史記錄中清除自動搜尋的內容。
• Bug嚴重等級（6顆滿）：❤❤
  • 系統功能：除了搜尋功能的反饋有些讓人摸不到頭腦外，基本能實現其他功能
  • 使用者體驗：其實是一個提升使用者體驗感的設計，只是沒有把歷史搜尋記錄保留的內容設計好
  • 安全性：對安全性無明顯影響
• 預期改進：在歷史記錄中，只保留使用者自己從鍵盤輸入後點擊搜尋按鈕的搜尋內容，不保留自動搜尋的內容。

Bug④ 一些小小的不太影響使用的bug

除了以上所寫的比較明顯的bug外，其實i至誠中還有一些小小的bug，並不影響使用，是我無意中發現的。

1.情況描述

下圖中，公告觀看的次數增加時，外面公告縮略部分的觀看次數不會增加。

2.Bug分析

• 可能成因：只在每次重新開啟軟體時才重新整理觀看的次數
• Bug嚴重等級（6顆滿）：❤
  • 系統功能：沒有明顯影響
  • 使用者體驗：很少會注意到這個部分，所以沒什麼影響使用者體驗之說
  • 安全性：對安全性無明顯影響
• 預期改進：將重新整理次數的時間設定在使用者每次點選頁面時

Part2. 功能分析

1.專案評估
估計需要26周左右，具體分析如下：

2.優劣勢分析

優勢：
①操作方便：單獨的app，無需藉助微信平臺，更方便操作。
②結構明瞭：功能模組的分類更加清晰。
③美觀性：更能體現本校的風格，比起公眾號來說，外觀也可以設計的更加美觀。
④時效性：app可以設定通知提醒，比起公眾號來說，可以更快的獲取到最新的資訊。

劣勢：
①缺少關鍵功能：缺少課程表、成績查詢、選課等學生經常使用的關鍵功能。
②卡頓：使用者流量較大時，會出現明顯的卡頓，或白屏等情況。

總而言之，雖然其他方面做得較好，但是缺少許多使用頻率高的關鍵功能，基於此，還是教務助手的實用性更高，如果能在App中加入教務助手的功能就再好不過了。

Part3. 建議和規劃

1.市場現狀

• 目前市場上是否有其他類似功能的產品、競品？

  • 基本上每個高校都會有一個屬於自己的校園幫手app，每個產品實現的功能都是類似的。如：福州大學的“福大助手APP”、福建師範大學的“福StarAPP” 、福建農林大學的“iFAFU APP”，“金山通”等等。

• 上述產品之間呈現什麼樣的關係，哪些為競品關係？以及競爭中的各方態勢如何？

  • 福建農林大學的兩款軟體互為競品關係，“iFAFU APP”是全校師生共同使用的而“金山通”主要為金山院區的學生提供服務。總體來說還是“iFAFU APP”的功能較為全面，所以使用的使用者也更多。

2.市場與產品生態

• 產品的使用者群體之間是否存在一定的關係？是否有利用其相互作用二次構成特定使用者生態的可能性？
  • 產品使用者都為師生，已經形成了校內的使用者生態。
• 產品的子產品，以及其他相關產品之間是否存在一定的關係？是否有利用各個產品特性之間的相互關係二次構成產品生態的可能性？
  • 產品使用者侷限於一個校區內，彼此之間除了功能類似外，無太大的聯絡。對於校內的產品來說，可開發一些有與教務無關，但與生活服務有關的功能的產品，實現校內產品生態。但是與外校產品之間，很難構成某種產品生態。

3.產品規劃

• 如果你是專案經理，可以招聘6個人，並且有4個月的時間，你認為應該如何配置角色(開發，測試，美工等等) 才能在第16周如期釋出軟體的改進版本，並取得預想中的成績。
  • 專案經理：負責調研，需求分析，協調溝通、總體規劃等。
  • 一名美工：負責完成UI設計
  • 三名開發人員：負責程式碼的編寫
  • 一名測試人員：負責軟體的測試
  • 一名文件編寫：負責階段文件的編寫
• 請為你的團隊設計16個週期每週的詳細規劃。