SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场design-testing-strategy

design-testing-strategy

测试与质量

查看项目

更新于 10-15 14:37

技能介绍

用途

Design Testing Strategy 是一个用于设计适合用途、适合关键性的测试策略的参考手册。它面向在编写任何类型测试之前需要做出测试决策的场景，帮助开发者确定对特定工件应启用哪些测试类型、跳过哪些测试类型，以及如何组织测试用例。

该技能以决策为导向，而非哲学讨论：每个决策门都是确定性的（满足 X 则开启 / 满足 Y 则关闭），每个模式都强制执行（字段顺序很重要），每个示例都端到端完整呈现。

主要能力

决策门（Decision Gates）

按数字顺序应用 Gate 0 到 Gate 6。每个门产生一个独立的布尔值（applies: true|false）。门之间不会相互否决——单个工件可以同时开启单元、集成、契约和基于属性的测试。

  • Gate 0 全部跳过：当关键性为 NONE（仅文档、注释、格式化、生成代码、无逻辑配置、一次性原型）时开启；当存在分支、计算输出、副作用或用户可见行为时关闭。
  • Gate 1 单元测试：当代码包含任何逻辑（分支、循环、条件、计算、转换、解析、验证、格式化）时开启；当是纯声明式接线（DI 注册、路由表）且无行为时关闭。
  • Gate 2 集成测试：当跨越边界（HTTP 调用、数据库查询、外部 SDK、消息队列、文件系统 I/O，或与 >=2 个不同协作者协作且单元测试替身会扭曲行为）时开启；当是无 I/O 且 0-1 个稳定协作者的纯函数时关闭。
  • Gate 3 组件或端到端测试：当存在 UI 表面且关键性 >= MEDIUM-HIGH 且属于用户面向的关键路径（注册、结账、认证、支付、主要 CTA）时开启；当是仅内部管理屏幕、开发工具或非关键 UI 时关闭。
  • Gate 4 契约测试：当公共 API 被 >=1 个不同客户端消费（移动端 + Web、多个内部服务、外部合作伙伴）且独立部署节奏时开启；当消费者和提供者一起部署时关闭。
  • Gate 5 冒烟测试：当存在可部署表面（Web 应用、API、服务）且存在部署/CI 管道使部署后验证有意义时开启；当是库、内部助手或无部署管道时关闭。
  • Gate 6 基于属性的测试：当输入域很大或无界（数值范围、字符串、列表、解析器、序列化器、编码器、数学）且不变量稳定（往返、幂等、单调、交换）且关键性 >= MEDIUM-HIGH 时开启；当输入域小且有限、不变量不稳定或关键性 LOW 时关闭。

关键性量表

用于 Gate 3 和 Gate 6：NONE（文档、格式化、生成代码、一次性代码、无逻辑配置）、LOW（内部开发工具、仅管理屏幕、日志格式化器）、MEDIUM（标准 CRUD、单团队消费者的内部 API、非关键 UI、助手和实用程序）、MEDIUM-HIGH（关键路径上的用户面向 UI、多消费者的公共 API、业务工作流）、HIGH（资金流动、认证/授权决策、安全关键验证、数据完整性、受监管领域）。

测试类型参考

提供每种测试类型的适用场景、不适用场景、框架、典型依赖和 Google 大小分类。包括单元、集成、组件、端到端、冒烟、契约、基于属性的测试。

Google 测试大小映射

按资源（大小）而非范围（覆盖路径）分类测试：small（单进程单线程、无网络、无文件系统、<100ms）、medium（单机多进程、仅 localhost、允许 tmpdir、<1s）、large（多机、允许外部网络、持久文件系统、<15min）、enormous（分布式、广泛网络、任意位置、更长）。测试类型和大小是正交的。

Playwright 与 Cypress 对比

提供 UI 端到端测试框架的选择维度：浏览器支持、多标签/多源、并行性、网络拦截，以及默认建议。

用例设计技术

使用 ISTQB 基础级黑盒技术推导每种选定测试类型内要测试的内容：

  1. 等价类划分（EP）：将输入域划分为系统预期行为相同的分区，每个分区一个测试即可。提供折扣函数的完整示例。
  2. 边界值分析（BVA）：对于每个边界值 B，测试 B-1、B、B+1。提供折扣函数边界 100 的完整示例。
  3. 决策表：当输出取决于条件组合时使用。提供 canCheckout 的完整示例。
  4. 状态转换：当行为取决于历史时使用。提供订单状态机的完整示例，包括合法和禁止转换。
  5. 表驱动测试：当 EP、BVA 或决策表分析产生 3+ 个相同形状的用例时，将其折叠为单个表驱动测试。提供 TypeScript/vitest 语法的完整代码示例。

依赖决策

为 Gate 2 和 Gate 3 选择依赖：真实基础设施（通过 Testcontainers）、内存假实现、模拟（测试替身）、存根 HTTP、真实外部服务。提供每种风格的适用场景、避免场景和注意事项。权衡总结：Testcontainers > 内存假实现 > 模拟，但成本同向增加。选择不会对边界行为撒谎的最便宜级别。

战略跳过启发式

明确的“不必麻烦”规则：内部助手不做端到端测试、绑定部署消费者的 API 不做契约测试、小有限域不做基于属性的测试、纯函数不做集成测试、静态标记不做组件测试、声明式接线不做单元测试、集成可靠覆盖的内容不做端到端测试、尖峰/一次性代码不做测试、没有“和”测试。

测试矩阵模式

每个测试策略必须表达为 YAML 块。每个列表条目内的字段顺序很重要——评判者和下游工具将第一个键解析为关键键（rationale/reason/why），第二个键解析为分类键（type/what）。模式包括 artifact、rationale、criticality、selected_types（含 rationale、type、size、framework、dependencies、gate）、rejected_types（含 reason、type）、deliberately_skipped（含 why、what）。

使用方式

  1. 按顺序阅读决策门（Gate 0 -> Gate 6）。每个门独立——可以以任何测试类型子集开启结束。
  2. 应用战略跳过启发式，移除此工件低 ROI 的开启门。
  3. 对于每个开启门，填写测试矩阵模式（selected_types 条目）——字段顺序是关键。
  4. 在 rejected_types 中列出被拒绝的类型，在 deliberately_skipped 中列出故意跳过。
  5. 使用用例设计技术中的 ISTQB 技术生成“要覆盖的测试用例”Markdown 项目符号列表。
  6. 与匹配的完整示例交叉检查（A 纯函数 / B HTTP+DB 端点 / C UI 组件）。

适用场景

适用于在编写任何类型测试之前，需要为特定工件设计测试策略的开发者。特别适合需要根据工件关键性系统化决定测试类型、避免过度测试或测试不足、并希望有确定性决策框架的团队。

限制

资料中未提供关于该技能的具体安装命令、收费信息、平台限制或效果保证。该技能为参考手册性质，不包含自动化执行功能。