企业官网建设流程全解析

简介：鼎利5G测试分析指导书是一份面向网络优化工程师、5G测试人员及通信技术学习者的行业分析报告类文档。内容系统梳理鼎利测试软件在5G NR网络测试中的核心功能，包括数据回放、信令显示、RB调度/MCS/调制方式窗口、MCS占比分析，以及参数图形化染色、数据过滤、数据合并与分割、智能分析（天馈接反、参数距离、重叠覆盖）、KPI报表生成和Logmask设置等，覆盖从数据采集到分析输出的完整工作流。包体为单个docx文件，约9.07MB，按功能模块分为八章目录，便于按需查阅。文档结合实操场景说明各项功能的应用价值，例如通过MCS占比评估信道质量，用前后对比视图验证优化效果，快速截取异常log导出Excel或高通MDM格式数据、自定义Logmask提升分析效率等，可帮助读者快速掌握5G网络测试分析方法与鼎利工具操作要点。该资源已有510人学习，适合需要提升5G无线网络测试与分析实战能力的从业人员参考。

1. 鼎利5G测试分析指导书：一份网优工程师的现场作战手册

很多刚入行的网优工程师拿到《鼎利5G测试分析指导书.docx》时的第一反应是打开文档、照着步骤做。但真正到外场跑一次才会发现，5G测试分析的核心从来不是“点哪个按钮”，而是如何让采集到的数据可信、可复现、能定位问题。这份指导书解决的是从设备连接、模板配置、现场打点、数据回放到报告输出的完整链路问题，适合外场测试工程师、网优新人和需要统一团队操作口径的项目负责人。我按自己带测试项目的习惯，把这条链路拆成准备、执行、分析、避坑、报告五段讲，每一步都说明为什么这么做。

2. 测试前准备：设备连接、软件配置与SA模式模板导入

2.1 软件与License：前台采集端和后台分析端的分工

鼎利的5G测试软件在项目里通常拆成两个角色：前台采集端跑在笔记本上，负责连接测试终端、GPS和加密锁，测试过程中实时记录空口信令、测量报告和业务层速率；后台分析端负责回放LOG、统计指标、生成轨迹图和栅格图。两者的关系可以理解为“前台负责存原始证据，后台负责把证据翻译成报告”。

新装软件后第一件必须做的事，是检查License授权里是否包含了5G NR模块。翻车现场大多不是软件装不上，而是License只开了LTE的SA/NSA开关，等到建测试模板时5G选项灰选，只能在现场干等授权。常见做法是启动软件后打开“帮助→关于→授权模块”，确认列表里有NR/5G相关字样，再顺手更新一次设备驱动库。

提示：测试前一晚把笔记本、加密锁、测试终端、GPS、数据线全部插一遍，并留10分钟做“连接自检”。这个动作能省掉现场至少半小时的排障时间。

接口驱动也是这类软件的隐形门槛。便携机如果用的是USB3.0转千兆或雷电扩展坞，插上终端后经常出现串口无法枚举的现象。我一般会提醒同事：测试笔记本尽量用自带USB口，不经过扩展坞；如果终端识别不到，先换数据线而不是重启软件。数据线看着一样，充电线和带数据通路的线差别很大。

2.2 测试终端与SA/NSA模式：锁频设置必须先搞清楚制式

现在国内运营商的5G网络已经是SA独立组网为主，但存量NSA站点没有完全退网，测试前必须先和运营商确认目标区域主打哪个制式。SA模式下终端直接注册到NR小区，测试关注的是SSB相关测量量；NSA模式下终端走“LTE锚点+NR辅载波”双连接，分析重点会多出辅小区添加、释放和SCG失败一类事件。选错制式，锁频逻辑完全不同。

锁频操作在鼎利里一般位于“终端控制→频点/小区锁定”。需要填的参数有绝对频点（如n78的3500MHz对应频点号）、PCI、带宽和BWP编号。只锁频点不锁PCI时，终端可能占用同频点下的干扰小区，这时测试数据虽然“有信号”，但SINR很难看，容易误判成网络问题。正确做法是频点+PCI一起锁，锁定后通过软件发一次重新搜网指令，让终端完成一次完整的注册流程，确认目标小区频点后再开始跑测试。

SA与NSA两种模式的测试关注点差异，可以按下面这个表来定：

无论哪个模式，测试完第一段路后要立刻回放30秒到1分钟，确认“有轨迹、有小区、有测量量”，再继续往下测。这个检查动作我称之为“后悔药”，发现得越早，废掉的测试里程越短。

2.3 测试模板配置：频段、SSB频点与关键指标怎么勾

测试模板是指导书里最值得花时间研究的部分。常见做法是从软件自带的默认模板改起，而不是从零建。选择正确的NR频段后，按场景勾选指标。下行重点勾SS-RSRP、SS-SINR、SS-RSRQ，上行重点勾PHR、MCS、CQI、BLER，业务层勾上下行PDCP吞吐率、TCP层速率时延。这些指标决定回放时能看哪些曲线和统计项，勾少了补不回来，只能重新测试。

模板里还有一项容易被忽略：工程参数导入。把当前片区的工参表（小区名、PCI、频点、经纬度、方位角、挂高）导入软件，路测时前台地图上会实时显示服务小区和邻区位置。没有工参的话，回放分析只能看到PCI，连“这个弱覆盖是哪个站的哪个扇区”都说不清。导入后自查一遍工参里频点和PCI是否与现场一致，常有台账和现网对不上的情况。

模板里建议固定的关键参数与用途：

LOG文件大小也要提前想清楚。长时间DT测试不开“文件分段”的话，单个LOG可能跑到几个GB，后台回放时卡到鼠标飘。一般把分段时间设成60分钟或2GB自动切换，文件名里自动加序号，后面按段合并。

2.4 设备连接顺序与GPS定位：避免现场假异常的常见做法

设备连接顺序看似小事，其实是现场“假异常”的主要来源。我一般按这个顺序来：先插加密锁再启动软件，等软件完全起来后接GPS，确认搜星定位后再接测试终端。顺序反过来的话，软件可能枚举不到终端，需要拔插重来排查。

GPS要放到室外空旷位置，等待状态栏从“2D定位”变为“3D定位”。2D定位精度差，轨迹会漂到马路上甚至楼顶，后期栅格统计全乱。鼎利的很多统计默认不记录未定位采样点，如果GPS长时间丢星，会出现“前台明明看到数据在跳，回放就是没有轨迹”的诡异结果，其实数据都丢了。

测试笔记本的电源策略也要先改掉：接上电源适配器，关闭自动锁屏和休眠，盖子合上时选择“不采取任何操作”。外场测试动辄两三个小时，屏幕一黑、系统一睡，软件连着终端和GPS一起失联，再醒来时LOG里就是一段空白。这个细节写不进模板，但每次都能拦住一批新手。

到这里准备阶段结束，能确认的确认了，能预检的预检了。后面现场的执行才会顺。

3. 现场路测执行：DT线路规划、CQT定点打点与实时盯控

3.1 DT拉网测试的路线规划：网格覆盖与“一笔画”原则

DT（Drive Test）的目的不是“跑得多”，而是跑出代表性。拿到一个测试网格后，第一件事是在地图上把主干道、次干道和重点商圈全部标出来，然后设计一条尽量不重复的道路：从网格边缘进入，按主路绕行一圈，再切到内部次级道路，最后从另一个方向驶出。这样既能覆盖大多数路面，又避免同一条路反复占用测试时间。

路线规划时注意几个细节：一是避免大面积穿越隧道和高架桥下方，这些区域GPS和信号都不稳定，除非任务就是测隧道覆盖；二是在高架桥上跑时走上层和下层的结果差异巨大，如果测试对象是地面道路系统，尽量走辅路；三是每个网格的测试时长建议控制在2到3小时以内，超过这个时长司机和测试员的疲劳度会明显影响打点质量。

鼎利前台有路径规划功能，可以先把路线存成KML导入。导入后核对一遍路线上每个拐点是否落在实际道路上，避免因为GPS漂移把路线拉到楼群里。跑DT时，需要设置好“自动保存”和“分段记录”。遇到过测了两小时才想起没开分段的人不在少数，一次断电或软件崩溃，2小时的数据全废。分段粒度小一点，文件损坏时的损失也可控。

3.2 CQT定点测试动作规范：每点几轮、每轮几秒、怎么命名

CQT（Call Quality Test）定点测试通常用于验证问题点整改效果、投诉热点或重点场景。和DT的连续拉网不同，CQT要的是可复现的单点数据。每个点位的标准动作我是这样定的：接入时延测10次，取平均值和中位数；上下行速率各测3轮，每轮持续30秒，轮间休息10秒，避免连续满负荷导致终端过热；有语音业务需求时单独呼叫并记录MOS或丢包率；如果有CA或载波聚合场景，还要确认每一轮的CA组合是否相同。

文件命名看起来不起眼，但回访报告时作用很大。常见命名格式是“日期_片区_测试类型_终端制式_序号”，例如“20240520_市南网格3_DT_SA_01”。测CQT时在文件名里带上点位编号，比如“CQT_P01_P02”，这样导出的LOG不用逐个打开也能知道每个文件对应哪个点。

定点测试开始前有一个关键动作：确认终端已注册到目标小区的目标频点。在鼎利界面看“服务小区信息”，核对PCI和频点与工参一致后再开始业务测试。很多速率问题其实是从测到了邻小区开始，严格来说测试动作已经失效。

3.3 吞吐率上不去的现场判断：先定性空口还是业务侧

外场最常遇到的“玄学”问题是：下载速率不稳定，几次测试结果相差很大。新手习惯先把锅扣给无线侧，但更理性的做法是先定性瓶颈在哪一层。鼎利后台同时记录了“TCP/IP层速率”和“PDCP层速率”，这两个值的对比可以快速定位：

这一条在指导书里值得重点标注。现场如果看到TCP层速率低于PDCP层速率一大截，先别急着调天馈，让后台同事换一个服务器节点再测一次，往往就恢复了。反之，如果PDCP本身就低，再换多少个服务器都没用。

吞吐率测试还有一个容易被忽略的环节：确认测试使用的是哪条协议栈路径。SA模式下业务面走NR直接接入，数据从UPF经gNB到终端；和NSA相比，信令面更简单，但时延和速率受核心网侧影响更大。结合5G网络架构去理解测试数据，比只看曲线更能解释异常：无线侧指标漂亮但速率低，问题往往在承载配置或UPF链路。

3.4 实时盯控参数与事件标记：SINR突变时的现场留证习惯

测试过程中不能只顾看前方路面，还要盯软件界面。我习惯在界面固定三个实时参数：SS-SINR、当前服务小区RSRP、上行PHR。SINR连续下跌超过5dB且没有恢复迹象时，软件里打一个“事件标记”，同时用手机拍一张全景照，记录旁边有没有新工地围挡、高楼遮挡或临时施工。

这些现场证据在回放分析阶段价值很大。一个弱覆盖点，如果没有现场照片，回放时看到的就是“RSRP低、SINR差”，至于是遮挡还是天线角问题完全没有线索；有了全景照，可以直接对比工参里的方位角和挂高判断是覆盖阴影还是天线故障。

事件标记的备注栏要写“人话”。不要只打一个默认标记，备注里写清“高架下遮挡”“新楼盘在建”“道路施工围挡”。这些备注最后会直接进报告的问题点清单，优化同事看报告时能少打三个电话。切换失败、RRC重建、掉线这类异常事件出现时，除了软件自动记录，建议手动在备注里写清楚当时的车速和路面情况，同样有助于回放定位。

4. 数据回放与分析：信令定位、指标口径与TOP问题生成

4.1 信令回放顺序：RRC建立、切换与重建的三种场景

回放LOG是测试分析最花时间的环节，但也是最容易被工具“带偏”的环节。我的习惯是回放不止看曲线，还要按信令顺序确认流程是否正常。每天的数据回放从三个场景入手：

RRC建立场景：找到“RRCSetupRequest→RRCSetup→RRCSetupComplete”这一串信令，确认建立成功。如果只看到请求没有建立，多半是接入被拒或前导码冲突；如果SIM卡驻留异常会出现反复请求，先查终端状态再怀疑网络。

切换场景：SA下重点找基于SSB的切换准备与执行信令。切换失败会留下“HandoverPreparationFailure”或重建立流程，结合邻区测量报告能看到目标PCI是否有信号。测量报告里RSRP和SINR都够但切换失败，大概率是目标小区准入或参数问题，需要到网管侧核对切换参数。

重建场景：RRC重建信令出现时，往前翻5秒找触发原因。常见有RadioLinkFailure、HandoverFailure等原因值，结合当时的SINR曲线判断是覆盖空洞还是干扰。这条链路走完，一个弱覆盖区域的原因就能定个七八分。

信令分析的深度其实取决于对5G网络架构的理解。SA模式下鼎利能看到的是接入网和部分NG接口交互信令，完整的核心网上下文建立失败、UPF路径异常等事件，需要结合网管侧“UE Context Setup”消息一起看。现场排障时，如果空口指标正常但业务无法建立，基本可以判断问题在NG或UPF侧，直接提交核心网配合定位。

4.2 指标统计口径：差一点就完全不一样的计算规则

鼎利后台的统计功能很强大，但“统计口径”才是报告的生死线。同样一份LOG，两种口径能得出完全不同的结论，这也是测试报告经常被优化侧质疑的原因。以下几点在拿到统计数据后先确认：

覆盖率的口径。常见写法是“SS-RSRP > -110dBm且SS-SINR > -3dB的采样点占比”。如果后台默认只按RSRP滤、不提SINR，覆盖率会偏乐观。报告里必须写明分子样本和分母样本是怎么过滤的。

掉线率的口径。掉线次数除以“成功接入总次数”还是“总试呼次数”，结果可能差一个数量级。项目上通常按集团规范用后者，但不同软件版本默认值不同，导出前要看一眼统计模板的备注。

接入成功率的口径。“RRC建立成功率”和“业务接入成功率”不要混用，对应的信令事件完全不同。

回放时勾选统计区间也要注意：只选“有业务”的区间，还是包含空闲态全程，对下行平均RSRP的影响很大。我一般会把DT的统计区间固定为“全程+业务态”双版本输出，报告里默认用业务态，附录里附全程数据，这样经得起问。

4.3 轨迹图和栅格图分析：把弱覆盖片区落到工参和框号上

轨迹图适合看连续路段的信号起伏，栅格图适合对片区质量做整体判断。栅格的大小建议按50米×50米，太小统计样本不够，太大会把局部问题淹没。栅格图里出现成片的红色区域，先在图上把问题栅格筛出来，统计栅格内的平均RSRP、SINR和下行速率，再去匹配工参找最强小区。

把问题区域落到“哪个站的哪个小区”，有一个实用技巧：在鼎利里导出问题点附近的主服务小区和邻区列表，记录下PCI和频点，然后到华为5G网管上查对应框号和小区名。网管查询一般按“框号—槽位—小区”的层级组织，输入PCI反查后，结合天线方位角判断是越区覆盖还是朝向空洞。这一步是把测试数据“翻译”成优化动作的关键，也是很多参赛选手在5G组网与运维大赛里拿分的地方。

话虽如此，反查框号前先把工参表的准确性和现场拍照核对好。遇到过PCI反查出的地理位置和测试现场差了2公里的情况，原因是工参台账没有更新，最后靠现场照片才确认了实际覆盖小区。

4.4 事件列表与TOP问题清单：一份能直接抄送优化的表格

后台的“事件列表”功能会把整个LOG里的所有异常事件列成一张表，比如切换失败、重建、掉线、接入失败、SCG失败等。直接导出这张表是不够的，还需要做两步加工：

第一步是去重合并。同一路段同一小区连续多次失败，在表里可能是几十行，要按“时间+位置+服务小区”聚合成一个问题点，而不是把每个事件都当成独立问题。

第二步是给问题点排名。按“影响时长、影响范围、是否核心区域”三要素打分。核心商圈一个重建事件，严重性远高于郊区连续三个弱覆盖采样点，排名规则要在处理前定好，报告里的“TOP问题清单”才不会被质疑“凭什么这个排第一”。

输出的问题点清单建议固定包含：时间、经纬度、服务小区PCI、频点和工参小区名、事件类型、当时RSRP/SINR、现场备注。这个表格直接作为报告附件，优化侧拿到就能干活。

5. 鼎利5G测试常见问题避坑：GPS丢星、锁频失效与统计口径坑

鼎利软件本身在商用无线测试工具里算稳定，真正让测试数据报废的，往往是一些看起来不起眼的现场环境因素。下面五条是我在几个项目里反复遇到的坑，每一条都按现象、原因、解决来写，方便对号入座。

5.1 回放时LOG是空的：GPS未定位与记录配置的隐藏坑

现象：测试时前台界面上数据明明在跳动，后台回放时发现轨迹没有任何覆盖数据，事件列表也是空的，整个文件基本报废。

原因：优先级最高的原因是GPS全程或大部分时间没有定位，软件默认不记录没有有效定位的采样点。其次是模板里漏勾了“导出轨迹”选项，数据采集了但没落盘。

解决：开始测试前把GPS放到室外等待3D定位，并在软件状态栏确认“定位正常”；测完第一段路后暂停设备，回放已记录的1分钟确认轨迹和事件都在。这个动作我每次都会做，十几秒的成本能避免几小时的白跑。

5.2 锁频失效：终端占用了非目标频点的三种现场原因

现象：明明在鼎利里锁定了n78的某个频点和PCI，测试过程中终端却上报了n79小区的测量，RSRP和SINR都不符合预期，数据不可用。

原因：锁频指令只对终端当前接入层生效，如果终端在测试过程中发生了小区重选或切换，且锁定的PCI在邻区列表里不存在，终端会按系统信息里的邻区选择新小区。部分厂商终端对锁频指令的支持也不完整，锁定频点后仍响应系统侧的重定向。

解决：锁定采用“频点+PCI”组合而不是只锁频点；锁定后下一次“重新搜网”让终端重新注册；测试过程中实时盯服务小区信息栏，发现PCI和频点与目标不一致时重新锁一次，别等回放时才发现。

5.3 前台显示与后台统计不一致：口径差一档，报告全重算

现象：测试时前台实时看到某路段RSRP普遍在-100dBm左右，后台统计报告里却是-110dBm，被质疑测试数据错误。

原因：前台实时显示的是当前采样点的瞬时值和短时平均值，后台统计则是整个统计区间内所有采样点的平均值或区间计数。后者受瞬时深衰落影响大，如果统计区间包含了路边停车、红绿灯等待时段，结果差异会更明显。

解决：先确认后台统计的区间设置——按时间过滤还是按事件过滤；再确认RSRP的区间分段是否覆盖了-110以下的部分，没有覆盖的区间会被计入兜底值。统一口径后重新统计，报告里写明采样区间和过滤条件。

5.4 终端发热掉速：吞吐率“过山车”背后的温控降频

现象：同一路段两次吞吐率测试，第一次跑到满速，第二次直接腰斩，且速率曲线呈周期性起伏，RSRP和SINR曲线完全正常。

原因：测试终端连续满载发射导致SoC温度升高，触发了温控降频或发射功率回退。这是5G测试里最隐蔽的“黑匣子”，软件显示一切正常，硬件默默限了速。

解决：给终端加散热背夹，且背夹要紧贴机身背部金属区域；连续测试超过1小时强制停机休息10分钟；同一问题点重复验证时，先测一轮当基线再测一轮做对比，避免两次状态差异误导结论。

5.5 软件崩溃与断电：分段保存是唯一的后悔药

现象：测试进行到第90分钟，笔记本断电或软件闪退，重新打开后那90分钟的文件无法回放，或者回放时卡死。

原因：前台软件是在内存里实时组织LOG的，没有及时落盘。段文件没有自动切分时，一次异常退出就会把整段数据写坏。

解决：开启文件自动分段，按30分钟或500MB切分，文件名带序号；每测完一个网格，手动导出一次；如果测试中软件异常退出，先备份当前目录下的临时文件，再尝试恢复。分段保存不是万能的，但不分段一定是脆弱的。

这几类问题的共性规律是：多数翻车不是软件故障，而是设备状态、统计口径和现场环境叠加出来的。遇到诡异结果先按这个顺序自查，能省下大量找厂商工单的时间。

6. 报告输出与指标验证：先抽查单个事件，再信统计报表

6.1 报告骨架与指标汇总表的固定格式

报告是测试分析的最终交付物，格式稳定对项目沟通很重要。我常用的报告骨架分四层：测试概览（时间、地点、设备、软件版本、网络制式）、指标汇总表、问题点清单、栅格图和轨迹图。指标汇总表固定放三组数据：覆盖率、接入成功率、上下行平均速率，并标明统计口径和采样区间。这四层覆盖了优化侧判断“这次测试是否可信、哪里需要动”所需的全部信息。

6.2 每次出报告前强制做的事件抽查验证

出报告前花20分钟做事件抽查是我的固定习惯。从LOG里随机抽3个事件点，回放核对事件前后的RSRP、SINR曲线和速率，确认统计口径与报告数字一致；再从栅格图里抽一个红色区域，确认栅格内采样点数超过30个，避免一个两个异常点撑起一片“弱覆盖”。这两轮抽查做完才能导出最终报告。

早些年我做报告只信平均值，被老师傅点醒后才学会先看单个事件再信统计报表。从那以后这个抽查习惯保持到现在，也少交了很多“报告被质疑后重跑数据”的学费。测试分析的每一张图、每一个数字都应该经得起回放验证，这才是一份指导书想让人真正带走的东西。希望帮到你。

本文还有配套的精品资源，点击获取