软件测试的革命(3)

　　在软件运行时你会发现很多新的信息，至少和设计时一样多。这也是RUP强调要把可运行的软件作为每一次迭代的组成部份的缘故。你发现的每一样东西都应该是可视的，并且放在你用于设计的同样的工件中。对运行着的系统的跟踪是一种UML的迭代，经过验证和裁决，可以转化为一种可复用的测试。数据也值得进行概括，并形成新的等价类的基础，等等。

　　当前，大多数探索性测试的提倡者，尤其是Kaner和Bach，都把这作为使用后即可放弃的行为[注7]。但我认为，我们一旦把所探索到的内容无缝地加入到设计中去后，就会发现，这是高度可重用的。事实上，这是实时分析的一个新的应用：通过探索而发现的有价值的东西的捕获和利用。

　　组件测试和易测试性设计

　　第三种趋势是关于理解测试人员和开发人员的相对角色，并为每种角色分配合适的工具。Rational把提供组件测试和易测试性设计作为一种最佳实践，这已有很长的历史。我认为对这些做法的采纳源自于对质量的基本理解。当前，太多的测试人员的行为都受限于规格说明的模式，其中有很多浪费。其实开发人员才有责任去保证所开发出来的软件和规格要求相一致，他们应该使用合适的工具和过程来达到这样的目的。

　　Boris Beizer描述了2种不同角色的区别：

　　独立测试的目的是提供一种不同的观察点，由此产生了不同的测试，并且在比开发人员所采用的开发环境更丰富的环境中执行测试。自我测试(self- testing)的目的是消除那些bug，这可以在相对更简单、更明确的单元/组件环境，或者低层次的系统测试中进行，并且只需花费较低的代价。[注8]

　　测试驱动型开发提供更大的能力。如果规格说明就是可执行的测试，而测试进行没有产生别的问题，那么就可以认为软件和规格说明相符。其它的单元测试过程也只是为了保证同样的事情：就规格说明而言，不管它们是什么内容，代码总是与之相符合的。如果不符合，那么就是开发人员的问题。Kent Beck非常清楚测试驱动型开发所带来的效果：

　　如果测试驱动编码的缺陷密度达到足够低的话，那么专业测试的角色将不可避免地发生改变。以前的是“成人监护”方式，而现在更类似于一种扩音器，它宣称测试要更多地验证的是系统必须做什么。[注9]

　　这需要整个团队接受这样的一个前提，即保证软件符合规格说明是开发人员的职责。这使得测试者可以有更多精力用于发现和避免一些别的问题，从客户或者用户的角度来看，这些问题的存在可能会使软件所应有的价值有所降低。Brian Marick针对这些冗长烦琐做法的错误性写过一篇很著名的文章[注10]。那些文档通常已说明了一个系统中的多于一半的错误，他声称，因此你就需要专门有一个过程来让你的测试人员用来发现这些问题。

　　易测试性的设计在这里具有重要的意义。现在很多软件已改用基于服务的构架，这种构架是基于组件的构架的一种扩展，随之而来的是新增加的复杂性，即组件可以在没有警告的情况下发生改变，其可靠性的问题是极为严重的。大多数IT经理会接受99%的可靠性，我敢打赌，他们会认为这一标准甚至已经高于他们所用的买来或构建的组件。但是，如果你构建的系统有超过100个组件，每个组件具有99%的可靠性，那么整个系统的可靠性是0.99的100次方，实际上仅有 37%。顺便提一下，这也是为什么那些有高可靠性要求的市场，例如电信业，会要求“5个9”的可靠性，即99.999%。在这样的情况下，你就可以使用 100个组件，综合起来仍有99.9%的可靠性。

　　这一基本原理实际上要求软件进行易测试性的设计，就象30年前市场形成时硬件所做的一样。 Bertrand Meyer是这一领域研究的领先者，他提出了按合约设计，其意思是把对类及调用该类的客户端之间的关系的检视作为一种正式的协议，这表达了每个团体的权利和义务[注11]。Meyer的概念已被广泛接受，其标志之一就是合约设计的规格语言WSDL的诞生，该语言是Web Service标准的核心[注12]。

　　我认为人们正越来越多地接受易测试性设计。易测试性已成为诸如Web Service等框架和标准的一个补充的组成部份。接口也正成为技术平台和操作系统的一部份。一个比较简单的例子是，J2EE和.NET 中预定义开放式接口和API映射，可以允许工具来检查在运行时刻环境中发生了什么。另一个真实而有益的趋势是人们正使用象Rational XDETM这样的工具，通过设计模式的方法来构建应用--而易测试性已被置入在设计模式中。模式所构造的组件包括外在的用于测试的接口 -- 即组件的一些适当的getter和setter方法。

原文转自：http://www.uml.org.cn/Test/200412202.htm