illegalCreed

中文

English

中文

English

Appearance

三方式对比 ​

三件趁手的工具，按场景配对，不排高下

速查 ​

  • 手工测试：人脑当断言，不写代码，一次性走查；赢在判断力、主观体验、探索性——这些 AI 替代不了
  • MCP + AI 跑 e2e：自然语言驱动真实浏览器（Playwright MCP / Chrome DevTools MCP），不写框架代码；赢在「即时验证 + 让 AI 自己探索」，临时验证和 bug 复现最划算
  • AI 写框架用例：AI 按五层 + 提示词写 Vitest/Cypress/Playwright 代码；赢在系统性、可重复回归、CI 门禁——长期守护核心与安全类
  • 决策原则：看「场景 + 阶段」选，不看自动化程度排序。三种各有真正赢的列，谁也不压谁

三方式各是什么 ​

手工测试 ​

人直接操作被测系统，用判断力当断言：好不好用、对不对、像不像需求要的样子。不写任何代码，结论靠人脑。最闪光的地方是 AI 给不出的判断——一个表单填起来顺不顺手、一段交互符不符合需求方脑子里的预期、一个新页面里有没有「看着就不对」的地方。

MCP + AI 跑 e2e ​

借 Playwright MCP / Chrome DevTools MCP，让 AI 用自然语言驱动真实浏览器：导航、点击、填表、断言、截图、读 console 报错、抓网络请求、跑 Lighthouse。配合 Claude Code skills 把常用流程封装起来。你说「打开登录页，用测试账号登进去，看看仪表盘有没有报错」，AI 就去做了。它的独门优势是「让 AI 自己点点看哪里坏」——这件事框架 e2e 做不到。

AI 写框架用例 ​

在 AI 懂需求、懂功能、能读白盒代码的前提下，让它按五层模型（L1~L5）+ 提示词工作流（plan→评审→TDD→自测报告）写出框架测试代码：Vitest 单元/组件、Cypress/Playwright 端到端。产物是 git 里能长期跑的 spec 文件，进 CI 当回归门禁。它把「系统性测试太贵没人写」变成「可落地」。

严格中立对比表 ​

每一列都标了「谁赢」——三种方式各有它真正占优的维度，这张表不是给谁排座次：

维度手工测试MCP + AI 跑 e2eAI 写框架用例
是否写代码不写（人脑断言）✅ 零门槛不写框架代码（自然语言驱动）✅ 零门槛写 spec 代码
可重复回归差（每次靠人重点）中（脚本化但断言松、易 flaky）强（git spec，CI 一键重跑） ✅
速度（单次出结果）中（人点的速度）快（说句话就跑，免写代码） ✅慢（要先写好用例）
系统性 / 覆盖严谨度低（凭经验，易漏分支）中（覆盖到哪靠提示，断言不严）高（五层 + 精确到 case + 反向验证） ✅
适合阶段需求早期 / 准入抽查 / 深度验证 / 发布冒烟开发中即时 / 自测冒烟 / bug 复现 / 验收 demo开发全程 / CI 长期门禁
谁来做研发 / QA / 需求方（人）研发 + AI（对话驱动）研发 + AI（懂白盒的人把关）
产物判断结论 / 探索发现 / bug 单即时验证结果 / 截图 / console 日志 / 复现路径git 里的 spec 文件 + 覆盖率报告
何时最划算 ⭐一次性走查、主观体验、探索性、需求验收——稳定可复现之外的一切快速冒烟、临时验证、bug 复现、没框架时兜底——要立刻有结果、不值得写 spec系统性回归、核心/安全类守护、TDD、CI 门禁——长期反复跑、值得一次写好

看「何时最划算」这一行就够了：三种方式各占一块地盘，没有哪种能把另外两块全吃下。

怎么用这张表 ​

我自己的判断顺序是这样的：

  1. 这件事要立刻有结果、且不值得为它写 spec 吗？ → 临时验证 / 快速冒烟 / bug 复现，用 MCP。说句话就跑，比开编辑器写 e2e 快得多。
  2. 这件事需要人的判断力吗？ → 好不好用 / 像不像需求 / 探索性找问题，手工。这些 AI 给不出靠谱结论，别上框架、别让 MCP 瞎跑。
  3. 这件事要长期反复跑、守住不许坏吗？ → 核心链路 / 安全类 / 回归网 / CI 门禁，AI 写框架用例。一次写好，CI 天天守。

三个问题不冲突——同一个功能，开发中用 MCP 冒烟，验收时手工走查，沉淀时让 AI 写成 spec 进回归网。这才是「配对」，不是三选一。

反过来用就是错配

  • 拿 MCP 当 CI 回归门禁 → 断言松、易 flaky，守不住
  • 拿手工去守回归网 → 每次发版人肉重点，又慢又漏
  • 拿 AI 写用例去做探索性 → AI 只会按你给的剧本走，发现不了「意料之外」的问题

下一步 ​