简介面向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 要拆成“主窗口 工具窗格”TMATest 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测试终端地址和端口填仪器实际管理地址超时设 10~15 秒Data Log保存目录和命名规则指到独立磁盘格式含日期与用例号Data Log日志切割大小按 500MB 切避免单文件过大ConversionCSV 分隔符与编码逗号 UTF-8转换后立刻抽查表头Session History保留会话数调大上限但每月归档一次Performance实时绘图开关跑批时关星座图只看关键量Charting Priority后台记录优先级设为 High我一般按这个顺序改先 Connection 保证连得上再 Data Log 保证数据落得下来最后再碰绘图和性能。理由是后面的所有操作——脚本、测量、自动化——都以“连接正常”和“日志落盘正常”为前提。别一上来就调星座图颜色那是最后一个小时才做的事。3. 用 Test Manager 编排可回归用例套件、用例、脚本、命令的四层关系3.1 先理解四层结构Suite → Case → Script → CommandTest 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 连接建立并成功去附着状态回到空闲。步骤测试步骤分类关键参数说明复位终端System ControlReset typeFull清除上一个用例遗留状态配置小区Channel ConfigurationEARFCN / 带宽 / PCI 占位按测试计划填写搜网附着Higher Layers / NASPLMN / APN 占位等待状态变为 Attached建立数据业务Data Service Generator上下行速率、时长用于灌入业务量读取测量Measurement组 ID / 类别 ID按测量项目选择去附着NASDetach 类型正常回到空闲态方便下个用例参数不要硬编码到用例里建议用覆盖表引用下一章细说。这个骨架的关键是“先复位、后配置、再业务、最后清理”的顺序——顺序反了测试终端会带着上一轮的 RRC 状态进入下一轮测试结果根本不可比。这个教训我记了很久后来每次搭用例都按这个顺序检查一遍。3.4 组织、注释和模板复用的习惯套件和用例的树形结构支持拖动、复制、创建快捷方式。文档单独讲 Creating shortcuts它的价值在于同一个用例可以出现在多个套件里而不复制实体修改原用例后所有快捷方式同步生效。这个特性适合搭“冒烟套件”和“全量回归套件”并用同一批用例的组合不需要维护两份用例副本。注释是另一个被低估的功能。给套件、用例、脚本加注释在团队交接时几乎等于后悔药。我会在每个用例头写三行测试目的、前置条件、期望结果在脚本级写依赖哪些配置表。这样做之后出问题时一眼能判断是该查用例参数还是该查脚本逻辑。模板用于新建用例或脚本时预置公共步骤例如把“复位终端”和“清除测量记录”做成模板新用例从模板派生比到处复制脚本干净得多。组织上唯一要注意的是移动节点后检查相对引用。快捷方式指向的目标可能因移动路径变化失效跑之前先确认引用关系高亮正常免得到夜里才发现某个用例跑的是空脚本。4. Test Steps 按协议栈分工常用步骤、覆盖表与参数输入的边界4.1 步骤分类背后是协议栈分层TMA 的测试步骤不是随意堆出来的按协议栈从底到顶分Layers 1/2 管物理层、MAC、RLCChannel 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 与 MeasurementSystem Control 负责测试终端的全局状态比如复位、射频开关、同步源选择。参数常见就三个Reset 类型、RF on/off、等待同步时间。Script Control 负责循环、条件跳转、等待和失败处理它把一串静态步骤变成有逻辑的脚本。例如“等待 Attach 完成超时 30 秒则跳失败处理”在脚本里显式加“失败后抓取当前测量并保存”比跑完再猜要高效得多。Measurement 本身不产生测试动作只负责启动测量、停止测量、读取结果、保存结果。启动测量时选组 ID 和类别 ID这和附录 A 的 Group/Category ID 表对应。三个类别组合起来几乎能覆盖任何用例的基本骨架系统控制负责干净起点脚本控制负责随时序变化测量负责结果记录。其它类别更像是具体的业务动作按需插入就行。步骤类别典型参数用途示例System ControlReset type, RF state, sync source用例开头复位终端Script ControlCondition, Timeout, Jump target等待事件、失败跳转MeasurementGroup ID, Category ID, Trigger启动自动测量并记录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 的三角关系RCIRemote Control Interface是 TMA 对外提供的远程控制通道。测试终端硬件、运行 TMA 的控制电脑和自动化主控三者通过它串起来主控连到 TMATMA 控制终端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 bREADY in buf: break return buf.decode(ascii, errorsreplace) # 连接 TMA 的 RCI 端口端口以本机 Connection 偏好为准 sock socket.create_connection((127.0.0.1, 9000), timeout5) # 先清空测量组 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”的最小闭环再往上加业务步骤。如果你也要搭类似的过夜跑批建议先把这条闭环跑通再谈效率和报表。希望帮到你。本文还有配套的精品资源点击获取
