规划测试工作2

2.9确定测试内容

这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档可以证明你测试了什么或测试测试什么。具体要点有：

l       功能的测试：理论上测试要覆盖所有的功能项，例如，在数据库中添加、编辑、删除记录等，这会是一个浩大的工程，但是有利于测试的完整性。

l       设计的测试：对一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

l       整休考虑：这部分测试需求要考虑到数据流从软件肿的一个模块流到另一个模块的过程中的正确性。

在软件测试过程中，有时会惊奇地发现软件产品中包含的某些内容不必测试，这些内容可能是以前发布过的或者测试过的软件部分。

计划过程需要验明软件的每一部分，知道它是否要测试。如果没有测试，就要说明这样做的理由。如果由于误解而使部分代码在整个开发周期漏掉，未做任何测试，就可能导致一场灾难。

2.10测试阶段

在计划测试阶段，测试小组就会查看预定的开发模式，并决定在项目期间的测试阶段是否应执行。在边写边改模式中，可能只有一个测试阶段某个成员宣布自己的工作完成时进行测试。在流水线和螺旋模式中，从检查产品说明书到验收测试可能有几个阶段。测试计划属于其中一个测试阶段。

在测试计划过程应该明确每一个预定的测试阶段，并通知项目小组。该过程一般有助于整个小组形成和了解全部开发模式。

与测试阶段相关联的两个重要原则是进入和退出规则。测试过程的每一个阶段都必须有客观定义的规则，绝对地声明本阶段结束，下一阶段开始了。

假如，说明书审查阶段在正式说明中审查公布时要结束。Beta测试阶段在测试员完成验收测试，从预定Beta测试构造中没有发现新的软件缺陷时要开始。

 假如没有明显的进入和退出规则，测试工作就会成为毫无头绪的单个工作，很像软件开发过程的边写边改开发模式。

2.11测试员的任务分配

到目前为止，我们已经定义了测试阶段、测试策略和资源需求，这些信息加上产品说明书就可以为每个测试员分配任务了。前面讨论的团队之间的责任是指哪些功能性团队（管理、测试和程序员）负责哪些高级任务。分配测试员的任务是指明确测试员负责软件的哪些部分、哪些可测试性能。表达式1-2给出了一个极为简化的Windows写字板程序的测试员任务分配表。

实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道应该负责什么，而且有足够的信息开始设计测试案例。

表1-2写字板程序的高级任务分配

2.12测试进度控制

测试进度需要以上所述的全部信息，并将其映射到整个项目进度中。该阶段在测试计划工作中至关重要。因为，往往存在一些原以为很容易设计和编制的必需特性，后来证实测试是非常耗时的。一个例子是：某程序在不明显的有限区域之外不执行的打印。没有人意识到打印对测试的影响而在产品中保留该特性，结果导致打印机配置测试要花几周时间。作为测试计划的一部分，完成测试进度安排可以为产品小组和项目管理员提供信息，以便更好地安排整个项目的进度。他们甚至会根据测试进度决定砍掉产品中的一些特性，或者将其推迟到下一个版本中推出。

关于测试计划的一个重要问题是，测试工作通常不能平均分布在整个产品开发周期中。有些测试是以说明书的代码审查、工具开发等形式在早期进行的，但是随着开发的进展，测试任务的数量、人员和测试花费的时间不断增长，在产品发布之间会形成短期的高峰。如图1-1显示了典型的测试资源图表。

表1-1项目中的测试资源数目随着开发进度增长示意图

测试任务持续增长的结果导致测试进度不断受到项目中先前事件的影响。如果项目中某一部分交给测试组时晚了2周，而按照进度只有3周测试时间，结果会怎样呢？或者是3周的测试在1周的测试时间进行，或者把项目推迟两周。出现的这种问题称为进度危机。

使测试任务摆脱危机的一个方法是，测试进度避免定死启动和停止任务的日期。表1-3所示的是肯定会使测试小组陷入进度危机的测试进度。

表1-3固定日期的测试进度

相反，如果测试进度根据测试阶段定义的进入和退出规则采用相对日期，那么显然测试任务依赖于其他交付内容先完成。单个任务需要多少时间也很明显，表1-4给出了一个例子。

许多有软件安排进度的产品会使该过程容易管理。项目管理员或者测试员最终负责进度安排，他们可能会使用此类软件，但是要求测试员参与安排自己的具体任务。

表1- 4相对日期的测试进度

2.13频度和统计手段

频度和统计是跟踪项目进展、成效和测试的手段。测试计划过程应该明确收集哪些信息。要做什么决定，准来负责收集。

l       实用测试频度的例子如下：

l       在项目期间每天发现的软件缺陷整数。

l       仍然需要修复的软件缺陷清单。

l       根据严重程序对当前软件缺陷评级。

l       每个测试员找出的软件缺陷总数。

l       从每个特性或者区域发现的软件数目。

2.14风险和问题

测试计划中常用而且非常实用的部分是明确地指出潜在问题或者对测试工作有影响的地方。

假设有十几个测试新手，全部软件测试经验来自于阅读本书，受命测试开发的核电站软件，这就是风险。也许没有人意识到某个新软件要测试1500个调制解调器，在项目进度中也没有为此留出时间，这又是一个风险。

软件测试员要负责明确地提出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些是真正的风险，而有些最终证实是无所谓的。重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。

3小结

即使对于小型项目，开发测试计划也是不可轻视的大风险。如果只填写模板的空白项，那是很容易的，用几个小时就可以打印出测试计划的副本，但是这样做并没有抓住要点。测试计划是一项全体测试员参与的工作，是整个产品小组中的主要参与者。做好测试计划要花费几周甚至几个月的时间。但是，如果该过程时间紧迫，在产品开发早期全面了解和统一测试内容、测试原因、如何测试，就会使测试工作更加顺利地开展。

如果读者正在进行实际的软件测试，一般不会负责开发整个软件测试计划，然而，你应该准备着向测试负责人或者管理员为本章所列的所有论题提供输入内容，你要负责测试软件的某些方面和特性：你制订的进度、所需的资源和承担的风险最终全部要融入整个测试计划中。