L5-07：Web应用自动化测试 —— AI帮你把网站的每个角落都点一遍

🎯 学什么：不用手写测试脚本，让 AI 像真实用户一样在你的网站上进行探索测试——发现你没预料到的 bug。核心洞察：传统测试和 AI 测试不是替代关系，是互补关系。传统测试回答「我们预期的问题发生了吗？」（回归测试），AI 测试回答「我们没预料到的问题存在吗？」（探索测试）。两者的结合才是完整的测试体系。 💡 难易度：⭐⭐⭐⭐ | ⏱️ 预计时间：50 分钟

---

1. 课程概览

💡 白话小课堂：假设你开了一家餐厅，雇了一个「神秘食客」。他进来后不告诉你他要测什么，而是真的像一个普通顾客那样——翻菜单、问服务员、点菜、吃、结账、上洗手间——然后告诉你：「服务员态度很好，但菜单上的标价有 3 处跟结账小票对不上，女厕所的门锁坏了。」webapp-testing 就是这个「神秘食客」——AI 像一个真实用户那样探索你的网站，发现你没想到的问题。

来源：Anthropic 官方 Skills 仓库

---

2. AI 测试 vs 传统测试：互补而非替代

2.1 两种测试的本质差异

传统测试（单元测试 / E2E 脚本）：
  开发者写测试脚本 → 脚本执行 → 检查断言
  → 预知所有可能的交互和结果
  → 回答：「我们预期的问题发生了吗？」
  → 核心价值：回归保护——确保已修复的 bug 不再出现

AI 测试（webapp-testing / Playwright）：
  AI 观察页面 → 理解功能和意图 → 自主探索交互路径 → 报告问题
  → 不需要预定义所有场景
  → 回答：「我们没预料到的问题存在吗？」
  → 核心价值：发现盲区——探索开发者没想到的交互组合和状态

2.2 成熟的测试策略

传统测试（守住底线）：
  → 每次 CI/CD 跑固定测试套件
  → 覆盖已知的关键路径（注册/登录/支付/核心功能）
  → 每次代码合并前必须通过

AI 测试（扩展覆盖）：
  → 每次关键上线前跑一次全面探索
  → 覆盖传统测试死角（非常规交互路径 / 边界状态 / 移动端适配）
  → 发现的问题补充为新的传统测试用例

两者结合 = 完整的测试体系：
  → 传统测试保证「不后退」
  → AI 测试保证「向前看」

---

3. 三种测试模式

3.1 模式对比

模式 1：侦察模式（Reconnaissance）——零风险入门
  行为：只观察，不操作
  → 检查页面加载是否完整
  → 记录所有可交互元素（按钮/表单/链接）
  → 截取不同视口的截图
  → 检查控制台错误日志
  适合：第一次使用 / 了解未知页面的结构
  风险：零（不执行任何操作）

模式 2：定向测试（Directed Testing）
  行为：按指定路径测试
  → 你知道要测什么，告诉 AI 具体路径
  → 如：「测试优惠券 + 会员折扣叠加结算，验证最终金额正确」
  适合：验证特定功能 / 回归测试补充
  风险：低（在指定路径上操作）

模式 3：探索测试（Exploratory Testing）
  行为：自由探索所有交互组合
  → AI 自主发现页面上的所有可交互元素
  → 尝试各种操作组合（点击、输入、选择、拖拽）
  → 观察每种组合的结果
  → 报告异常行为
  适合：新功能上线前 / 你不知道哪里有坑
  风险：中（会执行写操作，建议在测试环境运行）

3.2 Recon-then-Act 原则

为什么必须先侦察再行动？

如果直接行动（不看页面就点）：
  → 可能点到错误的元素（页面还没加载完）
  → 可能使用错误的选择器（DOM 结构和预期不同）
  → 就像在陌生房间里黑暗中直接冲——99% 撞墙

正确做法：
  Step 1: 等待页面完全加载（networkidle）
  Step 2: 通过截图或 DOM 检查识别所有可交互元素
  Step 3: 确定每个元素的选择器
  Step 4: 按计划执行操作

这就像在陌生房间里先开灯看清布局再走——
AI 用 Playwright（Playwright：浏览器自动化框架）的 page.screenshot() + page.locator() 实现「开灯」。

---

4. 测试覆盖的四个维度

4.1 四维度全景

维度 1：功能覆盖（Function Coverage）
  → 每个功能都被测试过吗？
  → 注册/登录/搜索/加购/结算/支付/退款——全部覆盖
  → 常规路径 + 异常路径（如支付时余额不足）

维度 2：状态覆盖（State Coverage）⚠️ 新手最常忽略
  → 每个 UI 元素的所有状态都被测试过吗？
  → 一个按钮至少 6 种状态：
    1. 正常（default）
    2. 悬停（hover）
    3. 聚焦（focus）
    4. 点击中（active）
    5. 禁用（disabled）
    6. 加载中（loading）
  → Bug 案例：
    - 禁用按钮双击后被激活（测了 disabled 属性但没测实际行为）
    - 加载中状态下快速点击 3 次 → 提交了 3 个重复订单

维度 3：设备覆盖（Device Coverage）
  → 桌面端 / 平板 / 手机端
  → 不同浏览器（Chrome / Firefox / Safari）
  → 不同视口尺寸

维度 4：数据覆盖（Data Coverage）
  → 空数据（新用户，购物车为空）
  → 正常数据（3 件商品在购物车）
  → 边界数据（达到最大库存量/优惠券刚好满额/运费临界点）
  → 异常数据（超长姓名/特殊字符/负数金额）

4.2 状态覆盖的重点检查

状态覆盖中最容易被忽略的三类状态：

1. 加载中状态（Loading State）
   → 用户点击「提交订单」→ 按钮变为 loading → 2 秒后成功
   → 问题：如果用户在这 2 秒内又点了 3 次？
   → 测试：快速连续点击 → 检查是否产生了重复订单

2. 空状态（Empty State）
   → 新用户的购物车是空的
   → 搜索结果 0 条
   → 问题：空状态页面是否有引导？（「去逛逛」按钮）
   → 测试：清空所有数据 → 检查各个页面的空状态

3. 错误状态（Error State）
   → 网络中断时的表现
   → 表单验证失败时的错误提示
   → 问题：错误提示是否清晰？是否能指导用户下一步做什么？
   → 测试：断开网络 → 提交表单 → 检查错误提示

---

5. 结构拆解：Web 测试型 Skill 模板

---

6. 电商案例：下单全流程自动化探索测试

某淘系女装店铺（主营设计师品牌连衣裙，日均 300+ 订单）的开发团队在 618 前重构了结算页面——新增「满 3 件 8 折 + 店铺券叠加 + 跨店满减」三层优惠计算逻辑。开发自测通过后，用 webapp-testing 在测试环境做了一次全面的探索测试。

测试环境准备：

• 测试店铺（非生产环境——探索测试会执行下单操作）
• 准备 3 类测试账号：新用户（无券）、VIP 用户（有 9 折会员折扣）、大促用户（有满减券+跨店满减）

AI 探索测试发现的关键问题：

✅ 功能覆盖（12 个关键路径）：
  ├─ 选品→加购→结算→支付 → 正常
  ├─ 选品→加购→用店铺券→结算 → 正常
  ├─ 选品→加购→凑跨店满减→结算 → 正常
  └─ 选品→加购→三层优惠叠加→结算 → 发现 3 个问题 ↓

⚠️ 问题 1：三层优惠叠加时的计算顺序错误（P0）
  预期：「满 3 件 8 折」先算 → 店铺券「满 500 减 50」后算 → 跨店满减「满 300 减 40」最后算
        = (598×0.8 - 50) - 40 = 388.4
  实际：跨店满减被先算，然后打 8 折，再减店铺券
        = (598 - 40)×0.8 - 50 = 396.4
  差异：客户多付 ¥8/单，每天影响约 180 单（占日均 60%）→ 日损失 ¥1,440
  严重度：P0（涉及消费者权益——若上线后被投诉可能触发平台罚款）

⚠️ 问题 2：提交订单按钮缺少 loading 态防重复提交（P0）
  步骤：点击「提交订单」→ 支付接口响应 1.8 秒（压测期间略慢）→ 用户在 1.8 秒内又点了 2 次
  结果：支付宝预授权创建了 3 笔，其中 2 笔超时未支付 → 触发银行风控短信
  严重度：P0（引发用户恐慌+银行风控介入）

⚠️ 问题 3：iPhone SE 屏幕下优惠券选择弹窗溢出（P1）
  优惠券列表共 8 张，弹窗高度超出 iPhone SE 屏幕（568pt），底部「确认使用」按钮被遮挡
  影响：约占 6% 的移动端用户无法完成优惠券选择
  严重度：P1（影响特定设备群）

效果：

• 3 个问题在 618 大促前全部修复
• 问题 1 修复后，618 期间日均 1200 单 × 正确计价 = 避免了可能的日损失 ¥9,600
• 问题 2 修复后（添加 loading 锁 + 支付幂等校验），618 期间零重复支付客诉

🔑 启示：电商结算页不是「测通过就行」——它需要测的是「组合爆炸」：3 种优惠 × 2 种用户身份 × 3 种设备 × 加载中/超时/断网状态。传统 E2E 脚本通常只覆盖「Happy Path」，而 AI 探索测试天然擅长发现非常规交互组合中的 Bug。

---

7. 掌握检验

Q1：AI 测试和传统测试最核心的区别是什么？

• A) AI 测试更快
• B) 传统测试回答「我们预期的问题发生了吗？」，AI 测试回答「我们没预料到的问题存在吗？」
• C) AI 测试不需要写代码
• D) 传统测试只能测后端，AI 测试只能测前端

Q2：以下哪个场景最适合使用「探索测试」模式？

• A) 你明确知道注册表单的邮箱验证有问题，需要定向测试
• B) 你不知道新上线的结算页面有什么问题，想让 AI 自由探索各种交互组合
• C) 你还没开始测试，需要 AI 先生成一份测试计划
• D) 你只需要检查首页的标题是否正确

Q3：测试覆盖的四个维度中，「状态覆盖」为什么被列为「新手最常忽略的维度」？以一个普通按钮为例，列出它至少 6 种状态，并举例说明 bug 通常藏在哪些状态里。

Q4：webapp-testing 的「侦察-然后-行动」模式是什么含义？为什么必须先侦察再行动，而不是直接行动？

Q5：你的电商网站有一个「优惠券 + 会员折扣」叠加结算功能。请设计一个包含正常路径和异常路径的定向测试描述，至少覆盖 3 个不同的测试场景。

Q6：Playwright 集成在 webapp-testing 中扮演什么角色？如果你的电商网站有 Cloudflare 防护和验证码，直接用 Playwright 测试可能会遇到什么障碍？

Q7：传统测试和 AI 测试为什么是「互补关系」而非「替代关系」？一个成熟的测试体系应该如何同时使用两者？

---

8. 答案

点击查看答案

Q1：B — 传统测试基于预定义的测试用例和断言，只能发现你预期到的问题。AI 测试自主理解页面功能和意图，探索各种交互路径，能发现开发者没预料到的 bug。两者是互补关系，不是替代关系。

Q2：B — 探索测试的核心是「你不知道哪里有坑，让 AI 满地图去碰坑」。选项 A 适合定向测试，C 适合侦察模式，D 太简单不需要 AI 测试。

Q3：参考答案 — 一个按钮至少 6 种状态：正常、悬停、聚焦、点击中、禁用、加载中。Bug 案例：(1) 禁用按钮在双击后居然被激活了——大多数测试只测了 disable 属性存在，没测实际行为；(2) 加载中状态下用户快速点击 3 次导致提交了 3 个重复订单——因为没有处理 loading 状态的防重复点击。

Q4：参考答案 — AI 先通过 networkidle 等待页面完全加载，然后通过截图或 DOM 检查识别所有可交互元素及其选择器，最后才执行操作。如果直接行动，可能会点到错误的元素（因为页面还没加载完）、或者使用错误的选择器。这就像在陌生房间里先开灯看清布局再走。

Q5：参考答案 — "Test the coupon + member discount stacking system: (1) Normal path: add items total 520 yuan, apply 满500减50 coupon, member VIP 10% discount should be calculated after coupon, verify final payment = (520-50)×0.9 = 423 yuan. (2) Edge case: add items total 480 yuan (below 500 threshold), verify coupon cannot be applied. (3) Error path: apply coupon first, then change shipping address to a remote area, verify coupon remains valid."

Q6：参考答案 — Playwright 提供真实浏览器环境，支持网络拦截、Cookie 管理、截图录制、移动设备模拟。它是 webapp-testing 的底层执行引擎。如果网站有 Cloudflare 防护或验证码，Playwright 可能被检测为机器人而被拦截——因为 Cloudflare 的 JS 挑战和 CAPTCHA 需要「人类行为特征」，Playwright 模拟的浏览器行为可能触发反爬机制。

Q7：参考答案 — 传统测试保证「已知的正确」（回归测试），AI 测试发现「未知的错误」（探索测试）。成熟体系：传统测试守住底线（每次 CI/CD 跑固定测试套件），AI 测试在每次关键上线前做一次全面的探索测试，发现传统测试覆盖不到的死角。两者结合 = 完整的测试体系。

（5/7 通过）

---

9. 延伸阅读

• [[L5-06-Web构件生成|上一课：Web组件构建器]] —— 测试的对象是 Artifact
• [[L5-08-MCP工具构建器|下一课：MCP工具构建器]] —— 给自己的 AI 助手装上更多超能力