最近看了 Lewis Prescott 在 MoT Manchester / MoTaverse 的一次分享：
永远是人的问题：AI 测试背后的真相
Lewis Prescott 是 Hippo Digital 的质量保障（QA）负责人，也是 Ministry of Testing 社区的参与者和 MoT London 的组织者之一。分享发生在 2026 年 9 月 23 日，主题听起来有点像一句抱怨：
无论看起来有多快，归根结底还是人的问题。
但 Lewis 特别澄清，这句话不是在说“人就是问题”。他的意思更实际：很多看起来像技术问题的事情，最后都需要把合适的人拉到一起，把该讨论的内容讨论清楚。
这句话正好对应 AI 测试里最容易被忽略的部分。AI 已经可以写代码、分析数据、生成文档、执行任务，甚至参与完整的工作流。于是问题变成了：
如果 AI 可以做这么多事情，QA 还剩下什么？
答案很具体。AI 可以接手大量重复劳动，但测试里最需要判断的部分仍然来自人：理解需求、发现风险、解释结果、验证证据，以及推动团队改变工作方式。
测试的目标从来不只是执行更多测试
先回到测试到底要解决什么问题。
Lewis 在分享里反复强调两件事：
| 目标 | 需要回答的问题 |
|---|---|
| 做对的东西 | 用户真正需要什么？这个需求解决了什么问题？我们有没有理解错？ |
| 把东西做对 | 系统是否按预期工作？异常路径、性能、接口契约和数据状态是否可靠？ |
第二件事通常更容易被看见，因为它可以转化成代码、测试用例、检查结果和报告。第一件事则需要更多讨论。用户到底要完成什么，需求背后的限制是什么，哪些风险不能接受，这些问题不会因为生成了更多测试代码就自动消失。
AI 可以帮助我们分析需求、整理上下文、生成测试草稿，也可以帮忙执行大量检查。但它不能替团队决定“我们应该做什么”。如果目标本身没有说清楚，AI 只会更快地把模糊目标实现出来——速度很快，方向未必对。
HUMAN：用“人”重新看整个软件开发生命周期
Lewis 用 HUMAN（人）这个单词串联整个软件开发生命周期。这个缩写来自他一位物理治疗师朋友，两人正在合作开发一款帮助用户自助解决腰痛等问题的应用。把这个词放进 AI 测试里看，重点很清楚：它把注意力拉回到工作中的人和上下文。
| 字母 | 中文含义 | 在测试和交付中的含义 |
|---|---|---|
| H | 倾听故事 | 听懂需求背后的故事，理解用户、业务和上下文 |
| U | 理解全貌 | 理解问题和系统全貌；AI 已经进入整个流程，成功与否仍需人验证 |
| M | 梳理问题 | 界定问题、画出边界，分清 AI 擅长和不擅长的部分 |
| A | 采取行动 | 把讨论转成行动，例如定义验收标准和推动验收测试驱动开发（ATDD） |
| N | 引导整个过程 | 在整个过程中引导协作，帮助不同角色一起做决定 |
把它当作一个提醒：测试工作不只发生在测试执行阶段。
需求理解属于测试。风险讨论属于测试。判断一个数据结果意味着什么属于测试。帮助新人融入团队、进行带教、建立共同语言、推动大家提前讨论，也都属于测试的一部分。
AI 可以进入这些环节，但它不能替代其中的人际关系和责任分配。谁知道业务规则，谁承担发布决定，谁真正理解用户受到的影响，这些问题仍然需要人来回答。
AI 最擅长的是那些我们不想手工做的事
Lewis 的判断很直接：AI 最适合处理那些无聊、重复、耗时的工作——恰好也是我们不想手工完成的部分。
最明显的例子是写代码、分析数据和生成文档。放到 QA 场景里，还可以包括生成测试数据、准备自动化脚本、整理日志、总结缺陷、生成测试用例草稿、整理需求、生成报告和分析执行结果。
这些工作 AI 已经做得越来越好。以后只会更强。
所以 QA 的价值不能建立在一个很脆弱的假设上：AI 永远写不好自动化测试代码。这个假设一旦失效，岗位价值也跟着失效，显然不是一个好设计。
更现实的问题是：
如果 AI 已经可以很好地完成这些工作，QA 应该把时间放在哪里？
QA 的时间应该回到测试本身：理解需求、发现风险、验证结果，而不是继续寻找下一批可以填满日历的脚本任务。
AI 节省下来的时间，应该还给测试
过去很多 QA 都希望把测试活动向整个研发流程扩展。需求阶段做评审，设计阶段做风险分析，开发之前讨论可测试性，发布前后分析真实数据，产品、开发和 QA 一起做三方协作讨论（Three Amigos）。
实际工作里，大家经常只有一个回答：
没时间。
时间被写脚本、维护脚本、整理数据、写报告、重复执行和补文档占用了。于是“测试应该更早介入”经常停在口号层面，团队也不是不知道该怎么做，只是当天还有一堆回归任务等着跑。
AI 正在减少这些重复工作的成本。节省出来的时间可以重新投入到更有判断价值的活动里：
- 先把需求和用户目标说清楚。
- 和产品、开发、架构以及运营一起做风险讨论。
- 在代码出现之前挑战关键假设。
- 设计实验，观察系统和用户行为。
- 分析生产数据，判断异常是否真的影响业务。
- 让测试策略、验收标准和发布证据保持一致。
AI 可能让真正的测试变多——前提是团队把省下来的时间还给测试，而不是全部拿去继续生成代码。
风险风暴不是生成一百条风险
Lewis 重点谈到了风险风暴（Risk Storming）。
可以想象一个具体场景：开发、QA、产品、架构师、运营或安全人员围着系统架构图、业务流程和新功能设计坐在一起，在白板或 Miro 上讨论：
- 这里可能怎样失败？
- 依赖服务不可用时会发生什么？
- 用户会不会用我们没预料到的方式操作？
- 数据在多个系统之间会不会不一致？
- 这个改动会不会暴露新的安全风险？
- 流量突然增长时，系统还能不能工作？
- 这个改变会影响哪些用户、团队或下游系统？
然后，团队把讨论结果放进测试策略、测试计划、探索式测试、自动化范围和提供给 AI 的上下文里。
不同角色看到的风险并不一样：
| 角色 | 可能首先看到的风险 |
|---|---|
| 开发人员 | 技术实现、依赖、状态和维护风险 |
| 产品 | 用户目标、业务规则和优先级风险 |
| QA | 行为、边界、回归和可验证性风险 |
| 运营人员 | 生产稳定性、容量和恢复风险 |
| 安全人员 | 权限、攻击面和数据暴露风险 |
真正有价值的地方，不是谁能最快生成一百条风险，而是团队能不能说清楚：
为什么我们认为这些风险重要？
风险清单可以由 AI 协助整理，风险判断不能只交给 AI。团队的讨论结果才是后续测试策略的上下文。
AI 可以分析数据，人还要理解数据意味着什么
AI 很适合读取数据、分类、聚合、寻找模式和生成摘要。问题通常出现在下一步：
所以呢？
例如，监控显示 P95 响应时间增加了 200 毫秒。这是一个事实，但还不是质量结论。我们还需要问：
- 用户能感觉到这个变化吗？
- 变化发生在哪条业务路径？
- 为什么变慢？
- 这是一次性波动，还是持续恶化？
- 哪些用户受到影响？
- 这个结果是否可以接受？
- 需要阻止发布，还是继续观察？
可以把数据判断拆成五层：
| 层次 | 要做的事情 |
|---|---|
| 数据 | 读取原始指标、日志、测试结果和用户行为 |
| 信息 | 对结果分类、聚合，找出异常模式 |
| 上下文 | 结合版本、业务路径、用户和环境解释结果 |
| 含义 | 判断异常是否代表真实风险，以及风险影响谁 |
| 决策 | 决定是否继续测试、修复、观察或发布 |
AI 可以参与整个过程。越接近“含义”和“决策”，人的责任越重要。因为发布决定不是一个摘要按钮，质量也不等于指标表格最后一行的颜色。
最难的不是工具，而是改变团队
Lewis 反复强调一句话：
团队流程才是难点。
测试左移、接口契约测试、ATDD、行为驱动开发（BDD）、三方协作讨论和基于风险的测试都有同一个难点。技术实现可能很快搭起来，团队愿不愿意改变工作方式才是问题。
开发愿不愿意在需求阶段参与？产品角色愿不愿意一起讨论边界？大家愿不愿意先写验收测试？谁负责维护这些约束？测试失败后，团队是修复问题，还是先想办法让报告变绿？
一个典型的旧流程是：需求写完后交给开发，开发完成后交给 QA，QA 在最后阶段发现需求歧义和风险。更有效的方式是让产品、开发和 QA 在前面一起讨论需求，定义验收标准，再决定怎样实现和验证。
最大的挑战通常不是：
BDD 工具怎么安装？
而是：
怎么让所有人愿意改变原来的工作方式？
AI 可以提供工具和建议，但不能替团队完成说服、协商和责任分配。
“AI 接管整个质量生命周期”过于简单
现在经常能看到一种营销说法：AI 将拥有整个质量生命周期。
Lewis 在分享中批评了一家跨浏览器自动化测试工具厂商的类似口号。它的客户本来就是质量从业者，却用“AI 将主宰整个质量生命周期”来吸引质量团队，这种说法和真实研发过程之间有很大距离。
这句话听起来很完整，却把质量工作压缩成了一个过于整齐的故事：输入需求，AI 生成实现，AI 自动验证，然后自动发布。
真实的软件质量包含很多无法直接生成的东西：需求歧义、权衡、风险、上下文、优先级、沟通和决策。AI 可以辅助这些工作，但至少在当前阶段，没有人判断 AI 做得对不对，就很难谈质量生命周期已经被 AI 接管。
Lewis 也承认，AI 已经无处不在，团队需要接受它的存在。问题不在于是否使用 AI，而在于关键判断点是否还保留人的验证：
- 人先提供目标、上下文和约束。
- AI 协助实现、分析和执行。
- 人再验证输出、证据和风险。
- 团队根据验证结果做决定。
让人参与流程中的关键判断，不是给流程加一层形式主义审批。这是把责任放在真正能理解目标、影响和后果的人手里。
BDD 可能重新变得重要
Lewis 预测，BDD 可能会出现一次明显的回归。
过去几年，很多团队对 BDD 的兴趣下降了。原因并不难理解：用 Gherkin 编写场景变成形式主义，场景数量不断增加，维护成本越来越高，业务人员没有真正参与，最后“假如、当、那么”这些场景步骤还是由 QA 一个人写完。
但 BDD 的核心价值从来不是 Cucumber，也不是把每个句子都套进“假如、当、那么”的固定结构。它真正解决的是：用业务和技术都能理解的语言，把需求、行为和验收标准讨论清楚。
BDD 很适合让 AI 参与。人可以先定义行为和边界，AI 再根据这些约束生成实现、测试数据和重复检查。语言越清楚，AI 越容易得到可验证的目标。BDD 使用平实的语言描述行为，也降低了不以编程为主要工作的人参与讨论的门槛。
如果代码由 AI 生成，为什么不先定义行为？
很多 AI 编程的流程是先让 AI 写代码，再让 AI 补测试。Lewis 认为这个顺序可能反了。
如果实现本来就准备交给 AI，团队可以先做下面这些事情：
- 产品、开发和 QA 讨论用户需要的行为。
- 写出验收标准，明确什么算正确，什么算失败。
- 把重要行为转成验收测试或 BDD 场景。
- 让 AI 根据这些约束生成实现和配套测试。
- 运行测试，观察失败结果。
- 让 AI 修正实现，再由人检查修正是否合理。
- 在测试通过后进行重构，并保留足够的验证证据。
这重新回到了大家已经讨论很多年的“红灯（测试失败）、绿灯（测试通过）、重构”，也回到了 ATDD、BDD 和测试驱动开发（TDD）的共同方向：先定义行为，再实现行为。
AI 编程越强，测试优先反而可能越重要。因为生成越快，错误方向被放大的速度也越快。
测试可能从验证代码，转向约束生成
沿着这个方向继续看，QA 的工作重心可能会提前。
测试人员需要参与定义：
- 什么是正确的结果。
- 什么是错误的结果。
- 哪些行为必须验证。
- 哪些风险不能接受。
- 哪些证据足以支持发布。
这些内容构成了给 AI 的质量约束。
QA 的价值因此不再只是代码写完以后找缺陷。更早的工作同样重要：理解需求、识别风险、设计验证方式、检查 AI 输出、构建质量证据，并推动团队把这些约束放进日常流程。
QA 可能越来越像质量架构师
Lewis 在问答环节提到，工程师的角色可能越来越偏向架构师。大量具体实现交给 AI 后，工程师可能更多负责架构和 BDD 层，再验证 AI 生成的实现。人的工作会更多集中在定义问题、设计系统、设置约束、评审、验证结果和做决策。
QA 也可能经历类似变化：
| 过去更常见的重心 | 逐渐增加的重心 |
|---|---|
| 手写和维护大量自动化脚本 | 设计有效的验证方式 |
| 执行测试并整理结果 | 判断 AI 输出是否真的正确 |
| 在后期发现问题 | 在需求阶段识别风险 |
| 维护自己的测试范围 | 推动团队共同建立质量约束 |
这不代表 Java、C#、Python、Playwright、Selenium 和 API 测试会突然失去价值。它们仍然是判断实现和验证结果的工具。变化在于，工具能力不再等于测试能力。
更重要的问题是：
- 你能不能理解需求？
- 你能不能识别关键风险？
- 你能不能设计有效的实验？
- 你能不能判断 AI 生成的测试是否真的验证了行为？
- 你能不能说明结论背后的证据？
- 你能不能推动团队接受更好的工作方式？
“能验证 AI 输出”会成为基础能力
未来的招聘广告可能仍然会写 C#、脚本、自动化和 API 测试。但招聘方真正想找的能力，可能越来越接近“能验证 AI 输出”。
AI 可以生成测试代码、测试用例、测试策略、SQL、模拟对象（Mock）、性能脚本和测试报告。QA 不一定要把这些内容全部从零写出来，但必须能判断：
| AI 输出 | QA 需要追问的问题 |
|---|---|
| 测试代码 | 它到底验证了什么？断言是否足够？ |
| 测试用例 | 重要风险覆盖了吗？有没有只是把需求换了一种说法？ |
| 模拟对象或测试数据 | 它是否隐藏了真实依赖的问题？ |
| 性能脚本 | 负载模型和用户行为真实吗？ |
| 测试报告 | 结论有证据吗？有没有把执行过写成验证过？ |
这个能力比背着写一段 Selenium 更接近未来 QA 的工作。会写代码仍然有用，但看懂代码、发现问题、提出问题和判断结果更关键。
QA 的面试也可能开始验证解读能力
Lewis 分享了 Hippo 的一个面试实践：面试里会给候选人代码，但不要求候选人现场写代码，而是要求他们解释这段代码在做什么。
甚至可以使用 AI。因为真实工作中本来就会用 AI，面试如果完全假装没有工具，测到的可能只是脱离工具背语法的能力。
面试真正想观察的是：
- 候选人能不能理解代码。
- 能不能指出可疑的行为。
- 能不能提出有价值的问题。
- 能不能判断结果是否合理。
- 能不能把 AI 用在合适的地方。
Lewis 还提到，面试官通常能看出候选人是否在使用 AI。这个细节更像一个提醒：使用 AI 不需要假装没用，真正需要展示的是你有没有验证它的输出。
AI 最难替代的工作，可能是和人相处
在问答环节，Lewis 被问到 AI 最不能替代、同时也是他最喜欢的工作是什么。
他的答案是和人相处：面对面待在同一个房间里，喝咖啡，聊一件事，再从这件事引出另一个问题。有人突然说“等等，这让我想到另一个风险”，一个之前没人意识到的问题就这样出现了。
从效率指标看，这种过程很难量化。它没有稳定的输入输出格式，也无法保证每次半小时聊天都能产生一条可执行的结论。但很多重要信息确实是在这种交流中出现的。
这也是三方协作讨论、风险风暴、结对讨论、带教和设计讨论在 AI 时代仍然有价值的原因。面对面的交流不一定快，却经常能让团队发现原本没人负责、没人提问、也没人写进需求的风险。
Lewis 还喜欢招聘和面试，因为它让他认识新人，并努力让紧张的候选人放松下来，进行开放交流。招聘也涉及责任和法律边界，不能简单把招聘决定交给 AI。这类工作很难被一个只追求吞吐量的系统完整替代。
几个值得继续追的线索
这场分享还提到几位与测试和质量实践有关的人：
- Dave Farley：Lewis 用他的观点解释为什么 ATDD 和 BDD 可能成为未来的重要方向，也对应持续交付和测试优先的讨论。
- Dan Ashby：他曾用图展示 AI 会触及软件交付的各个环节。Lewis 借此提出，过去测试想进入每个环节时经常被“没时间”挡住；如果 AI 还回了时间，测试就有机会真正贯穿整个流程。
- Baron：在 Ministry of Testing 和 TestBash 社区中经常讨论风险相关主题，风险风暴值得继续了解。
- 三方协作讨论：Lewis 在整个职业生涯里都在推崇的协作方式，把产品、开发和 QA 聚到一起，共同讨论如何解决问题。
这些名字不是待办清单。它们指向的是同一个方向：质量不应该只在最后一个阶段出现。
如果明天就在 AI 团队里做 QA
如果把这场分享落到日常工作，我会从下面几件事开始：
- 先确认用户要解决的问题，以及什么结果才算成功。
- 把产品、开发、QA 和真正掌握业务上下文的人拉到一起。
- 画出系统边界、依赖和可能受到影响的用户。
- 做一次风险风暴，把不同角色看到的风险记录下来。
- 把重要风险转成验收标准、验收测试或 BDD 场景。
- 让 AI 生成代码、测试数据、自动化脚本和报告草稿。
- 逐项检查 AI 的输出，确认它真的覆盖了目标和风险。
- 分析执行和生产数据，解释异常对用户和业务意味着什么。
- 在发布前确认结论、风险和证据，而不是只看测试是否通过。
- 继续改善团队流程，让下一次讨论更早发生。
这套做法仍然把 AI 放在流程里，只是先给它清晰的上下文，再让人把时间用在 AI 无法替代的判断上。
给 QA 新人的提醒
如果你正在进入 QA，别把自己和 AI 比谁打字更快。AI 写测试代码、生成数据和整理报告的速度很可能会超过任何人，这件事没有悬念。
你需要建立的是更稳定的基础能力：理解系统，分析需求，识别风险，设计实验，判断证据，解释结果，并和不同角色一起推动问题解决。
Lewis 给求职者的建议也很实用：如果你满足招聘要求的 60%，就可以投递。他自己大约满足 60% 就会投，而他的太太更接近满足 90% 才投。这两个数字都不是求职规律。重点是，很多恐惧来自对未知的想象。
你不需要等到完全准备好才开始使用 AI，也不需要假装自己不使用 AI。你需要知道自己为什么让 AI 做某件事，以及怎样确认它做对了。
最后
这场分享的标题是：
永远是人的问题。
技术依然重要，软件依然需要代码、数据、自动化、模型和工具。更要记住的是，AI 发展得越快，越不能忘记软件是人为了人构建出来的。
需求来自人。风险由人感知。优先级由人决定。团队由人组成。用户最终承受质量决策带来的影响。
AI 可以进入整个软件开发生命周期：需求、设计、开发、测试、发布和生产。这本身没有问题。我们仍然需要回答：
- 我们做的是正确的东西吗？
- 它真的解决用户的问题吗？
- 最大的风险是什么？
- AI 输出可信吗？
- 证据够吗？
- 现在应该发布吗？
这些问题不会因为模型能力提升而自动消失。
未来 QA 可能少写一些自动化代码，很多测试脚本、测试数据、报告和执行任务也可能由 AI 或智能体完成。但测试的核心能力仍然是理解问题、发现风险、提出有用的问题、验证结果，以及帮助一群人共同做出更好的质量决策。
从这个角度看，AI 接管的可能是测试工作里的劳动，而不是测试本身。