背景介绍
支付宝商家中心（b.alipay.com）是面向蚂蚁生态内所有商户的一站式服务平台，集产品签约、账户资金管理、营销推广、账单对账等核心功能于一体。团队负责该平台的PC端业务测试，日常工作中积累了丰富经验——今天这篇文章，将深入剖析核心思路与实践方法。
1.1 问题与挑战
挑战1：PC端业务繁多，测试链路长，且主要面向B端和小二端。
以支付宝商家中心的核心业务为例，店铺开通和商户入驻，每条都是跨系统、多步骤的长链路：
- 店铺开通：登录 → 选择类目 → 选择经营类型 → 设置结算 → 上传资质 → 勾选协议 → 提交 → 产品签约 → DB验证，一个流程跑下来，至少15步。
- 商户入驻：营业执照OCR → 经营场景 → 法人身份证 → 人脸核验 → 邮箱绑定 → 密码设置 → 签约，至少20步。
挑战2：无论是人工测试还是人工编写自动化脚本，成本都极高。
商家的业务特点是步骤多、弹窗多、上传多、异步等待多、SPA路由复杂。传统自动化编写用例，维护成本极高。React受控组件、qiankun微前端fetch隔离、弹窗内状态被上传重置——每一个都是坑。踩一个坑写一段workaround，换个业务场景又得从头开始。再加上公司内除商开部门外，其他团队对PC自动化依赖不高，导致自动化平台功能扩展缓慢（qiankun微前端、非标组件不支持）、录制调整成本高、部分功能不支持。在自动化ROI偏低的现实下，商开部门的大量外包只能花费大量时间去做前端页面点点点的验证，繁琐且人力成本极高。
挑战3：PC端线上问题风险高，前端研发人员持续缩减，风险进一步放大。
PC端是商家的主入口，近年先后出现过：组件升级导致某商家子页面不可用或提交报错等阻断性问题，前端代码冲突导致关键字段未提交至服务端，引发重大线上问题。加上前端监控覆盖率的缺失，以及前后端核对难以布防，很多前端线上问题的影响面不断扩大，最终导致客诉。
1.2 AI时代下的思考
核心思路的转变：不写测试代码，写测试知识。把踩过的坑、验证过的交互代码、有效的DOM选择器封装成“组件md”，AI执行时查阅对应组件直接复用。每一次执行，都在让组件库更完善，稳定性随知识积累递增。
核心公式：AI Agent + 组件化知识库 + 浏览器自动化 + DB验证 = 端到端AI测试
解决方案设计
关键词：稳定·通用·轻量
稳定执行不出错，一套方案通多业务，开箱即用成本低。AI替你跑浏览器、填表单、查DB、分析trace、出报告、发钉钉，验收一条龙。
2.1 方案演进：从使用平台到自建Skill
初期选用店铺业务作为试点，先后尝试了平台提供的两类AI测试能力。
- 自然语言驱动：模型对自然语言理解不稳定，导致用例编排出现偏差；执行下游存在资源瓶颈，单用例执行成功率低；前置步骤繁琐，需先配置空间测试账号、选择登录方式和执行账号。尤其是店铺场景存在账号独占性（一个账号只能开通一个店铺），审核通过后该账号即不可复用，每次执行需重新配置账号，流程格外沉重。
- 智能测试流：平台作为解决自然语言理解不稳定问题的推荐方案，但实际落地后，录制本身有成本，录制后仍需手动调整用例编排；后置执行也并不能解决业务问题。
实践过程中，平台方案在商家侧场景中暴露出明显短板：
| 痛点 | 具体问题 |
|---|---|
| 账号体系受限 | 不支持指定账号切换，审核通过分支每次必须换号，全流程用例无法自动执行 |
| 流程控制粒度不足 | 录制产出需大量手动修正；无法衔接DB验证、语雀归档等非浏览器环节，断链需人工补接 |
| 文件上传能力缺失 | 多处图片上传（营业执照、身份证、门头照）无法指定文件与校验 |
| 验证手段单一 | 无法获取接口响应和trace_id，无法从URL提取业务单号串联DB验证，页面验证仍依赖人工 |
| 扩展受平台排期约束 | qiankun fetch隔离、非标组件、CDP真实鼠标事件等均需等排期，无法自主解决 |
结论很清楚：平台方案在通用场景有一定价值，但在多步骤、强状态、深交互的业务场景中，执行稳定性、维护成本与适配性尚存差距。经过一个月持续协作，店铺场景核心能力仍在推进中，暂未跑通完整链路。为更快支撑AI测试转型，决定同步探索自建Skill方案。
2.2 Skill设计：框架选型
选型原则：能稳定执行。
Browser Agent相比Playwright的核心差异在于，它在CDP之上引入了大模型推理层，能理解自然语言意图、自主定位元素并生成操作序列，省去预编写选择器脚本。简单页面导航和基础表单，它能精准理解步骤描述、准确定位交互位置。但在商家侧的复杂组件上，通用推理难以覆盖边界情况，执行出现大量偏差：
| 问题 | 偏差 | 解法 |
|---|---|---|
| React受控组件 | input.value = 'xxx'赋值后React不感知，提交拿不到值 | 走prototype.value setter + dispatchEvent触发合成事件 |
| 图片上传 | CDP无法操作原生文件选择dialog | 绕过dialog，用DOM.setFileInputFiles直塞文件路径 |
| Cascader异步加载 | AI倾向跳级选择，面板未展开就点击 | 逐级选 + 等待500ms下级菜单渲染 |
| 异构搜索组件 | 同一“搜索”功能三种实现（ant-select / .optionItem / input+button），定位策略不统一 | DOM预扫描判断组件体系，分别走对应交互路径 |
| 上传触发重渲染 | 上传多图后 radio/cascader被清空 | 先上传、再选radio/cascader、最后填input，顺序与直觉相反 |
| SPA路由销毁拦截器 | 提交前注入的fetch拦截器被路由切换销毁，拿不到响应 | 每次submit前0.5秒内重注入，不等“之前装过就用” |
| 按钮无响应 | button.click()和dispatchEvent均不响应 | 用CDP真实鼠标事件（mouse move → down → up） |
| 页面崩溃表单丢失 | CDP session崩溃，已填表单全部丢失 | window.__formState表单快照 + 崩溃后重登恢复，上传放最后最小化崩溃暴露面 |
这些问题的共性是：同类交互的底层实现因框架、组件库、业务场景而异，我们靠组件知识逐一沉淀。每遇到一个偏差，就把正确的交互方式写入组件md的踩坑段，下次直接复用，而非重新推理。踩坑段只增不删，即使bug已修复也保留记录，避免同类问题换一种表现形式再次出现。不同业务场景持续喂入、持续校正、持续沉淀。随机出错率从首轮40%降到4轮后5%以下，靠的就是踩坑段的积累效果——它不是一次写对的，是在业务锤炼中变聪明的。
Skill架构设计
3.1 架构图
3.2 核心设计
1. 用例解析：四趟编译——把人话变成机器能跑的指令
用户写用例用自然语言，但AI不能直接拿着自然语言操作浏览器。于是设计了一个四趟编译管线，把人话逐步“翻译”成可执行内部指令——每一趟只做一件事、只承担一个职责，既保证解析精度，也让错误能被早发现、早拦截。
第1趟｜风格检测
用户可能用三种风格写用例，AI自动识别，用户无需指定格式：
- 表格风格（推荐，最易解析）：
| 序号 | 操作 | 参数 |
|---|---|---|
| 1 | 选择主营类目 | 本地生活-餐饮 |
| 2 | 填写经营类型 | 个体工商户 |
- 自然语言风格：“主营类目选本地生活-餐饮”（最常见、最灵活）
帮我执行 新增非标品牌 → 审核通过
站点：B站预发 https://b.alipay.com/page/brandManage/home
账号密码：**** / ***
数据库：数据库ARN:*****
商户载体ID(carrierId)：******
审核工具：brand-audit skill
操作步骤：
登录B站，进入品牌管理首页
点击【添加品牌】→ 跳转 /page/brandManage/home/brandReport
添加方式：选择【新增品牌】
品牌材料：选择【非标品牌】
品牌名称：输入「测试+当前时间戳」
点击「补充更多品牌信息」，品牌logo：上传reference里的图片
品牌故事：输入「这个是一个品牌故事」
品牌类目：选择 电商平台 → 工厂优选平台
门头店招：上传reference里的图片
勾选同意《支付宝品牌商服务协议》
点击【确定】→ 跳转 /page/brandManage/home/confirmResult，提示"已提交，预计1-2个工作日完成审核"
审核（brand-audit skill）：
从提交结果页获取brandId
调用 brand-audit，action=pass，eventCode=****_AUDIT
等待10s
预期结果：
提交后跳转确认页，文案含"已提交"
回到首页，已认领列表可见该品牌，状态为"审核通过"/"可使用"
DB校验：
SQL
-- 品牌主表：status=1（已通过），source=MRCH，owner_name=**测试的公司
SELECT * FROM **** WHERE brand_chs_name = '{brandName}' ORDER BY gmt_create DESC LIMIT 1;
-- 审批流水：approval_type=1，status=3（审核通过）
SELECT * FROM **** WHERE brand_id = '{brandId}' ORDER BY id DESC LIMIT 1;
- 清单风格：- [ ] 主营类目选择本地生活（Markdown）
第2趟｜元数据抽取
提取非操作步骤的结构化上下文，为执行准备“弹药”：账号密码、入口URL、DB ARN、期望断言、钉钉群号等。元数据与操作步骤分离，保证步骤序列干净，也保证执行阶段不会因为缺了密码而卡住。
第3趟｜组件匹配 + 置信度评分
这是四趟编译的核心环节——也是最容易出错的地方。把每一步操作匹配到对应的UI组件，并给出“我有多确定”的评分。
| 置信度 | 匹配条件 | 说明 |
|---|---|---|
| 95%+ | 确命中触发词 | 术语完全匹配，如“选择主营类目”→ CategorySelector |
| 80-89% | 部分命中 + 语义 | 关键词部分匹配 + 语义推理 |
| 60-69% | 纯语义推理 | 仅靠语义推断，无关键词支撑 |
| <50% | 猜测 | 几乎无依据，不建议执行 |
未匹配到的步骤标记为unmatched，同时建议可能需要新建的组件——既暴露问题，也给出建设性方向。
第4趟｜输出可执行的任务step列表
合并前三趟结果，输出AI能逐步执行的内部格式。最终产物是一个steps列表，每步绑定组件和参数。同时自动注入trace-collector作为第0步——用户不需要写“采集trace”，系统默认带上，保证可观测性。
置信度门控，可多问一句，不让AI猜错一步。置信度评分不是“参考值”，它是门控阈值，直接决定执行策略：
| 置信度区间 | 执行策略 |
|---|---|
| 90–100% | 静默执行，不打扰用户 |
| 70–89% | 展示摘要，需用户确认 |
| 50–69% | 拒绝执行，要求修正用例 |
| <50% | 提示无法解析，建议改写 |
核心思想：一条用例15步操作，第3步猜错的代价是后面12步全白跑——宁可多问一句，不让AI猜错一步。这不是保守，是工程上的止损逻辑：在不确定的环节停下来让人类拍板，比让机器蒙头冲完再发现全错，成本要低得多。
2. 组件查找优先链——平台兜底，业务按需覆盖
第3趟组件匹配时，AI不是只在一个地方找组件，而是按优先级依次查找三层目录：
| 优先级 | 目录 | 职责 | 举例 |
|---|---|---|---|
| 最高 | local-components/ | 业务方本地自定义组件，覆盖平台默认行为 | 业务觉得平台的“类目选择”组件不够用，自己写了一个 category-selector.md，加了品牌绑定逻辑 |
| 其次 | components/ | 平台级共享组件，所有业务通用 | 平台提供的标准 category-selector.md，只做了基础Cascader逐级展开 |
| 未命中 | 无匹配 | 标记unmatched，提示用户新建 | 新业务“棋盘密云”有个“私域用户筛选”操作，目前两个目录都没有对应组件 |
核心逻辑：同名组件，local-components/胜出，业务方可以局部覆盖平台行为，而不需要修改平台源码。类比CSS的层叠规则：局部样式覆盖全局样式。业务方不需要向平台提排期等排期，自己写一个.md放进local-components/就能生效。
实际使用场景：
- 覆盖：支小店的页面结构跟B站完全不同，同一个“登录”操作需要走不同的DOM路径→支小店在local-components/放自己的login.md，覆盖平台的login.md。
- 扩展：店铺开通的“结算设置”需要额外做支付宝账号校验→在local-components/写一个settle-modal.md，比平台版多一步校验。
- 新增：棋盘密云的“私域用户筛选”两个目录都没有→unmatched，提示用户新建，下次就不再unmatched了。
一句话总结：平台提供通用能力兜底，业务方按需局部定制覆盖，覆盖不了的新增。三层优先链保证了扩展性和可控性的平衡。
3. 脚本优于eval纪律
组件层（components/）写的是知识——“这个组件怎么交互、有什么坑”。但AI每次执行时如果自己拼agent-browser eval命令，拼出来的代码不稳定，容易出错。脚本层把验证过的操作固化成.sh文件。组件说“有脚本调脚本，禁手动拼eval”，确保每次走的是同一条经过实战的代码路径。
4. Phase 0→6门控
整个执行流程是7个阶段串联，但不是“无脑顺序往下跑”——每个Phase都有前置通过条件，条件不满足就卡住不推进，输出原因然后停下来。
| Phase | 干什么 | 门控条件（准入证） | 不满足会怎样 |
|---|---|---|---|
| Phase 0 | 执行环境precheck | ODC MCP连通 + yuque CLI可用 + allowlist配好 | ODC不通不执行——连数据库都查不了，跑下去验证也没意义 |
| Phase 1 | 浏览器自动化执行 | 登录成功 + 页面已到达 | 登录失败不填表——没登录进去，后面填表点按钮都是空操作 |
| Phase 2 | URL提取 & ID解析 | 从URL/拦截器拿到brandId或astoreId | 无ID不查DB——不知道查哪条记录，DB查询无从下手 |
| Phase 3 | 数据库查询 | SQL返回结果（至少1行） | SQL无结果不比对——空结果比对什么？不是“比对失败”，是“没东西可比” |
| Phase 4 | 数据比对 | 比对完成，状态明确（PASS/FAIL/WARNING） | 生成结论 |
| Phase 5 | 生成报告 | 报告含截图 + 无敏感信息 | 报告无截图不归档——没有截图的报告无法回溯验证 |
| Phase 6 | 归档到语雀 | 报告完整 + 图片已上传 | 归档成功 |
没有门控，AI一路往下跑，登录失败了还在“填表”，填完表发现页面没变，又去查DB，查到空结果还硬比，最后生成一个全是FAIL的报告归档到语雀——浪费了15分钟跑了一条从头就错的用例，浪费了token，浪费了context，产出的报告毫无价值。
- 置信度门控解决的是：AI可能在猜→不确定时停下来让人类确认。
- Phase门控解决的是：前置条件可能不成立→条件不足时停下来不白跑。
两者同源：宁可早停报告原因，不让错误往下传播放大。一条用例15步操作 + 7个Phase，如果在Phase 1就发现登录失败，后面6个Phase全免——省下来的不是时间，是整条链路的无效执行成本。一句话总结：每个Phase是一道关卡，关卡不放行，后面的路不许走。不是“跑完看结果”，是“跑前先验路”。
5. 失败自学习
用例失败→按errorCode匹配known-failures→命中则标注模式ID→未命中则自动补录新模式，只增不删。
假设场景你跑了一条用例，提交后返回错误码THIRD_SYSTEM_ERROR，用例失败了。第一次遇到这个错误
Skill去known-failures.md里搜THIRD_SYSTEM_ERROR，没找到——这是第一次遇到。
于是自动往文件里追加一条新记录：
F-017
状态: 活跃
首次发现: 2026-06-22
最近发现: 2026-06-22
出现次数: 1
errorCode: THIRD_SYSTEM_ERROR
失败特征: 提交店铺开通时下游三方系统异常
根因: 待补充
owner: 待分配
建议: 重试即可，非本系统问题
这就是“未命中则自动补录”——第一次见，记录下来。
第二次遇到同一个错误又跑了一条用例，同样的THIRD_SYSTEM_ERROR。这次去known-failures.md里搜，命中了F-017。
报告里直接写：失败模式F-017（THIRD_SYSTEM_ERROR），建议：重试即可，非本系统问题
不用再人工诊断——“命中则标注模式ID”，直接复用之前的结论。
业务实践 && 快速上手
4.1 优秀实践分享
案例1：蚂蚁答疑助手评测——4波137条用例AI自动评测，发现64个Bug
百晓蚂蚁答疑助手是AI驱动业务智答运营平台，一站式解答商家、商品、交易、营销技术和运营问题，需要验证多轮对话能力。评测方用Skill执行了4波自动化评测：
| 波次 | 用例数 | 类型 | 通过率 | 发现Bug |
|---|---|---|---|---|
| 第一波 | 15条 | 单轮问答 | 73.3% | 发现MCP工具列表泄露P0漏洞 |
| 第二波 | 35条 | 单轮问答 | 71.4% | 发现“全公司”超范围查询未拦截 |
| 第三波 | 40条 | 单轮问答 | 75.0% | 发现“导出数据”能力边界未拦截 |
| 第四波 | 47条 / 157轮 | 多轮对话 | 89.2% | 发现64个问题（3类大问题）响应慢、无响应、响应空 |
原先人工怎么测：测试同学手动在对话框一条条输入、等回复、判断结果、截图、记录。一条用例平均5分钟，多轮用例更长。4波137条，人工约需2天（含截图整理和报告写作）。
AI自动执行：Skill按用例脚本自动输入、等回复、抽取响应内容、判定OK/FAIL、截图归档。4波合计约3小时完成（含等待Agent响应时间和截图整理），节省70%人力。
发现问题：4波累计发现10类Bug：P0级2个（MCP工具列表泄露 + 接受“生成周报”超能力请求），P1级4个（导出未拦截/超范围未拦截/Agent执行报错/能力边界未拦截），P2级4个（第四波多轮评测额外发现64个问题：无响应17次、响应超慢29次、上下文丢失4次、回复为空14次）。
案例2：支付宝卡券频道-店铺开通——7条用例30分钟跑完，人工需半天-1天
店铺开通是商家侧最复杂的长链路：每条用例15步表单填写 + 文件上传，涉及账号切换（B站/P站/支小店不同账号），结算信息填写，类目资质等重要材料上传，每步需要等页面渲染、等接口返回、截图留证。
原先人工：一条用例手动操作约30分钟（含等页面渲染、填表、上传、截图），7条需要半天-1天。
Skill自动执行：7条用例在30分钟内全部跑完，提交+撤销DB双验证全过，自动截图 + 自动归档语雀 + 自动发钉钉通知。
4.2 其它业务实践案例
店铺-神券 + 支小店——最成熟的业务域，7条用例全流程冷启动验证
店铺开通是商家侧最复杂的长链路：15步表单填写 + 文件上传 + 异步等待 + SPA路由切换。Skill覆盖了B站自开通（独立门店/品牌连锁/mall店）、P站代开通（独立/品牌）、支小店（官方旗舰店/普通企业店）共7条用例，提交+撤销DB双验证全部PASS，最长一条236秒完成。
企业商户入驻——跨iframe + 人脸验证 + 邮箱验证码
商户入驻20+步，是目前人工介入最密集的用例：iframe内嵌开户验证页面（必须直接打开iframe src操作）、人脸验证扫码等待（session 5-10分钟过期需重新登录）、邮箱验证码（必须先点发送按钮再填码），Skill跑通了97+50老页面全流程。
品牌管理（B站）——12条用例全量覆盖，通过率100%
首次做全量用例覆盖而非只跑关键用例，12条从非标/标准品牌新增、审核通过/驳回、认证、认领、搜索筛选、品牌资产（门店/收款账号/小程序/会员卡/设备）到修改品牌、驳回重申请、首页冒烟，11/11 PASS。
品牌管理（P站）——跨Skill联合验证，发现前端Bug
P站与B站共用组件体系但域名和交互细节不同。Skill首次实现UI自动化 + 品牌审核skill HTTP审核的跨Skill联合验证——AI提交品牌后自动调用brand-audit skill完成审核，再回到UI验证结果。7/12 PASS，3条BLOCKED发现了P站前端Bug（品牌资产面板API绑定错误brandId）。
数商域客户管理——非标准登录体系 + 表单动态联动
数商域用非标准登录体系三段登录（输密码→选账号→点登录）。行业字段有动态联动：选“自助餐”触发额外必填字段，选“日化家清”则不会，AI需动态对比表单差异才能正确填写。品牌选择弹“已被其他客户挂载”Modal，点取消会清空品牌——必须点确定继续挂载。
跨域扩展——万知管理平台 + 订单管理页面安全越权 + 蚂蚁答疑助手
Skill的组件库不止服务商家平台侧，已被三个跨域团队复用：
- 万知管理平台：100条Monkey测试（导航/搜索/弹窗/表格），100% PASS，15分钟完成。首次适配Tailwind CSS（非Ant Design）组件体系。
- 订单管理页面安全越权校验：两个账号交叉走“有权限UI正路 + 无权限接口攻击”双路径验证，4/4 PASS。
- 蚂蚁答疑助手评测：90条三波评测，口径查询93%、数据资产查询100%，发现MCP工具泄露P0级漏洞。
4.3 组件能力全景
42个组件md + 34个脚本，分5类覆盖商家侧90%高频操作：
- 基础能力9个：登录（authsa128/pubbuservice双体系）、入口校验、Trace采集、崩溃恢复、钉钉通知、ODC precheck。
- React/Ant Design通用7个：表单填写（React setter）、Select（虚拟列表滚动）、Cascader（逐级+异步）、Modal、DatePicker、Form定位、高德地图。
- 上传/CDP 5个：fiber注入上传、多图批量上传、CDP真实鼠标事件、资质/品牌logo上传。
- 业务专属14+个：主营类目、经营类型、品牌搜索、结算弹窗、门店地址、经营/认证信息段、提交拦截、撤销审核、P站客户、商标、支小店组件组。
- 流程归档7+个：语雀报告归档、DB查询、钉钉模板、报告三段式、失败模式库、安全清单、经验沉淀。
4.4 快速上手
前置依赖
| 依赖 | 用途 |
|---|---|
| agent-browser | 浏览器自动化（CDP） |
| ODC MCP | 数据库查询验证 |
| yuque CLI | 报告归档 + 截图上传 |
| Antding.app | 钉钉消息发送 |
执行用例
① 建议先加载skill，避免模型幻觉未使用skill执行。
② 执行用例。
查看结果：
- 本地截图：~/Documents/pc-e2e-ai-result/YYYYMMDD/
- 语雀报告：自动创建并挂到指定目录节点，含截图。
- 钉钉通知：执行完成 / 失败 / 需人工介入时自动发送。