需要写单元/集成/E2E 测试…

适用于编写各类测试、制定测试策略、分析覆盖率缺口、性能与安全测试、以及调试 flaky 测试等质量保障场景。

适用场景

解决思路

1. 定义范围：先明确要测什么，以及适用哪些测试类型（功能/性能/安全）。
2. 制定策略：从功能、性能、安全三个视角规划测试方法。
3. 编写测试：用恰当的断言实现测试（参考快速示例中的写法）。
4. 执行测试并收集结果；若测试失败，先对失败分类（断言错误 vs 环境/不稳定导致），修复根因后重跑；若测试 flaky，则隔离顺序依赖、检查异步处理、加入重试或稳定化逻辑。
5. 报告：记录发现，标注严重级别并给出可执行的修复建议；关闭前确认覆盖目标已达成，并明确标出缺口。
6. 按示例结构写测试：使用有意义的描述、具体断言、隔离依赖，例如 describe('calculateDiscount') 下 it('applies 10% discount for premium users') 并用 expect(result).toBe(90) 断言具体结果而非仅真值；异常用 expect(...).toThrow('Price must be non-negative')；pytest 等框架沿用同样结构（def test_…、assert result == expected）。
7. 根据上下文加载对应参考文档：单元测试（Jest/Vitest/pytest）、集成测试（API、Supertest）、E2E 策略与用户流程、性能测试（k6、负载测试）、安全测试清单、报告模板与发现、QA 方法论（手工测试、质量倡导、shift-left、持续测试）、自动化框架（模式、扩展、维护、团队赋能）、TDD Iron Laws（测试优先、红绿重构）、测试反模式（测试评审、mock 问题、测试质量）。
8. MUST DO：同时测试正常路径与错误/边界情况（空输入、null、边界值）。
9. MUST DO：mock 外部依赖，单元测试中绝不调用真实 API 或数据库。
10. MUST DO：使用读起来像自然语言规格的 it('…') 描述。
11. MUST DO：断言具体结果（如 expect(result).toBe(90)），而不只是断言真值。
12. MUST DO：在 CI/CD 中运行测试；记录并修复覆盖缺口。
13. MUST NOT：跳过错误路径测试（例如只测 try/catch 的成功分支）。
14. MUST NOT：在测试中使用生产数据，改用 fixtures 或 factories。
15. MUST NOT：创建顺序依赖的测试，每个测试必须可独立运行。
16. MUST NOT：忽略 flaky 测试，应隔离并修复，而不是反复重跑直到变绿。
17. MUST NOT：测试实现细节（内部方法调用），应测试可观察行为。
18. 编写测试计划时输出：测试范围与方法、测试用例与预期结果、覆盖分析、带严重级别的发现（Critical/High/Medium/Low）、具体修复建议。

适用边界 · 注意事项

• 不适用于与测试无关的代码实现、代码评审或部署运维任务，应改用相应的专项技能。
• 当需要真实生产数据或必须调用真实外部 API/数据库来验证时，与本技能的约束冲突，需另设专门的环境与授权。
• 性能测试（k6/Artillery）与安全测试（OWASP 方法）需要相应工具和明确授权，未具备时不要贸然执行。