摘要：在距离“等待页面”模块（因为是双十一的关键模块，安全起见故用这个名称来替代）上线时间还剩2天的时候，接到了该模块的功能测试任务。在简单了解模块功能需求之后发现，如果选择现有的自动化测试工具来测试，将存在不少的盲点（终bug记录，也证明了这点），但是在这么短的时间内不可能自己设计和改造工具，因此当前高效且质量覆盖好的方法，将会是手工测试的方式。

　　模块功能需求：

　　该模块的功能需求非常简单，只有2点。

　　1、流程需求：

　　当用户访问，触发拦截引擎的拦截规则（访问过于频繁）后，前端web服务器（Tengine）将用户的请求转入“等待页面”模块的处理逻辑，“等待页面”模块将用户正常的请求（GET或POST表单请求）进行保存并返回用户一个页面（时间可配置）。当结束后，页面内的js代码触发浏览器自动重新提交用户的请求到其初的url地址（会带上用户原始的GET或POST请求）。如果重试成功，则正常返回用户的请求内容，如果重试失败（再次触发拦截规则），则再次进入等待页面，如果连续重试n（可配）次后，依然失败，则返回失败页面（告诉用户，对不起系统繁忙无法响应您的请求，请返回或前往其他地址）。

　　2、数据转发需求：

　　要求，在经过“等待页面”模块的逻辑处理后，用户请求的数据不能丢失和新增，保证用户在完成的等待时间后，能正常的重新访问初的url。

　　现有的自动化测试工具的弊端及盲点：

　　用于web服务器的自动化测试工具，常用的有1. HttpClient，2. Curl， 3. Perl， 4. Selenium 等。

　　他们的弊端和盲点分别在于：

　　1、难于模拟访问过于频繁从而触发拦截规则；

　　因为该拦截规则具有一点的模糊性，无法明确究竟连续发送几次请求能够触发拦截规则，而且如果一味的采用多发请求的方式，将于跳过页面，从而导致逻辑流程跳跃的问题；

　　2、无法实现页面的自动触发浏览器重新提交用户请求的功能；

　　因为对于基于请求发送，然后验证响应的测试工具，如HttpClient， Curl和Perl，他们所能获得的响应，只能达到获取页面这一步，无法让页面内的js脚本生效触发二次访问。而且虽然可以通过验证页面内的js代码来判断数据转发是否正确，但是有几处bug显示，即使第一经过页面的时候，数据能够完整的保存，但是由于“等待页面”模块的编码问题，导致第二次经过页面的时候，数据被重复编码导致数据篡改和新增的情况。

　　3、无法获取响应信息；

　　看完第二点的时候，你会说，come on 用Selenium吧，它能模拟鼠标动作，能够操作浏览器行为。但是，恰巧Selenium无法获取Resposne Header，Query String Parameters，  Request Payload， Form Data等信息，这也无法验证数据是否完整转发了。

　　4、容易忽略连续重试和失败页面的验证；

　　从几处bug的发现看出，采用自动化测试，容易忽略测试连续重试失败的过程及这之间的数据完整转发的需求，而且很少会将测试进行到返回失败页面这一步。

　　5、容易忽略细微的变化；

　　采用自动化测试，容易忽略每次重试之间的细节变化，如参数顺序和数量的变化，数据编码的前后变化等。