AI 辅助调试与测试：没有 QA 的日子

AI 学习系列第四篇 · 进阶教程 前置阅读：如何学习 AI 基础 → Vibe Coding 实战教程 → MCP 与 Skills 指南 → 本篇

---

写在前面

小公司前端的日常是这样的：

你写完一个页面 → 自己用 Chrome 点一遍 → 觉得差不多了 → 上线 → 然后老板在微信群里发了一张手机截图："这个页面怎么错位了？"

没有 QA 团队，没有测试流程，没有自动化。你就是开发 + 测试 + 运维的三合一。

好消息是，AI + Playwright MCP 可以当你的免费测试员。它能真正"打开"你的网页、"看到"页面效果、"操作"按钮和表单、"发现"控制台报错。不需要你写复杂的测试框架，最简单的情况下，一句话就够了。

前置准备：你需要在 Trae 或 Claude Code 中配置好 Playwright MCP Server。如果还没配，参考上一篇 MCP 与 Skills 指南 第四章。

---

第一章 · 最快上手：让 AI "看一眼" 你的页面

1.1 这是门槛最低的测试方式

不需要写测试代码，不需要学测试框架，你只需要：

1. 启动你的开发服务器（npm run dev）
2. 告诉 AI 一个网址
3. 让它去看

帮我打开 http://localhost:5173，截图看看首页效果，
顺便检查一下控制台有没有报错。

AI 会通过 Playwright MCP 做这些事：

• 打开一个真实的浏览器窗口
• 导航到你指定的 URL
• 对页面进行截图，展示给你看
• 读取浏览器控制台的日志和错误
• 告诉你它发现了什么问题

这就像你请了一个人帮你"看一眼"，但这个人不会漏看控制台里那个红色的 TypeError。

1.2 它能发现什么？

就这一步简单操作，AI 通常能发现：

• 控制台错误：未捕获的异常、404 资源加载失败、CORS 跨域错误
• 明显的视觉问题：空白页面、布局塌陷、图片无法加载
• 加载问题：页面打不开、无限 loading、白屏

它发现不了什么？

• 逻辑上的细微 bug（比如价格算错了 0.01 元）
• 偶发性问题（刷新 10 次才出现一次的 bug）
• 性能问题（"能打开"和"打开得快"是两码事）

实用原则：不要指望 AI 测试替代所有人工测试。把它当作"第一道过滤网"——先让 AI 扫一遍，过滤掉 80% 的低级错误，剩下 20% 的深层问题再自己看。

1.3 升级版：带着问题去看

如果你知道哪里可能有问题，可以让 AI 针对性检查：

我刚改了首页的 Header 组件，帮我检查一下：
1. 打开 http://localhost:5173
2. 看看 Header 的导航链接是否都能正常显示
3. 点击每个导航链接，确认没有跳到 404 页面
4. 截图给我看看效果

越具体，AI 检查得越有效。

---

第二章 · 响应式测试：一句话测所有设备

2.1 小公司最常漏测的就是移动端

你在 1920px 的显示器上开发，一切看起来很完美。但你的用户 70% 用手机访问。然后你就在微信群里收到了那张经典的错位截图。

以前你要手动调 Chrome DevTools 的设备模拟，一个一个分辨率切。现在：

帮我在三个视口下分别截图 http://localhost:5173 的首页：
1. 手机（375×812，iPhone SE 尺寸）
2. 平板（768×1024，iPad 尺寸）
3. 桌面（1440×900）

对比一下有没有布局问题。

AI 会自动调整浏览器窗口大小，分别截图，然后告诉你它观察到的问题。

2.2 常见的响应式问题

AI 通常能帮你发现这些：

问题	表现	常见原因
水平溢出	手机上出现横向滚动条	固定宽度元素没有做 max-width
文字截断	标题显示成 "超长标题文字超长标..."	没处理 text-overflow
按钮太小	手机上点不到	触摸目标小于 44×44px
导航消失	移动端找不到菜单	没做汉堡菜单响应式
图片变形	图片被拉伸或压扁	没设置 object-fit
间距异常	内容挤在一起或留白太多	padding/margin 用了固定 px

2.3 进阶：关键页面全部过一遍

如果你有多个重要页面，可以让 AI 批量检查：

我的应用有这几个关键页面，帮我在 375px 手机视口下全部截图检查：
- http://localhost:5173/          （首页）
- http://localhost:5173/login      （登录页）
- http://localhost:5173/dashboard  （仪表盘）
- http://localhost:5173/settings   （设置页）

重点关注：
- 有没有水平溢出
- 表单在手机上能不能正常操作
- 文字是否可读（字号不低于 14px）

上线前花 2 分钟让 AI 跑一遍，能帮你避免 80% 的"老板发截图"事件。

---

第三章 · 功能测试：让 AI 模拟用户操作

3.1 不只是"看"，还能"用"

Playwright MCP 不仅能截图，还能操作页面——点击按钮、填写表单、选择下拉菜单、键盘输入。这意味着 AI 可以像一个真实用户一样"使用"你的应用。

3.2 表单测试

表单是前端 bug 最密集的地方。让 AI 帮你测：

帮我测试 http://localhost:5173/register 的注册表单：

1. 正常流程测试：
   - 填入 用户名：testuser，邮箱：test@example.com，密码：Test123456
   - 点击注册按钮
   - 看看是否跳转到成功页面

2. 异常情况测试：
   - 什么都不填，直接点注册 → 应该显示必填提示
   - 填一个格式错误的邮箱（比如 "abc"）→ 应该显示格式错误
   - 密码太短（比如 "123"）→ 应该提示密码强度不够

每步都截图记录。

AI 会逐步执行这些操作，截图记录每一步的结果，然后告诉你哪些符合预期，哪些不符合。

3.3 导航和路由测试

单页应用（SPA）的路由问题很常见：

帮我测试导航是否正常：
1. 打开首页
2. 点击导航栏的"关于"链接
3. 确认 URL 变成了 /about，内容也变了（不是首页内容）
4. 点击浏览器后退按钮
5. 确认回到了首页
6. 直接在地址栏输入 http://localhost:5173/about 回车
7. 确认页面能正常加载（不是 404）

第 6-7 步很重要——这是测试直接访问路由是否有效，
SPA 如果没配好服务器，直接访问子路由会 404。

经验之谈：第 6-7 步测试的"直接访问子路由"问题，是 SPA 部署时最经典的坑。开发环境没问题，一上线就 404。让 AI 帮你养成测这一步的习惯。

3.4 登录流程测试

登录是用户的第一个操作，出了问题就是灾难：

测试登录流程：
1. 打开 /login 页面
2. 输入正确的账号密码，点登录
3. 确认跳转到 /dashboard
4. 刷新页面，确认登录状态还在（没被踢出）
5. 点击退出登录，确认回到 /login
6. 直接访问 /dashboard，确认被重定向到 /login（未登录不能进）

3.5 测试的颗粒度：什么值得测？

小公司不需要测试一切。以下是优先级指南：

优先级	测什么	为什么
必须测	登录/注册、支付、核心业务流程	出 bug 直接影响收入
应该测	表单提交、路由导航、权限控制	常见用户操作，bug 暴露率高
可以不测	纯展示页面、关于我们、帮助文档	坏了不影响核心功能
别浪费时间	动画效果、hover 交互	不是关键路径

---

第四章 · 让 AI 帮你生成测试代码

4.1 从手动到自动

前三章的方式是"每次让 AI 手动跑一遍"。但如果你有些测试需要反复跑（比如每次上线前），让 AI 生成测试代码更划算。

根据我们刚才测试注册表单的流程，
帮我生成一个 Playwright 测试文件 tests/register.spec.ts，
包含正常注册和异常输入两组测试用例。
用 TypeScript，用 @playwright/test 的 expect 断言。

AI 会生成类似这样的代码：

import { test, expect } from '@playwright/test';

test.describe('注册页面', () => {
  test('正常注册流程', async ({ page }) => {
    await page.goto('http://localhost:5173/register');
    await page.fill('[name="username"]', 'testuser');
    await page.fill('[name="email"]', 'test@example.com');
    await page.fill('[name="password"]', 'Test123456');
    await page.click('button[type="submit"]');
    await expect(page).toHaveURL('/success');
  });

  test('空表单提交应显示验证错误', async ({ page }) => {
    await page.goto('http://localhost:5173/register');
    await page.click('button[type="submit"]');
    await expect(page.locator('.error-message')).toBeVisible();
  });
});

4.2 审查 AI 生成的测试代码

AI 生成的测试代码不能直接信任，需要检查这几点：

• 选择器准不准？——AI 可能猜错了你的 DOM 结构。[name="username"] 可能在你的代码里是 [data-testid="username-input"]
• 断言合理吗？——"跳转到 /success" 是你的真实行为吗？还是显示一个弹窗？
• 测试数据有冲突吗？——每次跑都用 testuser 注册，第二次跑可能会报"用户已存在"
• 等待策略对吗？——有些操作需要等网络请求返回，AI 可能没加 waitForResponse

原则：AI 生成的测试代码是"初稿"，你需要跑一遍、看看哪里报错、然后调整。但它帮你省掉了"从零写"的 80% 工作量。

4.3 集成到开发流程

生成的测试可以很简单地融入你的工作流：

# 安装 Playwright（如果还没装）
npm init playwright@latest

# 跑测试
npx playwright test

# 看测试报告
npx playwright show-report

在 package.json 里加一条：

{
  "scripts": {
    "test": "playwright test",
    "test:ui": "playwright test --ui"
  }
}

以后每次上线前，跑一遍 npm test 就行。

4.4 什么时候该写测试代码？

场景	建议
一次性活动页面	不写测试，AI "看一眼"就够
核心业务流程（登录、支付）	必须写，每次改动都跑
被反复报 bug 的功能	写一个测试锁住正确行为
重构时	重构前先生成测试，确保重构不破坏功能

小公司的测试策略：不追求覆盖率，只保护关键路径。 5 个测试保护 5 个核心功能，比 50 个测试覆盖所有角落更实际。

---

第五章 · 调试：AI 帮你定位 Bug

5.1 场景一：页面白屏

这可能是前端最恐怖的 bug——页面一片空白，不知道哪里炸了。

打开 http://localhost:5173/dashboard，页面白屏了。
帮我：
1. 检查控制台有没有报错
2. 检查网络请求有没有失败的
3. 截图看看页面实际状态
4. 根据错误信息分析可能的原因

AI 会像一个有经验的开发者一样排查：

• 读控制台错误：Uncaught TypeError: Cannot read property 'map' of undefined
• 分析原因："看起来是在渲染列表时，数据还没加载就尝试 .map()，需要加空值判断"
• 给出修复建议

5.2 场景二：样式错乱

手机上某个页面的布局错乱了，但你在电脑上看是正常的。

用 375px 视口打开 http://localhost:5173/product，
我收到用户反馈说这个页面在手机上布局错位了。
帮我：
1. 截图看看当前状态
2. 检查是否有元素溢出视口
3. 看看 CSS 有没有什么明显问题

AI 截图后会告诉你："在 375px 下，.product-grid 的三列布局没有变成单列，导致内容被压缩到看不清。建议在移动端用 grid-template-columns: 1fr。"

5.3 场景三：接口报错

前后端联调是小公司的日常痛苦——后端说"我这边没问题"，前端说"我请求了但没数据"。

打开 http://localhost:5173/dashboard，
这个页面应该显示数据列表，但现在是空的。
帮我：
1. 检查页面发出了哪些网络请求
2. 看看请求状态码和响应内容
3. 如果有错误，分析是前端的问题还是后端的问题

AI 能帮你捕获网络请求，看到：

• 请求了 GET /api/tasks，返回 401 Unauthorized
• 原因：请求头里没带 Authorization token
• 结论：前端的问题——登录后没把 token 存下来或发请求时没带上

这比你自己打开 DevTools → Network → 找请求 → 看 Headers 快得多，而且 AI 会帮你分析原因而不是只展示原始数据。

5.4 场景四：功能逻辑 Bug

用户反馈"购物车加了商品但数量显示不对"：

帮我测试购物车功能：
1. 打开 http://localhost:5173/products
2. 点击第一个商品的"加入购物车"按钮
3. 再点一次同一个按钮
4. 查看右上角购物车图标的数字是否显示 2
5. 打开购物车页面，确认商品数量是 2

如果数字不对，截图记录每一步的状态。

AI 操作完后发现："点了两次'加入购物车'，购物车显示 1 而不是 2。看起来是每次点击都重置了数量，而不是累加。"

5.5 调试的思维模式

用 AI 调试时，记住这个流程：

报告现象 → AI 收集证据 → AI 分析原因 → 你确认 → 修复

不要直接问"帮我修这个 bug"，而是先让 AI 帮你定位问题。定位清楚了，修复往往只需要改几行代码。

---

第六章 · 可视化回归测试：改完代码没改坏

6.1 什么是回归测试

你改了一个组件的样式，结果另一个用到这个组件的页面布局崩了。这就是"回归"——修了一个地方，坏了另一个地方。

可视化回归测试的思路很简单：改之前截图 → 改完截图 → 对比差异。

6.2 简单的"人肉 diff"流程

不需要任何复杂工具，直接用 Playwright MCP：

改代码之前：

帮我截图以下页面，保存为"改动前"参考：
- 首页
- 商品列表页
- 购物车页面
分别截桌面和手机视口。

改完代码之后：

我刚修改了 Header 组件的样式。
帮我再截图这几个页面（同样的视口），
对比一下和改动前有没有意外的变化。
重点关注：
- Header 部分是否符合预期
- 其他部分有没有被影响

AI 会告诉你："首页和商品列表页的 Header 样式已更新，符合预期。但购物车页面的 Header 下方出现了一段额外的空白，可能是修改影响了 margin。"

6.3 什么时候需要做回归测试

改了什么	需要回归测试吗
全局样式（CSS 变量、基础组件）	必须——影响范围大
共享组件（Header、Footer、按钮）	应该——多个页面在用
单个页面的局部修改	一般不需要
升级依赖版本	强烈建议——你不知道会改变什么
重构代码（不改功能）	必须——这是重构的信心来源

---

附录 A · 常见测试场景 Prompt 模板

模板 1：快速页面检查

打开 [URL]，帮我做一个快速检查：
1. 页面是否正常加载（不是白屏或 404）
2. 控制台有没有红色错误
3. 截图给我看看整体效果

模板 2：响应式测试

在 375px（手机）和 1440px（桌面）两个视口下
截图 [URL] 的 [页面名]，检查：
- 布局是否合理，有没有溢出
- 文字是否可读
- 按钮和链接是否可点击

模板 3：表单测试

测试 [URL] 的表单：
1. 正常数据提交：[具体的测试数据]
2. 空提交：不填任何内容直接提交
3. 异常数据：[具体的异常输入]
每步截图记录结果。

模板 4：调试定位

[URL] 的 [描述现象]。
帮我排查：
1. 控制台错误
2. 网络请求状态
3. 页面实际展示截图
4. 根据以上信息分析可能的原因

模板 5：改动后回归检查

我刚修改了 [改动描述]。
帮我检查以下页面是否受影响：
- [页面 1 URL]
- [页面 2 URL]
分别在桌面和手机视口下截图，重点关注 [关注点]。

---

附录 B · "够用就好"的测试策略

小公司的测试金字塔（倒过来的）：

    ┌─────────────────────────────┐
    │                             │
    │   AI "看一眼"（最常用）       │  ← 每次改完代码都让 AI 看一下
    │   成本：0，时间：1 分钟       │
    │                             │
    ├─────────────────────────────┤
    │                             │
    │   AI 模拟操作（重要功能）     │  ← 核心流程上线前跑一遍
    │   成本：0，时间：5 分钟       │
    │                             │
    ├─────────────────────────────┤
    │  自动化测试脚本（关键路径）   │  ← 只对最核心的功能写测试
    │  成本：写一次，时间：持续收益  │
    └─────────────────────────────┘

核心原则：

1. 不追求覆盖率。5 个测试保护 5 个核心功能 > 50 个测试覆盖所有角落
2. 先手动再自动。用 AI 手动测几次后，觉得"这个测试我经常跑"，再让 AI 生成测试代码
3. 测试是保险，不是目的。花在测试上的时间应该远少于花在开发上的时间
4. 坏了再补。某个功能反复出 bug？补一个测试锁住它。没出过问题的功能不需要测试