写这篇文章是想对之前一个帖子的内容进行补充，又不想把内容都混在一起，所以拎出来跟大家一起分享探讨下，有其他不同看法的欢迎补充沟通~
附上之前的链接先：https://testerhome.com/topics/25070

为什么要用场景法？
很多测试的同学，往往对于表单的填写，数据的搜索查看等功能测试，做得比较多，所以对于边界值、等价划分的用例设计方法都耍的很溜，但是随着业务的发展，特别是在 toB 业务的兴起，出现了很多庞大且复杂的业务系统，对于一些新同学挑战就变大了，往往不知道如何去梳理，导致用例覆盖面不全，实际上，我遇到过的测试工程师，3、4 年左右的，面对这样的系统，也有相同的情况，所以，今天给大家好好科普一种用例测试方法，叫场景法，并教大家如何实际的应用。

场景法是什么？ (以下内容引用于网络，做了一些简单的梳理)
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。

场景法一般包含：
1、基本流
2、备用流
从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

流程图构成：
1、直黑线表示基本流，是经过用例的最简单的路径。
2、备选流可以从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如基本流->备选流 1->备选流 3）；
3、备选流也可以起源于另一个备选流（如基本流->备选流 1->备选流 2）;
4、备选流也终止用例而不再重新加入到某个流（如备选流 1->备选流 2->结束 or 备选流 4->结束）;

----------------------------------------华丽分割线（以上是网络上对场景法的解释）-----------------------------------------

那场景法怎么用？

其实场景法很多人听过但是不会应用，不会应用的原因有 2：
1、不太清楚什么叫基本流，什么叫备选流，导致很难跟现实当中的场景对上；
2、对于场景法给出的流程图跟自己日常接触的流程图有点偏差，没有一个清晰的认识；

所以针对以上 2 个问题，在做场景法的分析之前，我们先 2 个名词做下定义，还有达成一个共识：
基本流：我们称之为，主干，指的是在整个流程里基本的业务流程；
备选流：我们称之为，分支，指的是在业务流程执行的过程中，异常情况的流程或加入的其他业务流程；

PS：讲到这里是不是觉得有点熟悉，测试里常常有句话是：等冒烟测试跑通了，再测其他的分支流程；

所以场景法的基本思路就是，以正常的业务流程为主干，梳理（上一篇文章提到的条理性就提现了）出执行的过程中，各个节点有可能产生或加入的所有的异常情况或其他的流程的分支，最终将其进行组合，产生不同的场景，进而输出用例（划重点）；

那场景法有什么起步，答案是：流程图；
场景法一定要基于流程图，千万不要指望自己脑补，脑补会降低测试覆盖面，而基于流程图出现测试覆盖面不全的情况，能归根于流程图梳理欠缺，这是一个系统化的测试方式；

场景法的步骤如下：
1、分析出主要的业务流程（主干）；
2、分析出异常情况的流程或加入的其他业务流程（分支）；
3、绘制业务流程图（通常此图可以由产品经理给出）；
4、将其做组合分析，得出组合项；
5、输出测试用例；

简单的例子：
拿商城的订单支付流程做一个例子（跟网上的一个图类似，但是这个确实是比较常用且比较贴切的例子）

回顾下之前所讲的（我们根据这个流程来转下转换）：
1、直黑线表示主干，是经过用例的最主要的路径。
2、分支可以从主干开始，在某个特定条件下执行，然后重新加入主干中（如主干->分支 1->主干->分支 2->主干）；
3、分支也可以起源于另一个分支（如分支 4->分支 5->结束）;
4、分支也终止用例而不再重新加入到某个流程（如分支 3->结束）;

用以上的图，相信大家对于场景法都比较清晰了，其中大家也不难发现，所谓的分支，一定是出现在判断的节点上，因为只要存在判断，即产生分支（下面再跟大家分析一个更加复杂的场景）；

我们继续往下走，以上的图：
主干：登陆系统->购买商品->登陆账号->查看预定订单详情->提交订单->付款->生成订单->结束
分支 1：账号注册
分支 2：密码异常
分支 3：库存异常
分支 4：支付异常
分支 5：方式跟换

场景组合如下：
1、购买商品时，登陆账号，账号不存在，进行注册（分支 1）;
2、购买商品时，登陆账号，账号存在，密码不正确（分支 2），登陆账号;
3、购买商品时，登陆账号，账号不存在，进行注册（分支 1），登陆账号，密码不正确（分支 2），登陆账号；
4、购买商品时，登陆账号，查看预定订单详情，提交订单，库存不足（分支 3），结束；
5、购买商品时，登陆账号，查看预定订单详情，提交订单，付款，支付失败，是否可以更换支付方式（分支 4），更换支付方式，付款；
6、购买商品时，登陆账号，查看预定订单详情，提交订单，付款，支付失败，是否可以更换支付方式（分支 4），无法更支付方式（分支 5），结束；

场景组合的时候，需要考虑多分支组合

输出测试用例：
用例就不多说了；大家尝试列一下吧；另外场景法并不是独立的用例编写方法；

希望本文对一些新手也好，一些从事多年的 QA 也好，有一些帮助，有这个想法，源于面试测试 leader 的时候，对于用例覆盖面的问题，很多测试的 leader 会把其归类为经验，这种 “经验” 上的认知，对于一个执行者是可行的，但是对于一个 leader 来说是不可行的。因为你要去领导一个团队，你必须要抽象出一些方法来引导他们，才能让能力参差不齐的小朋友通过一些方法的训练快速的提升。所谓的经验上的指导是碎片化的，是不太能传播的，以至于把经验抽象成一套方法论尤为重要（而这些方法论实际上也是源于最基础理论的知识），好了今天就到这，后续再更新其他的；