过去两年，AI 辅助测试的讨论大多停留在用 ChatGPT 生成几条测试用例的层面。效果有限，因为聊天式工具只能凭人的文字描述去猜测系统行为，猜错了也无从验证。Claude Code 的出现改变了这个前提：它是运行在终端里的智能体，能够直接读取项目源代码、配置文件、既有测试和最近的改动记录，并通过 Model Context Protocol（MCP） 调用测试管理系统、浏览器自动化工具、CI 流水线等外部服务。
换句话说，它不是在描述你的系统，而是在查看你的系统。这个区别决定了它能在 QA 工作流里派上什么用场。
TestCollab 团队近期发布了一份实操指南，总结了 Claude Code 在 QA 场景下的六类具体用法，并给出了落地建议和边界提醒。下面逐一展开。
从代码库直接生成测试用例
最直接的收益来自测试用例生成。Claude Code 读取源码后，能识别功能实现中的正常路径、边界条件和错误处理，再生成带步骤和预期结果的结构化用例。这些用例基于代码的真实实现，而不是对功能描述的泛泛猜测。
它支持三种输入方式：直接指向一段刚写完的功能代码；给出用户故事或需求文档，让它反推测试场景；给出 OpenAPI 接口定义，生成覆盖合法请求、校验错误、鉴权失败、限流等情况的接口测试。如果连接了测试管理工具的 MCP server，生成的用例可以直接写入对应测试套件，并带上优先级和标签，人工只需要复核，不必再手动誊抄。
指南给出的效率参考是：在一个约 50 个文件的中型代码库上，用全量扫描模式让 Claude Code 逐模块生成用例，20~30 分钟能产出 50~100 条用例，覆盖 15~25 个测试套件。这个速度对于给历史遗留、缺乏测试覆盖的代码库补课，尤其有价值。
结合 Playwright CLI 的探索性测试
探索性测试历来依赖人的直觉：凭手感去戳边界，跟着可疑之处继续深挖。Claude Code 给这项工作增加了一个新维度：借助 Playwright CLI，它可以驱动真实浏览器完成导航、点击、填表并汇报观察结果。测试人员则用自然语言实时引导探索方向，比如继续深入错误状态、换成空字段提交、检查移动端视口表现。
这里有个技术细节值得留意：Playwright CLI 发送的是结构化文本命令，而不是像 Playwright MCP 那样传输截图，因此更省 token，能支撑更长时间的探索性会话，不容易过早触及上下文上限。
指南特别提醒了一个边界：这属于辅助式探索，不是自主抓 Bug。AI 可以操作浏览器、报告发现，但这些发现只是需要人工验证的线索，不能直接当作已确认的缺陷报告归档。
证据留存与质量治理
测试跑完只是一半的工作，另一半是证明测试确实跑过，记录发生了什么，并让这些证据可用于审计、合规和发布决策。Claude Code 结合 Playwright CLI 执行测试时，能够在关键步骤自动截图、记录网络响应和控制台输出；通过 MCP 连接测试管理工具后，这些证据可以直接绑定到具体测试执行记录上，形成一条从浏览器会话到审计轨迹的完整链路。
这个能力对三类场景特别有意义：发布前需要留痕的签发流程；需要满足 ISO 27001、SOC 2 等合规要求、证明测试严谨性的团队；以及跨时区协作的 QA 团队。下一个接手的人不需要开会同步，直接看执行记录附带的证据，就知道测过什么、结果如何。
基于风险的影响面分析
每次发布都要回答一个问题：这次改动可能破坏什么？传统做法依赖足够熟悉代码库的人手动追踪依赖关系。Claude Code 可以承担这部分追踪工作：指向一次 merge、一组提交或一次 release 的 diff，它能读取改动文件，并在代码库内追踪影响范围，识别受影响的模块、功能和用户流程。依据是实际代码依赖，而不仅仅是文件名匹配。
更进一步，它会将受影响区域与现有测试用例库做比对，找出覆盖缺口，并生成按风险优先级排序的定向测试计划，而不是每次都跑全量回归套件。这在合并大型 PR 前的风险评估、发布范围界定，以及紧急热修复的影响半径判断中，都能直接节省人力。
代码变更后的用例维护
测试用例会腐坏：代码变了，界面改了，错误提示换了措辞，接口加了新字段，用例却还停留在旧版本的假设上。手动追踪哪些用例需要更新，是 QA 工作里最枯燥、也最容易被拖延的部分。
Claude Code 处理这类任务的方式是：读取代码变更和现有用例，理解发生了什么变化，识别哪些用例引用了被改动的行为，然后给出具体的更新建议，包括改哪一步、改哪个预期结果。指南特意强调，这不是黑盒式的自愈。Claude Code 展示它想改什么、为什么改，人工复核之后才会应用。这个设计是刻意的，因为对涉及复杂业务逻辑的改动，AI 仍然可能误解意图。
从 Bug 修复到回归测试的闭环
每一次 Bug 修复理论上都应该留下一条回归测试，但在实践中这一步经常被跳过：写用例是修复 Bug 之外的额外工作，等修复合并时，大家往往已经转向下一个任务。
Claude Code 可以补上这个闭环：开发者修复 Bug 后，把修复背景讲给它，或者让它直接读取 Bug 报告和代码 diff，它就能生成覆盖具体失败场景的回归用例，包括前置条件、复现步骤和修复后的正确预期；再通过 MCP 打上标签，归档到对应套件，纳入后续回归测试范围。
指南举了一个例子：某个绕过邮箱验证直接访问后台的 Bug，修复后生成的回归用例会覆盖注册不验证、尝试直接访问、验证跳转、完成验证、确认可访问这一整条路径。这个例子提醒我们，AI 的价值不只是补一条用例，而是把缺陷、修复、回归验证串成可追踪的闭环。
落地建议
指南给出的起步路径是：先从测试用例生成切入，因为见效最快、风险最低。AI 给出建议，人工复核后采纳，即便判断有误，也不会直接造成实际损失。站稳之后，再扩展到风险驱动的影响面分析和 Bug 到回归用例的闭环，这两类场景能直接减少该测的没测到、改完 Bug 忘了补测试这类因人力疏漏导致的问题。探索性测试和证据留存，则更适合在有明确合规或跨时区协作需求时再引入。
指南反复强调的边界，值得作为团队试点时的原则：Claude Code 是测试执行的加速器，不是测试策略和判断的替代者。测试策略怎么定、结果算不算通过、能不能发布，这些决策仍然由人负责。它能做的，是把读代码、写用例、追依赖、补回归这类重复且需要上下文的工作接过去，把人力腾出来，放在真正需要判断力的地方。
相关阅读
##### FunTester 名片｜万粉千文，百无一用