我并不是经常能看到好的文档。需求文档常常象是市场销售用的系统特性列表。规格说明书有时就象是在代码完成后提交的用户手册文件。而设计文档经常不存在。

好了，通过针对交接所引起的变化的集中讨论，我已把测试过程和软件开发过程相对地分离开了。如果文档中关于“XML支持功能加入到COMM”的描述很薄弱的话，我会尽自己所知来进行尽可能好的测试设计。然后，假如在项目后期，XML相关的用户文档出来了，我就可以对后来再次提交的交接增加相关的测试。假如市场需求改变了，她们经常会这么做，我还会在此后增加或者去除一些测试。所有这一切看起来是这样的：

图3 在文档不完整的条件下进行测试，并在后期补充测试

这样，虽然项目文档总是不到位，而且经常延迟提交，测试的效果也因此常常被降低，我们还是要避免测试受到项目文档的制约。

头脑灵活的测试人员并不过于相信文档。毕竟，总是人在犯错误。那么，难道不是人在写这些文档吗？

由于“正式的”文档是很薄弱的，测试模型必须明确地鼓励在测试过程中使用项目文档之外的各种不同信息来源。

测试人员必须和程序员、用户、市场人员、技术作者以及任何的可能为实现更好测试提供线索的人进行交流。测试人员还应该努力把自己沉浸在某些技术所构建的氛围中。例如，我希望测试人员在做XML测试工作时常去访问W3组织的XML地址（http://www.w3.org/XML/）以及其它XML站点、邮件列表，甚至包括比较特别的 如Dave Winer的DaveNet/脚本新闻（http://www.scripting.com/）。这些资源并不是所谓的“辅助通道”，而是可以被列入计划和进度日程的资源。

另外，所执行的测试本身也是一种有用的信息的资源。好的测试人员会仔细阅读bug报告，因为这些报告讲授了系统所存在的薄弱之处。特别地，这些报告还暗示了一些正式的架构设计所没有提供的架构上的策略。执行测试的行为应该产生一些新的测试想法。如果模型没有考虑到这些，那么它就是一个落后的模型。

因此，测试模型应该包含反馈的循环，让测试设计可以考虑到，在运行测试时还可以继续发现到更多的测试内容。

在我们的工作中，真正的复杂性来自于所有计划的执行都处于一个不确定的、容易忽略的环境里。代码并不是唯一在不断变化的东西。而计划日程也在改变。新的功能扩充会带来新的里程碑。某些功能会从当前版本中去除。在开发过程中，所有人——市场人员、开发人员和测试人员，都会逐渐对诸如“产品究竟提供什么”这样的问题有越来越清晰的了解。在这些情形下，我们怎么能说测试计划的第一个版本会是完全正确的呢？

因此，模型应该要求测试计划人制定明确的规定，对已交接的交接内容，新的交接，以及交接内容的变更进行负责。

总结

V模型有以下致命的缺陷，其它模型实际上也与此相似：

1. 忽略了这样的事实情况，即软件开发是由一系列的交接所组成，每一次交接内容都改变了前一次交接的行为。

2. 依赖于开发文档的存在，及文档的精确性、完整性，并且没有对时间进行限制。

3. 认定一种测试的设计是依据某一个单独的文档，而不包括根据其前后阶段的文档的修改而作相应修改。

4. 认定这些依赖于某个单独文档的测试一定要在一起执行。

我大致描述了一个替代模型，但还不够精细。它考虑到了代码的交接和里程碑。对测试成本控制作了以下明确描述：

测试设计的目标是定义好可能发现bug的测试输入，而测试执行的目标是以各种方式加入这些数据，并检验结果，由此来降低整个生命周期的成本。

我们的模型假设软件产品总是不完美的，开发过程中有很多变更，而且对产品的测试也是一个不断学习的过程。

过去，我很少考虑到模型。表面上我一直还在用V模型。虽然我按此制订计划，但我总是还要花费很多额外的精力和时间来考虑模型中没有提到的方面。换言之，模型造成了一些阻碍，因此我有必要对此进行研究。

对一个新的模型来说，对模型所提出的要求必须非常明确，这就象业务需求对产品开发非常重要一样。我希望自己对本文中所提倡的模型的要求的描述能够和V模型中的描述一样精确，并具有同样的指导意义。

理想的测试模型应该包括下列要求：

1. 使测试对项目中的每一次代码交接有所反应。

2. 要求测试计划人制定明确的规定，对已交接的交接内容，新的交接，以及交接内容的变更进行负责。

3. 在测试设计中，除了使用项目文档外，还应明确鼓励使用其它各种信息，这些信息有不同来源。

4. 事实上项目文档总是不到位，而且经常延迟提交，测试的效果也因此常常被降低。但我们还是要尽量避免测试受到项目文档的制约。

5. 允许根据多种来源提供的综合信息来设计一些独立的测试。

6. 让测试被重新设计，以新的信息形式进行表现。

7. 包含反馈的循环，让测试设计可以考虑到，在运行测试时还可以继续发现到更多的测试内容。

8. 让测试人员认识到，避免测试的延迟可以节省成本。

9. 在组件被组装到程序中去之前对组件的执行进行测试。

感谢

是James Bach最早让我认识到，在测试计划中应考虑到交接。Noel

Nyman和Johanna Rothman在一份草案中提供了一些有帮助的评论。Kamesh Pemmaraju和Carol Stollmeyer使我终于没有放弃对原理的辩解和阐述，不仅是在细节方面，也在实际生活中，以及每一个实际项目中。他们给了我很大的促进，使我去反复地思考问题。

参考

[Boehm88]

Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, 1988年5月

[IEEE98]

"IEEE Standard for Software Test Documentation," IEEE标准829-1998, 电子和电气工程师学会, 1998

[Marick98]

Brian Marick, “When Should a Test be Automated?” 国际质量周刊,1998年5月（ftp://ftp.rstcorp.com/pub/papers/automate.pdf）