一、 測試流程圖
二、bug等級標準
Priority： QA提交的bug應有修復優先級，共分爲四級，分別爲P0、P1、P2、P3， 其中P0最高，P3最低。P0&P1的bug必須要在上線前完全修復。詳細說明如下：
P0: 完全不能滿足產品要求，基本功能明顯未實現或完全不可用。產品發佈後，出現此類問題，將導致產品必須下線或發小版本修復。
l 性能及穩定性
1. 嚴重crash, 閃退，黑屏, ANR(Application Not Responding)，無法啓動
2. 嚴重性能問題: CPU長期佔用不釋放(後臺服務死循環); 後臺或殺死進程後, 依然佔用系統資源
3. 嚴重流量問題: 請求過大/不斷重複請求(偷跑流量問題)
4. 頁面FPS(每秒傳輸幀數)低, 不可忍受的卡頓(反射出內存問題)
5. 首頁啓動/頁面加載/圖片加載/退出頁面時間超過3s或明顯可感知的變慢
l 數據錯誤
1. 用戶信息丟失或錯誤，如升級及覆蓋安裝後數據異常
2. 核心數據, 例如購物車、提單頁菜品、金額錯誤
3. 影響結算的金額錯誤，如下單返券金額
l 功能及視覺
1. 核心功能實現錯誤或未實現，如阻塞下單流程(新用戶命中反作弊不可下單)
2. 嚴重視覺問題: 核心頁面，如首頁金剛/動態入口、購物車提單頁小數點精度問題
3. 頁面明顯bug且嚴重影響用戶使用(元素不可點、核心頁面錯亂)
4. 操作系統兼容性問題導致的核心功能異常/Crash等
l 其他
1. 嚴重線上問題並且影響用戶使用, 或大量用戶反饋
2. 嚴重編碼規範及CR問題修復, RD提交測試代碼
3. BOSS發現的問題/影響外賣形象的問題
P1：產品的功能實現和需求不符合，沒有達到預期的效果，或是性能問題、安全性問題。產品出現此類問題，
可能會導致用戶投訴，或者轉入競爭對手的產品。
l 性能及穩定性
1. 復現概率極低的閃退、crash、ANR
2. 嚴重性能問題: 內存使用過多且沒有正常回收; listview等控件沒有重用導致GC嚴重;
3. 嚴重流量問題: 異常請求數據或者多次重複請求數據導致流量損耗
4. UE大尺寸切圖帶來的內存增長
l 功能及視覺
1. 主要模塊的主要使用路徑上的bug，非核心流程，不block測試或僅block少量case
2. 次要功能實現錯誤，或未實現
3. 嚴重視覺問題: 非核心頁面, 但是用戶體驗很差
4. 操作系統兼容性問題導致的次要功能異常
P2：比較小的功能、UI或交互問題，用戶可以繞過此類問題來使用產品。出現此類問題，用戶可能會抱怨，但是並不一定導致用戶流失。經常可能是界面佈局有問題、用戶不常使用的情景發現的問題。
l 性能及穩定性
1. 復現概率極低的閃退，且無crash日誌.
2. 佔比率極低的非主流系統兼容性閃退.
l 功能及視覺
1. 非常規操作或非常規路徑、如多步複合操作後才能復現的問題（用戶一般不這樣操作）
2. 異常情況處理缺失，如斷網、弱網、中斷操作(電話中斷、後臺前臺切換)
3. 視覺效果與UE設計不完全一致
4. 文案過長被遮蓋、未截斷或未折行
5. 交互體驗類bug: 與系統交互或常人認知不符的交互問題
6. UI兼容性/適配問題
l 其他
1. 安全保護代碼: 參數檢查, 判空，數組越界保護, 類型溢出
P3：極少衆機型適配問題，建議類bug，可修可不修，修了最好，不修不影響發版
三、 case等級標準
測試用例的優先級用於標識重要性和執行頻率，共分爲4級，由高到低分別是P0、P1、P2、P3
詳細如下：
| P0 |
核心功能測試用例（冒煙測試），確定此版本是否可測的測試用例，此部分測試用例如果fail會阻礙大部分其他測試用例的驗證。 |
| P1 |
高優先級測試用例，最常執行以保證功能性是穩定的；基本功能測試，和重要的錯誤、邊界測試 |
| P2 |
中優先級測試用例，更全面地驗證功能的各個方面，異常測試，邊界、中斷、斷網、容錯、UI等測試用例 |
| P3 |
低優先級測試用例，不常常被執行，性能、壓力、兼容性、穩定性、安全、可用性等等。 |
四、 QA注意事項
1. 需求評審前應先對MRD進行閱讀分析，對其中疑點先行記錄，挖掘異常點，在評審時將自己疑問提出
2. 需求變更時，請PM將最後決定以郵件形式周知
3. Case設計時應先保證正常流程case全部覆蓋後再可能的多些異常考慮
4. RD在wiki提供接口文檔後應能熟悉各接口意義
5. 測試前可主動與RD進行測前溝通，聽取建議方法
6. 測試中如遇遺漏case應及時添加到case列表中，以免忘記
7. 不管來自任何渠道的bug都應在icafe裏記錄，爲後續做統計或引以爲戒
8. bug編輯時應在描述裏清晰表明【問題方向】、【問題描述】、【復現步驟】、【特殊機型】等，若有截圖或log應一併添加
9. 執行穩定測試和性能測試後，結果應以郵件形式周知，郵件內容應清晰表達
10. RD修改代碼後應能主動了解修改模塊及測試方法
11. RD修改bug後推動RD在icafe中簡單描述bug原因，解決方法和建議測試模塊和方法
12. 集成測試中RD代碼提交後應能及時打包迴歸驗證
13. 單個Bug驗證時若有可能被影響的模塊，可一併進行測試
14. 測前提前瞭解環境是否可行，如遇環境阻塞，應能推動RD及時解決，以免縮短QA測試時間
15. 兼容測試時若時間不允許，應優先保證主流機型和系統的兼容型
16. 覆蓋安裝和卸載重裝時應保證數據無丟失、無異常現象
17. 重視升級測試
18. 產品發版後，應對放入市場上app進行線上迴歸，以便提前發現線上問題
19. 線上bug可持續記錄在wiki上，描述可包含【問題描述】、【原因】、【影響度】【解決方式】等
20. QA要對自己要有足夠的信心，相信自己O(∩_∩)O~
