07-测试 QA × AI 协同

💬 一句话读懂本篇：一人公司没有测试同事，AI 就是你的第二双眼睛——但小心”自己检查自己作业“：用 AI 按你的代码生成测试，测的是”代码做了什么”，不是”代码该做什么”。

岗位定位：🤝 人机协同 · AI 承担约 60% 工作量。测试岗的核心矛盾：AI 生成用例又快又多，但用例的”来源”决定测试的价值——从需求推导的用例能发现 bug，从实现代码推导的用例只会盖章确认。

一、传统画像：测试工程师原来干什么

二、AI 协同后的新画像

你戴上”QA 帽子”时，AI 是测试大军；但独立性必须人为制造。 关键动作：用例从需求生成，不从代码生成——这是本分册最重要的一句话。

flowchart LR
    subgraph SRC["📥 用例的两条来源"]
        R["✅ 从 PRD/验收标准生成<br>测的是「该做什么」<br>→ 能发现 bug"]
        C["❌ 从实现代码生成<br>测的是「做了什么」<br>→ 只会盖章确认"]
    end
    subgraph A["🤖 AI：测试大军"]
        A1["用例批量枚举<br>等价类/边界/状态机"]
        A2["自动化脚本<br>单测/E2E"]
        A3["日志比对/回归清单"]
    end
    subgraph H["👤 你：独立视角"]
        H1["补 AI 想不到的场景<br>（业务上下文/恶意操作）"]
        H2["验收标准拍板"]
        H3["上线放行签字"]
    end
    R --> A1
    A1 --> A2
    A2 --> H1
    A3 --> H1
    H1 --> H2 --> H3
    C -.->|"仅用于补覆盖率<br>不用于发现bug"| A2

    classDef human fill:#fff3e0,stroke:#e65100,color:#bf360c
    classDef ai fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    classDef bad fill:#ffebee,stroke:#c62828,color:#b71c1c
    class H1,H2,H3 human
    class A1,A2,A3,R ai
    class C bad

三、逐项对比：传统做法 vs AI 协同做法

四、协同工作流：一个功能的测试闭环

flowchart TD
    PRD["📋 PRD 验收标准<br>（01 分册产出）"] --> C["🤖 AI 从验收标准推导用例<br>（不看实现代码！）"]
    C --> H1{"👤 关口①：用例评审<br>补业务盲区：恶意操作/组合场景/历史坑"}
    H1 --> AUTO["🤖 AI 把用例转自动化<br>单测 + 关键路径 E2E"]
    AUTO --> RUN["🤖 跑测试 + AI 分析失败项"]
    RUN --> H2{"👤 关口②：断言质检<br>改坏一行代码，测试会红吗？"}
    H2 -->|"不会红=假测试"| AUTO
    H2 -->|"会红"| REG["🤖 AI 出最小回归清单<br>👤 手工过关键路径"]
    REG --> H3{"👤 关口③：放行决策<br>遗留 bug 分级：阻塞/可带病上线/下版修"}
    H3 -->|"放行"| REL["✅ 上线（08 分册接手）"]
    H3 -->|"阻塞"| FIX["修复 → 回炉"]
    FIX --> RUN

    classDef human fill:#fff3e0,stroke:#e65100,color:#bf360c
    classDef ai fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    class H1,H2,H3 human
    class C,AUTO,RUN,REG,FIX ai

节奏建议：日常小改动跑”自动化 + 影响面抽查”即可；碰钱、碰权限、碰数据的变更必须走完三关口。测试时间的分配原则：AI 覆盖 80% 常规面，你把省下的时间全砸在”AI 想不到的 20%”。

五、提示词模板（直接抄作业）

模板 A · 用例设计（从需求，不从代码）

1
2
3
4
5
6
7
8
【输入】功能描述与验收标准：（粘贴 PRD 相关节）
业务规则：（粘贴）
【任务】设计测试用例集，要求：
1. 方法覆盖：等价类 / 边界值 / 状态转换 / 权限矩阵，各标注属于哪类
2. 每条用例：前置条件 / 操作步骤 / 预期结果 / 优先级(P0~P2)
3. 单独一节「恶意与异常场景」：非法输入、重放、并发、越权尝试
【约束】只依据我给的验收标准推导，不要看实现代码；
验收标准含糊处，列出【需求疑问】向我提问，禁止自行脑补预期结果。

模板 B · E2E 自动化脚本

1
2
3
4
5
6
7
8
【输入】用例清单（P0 部分，粘贴）；技术栈：Playwright/Cypress + 前端框架版本
【任务】为 P0 用例生成 E2E 脚本
【约束】
1. 选择器优先用 data-testid / 语义化 role，禁止脆弱的 nth-child 和文本匹配
2. 测试数据自建自清（before/after），禁止依赖环境残留数据
3. 每个脚本独立可跑，不依赖执行顺序
4. 失败时自动截图
【输出】脚本 + 需要在页面代码里补的 data-testid 清单

模板 C · 变更影响面分析（最小回归清单）

1
2
3
4
【输入】本次变更的 diff：（粘贴）；项目模块依赖关系：（描述/贴目录）
【任务】1) 分析这个 diff 可能影响到的功能面（顺着调用链说，别只看改动文件）；
2) 输出「最小回归清单」：上线前必须手工验证的场景，按风险排序，控制在 10 条以内；
3) 指出哪些既有自动化测试覆盖了这次变更，哪些没覆盖。

模板 D · 断言质检（防假测试）

1
2
3
4
5
6
以下是一组测试代码（粘贴）和它测的业务代码（粘贴）。
请挑毛病：
1. 哪些断言是"弱断言"（改了业务逻辑它也不会红）？逐个指出并加强
2. 哪些用例实际没测到声称在测的场景（Mock 掉了被测逻辑本身）？
3. 测试之间有没有顺序依赖或共享状态？
输出修正后的测试代码。

六、验收清单（放行前逐项勾）

用例质量

• P0 用例全部来自验收标准推导（不是照着代码写的）
• 你人工补过至少一轮”业务盲区”场景（AI 不知道的历史坑、恶意操作）
• 【需求疑问】全部澄清，无”AI 脑补的预期结果”

测试有效性

• 断言质检做过：故意改坏一处业务逻辑，相关测试变红
• 无”只测顺利路径”的用例集；错误路径、边界都有覆盖
• E2E 脚本独立可重复跑，数据自建自清

回归与放行

• 最小回归清单手工过完（碰钱/碰权限/碰数据的变更：全量回归）
• 测试数据无真实用户信息（总纲红线）
• 遗留 bug 已分级并有书面决定：可带病上线的，写明理由和下版修复计划
• 放行决定是你做的，不是”AI 说测试都过了”

七、坑点清单

💬 收尾一句：测试岗的 AI 协同精髓是”让 AI 出数量，让人类出独立性“。一人公司最容易死在”没人挑刺”上——戴上 QA 帽子的那天下午，请对你上午写的代码保持敌意。 下一册：08-运维 DevOps × AI 协同——AI 写部署脚本很爽，但生产环境的每一个回车，都得你亲手按。

• Previous
  15-项目管理（自我管理）× AI 协同
• Next
  一人公司AI协同岗位全景：18个岗位的人机分工地图