竞品分析测试方案
竞品分析测试方案
1 测试哪些竞品？
将RCS的业务进行划分，各自选择1~2款当前最流行的APP应用作为竞争产品进行分析，其中：
●视频业务区分ios平台和android平台，分别选择FaceTime和微信作为分析对象；
●消息类业务区分国内外的流行软件，国内主要是微信，海外主要是whatsapp业务，分析
过程中同时拿两款app作为分析对象；
●呈现类业务，目前做的最好的软件微信作为分析对象；
●综合指标部分选择和RCS业务最相似的微信和skype作为分析对象。
2 测试哪些维度？
Qos测试基于网络有一定网络话务模型下进行竞品测试。根据《QoS&话务模型&性能规格》（2013-7-22刷新）中的定义，典型网络QoS模型如下：
注：
1、其中WIFI/宽带接入为必选场景，3G接入/2G接入为可选场景。
2、“丢包率、时延、抖动”等数值均指一侧的数据，即指UE->SBC->IMS(AS)的数据。需
要注意的是，在测试部分场景时，需要在两个UE侧加扰，比如在测试音频的“WIFI:较差”场景时，需要在UE1->SBC->IMS(AS)一侧按照"丢包：11.5%，时延：215ms，抖动：100ms"加扰，同时需要在UE2->SBC一侧也按照"丢包：11.5%，时延：215ms，抖动：100ms"加扰。
3 测试哪些项？
3.1 音频业务
3.1.1功能完备性
针对音频呼叫的功能完备性，进行如下维度的功能完备性测试
3.1.2Qos质量
在对比测试过程中，各个影响参数的设置如下：
针对语音呼叫的Qos分析，需要测试的关键指标如下（包括统计方法）：
3.2 视频业务
3.2.1功能完备性
针对视频频呼叫的功能完备性，进行如下维度的功能完备性测试
3.2.2Qos质量
在对比测试过程中，各个影响业务的参数设置如下：
针对视频呼叫的Qos分析，需要测试的关键指标如下（包括统计方法）
3.3 消息类业务3.3.1功能完备性
3.3.2Qos质量
【IM业务】
在IM业务的对比测试过程中，各个影响业务的参数设置如下：
针对IM业务的Qos分析，需要测试的关键指标如下（包括统计方法）
【位置业务】
位置业务使用IM消息发送，测试结果以IM业务的测试结果为准，不针对位置业务进行独立的Qos测试。
【图片共享】
在图片共享的对比测试过程中，各个影响业务的参数设置如下
针对图片共享的Qos分析，需要测试的关键指标如下（包括统计方法）
【名片共享】
名片共享业务使用IM消息发送，测试结果以IM业务的测试结果为准，不针对名片共享进行独立的Qos测试。
【视频文件共享】
在视频文件共享的对比测试过程中，各个影响业务的参数设置如下
针对视频文件共享的Qos分析，需要测试的关键指标如下（包括统计方法）
【PTT共享】
在PTT共享的对比测试过程中，各个影响业务的参数设置如下
针对PTT共享的Qos分析，需要测试的关键指标如下（包括统计方法）
3.4 登陆注销（包括断网重连） 3.
4.1 功能完备性
3.4.2 Qos 质量
测试RCS 和竞争产品在现网WiFi 网络上的注册时长和成功率，每种场景测试10次，取其平均值作为测试结果。
3.5 呈现类业务 3.5.1
功能完备性
3.5.2 Qos 质量
RCS 和微信在Presence 业务上的实现存在一定的差异。测试策略如下：
3.6 性能指标
性能测试指标是除业务完备度和用户体验外，最直接的竞争力体现。本测试方案针对安装包大小CPU、内存、流量、电量、流畅度进行对比测试。
3.6.1安装包大小
比较软件的安装包大小。
3.6.2CPU
对于APP来讲，CPU测试和内存测试根据如下几点考虑测试场景。
在相对稳定的状态进行CPU的测试和对比；
说明：对APP的稳定状态进行测试，因为用户一般不会感受到CPU的飙高，CPU的对外
呈现是终端的发热量、app的使用流畅度。对于操作过程瞬时状态用户较难察觉，因此竞品测试过程中基于如下两个原则设计场景：
针对场景进行的通用性。
说明：由于软件的业务和架构不同，无法做到很细节场景的对比，因此测试过程中关注业务场景，对应的配置以默认配置为准。某些业务独有的特性在业务实现完备性章节进行测试，不在性能指标中作为专项测试。
基于以上原则，抽象出以下几种测试场景：
1、后台运行
场景构造：空联系人，同一款终端，登陆10分钟后在后台运行。
测试方法：观察CPU的占用持续5分钟。
2、前台运行
场景构造：空联系人，同一款终端，登陆10分钟后在后台运行。
测试方法：在被测系统运行在前台，按照正常使用速度且在“1级”页面切换，观察CPU 的占用持续5分钟。
3、IM聊天过程中
场景构造：每个终端1个联系人。两个终端之间互发进行操作。
测试方法：按照如下顺序循环发送，若不支持则跳过。A发送消息给B；B发送消息给A；
A发送表情给B；B发送表情给A；A发送照片给B；B发送照片给A；A发送名片给B；B 发送名片给A；循环操作，持续5分钟观察cpu变化。业务结束后须持观察CPU5分钟。
4、音视频呼叫过程中
场景构造：每个终端1个联系人。
测试方法：从呼叫开始前30s开始到呼叫接触后持续观察5分钟。呼叫持续5分钟。
3.6.3内存
同CPU测试场景，抽象出以下几种测试场景：
1、后台运行
场景构造：空联系人，同一款终端，登陆10分钟后在后台运行。
测试方法：观察CPU的占用持续5分钟。
2、前台运行
场景构造：空联系人，同一款终端，登陆10分钟后在后台运行。
测试方法：在被测系统运行在前台，按照正常使用速度且在“1级”页面切换，观察内存的占用持续5分钟。
3、IM聊天过程中
场景构造：每个终端1个联系人。两个终端之间互发进行操作。
测试方法：按照如下顺序循环发送，若不支持则跳过。A发送消息给B；B发送消息给A；
A发送表情给B；B发送表情给A；A发送照片给B；B发送照片给A；A发送名片给B；B 发送名片给A；循环操作，持续5分钟观察cpu变化。业务结束后须持观察CPU5分钟。
4、音视频呼叫过程中
场景构造：每个终端1个联系人。
测试方法：从呼叫开始前30s开始到呼叫接触后持续观察5分钟。呼叫持续5分钟。
3.6.4流量
流量测试采用第三方软件进行统计。采用《瓦力流量仪》作为测试工具
预置条件：区分android和ios平台，Android使用防火墙屏蔽其他APP访问网络，ios在后台删除掉非被测软件和统计工具外的其它APP应用。软件的设置项采用APP应用的默认设置。
测试场景：
1、空跑一轮
不安装被测软件，只安装统计工具，目的是将测试结果作为参考基线，减少测试过程中误差
2、登陆
被测软件均统计在安装软件后首次登陆消耗的流量。由于当前RCS做成自动发现好友。
在和不同软件时间进行对比时，需要完成的流程如下：
说明：得到测试数据后，需要结合好友数量才能比对产品之间的测试数据。
3、后台运行1个小时
登陆成功后在后台运行1个小时。
4、前台运行1个小时
登陆成功后在前台运行1个小时。被测软件停留在登陆后的默认页面，关闭系统锁屏功能。
5、IM发送文本50条（测试3组数据）
终端A和终端B登陆后，互发IM文本消息，互发30分钟，文本内容固定为“1”->“50”
依次增加1.
6、音频10分钟
以默认编解码进行测试
7、视频10分钟
以默认编解码进行测试
3.6.5电量
电量测试继承使用版本测试的方法，使用如下几种测试场景进行和竞品的分析。
1、后台运行12个小时；
2、视频呼叫1个小时；
3、音频呼叫1个小时；
说明：iOS平台直接读取iPhone自身电量显示。Android平台采用第3方电量测试工具（金山电池医生）显示电量。测试时通过杀死后台程序的方式仅保留被测软件和测量工具。
3.6.6发热量
本方案暂时不关注
3.6.7流畅度
流畅度的测试在本版本首次执行，作为一个独立的测试项，需要输入单独的文档，本文档不进行描述，具体测试方案请参考《RCS Client V100R005C00流畅度测试方案》
3.7 用户体验评估
3.7.1测试思路
将RCS的业务抽象成各种任务，这些任务的集合能够覆盖RCS的主要功能场景（超过90%）。测试人员在执行这些任务的过程中评估用户的体验效果。
3.7.2任务划分
测试任务划分如下，所有测试任务的其实页面均从登陆后的默认页面开始。
3.7.3评估指标
3.7.4 附件
【体验评估表】
用户体验评估表.xl
sx