PAYATHON 2026

如何自动化测试 Amazon Connect 的 IVR 通话流程？

数据阿明

可以用开源 SIP 工具搭建 Amazon Connect IVR 自动化测试系统。自研功能回归工具时，可以考虑 PJSIP/PJSUA2；需要批量生成 SIP 呼叫、测试信令和发送 DTMF 时，可以考虑 SIPp。完整验证需要结合呼叫驱动、音频检查和 Amazon Connect 侧的路由证据。

先确定测试覆盖的范围

测试至少要分别确认：

  • 提示是否正确：用户实际听到的内容是否符合预期，有没有漏播、截断或长时间静音。
  • 输入是否生效：发送 DTMF 后，流程是否进入正确分支，非法输入和超时是否得到处理。
  • 路由是否正确：呼叫是否进入预期队列，必要时是否由预期测试坐席接听。

语音转写匹配可以帮助判断提示内容，但不能单独证明音频清晰，也不能证明呼叫已进入正确队列。

如果可以接受 AWS 托管能力，也可以先评估 Amazon Connect 的测试与模拟功能。官方文档提供 Voice call 测试用例配置，以及基于 observe、check 和 action 的交互设计。它不是开源方案，使用前应确认所在实例的功能可用性和测试覆盖范围；模拟流程通过后，仍应按需求安排真实电话链路验证。AWS 测试用例文档

开源工具如何选择

工具适合承担的工作需要补充的部分
PJSIP/PJSUA2编程控制 SIP 通话、发送 DTMF、接收并录制音频用例调度、提示识别、路由断言和结果报告
SIPp按场景生成 SIP 呼叫、发送 DTMF、进行信令与并发测试提示内容识别、音频质量分析和业务断言

PJSUA2 提供通话音频媒体对象和 WAV 录音能力，适合构建测试客户端，逐步等待提示、输入按键并检查响应。DTMF 接口和发送方式应按实际采用的版本确认。PJSUA2 音频文档、DTMF 文档

SIPp 支持 RTP 媒体相关操作、PCAP 回放和 DTMF 生成，但其媒体支持有明确边界，不能把它当成现成的语音内容验收工具。SIPp 媒体文档

自研工具的实现步骤

1. 先打通真实呼入链路

对于绑定电话号码的呼入 IVR，可以采用以下测试路径：

测试执行器
  → SIP 客户端
  → 支持拨打目标号码的 SIP trunk 或电话网关
  → Amazon Connect 测试号码
  → 待测 flow

SIP 客户端需要有可用的电话接入路径，不能仅凭 Amazon Connect 实例地址就假定能够直接建立 SIP 通话。先完成一次低并发通话，确认双向音频和 DTMF 都能通过整条链路。

如果测试对象是外呼流程，可以评估 StartOutboundVoiceContact，由 Amazon Connect 呼叫测试端并执行指定 flow。该 API 发起的是外呼，不能据此认定已覆盖电话号码绑定的完整呼入路径。StartOutboundVoiceContact API

2. 使用有超时的状态机驱动用例

每个测试步骤都应包含触发条件、动作、预期结果和截止时间。例如：等待欢迎提示、发送 1、验证后续提示、确认目标队列。

尽量根据音频或流程事件推进测试。固定等待几秒容易受到接通延迟、提示长度和后端响应时间的影响。

下面是编排伪代码，其中的方法属于自研适配层，不是 Amazon Connect 或 PJSUA2 的现成 API；提示、队列和超时值均为示例：

async def test_menu_route(driver, evidence):
    call = await driver.dial("<CONNECT_TEST_NUMBER>")
    try:
        await call.wait_connected(timeout=30)
        await call.expect_prompt(
            "欢迎致电测试服务", timeout=15
        )
        await call.send_dtmf("1")
        await call.expect_prompt(
            "正在为您转接", timeout=15
        )
        contact = await evidence.resolve_contact(call)
        await evidence.expect_queue(
            contact, "<EXPECTED_QUEUE_ARN>", timeout=30
        )
    finally:
        await call.hangup()

resolve_contact 需要将测试端呼叫标识可靠地关联到 Amazon Connect 的 ContactId。可以结合测试号码、时间窗口和可用的关联属性建立映射；并发测试时，不能仅按时间接近就认定是同一通话。

3. 同时检查用户听到的内容和服务端执行结果

在测试端采集接收音频，验证真实听感路径：

  • 固定提示可以与参考音频对齐并比较相似度，比较前统一采样率与音频格式。
  • 动态提示可以使用语音识别，再核对关键字段、文本和出现顺序。
  • 静音时长、截断和音量异常需要单独设置检查，阈值应通过正常样本校准。

不要用音频文件哈希判断提示是否一致，电话链路的编码转换和时序差异会影响文件内容。

在 Amazon Connect 侧，启用实例 flow logging，并在流程中设置 Set logging behavior。flow logs 包含 contact ID，可用于关联流程执行记录。AWS flow logs 文档

路由断言应结合可用的 flow logs、联系记录或联系事件检查目标队列。如果要求验证坐席接听，还需要受控测试坐席及相应的接通证据。仅听到“正在转接”不足以判定路由成功。

回归测试需要覆盖哪些情况

先覆盖正常菜单路径，再加入非法按键、不输入、重复输入、连续输入、提前按键、后端超时，以及队列无可用坐席等场景。DTMF 的发送方式、按键时长和间隔需要与实际链路匹配，并验证跨网关后仍能被流程识别。

每次执行保留用例标识、流程版本、ContactId、时间戳、测试端录音和失败步骤。CI 中可以先运行少量关键路径，将并发和容量测试单独安排。开源软件之外，电话号码、电话链路、Amazon Connect 使用和日志存储仍可能产生费用。

备注：内容仅供参考。