使用 Spring 的 Web 服务模拟器框架解决方案（2）模拟器最佳实践

look_w

模拟器最佳实践模拟器概览韦氏词典对模拟器的定义是 “能在试验条件下重现或表示出有可能会在真实情况中发生的现象的设备 ”。模拟器可在 SDLC 过程中使用，通过为后台服务提供端点实现更加敏捷的开发环境，后端服务呈现为一个调用应用程序，但实际上只是模拟真实的系统。模拟器以与实时后台服务相同的形式进行响应，并使用相同的请求/响应约定，但只是简单地从配置数据返回预置数据。这样就可以对支持系统的功能性和非功能性特性建模，即使您没有访问系统本身。        
比较常见的和通用的编程实践是使用 stub 接口，这种接口绕过了本地客户端接口调用，而是执行另外的本地代码路径并返回预置数据。很多情况下，stub 可加速初始开发，但无法实现执行整个代码路径和调用工作接口所能获得的功能。使用 stub 方法时，应用程序需要知道它正处在 “stub 模式” 下，这样才可以执行不同的代码路径。通过使用模拟器，应用程序只改变端点，而不会知道响应来自于模拟的后台系统。         
图 1 和图 2 显示出两种方法的区别
图 1. 应用程序使用本地 stub 代码，绕过 Web 服务调用图 2. 应用程序使用模拟器作为 Web 服务端点，取代活动的后台系统大多数情况下，应用程序会与各种 Web 服务交互，您可能最初希望在活动接口不可用时使用 stub 方法。这会在用户接口快速生成所需的可视流程，但客户端的 stub 不会测试数据的内部连接与编组。因此，模拟越深入，获益越大，因为可以运行更多的系统功能。图 2 演示了创建模拟器的最佳位置。        
为了更深入地演示这个概念，让我们查看一个 Web 2.0 示例，它包含一个来自客户端的 Asynchronous JavaScript and XML (Ajax) 请求和一个来自服务器的 JavaScript Object Notation (JSON) 响应，该服务器依赖后台系统构建响应。        
图 3. Web 2.0 交互示例建立的第一个约定是客户端与应用程序间的 JSON 对象。第二个约定位于应用程序与使用 Web Service Definition Language (WSDL) 的后台服务器之间。在初始开发阶段，JSON 约定和 Web Service 约定表示的是可以创建 stub 接口的共同位置点，这样就可通过维护约定来保持不同开发人员的独立性。        
理论上，当每个开发小组按照约定完成开发任务后，就可以顺利地集成应用程序。然而，在实际中，当集成多个外部系统时，情况并非如此。在接口集成期间经常会返回意外结果，或者服务到服务之间出现一系列依赖调用，这需要对调用进行编排。一个被破坏的或不可用的接口可能阻塞多个下游开发团队。        
在开发中使用模拟器的优点当与多个团队开发复杂系统（存在许多依赖关系）时，几乎不可避免地会出现接口延迟的风险。服务模拟将会成为重要的风险缓解工具，可以在开发复杂系统时采用该工具来显著减少风险与延迟。        
在决定模拟程度时需要考虑几个关键因素。很多情况下，最简单的模拟是不管输入是什么都返回相同的响应。这对于初始单元测试有效，但很难保证获得优质的代码。更常见的做法是，对模拟器加以扩展，能够根据请求数据返回更复杂的响应。某些情况下，用请求数据在 XML 文件中查找响应。对于其他的情况，在计算中重用或处理请求数据以用于响应。        
为了能实现更复杂的响应，需要构建简单、灵活和轻量级的模拟器模式，以便能被开发人员轻松采用，并且还提供了深入的模拟。             
图 4. 模拟器可访问的数据将影响其对于开发团队的可用性以及最后的成功 使用模拟器进行功能测试的优点在 SLDC 中使用模拟的好处超越了开发阶段。更新的技术，如 scrum、极限编程、特征驱动开发，可以促进迭代开发，但可能与传统的瀑布驱动方法冲突，在瀑布驱动方法中，一些连续的接口（gate）需要汇合以移到下一阶段。如果快速开发组件依赖于关键接口且开发周期较长，迭代测试就难以实现。在这种情况下，模拟器将会在活动接口可用前测试组件，并能提前发现主要问题。当试图向后台系统提供测试数据以支持可能发生的错误场景时，通常会遇到挑战。模拟器会提供有效的替代方法测试不常见的场景或难以使用活动后台系统实现的反向（negative）测试案例。         
模拟器也提供了一个强大的风险缓解策略。随着系统接口数量和复杂性的增加，故障和延期的风险也会增加。以下的情况经常会出现：接口不可用，因为需要使用补丁修复错误；或者开发人员必须安排宕机时间来处理活动测试窗口中的接口。这种情况下，开发和测试团队需要付出更多宝贵的时间才能实现一个完整的、有效的系统。通过在测试环境中使用模拟器，应用程序可以为特定的接口重新配置接口端点，将其从不可用的服务调整到正常的模拟服务，从而避免出现停机。测试系统可以继续对所有工作中的系统使用活动接口，只对不可用的服务使用模拟器。        
通常会开发一个服务指示板来结合用于模拟器，从而支持开发人员与测试人员测试模拟服务的请求和响应。这可以对请求数据配置进行快速验证。由于模拟器模仿活动的后台服务，服务指示板也可以在活动后台服务可用时测试和解决故障。某些情况下，服务指示板会揭示出一些在模拟器中不可用的独特响应场景。服务指示板可包含记录原始请求和响应的功能，能够扩展模拟器以使其将该场景添加到模拟集中。        
图 5 演示了由一组后台服务和模拟器共同支持的系统的逻辑视图。图中显示了一个外部应用程序通过 Enterprise Service Bus (ESB) 连接到各个服务。黄颜色的服务（服务 1、2 和 7）指示服务此刻不可用，由模拟器提供。红颜色服务（服务 3 和 4）表示服务正在部署或是不可用。指向红颜色服务的请求将通过 ESB 重新路由到模拟服务上。        
图 5. 同时利用模拟服务和活动后台服务的系统的逻辑视图 使用模拟器进行非功能性测试的优点性能测试是 SDLC 中的重要方面。许多情况下，用于测试的环境无法模拟出生产环境的性能特点。经常有这样的情况，公司的系统由于过于昂贵而无法在测试环境中完全重现。这种情况下，模拟器可以很好地支持性能测试，因为它们能模拟出期望的生产环境。        
要理解为什么模拟器会成为很好的性能测试工具，需要对负载有所理解。Little 的 负载定律（Law of Load）指出，平均负载（L）等于到达率（λ）乘以完成事务的平均处理时间（T）。即，L = λT。        
如果一个应用程序需要 1 秒的时间来响应请求，那么每秒的请求数必须是 1，负载才能均衡。图 6 演示的是到达率上升而持续时间不变的情况。许多前端负载测试工具强调提高到达率以产生负载。        
图 6. 增加每秒请求数而响应时间不变反过来也一样，并且展示了到达率在注册时未改变，但应用程序的响应时间会降低。图 7 显示的是响应率下降而请求率不变的情况。        
图 7. 每秒请求数不变，响应时间下降图 6 和图 7 在复杂系统中都很常见。值得注意的是请求率和响应时间都对负载有显著影响。         
负载测试通常会强调通过增加客户端访问应用程序的到达率增加负载（λ）。这通常可由 Mercury Load Runner 或 IBM Rational Performance Tester 之类的负载生成工具实现，但没有处理后台系统用于返回结果的预期平均处理时间（T）。作为推荐的最佳实践，模拟器可以和性能模型联合使用以生成更贴近生产环境的性能测试，通过使用性能模型决定每个接口的平均响应，并将这些响应时间编入到模拟器中。        
可根据生产中现有的或预期的响应时间，用性能模型文档记录每个生产系统的 Service Level Agreements(SLA)。这包括不同级别的请求率的响应时间。通常，每个请求的响应时间将会随着每秒事务量 (TPS) 的增加而减少。这些变化的响应时间也会被包含到模拟器内，以更好地对预期生产环境建模。        
通过在服务中模拟暂时的 “hiccup” 或暂停，或者通过模拟预计的 SLA 以外的响应来衡量对依赖系统的影响，模拟器还可以用于实现反向性能测试场景。这种额外的测试级别允许在 SDLC 中尽早发现并解决问题。