敏捷方法 集成测试_早期的集成测试如何实现敏捷开发

旧的一切又都是新的……

作为一名测试人员，在每次迭代结束时都拥有稳定且可运行的代码的想法让我发自内心。 和。 信不信由你，多年前（大约20岁），在敏捷软件开发风靡一时之前，我就曾在一家做到这一点的公司工作。 两个星期以来，开发人员会疯狂地编写代码。 我们将获得一个稳定的版本，对其进行一组（手动）回归测试，并声明它可供测试人员使用。 测试团队将在接下来的两周内开始对该版本进行工作，进行越来越复杂的测试，而在下一个“稳定”版本中，开发工作会变得疯狂。

而且我们都在同一地点，所以它确实有效。 当然，我们没有交付里程碑，仍然存在很多缺陷。 不，我们没有利益相关者来关注每次迭代。 我们缺少敏捷软件交付的关键方面，即装箱 ： 满足利益相关者需求的稳定，有效的代码。

即使敏捷开发的到来以及它带来的所有好处，也没有太大的改变。 为了进行复杂的测试，独立的测试组织仍在挑选“里程碑”，然后在下一次迭代中进行测试。 我们仍在尝试解决测试与开发完全相同的代码保持一致的问题。 而且，我们仍然在折衷满足利益相关者需求的稳定，有效的代码的定义。

敏捷开发打系统测试墙

但是随着敏捷开发的到来以及对完成，完成，完成的定义，这引起了新的抱怨。 开发人员觉得测试人员正在干扰他们对“速度的需求”。 开发人员继续前进后，测试人员正在发现代码中的缺陷。 至少在我以前的工作中，这是预料之中的。 开发人员没有说“两周前。我现在正在做其他事情”。 但是，如果在测试中发现基本问题，它们是否真的“完成，完成，完成”？ 似乎有些不对劲。

好的，您说自动化如何？ 这不是基本的敏捷原则吗？ 做测试驱动开发（TDD）？ 如果没有单元测试，开发人员无法交付任何代码？ 如果这足以证明里程碑构建是稳定的并且工作代码可以满足利益相关者的需求，那么为什么我们使用传统的测试方法发现这么多缺陷？ 我们如何定义验证以满足利益相关者的需求 ？ 如果开发团队正在演示，他们将展示什么？ 它是一个完全集成的演示，在整个系统的上下文中向利益相关者展示新功能的价值吗？ 系统越复杂，答案就越有可能是“否”。

这里发生了什么？ 让我们将洋葱去皮一点。 首先，我们有一个采用敏捷方法的开发组织，但是您可能已经注意到我提到了一个“独立”测试团队。 敏捷专家通常推荐嵌入式测试仪。 敏捷过程建立在整个团队方法的基础上（这极大地促进了它的成功）。 那么为什么会有一个独立的测试团队呢？ 因为该应用程序是系统的一部分，该系统实际上太大了，无法包含测试。 即使包括全面的TDD和单元测试以及某种程度的复杂测试（手动或自动）在内的所有最佳意图，开发团队也无法包含系统测试：完整的系统集成，大规模的性能，繁重的工作，大型数据集，安全性-您明白了。 在组织上，有一个独立的测试团队负责下一个级别的测试，通常是通过卓越测试中心来实现规模经济。

所以事情可能看起来像这样：

图1.集成测试落后

而且至少在某些时候，该测试仪需要N天的时间来安装和配置，却发现某些基本功能不起作用。 当它是无法使用的构建时，我们称其为“ 重大破损” ，这实际上并不是任何人的错。 这是人类如何处理复杂性的症状。 我们学习更深入的细节并成为越来越小的领域的专家，因为我们可以掌握的细节数量限制了我们可以深刻理解的领域数量。 这就形成了需要交接的边界和地方。

系统集成测试的新世界

好的，关于这个问题已经足够了。 如果您仍在阅读，那就是您的世界。 而且您可能一直在尝试用至少三遍的方法来解决它：通过向构建过程中添加进行比传统构建中所包含的更复杂的测试（即单元测试）的能力。 您可以构建一个自动化的自动化设置，以安装和配置构建，验证和配置测试工具环境，启动自动化测试套件并报告结果。

如果我们可以简化这一点怎么办？ 还是让越来越多的复杂异构系统（通过SOAP，MQ，SOA等利用各种外部系统）可以访问它？ 现在有服务虚拟化工具，可让您始终进行全面的集成测试。 这意味着更少的硬件和时间来配置复杂的异构系统，从而可以在每个构建上运行集成测试。 而且，如果您的开发团队采用了持续集成，则意味着对每个集成构建都进行集成测试 。

图2.服务虚拟化

服务虚拟化的工作方式是在生产或舞台环境中进行一次记录，然后对受测复杂系统中的组件进行智能存根。 我喜欢将其视为虚拟化系统的复杂性，而将不断变化的部分留给我要测试的部分。 这在很多情况下都很好用，但是在系统的其他组件没有更改或没有快速更改的情况下尤其有效。 它与测试最佳做法非常吻合，该最佳做法是减少变化的数量，然后进行测试。 关于服务虚拟化的一些事情确实令人兴奋：

• 虚拟化系统的复杂性以简化测试环境的设置
• 智能服务虚拟化包括状态功能，可让您的测试完成一些很酷的事情，例如每隔X次服务就关闭一次
• 虚拟化服务中的测试数据管理补充了数据池和企业测试数据工具，例如Optim
• 服务可以在存在之前进行虚拟化
• 测试团队可以在相同的里程碑上与开发团队保持一致，因为设置不再是瓶颈

这使我们回到了敏捷软件开发的承诺，并在每次迭代结束时交付稳定，可运行的代码。 当测试人员和开发人员可以同时对齐同一代码并真正提高质量时，这确实是一个勇敢的新世界。 现在，可以将Green Hat技术作为IBM Rational Test Workbench和IBM Rational Test Virtualization Server的一部分来使用。

---

翻译自: https://www.ibm.com/developerworks/rational/library/early-integration-testing-enables-agile-development/index.html