基于测试的项目进度管理

From:http://www.51testing.com/html/23/n-837623.html

1、介绍

这是一篇英文的文献，昨天把他翻译出来了。以为仍是比较有用，因此决定在这里把它贴出来。原文在：

http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILBROWSE&ObjectType=ART&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10

2、摘要

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

3、名词解析（本身添加的）

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

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

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

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

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

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

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

4、可交付性的定义

全部的工程项目，原则上都具备可交付性。若是采用迭代的开发途径，为了制定一个迭代的、基于里程碑节点的交付方案，须要将主交付性能够分红多个小的子交付性。（好比一个应用程序能够分红多个模块、函数或者用户开发实现）。

5、WBS和项目计划

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

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

6、测试用例

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

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

● 显示ID

● 显示区域

● 执行的动做

● 指望的结果

● 获得的结果

→ 结果：经过，失败，尚未测试

→ 描述任何非指望的行为

→ 相关的缺陷追踪问题

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

 

7、用测试来衡量进度

7.1 衡量测试结果

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

● 所有的测试用例

● 经过的测试

● 失败的测试

● 还未进行的测试

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

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

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

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

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

图一：测试状态表

7.2 模块进度状态

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

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

● 计划阶段：尚未开始编码

● 开发阶段：开始编码

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

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

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

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

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

图2 进度颜色条码图

 

8、基于测试的进度总览

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

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

9、缺陷数据

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

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

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

10、历史数据

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

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

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

11、这个方法不能作的

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

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

12、对这种方法的评价（本身添加的评论）

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