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

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