软件测试用例优秀例子_【软件测试】场景法设计测试用例

【转载自：http://www.cydtest.com/?p=1042】

---

该篇文章我自己至少读了有5遍，写的非常好，对于软件测试的认知很有帮助，感谢作者能提供如此高质量的文章。

---

概念和定义

不完全、不彻底是软件测试的致命缺陷，任何程序只能进行少量而有限的测试。测试用例在此情况下产生，同时它也是软件测试系统化、工程化的产物。而测试用例的设计一直是软件测试工作的重点和难点，那么

什么是测试用例？

为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，称之为测试用例。

我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

怎样的用例算是好用例？

一个好的测试用例是在于它能发现至今未发现的错误。

使用测试用例的好处

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

设计测试用例的方法

黑盒测试：

• 等价类划分法
• 边界值分析法
• 错误推测法
• 因果图法

白盒测试：

• 逻辑覆盖法
• 基本路径测试法

测试用例的设计过程

测试设计员（分析设计员）依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。

测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员，则可用分析设计员代替。

针对白盒，还应有驱动程序和桩模块。

测试点的确定

ISO 质量体系：在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。

CMM 质量体系：在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。

理解上的误区

测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。

测试点应由分析设计员确立，与测试人员无关。

测试工作展开于项目立项后，而不是代码开发完成之后。

测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。

用例场景的定义

用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

为什么引入用例场景

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

提出这种测试思想的是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 的测试用例：

注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。

实用举例

下面是一个由用例生成测试用例的更符合实际情况的示例。

示例：

一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：

以从这个用例生成下列场景

注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。
对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 – 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 – PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 – 输入 PIN。

输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 – 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 – 不存在的帐户/帐户类型有误和场景 7 – 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

• 场景 6 – 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
• 场景 6 – 帐户不存在/帐户类型有误：禁止从该帐户中提款
• 场景 7 – 帐户余额不足：请求的金额超出帐面金额
• 在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
• 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
• 无法读卡（读卡机堵塞、脱机或出现故障）
• 帐户已消户、冻结或由于其他方面原因而无法使用
• ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）
• 无法联系银行系统以获得认可
• 银行网络离线或交易过程中断电