《软件测试理论和方法(全面推荐)》.ppt

白盒测试方法 要核实单元的内部结构，应采用白盒测试方法。理论上，您应当测试代码中每一可能的路径，但这只有在非常简单的单元中才可能做到。作为一种最低限度，您应当对每个决定到决定路径（DD 路径）测试至少一次，因为这样您可以将所有语句至少执行一次。决定通常是 if 语句，而 DD 路径是两个决定之间的路径。 要达到这种程度的测试覆盖率，在选择测试数据时应该使每个决定都可以用每种可能的方法来评估。 可使用代码覆盖率工具来确定白盒测试没有执行到的代码。在进行白盒测试的同时应进行可靠性测试。 黑盒测试 黑盒测试的目的是在不知道单元将如何实施功能和行为的情况下，核实单元的指定功能和可观测行为。黑盒测试侧重并依赖于单元的输入和输出。 当基于黑盒方法进行单元测试时，将利用单元操作的输入输出参数和/或输出状态来进行评估。例如，单元的操作可能包括某个算法（需要两个值作为输入并返回第三个值作为输出），或者可能会引起对象或构件的状态变化（例如，添加或删除数据库记录）。对两种情况都必须进行全面的测试。要对一项操作进行测试，应生成足够数量的测试用例来核实以下内容： 对于每个用作输入的有效值，该操作是否返回了一个相应值 对于每个无效输入值，操作只返回一个相应值 对于每个有效的输入状态，是否出现了一个相应的输出状态 对于每个无效的输入状态，是否出现了一个相应的输出状态 可使用代码覆盖率工具来确定白盒测试没有执行到的代码。在进行黑盒测试的同时应进行可靠性测试。 如何测试被继承的操作 如果被继承的操作在后代中不起作用，这就属于后代和祖先之间的交互问题。您可以在测试用例时核实单元之间的交互。但不要在测试单元时测试被继承的操作。被继承的操作应该在测试用例时进行测试。 在以下两种情况下，被继承的操作都可能会失败： 后代类修改了被继承的操作为其指定了特定值的实例（或成员）变量。 祖先中的操作调用了在后代中实施的操作。 要避免第一种情况，应禁止祖先通过被继承操作以外的操作来修改被继承的实例（或成员）变量。要避免第二种情况，应全面测试被调用的操作。 如何测试抽象类 如果一个类不会进行实例化，而只是为了让其他类继承而存在，就必须对其进行测试。这种测试到底具有什么意义，这可能并不明显。因为按照定义，抽象类没有实例，所以测试实例没有任何意义。但是，抽象类可以被继承，而且可以创建其后代的实例。因此，测试抽象类的目的之一是确定继承是否可能，以及是否有后代类的实例。它的第二个目的是确定对抽象类本身的可能调用（C++ 中的 this、Smalltalk 中的 self）是否将会实现。要测试这一点，需要让测试程序创建一个继承该抽象类的后代类。测试程序将通过测试该后代类来对单元进行测试。 测试和多态性 多态性是一个编程语言方面的概念，它使代码更易于更改，但却使测试更加困难。在以下的示例中，您无法测试包含 Shape 类的每个子类的代码。当您测试用例时，必须测试这种情况。 在面向对象的语言中，多态性产生的一个有趣效果是：在 Smalltalk 中的每次消息发送以及在 C++ 中的每次功能调用都是一个潜在的 CASE 语句。 示例：假设您有以下类分层结构，并且类 Shape 具有操作 Draw。 测试模型 测试模型中表示的是测试对象和测试方式。它是设计和实施模型的视图，是由测试用例、测试过程和测试脚本以及它们之间的关系组成的集合。 测试模型是一种表示要在目标测试中测试的对象的模型（它可以是系统或系统的一部分）。它是设计和实施模型的视图，并且包含专门用于测试的测试用例、测试过程和测试脚本。测试模型的作用在于让我们了解测试对象和测试方法。 测试模型的使用 对于开发生命周期中的每次迭代，都会开发出测试模型的一个新版本。新版本应包括旧的测试（作为回归测试），以及用于新功能的新测试。 粗略地看起来，您会在测试模型中看到设计和/或实施模型以及反映测试用例的表示法。测试用例定义了输入、执行条件和预期输出的一个集合。多数测试用例来自用例场景或用例实现，而且在遍历测试目标时，测试用例与用例的执行过程相对应。如果测试目标是整个系统，则测试用例将对应于用例的完全执行过程。如果测试目标是一个子系统，则测试用例对应于遍历该子系统的那部分用例。 如果以 ATM 机为例，测试用例就是要核实顾客是否能够提取 100 美元，前提条件是：信用卡有效，并且所用帐户内有足够的金额。另一个用例测试是验证当用户的信用卡有效，但却输入了错误的 PIN，此时 ATM 软件是否还能按预期工作。 测试模型的使用 初期迭代中，可能还不存在任何完整的用例说明，仅仅是一些场景。因而，测试的第一次迭代中，只有用于验证提现能力的测试用例得以实施，还无法验证对错误 PIN 代码的处理能力。 最详尽的测试模型将描述为执行