3. 测试矩阵核心概念
在通信原型验证过程中，测试矩阵（Test Matrix）是连接需求、设计与验证的桥梁。它并非简单的“用例清单”，而是一种结构化、多维度的测试设计工具，用于系统性地覆盖通信协议栈、射频链路、基带算法以及端到端业务场景。一个高质量的测试矩阵，能够帮助工程师在有限的研发周期内，最大化发现缺陷的概率，并为后续的数据复盘提供可追溯的基线。本章将深入剖析测试矩阵的三个核心构成要素：矩阵维度、场景分类，以及测试项与预期结果之间的映射关系。
3.1 矩阵维度：从单一维度到多维正交分解
核心原理：测试矩阵的“维度”是指影响通信系统行为的独立变量集合。在通信原型测试中，常见的维度包括协议栈层级（PHY、MAC、RLC、PDCP、RRC）、信道条件（AWGN、TDL-E、TDL-F）、载波频率（FR1/FR2）、调制编码方案（MCS）、天线配置（SISO/MIMO/波束赋形）、业务模型（FTP、VoIP、VR视频）以及核心网状态（空闲态/连接态/切换态）。维度的选择决定了测试覆盖的广度与深度。一个常见的误区是试图覆盖所有维度的笛卡尔积，这会导致测试组合爆炸。例如，5个维度各取5个值，就会产生3125种组合，这在工程上不可行。
判断方法：采用正交分解法与边界值分析法相结合。首先，通过需求文档和协议规范识别出所有影响系统行为的独立变量；其次，使用Pairwise或正交表（如Allpairs工具）筛选出覆盖所有两两组合的最小测试集；最后，针对每个维度补充边界值（如最大TA值、最小SNR门限）和异常值（如超出规定范围的频偏）。
| 维度类别 | 典型取值 | 影响对象 | 优先级 |
|---|---|---|---|
| 信道模型 | AWGN, TDL-E(30ns), TDL-F(300ns) | 均衡器、信道估计 | P0（必测） |
| MCS等级 | QPSK(0-4), 16QAM(5-10), 64QAM(11-20) | 编码速率、吞吐量 | P0 |
| 子载波间隔 | 15kHz, 30kHz, 60kHz | OFDM符号长度、CP开销 | P1 |
| 天线端口数 | 1T1R, 2T2R, 4T4R | 空间复用增益、分集增益 | P1 |
| 业务负载 | 空载, 50%负载, 满载 | 调度器、缓存管理 | P2（视版本特性） |
3.2 场景分类：功能、性能、异常与互操作
核心原理：场景分类是将测试项按照测试目的和系统行为特征进行归组。合理的分类有助于资源分配和缺陷定位。通常分为四大类：功能场景（验证协议流程和状态机是否正确）、性能场景（验证在特定负载和信道条件下的吞吐量、时延、丢包率是否达标）、异常场景（注入干扰、丢包、失步等异常，验证系统的鲁棒性和恢复能力）、互操作场景（验证原型与商用设备或仿真器之间的兼容性）。
操作流程：场景分类应遵循“从简到繁、从理想到恶劣”的原则。首先执行基础功能场景，确保信令流程畅通；然后逐步增加信道噪声和业务负载，进入性能场景；接着人为制造异常（如拔出天线、注入CRC错误），观察系统反应；最后进行跨厂商互操作验证。每个场景都需要明确其入口条件（如UE处于RRC_CONNECTED状态）和退出条件（如测试完成或系统崩溃）。
背景与约束：某厂商的gNB原型机需验证在TDL-E 30ns信道下，64QAM MCS20的峰值吞吐量。测试环境为1个UE（模拟器），带宽100MHz，子载波间隔30kHz。
初始现象：实测吞吐量仅为理论峰值的65%（理论峰值约1.4Gbps，实测约910Mbps）。
分析过程：首先检查CQI上报值，发现UE上报CQI为12（对应MCS16），而非期望的MCS20。进一步分析发现，信道估计模块在TDL-E 30ns时延扩展下，导频插值精度不足，导致SINR估计偏低约3dB。
操作步骤：1) 将信道模型切换为AWGN，确认吞吐量恢复至理论值的92%，排除调度器问题；2) 修改信道估计器中的插值滤波器阶数，从2阶提升至4阶；3) 重新运行TDL-E场景，吞吐量提升至1.25Gbps（89%）。
结果对比：优化前910Mbps vs 优化后1.25Gbps，提升37%。
风险与代价：高阶滤波器增加了约15%的DSP计算量，导致功耗上升，需评估散热方案。
复盘经验：性能测试场景必须包含“信道估计精度”这一隐性维度，否则容易误判为射频或调度问题。
3.3 测试项与预期结果：可量化、可判定、可追溯
核心原理：每个测试项必须包含三个要素：激励（Stimulus）、观测点（Observation Point）和预期结果（Expected Result）。预期结果不能是模糊的定性描述（如“系统正常工作”），而必须是可量化的指标或明确的状态。例如，“BLER不超过10%”、“RRC连接建立时延小于50ms”、“切换成功率大于99%”。同时，预期结果需要定义容差范围，因为通信系统存在随机性，单次测量结果会有波动。
判断方法：采用SMART原则来编写预期结果：S（Specific）具体，M（Measurable）可测量，A（Achievable）可达，R（Relevant）相关，T（Time-bound）有时限。对于统计类指标（如误块率），需要明确采样次数和置信区间。例如，“在1000个TB块传输中，BLER≤10%，置信度95%”。
// 测试项定义示例（JSON格式）
{
"testCaseId": "TC_PERF_001",
"testObjective": "验证下行峰值吞吐量",
"preConditions": ["UE处于RRC_CONNECTED", "信道模型TDL-E 30ns", "MCS=20"],
"testSteps": [
"1. 配置gNB下行资源分配为满RB",
"2. 启动下行数据业务，持续60秒",
"3. 记录物理层吞吐量"
],
"expectedResult": {
"metric": "PHY Throughput",
"targetValue": 1.4, // Gbps
"tolerance": "±5%",
"samplingCount": 600, // 每秒采样一次
"passCriteria": "平均吞吐量 ≥ 1.33 Gbps"
}
}
| 测试项类型 | 预期结果示例 | 判定方式 | 常见错误 |
|---|---|---|---|
| 功能测试 | RRC重配置完成，UE进入目标小区 | 信令跟踪比对 | 只验证结果，不验证中间状态 |
| 性能测试 | 用户面时延 ≤ 4ms（URLLC场景） | Wireshark时间戳 | 未排除处理时延的抖动 |
| 异常测试 | 射频拉远单元（RRU）掉电后，系统在200ms内检测到VSWR告警 | 网管告警查询 | 未定义检测时间起点 |
| 互操作测试 | UE从厂商A的gNB切换到厂商B的gNB，切换成功率≥98% | 统计切换次数 | 样本量不足，统计误差大 |
3.4 矩阵构建的常见误区与复盘要点
核心原理：测试矩阵不是一次性交付物，而是随着原型迭代不断演进的活文档。常见的误区包括：维度遗漏（只关注协议层，忽略射频硬件接口）、场景同质化（大量测试项覆盖相同路径，关键分支未测）、预期结果模糊（使用“正常”“良好”等词汇）、缺乏可追溯性（测试项无法对应到具体需求或缺陷）。
总结复盘：每次测试迭代结束后，应进行矩阵有效性分析。统计各维度的缺陷检出率，如果某个维度（如特定MCS等级）从未发现缺陷，且代码覆盖率显示该路径已执行，可考虑降低该维度的测试频率；反之，如果某个场景频繁出现缺陷，则需要细化该场景的子测试项。此外，矩阵的变更必须经过评审，避免随意增删导致基线漂移。
背景：项目初期矩阵包含1200个测试项，但执行一轮回归需要2周时间，严重拖慢迭代节奏。
分析：通过缺陷分布统计发现，70%的缺陷集中在“切换场景”和“高MCS+低SNR”组合下，而“空闲态小区重选”相关测试项缺陷率仅为2%。
优化措施：1) 将“空闲态重选”测试项从每轮必测改为每3轮回归一次；2) 增加“切换+波束失败恢复”组合场景的测试项；3) 引入风险分级，P0级测试项（影响核心功能）必须全量执行，P2级测试项按周轮换。
结果：回归周期从2周缩短至5天，缺陷检出率反而提升了15%（因为释放的时间用于探索性测试）。
经验：测试矩阵的优化应基于数据驱动，而非主观感觉。定期分析“测试项-缺陷”关联矩阵，是持续改进的关键。
综上所述，测试矩阵的核心在于通过合理的维度划分控制复杂度，通过科学的场景分类保证覆盖度，通过严谨的预期结果定义确保可判定性。三者相互依存，共同构成通信原型验证的质量基石。在实际操作中，建议使用专门的测试管理工具（如TestLink、Jira Xray）来维护矩阵的版本和变更记录，确保团队协作的一致性。