面向对象软件开发教程9.doc

第9章

面向对象测试

任何值得构建的东西都应当测试。
包括模型、文档和源代码在内，你构建了很多种制品。

第9章
面向对象测试

你将从本章学到什么？
如何消除围绕着面向对象测试的误解
全生命周期面向对象测试（FLOOT）方法学
用于测试需求、分析和设计模型的技术
用于测试代码的技术
用于测试准备部署的系统的技术
用户可以用来验证系统的技术
如何写测试用例、装备和配套设施
如何记录缺陷

为什么需要阅读本章？
仅仅开发出软件还很不够，我们要开发能够工作的软件。由于软件变得更为复杂—要使用对象技术来处理这种复杂性，那将变得更难测试。在软件的整个生命周期内可以应用很多种测试技术，本章将讨论这些技术。

软件工程的基础之一是要尽可能地进行测试。要在开发早期找到并修正缺陷有两个理由：大多数错误都在项目周期的早期犯下，修正缺陷的成本将会随着发现它们的时间呈指数增长。
大部分缺陷在生命周期早期就已经进入软件产品之中。
第一，技术人员擅于完成编码和设计这样的技术任务，那也就是他们为什么是技术人员的原因所在。很不幸，技术人员往往并不擅长非技术工作，例如需求收集和进行分析，这也许是他们之所以是技术人员的另一个原因。
激励我们尽早测试的第二个原因是修正缺陷的成本将会随着发现的早晚而变化（越晚的话成本就会越大）。这是软件开发的本质所决定的，所有工作都将以前面的工作为基础。例如，建模基于需求定义阶段的信息收集；编程基于开发模型；测试基于源代码。如果某项需求被误解，那么所有基于这项需求的建模决策都将不合法，所有基于那项模型的代码都将变得可疑，之后进行的测试也就会查出应用程序出错。如果最终错误是在开发周期末期或在应用程序发布时检测到，那时维护起来很可能会费用昂贵。另一方面，如果错误在生命周期早期检测出来，修正它们就会需要较少的费用，因为我们只需要更新少量的文档。

定义
缺陷（defect）：任何降低系统完全而有效地满足用户需求功能的东西。也称做臭虫（bug）、错误（fault）或特性（feature）。
9.1消除对面向对象测试的误解
开发人员对于面向对象的测试存在几个常见的误解。部分原因是由于在面向对象发展的早期缺乏对OO测试的研究，人们更注重于概念、建模与程序实践。IT业界有一种趋势，喜欢把注意力集中在前端开发以及建模和编程上，而不会把注意力放在不太有“吸引力”的主题上，比如测试就是这种不太具有吸引力的主题。我想如果指出这些误解，这样我们就能准确地理解面向对象测试了。

提示：你可以测试的不只是代码从本章你将会了解到，可以测试所有可交付的制品，而不仅仅是源代码。至少要评审模型和文档，这样的话你可以在深入源代码之前就能找到并修正缺陷。
9.1.1误解1：有了对象就可以少做点儿测试
软件越复杂，需要投入测试的工作量就越大。
这是开发人员持有的最为危险的误解，造成这个误解的原因是没有完全理解继承。初次接触OO的开发人员常常会假定某个类已经被测试过，他们可以从这个类继承创建子类，而不需要完全测试新类。这个假设是错误的。当一个类从其他类中继承时，它增加了新的行为，在这些行为当中一部分是全新的，一部分是对已有行为的扩展。子类会实现新的、并且常常是比其父类更加复杂的业务规则。这些业务规则可能会扩展或与已有类的规则相冲突。结果是，除了与新行为相关的测试用例之外，还需要在新的子类上面适当地重新运行最初为父类开发的测试用例，以确保它仍能工作。重新运行测试以确保已有功能仍能工作，这被称做回归测试，重新把父类测试在子类上运行称做继承回归测试。换句话说，我们需要做更多的测试工作，而不是相反。当停下来思考时，你会发现这确实是有意义的。首先选择OO的一个理由就是，你想要开发比遵循结构化/过程方法开发的应用程序更为复杂的程序。这样，对于更为复杂的应用程序就需要做更多的测试，难道这会没有意义吗？

定义
回归测试（regressiontesting）：验证已有软件在变动后仍能工作。
继承回归测试（inheritanceregressiontesting）：在给定子类上直接或非直接运行父类测试用例的行为。
9.1.2误解2：结构化测试技术是充分的
测试方法需要变更以反映新的开发方法。
好的一方面是这个误解其实部分是正确的。坏的一方面是这个误解仅有部分是正确的。在本章中你会看到，许多代码测试技术，如边界值测试，对于测试OO代码来说仍是可用的，许多通用系统和用户测试技术对于软件整体的集成测试也是可用的。但是，从本章还会看到好几项传统的测试技术，例如覆盖测试等，它们在OO世界中将不再像以前那么重要。多态、对象改变类型的功能，否定了覆盖测试，因为代码今天可能对于某个对象来说是正确的，但明天在这个对象改变类型后可能会失效。结构化测试技术没有考虑这种情