这两年聊测试开发，很容易绕到一个问题上：AI 会不会取代测开？
我一开始也会被这个问题吸引。毕竟现在的大模型确实能写测试用例，能补自动化脚本，能分析日志，甚至能根据接口文档生成一批看起来还不错的测试代码。站在一个测试开发工程师的角度，这件事很难完全无感。
但想得久一点，我反而觉得这个问题有点偏。
AI 会不会取代测开，当然值得讨论。但更值得讨论的是：测试开发这个岗位，原本到底应该是什么？
如果一个测开的主要工作，是把手工用例翻译成脚本，是临时帮业务造数据，是需求提测后赶紧补自动化，是流水线挂了以后去修一下，是每个版本都被业务拉着救火，那么 AI 带来的压力会非常直接。因为这些工作里，确实有不少可以被生成式工具加速，甚至部分替代。
可如果测试开发的价值，是建设质量能力，是让研发更容易自测，是让测试资产和业务代码一起生长，是把历史问题、业务规则、风险判断沉淀成工具、框架、门禁和模型，那么 AI 就不是简单的替代者。它更像一次迟到的机会。
理想中的测开并不是 AI 时代才出现的新概念。早在没有 AI 的时候，它就已经在那里了。只是过去我们经常够不到。
很多时候，我们嘴上说测开要做质量工程，要做平台化，要做自动化，要提升效率。但落到日常工作，又会变成另一副样子：需求来了先支撑，环境坏了先修，数据缺了先造，脚本挂了先看，线上报警了先跟。时间长了，测开到底是在建设质量能力，还是在维持业务交付不掉链子，就有点说不清了。
——测开曾经从脚本开始
测试开发这个岗位，在很多团队里最早形态其实很朴素：写脚本。把手工测试步骤翻译成自动化脚本，把登录、下单、支付、查询、审批这些流程写成代码，让机器在夜里跑。
这个阶段当然有价值。但问题也很快出现。
脚本替代的是动作，不是判断。
脚本可以点击按钮，可以调用接口，可以比对返回值，却不天然知道这个场景为什么重要，也不知道这个需求真正的风险在哪里。一个脚本通过了，只能说明它覆盖的那条路径没有暴露问题。
更麻烦的是维护成本。页面改了，脚本挂了。接口字段变了，脚本挂了。测试数据被污染，脚本挂了。环境不稳定，脚本也挂了。到最后，有些自动化体系变成了另一种负担：不是脚本帮人工作，而是人每天照顾脚本。
这也是为什么 “脚本工程师” 这种形态很难长期成为主流。一个岗位如果只解决执行问题，就会不断被更便宜、更快的执行工具挤压。过去是自动化框架挤压手工执行，后来是平台化能力挤压单点脚本，现在轮到 AI 挤压脚本生产。这不是 AI 才带来的故事。这个趋势早就开始了。
——只写脚本，回答不了质量问题
质量工作里最难的部分，从来不是 “点哪里”。更难的是这些问题：这个需求最可能出问题的地方在哪里？哪些风险应该由研发在开发阶段发现？哪些历史问题应该沉淀成回归资产？一次上线前，测试到什么程度才算可以接受？
这些问题，脚本本身回答不了。
所以后来的测试开发岗位开始分化。有些人继续维护自动化脚本，有些人转向测试平台，有些人开始做环境治理、数据构造、CI/CD、质量门禁、精准测试、流量回放、监控巡检。
这条路其实是对的。测试开发不应该停在 “把测试动作写成代码” 这个层面。它应该往上走，去解决测试为什么低效，质量为什么漏出，风险为什么识别不出来。
质量不是最后测出来的。它是在需求、设计、开发、自测、联调、回归、发布、监控、止损这些环节里一点点形成的。测试开发如果只站在提测之后，那就已经晚了。
——理想中的测开，其实一直存在
我理想中的测开团队，大概是这样工作的。
研发是质量第一责任人。基础功能是否正确，核心分支有没有覆盖，异常路径有没有处理，接口契约有没有破坏——这些不应该全部等到给 QA 提测后兜底。测开的角色，是让研发更容易把这些事情做好。
理想一点的工作流应该更像这样：研发本地可以一键构造数据。提交代码后，基础用例自动执行。接口变更后，契约测试能发现影响。提测不是测试工作的起点，而是已有测试资产的一次集中验证。
测开要少量但深入地接入业务。不是每个需求都浅浅参与一下，而是挑那些最值得投入的需求，钻进去，把一类问题的验证能力沉淀下来。
比如做一次订单取消需求，测开不只是把这个需求测完，而是顺手把订单状态机校验、幂等校验、库存回滚、资金一致性、优惠券返还、异常补偿这些能力沉淀成工具或用例集。下一次再有类似需求，研发可以直接复用。
这才是测开应该有的杠杆。它不是替业务多测一点，而是让下一次同类问题不再从零开始。
——为什么过去很难做到
说起来很美，落地很难。没有 AI 的时代，理想测开一直很难实现。不是大家不知道这个方向，而是成本太高。
第一层成本是技术成本。环境要稳定，数据要可构造，用例要能维护，自动化要能跑，失败要能定位，链路要能分析，风险要能评估。测试数据不是简单插几张表，一个订单背后可能有用户、商品、库存、价格、券、支付、履约、售后。
第二层成本是业务压力。很多测开团队不是没有理想，而是没有时间。
今天需求要提测，先帮忙造个数据。明天自动化挂了，先修一下。久而久之，测开就被业务需求牵着走。长期能力建设永远排在 “这个版本先上线” 后面。长期能力建不起来，下一个版本又会更依赖人肉支撑。
第三层成本是组织成本。测开需要研发愿意承担自测责任，需要产品把验收标准说清楚，需要架构愿意暴露服务关系。如果测开只有建议权，没有流程权，很多事情只能停在 “我们做了一个工具，大家有空可以用”。
第四层成本是价值证明。功能上线了，价值很容易被看见。质量体系做得好，很多时候体现为问题没有发生。但 “没有发生” 很难证明。测开的价值经常藏在那些没有爆炸的夜晚里。
还有一个原因：很多团队没有真正给测开留下 “长出来” 的时间。质量能力是需要复利的。一个稳定的数据构造能力，要从十几个痛苦需求里慢慢抽象出来。这些事情都需要连续投入。但现实里，测开经常被安排在离业务火线最近的位置。哪里缺就补哪里，哪里急就去哪里。体系没建好，所以业务更依赖人。业务更依赖人，所以测开更没时间建体系。
——AI 改变的不是方向，而是成本
AI 出现以后，很多人第一反应是：危险了。但我觉得，AI 没有重新发明测开。它只是让过去一些太贵、太慢、太依赖人的事情，开始变得可以重新尝试。
过去写测试用例贵，现在可以让 AI 先生成草稿，人来筛选和修正。过去写接口测试代码贵，现在可以基于接口文档、调用样例、历史用例生成一版初始代码。过去整理历史问题贵，现在可以让 AI 从缺陷、复盘、日志里抽取规则和风险点。过去研发不愿用测试工具，可能是门槛太高，现在可以通过对话式入口让这些动作变得更顺手。
这些事情单独看都不神奇。但放在测开这个岗位里，它们可能改变成本结构。原来一个测开想让测试资产和业务代码并行生产，需要大量时间写用例、写脚本、维护框架。现在 AI 可以承担一部分初稿工作。
当然，AI 不是质量本身。AI 会胡说，会漏场景，会生成看起来很完整但其实没什么用的用例。AI 不能替组织承担质量责任，也不能替测开完成风险判断。但它能降低很多工作的启动成本，这就够重要了。因为理想测开过去最难的地方，恰恰是很多正确的事情成本太高。
但这里也有一个反面。如果测开的定位不变，AI 只是加速器。它会加速脚本生产，也会加速救火。它会加速报告生成，也会加速短期交付压力。只有当团队愿意把 AI 节省下来的成本投入到长期能力里，它才真的有可能改变测开的处境。
——AI 时代，测开应该重新回到理想模式
如果 AI 只是被用来更快地写脚本，那测开的处境可能不会变好。业务会说既然 AI 能写，那你再快一点。管理者会说既然效率提升了，那人是不是可以更少？
所以关键不是 “测开如何使用 AI 工具”，而是测开要把 AI 放进什么样的质量体系里。有几件事值得重新做。
第一，让研发真正具备自测能力。不能一边要求研发自测，一边让他手工查库、手工造数据、手工看日志。测开要提供好用的能力：数据构造、接口验证、Mock、契约测试、本地回归、失败诊断。AI 可以把这些能力的入口变得更低。
第二，让测试资产和业务代码并行生产。需求开发时，测试代码就应该开始出现。接口定义出来，契约测试可以跟着生成。提测时，基础验证应该立刻发生，而不是测试人员才开始从头准备。
第三，按风险分配测开精力。不是所有需求都值得测开深度介入。低风险需求走标准工具和门禁，高风险需求才值得测开提前参与。
第四，把每次业务支持沉淀成通用能力。测开最怕的是一次性劳动。AI 可以帮助把临时脚本变成模板，把排查过程变成诊断流程，把复盘结论变成规则。
第五，把 AI 当成质量体系的一部分，而不是一个外挂聊天框。真正有用的是让它接入需求、代码、用例、缺陷、环境、监控这些上下文。没有上下文，AI 只能给通用建议。有了上下文，它才可能变成团队自己的质量助手。
——结尾：重新试一次
我不想把 AI 写成救世主，它不是。
一个没有质量意识的团队，不会因为接入 AI 就突然变得重视质量。一个长期把测开当业务支撑岗使用的组织，也不会因为 AI 自动长出质量工程体系。
但我仍然觉得这是一次机会。
理想中的测开一直存在。过去不是没人想做，而是太贵、太慢、太依赖人，也太容易被业务压力打断。现在，AI 让一部分成本开始下降。这些变化不足以自动带来理想测开，但足以让我们重新试一次。
测试开发真正要面对的，不是 AI。而是能不能借 AI 之力，完成一次迟到已久的岗位升级：从脚本生产者走向质量能力设计者，从需求支撑者走向帮助研发把自测做扎实的人，从工具开发者走向质量体系建设者。
如果这一步走不出去，AI 会成为压力。
如果走得出去，AI 可能会成为测开离理想最近的一次机会。