AI 在工作中的一些使用

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 工时估计、面试设计