一
深度测试模式
所谓深度测试是通过深入现场调研，收集各类数据信息，深度挖掘网管在现场实际使用情况，从而持续改进测试场景设计、开发测试辅助工具等的测试活动，目的是尽早发现潜在故障，提高测试质量，避免外部故障泄露。
主要的分析方法有UX模型分析，操作模型分析，数据模型分析等，在通过这些分析得出结论基础上进行测试场景设计及相关的测试工具开发等开发活动。
深度测试模式关键步骤图如下：
二
深度测试思路
挑选典型的网管商用局点，到现场进行调研和信息收集，基本是按照用户模型->操作模型->数据模型三个层次进行分析，然后从改进测试用例设计、进行测试工具开发等方面着手解决，从而提高测试的有效性，这样来逐次开展：
a) UX模型分析
挑选典型局点在现场实际调研，对网管日常运维使用人员的关键角色画像，建立实例化的用户所处场景。
b) 操作模型分析
通过收集现场操作日志、网管定时任务信息等进行分析，把用户关键操作的时间点、操作规模、并发规模、及网管定时操作等情况分析清楚，以此作为测试环境模拟现场操作的依据。
c) 数据模型分析
通过利用gc tool、nmon等开放的系统资源监控分析工具，或自主开发更适合网管的采集和分析工具umd，收集现场环境软硬件信息，网管关键进程日志，系统资源监控nmon日志，gc日志等，从而指导测试环境能够模拟现场背景数据压力。
d) 测试场景设计
依据各类分析结果，检查现有测试用例的执行情况和有效性，应用MFQ等需求实例化的测试分析方法，重新设计贴近实际使用场景的测试用例。对一些重复操作，并发操作等测试用例，通过自动化用例开发，提高用例执行度。
e) 工具分析
对现有工具完备性进行分析，为达到辅助测试的目的，开发或改进相关测试工具，模拟器工具、系统资源监控分析工具等。
三
实施概述
第一步先到典型商用局进行现场调研，了解现场数据与公司内差异，并了解现场用户的操作模式与使用场景与公司内模拟环境差异。
第二步根据现场调研的结果进行分析和研究，挖掘出关键差异并识别出需要增加的工具、用例和方法等具体的改进行动计划。
第三步则是落实上述行动计划，落实入版本或其他到实际交付阶段。最终是在实施后选择商用局评估结果，看看模式与方法是否可以推广。
实践案例：
某城市现场出现问题比较集中，并且网络规模比较大是重点局，因此选择该城市进行客户交流和初步分析。
四
UX模型分析
UX是一种“以客户为中心”的研究方法，它关注用户的工作场景及流程，并了解用户对工具的心理期望和主观感受。整个理论方法包含角色建模、用户体验地图、线框图、原型及验收五个步骤。如下图：
实践方法：
（）考虑到实际能够深入到现场交流的测试人员主要是出差人员，后续可以作为一个出差任务来实施，但可选不强制，有些紧急支持的出差未必有时间交流。这种方式主要面向外部用户，一对一的沟通，可以考虑设计用户体验调查问卷来进行信息收集。主要包括用户使用网管的工作职责，工作流程，工作时间，常用操作，支撑工具，使用痛点，关注内容等方面。
（）定期组织用户体验交流会，这种方式主要面向内部用户，可以邀请本地用服和网优人员等参加交流会议，根据需要设定一个主题，进行多对多的沟通。
、用户建模背景
网管系统的性能管理功能的使用者有多种类型，简单划分就是运营商用户/外包/设备商售后团队这三大类。运营商与之相关的是的网优/运维/监控团队，国内的运营商组织之下实际操作的往往是一些外包团队，部分欧洲运营商亦然，也有国外运营商是自己的团队直接来操作。而在国内真正对/无线网络性能的监控、调优，最可靠和强大的一只力量是我们公司营销事业部的网优团队。
实践案例：
根据该城市现场调研所收集使用者情况分析归纳出相关角色，举例如下：
、关键角色画像
不同领域测试的侧重点不同，实际的使用者角色也略有差别。根据收集到的用户数据，可以对最关心的关键角色进行更详细的角色画像，即输出Persona。
实践案例：
经常使用网管性能模块功能的关键角色--网优工程师Persona，如下：
、用户场景分析
收集到的用户工作职责和工作流程等方面信息，对应用户工作场景进行分析，建立用户体验流地图，即输出User Experience Journey Map。
实践案例：
网络性能监控并和日常网络优化的用户场景较为简单，整个处理流程涉及到运维监控工程师、网优人员、数据组等几种角色。日常网优用户体验地图大致如下图所示：
（）网优工程师、运营商网优、运营商运维监控人员通过网管性能查询或故障上报或投诉发现网络性能问题的出现。
（）问题出现后基本是交给网优人员处理。
（）网优人员，进行问题定位：
a）首先是从时间和空间维度逐层细化，精确定位到出问题的性能对象和时间段。
b）再分析配置数据、操作日志、版本信息，以来定位问题是由于配置数据导致的还是版本升级导致。
（）根据问题定位结果，确定解决措施。
a）常规情况是通过修改配置数据解决。
b）版本问题则需要回退版本或再要求研发提供补丁。这种情况就需要升级到寻求研发支持了。
（）网优人员自行修改配置参数或通知数据组修改配置参数，形成新的数据文件。然后在系统中激活生效。
（）通过性能查询监控或告警查询来网络性能问题是否已解决。
a）如已解决则结束。
b）未解决则需要升级，寻求研发支持。
五
操作模型分析
、 操作模型综述
要获取现场比较完整的操作日志，需要根据实际情况，如果有网管客户端的系统管理员用户权限则可以通过网管的操作日志功能导出记录，如果不具备权限则需要从数据库中查询操作日志表并导出记录。对收集到的操作日志进行分类汇总分析，比如最频繁的操作，最集中的操作时间，操作并发度等方面。
实践方法：
为了获取更为完整的操作数据以备分析，建议分阶段定期对现场的网管上下级的操作日志数据表、系统日志数据表进行备份，然后恢复到测试环境中，根据需要进行各种不同侧重点的分析。制定适合的采集策略，比如日志保存时间为个月的话，开局阶段个月后采集一次日志数据，之后可以定期每隔个月采集一次。升级阶段，则在升级前采集一次，升级后采集一次，后续也可以定期采集。
实践案例：
下面以该城市现场为例进行操作日志分析实践，主要是以天为单位采集日志数据，进行人工分析，后续采集数据量大时建议使用工具分析。如果没有适合的工具，可以在工具开发阶段根据需要自行组织开发。
、现场操作日志采集和分析实践
抽取月、月中各天，对该城市现场的网管操作日志进行采集并进行统计分析，以性能数据查询操作为例来分析。年月日网管全天操作日志统计记录共条，其中性能数据查询如下：
、现场交流常用操作分析实践
通过操作日志统计可以看出现场常用的操作和发生时间，频率等，而通过与现场网优运维人员交流可以了解他们的工作流程，更清楚执行这些操作的原因。
网优维护人员主要关心一些关键性能指标的数据，因此会自定义较多性能指标，常用的是小区测量对象的小时或天粒度查询，时间范围为一天，有时会查一个月。设置一些定时模板任务来每天定时获取全网数据，一般是凌晨执行，每天上班先看一下这些报表数据，可以及时发现异常数据；工作时间最常操作的是历史性能数据查询，为方便快速执行查询，会将查询条件保存为查询模板，每天都会使用查询模板来执行历史性能数据查询，故现场自定义查询模板创建的较多；需要使用历史性能数据查询的人员较多，正常上班的操作高峰时间同时在执行查询的估计在人左右；当维护人员从查询结果中发现异常指标时，会使用性能实时监控来即时获取当前数据，故每天都会执行该操作，有时也会使用下级的信令跟踪功能来观察；对于存在异常的数据处理，会根据具体问题自行修改配置参数或反馈研发解决，主要使用网管客户端修改，现场有修改全网数据的需求，后续值得测试关注，并加强测试。
、操作模型分析实践总结
综上所述，由于测试环境是测试任务和测试用例驱动的模式，需要执行相关操作时才会有比较多的操作，而现场工作人员每天都要关注环境上的各类数据，故每天会重复执行大量类似的操作，模拟现场这种重复的操作压力，在测试环境中可以考虑通过创建定时任务和自动化工具来实现，另外还要重点测试可以一次执行大批量的相关操作，并增加批量操作的测试用例。
六
数据模型分析
数据模型分析在这里主要是对现场环境数据的收集和分析，目的是辅助测试场景还原搭建有关的数据，包括但不限于收集现场组网拓扑结构信息、网管安装规模、现网配置数据及规模、网络传输方式、上下级是否共机、是否使用双机软件、是否与其他非网管产品共机部署，各类服务器软硬件环境信息等。另外为进一步定位和分析具体问题，可以收集网管关键进程日志，数据库运行日志，系统资源监控工具nmon日志，网管进程gc日志等进行分析。
实践方法 ：
、现场服务器软硬件环境信息可以通过联系当地用服人员，从工程数据资料中获取，如果在现场也可以直接访问环境查看来收集。
、目前可以推荐使用的数据采集工具是网管平台开发的一个维测工具umd。用于监控和采集服务器、网管进程、数据库运行信息。除了提供日志信息定时采集、一键采集工具外，还提供了人机命令接口、巡检工具，自监控功能。该工具的功能直接与操作系统和数据库相关，该工具可以支持主流的操作系统及数据库。
此外也通过oracle，sybase数据库自带的日志功能采集数据库运行日志。
、对于网管进程日志的分析，现阶段测试部门已组织人员正在开发基于Hadoop的网管日志分析工具，开发完成的功能包括针对性能数据上报流程中的日志关键字统计分析，操作系统和数据库信息收集，操作日志分析等。后续仍持续收集需求，开发实现其他功能。
、对系统资源监控，推荐使用nmon工具。在现场服务器环境部署，定时每天输出日志，收集日志并进行分析，主要可以分析CPU，内存，IO等情况。
、jvm配置文件和gc日志是网管自带的，gc从网管各个进程启动开始直到进程停止生成一个该进程的gc日志文件，可以定期获取。推荐使用IBM的gc tool等工具，观察一段时间内的gc曲线是否正常，比较jvm配置、硬件配置等与测试环境的差异。
实践案例：
该城市现场北向性能延迟上报的问题，从代码方面定位未能发现故障，而通过观察gc日志的曲线发现了异常，进而调整jvm配置参数解决了该问题。gc异常曲线如下图：
七
测试场景设计
依据上述各类分析结果，检查现有测试环境及测试用例的执行情况和有效性，找出差异，应用需求实例化和MFQ测试设计等方法，重新设计贴近实际使用场景的测试用例。对频繁重复操作或高度并发类操作开发自动化用例并上线执行，提高测试效率，形成有效防护。
实践方法 ：
、各领域开发和测试团队，无论是进行深度测试还是日常研发测试，都应该使用需求实例化和MFQ方法，进行场景类测试设计。对应已有的特性用例进行重新梳理，设计符合该特性场景的用例和开发自动化用例。
、测试部门或测试cop定期举行场景类测试MFQ实践活动，提升测试设计技能水平。
实践案例：
通过上述各类分析结果，对现有测试用例进行改进，比如通过对该城市现场网管使用情况分析后得出对现有用例进行补充的内容，举例如下：
特性场景类测试用例设计：
根据分析结果，采用需求实例化和MFQ测试设计方法对场景测试用例进行重新设计。输出MFQ思维导图和测试用例。
八
测试工具开发
有些测试数据模拟或大量数据分析等工作需要借助各类测试工具，根据测试场景用例的需要，对现有测试工具或工具功能的完备性进行分析，全新开发或改进相关测试工具，包括但不限于各类前台模拟器工具、系统资源监控分析工具、日志采集分析工具等，以达到辅助测试的目的。
实践方法：
、各类前台模拟器工具比较多，但来源分散，各有优缺点，可以考虑合并成一个功能相对比较全面，既能融合各个模块功能又能各产品通用的模拟器。要达到这个目标，单一测试团队实现起来比较困难，需要各领域合作。目前网管开发的网元模拟器相对来说是功能比全面的，融合了各个模块数据模拟需求的测试工具，后续可以根据测试需要持续优化。
、测试部门或测试cop，可以从各自的测试需求出发，全新设计并开发适合的测试分析工具。比如对网管进程日志的分析，基于Hadoop的网管日志分析工具已完成开发，可以辅助研发人员进行分析。
实践案例：
针对该城市现场频发的性能相关功能问题的测试，分析现有模拟器工具的优缺点，以便工具研发人员后续可以改进，分析举例如下：基站模拟器上报的性能数据比较简单，数据上报分两种方式：随机数或固定数值，虽然能保证数据上报类型与真实基站一致，但数值不能满足真实前台数据的约束，例如数据会出现大于%的情况等问题。需要改进模拟器上报数值的范围符合约束。
