摘要：在距离“等待页面”模块（因为是双十一的关键模块，安全起见故用这个名称来替代）上线时间还剩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、容易忽略细微的变化；
采用自动化测试，容易忽略每次重试之间的细节变化，如参数顺序和数量的变化，数据编码的前后变化等。
手工测试过程：
手工测试过程其实也非常简单：
首先准备测试工具：
1、能够发送GET（自定义URL参数和Request Header）和POST（自定义URL参数，Form Data， Upload FileData， Request Header）请求的HTML文件。
2、后端JBoss上的Servlet，负责将请求发送过来的所有数据通过Response返回回浏览器，便于测试时的请求数据验证。
其次通过浏览器加载HTML文件并设置测试点之后发送请求，不断刷新访问触发拦截规则，观察每次经过“等待页面”模块处理，跳转到倒计时页面后重新触发浏览器执行用户请求及最后触发失败页面的前后请求数据是否一致，流程是否正常。
测试点包括正常逻辑，异常逻辑，空数据，特殊字符，XSS攻击字符等。
bug汇总分析：
本次测试共发现7处bug，2处风险点，鉴于安全考虑，此处就总结几处典型的BUG，风险点咱就不说了。
1、经过“等待页面”模块处理之后，POST请求所携带的URL参数丢失问题：
该问题是由于模块在处理POST请求的数据存储时，没正确保存数据长度，导致数据遗失；
2、POST的表单数据，携带特殊字符，如<，>，/，&等，经过“等待页面”模块处理之后，转译错误，如转译后的字符不完整，转译后的字符经过第二次模块处理之后，再次转译：
该问题是由于模块的转译代码1. 在转译之后没正确保存转译数据长度；2. 没正确区分转译内容，导致多次转译；
3、POST的表单数据，携带特殊字符，如空格，中文等，经过“等待页面”模块处理之后，出现编码错误，如第一次经过模块处理后，空格边encode成“+”，第二次经过模块处理后，继续encode“+”成为“%2B”，导致最后后端Server接收并deconde得到的数据是“+”而不是最初的空格；
该问题是由于模块的encode代码，使用了错误的参数设置，正确的做法是：ngx_unescape_uri函数调用时设置参数 NGX_UNESCAPE_WWW_FORM
4、对不支持的POST数据，直接丢弃POST Data 并强制转换content type为application/x-www-form-urlencoded：
该问题是由于模块对于不支持的POST数据，采用粗暴的处理方案导致的。
----------------------------------------------------------------------------------------------------------------------------
