我们都知道，「测试」是产品的真正试炼场；即使对一项软件开发工程投注了庞大的心血，如果测试不合格还是枉然，因为客户要的是「合格产品」，而不是你的「努力过程」。所以测试的重要性应该不必赘述。只不过，「知道」跟「做得到」是两回事，就如同我们都知道应该多吃青菜水果，然而还是有许多人每餐都是大鱼大肉。

许多人谈到测试，总是有满腹牢骚，因为它似乎是一件「知易行难」的麻烦工作。为何测试总是做不好？大致可归类成下述三大原因。

测试排最后

目前一般的软件开发工作，大多采用传统的「瀑布式（Waterfall）」流程法，也就是把开发过程分为「需求」、「分析」、「设计与撰写」、「整合」、「测试」等阶段，一个接一个依序进行。

这种方法很单纯，但导致「测试总是排在最后才进行」的状况。这种设计会产生两个状况：一是测试人员直到案子接近尾声才上工，所以往往在尚未了解整个系统架构的情况下，就一头栽进工作。二是这个时间点距离完工期实在太近，如果有什么突发状况，往往导致整个开发项目大乱或失败。

时间不够

测试做不好的第二个原因是「时间不够」，这是开发团队最常面临的问题。它其实也是上述「瀑布式」流程法把测试排在最后所导致的另一个致命伤。由于许多开发团队把大部分时间分配给前面阶段（特别是程序设计与撰写部分），只留少数时间给测试工作。然而突发状况永远无法预期，如果前面阶段因故导致工作拖延，在出货时间不能延后的情况下，后面阶段的时间就会不断地被牺牲。

所以我们常常看到，在一个预定进行八个月的软件项目里，因为前面阶段的状况百出（计算机当机、同仁生病请假、客户需求更改、开发不顺等），结果前面阶段不断占用后面阶段的时间，最后导致原本排定一个月的测试时间只剩下一周，甚至二、三天而已，根本无法测试。所以常常出现有些产品根本是在未经完整测试的情形下就贸然出货上市，把测试工作留给客户或消费者的情况。

另外还有一个与「时间不够」刚好相反的现象，就是「时间太长」。有时产品经初步测试之后发现问题丛生，实在无法交差（或是被客户退件），所以开发团队只好回头继续进行大量又重复的「测试→修改→验证」工作。如此折腾了好一阵子，最后产品终于可以验收。把这段额外时间加总起来，重新计算整体开发时间，这时才突然惊觉：「天啊，测试竟然占了将近一半的时间！」

风险太高

第三个问题是「风险太高」，也是流程设计不当所致。如文章开头所言：「测试才是产品的真正试炼场」，也就是一个项目的各种隐藏性风险，往往是透过「测试」才被完整发掘出来。但是「单向瀑布式」流程法却把测试集中在最后进行，所以它的风险容易随着开发流程的推进而越来越高；是一种相当危险的风险控管方式。

事实上，这也是许多项目在后期才突然出现成本失控或失败的重要原因。因为等到风险爆发之时，往往已经无力回天，或必须付出相当大的代价以为因应。

解决之道：采用RUP流程

该如何解决这些问题？很简单，因为问题核心出在流程设计，所以解决之道必须摒弃传统的「单向瀑布式」流程法，改采「往复式」（Iterations）的RUP（RationalUnifiedProcess）流程。它将一个准备开发的系统拆解成好几个子系统，然后不断往复循环整个开发流程，直到最终成品。

在RUP标准作业规范里，测试是从一开始就进行的。首先，当客户的需求被具体化与文件化之后，测试人员就会配合拟定相对的测试计划，这个工作随着客户需求进入分析等后续阶段，不断被追踪与进行细部修改，逐步接近系统层次。

然后，当任一子系统（或模块）在初期阶段被开发出来，它的测试工作就会立刻进行，检验它是否完全吻合客户需求与各项预定条件，如此就完成了一项子系统（模块）的所有开发工作。这也就是RUP所揭示的一项重要原则：「产品先出来，测试先行」。在整个开发流程里，从单元、模块、模块整合到最终产品，测试工作始终依此原则不断地进行。

这种方式的优点就在于可以完全解决前述「测试排最后」、「时间不够」、「风险太高」等深深困扰许多开发团队的棘手问题。

在RUP流程里，测试人员从「一开始」就进入整个开发工作，所以是在完全理解并亲身投入产品建置过程的情况下进行工作，不用等到最后阶段才尝试了解他所要测试的「到底是什么东西」，自然可以避免瞎子摸象的危险。

其次，在RUP流程里，测试人员的工作时间并不是集中在最后阶段，而是平均分布到整个开发流程，随着过程推展而持续进行测试工作，所以测试人员根本不用担心时间被占用而到最后才拼命赶工。

最后，就是深刻影响开发项目成败的「风险问题」。在RUP流程里，我们确定「测试先行」的原则，特意让可能隐藏的高风险在前面阶段就先被发觉，然后以逐步降低的方式分散风险，所以不会有传统瀑布式流程法「风险越来越高」的危机。

根据StandishGroupCHAOS于1999年的统计报告，同样一个问题，当它发生在前面阶段与后面阶段时，所需投入的「解决成本」的平均比例大约是1比200。经过上述两种流程法对测试工作的优劣分析之后，相信各位应该很清楚要采用哪种流程方法了。（ZDNET）