一、介绍

　　这是一篇英文的文献，昨天把他翻译出来了。觉得还是比较有用，所以决定在这里把它贴出来。

　　二、摘要

　　面向交付的项目管理和测试驱动开发能够结合在一起，能够为客户、开发成员和管理者提供客观的更容易理解的方法来测量项目的进度。在这篇文章里，john ferguson smart提供了一个学习用例来说明如何通过这种途径进行工作。

　　三、名词解析（自己添加的）

　　3.1 面向交付的项目管理是一种项目管理方法，测试驱动开发是一种开发方法。

　　3.2 面向交付的项目管理：就是本文说的，把任务分下去，总体任务代表一个总的交付，然后各个子任务代表子交付。项目根据各个交付任务来进行管理。

　　3.3  迭代的开发方法：就是先完成部分主要的功能，形成一个版本。然后再逐渐添加新的功能，形成新的版本。

　　3.4  测试用例（test case）：可以理解为就是测试用的程序和方法。每个测试用例对程序的某个功能进行测试，看是否实现了这个功能，有没有bug。完备的测试用例就是对程序的各个功能和稳定性进行全面的测试。设计好的测试用例，才能全面而且尽可能快的完成程序的测试。

　　3.5 测试驱动开发：表示总的程序需要什么功能，各个子模块需要什么功能。指定好测试用例，程序完成了测试用例的功能，就表示开发完成了。将测试用例用于开发过程中，而不是说先把程序写好了，最后再测试。

　　3.6 可交付性（deliverable）：可以理解为可以交付的工作产品，就是具备独立功能的一段代码。

　　3.7 beta版本：beta版本就是软件开发的一个阶段，一般这个阶段，程序已经可以完成大部分的功能，也比较稳定了。一般beta版本开发出来以后，就会提供给用户或者内部人员免费使用，然后根据使用发现的bug，进行修正。

　　四、可交付性的定义

　　所有的工程项目，原则上都具有可交付性。如果采用迭代的开发途径，为了制定一个迭代的、基于里程碑节点的交付方案，需要将主交付性可以分成多个小的子交付性。（比如一个应用程序可以分成多个模块、函数或者用户开发实现）。

　　五、WBS和项目计划

　　工作分解结构（WBS）是一个大家熟悉的而且非常有用的工具，用来将一个项目分解成容易管理的（也有人说可以消化的，或者可以咀嚼的）多个任务。在一定程度上，你分配WBS任务给单独的开发组成员，（某些时候，是一小群开发成员），然后要求他们产生一个具体的可交付产品。

　　工作分解结构（WBS）往往是跟项目计划紧密相连。这里，对于工作分解结构（WBS），工作需要细化到每个任务对应一个可交付性的条款，然后分配到具体的小组成员。将具体的交付工作分给具体的小组成员，可以让开发者将开发活动上聚焦在具体的、短期的目标上，同时也可以培养开发者的buy-in能力和责任感。

　　六、测试用例

　　自然，我们也为每个交付要写一组测试用例。这些测试用例代表了每个模块可以被接受的标准。可以有很多方法来做测试计划和测试用例。大部分会包含某种形式的，一系列的执行动作和步骤，伴随着特定的结果。在我们的用例中，对于每一个可交付的模块，我们将对应的测试用例填到Excel电子表格中，并加注额外的信息以便容易使用。下面就是Excel表格的表项。

　　● 一个独一无二的测试用例号

　　● 显示ID

　　● 显示区域

　　● 执行的动作

　　● 期望的结果

　　● 得到的结果

　　　　→ 结果：通过，失败，还没有测试

　　　　→ 描述任何非期望的行为

　　　　→ 相关的缺陷追踪问题

　　根据我们的经验，一组好的测试用例能够很完美的指示产品是否准备好交付。理想的情况，是测试用例和产品的功能定义一同交给开发者，尽管在实际中，测试用例一般要晚一点点。分析文档和测试用例为每一个模块提供了具体的有形的目标，使得开发者能够关注于代码的编写。

七、用测试来衡量进度

　　7.1 衡量测试结果

　　基于测试的进度报告能够用一种容易理解的、客观的观点来审视项目进度。在我们的项目中，对每个模块需要报告下面的测试状态：

　　● 全部的测试用例

　　● 通过的测试

　　● 失败的测试

　　● 还未进行的测试

　　我们从下面三个主要方面来进行度量：

　　● 一个模块当所有的测试用例都由QA执行过，并测试成功，这个模块就算完成了。QA包括内部测试组和用户测试人员。

　　● 测试一个模块需要的测试用例的数目反映了模块的复杂度。虽然不总是这样，但常常如此。

　　● 开发是迭代的：新版本被频繁的交付，测试也需要不停的进行，而不是仅仅在项目的最后才进行测试。

　　在这些条件下，各个模块的全部进度都可以通过各个模块的测试用例通过的数目来衡量。如果你能可靠的在特定的时间点（里程碑节点），获得各个模块通过的测试用例数、失败的测试用例数和未测试的用例数，就可以把它制成如图一所示的表格。

图一：测试状态表

　　7.2 模块进度状态

　　我从不相信一个开发者说他的一个模块快要完成了。在我的书中，只有所有的测试用例都通过了，一个模块才算完成了。然而，有些被普遍接受的原则认为，如果一个程序，85%的测试用例通过了，就可以进行beta版测试了。尽管你理论上认为必须100%的测试用例通过，才能说产品准备好了，但是我们的用户通常会接受产品，尽管产品还存在一些不严重的问题，并且这些问题在将来能够被修补。因此，我们把模块的“预产品”状态定义为至少95%的测试用例通过并且没有严重的问题。最后，我把模块开发过程的阶段划分原则制定出来。

　　我们划分成五个状态来表示五个开发阶段，通过测试成功的测试用例的数目来客观的衡量。

　　● 计划阶段：还没有开始编码

　　● 开发阶段：开始编码

　　● beta版本阶段：85%测试用例通过。

　　● 预产品阶段：95%的测试用例通过，没有发现严重的问题

　　● 产品准备好阶段：100%的测试用例通过

　　一旦你有了测试用例通过的百分数，你就对模块的开发进度和稳定性有了一个很好的评价。我们将这些数据用图形来表示，写在每周的进度报告中。

　　可以将进度表示成紫色的条图，用来指示模块的工作进展。这能够鼓励开发者自发主动的清楚工作的进度。如图2所示。

图2 进度颜色条码图

　八、基于测试的进度总览

　　我们从更高的层次上，通过测试用过的数据来看项目的进度。如图四所示。这图对外行人很容易看懂，在项目的进展报告中，放在在执行总结情况这部分特别有用。

图3 基于测试的项目进展总览图

　　九、缺陷数据

　　我们使用的迭代的开发周期，提供了方便的追踪缺陷数据的基础。（译者注：因为迭代是周期性的提交版本，可以周期性的对每个版本测试，发现版本的缺陷）。我们一般一到两周会提交一个面向用户交付的版本，每周或者几天就会提交一个内部版本。新版本的整洁性比增加的模块数目或者修正的bug数目更重要。然而，QA人员在接受一个新版本之前，必须对上一个版本进行一个合理长的时间测试。交付的日期就必须一起商量决定。在期望的交付日期前，我们要考虑交付是否可行（能否修正严重的问题），要考虑哪些新模块以及哪些bug能够对用户声明。

　　为了实现这个，我们把缺陷数据放在缺陷数据库，从数据库中提取出缺陷数据来衡量产品的质量可可靠性。全局缺陷状态图表示了各个缺陷状态（open, to-be-deployed,pending validation等）的缺陷数目。

　　我们对每次交付，都要衡量缺陷的状态——记录公开的问题数目和总的问题数。这对于交付规划是非常重要的。

　　十、历史数据

　　对于跟踪随时间变化的测试的结果也是很重要。它能告诉你软件的可交付性和稳定性的速度（多长时间可以产生一个交付版本，多长时间可以达到某种稳定程度）。如图6和图7所示。

图6 历史数据：随时间的测试完整性

图7 历史数据：随时间的测试完整性

　　十一、这个方法不能做的

　　（译者注：这个方法指基于测试的项目进度管理）

　　这种方法不完备，也不是要取代传统的项目进度跟踪和汇报。这种方法的特别之处在于它是纯粹面向交付的。因此它能够幸运的忽略哪些诸如延时、开销、资源消耗、关键途径等等术语。这些术语能够而且应该被诸如Gantt图，PERT图等代替。实际上，这种方法能够给上层管理人员、小组成员和项目投资人等一个项目进度的直观表示方法。基于测试的交付状态是一个重要的而且容易理解的项目汇报方式。但是延迟、花费和面向任务的观点同样重要。

　　十二、对这种方法的评价（自己添加的评论）

　　测试用例的设计非常重要，要完备，系统。要有机制对测试用例的优先级进行设定，哪些优先级高，先实现；哪些没那么重要，后实现。 对各个测试用例要归属各个版本，哪个版本应该实现哪些测试用例。要设计好。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/