美团到店测试团队不传之秘：AI把几十个城市的POI差异一键生成差异化用例

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

不用再为每个城市手写一套脚本，我们踩了四个月的坑才跑通

大家好，我是美团到店研发平台质量保障团队的一名技术负责人，负责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，针对性生成补充用例。

六、效果数据

说几个硬数据：

最关键的变化：测试团队从“为每个城市写用例”变成了“维护城市画像模板+审核AI生成的用例” 。大家终于不用再为“成都的POI和重庆的有什么不同”这种问题头疼了。

七、给同行的一些建议

如果你也在做多城市、多租户、多配置的差异化测试，我有几点实在的建议：

1. 先做数据画像，再做用例生成

不要一上来就让AI生成用例。先让AI分析各城市的数据差异，输出“城市数据画像”——哪些字段完整、哪些字段缺失、有哪些特殊规则。画像清楚了，用例自然就有了。

2. 用“模板+变量”，不要用“全量生成”

让AI从零为每个城市生成完整用例，效率低、质量也不稳定。更好的方式是先抽象出通用模板，再让AI根据城市画像填充差异化数据。

3. 别迷信“全自动”，保留人工审核节点

AI生成的用例，一定要有人工审核环节。我们现在的流程是：AI生成→测试同学审核（30分钟）→补充调整→提交。AI负责“铺量”，人负责“把关”。

4. 历史Bug是最好的差异化信号

哪个城市历史上出过什么类型的Bug，AI应该重点关照。我们把过去两年POI相关的所有线上Bug都喂给了模型，让它在生成用例时优先覆盖“历史上出过问题的城市+场景组合” 。

最后

AI做差异化测试，本质上是把“人脑对比几十个城市的差异”这件事自动化了。

以前测试同学要翻几十个城市的配置文档、对比数据差异、手工写用例——这件事的复杂度随着城市数量指数增长，人脑根本处理不过来。

现在AI帮我们做了三件事：分析差异、归类模板、生成用例。测试同学从“执行者”变成了“审核者+策略设计者”。

美团到店覆盖的城市还在增加。如果没有这套AI方案，我们的测试团队规模可能要翻一倍才能跟上业务扩张的速度。但现在，一个人加一套AI工具，就够了。

本文系作者基于美团到店研发平台真实项目经验的总结，文中数据已做脱敏处理。欢迎同行交流讨论。

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。