软件测试的革命(2)

　　图1：可理解性问题(基于Leffingwell和Widrig的观点)

　　实际上，Leffingwell和Widrig并没有真正地考虑到测试的问题。他们的主要目的是想让需求具备很高的可理解性，以便于让用户和投资者能够充份理解。他们没有解决这样的问题，即如何把规格说明提交给其他投资者和生命周期的其它阶段。作为一种争议，他们认为有必要保留一部份不明确性。而实际上，不明确的需求显然会让测试人员发疯。

　　Marick提出的测试驱动型开发方法则走向另一个极端：测试代表了需求，测试的表现形式是一些可编译、可执行的代码。但是，如果测试(需求)的唯一表现形式是代码的话，你就很难和商务人员/投资者/客户进行有效沟通，甚至也很难和其他测试人员及开发人员进行沟通。所有这些人都认为测试的形式本该是数据和流程，所以如果要以那种方式来做的话，你的测试必须变得非常容易进行交流。

　　一些公司正致力于为这种隔阂提供解决之道。Rational正积极参与一个OMG团体关于UML测试预定义项目，该项目可以把测试表示为数据和可视化的流程，例如顺序图和活动图。我们正在开发一些工具来对待以下三种表示方法，代码，数据和流程，并取代类似的测试视图。

　　在过去，我们制作了这些“实例化规格说明”，按照RUP的命名方法，可称之为“用例实现”。“实例化规格说明”和“用例实现”的相似性可以通过援引最近的一个使用Agile方法的工作团体的报告来说明：

　　[一个参与者]提到，和他一起工作的人都很喜欢使用“测试第一”的开发方式。当测试框架被开发好以后，特别是当用于组织运行的测试脚本被定义好时，他们的工作变得更为容易。而用例在组织起来开发脚本时会有所帮助。他们的测试可以捕捉到用户的需要。人们之所以喜欢这样的方法，其原因是它提供了他们工作所需的结构。在Agile方法中，需求以“案例(story)”的形式存在。于是，测试脚本将以接口已明确定义好的形式把这些“案例”编织在一起。这意味着结对编程的人可以根据他们需要的顺序相互测试接口[注5]。

　　类似地，OMG测试预定义工作组发现，将UML排列起来也很容易。你可以将一个用例实现转成为测试，这只需增加两件东西：验证工作(例如，“现在用测试来检查这个软件中的条件。”)以及裁决(例如，通过、失败，或者暂不决定)。这样的信息在规格说明中随处可以捕捉到，所以UML符号可以让我们测试人员有了表达的手段。

　　于是，只需要额外做一点点努力，就可以使测试对客户来说变得很容易理解：数据表和可视化流程。然后，当有软件需要测试的时候，测试已准备就绪。这一实践使测试驱动型开发在系统级测试上也具有实用的价值，因为在设计工件和测试设计工件之间确实没有什么区别。仅仅只要增加验证的注解以及进行裁决就可以了。在比较容易理解的可视化流程和数据的帮助下，你不再需要把系统设计从测试设计中分离出来。而且由于这些流程具有一个可执行的形式(生成的代码)，因此可以把每一次创建作为测试来执行。这使整个团队得到了解放，并成为Kent Beck和Erich Gamma所说的"受影响的测试(test infected)":

　　“...这是一种测试的类型，只要使用非常小的投入即可使你成为一个更快的、更多产的、更具预见性的、压力更小的开发者。”

　　-Kent Beck和Erich Gamma《Test Infected: Programmers Love Writing Tests》[注6]

　　探索性学习

　　这第二种趋势认识到了这样的现实，即我们通常很难把问题描述得十分正确：需求在演变，我们需要简化(扁平化)或者把著名的 “错误-代价”曲线颠倒过来。这里的核心思想是：我所说的每一项，不管是在产品、测试或者跟踪排错的第一步，都在运行软件时通过探索性发现，才使得可视化 -可执行-设计-测试的整个过程和结果变得更为真实。

　　实时分析工具，例如Rational PurifyPlus就带有制作精良的非常明确的实例，例如发现内存错误和性能上的瓶颈。你还可以用它们来支持更广泛的探索，尤其是在由各种不同组件所构成的系统中。80%的企业级行为都是对某些组件的重新组装，包括对遗留下来的成份进行更新或补充等等，而不是从头开始设计。

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