建议从业务出发做对的事，不要内耗。趋势上来讲，测试和开发的界限会越来越弱化，最终能服务好客户、做好业务的人才是鄙视链顶端的人。

300 年前的铁路工人、汽车工人那也是一等一的高大上，甚至就在 30 年前，上海的出租车司机那也是一等一的高大上。

10 年前我刚入行的时候我老板问了我一个问题：怎么看待测试今后的发展。
我当时回答，铁路刚刚兴起时，铁路工人最开始是通过人工架设铁路线，随着时间的推移，各种机械化设备的出现，他们有更高的效率和质量，与此同时对铁路工人的要求也在发生变化，操作机械设备成为了新的高级工种，维护与检测也变得愈发重要。
我回答的时候心里对后面的发展没有任何实际概念，只是遵循技术发展的客观规律，做出的浅薄判断。我更判断不到这一天会这么快的到来。
于测试来说，以前我总希望我能自己去写单元测试用例，又或者我可以根据开发的代码结构和逻辑去编写业务用例，这些都不太现实，而 AI 的出现，让这些以前的幻想都已经变成了现实。
还有什么好说呢！积极拥抱 AI，积极拥抱业务。
至于技术，你可以说他变得廉价了，也可以说只是打破了技术人心底的滤镜罢了。

从我毕业第一年开始，我就始终在思考一个问题：为什么我值这些钱？
希望你也思考一下。

AI 写用例这一套目前有很大的问题：

1. 上下文理解问题。单纯一篇 PRD，一些内部共识的信息很大概率会在脑子里自动补全而不体现在文档中，这部分不告诉 AI 就会生成的很差，轻则用例缺漏，重者驴唇不对马嘴。尝试过接入历史需求、历史用例和历史缺陷，但是又碰到信息过时、场景描述上的省略等等问题，花了很多时间去学习 RAG 相关的知识，然后又花了很多时间去优化，最终效果都很差，反而小伙伴怨声载道。从最开始的积极配合到疑虑重重再到最后消极怠工。
2. 二次评审问题。既然 AI 一次性生成的效果总是难以做到非常好，那我们后面暂行了一个评审 AI 用例的流程。现在事后看来，效果也很差。阅读 AI 写的用例，总会有一种坐副驾驶位上的昏睡感，会导致自己看 AI 生成的用例时难以投入，一些细节错误没发现、该增加的用例没评审到等等问题。甚至本来还算顺畅的用例评审都遭到了各个开发的投诉，说的结结巴巴，甚至要临时调整，完全没有评审自己写的用例时流畅。
3. 维护问题。这个问题我们没有实际经历过，但是在做的时候就有预想。每个迭代都会产生新的历史需求、历史用例、历史缺陷，而这三者的处理逻辑各不相同，尝试过完全让 GPT3.5 去按照预设逻辑处理，但是效果并不好，完全能用的数据只有 30% 左右（可能还高估了），剩下的都要人工处理，即便是人工处理也不能完全保证可用性。而用 GPT4 处理，效果会好很多，但是成本也没办法承受。

上面这些问题，或许交由更专业、更专心的团队去处理，还有机会处理好，但是内中的细节问题、效果问题上应该还会有一大堆又一大堆要进行处理。
在做之前，我其实也已经跟领导说过这些问题了，但是一句试一试吧，让我没办法反驳。只能当做一次技术上的实践去做了。

小米的同学都喜欢说话直截了当，不喜欢去绕弯子，讨厌卖关子吗？

直接生成用例效果会不好，但是帮你检查用例效果可以很好

不懂代码的这批人，日子已经很难过了，他们中的绝大部分也不在这个社区里，还要被人这样嘲讽。
发这个帖子有什么现实意义呢？

不确定我们做的算不算。
目前有一套检测增量代码系统，可以检测到两个 commit 之间的差值，进而找到对应影响的接口。
拿到这批接口后，我们会重跑 jvm-sandbox-repeater 录制到的接口请求。
目前这套已经接到持续集成中了，每次开发部署代码之后都会和线上版本进行对比，跑一遍涉及到的旧接口。
但是局限性还是比较大，只能说有点帮助，但是不多。