测试场景助手

先讲要解决的具体问题

写测试用例时最常遇到的困境是：需求文档只描述了主流程，边界条件和异常分支全靠测试同学凭经验脑补。这导致用例质量高度依赖个人能力，同一份需求不同人写出的用例覆盖率差异极大。更糟糕的是，业务规则散落在代码和口口相传中，等到评审时才发现遗漏了关键校验逻辑。

核心能力与关键步骤

test-scenario-helper 把测试用例设计拆成五个可执行步骤：

1. 需求理解与测试点提取：解读需求文档，还原真实用户场景，区分核心与辅助功能，并拆解为可落地的测试点。
2. 设计方法选型：按场景特征匹配方法。数值范围校验用 等价类划分 + 边界值分析；多条件组合逻辑用 判定表驱动法；端到端业务流程用 场景设计法；回归补测用 错误推测法；多因素组合爆炸用 正交试验法。
3. 用例编写：先搭整体框架再细化子模块。用例要素包括编号、标题、前置条件、测试步骤、预期结果和优先级（P0/P1/P2）。核心功能颗粒度细化，辅助功能适当收敛。
4. 测试点评审卡点：在正式写用例前，组织产品、开发、测试评审测试点清单。核心原则是测试点廉价、用例昂贵，低成本纠偏能避免后续大量返工。
5. 用例评审与迭代：聚焦需求覆盖率、场景完整性和可执行性。需求变更后第一时间同步更新用例。

适用边界与注意点

这套方法论适用于功能测试用例设计，但它有一个硬前提：references/business_rules.md 必须由你自行填充。通用方法论 + 你的业务规则 = 精准用例，缺少业务规则层，技能只能产出通用骨架，无法命中系统特有逻辑。