测试是一种思想，短视者把工具当目的，远视者把工具当手段.....
　　软件设计
　　1）单个用户操作 -> 触发单个事件 -> 事件处理
　　2）按顺序执行多个用户操作 -> 按顺序触发多个事件，形成事件流
　　注：通常事件是操作触发的，和操作往往是一一对应的关系，所以，这里为了便于理解，暂且把“操作”名称，称为事件名。
　　举例：在windows画图榜中画线为例

　　这里简单说，触发了三个事件：鼠标左键按下，鼠标左键弹起，鼠标移动。
　　事件处理：
　　鼠标左键按下时，用两个不同名称的变量保存鼠标的点击点，作为直线的起点和终点；
　　鼠标移动时，不断用新的鼠标点代替线条中线条终点，并擦除之前画的线条；
　　鼠标左键弹起时，保存后一个点作为直线终点，并画线。
　　当然，我们可以稍微宏光的把多个“较小”的用户操作整合为一个“较大”的用户操作，比如上述的三个操作（按下鼠标左键，移动鼠标，松开鼠标左键），可以整合为一个操作--“画线”。
　　借鉴软件设计的思想，引进“按场景设计用例”的思想

　　基本流用黑色表示，是经过用例的简单的路径。
　　备注：个人理解，这个称为“主要”的路径会比较合适，具体理由见下文说明
　　备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流 1 和 3）；也可能起源于另一个备选流（如备选流 2），或者终止用例而不再重新加入到某个流（如备选流 2 和 4）
　　什么叫场景
　　通俗的将，场景为用户活动和活动环境的结合。
　　其中，用户活动通常是由一系列操作组成，活动环境则通常是操作时的软、硬件环境。
　　-> 按场景来设计用例，其实是设计不同系列的操作，按顺序去触发每个系列的操作，查看其结果是否和预期保持一直。
　　问题来了，那么多用户操作，每个系列的操作要怎么安排？？
　　设计思想：
　　产品是给用户使用的 -> 用户是怎么使用产品的？ -> 操作产品：
　　1）如果顺利完成操作，产品功能好
　　2）如果不能完成操作，产品功能差
　　-> 测试人员要模拟用户操作 -> 用户怎么操作的？：
　　1）用户会按模拟的那样，操作产品(不管是有意还是无意)，测试投入有价值
　　2）用户永远不会那么操作，测试投入约等于无价值。
　　-> 按优先级模拟操作：优先模拟用户有可能的系列操作，即用户场景，然后模拟次可能的场景操作。
　　注意：不管是不是按场景设计用例，这也是作为用例优先级安排的一条基本的原则。
　　看完了似乎还是没解决怎么安排的问题，对吧
　　烦先看文章“细说软件产品和业务 & 业务过程(流程) & 业务逻辑”
　　看完了文章，可以容易得出
　　1）业务逻辑之业务过程是用户有可能执行的场景操作 -- 应设计为 基本流
　　2）业务逻辑之业务规则是用户次有可能执行的场景操作 -- 应设计为 被选流
　　注：以上这种对应关系仅是大致思想，基本是那样，并不。