NA端测试规范

一、      测试流程图

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