关于 ln-42-acceptance-test-builder
用于根据明确需求构建精简且可信的验收测试组合,面向开发者提供测试选择、实施与证据报告流程,并限制修改范围,不修复产品代码。
主要功能
- 01需求与可观测边界映射
- 02测试组合决策
- 03可复现的验收证据
- 04限定范围内实施测试
- 05执行与证据报告
适用场景
- 01决定新增或淘汰测试
- 02安全验证用户可见行为
- 03通过 UI、API 或 CLI 验证结果
- 04报告验收证据缺口
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ levnikolaevich/ claude-code-skills --skill ln-42-acceptance-test-builder安装后在 Claude Code 中输入/ln-42-acceptance-test-builder确认已加载。
详细介绍
验收测试构建器
目标: 针对已声明的需求,通过用户或外部系统可观察的边界,交付规模最小且可信的验收测试组合。仅修改获准的测试和测试文档;实施有依据的新增、更新、合并和删除,不修复产品代码。
执行约定: 按顺序排列的复选框即为完成定义。始终在内部将每项标记为 PENDING、附有具体证据的 PROVEN、附有条件不存在证据的 CLEARED,或标明差距的 UNPROVEN;阅读、委派或工具故障都不能视为证据。每完成一个部分后都要重新核对各项。返回前,解决所有 PENDING 项,并且只统计 PROVEN 和 CLEARED 项;针对每个差距,遵守此技能的判定和审批规则。
保留用户意图、范围和现有授权。继续已获授权的工作;仅针对尚未解决且影响重大的选择,或必须取得的外部审批提出询问。根据实质风险调整检查深度,不得悄然跳过检查。保留依赖关系和安全顺序;除此之外,应为每项义务选择合适的验证方法。
工具路由
| 需求 | 首选工具 | 适用时机 | 后备方案 |
|---|---|---|---|
| 工作区安全 | Git 状态、差异、仓库说明以及分支或工作树检查 | 编辑前始终执行 | 用户更改无法安全区分时停止 |
| 现有测试惯例 | 文件列表、搜索、清单、运行器配置、CI 和重点查阅 | 选择项目原生的运行器、布局、夹具和命令 | 遵循最近的维护中测试模式 |
| 行为与接线 | 语言服务器或宿主原生代码智能工具 | 定位可观察入口点、注册、使用方和状态边界 | 缩小搜索范围并直接检查 |
| 测试实施 | 原生编辑工具和项目生成器 | 创建测试、夹具、辅助程序和必要且范围狭窄的测试文档 | 创建最少且符合项目惯例的文件;绝不手动编辑生成状态 |
| 可观察执行 | 仓库定义的 Shell 命令、浏览器、API 客户端、CLI 或一次性集成环境 | 证明 UI、协议、命令或持久状态的结果 | 返回 INCOMPLETE,并指出缺少的具体检查 |
| 外部契约 | 与版本匹配的官方文档或规范 | 预期行为取决于当前外部 API 或标准 | 标记为 UNVERIFIED;不要编造预期结果 |
绝不针对生产环境或未经批准的外部目标运行验收测试。不得部署、发布、迁移共享数据、轮换凭据,也不得仅为让测试通过而接受输出变更。
证据规则
- 根据需求、公开契约、示例、不变量或独立参考推导预期行为;绝不能依据正在测试的实现计算来推导。
- 优先验证终端持久状态或用户可见结果,而非中间状态、模拟调用、日志行或内部方法结果。
- 仅对确定且可审查的契约使用 golden 文件或快照。更新预期输出属于规格变更,不是测试验证。
- 确保设置、数据分配、执行、清理和重跑行为可复现;在重试或清理掩盖首次失败之前,保留首次失败信息。
- 通过的命令只能证明它实际执行过的环境和场景。明确说明每个未覆盖的单元和不可用的边界。
- 不测试语言、框架、软件包、数据库供应商或其他通用行为;只测试依赖于该仓库的可观察契约、配置、集成或策略。
- 将
KEEP、ADD、UPDATE、MERGE、DELETE和NO_TEST视为测试组合决策,与执行结果区分开来。如果现有证据、整合、退役或接受剩余风险更合适,不要默认选择ADD。 - 仅当测试依据已过时,或有证据表明所有仍需覆盖的独特实质行为、故障模式、判定依据强度和有效故障定位能力仍得到覆盖时,才删除或合并测试。
检查清单
1. 确定变更边界
- 明确需求、验收标准、参与方、受保护结果、可观察契约、明确的非目标、获准的测试组合决策、允许的测试路径和允许的测试文档路径;将推断出的体验质量标注为假设。
- 编辑前阅读适用的仓库说明,并检查 Git 状态、未跟踪文件、生成目录和现有用户变更。
- 确定项目原生的运行器、目录布局、命名、固定数据、设置、清理、环境配置和 CI 调用方式。
- 新建测试前,清点受需求或契约影响的现有测试,并梳理它们实际使用的判定依据。
- 将每项需求映射到可用于验证的边界:UI、API、CLI、消息、集成、文件或持久状态。
- 确定场景所需的凭据、服务、账户、端口、设备、浏览器、数据集和破坏性影响。
- 如果没有安全的目标、可靠的预期契约或可分离的工作区,则在编辑前返回
BLOCKED。
2. 设计可复现的验收证据
- 为每项需求定义受保护的结果、缺陷类别、环境设置、操作、最终结果、独立判定依据、预期证据和清理方式。
- 为每项受影响的测试和重大风险,确认或推导出一项组合操作。若没有获批的策略,应根据影响、可能的故障、独特性、可信度和维护成本论证该操作;记录
NO_TEST,并提供现有证明、其他控制措施或已接受的剩余风险。 - 对重大且用户可观察的业务风险,优先采用确定性的端到端证据。只有在更窄的、符合生产环境形态的契约或集成边界能够以更高的确定性或精确度证明最终结果时,才采用该方式;绝不可用单元实现检查替代验收证据,也不可覆盖可观察契约中不存在的内部细节。
- 仅在无效输入、授权、边界、部分故障、重试、幂等性、恢复和兼容性行为可能实质性影响受保护的结果时,才将其纳入测试。
- 分配唯一或带命名空间的测试数据,并在影响可复现性时控制时钟、随机性、区域设置、顺序和并发。
- 当模拟对象会绕过验收所需行为时,使用真实依赖项或获批的模拟器;固定版本,并验证其就绪状态和重置行为。
- 对于确定性输出,应根据独立契约推导黄金样本或差异预期,并确保产物足够精简,便于审查。
- 对于非确定性输出,应断言稳定的不变量和语义字段,而不是通过规范化来掩盖故障,或对噪声创建快照。
- 根据可观察契约和区域设置策略,使用稳定且符合项目惯例的语义定位器(角色、可访问名称、标签)或明确的 ID/测试钩子。避免依赖样式、位置、时序和附带结构。若文案本身是需求,应单独处理精确文案断言;当稳健的语义定位器已存在时,不要仅为添加钩子而要求修改产品。
- 明确必需或诊断性门禁,并在证据具有临时性、受兼容性约束、针对特定事件或与变化中的契约紧密耦合时,设定审查或退役触发条件。
3. 在测试范围内实现
- 按照现有项目布局创建或更新测试,并使用能体现行为的名称和失败消息,以指出被违反的需求、受保护的结果和检测到的缺陷。
- 实施获批的
MERGE和DELETE操作,不遗留已被取代的测试、夹具、快照、辅助工具、注册项或 CI 条目;在仓库原生路径、名称、标签或任务证据中保留替换的可追溯性。 - 仅当维护中的夹具和辅助工具仍能清晰呈现其默认值和副作用时,才复用它们;不要为单一场景新增抽象。
- 缺少前置条件时,设置应立即失败;无论成功、断言失败、超时、取消还是设置部分完成,清理都应安全。
- 确保测试可重复运行且具备幂等性;不得依赖执行顺序,也不得默默复用先前运行留下的状态。
- 只有当贡献者无法通过其他方式配置、运行、解读或清理新证据时,才添加范围最小的测试文档。
- 不得编辑生产代码、弱化断言、在没有证据的情况下放宽超时、跳过失败用例,或重新生成预期产物以使测试通过。
- 检查差异,排除无关格式更改、生成文件带来的大量变动、机密信息、特定环境路径以及超出获批范围的更改。
4. 执行并保留证据
- 先运行受影响范围最小的场景,然后运行相关测试套件和可用时所需的仓库门禁;如果操作只会移除证据,则运行替代证据或最接近的保留证据。
- 记录命令、工作目录、环境类别、目标、版本、退出状态、耗时、产物和实际执行的场景。未选择任何测试或输出全部跳过,均不能证明已验收。
- 保留复现缺陷所需的首次失败输出、种子、顺序、请求、响应、截图、差异或持久状态。
- 修改测试前,先区分产品故障、测试缺陷、环境故障、依赖不可用和不稳定证据。
- 如果有效测试暴露了产品缺陷,保留失败的验收证据并报告最小复现;绝不修复产品代码。在安全的前提下,继续处理范围内的独立测试工作。
- 如果状态归属或幂等性很重要,则验证清理效果,并至少重新运行受影响的场景。
- 除非重试用于诊断不确定性,否则避免重试;重试不得将初次失败变成悄然通过。
5. 完成收尾,避免夸大结论
- 将每项要求和受保护结果对应到最终测试路径或
NONE、命令或替代控制、判定依据或已接受的风险,以及PASS、FAIL、BLOCKED或UNPROVEN结果。 - 核对计划与实际执行的测试组合操作,包括合理说明的偏差,并报告新增、更新、合并和删除测试的净数量;不要把数量当作质量目标。
- 所有获批的测试组合操作均已实施,且所需证据记录了可信的
PASS或产品FAIL,或有合理依据的NO_TEST控制时,使用COMPLETE。未解决的测试缺陷不属于已完成的证据;此判定不代表产品正确。 - 如果仍有安全的工作未完成,或环境、依赖、测试缺陷或中断导致无法可信地执行,则使用
INCOMPLETE;说明具体的剩余操作或检查。 - 如果无法安全实施操作、要求缺少可靠的判定依据,或无法保护工作区,则使用
BLOCKED。
自检
- 返回前核对。 检查各项证据、要求覆盖情况、矛盾、范围、判定和适用的清理工作。修正报告或已获授权的产物。重用有效证据;不要自动重新扫描仓库或重新运行已成功的命令。仅在相关变更、失败或证据未解决时重复检查。披露剩余差距。
输出约定
使用用户的语言,按以下顺序报告;保留全部五个字段,每项事实只陈述一次。结果较小时,每个字段可占一行;省略空表格,不要复制链接的产物:
- 结果: 技能专属判定及有证据支持的结果。
- 范围: 已审查/变更的范围、排除项、基线和重要假设。
- 证据: 以下技能专属字段;区分事实、推断和未经验证的说法。链接到产物;适用时使用表格。
- 验证: 检查/结果、不可用的证据,以及适用的清理/外部状态。
- 完成情况:
Checklist: X/Y complete;Incomplete: None或列出每项UNPROVEN的原因、结果影响和确切的下一步操作;剩余风险和所需决策。
技能专属证据: 要求/受保护结果 → 现有证据 → 测试组合操作 → 最终测试路径或 NONE → 独立判定依据/命令 → 门禁/结果 → 退役触发条件。列出变更的测试/文档文件、整合/删除测试的替代证据、测试组合的净影响、确切命令和产物、保留的产品故障复现、清理工作、不可用的环境和排除的单元。证据完备不代表产品正确。