一次手工测试的实践过程

Valora ·

更新时间:2024-11-15

· 619 次阅读

　　摘要：在距离“等待页面”模块（因为是双十一的关键模块，安全起见故用这个名称来替代）上线时间还剩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汇总分析：