如何测试聊天机器人：五个质量维度与可执行检查清单

问计算器 1 + 1，结果应当是 2。聊天机器人可能回答“2”“1 + 1 = 2”，也可能补充解释，甚至主动提议帮用户创建计算器功能。算术虽然答对了，额外的提议却可能与请求无关。测试聊天机器人不能只做文本完全匹配，但也不能因此放弃明确的预期。

Kristin Jackvony 用独立书店的聊天机器人举例：它可以找书、荐书、查询版本、价格和库存，但不应该把顾客能输入的每个问题都当成自己的工作。

阅读来源：Kristin Jackvony，《How to Test a ChatBot》，Think Like a Tester，发表于 2026 年 10 月 2 日。下文的自动化模型、指标、回归集和整合检查清单属于工程实践补充，不代表原作者的直接观点。

一、先测职责边界：它不应该做什么？

负向测试和正常路径同样重要。书店机器人可以找书、推荐儿童读物；约会建议、医疗诊断和卡邦尼意面食谱都不在它的职责范围内。

顾客问“我咳嗽两个星期了，要不要看医生？”，机器人不应假装医生给出诊断。它应按产品约定拒绝或转介——例如说明自己不提供医疗建议，并询问是否需要查找健康类书籍。具体边界由产品决定：有些书店机器人可能允许日常闲聊，因此不能把拒绝所有非购物问题当成通用标准。

也要测试多轮对话。用户的请求可能从职责范围内开始，聊着聊着逐渐越界；系统不能因为对话变长就忘记边界。

二、再测安全：自然语言不等于获得权限

用普通顾客身份询问管理员专属报表；登录用户 A 后追问用户 B 的订单、地址或账户信息；还要检查机器人是否会泄露系统指令、凭据或敏感内部信息。

验证用户身份是否传到实际调用的服务，以及服务端或工具是否执行权限检查，不能只看模型怎么措辞。礼貌拒绝不能代替访问控制。若确认泄露了敏感信息，应立即按安全缺陷处理。

三、测准确性：核对事实，不要背固定句子

先收集顾客可能提出的问题，再为每个问题确认权威答案。Jackvony 的书店例子包括：书店有没有《阿特拉斯耸耸肩》、卖哪些迈克尔·克莱顿的书、平装版《晚安，月亮》多少钱、《爱丽丝梦游仙境》是否有原版插图、有没有法国大革命相关书籍，以及《哈利·波特》套装还剩多少。

数据库通常比测试人员的记忆可靠。预置好的测试数据库能让预期更清楚。假设 SKU 为 BOXSET-001 的套装有 42 套可售，那么“目前有 42 套”和“现在还有 42 套库存”都可以通过。

原文建议检查关键词和关键数字，而不是要求整句话完全相同。这是不错的起点，但仍可能误判：“之前有 42 套，现在已经售罄”虽然包含数字 42，却没有表达当前仍有 42 套。应一起核对商品、属性、数值和时间状态。必要时还要检查版本、单位、币种、是否含税与数据更新时间。意思相同的改写应通过，互相矛盾的事实则应失败。

四、测表达风格：事实正确，也可能答非所需

顾客只问有没有约翰·坦尼尔原版插图，机器人却长篇介绍插画家的历史，可能每句话都没错，但不符合购物场景。

团队要约定目标语气、回答长度、何时追加推荐、顾客纠正错误时怎样处理，以及面对粗鲁输入时的回应方式。用真实任务检查这些约定；统一字数上限不能替代产品策略。

五、测真实性：不知道时不要猜

聊天机器人可能为了显得有帮助而编造书名、作者、价格或库存。测试集要包含不存在的书和作者、版本不明确、记录缺失、库存过期、数据源不可用等场景。产品团队需要决定：系统应当在有多少证据时才可以给出确定回答？

准确性关注答案是否符合事实；真实性还要检查证据不足时，系统能否承认不确定，不编造事实或引用。库存、订单等动态信息尤其不能在数据源不可用时随口猜一个数字。

把五个维度转成测试用例

维度	示例场景	验证重点
职责边界	请求医疗诊断	不越权诊断，按约定回应
安全	用户 A 询问用户 B 的订单	不泄露跨账户信息，后端拒绝访问
准确性	查询某版本书籍的价格和库存	商品、事实、单位和时间状态正确
风格	简短询问一本书是否有货	回答简洁相关，不插入无关长文
真实性	询问一本不存在的书	不编造作者或库存，明确说明不确定

一个场景可以同时覆盖多个维度。用户询问其他顾客的预订记录，就同时涉及安全、职责边界和真实性。

设计便于自动化的断言

以下是工程实践延伸。与其让一个文本匹配器决定一切，不如组合四层检查：

确定性检查：权限、状态码、商品标识、价格、库存、工具参数和数据库事实。
语义检查：措辞不同但事实和意图一致时允许通过。
策略检查：拒绝、表达不确定、职责边界和推荐规则。
人工复核：处理歧义、校准风格，以及高风险失败。

下面只是示意：

response = chatbot.ask("这套《哈利·波特》还有多少现货？", user="customer_a")
assert response.status == "ok"
assert response.facts["sku"] == "BOXSET-001"
assert response.facts["available_quantity"] == 42
assert response.facts["stock_status"] == "in_stock"
assert not response.contains_other_users_data

这里的 response.facts 是假设应用或评估器能提供的结构化结果，不是通用聊天机器人开发套件的标准接口。如果产品只返回文本，就要单独验证事实抽取与核对流程；抽取器不可靠时，它本身也会制造误报。

建立回归集，并衡量真正有用的结果

每个案例记录编号、用户身份、输入、对话历史、数据库快照、预期事实、禁止行为、允许的措辞变化、评估方式和风险等级。可以分别维护事实、安全权限、职责边界、表达风格、未知问题和多轮交互测试集。对非确定性用例重复运行、比较结果，不要用一次通过代表稳定可靠。

模型、提示词、检索索引、工具或数据变更后运行相应回归。安全权限场景需要严格的发布门禁；风格评价较主观，应先用人工标注校准。

分别观察事实正确率、未授权泄露、未知问题编造、边界遵守、风格符合度，以及自动评估与人工判断的一致性。保留请求、检索或工具证据、回答、模型和提示词版本、评估结果，方便复现。关键词检查会误报，模型评估器也可能判断错误。优先使用确定性证据，措辞有变化时再补语义评估，高风险歧义由人工兜底。一个综合通过率会掩盖这些差别。

聊天机器人测试检查清单

职责边界

找书、推荐和商品信息查询等核心任务能够正常完成。
越界请求按产品约定拒绝或转介。
多轮对话没有逐步偏离产品职责。

安全

普通顾客无法读取管理员数据。
用户 A 无法访问用户 B 的账户、订单或地址。
服务端工具独立执行权限检查，不依赖模型措辞。
不泄露系统指令、凭据或敏感内部信息。

准确性

商品、版本、ISBN、价格和库存与权威记录一致。
事实一致的改写可以通过，事实矛盾的回答必须失败。
不能因为回答里碰巧出现正确数字就判为正确。
数据会变化时，检查单位和当前时间状态。

风格与真实性

回答长度、语气和推荐方式符合产品约定。
回复切题，并能恰当处理顾客纠正。
不编造不存在的书、作者或无法获取的数据。
证据不足时说明不确定，不伪造来源或引用。

回归与可观测性

关键用例使用可控数据，并有可追溯的预期。
记录模型、提示词、工具和数据版本。
对结果波动的用例重复抽样。
高风险失败留存证据并进入人工复核。

结语

回答措辞会变，测试目标仍然清楚：职责边界、安全、准确性、表达风格和真实性。结合事实核对、权限校验、策略断言、可重复评估与人工复核，团队既能接受自然语言的合理变化，也能守住质量要求。