测试场景编写以及场景分析法

前言

大汉堡我进入公司的第59天了，最近在写测试场景写的头昏眼花，嗯~搬砖。这个项目情况比较特殊，一是时间比较赶来不及写用例；二是没有具体的需求文档，需要我手搓测试场景来进行测试，也就是使用场景测试法进行测试；三是项目比较大，之前完全没接触过此项目的业务。
EMMM~~

测试场景与测试用例的关系

测试场景

指对被测系统进行全面测试所需模拟的环境、情景和条件。
通俗点讲，测试场景就好比是给一个要接受检查的需求创造各种不同的情况和环境。比如说你要测试登录注册，测试场景可能包括使用账号密码登录，使用短信验证码登录、或使用第三方软件登录；也可能是在不同的设备上进行登录，如手机、平板、电脑等，检查跨设备登录的兼容性和一致性。总之，测试场景就是为了全面地测试这个被检查的系统，而特意模拟出来的各种各样的环境、情景和条件。

与测试用例的关系

测试场景是测试用例的背景和前提条件，测试用例是根据测试场景来编写的，是测试场景的具体实现。测试场景和测试用例不一定是一对一的关系，一个场景有可能需要多条用例，同理一条用例也有可能支撑测试多个场景。测试场景的变化可能会导致测试用例的编写和执行方式的变化，测试用例的改变也可能会影响测试场景的修改。

测试场景怎么写

测试场景编写的难易程度取决于业务的复杂度，包括业务所涉及的操作、交互以及决策情况，业务流程理解难易度等。
1.确定业务分析范围
从业务活动角度解释，业务场景涵盖了特定业务所涉及的各种操作、交互和决策过程。
以航班预定业务为例，业务分析范围包括了用户查询机票，机票低价日历，选择航班以及舱位，填写购票人信息，购买保险以及选择支付方式等操作和交互；决策情况包括是否使用优惠券或积分购买机票，是否购买保险或辅营产品等。
2.业务流程梳理
将需求说明转化为业务流程，完成事件流（基本流+备选流）的梳理。
同一事件不同的触发顺序和处理结果形成事件流，事件流分为基本流和备选流；基本流是程序从开始执行直到成功结束所经过的最短路径，备选流可能从基本流开始，在特定条件下执行，然后重新加入基本流中；也可起源于另一个备选流，执行后加入基本流或终止用例。
梳理步骤如下：

• 明确各个业务活动的先后顺序
• 识别每个业务活动的具体操作步骤
• 分析业务活动之间的关联和依赖关系
• 确定业务活动中的关键节点和决策点
  eg：
• 在航班预定业务场景中，存在机票查询，机票城市组件…到最后信息填写，辅营产品，生成订单支付业务流程，按照业务活动的先后顺序将他们排列好（可用xmind来写）；
• 再写出每个业务活动的基本流和备选流，也就是写出业务活动的具体操作步骤；
• 分析业务活之间的具体关系如信息填写与它依赖的业务有航班选择，舱位选择等，没有这些业务信息填写业务就没有前置条件；与它关联的业务有保险购买，辅营产品等，这些业务不是基本流中的，就是不是最短路径中的，当你购买机票时可以选择购买保险也可以选择不买；
• 最后就是确定业务活动的关键节点和决策点，这一步靠的是测试人员对业务的理解以及过往的经验(关于￥的最好处理为关键点和决策点)

3.场景串联
根据第二步中梳理出的场景利用组合以及合并的形式梳理出所有的事件流。

场景分析法

在面对时间紧任务重的情况时，场景分析法是解决问题的好方法之一。场景分析法是一种面向用户的测试用例设计方法。在场景法中，测试人员把自己当成最终用户，尽可能模拟用户的操作，通过场景法描述的业务流程，也包括代码实现逻辑设计用例来遍历场景。

• 优点：实用性强，有效，设计出来的用例有价值
• 缺点：设计出来的用例覆盖不完整

场景分析法模拟两类操作：

• 模拟用户正确操作的业务流程—— 验证软件功能是否能够正确实现（基本流+部分备选流）。
• 模拟用户错误操作的情景——验证软件的健壮性（备选流）。

这样做的目的是确保软件的功能要能够实现以及要有强大的异常处理能力。测试思路是先整体后细节。
需要注意的是场景法必须有基本流，必须有内容从用例的开始，到用例的结束。场景法的重点是测试流程，因此每个流程一个用例验证即可。流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试。场景法的难易程度在于业务复杂程度，业务越复杂则测试难度越大。

总结与建议

测试场景是为全面测试系统而模拟的各种环境与条件，而测试用例是基于这些场景设计的具体测试步骤。一个测试场景可以对应多个测试用例，反之亦然。编写测试场景涉及确定业务范围、梳理业务流程及串联场景，而场景分析法通过模拟用户操作来设计测试用例，确保软件功能和异常处理能力。场景法的难点在于业务复杂性，其优点是实用性强，但覆盖可能不完整。
遇到和我一样的情况时（需求不明确，没有需求文档）一定要先问清楚本次的测试或者回归范围。