AI 协助接口自动化从生成到维护
今天这篇分享比前几篇稍微干一点,讲一下接口自动化测试的事情。
不少方案都会让 Agent 去执行接口、调用数据库、分析日志,甚至实时决定下一步操作,这件事情在接口自动化上没有那么重要,接口自动化,特别是用来门禁的用例,更需要稳定执行。接口自动化最大的价值,是确定性:同一份代码,在任何时间、任何环境执行,结果应该一致;失败时能够复现,成功时能够追溯。
今天这篇分享比前几篇稍微干一点,讲一下接口自动化测试的事情。
不少方案都会让 Agent 去执行接口、调用数据库、分析日志,甚至实时决定下一步操作,这件事情在接口自动化上没有那么重要,接口自动化,特别是用来门禁的用例,更需要稳定执行。接口自动化最大的价值,是确定性:同一份代码,在任何时间、任何环境执行,结果应该一致;失败时能够复现,成功时能够追溯。
最近参加了一场 AI 黑客马拉松。
看了很多团队的作品,给我带来了一种思维方式的变化。
我发现,很多技术人,做应用时都带有明显的开发者思维。
看到一个 AI 产品,脑子里第一反应总是:
我把 AI 接入了企业微信工作流,让它帮我处理一些日常的轻度工作,整体感受还不错。记录一下接入过程中的几个关键决策和一些细节。不是什么高深的东西,只是分享一下我的实践。
在微服务越来越普遍的今天,接口测试面临一个很现实的问题:
测试环境难搭、依赖服务太多、Mock 成本越来越高。
一个简单的接口调用,背后可能依赖数据库、Redis、消息队列以及多个下游服务。为了编写自动化测试,我们往往需要花费大量时间构造 Mock 数据,维护测试环境。
今年,各公司纷纷将重心放在 AI 上。随着半年的“热火朝天”,AI 领域也开始出现了名词膨胀的现象,仿佛流畅说出各种高大上的概念,就代表对 AI 有了深入理解,以便升职加薪,或是吸引流量、贩卖焦虑。
Shopify 最近更新了一篇文章,讲了他们如何使用 MySQL 替换 Redis 实现库存预留(Inventory Reservation)。我进行了一番阅读,并结合自己的实验做了一些分析。