在我上一篇关于服务虚拟化的文章中，我讨论了使用虚拟响应来模拟还在发展中或尚未可用的应用行为的测试。今天我将讨论下一个问题：如果因为后台系统的行为需要一些不正常的配置，而有一些额外的需求或条件无法用正常的应用来创建，怎么办？
服务虚拟化允许我们接近这个挑战，不仅让我们不受限制地访问后端系统和技术，而且允许我们控制这些组件提供的响应。通常情况下，服务虚拟化用于模拟环境中依赖性组件的快乐路径行为，或者在某个组件缺失时填补空白，但这一点还有另一面。我们可以把这个工作流颠倒过来，用服务虚拟化来模拟现有组件的异常行为。
异常行为模拟
什么是异常行为模拟？最简单地说，它指的是以一种可预测的方式从服务中提供消极的响应，以验证或防范特定的应用行为。为了说明这个概念，我们可以考虑这样一种情况，即开发人员希望对他们的应用程序进行防弹，以防止上游中断。这听起来是每个开发者的重要任务，但现实中，做到这一点通常是不可能的。
想象一下，开发者构建了一个利用PayPal的购物车应用程序，并希望构建一些功能来处理PayPal的中断。也许他们想确保如果PayPal突然下线或发出负面回应，最终用户不会失去他们的进度。在真实环境中测试这个条件将是一个挑战。在没有虚拟化的情况下，开发人员如何做到这一点呢？想象一下，给PayPal打一个电话。“你能让你的服务器今天超时几个小时吗？”这不仅不会是一个很好的对话，而且即使在万一他们真的引入了负面行为，也会影响你的整个开发环境。任何想在当天针对PayPal API进行测试的人都会受到影响。
这就是服务虚拟化的强大之处。由于开发人员控制着虚拟服务，他们将很容易配置这种异常行为。他们可以通过引用PayPal或任何第三方服务合同提供的WSDL或Swagger文档，在自己的私有端点创建一个虚拟PayPal接口。然后他们会进入虚拟服务，并将其设置为“500内部服务器错误”。这将允许开发人员看到在这些条件下他们的代码会发生什么。再进一步，他们可以模拟“200 OK”，但用畸形的JSON响应，甚至可以设置服务响应有相当大的延迟，只是为了看看会发生什么。这种可能性是无穷无尽的。
这种按需的异常测试是非常宝贵的。它允许开发人员按摩他们的代码，同时控制所有类型的异常响应行为。这加快了验证的过程，并在整体上做出更好的应用代码。但这并不是它的止境。还有一些额外的、通常没有想到的领域，模拟异常服务行为可以为开发组织带来相当大的好处，这就是缺陷虚拟化的理念。
那么，什么是缺陷虚拟化？
把缺陷虚拟化看成是一种“负面重放”。你正在做的是为应用程序创造一个异常的环境来“生活”。想想一个碰撞测试假人——你不会把一个碰撞测试假人设置成一辆汽车，它只是在正常情况下在路上行驶。很有可能，那个假人所处的环境是经过特殊配置的，可以为他提供相当糟糕的一天。
这在缺陷虚拟化中也是一样的。模拟外部可能发生的负面条件会迫使应用程序暴露出某种意想不到的行为。这可以是相当强大的，因为你可以使用该模拟环境为QA或开发团队重放行为。团队可以拿着这个模拟环境，亲身体验一下问题所在。这将为他们持续地重放负面行为，在修复应用程序的过程中，他们可以在负面环境中“重放”这个场景，以确保新代码已经解决了问题。