如何克服录制回放模式的弊端

        Web浏览器的可视化界面及交互操作屏蔽了与服务器端交互的请求响应的复杂性。例如，我们随便打开一个网页或者触发一次交互操作，就可能在后端触发了成百上千的HTTP请求响应的处理，这些过程对使用者来说是不可见的，也是不需要关心的。但是对于开发者和测试者来说，在性能诊断和优化工作中，我们不得不揭开这层黑幕，剖析和跟踪每个请求响应的状态和数据，去淡然面对这种复杂性。

        在基于请求响应模型的自动化测试中，尤其是服务端性能测试，如果让测试者手工去编写处理每个请求的脚本，肯定是死的心都有了。幸运的是测试工具提供的录制回放模式，帮助我们把所有的交互操作转变成了实际的HTTP请求响应脚本，减少了我们手工编写测试脚本的代价。

        对录制回放模式有使用经验的人都应该已经意识到，录制回放模式远远没有听上去那么美好，苦和痛只有体验过才知道，比如脚本维护的代价很高，几乎没什么重用性，稳定性和容错能力很差，没什么可阅读性等等。在一些可持续项目中，录制回放模式的缺点明显大于优点，所以测试高手和高能组织者们都会极力选择摒弃这种模式，自行开发对自家应用程序更可靠更健壮的测试框架。但是对于大部分项目和测试者来说，录制回放是一种不得不选的模式，这使得他们能以零基础或者低门槛开展测试工作，完成任务。

        HyperPacer支持基于Web的脚本录制和回放模式，同时为了克服录制回放模式的弊端，选择性继承Jmeter的组件化设计风格，提供了足够多的组件化支持，给予普通测试者更强大的脚本开发能力，满足对脚本可靠性和健壮性的要求。下面逐项予以介绍：

        参数化硬编码：录制脚本中的数据和变量记录的是录制者操作过程中的硬编码，记录的是一种历史状态极其数据，准确的说只是一个寄希望能复用的脚本模版。比如会话标识和表证单据状态等相关变量，录制结束后就已经失效，回放时对于服务端来说已经属于非法状态和不合规数据，我们需要在回放前替换成服务端认可的有效状态和合规数据，才能运行成功；测试过程中我们需要模拟不同用户或不同情况的输入数据和交互变量进行测试，所以需要将这些变量和数据转变成动态自适应的合规数据，以更真实的模拟各种条件和场景。对于变量处理，HyperPacer提供了响应数据提取器（如正则表达式、CSS/JQuery等），测试者可以从服务器端响应中提取合法状态的数据，替换掉所有请求中的硬编码变量。对于动态数据输入，HyperPacer提供了数据池、数据库（JDBC）提取器等，能帮助测试者提取或生成各种合规的数据，替换掉脚本中的硬编码数据，实现基于数据驱动的测试。

        提高脚本维护性：目前大部分成熟平台都采用透明的组件化开发，组件的动态构造和适应能力导致测试脚本URL路径以及响应数据中Web元素的标识和属性总是处于动态变化中，这让录制的脚本几乎没有什么适用性，只要程序版本或者场景状态稍微发生变化，就得重新录制脚本，甚至为了适应各种情况，需要录制很多脚本。但是大部分情况下，程序中的关键字和元素位置相对固定，基于关键字匹配和相对定位，我们就可以让脚本适应这种变化，HyperPacer中的正则表达式和CSS/JQuery提取器就可以实现关键字匹配和元素相对定位；另外，事务控制器使用户基于操作或者业务逻辑能够对脚本重新进行分组命名，更复杂的情况也可以使用Groovy脚本处理器通过编程实现，从而最大可能的提高脚本维护性，降低维护成本。

        提高脚本重用性：模块化支持是提高脚本重用性的普遍办法，HyperPacer支持对测试脚本进行抽象和重构，将通用业务或处理过程抽象为独立的模块化文件，通过模块化组装实现脚本间的灵活调用；脚本内部的通用处理也可以抽象为测试片段，实现脚本内部的重复调用和统一维护。目前3.0.x版本中还不支持，预计在3.1.x版本中提供更全面的支持。

        提高脚本健壮性：HyperPacer中提供了丰富的逻辑控制器，通过逻辑控制器，可以基于条件控制或变量适应来提高脚本处理异常或流程分支跳转的能力，进而提高脚本的自适应和容错能力，从而开发更加健壮的脚本。

        提高脚本阅读性：HyperPacer中将每个请求抽象为一个独立的取样器，对请求中传递的参数自动进行解析，以表格化编辑的模式展示给用户，将请求的配置变量以表单选项形式提供，通过表单化操作即可完成配置，让脚本更具有可视化阅读能力。