两种有效的测试思想

摘要：项目的开发风险来自于对需求的误解，来自于设计与开发过程及产品的缺陷，只有尽早发现这些缺陷，才能降低并控制项目风险。基于这种思想，软件业出现了一些新的测试思路。（据调查，测试中发现的BUG有56%是来自需求文档，而这56%的BUG正是由于需求文档编写存在问题，不明确、不清晰、不正确所导致的。）

1、测试驱动开发。这种测试思想被最近流行的XP（Extreme Programming）极限编程方式所大力提倡。它的基本思想是，通过测试来为编程做指导，在某个要开发的需求对象明确之后，在编码之前，先进行相关测试代码（测试代码的内容和需求规格说明书描述是相同的，有人把它称为“可执行的需求规格说明书”）的编写工作，完成之后针对测试代码进行编程，然后再用测试程序对开发代码进行测试，验证其正确性，若程序通过了测试，就说明它是符合需求规格说明书要求的。周而复始，通过这样的过程，开发进程得以层层深入，直到开发完成。而这时单元测试也基本完成了。

　　这种测试方式的最大的好处是，尽早地发现设计、开发中存在的问题，避免传统开发模式中的“测试过程中发现代码不能满足需求而导致的大量返工”。降低项目风险；同时可以尽早地将“半成品”展示给客户，使客户对需求进行验证、补充及完善，另外测试代码的表达方式相对准确、无二义性，可以降低因需求理解错误而导致的项目风险。

　　2、迭代测试。这种测试是IBM所推崇测试方式之一，它从迭代式开发模式演变而来。在迭代开发模式中，每个迭代都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：

　　*   对当前迭代周期产品的增量测试。

　　*   对前迭代周期已完成功能的回归测试。

　　随着迭代周期的累进，测试工作内容随之不断变化。早期迭代测试重点在于新功能的测试，后期迭代测试重点在于累积功能的回归测试。

　　有的人不喜欢XP编程的开发方式，认为其没有明确的阶段性划分，不利于计划管理，模式过于灵活，不好掌握。迭代式开发模式为这些人提供了新的选择。这种开发方式继承了瀑布式开发模式的优点――全面、严谨、有计划性、易管理，更重要的是，这种模式将测试工作分布到每个迭代周期中，使测试工作提前进行，从而使将发现软件缺陷的周期提前，大大降低软件风险及开发成本。

　　它将软件开发比喻成制作一桌盛宴，项目经理比作大厨，测试人员比作品尝师，用户则比作就餐者。为保障饭菜质量，上菜之前，先由品尝师对满桌的半成品、准成品逐个品尝，发现不足的地方要及时通知大厨进行改进，完善质量，直至品尝师觉得：全部的饭菜已经色、香、味俱佳，满足用户要求了，才通过审查，允许饭菜上桌，供就餐者品尝。我想说的是：饭菜质量靠品尝师的监督，但主要靠的是大厨的技术，同理，软件的质量则是靠各个项目管理过程的互相配合及项目经理的整体控制和把握，测试只是其中的一份子。所以，请不要将软件的质量都交给测试过程来承担，那样将是“生命不能承受之重”。