|
上个财年，我们团队从0到1建设了一款AI测试平台。 面向API性能领域，我们利用AI自动生成压测用例，实现了API压测工作流，包括前置资源准备、压测执行与性能报告输出、以及压测资源清理的自动化，极大提升了API压测的效率。 平台架构 如图所示，平台包含压测用例生成、压测脚本生成、压测脚本执行、性能报告生成4个模块。 1）压测用例生成：基于压测API及API文档自动构造提示词(prompts)，然后基于prompts调用LLM推理服务，生成用例上下文(context)，最后利用context渲染预定义的API压测用例模板，生成YAML格式的API压测用例。人工可确认和校准用例正确性。 2）压测脚本生成：将YAML格式的压测用例转换成可执行的Jmeter压测脚本。 3）压测脚本执行：基于K8S自动创建Jmeter POD集群，将压测脚本分发到POD集群，并发起弹性分布式压测。 4）性能报告生成：收集Jmeter压测结果，输出包含API吞吐量、时延、错误率的性能报告。人工可分析性能报告和压测日志，识别性能问题。 用例生成 我们对API压测工作流进行了抽象与建模，定义了一套通用的API压测用例模板如下： 模板由5个区块组成：全局变量、压力模型、前置操作、压测步骤和后置操作。对于任意待压测API，实例化该模板所需要的信息就是用例上下文。这是与待压测API相关的个性化信息，由大模型从API定义文档中推理而得。举个栗子：压测某异步创建类API(CreateXXX)，我们需要轮询对应的查询API(ReadXXX)，查询已创建的资源状态(XXX.status)，并计算状态到达成功态(Init-> rocessing->Success)的时间，作为异步API的实际性能。 推理“状态”和“成功态”的具体取值，所需的提示词如下： 三点思考 1）AI让测试平台更简单 经常有人抱怨研发不做测试，但是如果有一个简单易用的测试工具，谁不愿意做测试呢？ 过往的API压测平台存在两大问题：1）压测脚本需要人工编写，上手门槛高 2）压测工具只负责压测步骤的自动化执行，压测资源准备与释放工作仍需人工。 我们的AI压测平台上线后，研发同学在短时间内完成了数百个API的性能压测，发现了数十个性能风险问题，不乏隐藏多年的严重并发BUG(线上一旦触发就是灾难)。
一个简单易用的测试平台，帮助和促进研发做更多的测试工作，提升产品质量。AI的出现，无疑给了我们巨大机会把测试平台做简单。 2）建模让测试平台更简单 测试平台的初心是让测试更简单，但是这些年我们见过太多把测试平台越做越复杂的事情，以至于有人疾呼要去平台化。 设计一个简单的测试平台，AI只是辅助，从根本上说需要抽象能力，这背后是对具体测试业务本质的洞察。 以AI压测平台来说，我们通过对API压测工作流进行建模，抽象出通用的API压测用例模板。即使没有AI辅助，研发依靠这个模板编写压测用例，也是显著的提效。
3）用好AI：think big，start small AI很强大，但我们并不试图让AI解决API压测领域的所有问题，也不试图让AI生成API压测用例的全部内容。 相反，我们只是利用大模型强大的文档理解推理能力，生成一些实例化压测用例模板所需要的关键信息。 本质上，我们只是用AI解决一个又一个具体的、确定性高的小问题，然后整合结果形成解决方案。 这样做的直接好处是提升AI生成的准确率。整体看，我们生成的用例准确率达到80%以上，远高于AI代码生成(例如Github Copilot、通义灵码)的采纳率20-30%。 间接好处是建立大家对AI的信心：在AI落地时，先立足于让AI在局部产生实实在在的价值，然后再扩大AI应用范围，徐徐图之。 | 
