~~借助AI润色，不足之处敬请谅解~~

看不到工具源码，不能直接调用函数，也不会编写 Agent。
测试工程师还能做好 Agent 测试吗？

当然可以。真正的关键不是能不能阅读代码，而是能不能做到：输入可控、预期明确、结果可核对、过程有证据。

目前，我们的 Agent 已经拥有两个工具：

• 时间解析工具：理解“昨天上午 9 点”等自然语言时间；
• 文件查询工具：根据名称、类型和修改时间查找文件。

这一节插播课暂时不增加新功能，也不要求大家开发 Agent。

我们将站在测试工程师的真实工作场景中，通过聊天页面、测试目录和调用轨迹，对现有 Agent 进行黑盒测试。

一、先纠正一个常见误区

提到测试 Agent，很多人第一反应是：

我要不要先学习 Python？
我要不要阅读 LangChain 源码？
我要不要给工具编写单元测试？

这些能力当然有价值，但不一定是测试工程师当前最紧迫的任务。

在很多公司中，工具由开发人员负责实现，测试工程师通常接触不到：

• 工具内部函数；
• Agent 编排代码；
• 模型调用代码；
• 数据库连接方式；
• 开发人员的本地环境。

测试人员真正能够使用的，往往只有：

Agent 聊天页面
测试账号
测试数据
接口或调用日志
最终回答

因此，我们不应该照搬开发人员的单元测试，而应该解决一个更现实的问题：

在看不到源码的情况下，如何证明 Agent 的行为是正确、安全、可信的？

这就是黑盒 Agent 测试。

二、Agent 黑盒测试不只是“问一句、看答案”

假设我们输入：

以 2026 年 8 月 11 日上午 10 点为参考，
查找昨天上午 9 点以后修改的 Python 文件。

Agent 回答：

找到了 payment_test.py。

看起来回答正确，但测试不能到此结束。

我们还需要思考：

1. “昨天上午 9 点”是否被解析成了正确日期？
2. Agent 是否真的调用了时间工具？
3. 时间工具的结果是否传给了文件工具？
4. 文件工具是否使用了 .py 作为筛选条件？
5. 是否有符合条件的文件被遗漏？
6. 是否有不符合条件的文件被错误加入？
7. Agent 是否访问了允许范围之外的目录？
8. 最终回答是否忠于工具查询结果？

由此可以看出，Agent 测试至少包含三个层面。

结果层

最终回答中的时间、文件名和数量是否正确。

行为层

Agent 调用了什么工具，使用了什么参数，调用顺序是否合理。

安全层

Agent 是否越权访问、泄露数据或执行了用户没有授权的操作。

所以，黑盒测试并不浅。

即使不知道代码怎样实现，我们依然可以通过外部行为和证据定位问题。

三、测试工程师转型 Agent 测试的优势

很多测试工程师担心：

我不会开发 Agent，是不是没有竞争力？

实际上，我们过去积累的很多能力可以直接迁移过来。

需要补充的新知识主要是：

• 模型的输出存在一定波动；
• 相同意思可能使用不同措辞；
• 最终回答正确，不代表调用过程正确；
• Agent 的错误可能来自模型，也可能来自工具；
• 测试时必须保存工具调用轨迹。

换句话说，我们不是重新从零开始，而是在原有测试能力上增加模型与工具调用的知识。

四、先明确测试边界

测试开始前，必须向产品和开发确认当前 Agent 的能力范围。

至少需要回答以下问题：

时间工具支持哪些表达？
没有参考时间时，以哪个时间为准？
系统使用哪个时区？
文件工具可以查询哪个目录？
是否支持子目录？
文件名匹配是否区分大小写？
“某时间以后”是否包含该时间点？
最多返回多少个文件？
工具失败时页面如何提示？

这些问题看起来很细，却会直接影响预期结果。

例如：

查找上午 9 点以后修改的文件。

“以后”到底是：

修改时间 > 09:00:00

还是：

修改时间 >= 09:00:00

两个定义都会影响 9 点整的文件是否应该出现。

如果需求没有说明，测试工程师不能自己猜。

应该把它记录为需求确认项。

测试工作的价值，不只是发现程序错误，也包括发现自然语言需求中的歧义。

五、向开发申请最低限度的可测试性

看不到源码，不代表只能根据回答猜测过程。

一个可测试的 Agent，至少应该提供基本的调用证据。

建议测试环境展示或记录：

例如，一次调用轨迹可以是：

Trace ID：trace-20260811-001

第 1 次工具调用
工具：parse_natural_datetime
参数：
  expression = 昨天上午9点
  reference_time = 2026-08-11 10:00
状态：成功
结果：2026-08-10 09:00

第 2 次工具调用
工具：search_personal_space_files
参数：
  extensions = [".py"]
  modified_after = 2026-08-10 09:00
状态：成功
结果数量：1

测试工程师不需要知道工具内部用了什么算法。

只要能看到这些信息，就可以判断：

• 工具是否选对；
• 参数是否正确；
• 上一步结果是否传给下一步；
• 工具失败还是结果为空；
• 最终回答是否与真实结果一致。

如果系统暂时不能展示完整轨迹，至少应该提供 Trace ID，让开发能够根据该编号查询后台日志。

这不是测试人员提出的额外负担，而是 Agent 产品的基本可测试性要求。

六、建立独立、可控的测试空间

文件查询最容易受到环境变化影响。

如果直接使用真实办公目录，今天有 10 个文件，明天可能只剩 8 个。同一条用例每次结果不同，测试就失去了意义。

因此，应该申请一个独立测试目录，例如：

个人空间/
└── agent_test_space/

然后准备以下文件：

agent_test_space/
├── login_test.py
├── payment_test.py
├── test_plan.md
├── meeting_notes.txt
└── report.pdf

对应关系如下：

有了这组数据，我们就可以人工推导预期结果。

查询所有 Python 文件

预期：

login_test.py
payment_test.py

查询名称包含 test 的文件

预期：

login_test.py
payment_test.py
test_plan.md

查询名称包含 test 的 Python 文件

预期：

login_test.py
payment_test.py

测试数据越明确，测试结论越可靠。

七、为测试文件设置明确的修改时间

为了测试时间条件，还要控制文件的修改时间。

例如设置为：

Windows 测试人员可以使用 PowerShell 设置时间：

(Get-Item ".\login_test.py").LastWriteTime =
    Get-Date "2026-08-10 08:30:00"

(Get-Item ".\payment_test.py").LastWriteTime =
    Get-Date "2026-08-10 09:30:00"

(Get-Item ".\test_plan.md").LastWriteTime =
    Get-Date "2026-08-10 10:00:00"

完成后，还要通过文件属性重新确认实际修改时间。

现在输入：

查找 2026 年 8 月 10 日上午 9 点以后修改的 Python 文件。

如果“以后”不包含 9 点整，唯一正确结果就是：

payment_test.py

原因很清楚：

• login_test.py
   是 Python 文件，但时间早于 9 点；
• payment_test.py
   同时满足时间和类型条件；
• test_plan.md
   时间符合，但不是 Python 文件；
• 其他文件也不满足全部条件。

这种方法体现了黑盒测试的核心思想：

我们不查看内部实现，而是通过控制外部数据，精确计算正确结果。

八、建立测试数据清单

仅仅创建文件还不够，还要保存一份测试数据清单。

推荐格式如下：

以后发现问题时，可以把这张表作为证据提交给开发。

缺陷报告不能只写：

Agent 查错了。

而应该写：

测试目录中共有两个 Python 文件。

login_test.py 的修改时间为 08:30，
payment_test.py 的修改时间为 09:30。

查询条件为 09:00 以后修改的 Python 文件，
预期只返回 payment_test.py，
实际同时返回了 login_test.py。

这类证据能显著降低沟通成本。

九、确认系统时间与时区

时间测试中，经常被忽略的是时区。

测试前应确认：

测试电脑使用什么时区？
Agent 服务端使用什么时区？
工具返回结果是否包含时区？
未指定参考时间时使用谁的当前时间？

例如，用户在中国使用北京时间，而服务器运行在 UTC 时区。

用户说：

今天上午 9 点。

如果系统直接使用服务器时间，就可能得到错误日期。

因此，测试记录中应明确写出：

测试时区：Asia/Shanghai
参考时间：2026-08-11 10:00 +08:00

不要只写：

参考时间：上午10点

只有固定日期、时间和时区，结果才可复现。

十、先设计“最小测试闭环”

在正式执行大量用例前，先用一个简单场景验证测试环境。

测试输入

查找名称包含 test 的 Python 文件。

已知测试数据

login_test.py
payment_test.py
test_plan.md

预期结果

应该返回：

login_test.py
payment_test.py

不应该返回：

test_plan.md

需要收集的证据

用户完整输入
Agent 最终回答
Trace ID
工具名称
脱敏后的工具参数
工具返回数量
测试目录文件清单

如果这条最简单的用例都无法获得清晰结论，先不要急着执行更复杂的时间与多工具场景。

应该优先解决：

• 测试数据是否可控；
• 调用轨迹是否可获得；
• 需求规则是否明确；
• 预期结果是否可以人工计算。

十一、测试前检查清单

环境准备

[ ] 已申请独立测试账号
[ ] 已申请独立测试目录
[ ] 测试目录不会混入真实业务文件
[ ] 测试人员可以创建和修改文件
[ ] 已确认系统时区

数据准备

[ ] 已准备不同扩展名的文件
[ ] 已准备包含和不包含关键字的文件
[ ] 已设置明确的修改时间
[ ] 已核对文件属性
[ ] 已保存测试数据清单

可观测性

[ ] 可以获得 Trace ID
[ ] 可以确认调用了哪个工具
[ ] 可以查看脱敏后的工具参数
[ ] 可以区分工具成功、失败和空结果
[ ] 可以确认工具返回数量

需求确认

[ ] 已确认时间工具使用的时区
[ ] 已确认“以后”是否包含边界
[ ] 已确认文件名是否区分大小写
[ ] 已确认是否查询子目录
[ ] 已确认最大返回数量

本篇总结

这一篇还没有正式开始执行大量测试。

我们首先完成了黑盒 Agent 测试最重要的准备工作：

明确测试边界
    ↓
申请必要的调用证据
    ↓
建立独立测试目录
    ↓
准备固定测试文件
    ↓
控制文件修改时间
    ↓
确认系统时区
    ↓
形成可人工计算的预期结果

对于测试工程师来说，这一步看似缓慢，却决定了后续测试是否可信。

如果测试环境中的数据不断变化，或者连工具是否执行成功都无法确认，那么执行再多问题也只能得到模糊结论。

请记住本篇最重要的一句话：

黑盒测试不是盲测。看不到源码，更要让测试数据可控、业务规则明确、执行过程有证据。

下一篇，我们将正式开始实战：

插播课（中）：不看源码，分别测试时间工具和文件工具

我们会围绕聊天页面设计：

• 时间等价类；
• 跨月、跨年和闰年测试；
• 模糊时间测试；
• 文件关键字与扩展名测试；
• 组合条件测试；
• 时间边界测试；
• 空结果与工具失败测试。

先把两个工具分别测清楚，再进入多工具协作场景。

插播课（上）：看不到源码，如何测试 Agent

看不到工具源码，不能直接调用函数，也不会编写 Agent。
测试工程师还能做好 Agent 测试吗？

当然可以。真正的关键不是能不能阅读代码，而是能不能做到：输入可控、预期明确、结果可核对、过程有证据。

目前，我们的 Agent 已经拥有两个工具：

• 时间解析工具：理解“昨天上午 9 点”等自然语言时间；
• 文件查询工具：根据名称、类型和修改时间查找文件。

这一节插播课暂时不增加新功能，也不要求大家开发 Agent。

我们将站在测试工程师的真实工作场景中，通过聊天页面、测试目录和调用轨迹，对现有 Agent 进行黑盒测试。

一、先纠正一个常见误区

提到测试 Agent，很多人第一反应是：

我要不要先学习 Python？
我要不要阅读 LangChain 源码？
我要不要给工具编写单元测试？

这些能力当然有价值，但不一定是测试工程师当前最紧迫的任务。

在很多公司中，工具由开发人员负责实现，测试工程师通常接触不到：

• 工具内部函数；
• Agent 编排代码；
• 模型调用代码；
• 数据库连接方式；
• 开发人员的本地环境。

测试人员真正能够使用的，往往只有：

Agent 聊天页面
测试账号
测试数据
接口或调用日志
最终回答

因此，我们不应该照搬开发人员的单元测试，而应该解决一个更现实的问题：

在看不到源码的情况下，如何证明 Agent 的行为是正确、安全、可信的？

这就是黑盒 Agent 测试。

二、Agent 黑盒测试不只是“问一句、看答案”

假设我们输入：

以 2026 年 8 月 11 日上午 10 点为参考，
查找昨天上午 9 点以后修改的 Python 文件。

Agent 回答：

找到了 payment_test.py。

看起来回答正确，但测试不能到此结束。

我们还需要思考：

1. “昨天上午 9 点”是否被解析成了正确日期？
2. Agent 是否真的调用了时间工具？
3. 时间工具的结果是否传给了文件工具？
4. 文件工具是否使用了 .py 作为筛选条件？
5. 是否有符合条件的文件被遗漏？
6. 是否有不符合条件的文件被错误加入？
7. Agent 是否访问了允许范围之外的目录？
8. 最终回答是否忠于工具查询结果？

由此可以看出，Agent 测试至少包含三个层面。

结果层

最终回答中的时间、文件名和数量是否正确。

行为层

Agent 调用了什么工具，使用了什么参数，调用顺序是否合理。

安全层

Agent 是否越权访问、泄露数据或执行了用户没有授权的操作。

所以，黑盒测试并不浅。

即使不知道代码怎样实现，我们依然可以通过外部行为和证据定位问题。

三、测试工程师转型 Agent 测试的优势

很多测试工程师担心：

我不会开发 Agent，是不是没有竞争力？

实际上，我们过去积累的很多能力可以直接迁移过来。

需要补充的新知识主要是：

• 模型的输出存在一定波动；
• 相同意思可能使用不同措辞；
• 最终回答正确，不代表调用过程正确；
• Agent 的错误可能来自模型，也可能来自工具；
• 测试时必须保存工具调用轨迹。

换句话说，我们不是重新从零开始，而是在原有测试能力上增加模型与工具调用的知识。

四、先明确测试边界

测试开始前，必须向产品和开发确认当前 Agent 的能力范围。

至少需要回答以下问题：

时间工具支持哪些表达？
没有参考时间时，以哪个时间为准？
系统使用哪个时区？
文件工具可以查询哪个目录？
是否支持子目录？
文件名匹配是否区分大小写？
“某时间以后”是否包含该时间点？
最多返回多少个文件？
工具失败时页面如何提示？

这些问题看起来很细，却会直接影响预期结果。

例如：

查找上午 9 点以后修改的文件。

“以后”到底是：

修改时间 > 09:00:00

还是：

修改时间 >= 09:00:00

两个定义都会影响 9 点整的文件是否应该出现。

如果需求没有说明，测试工程师不能自己猜。

应该把它记录为需求确认项。

测试工作的价值，不只是发现程序错误，也包括发现自然语言需求中的歧义。

五、向开发申请最低限度的可测试性

看不到源码，不代表只能根据回答猜测过程。

一个可测试的 Agent，至少应该提供基本的调用证据。

建议测试环境展示或记录：

例如，一次调用轨迹可以是：

Trace ID：trace-20260811-001

第 1 次工具调用
工具：parse_natural_datetime
参数：
  expression = 昨天上午9点
  reference_time = 2026-08-11 10:00
状态：成功
结果：2026-08-10 09:00

第 2 次工具调用
工具：search_personal_space_files
参数：
  extensions = [".py"]
  modified_after = 2026-08-10 09:00
状态：成功
结果数量：1

测试工程师不需要知道工具内部用了什么算法。

只要能看到这些信息，就可以判断：

• 工具是否选对；
• 参数是否正确；
• 上一步结果是否传给下一步；
• 工具失败还是结果为空；
• 最终回答是否与真实结果一致。

如果系统暂时不能展示完整轨迹，至少应该提供 Trace ID，让开发能够根据该编号查询后台日志。

这不是测试人员提出的额外负担，而是 Agent 产品的基本可测试性要求。

六、建立独立、可控的测试空间

文件查询最容易受到环境变化影响。

如果直接使用真实办公目录，今天有 10 个文件，明天可能只剩 8 个。同一条用例每次结果不同，测试就失去了意义。

因此，应该申请一个独立测试目录，例如：

个人空间/
└── agent_test_space/

然后准备以下文件：

agent_test_space/
├── login_test.py
├── payment_test.py
├── test_plan.md
├── meeting_notes.txt
└── report.pdf

对应关系如下：

有了这组数据，我们就可以人工推导预期结果。

查询所有 Python 文件

预期：

login_test.py
payment_test.py

查询名称包含 test 的文件

预期：

login_test.py
payment_test.py
test_plan.md

查询名称包含 test 的 Python 文件

预期：

login_test.py
payment_test.py

测试数据越明确，测试结论越可靠。

七、为测试文件设置明确的修改时间

为了测试时间条件，还要控制文件的修改时间。

例如设置为：

Windows 测试人员可以使用 PowerShell 设置时间：

(Get-Item ".\login_test.py").LastWriteTime =
    Get-Date "2026-08-10 08:30:00"

(Get-Item ".\payment_test.py").LastWriteTime =
    Get-Date "2026-08-10 09:30:00"

(Get-Item ".\test_plan.md").LastWriteTime =
    Get-Date "2026-08-10 10:00:00"

完成后，还要通过文件属性重新确认实际修改时间。

现在输入：

查找 2026 年 8 月 10 日上午 9 点以后修改的 Python 文件。

如果“以后”不包含 9 点整，唯一正确结果就是：

payment_test.py

原因很清楚：

• login_test.py
   是 Python 文件，但时间早于 9 点；
• payment_test.py
   同时满足时间和类型条件；
• test_plan.md
   时间符合，但不是 Python 文件；
• 其他文件也不满足全部条件。

这种方法体现了黑盒测试的核心思想：

我们不查看内部实现，而是通过控制外部数据，精确计算正确结果。

八、建立测试数据清单

仅仅创建文件还不够，还要保存一份测试数据清单。

推荐格式如下：

以后发现问题时，可以把这张表作为证据提交给开发。

缺陷报告不能只写：

Agent 查错了。

而应该写：

测试目录中共有两个 Python 文件。

login_test.py 的修改时间为 08:30，
payment_test.py 的修改时间为 09:30。

查询条件为 09:00 以后修改的 Python 文件，
预期只返回 payment_test.py，
实际同时返回了 login_test.py。

这类证据能显著降低沟通成本。

九、确认系统时间与时区

时间测试中，经常被忽略的是时区。

测试前应确认：

测试电脑使用什么时区？
Agent 服务端使用什么时区？
工具返回结果是否包含时区？
未指定参考时间时使用谁的当前时间？

例如，用户在中国使用北京时间，而服务器运行在 UTC 时区。

用户说：

今天上午 9 点。

如果系统直接使用服务器时间，就可能得到错误日期。

因此，测试记录中应明确写出：

测试时区：Asia/Shanghai
参考时间：2026-08-11 10:00 +08:00

不要只写：

参考时间：上午10点

只有固定日期、时间和时区，结果才可复现。

十、先设计“最小测试闭环”

在正式执行大量用例前，先用一个简单场景验证测试环境。

测试输入

查找名称包含 test 的 Python 文件。

已知测试数据

login_test.py
payment_test.py
test_plan.md

预期结果

应该返回：

login_test.py
payment_test.py

不应该返回：

test_plan.md

需要收集的证据

用户完整输入
Agent 最终回答
Trace ID
工具名称
脱敏后的工具参数
工具返回数量
测试目录文件清单

如果这条最简单的用例都无法获得清晰结论，先不要急着执行更复杂的时间与多工具场景。

应该优先解决：

• 测试数据是否可控；
• 调用轨迹是否可获得；
• 需求规则是否明确；
• 预期结果是否可以人工计算。

十一、测试前检查清单

环境准备

[ ] 已申请独立测试账号
[ ] 已申请独立测试目录
[ ] 测试目录不会混入真实业务文件
[ ] 测试人员可以创建和修改文件
[ ] 已确认系统时区

数据准备

[ ] 已准备不同扩展名的文件
[ ] 已准备包含和不包含关键字的文件
[ ] 已设置明确的修改时间
[ ] 已核对文件属性
[ ] 已保存测试数据清单

可观测性

[ ] 可以获得 Trace ID
[ ] 可以确认调用了哪个工具
[ ] 可以查看脱敏后的工具参数
[ ] 可以区分工具成功、失败和空结果
[ ] 可以确认工具返回数量

需求确认

[ ] 已确认时间工具使用的时区
[ ] 已确认“以后”是否包含边界
[ ] 已确认文件名是否区分大小写
[ ] 已确认是否查询子目录
[ ] 已确认最大返回数量

本篇总结

这一篇还没有正式开始执行大量测试。

我们首先完成了黑盒 Agent 测试最重要的准备工作：

明确测试边界
    ↓
申请必要的调用证据
    ↓
建立独立测试目录
    ↓
准备固定测试文件
    ↓
控制文件修改时间
    ↓
确认系统时区
    ↓
形成可人工计算的预期结果

对于测试工程师来说，这一步看似缓慢，却决定了后续测试是否可信。

如果测试环境中的数据不断变化，或者连工具是否执行成功都无法确认，那么执行再多问题也只能得到模糊结论。

请记住本篇最重要的一句话：

黑盒测试不是盲测。看不到源码，更要让测试数据可控、业务规则明确、执行过程有证据。

下一篇，我们将正式开始实战：

插播课（中）：不看源码，分别测试时间工具和文件工具

我们会围绕聊天页面设计：

• 时间等价类；
• 跨月、跨年和闰年测试；
• 模糊时间测试；
• 文件关键字与扩展名测试；
• 组合条件测试；
• 时间边界测试；
• 空结果与工具失败测试。

先把两个工具分别测清楚，再进入多工具协作场景。