简介：这份文档是Aeroflex（艾法斯）TM500 LTE Test Mobile Application的官方用户指南，面向从事TD-LTE基站研发、生产与现场测试的工程师、测试人员及技术支持团队。TM500作为模拟真实移动终端的网络测试仪，被华为、中兴、大唐、诺基亚-西门子、阿尔卡特-朗讯、爱立信等厂商广泛用于产品开发，本手册正是帮助用户理解并操作该测试应用、实现高效精确测试的权威参考。资源包内共1个docx文件，约4.62MB，内容涵盖TM500 Test Mobile介绍、LTE文档套件说明、TMA主窗口与工具窗口操作、测试场景配置步骤、示例配置及常见问题解决方案，并附文本约定、技术支持与培训、反馈机制等章节，目录结构清晰，便于按模块查阅。目前已有284人学习。读者可借此掌握TMA的启动与组织方式、硬件软件界面设置及典型测试流程，快速上手基站射频性能、协议栈功能与系统级行为验证，减少摸索成本。

1. 拿到一份 2010 年的 TM500 用户手册，先别急着翻目录

如果你手上有一台 TM500 综测仪，或者正在做 LTE 基站的协议栈联调，这份《TM500 LTE Test Mobile Application User Guide》大概率是你绕不开的一手资料。它不是什么新潮的教程，而是一份 Issue 16、2010 年 2 月定稿的官方操作手册，覆盖了 TMA 主窗口、Preferences 配置、Profile 管理、Test Manager 脚本编排、Test Step 参数填写、测量与日志、会话回放，以及 RCI 远程自动化接口。说白了，它解决的是“这台模拟终端的软件到底怎么配、脚本怎么写、日志怎么捞、远程怎么控”这一整套落地问题。适合谁？基站研发、协议测试、射频验证、产线自动化这几类岗位的工程师，尤其是需要把手工点测变成可复现脚本的人。新手能照着步骤走通一条附着流程，熟手能从中挖出 RCI 命令和测量组 ID 这类边界细节。

2. 把 TMA 跑起来：主窗口、Preferences 与 Profile 三件套

TM500 的软件层叫 TMA（Test Mobile Application），所有测试动作都从这个壳里发起。很多人第一次打开会懵：左边一堆工具窗口，右边是空的，菜单栏里还藏着一个 Test Manager。其实它的组织逻辑很清晰——Preferences 决定“软件怎么跑”，Profile 决定“终端怎么模拟”，Test Manager 决定“流程怎么走”。这三者没理顺，后面写再多脚本也是白搭。

2.1 主窗口与工具窗口的停靠逻辑

TMA 主窗口本身不承载具体测试内容，它是一个容器。真正干活的是 Tool Windows：Test Manager、Command Line、Error Monitor、Session History、Measurements 这些。手册里专门有一节讲“Arranging tool windows”，核心就一句话：工具窗口可以停靠、浮动、自动隐藏，布局会跟着会话走。实操中我一般先把 Test Manager 和 Error Monitor 并排停靠，Command Line 放底部自动隐藏，这样跑脚本时能同时看到步骤执行和错误上报。

启动方式有两种：桌面快捷方式，或者从 Windows 命令行拉起。后者在自动化场景里更常用，因为可以带参数指定初始 Profile 和连接配置。手册第 1 章和第 11 章都提到了命令行启动，区别在于第 11 章是配合 RCI 做远程拉起。如果你只是本地调试，直接双击就行；如果要接产线工装，建议把启动命令固化到批处理里。

提示：工具窗口布局是跟用户配置绑定的，换一台机器或者换一个 Windows 账户，布局会回到默认。团队协作时最好把布局截图存进项目文档，省得每个人上来先花十分钟拖窗口。

2.2 Preferences 里真正影响测试的几项

Preferences 对话框条目很多，但按“会不会让测试翻车”来排，优先级最高的是这几类：

Connection 这一项是最容易出玄学问题的地方。手册里写得很克制，只说“配置连接参数”，但血泪经验是：如果 TMA 连不上硬件，先看 Connection 里的地址是不是还指着上一台设备，再看防火墙有没有拦端口，最后才怀疑网线。Data Log 的路径问题也是老坑，路径里带空格在某些转换工具下会截断文件名，表现是日志“生成了但转不出来”。

2.3 Profile 的建立与复用

Profile 是 TM500 模拟终端行为的配置文件，里面装着频点、带宽、UE 能力、NAS 参数这些。手册第 3 章讲得比较简略，但实际用起来，Profile 的管理策略直接决定测试效率。我的习惯是按“制式+带宽+场景”建三层命名，比如LTE_20M_Attach、LTE_10M_Handover，而不是按日期或人名。这样 Test Manager 里引用的时候一眼能看出用途。

新建 Profile 的典型步骤是：在 Profiles 视图里新建，填基础射频参数，配 UE 类别和承载，保存后关联到 Test Manager 的测试用例。这里有个容易忽略的点：Profile 改动后，已经打开的测试脚本不会自动刷新参数，需要重新加载。手册没明说这一点，但实测就是这样，表现是“改了频点脚本还跑旧频点”，排查半天以为是缓存，其实就是引用没重载。

3. Test Manager 编排：从手工点测到可复现脚本

Test Manager 是这份手册里篇幅最重的一块，也是 TM500 从“手动仪表”变成“自动化平台”的关键。它的模型是四层：Test Suite → Test Case → Test Script → Command/Test Step。理解了这个层级，后面写脚本就是填空。

3.1 四层模型与脚本生成路径

Test Suite 是最大的容器，一个 Suite 可以装多个 Case；Case 对应一个测试场景，比如“开机附着”“切换”“去附着”；Script 是 Case 里的具体步骤序列；每一步要么是 Command（直接下发指令），要么是 Test Step（封装好的高层动作，比如“配置信道”“发起测量”）。手册第 4 章给了“How to generate a simple script”的流程，核心就是拖拽 Test Step 进 Script 编辑区，填参数，保存。

我一般不建议一上来就手写 Command，除非你要做的动作 Test Step 库里没有。Test Step 的好处是参数有校验、日志有结构、出错有明确报错；Command 的好处是灵活，但调试成本高。新手路径：先用 Test Step 拼出一条完整的附着流程，跑通看日志，再逐步替换成 Command 做精细控制。

3.2 Test Step 参数填写与“发现它到底干什么”

手册第 5 章有一节叫“How to discover what test steps do”，这个提法很实在——Test Step 的名字往往比较抽象，比如Channel Configuration、Data service generator，光看名字不知道它下发什么。手册的建议是看参数说明和关联的日志输出。实操中更快的办法是：跑一遍，去 Layer 3 Status 日志里看实际下发的信令，对照参数反推。

参数填写有几个通用规则：必填项没填会标红；枚举型参数是下拉框，不要手输；数值型参数注意单位，比如功率是 dBm 还是 dB，带宽是 RB 数还是 MHz。手册在“How to input test step parameters”里列了这些约定，但没强调单位混用的后果——填错单位不会报错，只会让测试结果莫名其妙偏掉，这是典型的“黑匣子”式翻车。

示例：一条简化的附着脚本步骤序列（伪代码表示层级） Test Suite: LTE_Basic Test Case: Attach_20M Test Script: attach_flow Step 1: System Control -> 初始化小区参数 Step 2: Channel Configuration -> 配置下行/上行信道 Step 3: Higher Layers -> NAS 附着请求 Step 4: Measurement -> 启动 Layer 3 状态记录 Step 5: Script control -> 等待附着完成事件

上面这个序列不是让你照抄，而是说明编排思路：先配系统，再配信道，再发高层信令，同时开测量，最后用脚本控制做同步等待。每一步的参数在手册第 5 章对应小节里都能查到，重点是 Step 5 的等待条件——不要用固定延时，要用事件触发，否则机器快慢不同结果就不一致。

3.3 测量与日志：Layer 3 Status 和自动测量

手册第 6 章把日志分成几类：Layer 3 Status logging、手动测量日志、自动测量日志、协议数据日志。最常用的是 Layer 3 Status，它记录信令流程，排查附着失败、切换失败基本靠它。自动测量则是配好测量组和类别 ID 后，让 TMA 周期性记录射频和性能指标，适合做长时间稳定性测试。

测量配置的关键在附录 A 的 Group 和 Category ID 表。每个测量项对应一个组 ID 和类别 ID，配错了不会报错，只会记录出空数据或者错位数据。我的做法是把常用测量项的 ID 抄在一张便签上贴在工位，配的时候逐项核对。日志转换（Converting log files）也是常踩的坑：原始日志格式和转换后格式是两回事，转换工具的参数在 Preferences 的 Conversion 里配，转之前先确认目标分析工具吃哪种格式。

4. 避坑与排查：五条实测踩出来的记录

4.1 脚本跑完没日志，磁盘却满了

现象：Test Manager 显示脚本执行完成，但 Data Log 目录里找不到对应日志。原因：Data Log 路径指向了一个剩余空间不足的分区，TMA 写日志失败但不一定弹窗，Error Monitor 里可能只有一条低级别告警。解决：把日志路径改到独立数据盘，Preferences 里设置滚动上限，跑长测前先看磁盘余量。

4.2 Profile 改了参数，脚本还在用旧值

现象：修改 Profile 的频点后重新跑 Case，Layer 3 日志显示还是旧频点。原因：Test Case 引用的是 Profile 的快照或缓存，不会自动跟随 Profile 文件变更。解决：改完 Profile 后在 Test Manager 里重新加载关联，或者干脆重建 Case 引用。养成“改 Profile 必重载”的习惯。

4.3 RCI 远程连上了，命令发出去没反应

现象：通过 RCI 建立远程连接成功，发 logging 配置命令返回 OK，但日志没变化。原因：RCI 命令有作用域，连接和断开、日志配置、日志控制是不同命令组，配置完还需要发启动类命令才真正生效。解决：对照手册第 11 章的“Logging configuration commands”和“Logging control commands”两组，确认配置命令之后有没有跟控制命令。另外检查 LC_GRP 和 LC_CAT 的参数是不是跟附录 A 的 ID 表对得上。

4.4 测量数据全是零或者空

现象：自动测量跑了一段时间，导出的数据全是零值或空字段。原因：测量组 ID 或类别 ID 配错，或者测量启动命令发了但对应信道没配起来。解决：先用单次手动测量验证 ID 正确，再切自动测量；确认测量启动在信道配置之后。手册附录 A 的表要逐列看，组和类别是两级索引，别只对一级。

4.5 命令行启动 TMA 报参数错误

现象：从 Windows 命令行拉起 TMA 时提示参数无效，双击却能开。原因：命令行参数对引号和路径格式敏感，路径里有空格没加引号，或者参数顺序跟手册示例不一致。解决：路径统一加双引号，参数顺序照手册第 11 章“Starting the TMA from Windows Command Prompt”的示例来，先跑最简参数确认能起来，再逐步加。

5. 用 Session History 做回放验证：一个被低估的排查手段

手册第 9 章的 Session History 是我认为整份文档里最值得深挖、但最容易被跳过的一节。大多数人跑完测试只看日志，其实 Session History 记录的是整个会话的操作轨迹——你点了什么、脚本执行到哪、命令下发顺序是什么。它的价值在于“事后复现”：当一次失败测试说不清是脚本问题还是操作问题时，把 Session History 导出来，逐条对照，往往能定位到某一步参数填错或者某个命令发早了。

具体做法是：测试失败后，先在 Session History 里用 session browser 定位到出问题的时间段，导出当前会话历史（Exporting and importing sessions），再用“Generate Command Log Files”把操作轨迹转成命令日志。这一步相当于把“人机交互”翻译成“可读的命令序列”，对照手册第 5 章的 Test Step 说明，就能看出哪条命令的参数跟预期不符。如果怀疑是事件触发类日志没记全，还可以用“Recording Event Triggered Logging”补录。

验证脚本可复现性的一个笨办法但很有效：同一脚本连跑三遍，每遍都导出 Session History，对比三次的命令序列是否完全一致。不一致的地方就是脚本里的不确定因素，常见的是固定延时、随机种子、或者依赖上一次会话残留状态。把这三遍对比做完，脚本的稳定性基本就有底了。

从那以后我每次交付自动化脚本前，都强制走一遍“三遍连跑 + Session History 对比”，宁可多花二十分钟，也不要在产线上被一句“上次跑还是好的”堵回来。这份 2010 年的手册虽然老，但 Session History 和 RCI 这两块的思路放到今天的测试自动化里依然成立，值得把它从文档堆里翻出来对着设备走一遍。希望帮到你。

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