对话 AI Agent 时代下的软件测试演变(一)

以下来自与 GPT-5.3 的对话

「【你说】」

我们来系统性探讨 AI Agent 时代下的软件测试。 在这个对话中，你需要以一名具备前瞻视角的技术战略专家进行思考：

• 不停留在表层结论，而是拆解底层逻辑与演化路径
• 关注范式变化（而不仅是工具变化）
• 给出结构化、可落地、具有长期价值的判断
• 在必要时对传统测试认知提出质疑甚至推翻 输出要求：
• 言简意赅，但信息密度高
• 有洞察、有判断，而不是罗列事实
• 尽量形成“模型 / 框架 / 一句话本质总结”

我们的目标不是理解现状，而是判断未来 3–5 年软件测试的本质变化。

「【ChatGPT 说】」

先把话说重一点：「如果你还把“测试”理解为验证代码正确性，那这个岗位在 3 年内会被边缘化。」

我们要讨论的不是“测试怎么做”，而是 「“在 Agent 时代，什么还需要被测试？”」

一、先给结论：测试的本质正在迁移

❝

「一句话本质：」「软件测试正在从「验证确定性系统」→「约束非确定性智能体」」

❞

传统软件 vs Agent 系统，本质差异：

👉 「结论：测试对象已经从“代码”变成“决策系统”」

二、范式转移：从 QA 到 “Behavior Governance”

未来 3–5 年，测试会分裂成三层（这是核心框架）：

1️⃣ Execution Correctness（执行正确性）—会被自动化吞掉

• 单测 / 接口测试 / UI 自动化
• Playwright、CI pipeline、AI 自动生成测试

👉 「趋势：」

• 人不再写测试用例
• AI 自动生成 + 自愈
• 覆盖率不再是核心指标

👉 「判断：」

❝

这是“基础设施层”，价值快速贬值

❞

2️⃣ System Reliability（系统可靠性）—转向工程能力

关键词：

• chaos engineering
• observability
• 分布式 tracing
• fallback / retry / guardrail

👉 Agent 系统新问题：

• Prompt 漂移
• 工具调用失败链式反应
• 长链 reasoning 崩溃

👉 测试不再是“测”，而是：

❝

「设计系统在失败时如何优雅失败」

❞

👉 「判断：」

❝

测试工程师 = SRE + AI系统工程师

❞

3️⃣ Behavior Alignment（行为对齐）—未来核心战场

这是最关键的变化。

Agent 的问题不是“对不对”，而是：

• 是否符合预期目标？
• 是否稳定表现？
• 是否在边界条件下失控？

👉 这本质上是：

❝

「“测试”升级为：约束智能体行为分布」

❞

三、核心新测试对象：不是功能，而是“策略空间”

传统测试：

input → output 是否符合预期

Agent 测试：

goal + context → policy → behavior distribution

👉 测试对象变成三件事：

1️⃣ Prompt / Policy 测试

• prompt 是否稳定？
• 不同 phrasing 是否导致行为漂移？

👉 本质：

❝

prompt = code（但不可控）

❞

2️⃣ Tool Use 测试

Agent 的真实能力来自工具调用：

• API 调用是否可靠？
• 是否误调用？
• 是否形成死循环？

👉 新测试点：

❝

「“决策链”而不是“接口”」

❞

3️⃣ Memory / State 测试

• 长期记忆污染
• 上下文遗忘
• 错误强化

👉 本质：

❝

系统是否在“学习错误”

❞

四、测试方法论的重构（重要）

未来不会再有“测试用例”，而是三种新范式：

1️⃣ Simulation Testing（仿真测试）

❝

构建一个世界，让 Agent 在里面“活”

❞

形式：

• 多 Agent 对抗
• 用户行为模拟
• 随机环境 perturbation

👉 类似：

• 自动驾驶仿真
• 游戏 AI 测试

👉 「结论：」

❝

测试从“验证函数” → “运行生态系统”

❞

2️⃣ Statistical Evaluation（统计评估）

你不再问：

❝

“这个 case 对不对？”

❞

而是问：

❝

“在 10,000 次运行中，错误率是多少？”

❞

指标：

• 成功率
• 幻觉率
• 工具调用正确率
• cost / latency

👉 「测试报告 = 数据科学报告」

3️⃣ Continuous Red Teaming（持续对抗）

• prompt injection
• 越权行为
• jailbreak

👉 测试角色变成：

❝

「攻击者 + 策略设计者」

❞

五、组织结构的变化（很现实）

未来团队不会再有“测试部门”，而是：

旧结构：

• Dev
• QA

新结构：

• AI Engineer（构建能力）
• Reliability Engineer（系统稳定性）
• Alignment Engineer（行为约束）

👉 QA 会被拆解吸收

六、关键误区（必须推翻）

❌ 误区 1：提高自动化覆盖率

👉 在 Agent 时代几乎无意义

❌ 误区 2：测试左移

👉 已经不够了

❝

正确说法是：「测试融入系统设计」

❞

❌ 误区 3：用例设计能力很重要

👉 会被 AI 完全替代

七、真正长期有价值的能力（给你重点）

你如果要做 3–5 年规划，只需要抓这 4 个能力：

1️⃣ 系统建模能力（最重要）

• 能抽象 Agent 的决策空间
• 能定义 failure mode

👉 这是“高级测试”的本质

2️⃣ 分布式系统 + SRE 思维

• fallback
• degrade
• retry 策略

3️⃣ 数据分析能力

• 设计评估指标
• 分析行为分布

4️⃣ 对抗思维（安全 + 红队）

• 找边界
• 构造极端 case

八、最终判断（给你一个压缩模型）

❝

「软件测试 = 从“验证代码” → “设计系统不出事的机制”」

❞

或者更狠一点：

❝

「未来没有测试工程师，只有“系统可信性工程师”」

❞

如果再往前推一步（更前瞻）

3–5 年后，最强的测试体系长这样：

• Agent 自己生成测试
• Agent 自己发现异常
• Agent 自己修复策略
• 人只负责：
• 定义目标函数（reward / constraint）

最后一刀（帮助你判断方向）

问你自己一个问题：

❝

「如果系统是“会思考的”，你还在测什么？」

❞

如果你的答案还是：

• 功能是否正确
• 页面是否正常

那方向已经错了。

如果你愿意，我们可以下一步深入一个更关键的问题：

👉 「“如何设计一套可落地的 Agent 测试体系（不是概念，而是工程方案）”」

「【你说】」

来吧，让我大开眼界、涨涨见识，不要妄图忽悠我，我作为一名多年的资深测试工程师，是能轻易识破你的逻辑漏洞的！

「【ChatGPT 说】」

很好，那我们就不讲概念，直接给你一套「能落地、能打、能被你挑刺的 Agent 测试体系」。我会刻意把容易“翻车”的地方也说出来。

一、先定边界：你到底在测什么？

先把问题收敛，否则体系必崩。

❝

「Agent 系统 = LLM + Tools + Memory + Policy」

❞

所以测试对象不是一个东西，而是四层：

1. LLM（推理能力）2. Tool（外部执行能力）3. Memory（状态演化）4. Policy（调度/策略）

👉 「关键判断：」

❝

80% 的问题不在 LLM，而在「Policy + Tool 交互」

❞

二、核心模型：四层测试架构（可落地版）

我给你一个工程上能实现的结构，不是PPT：

┌────────────────────────────┐│ Layer 4: Behavior Eval     │ ← 业务层：是否“像人”├────────────────────────────┤│ Layer 3: Trajectory Test   │ ← 决策链是否合理├────────────────────────────┤│ Layer 2: Tool Reliability  │ ← 工具调用是否稳定├────────────────────────────┤│ Layer 1: LLM Unit Eval     │ ← 模型能力基线└────────────────────────────┘

下面逐层拆（重点在“怎么做”）

三、Layer 1：LLM Unit Eval（很多人做错）

❌ 常见错误

• 用几个 prompt 测一下
• 人工看回答“还不错”

👉 这完全是错的，因为：

❝

LLM 是概率分布，不是函数

❞

✅ 正确做法：基线能力评估（Benchmark化）

你需要做三类 eval：

1️⃣ 能力边界测试（Capability Boundary）

例如：

• 推理深度（multi-hop）
• 指令遵循能力
• 长上下文稳定性

👉 做法：

• 构造「分级 difficulty 数据集」
• 看性能曲线，而不是单点结果

2️⃣ 稳定性测试（Stability）

同一个问题：

• paraphrase 10 次
• temperature 扰动

看输出波动：

variance(answer_quality)

👉 如果波动大：

❝

后面所有测试都是假象

❞

3️⃣ 幻觉率（Hallucination Rate）

关键点：

• 不是“有没有错”
• 是“自信地错”

👉 指标：

hallucination_rate = confident_wrong / total

四、Layer 2：Tool Reliability（这是第一个真实坑）

Agent 真正崩的地方在这里。

你必须测的不是 API，而是：

❝

「“LLM 是否在正确的时机调用正确的工具”」

❞

✅ 测试方法：Tool Use Matrix

构造一个矩阵：

核心指标：

precision = 正确调用 / 所有调用recall    = 正确调用 / 应调用

👉 很多人只测成功率，忽略误调用（这是大坑）

❗隐藏炸点（你可以重点质疑我）

Tool chaining failure

例子：

查航班 → 查天气 → 推荐

问题：

• 中间一步错了，后面全错
• Agent 不会回滚

👉 必测：

❝

「“中间失败是否被感知 & 修正”」

❞

五、Layer 3：Trajectory Test（核心创新点）

这是 Agent 测试和传统测试的分水岭。

你不再验证结果，而是验证：

❝

「“决策路径是否合理”」

❞

怎么落地？

1️⃣ 记录 Trajectory（必须做日志结构化）

{"step": 1,"thought": "...","action": "search","input": "xxx"}

2️⃣ 定义“好路径”

不是唯一答案，而是约束：

例如：

• 不应重复调用同一工具 > N 次
• 不应无意义搜索
• 必须先获取关键信息再决策

3️⃣ 自动判定（关键）

用规则 + LLM judge：

score = f(路径长度, 工具效率, 是否绕路, 是否失败恢复)

❗这里的本质突破：

❝

「测试对象 = 行为过程，而不是结果」

❞

六、Layer 4：Behavior Eval（最难，也最值钱）

这一层决定产品是否“像人”。

测什么？

• 是否符合业务目标
• 是否用户体验稳定
• 是否存在危险行为

✅ 方法：Simulation（必须上）

构建“用户模拟器”

不是写死脚本，而是：

❝

用另一个 LLM 作为用户

❞

形成对话：

User Agent ↔ Your Agent

然后测：

• 成功率
• 对话轮数
• 用户满意度（LLM judge）

❗关键陷阱：

LLM judge 偏差

👉 解决：

• 多模型投票
• 人类校准小样本

七、贯穿全局的三大基础设施（没有就别谈体系）

1️⃣ Eval Dataset（测试数据资产）

必须是：

• 可版本化
• 可扩展
• 覆盖边界 case

👉 本质：

❝

测试工程师 = 数据集工程师

❞

2️⃣ Observability（可观测性）

你至少要有：

• prompt 日志
• tool 调用链
• token 消耗
• 错误分类

否则：

❝

你根本不知道系统在干嘛

❞

3️⃣ Continuous Eval（持续评估）

每次改：

• prompt
• model
• tool

都要自动跑：

regression + distribution shift detection

八、最容易翻车的三个点（我替你先质疑）

❌ 1. “用 GPT 做 judge 就行”

问题：

• 偏见
• 不稳定
• 可被 prompt hack

👉 必须：

• 固定评估 prompt
• 多模型 cross check

❌ 2. “case 覆盖越多越好”

错。

❝

Agent 是无限输入空间

❞

👉 正解：

• 覆盖“决策模式”，不是 case

❌ 3. “可以完全自动化”

不行。

👉 人类仍然负责：

• 定义 reward
• 定义风险边界

九、给你一个最终工程化形态（可以直接想象 repo）

agent-test/├── datasets/│   ├── tool_use/│   ├── reasoning/│   └── adversarial/├── evals/│   ├── llm_eval.py│   ├── tool_eval.py│   ├── trajectory_eval.py│   └── behavior_eval.py├── simulator/│   └── user_agent.py├── metrics/│   └── scoring.py└── dashboard/    └── eval_report

十、最后给你一个“压缩到极致”的认知模型

❝

「传统测试：找 bug」

「Agent 测试：限制系统不要变成“危险的随机体”」

❞

或者更狠一点：

❝

「你不是在验证正确性，你是在控制“失控概率”」

❞

如果你还想继续深挖（建议下一步）

我们可以继续拆一个更硬核的问题：

👉 「“如何设计一套 Agent 测试指标体系（避免 KPI 失真）”」

这个问题如果搞不清楚，整个测试体系会变成“看起来很科学，但其实在自欺欺人”。

「【你说】」

我觉得你说的很好，可能确实很有前瞻性，但我还是有一个很大的疑问。即使是 Agent 正确地毫无偏差地编写出了代码，但最终由谁来保证功能被正确地实现了？

「【ChatGPT 说】」

这个问题问得很关键，而且可以说是「整个 Agent 时代测试体系的“地基问题”」。

我先给你一个不太舒服、但必须接受的结论：

❝

「“代码写对 ≠ 功能实现对”这个问题，从来没有被彻底解决过；Agent 时代只是把它放大了。」

❞

一、先拆穿一个隐含前提

你问题里有一个默认前提：

❝

“只要代码是正确的，就应该实现正确的功能”

❞

这个前提在现实里一直是错的。

传统软件的问题其实是：

需求（模糊） → 代码（精确）

测试的职责，本质是：

❝

「弥补“需求表达不完备”带来的不确定性」

❞

到 Agent 时代，问题变成：

意图（更模糊） → Agent（解释） → 代码（精确）

👉 多了一层：

❝

「Agent 对“意图”的理解」

❞

二、核心断裂点：谁对“正确性”负责？

你问的是：

❝

谁保证功能被正确实现？

❞

我反问你一个更底层的问题：

❝

「“正确”是由谁定义的？」

❞

在 Agent 时代，这个链条变成：

Human Intent   ↓Spec（弱化甚至消失）   ↓Agent Interpretation   ↓Code   ↓Runtime Behavior

👉 每一层都可能错：

• 意图表达错
• Agent 理解错
• 代码实现错
• 系统运行偏离

三、结论：不会再有“单一责任人”

传统模式：

• Dev：写代码
• QA：验证功能

👉 有清晰边界

Agent 模式：

❝

「正确性 = 多层系统的“涌现属性”」

❞

没有人能“保证”，只能：

❝

「通过系统设计，把错误概率压到可接受范围」

❞

四、那测试到底还干什么？（核心回答）

你这个问题的真正答案是：

❝

「测试不再“保证正确”，而是“验证意图是否被保真地转译”」

❞

五、落地：如何验证“功能真的被实现”？

我给你一个工程上可执行的三层闭环：

1️⃣ Intent → Spec（意图具象化）

👉 必须做的一步（很多团队忽略）

不要直接让 Agent 写代码，而是：

用户意图 → Agent 生成 Spec（结构化）

例如：

{"feature": "用户登录","constraints": ["密码错误 5 次锁定","支持邮箱登录"  ],"edge_cases": ["SQL 注入","弱密码"  ]}

👉 「关键点：」

❝

先测 Spec，再测代码

❞

2️⃣ Spec → Code（传统测试仍然存在，但被重构）

这一步其实你很熟：

• 单测
• 接口测试
• E2E

👉 但变化是：

❝

「测试用例由 Agent 生成 + 人类约束」

❞

3️⃣ Behavior → Intent（闭环验证，最关键）

这是你问题的真正答案所在。

做法：反向验证（Back-validation）

运行系统 → 观察行为 → 判断是否符合最初意图

怎么做？

方法 1：Scenario Simulation（场景仿真）

构造真实使用路径：

• 正常路径
• 边界路径
• 恶意路径

👉 看系统是否符合：

❝

「用户真实目标，而不是代码逻辑」

❞

方法 2：LLM as Judge（但要克制用）

让模型判断：

“这个行为是否满足最初需求？”

但要：

• 多模型投票
• 固定 prompt
• 人工校准

方法 3：Invariant Testing（最重要）

定义“永远不能错”的东西：

例如：

• 钱不能变少/变多
• 权限不能越权
• 数据不能丢

∀ 行为 ∈ 系统：    invariant 必须成立

👉 这是未来测试的“锚点”

六、一个你可以攻击我的点（我先说出来）

你可能会说：

❝

“这些方法仍然不能保证 correctness”

❞

对，这是事实。

七、更深一层的结论（也是最终答案）

❝

「在复杂系统中，“功能正确”不是可证明的，而是可观测、可约束、可逼近的」

❞

八、给你一个压缩模型（你可以拿去用）

正确性 = Spec 完整性       × Agent 理解一致性       × 实现可靠性       × 行为约束强度

👉 任何一项为 0，系统必错

九、真正的角色变化（说人话版）

未来你不再是：

❝

“验证功能的人”

❞

而是：

❝

「“定义什么叫对，并设计系统持续逼近它的人”」

❞

十、最后一句（我认为最关键）

❝

「Agent 时代没有人能保证“功能正确”，只能保证“系统不会在错误中失控太远”」

❞

如果你愿意，我们可以继续往下挖一个更“致命”的问题：

👉 「“如果连 Spec 都是 Agent 生成的，那正确性是不是彻底失去了锚点？”」

这个问题一旦想清楚，你对测试的理解会彻底换一套体系。

「【你说】」

你的观点发人深思。我非常认可“软件功能正确”不是可被证明的。 我先从一个和传统测试更贴近我更熟悉的点来进行提问：就是“测试用例由 Agent 生成：这个部分。 你觉得 Agent 要生成什么样的用例，最终由于谁来执行，对于长流程&业务复杂的系统，前置的复杂数据依赖又应该如何解决？

「【ChatGPT 说】」

很好，这一问开始真正进入“工程落地的硬骨头”了。如果这一层搞不清楚，前面所有 Agent 测试体系都会沦为 PPT。

我先给一个结论压住全局：

❝

「Agent 生成的不是“测试用例”，而是“可执行的验证策略（Verification Strategy）”」

❞

这不是措辞优化，是范式变化。

一、先拆掉“测试用例”这个概念

传统测试用例：

前置条件 → 步骤 → 预期结果

问题在 Agent 时代会爆炸：

• 前置条件极其复杂（数据、状态、上下文）
• 步骤路径不唯一
• 结果不再是单点，而是分布

👉 所以：

❝

「“用例”这种线性结构，不足以描述复杂系统验证」

❞

二、Agent 应该生成什么？（核心回答）

不是用例，而是三层结构：

1. Intent Model（测什么）2. Scenario Generator（怎么覆盖）3. Oracle（怎么判定对错）

1️⃣ Intent Model（测试目标建模）

Agent 首先要做的是：

❝

「把需求转成“可验证目标空间”」

❞

例如（不是用例，而是约束）：

{"goal": "订单系统正确处理支付","invariants": ["支付成功 → 订单状态必须为已支付","重复支付不能重复扣款"  ],"risk_points": ["并发支付","超时回调","支付失败重试"  ]}

👉 关键点：

❝

「从“测路径” → “测约束 + 风险空间”」

❞

2️⃣ Scenario Generator（场景生成器）

Agent 不生成一个 case，而是生成：

❝

「一类场景的生成规则」

❞

例如：

运行defgenerate_payment_scenarios():for concurrency in [1, 5, 10]:for retry in [0, 1, 3]:yield Scenario(concurrency, retry)

👉 本质：

❝

「从“枚举 case” → “生成 case 分布”」

❞

3️⃣ Oracle（判定机制）

这是最容易被忽略的。

传统：

• assert ==

Agent 时代：

❝

「Oracle = 规则 + 模型 + 不变量」

❞

例如：

if money_changed and not expected:    FAILif LLM_judge(answer, spec) < threshold:    FAIL

三、谁来执行？（关键分层）

执行必须分裂，否则一定崩：

1️⃣ 确定性部分 → 机器执行（CI / 测试框架）

• 接口调用
• UI 操作（Playwright）
• 数据校验

👉 没争议，这部分继续自动化

2️⃣ 非确定性部分 → Agent 执行

例如：

• 动态构造输入
• 决定下一步操作
• 探索未知路径

👉 这里 Agent 是“测试执行器”

3️⃣ 判定（Oracle）→ 混合执行

• 硬规则 → 机器
• 软判断 → LLM
• 高风险 → 人类抽检

👉 「人类不再执行测试，而是校准系统」

四、长流程 & 复杂业务：真正难点来了

你问的这个问题，90%团队会死在这里。

本质问题不是“流程长”，而是：

❝

「状态空间爆炸 + 数据依赖复杂」

❞

五、解决方案核心：三件事（缺一不可）

1️⃣ 状态建模（State Modeling）

你必须把系统抽象成：

State + Transition

例如订单系统：

Created → Paid → Shipped → Completed

👉 测试不再是跑流程，而是：

❝

「验证状态转换是否合法」

❞

2️⃣ 数据工厂（Test Data Factory）

必须有：

❝

「“按需生成业务数据”的能力，而不是写死数据」

❞

两种模式：

✅ 模板化数据

{"user": "new_user()","order": "unpaid_order()"}

✅ 依赖图生成（推荐）

Order ├── User ├── Product └── Inventory

👉 自动生成依赖链

❗关键点：

❝

「测试数据必须“可组合”，而不是“预制”」

❞

3️⃣ 流程切片（Flow Slicing）

长流程不要从头跑。

👉 拆成：

登录 → 下单 → 支付 → 发货

每一段：

• 独立可执行
• 可注入状态

👉 关键能力：

❝

「任意状态启动（State Injection）」

❞

例如：

• 直接构造“已支付订单”
• 跳过前面流程

六、Agent 在这里的真实作用（别高估）

Agent 不负责：

• 精准构造复杂数据（容易翻车）
• 100% 覆盖路径（不现实）

Agent 负责：

❝

「探索 + 生成 + 扰动」

❞

例如：

• 随机组合场景
• 改写输入
• 尝试异常路径

七、一个完整执行流（给你一个可以落地的）

1. Agent 生成 Intent Model2. Agent 生成 Scenario Generator3. 数据工厂生成数据4. 执行引擎跑流程（可部分 Agent 控制）5. Oracle 判定结果6. 汇总统计指标

八、你可以重点挑战我的一个点

❝

“数据工厂 + 状态注入成本太高，不现实”

❞

✔️ 这是对的。

九、现实世界的折中解（很重要）

不要一开始就做完整系统：

优先级建议：

1. 核心链路（支付 / 权限） → 完整建模
2. 次要功能 → 传统自动化 + Agent 补充
3. 长尾 → 完全交给 Agent 探索

十、最后给你一个压缩认知模型

❝

「测试用例 = 低维离散点（过时）」

「Agent 测试 = 高维空间采样 + 约束验证」

❞

或者一句更狠的：

❝

「你不再设计“测试路径”，而是在定义“系统在哪些区域绝不能出错”」

❞

如果继续深入（下一刀）

我们可以直接进入一个更难但更关键的问题：

👉 「“如何设计 Test Data Factory + State Injection 体系（避免成为测试瓶颈）”」

这个一旦设计错，整个 Agent 测试体系会被数据拖死。

「【你说】」

你说到点子上了！开始你的 show time！

「【ChatGPT 说】」

好，那这一段我不讲“理念”，直接给你一套「能在真实复杂系统里活下来的 Test Data Factory + State Injection 体系设计」。

我会先给一个结论压住全局：

❝

「测试数据问题本质不是“构造数据”，而是“控制系统状态空间的入口”」

❞

你一旦这么理解，很多设计就自然了。

一、先拆掉一个致命误区

大多数团队的数据方案是这样的：

准备一批测试账号 + 测试订单 + 测试数据表

然后：

• 用例依赖这些数据
• 数据被污染
• 并发冲突
• 回归不稳定

👉 「本质问题：」

❝

数据是“静态资源”，但系统是“动态演化的”

❞

二、正确抽象：数据 ≠ 数据，而是「状态构造器」

你真正需要的是：

State = 数据 + 时间 + 外部条件 + 副作用历史

👉 所以：

❝

「Test Data Factory 本质是：State Factory（状态工厂）」

❞

三、核心架构（可以直接落地）

┌─────────────────────────────────┐│   State Request (测试需要什么状态) │└──────────────┬──────────────────┘               ↓┌─────────────────────────────────┐│   State Builder（状态构建器）     │├──────────────┬──────────────────┤│ Data Layer   │ Dependency Graph ││ 数据生成      │ 依赖解析           │├──────────────┴──────────────────┤│   State Injection（状态注入）     │└─────────────────────────────────┘

四、第一核心：State DSL（必须有）

你不能再写“创建用户+创建订单”，而是要有一套声明式语言：

示例（关键）

state:user:type:new_userorder:status:PAIDamount:100payment:retries:2

👉 这段的意思不是“怎么创建”，而是：

❝

「“我要一个已经支付完成，但经历过2次重试的订单状态”」

❞

关键点：

• 不描述过程（how）
• 只描述目标状态（what）

五、第二核心：Dependency Graph（真正难点）

复杂系统的问题在这里：

Order ├── User ├── Product ├── Inventory └── Payment

❌ 错误做法：

手写创建顺序

✅ 正确做法：

❝

「自动解析依赖图 + 自动构建」

❞

伪代码：

运行defbuild_state(state_spec):    deps = resolve_dependencies(state_spec)    ordered = topo_sort(deps)for node in ordered:        create(node)

关键能力：

👉 「幂等 + 可重复执行」

否则 CI 会炸

六、第三核心：State Injection（这是分水岭）

你如果还在“走流程造数据”，基本已经输了。

三种注入方式（按成熟度排序）

1️⃣ API 注入（基础版）

• 调内部接口创建数据
• 例如：createOrder()

👉 问题：

• 慢
• 受业务逻辑限制

2️⃣ DB 注入（进阶版）

• 直接写数据库
• 绕过业务流程

👉 问题：

• 容易破坏约束
• 不真实

3️⃣ Hybrid Injection（推荐）

❝

「部分走 API，部分直写 DB」

❞

原则：

❗关键能力：

❝

「“任意状态可构造”」

❞

否则：

• 长流程测试永远慢
• 覆盖永远不全

七、第四核心：状态快照（Snapshot）

这是提升 10 倍效率的关键。

思路：

构造一次复杂状态 → 保存 → 重复使用

示例：

snapshot: paid_order_with_retry

使用：

use_snapshot:paid_order_with_retrymutate:retry_count:3

👉 本质：

❝

「从“生成数据” → “复用状态”」

❞

八、第五核心：Agent 在数据体系里的角色

这里很容易走偏，我帮你校准：

❌ 不要让 Agent 做：

• 精确构造数据（不稳定）
• 直接写 DB（危险）

✅ Agent 应该做：

1️⃣ 生成 State Spec

goal:测试重复支付→自动生成statespec

2️⃣ 扰动状态（fuzzing）

amount:[0,-1,999999]retry:[0,1,10]

3️⃣ 发现“缺失状态”

👉 例如：

❝

“没有测试部分退款 + 并发支付”

❞

九、解决你最关心的问题：长流程

传统：

登录 → 下单 → 支付 → 发货（全跑）

新范式：

直接构造：“已支付订单”

然后只测：

支付 → 发货

👉 本质：

❝

「流程测试 → 状态跃迁测试」

❞

十、你可以质疑的点（我先说）

❗问题 1：实现成本极高

✔️ 对

❗问题 2：容易和真实环境偏离

✔️ 对

十一、现实落地策略（关键）

不要一步到位，分三阶段：

Phase 1（2–4 周）

• 简单 Data Factory（函数式）
• 少量状态注入

Phase 2（1–2 月）

• 引入 State DSL
• 构建 Dependency Graph

Phase 3（3–6 月）

• Snapshot
• Agent 参与生成
• 覆盖复杂场景

十二、最终给你一个压缩模型

❝

「测试数据系统 = 状态空间控制系统」

❞

或者更狠一点：

❝

「谁控制了“状态构造能力”，谁就控制了测试效率上限」

❞

最后一刀（真正的洞察）

你以为你在解决“测试数据问题”，其实你在做的是：

❝

「给复杂系统增加一个“可逆的入口”」

❞

如果你还想继续深挖，我们可以进入最难的一层：

👉 「“如何设计 State DSL，让它既通用又不会失控（避免变成第二套业务系统）”」

这个问题一旦设计不好，你的整个体系会因为“抽象过度”而崩掉。

「【你说】」

给出你简明扼要的设计！

「【ChatGPT 说】」

好，我直接给你一套「可用、克制、不失控的 State DSL 设计最小闭环」。没有花活，核心是“够用 + 不爆炸”。

一、设计目标（一句话）

❝

「用最少的抽象，表达“我想要什么状态”，而不是“怎么构造它”」

❞

二、DSL 最小结构（必须控制在 4 个元素内）

state:### 要什么use:### 复用已有状态override:### 覆盖差异check:### 可选断言（轻量 oracle）

👉 「只允许这 4 个字段，超过就会失控」

三、核心语义（每个字段的“边界”）

1️⃣ state（声明目标状态）

只描述“结果”，禁止描述过程

state:order:status:PAIDamount:100user:type:NEW

✅ 表达的是：

❝

“我要一个已支付订单 + 新用户”

❞

❌ 不允许：

create_user:truecall_api:xxx

2️⃣ use（状态复用）

避免重复构造复杂状态

use:paid_order_base

👉 约束：

• 必须是「稳定快照」
• 不允许嵌套超过 2 层

3️⃣ override（差异注入）

只允许“改值”，不允许改结构

override:order:amount:999

👉 关键限制：

• 不允许新增字段
• 不允许删除字段

❝

否则 DSL 会变成“编程语言”

❞

4️⃣ check（轻量断言）

只做最关键的 invariant，不做复杂逻辑

check:-order.status=="PAID"-payment.count<=1

👉 作用：

• 防止构造错误状态
• 不是完整测试断言

四、底层约束（防止 DSL 失控的关键）

1️⃣ 禁止循环依赖

A → B → A ❌

👉 必须 DAG（有向无环）

2️⃣ 限制表达能力（非常重要）

DSL 「不能有」：

• if / else ❌
• for 循环 ❌
• 任意函数 ❌

👉 原则：

❝

「DSL 不是编程语言，只是声明语言」

❞

3️⃣ 状态粒度必须受控

禁止：

state:system:everything

必须：

state:order.status:PAID

👉 「粒度越粗，越不可控」

五、一个完整示例（你可以直接落地）

use:paid_order_baseoverride:payment:retry_count:2order:amount:200check:-order.status=="PAID"-payment.retry_count==2-order.amount==200

👉 表达：

❝

在“已支付订单”基础上，构造一个“重试2次 + 金额200”的状态

❞

六、执行引擎（必须配套，否则 DSL 没用）

DSL 本身很简单，关键在执行：

执行流程

1. 解析 use → 加载 snapshot2. merge state3. apply override4. 构建 dependency graph5. 注入状态（API / DB / Hybrid）6. 执行 check（fail fast）

核心函数（伪代码）

运行defbuild(dsl):    base = load_snapshot(dsl.use)    target = merge(base, dsl.state)    target = apply_override(target, dsl.override)    graph = resolve_dependency(target)    inject(graph)assert check(target)

七、Agent 如何接入（控制边界）

Agent 只允许做两件事：

1️⃣ 生成 DSL

goal:测试重复支付→自动生成DSL

2️⃣ 扰动 override

override:amount:[-1,0,999999]

❌ 禁止 Agent：

• 修改 dependency graph
• 写注入逻辑
• 直接操作 DB

八、设计哲学（防止你走歪）

原则 1：80% 场景覆盖即可

不要追求 DSL 表达一切

原则 2：复杂逻辑下沉到代码层

DSL 只做声明：

DSL（what） → Engine（how）

原则 3：宁可不优雅，也不要失控

九、最终压缩模型（你可以直接用来评审设计）

❝

「好的 State DSL =」

「最小表达力 + 强约束 + 可组合 + 不可编程」

❞

十、最后一刀（帮你守住边界）

如果你的 DSL 出现了这些迹象：

• 开始支持条件判断
• 开始写循环
• 可以调用函数

👉 立刻停下来。

因为：

❝

「你正在重写一个“影子业务系统”，而它一定会失控」

❞

如果你下一步想继续，我建议我们直接进入：

👉 「“如何设计 Dependency Graph & 注入策略（保证状态构造既快又真实）”」

这一层，才是决定你这套体系能不能在生产级系统活下来的关键。

「【你说】」

给出你的设计，确保真正可落地！

「【ChatGPT 说】」

好，我们把最后一块“最容易写成 PPT、最难真正落地”的东西钉死：

❝

「Dependency Graph + State Injection：如何做到“既真实、又快、还能长期维护”」

❞

我直接给你一套「工程级设计（含约束 + 实现策略 + 取舍）」，你可以对着现有系统一点点替换。

一、核心原则（先定死边界）

❝

「状态构造必须满足三个目标：」

1. 「快」（秒级，而不是分钟级）
2. 「真」（符合业务约束，不是伪数据）
3. 「稳」（幂等 + 可重复）

❞

三者冲突时：

❝

「优先级：稳 > 真 > 快」

❞

二、Dependency Graph 设计（核心骨架）

1️⃣ Graph 的最小抽象（不要过度建模）

Node = 一个“业务实体”Edge = “依赖关系”

示例（订单系统）

Order ├── User ├── Product ├── Inventory └── Payment

❗关键约束：

✅ 每个 Node 必须满足：

1. 可独立创建（create）2. 可查询（get）3. 可幂等（idempotent）

2️⃣ Node 定义（工程落地）

直接用代码结构，不搞复杂 DSL：

运行classOrderNode:    depends_on = ["User", "Product"]defcreate(self, spec):### 可以走 API 或 DBreturn order_iddefready(self, state):return state.get("order_id") isnotNone

3️⃣ Graph 构建（自动化）

运行defresolve_graph(state_spec):    nodes = extract_entities(state_spec)return topo_sort(nodes)

👉 必须保证：

• 无环（启动时校验）
• 顺序稳定（否则测试不稳定）

三、State Injection（核心差异点）

关键结论（先说死）

❝

「不能纯 API，也不能纯 DB，必须 Hybrid」

❞

四、Hybrid Injection 策略（可执行标准）

1️⃣ 分类策略（这是关键设计）

把所有数据分三类：

判断标准（非常实用）

是否有复杂业务校验？→ 有：API→ 没有：DB

2️⃣ 注入流程（标准执行链）

1. 构建依赖节点2. 优先创建强约束（API）3. 补充弱约束（DB）4. Mock 外部依赖5. 校验状态完整性

3️⃣ 示例（真实可落地）

Step 1：创建用户（DB）

运行user_id = db.insert("user", {...})

Step 2：创建订单（API）

运行order_id = api.create_order(user_id)

Step 3：修改状态（DB 注入）

运行db.update("order", {"status": "PAID"})

Step 4：模拟支付回调（Mock）

运行mock_payment_callback(order_id)

👉 最终状态：

❝

一个“真实链路 + 快速构造”的已支付订单

❞

五、幂等设计（不做这个一定炸）

核心问题：

CI 并发跑测试时：

• 数据冲突
• 重复创建
• 状态污染

解决方案：三层幂等

1️⃣ 命名空间隔离（强制）

test_run_id = uuid

所有数据：

user_email = test_run_id + "@test.com"

2️⃣ Node 幂等（必须）

运行defcreate(self, spec):    existing = find_by_unique_key(spec)if existing:return existingreturn create_new()

3️⃣ 状态校验（最后兜底）

运行assert current_state == expected_state

六、性能优化（否则你会被骂慢）

1️⃣ Snapshot（必须做）

复杂状态：

构造一次 → dump DB → 复用

2️⃣ 分层缓存

L1: 内存（当前测试）L2: Redis（跨测试）L3: DB snapshot

3️⃣ 并行构建（Graph 级别）

运行parallel_execute(independent_nodes)

👉 条件：

• 无依赖冲突
• DB 支持并发

七、失败恢复机制（90%团队没做）

问题：

中间节点失败 → 整个构造失败

解决：

运行try:    create(node)except:    rollback_partial_state()

或：

失败 → 标记脏数据 → 下次跳过

八、可观测性（否则你根本调不动）

必须记录：

{"node": "Order","action": "create","method": "API","latency": 120ms,"result": "success"}

👉 否则：

❝

出问题你根本不知道卡在哪

❞

九、最小可落地版本（给你现实路径）

第一阶段（1–2 周）

• 手写 Node（3–5 个核心实体）
• 简单 topo 排序
• API + DB 混用

第二阶段（1 月）

• 引入 DSL
• 加幂等机制
• 支持 snapshot

第三阶段（2–3 月）

• Agent 生成 state
• 自动扰动测试
• 指标体系

十、最终压缩模型

❝

「Dependency Graph = 定义“构造顺序”」

「State Injection = 定义“如何作弊但不被发现”」

❞

最后一刀（真正工程洞察）

你会发现：

❝

「最难的不是“怎么造数据”，而是“在哪些地方可以不走真实流程”」

❞

👉 做对了：

• 测试快 10 倍
• 覆盖提升一个数量级

👉 做错了：

• 数据不可信
• 测试全部失效

如果你还想继续（最后一层）

可以进入真正“顶级测试工程师”才会思考的问题：

👉 「“如何定义哪些数据必须真实流转，哪些可以被‘伪造’（Mock / Injection 边界）”」

这个问题，本质上是：

❝

「你对系统“真实性边界”的理解深度」

❞