自动化测试 on 重定向学院

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使得年轻人的体力优势变得不是那么明显了；但对于功能测试来说，当前阶段我们靠见啊来提升生产力；
不同模型之间差距还是比较大的，有条件的话还是得上好一点的模型；