mcpField
L
ln-41-test-strategy-planner

ln-41-test-strategy-planner

github.com/levnikolaevich测试与质量58457 次安装2 天前更新
代码仓库

关于 ln-41-test-strategy-planner

用于制定只读、基于风险的测试组合方案,面向需要评估测试覆盖与证据的开发团队。它要求将风险、现有证据、测试决策和验证条件对应起来,并给出优先级与结果判定。

主要功能

  1. 01梳理需求与现有测试证据
  2. 02追踪关键流程和风险
  3. 03决定测试保留、增补或淘汰
  4. 04选择测试层级与判定依据
  5. 05生成优先级测试矩阵
  6. 06标记方案就绪或证据缺口

适用场景

  1. 01为功能变更规划测试组合
  2. 02识别高风险行为的证据缺口
  3. 03整合重复或过时的测试
  4. 04在只读审查中评估测试方案

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-41-test-strategy-planner

安装后在 Claude Code 中输入/ln-41-test-strategy-planner确认已加载。

详细介绍

测试策略规划器

目标: 针对所请求的范围,制定只读、基于风险的测试组合决策。最大限度地提高对重要本地行为的信心,同时避免测试数量无谓增长、却无法提供独特缺陷信号;并明确如何保留、更改、合并、退役或有意省略受影响的证据。

执行约定: 按顺序排列的复选框即为完成定义。内部将每项标记为 PENDING、PROVEN(有具体证据)、CLEARED(有证据表明其条件不存在)或 UNPROVEN(存在缺口);阅读、委派或工具故障都不能作为证明。每完成一个部分后都要核对各项。返回前,解决所有 PENDING 项,仅统计 PROVEN 和 CLEARED 项;对每个缺口应用本技能的判定和审批规则。 保留用户意图、范围和现有授权。继续已授权的工作;仅针对尚未解决且会产生重大影响的选择或所需的外部审批提出询问。根据实际风险调整深度,不得悄然跳过检查。保留依赖关系和安全顺序;其他情况下,选择适合各项要求的验证方法。

工具路由

需求首选工具适用场景备用方案
需求和仓库规则使用原生文件读取工具以及 Git确定范围、当前工作、验收标准和受支持的命令用户提供的需求,并明确说明其局限
现有测试面文件列表、搜索、清单文件、运行器配置和 CI梳理测试级别、固件、环境和约定仓库目录树和已知测试入口
行为和边界语言服务器或宿主环境原生代码智能工具追踪入口点、使用方、信任边界、持久化、队列和外部契约定向搜索后直接检查
现有证据现有测试/CI 报告、测试读取和安全的仓库命令有关当前证明的重大不确定性可能改变策略使用静态证据并说明执行限制;不要仅为制定计划而运行测试套件
当前外部故障模式官方文档、规范、安全公告和一线实测证据外部契约或真实用户故障可能改变场景或优先级将该主张标记为 UNVERIFIED;不得臆造风险

保持此次执行为只读。不要创建测试、固件、快照、任务或文档,也不要更新正在审查的实现。

证据规则

  • 选择能够证明每项重大风险的最小可靠边界。如果无法在更低层级确立端到端流程,则使用端到端证据;若单元、集成和契约层的证明能检测不同故障,则保留各自的证明。
  • 覆盖率是发现问题的证据,不是证明。必须有一个能在指定缺陷存在时失败的判定标准。
  • 根据影响、故障的可能性、独特性、可检测性和恢复成本确定优先级;不要将这些判断转化为普遍适用的数值阈值。
  • 只有当现有测试的设置和断言能证明相同的行为及故障模式时,才能用它们缩小缺口。
  • 框架、语言、ORM、序列化器或库的行为不属于产品测试,除非本地配置或集成改变了其契约。
  • 将组合决策与执行状态分开。使用 KEEP、ADD、UPDATE、MERGE、DELETE 或 NO_TEST 表示决策;仅使用 PASS、FAIL、BLOCKED 或 UNPROVEN 表示证据状态。
  • NO_TEST 是明确的风险决策,不代表遗漏工作。请指出现有证明、替代控制措施或已接受的残余风险。
  • 可选地维护持久化测试登记表。除非规模或治理要求另行维护文档,否则优先使用仓库原生的测试名称、路径、标签、CI 配置和任务输出。
  • 只有在外部调研能为本计划补充具体故障模式、边界或判定标准时,才具有实际价值。

检查清单

1. 明确范围并收集证据
  • 明确功能、需求、验收标准、参与者、明确的非目标,以及需要保护的人或系统结果;区分所请求的机制与该机制必须实现的结果;如果没有可供规划的具体行为,则返回 BLOCKED。
  • 阅读适用的仓库说明并检查 Git 状态,避免将当前工作和无关更改误认为既定行为。
  • 检查语言、框架、运行器、测试目录、测试样本、工厂、环境、CI 门禁、覆盖率、契约测试和手动测试范围。
  • 将现有证据及每项受请求行为影响的测试映射到各项需求;依据实际判定依据,按照 Evidence Rules 中定义的执行状态,将覆盖情况记录为完整、部分、缺失或不可用;名称和接近程度都不能作为证据。
  • 检查手动、探索性、事件和生产环境证据(如果这些证据揭示了自动化测试套件未覆盖的行为)。
  • 在提出测试场景前,确定环境、数据、凭据、服务、设备、浏览器以及破坏性状态方面的限制。
  • 记录可能改变测试级别、优先级或可行性的假设和未知事项;只有在不同解释会实质性改变策略时,才提出一个简短问题。
2. 构建风险图谱
  • 追踪关键流程,从参与者触发操作开始,经过入口点、运行时接线和状态变更,直至持久化或用户可见的结果。
  • 找出具有独特重要性的本地行为,包括涉及资金、身份验证、授权、所有权、数据完整性、破坏性操作、迁移、公共契约或不可逆工作流的行为。
  • 枚举可能的缺陷类型:错误成功、拒绝有效输入、接受无效输入、边界错误、部分失败、重复交付、顺序问题、超时、重试、取消、竞态、回滚、恢复和兼容性偏移;说明哪些受保护的结果会丢失,或会造成什么具体损害。
  • 区分产品风险、实现细节以及依赖项已经保证的行为;排除虽可通过技术手段表达、但不会保护任何独特本地结果或决策的状态。
  • 找出涉及隐私或受监管的测试数据,并要求使用合成数据、最小化数据或经过明确批准的测试样本。
  • 仅在版本相关契约、反复出现的用户故障、滥用模式或互操作性风险可能改变风险图谱时,才使用最新的外部证据。
  • 定性排列风险优先级,并解释并列情况或不确定性;不要根据缺失的频率或影响数据虚构精确度。
3. 确定测试组合的操作、级别和预言机
  • 为每项实质性风险和受影响的测试分配且仅分配一个暂定操作:当可信且唯一的证明仍然有效时,选择 KEEP;对于尚未证明的实质性风险,选择 ADD;当有价值的意图仍然成立,但依据、边界、设置或预言机发生变化时,选择 UPDATE;对于可以安全合并的证明,选择 MERGE;对于过时、重复、琐碎或不可信的证明,选择 DELETE;当其他控制措施或已接受的风险已足够时,选择 NO_TEST。
  • 对于 DELETE 或 MERGE,证明测试依据已过时,或指出能够保留所有仍需验证的实质性行为、故障模式、预言机和有用故障定位信息的替代证据;切勿仅仅因为过时的证明已存在,就将其保留下来。
  • 孤立的本地规则使用单元测试;生产者与消费者一致性使用契约测试;由项目负责的边界使用集成测试;对于无法在更低层证明其最终结果、且符合生产实际形态的完整流程,使用端到端测试。
  • 避免在各个级别重复验证相同行为,除非每个级别都能检测不同类别的故障。
  • 定义充分且最少的独立预言机,并在契约要求时结合多项观测结果:返回的契约、持久化状态、发出的事件、渲染行为、外部效果、不变量或确定性产物。
  • 检查模拟和伪造实现是否绕过了场景声称要验证的边界或故障语义。
  • 根据可观测契约和本地化策略,使用项目中稳定的语义定位器(角色、可访问名称、标签)或显式 ID/测试钩子。避免依赖样式、位置、时序和偶然的结构。若文案本身是需求,应单独进行精确文案断言;如果已有稳健的语义定位器,不要仅为添加钩子而要求修改产品。
  • 仅在风险图表明相关时,才纳入正向、无效、边界、授权、错误、恢复、并发和兼容性用例。
  • 如果默认设置可能掩盖硬编码行为,则明确指定非默认配置、时间、本地化设置、随机性、顺序或数据规模。
  • 仅当受支持的契约或已知风险会影响决策时,才添加浏览器、设备、操作系统、运行时或版本维度。
  • 优先采用确定性的设置和有界数据;明确指出哪些情况下必须使用真实依赖、模拟器、一次性环境或类似生产的拓扑结构。
  • 为每项测试组合操作定义仓库门禁或诊断用途、入口前提条件,以及基于证据的完成标准;不得以测试数量或原始覆盖率作为完成标准。
4. 制定优先级测试矩阵
  • 对每项决策,注明测试依据、受保护结果、风险、现有证据或受影响的测试、测试组合操作、级别、设置、判定依据、预期证据、环境、门禁,以及已知的结果状态。
  • 对价值取决于契约、迁移、兼容窗口、变通方案、事件、依赖项或临时风险的证据,定义审查或退役触发条件;没有明确负责依据时,不要编造日期。
  • 安排场景顺序,使安全关键和信息量高的检查先于高成本的广泛检查,同时保留前置条件和状态依赖。
  • 指明哪些场景可以并行运行,哪些场景会共用可变状态、速率限制、账户、设备或环境设置。
  • 按失败后果和所需检测时间对门禁分类;只有在其他控制措施覆盖发布关键风险时,才将耗时较长的诊断检查移出常规门禁。
  • 明确说明排除项,包括没有独特受保护结果或缺陷信号的场景、低价值重复测试、框架行为、不可行的环境以及已接受的剩余风险。
  • 当策略可执行且决策完整时,使用 READY;当可以进行有价值的部分规划,但缺少重要证据时,使用 INCONCLUSIVE;当无法确定要求或安全关键边界时,使用 BLOCKED。
  • 核对风险图和决策台账:每项重要风险或受影响的测试都必须有对应操作和充分依据。
  • 对每个 INCONCLUSIVE 或 BLOCKED 区域,说明能收集证据的最小后续操作。

自检

  • 返回前先核对。 检查条目级证据、需求覆盖、矛盾、范围、结论和适用的清理工作。更正报告或获授权的产物。复用有效证据;不要自动重新扫描仓库或重新运行成功的命令。仅针对相关变更、失败或未解决的证据重复检查。披露剩余差距。

输出约定

使用用户的语言,并按以下顺序报告;保留全部五个字段,每项事实只陈述一次。简短结果可每个字段占一行;省略空表格,不要复制链接指向的产物:

  1. 结果: 与技能相关的结论及有证据支持的结果。
  2. 范围: 已审查/变更的范围、排除项、基线和重要假设。
  3. 证据: 以下与技能相关的字段;区分事实、推断和未经验证的说法。链接到产物;适用时使用表格。
  4. 验证: 检查及结果、无法获取的证据,以及适用的清理工作/外部状态。
  5. 完成情况: Checklist: X/Y complete;Incomplete: None,或列出每个 UNPROVEN 项的原因、对结果的影响及确切的后续操作;剩余风险和所需决策。

技能相关证据: 受保护结果 → 缺陷类别 → 影响 → 现有证明 → 优先级。对每项受影响的测试或差距,说明测试组合操作、级别/场景/环境、独立判定依据、必需/诊断门禁及结果,以及审查/退役触发条件。报告测试组合的净影响,并说明合理的 NO_TEST、排除的低价值重复测试、环境需求,以及针对未能确定的区域所需的确切证据操作。

评论

支持 Markdown