authoring-test-plan

authoring-test-plan — SKILL.md

变体： standard · 使用时机： 为项目编写（或修订）QA／验证计划，达到测试人员无需进一步提问即可执行的标准；每种行为至少有一个可追溯的测试用例，测试用例目录按风险加权而非穷举组合，并且适用的非功能测试具有数值目标。

概述

此技能介绍如何编写一份出色的测试计划（QA／验证计划）——这份文档说明测试什么、在哪个层级测试、在什么环境中测试、使用什么数据、达到什么完成标准，以及要执行哪些具体用例。其内容涵盖测试策略（范围、功能测试层级和类型、覆盖方法、非功能测试、环境和测试数据、进入／退出标准、基于风险的优先级排序），以及逐条列举的测试用例目录（每个用例包括：ID、前置条件、步骤、预期结果、可追溯性），还包括如何以版本化差异的形式修订已获批准的计划。此技能传授的是编写者的判断力——研究方法和质量标准——而非章节列表。它假设有两种协作工具：提供章节结构的测试计划模板工具，以及用于依据成熟测试策略实践制定计划的深度研究能力。编写者会收到上游文档（通常包括：列出待验证行为的 feature-spec、列出待测试操作和错误的 api-spec、作为退出标准依据的 PRD，以及用于确定非功能测试目标的 NFR／architecture-doc），而不是一张白纸。质量标准是：测试人员无需进一步提问即可执行计划——每种受支持的行为都有可追溯的测试用例，测试层级、环境和数据均有说明，退出标准可测试，适用的非功能测试具有数值目标，测试用例目录的规模按风险确定，既不凑数也不单薄。

何时启用

• 根据已获批准的 feature-spec（以及 api-spec／PRD／NFR）编写测试计划／QA 验证计划，其中明确列出系统必须满足的行为。
• 明确功能测试层级和类型、覆盖方法、非功能测试、环境和测试数据、进入／退出标准、风险优先级，以及测试用例目录。
• 根据变更请求修订已获批准的计划（上游行为发生变更、新增或移除，或发现缺陷）——采用版本化差异，而不是重画计划（参见步骤 8）。
• 使用经研究、有可追溯性且按风险加权的逐行为覆盖和可执行用例填写测试计划模板。

请勿在以下情况启用：

• 编写测试自动化代码（可执行的 pytest／Playwright 等脚本）——这是本计划的下游实现工作。计划规定测试什么以及测试用例；它不编写脚本。
• 编写发布运行手册中的部署后验证（运维冒烟测试流程）——这是单独的文档，会复用本计划的退出标准，而非 QA 策略。
• 编写行为契约本身（feature-spec／api-spec）——这些是上游输入；计划据此制定覆盖范围，而不是重新定义它们。
• 审查或评分已完成的测试计划——请使用 reviewing-test-plan（配套的审核关卡）；此技能仅用于编写。

输入

阅读计划交给你的每一份文档——即你的 depends_on 集合（上游发现步骤确定的、为本计划提供信息的文档）——并据此推导内容。不要硬编码狭窄的输入范围：常见上游文档（feature-spec + api-spec + PRD；如有，则包括 architecture-doc / NFRs）是方法指引，不是上限——实际输入是计划交给你的所有文档。务必自包含：根据收到的任何上下文制定计划；若缺少预期的信息来源文档（例如，没有用于性能方案的 NFRs 文档），就基于现有信息继续，并将缺口列为明确假设，切勿捏造行为或目标。如有条件，请使用研究能力（deep-research），以成熟的测试策略实践为依据，并根据风险加权的覆盖情况，按产品类型合理确定测试目录规模。对于修订，输入还包括现有计划 + 变更请求。

工作流

步骤 1：采用模板工具提供的结构——不要自行编造大纲

从测试计划模板工具（综合版）获取章节结构。此处不要重述或重新推导章节列表；本技能提供的是填充这些章节的方法。综合模板涵盖：范围、功能测试级别与类型、覆盖矩阵、环境、进入/退出准则、风险优先级、用例目录、缺陷/分诊、版本管理与变更日志、非功能测试矩阵、测试数据管理以及回归/变更影响。如果没有可用模板，请索取或制作一个，或采用上述规范章节集，然后继续。

步骤 2：加载上游文档；先构建覆盖映射——推导，绝不臆造

阅读 feature-spec（行为 + 验收标准）、api-spec（操作 + 错误模型）和 PRD（退出准则所依据的成功指标）——它们是你的输入，不是一张白纸。编写任何用例之前，先构建覆盖映射：将 feature-spec 中的每项行为/验收标准，以及 api-spec 中的每项操作 + 错误用例分别列为一行，并映射到能够验证它们的测试级别。此映射是你的覆盖检查清单——每个测试用例都必须追溯到其中一行（不得出现孤立/臆造的用例；不得有未覆盖的行为）。这是关键所在。覆盖范围和退出准则应以需求 + 风险覆盖为依据（验证每项行为；深入覆盖高风险区域），而不能只看代码覆盖率百分比（这是下游衡量的脚本指标，无法说明每项行为是否经过测试）。如果上游文档内容有限或缺失，请将缺口列为明确假设，切勿默默臆造行为。

步骤 3：通过研究为策略提供依据

进行一次 deep-research，依据成熟的测试策略实践制定计划——测试级别（依据 ISTQB：单元/组件、集成、系统/端到端、验收）、测试计划结构（ISO/IEC/IEEE 29119，现行标准；IEEE 829 已被取代，但其章节列表仍可作为易读的检查清单）、测试类型分类（功能/回归/冒烟-健全性/结构）、基于风险的测试（可能性 × 影响决定优先级 + 深度）、需求覆盖可追溯性，以及用例设计技术（BVA、等价类划分、判定表、状态转换测试、成对选择、负向测试）——针对本产品的实际表面，而不是泛泛而谈“测试”。如果没有研究能力，不要捏造行为、级别或标准——将其列为明确标注、待验证的假设。

第 4 步：选择项目所需的测试层级——以最低成本验证

并非每个项目都需要覆盖所有层级。将覆盖映射中的每一行对应到能够验证它的最低成本层级：纯逻辑用单元测试，模块／服务边界用集成测试，用户可见的流程用系统／端到端测试，PRD 的业务标准用验收测试。审慎选择所需的类型（回归、冒烟／健全性测试）。对于纳入或省略的每个层级／类型，都要说明理由——不作说明地省略会造成覆盖缺口。

第 5 步：按风险确定测试目录优先级 + 设计用例——测试深度取决于风险，而非笛卡尔积

不可能做到穷尽测试。评估范围内每个区域的可能性 × 影响 → 得出风险优先级，并据此确定测试的深度和顺序：

• 每种行为／错误至少要有一个可追溯的用例（覆盖底线）。
• 高风险区域需要更多用例——采用适合的技术：边界值分析（BVA）（边界值及其附近）、等价类划分（每类选一个）、判定表（组合规则）、状态转换测试（有状态行为）、成对选择（存在多个相互影响的参数时覆盖所有参数对，而非 2^N 种组合）、负向测试（验证精确的预期错误）。
• 简单／低风险区域只需覆盖正常路径。
• ML／概率性行为：对于没有固定输出的模型，确定性的“预期结果”并不适用（即测试预言问题）。此类用例应采用基于指定数据集的指标阈值（例如，“在 eval-v3 上的精确率 >= 0.92”）或蜕变关系——绝不能写“模型准确”。酌情添加漂移／公平性检查。（深度说明：references/case-design-and-nonfunctional.md。）
• 可选：通过有章程、限时的探索式（SBTM）测试会话补充脚本用例，适用于自动化不具成本效益的场景——应制定章程（任务 + 测试区域 + 时间限制），而非随意点击。

规模目标是按风险做到项目范围内的穷尽，而非覆盖全部输入排列组合（一个含 N 个开关的模块有 2^N 种组合；应按风险 + 成对选择进行覆盖）。规模应与项目类型相称：轻量级 CLI 只需少量用例，并合并不需要的层级；大型 UI 产品则需要更多用例。

第 6 步：非功能测试、环境 + 测试数据、可测试标准、可执行用例

• 非功能测试（按需设置）。 对于 NFR／项目类型所要求的每种非功能测试类型，都要说明可验证的方法 + 数值／标准目标：性能（负载配置 + p95／吞吐量 + 工具）、安全性（基于威胁分析的一组测试）、无障碍（WCAG 2.2 AA）、可用性、兼容性（矩阵）、国际化／本地化。若没有 NFR 要求某种测试类型，则用一行说明后省略——绝不臆造延迟数值。（深度说明：references/case-design-and-nonfunctional.md。）
• 环境 + 测试数据。 每个层级都要说明运行地点和所需的数据。有计划地管理测试数据：合成数据与脱敏生产数据的选择、PII／PHI 处理（测试环境中不得使用未经处理的生产 PII）、夹具生命周期（配置 + 重置）、数据驱动测试。（深度说明：references/execution-and-amend.md。）
• 准入／退出（“完成”）标准必须可观察／可度量——退出标准应为“所有高优先级用例均通过 + 每种行为都有通过且可追溯的用例 + 满足所有要求的非功能目标 + 没有未解决的严重／高危缺陷”（缺陷严重性与优先级分级标准 + 未解决缺陷阈值，使“完成”在机制上可判定），而不是“测试看起来不错”。
• 测试目录中的每个用例都要明确列出前置条件、以动词开头的单一操作步骤（导航、输入、点击、验证——每步仅一个操作）、可观察的预期结果（负向用例要写出准确的消息／错误；ML 用例要写出指标门槛），以及指回覆盖映射对应行的追溯链接。

步骤 7：交付前对照标准进行自检

确认以下各项均满足（这就是 reviewing-test-plan 门禁断言的标准——作者和门禁共用这套标准，避免各行其是）：

1. 覆盖完整——每项功能规格行为/AC，以及每个 api-spec 操作/错误，至少有 1 个可追溯的用例。每项行为都有用例。
2. 功能测试级别恰当——单元/集成/e2e/验收测试符合项目实际情况；每项省略都说明理由，不得无说明地省略。
3. 入场/退出标准可测试——可观察、可衡量；退出标准与覆盖率下限和未解决缺陷阈值挂钩；覆盖率应以需求/风险为依据，而非单纯的代码覆盖率百分比。
4. 明确指定环境和测试数据——每个级别都说明运行位置、所需数据、数据的提供/重置方式，以及敏感数据的处理方式。
5. 每个用例都可执行且可追溯——包含前置条件、单一操作步骤、可观察的预期结果（或针对 ML 的指标阈值），以及追溯目标。
6. 按风险排序并加权——可能性 x 影响；测试深度随风险调整（高风险项覆盖边界情况和负向场景）；不得采用排列组合式的交叉测试；不得过于单薄或刻意填充。
7. 不虚构任何内容——每个用例都可追溯到真实的上游依据；存在缺口时，应明确标注为假设，绝不编造行为/目标。
8. 与项目类型相称——规模适合项目；对项目而言足够全面，但不做组合爆炸式测试，也不流于粗略。
9. 非功能测试——每种必要的非功能测试都应包含可核验的方法和数值/标准目标；不适用的类型应省略并注明原因。
10. 修订（如需修订）——明确变更范围，采用编辑而非重绘的方式，重新追溯覆盖映射，根据影响和风险选择回归测试集，为计划更新版本并记录变更日志，将被取代的用例标记出来（步骤 8）。

输入不足门禁：如果某项系统必须满足的行为无法通过研究确认，也无法可信地假设成可测试用例，应将其列为阻塞项（“行为规格不足——需要产品/工程决策后才能进行测试”），而不是编造用例。

步骤 8：修订已批准的计划（版本化增量——不是重绘）

收到现有计划和变更请求时（上游行为发生变更/新增/移除，或发现缺陷）：

1. 明确范围——确定受影响的覆盖映射行、用例、级别/类型、标准或非功能测试方法。
2. 编辑，不重绘——在原位置修订受影响的行/用例。
3. 重新追溯覆盖映射——变更/新增的行为应重新映射相应行；移除的行为应停用相应用例；确保覆盖完整性（每项行为都有用例，没有孤立用例）。
4. 根据影响 + 风险选择回归测试集——因涉及变更区域而必须重跑的现有用例（基于影响），加上高风险/高价值用例（基于风险）；既不是全部，也不是一个不留；并说明理由。
5. 缺陷 → 回归用例——发现的每个缺陷至少新增 1 个用例，并追溯到其破坏的行为，避免缺陷再次悄无声息地出现。
6. 为计划本身更新版本 + 记录变更日志（谁/何时/变更内容/原因）；标记被取代/停用的用例（不得悄然删除）。（详细说明：references/execution-and-amend.md。）

规则

硬性规则（绝不违反）：

• 每个测试用例都必须源自上游。 每个测试用例都必须追溯到功能规格中的行为/验收标准（AC），或 API 规格中的操作/错误。不得有无依据或臆造的测试用例；每项行为都必须有对应的测试用例。
• 按风险确定测试目录的权重，不要做笛卡尔积。 每项行为至少有 1 个测试用例；对高风险领域，使用合适的技术（边界值分析 BVA／等价类划分 EP／决策表／状态迁移／成对测试）增加测试用例（边界、负向测试）；绝不穷举全部排列组合。
• 准入和退出标准必须可测试。 每项标准都必须可观察或可测量，让读者能够机械地判定是否达标。退出标准要与覆盖率下限和未解决缺陷阈值挂钩。“测试看起来不错”不算标准。
• 每个测试用例都必须可执行且可追溯。 明确前置条件、以动词开头的单一操作步骤，以及可观察的预期结果（负向测试须写明确切错误；机器学习测试须写明指定数据集上的指标阈值，绝不能只写“模型正常工作”），并注明追溯来源。
• 非功能测试必须有针对性，不能含糊。 每种适用的非功能测试都必须包含可验证的方法和数值/标准目标（性能 p95、WCAG 2.2 AA、威胁集）；对不适用的类型，注明理由并省略。
• 绝不捏造。 不得为了显得完整而臆造行为、级别、标准或非功能需求/延迟目标。缺少来源时，应将其明确标记为假设。
• 以带版本的差异形式修订。 收到变更请求时，应在原文基础上编辑，而非重写；重新追踪覆盖情况；按影响和风险选择回归测试集；更新版本和变更日志，并标记已被取代的内容——绝不能悄悄地整体重写。
• 组合，而非重复。 按模板工具的结构组织章节；本技能负责填充内容。不要另行粘贴一份相互竞争的大纲。
• 编写测试用例规格，而非脚本；制定策略，而非运行手册。 说明要测试的内容和测试用例，而不是可执行的测试代码（由下游负责），也不是发布运行手册中的操作验证步骤。

偏好（可覆盖）：

• “全面”指的是设定目标，仍须保持适度——按风险实现覆盖完整，而非追求篇幅。对于简单的 CLI，无需的非功能测试矩阵、回归测试和变更日志可以精简。
• 对代表性取值，优先使用边界值分析 BVA 和等价类划分；对组合规则，使用决策表；对有状态行为，覆盖状态迁移；参数相互作用时，优先采用成对测试，而非穷举排列组合。
• 退出标准优先以覆盖映射为依据来表述（“每项行为都有一个通过且可追溯的测试用例”），而非只给出一个百分比。

常见问题

• 目录膨胀。 枚举所有输入组合会形成组合爆炸，也难以维护。按风险确定规模：每种行为至少一个用例；仅在可能性 × 影响较高时增加用例（边界、负面场景）；参数相互作用时采用成对测试。
• 某种行为没有对应用例。 跳过功能规范中的某项行为或 API 规范中的某个错误，会留下覆盖缺口，而质量门禁会发现这一点。先构建覆盖映射，并确保每个用例都能追溯到它。
• 退出标准含糊。 “感觉稳定了就算完成”无法评估。将每项标准表述为可观察的内容（用例通过、缺陷已关闭、覆盖映射中的行已覆盖）。
• 对 ML 功能说“模型准确”。 非确定性系统没有固定的判定基准，因此无法运行确定性的通过／失败用例。应在指定数据集上使用指标阈值（或使用蜕变关系）。
• 凭空设定性能／无障碍目标。 没有非功能需求（NFR）→ 不要编造延迟／吞吐量数值；注明上游缺失，并省略（或标记）该类型。无障碍方面的标准目标是 WCAG 2.2 AA。
• 以代码覆盖率作为退出门禁。 “覆盖率达到 90%”是可被操纵的脚本指标，无法说明每种行为是否都经过测试。应以需求覆盖和风险覆盖作为门禁标准。
• 通过重新绘制来修订。 小改动时重新生成整个计划会丢失审计轨迹和回归测试选择纪律。应限定修改范围、原地编辑并进行版本管理。
• 混淆计划、测试代码和发布运行手册。 脚本是下游实现；运行手册中的冒烟测试会复用本计划的退出标准，但运行手册本身是操作流程。请将本文保持为策略 + 目录。
• 照搬模板大纲。 重新推导章节列表会重复模板工具的工作，而且容易偏离；应结合判断力填写模板各部分。

对比示例——表面合规但规范不足 vs 可执行（用它来自查）：

方面	规范不足（拒绝）	可执行（可交付）
覆盖范围	“我们会测试登录功能。”	“FS-§3.1 登录 + API 规范中的 POST /sessions（200、401、429）均对应覆盖矩阵中的端到端 + 单元测试行。”
测试级别	“我们会编写测试。”	“令牌哈希器使用单元测试；会话存储使用集成测试；登录流程使用端到端测试。”
目录深度	“测试所有输入组合。”	“TC-001 有效登录（正常场景）；TC-002 密码错误 -> 401；TC-003 密码为空（边界）；TC-004 第 6 次尝试 -> 429（高风险负面场景）。”
ML 用例	“验证推荐器是否准确。”	“前置条件：数据集 rec-eval-v2。预期：precision@10 >= 0.85 且 p95 延迟 <= 120ms。追溯到：FS-§4.2。”
非功能需求	“它应该快速且无障碍。”	“性能：500 个并发用户，p95 <= 200ms（k6）。无障碍：WCAG 2.2 AA —— 键盘操作 + 对比度 + 焦点外观。”
退出标准	“测试到稳定为止。”	“所有高优先级用例均通过；没有未解决的严重／高优先级缺陷；覆盖映射中的每一行都有通过的用例。”

如果你的填写内容看起来像左栏——适用于任何项目、没有测试级别、没有可追溯性、没有目标——那就还没有完成。

反模式

• “我要测试所有输入组合，确保面面俱到。” 这是组合陷阱——按风险和成对组合设计规模，而不是穷举笛卡尔积。
• “只测正常路径就够了。” 高风险行为需要边界和负向用例；明确预期错误。
• “我来设定一个合理的性能目标。” 没有非功能需求，就不要编造数字——指出缺口并省略该类型。
• “对模型来说，确定性的通过/失败就够了。” 机器学习需要针对指定数据集的指标阈值或蜕变关系，而不是固定的预期值。
• “我直接为这项变更重新生成整个计划。” 修订应是范围明确、带版本的增量，并根据影响和风险选择回归测试。
• “我顺便把测试脚本也写了吧。” 可执行代码属于后续实现；本文档规定测试用例。
• “看起来不错就结束。” 验收标准必须能机械化评估；表述应基于通过的用例和已关闭的缺陷。
• “我自己写大纲吧。” 这会重复模板工具的工作——从模板工具获取结构。
• “跳过调研吧，我懂测试。” 调研为这个产品的测试级别、风险权重、非功能目标和用例设计提供依据——而不是讲解测试理论。

输出

一份全面的测试计划，达到第 7 步标准（覆盖完整且可追溯；功能测试级别恰当；准入/退出标准可测试，并与缺陷阈值挂钩；包含环境和测试数据管理；用例可执行且可追溯，包括带指标阈值的机器学习用例；按风险加权而非穷举组合；非功能测试有充分依据和数值目标；不编造内容；规模适当；修订时包含范围明确、带版本的增量，并根据影响和风险选择回归测试）。该产物是文本——以 Markdown 编写策略说明、覆盖矩阵、非功能矩阵和测试用例目录；不是 TestRail/Xray 导出文件。该方法和标准不依赖具体介质（未来测试管理后端只会改变介质）。抽象使用者包括执行计划的测试人员、复用其退出标准的下游发布运行手册，以及执行相同标准的 reviewing-test-plan 门禁。该计划依赖于功能规格和 API 规格（如有，还包括 PRD / 非功能需求）。其结构来自模板工具；此技能提供内容质量。

相关内容

• 测试计划模板工具（例如 content-template-gateway）——提供此技能要填充的章节结构（包括非功能、版本管理、测试数据和回归测试部分）。与其配合使用；切勿复述其大纲。
• 深度研究能力——为计划提供成熟实践依据（ISTQB 测试级别、ISO/IEC/IEEE 29119 结构、基于风险的测试、需求可追溯性、边界值分析/等价类划分/决策表/状态转换/成对组合、机器学习测试、WCAG 2.2 AA）。
• reviewing-test-plan——配套门禁；它执行相同的覆盖和可测试性标准（与此技能的第 7 步共用 10 条检查清单），以避免计划编写与审查标准不一致。
• feature-spec-authoring 和 api-spec-authoring 技能——生成用例验证的上游行为契约。
• PRD 和 架构文档 / 非功能需求——上游背景信息：退出标准所依据的验收要求，以及第 10 节测试所验证的非功能目标。
• 发布运行手册技能——下游运维验证文档，与本计划不同，但会复用本计划的退出标准。

渐进式披露

• references/case-design-and-nonfunctional.md — 用例设计技术（BVA、等价类划分、决策表、状态迁移测试、成对测试）+ 探索式测试/SBTM、非功能测试分类（各类型的方法 + 目标），以及机器学习/概率用例设计（指标阈值、蜕变测试、漂移/公平性）。
• references/execution-and-amend.md — 测试数据管理（合成数据与脱敏数据、PII/PHI、固定装置、数据驱动）、缺陷严重性/优先级 + 与退出条件的关联，以及修订/回归测试选择流程。
• references/sources.md — 方法 + 质量标准的研究来源。仅在审查指导内容的来源时加载。

正文篇幅预算

• description <= 1,024 个字符（agentskills.io 上限）。
• 正文 <= 约 500 行 / 5,000 个 token。
• 大量内容放在 references/ 中，按需加载。

更新日志

• 1.1.0（2026-06-15）— 面向生产环境的结构重组：新增迭代/修订方法（步骤 8）、包含数值目标的非功能测试分类（性能/安全性/WCAG 2.2 AA/兼容性/国际化）、机器学习/概率用例设计（指标阈值/蜕变测试）、用例设计技术集（BVA/EP/决策表/状态迁移/成对测试）+ 探索式测试/SBTM、覆盖率标准分类 + 基于覆盖率的退出条件、测试数据管理，以及缺陷严重性与优先级；将 ISO/IEC/IEEE 29119 列为当前标准（IEEE 829 已被取代）；将详细内容扩展至两个新的 references/ 文件。仅新增内容——输入契约 + 文本产物保持不变。与 reviewing-test-plan 1.1.0（10 条件标准）采用单一来源。
• 1.0.0（2026-06-05）— 初始评审版本。