现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行，从而大程度上覆盖用户需求。这是我们通常所说的基于场景的测试方法。

　　说到这里，大家可能会比较关注场景测试适用于什么样的项目呢?个人认为对于业务流程或事件比较复杂的程序，主要用来探索对于比较有经验的用户是怎么来使用软件的，并查找出更加有说服力的bug。不同的触发顺序和处理结果形成事务流，通过设计足够多的测试用例来覆盖基本流和各种备选流。流程性比较强，显然一个一个模块测试是不明智的，他的模块之间需要有数据流的流动才能运转，这是可以采用场景法确定数据流的大致情况。有些软件有明确的但是复杂的各种输入(原因)，他们会导出许多复杂的输出，这个时候用因果图方法理清因、果之间的关系。但是光用这两个方法显然是不够的，针对每一个输入，有无数种情况，我们要用等价类的方法把无限测试变为有限测试。当然边界值、错误测试都是很有用也必要的测试案例的补充。对于一个软件，如果没有很明确的流程，也不需要使用因果图、场景法等方法，但是它依然需要等价类、边界值与错误输入等技术。对于这类软件我们可以分模块来进行功能的“扫菜单”方式组织案例的编写。

　　基本流是经过用例的简单的路径。备选流可能是从基本流开始，在特定条件下执行。备选流也可能会源于另一个备选流。备选流一般有两种去向：回到基本流或者异常中止。在用例场景作成时，有时候很难搞清楚哪些是基本流，哪些是备选流。基本流是那些完成某个操作需要经过的必须步骤，而备选流则是完成这些必须步骤中出现的一些可选操作。当业务流、场景都确定下来以后，一个业务的具体操作流程确定了，基于场景的测试主要集中在用户和系统之间的交互，主要用来检测业务需求的正确性，而不是代码本身的正确性。