聊5G网络切片的时候很多软件测试同学的第一反应是——这不就是网络工程师的事吗我一开始也这么想直到真把“5G网络切片性能基准测试”这个任务接到手里才发现它本质上是个彻头彻尾的测试问题设计用例、搭环境、定基线、跑流量、采集指标、定位瓶颈、出报告。这跟我们测一个Web服务、一个App后台流程上并没有本质区别区别只在于被测对象换了换成了一个横跨终端、空口、核心网、数据网络的端到端链路。这篇文章就是把我自己在5G网络切片性能基准测试上的完整实践过程从认知、指标、环境、用例设计到问题排查一条线写清楚。适合两类人一类是刚接触5G核心网/切片测试的软件测试工程师另一类是已经在做通信测试、但想系统梳理切片性能基准测试方法论的同行。看完你至少能回答三件事切片测试到底测什么、怎么搭一个能跑的真实环境、拿到数据之后怎么分析出有效结论。1. 5G网络切片不是“5G网络”测试视角的认知重构1.1 网络切片的本质一张物理网络上切出多个逻辑网络网络切片这个词听起来很高大上但用大白话解释就一句话把一张物理5G网络按需切成多个逻辑上互相隔离的“虚拟网络”。每个虚拟网络有自己独立的资源配额、独立的QoS策略、独立的业务逻辑甚至独立的管理视图。打个比方一条高速公路上有公交专用道、货车车道、私家车道所有车都跑在同一条物理路面上但每条车道的通行规则、限速标准、优先级别完全不一样。公交车道要让公交车优先通过货车车道要承受更高的载重。网络切片干的事情就是类似的事同一个基站、同一个核心网通过资源划分和调度策略同时服务“低延迟的自动驾驶业务”“大带宽的高清视频业务”“海量连接的水表电表业务”且互不干扰。在3GPP的标准定义里一个网络切片是用S-NSSAISingle Network Slice Selection Assistance Information单一网络切片选择辅助信息来唯一标识的。S-NSSAI由两部分组成SSTSlice/Service Type切片/服务类型8位和可选的SDSlice Differentiator切片区分符24位。SST有标准化取值比如1代表eMBB增强移动宽带、2代表URLLC超可靠低延迟通信、3代表MIoT大规模物联网、4代表V2X车联网。SD则是给运营商自定义扩展用的。从端到端的角度看切片不只是核心网的概念它贯穿了UE终端、RAN无线接入网、核心网5GC三个层面。UE要告诉网络“我要接入哪个切片”RAN要把无线资源按照切片策略调度核心网的AMF接入和移动性管理功能、SMF会话管理功能、UPF用户面功能要完成切片的选择、策略控制和数据转发。任何一个环节对切片的认知不一致这个切片就用不起来。1.2 为什么软件测试从业者要关注切片性能基准测试传统通信测试测的对象是单台设备测试基站、测试核心网网元的信令、测试接口协议。但软件测试从业者关注的视角不一样我们关注的是“业务体验”和“系统性能”之间的映射关系。切片这个东西恰好把两者绑在了一起一个视频业务的时延卡顿可能不是视频服务器的问题而是切片资源调度策略的问题一个物联网设备的连接失败可能是切片接入限制策略的问题。软件测试的核心能力是设计场景、构造输入、验证输出、分析偏差。这在切片性能测试里完全适用甚至比传统网络测试更需要这种能力。因为切片是逻辑概念你没法拿一把钳子去物理隔离它你能做的是通过配置和策略让不同业务流走不同的路径然后验证切片的隔离性、资源保障能力和SLA满足情况。所以我个人的看法是5G切片性能基准测试不是一个“通信专属测试”而是一个“分布式系统性能测试”在5G场景下的具体落地。软件测试从业者完全有能力把它做好前提是补齐通信协议和切片架构的底层认知。这篇文章的剩余部分就是把这块认知补齐并且把可直接执行的测试方法论给你。2. 切片性能基准测试的核心指标体系设计2.1 延迟eMBB切片和URLLC切片的差异到底有多大性能基准测试第一步永远是定义指标。5G切片测试里最核心的指标组是延迟Latency、吞吐量Throughput、可靠性Reliability、可用性Availability和连接密度Connection Density。延迟指标要分场景看。eMBB切片面向的是视频、AR/VR等大带宽业务对延迟要求相对宽松3GPP定义的eMBB用户面延迟目标是10ms量级URLLC切片面向工业控制、远程医疗、自动驾驶用户面延迟目标在1ms量级无线侧。这个差距在真实测试环境里会直接表现为两个切片的RTT往返时延数据完全不同。测延迟不能只测平均值我一般会同时采集三类数据平均RTT反映切片典型的响应水平用于和其它切片横向对比p95/p99延迟反映最差情况下的延迟表现业务SLA服务等级协议通常按这个值来考核延迟抖动Jitter反映延迟的稳定性对语音和实时视频业务影响很大。2.2 吞吐量从单用户峰值到多用户饱和吞吐量是切片性能测试里最容易测、也最容易测错的指标。首先是方向要分下行DL网络到终端和上行UL终端到网络。其次是模型要分三种单用户峰值吞吐验证切片内的单条流最多能跑多快这个值受限于空口调制编码方式、核心网转发能力和UE模拟器能力多用户饱和吞吐验证切片在承受大量并发终端时总吞吐量能到多少这个值能反映切片资源的聚合调度能力长时间稳定吞吐验证切片在持续高压下是否会出现吞吐回落这个值通常暴露内存泄漏、CPU过热降频、定时器超时等问题。吞吐量的两个关键测试参数是流量方向和持续时间。下行打流要关注TCP窗口或UDP包大小上行打流要关注UE侧的带宽占用。持续时间我建议至少120秒前30秒做预热中间60秒取稳定数据后30秒观察回落情况。只跑30秒就得出结论很容易漏掉系统在长时间运行后的性能劣化问题。2.3 可靠性、可用性和连接密度容易被忽略的另外三个指标可靠性在切片测试里通常用“一定时延预算内的成功传输概率”来定义。举个例子URLLC切片要求99.99%的包在1ms内完成传输那测试就要统计发送100万个数据包有多少个包在1ms内到达是否达到99.99%。这比单纯的丢包率更能反映切片对关键业务的保障能力。可用性则是指切片的“服务能力”常用来衡量网络不可用的频率和持续时间。在软件测试里我习惯把它拆成几个可操作的指标PDU会话建立成功率终端请求建立数据会话时核心网回复成功的比例PDU会话建立时延从发起请求到会话建立完成的时间会话保持率在高负载或切片资源紧张时已建立的会话被异常释放的比例。连接密度是eMBB和mMTC切片对比的核心指标反映单个切片实例能同时支持的终端数。这里的“同时支持”不一定是所有终端同时跑满带宽而是所有终端都能保持注册和会话状态能周期性收发数据。云管平台连接数、核心网用户面资源、RAN侧的资源调度粒度都会影响这个指标。2.4 切片间隔离指标测切片性能绕不开的交叉场景刚才说的几个指标都是切片的“单测”指标但切片还有一个特性是“隔离性”——多个切片共享同一个物理网络一个切片的高负载是否会影响另一个切片的性能这是切片与传统专网最大的区别点也是测试里最容易忽视的部分。隔离性测试的基本方法是在切片B上维持稳定的基准流量同时在切片A上施加突发高压流量观察切片B的延迟、吞吐、丢包是否有明显劣化。如果切片B的p99延迟从10ms涨到50ms说明两个切片的资源隔离策略没有生效存在相互抢占。这类问题在规划阶段很难发现只有通过实测才能暴露所以做切片性能基准测试时这个用例一定要加进去。3. 测试环境搭建低成本复现一套带切片的5G网络3.1 选型UERANSIM加free5GC的组合方式5G切片性能测试环境如果全用商用设备和真实终端成本高、交付周期长而且对软件测试从业者来说并不必要。更现实的选择是用开源模拟器搭建一个端到端的测试环境。我常用的组合是UERANSIM开源5G UE和gNB基站模拟器能模拟UE的注册、PDU会话建立流程也能模拟gNB与核心网的NGAPNG应用协议接口通信free5GC开源5G核心网项目实现了AMF、SMF、UPF、NSSF、AUSF、UDM等核心网网元支持3GPP R15/R16/R17的协议流程iPerf3流量发生器用于在终端和服务器之间产生TCP/UDP流量tcpdump加Wireshark抓包和分析工具用于排查协议层问题和性能瓶颈。这套方案的优势是什么成本几乎为零所有组件开源流程可控每个信令步骤都能抓包看细节性能数据真实可测因为用户面数据确实经过了完整的核心网转发链路。缺点是它跑在通用服务器上性能和商用设备有差距但做“性能基准测试”完全够用尤其是用来做相对比较、回归验证、SLA达标判断。3.2 部署细节切片的正确配置方法第一步先部署核心网。free5GC推荐用Docker Compose方式部署在YAML里定义好AMF、SMF、UPF、NSSF等服务。部署完成之后最关键的一步是配置切片。在free5GC的amfcfg.yaml中需要配置网络支持的切片列表plmnSupportList: - plmnId: mcc: 208 mnc: 93 sliceSupportList: - snssai: sst: 1 sd: 0x010001 - snssai: sst: 2 sd: 0x020001这段配置的意思是该网络支持两个切片一个用SST1标识适合eMBB业务SD为0x010001另一个用SST2标识适合URLLC业务SD为0x020001。第二步是配置UERANSIM的基站侧。在UERANSIM的gnb.yaml中要把切片信息告诉gNB让gNB知道哪些切片可用amfConfigs: - address: 127.0.0.1 port: 38412 sliceSupportList: - sst: 1 sd: 0x010001 - sst: 2 sd: 0x020001第三步是配置终端侧。在UERANSIM的ue.yaml中UE要告诉网络“我想接入哪个切片”supi: imsi-208930000000001 defaultSlice: sst: 1 sd: 0x010001这里有个经验之谈核心网、gNB、UE三侧的SST和SD必须完全一一对应任何一个不一致注册请求就会被拒绝。很多初学的朋友遇到“注册失败”第一反应是查代码其实90%的情况是切片配置不一致。3.3 验证切片注册成功从信令角度确认环境可用配置完成之后环境是否可用不能只看进程是否启动要看真实的注册流程是否走通。启动UERANSIM的gNB和UE之后UE会发注册请求给gNBgNB通过NGAP封装转发给AMFAMF与AUSF、UDM做鉴权通过后AMF返回注册接受。验证方法有两种。第一种是看UERANSIM的控制台输出如果注册成功会显示状态为CONNECTED。第二种更可靠在核心网一侧用tcpdump抓包tcpdump -i any -s 0 -w /tmp/ngap.pcap port 38412然后用Wireshark打开过滤NGAP协议。重点关注两条消息InitialUEMessage和DownlinkNASTransport。如果能看到这两条消息的顺序出现说明UE的注册请求已经成功到达AMF这是整个环境“通”的最直接证据。4. 切片级性能基准测试的设计与执行4.1 端到端测试链路从UE到应用服务器的完整路径切片性能测试不是直接对着核心网网元打压力而是走完整的端到端路径。一条典型的测试数据路径是UEUERANSIM模拟 → gNBUERANSIM模拟 → NG-U隧道 → UPF → 应用服务器 → 回程控制面路径则是UE → gNB → NGAP接口 → AMF → SMF → UPF理解这条路径对测试设计至关重要因为性能基线的位置不同指标的含义也不同。比如你在应用服务器上用iperf3测试收到的吞吐量它反映的是UE到服务器整条链路的吞吐如果你在UPF上用tcpdump抓包分析GTP-U隧道的流量速率它反映的是核心网用户面的转发能力。两个数据之间的差值就是RAN侧模拟器消耗的部分。测出来的端到端值才是切片用户的真实体验。4.2 测试方案设计从单用户基线到多用户并发全覆盖切片性能基准测试建议按照“从简到繁、逐层加压”的思路设计用例第一层单用户基线测试。一个UE接入指定切片在该切片下跑单流TCP/UDP获取延迟和吞吐量的基础值。这一层的作用是验证“切片最少能保障多少性能”是所有后续测试的参照系。第二层多用户并发测试。逐步增加UE数量比如10、50、100、200个UE同时接入同一切片同时发起流量观察总吞吐量和单用户平均吞吐量的变化趋势。这一层能暴露核心网的资源瓶颈和调度策略问题。第三层切片隔离测试。切片A和切片B同时承载流量对切片A施压监测切片B的性能指标是否稳定。第四层异常场景测试。模拟UPF重启、AMF重启、传输接口拥塞等情况观察切片内的业务恢复时间和服务降级情况。4.3 执行时的参数设置和采样策略执行多UE并发测试时有一些参数需要根据环境实际情况计算。比如你的测试机器CPU是16核UERANSIM每个UE模拟会占用一定CPU如果你一次性开到200个UE很可能先把控制面压垮和切片本身无关。我建议UE数量的增长梯度为5、10、20、50、100每级至少跑满60秒观察稳定后再加。流量参数方面iperf3的典型用法是iperf3 -c 192.168.1.100 -u -b 30M -t 120 -i 5这条命令的含义是向192.168.1.100发送UDP流目标带宽30M持续120秒每5秒输出一次中间结果。UDP流比TCP流更贴近切片性能测试的需求因为TCP的拥塞控制会掩盖底层链路的实际性能而UDP打流能直接反映链路的真实带宽和丢包情况。采样策略上我强烈建议不要只记录iperf3最后一次汇总值要把每隔5秒的中间数据全部保存下来。因为在长时间测试中系统往往不是匀速工作的中间会出现周期性的性能抖动这些数据是定位问题的重要证据。5. 实战中的常见问题与排查技巧5.1 切片接入失败S-NSSAI配置不一致第一坑我遇到最多的一个问题是UE发起注册核心网回复REGISTRATION REJECT。排查思路按优先级来第一步查看AMF日志。free5GC的AMF在收到注册请求后会检查该UE的订阅数据中是否包含请求的S-NSSAI。如果UDM中的订阅数据没配置这个切片AMF会直接拒绝。第二步检查核心网的切片配置。确认amfcfg.yaml中的sliceSupportList是否包含UE请求的SST和SD。第三步客户端抓包确认。在UE侧抓NAS消息看REJECT原因值。不同的原因值能直接定位问题原因值是“PLMN not allowed”通常是PLMN配置不一致原因值是“Slice not supported”则基本可以确定是S-NSSAI的问题。一个比较容易忽略的细节是SD在协议中是24位但配置时通常用4字节的十六进制表示比如0x010001。如果配置成了0x10001——少了一个零表面看起来“差不多”实际上两个切片完全不同。这是我踩过的坑写出来提醒大家。5.2 吞吐量远低于预期从用户面路径逐段排查假设配置完成了单用户下行吞吐量只有50M预期是200M怎么排查我的经验是一条路径逐段查第一段查gNB和UPF之间的GTP-U隧道。在UPF侧抓包统计NG-U接口的速率。如果UPF收到的速率已经很低说明问题出在RAN模拟器或传输接口如果UPF收到的速率高但应用服务器收到的速率低说明问题出在UPF到服务器的转发路径。第二段查UPF的转发性能。free5GC的UPF是基于DPDK或AF_XDP的转发模式性能受限于CPU核的数量和网卡驱动。可以用perf工具看一下UPF进程的CPU占用如果CPU已经跑满那就是性能瓶颈需要给UPF绑定更多CPU核或优化网卡队列配置。第三段查模拟终端侧的CPU限制。UERANSIM的UE下行接收需要消耗CPU来解封装PDCP层的数据如果UE进程单核跑满吞吐量上限就锁死了。这种情况可以给UERANSIM分配更多线程或者用多台机器分担UE模拟的压力。还有一个小细节iperf3需要在应用服务器侧使用正确版本的UDP模式。用iperf3测UDP时应用服务器必须也跑iperf3的服务器模式默认端口5201否则数据包直接被系统丢弃吞吐量看起来会很奇怪。5.3 延迟抖动异常查调度策略和资源争抢延迟指标出现周期性抖动可能的原因包括切片资源配额被另一个切片的突发流量挤占、核心网网元触发了周期性定时器、RAN侧调度策略对非GBR业务采用了协商调度。排查建议用Wireshark打开抓包文件按时间统计RTT的分布图。如果抖动周期和gNB的调度周期重合通常是毫秒级优先在RAN侧找原因。如果抖动周期在秒级多为网元内部定时任务影响可以查看AMF、SMF日志中的周期任务输出。5.4 UERANSIM模拟多UE时的资源管理问题模拟大量UE时控制面信令风暴和用户面流量会争抢CPU资源导致测试结果失真。我建议采用多机部署一台机器跑核心网一台机器跑gNBUE模拟两台机器之间用万兆网卡连接。如果只有一台机器至少要把核心网和RAN模拟分配到不同CPU核组用taskset绑定CPU核taskset -c 0-7 docker-compose up taskset -c 8-15 ./nr-ue这种隔离能够显著减少资源争抢带来的测试数据抖动测出来的基线更稳定也更接近真实商用环境的表现。6. 性能基准报告的框架和基线管理测试做完不能只是把数据扔给开发然后说一句“有问题”。性能基准测试的最终交付物是一份可复现、可追溯的报告。我常用的报告框架是测试概述测试目的、涉及的切片类型、被测环境版本核心网版本、UERANSIM版本、服务器配置拓扑说明画出端到端数据链路图标清各项参数指标定义每个指标的计算方式、统计口径比如平均RTT是用ICMP还是业务流量测的基线结果单用户、多用户、隔离性等各层测试的实测数据表对比分析与SLA目标值的对比、与历史版本的对比问题清单发现的问题、影响范围、建议修复优先级。报告里的基线数据尤其重要。我坚持每轮测试使用同一套环境、同一套参数、同一个测试序列保证数据可对比。任何环境变更核心网升级、服务器配置调整之后都要重新跑一遍基线不要拿上一次的基线数据硬套。一次我在free5GC版本升级后直接拿老版本数据做对比结果发现吞吐量下降一半吓得以为是代码回归后来才定位到是新版本默认配置改了隧道封装方式环境变更导致的性能差异。最后再说一个经验切片性能基准测试前期准备占七成真正跑数据只占三成。环境搭建和指标定义阶段多花些时间把切片配置、抓包点、流量模型都确认清楚后面的测试就是水到渠成的事。如果环境都没起干净就开始跑数据后面的排查成本会远高于重新搭环境的成本。这个教训我在做切片测试第二批用例时深有体会希望大家不用重新踩一遍。