AI 工具的形态

传统 AI工具

特点：只动口，不动手

比如你想 do something，

Agent（智能体）

特点：既动脑，又动手

如代码智能体

动脑：自己规划要做啥

动手：具有一定执行能力

如openclaw

个人助理，对机器具有较高操作权限，能够保存文件，使用电脑上的一些工具等

传统软件测试的瓶颈

重复劳动： 大量的回归测试、重复的UI点击，耗费人力且容易倦怠。

用例编写效率低： 依赖个人经验，覆盖不全，容易出现漏测。

数据构造和分析： 测试数据构造和检查具有较大成本；问题定位分析定位慢

自动化维护成本： 自动化脚本随开发代码变动频繁失效，维护代价高昂。

当上游使用 AI 相关能力快速交付，测试的压力山大

AI 带来的机会

AI 的优势

• 具有较好的代码能力，如 代码补全和生成
• 具有一定的分析和总结能力，如 文档总结、通过知识库问答
• 能够学习，不断通过外部信息和工具增强自己
• 无限生成，不知疲倦

AI 的风险：

• 幻觉，胡说八道
• 冗余，生成过多的信息，不精准
• 缺失，缺乏领域知识或者内部业务知识；上下文限制，全部信息
• 不同模型的能力层次不齐

目前研发戒断中， AI 辅助编程是比较成功的领域：

可以继续探索和挖掘的阶段：

主要利用了模型的分析能力、总结能力、代码生成等能力

一些 AI 在测试活动中的使用场景

造数

数据生成

比如

由 AI 编写造数 SQL

由 AI 编写造数脚本

直接让 AI 帮你造数

测试工具编写

本质是使用代码生成能力，使用 AI 去实现造数工厂，实际工作时，前后端是同时编写的，再+一个测试进行检查

当工具足够多，可以考虑使用 AI 进行编排调度 货拉拉数据工厂：从3k+工具到AI智能体，我们如何让造数效率翻倍？

测试结果检查

数据提取和比较

AI 能帮助进行数据识别和提取，可以辅助进行数据检查，尤其是需要进行格式转换或者对齐的时候效率比人高

数据的自动校验

用例执行完，往往需要对结果，如数据库字段进行检查

当智能体具有 mysql 查询能力，那么可以帮我们根据指定规则进行校验

一些复杂校验可以使用 agent+MCP+skill 能力， workflow 和规则包装成 skills：

• 使用到 mysql mcp（让 agent 能够操作数据库）
• skills（定义了如何校验以及如何返回）

before:

如果检查的逻辑比较复杂，同时每一次执行都需要做检查

after:

自动校验再加上上面提到的自动执行操作，实际上就是一个能自动执行用例的测试智能体了

简单的用例生成

给定多模态信息去简单生成用例，用例生成比代码生成难很多：

1. 通常测试脚本的代码能用就行，用例需要符合一定的规范
2. 用例不能遗漏 也不能过多
3. 需要理解业务和逻辑

以最近一个项目中售后列表功能为例

经过生成和简单调教，如约定要用 ms 的格式，生成的文件直接生成 xmind

但还有一些需要改进的点，比如用例标题 路径不清晰，前置条件里 使用的数据没有放进去

修改后好一些，但还是有一些需要人工 check 的地方，如 xxxx；用例优先级定义也不对；要么继续调教制定规则，要么改用手工修改

需要自己去制定规则（rule）和 sop（skill）

代码分析和梳理

代码分析

对一些不熟悉的应用或代码语言（如前端/小程序的代码），可以让 AI 查找代码

代码逻辑梳理/review

对复杂代码逻辑进行梳理，生成梳理文档/流程图

但注意有可能会遗漏一些细节，很多是上下文限制导致的

---

甚至可以对一块逻辑进行静态运行，分析结果是如何计算出来的

如断货重分配算法

报告分析和增强

通过对 jacoco 覆盖率文件进行分析，对于覆盖率报告进行增强，同理也可考虑对其他类型测试报告进行增强，如项目分析

现在我已经成功分析了 jacoco.xml 文件的覆盖率情况，让我为你提供详细的覆盖率报告：

## 覆盖率分析报告
### 总体情况
- 分析文件数 ：5 个源文件
- 完全覆盖 ：2 个文件 (40%)
- 部分覆盖 ：1 个文件 (20%)
- 未覆盖 ：2 个文件 (40%)
### 详细覆盖率数据
1. PasswordUtil.java (com/cicc/ut/util)
   
   - 行覆盖率：100% (2/2 行)
   - 分支覆盖率：0% (0/0 分支)
   - 状态：完全覆盖
2. UserServiceImpl.java (com/cicc/ut/service/impl)
   
   - 行覆盖率：89.58% (43/48 行)
   - 分支覆盖率：66.67% (4/6 分支)
   - 状态：部分覆盖
   - 未覆盖行：33, 67, 69, 71, 72
   - 未覆盖分支：67
   - 部分覆盖分支：32
3. Constants.java (com/cicc/ut/constants)
   
   - 行覆盖率：0% (0/0 行)
   - 分支覆盖率：0% (0/0 分支)
   - 状态：未覆盖
4. AuthException.java (com/cicc/ut/exceptions)
   
   - 行覆盖率：100% (2/2 行)
   - 分支覆盖率：0% (0/0 分支)
   - 状态：完全覆盖
5. UserService.java (com/cicc/ut/service)
   
   - 行覆盖率：0% (0/0 行)
   - 分支覆盖率：0% (0/0 分支)
   - 状态：未覆盖
### 分析结论
1. 核心业务逻辑 ：UserServiceImpl.java 作为核心服务实现类，覆盖率达到了 89.58%，说明大部分业务逻辑已经被测试覆盖。
2. 工具类和异常类 ：PasswordUtil.java 和 AuthException.java 完全覆盖，说明这些辅助类的测试覆盖情况良好。
3. 接口和常量 ：UserService.java 和 Constants.java 没有覆盖，这是正常的，因为接口通常没有具体实现，常量类通常也不需要测试。
4. 改进空间 ：UserServiceImpl.java 还有 5 行代码未覆盖，特别是 67-72 行的逻辑，建议增加相应的测试用例。

其他一些工作场景

排期

审工单、jira 工时估计、面试设计