测试设计

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

平安科技移动二队

移动端产品测试标准及方案

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目录

1.产品测试标准.. 4

1.1功能测试标准.. 4

1.1.1手工测试用例分类以及测试通过率标准.. 4

1.1.2 Bug修复率标准.. 7

1.1.3核心功能点列表.. 8

1.2性能测试标准.. 8

1.2.1性能测试指标.. 8

1.2.2性能指标影响因素.. 8

1.2.3性能测试标准.. 9

1.3稳定性测试标准.. 9

1.3.1 Monkey. 9

1.3.2 Rack test9

1.4 兼容性测试标准.. 10

1.4.1硬件兼容性指标.. 10

1.4.2软件兼容性指标.. 10

1.4.3网络兼容性指标.. 11

1.4.4数据兼容性.. 11

1.5 API交互测试标准.. 11

1.6核心API交互场景线上监控.. 12

1.7上线checklist12

 

 

 

 

 

 

 

 

 

 

 

 

 

修订记录：

文档修订记录
修改时间	修改人	审核人	备注
2015/5/4	刘慧众 黄小婷

 

 

1.产品测试标准

1.1功能测试标准

1.1.1手工测试用例分类以及测试通过率标准

       目前APP客户端每个版本需要手工测试执行的用例基本划分为以下几类：

²  冒烟测试用例 （Smoke testcase：SMT）

²  新功能测试用例（System NewTest case: SNT）

²  核心功能测试用例（Core Testcase：CT）

²  Bug验证用例(Defect verifytest case: DVT)

²  相关功能回归测试用例（Regressiontest case）

 

类型	覆盖范围	用例规模	特点
SMT	最基本功能的验证，无特殊输入输出，无特殊中断交互，无高压，无兼容性	覆盖基本功能用例	用例相比系统级测试用例，撰写内容经过抽象，面向功能主干的可用性。确保产品可测，单条用例的覆盖面高于一般的系统测试用例
SNT	全面的，完整的新增功能测试用例	视app新增功能的规模	用例撰写详细，全面，细致点出检查点。
CT	已有核心功能用例	视app核心功能模块而定	覆盖核心功能模块基本功能。
DVT	面向已经修复的bug，检验其是否修复，有无side effect	无测试用例，参考提交bug。	参考内容为bug report
RGT	基本功能回归测试用例，无边界检验，无特殊中断交互，无压力测试	大约为系统级测试用例的25-35%	和准入测试用例的覆盖类型相当，用例为系统测试的一部分，
RGDVT	接近于RGT+DVT，但这里的DVT不是本轮次的bug，而是标记在测试用例执行中，被标记fail以及block过的用例	用例规模的50%左右	在RGT的基础上，验收版本曾发生过的问题的用例

 

备注：系统级测试用例包含范围：

•   Basic– 基本功能测试：面向于被测应用的基本功能实现（MRD从文字到代码的过程）

•   Boundary– 边界分析测试：在基本功能的基础上，开始考虑各种输入输出的影响

•   Memory– 存储测试：主要测试涉及存储空间读写的部分

•   Performance– 响应速度，资源占用：响应速度，资源占用，流量消耗，CPU开销的测试

•   Stress– 压力测试：在基本功能上的提升负载，速度，吞吐量等指标

•   IOT/compatibility  – 互操作测试/兼容性测试 ：检验相同的功能在不同的环境下的表现能力

•   Interrupt– 中断功能测试：当前的被测APP被另外的APP打断当前的功能执行状态

•   Interaction– 交互功能测试：APP和APP之间的调用，以及不存在APP层面的调用，但是存在更低一层的资源抢夺以及公用。

 

用例实施分级，通过重要程度做分级。

l  A级用例，覆盖核心功能基本功能，比例控制在总用例数量的15%左右

l  B级用例，覆盖非核心基本功能，核心功能边界值，交互操作和中断，比例控制在35%左右

l  C级用例，覆盖非核心功能边界，交互中断，以及兼容性，35%左右

l  D级用例，压力、性能、存储等其他测试内容，15%左右。

RD同学对A级用例做必须保障，QA则以A级用例作为准入约束条件（对稳定性测试，兼容性测试等相应增加准入约束），并建议RD同学常识性的从B到D级用例逐层下探，阶段性提升提测质量。

用例分级参考

核心功能	主要功能（短路径）	主要功能（长路径）	次要功能（短路径）	次要功能（长路径）
基本功能 边界测试（面向功能）	0	0	0_1	1_2	2
边界功能（面向UI展现） 交互测试（主动交互）	0	0_1	1	2	2
交互测试（非主动） 中断测试（常见） 兼容性（功能级别） 存储测试(常见功能）	0_1	1	1_2	2	3
中断测试（非常见） 兼容性（UI级别） 存储测试（非常见）	1_2	1_2	2	3	3
压力测试 性能测试	2	2	3	3	3

 

 

一般执行次序为(前一项测试的通过是后一项测试的触发条件，RGT和RGDVT可以根据情况合并)：

 

冒烟测试：必执行

l  用例范围：冒烟测试用例关注新开发/修改模块的基本功能，挑选正常路径、常规输入的测试用例，验证软件的基本质量。

l  数量：新功能测试用例的15~30%左右。以A级用例为主

l  执行角色：rd（开发人员）自测和qa（测试人员）测试

l  通过标准：冒烟测试用例通过率100%；若rd自测未通过，则继续开发直到自测通过；若qa测试未通过，则打回提测版本。QA不介入测试，RD继续开发，给出新的提测时间点，测试排期顺延。

 

系统测试：必执行

l  用例范围：新功能用例、核心功能用例、相关功能回归用例

²  新功能用例：根据mrd开发出的测试用例，关注所有新功能

²  核心功能用例：关注产品所有已有功能的最核心操作，覆盖用户常用功能

²  相关功能用例：关注跟新功能有关的功能模块或较长时间没有回归的模块，需要在测试排期设计阶段或后续项目进行过程中，与pm协商确认测试范围或调整测试范围

•   项目排期宽裕且进度正常情况下，执行所挑选模块的所有用例

•   项目排期较紧或后期测试时间不够的情况下，挑选优先级高的case覆盖基本功能：相关功能覆盖A+B级别

•   项目排期紧急或后期测试时间严重不足的情况下，放弃本部分测试。

l  数量：新功能用例+核心功能（basic用例）用例+相关功能用用例

²  新功能：全部

²  核心功能：核心功能（各个产品线自行补充）中的基本功能

²  相关功能：

•   正常情况：根据产品线功能规模设定

•   排期较紧：根据产线功能规模设定

•   排期很紧张：0条

l  执行角色：QA

l  执行标准：一般系统级测试用例Fullrun仅在大版本升级，代码重构后执行，通常的小版本迭代（如消息推送）仅覆盖新增功能的系统级测试用例。另外模块级的较大变更甚至重构后，对应模块的系统级测试用例用例触发进入测试。

l  通过标准：介入执行的测试用例通过率95%+

 

Bug验证测试：必执行

l  范围：根据bug的提交报告做测试

l  数量：上一轮遗留bug的95%

l  执行角色：QA；

l  执行标准：S0-S1bug全部修复提交，S2-S3bug修复90%+，总体修复95%+

l  通过标准：标记fixed的bug 100%通过验证并无严重新问题引入。

 

回归测试：必执行

基本功能回归测试：必执行, code freeze后，两天开始（和rd沟通，短期目标核心功能测试前完成样式调整，高优先级bug修改）

l  范围：系统级测试用例中basic的部分+fail，block的case内容

l  数量：200左右条+

l  执行角色：线下QA；线上回归QA及pm

l  执行标准：

²  正常情况：200条左右

²  排期紧张：100条核心功能用例

备注：若新增的模块和老功能耦合性小，则RGT线下部分可以合并到RGDVT线上一起。若耦合性较大，则在新功能的系统级测试完成且bug修复达到预期后，做相关老功能块的基本功能回归，确保老功能块完备。

l  通过标准：测试用例通过率98%+

 

1.1.2 Bug修复率标准

1、优先级为0级和1级的必须修复（这里使用优先级作为标准，而不是严重等级，bug严重等级划分标准以及优先级与严重等级的关系，请参考附表）。

2、Bug修复率达到95%以上。

附：bug严重等级划分标准

严重等级	错误类型
0	应用造成系统崩溃或严重资源不足、阻塞后续测试工作
1	应用崩溃或无响应、功能未实现或实现与需求严重不符、正常路径工作异常
2	界面或文案问题、功能实现不完善或个别路径使用异常
3	易用性或建议类的问题

 

优先级与严重等级关系:

复现率 严重等级	100%重现	偶尔复现	较难复现
0	0	0	1
1	0	1	2
2	1	2	3
3	3	3	3

另，强烈影响用户体验和感情的bug，可以在不考虑严重等级的情况下提高优先级。

 

 

1.1.3核心功能点列表

核心功能点列表适用于服务端、后端数据做修改后，除需专门验证的功能外，客户端还需要验收的功能提纲。

 

各个产品线根据核心功能做梳理，核心覆盖需要和产品线达成一致

1.2性能测试标准

1.2.1性能测试指标

一般对于新生产品，优先功能测试，之后才会是安全、性能方面的测试，随着客服端越来越完善，用户群越来越多，性能、响应、稳定性也被重点关注。

产品性能测试一般分为两部分：

系统性能测试：包括CPU，内存，耗电量，流畅度

业务性能测试：包括多个业务的响应时间，以及对应的流量、

 

1.2.2性能指标影响因素

各个性能指标的影响因素考虑如下：

1.    CPU：

CPU的主要功能是用于计算处理，所以CPU占用率影响因素主要是CPU性能，以及产品中需要进行大规模计算处理的场景，比如导航产品中的引导用户行进的场景。

2.    内存：

内存用于快速存取数据，所以内存占用率影响的因素是产品中数据大规模交换的场景，以及屏幕大小。屏幕大小是影响因素的原因是对于不同分辨率程序所用的贴图是不同的，所以消耗的内存也不同

3.    耗电量

耗电量可根据产品特点，主要测试需要产品长时间运行的场景。比如音乐后台播放，导航过程等。

4.    响应时间、流量

响应时间与流量，主要考虑测试产品核心功能，以及与其他产品功能相似、可做竞品对比的场景。

5.    流畅度

功能使用和切换中的，页面流畅程度，通过帧率等方式可以获得流畅度。

1.2.3性能测试标准

对用户而言：特定网络下客户端流畅不流畅、响应快不快决定着用户对客户端的使用时长和粘度；此外，用户在考虑速度的同时，还会考虑跟自身利益相关的—-金额&网络流量的消耗。由此根据用户需求，总结如下：

•  移动份额占主导-2G网络不容忽视

•  消费者对消费金额是比较在意的-因此app使用时消耗的流量需要关注

•  使用app时，页面的响应时间，直接影响用户体验，必须关注

•  wifi 户外还未普及

另外考虑业务特点，针对性的输出对应的性能测试用例

所以在不同网络下响应时间，流量消耗，是性能测试关注的重点。

若产品有竞品需求，可以对竞品进行同一场景的对比测试。

至于性能测试的机型，建议使用兼容性中确定的机型

测试说明：执行尽量覆盖典型机型，需与pm、rd沟通确定，但是在测试资源有限的情况下选择已有测试机型中市场占有量高的某一款机型进行测试。

1.3稳定性测试标准

1.3.1 Monkey

Monkey测试通过使用monkey及类monkey的工具连续随机注入例如屏幕点击、滑动、键盘输入等事件，模拟用户无序随机的操作身边应用，从而在一段较长时间内衡量身边的稳定性。

通过标准：

²  事件输入间隔设置为300ms

²  平均无故障时间达到Android8小时以上，IOS8小时以上，过程中被测试应用无Force close、ANR、Native Crash，无因身边应用导致的手机 freeze、shut down或powercycle。

1.3.2 Rack test

针对被测试应用的功能优先级和使用频率，选取测试点，对每个测试点设定需要执行的次数，然后在一周期内重复执行，从而模拟用户长期、常规使用的行为，测试过程中通过关注崩溃、无响应、重启、内存增长趋势等情况，来检查程序的稳定性。

通过标准：

²  执行过程中，被测试应用无Forceclose、ANR、Native Crash，无因应用导致的phone freeze、shut down或power cycle。

²  从执行开始到结束，进程占用的内存变化量小于一定范围，具体检查方法见测试方案。

内存警告测试

测试说明：核心功能稳定性参考核心功能用例UI自动化转化实际状况，对实现UI自动化的，通过ract。

1.4 兼容性测试标准

兼容性测试就是检查软件在一个特定的硬件、软件、操作系统、网络等环境下是否能够正常地运行，检查软件之间是否能够正确地交互和共享信息。

1.4.1硬件兼容性指标

l  分辨率兼容性

智能手机分辨率的兼容性测试主要关注的是程序不同页面，弹窗，提示等在不同分辨率下显示的是否正常（包括横竖屏的切换）。

主要考虑因素如下：

1. 分辨率市场占有率topN，参考和产品线PM沟通的结果。
2. 产品用户所用分辨率topN

l  机型兼容性

需要保证市场占用率较大的厂商机器可以正常执行产品功能，比如三星、htc，同时结合市场占有率和产品线的数据统计确定测试机型。

主要考虑因素如下：

1. 主流机型的市场占有率的top3
2. 产品线用户机型的top3
3. 特殊厂商，特殊机型。

l  操作系统兼容性

不同的操作系统及同一操作系统不同版本对程序处理方式可能会不同，所以要针对产品对操作系统做兼容性测试。

主要考虑因素如下：

1. 操作系统原生版市场占有率的top3
2. 特殊厂商，自己制作了适合自己手机的rom，比如小米系统、魅族、CM等，与原生系统略有些不一样。
3. android测试，大版本覆盖到小数点后一位，如2.3.X，4.1.X，5.1.X，小版本覆盖到整数位，2.X，4.X，5.X；IOS同Android，但作为最新的系统版本必测。

1.4.2软件兼容性指标

主要考察两项内容：一是软件运行需要哪些其他应用软件的支持，二是判断与其他常用软件如MSOFFICE，反病毒软件一起使用，是否造成其他软件运行错误或软件本身不能正确实现其功能。

与其他软件交互时主要有以下三个部分：

APP兼容性	平安APP系列：口袋银行，平安好车主 ……	相互无冲突
	监控类产品：网秦、360手机卫士	相互无冲突
	聊天类产品：QQ、飞信	相互无冲突
	浏览器产品：UC	相互无冲突
	输入法产品：QQ输入法、搜狗输入法	相互无冲突
	系统工具：蓝牙助手、高级任务管理、缓存助手	相互无冲突
	娱乐播放类：豆瓣电台、酷我听听、天天、优酷、QQ音乐	相互无冲突

1.4.3网络兼容性指标

网络兼容性，是保证各种网络环境能够够完全覆盖，排除由于不同网络网关特殊处理导致产品功能不可用情况，同时也需要检查在各种网络下的用户体验问题。主要包括移动2g，3g，4g，联通2g，3g，4g，有鉴权的wifi和无鉴权的wifi

		接入点	测试结果	说明
网络	移动	cmnet
		cmwap
	联通	uninet
		uniwap
		3gwap
		3gnet
	电信	ctnet(2g/3g)
		ctwap(2g/3g)
	wifi

 

1.4.4数据兼容性

通常指不同版本间的数据兼容性，主要检查低版本程序运行产生的数据在安装新版本后是否可用，或者正常升级的情况下，用户原始数据是否丢失。

1.5 API交互测试标准*

Api交互测试关注客户端在server api返回数据异常或延时的情况下的容错能力，考量客户端的健壮性已经在错误发生后的恢复能力。

初期拟挑选以下页面进行的测试，挑选原则：

1、 关键页面（高pv）

2、 返回数据量大

考察页面

对应请求url示例

异常数据构造点

 

通过标准：

1、 数据返回延时的情况下，客户端能够正确处理，给出友好提示；无崩溃、持续加载或页面显示异常的问题。

2、 在延时情况发生后，再次请求数据，正常返回的情况下，客户端可以恢复正常使用。

3、 客户端健壮，具有容错性，在返回数据异常的情况下，可以特殊处理，不会因此出现崩溃、显示乱码等问题。

----详见移动APP测试报告 异常交互测试sheet。

1.6核心API交互场景线上监控

为保证线上服务端核心功能或场景对应的接口是稳定的，并且产品相关人员能先于用户发现线上问题，我们开启了核心API交互场景线上兼容。

主要监控核心API线上服务稳定可用，并基于可用的基础挖掘错误的

1.7上线checklist

上线checklist检验产品约定测试内容的测试结果，属于测试报告提交时的一部分。主要包括的内容有，功能性指标，性能指标，兼容性指标，网络和系统覆盖等内容。

见附件APP store审核checkList，以及平安科技移动二队客户端产品测试报告。