早期集成测试如何启用敏捷开发
简介：很难为复杂、异构的系统实施“done，done，done”的敏捷原则。Monica Luke 介绍了服务虚拟化如何帮助改善团队协作能力，协调独立测试机构，让其将精力放在与开发团队相同的里程碑上。
推陈出新……
作为测试人员，在每次迭代结束时拥有稳定、有效的代码的想法让我心潮澎湃。而且，不管您信不信，许多年前（也许是 20 年前），在敏捷软件开发大行其道之前很久，我任职的公司已经这么做了。在两周时间内，开发人员疯狂地编码。我们将获得一个稳定的构建版本，在它之上运行一组（手动）回归测试，然后宣布它已可供测试人员使用。测试团队将在接下来的两周内处理该构建版本，执行越来越复杂的测试，同时我们又针对下一个“稳定”构建版本疯狂地编码。
而且我们都在同一地点工作，所以这种方法确实很有效。当然，我们没有制定里程碑，仍然存在大量缺陷。而且我们也没有利益相关者来审核每次迭代。我们缺少敏捷软件交付的一个关键方面，那是时间盒：满足利益相关者需求 的稳定、有效的代码。
情况没怎么变化，甚至在敏捷开发诞生之后，它带来的所有优点仍然存在。为了执行复杂测试，独立测试机构仍在“挑选”里程碑，然后在下一次迭代时继续测试它们。我们仍在尝试解决让测试团队与开发团队处理完全相同的代码的问题。而且，我们仍在以折衷方式解决满足利益相关者需求的稳定、有效的代码的定义。
敏捷开发碰上系统测试这颗钉子了
但随着敏捷开发及其“done，done，done”定义的出现，这又引发了新的抱怨。开发人员感觉测试人员正在损害他们的“速度需求”。测试人员在开发人员前进到下一步时才查找代码中的缺陷。至少在我以前的工作中，这是符合预期的。开发人员不会这么说，“那已经是两周以前的事了，我现在正在处理其他事情。”但如果在测试中发现了根本性的问题，它们真的符合“done， done， done”原则吗？似乎是哪里出错了。
好吧，您会说，实现自动化怎么样？这不是一种基本的敏捷原则吗？要执行测试驱动的开发（TDD）？没有单元测试，开发人员无法交付任何代码？如果这足以证明一个里程碑构建版本是稳定的，以及该有效的代码满足利益相关者的需求，为什么我们使用传统测试方法还会发现如此多的缺陷？我们该如何定义进行验证来满足利益相关者需求？如果开发团队正在进行演示，它们展示了什么？它是否是完全一体化的演示，在整个系统的上下文中向利益相关者展示了新功能的价值？系统越复杂，答案越可能为“否”。
这里发生了什么？让我们稍微深入分析一下。首先，我们有一个采用敏捷方法的开发组织，但您可能已经注意到，我提到了一个“独立”测试团队。敏捷专家一般会推荐嵌入式测试人员。敏捷流程以整体团队 方法为基础（而且这为它的成功做出了巨大贡献）。那么为什么要有一个独立测试团队？因为应用程序是一个系统的一部分，这个系统非常大，不能再包含测试了。即使拥有包括全面的 TDD 和单元测试，以及一定复杂程度的测试（手动或自动化）的好想法，开发团队也无法包含系统测试：完整的系统集成、大规模性能、大负载、大型数据集、安全性，您一定明白了。从组织上讲，有一个独立测试团队来负责下一个层次的测试，这通常是为了通过卓越测试中心来实现规模经济。
所以，情况可能有点类似于：
图1 集成测试已落伍了
而且至少在某段时间内，测试人员会花 N 天时间来进行安装和配置，结果却发现一些基本功能无效。我们称之为 gross breakage，因为它是一个无法使用的构建版本，并且它确实不是任何人的错。它是人们处理复杂事物的方式的一种表现。我们了解了深入的细节，变成了越来越小的领域的专家，因为我们可 掌握的细节量限制了我们可深入理解的区域。这创造了边界和需要交接工作的地方。
系统集成测试的一个全新世界
好了，对这个问题已讲得够多了。如果您仍在阅读，那么您处在这个世界中了。而且您可能以与我们同样的方式至少已经尝试过 3 次来解决它：向构建流程中添加执行比传统的构建版本中包含的测试更为复杂的测试，也是单元测试。您构建一个 lights-out 自动化安装程序来安装和配置该构建版本，验证和配置测试工具环境，执行自动化的测试套件，然后报告结果。
如果我们能简化这一过程，将会怎么样？或者让它可供越来越复杂的异构系统（通过 SOAP、MQ、SOA 等利用各种外部系统）访问，又会怎么样呢？现在有一些 服务虚拟化 工具允许随时执行全面的集成测试。这意味着配置复杂异构系统所需的硬件和时间更少，从而可在每个构建版本上运行集成测试。如果开发团队采用了持续集成，这意味着可在每个集成构建版本上进行集成测试。
图2 服务虚拟化
通过一旦处于生产或分段环境中随即进行记录、随后对测试的复杂系统中的组件进行智能存根，服务虚拟化即可工作。我喜欢将此想成是虚拟化系统的复杂性，将更改的部分视为我希望测试的部分。这适用于许多情形，然而特别适用于系统中的其他组件未更改或未快速更改时。它实际上与在不同测试中逐渐减少更改的变量数量的测试佳实践完全一致。关于服务虚拟化，有许多真正令人兴奋的好处：
● 虚拟化系统的复杂性以便简化测试环境安装
● 智能服务虚拟化包括有状态性功能，它允许您的测试做一些有趣事情，比如表现为一个服务每隔 X 次中断一次
● 虚拟化的服务组件数据池和企业测试数据工具（比如 Optim）中的测试数据管理
● 服务可在存在之前虚拟化
● 测试团队可与开发团队处理相同的里程碑，因为安装不再是瓶颈
这将我们带回到了敏捷软件开发和在每次迭代结束时交付稳定、有效的代码的承诺上。当测试人员和开发人员可同时处理相同代码并真正实现高质量构建时，它真正是一个全新的世界。Green Hat 技术现在已包含在 IBM Rational Test Workbench 和 IBM Rational Test Virtualization Server 中。
