一个项目的测试是一个持续性的过程,小的项目少则几天,大一些的通常会持续几个月,时间长的大项目也有几年的情况。项目开始之初,常看到不确定的需求太多,已确定的需求又觉得它太粗放,可测试性不好,让人无从下手,所有这些都是很正常的事情。本节介绍如何把项目的终极目标进行细分,定义过程测试里程碑,并进行跟踪与控制,以最终达到项目测试任务的胜利完成。
提到测试阶段,自然地想到软件开发的模型,因为在一般情况下,采用什么样的开发模型,会有对应的测试模型。例如,如果项目采用的是增量式(迭代式)的开发模型,测试也用增量式的测试模型划分不同的测试阶段才比较合适,如表5-2所示。一个完整的项目,站在项目经理的角度,需要输出一个项目的综合开发计划。其中,软件只是其中之一的子系统,可能还包括硬件、机械等产品组成部分的其他子系统(与开发的目标产品有关)。综合开发计划有它的阶段性里程碑目标任务,其中包括软件子系统,软件开发计划的里程碑目标应从项目计划中分解、细化出来。软件开发的详细计划出来后,符合项目要求的测试计划便可以跟随开发的计划进行测试阶段的划分与目标的制定。
表5-2 迭代开发模式的测试阶段划分
软件需求 | 软件开发 | |
目标:2009.1.1~2009.2.28,完成模块A,模块B的一、二级功能设计,以支持市场演示 | ||
需求基线1.0 | 设计方案1.0 | 测试方案1.0 |
需求设计1.1 1.2 1.3 1.n | 编码1.0 | 测试用例1.0 |
迭代版本2 目标:2009.3.1~2009.5.30,完成模块A,模块B的三级功能, 模块C,模块D的一、二级功能可以使用,以支持产品的系统级联调 | ||
需求基线2.0 | 设计方案2.0 | 测试方案2.0 |
需求设计2.1 2.2 2.3 2.n | 编码2.0 | 测试方案2.0 |
… | … | … |
迭代版本n 目标:2009.9.30,全功能版本,版本正式发布 | ||
需求基线n.0 | 设计方案n.0 | 测试方案n.0 |
编码n.0 | 测试用例n.0 | |
需求基线n版归档 | 设计方案n版归档 | 测试方案n版归档 |
表5-2中反映的是典型的迭代开发模式,它的最大优点就是需求、开发、测试密切相关的三方都在并行开展工作。需求是开发与测试工作的输入,所以它也一直走在前面,但有一点很关键,就是无论哪个里程碑版本,开发与测试的工作始终以某个需求基线为目标,尽量降低频繁变化的需求的影响。
测试目标明确,任务细化后,团队成员的工作就有了一个共同努力的方向,这是策略中很重要的一个环节。但有了目标,如果没有跟踪过程,会使得计划流于形式,存在的问题不能及时发现与解决,陷入一种测试过程失控状态,最后的结果可想而知。如表5-3所示是一个测试任务过程跟踪矩阵表范例。读者可以根据所服务项目的不同特点加以修改便可使用。有了这个跟踪矩阵表,项目的测试进展、质量完成情况、遇到的困难与解决措施等所有相关信息便可做到了然于心。通常这是项目测试负责人要做的事,是对测试项目进行有序管理的策略。
表5-3 测试任务过程跟踪矩阵表
过程跟踪机制,可以及时发现问题,但发现问题后还需解决问题,方能推动各测试阶段的任务顺利完成。