KJC1999

我也准备尝试增加设置一下超时时间，但我也在想需不需要监控线程，这线程一旦崩了，就彻底挂了....

这个问题其实源自我公司内最初的一个自动化需求->firebase配置验证 不清楚你们在生产环境中的配置是自己的服务器还是用别人的服务，我大概描述一下这个场景吧。 比如登录配置中，有Google登录、Facebook登录、Twitter登录、dropbox登录 在之前Twitter大改后，将我们的服务拒绝掉了，所以在firebase上将这些登录入口做成可配置项，作为兜底 目前firebase的返回json中有一项是 `"login_btn_orders":["google","apple","facebook","dropbox"]` 但如果哪一天Twitter恢复了我们的权限，那么json会更改配置，并且根据这个返回的列表按照顺序放出登录入口 我们想做的就是拦截掉接口，然后更改到自己想要的（比如放出Twitter入口，屏蔽Facebook入口），以此来验证该功能是否正常 至于大佬提到的在本地开代理后，配置固定，是指修改的响应内容/文件吗？ 我这边是在用例中看情况进行前置函数/类&后置函数/类来对mitmproxy的服务进行开关，这样我也能在执行用例的过程中支持多个响应体的赋值/修改 其实建议集成mitmproxy的原因也是我们没有太好的头绪去管理数据驱动，这类配置通常是产品去定义，但我在看到seldom中内置的数据驱动方法，觉得这好像就是符合我们业务的数据驱动，也有在考虑要不要迁移到seldom 哈哈，可能字有点多，有点啰嗦，见谅

另外提一嘴，mitmproxy其实并不是服务于接口测试，而是应用端的功能测试，关注于应用端在接口修改后的反应

> 是接口测试的场景吗。第一次碰见也不明白为什么会有拦截接口信息进行信息篡改的需求。 > > 在我看来，分成两次请求不就行了吗。 > > 第一次是。`"login_btn_orders":["google","apple","facebook","dropbox"]` 第二次加入Twitter，移除Facebook。也就是 `"login_btn_orders":["google","apple","Twitter","dropbox"]` > > 查看自己服务这边接口返回数据是否达到期望就可以了 不是的，是应用端的功能测试，接口自动化肯定是修改请求头/体来实现才最为标准，但APP端很多时候的控件入口/弹窗提示/toast提示，都依赖于响应内容，而请求体通常并不会改变，只能通过修改/配置后台数据，才会影响APP拿到的响应内容

> 是的，因为我自己也将mitmproxy封装好了，也在考虑迁移的事情，后面我会看看能否二次开发seldom，毕竟适合业务的自动化框架才是最重要的哈哈

那看来我还是要去弄下大漠试试了，可惜大漠注册需要花钱哈哈

谢谢大佬，我这就去研究下大漠