都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：
· 对当前迭代周期产品的增量测试。
· 对前迭代周期已完成功能的回归测试。
随着迭代周期的累进，测试工作内容随之不断变化。早期迭代测试重点在于新功能的测试，后期迭代测试重点在于累积功能的回归测试。
有的人不喜欢XP编程的开发方式，认为其没有明确的阶段性划分，不利于计划管理，模式过于灵活，不好掌握。迭代式开发模式为这些人提供了新的选择。这种开发方式继承了瀑布式开发模式的优点――全面、严谨、有计划性、易管理，更重要的是，这种模式将测试工作分布到每个迭代周期中，使测试工作提前进行，从而使将发现软件缺陷的周期提前，大大降低软件风险及开发成本。
测试过程的衡量
测试过程在不断地改进，但效果如何，如何来衡量测试的效果呢？我们需要引入一把尺子，一个度量标准，这样才能把握测试过程的改进方向。那么，怎样来收集数据，如何来度量？这是我们长久以来一直困惑的地方。
我们不妨借助“他山之石”来想想办法，CMMI是当今国际流行的软件过程衡量模型，它在这方面是有自己的独到之处的：
1、 面向全局。CMMI的测试度量面向的不仅仅是测试过程的改进，测试效果的加
强，它面向的是整个开发过程，并始终将质量监督放在工作首位。比如，它度量工作产品规模（例如代码行数），度量工作量和成本（例如人工小时数）。我们从中搜集的数据对整个开发过程的改进都有指导作用。更高的起点可使我们避免项目管理改进过程中常见的“头痛医头、脚痛医脚”毛病。
2、 建立度量数据库，从而对搜集的数据、分析的方式及结果进行完整、规范的
保存。这个数据库面向的是软件开发过程的持续改进，它的数据是可复用的，可供多个项目参考使用，不随当前项目的结束而消失，而是会作为历史信息持续保存，从而为测试及其他软件过程的改进提供更客观、更全面的度量数据。
3、 关注度量、分析过程的改进。度量过程是为了对测试及其他软件过程的改进提
供参考依据，它自身运作方式的合理性直接会影响度量结果的准确性。CMMI避免了“灯下黑”现象的出现，它没有忽略测量分析度量过程的改进，它会定期召集受影响的受益者一起审查初始分析结果，总结本过程运作中遇到的经验教训，从而对度量过程方式进行改进，保证度量结果的正确性，可参考性。
CMMI度量方式的优点往往是我们所忽略的，我们应尽力学习它的这些长处，这对软件测试过程的改进会很有帮助。
结束语
测试很重要，它是检验开发结果是否接近预期目标的重要手段，但我们应清楚地认识到：它毕竟只是一种信息反馈过程，作为软件质量的守护者，它可以发现缺陷，但无法避免缺陷的发生，我们不能将软件质量的安危都押在测试这个砝码上。
曾看过一个比喻，还记忆犹新，它将软件开发比喻成制作一桌盛宴，项目经理比作大厨，测试人员比作品尝师，用户则比作就餐者。为保障饭菜质量，上菜之前，先由品尝师对满桌的半成品、准成品逐个品尝，发现不足的地方要及时通知大厨进行改进，完善质量，直至品尝师觉得：全部的饭菜已经色、香、味俱佳，满足用户要求了，才通过审查，允许饭菜上桌，供就餐者品尝。我想说的是：饭菜质量靠品尝师的监督，但主要靠的是大厨的技术，同理，软件的质量则是靠各个项目管理过程的互相配合及项目经理的整体控制和把握，测试只是其中的一份子。所以，请不要将软件的质量都交给测试过程来承担，那样将是“生命不能承受之重”。