从提交代码到 AI 探索测试:一套自动交付方案的设计思路

正文

代码写完、自测通过，接下来通常还要做多少事？

更新代码、打包、上传服务器、停服务、换包、重启，再打开系统检查一遍。遇到离线 Docker 部署，还要构建镜像、导出、传输、导入、启动容器。

即使已经开始用 AI 做测试，也可能还需要人先把环境准备好，再手工启动一次任务。构建、部署、测试和交付，仍然是几段需要人工接起来的流程。

所以，我整理了一份《自动交付与 AI 探索测试方案 V1》，想回答一个问题：

开发者提交代码之后，能不能让系统继续完成构建、测试环境部署、AI 探索测试和报告归档，最后给出有依据的交付结论？

先说明进度：这是一份尚未实施的方案讨论稿。下面分享的是设计思路、验证路径和能力边界，实际效果需要通过试点检验。

01｜先把提交后的流程接起来

方案面向的现有环境包括自建 Gitee、Vue 3、Java 8 / Java 21，以及普通服务器和 Docker 部署。

一次运行的目标流程是：

指定分支提交 → 锁定版本 → 构建 → 部署测试环境 → 健康与版本检查 → AI 探索及约定的接口、性能检查 → 报告归档 → 交付规则判定。

拟由 Jenkins 组织任务，构建执行器处理项目对应的工具链，部署适配器处理包或镜像的交付。AI 执行器连接浏览器和 HTTP 工具，性能任务使用 k6。

这些组件的接入方式仍需验证，尤其是 AI 执行器能否稳定地无人值守运行、调用工具、保存进度和响应取消。

这里有两个容易忽视的细节。

第一，测试版本必须与候选交付版本一致。前后端分仓时，要先固定两边的提交号；被测试的构建产物，也应当是最终生成候选交付物的那一份。

第二，共享测试环境需要执行锁。一个版本还在测试，另一个版本就覆盖部署，测试结果会失去清晰的版本归属。

02｜让 AI 在运行时发现并检查页面

这份方案的核心，是让 AI 根据页面和业务依据，在运行时规划并执行检查。

接入时仍然需要提供测试地址、角色账号、可操作数据范围、关键业务规则和必测功能清单。在这些条件下，AI 执行：

观察页面 → 选择检查 → 调用工具 → 验证结果 → 保存证据 → 更新待测队列。

例如进入一个表单，AI 可以围绕必填、格式、边界值、正常提交和取消操作规划检查；进入列表，可以检查查询、重置、分页和空结果。

但点击“保存”之后出现提示，只是观察的一部分。还需要按项目规则核对业务返回值，检查记录能否重新查询、刷新后是否保留、字段是否正确保存。

这条路线希望减少事先编写完整脚本库的准备工作。探索中实际执行过、能够依据规则复验的关键流程，可以再生成回归脚本，经重置数据和再次执行后沉淀下来。

于是，探索与回归可以形成积累：前者发现和尝试，后者重复验证已确认的关键路径。

03｜最关键的设计：什么才算测试通过

让 AI 操作页面，只解决了一部分问题。结果可信，还需要明确的判断依据。

打开菜单，不等于验证了功能；HTTP 200，不等于业务成功；脚本执行结束，也不等于每个检查项都通过。

方案要求每个检查项关联功能、角色、场景、前置条件、判断依据、操作步骤、实际结果和证据。业务预期优先来自需求、接口约定和已确认规则。

比如“某角色是否允许导出”，如果没有权限规则，AI 可以记录看到的现象，但不能只凭页面布局替业务作决定。

因此，报告需要区分六种检查状态：

• 通过：实际执行，符合明确依据，并保留必要证据。
• 失败：实际执行，与明确依据不符，并提供复现信息。
• 阻断：账号、数据、环境或工具问题导致无法验证。
• 未测：属于声明范围，但本轮尚未执行。
• 待确认：观察到了现象，但缺少足够的业务判断依据。
• 不适用：有明确理由不适用于本轮检查。

未测、阻断和待确认项，都要留在报告里。

覆盖记录按“功能 × 角色 × 场景”展开，同时写明范围来自哪里。缺少完整功能基线时，只能说明本轮发现和检查的范围，不能据此宣布整个系统已被覆盖。

04｜接口、性能和交付结论要接得上

页面操作关联的请求，可以用于核对服务端结果。有接口文档时，再按约定补充参数、鉴权、异常和幂等等独立场景。页面上发现的请求，只能代表已发现的接口范围。

性能测试同样需要项目先给出场景、数据规模、负载和阈值。AI 可以参与生成、维护 k6 脚本，但要先用小负载验证请求与业务检查，再执行约定负载。

性能结果应记录错误率、p95/p99、业务检查和运行条件。只有环境、数据、负载及资源条件一致，基线比较才有清晰的解释；测试环境结果也不能直接换算为生产容量。

最终，任务“执行结束”和业务“验证通过”分开记录。

必测项全部完成且通过、必需接口和性能检查达标，并满足项目缺陷条件，才把候选交付物标记为就绪。存在阻断缺陷、必测项未完成或关键结论待确认时，都要如实呈现。

V1 的默认终点是测试或验收环境，以及候选交付物。生产自动发布要在明确项目发布条件、目标环境和恢复方式后再接入。

05｜先拿到一次真实探索报告

实施顺序上，我准备先验证最不确定的一环：AI 能否在真实系统里稳定完成探索、做出有依据的判断，并留下可核查证据。

第一步，选一个试点项目，圈定 3～5 个代表性业务模块，条件允许时加入管理员和普通用户两类角色，直接连接现有测试环境。

提前准备正常场景和可复现的故障样例，例如必填校验失效、保存请求失败、数据没有持久化。观察 AI 能否实际执行、识别问题，并记录预期、实际结果和证据。

运行还需要明确的时长、工具调用和费用上限；写操作限定在约定测试数据范围。登录失败、工具中断、超时或清理失败，都应留下原因和剩余工作。

拿到这次报告后，再接入提交触发的构建部署，串起测试、报告和交付判定，最后尝试把配置与适配方式复用到第二个项目。

我希望先用试点回答这些问题：人工介入发生在哪里？哪些业务规则最难补齐？哪些错误能稳定复现？每轮耗时和模型开销是多少？

让每个结论都能回到规则、操作和证据，是这份方案最想先做扎实的事。

如果你也在尝试把 AI 接入交付流程，欢迎聊聊：你最想先验证页面探索、业务判定，还是运行稳定性？