1 引言
前几篇文章主要针对单点功能的测试用例设计方法展开介绍。然而,当拿到一个测试任务时,并非先关注某个功能的细节测试,而是先要使用场景法对主要业务流程和主要功能展开测试,当业务场景没有问题后,再使用等价类、边界值、判定表等方法对细节功能进行测试(先整体后细节)。
2 概念及原理
2.1 场景法概念
场景法是一种通过使用事件触发流程,对系统的功能点或业务流程进行描述的方法。对于同一事件不同的触发顺序和处理结果, 可以形成不同的场景。
在日常工作中,针对同一业务需求可以模拟出不同场景,测试用例中对所有功能点及业务流程的覆盖,有利于测试人员设计测试用例,从而提高测试效果,使测试用例更容易理解和执行。
2.2 场景法设计层面
- 业务层面:需熟悉需求业务逻辑,并针对当前需求进行发散性思考。
- 技术层面:需分析出基本流和备选流,通过遍历所有基本流和备选流,可以覆盖完整的业务场景。
- 基本流:模拟用户正确的业务操作流程
- 备选流:模拟用户错误的业务操作流程
2.3 场景法原理介绍
1)场景业务流组成
场景法一般包含基本流和备选流两种业务流。
上图中,经过用例的每条路径都可以使用基本流和备选流表示。其中,绿色主线代表基本流,是经过用例的最简单的路径,一个业务场景只存在一条基本流,基本流仅有一个起点和一个终点。
备选流表示流程存在反复,但经过纠正后依然能达到目标的流程。备选流包含假设、异常操作等多种情况。上图中,备选流1和备选流3均始于基本流,在特定条件下执行后,重新加入基本流;备选流2和备选流4均从其余备选流出发,终止场景而不加入基本流中。
2)场景组合
按上图可组合多个不同的场景:
3)备选流覆盖准则
- 覆盖每个备选流
- 覆盖一个循环
4)如何识别基本流与备选流?
- 基本流只有一个起点和一个终点;
- 基本流是主流,备选流是支流;
- 备选流可始于基本流,也可始于其他备选流;
- 备选流可回到基本流,也可是其他备选流的起点。
3 方法步骤
- 根据需求文档,梳理业务的流程图;
- 分析主干业务正常执行的流程——基本流;
- 分析出分支流程——备选流;
- 组合基本流、备选流,确定基本场景;
- 对每一个场景生成相应的测试用例;
- 对每一个测试用例确定测试数据值。
4 举个栗子
以销售提交报价单审批的流程为例:
销售提交多产品组合报价单至OA审批。业务场景如下:
销售提交多产品组合报价—>一级审批通过—>二级审批通过—>结束
1)业务场景梳理
2)确定基本流:
销售提交多产品组合报价至OA审批—>一级审批通过—>二级审批通过—>结束
3)确定备选流
- 备选流1:销售提交多产品组合报价单至OA审批,销售撤回报价单;
- 备选流2:一级审批人审批驳回;
- 备选流3:一级审批人加签至加签人A,A审批通过;
- 备选流4:一级审批人加签至加签人A,A审批驳回;
- 备选流5:二级审批人审批驳回;
- 备选流6:二级审批人加签至加签人B,B审批通过;
- 备选流7:二级审批人加签至加签人B,B审批驳回。
4)组合基本流、备选流,确定基本场景
5)对每一个场景生成相应的测试用例
本例中,对于每个测试用例,存在一个测试用例ID、基本场景、测试用例中涉及的所有元素以及预期结果。
通过从确定执行用例场景所需的元素入手构建矩阵;然后针对每个场景,确定包含执行场景所需条件的测试用例。在如下矩阵中,V(有效)表明这个条件必须是有效的;I(无效)表明这种条件下将激活所需备选流;N/A表明这个条件不适用于测试用例。
6)对每一个测试用例确定测试数据值
5 总结
场景法 | |
---|---|
适用场景 | 业务流程较清晰的软件系统或功能模块 |
优点 | 涉及到业务流程的需求可使用场景法 |
缺点 | 只能验证业务流程,不能验证单点功能。一般先采用等价类划分、边界值分析、错误推断法、判定表等方法对单点功能进行验证,验证通过后再采用场景法进行业务流程的验证。 |
注意事项 | (1)主题清晰:了解场景用例需测试的功能,确保测试场景在用户使用过程中会出现; (2)逻辑无误:确保基本功能结合起来无bug; (3)步骤简洁:测试用例的步骤描述需简洁明了,无歧义; (4)场景唯一:确保不同用例可覆盖不同的测试点。 |
通过本文讲解的场景法,可以对业务流程较为复杂的需求进行用例设计。然而,该方法并不能涵盖一个需求的全部测试点,对于细节功能、业务中的非常规操作等,还需要借助其他测试用例设计方法。如何尽可能多地覆盖业务功能,设计出完美的测试方案?下一篇文章将为您展开详细介绍~
作者:京东物流 李硕
来源:京东物流 自猿其说Tech 转载请注明来源
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。