案例常州移动互联网用户感知主动性测试七维十步法重点推荐.docx
《案例常州移动互联网用户感知主动性测试七维十步法重点推荐.docx》由会员分享，可在线阅读，更多相关《案例常州移动互联网用户感知主动性测试七维十步法重点推荐.docx（31页珍藏版）》请在冰豆网上搜索。
案例常州移动互联网用户感知主动性测试七维十步法重点推荐
移动互联网用户感知主动性测试七维十步法
摘要:
随着移动互联网业务和行业应用的日益丰富，用户感知问题成因复杂，由于无线接入不同于有线接入的某些特性，单单无线侧或IP侧都不能全面定位移动互联网用户感知问题，现网中很多的问题都是非信号类的感知问题，如何将IP包和无线信令相关联是打通端到端移动互联网用户感知分析的关键。
本创新基于大量用户感知投诉的案例，江苏公司融合IP和无线技能，深度挖掘Wireshark/Shark、QXDM等专业工具与专业网管能力，针对非信号类的感知问题，在业界首先提出用户感知测试十步法及移动互联网感知分析七维度，分析用户IP数据报文，精确匹配业务模型、终端类别，快速解决传统手段难以定位的业务层面感知问题。
该成果在江苏经过两年的规模使用，提升了自有APP、电信合作SP、行业用户、明星机型的运营能力。
直接挽回农行、二院、中天钢铁等大客户行业应用损失，可量化经济效益近两百万元；改善了电信自有产品爱游戏、翼支付的使用感知，提升了市场竞争力；并协助合作客户定位了乐视视频、华泰证券、苏宁易购产品的缺陷，产生了间接的经济效益。
关键词：
用户感知、移动互联网、QXDM、Shark、Wireshark
一、背景介绍
1.1移动互联网业务日益丰富，用户感知问题成因复杂
随着4G的发展，现在的移动互联网业务已经非常的丰富，除了手机侧的业务以外，物联网或者行业应用的发展已经非常普遍，涉及到了各个领域，各种各样用户的感知问题形成的原因非常复杂，终端、软件、无线网、核心网、SP等都有可能出问题。
图1移动互联网业务丰富
1.2无线接入有别于有线接入、单无线或IP侧都难以定位问题
有线接入网基本是点对点的业务，障碍很容易定位到具体的节点；但是无线接入是有别于有限接入的，中间涉及的网关和节点都非常的多，仅仅无线侧或仅仅IP侧都是非常难以定位最终的问题。
图2端到端网络结构
1.3针对非信号类的感知问题，MR、DPI、感知平台都束手无策
现网中用于分析感知问题使用到的MR、DPI、感知平台等大数据可以对一些感知问题进行定界和定位，可以定位部分无线侧和核心侧的问题引起感知差的原因，但是现网中还存在大量的手机侧软件问题、物联网的终端问题、SP平台问题等，这些通过传统的MR、DPI和感知平台数据都不能精确的定位到底是什么原因引起的感知差，网优人员更多的是能定位无线网或核心网的具体问题，对于终端、软件、SP等问题往往束手无策。
图3MR、DPI和感知平台定位不了具体终端和SP感知差的原因
1.4融合IP和无线技能，针对非信号类感知问题制定测试和分析方法
随着移动互联网业务和行业应用的日益丰富，用户感知问题成因复杂，定位困难。
江苏公司融合IP和无线技能，深度挖掘Wireshark/Shark、QXDM等专业工具与专业网管能力，针对非信号类的感知问题，在业界首先提出用户感知测试十步法及移动互联网感知分析七维度，精确匹配业务模型、终端类别，快速解决传统手段难以定位的感知问题。
二、主要特点介绍
该测试方法主要体现在以下三个方面：
2.1七维十步移动互联网业务感知主动测试和分析体系
利用主动测试十步法可完成所有终端侧和SP侧用户感知问题的测试，再从无线信令、心跳机制、话务模型、设备硬件、服务器、速率调度及程序等七个维度开展分析，建立了一套针对非信号类问题的七维十步移动互联网业务感知分析体系。
详细操作方法见附录
图4七维十步移动互联网业务感知分析体系
2.2专业软件实现终端信令和业务感知紧密结合
终端信令和业务感知紧密结合，配合使用高通QXDM软件、专业网管、Wireshark和Shark等专业软件实现终端信令及业务精细化测试，建立了终端协议规范性和业务评估的标准化测试流程，可实现信令跟踪、数据抓包和TCP/IP数据报文的精确分析。
图5专业且免费的测试软件
2.3省市联动的测试机制，保证了终端测试工作高效有序开展
针对问题终端发现的三类渠道（用户投诉、指标监控、入网前检测），建立了省市联动的测试机制，由省无线网优中心、常州无线维护中心、市场部、校园中心、终端公司组成一个测试、跟踪、反馈、改进的全流程闭环管理机制，保证了终端测试工作高效有序开展。
图6省市联动测试机制
三、详细技术方案
针对非信号类的用户感知测试和分析技术方案介绍：
用户感知测试方法和分析手段，主要分为以下10大步骤：
各软件的详细操作步骤见附录
图7用户感知测试测试和分析十步法
1）QXDM抓取手机侧信令：
QXDM可抓取手机侧详细的打印消息和无线信令，对比协议规范，确认手机侧信令和处理方式是否符合协议；
2）Shark抓取用户面数据包（手机侧）：
Shark可抓取手机侧用户行为数据报文，在Wireshark客户端分析手机侧上网行为；
3）网管跟踪基站侧信令：
专业网管跟踪网络侧详细信令，对比QXDM抓取的手机侧信令，可定位问题节点是网络还是手机；
4）网管抓取用户面数据包（基站侧）：
针对无法安装Shark软件的行业应用设备，可抓取网络侧设备行为数据报文，在Wireshark客户端分析行业应用上网行为；
5）心跳周期测试分析：
在Wireshark客户端上查找周期性报文（Echo，Ping等）确定心跳周期；
6）话务模型测试分析：
专业网管统计信令中单位时间内空口寻呼、建立和释放的次数；Wireshark客户端统计单位时间内的数据报文数量、字节数及速率；
7）设备硬件测试分析：
针对行业应用的设备硬件，Wireshark客户端分析感知异常情况下设备的上网行为，对比设备异常情况下的日志，定位设备是否存在硬件故障；
8）服务器测试分析：
针对电信自由产品，可开展端到端详细测试，在Wireshark客户端分析数据报文中服务器的窗口大小、线程调度，用于对比验证服务器端参数设置的合理性；
9）速率曲线测试分析：
针对大流量应用，Wireshark客户端中I/O图表可用于分析各个线程速率调度情况；
10）程序编写测试分析：
在Wireshark客户端进行TCP流的socket分析，可定位程序socket进程编写的合理性。
四、应用实例介绍
该技术在江苏经过两年时间不断研究、完善，成功解决各类感知问题，提升自有APP、电信合作SP、行业用户、明星机型的运营能力，支撑了市场发展。
江苏利用本技术成功解决了集团爱游戏、翼支付的感知差问题；支撑市场部完成合作客户乐视视频、华泰证券、苏宁易购产品的感知性能测试；解决了集团客户农业银行ATM吞卡问题、中天钢铁自助式发货终端联网失败问题、常州二院移动护士站程序缺陷问题；定位了翼网测速专家速率不准确原因、搜狐门户打开失败原因、三星S5与UIM卡不兼容原因。
4.1爱游戏APP感知差问题定位和改进
感知问题描述：
1）同等条件下，爱游戏均速25Mbps，远低于安卓市场的46Mbps；
2）爱游戏速率波动太大，安卓市场相对较稳定。
图8爱游戏使用感知明显差于安卓市场
感知问题定位：
DPI数据只能看到http的速率，无法再采集其内容源的下载速率。
图9爱游戏的Dpi只能采集网页的速率没有下载内容的速率
通过创新手段测试和分析以后定位爱游戏平台及程序存在3大缺陷：
1）分片机制不合理：
将200MB文件被切片为100个2M小文件，导致小包太多，效率低下；
2）ACK应答效率低：
爱游戏的ACK应答效率比安卓市场低2.8倍；
3）线程调度不合理：
爱游戏使用的双线程下载机制，因线程调度不合理，导致速率经常掉坑。
感知问题解决：
针对三大缺陷进行爱游戏版本升级改进，改进后速率从之前的25Mbps提升到50Mbps左右，提升近一倍。
1）改进分片机制：
将200M文件被切片为2个100M文件，提升速率30%；
2）改进ACK应答：
从每ACK应答1.76个包改进为应答3.4个包，提升速率20%；
3）改进线程调度：
双线程调度资源分配均衡，提升速率20%。
图10爱游戏三大缺陷改进
图11爱游戏改进前后速率对比
4.2翼支付APP感知差问题定位和改进
感知问题描述：
“甜橙理财”、“通信缴费”和“添益宝”在使用过程中返回，会经常性会提示“亲，你的网络不给力哟”或“连接超时请重试”等，这种提示即使在信号非常好的情况下也会出现，感知非常差。
感知问题定位：
主要原因是翼支付程序编写不合理。
图12翼支付程序编写不合理
感知问题解决：
翼支付四次挥手Socket中的Fin-Wait修改以后，感知问题得以彻底解决。
图13翼支付升级前后感知对比
4.3农业银行自助式ATM终端吞卡问题
感知问题描述：
农行自助式ATM终端是一款行业应用设备，经常出现吞卡问题，吞卡以后，ATM界面一直提示“正在处理中，请稍候”。
图14终端正常和异常是的截图
感知问题定位和改进：
使用Wireshark客户端分析感知异常情况下设备的上网行为，同时对比设备的日志信息定位原因为：
ATM终端检测不到读卡器模块，进而导致与农行主服务器信息匹配失败，产生吞卡行为。
国光公司对农行设备升级改进后感知问题得以解决。
图15农行设备原因定位和改进
4.4自助式发货终端经常联网失败问题
感知问题描述：
中天钢铁自助式发货终端是一款行业应用设备，经常出现联网失败的问题，必须要重启才能解决，用户感知很差。
感知问题定位和改进：
该感知问题从发现到解决先后经过两次分析和改进：
第一次分析：
设备无心跳机制，无法检测网络是否中断，导致断网时不能自动联网；
第二次分析：
设备增加了心跳机制，采用PingXX地址作心跳不合理，当XX服务器割接时，设备无法ping通，则误判为网络中断（实际无线网络正常），重新发起拨号，影响业务感知20秒钟。
最终的改进：
改进心跳机制，变PingXX地址为Ping自身服务器，彻底避免了设备的误判。
图16中天钢铁自助式发货终端的原因定位和改进
4.5常州二院移动护士站APP感知问题
感知问题描述：
常州二院移动护士站是一款基于手机的APP应用，主要存在两大感知问题：
1）子页面打开比较慢；2）手机耗电比较大。
感知问题定位：
耗电原因分析：
Wireshark分析业务报文发现存在两个心跳周期，1）APP程序侧采用Post作为心跳，周期10秒；2）VPDN服务器侧Keepalive采用Echo作为心跳，周期10秒。
这两个心跳导致手机处于长在线状态，心跳交互频繁，耗电严重；
页面打开慢分析：
TCP程序缺少完整的四次挥手，导致进程没有正常结束，在下次子页面打开时会重复上次TCP进程，导致子页面打开比较慢。
图17移动护士站耗电分析和页面打开慢分析
感知问题解决：
手机程序做了两方面修改：
程序Post心跳由10s改为300s；完善四次挥手Socket进程；
VPDN服务器修改Keepalive时间由10s改为700s。
修改完成以后二院感知问题得以彻底解决。
图18移动护士站程序修改和VPDN服务器Keepalive修改
4.6合作客户产品的感知性能对比分析
使用Wireshark客户端中的I/O图表用于分析视频的速率曲线，协助市场部分析合作客户的产品应用，对比同类互联网产品，提供合作客户其产品的优缺点，增加客户粘性及满意度。
2016年完成合作客户乐视、华泰证券、苏宁易购与同类互联网产品的感知对比分析。
4.6.1乐视视频、优酷、PPTV的感知对比
感知对比-点播：
乐视的机制要优于优酷，优点在于：
乐视视频下载周期合理（10秒钟），而优酷周期为60秒钟，乐视视频更能抵抗无线网络快衰落。
图19乐视点播与优酷点播业务感知对比
感知对比-直播：
相比较而言乐视的机制要劣于PPTV，缺点在于：
乐视视频直播采用TCP数据传输，直播有别于点播并不需要采用可靠性传输方式TCP，使用UDP效果更佳；乐视每个媒体段（ts）的持续时间为4s，对速率要求非常高，一旦4s内未传输完则会造成卡顿，实际测试中乐视确实卡顿次数要多于PPTV。
图20乐视直播与PPTV直播业务感知对比
4.6.2华泰证券、同花顺的感知对比
华泰证券手机炒股软件涨乐财富通与同花顺感知对比：
涨乐财富通的资讯浏览比同花顺感知差。
主要原因是涨乐财富通资讯浏览的Get请求都是串行的，而同花顺则是选择性的并行发起Get请求，所以涨乐财富通的效率要低于同花顺导致其资讯打开时延较长。
同等环境下，涨乐财富通资讯打开页面需要2s左右时间，感知明显差于同花顺的1s。
图21涨乐财付通与同花顺资讯页面打开时延对比
图22涨乐财富通串行和同花顺并行Get机制的对比
4.6.3苏宁易购、淘宝、京东的感知对比
苏宁易购与京东、淘宝的感知对比：
都是非常成熟的购物APP，原理和HTTP网页浏览类似。
感知对比测试，三款APP的感知相当，性能都非常优秀，苏宁易购与京东感知类似，时延上略优于淘宝。
图23苏宁易购、京东和淘宝的RTT时延对比
淘宝时延相对大的原因是：
存在很多RTT时延100ms以上的包（采用tcp.analysis.ack_rtt＞0.1过滤），主要由两个IP地址产生140.205.160.8和180.97.159.242，这两个服务器的整体性能可能比较差。
图24淘宝最大时延较长的原因
4.7测速专家速率测试不准问题定位
感知问题描述：
在理想环境下，测速专家无法测试出极限速率，而SpeedTest可以。
如下图所示，SpeedTest速率为106Mbps，而测速专家只有82Mbps。
图25speedtest和测速专家测速对比
感知问题分析：
测速专家无法测试出极限速率的原因是：
测速专家使用三线程下载，但三个线程的速率调度不均，相当于只有1线程起作用。
测速专家三线程下载原本是可以利用多线程饱和下载的优势来提升下载速率，但由于三各线程之间资源分配不均衡，使得其并不能发挥三线程的优势，反而因调度问题使得速率下降；而SpeedTest使用两线程下载，两个线程速率调度非常均衡。
图26speedtest和测速专家速率曲线和各个线程机制
4.8三星打开搜狐网页失败问题定位
感知问题描述：
部分三星手机（三星i889、三星i909）搜狐网页无法打开，提示“页面包含的服务器重定向太多”，严重影响了用户的使用感知。
图27三星手机打不开
感知问题分析：
三星手机多次重定向是由跳转到再跳转到，进入死循环跳转，三星浏览器有一保护措施，禁止过多跳转，所以有“数据连接性问题——页面包含的服务器重定向太多”提示。
图28和的PR
感知问题解决：
搜狐公司对完成正式注册，成为合法域名，重新检测已成为合法网站，使用感知问题得以解决。
图29和更新后的PR
4.9三星S5从4G下切3G后鉴权失败定位
感知问题描述：
三星S5等手机使用4G网络下切3G以后无法上网，需要重启才能解决，严重影响了用户感知。
感知问题分析和改进：
手机拨号时与网络进行LCP协商CHAP鉴权算法为MD5算法，网络返回时密钥是根据CAVE算法计算的，最终导致手机侧和网络侧计算的密钥不匹配导致鉴权失败，无法上网。
这种鉴权失败的原因是因为早期的UIM卡和三星S5等手机不太兼容引起的，后期的4GUIM卡不存在此类问题。
图30手机CHAP鉴权使用的算法与网络侧下发的算法不一致
五、经济效益评估
本技术近两年对客户行业应用及终端开展的测试分析不仅解决了客户的感知问题，还挽回了可量化经济损失约185万元，挽回损失详细计算如下：
1）常州二院移动护士站应用：
常州二院采购终端数量400部，每部价值1000元左右，办理的89套餐，每部手机每年通信费用约1068元。
两年下来合计总费用=400部*1000元/部+89元*12月*400部*2年=1254400元；
2）中天钢铁移动式发货终端：
中天钢铁采购终端数量180部（非电信提供），办理的89套餐，每部终端每年通信费用约1068元，两年下来合计总费用=180部*89元*12月*2年=384480元；
3）农行自助式发货终端：
常州农行采购终端数100部（非电信提供），办理的89套餐，每部终端每年通信费用约1068元，两年下来合计总费用=100部*89元*12月*2年=213600元。
本技术可解决电信自有产品的感知问题，提升电信产品的市场竞争力；也可协助市场部完成合作客户产品的测试，协助客户改进产品质量，增加电信市场份额，这些会带来间接的经济效益。
六、附录
6.1用户感知测试方法
6.1.1QXDM抓取手机侧信令
抓取手机侧信令的目的是为了分析手机的信令，进而了解手机侧的相关行为是否符合正常的协议规范。
高通芯片手机基本都可以连接QXDM进行测试，有些手机可以直接连，有些手机需要进入工程态，部分手机进入工程态密码如下：
高通芯片华为手机*#*#2846579#*#*，三星手机*#0808#，酷派手机*20121220#，海信手机*1973460#，OPPO手机*#801#，VIVO手机*#225#，努比亚*#7678#等等。
QXDM模板可以按照以下的勾选进行配置：
在【Options】菜单中à选择【LoggingConfig】à打开【LoggingViewConfiguration】窗口。
图32log抓取前信令选项设置
6.1.2Shark抓取用户面数据包（手机侧）
抓取手机侧用户面数据包的目的是为了通过这些数据包分析用户的使用行为。
通过用户的行为分析，可以发现部分感知差的原因。
Android手机需要root以后在手机侧安装一个shark软件，参数设置界面如下图；Iphone手机可以通过Wifi接入Android手机进行抓包。
图33手机侧shark抓包配置
6.1.3网管后台跟踪信令
网络侧的相关问题可以通过网管侧跟踪的信令进行分析，这时候需要跟踪后台信令，3G/4G都可以跟踪；在Airbridge后台网管上打开【用户接口跟踪】勾选所有的接口，输入IMSI和ESN进行跟踪。
图34后台跟踪信令
6.1.4网管抓取用户面数据（网络侧）
前面提到手机侧的用户面数据包抓取，分析用户感知问题有的时候需要端到端的数据，很多情况下我们获取不到用户侧的数据，这时可以通过后台网管来获取网络侧的用户面数据。
3G网管AN侧抓包的方法：
在命令栏输入“SETCAPPACKS”；
图35后台抓包
AN侧所跟踪的数据包在BAM的D:
\cdma2000\TRACE\SNAPPACKSPATH目录中。
图36AN侧所跟踪数据包的目录
4G网管如果基站S1口连接有交换机/路由器，可以在交换机或路由器上做端口镜像，然后通过镜像端口进行抓包，另外也可以使用主控板的端口镜像功能。
UMPT板有两个端口，一般只是用一个，另一个空闲，可以通过配置，将一个端口镜像到另一个端口进行抓包。
或者也可以请求核心网进行抓包，4GMML配置如下：
图374GMML配置镜像
源端口号：
被镜像的端口。
目的端口号：
可以连接PC进行抓包的端口。
方向：
需要选择双向。
时间：
端口镜像生效的时间长度。
使用一台PC用网线连接到目的端口，IP设置自动获取
6.2移动互联网业务感知分析体系
6.2.1无线信令
无线信令维度主要是根据QXDM抓取的手机侧信令及后台网管抓取的网络侧信令与协议进行对比，及时发现信令中不符合协议的地方，进而推动厂家改进。
下图的信令是海信E87手机在关机以后没有关机注册信令导致用户的提示音为无法接通，给用户的感知非常不好。
图38关机信令不符合协议规范
6.2.2心跳机制
心跳机制测试的目的是为了了解终端、网络、服务器等各个网元的心跳周期，心跳周期不能设置太短，也不能设置太长。
心跳周期过长：
则会占用大量空口，心跳周期过短：
则会产生大量信令交互，增加信令负荷，手机耗电也会增加；千万不能将心跳周期设置为长在线模式，这种模式会永久性占用空口不释放，使得基站无法承载更多的用户。
心跳周期具体多少可以根据前面提到的信令和用户面数据都可以分析出来。
现网的3G/4G的休眠态定时器一般在10s左右，如果将心跳周期设置为小于等于10s会使得这些应用变为长在线模式，会消耗大量的空口资源，不能在人员聚集区发展此类应用；如下图所示，心跳周期为10s，导致该应用一直占用空口，使得网络无法承载大量的用户。
图39心跳周期太短导致长在线
6.2.3话务模型
话务模型测试的目的是为了了解该应用对网络资源的消耗情况，以便于网络资源的调配。
特别是在业务发展初期一定要测试一下话务模型，避免对网络造成大面积冲击，反而影响了用户的使用感知。
话务模型主要分析速率需求、占用空口的时长、寻呼的频次等等。
这些都需要通过信令和数据包分析。
下图就是部分手机的系统休眠定时器和手机侧的休眠定时器，不同的手机不一定会遵循网络侧的设置，通过这些模型测试对于这些终端密集发行区域，比如校园区域，我们可以提前预估到对网络的冲击，进而做好资源调配，满足用户的使用感知。
图40不同手机不同的休眠定时器
6.2.4设备硬件
用户在使用电信产品的过程中，当感知出现问题时，用户第一感觉就是电信网络或产品问题，但通过我们日常处理的经验，很多用户感知问题是因其硬件问题导致，并非电信产品和网络的问题。
所以开展硬件测试也是为了快速定位故障节点。
硬件测试需要借助数据包或用户侧的一些log信息分析。
下图就是借助设备的打印日志发现硬件设备在调研自身的模块方面存在缺陷。
图41ATM的打印日志信息
6.2.5服务器
端到端分析的最后一个节点就是服务器，很多情况下我们是没法测试服务器的，主要是一些行业应用或电信自有的应用必须要开展服务器测试的一些测试。
服务器主要是测试一些配置、窗口大小、缓存等等。
下图是爱游戏的服务器窗口设置不合理导致的速率掉坑。
图42滑窗问题导致速率掉坑
6.2.6速率调度
这里的速率测试分析主要是通过Wireshark的IO速率曲线分析，针对的是一些大流量的应用程序或APP开展测试时使用，以观察程序对各个端口或各个线程之间的调用上是否存在缺陷。
附件是爱游戏的双线程速率调度不合理导致速率突降的问题。
图43双线程分布不均导致速率突降问题
6.2.7程序编写
很多的软件或APP应用程序的编写上存在缺陷，我们可以通过抓包测试发现其程序上存在的缺陷，进而推进改进。
下图是二院APP在登入护士站页面时，虽然输入的密码显示是“……”,但在实际数据交互过程中使用的是明文；这个存在安全隐患，账号密码等信息很容易被别人获取。
图44APP程序编写不当导致密码是明文
升级会员 