| 和传统测试用例设计不同，传统测试是由软件的输入-加工-输出视图或个体模块的算法细节驱动的，面向对象测试关注于设计合适的操作序列以测试类的状态。
|
|
|
| Berard提出了一些测试用例的设计方法，主要原则包括：
|
|
|
| . 对每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。
|
|
|
|
|
| . 应当为每个测试用例开发一个测试步骤列表。这个列表应包含以下一些内容：
|
|
|
|
|
|
|
|
|
| ④列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。
|
|
|
|
|
|
|
| 如前所述，尽管OO软件的局域性、封装性、信息隐藏、继承性和对象的抽象这些特性使得测试用例设计带来了额外的麻烦和困难，但黑盒测试技术不仅适用于传统软件，也适用于OO软件测试，use cases可以为黑盒及基于状态的测试的设计提供有用的输入。白盒测试也用于OO软件类的操作定义，基本路径、循环测试或数据流技术，可以帮助保证已经测试了操作中的每一条语句。但OO软件中许多类的操作结构简学明了，所以有人认为在类层上测试可能要比传统软件中的白盒测试方便。
|
|
|
|
|
| 在OO软件中，基于故障的测试具有较高的发现可能故障的能力。由于系统以满足用户的需求为目的，因此，基于故障的测试要从分析模型开始，考察可能发生的故障。为了确定这些故障是否存在，可设计用例去执行设计或代码。
|
|
|
| 看一个简单的例子。软件开发人员经常忽略问题的边界，例如，当测试Divide操作（该操作对负数和零返回错误）时，我们考虑边界，“零本身”用于检查是否程序员犯了如下错误：
|
|
|
|
|
|
|
|
|
| 当然，这种方法的有效性依赖于测试人员如何感觉“似乎可能的故障”，如果OO系统中的真实故障被感觉为“难以置信的”，则本方法实质上不比任何随机测试技术好。但是，如果可以从分析和设计模型进行深入的检查，那么基于故障的测试则可以用相当低的工作量来发现大量的错误。
|
|
|
| 基于故障测试也可以用于集成测试，集成测试可以发现消息联系中“可能的故障”。
|
|
|
| “可能的故障”一般为意料之外的结果、错误地使用了操作/消息、不正确的引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。
|
|
|
| 这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的“属性”是由其赋予属性的值定义的。
|
|
|
| 应当指出，集成测试是从客户对象（主动），而不是从服务器对象（被动）上发现错误。正如传统的软件集成测试是把注意力集中在调用代码，而不是被调用代码一样，即发现客户对象中“可能的故障”。
|
|
|
|
|
|
|
| ①不正确的规格说明，如做了用户不需要的功能，也可能缺少了用户需要的功能。
|
|
|
| ②没有考虑子系统间的交互作用，如一个子系统（事件或数据流等）的建立，导致其他子系统的失败。
|
|
|
| 基于场景的测试主要关注用户需要做什么，而不是产品能做什么，即从用户任务（使用用例）中找出用户要做什么及如何去执行。
|
|
|
| 这种基于场景的测试有助于在一个单元测试情况下检查多重系统。所以基于场景测试用例的测试比基于故障测试的更实际（接近用户），而且更复杂一点。
|
|
|
|
|
|
|
| 背景：打印最终设计，并能从预览窗口上发现一些不易察觉的错误。
|
|
|
| 其执行事件序列：打印整个文件；对文件进行剪切、复制、粘贴、移动等修改操作；修改文件后，进行文件预览；进行多页预览。
|
|
|
| 显然，测试人员希望发现预览和编辑这两个软件功能是否能够相互依赖，否则就会产生错误。
|
|
|
|
|
| 如果一个类有多个操作（功能），这些操作（功能）序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。
|
|
|
| 例如，一个银行信用卡的应用，其中有一个类：账户（account）。该account的操作有open、setup、deposit、withdraw、balance、summarize、creditlimit和close。这些操作中的每一项都可用于计算，但open、close必须在其他计算的任何一个操作前后执行，即使open和close有这种限制，这些操作仍有多种排列，所以一个不同变化的操作序列可由于应用不同而随机产生。如一个account实例的最小行为转换期可包括以下操作：
|
|
|
|
|
| 这表示了对account的最小测试序列。然而，在下面序列中可能发生大量的其他行为：open+setup+deposit+［deposit|withdraw|balance|summarize|creditLimit］+withdraw+close
|
|
|
|
|
| 测试用例1：open+setup+deposit+deposit+balance+summarize+withdraw+close
|
|
|
| 测试用例2：open+setup+deposit+withdraw+deposit+balance+creditLimit+withdraw+close
|
|
|
| 可以执行这些测试和其他的随机顺序测试，以测试不同的类实例生命历史。
|
|
|
|
|
| 这种测试可以减少用完全相同的方式检查类测试用例的数目。这很像传统软件测试中的等价类划分测试。分割测试又可分为三种。
|
|
|
| . 基于状态的分割。按类操作是否改变类的状态来进行分割（归类）。这里仍用account类为例，改变状态的操作有deposit、withdraw，不改变状态的操作有balance、summarize、creditlimit。如果测试按检查类操作是否改变类状态来设计，则结果如下：
|
|
|
|
|
| open+setup+deposit+deposit+withdraw+withdraw+close
|
|
|
|
|
| open+setup+deposit+summarize+creditlimit+withdraw+close
|
|
|
| . 基于属性的分割。按类操作所用到的属性来分割（归类），如果仍以一个account类为例，其属性creditlimit能被分割为三种操作：用creditlimit的操作，修改creditlimit的操作，不用也不修改creditlimit的操作。这样，测试序列就可按每种分割来设计。
|
|
|
| . 基于类型的分割。按完成的功能分割（归类）。例如，在account类的操作中，可以分割为初始操作：open、setup；计算操作：deposit、withdraw；查询操作：balance、summarize、creditlimit；终止操作：close。
|
|
|
|
|
| 状态转换图（STD）可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的类的动态行为测试序列。
|
|
|
| 为了说明问题，仍使用前面讨论过的account类。开始由empty acct状态转换为setup acct状态。类实例的大多数行为发生在working acct状态中。而最后，取款和关闭分别使account类转换到non-working acct和dead acct状态。如下图所示为状态转换图（STD）。
|
|
|
|
|
|
|
| 这样，设计的测试用例应当是完成所有的状态转换。换句话说，操作序列应当能导致account类所有允许的状态进行转换。
|
|
|
| 测试用例1：open+setupAcct+deposit（initial）+withdraw（final）+close；
|
|
|
| 应该注意，该序列等同于一个最小测试序列，加入其他测试序列到最小序列中。
|
|
|
| 测试用例2：open+setupAccnt+deposit（initial）+deposit+balance+credit+withdraw（final）+ close；
|
|
|
| 测试用例3：open+setupAccnt+deposit（initial）+deposit+withdraw+accntInfo+withdraw（final）+close。
|
|
|
| 还可以导出更多的测试用例，以保证该类所有行为被充分检查，在类行为导致与一个或多个类协作的情况下，可使用多个STD去跟踪系统的行为流。
|
|
|
| 面向对象测试的整体目标——以最小的工作量发现最多的错误，和传统软件测试的目标是一致的，但是由于OO软件具有的特殊性质，在测试的策略和战术上有很大不同。测试的视角扩大到包括复审分析和设计模型，此外，测试的焦点从过程构件（模块）移向了类。
|
|
|
| ①OOA（Object-Oriented Analysis）和OOD（Object-Oriented Design）的评审与传统软件的分析和设计相同，应给出相应的评审检查表。
|
|
|
| ②OOP（Object-Oriented Programming）后，单元和组装测试策略必须作相应的改变。
|
|
|
|
|
