我开始用 AI 辅助测试后，真正改变的不是写用例

最近一段时间我开始尝试把 AI 放进日常测试工作。一开始的想法很简单能不能让 AI 帮我写测试用例实际用下来我发现这个问题问得有点浅。AI 确实可以帮我生成测试用例、写测试代码但真正让我觉得有价值的地方其实不是“帮我多写几个用例”。而是AI 开始参与测试人员的思考过程。这也是我这段时间实践下来比较明显的一个变化。一、以前写测试用例我通常是怎么做的拿到一个需求之后基本流程是阅读需求↓理解业务规则↓整理测试点↓编写测试用例↓执行测试↓发现问题真正比较耗时间的其实是中间这一步“这个需求到底应该测什么”因为一个需求往往不会把所有情况都直接写出来。比如用户完成某操作后可以获得一次奖励。看起来非常简单。但测试真正需要考虑的是第一次操作是否获得重复操作是否还能获得操作失败是否获得网络异常时怎么办用户状态发生变化怎么办并发操作会不会重复获得数据已经存在时怎么办接口重复请求怎么办这些才是测试工作的核心。所以我开始尝试把这个过程交给 AI 一部分。二、第一种用法让 AI 帮我“拆需求”我不会直接告诉 AI“帮我写测试用例。”而是先让它做一件事情分析这个需求有哪些规则以及哪些地方存在不确定性。例如可以这样描述你是一名测试工程师。请分析下面这个需求【需求内容】请从以下几个方面分析核心业务规则正常场景异常场景边界条件数据状态变化权限相关场景并发/重复操作场景需求中存在的歧义对于无法从需求中确定的内容请单独列出不要自行假设。这里有一个很重要的变化不是让 AI 替我设计测试。而是先让 AI 帮我把需求拆开。这一步实际上很有价值。因为测试人员最容易遗漏的并不是某一个按钮点击。而是隐藏在业务规则里的条件。三、第二种用法让 AI 主动找“我没想到的场景”当 AI 完成第一轮分析之后我会继续追问基于刚才的需求分析假设你是一名负责线上质量的测试工程师。请专门寻找“正常测试人员容易遗漏但线上可能出现问题”的场景。不要重复已经列出的内容。重点关注边界状态变化重复操作异常流程数据一致性权限并发接口绕过前端限制这时候 AI 的作用就开始发生变化。它不再只是“帮我写东西。”而是在尝试“挑战我的测试思路。”这对测试人员来说其实更有价值。四、第三种用法AI 生成用例但我不会直接使用经过前面的分析之后才进入测试用例生成。基于已经确认的业务规则生成测试用例。要求不重复每条用例只验证一个核心目标明确前置条件明确操作步骤明确预期结果标记优先级对存在需求歧义的场景单独标记不要对需求中没有明确说明的规则自行下结论。这时候 AI 可以比较快地产出第一版。但是有一个原则AI 生成的用例不是最终用例。我仍然需要人工检查。原因很简单AI 可以理解文字。但它并不知道我们系统真实的数据结构历史 Bug业务特殊规则线上真实使用习惯当前版本的技术限制团队已经约定好的规则所以AI负责扩展思路人负责最终判断。五、真正让我觉得有价值的是AI 可以帮我做“反向测试”以前我们设计测试用例通常是产品告诉我们应该怎么做 → 我们验证是不是这样。现在我会增加一个问题如果有人故意不按照产品设计来操作会发生什么例如前端限制用户只能点击一次。那么测试不能只验证点击一次有没有成功。还应该考虑如果直接重复调用接口呢如果前端限制用户不能提交空数据直接调用接口提交空数据呢如果页面限制了某个权限接口层是否真的也校验了权限这类思路其实属于突破正常使用路径。AI 在这里可以作为一个“攻击测试思维的助手”。可以让它站在普通用户恶意用户新用户老用户异常网络重复请求并发请求等不同角色和条件下重新思考。六、AI 也开始进入自动化代码阶段当测试场景确定之后下一步就是自动化。例如需求↓测试场景↓测试用例↓自动化脚本↓CI/CD执行↓测试结果以前写自动化代码我需要自己完成定位元素编写请求组织数据编写断言封装方法调试代码现在其中一部分工作可以交给 AI。例如直接给它接口定义 请求参数 返回结果 项目现有代码结构让 AI 根据现有框架补充测试代码。但这里也有一个很重要的经验不要让 AI 凭空写代码。如果只是“帮我写一个接口自动化。”AI 很容易生成一份“看起来正确”的代码。但真正放进项目之后可能不符合现有框架不符合项目规范方法重复数据处理不合理断言不完整后期很难维护所以更有效的方式是给 AI 上下文让它在现有工程里修改而不是从零创造一个工程。七、AI 最适合做什么经过一段时间实践我目前更倾向于把工作分成三类。第一类非常适合 AI例如信息整理测试点扩展用例初稿测试数据生成重复代码编写文档整理简单代码转换特点是规则相对明确重复度高。第二类AI 可以辅助但必须人工判断例如测试策略风险分析复杂业务场景自动化架构Bug原因分析测试范围判断AI可以提供思路。但最终决定不能完全交给 AI。第三类目前仍然应该由人负责例如这个版本到底有哪些风险这个需求到底应该怎么定义这个问题上线的影响有多大什么时候可以发布这些问题最终需要结合业务 技术 用户 项目现状综合判断。AI可以参与。但不能替代测试人员承担质量责任。八、所以我现在对“AI辅助测试”的理解发生了变化刚开始我以为AI辅助测试 AI帮我写测试用例。现在我更倾向于认为AI辅助测试 AI参与测试人员的思考、执行和验证过程。整个过程可以变成┌→ 需求拆解 │需求 → AI辅助分析 ┼→ 风险识别│ └→ 场景扩展 ↓ 人工判断 ↓ 测试用例 ↓ AI辅助生成代码 ↓ 自动化执行 ↓ 结果分析 ↓ 人工决策这里面最重要的不是 AI。而是测试人员依然是整个流程的负责人。九、目前最大的一个误区我觉得很多人刚开始使用 AI 时很容易陷入一个误区“我要让 AI 替我完成测试工作。”但实际使用之后我觉得更合理的方向应该是“我要让 AI 帮我扩大测试能力。”两者差别很大。前者追求的是少做一点。后者追求的是想得更多、做得更快、覆盖得更广。例如以前一个需求我可能想到 20 个测试场景。现在通过 AI 进行反向分析之后可能会得到 40 个。但最终我不一定全部执行。因为还需要结合风险 × 成本 × 收益进行取舍。这才是测试工程师真正应该做的事情。十、下一步我准备继续验证什么这次实践只是一个开始。接下来我比较想继续验证几个问题01AI生成测试用例实际有效率到底有多高02AI生成自动化代码之后人工修改比例有多少03AI能不能参与接口自动化测试的整个流程04能不能把 AI 自动化 CI/CD 串成一个完整闭环最终希望验证的不是“AI厉不厉害。”而是“在真实测试工作中AI到底能够把效率和质量提升到什么程度”这个问题可能没有一个统一答案。所以我准备边做边记录。写在最后技术沉淀对我来说不应该只是收藏了一篇文章。也不是看完了一套教程。真正的沉淀应该是自己做过。自己踩过坑。自己验证过。最后能够解释为什么这么做。所以后面的文章我会尽量按照这个方式记录。不只写“这个工具怎么用。”而是尽量写清楚为什么用 → 怎么用 → 遇到什么问题 → 最后有没有价值。这也是我开始写「测试工程实践录」之后希望坚持下来的方式。把做过的事情留下来把验证过的方法留下来。然后继续往前走。检测到的源语言为 简体中文与当前目标语言 简体中文 一致页面可能没有需要翻译的内容。以后不再显示×