功能测试 on 重定向学院

字节“测试转开发”：披着AI外衣的变相裁员与降薪

Mon, 12 Oct 2026 14:30:00 +0800

最近看到有消息说字节现在正在进行测试转开发的尝试，但属于小范围灰度试点，并非全公司一刀切。

字节官方并没有任何说明，我找了一下信源，基本属于二次加工二次传播，真实性存疑，但无风不起浪，这件事应该还是有一定的可信度的。

消息来源

掘金：《突发！字节内部大调整，QA直接转研发了？》（2026-09-28 左右）
腾讯云开发者社区 / 掘金：《QA 正在被“升级”，不是被“取代”：字节这次调整在说哪件事》（2026-09-29）

简单说明一下我的观点，这件事情的本质还是在降低研发成本，而不是去提升产品质量。这是一种变相裁员和降薪的方式，而且并非行业首创。

AI 时代，为什么回归测试反而更重要了？

Sun, 27 Sep 2026 10:06:18 +0800

我有一个暴论，在AI时代，回归测试将变得越来越重要。

最近发现AI经常出现改一个问题，送几个bug情况。仔细分析一下，几个项目里都出现了类似的情形。

A项目中AI增加了一个字段，却误判了老字段的影响的范围，将之前的字段默认值重置了，导致了线上的旧版本出现了严重的问题；B项目里AI修改了一个小问题，却没有考虑到对其他功能的影响，也产生了一些线上缺陷。

因为这些改动都不大，所以我们在回归的时候并没有走全量，只是把相关的功能做了回归跟验证，这固然是测试的失误，但研发也搞不清楚AI具体进行了哪些修改，基本上只是AI操作员，或者是需求输入员，离程序员这个职位的初衷越来越远，在几方的共同努力下，线上缺陷有上升的趋势。

也正是这些情况的频繁出现，我觉得在AI时代，回归测试将变得越来越重要。

英雄式的变更安全感现在越来越弱

不知道大家有没有过类似的感受，在不是很久远的古法编程时代，一个成熟的团队中往往有一个或多个老专家，他们做新需求或者是修复问题往往十分靠谱，要么每次产出的bug基本很少，要么就是对变更的影响范围估计的十分准确，测他们开发的需求往往有实实在在的安全感，回归的范围也基本清晰可控。

但是在AI编程时代，这种个人英雄式的开发带来的安全感却在逐渐消失。

原因可能多种多样，有可能是单位时间内AI产出的代码太多，原先的老专家也没办法逐一阅读和评审，导致了疏漏；也有可能是AI对项目的理解产生了偏差，一些新晋的AI代码生成工程师完全不清楚AI究竟做了什么，最终提交测试，在宽泛的回归范围的辅助下，将一些没有妥善处理的细节给带到了线上。

时间紧，任务重，要提升效率，那么就得有取舍。

反正效率提上去了，指标也更好看了，那就让质量来代偿好了。

精准测试是不是银弹？

既然变更的影响范围没人说的清楚，那么就让AI自行判断好了。

我们这里也确实是这样做的。

每次AI输出看起来信心满满的回归范围时，我们都会按图索骥进行刻舟求剑式的回归。

但是AI给出的影响范围有时候也会出错，假设出错的概率是一定的，那么单位时间AI写的代码越多，隐藏的bug可能就越多。

这时候想要又快又好就非常有挑战了。

那么是时候让精准测试大展拳脚了。

我们尝试过用分析调用链的方式，找到某次变更的影响范围，但是遇到了2个问题。

静态分析的速度比较慢，赶不上AI产生变更的速度。如果按照版本或者迭代来分析，那么影响范围又相对比较大，精准性就打了折扣；
影响范围可以确定下来，但是如果遇到多场景的情况，那么静态分析是没办法给出具体会受到影响的地方的；

所以后面我们的方向是通过静态分析去确定范围，然后加上AI辅助分析去确定场景，希望可以通过精准给出上下文的方式降低AI的幻觉，提升测试的精准性。

全量回归是不是必选项？

我们目前的回归策略是主流程回归，每次大的版本发布都会去做。

不过现在我们在主流程回归的时候也会漏掉细节，比如有次的一个变更导致了主流程上一个很小的分支流程出了问题，但是我们回归的时候漏掉了，复盘的时候我们在TAPD单上可以很清楚的看到AI给出了影响范围，很遗憾，那个场景AI也漏掉了。

盲目的全盘接受AI的判断显然不是一个好的回归策略。

所以当下每次大版本在发布之前都需要进行细粒度的主流程回归，全量回归的时间太长，只能抓大放小，把监控的维度补上去，出了问题快速响应，快速修复，用最少的时间去加固核心质量，其他的只能亡羊补牢，见机行事了。

但不是所有人都认可回归测试的重要性，比如一种叫做老板的生物就会认为开发节约的时间在测试阶段全部给还了回来，研发提效变成了啼笑皆非，这显然是不能接受的。

当然了，这也就解决的方案，那就是要么把测试全开了，研发兜底；要么把研发开掉一部分，让测试去做代码生成操作员，或者更进一步，把测试和开发都开了，让产品自己去solo全流程，这些可能会在短期造成质量的急剧下降，但如果长时间运转下去，效率大概率是会有提升的。原因很简单，这样减少了流程和反复沟通，明确了质量责任人，没人甩锅，只能负重前行，质量和效率最终会达到平衡。

不过这是九阴真经，欲练神功，是不是要狠下心去挨上一刀，那就见仁见智了。

自动化回归

代码的产出变得日益廉价，自动化回归的门槛也变得越来越低。

因为UI自动化的不稳定性，以及实现难度较高，我还是建议从单元测试和接口测试的自动化先做起。

单元测试覆盖率越高，变更的影响就越容易判断，AI产生幻觉的风险也会降低；接口测试的场景越丰富，集成过程中的问题也就越容易暴露。

至于主流程的UI回归，有条件的话就用自动化去实现，但用例一定要设计的足够精巧，每一步都要有精心的编排，这样稳定性才会有显著的提升，ui自动化才有发现bug的能力。

没有条件的话就先手工回归吧，毕竟大多数的产品还是给人类去用的，站在人类的角度去回归也是合情合理。

总结

综上所述，由于AI代码生成工程师可能不了解AI生成代码的所有细节，加上AI依然会产生幻觉，在单位时间内代码产出量急剧增加的大背景下，变更所带来的隐藏问题可能会越来越多。

回归测试是当下一个简单且有效的测试策略，我们可以通过精准测试来减少回归范围，用自动测试来提升回归效率，最后对于面向人类用户的产品，还是要人工验证一下主流程，毕竟你是要赚用户/客户的钱，而AI是要赚你的钱，它对客户/用户没有任何的义务。

AI提效半年后，我们的测试团队规模反而更大了

Fri, 28 Aug 2026 10:06:18 +0800

公司的AI提效进行了半年了，距离上一次总结和分享也过去快3个月了，是时候重新审视一下最近几个月的观察和实践了。

一些观察

提测质量降低。就目前的情况看来，在工程化程度一般的团队，使用AI进行高强度的代码开发之后，提测的质量看上去是降低了。比如提测之后发现需求做漏了，单位时间内测试发现的bug数变多了。我也思考了一下，在用AI写代码之后，由于单位时间产出的代码量有成倍的提升，所以一些开发基本上也不知道代码里到底干了些什么，自己只是做AI的操作员，不了解代码运行的逻辑和细节，一些之前自己写的时候会去详细拆解的细节点就这样被忽略掉了，bug变多就不足为奇了。另外产品经理现在也是用AI去写产品文档，开发在转代码的时候不会详细去看需求的细节，而是直接让AI去总结需求的内容，属于用魔法打败魔法。这种内容压缩的过程中细节丢失，最终可能导致代码没有实现需求中所有的要求。
测试团队扩大。AI提效之后我们测试团队人力增加了23%，但目前还是处于人力紧张的状态。这可能是因为AI让需求实现的周期缩短了，所以单位时间提测的需求变多了；另外提测质量降低了，测试周期不变的情况下，测试的工作量其实是提高了。
开发过度依赖AI导致需求返工。我们一个比较复杂的需求，由于各种各样的关系，开发过度依赖AI进行方案的设计和实现，最后在做code review的时候发现了很多严重的问题，最终导致需求返工重写，浪费了非常多的时间。这其实暴露了2个问题，第1就是在复杂问题的处理上，AI可能还有提升的空间；第2个问题其实比较普遍，开发人员过度相信AI，较少的进行自我思考，最终交付的产出物质量变低，存在相当大的风险。
测试人员写用例的门槛变得非常低。之前一个需求可能要写2天，现在一上午就搞定了。如果只是把需求内容直接丢给AI一把梭的话，可能几分钟就搞完了。这就可能导致一些需求，测试人员都没完整的看完和消化，测试用例就已经大而全的准备好了。所以我们现在对用例评审抓的比较紧，这是因为1，我们要在提测前最后对齐一次需求，沟通的成本不能省；2，强制让测试人员讲解用例，尽量保证大家都把需求读完了，弄明白了。
测试提效困难。AI可以很好的辅助测试用例的编写，但是在用例执行方面，还是有很多地方不能替代人工的。比如我们有个小项目，170条用例，AI可以自己执行大概50-60条，剩下的大头还是要人工去执行。而且AI执行的用例都比较简单，复杂一点的用例，比如去后台改个配置，然后再去观察用户同样操作下的另外一种表现，这些AI是没办法执行的。本质原因就是我们的用例里面没有给AI所有的必要信息，比如后台怎么操作，产品的所有细节等等，这就导致AI在业务知识以及技能储备方面不如专业测试，一些用例人类能看懂并且脑补的，AI没办法看懂，所以可执行的部分就十分有限了。而测试如果要提效，大头其实是在执行用例上面，目前看来能提效，但是覆盖面比较有限。
从发散思维到回归。我们这边测试全员都是要使用codex做一些提效相关的事情的，刚开始的1-2个月，我们鼓励每个测试人员把手头上需要重复去做的事情都想办法让codex去做，效果其实一般。后来我想了想，这是因为消除重复工作本质上是在开发工具，而开发工具比写业务代码要难，也比写自动化测试用例难，所以大家无从下手，这也是情有可原的。后面我改变了思路，先把框架搭好，然后让大家去根据业务场景补充自动化用例，把回归测试先做起来，这样方向限制住了之后，大家的参与度才慢慢的有了一些提升。

一些实践

测试用例评审前置。我们现在用AI做开发，遗漏需求细节基本变成了常态，所以我把研发流程稍微改了一下，需求评审完成之后直接用例评审，把测试用例作为研发过程中的输入，目前看来质量提升效果不明显。可能是因为开发为了提高吞吐量在需求评审之后就直接开干了，测试用例出来的时候功能都做完了，所以前置了个寂寞。
测试skill的全面使用。之前让我们这边的测试人员去开发一些造数的工具，用来提升数据准备的效率。后来发现工具写起来很困难不说，而且写好以后还要去跟使用者讲使用技巧，本身对使用者来说也是有心智负担的。最近我们改变了策略，直接把一些造数能力做成cli，然后封装成skill，测试人员只要告诉AI具体要什么样的数据，最后AI负责执行操作，编排步骤和核对结果。目前基本上这些skill每天都会用到，对测试效率的提升有着不错的正向效果。
回归用例的持续建设。测试工具不好写，但是回归用例用AI去写还是有可能的。之前我们陷入了一种误区，就是把所有的项目相关的上下文一股脑的丢给AI，让AI自己去写接口用例和UI用例，实际效果并不好。后来我们改变了策略，测试用例和断言都用自己语言去写，AI负责用代码去实现，这样用例的质量得到了巨大的提升，尽管人工参与的部分变多了，但是自动化用例的可掌控性实际上是变高了的，有信心的用例才是值得反复去执行的回归用例。
性能压测的工程化。在做后台压测的时候，对于一些稍微复杂一点的场景，数据准备往往是比较困难和费时的，特别是我们现在的团队偏年轻，大家没有相关经验，做起来更是举步维艰。后面我们尝试用AI去做压测数据的生成，测试人员负责构造测试场景，给出造数据的方案以及步骤，AI负责代码化和工程化，整个的性能测试流程变得顺畅了很多。其实压测数据的准备是有点难度的，拿我们之前压测的一个项目举例，我们需要用python去跑数据构造，用shell脚本去做场景编排和调用，最后用wrk实现测试脚本的时候还需要用到lua脚本，一个场景就需要用到3种不同的编程语言，这对测试人员的挑战很大，不过现在AI参与进来之后，这些流程定义的非常清楚的过程脚本的实现就非常简单，整体的测试效率得到了极大的提升。
千奇百怪的各种监控。我们有时候会收到一些奇怪的需求，比如要监控某个邮箱里的邮件，如果出现一些运营商或者应用市场发出的特定类型邮件就要进行告警。类似这样的监控，我们做了挺多的，AI实现起来又快又好，等于是节约了很多人工巡检以及打杂的时间，提升了项目的质量下限。
逆向应用进行接口测试。测试没有前后端的代码，而我们的前后端文档年久失修，不一定能反应当下应用的状态。所以我们通过AI去逆向前端和客户端应用，找到真正接口调用的方式和流程，配合请求抓包，拿到真实参数，最后用AI进行接口的编排和用例实现，把核心场景的接口调用都测试了一遍。因为是确定的代码，所以用例可以反复运行，配合ci/cd，就可以实现更加丰富的测试策略。
Web及H5测试。我们发现一些特定类型的产品，在给出足够上下文，明确操作步骤，并在skill中定义好测试的方式方法时，基本上80%以上的用例都可以让AI自己跑。当然了，AI不能背锅，所以不管怎么样，人工介入还是必须的，但是如果只是冒烟或者并行测试提升测试效率的话，web和h5的测试确实可以外包相当大的一部分让AI代劳。

一些感触

完全交给AI写代码周，提测质量下降是个很显著的事实；
一些开发人员并不知道自己提交的代码细节，给他们提bug他们也改不了，最终还是要求助AI，久而久之这块代码就成了最熟悉的陌生人，可能会隐藏风险；
测试人员负载在变高；
测试开发的门槛在降低，自动化用例生成的门槛和成本已经非常低了，但是日常的维护还是需要较大的工作量；有经验的测试开发人员可以探索的空间变大，测试工程化还是有很大的潜力的；
纯手工的测试其实是有市场的，但是要学会用AI工具去提升测试效率；
AI写的自动化用例必须人工review一下，因为AI可能偷懒，过度设计，前后矛盾，让简单的事情复杂化，编写完美主义的断言，哪怕在AGENTS.md中进行各种干预，久而久之代码还是有腐化的趋势；
讨论编程语言的意义已经不大了，根据应用场景选择语言就像是用不同的钥匙去打开不同的锁，就这么简单；
有经验的开发人员/测试人员的杠杆作用在放大，隐隐有老专家驱动开发的趋势了；年轻人现在不写代码了，成长的空间不足，如果只是AI操作员的话，年轻人是不如老专家那般可以自如面对疑难杂症的；
测试不会消失，反而越来越重要，可能以后的AI开发团队，人人都是测试；

开发靠 AI 提效，测试成最大瓶颈，现状过于真实

Thu, 21 May 2026 10:06:18 +0800

最近两个月高强度的使用AI进行了一些跟测试相关工作的探索，从之前大火的openclaw到hermes，从claude code到opencode再到codex，从各种国内模型到sunnet再到gpt5.5，感觉上是一日不见如隔三秋，两个月的时间变化相当迅速。

昨天同国内的某团队进行了一次关于ai在研发过程中使用的交流，发现大家所处的阶段以及遇到的问题都差不多，特别是在测试方面，大家的诉求痛点以及难点都是相似的，事后想了想，是时候做一些阶段性总结了。

实践

在ai与测试工作结合的方向上，我们做了一系列的探索，大体分为如下几个部分。

日常使用ai进行需求的分析，用例的增强以及知识盲区的学习

当前阶段，有些产品经理使用ai进行需求的补充和完善，某些需求一眼看上去就显得洋洋洒洒，面面俱到，但真正脱水和压缩之后，里面的信息量其实还是有限的。

这时候我们一些测试人员就使用ai进行总结，把里面的核心要素给提取出来，看上去像是提升了测试效率。

但是提取的重点有可能还是有遗漏的地方，所以需求我们还是要人工进行通读，写用例的时候也是要对照大而全的需求的，所以真实的情况是：通过ai对需求的要点进行了总结，能够比较快速的进行需求的了解，但是细节还是反复阅读和对比才能搞清楚，毕竟ai生成的需求里哪些是冗余的完全没有价值的，还是人工去判断才比较稳妥。

产品人员用ai去生成需求，其他角色用ai去阅读需求，也算是用魔法应对魔法了。

还有就是在日常进行用例编写的时候，我们也会把需求和用例都丢给ai，让ai进行一些场景的补充，很多时候ai给出的建议都是很有价值的。

最后在做一些技术优化类需求测试的时候，大部分的测试人员是不了解技术原理和优化细节的，这时候我们就会用ai进行快速学习，这点让我想起了二十年前我入行的时候，很多东西其实完全没接触过，当时硬是靠着百度和谷歌一点点的去搜索，去学习有异曲同工之妙。不过当时我们搜到的是各种材料，我们需要在材料里去总结去提炼，现在ai直接给答案了，效率跟之前相比真是不可同日而语了。

一键用例生成

我们用ai开发了一个简单的用例一键生成工作，思路是从tapd上导出项目的所有需求，并进行向量化。

测试人员在使用的时候直接把tapd的需求链接贴进去，工具会自动搜索与这个需求最接近的一些需求，然后对需求进行合并，最终分析合并过的完整需求，生成测试用例。

用例可以导出为xmind或markdown格式。

最后测试人员再精调一下导入的用例，去掉不合理的部分，加入一些用例中考虑不到的细节，形成最终用例。

这个工具目前来使用频率很高，属于不需要推广大家就会主动使用工具，在提升效率和测试质量上都有不错的帮助。

各种自动生成用例的框架

ai有其不确定性，比如问ai一个问题，ai有可能每次给出的回答都不太相同。

但对于非模型类的业务测试来说，我们需要的是确定性，确定的输入一定能得到确定的结果，这样我们才能把确定的实际结果跟预期结果进行比较，得到测试的结论。

因此用ai来直接进行测试活动还是有一定的风险的。

另外ai目前擅长的是直接输出代码，而不是直接执行用例。

基于上面这两点，我们目前对ai的使用其实是偏重于让ai直接编写测试用例（这是让ai写代码），规定好测试步骤和断言，这样每次执行的结果是稳定的，既发挥了ai写代码的优势，又一定程度上规避了ai运行结果不稳定的缺点。

我们做了如下的一些自动化的用例生成探索。

用claude code + playwright cli 全自动化生成web自动化用例。这个之前我有录过视频，感兴趣的同学可以去看一下。用这种方案只需要用自然语言把用例描述清楚，直接把用例扔给ai，就可以在无人值守的情况下让ai自己写自动化用例了。因为一般的项目都会有核心用例，只要这些用例不是xmind脑图形式的，其实都可以拿来直接用。这里有3个细节可能是比较有价值的。1，一定要让ai在写完用例之后自己跑几轮，确保所有的用例都能通过，这样用例的稳定性会大大提升；2，可以用定时任务的方式，让claude每天晚上自动去写，这样不占用上班时间；3，尽量给ai比较高的权限，比如claude code的--permission-mode auto模式，这样就不需要人工干预了；
用claude code + appium/maestro mcp实现客户端的自动化测试用例。跟上面的思路一样，只是测试对象换成了app。
用codex/claude code实现接口编排的测试用例。这里的思路是先让codex/claude实现单接口的用例，然后实现一些典型业务的接口编排用例，最后用自然语言给出高价值的业务场景，让ai自动去生成并运行用例。这里我之前是用纯pytest去实现的，后来发现接口编排的场景用代码描述出来不太直观，后面用pytest-bdd去实现了，效果要好不少。这里的思路是先实现单接口，类似于给出了接口的返回，然后实现典型场景，等于是给出例子教ai怎么去做接口编排，最后给出具体场景，让ai根据单接口和编排的例子自己去推断，准确性还是很高的，而且可以实现无人值守自己写用例。

实践中我还发现，对于一些简单的用例或者是在框架和存量用例都比较成熟的情况下，用国产模型的话都可以取得不错的效果。

各种稀奇古怪的测试工具

通过截图去测试多语言的自动化工具。我们的产品有9种语言，人工去比对翻译的正确线其实基本上是不现实的，所以这里我写了一个自动化工具，只要测试人员在对应的场景把英文和目标语言的截图保存下来，就可以自动去比对翻译的准确性了，这个工具对于提升测试效率有着不错的效果；
自动化造数工具。这里我写了几个版本，大概的思路就是导入所有的接口文档，把每个接口做成tool或者是function call，然后用agent框架，实现让ai自动去推断造数据需调用到哪些接口，自动把接口调用串起来，实现批量造数的功能。最后的效果是简单的造数行为还是可以跑通的，但是稍微复杂一点就不行了。效果一般的原因大体是接口文档可能不全，复杂的造数逻辑ai没办法一步一步进行推断，所以后面造数的工作还是要有一定的人工干预和补充，才能实现的更好；
疑难杂症的复现。有时候我们需要长期进行重复的行为去复现一些疑难杂症的问题，这属于机会主义，不仅费时，而且可能浪费了时间之后还无法达到效果。这时候其实可以用codex/claude，给其设定一个目标(goal)，让其自己写脚本去长时间运行，尝试复现；在codex辛苦复现的时候，我们可以做其他事情，不耽误日常的测试工作；
tapd质量数据上报工具。我这边在tapd上有多个项目，想把所有项目的质量数据都拉下来做横向的比较和数据的挖掘其实还是有点费事的，所以我用ai写了个自动上报的工具，每天定时把每个项目的质量数据上报到远程机器上的indexdb上面，用grafana做呈现，目前看来挺方便的，推荐大家也可以尝试一下。另外远程机器上的indexdb和grafana都是codex自己搭建的，dashboard也是ai自己去创建的，非常省事；

一些感触

因为水平有限，现阶段大部分的探索其实都是针对存量的功能去做的，在新功能的测试上，特别是在app的测试上，目前人工点击还是比ai写脚本，ai调试脚本，通过脚本操作app的速度要快的多。因为我们的产品是给人类去用的，交互多，动效多，ai对新功能的直接测试行为帮助有限，所以目前情况下，根本不存在ai去取代测试人员的情况；
开发侧在使用ai进行代码的编写之后，单位时间内提测的需求数增加了不少，导致目前测试反而成了瓶颈，测试团队的规模其实是在增长的；
个别产品存在用ai提交的代码缺陷数量较多的情况，提测质量不高，反而导致测试的工作量增加；
大部分的测试人员其实没有开发思维，所以哪怕给了他们最新的工具和最好的模型，他们在进行测试工具和用例的开发上依然困难重重；
目前上层和中层对ai的态度是拥抱的，反而执行层面的人员学习ai的热情不是很高；
当项目中不同角色之间的沟通成本足够高的时候，ai进行代码编写的效率提升其实对项目的交付速度和交付质量并没有带来本质的变化；
从开发的角度上看，ai使得年轻人的体力优势变得不是那么明显了；但对于功能测试来说，当前阶段我们靠见啊来提升生产力；
不同模型之间差距还是比较大的，有条件的话还是得上好一点的模型；

AI Agent（如 OpenClaw）如何彻底重构测试人员的工作内容

Thu, 05 Mar 2026 00:02:55 +0800

最近一直在思考如何在测试过程中使用openclaw等AI agent工具来提升测试效率。

直接用AI写用例一直是各个大厂关注的重点，各家也有了一定的突破，可以预见在不久的将来，一些通用用例的编写和执行是可以交给AI去完成的。

不过复杂业务场景下的用例编写和执行还是需要人工参与比较好。

这是因为

AI对复杂业务场景的理解可能不如测试领域的业务专家；
测试策略的制定和把控最好需要有经验的测试人员进行介入，否则方向错了，做的越多，错的越多；
如果AI在复杂业务场景下的验证工作出了问题，那就找不到人背锅了；

所以我忽然意识到，与其苦苦追求提升测试效率，不如思考一下如何去提升测试人员整体的日常工作效率。

因为毕竟编写用例以及执行用例只是日常工作的一部分。

如果除了这两部分之外的其他杂事和重复工作的完成效率提升了，那么测试人员的整体输出也会有显著的变化。

测试人员的一天

大部分测试人员的典型一天可能是这样的。

早晨启动阶段（9:00–10:30左右）

开电脑 → 查看/回复邮件、钉钉/企业微信（经常一早上要回几十条）
参加站会/早会/Scrum Daily（10–15分钟）：汇报昨天做了什么、今天计划做什么、阻塞困难以及卡点是什么
查看Bug管理系统（Jira、禅道、Tapd）：自己昨天提的Bug有没有被开发修复/重开/驳回
拉取最新构建/提测包，部署或更新测试环境，如果环境被开发玩坏了，还要求助🙏开发进行修复
快速过一遍需求变更/新提测单/hotfix说明，评估影响范围

上午核心测试阶段（10:30–12:30 / 13:30–17:00）

最占时间的部分，通常占一天50–70%：

执行测试用例（手动为主，自动化为辅）
- 跑冒烟测试/核心路径验证（新版本可能需要）
- 按优先级逐条执行详细用例
- 探索式测试（ Exploratory Testing）：随便点一点、试试各种组合、测试一下弱网、看看暗黑模式、有多设备就换设备跑一下
- 接口测试（Postman/JMeter/自己写脚本）
发现Bug → 复现 → 提Bug单
- 截图/录屏/日志/复现步骤/写清楚预期结果和实际结果
- 做严重程度和优先级的判断（比如P0致命/P1高/P2中/P3低）
- @开发、跟进讨论（经常要语音/会议演示）
跑自动化用例（如果有维护了自动化测试用例的话）
- 触发CI/CD pipeline后看下结果
- 分析失败用例的原因，是代码问题,环境问题,还是用例问题
- 修复脚本，ui用例可能要更新locator或者加等待；接口用例就增加字段或者修改已存在的字段名称
专项测试（视项目阶段）
- 性能或者压力测试（JMeter/Locust）
- 安全测试（SQL注入/XSS/垂直或水平越权）
- 兼容性/国际化/无障碍
- 回归测试（尤其是大版本后）

下午/傍晚协作 & 收尾阶段（15:00–18:30）

参加各种会议（需求评审、缺陷评审、联调会、上线评审、复盘会）
与开发/产品/运营对齐（最耗时也最关键）
- 需求不清晰，那么怼产品
- Bug开发不认，那么拉产品一起怼开发
- 上线有风险，各种升级，拉所有人一起评估
写/更新测试文档
- 写各种测试报告（日报/周报/版本报告）
- 做测试总结，覆盖率统计，典型bug分析，bug趋势分析，输出质量指标
- 写操作手册或者输出验收的checklist
环境维护/数据准备
- 造数、刷库、Mock接口
- 清理脏数据、回收资源
学习/工具优化（优秀测试的常态）
- 研究新需求的技术实现，或者参加开发的方案评审
- 学习/优化自动化框架
- 玩OpenClaw/Claude等AI Agent写用例/生成脚本/分析日志（这个比较科幻）

一天结束前（下班前30分钟）

汇总当天Bug/测试进度 → 发日报/更新看板
确认明天要测的内容、功能是否提测，环境是否ready
把未完成的用例/阻塞事项记下来

可以看出典型QA的一天比较零碎，可以工程化的部分其实有限。不过我们仍然可以提炼出一些可以进行自动化的非测试场景。

别再问测试会不会被AI取代了 ——2026年数据告诉你：QA才是最后防线

Sat, 14 Feb 2026 09:02:55 +0800

感受

我最近用 opencode 搭建了一个完整的应用。

整个过程中，我大部分的精力其实都在做3件事情。

像产品经理一样设计功能和交互
像测试人员一样验证产品的功能及交互
不停的发现bug，提出缺陷，然后跟AI一起配合修复问题

这么反复循环了几次之后，我最终意识到：AI极大地降低了实现的门槛，却成倍放大了验证的难度和重要性。

用AI进行编码，实现代码确实是唾手可得了，但是验证的过程却是没有办法省略的。

AI在进行逻辑实现的时候，如果需求描述的不是很明确，那么一些实现细节是一定会遗漏的，这点跟现存的软件开发是类似的。

需求缺乏细节，那么只有用反复的测试来弥补。

比如我要实现一个需求，大致描述一番之后，AI会给出它的实现思路，然后让我们进行选择。

我们任意选择一个选项之后，很多的细节其实是AI自己去把控的，功能看似可以完成，但不一定跟我们的初衷相符，所以要反复测试和修改才可以真正达到可用以及正确的状态。

这其实让我意识到: 生产力工具越强大，对质量把控的要求可能就要越高。

毕竟现在需求可以实现的很快，但是要又快又好，很多细节和问题都需要人类来进行测试验证以及兜底。

AI时代的产品开发范式已经变了

传统的软件开发流程是这样的。

需求 → 设计 → 编码 → 测试 → 上线，根据Pressman教材数据，在经典软件工程里，测试环节通常占 20-30% 时间。

但是现在，编码环节被压缩到10-20%，但验证以及打磨环节占比飙升到50-70%。

JetBrains《2025开发者生态报告》显示：85%开发者定期用AI工具，62%依赖至少一个AI编码助手，但他们把更多时间花在“审查AI输出”和“调试AI生成代码”上（新增开销9-18%）。

我的看法是，如果多agent模式下的AI编码能力进一步提升，在一个项目团队里，产品和测试可能会比开发更为关键，毕竟编码的内容来自产品，编码的结果验证来源于测试。

在一个人一个团队的小型项目里，不会编码就能直接做应用的例子也逐渐习以为常，这一个人，大概率是更偏向于产品设计和测试。

市场的反馈其实也是这个趋势。

在中国市场，前程无忧《2026届校招AI人才需求报告》显示：AI测试工程师月薪中位数为13621元（虽低于核心算法岗的2.4-2.5万，但需求稳定增长，头部企业如阿里、腾讯、字节在AI质量方向扩招明显）。

这反映出：企业越来越愿意为“功能验证及质量控制”的能力买单。

为什么验证环节在AI时代变得更难、更重要？

第一个原因很容想到，那就是AI生成的代码充满概率性。

有数据称幻觉率（hallucination）在复杂任务中可达 30-88%。

有时候AI觉得自己生成的东西没有问题，但真正上手测一下，就会发现一些隐藏的缺陷。

第二个原因是AI可以实现从“功能正确”，但是“体验正确”却还需要反复的打磨。

AI很快做出“能跑”的东西，但“好用、防呆、边缘情况下不崩溃”的能力，还要靠人类来进行保证。

AI生成的代码往往停留在“表面能用”的层面：语法正确、逻辑基本通顺、基本路径走得通。但一到真实用户场景，就暴露出一堆“看起来小、实际致命”的体验问题。

这些坑AI自己很难感知，因为大模型缺乏真正的共情、上下文连续性和“好的人类体验”的直觉。

比如在我自己用 ai 实现的 kidcoins里，ai实现的兑奖下拉框原本是一个普通的select控件，用户体验不是很好。后面我自己上手之后给出了需要支持搜索的建议，反复修正之后，终于达到一个基本可用的用户体验。

功能测试 on 重定向学院

字节“测试转开发”：披着AI外衣的变相裁员与降薪

AI 时代，为什么回归测试反而更重要了？

英雄式的变更安全感现在越来越弱

精准测试是不是银弹？

全量回归是不是必选项？

自动化回归

总结

AI提效半年后，我们的测试团队规模反而更大了

一些观察

一些实践

一些感触

开发靠 AI 提效，测试成最大瓶颈，现状过于真实

实践

日常使用ai进行需求的分析，用例的增强以及知识盲区的学习

一键用例生成

各种自动生成用例的框架

各种稀奇古怪的测试工具

一些感触

AI Agent（如 OpenClaw）如何彻底重构测试人员的工作内容

测试人员的一天

早晨启动阶段（9:00–10:30左右）

上午核心测试阶段（10:30–12:30 / 13:30–17:00）

下午/傍晚协作 & 收尾阶段（15:00–18:30）

一天结束前（下班前30分钟）

别再问 测试会不会被AI取代了 ——2026年数据告诉你：QA才是最后防线

感受

AI时代的产品开发范式已经变了

为什么验证环节在AI时代变得更难、更重要？

第一个原因很容想到，那就是AI生成的代码充满概率性。

第二个原因是AI可以实现从“功能正确”， 但是“体验正确”却还需要反复的打磨。

别再问测试会不会被AI取代了 ——2026年数据告诉你：QA才是最后防线

第二个原因是AI可以实现从“功能正确”，但是“体验正确”却还需要反复的打磨。