NA端測試規範

1、      測試流程圖

2、bug等級標準

Priority： QA提交的bug應有修復優先級，共分爲四級，分別爲P0、P一、P二、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，可修可不修，修了最好，不修不影響發版

 

3、    case等級標準

測試用例的優先級用於標識重要性和執行頻率，共分爲4級，由高到低分別是P0、P一、P二、P3

詳細以下：

P0	核心功能測試用例（冒煙測試），肯定此版本是否可測的測試用例，此部分測試用例若是fail會阻礙大部分其餘測試用例的驗證。
P1	高優先級測試用例，最常執行以保證功能性是穩定的；基本功能測試，和重要的錯誤、邊界測試
P2	中優先級測試用例，更全面地驗證功能的各個方面，異常測試，邊界、中斷、斷網、容錯、UI等測試用例
P3	低優先級測試用例，不經常被執行，性能、壓力、兼容性、穩定性、安全、可用性等等。

 

4、    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~