软件测试驱动开发的迭代过程

发表于:2010-10-04来源:作者:点击数: 标签:软件测试开发驱动
在传统的产品研发模式中,单调从 需求分析 开始到测试验收结束。开发和测试始终处于产品研发的不同阶段,开发人员在产品研发的早期就介人,然后经过一段时间的开发设计,将开发的累计成果转交给 测试人员 从而进入到测试阶段。在测试完成并提交用户验收通过

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

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

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

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

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

原文转自:http://www.ltesting.net