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~