Guide

AI 火起来已经有好一段时间呢，我这边简单整理了下我以及我们团队利用 AI 在测试方面做的一些提效方面的一些能力吧，仅供大家参考用。工具方面，国内主要用过 trae，国外的之前用 claude，现在主要用 codex，目前做的以各种 skill 为主，涉及到测试用例生成、测试用例执行、服务端接口及变更测试（增删改 + 代码变更影响到的接口）、客户端 E2E 测试（回归 + 探索性测试为主）、代码审查 agent、需求实现度分析（测试用例 + 提测分支，分析研发需求的实现评分，并通过工作流拉取需求池中所有提测的需求逐个分析，生成飞书报告周知项目干系人），以及用 AI 做了很多日常测试高频用到的一些可以明显提效的工具。

测试用例生成

1、最早尝试过 dify、coze 等工作流，效果比较一般，主要生成的格式都是表格或者 md 文件，可读性也比较差，也就没有怎么推进，直到 4 月份的时候写了一个 skill，我先搭了个大的框架，解决了格式的问题，然后找组内写用例比较好的两个资深测试同学前后优化了 20 多版本，围绕怎么写，写哪些，不写哪些明确的比较多（比如后台的部分、比如边界异常的部分，AI 会放大了写），整个 skill md 文件 400 多行，主要的流程是根据给的飞书链接，通过飞书 mcp 或者飞书 cli 读取内容，然后结合过去一年的所有缺陷、当前主分支代码，在 skill 的约束下完成测试用例的编写，区分客户端、服务器，生成的是 xmind 层级的 md 文件，然后手动复制粘贴到飞书思维笔记中（因为飞书 api 还不支持 mindnote 的 api 读写，这种方式也很快，十秒钟就行），成品就是飞书思维笔记的文档。效果方面，我们团队反馈还算可以，采样率 75% 还是有的，甚至会更高，可读性也比较强，生成速度也比较快，6 分钟能够写完 200+ 测试用例的一个涉及到客户端、服务端的中等或者中等偏上需求，最后再改改，差不多 15 分钟也就写好了。

2、单个需求完成之后，在这个基础上又写了一个基于飞书多维表格（需求池）给某个迭代下所有需求写测试用例然后回写到需求池的这么一个 skill，单个方法上面已经说了，那这里主要是多个需求怎么写了，其实也不难：扔给 AI 一个某个版本的需求池链接 -》读取每个需求的需求文档内容（我们需求池每一个需求都有需求名称、需求飞书文档地址）-》生成测试用例 -》通过浏览器的方式来创建飞书文档，替代飞书 mindnote api 不可用的方法 -》回写到需求池 测试用例 一栏中。这个流程已经跑通，但跑了一阵发现大家其实还是更喜欢自己用上面的 skill 来写用例，所以也就没有大力推了。

写到这里，发现写文档也是很耗时的，最后还是让 AI 来整理了下大方向的吧，有想要详细了解的同学可以评论交流。

一、这件事在解决什么问题

核心目标不是 “用 AI 替代测试”，而是解决测试工作里最消耗人力、最依赖经验、最难规模化的几个问题：
需求理解成本高，用例设计重
回归范围大，执行效率低
研发提测质量参差不齐，风险识别靠经验
广告、资源、日志、数据排查等高频工作重复度高
测试能力分散，难沉淀、难复用、难复制

二、整体方法：从 6 个层面推进

这套 AI 测试提效实践，不是围绕某一个工具做尝试，而是沿着测试工作流本身，分成 6 个层面持续建设，尽量把测试设计、执行、分析、协同和沉淀串成闭环。

测试用例生成

围绕需求文档、设计稿、接口说明、埋点说明、代码和历史缺陷知识库，建设 AI 用例生成能力，用于生成测试点、测试大纲和可导入飞书思维笔记的测试用例。
这部分重点解决的是测试设计阶段的效率和完整度问题，让 AI 先参与需求理解、场景展开和边界补充，而不是只在执行阶段介入。

测试执行

在执行层面，逐步覆盖了接口测试、客户端 E2E、客户端回归、后台测试和网页测试等场景，让 AI 不只是 “生成建议”，而是开始直接参与测试落地。
为了让执行更稳定，我们同步推动测试步骤、观测点、缺陷判定口径和失败取证方式标准化，尽量把执行过程从自由推理收敛为可复用、可编排的动作链路。

研发流程协同

把 AI 能力前移到研发流程中，重点落在代码 review、版本变更分析和需求提测分析，让测试参与点从 “提测后验证” 延伸到 “提测前识别风险”。
在这个过程中，结合 testcase、需求文档和 code diff，对实现完整度、影响范围、潜在回归风险和明显缺陷进行分析，提升测试前置和质量把关能力。

测试工具开发

围绕日志分析、埋点校验、Push 发送、客户端性能测试、后台系统、测试数据构造等高频测试场景，建设了一批专项测试工具。
这部分的目标不是做大而全的平台，而是优先把高频、重复、重经验依赖的测试工作工具化，先解决实际工作中最耗时、最容易出错的问题。

自动化测试框架

在框架层面，持续推进 UI 自动化、Monkey 稳定性测试和接口自动化三条线，分别覆盖客户端操作链路、异常稳定性问题发现和服务端接口巡检等方向。
这里更强调按场景建设能力，而不是追求统一框架，把适合标准化和批量执行的测试场景优先自动化，逐步补齐自动化能力闭环。

提效工具与知识沉淀

除了测试本身，也围绕缺陷分析、打包安装、周报生成、MySQL/Redis 排查等日常协作场景建设提效工具，减少大量重复性人工操作。
同时持续沉淀测试规范、缺陷知识库、workflow 和复用型测试资产，把单点经验逐步转化为团队可复用、可迭代的工程能力。

三、目前最有价值的落地方向

如果从社区分享角度提炼，最值得强调的不是 “做了很多工具”，而是以下 3 类最有代表性：

AI 用例生成

这是最容易起量、最容易被团队感知价值的一步，也是后续自动执行、代码分析的输入基础。
手动插入：没做之前我也觉得 AI 写用例也就那样，没法跟人比，但如果你让 AI 写出来的测试用例质量比较高，速度也比较快，还是比较有感触的吧，至少我是这样的。

版本/需求提测分析

这是最能体现测试前置价值的一步。AI 不只是帮忙写用例，更开始参与判断 “这次改动到底该测什么、风险在哪”。
手动插入：需求提测分析，这个我觉得还是挺好的，建议大家试试。基于评审过的测试用例，然后拉取客户端、服务端和前端的分支代码，从代码层面对测试用例进行实现度的校验（百分制），并让 AI 给出明确的代码证据，证明哪些实现了，哪些没有实现，哪些是部分实现，存在哪些主要的缺陷，以及测试的时候需要注意什么。通过这个 skill，在测试之前其实你就能知道这个需求提测的质量了，以及哪些地方你需要重点测试下。而版本分析，这个纯粹就是 code diff 了，上个版本发布的 tag 到这个版本合到主分支之后的提交，拉取所有的 change，然后让 AI 生成回归测试的重点，从 P0 -P2 不等，主要是怕研发改了某些测试不知道的场景，引发完全没在此次需求范围内的缺陷。

高频测试场景工具化

日志、Push、数据排查、打包、缺陷分析等场景，往往是 ROI 很高的提效突破口。
手动插入：线上反馈的一些问题，很多时候也是需要 QA 同学来排查的，适当开发一些埋点和日志分析的 skill 或者 agent，还是挺有用的，我沉淀了好几套查询特定问题的方法到 skill 中，直接扔给这个 skill 用户反馈的真实内容，稍微加工下，AI 就能自己去查数据，然后给出相对比较靠谱的结论了，还是挺省时间的。