【建议需求】集成mitmproxy进行接口响应改写 about seldom

[defnngj]

不太清楚你的问题，如果要修改响应数据。

1. seldom 发送请求完，用 你说 保存 的json 替换掉 response 的结果。比过，这有点掩耳盗铃，接口真的有问题也无法测出。

2. 利用 mitmproxy 在本机开个代理， mitmproxy 的response 配置是固定的，一旦启动引用配置文件，就不能动态改了。 这种情况 seldom 也不需要集成 mitmproxy。

3. 我们是用是：
   
   这种方案就比较复杂了， 接口服务要支持 路由配置； 还需要单独的mock 服务。 不是 seldom 自己可以实现的。

不清楚你要的是那种方案，或者都不是。请求描述清楚你的问题。

[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

哈哈，可能字有点多，有点啰嗦，见谅

[KJC1999]

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

[yongchin0821]

是接口测试的场景吗。第一次碰见也不明白为什么会有拦截接口信息进行信息篡改的需求。

在我看来，分成两次请求不就行了吗。

第一次是。"login_btn_orders":["google","apple","facebook","dropbox"]
第二次加入Twitter，移除Facebook。也就是 "login_btn_orders":["google","apple","Twitter","dropbox"]

查看自己服务这边接口返回数据是否达到期望就可以了

[KJC1999]

是接口测试的场景吗。第一次碰见也不明白为什么会有拦截接口信息进行信息篡改的需求。

在我看来，分成两次请求不就行了吗。

第一次是。"login_btn_orders":["google","apple","facebook","dropbox"] 第二次加入Twitter，移除Facebook。也就是 "login_btn_orders":["google","apple","Twitter","dropbox"]

查看自己服务这边接口返回数据是否达到期望就可以了

不是的，是应用端的功能测试，接口自动化肯定是修改请求头/体来实现才最为标准，但APP端很多时候的控件入口/弹窗提示/toast提示，都依赖于响应内容，而请求体通常并不会改变，只能通过修改/配置后台数据，才会影响APP拿到的响应内容

[defnngj]

我的理解， 处理过程大概是：

• 请求：接口自动化 ---> 被测接口服务 ---> firebase

• 响应：接口自动化 <--- 被测接口服务 <--拦截- firebase

拦截应该是 frebase 返回给 被测试接口服务 登录类型。 通过配置 firebase 控制 显示哪些登录入口。

正如我上面画的图，要有一种方式 控制修改： 1. 修改 被测接口 服务 指向 mock 数据， 2. 控制 firebase 修改返回的数据。

---分割 ---

数据驱动支持调用接口。

• @api_data()

你可以启动 一个web 服务，以接口的形式 提供 数据驱动所需要的数据，类似造数平台，在改动 seldom 代码的情况下，可以比较方便的管理数据。

[KJC1999]

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