第3章 Given前置条件编写原则:状态设定、数据准备、环境上下文

适用场景

Given 前置条件是验收场景的“初始快照”。以下场景尤其需要严格遵循三个维度的编写原则:

  • 业务状态依赖型:如订单状态、用户会员等级、审批流程节点。
  • 数据驱动型:如价格计算依赖商品库存、汇率、优惠券。
  • 多环境/多上下文:如跨区域部署、时区差异、租户隔离。
  • 复合条件组合:多个前置条件相互影响,需避免遗漏或冲突。

前置条件:三个核心维度

完整的 Given 前置条件必须同时覆盖“状态设定”“数据准备”“环境上下文”。缺失任何一个维度都可能导致验收结果的不可复现。

维度描述典型问题
状态设定系统或对象的业务状态(如:用户已登录、订单已支付)只写“用户存在”未写“用户已登录”
数据准备具体的数据值(如:账户余额 100 元、库存数量 5)写“有商品”未指定具体库存
环境上下文运行时环境参数(如:当前时间、语言、地区、配置开关)依赖默认时区导致跨时区测试失败
最佳实践:每个 Given 语句尽量只表达一个维度,用“And”组合,方便维护和复用。

操作步骤

编写 Given 前置条件时,建议按以下四步递进:

  1. 分析业务状态:从场景描述中提取系统或角色的初始状态,使用领域术语定义。
  2. 梳理数据依赖:列出所有影响场景的变量(金额、数量、标记位等),明确其具体值。
  3. 明确环境上下文:确定运行时的外部条件(时间、网络、配置、外部服务模拟)。
  4. 组合为完整 Given:按“状态→数据→环境”顺序组织,必要时加上注释说明。

示例:网上购物“使用优惠券下单”场景

Given 用户已登录(状态设定)
And 用户账户中有 1 张满 100 减 20 的优惠券(数据准备)
And 购物车商品总额为 120 元(数据准备)
And 当前系统时间为 2025-06-01 10:00:00(环境上下文)
And 促销活动“618大促”已生效(环境上下文)

输入输出物

类型说明
输入用户故事/验收场景描述、领域模型、接口定义
输出按“状态-数据-环境”维度拆解的 Given 语句集(通常以 Gherkin 格式呈现)

责任边界

角色职责
业务分析师(BA)明确业务状态定义和有效数据范围
测试分析师(QA)补充边界值、异常环境上下文,确保可测试性
开发人员(Dev)反馈技术可行性,确认环境上下文可被模拟(如 Mock 时间)

记录材料

推荐使用统一模板记录 Given 前置条件的分析结果:

场景:使用优惠券下单
状态设定:用户已登录,订单未支付
数据准备:优惠券满100减20,购物车合计120元
环境上下文:系统时间2025-06-01,促销活动ID=618
Given 语句:
  Given 用户已登录
  And 用户账户中有1张满100减20的优惠券
  And 购物车商品总额为120元
  And 当前系统时间为2025-06-01 10:00:00
  And 促销活动“618大促”已生效

异常处理

  • 状态冲突:如同时要求“用户已登录”和“用户未注册”——需要和 BA 确认正确状态。
  • 数据不充分:Given 中未指定关键数值(如库存数量)——补充默认值或边界值。
  • 环境上下文遗漏:场景依赖特定时区或配置——使用显式条件(如“系统时间设置为 UTC+8”)。
  • 过度复杂:一个 Given 包含多个维度——拆分为多条 And 语句。

验收标准

检查 Given 前置条件是否合格:

  • ✅ 每个维度(状态、数据、环境)都至少被提及一次?
  • ✅ 数据值具体、可度量,不含模糊词(如“一些”“多个”)?
  • ✅ 环境上下文可以精确复现(包括时间、配置、外部依赖)?
  • ✅ Given 语句不包含步骤描述(不能出现“点击”“输入”)?
  • ✅ 组合后的 Given 能在测试前通过调用 API/数据库/模拟器完全设置?
Given前置条件编写流程 Given前置条件编写流程(三个维度) 场景需求 / 验收标准 状态设定 业务状态 / 角色状态 数据准备 具体数值 / 边界值 环境上下文 时间 / 配置 / 模拟 完整 Given 条件 每个维度单独列出 → 用 And 组合 → 确保可复现
核心要点:编写 Given 时,将“状态设定”“数据准备”“环境上下文”视为三个独立检查项,逐一填写。可参考“状态-数据-环境”清单快速校验是否包含完整前置条件。