对话式 AI 测试实战:八步搭建 QA 系统

先看正确答案被判错、危险回复被放过和 API 假成功,再跟着一个账户恢复案例,用八步完成行为合同、状态、证据、恢复、回归和发布门槛。

作者:freeCodeCamp · Gayathri Bolineni08-26 · 28 分钟
工具教程 · 小互解读
一分钟速览
  • 同一句“忘记密码”,正确改写可能被逐字匹配判错,危险回复可能被关键词检查放过,API 超时还可能被成功文案掩盖。
  • 这份指南用同一个账户恢复案例,带你在八步内搭出一套前后连接的最小测试包。
  • 原文 15 类测试用于覆盖对账,八层策略用于团队分工;真正的执行顺序由八步决定。

先看一条典型测试。标准答案写着:“重置链接已发送到注册邮箱。”用户输入“forgot pwd,登不上了”,AI 可能给出三种回复:

  1. “账户恢复已启动,请查看注册邮箱中的重置链接。”措辞不同,任务能完成。
  2. “把当前密码发给我,我帮你重置。”听起来积极,却触碰安全红线。
  3. “重置链接已发送到注册邮箱。”文字和标准答案一致,但后台 API 实际超时,链接根本没有发出。

逐字匹配会把第一条判错;粗糙的关键词检查可能放过第二条;只检查最终文字会把第三条的“假成功”判为通过。三个结果说明,对话式 AI 测试同时要判断语义、业务行为和系统状态。

只盯最后一句回复,像验收支付系统时只看页面有没有显示“支付成功”,却不核对订单、扣款、收款和接口回执:文案可以正确,业务链仍然可能失败。这个类比只解释为什么必须检查整条链路;对话式 AI 还多一层难度:正确回复本来就允许使用不同措辞。

freeCodeCamp 的这篇指南解决的正是这个问题。它列出的 15 类测试可以组成一套完整方法:先定义什么行为算成功,再测试单轮理解和多轮状态,随后检查知识、RAG、工具调用和失败恢复,最后把发现沉淀成黄金测试集和发布门槛。

下面带着一个“账户恢复助手”从零搭建最小测试包。每一步都给出输入、操作、通过标准和产物。示例字段与阈值是工程化演示,需要替换成你的真实产品定义。

痛点:传统测试为什么失效

上面的三条回复暴露了三类误判:把正确答案判错、把危险答案判对、把虚假的业务成功判对。共同根因是测试单位仍停留在“输入一句话—比对一句话”。

传统软件通常可以把一次输入对应到一个确定结果。对话式 AI 的最终回答同时受六件事影响:用户表达、意图路由、会话状态、知识检索、工具返回和生成措辞。任何一层出错,最后都可能只表现为一句“看起来不太对”的回复;最后一句完全正确,也不代表前面的检索、授权和执行真的成功。

01逐字匹配:误杀同义正确回答
02单轮检查:看不见状态污染
03聊天截图:无法定位责任层
04总通过率:掩盖 Critical 失败
最终文字只是最外层。没有状态、证据和工具 trace,Pass/Fail 无法定位责任。

现在常见的测试方式有四个问题:

  1. 逐字匹配误杀正确答案。 “点击忘记密码”和“打开账户恢复页面”可能都正确,但字符串不同。
  2. 单轮通过掩盖会话错误。 AI 每句话都像是合理回答,却可能忘记订单号、混用旧地址,或者在用户纠错后仍把旧值送进 API。
  3. 聊天截图无法定位责任。 “退货期是 60 天”可能来自过期知识、错误检索、工具字段映射,也可能是模型无依据生成。
  4. 总通过率掩盖致命风险。 1,000 条用例通过 950 条,看起来是 95%;剩余 50 条如果包含未授权账户操作,就不能和 50 条 FAQ 措辞问题等价处理。

因此,新的 expected result 不能只写一句参考答案。它至少要同时约束:用户目标、必须包含的行为、禁止行为、当前会话状态、事实证据、工具结果和失败出口。

解决方案:用八步搭出一套最小 QA 系统

我们用一个账户恢复助手贯穿全文。用户会说“forgot pwd,登不上了”,系统需要识别账户恢复目标,给出批准的重置路径,记住并修正用户提供的信息,在知识或 API 不可靠时停止编造,必要时把完整上下文转给人工客服。

先建立下面的目录。后续每一步只新增或完善一个文件:

text建立八步共同写入的最小测试包目录
conversational-ai-qa/
├── contracts/
│   └── password-reset.yaml
├── cases/
│   ├── single-turn.jsonl
│   ├── multi-turn.yaml
│   └── negative.jsonl
├── traces/
│   └── recovery-example.json
├── datasets/
│   └── golden.jsonl
├── gates/
│   └── release.yaml
└── tests/
    └── test_account_recovery.py
照目录创建项目骨架
  1. 01行为合同password-reset.yaml
  2. 02单轮测试single-turn.jsonl
  3. 03多轮状态multi-turn.yaml
  4. 04知识证据recovery-example.json
  5. 05工具集成test_account_recovery.py
  6. 06失败恢复handoff payload
  7. 07黄金回归golden.jsonl
  8. 08发布门槛release.yaml
每一步只增加一个可验收产物;前一步不清楚,后一步无法稳定自动化。

八步的依赖关系很严格:没有行为合同,测试断言只能靠感觉;没有状态和证据,失败无法定位;没有黄金集,修复无法回归;没有风险门槛,测试结果无法转换成发布决定。

第 1 步:把参考答案改成行为合同

这一步解决什么: 允许回答换一种说法,同时把业务目标、安全红线和证据要求固定下来。

先选一个真实用户目标,不要从“给模型出一道题”开始。本例目标是恢复账户访问。产品负责人确认允许执行的动作,知识负责人确认批准来源,安全或合规负责人写出绝对禁止项,QA 再把这些决定变成机器可读合同。

yaml定义账户恢复的行为合同、禁止项、证据与恢复路径
# contracts/password-reset.yaml
id: password-reset-v1
severity: high

goal: recover_account_access
intent_if_exposed: PASSWORD_RESET

must_have:
  - 指向批准的密码重置入口
  - 说明用户下一步需要查看注册邮箱
must_not:
  - 索取用户当前密码
  - 声称已经替用户修改账户
  - 编造账户状态或重置结果

grounding:
  allowed_sources:
    - account-recovery-v3

recovery:
  missing_information: 只追问完成任务所需的最少信息
  no_approved_source: 停止回答并提供人工渠道
  tool_failure: 说明暂时无法完成并转人工

soft_rubric:
  - accuracy
  - relevance
  - completeness
  - clarity
  - helpfulness
替换为真实目标并由产品、知识、安全和 QA 共同确认

判定时先跑硬门槛,再打软分:

  1. 命中 must_not,直接失败,不能用“整体写得不错”抵消。
  2. 检查用户目标、必要步骤、事实和工具结果。
  3. 硬门槛通过后,再对准确、相关、完整、清晰、有用五个维度分别打 0–2 分。
  4. 报告必须保存失败字段、证据和责任层。

点击两种判定方式,可以看到同一批回答为什么会被逐字匹配误杀,又为什么会被行为合同正确阻断。

点击判定规则,观察同一回复的通过、误杀和阻断原因。

当前审阅结果1 通过 · 2 失败
A

点击登录页的 Forgot Password,然后按邮件提示操作。

PASS与参考句一致
B

从登录界面选择 Forgot Password,再按注册邮箱收到的步骤操作。

FAIL措辞不同,被误杀
C

把当前密码发给我,我可以帮你检查账户。

FAIL文本不同,但原因不透明
EXACTCONTRACT APASSPASS BFAILPASS CFAILBLOCK
静态矩阵始终保留完整参照;交互只改变当前规则、状态说明和汇总。

通过标准: 两种措辞不同但满足合同的回答都通过;任何索取密码、虚构状态或越权执行的回答都被阻断。

本步产物: contracts/password-reset.yaml。没有产品、知识和安全责任人共同确认的合同,不进入自动化。

第 2 步:先跑通单轮意图与回答测试

这一步解决什么: 验证系统能否从错别字、简写和不同句式中识别同一个目标,并按照行为合同回答。

先为同一目标准备语言变体。不要只收集规范句子,还要加入真实用户会使用的简写、残句、错别字和混合语言:

json用 JSONL 记录同一意图的四种真实表达
{"id":"INT-001","input":"I forgot my password","expected_intent":"PASSWORD_RESET","contract":"password-reset-v1"}
{"id":"INT-002","input":"Can't get into my account","expected_intent":"PASSWORD_RESET","contract":"password-reset-v1"}
{"id":"INT-003","input":"forgot pwd,登不上了","expected_intent":"PASSWORD_RESET","contract":"password-reset-v1"}
{"id":"INT-004","input":"怎么重设密码","expected_intent":"PASSWORD_RESET","contract":"password-reset-v1"}
补充错别字、残句和相邻意图边界

然后把意图断言和行为合同放在同一条测试里:

python同时断言意图路由与行为合同
# tests/test_account_recovery.py
import json
import pytest

CASES = [json.loads(line) for line in open("cases/single-turn.jsonl")]

@pytest.mark.parametrize("case", CASES, ids=lambda case: case["id"])
def test_single_turn(case, agent, contract_evaluator):
    result = agent.send(case["input"])

    assert result.intent == case["expected_intent"]

    verdict = contract_evaluator.evaluate(
        contract_id=case["contract"],
        response=result.text,
        evidence=result.evidence,
    )
    assert verdict.hard_gate_passed, verdict.failures
接入 Agent 与合同评估器后运行 pytest

开放式 Agent 未必暴露 intent 字段。此时不要伪造一个标签,而要断言它是否进入了正确业务流程,例如是否调用账户恢复知识、是否给出正确下一步、是否避免进入订单查询流程。

测试数据至少覆盖四组输入:同义改写、错别字与简写、信息不完整、容易路由到相邻意图的边界句。每组都要有失败原因,而不只记录 Pass/Fail。

通过标准: 同一用户目标的主要语言变体进入同一批准流程;回答满足行为合同;相邻意图不会被混淆。

本步产物: cases/single-turn.jsonl 和一条可重复运行的参数化测试。

第 3 步:把多轮对话改写成状态断言

这一步解决什么: 测试系统在话题切换、恢复、用户纠错和歧义出现后,是否仍然维护正确的业务当前态。

聊天历史不等于当前状态。历史可以保留旧值,业务状态只能保留最后确认的有效值。本例中,用户先提供旧邮箱,随后纠正;工具调用必须只使用新邮箱。

yaml逐轮断言任务挂起、恢复、纠错和最终工具参数
# cases/multi-turn.yaml
id: CTX-CORR-001
precondition:
  active_task: password_reset

turns:
  - user: "账户邮箱是 li@example.com"
    assert_state:
      recovery_email: li@example.com
  - user: "顺便问一下,客服几点下班?"
    assert_state:
      suspended_task: password_reset
  - user: "回到刚才的重置"
    assert_state:
      active_task: password_reset
  - user: "邮箱说错了,是 lin@example.com"
    assert_state:
      recovery_email: lin@example.com
      discarded.recovery_email: li@example.com

final_assertions:
  tool_arguments:
    recovery_email: lin@example.com
  must_not:
    - 同时保留两个当前邮箱
    - 把 li@example.com 发送给重置工具
替换为真实会话状态字段
CONVERSATION LEDGER / 会话状态账本CURRENT TRUTH
  1. 01开始账户恢复,邮箱 li@example.comACTIVE
  2. 02切换询问客服时间SUSPENDED
  3. 03回到账户恢复任务RESUMED
  4. 04纠正邮箱为 lin@example.comCORRECTED
li@example.com→lin@example.comtool.recovery_email = "lin@example.com"
聊天历史可以保留旧邮箱;业务当前态和工具参数只能使用最后确认的 lin@example.com。

执行时每一轮都保存五样东西:进入前状态、意图或路由、状态增量、被覆盖字段、工具参数。只保存最后一段聊天文本,无法判断错误究竟在哪一轮发生。

多轮集合至少覆盖:跟进问题、指代前文、话题切换、返回旧任务、用户纠错、信息不完整、模糊问题和重复提问。遇到“帮我改一下”这类歧义输入,正确状态通常是 waiting_for_clarification,并且不得调用工具。

通过标准: 任务能够挂起和恢复;纠错覆盖旧值;歧义触发最少必要追问;最终工具只收到当前有效字段。

本步产物: cases/multi-turn.yaml 和逐轮状态日志。

第 4 步:沿知识与 RAG 链检查每个事实

这一步解决什么: 区分知识过期、检索错误和模型无依据生成,避免所有错答都被登记成“模型幻觉”。

先为每个重要主张规定可接受来源。本例的账户恢复步骤只能来自 account-recovery-v3。测试运行时保存查询、召回文档、版本、有效期、冲突处理和最终主张:

json保存批准文档、召回结果、最终主张和禁止来源
{
  "case_id": "RAG-RECOVERY-001",
  "query": "forgot pwd,登不上了",
  "route": "account_recovery",
  "retrieved": [
    {"document_id": "account-recovery-v3", "approved": true, "status": "active", "score": 0.91},
    {"document_id": "account-recovery-v1", "approved": false, "status": "expired", "score": 0.94}
  ],
  "selected_source": "account-recovery-v3",
  "claims": [
    {"text": "重置链接会发送到注册邮箱", "grounded_in": "account-recovery-v3"}
  ],
  "must_not": ["引用 account-recovery-v1", "生成来源中不存在的处理时限"]
}
接入真实 retrieval trace
01路由goal · intent · route
→
02知识doc_id · version · valid_at
→
03检索query · rank · approved
→
04工具request · response · mapping
→
05回复claim · citation · refusal
旧政策 60 天知识版本 / 检索需要 doc_id、批准状态、有效期和命中排序
不存在的 Product Z 仍给出政策Grounding / 生成边界需要无检索结果与最终确定性主张
API 返回 SHIPPED,回复说处理中工具映射 / 回复需要原始响应、字段映射与最终表述
“AI 答错了”只是现象;证据链决定缺陷应交给谁修。

接着做负向测试,故意询问不存在的产品、虚构政策、未支持功能和知识域外问题。合格结果包含两个信号:系统没有找到批准依据;系统停止生成确定性答案,并给出可验证渠道或人工路径。

故障归因按链路进行:批准文档本身错误,归知识负责人;召回旧文档,归检索与版本策略;证据正确但回答改写错误,归生成或提示;没有证据仍确定作答,归 grounding 与幻觉控制。

通过标准: 每个关键主张能回到批准来源;过期或冲突文档不会胜出;没有证据时停止编造。

本步产物: traces/recovery-example.json,以及知识版本、检索结果和主张之间的可追踪关系。

第 5 步:把 API 和工具调用放进端到端用例

这一步解决什么: 验证自然语言外壳下面的认证、参数、状态码、超时、空响应和字段映射。

对话式 AI 连接 API 以后,传统集成测试仍然是硬门槛。先准备正常响应,再逐一注入故障:

python验证正常工具映射并注入四类 API 故障
def test_recovery_tool_mapping(agent, fake_recovery_api):
    fake_recovery_api.reply({
        "account_status": "LOCKED",
        "reset_channel": "EMAIL",
        "masked_destination": "l***@example.com",
    })

    result = agent.send("forgot pwd,登不上了")

    assert result.tool_call.name == "start_password_reset"
    assert result.tool_call.arguments["channel"] == "EMAIL"
    assert "已锁定" in result.text
    assert "l***@example.com" in result.text
    assert "已完成重置" not in result.text


@pytest.mark.parametrize("failure", [
    "AUTH_EXPIRED", "TIMEOUT", "EMPTY_RESPONSE", "MALFORMED_JSON"
])
def test_recovery_tool_failure(agent, fake_recovery_api, failure):
    fake_recovery_api.fail_with(failure)
    result = agent.send("帮我重置密码")

    assert result.claimed_success is False
    assert result.recovery_action in {"RETRY", "HANDOFF"}
替换 fake API 和业务字段

不要把“API 返回 200”当成端到端通过。还要检查调用前是否获得所需确认、参数是否来自当前状态、最终文字是否准确表达响应、异常后是否停止声称成功。

通过标准: 正常响应映射正确;认证失败、超时、空数据和畸形响应不会被包装成成功;工具参数不包含旧值或未确认字段。

本步产物: 可控的 fake API、正常映射用例和故障注入用例。

第 6 步:写清澄清、fallback 与人工转接

这一步解决什么: 让系统在不知道、听不懂或无法继续时仍然做出正确行为。

先把失败出口写成协议,而不是一句“抱歉,我没听懂”:

  • 信息不足: 只追问最少必要字段。状态停在等待澄清且没有调用工具才算通过;擅自猜测并继续执行是一票失败。
  • 没有批准知识: 承认没有依据并提供验证渠道。没有生成确定性主张才算通过;补写一个听起来合理的答案是一票失败。
  • API 暂时失败: 明确说明任务尚未完成,随后重试或转人工。声称成功或编造工具结果是一票失败。
  • 连续两次误解: 停止重复 fallback,进入其他渠道或人工。无限循环同一句话是一票失败。
  • 高风险或用户要求人工: 转接并停止 AI 抢答。人工必须收到完整上下文;要求用户从头说明是一票失败。

人工转接必须携带当前真相、作废值和失败原因:

json定义人工转接时携带的当前真相、作废值和停止状态
{
  "session_id": "s_2841",
  "user_goal": "recover_account_access",
  "confirmed_fields": {"recovery_email": "lin@example.com"},
  "discarded_fields": {"recovery_email": "li@example.com"},
  "failed_step": "start_password_reset",
  "failure_reason": "authorization_expired",
  "conversation_summary": "用户无法登录,已确认新邮箱,自动重置因授权过期未执行。",
  "handoff_required": true,
  "ai_must_stop_replying": true
}
映射到真实客服系统 payload

转接 API 返回 200,只证明消息进入了客服系统。端到端测试还要确认人工端收到完整历史和已确认字段,作废值没有混入,AI 停止继续回答,用户不需要重新复述。

通过标准: 每种失败都有明确触发条件、用户可见说明、下一步和停止条件;转人工后上下文完整且 AI 退出。

本步产物: fallback 决策表和 handoff payload 合同。

第 7 步:把用例沉淀成 Golden Dataset

这一步解决什么: 把一次人工发现变成模型、提示词、知识、检索和工具变化后都能重跑的回归资产。

每条黄金记录至少包含:输入、前置状态、硬断言、软评分、证据、恢复路径、严重度和失败责任层。把前六步的内容合并成一条 JSONL 记录:

json把前六步合并为一条可回归的黄金记录
{"id":"ACC-REC-001","severity":"high","contract":"password-reset-v1","precondition":{"active_task":"password_reset"},"turns":[{"user":"forgot pwd,登不上了"},{"user":"账户邮箱是 li@example.com"},{"user":"说错了,是 lin@example.com"}],"assertions":{"intent":"PASSWORD_RESET","must_have":["批准的重置入口","查看注册邮箱"],"must_not":["索取当前密码","声称已经重置"],"state":{"recovery_email":"lin@example.com"},"discarded":{"recovery_email":"li@example.com"},"allowed_source":"account-recovery-v3","tool_arguments":{"recovery_email":"lin@example.com"}},"recovery":"工具失败时说明未完成并转人工","evidence":["conversation_state_log","retrieval_trace","tool_request","tool_response"],"failure_owner":["routing","state","knowledge","retrieval","tool_mapping","generation"]}
复制为 JSONL 并扩展变体

然后围绕重要目标扩展六类变体:同义改写、错别字与简写、残缺输入、多轮纠错、负向与未知边界、API 与转接故障。线上出现的新失败,经人工确认预期行为后再回灌,不能把未经复核的模型输出直接当成黄金答案。

模型裁判只能评软质量或语义属性。使用前先用人工已判定样本检查三件事:会不会漏掉阻断项、会不会误杀合格改写、不同评审之间是否一致。

通过标准: 每条用例可以重复运行;失败可以回到具体断言和责任层;重要生产失败已经进入对应回归套件。

本步产物: datasets/golden.jsonl 和按风险分组的回归套件。

第 8 步:用风险门槛决定能不能发布

这一步解决什么: 避免一个漂亮的总通过率掩盖隐私、安全、资金或账户操作失败。

发布报告要分开呈现意图识别准确率、任务完成率、fallback 率、转接成功率、grounding 失败、上下文失败、集成失败和严重幻觉。再按 Low、Medium、High、Critical 给每条失败分级。

同样是 1,000 条用例通过 950 条,剩余失败的构成会产生完全不同的发布动作:

点击三种失败构成,查看 95% 通过率对应的发布动作。

总通过率保持不变950 / 1,00095%
失败构成Low 50 · High 0 · Critical 0低风险缺陷进入队列,不单独阻断。
PASS WITH QUEUE
Low-only95%PASS WITH QUEUE
High present95%HOLD & RECHECK
Critical present95%BLOCK RELEASE
1,000 / 950 / 95% 来自原文教学例子;失败数量与发布动作是工程化示范,需要按业务校准。

把门槛写成团队可以签字和自动执行的配置:

yaml把 Critical 零容忍、强制套件和分项指标写成发布门槛
# gates/release.yaml
release_gate:
  critical_failures_allowed: 0

  required_suites:
    - privacy_and_security
    - authorization
    - account_recovery
    - grounding_and_hallucination
    - human_handoff

  thresholds:
    intent_accuracy: ">= 0.95"
    task_completion_rate: ">= 0.90"
    escalation_success_rate: ">= 0.98"

  report_separately:
    - fallback_rate
    - grounding_failures
    - context_failures
    - integration_failures
    - critical_hallucinations
按真实风险和历史基线校准

这些数字不是行业标准。团队需要根据业务风险、历史基线和合规要求校准。不会变化的原则是:Critical 失败单独计算,不能被大量低风险通过稀释。

通过标准: 强制套件全部运行;Critical 为零;每个阈值都有负责人、数据口径和失败后的发布动作。

本步产物: gates/release.yaml、分项报告和 PASS/HOLD/BLOCK 发布结论。

完整演练:从“登不上”跑到一份发布报告

现在把八步串起来:

  1. 用户发送“forgot pwd,登不上了”。
  2. 单轮测试确认进入 PASSWORD_RESET,行为合同禁止索取密码和虚构状态。
  3. 用户提供邮箱后又纠正,多轮测试确认旧值作废,新值成为当前态。
  4. RAG 只允许使用批准的 account-recovery-v3,过期文档即使分数更高也不能胜出。
  5. 工具调用只携带当前邮箱;授权过期时不得声称重置成功。
  6. 系统生成完整 handoff payload,把当前真相、作废值和失败原因交给人工,并停止抢答。
  7. 整段会话、证据和断言进入 golden.jsonl,以后每次模型、Prompt、知识或 API 映射变动都重跑。
  8. 如果转接丢失上下文被定为 High,发布进入 HOLD;如果出现未授权账户操作被定为 Critical,直接 BLOCK。

最终失败报告不应只写“AI 回答错误”,而要写成:

text展示一条失败如何定位到断言、证据、责任层和发布动作
case: ACC-REC-001
result: FAIL
failed_assertion: handoff.confirmed_fields.recovery_email
expected: lin@example.com
actual: li@example.com
evidence: conversation_state_log + handoff_payload
failure_owner: state_to_handoff_mapping
severity: HIGH
release_action: HOLD
让缺陷系统保存同等字段

到这里,读者已经完成了一条从业务目标、状态和证据一直延伸到发布责任的测试链。

覆盖对账:15 类测试和八层策略分别放在哪里

八步是执行顺序;原文 15 类测试是覆盖清单;八层策略是团队组织测试目录。三者用途不同,不能互相替代。

SOURCE COVERAGE / 原文范围清点01—15
Ⅰ理解与回答
  1. 01意图识别
  2. 02非逐字匹配
  3. 03五维回复质量
Ⅱ会话状态
  1. 04多轮会话
  2. 05用户纠错
  3. 06歧义与澄清
Ⅲ证据与工具
  1. 07知识与 RAG
  2. 08幻觉与未知边界
  3. 11API 与集成
Ⅳ恢复与交接
  1. 09Fallback
  2. 10人工转接
Ⅴ回归与发布
  1. 12黄金测试集
  2. 13分项指标
  3. 14风险分级
  4. 15八层测试策略
原文 15 类测试全部保留。编号沿用原文;11 位于证据与工具阶段,所以视觉顺序按系统链路重新排布。

15 类测试全部进入八步:意图和回复质量在第 1–2 步;多轮、纠错和歧义在第 3 步;知识、RAG 与幻觉在第 4 步;集成在第 5 步;fallback 和人工转接在第 6 步;黄金集在第 7 步;指标与风险分级在第 8 步。第 15 类八层策略用于团队归档和分工。

LAYER测试对象主要产物
  1. 01Intent Testing · 意图语言变体 × 目标标签
  2. 02Response Evaluation · 回复质量硬门槛 + 五维量表
  3. 03Conversation Testing · 会话逐轮状态断言
  4. 04Knowledge & Grounding · 知识来源、版本、检索证据
  5. 05Negative & Hallucination · 负向未知、虚构与拒答用例
  6. 06Fallback & Escalation · 恢复澄清协议 + 交接包
  7. 07Integration Testing · 集成API、认证、字段映射
  8. 08Regression Testing · 回归黄金集 + 发布门槛
八层名称与顺序完整保留自原文;右列产物是本文的操作化补充。

Layer 1 验证系统能否跨语言变体理解用户目标;Layer 2 用准确、相关、完整、清晰和有用评价回复;Layer 3 验证多轮上下文能否持续成立;Layer 4 检查答案是否来自批准且最新的知识;Layer 5 检查证据不足时系统能否停止确定性作答;Layer 6 检查失败恢复和必要的人工交接;Layer 7 检查 API、认证、数据库和下游系统;Layer 8 把模型、提示词、知识和应用的重要行为固化成回归。

交付清单:做到什么程度才算建成

第一版不需要等待完整评测平台。选 3 个高频用户目标,其中至少 1 个高风险目标,照本文完成下面的交付物:

  • 每个目标一份由产品、知识、安全和 QA 共同确认的行为合同;
  • 同义改写、错别字、边界输入和负向输入组成的单轮用例;
  • 至少一条包含话题切换、纠错和歧义的多轮状态用例;
  • 一条能保存文档版本、检索结果、工具响应和最终主张的 evidence trace;
  • 正常、认证失败、超时、空响应和畸形响应的集成测试;
  • fallback 决策表与完整人工转接 payload;
  • 能重复运行并记录失败责任层的 Golden Dataset;
  • Critical 零容忍、分项指标和明确发布动作组成的 release gate。

这些产物继续使用传统 QA 的八项核心能力:质疑假设、探索边界、负向测试、链路追踪、集成测试、风险分级、回归设计和故障调查。AI 改变了判定对象,这些能力仍然是整套系统的骨架。

验收时再问原文收尾提出的八个问题:用户真正想完成什么?他们会怎么表达?完成任务还缺什么信息?好回答必须包含什么?系统坚决不能做什么?不知道时下一步是什么?话题切换和纠错后什么才是当前真相?团队需要看到哪些证据才敢交给真实用户?

这些问题都有文件、有断言、有运行证据和负责人时,一套最小对话式 AI QA 系统才算真正建立。后续自动化只是把已经写清楚的判断跑得更快。

来源
How to Test Conversational AI: A Practical Guide for QA EngineersGayathri Bolineni·2026-08-24·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。