AI 时代如何测试
我做了几年前端测试，AI 进来之后，我手上其实多了三件趁手的工具，而不是一件「银弹」。这篇是我的实战观点：别再默认「上最自动化的那个」，本事在于按「场景 + 阶段」把三件工具配对。 三者平权、各擅其场，谁也不压谁——
- 手工测试 —— 判断力、主观体验、一次性走查。AI 替代不了的「人」的那部分，探索性点点看、UX 好不好用、需求验收走查，就该人来。
- MCP + skills 让 AI 跑 e2e —— 用自然语言驱动真实浏览器（Playwright MCP / Chrome DevTools MCP）。快速冒烟、临时验证、bug 复现的最优解；很多场景写框架 e2e 反而是杀鸡用牛刀。
- 传统框架 + AI 写用例 —— 在懂需求/白盒的前提下，让 AI 按五层 + 提示词工作流写系统化用例（Vitest / Cypress / Playwright）。系统性回归、CI 门禁的归宿；但不是所有东西都值得为它买单。
我反对的框架是：把「AI 写用例」摆成质量底座/终点，搞一套「手工 < MCP < AI 写用例」的高下阶梯。这篇里你看到的决策表是按场景选，不是按自动化程度排序。
一句话总纲：AI 没有取消测试纪律（分层 / 精确到 case / 反向验证 / 回归网），而是让这些该有的纪律以更低成本落地——并新增了「让 AI 直接驱动浏览器探索」这件以前做不到的事。
评价
这套打法的优点
- 不浪费：低价值的回归交给 AI 写用例守住，一次性走查交给人，临时验证交给 MCP——每件事用最划算的方式做，而不是一律上重框架
- 纪律没丢：自测 → 自测报告 → 测试准入这套制度，以前靠人肉执行成本高，AI 副手让它能真正落地；分级覆盖、反向验证、bug-fail-first 一样不少
- QA 被释放：研发自测兜住低级缺陷，QA 不再当清道夫，精力投到业务语义、探索性、集成与回归的深度验证
- 以前做不到的能力：MCP 让「让 AI 自己点点看哪里坏了」从空想变成现实，补上了探索性自动化的空白
这套打法的边界
- MCP 不是 CI 门禁：自然语言驱动浏览器适合「发现问题」，可重复性 / 严格断言不如框架 spec，别拿它当回归网
- AI 会写假绿用例：「看着覆盖、实则不验证」是 AI 写用例的头号陷阱，反向验证 + 人评审粒度是不能省的防线
- 手工不是落后：能稳定复现的回归别一直手工点——沉淀成自动化；但探索性 / 主观体验就该一直手工，别硬塞框架
- 三件配齐才完整：只用其中一件都会留洞——光手工漏回归网，光 AI 写用例漏探索性与手感，光 MCP 漏 CI 门禁
文档地址
我的《通用测试规范》理念（自测→报告→准入 / 五层 / 分级覆盖 / 反向验证 / 回归网） ｜ 测试金字塔（Martin Fowler） ｜ MDN：测试入门