以测试驱动开发的迭代过程在华虹新产品研发中的应用.doc

以测试驱动开发的迭代过程在华虹新产品研发中的应用 在传统的产品研发模式中,单调从需求分析开始到测试验收结束。开发和测试始终处于产品研发的不同阶段,开发人员在产品研发的早期就介入,然后经过一段时间的开发设计,将开发的累计成果转交给测试人员,从而进入到测试阶段。在测试完成并提交用户验收通过后,产品即可交付使用。这种产品研发模式最大的优点是产品研发的阶段划分明确,职责明确,易于管理。 但是随着产品复杂程度的增加,操作系统日益庞大,传统的产品研发模式会给产品质量带来极大的风险,同时也给研发人员带来很大的压力。首先针对累计开发成果的集中测试使得多个测试任务在同时爆发,在测试时间一定的情况下,经常导致分配到单个测试项的时间被一再压缩,或者优先级较低的测试项将被剔除,很难保质保量按照测试计划执行。其次即使在规定时间内完成了测试任务,但是没有充裕的时间针对市场需求、用户需求、产品定位和质量达标的度量输入进行充分和全面的测试,难以保证产品已经完全满足设计要求和用户需求。 众所周知,测试作为研发过程的常规部分,最重要的作用是发现问题和及时反馈问题。理想化模型中认为只要能发现问题就能够修改,但实际中却要求产品设计之初就必须预留有修正错误的接口和方案,否则当产品研发进行到测试阶段,产品已经基本定型,如果此时才发现了问题并进行修正,会导致耗费的成本十分昂贵。由此可见,传统的产品研发模式从本质上推迟了产品风险和问题的暴露时间,可能会导致产品的研发周期延长,研发质量低下,研发成本超支等问题,同时严重打击参与者的积极性和信心,甚至导致整个产品线的失败。 因此为了在一定程度上解决上述问题,同时满足新产品研发的需求,我们在华虹新产品的研发过程中,逐渐探索出了一套全新的产品研发模式,称之为测试驱动开发的迭代研发过程,也称为(3+2策略)。该研发模式强调测试与开发的齐头并进,通过对新产品的不断测试与修正,将设计缺陷扼杀于萌芽状态,提供产品质量信心,实现产品价值提升。 下面将着重介绍我们在实践中如何使用该迭代研发过程。迭代的概念源自软件测试,在本文中的定义为,迭代起始于模块设计,结束于模块测试通过。 首先我们把一个产品研发过程划分为3个阶段(立项、研发、验收)。 各阶段的工作内容都是传统产品研发模式的流程和工作内容的延续,但是又强调新的突破点。在立项阶段(如图1所示),我们强调对用户需求,投入产出和升级方案的预研,考核的阶段成果将汇总为需求输出到研发团队;在研发阶段(如图2所示),我们强调产品定义时采用模块化的方式,分离,设计,开发和测试,已成型的模块,并逐步集成,最终构成完整的系统。考核的阶段成果将体现为把需求转化为系统实现;而在验收阶段(如图3所示),就注重技术指标和研发成本的确认,其阶段成果表现为产品成本的控制和客户验收通过。其中立项阶段的需求输出和研发阶段的设计实现同等重要(如图4所示),只有实现了二者的相互补充和相互制约,才能保证产品验收的成功。 其次在进入研发阶段后,我们会制定2类计划,第一是粗粒度的计划:也称为阶段计划。 包括从用户需求、系统设计、概要设计、详细设计到编码,涵盖了整个产品的研发目录。主要用于控制产品开发进度和开发周期,阶段计划制定完成后相对固定,且必须严格执行。第二是细粒度的计划:也称为迭代计划。包括了任务的详细说明,并给每个参与者和参与团队分配任务,覆盖到可能的应用场景,分解出关键的技术指标。目的用于控制开发质量和开发回溯。迭代计划通常会随着开发的深入而动态变化。 大家对于执行单一的阶段计划都非常熟悉,但是在阶段计划中加入了迭代计划,研发过程将会发生怎样的变化呢?流程图如图5所示。迭代计划可以看作是单个阶段计划中的移动窗口,所起的作用是把阶段计划进行逐级放大。首先将阶段计划中的工作分配到小集体,继而分配到每个集体中更小的集体;其次将研发过程化整为零,从最基础的模块开始开发并测试,逐级累加测试模块。最后分解出关键的技术指标(模块),要求必须尽早完成,这样就可以在不断迭代中对其进行彻底的测试。 由此可见,我们在新的产品研发模式中引入的第一个大变革是,要求测试人员在开发初期就介入。测试人员与开发人员同步熟悉开发文档,建立测试计划,准备测试平台,一旦开发人员完成了部分功能的交付,就必须迅速展开测试,考核技术指标的完成度,由此判定是需要回溯到上一阶段,还是进入下一阶段,而每进入下一个阶段就标志着一个迭代过程的终结。通常同时有两个活跃的迭代计划,在当前迭代存活的时候程中,项目组成员就需要着手分析开发进度和开发过程中需求的改变,准备好下一个迭代计划。在上一个迭代过程结束时进行评估,按照迭代的目标的达成度作为能否开始下一个迭代过程的准则。 其次引入的第二个大变革是,测试的进度紧随开发的进度。给与测试人员充分的时间,进行全面的测试,同时总结出的经验教训能够及时反馈,修正开发计划,增强团队中的交流。通常一个迭代的时间跨度是13周,如果项目比较重大,以及有足够的自动化水平和成熟的过程,可以增加迭代的次数。迭代的数量多少取决于产品的级别优先级。 最后引入的第三个大变革是,研发过程可以随客户需求的改变而迅速对产品作战略调整。可以方便的减少一些系统功能,从而提前发布,缩减需求改变和扩展给产品研发造成的麻烦,保证开发进度。更进一步,采用了模块化的设计,通过分析普遍存在的问题,便于开发复用的模块,以此构成整个系统中复用的基础。所以当我们在新产品研发中采用了混合有迭代计划的研发模式,已使得我们的研发过程面貌焕然一新,提高了新产品的研发效率和产品质量。 但是尽管在新产品研发中采用测试驱动开发的迭代过程可以一定程度上缓解产品研发中的问题,还需要强调的是,目前迭代计划的制定还只是一个完全凭经验的方法,执行的效果依赖于制度和系统的保障,无法逆转整个产品研发流程。为了更好的使用该迭代方法,我们总结出了以下几点注意事项,供大家参考。1)制定一个固定边界框的迭代计划,确定迭代的数量,持续时间和可分配的资源,避免迭代的设计大于目标以至于无法完成。2)为迭代制定一个成功的目标准则,在迭代结束的时候评审中使用这些准则进行判断。 3)明确每个参与人员的任务和职责,以及达到迭代的目标需要完成的活动。4)分解迭代的工作结构,并考虑其必定要发生的实际活动。估计各个活动的持续时间和工作量,注意控制在节点之内。5)迭代过程是动态的,会随着目标和战略的改变而调整,不需要花过多的时间和精力去制定一个超级详细的计划。6)做好需求管理,对预期的系统行为和需求的扩大缺乏理解容易造成迭代失控。7) 各个阶段的迭代结束时,要注意对测试用例进行总结归纳,形成一个逐渐完善的回归测试库。八: 要注重自动化测试环境的准备和开发,减少手工测试的工作量,这样才能保证迭代测试是可以坚持下去的。 综上所述,我们在新产品中研发中采用的以测试驱动开发的迭代过程,其中心思想就是,在开发设计的同时最大限度的展开充分测试,对每个开发环