八、基于测试的进度总览

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

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

　　九、缺陷数据

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

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

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

　　十、历史数据

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

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

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

　　十一、这个方法不能做的

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

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

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

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