可以看下我之前写的一个基于 fiddlercore 的傻瓜版改包工具：
http://mockserver.codeplex.com/

如果团队有比较强的开发能力，我个人建议别用 Jenkins 了。这个东西我用下来的感觉是比较挫（也可能是我用的版本比较老)。
主要有：

1. 设计疑问：master slave 在执行过程中是保持长连接的。一旦网络抖动，长时间运行的测试用例就会中断，无法获得测试结果。这块完全可以用异步来做，不清楚为啥这么设计。
2. 二次开发问题。如果基于 Jenkins 进行二次开发来修正他的一些底层奇葩设计，修复 BUG 或者实现自己定制化需求，一旦 Jenkins 版本升级，很难为二次开发版本添加新特性。而且 Jenkins 现在的体量太大，二次开发复杂度也比较高。说不定改着改着就踩另一个坑了。
3. 各种版本有各种奇怪 BUG。遇到了除了尝试升级外，一般只能干瞪眼。代码量太大，很难排查。
4. 如果不是直接对 Jenkins 二次开发，而是在上层再封装一层做定制化的需求，这样会导致链路过长。越长链路的系统越难维护，稳定性也越差。

从头做一个分布式持续集成测试系统其实并不那么难。你们现在的系统强耦合 Jenkins，后面维护的人可能会遇到各种坑。特别是需要升级 Jenkins 的时候。如果你们有能力的话，个人建议先将你们现在耦合 Jenkins 的地方抽象出来，把目前的依赖 Jenkins 的逻辑作为一个特殊的实现，同时并行做一个分布式持续集成系统来自己实现这些功能，完成后替换 Jenkins 的实现即可。

我们目前的实践是 Lint 扫一下未使用的图片然后让开发删除。其他的点。。由于问题太多太琐碎，难以推动开发修改。

#3 楼 @eurekasaber 这是我们是基于 Fiddler 内核模块二次开发的 mock 工具，完全开源，改进了一些 Fiddler 用起来不够方便的地方，另外能比较方便地支持加密接口响应篡改。

Fiddler 工具有这个功能。或者可以考虑用我们二次开发的http://mockserver.codeplex.com/
顺便打个广告，我们书中 5.3 章有介绍这个。http://item.jd.com/11728332.html

赠书已经寄出。最后再次感谢 testerhome，感谢 monkey 和桓温对本书的支持！