【IT168 技术文章】
虽然大多数人都认同模型的重要性，但在开发周期中，测试模型并没有受到应有的关注。V模型是最广为人知的测试模型，不过很多测试人员仍对V模型不是很了解。V模型还受到很多质疑，其中Brian Marick（《The Craft of Software Testing9 (Prentice Hall, 1995)》一书的作者就曾对V模型提出过一些中肯的批评。在本系列的第二篇中，我们讨论了X模型，该模型覆盖了Marick的意见，并由此形成了一个相适的测试模型，而在第一篇中，我们已经讨论了V模型。在第三篇文章中，我们将V模型和X模型相结合，提出了前置测试模型，该模型沿用了前者的长处，同时又尽量弥补了前者的不足。在本文中，我们将说明实行“测试驱动开发”所能带来的益处。
前置测试的计划
附图“一个复杂的标准”描述的是IEEE标准829-1998中提供的测试计划的概念性结构。然而一些批评家曾认为该标准并不切合实际情况，仅仅是书面出版物而已。
图1 一个复杂的文档计划结构
从图中可以看到，该标准将测试计划分为多个不同的层次，其中也包括个人文档部分，这些文档可以作为整个较大规模的文档，即单独的测试计划（例如单元测试计划）的组成部分。而主测试计划则最终可以成为项目计划的一个组成部分。
我们将逐层往下看，并探讨一下这些层次是否真的对我们的工作有帮助。
主测试计划组合了一整套的测试计划，该计划主要考虑的是，系统作为一个整体时必须正常运作。通常，在一个分计划（详细计划）中应描述相应的单元测试、集成测试、特殊测试及系统测试。其中，特殊测试是一种综合性的测试，而并不是被应用所驱动的那种测试，可以是诸如压力测试、安全性测试或者可用性测试等等。相应地，在各分测试计划中，分别组合了各自的一套性能或功能，以确保相关的单元测试、集成测试、特殊测试及系统测试内容能够正常运作。对于每一个性能和功能来说，一份测试设计说明可以对如何验证其正常运作进行了描述。每一份测试用例的设计说明都要标明相关性能或功能是如何工作的。
测试计划结构带来了很多的益处。虽然很多测试人员认为IEEE标准提供了大量冗余的文档，这些文档并没有太多价值，但我们并不这么认为。我们并不反对象X模型中所提倡的写完即交付的测试计划文档，但我们更提倡记录重要的测试计划信息，并将其作为容易记忆的内容，进行充分的共享与重复利用，以及对其进行持续改进。
对很多人来说，测试计划主要是对测试用例的收集整理，但收集起来后文档可能会变得很大，很难进行管理。其实从图中可以看到，标准结构可以帮助组织和管理测试用例，由此也体现了该结构所具有的直接的价值。
我们应提前定义好可重用的测试设计说明，确定如何在通用的情形下进行测试。这些说明可以防止大量的重复工作，使我们能顺利开展可靠的测试，而不至于造成时间上的延误。同样地，该结构可以帮助我们定义好可重用的测试用例及可选择的资源分配。另外，该结构和测试设计说明将有助于在必要的时候重复创建测试用例。
前置内容的优先级划分
风险的优先级划分是任何测试方法的一个组成部分，在V模型和X模型中却都没有进行明确的定义。而我们使用的前置风险分析方法则要比我们所见过的其它方法都有效得多。
前置测试可以从2个途径来改进测试。其一，传统方法一般会把风险定位到每一个测试上，由于没有对比，因此每一项测试都成了高风险。有了前置测试计划结构后，就可以很快地揭示可选项，这样即可从选项中区分其优先级别。其二，我们可以排除那些常用的评定测试风险等级的技术，显然，对于那些被忽略的测试，不会有风险加到这些测试上面，但忽略这些测试本身常常就是最大的风险。相应地，前置风险分析可以使我们确定传统方法所忽视的紧要的风险，然后定义好有关的测试以避免这些风险的出现。当我们在各个不同层次上使用前置测试计划的时候，其中最重要的任务就是在主测试计划中列入项目级风险的识别及其处理的优先级排定。特别要指出的是，这一前置技术可以帮助我们预见到很多常见的突发事件。其实每个开发人员都能列举出很多使项目停顿的意想不到的事件，而且这些事件往往是发生在项目实施的前后。
在和一个项目团队协同工作时，我们总是可以发现他们一直在试图使用前置风险分析方法来确定大量潜在的突发事件，而有关的报告指出，传统的项目和测试计划往往会忽视多达75%的突发事件。
一旦我们确定了风险，并对风险划分了优先级别，我们就可以定义哪些系统部分需要优先进行测试。这些部分往往和组织中原先计划好的次序有所不同。然而通常的开发计划的目的是要开发整个程序，所以常常会以工作执行顺序来做计划，而前置测试模型定义了出现在高风险区的系统的部件--单元或集成的测试。让测试驱动开发，就要优先对这些部分进行开发。
优先创建并测试这些高风险的部分可以帮助开发人员在付出额外劳动之前就能抓住问题所在。如果能对特殊测试给予应有的重视，则效果将会更好。特殊测试还有益于详细测试的结果一致性，这比在系统测试 (例如负载测试和安全性测试）中进行更好，另外风险分析还可以避免忽略其它的测试（例如培训、文档和操作示范程序的测试）。这样，每一次创建可以包含传统方法需要同时通过单元、集成和系统测试后才能包含的成分。
一个基本的A-B-C例子
为了感受一些测试驱动开发的模式，让我们看一个简单的例子。假设我们有一个系统，包含了A、B和C三个程序，系统按A-B-C顺序执行。表面上看，程序的开发和测试可能都会以同样的顺序进行。
但是，我们的风险分析揭示，B和C之间的集成会产生最大的风险。因此，B程序和C程序应该首先创建并优先进行单元测试。由于在B和C中发现的问题可能会影响到A，所以在A开发之前发现这些问题可以有助于避免A中某些部分的重写。
下一个高风险是A程序中的通讯能力。在传统方式的开发计划中，我们会将A作为一个整体进行开发，然后进行单元测试，但作为一个整体来看，A可能很庞大，比较难以进行测试，查找问题与修改错误。因此我们可以将A分成为2个单元，其中一个专门处理通讯功能，另一个则处理剩余的其它功能，这样我们就可以更快地针对通讯能力进行测试，同时，其它的问题也相对更容易被发现和修改。
接着，我们需要对A程序的2个组成部分进行集成测试，以确保这2个部分能正确地组合在一起。最后，既然B-C以及A的内部组成部分的集成测试已经完成，我们可以引入并处理第三个风险，即对全部3个程序的集成所进行的测试。
需要注意的是，前置测试模型并没有规定测试要按怎样的特定顺序来进行。它可以指导我们基于每个项目的特殊性来排定开发和测试的计划，由此可以快速而低成本地达到项目的预期结果：高质量的软件。
使用过前置测试模型的开发人员可以很快地想起该方法曾帮助他们避免问题的固有优越性。他们也知道这些问题常常就是项目延期、超预算的主要原因。当项目经理和开发人员意识到前置测试是如何帮助他们认识到那些风险及其规避方法的时候，他们将欣然接纳具备如此多的内在价值的前置测试所带给他们的满意成果。
