前言

最近在尝试把 AI 用在测试工作中，一开始想到的是：

• AI 生成测试用例

• AI 写自动化脚本

• AI 写测试报告

这些确实可以提升效率，但用下来会发现一个问题：

这些更多是“提效”，而不是“解决问题”。

测试工作里真正的痛点，其实并不是写用例慢。

而是：

• 需求文档看了还是懵

• 系统是怎么实现的并不清楚

• 代码、数据库很多时候也没有权限

• 很多逻辑只有功能做出来后才真正理解

• 很容易漏测

换句话说：

测试最大的困难，其实是 理解系统太慢。

所以后来慢慢意识到，感觉AI 在测试领域最有价值的地方，并不是写用例，而是帮助测试工程师：

更快理解系统、识别风险，并让经验沉淀下来。

一、测试最核心的能力，其实是“系统理解”

我们理解测试是这样的：

需求 → 写用例 → 执行测试 → 提 Bug

但工作中，真正影响测试质量的，是对系统的理解程度。

例如一个下单流程。

如果只是从功能角度理解：

下单 → 支付 → 成功

测试点可能就是：

• 下单成功

• 支付成功

• 订单状态正确

如果从系统角度理解：

用户
↓
订单服务
↓
库存服务
↓
优惠券服务
↓
支付服务

测试思路就会完全不同：

• 库存并发问题

• 优惠券叠加逻辑

• 支付失败回滚

• 状态同步问题

很多关键 Bug，其实都是在 系统层面 出现的，而不是简单功能错误。

二、为什么测试理解系统会很慢？

在很多公司里，测试会遇到一些非常现实的限制：

• 看不到代码

• 数据库权限有限

• 架构文档不完整

• 需求文档偏业务视角

于是测试理解系统通常是这样：

需求 → 操作系统 → 推测逻辑

也就是说：

测试很多时候是在“猜系统”。

这也是为什么经常会有一种感觉：

功能做出来后，才真正理解这个系统。

三、通过 Bug 反推系统

在之前的工作中，我有一个习惯：

接手一个新项目时，会先看历史 Bug。

一个 Bug 单里通常会包含很多信息：

• 复现步骤

• 测试流程

• 错误截图

• 日志信息

• 开发修改方案

这些信息组合起来，其实可以反推出：

• 业务流程
• 服务调用
• 异常逻辑

例如一个 Bug：

退款后库存没有恢复

通过 Bug 信息，可以推断：

订单流程
↓
库存服务
↓
退款逻辑

所以 Bug 其实是一个非常重要的信息源。

因为：

Bug 往往暴露的是 系统最复杂、最脆弱的地方。

通过历史 Bug，能很快发现系统的高风险模块。

四、理解系统，需要三个信息

发现理解一个系统，最关键的其实是三件事：

1、关键业务流程

例如：

• 注册
• 下单
• 支付
• 退款

2、服务调用关系

例如：

• 订单服务
• 库存服务
• 优惠券服务
• 支付服务

3、历史 Bug

例如：

• 库存并发
• 优惠券叠加
• 退款状态同步

如果把这三样东西串起来，其实就能形成一张：

系统地图。

五、AI 在测试领域真正的价值

当我们把问题看清楚之后，会发现：

AI 最有价值的地方是：

1、AI辅助需求理解

需求 → 输出业务流程

例如：

下单
→ 库存锁定
→ 支付
→ 发货

帮助测试更快理解系统。

---

2、AI辅助系统建模

通过接口信息、日志信息，整理出：

服务调用关系

例如：

• order-service
• inventory-service
• payment-service

形成系统结构。

---

3、AI辅助风险分析

通过历史 Bug，总结出：

高风险模块

例如：

• 库存并发
• 优惠券叠加
• 退款状态同步

这样测试设计就会更有方向。

六、从“写用例”到“理解系统”

很多都在强调：

• 用例设计

• 自动化测试

• 性能测试

但测试能力的提升，其实更像这样一个过程：

需求理解
↓
系统建模
↓
风险分析
↓
测试设计
↓
经验沉淀

而 AI 的价值，在于帮助测试工程师：

更快完成前面的三步。

结语

很多人讨论 AI 测试时，都会把重点放在：

• 自动生成用例

• 自动化测试

• 提升效率

但我觉得重要的一点是：

AI 可以帮助测试工程师 更快理解系统、识别风险，并让经验沉淀下来。

这比提效更有价值。

接下来也会继续尝试把这些思路逐步落地，例如：

• 利用 AI 辅助需求分析

• 通过历史 Bug 构建风险模型

• 建立自己的测试知识库

慢慢把这些经验沉淀下来。