例如，Fiddler是一个Web调试代理，能够记录并实时修改计算机与网络服务器之间的HTTP(S) 通信。Fiddler启动时将自身注册为Windows互联网服务的系统代理，因此能够监控所有Windows程序（包括Windows操作系统）的HTTP通信。Fiddler还支持远程计算机连接，只要在移动设备上将代理设置为运行Fiddler的计算机，就可以使用Fiddler调试Windows Phone、iPod、iPad等移动设备的HTTP通信 。

　　上图显示了Fiddler记录的浏览器与必应词典之间的通信，从区域A可知所查询的单词是testing，从区域B可以获得服务器返回的JSON字符串。可见，测试人员利用Fiddler能够掌握被测产品与服务器之间的通信内容，有助于产生更多的测试想法。在测试过程中，他可以修改客户端发送的请求，以测试服务器能否处理包含错误或攻击的请求；他也可以修改服务器返回的响应，以测试客户端能否处理包含错误或攻击的响应。此外，Fiddler也可以用于错误定位。在客户端行为异常时，可以查看客户端与服务器的通信。如果客户端正确地发送了请求，但是服务器返回了错误的响应，可以推断服务器发生故障；如果服务器返回了正确的响应，则可以推断错误发生在客户端。

探索式测试的实施与管理

　　51Testing：您是如何组织您的测试团队实施探索式测试的？请分享下这方面的实践经验。

　　史亮：我的博客文章“探索式测试：基于测程的测试管理”介绍了由测试专家Jonathan Bach和James Bach提出的基于测程的测试管理（Session-Based Test Management，简称SBTM）。这是目前最知名、也是应用最广的探索式测试管理方法。

　　51Testing：对于探索式测试的管理，您是否有一套自己独有的管理方法？

　　史亮：在测程之上，测试人员应该结合项目语境动态地调整测试策略和测试活动。例如，测试人员接到一个为期一周的测试任务：测试一个即将发布的产品补丁（或测试一个即将上线的新功能）。他可以考虑按如下方式组织测试。

　　周一，他安装补丁，并执行冒烟测试，目的是在第一时间发现严重的缺陷，如补丁无法安装、基本操作执行失败、基本情景被阻塞等。然后，他会收集补丁相关的信息，例如被修复功能的规格说明和测试文档、缺陷描述和修复说明、互联网上相关的业务或技术文档等。他一边积极地学习信息，一边“同情地测试”。测试的目的是检验信息的有效性，获得真实的反馈，并建立产品的测试模型，为进一步的测试做好准备。

　　周一下午，他会根据研究成果，编写一份1~2页的测试计划，列出已经执行和即将执行的测试想法，并发送给补丁开发人员、资深测试同事、项目经理和测试领导，邀请他们对测试计划提供反馈。下班时，测试人员会对未来的测试充满信心，因为他已经验证了基本的功能，并根据多样的信息源和真实的测试反馈拟定了有针对性的测试计划。

　　周二，测试人员会“积极地测试”，对补丁和被影响的相关功能执行深入的测试。在测试的间隙，他会将新的测试想法写入测试计划，使测试计划反映他对产品的最新理解。

　　周三，测试人员已经对补丁和产品有了深入的理解，他也陆续收到同事对测试计划的反馈。他会再次综合各方面信息，完善产品的测算模型，从而“多样地测试”。他可以执行同事补充的测试想法，检查自动化测试的结果，利用测试工具执行压力测试，利用调试器检查产品代码的行为——他会运用一切手段去获取有价值的信息，直至新的信息不再出现。