面向对象实现.pptVIP

第12章 面向对象的实现 * * * * 9. 参数化类 在实际的应用程序中，常常看到这样一些软件元素(即函数、类等软件成分)，从它们的逻辑功能看，彼此是相同的，所不同的主要是处理的对象(数据)类型不同。例如，对于一个向量(一维数组)类来说，不论是整型向量，浮点型向量，还是其他任何类型的向量，针对它的数据元素所进行的基本操作都是相同的(例如，插入、删除、检索等)，当然，不同向量的数据元素的类型是不同的。如果程序语言提供一种能抽象出这类共性的机制，则对减少冗余和提高可重用性是大有好处的。 * * * * * * * * * * * * * * * * * 测试面向对象软件时，不能再孤立地测试单个操作，而应该把操作作为类的一部分来测试。例如，假设有一个类层次，操作X在超类中定义并被一组子类继承，每个子类都使用操作X，但是，X调用子类中定义的操作并处理子类的私有属性。由于在不同的子类中使用操作X的环境有微妙的差别，因此有必要在每个子类的语境中测试操作X。这就说明，当测试面向对象软件时，传统的单元测试方法是不适用的，不能再在“真空”中（即孤立地）测试单个操作。 * * * * * * * * 最小的可测试单元是单个封装起来的类和对象。 测试一个类就是测试它的对象子集(不可穷尽). 测试对象主要是测试它的操作. 不能孤立地测试单个操作: 同一个操作在不同状态下行为不同. 同一个操作在不同类中有不同的实现(多态性). 有必要在每个子类的语境中测试操作 比面向过程更复杂 12.3.1 面向对象的单元测试 * 集成=组装有关联的类 不存在层次的控制结构(隐含在类中) 传统的自顶向下/自底向上的集成策略无意义。 12.3.2 面向对象的集成测试 * 面向对象软件的集成测试的两种策略: （1） 基于线程的测试（thread based testing): 把响应系统的一个输入或一个事件所需要的那些类(线程)集成起来。 （2） 基于使用的测试（use based testing): 首先测试独立类(几乎不使用其它类的类)，再测试使用独立类的下一个层次的类（称为依赖类）。据此依赖关系持续下去，直至把整个软件系统构造完为止。 集群测试（cluster testing）：用精心设计的测试用例检查一群相互协作的类（通过研究对象模型可以确定协作类），以发现不同的类之间的协作错误。 * 和传统的确认测试一样，面向对象软件的确认测试也集中检查用户可见的动作和用户可识别的输出。 从动态模型和描述系统行为的脚本可导出确认测试用例，以发现用户交互需求可能错误的情景。 黑盒测试方法也可用于设计上述确认测试用例。 12.3.3 面向对象的确认测试 * 与传统软件测试不同，面向对象测试关注设计适当的操作序列以检查类的状态。 （1）传统方法的可用性 白盒测试：用于类级别的测试。测试类中封装的操作，检查类的状态以确定是否存在错误。 黑盒测试：用于集成测试、确认测试。 12.4 设计测试用例 * 着重测试单个类和类中封装的方法主要有：随机测试、划分测试和基于故障的测试等3种。 12.4.1 测试类（单元）的方法 * 1. 随机测试 随机选取测试类操作序列以测试该类对象不同的生命历史 问题的性质隐含了一些限制 例：银行应用系统的account(账户）类有下列操作： open(打开），setup(建立），deposit(存款），withdraw(取款），balance(余额），summarize(清单），creditLimit(透支限额）和close(关闭）。 限制：必须在其他操作前打开账户，完成了全部操作之后才能(/必须)关闭账户。 * 一个account类实例的最小(正常)行为历史包含下列操作： open·setup·deposit.withdraw·close 可能发生许多其他行为： Open·setup·deposit· [deposit|withdraw|balance|summarize|creditLimit]n.withdraw·close 从上列序列可以随机地产生一系列不同的操作序列： #r1:open·setup·deposit·deposit·balance·summarize.withdraw·close #r2:open·setup·deposit·creditLimit·withdraw·close 也要考虑异常（用户或编程)序列： open·setup·.withdraw·close setup·deposit.withdraw·close * 2. 划分测试 划分测试（partition testing）可以减少测试用例的数量。 3种划分：状态，属性，功能。 （1） 基于状态的划