3. 链路测试概述：测试目的、范围与环境搭建
链路测试是 Session 建立与 Online 状态切换验证的基础环节。本章从测试目的、测试范围、测试环境搭建三个维度，建立链路测试的全局视图，为后续各场景的详细测试用例设计提供统一的框架和前置条件。
3.1 链路测试的目的
链路测试的核心目标是在受控条件下验证 Session 建立与 Online 状态切换的端到端正确性、稳定性和性能表现。具体目的包括：
- 功能正确性验证：确认协议栈在正常流程、异常流程、边界条件下均能按规范完成 Session 建立与状态切换。
- 状态机一致性校验：验证被测设备（DUT）的状态迁移路径与协议定义的状态机完全一致，无非法跳转或状态滞留。
- 互操作性确认：确保不同厂商、不同协议版本、不同网络环境下的设备能够成功建立 Session 并维持 Online 状态。
- 性能基线建立：获取 Session 建立时延、Online 状态切换耗时、并发处理能力等关键性能指标，作为后续优化和回归的基准。
- 异常恢复能力评估：验证网络中断、协议超时、资源耗尽等异常场景下，Session 能否自动恢复或优雅降级。
关键提示： 链路测试不是简单的“通断测试”，而是覆盖协议交互全生命周期的系统性验证。测试目的必须与产品需求文档（PRD）和协议规范逐条对齐。
3.2 测试范围
链路测试的范围从纵向和横向两个维度进行划分，确保测试覆盖无盲区。
3.2.1 纵向范围：协议层级
| 协议层级 | 测试内容 | 典型关注点 |
|---|---|---|
| 传输层 | TCP/UDP 连接建立、TLS 握手、Keep-Alive 机制 | 连接超时、重传策略、端口可达性 |
| 会话层 | Session ID 分配、会话密钥协商、状态同步 | Session 唯一性、密钥更新、状态一致性 |
| 应用层 | Online 状态注册、心跳维持、状态切换信令 | 状态切换时延、心跳间隔、状态广播范围 |
3.2.2 横向范围：测试场景分类
- 正常流程场景：标准 Session 建立、Online 状态注册、状态保持、正常注销。
- 异常流程场景：网络闪断、协议超时、重复 Session 请求、非法消息格式。
- 边界条件场景：最大并发 Session 数、最小/最大心跳间隔、超长 Session ID、空载荷消息。
- 性能压力场景：批量 Session 建立、高频状态切换、长时间稳定性运行。
- 互操作场景：跨厂商设备对接、不同协议版本兼容、异构网络桥接。
建议： 测试范围应形成矩阵表格，横轴为协议层级，纵轴为测试场景，交叉点即为具体的测试用例。建议使用 Excel 或测试管理工具维护此矩阵，确保每个交叉点至少有一个正向用例和一个反向用例。
3.3 测试环境搭建要求
测试环境的搭建直接影响测试结果的可靠性和可复现性。以下从硬件、软件、网络、工具四个维度提出具体要求。
3.3.1 硬件环境要求
| 设备类型 | 最低配置 | 推荐配置 | 数量要求 |
|---|---|---|---|
| 被测设备（DUT） | 4 核 CPU / 8 GB RAM / 100 GB 磁盘 | 8 核 CPU / 16 GB RAM / 256 GB SSD | 至少 1 台 |
| 测试仪表/模拟器 | 支持 1000 并发连接 | 支持 10000 并发连接 + 协议定制能力 | 至少 1 台 |
| 网络交换机 | 千兆端口 / 支持 VLAN | 万兆端口 / 支持流量镜像 / 低延迟 | 至少 1 台 |
| 时间同步服务器 | NTP 协议支持 | GPS 授时 / PTP 精确时间协议 | 1 台（可选） |
3.3.2 软件环境要求
- 操作系统：DUT 与测试仪表使用统一的操作系统版本（如 Ubuntu 22.04 LTS 或 CentOS 7.9），避免因系统差异引入干扰。
- 协议栈版本：明确被测协议栈的版本号（如 SIP v2.0 / WebSocket RFC 6455），测试过程中不得随意升级或降级。
- 测试工具：推荐使用 Wireshark（抓包分析）、JMeter（性能测试）、自定义脚本（Python/scapy 构造异常报文）。
- 日志系统：DUT 需开启全量协议日志，日志级别设置为 DEBUG，日志文件按时间戳自动轮转。
3.3.3 网络环境要求
- 网络拓扑：采用星型拓扑，DUT 与测试仪表直连或通过一台交换机连接，避免中间设备引入额外延迟或丢包。
- IP 地址规划：使用独立的测试网段（如 192.168.100.0/24），确保与生产网络隔离。
- 延迟与丢包模拟：使用 tc（Traffic Control）或网络损伤仪模拟不同延迟（10ms / 50ms / 200ms）和丢包率（0.1% / 1% / 5%）。
- 防火墙规则：关闭或配置白名单，确保测试流量不被防火墙拦截或修改。
3.3.4 测试工具链要求
| 工具类别 | 推荐工具 | 用途 |
|---|---|---|
| 协议模拟器 | SIPp / IxLoad / 自研模拟器 | 模拟大量客户端并发建立 Session |
| 抓包分析 | Wireshark / tcpdump | 捕获协议交互报文，分析时序与内容 |
| 性能监控 | Prometheus + Grafana / nmon | 监控 DUT 的 CPU、内存、网络连接数 |
| 自动化测试 | Robot Framework / pytest | 编写可重复执行的测试用例 |
| 异常注入 | scapy / netem / Chaos Monkey | 构造畸形报文、模拟网络故障 |
注意： 测试环境搭建完成后，必须执行环境验证测试（Smoke Test），确认 DUT 与测试仪表之间的基本通信正常、抓包工具可捕获到预期报文、日志系统正常输出。环境验证不通过，不得开始正式测试。
3.4 链路测试总体架构
下图展示了链路测试的总体架构，包括测试仪表、DUT、网络损伤层、监控与分析工具之间的交互关系。
3.5 环境搭建检查清单
为降低环境搭建遗漏风险，建议使用以下检查清单逐项确认：
| 检查项 | 验收标准 | 状态 |
|---|---|---|
| DUT 网络连通性 | DUT 与测试仪表之间 ping 通，延迟 < 1ms（直连） | ☐ 通过 / ☐ 未通过 |
| 协议端口可达 | telnet/nc 测试目标端口（如 5060/443）返回正常 | ☐ 通过 / ☐ 未通过 |
| 抓包工具可用 | tcpdump 或 Wireshark 可捕获到 DUT 与仪表之间的报文 | ☐ 通过 / ☐ 未通过 |
| 日志输出正常 | DUT 日志文件持续写入，无磁盘空间告警 | ☐ 通过 / ☐ 未通过 |
| 时间同步 | DUT 与测试仪表时间偏差 < 100ms | ☐ 通过 / ☐ 未通过 |
| 网络损伤配置 | tc 规则生效，延迟/丢包符合预期 | ☐ 通过 / ☐ 未通过 |
| 性能监控就绪 | Prometheus 可采集 DUT 指标，Grafana 面板正常显示 | ☐ 通过 / ☐ 未通过 |
最佳实践： 将检查清单制作为 Shell 脚本或 Ansible Playbook，实现环境搭建的自动化验证。每次环境变更后，重新执行检查脚本，确保环境状态可追溯。