第二章：测试环境搭建——仪表连接、自动化框架部署与DUT配置

做高速网络芯片测试，环境搭建是第一步，也是最容易踩坑的一步。我见过太多团队，芯片设计得不错，结果测试环境搭得稀里糊涂，最后数据根本没法看。说白了，测试环境就是你的“战场”，战场没布置好，仗怎么打？

这一章，咱们就聊聊怎么把测试仪表（IXIA/Spirent）连好、自动化框架（Python + Robot Framework）部署起来、以及DUT怎么配置。嗯，都是实打实的经验。

2.1 测试仪表连接：IXIA与Spirent的物理链路

先说说仪表。IXIA和Spirent是两大主流，用法大同小异。我个人习惯用IXIA多一些，但Spirent在某些场景下更顺手。不管用哪个，物理连接是基础。

2.1.1 物理连接要点

  • 光模块选择：高速测试（比如100G/400G）必须用对应速率的光模块。我曾经遇到过用10G模块插在100G端口上，结果仪表死活不亮——嗯，低级错误，但真有人犯。
  • 线缆质量：高速信号对线缆很敏感。建议用原厂线缆，或者至少是经过认证的。我见过用普通跳线跑400G，误码率直接飙到10⁻⁶。
  • 时钟同步：多端口测试时，时钟必须同步。IXIA和Spirent都支持外部时钟输入，或者用仪表内部的时钟分配模块。不同步的话，抓包时间戳全是乱的。
⚠️ 注意： 仪表端口的光功率不能超过接收端阈值。我曾经有一次没注意，直接把高功率光信号怼进DUT，结果DUT的PHY芯片烧了……从那以后，我每次上电前都会用光功率计测一遍。

2.1.2 仪表配置步骤（以IXIA为例）

  1. 打开IXIA的IxNetwork软件，创建新配置。
  2. 添加端口，选择对应的物理端口号。
  3. 配置端口速率（比如100G）、FEC模式（RS-FEC或Firecode）。
  4. 设置IP地址和MAC地址（用于控制面通信）。
  5. 启动端口，检查Link状态。
# 用Python脚本控制IXIA（IxNetwork API示例）
from ixnetwork_restpy import SessionAssistant

session = SessionAssistant(IpAddress='192.168.1.100', 
                           UserName='admin', 
                           Password='admin',
                           LogLevel='INFO')
ixnetwork = session.Ixnetwork

# 添加端口
port = ixnetwork.Vport.add(Name='Port1')
port.Assign(Location='192.168.1.200/1/1')  # 机框/槽位/端口

# 配置速率
port.L1Config.CurrentType = 'ethernet'
port.L1Config.Ethernet.EnableAutoNegotiation = False
port.L1Config.Ethernet.Speed = 'speed100g'
port.L1Config.Ethernet.FecMode = 'rsFec'

# 启动端口
port.Start()
💡 小技巧： 用REST API控制仪表比传统TCL脚本方便多了。我现在的项目全是Python + REST，调试效率翻倍。

2.2 自动化测试框架部署：Python + Robot Framework

手动测试？不存在的。高速网络芯片测试，动辄几千个用例，不用自动化根本跑不完。我推荐Python + Robot Framework的组合，原因很简单：Python灵活，Robot Framework可读性强，团队里新人也能看懂。

2.2.1 环境安装

# 安装Python 3.8+（推荐3.10）
# 安装Robot Framework和相关库
pip install robotframework
pip install robotframework-requests  # 用于HTTP API测试
pip install robotframework-sshlibrary  # 用于SSH连接DUT
pip install robotframework-pabot  # 并行执行

# 安装IXIA/Spirent的Python库
pip install ixnetwork-restpy  # IXIA
pip install spirent-testcenter  # Spirent（需从官网下载）

2.2.2 项目结构

我个人习惯这样组织目录：

test_project/
├── testcases/          # 测试用例（.robot文件）
│   ├── 01_link_test.robot
│   ├── 02_throughput_test.robot
│   └── 03_packet_loss_test.robot
├── resources/          # 关键字库（.resource文件）
│   ├── common_keywords.resource
│   └── dut_config.resource
├── libraries/          # Python自定义库
│   ├── ixia_lib.py
│   └── dut_lib.py
├── config/             # 配置文件
│   ├── dut_config.yaml
│   └── testbed.yaml
└── results/            # 测试报告

2.2.3 一个简单的测试用例

*** Settings ***
Library    ../../libraries/ixia_lib.py
Library    ../../libraries/dut_lib.py
Resource   ../resources/common_keywords.resource

*** Variables ***
${IXIA_IP}      192.168.1.100
${DUT_IP}       192.168.1.10
${PORT1}        1/1
${PORT2}        1/2

*** Test Cases ***
验证100G链路建立
    [Documentation]    测试DUT与IXIA之间100G链路是否正常建立
    Connect To IXIA    ${IXIA_IP}
    Configure Port    ${PORT1}    speed=100g    fec=rsFec
    Configure Port    ${PORT2}    speed=100g    fec=rsFec
    Start Ports    ${PORT1}    ${PORT2}
    Wait Until Keyword Succeeds    10s    1s    Check Link Status    ${PORT1}    up
    Wait Until Keyword Succeeds    10s    1s    Check Link Status    ${PORT2}    up
    [Teardown]    Disconnect From IXIA
📌 核心思路： 把仪表操作封装成Python库，Robot Framework只负责调用。这样测试用例写起来像自然语言，维护也方便。

2.3 DUT配置：从命令行到自动化

DUT（Device Under Test）配置是测试环境里最灵活的部分。不同芯片的配置方式千差万别，但核心思路是一样的：通过某种接口（SSH、串口、网管协议）把配置下发到芯片。

2.3.1 常见配置方式

方式 适用场景 优点 缺点
SSH + CLI 大多数交换芯片 通用性强，调试方便 速度慢，批量配置效率低
RESTCONF/NETCONF 支持YANG模型的芯片 标准化，可编程 学习曲线陡
寄存器直接读写 芯片验证阶段 最底层，控制力最强 容易出错，需要芯片手册
厂商SDK 特定芯片（如Broadcom） 封装好，功能全 依赖厂商，不通用

我个人最常用的是SSH + CLI，原因很简单：几乎所有芯片都支持，而且调试时可以直接敲命令看效果。但要注意，CLI的解析很麻烦，不同厂商的输出格式不一样。

2.3.2 自动化配置DUT的Python示例

# dut_lib.py
import paramiko
import time

class DUTConfig:
    def __init__(self, ip, username, password):
        self.client = paramiko.SSHClient()
        self.client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
        self.client.connect(ip, username=username, password=password)
    
    def send_command(self, cmd, timeout=5):
        stdin, stdout, stderr = self.client.exec_command(cmd, timeout=timeout)
        return stdout.read().decode('utf-8')
    
    def configure_interface(self, interface, speed, fec):
        # 假设DUT是类似Cisco的CLI
        cmds = [
            f"configure terminal",
            f"interface {interface}",
            f"speed {speed}",
            f"fec {fec}",
            f"no shutdown",
            f"end"
        ]
        for cmd in cmds:
            self.send_command(cmd)
            time.sleep(0.5)  # 给DUT一点处理时间
    
    def close(self):
        self.client.close()
⚠️ 避坑指南： 我曾经在配置DUT时，连续发了10条命令，结果DUT的CPU直接100%卡死了。后来我加了个延时，每条命令之间等0.5秒，问题解决。高速芯片的控制面CPU其实很弱，别把它当服务器用。

2.4 知识体系总览

下面这张图，是我对本章内容的总结。你想想看，测试环境搭建其实就三块：仪表、自动化框架、DUT。三者连起来，才能跑通一个完整的测试。

测试环境搭建知识体系 测试仪表连接 IXIA / Spirent 自动化框架部署 Python + Robot Framework DUT配置 SSH / RESTCONF / 寄存器 物理连接（光模块/线缆） 端口配置（速率/FEC） REST API控制 环境安装（pip） 项目结构组织 测试用例编写 SSH/CLI配置 RESTCONF/NETCONF 寄存器读写 三者联动 → 完整的自动化测试环境

2.5 常见问题与避坑

最后，分享几个我实际项目中遇到的坑：

  • 仪表端口冲突：多个人同时用同一台仪表，端口分配乱了。建议用仪表自带的资源锁功能，或者自己写个简单的分配脚本。
  • DUT配置不生效：有时候命令发出去了，但芯片没反应。原因可能是配置需要commit，或者需要重启某个模块。我习惯在配置完后，用show命令确认一下。
  • 自动化脚本超时：高速测试中，某些操作（比如流量发送）可能耗时较长。记得在Robot Framework里设置合适的超时时间，别让脚本傻等。
💡 我的经验： 测试环境搭建完成后，先跑一个最简单的“链路建立+发送一个包”的用例，验证整个链路通不通。这叫“冒烟测试”，能帮你快速发现环境问题，而不是等到跑几百个用例后才崩溃。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →