TM500基站测试：从TMA偏好设置到RCI自动化回归测试

简介：面向TD-LTE基站研发、生产与现场测试人群的官方用户指南，源自艾法斯（Aeroflex）的TM500 LTE测试手机应用。文档为docx格式，共1个文件，压缩包约4.62MB，适合需要系统掌握TM500测试仪操作的工程师、研发人员与技术支持团队。内容先介绍TM500测试手机的产品定位，说明其如何模拟真实终端，支持TD-LTE等多种制式，从射频性能、协议栈功能到系统级行为全面验证基站；同时梳理了LTE文档套件的整体构成。正文详细讲解测试应用的主窗口、工具窗口布局、任务组织与启动方法，涵盖启动、配置、执行、分析全流程，并给出测试场景配置步骤、操作示例、常见问题排查，以及警告、注意、提示等文本约定。此外还列出适用读者范围，并说明官方支持、培训课程和反馈机制，便于用户获取后续协助。该资料在平台已有278人学习浏览，作为原厂用户指南的电子版，能帮助研发测试人员快速上手TM500，规范TD-LTE基站测试流程并提升验证效率。

1. TM500 不是手机：它如何在基站研发里撑起可重复的回归测试

某设备厂商的射频实验室里，A同学跑了一整晚 TD-LTE 基站的过载测试，第二天早上发现第 27 步掉话，回放 log 始终找不到原因——最后排查出来是测试终端自己在上一轮遗留的 RRC 状态没复位。这种翻车，几乎每个做基站测试的人都遇到过。TM500 就是为这类问题生的设备：它不是拿在手里的手机，而是把 LTE 终端协议栈固定成一台可重复、可记录、可远程控制的测试仪器，专门用来验证基站的射频性能、协议流程和系统级行为。

这本用户手册，覆盖从软件界面的 TMA 到 Test Manager、Test Steps、测量记录再到 RCI 自动化，几乎把测试工程师一天里要碰的功能都写到了。适合做 LTE/TD-LTE 基站研发、生产和现场测试的人；对写自动化脚本的同事来说，后半本远程控制章节才是重点。要快速上手，建议从第 2 章的偏好设置开始读，而不是从“如何生成脚本”开始读。

2. 第一次打开 TMA：界面组织与 7 个我建议先碰的偏好设置

2.1 为什么 TMA 要拆成“主窗口 + 工具窗格”

TMA（Test Mobile Application）的主窗口不是把功能堆成一排按钮，而是只保留菜单、工具栏和工作区；测试步骤库、脚本编辑器、测量结果是独立的工具窗格，可停靠、可浮动、可自动隐藏。我第一次用的时候觉得窗口太多，适应了很久。后来发现这个设计是有原因的：基站测试场景复杂，需要同时盯脚本执行行、当前状态和实时测量，任何一个单窗口都装不下这些信息。工具窗格的意义在于：需要哪个拉哪个，不需要的收掉，留出最大面积给日志和星座图。

文档里讲到的“arranging tool windows”值得多看一遍，绝大多数新手抱怨“界面太挤”，其实是不会用自动隐藏和停靠预设。View 工具栏控制各窗格的显隐，常用的是 Test Step Library、Test Manager、Measurement、Session 这四个。早期版本里 TMA 启动时的默认布局并不适合调试，我一般会把窗格存成自定义布局，避免每次重排。这个动作在后期接自动化测试时尤其值钱——主控脚本通过 RCI 启动 TMA 后，界面布局哪怕乱了，至少不能影响测量记录，所以布局和偏好要一起固化下来。

2.2 连接偏好和数据记录偏好：先于测试动作设置

Connection Preferences 里要确认测试终端（TM500 本体）的连接地址和端口。TMA 是跑在控制电脑上的软件，TM500 是仪器硬件，两者通过以太网或本地连接通信。常见现象：TMA 显示连接超时，测试步骤全部置灰。原因往往是地址填错，或者测试终端被前一个会话占用。我会先在偏好里把超时时间拉长一点，首次连接便于观察握手日志，确认通了之后再改回正常值。

Data Log Preferences 是另一个高频设置：日志保存目录、文件命名规则、是否按大小切割。跑 24 小时稳定性测试时，日志增长速度很快，推荐把保存目录指到剩余空间大的分区，并按“日期 + 用例名”命名，否则后期整理时会很被动。Conversion Preferences 控制 log 转成文本或 CSV 时的格式选项，最常见的坑是分隔符和编码不匹配，导致 Excel 打开乱列。把默认分隔符固定成 CSV 标准逗号，并在第一次转换后打开检查一遍表头，能省下大量返工时间。

Command Line Preferences 和 Error Monitor Preferences 属于调试向：前者控制 TMA 自带命令行的回显和脚本宽度，后者设置报错弹窗的级别。现场长时间跑批时，我会把 Error Monitor 弹窗级别调低，避免一个警告把整个自动化卡住。

2.3 转换偏好、会话历史和性能调优：影响结果文件质量的参数

Session History Preferences 决定 TMA 保留多少个历史会话。默认值通常不大，跑几天就滚动覆盖。我的习惯是调高上限，但配合“定期导出和清理”——历史上翻过车：某同事清理了会话历史，结果把当天还没导出的测量记录一并扫掉。从此以后，我每次做清理前都先确认归档目录里已经有备份，再动会话。

性能调优（Performance Tuning）和绘制优先级（Charting Priority）是容易被忽略的两页。实时绘图占 CPU，在大量自动测量跑批时，如果不希望界面卡死，就把实时星座图关闭，只记录数据，事后再从记录里绘制。图表优先级设置成“后台记录优先”，能让测量采集不丢点，代价是界面看着不那么流畅。Test Manager Preferences 和 Incident Reporting Preferences 相对次要：前者影响脚本编辑器默认字体和自动保存间隔，后者是故障上报通道配置，一般团队环境里用得少，我通常保持默认。

2.4 新环境落地清单：装机后先改这 7 项

我一般按这个顺序改：先 Connection 保证连得上，再 Data Log 保证数据落得下来，最后再碰绘图和性能。理由是后面的所有操作——脚本、测量、自动化——都以“连接正常”和“日志落盘正常”为前提。别一上来就调星座图颜色，那是最后一个小时才做的事。

3. 用 Test Manager 编排可回归用例：套件、用例、脚本、命令的四层关系

3.1 先理解四层结构：Suite → Case → Script → Command

Test Manager 是 TMA 里管测试编排的模块。核心模型是四层嵌套：Test Suite（测试套件）包含多个 Test Case（测试用例），用例通过调用 Test Script（测试脚本）执行，脚本内部由一条条 Command 或 Test Step 组成。这里的 Command 指脚本编辑器里的单步操作，比如“发送某条 RRC 消息”或“读取一个测量值”。理解这层关系比记住每个按钮更重要，因为后面所有组织、模板、快捷键、注释都建立在这套嵌套上。

嵌套的意义在于：套件级做环境准备和资源回收，用例级做一次业务场景，脚本级做可复用步骤。同一个脚本可以被多个用例引用，同一个用例也可以挂在多个套件里。如果一开始把公共步骤平铺在每个用例里，后续修改就要改很多处，这属于典型返工现场。我见过别人把一个“去附着”脚本复制到 20 个用例里，等到要统一改成“先释放数据业务再去附着”时，一整晚都在做重复劳动。

3.2 三分钟生成一个可运行脚本

在 Test Step Library 里搜索需要的步骤，例如 Attach；把它拖到脚本编辑器；双击步骤填参数；保存为脚本；新建测试用例并挂上这个脚本；把用例加入测试套件。文档里有一节专门讲 How to generate a simple script，我第一次照着做大概只花了几分钟。要点不是拖拽本身，而是“先建空脚本再拖，还是直接拖到用例里”的选择。

直接拖到用例里也能生成脚本，但文件名是默认的，后人看到脚本名完全不知道它是干嘛的。我习惯先用“目的-动作-配置”格式命名脚本，比如 Attach_NW_Band38_TM500_DefaultConfig，至少半年后回来看不会猜谜。完成之后在 Test Manager 里右键 Run，会看到步骤高亮执行。第一次跑建议只挂一个脚本，不要直接跑整套件；先把单脚本跑通，再往套件里加。这个节奏能大幅减少定位问题时浪费的时间，应该当成默认调试习惯。

3.3 用例参数怎么定：一个基本呼叫流程实例

给一个最常用的用例骨架，作为抄作业的起点。用例目标：基本呼叫建立与释放。前置条件：终端已空闲、网络小区已配置。期望结果：RRC 连接建立并成功去附着，状态回到空闲。

参数不要硬编码到用例里，建议用覆盖表引用，下一章细说。这个骨架的关键是“先复位、后配置、再业务、最后清理”的顺序——顺序反了，测试终端会带着上一轮的 RRC 状态进入下一轮，测试结果根本不可比。这个教训我记了很久，后来每次搭用例都按这个顺序检查一遍。

3.4 组织、注释和模板复用的习惯

套件和用例的树形结构支持拖动、复制、创建快捷方式。文档单独讲 Creating shortcuts，它的价值在于：同一个用例可以出现在多个套件里而不复制实体，修改原用例后所有快捷方式同步生效。这个特性适合搭“冒烟套件”和“全量回归套件”并用同一批用例的组合，不需要维护两份用例副本。

注释是另一个被低估的功能。给套件、用例、脚本加注释，在团队交接时几乎等于后悔药。我会在每个用例头写三行：测试目的、前置条件、期望结果；在脚本级写依赖哪些配置表。这样做之后，出问题时一眼能判断是该查用例参数还是该查脚本逻辑。模板用于新建用例或脚本时预置公共步骤，例如把“复位终端”和“清除测量记录”做成模板，新用例从模板派生，比到处复制脚本干净得多。

组织上唯一要注意的是移动节点后检查相对引用。快捷方式指向的目标可能因移动路径变化失效，跑之前先确认引用关系高亮正常，免得到夜里才发现某个用例跑的是空脚本。

4. Test Steps 按协议栈分工：常用步骤、覆盖表与参数输入的边界

4.1 步骤分类背后是协议栈分层

TMA 的测试步骤不是随意堆出来的，按协议栈从底到顶分：Layers 1/2 管物理层、MAC、RLC，Channel Configuration 和 Channel deletion 管小区和信道，Higher Layers 和 NAS 管 RRC 与 NAS 流程，APT 管接入层参数，Data service generator 管业务面，Override tables 管批量参数覆盖。理解这个分层后，找步骤时就按“我要动哪一层”去定位，而不是在整个步骤列表里做全文搜索。

文档把测试步骤列成十几类，常见类别包括 System Control、Script Control、Measurement、Layers 1/2、Channel Configuration、Channel deletion、Test features、Higher Layers、NAS、APT、Data service generator、Override tables。我第一次看时觉得琐碎，直到遇到一个“测试终端连不上小区”的问题——排查了一圈才发现是 Channel Configuration 里的小区 ID 没匹配上基站的 PCI。从那以后我找步骤先问自己是哪一层，再进对应分类里找，不再乱翻。

4.2 公共步骤速查：System Control、Script Control 与 Measurement

System Control 负责测试终端的全局状态，比如复位、射频开关、同步源选择。参数常见就三个：Reset 类型、RF on/off、等待同步时间。Script Control 负责循环、条件跳转、等待和失败处理，它把一串静态步骤变成有逻辑的脚本。例如“等待 Attach 完成，超时 30 秒则跳失败处理”，在脚本里显式加“失败后抓取当前测量并保存”，比跑完再猜要高效得多。

Measurement 本身不产生测试动作，只负责启动测量、停止测量、读取结果、保存结果。启动测量时选组 ID 和类别 ID，这和附录 A 的 Group/Category ID 表对应。三个类别组合起来几乎能覆盖任何用例的基本骨架：系统控制负责干净起点，脚本控制负责随时序变化，测量负责结果记录。其它类别更像是具体的业务动作，按需插入就行。

4.3 信道配置和覆盖表：测试频点、带宽、MCS 时的高频操作

做 TD-LTE 基站测试，每天改得最多的是小区频点、带宽、PCI、MCS 和上下行子帧配置，这些集中在 Channel Configuration 步骤里。注意它和 Channel deletion 的关系：修改一个已激活的小区，通常要“先删后建”，而不是直接覆盖参数；修改专用信道时顺序尤其敏感。文档把 Channel deletion 单独列一节不是没有原因，我在现场见过几次配置冲突，都是因为旧信道没删干净，新参数写不进去。

Override tables 是批量引入不同参数组合的最实用工具。把频点、带宽、MCS、子帧配比的组合预先放在覆盖表里，测试用例通过“指向第几行”来切换配置，而不是在每个用例里重填。优点是改配置只改表、不动脚本，回归时跑同一脚本就能覆盖多组参数。我第一次意识到这个设计的价值，是在连续改 30 行脚本参数时——一个数字错了，得一个用例一个用例地找。

对于覆盖表，注意一点：不能只建表而不在脚本里指定“使用覆盖表第 N 行”，否则脚本跑的是默认参数。你会以为是覆盖成功，实际没有。这种“以为设置了实际没生效”很容易被忽略，我好几次翻车都在这里，后来每次保存脚本前都专门检查一遍覆盖表引用行。

4.4 参数输入方式与常见返工原因

参数输入有三种方式：直接填、下拉选、引用变量或覆盖表。直接填适合单次测试，下拉选适合枚举值，引用变量适合批量场景。参数有严格的类型边界：枚举不能输数字，整数和浮点要检查范围，时间要注意 ms/s 单位，十六进制字节块常见于 NAS 消息内容，填错会被步骤校验挡回来。

常见返工原因第一条是单位错，毫秒填成秒，超时全部失效；第二条是引用覆盖表时没选表名，步骤栏直接提示无效；第三条是删除信道的步骤放在配置信道之前，导致空小区还在尝试配置；第四条是改动脚本参数后没有重新保存，运行的是磁盘上旧版本。每一条事后看都低级，但都真实消耗过时间。我的习惯是保存脚本前先看一遍参数摘要面板，专门检查单位和表引用。

5. 测量与日志排查：手动自动记录、log 转换和 5 个常见问题

5.1 日志类型怎么选：Layer 3 Status、协议数据与星座图

TMA 的测量记录不只是数值，还有状态日志。Layer 3 Status logging 记录终端和网络之间的 RRC/NAS 状态变化，是排查信令流程的首选。协议数据日志记录原始协议消息，携带更多字段，适合定位具体是哪条消息出了问题。星座图记录解调后的 IQ 采样点，用来判断 EVM 差是因为噪声、干扰还是信道估计不准确。

选型理由很简单：看有没有接通用 Layer3 Status；看具体哪条消息出错用协议日志；看射频解调质量用星座图。三种日志的时间戳要保持一致，否则后面对齐全靠猜。我开始用的时候习惯只开一种日志，等到问题复现才发现信息不够，现在基本同时开状态日志和协议日志，星座图按需再开，磁盘压力会小很多。

5.2 手动测量和自动测量：什么时候用哪个

手动测量适合单次点测，比如验证某个频点的 RSRP 读数正不正确。自动测量适合长时间跑批，按组 ID 和类别 ID 启动后自动记录。文档里附录 A 的 Group and Category ID 表就是用来配置测量范围的核心参考，不细看这张表，自动测量启动后可能一个指标都没采到。

长时间回归里我几乎全用自动测量，因为手动测量无法保证每轮都在同一时刻采样，比较结果不可靠。自动测量启动前先确认组 ID 已经配置正确，不然记录文件里只有空目录，跑完才发现就晚了。文档里区分了 logging manual measurements 和 logging automatic measurements，对应到操作上是两个入口，入口名字有点像，选错之后的表现也不明显，第一次用的人建议先跑 30 秒小样验证一下，再上长时间任务。

5.3 log 文件转换与数据记录选项

记录下来的原始 log 不能直接给分析工具，一般要经过转换。转换偏好里选好目标格式（文本或 CSV）、分隔符、编码和时间基，然后指定源文件和输出目录。转换后务必抽查开头、中间、结尾三条记录：头尾对齐完整，说明文件没截断。如果某一端缺数据，先检查是不是记录过程中磁盘满了或者文件切割参数设得太小。

数据记录选项里还包含缓存上限和文件切割策略。长时间跑批时我会把缓存上限调大，并开启自动切割，避免单个文件过大导致转换工具崩溃。测量记录特别多的时候，先用小数据量试转一次，确认分隔符和表头没问题再全量转换。这个习惯至少帮我省过一晚的返工，因为转换配置里的编码选项一旦选错，整批 CSV 打开都是乱码，重转又得花同样的时间。

5.4 排查记录：这 5 个问题我基本都遇到过

问题一：跑了一整晚，第二天测量记录全是空的。

现象：自动测量“启动”了，但记录文件里没有数据。

原因：用例脚本里没有显式加“启动自动测量”步骤，人工启动的测量在 TMA 重启后不保留。

解决：在每个用例开头加“启动测量”步骤、末尾加“停止测量”，并确认状态窗口显示 Recording。

问题二：转换后的 CSV 时间戳和信令对不上。

现象：日志时间整体偏移或抖动。

原因：记录文件中同时存在本地时钟和仪器时钟，转换时用了错误的时钟源。

解决：转换配置里统一指定仪器时钟，先转换小段数据做对齐验证。

问题三：星座图打开是空白。

现象：界面有星座图控件，但没有采样点。

原因：信号没有同步，或触发方式选成手动且无信令触发。

解决：先在频谱或功率视图确认同步，触发方式改为“解调成功后自动触发”。

问题四：多组结果无法按用例归档。

现象：自动测量数据都在，但分不清哪段属于哪个用例。

原因：用例边界没有在记录流里标记出来。

解决：每个用例开始处打一个事件标记（Event Triggered Logging），事件名用用例 ID。

问题五：清理了会话历史，结果把 log 也清没了。

现象：Session History 里没有记录，归档目录里文件也被移除。

原因：会话清理连带清理了关联的数据文件。

解决：清理前先导出或转换，或把数据记录目录移到独立归档盘，并设置清理前确认或禁止自动清理。

6. 用 RCI 把 TMA 拉进自动化：一套能过夜跑批的脚本起点

6.1 远程控制结构：TMA、测试终端与 RCI 的三角关系

RCI（Remote Control Interface）是 TMA 对外提供的远程控制通道。测试终端硬件、运行 TMA 的控制电脑和自动化主控三者通过它串起来：主控连到 TMA，TMA 控制终端，TMA 回传指示消息。自动化主控不再需要有人盯着界面，适合过夜跑批。文档里专门有一章讲 remote operation，包括从命令行启动 TMA 和从另一台电脑建立连接，都是同一个控制链路的不同入口。

6.2 最小自动化流程：连接、配置测量组、开测、收指示

最小闭环四步：建立连接；清空并配置测量组；启动记录；执行用例后停止记录并断开。测量组和类别 ID 分别对应文档里的 LC_GRP 和 LC_CAT 类命令——组负责“记录哪几类测量”，类别负责“在这些类里细分到哪个粒度”。这个关系和手工操作里选组 ID 类别 ID 是同一个概念，只是从界面点选变成了命令行下发。

6.3 一个示意脚本与参数说明

import socket import time def rci_command(sock, cmd: str, timeout: float = 10.0) -> str: # 发送单条 RCI 命令，读到命令提示符或超时后返回回显 sock.sendall(cmd.encode("ascii") + b"\r\n") buf = b"" deadline = time.time() + timeout while time.time() < deadline: chunk = sock.recv(4096) if not chunk: break buf += chunk if b"READY" in buf: break return buf.decode("ascii", errors="replace") # 连接 TMA 的 RCI 端口，端口以本机 Connection 偏好为准 sock = socket.create_connection(("127.0.0.1", 9000), timeout=5) # 先清空测量组 1，再向组里添加需要记录的类别 ID rci_command(sock, "LC_GRP 1 CLEAR") rci_command(sock, "LC_GRP 1 ADD 3,5,7") # 对类别 10、20 做细粒度记录，随后开始记录 rci_command(sock, "LC_CAT 1,10,20") rci_command(sock, "LC_START") # 在这里由主控启动 Test Manager 用例，跑完再收尾 # time.sleep 只是示意，真实使用时替换为用例执行等待 time.sleep(60) rci_command(sock, "LC_STOP") sock.close()

整个脚本围绕“先清空再配置”的原则，避免上一轮组配置残留进本轮；LC_START 和 LC_STOP 包住用例执行区间，保证记录边界清晰。命令名是对照文档里 Logging configuration commands 和 Example LC_GRP and LC_CAT commands 章节整理的示意写法，不同版本在回显格式上可能存在差异，落地前先在自己的环境里发一条命令确认提示符和返回内容；端口 9000 只是示例，实际使用 Connection 偏好里的数值。如果自动化主控和 TMA 不在同一台机器，把 127.0.0.1 换成 TMA 所在机器的地址。

我最早做远程自动化时图省事，没在用例开头做“清空测量组”，结果每一轮回归的测量数据都叠加了上一轮的配置，结果文件里的组号对不上，浪费了整整一天。从那以后，我每次写自动化脚本都强制先走一遍“连接—LC_GRP 清空/重建—LC_START—用例—LC_STOP”的最小闭环，再往上加业务步骤。如果你也要搭类似的过夜跑批，建议先把这条闭环跑通，再谈效率和报表。希望帮到你。

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