面向对象实现及测试(第九章)

第九章面向对象软件的实现与测试面向对象程序设计语言的优点程序设计风格如何对面向对象程序进行测试？面向对象的实现主要包括两项工作：（1）写面向对象程序；（2）测试并调试面向对象程序面向对象程序的质量基本上由面向对象设计的质量决定，但程序设计语言的特点和设计风格也将影响程序的可靠性、可重用性和可维护性软件测试是保证软件可靠性的主要措施§9.1程序设计语言9.1.1面向对象语言的优点（1）一致的表示方法（2）可重用性（3）可维护性9.1.2面向对象语言的技术特点（1）支持类与对象概念的机制（2）实现整体----部分结构的机制（3）实现一般----特殊结构的机制（4）实现属性和服务的机制（5）类型检查（6）类库（7）效率（8）持久保存对象（9）参数化类（10）开发环境9.1.3选择面向对象语言（1）将来是否占主导地位（2）可重用性（3）类库和开发环境（4）其他因素§9.2程序设计风格9.2.1提高可重用性（1）提高方法的内聚（2）减小方法的规模（3）保持方法的一致性（4）把策略与实现分开（5）全面覆盖（6）尽量不使用全局信息（7）利用继承机制

调用子过程分解因子使用委托把代码封装在类中9.2.1提高可扩充性（1）封装实现策略（2）不要用一个方法遍历多条关联链（3）避免使用多分支结构（4）精心确定公有方法9.2.1提高健壮性（1）预防用户的操作错误（2）检查参数的合法性（3）不要预先确定限制条件（4）先测试后优化组装(Composition)组装关系是一个实现级关系，它对应于应用级的聚合关系。它也叫做component（部件）或叫做ispartof（是…的一部分）。组装与消息两者都是类间的关系，在这种关系中，一个类的实例将是另一个类的实现的一部分。可以利用既存类来生成新类考虑Dictionary类的实现。在Dictionary中存储item的一种数据表示是使用散列表(HashTable)。进行Dictionary类的低层设计时，要指明在Dictionary类和HashTable类之间的一个ispartof关系。在实现时，应当在Dictionary类的定义中声明这个HashTable的实例。继承(Inheritance)继承允许在既存类的基础上定义新的类。一个新类B继承了既存类A，则B包括了A定义的某些行为，以及它自定义的某些附加行为。有多少种面向对象程序设计语言，就有多少种不同的继承实现方式。继承图①针对实现的继承两个类之间“针对实现”的继承关系的建立指的是使用既存类的内部表示来做为新类的内部表示的一部分。我们不推荐这种继承方式。考虑使用继承来实现一个Circle类，为了定义一个圆，需要定义一个点和一个值，做为圆的圆心和半径。因此，Point类可支持Circle类的一部分实现。把Point当做派生类。如果Circle类直接使用Point的数据成员x和y，将失去抽象。而且失去做为一个点的圆心的标识。针对实现的继承一般在原型开发中使用。②针对特殊化的继承这种继承的使用适合于大多数面向对象程序设计语言所提供的关系，是针对一般化-特殊化关系的。这种继承使用isa关系。类B的一个实例是(isa)类A的一个实例。在使用中，继承将使得既存类的界面成为新类的界面。这表明新类具有它的基类的所有行为。为了定义Dictionary类，应当首先查找既存的抽象，看Dictionary类会是哪个既存抽象的特殊情况。Dictionary应是一个有序表，但具有它自己特有的操作，如使用关键码进行搜索等。既存的OrderedList类可以提供Dictionary类的某些行为，但不是全部。还要确认，在OrderedList中是否有的行为在Dictionary中是不需要的。如果有，可能需要重新组织层次或者开发某些附加的抽象。iskindof

(是一种…)继承这种继承允许有选择地包含既存类的属性，从而建立新的定义。一个鸟类可能有一个关于飞行的属性。一个鸵鸟派生类在模型化时可能就不选择这个属性，因为鸵鸟不会飞。鸵鸟是一种(iskindof)鸟，但具有的属性与鸟不完全相同。iskindof继承是不严格继承。类的实现一种方案是先开发一个比较小的比较简单的类，做为开发比较大的比较复杂的类的基础。即从简单到复杂的开发方案。在这种方案中，类的开发是分层的。一个类建立在一些既存的类的基础上，而这些既存的类又是建立在其它既存的类的基础上。通过诸如“isa”或“ispartof”之类的关系，利用既存代码就能着手建立新的类。§9.3面向对象的测试策略测试计算机软件的经典策略是从“小型测试”开始，逐步过渡到“大型测试”测试顺序：单元测试－>集成测试->确定测试->系统测试单元测试（类测试）

在面向对象环境下，最小的可测试的单元是封装了的类或对象，而不是程序模块。面向对象软件的类测试等价于传统软件开发方法中的单元测试。但它是由类中封装的操作和和类的状态行为驱动的。完全孤立地测试类的各个操作是不行的。考虑一个类的层次。在基类中我们定义了一个操作X。每一个派生类都使用操作X，它是在各个类所定义的私有属性和操作的环境中使用的。因使用操作X的环境变化太大，所以必须在每一个派生类的环境下都测试操作X。在面向对象开发环境下，把操作完全孤立起来进行测试，其收效是很小的。集成测试因为面向对象软件没有一个层次的控制结构，所以传统的自顶向下和自底向上的组装策略意义不大。每次将一个操作组装到类中（像传统的增殖式组装那样）常常行不通，因为在构成类的各个部件之间存在各种直接的和非直接的交互。对于面向对象系统的集成测试，存在两种不同的测试策略。基于线程测试(Thread-basedTest)

它把为响应某一系统输入或事件所需的一组类组装在一起。每一条线索将分别测试和组装。基于使用的测试(Use-basedTest)

它着眼于系统结构，首先测试独立类，这些类只使用很少的服务器类。再测试那些使用了独立类的相关类。一系列测试各层相关类的活动继续下去，直到整个系统构造完成。确认测试在进行确认测试和系统测试时，不关心类之间连接的细节。着眼于用户的要求和用户能够认可的系统输出。为了帮助确认测试的执行，测试者需要回到分析模型，根据那里提供的事件序列（脚本）进行测试。可以利用黑盒测试的方法来驱动确认测试。测试方法学检测软件中的故障并确定软件是否执行了预定要开发的功能。测试过程包括了一组测试用例的开发，每一个测试用例要求能检验应用的一个特定的元素。还需要分析用各个测试用例执行测试的结果来收集有关软件的信息。按不同层次进行测试测试类中各个操作，主要测试类，这种测试是某些单元测试与组装测试的组合假定测试一个软件与测试一个类一样。这个测试者常常就是一个特定类的开发者。9.4.1类测试的种类随机测试划分测试基于故障的测试9.4设计测试用例随机测试例：银行应用系统中，account（帐户）类的操作有：open，setup，deposit，withdraw，balance，summarize,creditLimit和close

限制：在所有操作中最先执行open

在所有操作中最后执行close则：一个account类的最小测试序列包括如下操作：

open.setup.deposit.withdraw.close

但该序列中可能有许多其它行为：

open.setup.deposit.[deposit|withdraw|balance|summarize|creditLimit].withdraw.close从上述序列中可以随机地产生一系列不同的操作序列：

#r1：open.setup.deposit.deposit.balance.summarize.withdraw.close#r2:open.setup.deposit.withdraw.deposit.balance.creditLimit.withdraw.close划分测试（等价划分）基于状态的划分根据类操作改变状态的能力来划分类操作。对account类来说，状态操作包括deposit和withdraw，非状态操作有balance，summarize和creditLimit#r1:open.setup.deposit.deposit.withdraw.withdraw.close#r2:open.setup.deposit.summarize.creditLimit.withdraw.close基于属性的划分根据类操作使用的属性来划分类操作。对account类来说，操作分成三个类别：

使用balance的操作

修改balance的操作

不使用也不修改balance的操作基于功能的划分根据类操作所完成的功能来划分类操作。对account类来说：

初始化操作（open,setup）

计算操作（deposit,withdraw）

查询操作balance,summarize,creditLimit）

终止操作（close）基于故障的测试与传统的方法类似，也是首先推测软件中可能错误，然后设计出最可能发现这些错误的测试用例。例：测试SQRT（计算平方根）操作把语句if(x>=0)calculate_square_root();

误写成if(x>0)calculate_square_root();9.4.2集成测试

测试一个新类时，需要先测试在定义中所涉及的类，再考虑这些类的组装。关系“isa”“ispartof”和“refersto”建立了测试几个类时的次序之间的关联。一旦基本类测试完成，使用这些类的那些类可以接着测试，然后按层次继续测试下去。多类测试－－对每个客户类，使用类操作符列表来生成一系列随机测试序列，这些操作符向服务器类实例发送消息。－－对所产生的每个消息，确定协作类和在服务器对象中的对应操作符－－对服务器中的每个操作符（已经被来自客户对象的消息调用），确定传递的消息－－对每个消息，确定下一层被调用的操作符，并把这些操作符结合进测试序列中例：银行系统协作图对于操作序列：

Bank类对ATM的操作序列：verifyAcct.verifyPIN.[[verifyPolicy.withdrawReq]|depositReq|acctInfoREQ]对Bank类的测试用例可能是：#r3verifyAcct.verifyPIN.depositReq为考虑协作者，上述序列中需要考虑与测试用例#r3中的每个操作相关的消息

Bank需与ValidationInfo协作以执行verifyAcct和VerifyPIN，Bank还必须与Account协作以执行depositReq，因此上述协作的新测试用例是：#r4：verifyAcctBank.[validAcctValidationInfo].verfyPINBank.[validPINvalidationInfo].depositReq.[depositaccount]从动态模型导出测试用例例：

设计出的测试用例应该覆盖所有状态，即操作序列应该使得account类实例遍历所有允许的状态转换：#s1：open.setupAccnt.deposit(initial).withdraw(final).close向该序列中加入附加的测试序列，可得到其他测试用例：#s2:open.setupAccnt.deposit(initial).deposit.balance.credit.withdraw(final).close#s3:open.setupAccnt.deposit(initial).deposit.withdraw.accntInfo.withdraw(final).close习题：以下观念正确吗？我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。如果我们落后于计划，可以增加更多的程序员来解决。既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。习题：以下观念正确吗？如果软件运行较慢，是换一台更快的计算机还是设计一种更快的算法？有最好的软件工程方法，最好的编程语言吗？编程时是否应该多使用技巧？软件中的错误是否可以按严重程度分等级？判断下列关于程序设计风格和软件测试的叙述。(1)用黑盒法测试时，测试用例是根据程序内部逻辑设计的(2)尽量用公共过程或子程序代替重复的代码段。(3)测试是为了验证软件已正确实现用户的要求。(4)有n个判定语句的连锁分支结构有2n条路径。(5)尽量采用复合的条件测试，避免嵌套的分支结构。(6)GOTO类型的语句概念简单，使用方便，在某些情况下，保留GOTO类型的语句反能使写出的程序更加简洁。(7)发现错误多的程序模块，残留在模块中的错误越少。(8)程序效率的提高主要应通过选择高效的算法来实现。软件测试的目的是（A）。为了提高测试的效率，应该（B）。使用白盒测试方法时，确定测试数据应根据（C）和指定的覆盖标准。与设计测试数据无关的文档是（D）。

A.①评价软件的质量

②发现软件的错误

③找出软件中的所有错误

④证明软件是正确的

B.①随机地选取测试数据