如何拆分步骤过多的长Cucumber场景？有哪些方法与实践示例？

Cucumber场景设计的核心原则是单场景只验证一个独立可感知的业务行为，20-30步的长场景本质是把多个不同验证目标的业务流程硬串在了一起，和是否能用Background没有关系，按下面的方法拆完自然能做到每个场景4-6步。

实操拆分技巧 #

• 先给现有长场景做边界标记：逐行读步骤，把能对应明确业务结果的3-5个连续步骤圈成一个块，块的结束点必须有可独立断言的状态，比如“注册完成拿到登录态”“商品成功加入购物车”“订单生成待支付记录”，每个块就是一个独立场景的雏形。
• 打破“前置必须靠UI走出来”的误区：不要觉得拆完场景每个都要从头点页面效率低，所有非当前场景验证目标的前置流程，全部通过接口调用、数据库插入、测试工厂方法直接构造对应状态，封装成1句高层级的Given步骤就行。比如测退款的时候，不需要真的走注册、搜商品、加购、下单、支付全流程，一句给定当前登录用户存在1笔已支付的无线耳机订单，底层直接造数据，100毫秒就能完成前置准备，比走UI快几十倍，也不需要靠Background堆公共步骤。
• 严格按「1个Given铺前置、2-3个When做操作、1-2个Then做断言」的结构卡每个场景的步骤数，只要一个场景里出现超过2组独立的断言目标，直接拆，绝对不要在同一个场景里既验证加购成功、又验证下单成功、还验证退款成功，这三个是完全独立的业务行为。
• 长链路场景按业务里程碑拆，不要按页面拆。比如从注册到售后的全链路，里程碑节点就是账号注册成功、购物车加购成功、订单提交成功、支付完成、退款提交成功，每个节点对应一个场景，场景之间不依赖执行顺序，每个场景自己保证前置状态完备。

落地避坑经验 #

• 不要硬凑Background：Background只放当前特性文件下所有场景100%会用到的公共步骤，比如“启动测试站点”，只要有一个场景不需要某步前置，就不要往Background里塞，直接把步骤做成可复用的步骤定义，需要的场景单独调用即可。
• 不要追求100%全UI串测：那种从头点到尾的20+步场景，90%的失败原因是中间页面加载慢、网络波动、测试数据冲突，根本不是业务逻辑bug，维护成本极高。拆完之后只需要留1-2个核心冒烟场景走全UI链路，其他场景全部用接口/数据库造前置数据，执行速度和稳定性会提升一个量级。
• 步骤定义不要写死实现逻辑：同一个步骤文本可以根据测试标记切换执行方式，比如给定用户已登录这个步骤，冒烟测试时走UI输入账号密码，回归测试时直接注入登录Cookie，这个逻辑封装在步骤定义内部，写特性文件的人不需要感知底层实现。

实现示例 #

反面示例（23步超长场景，多目标混杂） #

场景: 用户从注册到完成退款全流程
  给定用户打开电商站点首页
  当用户点击注册按钮
  且用户输入手机号"13800138000"
  且用户输入验证码"123456"
  且用户设置密码"test1234"
  且用户点击提交注册按钮
  那么页面提示注册成功
  当用户搜索关键词"无线耳机"
  且用户点击第一个搜索结果进入商品详情
  且用户点击加入购物车按钮
  那么页面提示加购成功
  当用户进入购物车页面
  且用户选中刚加购的耳机商品
  且用户点击结算按钮
  且用户填写收货地址
  且用户选择微信支付
  且用户点击提交订单
  那么页面跳转到支付成功页
  当用户进入订单详情页
  且用户点击申请退款按钮
  且用户选择退款原因"不想要了"
  且用户提交退款申请
  那么页面提示退款申请已提交

拆分后正确示例（单场景4-5步，独立可运行） #

场景: 新用户可通过手机号完成注册
  给定注册页面已正常打开
  当用户提交手机号"13800138000"、验证码"123456"、密码"test1234"完成注册
  那么页面提示注册成功
  且用户账号自动处于登录状态

场景: 登录用户可将在售商品加入购物车
  给定存在一个已登录的正常测试账号
  且商品库存在售的"无线耳机"商品信息正常
  当用户将"无线耳机"商品加入购物车
  那么用户购物车中存在1件"无线耳机"商品

场景: 用户可对购物车选中商品提交有效订单
  给定当前登录用户的购物车中有1件选中状态的在售"无线耳机"商品
  当用户填写默认收货地址、选择微信支付渠道提交订单
  那么系统生成1笔对应商品的待支付订单

场景: 用户可完成待支付订单的付款流程
  给定当前登录用户存在1笔金额99元的"无线耳机"待支付订单
  当用户通过微信支付完成该订单付款
  那么订单状态更新为已支付
  且页面展示支付成功提示

场景: 用户可对已支付订单提交退款申请
  给定当前登录用户存在1笔已支付的"无线耳机"有效订单
  当用户选择"不想要了"作为退款原因提交申请
  那么订单状态更新为退款审核中
  且页面提示退款申请提交成功

拆分后的场景除注册场景外，其余Given步骤均通过底层测试工具直接构造对应业务状态，不需要重复执行前置UI操作，单场景执行耗时从原来的几十秒降到1秒内，失败时可直接定位到具体业务环节，不需要翻长日志排查失败点。

内容的提问来源于stack exchange，提问作者Kirill MIlititskiy