简介：很难为复杂、异构的系统实施“done，done，done”的敏捷原则。Monica Luke 介绍了服务虚拟化如何帮助改善团队协作能力，协调独立测试机构，让其将精力放在与开发团队相同的里程碑上。

　　推陈出新……

　　作为测试人员，在每次迭代结束时拥有稳定、有效的代码的想法让我心潮澎湃。而且，不管您信不信，许多年前（也许是 20 年前），在敏捷软件开发大行其道之前很久，我任职的公司就已经这么做了。在两周时间内，开发人员疯狂地编码。我们将获得一个稳定的构建版本，在它之上运行一组（手动）回归测试，然后宣布它已可供测试人员使用。测试团队将在接下来的两周内处理该构建版本，执行越来越复杂的测试，同时我们又针对下一个“稳定”构建版本疯狂地编码。

　　而且我们都在同一地点工作，所以这种方法确实很有效。当然，我们没有制定里程碑，仍然存在大量缺陷。而且我们也没有利益相关者来审核每次迭代。我们缺少敏捷软件交付的一个关键方面，那就是时间盒：满足利益相关者需求 的稳定、有效的代码。

　　情况没怎么变化，甚至在敏捷开发诞生之后，它带来的所有优点仍然存在。为了执行复杂测试，独立测试机构仍在“挑选”里程碑，然后在下一次迭代时继续测试它们。我们仍在尝试解决让测试团队与开发团队处理完全相同的代码的问题。而且，我们仍在以折衷方式解决满足利益相关者需求的稳定、有效的代码的定义。

　　敏捷开发碰上系统测试这颗钉子了

　　但随着敏捷开发及其“done，done，done”定义的出现，这又引发了新的抱怨。开发人员感觉测试人员正在损害他们的“速度需求”。测试人员在开发人员前进到下一步时才查找代码中的缺陷。至少在我以前的工作中，这是符合预期的。开发人员不会这么说，“那已经是两周以前的事了，我现在正在处理其他事情。”但如果在测试中发现了根本性的问题，它们真的符合“done， done， done”原则吗？似乎是哪里出错了。

　　好吧，您会说，实现自动化怎么样？这不是一种基本的敏捷原则吗？要执行测试驱动的开发（TDD）？没有单元测试，开发人员就无法交付任何代码？如果这足以证明一个里程碑构建版本是稳定的，以及该有效的代码满足利益相关者的需求，为什么我们使用传统测试方法还会发现如此多的缺陷？我们该如何定义进行验证来满足利益相关者需求？如果开发团队正在进行演示，它们展示了什么？它是否是完全一体化的演示，在整个系统的上下文中向利益相关者展示了新功能的价值？系统越复杂，答案越可能为“否”。

　　这里发生了什么？让我们稍微深入分析一下。首先，我们有一个采用敏捷方法的开发组织，但您可能已经注意到，我提到了一个“独立”测试团队。敏捷专家一般会推荐嵌入式测试人员。敏捷流程以整体团队 方法为基础（而且这为它的成功做出了巨大贡献）。那么为什么要有一个独立测试团队？因为应用程序是一个系统的一部分，这个系统非常大，不能再包含测试了。即使拥有包括全面的 TDD 和单元测试，以及一定复杂程度的测试（手动或自动化）的最好想法，开发团队也无法包含系统测试：完整的系统集成、大规模性能、大负载、大型数据集、安全性，您一定明白了。从组织上讲，有一个独立测试团队来负责下一个层次的测试，这通常是为了通过卓越测试中心来实现规模经济。

　　所以，情况可能有点类似于：

图1 集成测试已落伍了

　　而且至少在某段时间内，测试人员会花 N 天时间来进行安装和配置，结果却发现一些基本功能无效。我们称之为 gross breakage，因为它是一个无法使用的构建版本，并且它确实不是任何人的错。它是人们处理复杂事物的方式的一种表现。我们了解了深入的细节，变成了越来越小的领域的专家，因为我们可 掌握的细节量限制了我们可深入理解的区域。这创造了边界和需要交接工作的地方。