不用再为每个城市手写一套脚本，我们踩了四个月的坑才跑通
大家好，我是美团到店研发平台质量保障团队的一名技术负责人，负责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是最好的差异化信号
哪个城市历史上出过什么类型的Bug，AI应该重点关照。我们把过去两年POI相关的所有线上Bug都喂给了模型，让它在生成用例时优先覆盖“历史上出过问题的城市+场景组合”。
最后
AI做差异化测试，本质上是把“人脑对比几十个城市的差异”这件事自动化了。
以前测试同学要翻几十个城市的配置文档、对比数据差异、手工写用例——这件事的复杂度随着城市数量指数增长，人脑根本处理不过来。
现在AI帮我们做了三件事：分析差异、归类模板、生成用例。测试同学从“执行者”变成了“审核者+策略设计者”。
美团到店覆盖的城市还在增加。如果没有这套AI方案，我们的测试团队规模可能要翻一倍才能跟上业务扩张的速度。但现在，一个人加一套AI工具，就够了。
