一、背景：
前段时间我们的安卓端意外地在某一天出现了用户的crash反馈，而该版本已经上线N久了，查找原因居然是某一个接口没有返回数据导致的。当然该接口也是经过测试才上线，但是它依附于第三方的底层服务的不靠谱导致了此次事件的发生。如何避免此类问题再次发生，一方面接口异常需及早发现，另一方面，客户端也不能完全信任接口，做好稳定性及异常测试则显得尤为重要。
客户端的稳定性主要包括自身的健壮稳定，以及与服务端的交互稳定。本文主要探讨与服务端的交互稳定的实践方法。我们主要使用Fiddler来拦截请求，并模拟服务器的各种异常返回数据测试产品的稳定性。
二、接口异常模拟
我们使用Fiddler来进行接口的异常模拟。
1.Fiddler拦截请求
首先我们在fiddler->Rules->Automatic Breakpoints，选中After Responses，如下图所示：
此时所有接下来的请求都会被拦截。
2.修改Response
我们以网易云阅读的书架接口为例。刷新书架，我们把shelf/detail.json接口请求拦截起来。如下图所示：
其中左边显示的是拦截的请求，右边上方是客户端发出的接口请求体（Request），右边下方是服务端返回的正常数据（Response）。为了进行异常模拟，我们需要修改Response的内容。选中TextView，如上图所示，这里是服务端返回的json数据，我们可以人为控制制造出异常数据，比如缺少某个字段或者返回某个字段的异常类型，甚至可以清空Response数据等。
3.执行修改后的请求
直接点击右边下方的绿色按键“Run to Completion”或者在左下角执行框里输入“go”命令敲回车即可，如下图所示：
这两个方法的不同在于，Run to Completion适用于单条请求的通过执行，而go命令则适用于多条请求的通过执行。
以上就是Fiddler模拟接口异常测试APP稳定性的主要方法。这里修改的是Response，显然Request也是可以修改的，方法相似，只是拦截请求的开始选中Rules->Automatic Breakpoints的Before Responses即可。
4.几点思考
（1）虽然用Fiddler模拟异常请求数据较为简单，但复杂的是如何设计测试用例完整地覆盖到全部异常数据，以及如何将复杂的模拟数据操作自动化、脚本化，在客户端更新或者接口更新的时候进行稳定性测试和回归校验，使之能够以最小的代价纳入日常测试中。
（2）Fiddler拦截请求的方法同样可以作为接口安全性测试的重要手段之一。我们完全可以拦截掉客户端发出的请求，并对其明文或者易破解的部分进行修改，验证接口的安全性。PS：通过这种方式发现了云阅读充值相关接口上的一个漏洞（已修复）。
