前置内容的优先级划分

　　风险的优先级划分是任何测试方法的一个组成部分，在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个程序的集成所进行的测试。

　　需要注意的是，前置测试模型并没有规定测试要按怎样的特定顺序来进行。它可以指导我们基于每个项目的特殊性来排定开发和测试的计划，由此可以快速而低成本地达到项目的预期结果：高质量的软件。

　　使用过前置测试模型的开发人员可以很快地想起该方法曾帮助他们避免问题的固有优越性。他们也知道这些问题常常就是项目延期、超预算的主要原因。当项目经理和开发人员意识到前置测试是如何帮助他们认识到那些风险及其规避方法的时候，他们将欣然接纳具备如此多的内在价值的前置测试所带给他们的满意成果。