SD-WAN 试用期间应该测试什么？一份可执行的验收清单

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

摘要： 本文围绕 SD-WAN 试用阶段如何科学验收展开，指出单次测速结果不能代表真实网络质量。文章从建立业务基线、核心网络指标（延迟、抖动、丢包、吞吐量）测试、实际业务体验验证、主备切换与故障告警测试、多时段多地点对照测试五个方面给出可执行方法，并整理了一份 15 项验收清单与测试记录模板，最后说明如何结合约定指标判断试用是否通过验收。核心观点是：SD-WAN 试用应重点验证业务连续性与真实使用体验，而不是只看测速数字。

企业在选择 SD-WAN 方案时，通常会安排一段试用时间，用来验证网络质量、业务访问效果以及故障处理能力。

但实际试用过程中，不少企业容易陷入一个误区：测速软件显示延迟降低了，网页打开速度也快了一些，就认为网络优化已经达标。

事实上，单次测速结果并不能代表真实的网络质量。

SD-WAN 的价值不仅体现在延迟、丢包等基础指标上，还包括链路稳定性、主备切换、故障告警、业务连续性以及不同办公地点之间的访问表现。

如果试用期间没有明确的测试目标和验收标准，即使网络确实有所改善，也很难判断改善幅度是否符合预期。

那么，SD-WAN 试用期间应该测试什么？企业又应该如何判断测试结果是否合格？

本文整理了一份可以直接执行的 SD-WAN 试用验收清单，帮助企业在试用阶段完成网络质量和实际业务表现的综合评估。

一、测试之前：先建立业务基线

在正式测试 SD-WAN 之前，首先要明确企业目前的网络状况。

如果没有原始数据作为对照，即使试用期间测出了延迟、丢包和访问速度，也很难判断网络究竟改善了多少。

建议在试用开始前，先记录现有网络的基础表现。

1. 明确需要测试的业务系统

不要只测试一个普通网站，而应该选择企业日常工作中真正依赖的业务系统。

例如：

• ERP、CRM 等企业管理系统。
• Shopify 等电商后台。
• 海外云平台及 SaaS 应用。
• 视频会议和远程协作工具。
• 文件上传、下载及数据同步业务。
• 社交媒体运营和广告管理平台。

不同业务对网络的要求并不相同。

例如，视频会议对延迟和抖动比较敏感，文件传输更关注吞吐量和持续稳定性，而 ERP 系统除了网络连接质量，还需要关注页面响应时间和业务操作耗时。

因此，测试目标应该围绕企业的实际业务来确定。

2. 记录试用前的网络数据

建议至少记录以下内容：

这里需要注意，测速结果应该尽量在相同测试目标、相同设备和相近网络负载条件下采集。

例如，上午网络空闲时测出的数据，不能直接与晚上业务高峰期的数据进行简单比较。

二、核心网络指标：延迟、抖动、丢包和吞吐量

完成基础数据记录后，就可以进入 SD-WAN 的核心网络质量测试。

1. 延迟测试

延迟通常指数据从发送端到接收端所经历的传输时间。

延迟越高，通常意味着网络响应越慢。

测试方法：

可以使用 Ping 工具，对企业实际访问的目标地址进行连续测试。

Windows 系统可以使用：

ping 目标IP -n 100

Linux 系统可以使用：

ping -c 100 目标IP

建议连续采集至少 100 个数据包，记录平均延迟、最大延迟以及延迟波动情况。

测试时需要注意：

• 测试目标应该尽量接近实际业务服务器。
• 同时记录不同办公地点的测试结果。
• 分别测试工作时间和业务高峰期。
• 不要只使用一个公共测速地址作为判断依据。

判定方式： 将试用前后的平均延迟和波动情况进行对照，判断是否达到双方约定的延迟目标。

2. 抖动测试

抖动是指网络延迟在不同数据包之间发生的变化。

例如，连续几次数据包的延迟分别为 30ms、32ms、31ms 和 85ms，虽然平均延迟可能不算太高，但明显存在较大的波动。

这种情况可能影响视频会议、语音通话和实时协作业务。

测试方法：

可以通过支持 RTP 或网络质量检测的工具，采集连续数据包的延迟变化情况。

也可以使用支持 UDP 测试的网络测量工具进行测试。

判定方式： 记录平均抖动、最大抖动以及高峰期的变化情况，并与试用前的数据及约定阈值进行比较。

3. 丢包率测试

丢包是指数据包在传输过程中没有成功到达目标端。

丢包可能导致网页加载异常、远程连接卡顿、视频会议断续等问题。

测试方法：

可以使用 Ping 连续发送数据包，观察发送数量与接收数量之间的差异。

例如，发送 1000 个数据包，收到 995 个，则丢包率为：

丢包率 =（发送数量 – 接收数量）÷ 发送数量 × 100%

需要注意，ICMP 测试结果不一定完全等同于实际业务流量的丢包情况，因为部分设备可能对 ICMP 报文进行限速或过滤。

因此，对于重要业务，建议结合 TCP、UDP 或实际应用测试进行综合判断。

判定方式： 关注平均丢包率、连续丢包情况以及高峰期丢包表现，而不是只看一次测试结果。

4. 吞吐量测试

吞吐量反映网络在一定时间内实际传输的数据量。

对于需要上传文件、同步数据、下载资源的企业来说，这项指标同样重要。

测试方法：

可以使用 iPerf3 等工具，在可控的测试环境中进行 TCP 或 UDP 吞吐量测试。

也可以通过企业实际文件上传和下载任务，观察单位时间内的传输速度。

测试时需要注意：

• 测试服务器的性能不能成为瓶颈。
• 尽量保持测试终端和测试目标一致。
• 区分单线程与多线程测试结果。
• 同时记录上传和下载方向的数据。

判定方式： 比较试用前后的实际吞吐量，并确认是否满足企业业务所需的带宽。

三、实际业务测试：不能只看测速软件

基础网络指标合格，不代表业务体验一定良好。

因为用户访问一个业务系统，需要经过 DNS 解析、连接建立、数据传输、应用处理等多个环节。

其中任何一个环节出现问题，都可能影响最终体验。

建议至少安排以下业务测试：

建议每个场景至少重复测试 3～5 次，尽量排除偶发因素。

例如，测试 ERP 系统时，不要只记录登录页面是否能够打开，还应该测试查询数据、提交表单以及切换业务模块的耗时。

如果基础网络指标有所改善，但业务系统依然响应缓慢，就需要进一步判断问题是否来自服务器性能、数据库处理或应用自身。

验收重点： 网络指标改善与实际业务体验改善应该分别记录，不能用其中一项替代另一项。

四、主备切换测试：验证故障发生时能否正常恢复

主备切换是 SD-WAN 试用期间非常重要的一项测试。

企业网络不能只在正常运行时表现良好，还需要验证链路发生故障后，系统能否及时发现异常并按照预设策略进行切换。

建议重点测试以下几个方面。

1. 主链路故障测试

在经过授权并确认不会影响生产业务的测试环境中，可以模拟主链路中断。

观察以下内容：

• 系统是否能够识别主链路异常。
• 是否按照策略切换到备用链路。
• 从故障发生到完成切换需要多长时间。
• 切换期间业务是否出现中断。
• 备用链路能否正常承载业务流量。

需要记录故障发生时间、检测时间、切换完成时间和业务恢复时间。

2. 链路恢复测试

主链路恢复后，还需要观察系统是否能够正确识别链路状态。

重点检查：

• 主链路恢复后是否正常上线。
• 是否按照预设策略回切。
• 回切过程中是否出现二次中断。
• 原有业务连接是否需要重新建立。
• 是否存在频繁切换或反复抖动的情况。

需要注意，链路切换成功并不意味着所有业务连接都能无感恢复。

例如，部分 TCP 会话可能因为出口地址变化、NAT 映射变化或应用自身的连接机制而中断，需要重新建立连接。

因此，应该分别记录链路切换时间和业务恢复时间。

3. 故障告警测试

除了切换能力，还要检查系统的故障监控和告警机制。

建议模拟以下情况：

• 主链路断开。
• 网络延迟持续升高。
• 丢包率超过设定阈值。
• 备用链路出现异常。
• 设备离线或连接中断。

观察系统能否及时产生告警，以及告警信息是否包含故障时间、异常对象、故障类型和恢复状态。

验收重点： 故障检测、链路切换、告警通知和业务恢复是四个不同的环节，应该分别测试，不能只凭一条切换成功记录判断整个高可用能力合格。

五、多时间段、多地点测试：避免单次测试产生误判

网络质量会受到线路负载、运营商路由、设备状态和业务访问量等因素影响。

因此，建议企业不要只在某一个时间段、某一个办公地点进行测试。

1. 不同时间段测试

建议选择三个典型时间段：

• 上午：业务刚开始运行时。
• 下午：正常业务运行时。
• 晚间：网络使用高峰期。

如果企业存在特定的业务高峰，例如海外客户集中访问时段，也应该将其纳入测试范围。

每个时间段记录延迟、抖动、丢包和实际业务响应情况。

2. 不同办公地点测试

如果企业有多个分支机构，建议至少选择总部和两个具有代表性的分支进行测试。

重点比较：

• 不同地点访问同一业务系统的表现。
• 不同地点的网络延迟和丢包情况。
• 不同分支之间的数据传输表现。
• 是否存在某个地点持续出现网络异常。

这样可以判断 SD-WAN 是否真正改善了多办公地点的网络访问体验，而不是只优化了某一个测试点。

3. 试用前后对照

所有测试都应该尽量保持条件一致。

例如，同一台电脑、同一个业务系统、相同的测试文件、相近的网络负载和相同的测试时间。

如果测试条件发生变化，需要在记录中明确说明，避免将测试环境变化误认为网络优化效果。

六、SD-WAN 试用验收清单：可以直接照着执行

前面的内容主要介绍了测试方法，下面将其整理为一份实际验收清单。

企业可以在试用期间逐项完成，并记录测试结果。

建议采用的测试记录模板

每次测试都建议保留以下信息：

建议将试用前、试用中和试用后的测试数据保存在同一份记录中，方便后续横向对比。

七、如何判断 SD-WAN 试用是否通过验收？

完成所有测试后，企业需要根据测试结果做出综合判断。

这里不建议直接采用一套固定的延迟、丢包或切换时间标准来判断所有企业的 SD-WAN 是否合格。

因为不同企业的业务类型、访问目标、网络环境和 SLA 要求存在差异。

更合理的方式，是在试用开始前与服务提供方确认具体的验收指标。

例如：

最终可以将测试结果划分为三种情况：

通过验收： 核心业务、网络质量、故障切换和监控能力均达到事先约定的要求。

有条件通过： 大部分指标符合要求，但个别项目存在偏差，需要明确整改时间和复测方案。

未通过验收： 核心业务访问不稳定、关键指标持续不达标，或者故障切换及恢复能力无法满足企业要求。

对于未通过的项目，应该保留测试证据，明确问题发生的时间、地点、影响范围和具体表现，再进行针对性整改。

八、总结：SD-WAN 试用，重点是验证业务而不是只看测速

企业进行 SD-WAN 试用，不能简单地把测速结果当成最终验收依据。

延迟、抖动、丢包和吞吐量能够反映基础网络质量，但企业真正关心的，是 ERP 能不能正常使用、海外 SaaS 是否流畅、文件传输是否稳定，以及链路出现故障后业务能否及时恢复。

因此，一次完整的 SD-WAN 试用，至少应该覆盖三个方面：

第一，基础网络指标是否达到预期。

第二，核心业务在真实使用场景下是否有所改善。

第三，链路故障、告警和恢复机制是否符合企业的连续性要求。

对于企业而言，试用不是简单地体验一下网络，而是一次正式的技术验证。只有建立测试基线、明确验收指标、保留测试记录，并通过多地点、多时段的对照测试，才能真正判断一套 SD-WAN 方案是否适合自身业务。