總體測試計劃
| 測試模組 | 子模組 | 測試內容 | 預期結果 |
|---|---|---|---|
| 使用者登入 | 登入 | 學號為空 | 提示“學號不能為空” |
| 教務處密碼為空 | 提示“密碼不能為空” | ||
| 學號或密碼錯誤 | 提示“賬號或密碼錯誤” | ||
| 學號和密碼都正確 | 登入成功 | ||
| 個人資訊修改 | 頭像修改 | 點選頭像 | 提示“是否允許訪問”，後進入照相或選擇相簿圖片 |
| 選擇圖片 | 影象修改成功 | ||
| 我的資訊 | 點選我的資訊 | 出現使用者的相關資訊 | |
| 點選登出 | 退出賬號 | ||
| 訊息 | 各個對話方塊 | 點選對話方塊，和買家對話， | 可以實現 |
| 學習資料庫 | 專業課資料 | 點選相關資料 | |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 考研資料 | 點選相關資料 | 出現相關產品 | |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 課外資料 | 點選相關資料 | 出現相關產品 | |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 福大圖書館 | bug... | ||
| 二手市場 | 電動車 | 點選相關產品 | 出現相關產品 |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 銳捷 | 點選相關產品 | 出現相關產品 | |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 生活用品 | 點選相關產品 | 出現相關產品 | |
| 點選該欄目下相關產品 | 出現商品詳情及使用者資訊和“聯絡賣家”按鈕 | ||
| 點選“聯絡賣家” | 出現賣家資訊和“發訊息”按鈕 | ||
| 買家賣家通訊 | 能正常通訊 | ||
| 釋出產品 | TextView | 點選相應的對話方塊 | 是否可以進行編輯 |
| 新增照片 | 開啟相機或選擇照片 | 可以進行 | |
| 求購資訊 | bug... |
Bug記錄：
存在的bug
- 由於伺服器限制，查詢資訊速度沒有很快，不太穩定
- 個人和主頁點選切換時都會顯示被選中狀態
- 部分使用者操作錯誤提示沒有顯示
場景測試
| 場景一 | 即將畢業的大四學生劉星，宿舍裡有很多閒置的二手物品想轉讓，經好友推薦，下載這款福大易寶APP。用起來最大的感受就是操作簡單易懂容易上手。考慮好要賣哪些二手物品以及相應的價位後，劉星釋出了他的第一個商品資訊，隨後聯絡到了幾個想買他二手物品的童鞋，完成了他的第一筆交易。 |
|---|---|
| 場景二 | 剛進大學的大一小鮮肉夏雪，他覺得有些生活用品可以買一買二手的，可以省很多很多很多money。於是他開啟了福大易寶這款超級牛的APP，在購得他的第一個二手物品之前，他瀏覽了不少商品資訊，他感覺商品種類有點少（畢竟現在使用者量比較少），整體上感覺功能有點少，沒有特別好的使用者體驗。 |
| 場景三 | 大二的老油條夏雨，他偶爾會逛一逛淘寶，偶爾逛一逛二手市場，偶爾會出售自己的二手物品。所以他很喜歡這種二手市場APP。他感覺這款福大易寶APP用起來還是和鹹魚有挺大區別，不過整體感覺還行，基本的功能都能滿足自己的需要。目前還需要一個可以釋出求購資訊的功能，以便能買到自己真正需要的二手物品。期待下一個版本可以帶來一些更好、更新的使用者體驗！ |
上述三個場景中，場景一和場景二分別代表了買家和賣家，他們對這款福大易寶APP的評價和感受還是非常客觀的。普遍感覺整體不錯，但是還需要更多能刺激他們內心痛點的功能。買家釋出求購商品資訊後，賣家可以實時地檢視這些訊息，以便隨時和買家取得聯絡並完成交易。而賣家釋出二手商品資訊後，買家通過瀏覽商品資訊再完成交易，這兩種功能相輔相成，非常合理地滿足了使用者的需要。
安卓相容性測試
- 總體概況
- 失敗情況彙總
- 失敗機型如下
- 成功機型如下
- 效能概況
- 效能分析
可以根據效能對比可知，app的效能指標遠遠低於行業平均指標，佔用的空間記憶體等都比較小，這與我們app功能和定位有很大關係，apk的安裝包不足10M，功能有限，不過在已完成的功能體驗上有一定的較好體驗感。 - 失敗原因分析
由上圖，發現5.0.0以下系統的手機不能夠很好相容，這與我們開發時採用的框架不支援5.0.0以下的智慧手機有關。
app深度效能測試
- 效能分數
- 效能建議
- 效能問題
- 失敗分析
由於效能測試採用的手機系統版本較低，所以造成測試時不能夠進行安裝，只能對安裝包進行分析。
效能測試
考慮到APP的實際使用情況，查詢資料應該是使用者使用最多的功能。我使用siege對商品的根據一個類別查詢資料進行了效能測試。
這是siege的引數說明：
Transactions: 265 hits #完成265次處理
Availability: 100.00 % #成功率
Elapsed time: 27.27 secs #總共使用時間
Data transferred: 0.68 MB #共資料傳輸 0.68 MB
Response time: 11.33 secs #響應時間，顯示網路連線的速度
Transaction rate: 9.72 trans/sec #平均每秒完成 9.72 次處理
Throughput: 0.02 MB/sec #平均每秒傳送資料
Concurrency: 110.13 #實際最高併發連線數
Successful transactions: 265 #成功處理次數
Failed transactions: 0 #失敗處理次數
Longest transaction: 27.26 #每次傳輸所花最長時間
Shortest transaction: 0.61 #每次傳輸所花最短時間
從測試結果來看，在265併發，重複1次的時候，系統還可以正常執行，平均響應時間為11.33s，實際最高併發連線數可以達到110.13，但是到266併發重複1次時，資料庫就直接崩潰，連線斷開了。第一次測試的我超級虛的，還好重啟了下mariadb就可以了。
下面嘗試重複2次。
可以看出 在210併發重複請求2次就開始發生錯誤，最大併發連線數是66.23。
這是查詢模組伺服器目前可以訪問的壓力測試。
但是用siege，沒有實際的資料圖表來顯示，不友好的命令列。我嘗試用了騰訊的壓力測試工具。
這是我們的測試資料
我們選擇了從10人開始，依次增加到15人，每階段增加1人，每階段持續30s的壓力測試。
可以看出總共請求了11520次，失敗了72次。 並且109次出現了peerclose。平均響應時間是213.68ms.。
從post的請求率來看，在查詢這塊，伺服器還是能應對較多請求。只是伺服器CPU的使用率。。。
針對這個，我們的想法是：
第一點， 伺服器是1g記憶體 1核的學生特惠伺服器，硬體方面就只能先將就了。
第二點， 考慮到資料庫的查詢優化，我們打算在β做資料庫的快取優化。