1. 项目背景与测试目标
作为一名长期从事AI系统开发的工程师,我深知功能测试对于智能体(Agent)系统的重要性。这次分享的打卡/日报Agent v1.0测试用例设计,源于我们团队在实际开发过程中遇到的真实需求——如何确保一个看似简单的打卡Agent在各种复杂场景下都能稳定运行。
这个Agent的核心功能看似简单:记录工作碎片、查询状态、处理打卡请求。但在实际使用中,用户输入千变万化,系统状态组合多样,如何保证Agent不会"自作主张"地越权操作,或者被用户的情绪化表达带偏,就成了测试设计的重点。
提示:在AI系统测试中,行为可控性比功能完整性更重要。一个不会"帮忙"的Agent,远比一个乱帮忙的Agent更可靠。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 测试框架设计思路
2.1 输入分类体系
我们首先建立了严格的输入分类标准,这是所有测试用例的设计基础:
| 输入类型 | 典型特征 | 允许行为 | 风险点 |
|---|---|---|---|
| 事实输入 | 描述已完成工作 | 记录碎片 | 误解析为指令 |
| 查询输入 | 包含"吗""是不是"等疑问词 | 只读查询 | 误触发写操作 |
| 打卡确认 | 明确包含"打卡"关键词 | 修改打卡状态 | 时间推断错误 |
| 情绪/混合输入 | 感叹词、模糊表达 | 兜底回应 | 误记录为事实 |
| 越界指令 | 包含"写""帮"等动词 | 明确拒绝 | 部分执行风险 |
这种分类不是基于语义分析,而是从用户意图和行为边界角度划分,更符合实际测试需求。
2.2 系统状态定义
我们定义了
