主编：祁彩云、黄瑶
审核：汪腾霞
进度：未完成
场景法
概述及适用场景、相关术语解释（场景、基本流、备选流）
概述：从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。通过运用场景来对系统的功能点或业务流程进行描述，从而提高测试效果。
场景：由一系列相关活动组成，且场景中的活动还能由一系列场景组成。
基本流：是经过用例的最简单的路径，无任何差错，程序从开始直接执行到结束。
备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不再加入到基本流中。
场景法：解决业务流程清晰的系统或功能
在使用场景法设计测试用例时，需要覆盖系统用例中的主成功场景和扩展场景，并且需要适当补充正反面测试用例和考虑出异常场景的情形。
当使用场景法测试程序没有问题时，可以使用边界值、等价类方法对账号、密码进行更加细致、完整的测试。
为什么使用场景法？
现在的系统基本上都是由事件来触发控制流程的。如：我们申请一个项目，需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能来说，利用等价类划分、边界值分析、判定表等用例设计方法就能够解决大部分问题。而涉及业务流程的软件系统，采用场景法比较合适。
业务流组成、场景组合、覆盖原则及识别原则
（1）场景业务流组成：基本流 + 备选流
图中经过用例的每条路径都用基本流和备选流来表示，绿色主线表示基本流，是经过用例的最简单的路径，即无任何差错，程序从开始直接执行到结束的流程。通常，一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到目标的流程。备选流为除了基本流之外的各支流，包含多种不同情况，例如，一个备选流可始于基本流，于某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可始于另一备选流（如备选流2）；也可终止用例而不再加入到基本流中（如备选流2和4）。
（2）场景组合
按上图组合多个不同的场景：
- 场景1：基本流
- 场景2：基本流 备选流1
- 场景3：基本流 备选流1 备选流2
- 场景4：基本流 备选流3
- 场景5：基本流 备选流3 备选流1
- 场景6：基本流 备选流3 备选流1 备选流2
- 场景7：基本流 备选流4
- 场景8：基本流 备选流3 备选流4
（3）备选流覆盖准则
- 覆盖每个备选流；
- 覆盖一个循环；
- 这两种方法可以看情况选择，到这一步基本的测试用例就出来了，每个场景对应一个测试用例，对每个用例进行评审，删掉重复的。
（4）基本流和备选流的识别原则
- 基本流只有一个起点，一个终点；
- 基本流是主流，备选流是支流；
- 备选流可以始于基本流，也可以始于其它备选流；
- 备选流的终点，可以是一个流程的出口，也可以是回到基本流，还可以是汇入其它的备选流；
- 备选流汇合时，谁汇合到谁，取决于流量大小也即该流程出现的可能性大小，小的汇入大的；
- 如果在流程图中出现了两个不相上下的基本流，一般需要把它们分别当做一个业务看待。
场景分析法设计测试用例步骤
- 根据需求规格说明，描述出程序基本流和备选流
- 根据基本流和各项备选流生成不同的场景
- 对每一个场景生成相应的测试用例，可以采用矩阵或决策表来确定和管理测试用例
- 审核用例，去掉冗余或等价的测试用例，给用例确定测试数据值
适用场景
- 场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
- 使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
- 基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
- 场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
优缺点
- 优点：涉及到业务流程的适合用场景法
- 缺点：只验证业务流程，不验证单点功能。一般先采用等价类划分、边界值分析、错误推断法、判定表等方法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。
场景法应用的重难点
- 重点：场景法最主要的是能够分析出基本流和备选流。
- 难点：场景法测试的难点在于对业务的理解，业务越复杂测试难度越大。
使用场景法设计测试用例应该注意什么？
- 注意主题化，要明白这个场景用例是要测试什么功能，切忌将API中的测试点自己任意组合，想到哪里写到哪里；为了达到测试点的主题化，我们可以在写用例之前先构想出一个用户使用的场景故事，也就是保证这个场景在用户使用的过程中是会出现的。
- 注意上下文，场景用例本身就是模拟用户使用，测试基本功能（BVT）连接起来是否有bug，一定要具备用户使用时的逻辑性；
- 只测试简单的基本功能，而诸如密码的合法性，内存，带宽的越界这样的问题在场景中不需要出现，也就是场景中只出现主流程（密码错误属于副流程）；
- 步骤要简洁明了，没有歧义，数字要说明单位。写出来的测试用例要做到让别人一下子就可以看懂，没有歧义；
- 尽量不要使得不同的场景覆盖同样的测试点。
场景法和路径法的区别
从根本出发，所用的都是一个流程，但是场景法是从用户的角度去考虑这个功能是否存在缺陷，是在基本健壮的软件系统下，不同场景下进行测试。场景里面包含，由软件基本的设计流程而体现出来的场景，也包含用户根据“奇思妙想”、“天马行空的操作”下的场景，是对实际情况下的场景尽可能地覆盖。而路径法，是从设计者的角度去考虑软件问题，其流程都是根据用户需求且商量好的设计模式所产生的，只要满足流程测通即可。在测试的过程中我们可以根据场景法的方法进行测试，并以设计者的身份（路径法）测试软件，辅助以用户的角度考虑软件是否存在问题，这样更能保证软件的健壮性。