很多时候人们把代码移交给其他人，并且说：“希望你能接受和喜欢它。”这不仅发生在将整个项目放在一张光盘中交给客户的时候，也发生在项目内部。

例如，一个小组对另一个小组说：“我们已经完成了为COMM库加入对XML的支持。源代码现在已经放在master库中，可执行库则已经加入到集成与创建的环境中。XARG小组的工作已经没有什么阻碍了，随时去取吧。”

某个程序员检查了bug的修改并且发出邮件：“我已经修改了Bug列表中的那个Bug，很抱歉！”至此，早先受该问题影响的其它代码就可以继续处理了。

在这些情况下，人们要把代码移交给其它人，其中有可能会存在一些影响。测试人员需要干预这个过程。在移交之前，测试人员应执行这些代码，发现其中的bug（影响），并且提出问题：“你确实要提交这些吗？”由此，移交的内容可能会被延期，直到bug被修复好。

尽管你还要做其它的各种测试，这项测试仍然是很基本的测试工作。如果你没有做这样的测试，就不能算是合格的测试人员。

我们的测试模型必须包含这一重要的现实需要：针对代码移交的测试。由此，测试模型应提示进行针对每一次代码移交的测试。

就让我以支持XML的COMM库作为例子。这里存在着一个小组把代码移交给XARG小组以进行项目的余下部分。那么谁会遭受影响？

· 要将这些支持XML的代码直接进行使用的XARG小组可能会立即受到影响；

· 这可能会在稍后影响到市场人员，他们要在一个行业展示会议上为“合作伙伴发行”版本提供产品演示和宣传，而XML支持是影响他们销售的重要部分；

· 还有，它可能损害采纳我们的产品的合作伙伴。

现在我们可以提出一些有趣的关于测试计划的问题了。可以做的最简单的事情是，在移交的时候立即执行XML支持的完整测试。（“完整”的含义是，为此设计尽可能多的测试）但也许一些XML特性并不是XARG小组所需要的，因此可以把它们放在合作伙伴版本封版（下图中的“Partner Release”）的测试中去。这意味着可以把一些XML相关测试放到稍后的移交过程中去。或者基于其它理由，例如在近阶段有其它的测试任务要执行。而XARG小组则要因XML中的bug修复而延迟一小段时间。

我们的测试计划所表示的进度可以通过在开发的时间线上进行注解的方式来表现，如下图所示：

图1 添加在开发计划之上的测试计划

我们应严格地围绕在XML支持的功能交接的时段里进行测试。测试设计和测试支持工作要早于测试执行。而另外的XML测试则要延迟到基于整个项目范围的“代码完成”（图中的“Code Complete”里程碑），或者要等到全部的子系统被集中在一起，而且整个产品为了行业会议而在经过稳定化处理后创建了版本（图中的“Partner Release”里程碑）。

显然，有两项内容没有包含在代码完成里程碑中：

还有大量其它的测试工作（包括设计、工具选用）。这些工作可能因为COMM以外的子系统的交接而延期。

而且，还有用于完成里程碑中所规定的某些风险的测试，例如，可能还有一组用于运行市场人员的演示Demo脚本的测试，包括她可能在无意中引起的偏离。其目的是要避免这样的情况，即当她站在1000人的观众面前时，她还仅仅是第一次以某种特定的顺序来输入数据。

一些首次交接时进行的XML测试需要在代码完成里程碑上再次执行。

我的观点是，测试计划是由很多困难的决定所组成，这些决定包括人员组织安排、机器资源配置、测试设计的时间定位、测试支持代码的数量、哪些测试要做自动化，等等。这些决定应根据单独的交接中的内容信息来作出。如果仅有一次交接，那么你可以更顺利一些。测试计划还应继续考虑以下问题：

1. 风险分析，谁会因此受到损害，以什么方式？

2. 选定一种测试途径来定位特定的风险。

3. 对测试设计和执行的周期和成本进行估计。

4. 在项目进度上的特定位置，将计划纳入执行的行动：

A. 开始对测试进行设计…

B. … 同时设计和创建一些支持测试的代码…

C. … 在全部测试完成以前就执行部分的测试，因为可能存在不只一次的交接，在每一次交接的测试规划中，可能存在一些潜在的复杂的相互影响。工作安排不得不进行一些调整以达到相互间的平衡。测试支持代码和工具需要在各项任务中得到共享。你还必须考虑到在什么程度上让那些为早先的交接所设计的测试在以后重新执行，等等。

这看起来很复杂。看上去似乎有太多的内容需要跟踪，而且太多的内容可能被忽略。也许你认为我是在要求你要对每一次交接来执行IEEE 829 [IEEE98]中关于测试计划的要求，然后把它们合并为一份贯穿整个项目的针对交接进行测试的测试计划。

是，也不是。思考问题总是要占用时间的。太多的计划可能会减少结果的产出。在有些时候，你需要做的是停止计划并开始行动。例如，你无法思考并描述每一个bug修复，尽管bug修复也是一种交接。

但是bug修复是实际工作中现实存在的问题。总体项目计划中应该包含bug修复。需要强调的是，你应该有一个默认的bug修改处理的标准过程，该过程应包括运行于每一个提交的bug修复的验证过程。你还需要努力地去思考问题。很多时候，各项验证是被放在一起同时进行并完成的。

比较现实地来说，一个模型应该允许一些机械式行为，例如，“不管是哪一个X类型的交接，都要执行下列操作”。同时我们鼓励对特定的交接执行刚刚够的检查，对于风险越小的交接，就越可以采用机械式的测试行为。

一个明确考虑到基本的测试现实的模型肯定会比忽略这些现实或者把你的工作复杂性完全抽象化的模型做得更好。文档则是另一个例子。

我还没有提到需求及规格说明书，或者设计文档。某个交接中产生的一系列变化会引起很多争议。这些文档所扮演的角色是什么呢？它们常常是这么被使用的：

图2 测试中对开发文档的利用

文档可以指导你在一个交接变化时如何作出反应。如果你有一份很好的需求文档，它可能是产品所解决的问题的描述，尽管也许不是很直接。它可以帮助你对风险进行分析。一份好的规格说明应对系统的行为进行描述。这将帮助你把测试方法转化为具体的测试。一份好的架构设计则可以帮助你理解变化可能引起的几种不同的情况：系统的其它部分会受到怎样的影响？什么测试需要再次进行？