我把自己项目的一轮功能测试，交给了 GPT-6 Astra。
18 个功能范围，153 条测试用例，展开成 322 个独立执行项。Python、JavaScript、Java、TypeScript、Go，五种语言都要覆盖。
还要准备测试文件，连接外部系统，安装依赖，与内置AI助手对话生成适配器代码，等待定时任务，监测 Webhook，核对输出日志等等。
这是我正在做的 DataLinkRuntime，面向生产环境的FDE工具。
它允许用户使用内置的AI助手把数据连接和处理逻辑写成适配器，再放进隔离环境里运行。比如，从接口采集资产，把文件解析成结构化数据，定时同步一份清单，或者接收一条资产变更事件。
开发了很多个版本之后，功能已经基本固定。但从真实用户的操作出发，把这些功能完整地走一遍，我做得还不够。
一段代码，需要在编辑器里保存，绑定凭据，选择运行节点，装好依赖，配置输入。它可能手动运行，也可能每隔一段时间执行，还可能等待外部请求。运行之后，页面上的状态、日志、输出，以及外部系统实际收到的内容，都要对得上。
语言一换，这条链路得重新测。
刚好OpenAI发布了新模型，我想试着让 Codex 从帮我设计测试用例开始，到操作浏览器执行，再把过程和结果整理成交付物。
实际做下来，最值得分享的，是这项工作怎么一步步交出去。
测试过程
我给它的第一条要求，是先当测试负责人。
我口喷了几个示例方向，让Codex去核对源码里已经实现的所有功能，整理出完整的范围，经我核对后再生成功能测试用例。
当时我给了几个很具体的业务场景。
用本机的 InfraSourceLab 生成一组模拟的资产数据，创建手动任务和定时任务去接口里拉取，解析后输出。再做一个定时发送任务和Webhook任务，自己给自己发消息，由接收端解析并打印。准备 CSV、日志等文件，从页面上传，让文件解析任务处理。
依赖也要真的装，代码里要调用。适配器和模板要经过导出、导入、修改、再次运行。我提前提供api key，测试过程中控制AI助手生成的程序，要保存后实际执行。
这些例子把我的要求具体化了：测试要沿着用户真实会走的业务路径展开。
随后，Codex核对代码和项目文档，整理出了 18 个功能范围。除了我提到的业务场景，还补进了账号权限、保存与版本一致性、文件管理、历史记录、设置持久化和前端交互等等。
我再校准一遍，把本轮不需要的云厂商和 ServiceNow 场景排除，再次确认后才让它生成用例。
这个顺序，我觉得以后可以直接复用。
先把自己的业务讲清楚，让模型扫出范围，再做一次人工校准。范围确定以后，后面的用例设计和执行就有了共同依据。
设计完成后，目录下多了一套正式文件，放在 docs/testing/functional-acceptance/。
总入口、范围与覆盖矩阵、完整用例索引、18 个功能分册，还有浏览器执行说明和记录模板。153 条用例展开成 322 个执行项。
更关键的是，每条用例都有前置条件、测试数据、操作步骤、预期结果、证据要求和清理要求。
比如文件解析，要事先写清楚文件里有什么，从哪里上传，保存后怎么运行，预期解析出什么，应该留下哪份输出。
用例准备好以后，我才把执行任务交给Codex的另外一个对话分支。
设计和执行两个阶段，本地任务记录中的模型配置都是 GPT-6 Astra，思考强度 high。
执行时，Astra 通过 Chrome DevTools MCP 操作真实 Chrome（其实也可以用Codex自带浏览器插件），点击、填表、编辑、保存、运行，再读取页面状态、请求记录和日志。由Computer Use 补充原生交互：文件选择器、下载保存对话框，以及 Monaco 编辑器的粘贴操作。
Codex编写辅助脚本，用来准备数据、依赖材料和本机服务，也用于读取结果进行核对。
这里的自动化方式，是 Agent 读取用例后操作浏览器，观察结果，再决定下一步。322 个执行项是它遵循的执行清单，并不等于已经生成了 322 条固定的 Playwright 脚本。
我给执行阶段的要求，可以压缩成下面这段。
先读取规则、覆盖矩阵和执行说明。按照用例通过真实页面完成业务操作，以预先确定的数据和结果进行核验。每个执行项记录状态、对象编号和证据位置，按批次保存进度，结束后交付报告、台账和展示材料，运行结果进行截图留档。
接下来就是一个长达15小时31分的自动化测试过程。
执行过程中，Codex持续维护台账和检查点，记录哪些项已经处理、对应哪个执行编号、证据放在哪里、下一批接着做什么。
实际执行时，我最关注的是，它怎么判断自己做对了。
还是拿资产采集适配器的创建和执行举例。Codex先根据测试用例生成一组输入数据，再确定预期的记录数、关键字段和关系。然后调用我项目的ai助手生成适配器内部的业务代码去采集这组数据，在页面上点击适配器运行，完成采集后，把日志中的结构化输出逐项与这份预期核对。
文件解析也是类似的思路。Codex先制作内容已知的文件，再上传、保存、运行，核对解析后的数据。
所以，如果你也准备让 Agent 测自己的项目，可以先固化一条这样的完整链路到测试要求中。让Codex在测试时把输入和预期写清楚，让它把页面操作、运行结果和外部效果一起交回来。
到收尾时，交回来的文件也分成了几层。
一层是设计资产，也就是前面的范围、覆盖矩阵、用例分册和执行说明。这些保存在项目里，下一轮可以沿用和更新。
一层是执行台账和对象清单。台账记录每个执行项的状态，对象清单把测试中创建的适配器、文件等材料与执行记录关联起来。我们可以针对测试现场进行人工核查。
再往下，是具体证据。页面截图、请求与响应、结构化输出、日志、下载文件、逐项判定说明，都有各自的位置。测试报告负责汇总，检查点记录后续接续位置，复测记录保留不同阶段的结果。
有了这些产物，后续人工对测试结果审核就有了入口。
想知道某个功能怎么测的，去看用例。想知道某一项实际做了哪一步，去查台账。需要核实判定，就顺着编号打开证据。下一次改动之后，还可以找到需要重新执行的那组用例。未来我想还可以做一个网页版的测试管理页面，方便在线搜索和查看测试物料。
测试完成后，对于不通过项，就可以让agent提交修复issues了。修复完成后，完全可以接着本次测试进行回归测试。
结语
这次测试实战又让我想起了Sam Altman那个“眩晕瘫坐、原子弹爆炸”的梗。
我们已经可以认真尝试，在agent把功能写完、白盒测试通过之后，把整个功能测试工作也交给它。相信我，范围梳理、用例设计、真实操作、结果核对、材料归档，agent一定可以做的比人要更细、更认真。
测试人员需要做的，是讲清业务，校准范围，确认预期，提供必要条件，再审查它交回来的东西。关键场景务必再亲自完整走一遍。
以前这样一轮测试，要排期，要协调，要挤时间。现在，一个晚上。
当一个人一个晚上能做完过去一个团队一周的事，限制你的就不再是人手，是你敢把范围想多大。
GPT-6 也许真的是 AGI 的一个起点。
当 AI 开始无所不能，我们要做的，就是尽量多地向它提要求。越具体越好。只要你能够把需求说清楚，你的愿望就能够实现。
文中项目
- • 自然语言驱动的IT资产测试数据生成器(https://github.com/john-ops-lab/InfraSourceLab)
- • AI 辅助、代码优先的数据适配开发与运行平台(https://github.com/john-ops-lab/DataLinkRuntime)
- • ChromeDevTools for agent(https://github.com/ChromeDevTools/chrome-devtools-mcp)
