过去一年，我们团队在项目中落地了AI测试自动化。从最开始的尝试，到后来的全面应用，中间踩了不少坑，也积累了一些经验。

AI测试自动化，听起来很美好。用AI生成测试用例、自动执行测试、智能分析结果，听起来能大大提高测试效率。但真正落地的时候，才发现没有那么简单。

这篇文章我想总结一下，我们在落地AI测试自动化过程中踩过的坑，以及总结出来的实战经验。希望能给正在做或者准备做AI测试自动化的朋友一些参考。

我们做了什么

先简单介绍一下我们做的事情。

我们的项目，是一个大型的Web应用，功能很复杂，回归测试的工作量很大。每次发版之前，都要花大量的时间做回归测试，效率很低，而且容易漏测。

所以，我们想引入AI测试自动化，用AI来辅助测试。具体做了几件事情：

第一个是，用AI生成测试用例。根据需求文档和代码，自动生成功能测试用例。

第二个是，用AI生成自动化测试脚本。根据测试用例，自动生成UI自动化和接口自动化的脚本。

第三个是，用AI做测试结果分析。自动分析测试失败的原因，判断是代码bug还是测试脚本的问题。

第四个是，用AI做智能回归。根据代码变更，自动推荐需要回归的测试用例，不用每次都跑全量。

这几件事情，听起来都很美好。但在落地的过程中，我们踩了很多坑。

踩过的坑

第一个坑是AI生成的测试用例质量参差不齐。最开始我们把需求文档扔给AI让它生成测试用例。AI生成的速度很快几分钟就能生成几十条用例。但仔细一看质量很差。很多用例都是很表面的比如输入正确的用户名和密码能登录成功这种。真正有价值的边界用例异常用例AI生成得很少。还有一些用例理解错了需求测的根本不是那个功能。甚至有一些用例前后矛盾根本无法执行。我们花了很多时间去审核和修改AI生成的用例。到最后发现修改的时间比自己写用例的时间还长。后来我们总结了经验不能直接让AI生成完整的用例。而是要先让AI分析需求列出测试点然后人工审核测试点确认没问题之后再让AI根据测试点生成用例。这样用例的质量就高了很多。

第二个坑是AI生成的自动化脚本不稳定。AI生成的UI自动化脚本第一次跑的时候可能能通过。但过几天再跑就失败了。原因有很多比如页面元素变了AI用的选择器不稳定等待时间不够等。特别是UI自动化本身就很脆弱。AI生成的脚本虽然能跑但不够健壮。稍微有一点变化就挂了。后来我们做了几件事情来解决这个问题。一是建立了统一的元素管理库所有元素的定位都统一管理页面变了只需要改一个地方。二是在脚本里加入了更健壮的等待机制不用固定的sleep而是用显式等待。三是定期维护脚本及时修复失败的用例。第三个坑是AI分析测试结果经常误判。测试失败之后我们让AI分析失败原因判断是代码bug还是脚本问题。AI的分析有时候很准确但有时候会误判。比如明明是代码的bugAI却说是脚本的问题建议修改脚本。或者明明是脚本的问题AI却说是代码的bug导致开发白忙活一场。后来我们发现AI分析的时候如果只给它错误日志它分析得不够准确。如果给它更多的上下文比如相关的代码最近的变更历史的测试结果它的分析就会准确很多。所以我们现在做AI分析的时候会把尽可能多的上下文信息都提供给AI。而且AI的分析结果只作为参考最终还是要人工确认。第四个坑是智能回归的准确率不高。我们想做智能回归根据代码变更自动推荐需要回归的用例。最开始我们用AI来做推荐准确率只有60%左右。很多需要回归的用例没有被推荐到导致漏测。后来我们改进了算法不只是用AI还结合了代码覆盖率调用链分析历史缺陷数据等多种信息。这样推荐的准确率提高到了85%以上。但即便如此我们也不敢完全依赖智能回归。对于核心功能还是会跑全量回归。智能回归只是作为辅助帮助我们优先测试高风险的部分。第五个坑是成本比预期的高。最开始我们以为用AI做测试自动化能节省成本。但实际上落地的成本比预期的高很多。首先是API调用的成本。AI生成用例生成脚本分析结果都要调用大模型API。用得多了费用也不少。其次是维护成本。AI生成的脚本和用例需要人工审核和维护。而且随着项目的迭代脚本和用例都要不断更新维护工作量很大。最后是培训成本。团队成员需要学习怎么用AI工具怎么写好提示词怎么审核AI的输出。这些都需要时间和精力。所以在做AI测试自动化之前一定要做好成本评估不要只看到它能提高效率还要看到它的成本。

实战经验

踩了这么多坑之后，我们总结了一些实战经验。

第一个经验是，AI是辅助，不是替代。

这是最重要的一条经验。AI能帮我们提高效率，但不能完全替代人。测试用例需要人来审核，自动化脚本需要人来维护，测试结果需要人来确认。

不要指望AI能帮你搞定一切。把AI当成一个聪明的助手，让它帮你做那些繁琐、重复的工作，而核心的判断和决策，还是要靠人。

第二个经验是，从小处着手，逐步推广。

不要一上来就想把所有测试都AI化。那样风险太大，很容易失败。

我们的做法是，先选一个小的模块，做试点。在这个模块上，跑通整个流程，验证效果。然后，总结经验，再逐步推广到其他模块。

这样，风险小，见效快，也能不断积累经验。

第三个经验是，建立完善的审核机制。

AI生成的内容，不管是测试用例还是自动化脚本，都必须经过人工审核，才能使用。

我们建立了一套审核机制。AI生成的用例，由测试工程师审核，确认没问题之后，才能加入用例库。AI生成的脚本，要先在测试环境跑通，经过代码review之后，才能合入代码库。

这样，能有效避免AI的错误，流入到生产环境。

第四个经验是，持续优化提示词。

AI的输出质量，很大程度上取决于提示词。好的提示词，能让AI生成高质量的内容。差的提示词，生成的内容就没法用。

我们花了很多时间，优化提示词。把需求的背景、测试的重点、输出的格式，都写得很清楚。还会给AI一些示例，让它知道我们想要什么样的输出。

而且，提示词不是一成不变的。我们会根据AI的输出，不断调整和优化提示词，让它越来越好。

第五个经验是，做好数据积累。

AI测试自动化，需要大量的数据。测试用例、测试脚本、测试结果、缺陷数据，这些都是宝贵的数据。

我们把所有的测试数据，都统一管理起来。这些数据，既可以用来训练和微调模型，也可以用来做分析，不断优化测试策略。

数据积累得越多，AI的效果就越好。这是一个正向循环。

现在的效果

经过一年的努力，我们的AI测试自动化，已经取得了不错的效果。

测试用例的生成效率，提高了50%。以前写一个模块的用例，需要两天，现在AI生成加人工审核，一天就能完成。

自动化脚本的覆盖率，从30%提高到了70%。很多以前没有自动化的用例，现在都有了自动化脚本。

回归测试的时间，从三天缩短到了一天。智能回归加上全量回归，效率提高了很多。

测试人员的工作，也从重复的执行测试，变成了更有价值的测试设计和质量分析。

当然，还有很多需要改进的地方。但总体来说，AI测试自动化，确实给我们带来了价值。

给大家的建议

如果你也想做AI测试自动化，我有几个建议。

第一，不要盲目跟风。先想清楚，你的项目是不是真的需要AI测试自动化。如果项目很小，测试工作量不大，可能不需要搞这么复杂。

第二，做好预期管理。AI测试自动化，不是银弹，不能解决所有问题。它能提高效率，但也需要投入成本。不要期望太高，也不要因为遇到困难就放弃。

第三，选好切入点。从最能体现价值的地方入手，比如回归测试、用例生成等。先做出效果，再逐步扩展。

第四，重视人的作用。AI是工具，人才是核心。要有懂测试、懂AI的人，来推动这件事情。

第五，持续迭代。AI测试自动化，不是一次性的项目，而是一个持续优化的过程。要不断总结经验，不断改进。

写在最后

AI测试自动化，是一个很有前景的方向。但它不是一蹴而就的，需要踩很多坑，积累很多经验，才能慢慢看到效果。

我们团队踩过的这些坑，希望能给大家一些参考。让大家少走一些弯路，更快地落地AI测试自动化。

最后用一句话来结束这篇文章："AI不会取代测试工程师，但会用AI的测试工程师，会取代不会用AI的测试工程师。"

愿每一个测试人，都能善用AI，让自己的工作更高效，更有价值。