不用再为每个城市手写一套脚本我们踩了四个月的坑才跑通大家好我是美团到店研发平台质量保障团队的一名技术负责人负责POI兴趣点业务方向的质量保障工作。今天聊聊我们团队去年做的一个项目——用AI自动生成覆盖几十个城市POI差异的测试用例。先上结果系统上线后POI相关测试用例的编写效率提升了8倍覆盖城市从原来的5个核心城市扩展到了68个线上POI相关的数据不一致问题下降了67%。不是标题党。下面我把这个方案的完整思路和踩过的坑都说一遍。一、POI测试为什么这么难先解释一下什么叫POI。在美团到店业务里POI就是每一个具体的“店”——一家餐厅、一个景点、一家酒店、一个美容院。美团到店业务覆盖几百个城市每个城市有成千上万个POI。POI测试的核心难点就三个字差异化。同样一个“搜索餐厅”的功能北京的POI有“必吃榜”标签上海的POI有“黑珍珠”标签三四线城市的POI可能什么标签都没有不同城市的POI信息字段完整度不一样不同城市的排序规则不一样不同城市的展示样式不一样以前我们的做法是每个城市手工写一套测试用例。北京测“必吃榜”标签展示、测排序规则上海测“黑珍珠”标签展示、测不同的排序规则成都又是一个版本广州又是一个版本测试用例数量随着城市数量线性增长。50个城市就有50套用例每套还不太一样。维护成本高到离谱——POI字段一改50套用例全部要改。更坑的是我们永远不知道哪个城市的POI数据有“特殊的坑”。北京的POI字段完整不代表乌鲁木齐的也完整。某个城市的POI照片字段可能是空的另一个城市的营业时间格式不一样——这些差异在测试阶段很难全部覆盖。人工枚举永远有遗漏。二、转折点让AI“理解”城市差异去年Q3我们开始探索用AI来解决这个问题。核心思路很朴素让AI学习不同城市POI的数据分布和业务规则然后自动为每个城市生成适配的测试用例。具体来说我们做了三件事。第一件事把POI数据“喂”给AI我们从数据仓库里抽取了68个城市、超过100万条POI数据样本脱敏后包括POI的基础字段名称、地址、电话、坐标POI的业务字段标签、评分、价格、营业时间POI的展示字段图片、视频、描述每个城市特有的业务规则配置然后让大模型对这些数据做自动分析输出每个城市的“POI数据画像”这个城市的POI字段完整度是多少哪些字段经常为空这个城市特有的标签体系是什么排序规则和别的城市有什么不同这一步的目的是让AI理解“城市A和城市B到底差在哪里”而不是让测试同学自己去翻几十个城市的配置文档。第二件事建立“城市差异化模板库”AI分析完所有城市的数据后我们让它做了一件事——把城市归类。不是按地理区域分而是按POI数据特征分类型一一线城市POI字段完整、标签丰富、有特色榜单、评价体系完善类型二省会城市POI字段基本完整、部分标签缺失、榜单覆盖不全类型三三四线城市POI字段不完整、标签稀疏、评价数据少类型四特殊城市有特殊业务规则比如旅游城市的景点POI有特殊字段同一类型的城市测试用例可以复用同一套模板只需要替换具体的城市名和数据即可。这一步做完68个城市的测试用例从“68套”变成了“4套模板参数化配置”——工作量直接降了一个数量级。第三件事AI自动生成差异化用例有了模板和城市画像最后一步就是让AI自动生成每个城市的测试用例。我们设计了一套“模板变量”的生成策略模板层定义测试场景的通用逻辑比如“搜索餐厅→验证搜索结果展示”变量层根据城市画像自动填充差异化数据比如“北京的搜索词用‘烤鸭’成都用‘火锅’”规则层根据城市特有的业务规则自动调整断言逻辑比如“北京验证‘必吃榜’标签其他城市验证‘热门’标签”这套机制的核心是测试同学只需要维护4套模板AI负责生成68个城市的差异化用例。三、真实案例AI是怎么发现“青岛的坑”的说一个真实案例。去年Q4我们的POI详情页做了一次改版新增了“周边推荐”模块——根据当前POI的位置推荐附近的其他店铺。测试同学按常规流程测了北京、上海、广州三个城市全部通过准备上线。但AI在自动生成其他城市的测试用例时发现了一个问题。AI在分析青岛的POI数据时发现青岛的很多POI尤其是沿海景点的餐厅经纬度坐标精度不够——坐标点落在了海面上而不是在陆地上。这个数据问题一直存在但从来没有影响过功能——因为以前的POI详情页不需要“周边推荐”。新功能上线后坐标不准的POI会推荐出“海上的店铺”。AI在生成青岛的测试用例时自动补充了一条用例“验证坐标落在非陆地位置的POI周边推荐是否展示为空或合理降级。”测试同学照着这条用例一跑果然复现了——那个POI的周边推荐里出现了几个“海上的餐厅”。如果这条用例是人工写的大概率会被遗漏——因为测试同学不会专门去查“青岛的POI坐标有没有问题”。但AI在分析城市数据画像时自动发现了这个异常模式并生成了对应的测试用例。这就是AI做差异化测试的核心价值——它能看到人看不到的数据模式。四、技术架构我们是怎么搭的整个系统分成四层第一层数据采集层从数据仓库抽取各城市POI样本数据从配置中心拉取各城市的业务规则配置从历史测试用例库提取已有用例模板第二层AI分析层大模型分析各城市POI数据分布生成“城市数据画像”自动识别数据异常模式字段缺失、格式不一致、坐标异常等对城市进行聚类分组建立“差异化模板库”第三层用例生成层基于模板城市画像自动生成差异化测试用例支持自然语言用例和自动化脚本两种输出格式生成后自动提交到测试管理平台第四层执行验证层集成美团到店自研的AUITestAgent实现自然语言用例的自动化执行AUITestAgent通过多模态模型识别UI元素自动完成交互和校验执行结果自动回传失败用例自动标记AUITestAgent是我们和复旦大学周扬帆教授团队联合开发的智能化终端测试工具。它的核心特点是交互与检查解耦的双流结构——先把测试需求分解成交互指令和校验指令再分别执行。这就意味着AI生成的差异化用例不需要人工转成脚本直接以自然语言形式交给AUITestAgent就能跑。五、踩过的坑说三个最痛的坑一AI“学会”了错误的数据模式初期我们直接把各城市的POI数据喂给AI让它“自己分析”。结果AI学到的不仅是“正常的数据分布”还有“历史数据里的脏数据模式”。举个例子某个城市的历史POI数据里有大量“营业时间为空”的记录——不是业务规则如此是历史数据迁移时的遗留问题。AI分析后认为“这个城市的营业时间就是经常为空”于是在生成测试用例时把“营业时间为空”当成了正常情况没有生成异常测试用例。解法在数据喂给AI之前先做一轮数据质量清洗——把已知的数据问题标注出来告诉AI“这些是脏数据不是业务规则”。同时用人工标注的高质量数据集做Few-shot示例教会AI“什么才是正常的数据模式”。坑二城市分类太粗丢了细节第一版我们把城市分成了4类但很快发现问题——同一类型的城市细节差异依然很大。同样是“三四线城市”有的城市有“本地特色榜单”有的城市完全没有榜单功能。用同一套模板生成用例要么漏测要么生成无效用例。解法从“硬分类”改成“软标签”体系。每个城市不是属于“某一类”而是有一组标签——has_rank_list: true、has_review_system: true、data_completeness: high。AI根据标签组合动态生成用例而不是套用固定模板。坑三生成的用例“太像了”缺少真正的差异化这是最隐蔽的问题。AI生成的用例表面上看每个城市都不同——城市名不同、搜索词不同、断言数据不同。但测试逻辑完全一样——“搜索→验证结果展示”。真正的差异化测试应该是根据每个城市的业务特点测试不同的东西北京测“必吃榜”的展示和排序成都测“火锅”标签的筛选准确性三亚测“景点POI”的特殊字段AI如果只做“参数替换”那和脚本参数化没什么区别。解法在Prompt里明确要求AI“为每个城市生成至少一条该城市特有的测试场景”并给出Few-shot示例。同时让AI在生成用例前先检索该城市历史上出过什么类型的Bug针对性生成补充用例。六、效果数据说几个硬数据指标优化前优化后覆盖城市数5个68个用例编写时间3人天/版本0.5人天/版本POI相关线上问题基线↓67%用例模板数50套独立用例4套模板AI生成AI发现的数据异常模式-累计47个最关键的变化测试团队从“为每个城市写用例”变成了“维护城市画像模板审核AI生成的用例”。大家终于不用再为“成都的POI和重庆的有什么不同”这种问题头疼了。七、给同行的一些建议如果你也在做多城市、多租户、多配置的差异化测试我有几点实在的建议1. 先做数据画像再做用例生成不要一上来就让AI生成用例。先让AI分析各城市的数据差异输出“城市数据画像”——哪些字段完整、哪些字段缺失、有哪些特殊规则。画像清楚了用例自然就有了。2. 用“模板变量”不要用“全量生成”让AI从零为每个城市生成完整用例效率低、质量也不稳定。更好的方式是先抽象出通用模板再让AI根据城市画像填充差异化数据。3. 别迷信“全自动”保留人工审核节点AI生成的用例一定要有人工审核环节。我们现在的流程是AI生成→测试同学审核30分钟→补充调整→提交。AI负责“铺量”人负责“把关”。4. 历史Bug是最好的差异化信号哪个城市历史上出过什么类型的BugAI应该重点关照。我们把过去两年POI相关的所有线上Bug都喂给了模型让它在生成用例时优先覆盖“历史上出过问题的城市场景组合”。最后AI做差异化测试本质上是把“人脑对比几十个城市的差异”这件事自动化了。以前测试同学要翻几十个城市的配置文档、对比数据差异、手工写用例——这件事的复杂度随着城市数量指数增长人脑根本处理不过来。现在AI帮我们做了三件事分析差异、归类模板、生成用例。测试同学从“执行者”变成了“审核者策略设计者”。美团到店覆盖的城市还在增加。如果没有这套AI方案我们的测试团队规模可能要翻一倍才能跟上业务扩张的速度。但现在一个人加一套AI工具就够了。