【IT168 技术文档】

　　引言：全面单元测试是保证软件开发过程质量的关键策略，但迄今为止并没有为人们广泛接受。本文考查了妨碍全面单元测试的"拦路石"，并介绍了来自 IBM Rational 软件公司旨在克服这些拦路石的新技术。

　　去年春天，我的一位同事获悉他的汽车由于某些部件的缺陷，正在被召回。事实证明，这对他来说仅仅是稍微不便。他把车开到经销商那里，人家免费为他更换了有缺陷的部件，不到几个小时，他就拿回了车。除了在经销商那里浪费了几个小时的工作时间之外，他并没有受到什么损失。但从汽车制造商的角度讲，问题要严重得多。这次召回涉及到的车主有 16500 人之多，给制造商造成的损失超过 1.14 亿美元。这真是一笔不小的费用！

　　由此不难得出结论，只要制造商能在产品生产的早期发现部件的缺陷，就能节省一大笔费用。即便是在所有的汽车都已经装配好但还没有交付的时候发现缺陷，节省的费用也是很可观的。另外还可以避免由于客户的信任度受损和同行的恶意攻击而造成的尴尬局面。我们不妨设想一下，如果制造商能在设计图纸时就发现这一缺陷，那他们节省的费用又该有多少呢？

　　以设计求质量及全面单元测试

　　以设计求质量的产品生产方法包括一系列的策略、过程和实践，借助于它们，在开发过程的早期就能够满足质量要求。这种方法既不是新生事物，也不是无的放矢。比如，这种方法曾被用于制造波音 777 飞机。这种飞机的超过 90％ 的测试都是根据计算机设计模型来完成的。在组装第一架飞机之前，实际上只造了一个样机，这样一来，就节省了几百万美元。

　　Steve McConnell 在他 1997 年出版的《软件项目生存指南》（Software Project Survival Guide）一书中验证了以设计示质量方法：在编码以前修复缺陷比在产品交付时或交付后要少花 50－200 倍的代价。这是个发人深省的数字且在业界引起了广泛的注意。然而，并不是所有的人都遵循以设计求质量的方法，而且事实上多年以来我们一直没有这样做，这究竟是为什么呢？这些问题很复杂--以设计求质量是一个涉及范围很广的话题，根本不可能在短短一篇文章之中将它讨论清楚。但我们可以通过探讨软件开发相关的以设计求质量的一个方面，即全面的组件测试，作为一个"敲门砖"来理解该方法，以及为什么采用该方法会有如此巨大的阻力。

　　为全面单元测试扫清障碍

　　尽管所有的软件开发人员都承认全面单元测试会带来极大利益，但实际上全面单元测试远远没有得到普及，尤其是对于中间层组件测试和缺少图形用户界面的组件测试。为何会出现这种情况呢？因为这些工作既费时又乏味。在过去，克服这些障碍经常是得不偿失。一个主要的问题在于，大多数测试是为特定组件而量身订做的，重用更是机会渺茫。由于开发团队的时间压力很大，因此他们为了赶进度而不得不将精力集中在开发应用程序本身上。通常，开发人员认为，对于每个项目如果都从头构建测试工具和存根，项目结束后再"扔掉"它们。这个过程是一种浪费。所以，他们宁愿将有限的资源都用在编写组件代码上面，而不是花在测试上面。

　　所幸的是，现在我们终于可以摆脱这项困扰。IBM Rational 刚刚引进了一种新技术，使我们能够进行经济高效的全面组件测试。IBM Rational 公司一直致力于为软件开发人员提供各种工具，以帮助他们在更短的时间内交付高质量的软件产品，Rational QualityArchitect 正是其中的一部分。Rational QualityArchitect 通过利用能够自动生成测试代码的可视模型，简化了组件测试。开发人员可以集中精力来创建所需的测试用例，而不用花费时间来编写容易出错并且不可重用的测试代码。