企业官网建设流程全解析

聊5G网络切片的时候，很多软件测试同学的第一反应是——这不就是网络工程师的事吗？我一开始也这么想，直到真把“5G网络切片性能基准测试”这个任务接到手里，才发现它本质上是个彻头彻尾的测试问题：设计用例、搭环境、定基线、跑流量、采集指标、定位瓶颈、出报告。这跟我们测一个Web服务、一个App后台，流程上并没有本质区别，区别只在于被测对象换了，换成了一个横跨终端、空口、核心网、数据网络的端到端链路。

这篇文章就是把我自己在5G网络切片性能基准测试上的完整实践过程，从认知、指标、环境、用例设计到问题排查，一条线写清楚。适合两类人：一类是刚接触5G核心网/切片测试的软件测试工程师，另一类是已经在做通信测试、但想系统梳理切片性能基准测试方法论的同行。看完你至少能回答三件事：切片测试到底测什么、怎么搭一个能跑的真实环境、拿到数据之后怎么分析出有效结论。

1. 5G网络切片不是“5G网络”，测试视角的认知重构

1.1 网络切片的本质：一张物理网络上切出多个逻辑网络

网络切片这个词听起来很高大上，但用大白话解释就一句话：把一张物理5G网络，按需切成多个逻辑上互相隔离的“虚拟网络”。每个虚拟网络有自己独立的资源配额、独立的QoS策略、独立的业务逻辑，甚至独立的管理视图。

打个比方，一条高速公路上有公交专用道、货车车道、私家车道，所有车都跑在同一条物理路面上，但每条车道的通行规则、限速标准、优先级别完全不一样。公交车道要让公交车优先通过，货车车道要承受更高的载重。网络切片干的事情就是类似的事：同一个基站、同一个核心网，通过资源划分和调度策略，同时服务“低延迟的自动驾驶业务”“大带宽的高清视频业务”“海量连接的水表电表业务”，且互不干扰。

在3GPP的标准定义里，一个网络切片是用S-NSSAI（Single Network Slice Selection Assistance Information，单一网络切片选择辅助信息）来唯一标识的。S-NSSAI由两部分组成：SST（Slice/Service Type，切片/服务类型，8位）和可选的SD（Slice 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与核心网的NGAP（NG应用协议）接口通信；
• 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

这段配置的意思是：该网络支持两个切片，一个用SST=1标识，适合eMBB业务，SD为0x010001；另一个用SST=2标识，适合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会发注册请求给gNB，gNB通过NGAP封装转发给AMF，AMF与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到应用服务器的完整路径

切片性能测试不是直接对着核心网网元打压力，而是走完整的端到端路径。一条典型的测试数据路径是：

UE（UERANSIM模拟） → gNB（UERANSIM模拟） → 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资源，导致测试结果失真。我建议采用多机部署：一台机器跑核心网，一台机器跑gNB+UE模拟，两台机器之间用万兆网卡连接。如果只有一台机器，至少要把核心网和RAN模拟分配到不同CPU核组，用taskset绑定CPU核：

taskset -c 0-7 docker-compose up taskset -c 8-15 ./nr-ue

这种隔离能够显著减少资源争抢带来的测试数据抖动，测出来的基线更稳定，也更接近真实商用环境的表现。

6. 性能基准报告的框架和基线管理

测试做完不能只是把数据扔给开发然后说一句“有问题”。性能基准测试的最终交付物是一份可复现、可追溯的报告。我常用的报告框架是：

• 测试概述：测试目的、涉及的切片类型、被测环境版本（核心网版本、UERANSIM版本、服务器配置）；
• 拓扑说明：画出端到端数据链路图，标清各项参数；
• 指标定义：每个指标的计算方式、统计口径（比如平均RTT是用ICMP还是业务流量测的）；
• 基线结果：单用户、多用户、隔离性等各层测试的实测数据表；
• 对比分析：与SLA目标值的对比、与历史版本的对比；
• 问题清单：发现的问题、影响范围、建议修复优先级。

报告里的基线数据尤其重要。我坚持每轮测试使用同一套环境、同一套参数、同一个测试序列，保证数据可对比。任何环境变更（核心网升级、服务器配置调整）之后，都要重新跑一遍基线，不要拿上一次的基线数据硬套。一次我在free5GC版本升级后直接拿老版本数据做对比，结果发现吞吐量下降一半，吓得以为是代码回归，后来才定位到是新版本默认配置改了隧道封装方式，环境变更导致的性能差异。

最后再说一个经验：切片性能基准测试，前期准备占七成，真正跑数据只占三成。环境搭建和指标定义阶段多花些时间，把切片配置、抓包点、流量模型都确认清楚，后面的测试就是水到渠成的事。如果环境都没起干净就开始跑数据，后面的排查成本会远高于重新搭环境的成本。这个教训，我在做切片测试第二批用例时深有体会，希望大家不用重新踩一遍。