(软件测试的新模型.docVIP

软件测试的新模型 由安博测试空间技术中心/提供 　　通常情况下，一个软件模型说明的内容主要包括，在测试过程中你应该考虑到哪些问题，如何对测试进行计划，测试要达到什么目标，什么时候开始，在测试中你要用到哪些信息资源。一个好的模型可以引导你对问题进行思考，而不好的模型则只能使你误入歧途。 这里我要宣称的是，目前的大多数软件测试模型都是不好的模型。这是因为这些测试模型仅仅是软件开发模型的一些装饰和补充而已。 　　人们一直在苦苦寻找软件开发的模型，在创建了新的模型后，就把测试作为一个阶段放在模型的后面部分。因此测试总被作为一种事后行为，测试总是被开发所驱动。总的来说，我们是在检测他们的完成品。但是，作为事后处理的测试，其驱动方式是不正确的。实际上它显而易见地和开发过程中各种行为之间有关，测试没有起到应有的平衡作用。这样的测试只是检测了开发人员做了什么，而并没有检测到他们是否按照规则做了什么，这样的做法割裂了本该紧密联系的行为，剩下的只有那些匆忙而草率的想法所带来的伤害。 　　而这样做的结果就是效果很差的、效率很低的测试。效果很差的测试将导致很多bug没有被发现，而效率很低的测试所浪费的是成本。 　　在本文中，我要做2件事，其一，我要否定一个不好的模型，即V模型。我希望通过论述来表明，“单元测试”和“集成测试”这2个词汇可以从我们的词汇表中取消了。其二，我将描述一个更好的模型。不过首先我认为，要真正拥有一个充分合理的模型还为时尚早。我仅仅是描述了一些新模型应该符合的重要的要求。这些要求将在本文末尾处列举。 　　V模型有什么问题呢？ 　　在本文中我要把V模型作为不好的模型的典型来进行分析。我选择V模型作为分析的典型是因为V模型是最广为人知的测试模型。 　　最典型的V模型版本一般会在其开始部分对软件开发过程进行描述，如下图所示： （图1--V模型的各级开发阶段） 　　这是古老的瀑布模型。作为开发模型，它有很多问题，不过这里不作讨论。尽管它的各种状态是我们接着要讨论的大家最熟悉的V模型的基础。我的批评意见同时也针对其它的装饰在一些更好的开发模型之上的测试模型，例如螺旋模型[Boehm88]。 在V模型中，测试过程被加在开发过程的后半部分，如下图所示： （图2--V模型示意图） 　　单元测试所检测的是，代码的开发是否符合详细设计的要求。集成测试所检测的是，此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测的是，已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。 　　对于测试设计，显而易见的是，V模型的用户往往会把执行测试与测试设计分开对待。在开发文档准备就绪后，就可以开始进行相关的测试设计。如下图所示，相应的测试设计覆盖在了相关的开发过程之上： （图3--将测试设计覆盖了开发过程后的V模型） 　　V模型有着很吸引人的对称外形，并且把很多人都带入了歧途。本文将集中讨论它在单元测试和集成测试中引起的问题。 　　为了说明的方便，这里专门制作了以下图片，图中包括一个单独的单元，以及一个单元组，我称之为子系统（subsystem）。 （图4--一个假想的子系统） 　　对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类，还是相关的类的集合？这些讨论并不影响我在这里所要阐述的观点。我们权且认为一个单元就是一个具有最小程度的代码块，开发人员可以对进行独立地讨论。 　　V模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。 　　那么，如何针对单元进行测试呢？我们会查看在详细设计中对接口的定义，或者查看源代码，或者同时对两者进行查看，找出符合某些测试设计中的有关准则的输入数据来进行输入，然后检查结果，看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块（Stub）和驱动模块（Driver），如下图所示。 （图5：单元及其外部的驱动模块和桩模块） 　　图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试”。我认为这样的方法有时候是一种不好的方法。 　　同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块，又扮演了驱动模块。如下图所示： （图6--子系统内部各单元间的测试执行轨迹） 　　到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价？这些模块如何进行维护？子系统是否会由此而掩盖了一些故障？在整个子系统范围内进行排错的困难程度有多大？如果我们的测试直到集成测试时才真正开始，那么一些bug可能较晚才被发现。由