场景测试学习与探索
我们的现实生活是由一幅幅生动的场景画面所组合而成的。对于一个电影导演来说，要想获得一个高票房的收入，在拍摄的过程中必须事先精心设计好画面中的每一个场景，否则观众是不会来买单的，同样测试的工作也不例外，交付用户使用的系统要想获得用户的认可，必须站在用户的角度，以用户的使用逻辑及操作习惯为出发点，结合功能用例的设计方法，使用例设计更贴近实际，从而最大程度上满足用户的需求。举一个生活中常见的例子，来感受一下常用的测试设计方法与场景测试之间的关系：测试一个创建贺卡的功能，对比两个不同视角的结果。从功能测试的角度出发，要测试的功能点大致为： 1.为卡片添加文本信息 2.为卡片添加图片 3.从卡片库中获取草图 4.发送卡片： 1) 通过email发送 2) 打印卡片；添加文本、图片，从库中加载卡，以及发送卡片这些可以通过我们常用的等价类，边界值等手段进行测试，而站在用户使用的角度出发则会更偏重于： 1.发送生日贺卡 2.发送周年纪念卡 3.发送聚会请帖 4.从一张空白卡片开始制作贺卡，并通过前面提供的这一堆功能创建一张自己需要的卡片。这就是场景测试的一个缩影，场景其实就是对每一个活动进行再细化描述活动执行的过程。
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行，从而最大程度上覆盖用户需求。这就是我们通常所说的基于场景的测试方法。
说到这里，大家可能会比较关注场景测试适用于什么样的项目呢？个人认为对于业务流程或事件比较复杂的程序，主要用来探索对于比较有经验的用户是怎么来使用软件的，并查找出更加有说服力的bug。不同的触发顺序和处理结果形成事务流，通过设计足够多的测试用例来覆盖基本流和各种备选流。流程性比较强，显然一个一个模块测试是不明智的，他的模块之间需要有数据流的流动才能运转，这是可以采用场景法确定数据流的大致情况。有些软件有明确的但是复杂的各种输入（原因），他们会导出许多复杂的输出，这个时候用因果图方法理清因、果之间的关系。但是光用这两个方法显然是不够的，针对每一个输入，有无数种情况，我们要用等价类的方法把无限测试变为有限测试。当然边界值、错误测试都是很有用也必要的测试案例的补充。对于一个软件，如果没有很明确的流程，也不需要使用因果图、场景法等方法，但是它依然需要等价类、边界值与错误输入等技术。对于这类软件我们可以分模块来进行功能的“扫菜单”方式组织案例的编写。
谈到场景测试，首先要知道什么是场景？场景是从用户的角度来描述系统的运行行为,反映系统的期望运行方式,是由一系列的相关活动组成的, 它就像一个剧本，是演绎系统未来预期的使用过程。场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互，之后的功能需求说明，则是用户需求分解的结果，定义了必须实现的软件功能。场景描述是一个迭代细化的过程，一般以故事叙述的方式描述如何帮助用户解决问题，辅以系统的交互草图。场景需要有清晰、明确的上下文环境，说明这个场景发生在什么背景下，何时会发生，从用户的角度出发，描述用户做什么，与系统的交互行为，以及用户对出现问题的反应。设置场景的目的是让所有人员明白用户的目标是什么，以及用户希望怎样做，不涉及具体的界面展现是怎样的，也不关注具体的实现方式是怎样的。
场景来源于哪里？场景是use case的一个实例，一个简单的场景是通过一个use case，并定义一些相关的数据以及覆盖这个case所流经的路径，数据通过输入,输出,以及一些中间状态与具体的场景相关联。一个复杂的场景包含对多个use case的组合，通过控制场景或子场景的执行顺序、条件控制、并行或反复处理来组合而成的,表明多个功能之间的信息流是如何进行运作的。 场景需要定义actors, roles, business processes, events以及the goal(s) of the actor(s) 。
什么是基于场景的测试方法呢？说白了就是在场景的基础上进行的测试，通过执行测试场景或与需求以及系统可操作的流程相关的测试用例来验证系统的功能。一个场景测试用例仅测试一个场景、事务或业务流程。基于场景技术的软件测试,首先需要完成对被测试系统进行分析建模,通过分析需求规格说明书,获得系统级的输入/输出变量,然后模拟用户的各种使用场景，基于该使用场景对测试对象进行测试。
基本流是经过用例的最简单的路径。备选流可能是从基本流开始，在特定条件下执行。备选流也可能会源于另一个备选流。备选流一般有两种去向：回到基本流或者异常中止。在用例场景作成时，有时候很难搞清楚哪些是基本流，哪些是备选流。基本流就是那些完成某个操作需要经过的必须步骤，而备选流则是完成这些必须步骤中出现的一些可选操作。当业务流、场景都确定下来以后，一个业务的具体操作流程就确定了，基于场景的测试主要集中在用户和系统之间的交互,主要用来检测业务需求的正确性,而不是代码本身的正确性。
Cem Kaner, Florida Tech, 《An Introduction to Scenario Testing》
Using Dependency Charts to Improve Scenario-Based Testing
Management of Inter-Scenario Relationships:Depicting and Managing Dependencies between Scenarios
Scenario Test Pack：A Summary of the Testing Scenarios Produced by the Retail Market Testing Team 确实，对于流程清晰的测试实体，场景或流程法都是相当好用的。:)
不过我想加一点
场景法虽然易于执行人员理解，可是对于稍大一些的测试实体，设计过程会相当复杂。在设计难度上要高于功能点法。
比如，就以发送贺卡的“制卡”这个场景来说，它除基本流外“白卡制卡”外，还有很多支线流，如：转发卡、套用模板卡、超长卡（大到必须要分割传输的卡）、纯文字卡、混合卡（文字和图片）、空白卡等等。要是所有场景都这样设计，可以想象，整个流程图画出来是不是有点“花”呢？
其实很容易看出，在场景法搭建出基本流后，支线流的测试其实和功能点法是基本一致的，也是一些基本的测试设计方法。
所以，只使用场景法使用基本流搭建框架，然后根据实际情况选择其他的设计方法才是个比较省力的法子。 恩，2位说都都挺对的
页:
[1]
