80浏览
导读
这篇文章想讨论的不是“AI会不会取代测开”，而是一个更本质的问题：测试开发这个岗位，原本应该成为什么？
这两年聊测试开发，很容易绕到一个问题上：AI会不会取代测开？
我一开始也会被这个问题吸引。毕竟现在的大模型确实能写测试用例，能补自动化脚本，能分析日志，甚至能根据接口文档生成一批看起来还不错的测试代码。站在一个测试开发工程师的角度，这件事很难完全无感。
但想得久一点，我反而觉得这个问题有点偏。
AI会不会取代测开，当然值得讨论。但更值得讨论的是：测试开发这个岗位，原本到底应该是什么？
如果一个测开的主要工作，是把手工用例翻译成脚本，是临时帮业务造数据，是需求提测后赶紧补自动化，是流水线挂了以后去修一下，是每个版本都被业务拉着救火，那么AI带来的压力会非常直接。因为这些工作里，确实有不少可以被生成式工具加速，甚至部分替代。
可如果测试开发的价值，是建设质量能力，是让研发更容易自测，是让测试资产和业务代码一起生长，是把历史问题、业务规则、风险判断沉淀成工具、框架、门禁和模型，那么AI就不是简单的替代者。
它更像一次迟到的机会。
理想中的测开并不是AI时代才出现的新概念。早在没有AI的时候，它就已经在那里了。只是过去我们经常够不到。
所以这篇文章更像一次自问自答。
我不是想证明AI一定会替代谁，也不是想写一篇“测开应该如何拥抱 AI”的工具指南。工具当然要学，但我更关心另一个问题：如果暂时把AI放到一边，我们对测试开发这个岗位的期待，本来是不是就有些模糊？
很多时候，我们嘴上说测开要做质量工程，要做平台化，要做自动化，要提升效率。但落到日常工作，又会变成另一副样子：需求来了先支撑，环境坏了先修，数据缺了先造，脚本挂了先看，线上报警了先跟。时间长了，测开到底是在建设质量能力，还是在维持业务交付不掉链子，就有点说不清了。
我想从这个说不清的地方开始。
这篇文章大概会围绕几个问题展开：
- 测开为什么曾经从“写脚本”开始？
- 为什么“脚本工程师”这种形态没有长期成为主流？
- 没有AI的时代，理想测开为什么很难实现？
- AI改变的到底是什么？
- 如果重新试一次，测开应该往哪里走？
测开曾经从脚本开始
测试开发这个岗位，并不是一开始就带着“质量工程体系建设者”的光环出现的。
在很多团队里，它最早的形态其实很朴素：写脚本。
把手工测试步骤翻译成自动化脚本。把登录、下单、支付、查询、审批这些流程写成代码，让机器在夜里跑，让回归不再完全依赖人一遍遍点页面。
那时候有些人会被叫作自动化测试工程师，有些人叫测试脚本开发，有些团队里甚至没有明确名称，只是有一类人比普通测试更会写代码，于是承担了“把测试自动化起来”的任务。
这个阶段当然有价值。
如果一个流程每天都要回归，靠人点十遍、二十遍，会很慢，人也会疲劳。脚本能把重复动作固化下来，让机器替人跑。它把测试从纯手工执行往前推了一步。
但问题也很快出现。
脚本替代的是动作，不是判断。
脚本可以点击按钮，可以调用接口，可以比对返回值，却不天然知道这个场景为什么重要，也不知道这个需求真正的风险在哪里。一个脚本通过了，只能说明它覆盖的那条路径没有暴露问题。它不能证明系统没有风险。
更麻烦的是维护成本。
页面改了，脚本挂了。接口字段变了，脚本挂了。测试数据被污染，脚本挂了。环境不稳定，脚本也挂了。到最后，有些自动化体系变成了另一种负担：不是脚本帮人工作，而是人每天照顾脚本。
这也是为什么“脚本工程师”这种形态很难长期成为主流。
一个岗位如果只解决执行问题，就会不断被更便宜、更快的执行工具挤压。
过去是自动化框架挤压手工执行，后来是平台化能力挤压单点脚本，现在轮到AI挤压脚本生产。这不是AI才带来的故事。这个趋势早就开始了。
只写脚本，回答不了质量问题
质量工作里最难的部分，从来不是“点哪里”。
更难的是这些问题：
- 这个需求最可能出问题的地方在哪里？
- 哪些风险应该由研发在开发阶段发现？
- 哪些问题适合用接口测试召回？
- 哪些问题必须放到集成环境甚至线上灰度里观察？
- 哪些历史问题应该沉淀成回归资产？
- 一次上线前，测试到什么程度才算可以接受？
- 出了线上问题，是用例没覆盖，环境不真实，数据不充分，还是压根没有做变更影响分析？
这些问题，脚本本身回答不了。
所以后来的测试开发岗位开始分化。有些人继续维护自动化脚本，有些人转向测试平台，有些人开始做环境治理、数据构造、CI/CD、质量门禁、精准测试、流量回放、监控巡检。
这条路其实是对的。测试开发不应该停在“把测试动作写成代码”这个层面。它应该往上走，去解决测试为什么低效，质量为什么漏出，风险为什么识别不出来，研发为什么自测困难，线上问题为什么不能更早发现。
换句话说，测开的价值不该只看写了多少脚本，而要看它有没有让质量变得更容易被生产出来。
这句话听起来有点绕，但我觉得很重要。
质量不是最后测出来的。它是在需求、设计、开发、自测、联调、回归、发布、监控、止损这些环节里一点点形成的。测试开发如果只站在提测之后，那就已经晚了。
我为什么越来越在意“理想测开”
我以前对测开的理解，也没有一开始就这么“体系化”。
很长一段时间里，我也会自然地把测开和自动化、平台、工具放在一起。好像只要能写代码，能做平台，能把测试执行自动化起来，就比传统测试更“技术化”一点。
这种理解不能说错，只是它不够。
因为你很快会遇到一些很别扭的场景。
自动化用例很多，但线上问题还是发生。平台页面很多，但业务还是不爱用。测试工具越来越多，测试工作却没有明显变轻。测开每天都在忙，但忙完以后，下一次需求还是从头来一遍。
这时候就会意识到，问题不在于有没有工具，而在于工具有没有改变质量生产的方式。
比如数据构造平台，如果只是把原来人工查库、写 SQL 的动作搬到页面上，它当然有价值，但价值有限。更理想的状态，是研发在开发阶段就能自己构造符合业务状态的数据，测试在设计用例时能复用这些数据模板，线上问题复盘后还能补充新的异常数据模型。这样它就不只是一个工具，而是质量资产的一部分。
再比如自动化测试，如果只是把手工步骤翻译成脚本，它也有价值，但很容易变成维护负担。更理想的状态，是自动化和变更影响、业务链路、历史缺陷、准出规则连在一起。一个需求改了某个接口，系统知道该跑哪些用例，也知道哪些历史问题要重点关注。这样自动化才不只是执行器，而是风险识别体系的一部分。
我觉得，测开的真正难点不在“会不会写代码”，而在于能不能把质量工作从一次次项目交付里抽象出来：
- 抽象成工具
- 抽象成规则
- 抽象成数据
- 抽象成流程
- 抽象成别人愿意用的能力
这件事很难，但它才像测开的本职。
理想中的测开，其实一直存在
我理想中的测开团队，大概是这样工作的。
研发是质量第一责任人。
基础功能是否正确，核心分支有没有覆盖，异常路径有没有处理，接口契约有没有破坏，这些不应该全部等到给QA提测后兜底。
测开的角色，是让研发更容易把这些事情做好。
比如，一个需求还在开发阶段，测试能力就已经介入了。不是等研发说“我提测了”，测试才开始理解需求、准备数据、写用例，而是业务代码在写的时候，测试代码、接口用例、契约校验、核心链路回归也在并行生成。
理想一点的工作流应该更像这样：
- 研发本地可以一键构造数据。
- 提交代码后，基础用例自动执行。
- 接口变更后，契约测试能发现影响。
- 主链路改动后，相关回归集会被推荐出来。
- 提测不是测试工作的起点，而是已有测试资产的一次集中验证。
普通需求不需要每次都把测试人员完整卷进去。它们应该尽量通过工具、门禁、自动化、数据和环境能力完成基础保障。测开人员应该把更多精力放在高风险需求上，比如资金链路、核心交易、复杂状态机、跨系统履约、线上大流量场景、历史事故高发区域。
这不是说测试人员远离业务。
恰恰相反，测开要少量但深入地接入业务。不是每个需求都浅浅参与一下，而是挑那些最值得投入的需求，钻进去，把一类问题的验证能力沉淀下来。
比如做一次订单取消需求，测开不只是把这个需求测完，而是顺手把订单状态机校验、幂等校验、库存回滚、资金一致性、优惠券返还、异常补偿这些能力沉淀成工具或用例集。下一次再有类似需求，研发可以直接复用。
这才是测开应该有的杠杆。它不是替业务多测一点，而是让下一次同类问题不再从零开始。
这里很容易被误解：我说“研发应该自测”，不是说测试人员就不重要了；我说“普通需求应该通过工具和门禁完成基础保障”，也不是说测开可以离业务越来越远。
恰恰相反，如果测开远离业务，它做出来的工具大概率不会好用。
质量能力一定是从真实业务痛点里长出来的。你没有见过研发为什么不愿意自测，就很难设计出真的能降低自测门槛的工具。你没有经历过测试为什么造数据痛苦，就很难理解一个“好用”的数据平台到底应该藏掉多少复杂性。你没有跟过线上问题，就很难知道监控、日志、链路、变更记录之间差的那一块信息有多要命。
所以理想状态不是测开退回后台闭门造平台，而是少量、深入、高质量地接入业务。
- 少量，是为了不被所有需求平均消耗。
- 深入，是为了看见真实问题。
- 高质量，是为了每次接入都能沉淀出下一次可复用的能力。
测开不应该成为每个需求的“技术测试人力”，但也不能变成完全脱离业务现场的“平台开发人力”。这两边都不对。
我更认可的状态是：测开带着建设能力的目的进入业务，再带着业务问题回到能力建设。
这条往返通道如果断了，测开就会偏。
为什么过去很难做到
说起来很美，落地很难。
没有AI的时代，理想测开一直很难实现。不是大家不知道这个方向，而是成本太高。
第一层成本是技术成本。
环境要稳定，数据要可构造，用例要能维护，自动化要能跑，失败要能定位，链路要能分析，风险要能评估。这些东西没有一个是轻的。
很多团队一开始都想做平台，想做统一能力，想做质量中台。做着做着就会发现，最难的不是写几个页面，也不是调几个接口，而是业务太复杂，数据太散，规则太多，历史债太厚。
测试数据不是简单插几张表。一个订单背后可能有用户、商品、库存、价格、券、支付、履约、售后。你想构造一个“看似普通”的订单，可能要穿过半个系统。
变更影响分析也不是一句“精准测试”就能解决。代码、接口、服务拓扑、历史缺陷、用例、流量、监控数据要能连起来。连不起来，很多判断就只能靠人拍脑袋。
第二层成本是业务压力。
这可能更现实。
很多测开团队不是没有理想，而是没有时间。
今天需求要提测，先帮忙造个数据。明天自动化挂了，先修一下。后天环境有问题，先排查。大后天线上出了报警，先跟进。月底要大促，先把回归撑住。
久而久之，测开就被业务需求牵着走。
长期能力建设永远排在“这个版本先上线”后面。可长期能力建不起来，下一个版本又会更依赖人肉支撑。于是团队进入一个很熟悉的循环：越忙越没时间建设，越没建设越忙。
第三层成本是组织成本。
测开想真正发挥作用，不能只靠自己写代码。
它需要研发愿意承担自测责任，需要产品把验收标准说清楚，需要架构愿意暴露服务关系，需要发布流程接入质量门禁，需要线上故障复盘形成可复用规则。
如果测开只有建议权，没有流程权，很多事情只能停在“我们做了一个工具，大家有空可以用”。这种工具最后往往用不起来。
第四层成本是价值证明。
功能上线了，价值很容易被看见。质量体系做得好，很多时候体现为问题没有发生。
但“没有发生”很难证明。
一个线上事故被拦住了，大家可能觉得这是应该的。一个需求因为门禁发现问题晚了两小时上线，业务可能先看到的是延迟，而不是避免了潜在损失。测开的价值经常藏在那些没有爆炸的夜晚里。
这就导致一个尴尬的局面：测开被期待做长期建设，却很难获得长期建设所需的资源、耐心和授权。
过去理想测开难以实现，不是因为理想错了，而是因为抵达理想的成本太高。
还有一个原因，我想单独说。
很多团队没有真正给测开留下“长出来”的时间。
这不是抱怨业务。业务要交付，这是现实。产品要上线，活动要保障，线上问题要处理，这些都不能等。问题在于，如果测开的时间长期被这些事情切碎，它就很难积累复利。
质量能力是需要复利的。
一个稳定的数据构造能力，可能要从十几个痛苦需求里慢慢抽象出来。一个靠谱的回归推荐能力，可能要先把代码、接口、用例、缺陷之间的关系一点点补上。一个真正有用的质量门禁，也不可能第一天就很准，它要经历误拦截、漏拦截、规则调整、业务适配。
这些事情都需要连续投入。
但现实里，测开经常被安排在离业务火线最近的位置。哪里缺就补哪里，哪里急就去哪里。短期看，这样很有效。长期看，测开会失去自己的主线。
这就是我前面说的恶性循环。
体系没建好，所以业务更依赖人。业务更依赖人，所以测开更没时间建体系。
这件事如果不被打断，团队就会一直在同一个地方打转。
AI 改变的不是方向，而是成本
AI出现以后，很多人第一反应是：危险了。
这个反应可以理解。毕竟AI确实能写脚本，能生成测试用例，能分析日志，能解释失败原因。过去一些需要人花时间做的事情，现在模型几秒钟就能给出一个版本。
但我更愿意换个角度看。
AI没有重新发明测开。它只是让过去一些太贵、太慢、太依赖人的事情，开始变得可以重新尝试。
- 过去写测试用例贵，现在可以让AI先生成草稿，人来筛选和修正。
- 过去写接口测试代码贵，现在可以基于接口文档、调用样例、历史用例生成一版初始代码。
- 过去整理历史问题贵，现在可以让AI从缺陷、复盘、日志里抽取规则和风险点。
- 过去研发不愿用测试工具，可能是门槛太高。现在可以通过对话式入口，把造数、查日志、跑用例、看报告这些动作变得更顺手。
- 过去失败定位需要翻日志、查链路、看变更。现在AI至少可以帮忙聚合信息，先给一个排查方向。
这些事情单独看都不神奇。
但放在测开这个岗位里，它们可能改变成本结构。
原来一个测开想让测试资产和业务代码并行生产，需要大量时间写用例、写脚本、维护框架。现在AI可以承担一部分初稿工作。原来想把历史问题沉淀成规则，需要人工长期整理。现在可以把复盘、缺陷、代码变更、线上日志喂给模型，让它辅助归纳。
当然，AI不是质量本身。
AI会胡说，会漏场景，会生成看起来很完整但其实没什么用的用例。它写出来的测试代码也可能脆弱、重复、不可维护。更重要的是，AI不知道一个业务真正怕什么，除非我们把足够多的上下文、规则和约束给它。
所以AI不能替组织承担质量责任，也不能替测开完成风险判断。
但它能降低很多工作的启动成本，这就够重要了。
因为理想测开过去最难的地方，恰恰是很多正确的事情成本太高。
不过这里也有一个反面，AI也可能把旧问题放大。
如果一个团队原来就把测开当成业务支撑岗，那么AI可能不会让测开更自由，反而会让业务对测开的响应速度期待更高。以前写一批接口脚本要两天，现在有AI了，是不是半天就行？以前整理一份测试报告要半天，现在有AI了，是不是十分钟就行？以前一个需求测三天，现在工具更强了，是不是一天就够？
看上去效率提高了，但人可能更喘不过气。
因为节省出来的时间没有回到体系建设，而是被更多短期需求吃掉了。
所以AI的价值不是自动发生的。它需要被放进一个正确的工作模式里。
如果测开的定位不变，AI只是加速器。它会加速脚本生产，也会加速救火；会加速报告生成，也会加速短期交付压力。
只有当团队愿意把AI节省下来的成本投入到长期能力里，它才真的有可能改变测开的处境。
AI 时代，测开应该重新回到理想模式
如果AI只是被用来更快地写脚本，那测开的处境可能不会变好。
业务会说：既然AI能写，那你再快一点。
研发会说：既然AI能生成用例，那测试应该覆盖得更多。
管理者会说：既然效率提升了，那人是不是可以更少？
如果测开没有自己的主线，AI只会让短期支撑工作跑得更快，也让人更快被卷进去。
所以关键不是“测开如何使用AI工具”，而是测开要把AI放进什么样的质量体系里。
我觉得至少有几件事值得重新做。
1. 让研发真正具备自测能力
研发自测不能只靠一句口号。你不能一边要求研发自测，一边让他手工查库、手工造数据、手工找接口、手工拼参数、手工看日志。
测开要提供足够好用的能力：数据构造、接口验证、Mock、契约测试、本地回归、失败诊断、质量报告。AI可以把这些能力的入口变得更低，比如用自然语言描述“给我构造一个已支付但未履约的订单”，系统自动完成后面的数据准备和依赖处理。
2. 让测试资产和业务代码并行生产
需求开发时，测试代码就应该开始出现。接口定义出来，契约测试可以跟着生成。业务规则确定下来，边界用例可以跟着生成。历史缺陷关联到某条链路，回归用例可以被自动推荐。
提测时，基础验证应该立刻发生，而不是测试人员才开始从头准备。
3. 按风险分配测开精力
不是所有需求都值得测开深度介入。低风险需求应该尽量走标准工具和质量门禁。高风险需求才值得测开提前参与设计测试策略。
这需要风险识别能力。AI可以帮忙读需求、读代码变更、读历史缺陷，给出初步风险提示。但最终判断仍然要由人来定。因为有些风险不是代码层面的，是业务常识层面的。
4. 把每次业务支持沉淀成通用能力
测开最怕的是一次性劳动。
今天帮这个需求造一批数据，明天帮另一个需求写一批脚本，后天帮第三个需求查一晚上日志。如果这些工作没有沉淀，团队永远在原地跑步。
AI可以帮助把一次性的经验整理出来：把临时脚本变成模板，把排查过程变成诊断流程，把复盘结论变成规则，把口头经验变成可搜索、可执行、可推荐的质量资产。
5. 把AI当成质量体系的一部分，而不是一个外挂聊天框
如果AI只是一个问答工具，它的价值会很有限。真正有用的是让它接入需求、代码、用例、缺陷、环境、监控、发布、故障复盘这些上下文。
没有上下文，AI只能给通用建议。有了上下文，它才可能变成团队自己的质量助手。
我还想加一件更朴素的事：测开要重新定义自己的交付物。
以前我们很容易把测开的交付物看成脚本、平台、工具、报告。这些当然都是交付物，但还不够。
更值得看的交付物应该是：
- 研发是否更容易自测了？
- 同类需求下一次是否更少依赖人了？
- 历史问题是否变成了可执行的规则？
- 核心链路的风险是否更早暴露了？
- 线上问题发生后，定位和止损是否更快了？
- 测试资产是否能被新人、研发、AI一起使用？
如果这些问题的答案没有变化，平台再多也只是表面繁荣。
测开要对“能力是否真的被使用”负责，而不只是对“能力是否被开发出来”负责。
这句话可能有点扎心。很多内部平台最后变成摆设，不是因为开发得不努力，而是它没有进入真实流程。没有流程约束，没有使用场景，没有持续反馈，也没有让使用者少受一点苦。
质量能力如果不进入研发日常，它就只是一个链接。
真正要变的是质量生产关系
过去很多团队的质量模式是后置的。
研发开发完，提测。测试发现问题，打回。研发修复，再回归。时间不够，就压缩测试。线上出了问题，再复盘，再补一条规则。
大家都很忙，也都很辛苦，但系统没有变。
理想的模式应该不一样。
研发写代码时，质量能力就在旁边。需求规则能转成用例，接口契约能自动校验，核心链路能自动回归，历史问题能被提醒，提测前大部分低级问题已经暴露。
测试人员不再把主要精力花在重复执行上，而是判断风险、设计策略、观察体验、处理复杂场景。
测开也不再只是业务交付的技术支撑，而是质量能力的建设者。他要关心的不是这个版本多跑了多少脚本，而是下一次类似需求能不能更轻松、更早、更准确地完成验证。
这其实是一种质量生产关系的变化。
- 研发不再把质量外包给测试。
- 测试不再把希望寄托在最后一轮回归。
- 测开不再把自己困在脚本和平台需求里。
- AI也不再只是帮大家更快完成原来的工作，而是参与到质量资产的生成、整理、执行和反馈里。
如果能走到这一步，AI时代的测开反而会更接近它原本应该成为的样子。
结尾：重新试一次
我不想把AI写成救世主，它不是。
一个没有质量意识的团队，不会因为接入AI就突然变得重视质量。一个长期把测开当业务支撑岗使用的组织，也不会因为AI自动长出质量工程体系。
AI甚至可能让问题变得更严重。因为它提升了短期产出速度，业务需求会跑得更快，测开如果没有清晰定位，只会被更快地卷进交付压力里。
但我仍然觉得这是一次机会。
理想中的测开一直存在。过去不是没人想做，而是太贵、太慢、太依赖人，也太容易被业务压力打断。
现在，AI让一部分成本开始下降。
用例生成没那么贵了，测试代码初稿没那么贵了，日志分析没那么贵了，历史经验整理没那么贵了，研发使用质量工具的门槛也可能没那么高了。
这些变化不足以自动带来理想测开，但足以让我们重新试一次。
测试开发真正要面对的，不是AI。
而是能不能借AI之力，完成一次迟到已久的岗位升级：从脚本生产者走向质量能力设计者，从需求支撑者走向帮助研发把自测做扎实的人，从工具开发者走向质量体系建设者。
如果这一步走不出去，AI会成为压力。
如果走得出去，AI可能会成为测开离理想最近的一次机会。
