在软件测试中,我们经常会遇到各种复杂的业务流系统,比如电商订单、客服工单、审批流程等。这些系统都有一个共同特点:它们都有明确的状态,并且会在特定条件下在不同状态之间流转。
面对这样的系统,如何设计出覆盖全面、高效有效的测试用例呢?今天我们就来介绍两种利器:状态迁移法和场景法。
什么是状态迁移测试法?
状态迁移测试法是一种基于系统状态变化的测试方法,特别适用于有状态流转的系统。它的核心思想是:系统的行为取决于当前状态和触发事件。
状态迁移图基本元素
- 
状态(State):系统在特定时间点的状况 
- 
迁移(Transition):从一个状态到另一个状态的转变 
- 
事件(Event):触发状态迁移的条件或动作 
- 
动作(Action):状态迁移时执行的操作 
一个简单的状态迁移图示例

这个简单的状态迁移图描述了两个状态(锁定和解锁)以及它们之间的迁移条件。
状态迁移法在订单系统中的应用
让我们看一个更实际的例子:电商订单系统。
订单状态迁移图

状态迁移表

基于状态迁移的测试设计
使用状态迁移法,我们可以系统地设计测试用例:
- 
覆盖所有状态:确保测试到系统的每一个状态 
- 
覆盖所有迁移:测试每一个状态之间的迁移路径 
- 
测试无效迁移:尝试在错误的状态下触发事件 
- 
测试边界条件:关注状态迁移的边界情况 
这种方法确保了我们对订单系统的每一个状态和每一次状态变化都进行了测试,大大提高了测试覆盖率。
什么是场景法?
场景法(也称流程图法)是一种从用户视角出发的测试方法,通过描述用户使用系统的完整路径来设计测试用例。它关注的是用户为了完成某个目标而执行的一系列操作。
场景法的核心要素
- 
基本流:用户最直接、最顺利达成目标的路径 
- 
备选流:用户在达成目标过程中可能遇到的各种分支路径 
- 
异常流:用户操作出错或系统异常时的处理路径 
场景法在测试中的应用
场景法的优势
- 
用户视角:从用户如何使用系统的角度设计测试,更贴近实际使用情况 
- 
端到端覆盖:覆盖用户完整的操作路径,而不是孤立的单个功能 
- 
业务逻辑覆盖:能够更好地覆盖复杂的业务逻辑和交互 
- 
易于理解:测试场景就像用户故事,容易被项目成员理解 
场景设计步骤
- 
理解业务需求和用户目标 
- 
识别主要用户和他们的目标 
- 
为每个目标设计基本流 
- 
识别并设计备选流和异常流 
- 
将场景转化为具体的测试用例 
实战:电商下单流程测试场景设计
现在,让我们结合状态迁移法和场景法,为一个典型的电商下单流程设计测试场景。
电商下单业务流程分析
典型的电商下单流程包括以下步骤:
- 
用户浏览商品 
- 
用户添加商品到购物车 
- 
用户进入结算页 
- 
用户选择收货地址 
- 
用户选择支付方式 
- 
用户提交订单 
- 
用户支付订单 
- 
商家发货 
- 
用户确认收货 
- 
订单完成 
状态迁移图设计
首先,我们为电商订单系统设计一个详细的状态迁移图:

主页测试场景设计
场景1:正常下单流程(基本流)
场景描述:用户顺利下单并完成收货的全过程
步骤:
- 
用户添加商品到购物车 
- 
用户进入结算页面,确认订单信息 
- 
用户选择收货地址和支付方式 
- 
用户提交订单,进入待支付状态 
- 
用户支付成功,订单状态变为已支付 
- 
商家发货,订单状态变为已发货 
- 
用户确认收货,订单状态变为已完成 
测试点:
- 
每个步骤的界面显示是否正确 
- 
每个状态转换是否正确 
- 
库存扣减和恢复是否正确 
- 
通知消息是否及时发送 
- 
订单日志是否完整记录 
场景2:支付后取消订单(备选流)
场景描述:用户支付成功后申请退款
步骤:
- 
用户完成支付,订单状态为已支付 
- 
用户申请退款,订单状态变为退款中 
- 
商家审核通过,执行退款 
- 
退款成功,订单状态变为已取消 
测试点:
- 
退款申请流程是否顺畅 
- 
退款金额是否正确计算 
- 
支付渠道退款是否正确触发 
- 
库存是否正确恢复 
- 
用户通知是否及时 
场景3:退货流程(备选流)
场景描述:用户收到商品后申请退货
步骤:
- 
用户确认收货前申请退货,订单状态变为退货中 
- 
商家审核退货申请 
- 
用户寄回商品 
- 
商家确认收到退货 
- 
退款执行,订单状态变为已退货 
测试点:
- 
退货申请条件判断是否正确(如是否在允许退货期内) 
- 
退货物流信息跟踪是否正确 
- 
退款金额计算是否正确(考虑部分退货情况) 
- 
商品入库流程是否正确 
场景4:支付异常处理(异常流)
场景描述:用户支付过程中遇到问题
步骤:
- 
用户提交订单,进入待支付状态 
- 
用户支付时银行卡余额不足,支付失败 
- 
系统提示支付失败,订单仍处于待支付状态 
- 
用户更换支付方式,重新支付成功 
测试点:
- 
支付失败的错误信息是否清晰 
- 
订单状态在支付失败后是否正确保持 
- 
是否允许更换支付方式重新支付 
- 
支付记录是否正确记录失败和成功记录 
场景5:超时处理(异常流)
场景描述:订单在各个环节的超时处理
步骤:
- 
用户提交订单但未支付,等待超时 
- 
系统自动取消订单,状态变为已取消 
- 
用户已支付,商家超时未发货 
- 
系统提醒商家尽快发货 
- 
商家发货,用户超时未确认收货 
- 
系统自动确认收货,订单状态变为已完成 
测试点:
- 
各种超时时间配置是否正确生效 
- 
超时后的自动处理是否正确执行 
- 
超时前的提醒通知是否正确发送 
- 
超时后的状态转换是否正确 
测试用例设计技巧
1. 基于场景矩阵设计用例
我们可以创建一个场景矩阵,确保覆盖所有重要的场景组合:

2. 使用场景模板
为每个测试场景创建一个标准模板,确保覆盖所有重要信息:
场景模板:
- 
场景ID和名称 
- 
场景描述 
- 
前置条件 
- 
测试步骤 
- 
预期结果 
- 
测试数据要求 
- 
优先级 
- 
关联的需求或用户故事 
3. 结合边界值分析
在每个场景中,结合边界值分析方法设计更细致的测试用例:
- 
商品数量边界:0、1、正常数量、库存上限、超过库存 
- 
金额边界:0元订单、小额订单、大额订单、金额上限 
- 
时间边界:超时临界点、活动时间边界 
状态迁移法与场景法的结合使用
状态迁移法和场景法并不是相互排斥的,而是可以很好地结合使用:
结合使用的优势
- 
全面覆盖:状态迁移法确保状态转换覆盖全面,场景法确保用户路径覆盖全面 
- 
深度与广度:状态迁移法提供测试深度,场景法提供测试广度 
- 
不同视角:状态迁移法从系统视角设计测试,场景法从用户视角设计测试 
结合使用的实践方法
- 
先状态,后场景:先使用状态迁移法分析系统的所有状态和迁移,然后基于这些状态设计用户场景 
- 
状态验证融入场景:在场景测试中,验证每个步骤后的系统状态是否正确 
- 
异常场景补充:基于状态迁移图中的无效迁移设计异常场景 
实际工作流程
- 
分析需求,绘制状态迁移图 
- 
基于状态迁移图,设计状态迁移测试用例 
- 
分析用户操作,绘制业务流程图 
- 
基于业务流程图,设计场景测试用例 
- 
合并和优化测试用例,去除重复 
- 
确定测试用例优先级,制定测试计划 
总结
状态迁移法和场景法是测试复杂业务流系统的两种重要方法。状态迁移法关注系统的状态变化,确保每个状态和迁移都被充分测试;场景法关注用户的完整操作路径,确保测试贴近用户实际使用情况。
在实际项目中,我们可以根据系统特点灵活运用这两种方法:
- 
对于状态流转复杂的系统(如订单、工单、审批流),可以以状态迁移法为主,场景法为辅 
- 
对于用户操作路径复杂的系统(如电商购物、银行转账),可以以场景法为主,状态迁移法为辅 
- 
对于复杂系统,最佳实践是结合使用两种方法,从不同视角设计测试用例 
通过合理运用这两种方法,我们能够设计出覆盖全面、高效有效的测试用例,大大提高软件质量和测试效率。
希望本文能帮助你更好地理解状态迁移法和场景法,并在实际工作中灵活运用。如果你有任何问题或想法,欢迎在评论区留言交流!
本文原创于【程序员二黑】公众号,转载请注明出处!
欢迎大家关注笔者的公众号:程序员二黑,专注于软件测试干活分享,全套测试资源可免费分享!
最后如果你想学习软件测试,欢迎加入笔者的交流群:785128166,里面会有很多资源和大佬答疑解惑,我们一起交流一起学习!
