三、测试用例设计 

    这种设计目前正处于形成阶段。

    传统软件测试用例设计是从软件的各个模块的算法细节得出的，而OO软件测试用例则着眼于适当的操作序列，以实现对类的说明。

    黑盒子测试不仅适用于传统软件，也适用OO软件测试。白盒子测试也用于OO软件类的操作定义。但OO软件中许多类的操作结构简明，所以有人认为在类层上测试可能要比传统软件中的白盒子测试方便。

    OO测试用例设计包含OO概念，在OO度量中所讲的五个特性:局域性、封装性、信息隐藏、继承性和对象的抽象，肯定会对用例设计带来额外的麻烦和困难。

    Berard提出了一些测试用例的设计方法，主要原则包括:
 
    （1）每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。

    （2）测试目的应当明确。

    （3）应当为每个测试用例开发一个测试步骤列表。这个列表应包含以下一些内容：

    列出所要测试对象的专门说明。
 
    列出将要作为测试结果运行的消息和操作。

    列出测试对象可能发生的例外情况。

    列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。

    列出为了帮助理解和实现测试所需要的附加信息。

    1．基于故障的测试

    在OO软件中，基于故障的测试具有较高的发现可能故障的能力。由于系统必须满足用户的需求，因此，基于故障的测试要从分析模型开始，考察可能发生的故障。为了确定这些故障是否存在，可设计用例去执行设计或代码。

    基于故障测试的关键取决于测试设计者如何理解“可能的错误”。而在实际中，要求设计者做到这点是不可能的。

    基于故障测试也可以用于组装测试，组装测试可以发现消息联系中“可能的故障”。

    “可能的故障”一般为意料之外的结果、错误地使用了操作/消息、不正确引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。

    这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的“属性”是由其赋予属性的值定义的。

    应当指出，组装测试是从客户对象（主动），而不是从服务器对象（被动）上发现错误。正如传统的软件组装测试是把注意点集中在调用代码而不是被调用代码一样，即发现客户对象中“可能的故障”。

    2．基于脚本的测试

    基于故障测试减少了两种主要类型的错误：

    （1）不正确的规格说明,如做了用户不需要的功能，也可能缺少了用户需要的功能。

    （2）子系统间的交互作用没有考虑，如一个子系统（事件或数据流等）的建立，导致其他子系统的失败。

    基于脚本的测试主要关注用户需要做什么，而不是产品能做什么，即从用户任务（使用用例）中找出用户要做什么及去执行。

    这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本测试用例测试比基于故障测试不仅更实际（接近用户），而且更复杂一点。

    例如：考察一个文本编辑的基于脚本测试的用例设计。

    使用用例：确定最终设计

    背景：打印最终设计，并能从屏幕图像上发现一些不易见到的且让人烦恼的错误。

    其执行事件序列：打印整个文件；移动文件，修改某些页；当某页被修改，就打印某页；有时要打印许多页。

    显然，测试者希望发现打印和编辑两个软件功能是否能够相互依赖，否则就会产生错误。

    3．OO类的随机测试

    如果一个类有多个操作（功能），这些操作（功能）序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。

    例如一个银行信用卡的应用，其中有一个类：计算（account）。该account的操作有：open、setup、deposit、withdraw、balance、summarize、creditlimit和close。

    这些操作中的每一项都可用于计算，但open、close必须在其他计算的任何一个操作前后执行，即使open和close有这种限制，这些操作仍有多种排列。所以一个不同变化的操作序列可由于应用不同而随机产生，如一个Account实例的最小行为生存史可包括以下操作：

    open+setup+deposit+[deposit|withdraw |balance|summarize|creditlimit]+withdraw+close

    从此可见，尽管这个操作序列是最小测试序列，但在这个序列内仍可以发生许多其他的行为。