（4）从功能图生成测试用例的过程。
A、生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
B、测试路径生成：利用上面的规则（3种）生成从初始状态到最后状态的测试路径。 C、测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。 D、测试用例的合成算法：采用合成构造树。
用例设计之正交试验法
用例设计之场景设计
用例场景的定义
用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。提出这种测试思想的是Rational 公司，在RUP2000 中文版当中有其详尽的解释和应用，用例场景贯穿其中。 用例场景例子
下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 场景 1 基本流
场景 2 基本流备选流 1
场景 3 基本流备选流 1 备选流 2 场景 4 基本流备选流 3
场景 5 基本流备选流 3 备选流 1
场景 6 基本流备选流 3 备选流 1 备选流 2 场景 7 基本流备选流 4
场景 8 基本流备选流 3 备选流 4
注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。 测试用例
生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
测试用例例子
假定上图描述的用例对备选流 3 规定如下：
“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。”
据此，可以开始确定需要用来执行备选流 3 的测试用例： 测试用例 ID 场景条件预期结果
TC x 场景 4 步骤 2 - 提款金额>帐户余额在步骤 2 处重新加入基本流 TC y 场景 4 步骤 2 - 提款金额<帐户余额不执行备选流 3，执行基本流 TC z 场景 4 步骤 2 - 提款金额 = 帐户余额不执行备选流 3，执行基本流
注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单
较全的一个例子：
下图所示是ATM例子的流程示意图。
基本流：
1.
2. 3.
4.
5.
6.
7. 8. 9.
10.
备选流：
生成的场景：
注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。
用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
表3-9 测试用例表 TC（测试用例）ID号 CW1 CW2 输入（或的PIN 账号 选择）金额 V V V V V V ATM账面 内的金金额 额 V V V I 场景/条件 场景1：成功提款 场景2：ATM内没有现金 场景3：ATM内现金不足 场景4：PIN有误（还有不止一次输入机会） 场景4：PIN有误（还有一次输入机会） 场景4：PIN有误预期结果 成功提款 提款选项不可用，用例结束 警告消息，返回基本流步骤6，输入金额 警告消息，返回基本流步骤 4，输入 PIN 警告消息，返回基本流步骤 4，输入 PIN 警告消息，卡CW3 V V V V I CW4 I V n/a V V CW5 CW6 I I V V n/a n/a V V V V