2010年软考系统分析师：测试驱动开发的迭代过程

　　在传统的产品研发模式中，单调从需求分析开始到测试验收结束。开发和测试始终处于产品研发的不同阶段，开发人员在产品研发的早期就介人，然后经过一段时间的开发设计，将开发的累计成果转交给测试人员从而进入到测试阶段。在测试完成并提交用户验收通过后，产品即可交付使用。这种产品研发模式最大的优点是产品研发的阶段划分明确，职责明确，易于管理。

　　但是随着产品复杂程度的增加，操作系统日益庞大，传统的产品研发模式会给产品质量带来极大的风险，同时也给研发人员带来很大的压力。首先针对累计开发成果的集中测试使得多个测试任务在同时爆发，在测试时问一定的情况下，经常导致分配到单个测试项的时间被一再压缩，或者优先级较低的测试项将被剔除，很难保质保量按照测试计划执行。其次即使在规定时间内完成了测试任务，但是没有充裕的时间针对市场需求、用户需求、产品定位和质量达标的度量输入进行充分和全面的测试，难以保证产品已经完全满足设计要求和用户需求。

　　众所周知，测试作为研发过程的常规部分，最重要的作用是发现问题和及时反馈问题。理想化模型中认为只要能发现问题就能够修改，但实际中却要求产品设计之初就必须预留有修正错误的接口和方案，否则当产品研发进行到测试阶段，产品已经基本定型，如果此时才发现了问题并进行修正，会导致耗费的成本十分昂贵。由此可见，传统的产品研发模式从本质上推迟了产品风险和问题的暴露时间，可能会导致产品的研发周期延长，研发质量低下，研发成本超支等问题，同时严重打击参与者的积极性和信心，甚至导致整个产品线的失败。

　　因此为了在一定程度上解决上述问题，同时满足新产品研发的需求，我们在华虹新产品的研发过程中，逐渐探索出了一套全新的产品研发模式，称之为测试驱动开发的迭代研发过程，也称为(3+2策略)。该研发模式强调测试与开发的齐头并进，通过对新产品的不断测试与修正，将设计缺陷扼杀于萌芽状态，提供产品质量信心，实现产品价值提升。下面将着重介绍我们在实践中如何使用该迭代研发过程。迭代的概念源自软件测试，在本文中的定义为，迭代起始于模块设计，结束于模块测试通过。首先我们把一个产品研发过程划分为3个阶段(立项、研发、验收)。各阶段的]一作内容都是传统产品研发模式的流程和工作内容的延续，但是又强调新的突破点。在立项阶段，我们强调对用户需求，投入产出和升级方案的预研，考核的阶段成果将汇总为需求输出到研发团队;在研发阶段，我们强调产品定义时采用模块化的方式，分离，设计，开发和测试，已成型的模块，并逐步集成，最终构成完整的系统。考核的阶段成果将体现为把需求转化为系统实现;而在验收阶段 ， 就注重技术指标和研发成本的确认， 其阶段成果表现为产品成本的控制和客户验收通过。其中立项阶段的需求输出和研发阶段的设计实现同等重要 ， 只有实现了二者的相互补充和相互制约， 才能保证产品验收的成功。

　　其次在进入研发阶段后，我们会制定2 类计划，第一是粗粒度的计划：也称为阶段计划。包括从用户需求、系统设计、概要设计、详细设计到编码， 涵盖了整个产品的研发目录。主要用于控制产品开发进度和开发周期， 阶段计划制定完成后相对同定， 且必须严格执行。第二是细粒度的计划： 也称为迭代计划。包括了任务的详细说明， 并给每个参与者和参与团队分配任务，覆盖到可能的应用场景，分解出关键的技术指标。目的用于控制开发质量和开发回溯。迭代计划通常会随着开发的深入而动态变化。大家对于执行单一的阶段计划都非常熟悉， 但是在阶段计划中加入了迭代计划， 研发过程将会发生怎样的变化呢? 。迭代计划可以看作是单个阶段计划中的移动窗口， 所起的作用是把阶段计划进行逐级放大。首先将阶段计划中的工作分配到小集体， 继而分配到每个集体中更小的集体;其次将研发过程化整为零， 从最基础的模块开始开发并测试， 逐级累加测试模块。最后分解出关键的技术指标( 模块) ， 要求必须尽早完成， 这样就可以在不断迭代中对其进行彻底的测试。