4. 需求分析与可测试性评审

需求分析阶段的测试介入，目标不是“把需求文档读一遍”，而是把需求中隐含的可验证条件显式化。用户故事、验收标准与业务规则是三类最常见的需求载体，它们各自携带不同粒度的信息：用户故事给出角色、目标与价值，验收标准给出可判定的行为边界，业务规则给出跨场景的约束与计算逻辑。测试人员要做的是把这三者“翻译”成测试条件，并在翻译过程中暴露歧义、遗漏与不可测试的表述。

一、三类需求载体的信息差异

用户故事通常采用“作为……我希望……以便……”的格式，它描述的是意图而非行为。例如：“作为会员，我希望在结算时使用优惠券，以便降低支付金额。”这句话本身无法直接测试，因为它没有说明优惠券如何生效、是否可叠加、过期如何处理。验收标准则把意图落到可观察的行为上，常见形式是 Given-When-Then：Given 会员持有一张满100减20的有效券，When 订单金额为120元并选择该券，Then 应付金额为100元。业务规则进一步补充约束，例如“同一订单最多使用一张优惠券”“优惠券不可与限时折扣叠加”“券过期后不可使用”。

测试条件提取的关键动作，是把验收标准中的每个可判定短语拆成独立的测试维度。以上述验收标准为例，可提取出：券状态（有效/过期/已使用）、订单金额与门槛的关系（低于/等于/高于100）、券类型（满减/折扣）、叠加规则（是否与其他优惠同时存在）。这些维度组合后形成测试条件，而不是直接写成测试用例——测试条件描述“要验证什么”，测试用例描述“怎么验证”。

二、从验收标准到测试条件的拆解方法

拆解时建议采用“维度—取值—约束”三层结构。以“满100减20优惠券”为例，第一层维度包括：订单金额、券状态、券类型、用户等级、叠加规则。第二层取值：订单金额可取 99、100、101、200；券状态可取有效、过期、已使用、未激活；券类型可取满减、折扣、免邮。第三层约束来自业务规则：满减券要求订单金额≥门槛；过期券不可用；同一订单最多一张券；券不可与限时折扣叠加。

把三层结构展开后，测试条件自然浮现。例如“订单金额=100 且券状态=有效 且无其他优惠”是一个正向条件；“订单金额=99 且券状态=有效”是一个边界条件；“订单金额=120 且券状态=有效 且同时存在限时折扣”是一个规则冲突条件。每个条件都应能回答“预期结果是什么”，否则说明需求本身还不可测试。

三、识别歧义、遗漏与不可测试需求

歧义通常来自模糊形容词或未定义术语。例如“系统应快速响应”“界面应友好”“优惠力度合理”。测试人员需要追问：快速是多久？友好体现在哪些可观察行为？合理由谁判定？把“快速”改为“在 200 并发下，订单提交接口 P95 响应时间不超过 800ms”，需求才具备可测试性。

遗漏常见于异常分支和边界值。上述优惠券需求若只写了“有效券可抵扣”，就遗漏了：券过期时用户看到什么？订单金额刚好等于门槛时是否可用？用户同时选中两张券时系统如何处理？支付失败后券是否退回？这些遗漏如果不补充，测试只能凭猜测执行，缺陷会在生产环境暴露。

不可测试需求的典型特征是缺少判定标准或依赖主观判断。例如“系统应保证数据安全”“用户体验应流畅”。改进方向是把它转化为可观察、可量化的指标：数据安全可细化为“敏感字段在传输和存储时均加密，未授权访问返回 403”；体验流畅可细化为“列表页首屏渲染时间不超过 1.5s，滚动帧率不低于 50fps”。

四、评审推动改进的实践方式

可测试性评审不是测试人员单方面挑毛病，而是与产品、开发共同把需求“打磨到可验证”。实际操作中，可以在需求评审会上同步输出一份测试条件清单，按“需求条目—测试条件—当前状态（明确/歧义/遗漏/不可测）—改进建议”组织。对于歧义项，当场确认量化标准；对于遗漏项，补充异常分支和边界规则；对于不可测项，推动转化为可观测指标。

例如，针对“优惠券不可与限时折扣叠加”这条规则，测试条件清单中应记录：叠加场景下系统应拒绝使用券还是自动选择最优优惠？拒绝时提示文案是什么？自动选择时按什么优先级计算？这些问题的答案会直接改变测试预期，也会反向推动产品补充规则说明。评审结束后，测试条件清单可作为测试用例设计的直接输入，避免从零开始重新理解需求。

需要强调的是，测试条件提取的粒度应适中。过粗会遗漏关键分支，过细则会在需求阶段陷入用例细节。一个实用的判断标准是：每条测试条件应能对应一个明确的预期结果，且不同条件之间的边界清晰可辨。满足这两点，就足以支撑后续的用例设计与执行。