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

面试求职「面试试题小程序」 内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试命中率杠杠的。大家刷起来…职场经验干货软件测试工程师简历上如何编写个人信息一周8个面试软件测试工程师简历上如何编写专业技能一周8个面试软件测试工程师简历上如何编写项目经验一周8个面试软件测试工程师简历上如何编写个人荣誉一周8个面试软件测试行情分享这些都不了解就别贸然冲了.软件测试面试重点搞清楚这些轻松拿到年薪30W软件测试面试刷题小程序免费使用永久使用最近两个月高强度的使用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使得年轻人的体力优势变得不是那么明显了但对于功能测试来说当前阶段我们靠见啊来提升生产力不同模型之间差距还是比较大的有条件的话还是得上好一点的模型最后下方这份完整的软件测试视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​