软件测试的新模型(5)

　　另外，所执行的测试本身也是一种有用的信息的资源。好的测试人员会仔细阅读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使我终于没有放弃对原理的辩解和阐述，不仅是在细节方面，也在实际生活中，以及每一个实际项目中。他们给了我很大的促进，使我去反复地思考问题。

原文转自：http://www.uml.org.cn/Test/test47.htm